Please remove RFCs from the documentation in Debian packages
(For those who are not aware of this issue, please read #92810) Since the doc-rfc packages have been moved to non-free, I have just cloned the doc-rfc RC bug (#92810) and assigned it to some other packages which provide RFCs (for a full list see the the bug report, but more might be affected). I advise maintainers which include RFCs in their packages to remove the RFC documentation from them. Also, since ISOC has not been contacted (as far as the information on the bug reports describes), it would be nice for someone to clarify the copyright issue with ISOC (the maintainer does not want to do it himself, as he states in the last upload's changelog). It seems that some RFCs might be DFSG-free (probably the earliest), I encourage maintainers to clear this up with the Internet Society and, if possible, create a package with DFSG-free RFCs. This has been discussed several times at debian-legal [1] and is now currently discussed there [2] too. Friendly Javier Fernandez-Sanguino [1] Such as: http://lists.debian.org/debian-legal/2002/debian-legal-200210/msg00352.html http://lists.debian.org/debian-legal/2002/debian-legal-200203/msg00012.html or http://lists.debian.org/debian-legal/2003/debian-legal-200304/msg00356.html [2] http://lists.debian.org/debian-legal/2003/debian-legal-200307/msg00012.html pgpjzOU7zFAtE.pgp Description: PGP signature
NMU (was: )Re: po-debconf de configure-debian)
(désolé, j'aurais du changer le sujet plus tôt) Quoting Mathieu Roy ([EMAIL PROTECTED]): De toute façon, les docs à ce propos sont assez claires (pas de NMU pour des bugs mineurs, pas de NMU sans avoir contacté le mainteneur, pas de NMU sans respecter un délai). Je cherche encore où les docs sont claires sur le fait qu'il ne faut pas faire de mise à jour indépendante (NMU) pour des bogues mineurs. La référence du développeur est muette à ce sujet. Elle donne un protocole précis, mais pas de limite pour l'objectif des NMU. En fait, comme beaucoup de documentations Debian, elle fait appel à l'intelligence du lecteur plutôt que de chercher à mettre des règles strictes. C'est évidemment très bien comme cela et c'est pour cela que je continuerai à proposer des NMUs, voire à les faire, pour des bogues de traduction. En fait, je pense sincèrement qu'un mainteneur non réactif est, en soi, un bogue plus important que les bogues qu'il laisse lui-même trainer dans le BTS. Quand, les uns et les autres, nous avons pris l'engagement de maintenir un ou plusieurs paquets, nous nous sommes engagés à fournis une certaine qualité de travail. Ceux qui lèvent des bogues sont nos alliés principaux et c'est pour cela que nous avons le devoir de tout faire pour ne pas laisser trainer des bogues, surtout quand ils sont triviaux à corriger. Et, quand on voit les outils qu'on a dans Debian pour nous aider à faire cela (BTS, PTS, etc.), on n'a guère d'excuse.. :) Rappelons que, dans le cas du paquet configure-debian, il s'agissait de : -mv debian/po/pt_FR.po debian/po/fr.po -debchange -i pour documenter -debuild -dupload Si un mainteneur est trop occupé pour faire ne serait-ce que ça, j'ai des doutes sur sa réelle qualité de mainteneur. Donc je le titille un peu en proposant, voire en faisant, un NMU.
Re: po-debconf de configure-debian
Christian Perrier [EMAIL PROTECTED] wrote: La réponse vaut pour toi et Denis, je ne veux pas poster 2 fois ;) Surtout si c'est pour un truc aussi important que des fichiers mal nommés dans debian/po. Là je comprends que le mainteneur puisse avoir une furieuse envie d'étrangler l'auteur du NMU... Et pourquoi donc ? Le premier mail parlant de NMU laissait plutôt présager une NMU un poil sauvage, c'est surtout ça qui me dérangeait. Je n'ai rien contre une NMU dans les règles ou avec l'accord du mainteneur, pour ce qui est des bugs normaux. Pour ce qui est des RC, là j'en suis au stade pas de quartier, NMU dans delayed-3 et puis c'est tout (pour les bugs suffisament vieux). La correction est totalement triviale à faire. Comment expliquer autrement que par un manque de temps le fait qu'elle ne soit pas faite ? C'est une question que je me suis longtemps posée, et puis un jour j'ai réalisé qu'il y avait des gens qui, malgré leur bonne volonté, n'avait pas le temps matériel de faire même de petites corrections. Ca arrive. Dans ce cas, le NMU est un aide au mainteneur : l'aider à ne pas s'embarrasser de bogues qui encombrent sa page de bogues. Avec toujours ce risque de voir les bugs réapparaître dans la version suivante du mainteneur, parce que patch oublié ou fix pas compris :/ Mais ça on n'y peut pas grand chose, tu me diras... Je veux bien qu'on ne veuille pas sortir une version à chaque fois qu'il y a un bogue à fixer...mais de là à laisser ouvert plusieurs dizaines de jours des bogues qui proposent un fr.po ou un pt_BR.po, il y a un monde. Ca ne me choque pas plus que ça, mais je ne dois pas être assez porté sur les traductions. Qui plus est, dans les bogues liées à la traduction, on doit pouvoir dire sans trop de forfanterie qu'on a souvent plus de compétences pour les fixer que pas mal de mainteneurs. Je vous le laisse volontier :-) (surtout, imho, quand c'est de l'anglais de vache espagnole qui est dans les écrans debconf) tetex-* ? JB. -- Julien BLACHE - Debian GNU/Linux Developer - [EMAIL PROTECTED] Public key available on http://www.jblache.org - KeyID: F5D6 5169 GPG Fingerprint : 935A 79F1 C8B3 3521 FD62 7CC7 CD61 4FD7 F5D6 5169
Re: po-debconf de configure-debian
Christian Perrier [EMAIL PROTECTED] writes: La correction est totalement triviale à faire. Comment expliquer autrement que par un manque de temps le fait qu'elle ne soit pas faite ? Il se trouve que le mainteneur en question est dans le processus NM et que je m'occupe de son application. Effectivement, il a souffert d'un manque de temps chronique ces derniers temps. Ceci-dit, sa réaction face au NMU a été positive. Dans ce cas, le NMU est un aide au mainteneur : l'aider à ne pas s'embarrasser de bogues qui encombrent sa page de bogues. Il y a des aides qui facilitent plus ou moins :-). Un NMU a également un coût car il peut désorganiser le travail du mainteneur (par ex. s'il utilise un outil de gestion de versions). En outre, il faut quand même relativiser, des bugs RC restent ouverts très longtemps, ça ne me choque pas qu'un bug minor ne soit pas corrigé dans la seconde (surtout que le rapport de bug original ne précise pas quelles fonctionnalités ne fonctionnent pas). Je veux bien qu'on ne veuille pas sortir une version à chaque fois qu'il y a un bogue à fixer...mais de là à laisser ouvert plusieurs dizaines de jours des bogues qui proposent un fr.po ou un pt_BR.po, il y a un monde. Je ne comprends pas le problème: pt_BR me semble correct, puisqu'il s'agit du Portugais parlé au Brésil. Typo ? Qui plus est, dans les bogues liées à la traduction, on doit pouvoir dire sans trop de forfanterie qu'on a souvent plus de compétences pour les fixer que pas mal de mainteneurs. C'est sûr. La répartition de la responsabilité sur les traductions manque peut-être également de recul. Je suis convaincu que le mainteneur ne devrait pas avoir à s'en occuper, car comme tu dis, ce n'est pas son boulot. Un exemple parmi d'autres: les templates de mes paquets, que j'écris pourtant dans ma langue maternelle, ne respectent pas les normes de vocabulaire de l'équipe de traduction. A+ -- .''`. ; ;' ; Debian GNU/Linux | Benjamin Drieu `. `'http://www.debian.org/ | [EMAIL PROTECTED] `- pgpHGIIDVEvNA.pgp Description: PGP signature
Re: po-debconf de configure-debian
Salut à tous, Le jeudi 03 juillet 2003 à 12:10 +0200, Benjamin Drieu a écrit : [...] C'est sûr. La répartition de la responsabilité sur les traductions manque peut-être également de recul. Je suis convaincu que le mainteneur ne devrait pas avoir à s'en occuper, car comme tu dis, ce n'est pas son boulot. le point important c'est que tous les responsables de paquets ne s'accordent pas sur ce point. (Voir la flame d'il y a quelques semaines sur debian-devel) Un autre point, et je pense que c'est le plus important, il faut trouver une structure pour gérer les traductions en dehors des paquets et mettre au point un système qui rende les traductions indépendantes du paquets de base. Avoir un paquet atomique et pouvoir lui ajouter des modules. Avec par exemple un module pour la documentation, un module pour la traduction française, un module pour la traduction italienne... C'est peut-être une idée assez utopique, mais ça me semble intéressant et c'est une piste de réflexion sur laquelle nous devrions nous pencher. A+ -- Pierre Machard [EMAIL PROTECTED] TuxFamily.org [EMAIL PROTECTED] techmag.info +33(0)668 178 365http://migus.tuxfamily.org/gpg.txt GPG: 1024D/23706F87 : B906 A53F 84E0 49B6 6CF7 82C2 B3A0 2D66 2370 6F87 pgpaqKU9CwYGa.pgp Description: PGP signature
Re: po-debconf de configure-debian
Le jeudi 3 juillet 2003, Benjamin Drieu écrit : Christian Perrier [EMAIL PROTECTED] writes: Je veux bien qu'on ne veuille pas sortir une version à chaque fois qu'il y a un bogue à fixer...mais de là à laisser ouvert plusieurs dizaines de jours des bogues qui proposent un fr.po ou un pt_BR.po, il y a un monde. Je ne comprends pas le problème: pt_BR me semble correct, puisqu'il s'agit du Portugais parlé au Brésil. Typo ? bien sûr que c'est correct, mais quand quelqu'un a fait un travail (la traduction ici) il n'est pas logique de laisser le bogue ouvert pendant plus d'un mois à mon sens : - soit le responsable travaille sur son paquet et de toute façon il fait une mise à jour pour autre chose et n'a donc qu'à ajouter la nouvelle traduction ; - soit il ne travaille pas dessus et il fait la mise à jour avec seulement la nouvelle traduction parce que ce n'est pas difficile à faire et très rapide et que ça sert à plein de gens non anglophones. Nicolas --
Re: Info, pb de dépendances
Maxime Chatelle [EMAIL PROTECTED] a tapoté : Salut, J'aurait souhaiter savoir comment je pouvais signaler un probleme de dépendance ? (avec reportbug ?? ) (ou par mail au mainteneur ?? ) il y a un mois environ, j'ai installer Sid sur une de mes machines et j'avais remarquer un probleme de dépendance: ksysguardd dépend de libsensors1 (qui n'existe pas) j'ai donc modifié ma ba base /var/lib/apt/list/mirroir.debian pour y mettre libsensors-1debian1 à la place j'ai aussi dû reconstruire le packet. Et j'ai eu le même problème avec kuickshow qui dépend de imlib2 ( qui a été renomé en libimlib2 ) J'ai donc fait les même opérations que plus haut. J'avais envoyé un mail aux mainteneur respectif mais il ne m'avais pas répondu, j'ai donc cru que le bug était résolut. Mais, il y a 2 jours, j'installais la Sid sur mon portable et rebelotte je problème est toujours là. Etait-ce la bonne solution que d'envoyer un mail aux mainteneurs ? Ou doit-je utiliser reportbug ? A priori, ça devrait être envoyé a reportbug. Le mainteneur recevra l'info de toute façon et même si le bug n'est pas confirmé, ne peut être résolu, il sera en tout cas archivé, permettant à d'autres personnes confrontée au problème d'avoir une réponse directement. -- Mathieu Roy Homepage: http://yeupou.coleumes.org Not a native english speaker: http://stock.coleumes.org/doc.php?i=/misc-files/flawed-english
Re: Info, pb de dépendances
* Maxime Chatelle [EMAIL PROTECTED] [2003-07-03 21:02] : Salut, J'aurait souhaiter savoir comment je pouvais signaler un probleme de dépendance ? (avec reportbug ?? ) (ou par mail au mainteneur ?? ) il y a un mois environ, j'ai installer Sid sur une de mes machines et j'avais remarquer un probleme de dépendance: ksysguardd dépend de libsensors1 (qui n'existe pas) j'ai donc modifié ma ba base /var/lib/apt/list/mirroir.debian pour y mettre libsensors-1debian1 à la place j'ai aussi dû reconstruire le packet. Et j'ai eu le même problème avec kuickshow qui dépend de imlib2 ( qui a été renomé en libimlib2 ) J'ai donc fait les même opérations que plus haut. J'avais envoyé un mail aux mainteneur respectif mais il ne m'avais pas répondu, j'ai donc cru que le bug était résolut. Mais, il y a 2 jours, j'installais la Sid sur mon portable et rebelotte je problème est toujours là. Etait-ce la bonne solution que d'envoyer un mail aux mainteneurs ? Ou doit-je utiliser reportbug ? Soit ça, soit créer un rapport de bogue dans le BTS (en utilisant reportbug si tu apprécies cette interface, mais tu peux aussi le faire manuellement ou autre). L'avantage du rapport de bogue est que d'autres personnes qui auront remarqué le problème n'enverront pas un nouveau courrier au responsable Debian car il verront que le problème a déjà été signalé. Pour les problèmes que tu signales, il s'agit des bogues 196370 et 196009. Pas besoin donc d'envoyer un courrier au responsable Debian dans ce cas. Fred
Re: NMU (was : )Re: po-debconf de configure-debian)
On Thu, Jul 03, 2003 at 09:14:34AM +0200, Christian Perrier wrote: (désolé, j'aurais du changer le sujet plus tôt) Quoting Mathieu Roy ([EMAIL PROTECTED]): De toute façon, les docs à ce propos sont assez claires (pas de NMU pour des bugs mineurs, pas de NMU sans avoir contacté le mainteneur, pas de NMU sans respecter un délai). Je cherche encore où les docs sont claires sur le fait qu'il ne faut pas faire de mise à jour indépendante (NMU) pour des bogues mineurs. Voilà l'URL qu'il te faut ;) http://lists.debian.org/debian-devel/2003/debian-devel-200302/msg01996.html Denis
Re: debootstrapping and sysvinit
On Wed, 02 Jul 2003, Miquel van Smoorenburg wrote: I accepted maintainership because I am the upstream author, and having [...] In short, I am actively developing the Debian and non-debian parts of it. It's just that I happen to do this in bursts, and some people get upset when the bursts they develop in don't always overlap with mine. That's actually why it is a good idea to either have a downstream maintainer (as you used to, when you were not the Debian maintainer of something you're also upstream), or co-maintainers that you can trust to pick up the pace when you can't do it (but still do it in a way that won't upset you). -- 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: Status of Unofficial Sarge Release Issues (Updated for July)
Drew Scott Daniels [EMAIL PROTECTED] wrote: The last time I posted my unofficial release issues status I received several requests to change the formatting, and so I have. I plan to find a site to host this html document (preferably alioth), but I haven't ironed out the details yet. It should also be strongly noted that this is an unofficial document. I know text is preferred by many over html, but formatting is easier for me in html than in text. If anyone's interested in a text only version, let me know. Please. lynx -dump or w3m -dump Or change this [-- application/octet-stream, Encoding base64, 465 Zeilen, Name: usri.html --] to sane values - for example text/html with encoding 8-Bit. thanks for your work, cu andreas
Concurrent CLEAN Package
Last I mentioned my intention to package CLEAN for Debian. Someone (Sorry I lost your email.) replied me that there is already a CLEAN package for Debian. But I can't find the package from apt-cache. I thought it was still waiting in incoming queue so I waited for awhile, but it's still not there. Can you tell me the current status of CLEAN in Debian? Thanks! -- ZHAO Wei [EMAIL PROTECTED] [EMAIL PROTECTED] http://www.advogato.org/person/zhaoway/ Linux Free Software Consultant, Nanjing, China
Re: Debconf or not debconf
On Wed, Jul 02, 2003 at 08:53:57PM -0400, Joe Drew wrote: Joey Hess has mentioned, and I agree (see 199722), that debconf notes should really be named (and should always be interpreted as) warnings. Huh. I thought it was supposed to be even stricter than that; errors only. E.g.: Template: xserver-xfree86/config/device/bus_id_error Type: note _Description: Please enter a bus identifier in the proper format. The BusID should be a string in the following format: . bustype:bus:device:function . Where bustype is PCI for PCI and AGP video cards, and each of bus, device, and function is a decimal (not hexadecimal) value. For example, PCI:0:16:0 is valid input (without the double-quotes). I'm trying to get my debconf notes down to just input validation errors. -- G. Branden Robinson| The key to being a Southern Debian GNU/Linux | Baptist: It ain't a sin if you [EMAIL PROTECTED] | don't get caught. http://people.debian.org/~branden/ | -- Anthony Davidson pgpQCEifDZowM.pgp Description: PGP signature
Package Moscow ML and HOL
I intend to package Moscow ML and later HOL theorem prover for Debian. This is not a fromal ITP because I'm not eager to prevent others from doing the same. :) I won't compete with you too. The purpose of this mail is that I want to know if there is already these packages somewhere and why they're not yet in Debian main? Thanks! -- ZHAO Wei [EMAIL PROTECTED] [EMAIL PROTECTED] http://www.advogato.org/person/zhaoway/ Linux Free Software Consultant, Nanjing, China
Re: Gnome2 in sarge
On Wed, 02 Jul 2003 13:21:26 -0300, Daniel Ruoso wrote: I didn't see any noise in debian-devel see debian-gtk-gnome -- .''`. Mark Howard : :' : `. `' http://www.tildemh.com `- [EMAIL PROTECTED] | [EMAIL PROTECTED] | [EMAIL PROTECTED]
Re: Bug#199642: xpilot: French translation of the debconf templates
On Wed, Jul 02, 2003 at 06:12:02PM -0300, Ben Armstrong wrote: [...] Now I'm left at a loss as to what to do with the file. I want the half-finished work to remain in the package so that someone picking up the package and customizing it (or in future, adopting it, should I decide to ever give it up) can benefit from it. [...] Instead of shipping useless files, you could open a bugreport against your package to track your changes down. Denis
Re: Package Moscow ML and HOL
On Thu, Jul 03, 2003 at 02:02:26PM +0800, ZHAO Wei wrote: I intend to package Moscow ML and later HOL theorem prover for Debian. This is not a fromal ITP because I'm not eager to prevent others from doing the same. :) I won't compete with you too. I remember vaguely that there used to be a licence problem with Moscow ML. What is its exact licence now? -Ralf. --
RE: debootstrapping and sysvinit
Miquel van Smoorenburg wrote: Julian Mehnle [EMAIL PROTECTED] wrote: Miquel van Smoorenburg wrote: And you think an attitude like this is going to make me work harder? For *you* ?? Get real. Regardless of whether it was right to NMU sysvinit without you being notified: I get the impression maybe you should think over why you have accepted maintainership of the package. If you are maintaining it for your own sake only, then maybe you should give up maintainership and use a self-maintained, forked copy of the package. I accepted maintainership because I am the upstream author, and having the package in Debian/unstable is a great way to make sure it is stable. I can also try out new features, and Debian will have it first. Please excuse my ignorance of not recognizing you as the upstream author. Your statement above made me feel like you had no real interest in keeping the package working for everyone else. I'm sorry! Julian.
Re: [devel] Debconf or not debconf
Re: Re: [devel] Debconf or not debconf [Jim Penny [EMAIL PROTECTED], Wed, Jul 02, 2003 at 10:50:29AM -0400, [EMAIL PROTECTED]] It breaks 100% of stunnel installations. The old stunnel was command line oriented, the current one is configuration file oriented. It would be very difficult to write a converter. Well, it broke my installation. I read the -devel thread over the last days, and even then I thought It won't concern me as I'm using stunnel from /etc/inetd.conf instead of a stand-alone service. In the end, I could no longer fetch mail via imaps after upgrading to the current Sarge version of stunnel. I think the main point about Debian is to provide a smooth upgrade of packages, and in this case, a debconf note about you will have to write a stunnel configuration file would have been *much* nicer than just breaking the program. One has to tune his system anyway after the upgrade, so I would have been very glad had Debian told me what to do. (Which is just one Enter press more for those who already know.) On the other hand, not changing the interface is even nicer. But if upstream decides to change it, there are probably good reasons to follow that. And yes, I read the README.Debian, the manpage etc. But a debconf note would have sped things up further. Christoph -- Christoph Berg [EMAIL PROTECTED], http://www.df7cb.de Wohnheim D, 2405, Universität des Saarlandes, 0681/9657944 pgpN9v0vmmPmV.pgp Description: PGP signature
Re: Bug#199642: xpilot: French translation of the debconf templates
On Wed, Jul 02, 2003 at 06:12:02PM -0300, Ben Armstrong wrote: Now I'm left at a loss as to what to do with the file. I want the half-finished work to remain in the package so that someone picking up the package and customizing it (or in future, adopting it, should I decide to ever give it up) can benefit from it. But to include the translation is going to give the wrong signals to other translators, causing them, too, to spend unnecessary time with translations for texts that aren't even in use in the package. So, how do I include development only text in debian/foo.templates that translators are not to waste their time translating until it actually goes into production? And do we need a standard for this? You can put a README.trans in debian/ where you explain the situation, and clearly state that those files should not be translated. You can also add an header in the template stating it. Just add plain text without special formating. It will break the template handling tools, forcing translators to check the source to see why, and realize those facts. Yet another way is to create a debian/underway directory, and pack everything not done yet here. I guess the tools used by translators to check what is still to do won't find them here. Once this is done, you can add the translated stuff for archiving without fear. Bye, Mt. -- Tout dormeur a en lui un lève tard qui sommeil.
Re: Debconf or not debconf
Joe Drew [EMAIL PROTECTED] wrote:
On Wed, 2003-07-02 at 17:23, Herbert Xu wrote:
I'd prefer no interaction at all during installation. I'm perfectly
able to read documenation thank you very much.
Happily, the noninteractive debconf frontend exists.
And getting hundreds of emails after a mass upgrade? No thanks.
--
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: Ein paar Fragen zu meinem Mailserver
Kai Timmer wrote: Stelle ich nun die Zeile mydomain = kaitimmer.local funktioniert das Schon mal daran gedacht, das local.kaitimmer.de zu nennen? Dann sollte es dem Relay egal sein. Gruss T. pgpQd9BwbMqix.pgp Description: PGP signature
Re: inews path question
On Wed, Jul 02, 2003 at 12:30:02AM +0100, Matthew Garrett wrote: Hopefully, Debian Policy (and FHS) will allow the use of libexec some day... Debian's not a BSD, regardless of the kernel that it's running on. AFAIK, /libexec is used by the theoretical GNU system as well. Michael
Re: Concurrent CLEAN Package
On Thu, Jul 03, 2003 at 01:57:54PM +0800, ZHAO Wei wrote: || Last I mentioned my intention to package CLEAN for Debian. Someone || (Sorry I lost your email.) replied me that there is already a CLEAN || package for Debian. But I can't find the package from apt-cache. I || thought it was still waiting in incoming queue so I waited for awhile, || but it's still not there. || || Can you tell me the current status of CLEAN in Debian? Are you on the Clean mailing list? If not, go to http://www.cs.kun.nl/~clean/. You can ask on the mailing list about debianising Clean. It will not go into main because of license restrictions (not for commercial purposes), unless they've changed the license recently. There was also the problem of having to bootstrap the compiler using the old closed source compiler, because it's written in Clean itself, but the new compiler can be used for it now. I myself may have said something once about debianising Clean (used to work there), but I don't remember really, and it is probably a little too much for me now. Ciao. Vincent.
Re: Concurrent CLEAN Package
On Thu, 2003-07-03 at 14:51, Vincent Zweije wrote: Are you on the Clean mailing list? If not, go to http://www.cs.kun.nl/~clean/. You can ask on the mailing list about debianising Clean. I'm subscribing right now. Thanks for the reminder. It will not go into main because of license restrictions (not for commercial purposes), unless they've changed the license recently. I think they did change the license to LGPL a few months ago. I will check it again. But since there is already a debian package for CLEAN by bfulgham, I think all I need to do is to wait. :) Thank you all who replied! -- ZHAO Wei [EMAIL PROTECTED] [EMAIL PROTECTED] http://www.advogato.org/person/zhaoway/ Linux Free Software Consultant, Nanjing, China
[no subject]
hi, this is test msg. pls ignore. tks.
Re: Package Moscow ML and HOL
On Thu, 2003-07-03 at 14:47, Ralf Treinen wrote: I remember vaguely that there used to be a licence problem with Moscow ML. What is its exact licence now? Under the mosml/copyright directory, there are three license files: 1. gpl2 - which is exactly a copy of GPL v2 2. copyright.att - which covers part of the library come from SML/NJ, and as I read it, it's mostly BSDish 3. copyright.cl - covers code come from CAML Light, which looks a little bit strange, but to my unexperienced eyes, looks like a homebrew GPL Anyway, I think it's generally acceptable to put it in Debian main. What's you opinion? -- ZHAO Wei [EMAIL PROTECTED] [EMAIL PROTECTED] http://www.advogato.org/person/zhaoway/ Linux Free Software Consultant, Nanjing, China
Re: Package Moscow ML and HOL
On Thu, 3 Jul 2003 17:36:30 +0800, ZHAO Wei wrote: On Thu, 2003-07-03 at 14:47, Ralf Treinen wrote: I remember vaguely that there used to be a licence problem with Moscow ML. What is its exact licence now? Under the mosml/copyright directory, there are three license files: 1. gpl2 - which is exactly a copy of GPL v2 2. copyright.att - which covers part of the library come from SML/NJ, and as I read it, it's mostly BSDish 3. copyright.cl - covers code come from CAML Light, which looks a little bit strange, but to my unexperienced eyes, looks like a homebrew GPL Anyway, I think it's generally acceptable to put it in Debian main. What's you opinion? I'll quote parts of 3: a- Extent of the rights granted by the INRIA to the user of the software: INRIA freely grants the right to use, modify and integrate the software in another software, provided that all derivative works are distributed under the same conditions as the software. b- Reproduction of the software: INRIA grants any user of the software the right to reproduce it so as to circulate it in accordance with the same purposes and conditions as those defined at point a- above. Any copy of the software and/or relevant documentation must comprise reference to the ownership of INRIA and the present file. The user undertakes not to carry out any paying distribution of the software. However, he is authorized to bill any person or body for the cost of reproduction of said software. As regards any other type of distribution, the user undertakes to apply to obtain the express approval of INRIA. It looks like a) possible GPL incompatibility - so no distribution would be possible at all, b) even if not, no paying distribution means non-free IMHO. -- Micha Politowski -- [EMAIL PROTECTED] Warning: this is a memetically modified message pgpIcRtc2oNch.pgp Description: PGP signature
Re: Debconf or not debconf
On Thu, Jul 03, 2003 at 01:24:54AM +0100, Andrew Suffield wrote: Somehow, you managed to miss the point entirely in your first line, *even though* you restated it later. I don't miss the point at all. You have assumed that it is ok to break the user system and warn people about it. It is not. Do not break the user system. Then no warnings are necessary. Yes, that's what we should be aiming for. Sadly things like upstream changes may make this unreasonably difficult - for example, configuration formats may change substantially in a way that is not ameinable to automated translation or a bug fix may require incompatible changes. If we're left in this unfortunate suituation where we're going to break the user system then we ought to warn them about it. -- You grabbed my hand and we fell into it, like a daydream - or a fever. pgpshkdnrPR29.pgp Description: PGP signature
Re: Package Moscow ML and HOL
On Thu, 2003-07-03 at 17:53, Micha Politowski wrote: It looks like a) possible GPL incompatibility - so no distribution would be possible at all, b) even if not, no paying distribution means non-free IMHO. I see your point. But I think it should be resolvable. Since that part of the clause covers part of the code from CAML Light. And we all know the CAML Light descendents O'CAML is perfect Free Software. And since Moscow ML authors put their own work, major part of Moscow ML in GPL itself, so I dare to say both parts are good supporters of Free Software. :) I think it's resolvable. If nobody will contact them, I'll contact them after awhile about the license issue. But since I'm not a native English speaker nor .dk nor .fr speaker, I'd rather hope someone else could approach the authors of Moscow ML representing Debian. Anyone? :) -- ZHAO Wei [EMAIL PROTECTED] [EMAIL PROTECTED] http://www.advogato.org/person/zhaoway/ Linux Free Software Consultant, Nanjing, China
Why doesn't libsidplay enter testing?
Hi! Yes, I've read the testing page with the FAQ and both the testing_excuses and testing_output, but I can't see the reason why libsidplay doesn't enter testing. The following packages depend on it: xmms-sid, mp3blaster, xsidplay, sidplay-base (from the same source) and gst-plugins. Only the latest isn't a valid candidate but that must not hold it back because it has never been in testing anyway. From the update_output it seems that alpha seems to have problems with the package -- but shouldn't then at least one of the packages depending on it be outdated for alpha and thus being no valid candidate? It would be nice if someone can unpuzzle me here Thanks. Alfie -- SILVER SERVER \\ \\ \ [EMAIL PROTECTED]www.sil.at keep your backbone tidy
Bug#199837: ITP: clustalw-mpi -- MPI-distributed global sequence alignment with ClustalW
Package: wnpp Version: N/A; reported 2003-07-03 Severity: wishlist * Package name: clustalw-mpi Version : 0.13 Upstream Author : Kuo-Bin Li [EMAIL PROTECTED] * URL : http://www.bii.a-star.edu.sg/~kuobin/clustalg/clustalw-mpi-0.13.tar.gz * License : non-free Description : MPI-distributed global sequence alignment with ClustalW -- System Information Debian Release: 3.0 Architecture: i386 Kernel: Linux pzr6 2.4.20-pzr5 #1 Don Mär 13 20:41:05 CET 2003 i686 Locale: LANG=de_DE, LC_CTYPE=de_DE
Re: Why doesn't libsidplay enter testing?
Gerfried Fuchs wrote: Yes, I've read the testing page with the FAQ and both the testing_excuses and testing_output, but I can't see the reason why libsidplay doesn't enter testing. I've written a little script that tries to answer precisely this type of question. You can run it here: http://bjorn.haxx.se/debian/ For libsidplay, it says: - Updating libsidplay makes 3 packages uninstallable on alpha: sidplay-base, xmms-sid, xsidplay - sidplay-base is waiting for libsidplay - Updating sidplay-base makes 1 packages uninstallable on alpha: sidplay-base - xmms-sid is waiting for libsidplay - Updating xmms-sid makes 1 packages uninstallable on alpha: xmms-sid - xsidplay is waiting for libsidplay - Updating xsidplay makes 1 packages uninstallable on alpha: xsidplay The packages are waiting for each other, so none of them can go in. It looks like a nudge by a maintainer is required. From the update_output it seems that alpha seems to have problems with the package Platforms are tested in alphabetical order, and only the first that breaks is displayed. That's why many packages are reported as uninstallable on alpha. Actually they are most likely uninstallable on many other platforms too, but only the result for alpha is displayed. -- Björn
Re: Please remove RFCs from the documentation in Debian packages
[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. I believe this whole case of RFC standards are not confirming to The Debian Free Software Guidelines display a complete lack of understanding of the value of standards, and should be rejected. Standards are not software, nor software manuals, and should not be treated as such. I haven't been following this case, and understand it might be late to speak up against it, but believe it is about time the whole case is stopped.
Re: Please remove RFCs from the documentation in Debian packages
On 03 Jul 2003 13:00:47 +0200 Petter Reinholdtsen [EMAIL PROTECTED] 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. I believe this whole case of RFC standards are not confirming to The Debian Free Software Guidelines display a complete lack of understanding of the value of standards, and should be rejected. Standards are not software, nor software manuals, and should not be treated as such. I haven't been following this case, and understand it might be late to speak up against it, but believe it is about time the whole case is stopped. #92810 specifically deals with whether the RFCs should be in main or non-free. They are not freely modifiable, so they should not be in main - end of story, regardless of whether it's a good thing or a bad thing. I happen to agree with your thoughts (if not the phrasing and tone), and agree that standards by their nature can't be both Free and effective. But they're no less effective in non-free, so just relax :) pgp0WiB4muIiQ.pgp Description: PGP signature
Re: Please remove RFCs from the documentation in Debian packages
(Please don't CC: me, I'm in the list) On Thu, Jul 03, 2003 at 01:00:47PM +0200, 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. I'm sure that's true. Unfortunately, we only have guidelines to accept software into Debian, and those are the DFSG. There is no such thing (yet) as a Debian Free Documentation Guidelines, so we have to treat them with the only guidelines we have at the moment. I encourage you to read the Debian Documentation Draft Policy, available at http://www.debian.org/doc/ddp-policy/, which discusses some of the issues related to documentation, improve it and make it evolve into a proper policy for Debian. I believe this whole case of RFC standards are not confirming to The Debian Free Software Guidelines display a complete lack of understanding of the value of standards, and should be rejected. Standards are not software, nor software manuals, and should not be treated as such. Unfortunately you are misjudging here. Please read the bug reports. I haven't been following this case, and understand it might be late to speak up against it, but believe it is about time the whole case is stopped. The only way to stop this case is to produce a proper set of guidelines for documentation in Debian that would cover this (an other) cases, have a vote on it and get it approved as part of our own guidelines. If you want to help, you are welcome. Regards Javi pgpVqHW4qi6wP.pgp Description: PGP signature
Re: Debconf or not debconf
On Thursday, July 3, 2003, at 02:05 AM, Branden Robinson wrote: On Wed, Jul 02, 2003 at 08:53:57PM -0400, Joe Drew wrote: Joey Hess has mentioned, and I agree (see 199722), that debconf notes should really be named (and should always be interpreted as) warnings. Huh. I thought it was supposed to be even stricter than that; errors only. E.g.: [...] input validation errors. IMO, when a debconf warning is shown, the administrator should need to do something. Regardless of whether that something is dumping and re-loading databases, reconfiguring a radically changed package, or re-entering the PCI BusID in a valid format, the warning (or error) informs the administrator that action is required on their part. Anything else should be placed in NEWS.Debian.
Re: Debconf or not debconf
Julien LEMOINE [EMAIL PROTECTED] wrote: On Tuesday 01 July 2003 22:51, Andreas Metzler wrote: Julien LEMOINE [EMAIL PROTECTED] wrote: I received a bug report on stunnel package from an user [1] that complained about the fact that I didn't warning about the new /etc/default/stunnel file introduced in package (thereis a note in README.Debian and in changelog). Since debconf is not really appreciated for this use, what is the best solution ? Inform users with debconf or give them informations only in changelog and README.Debian ? Is this just the usual default file for modifying the init-script's behaviour, i.e. will the package just continue to work as it did if the user does not know about it? Not exactly, there is a variable ENABLED which is set to 0 at installation. So the service will not start while variable is not set to 1. I see. I cannot do much more than AOL!! other posters in this thread: Steve Langasek | If so, I would recommend looking for a way to provide a more | graceful upgrade -- this is worth much more than a note telling | users that you've just broken their systems... *If* this is not possible, because it would require you to maintain a big patch differing from upstream and you can't change their minds with [EMAIL PROTECTED] *then* a debconf note with priority high is needed. cu andreas -- Hey, da ist ein Ballonautomat auf der Toilette! Unofficial _Debian-packages_ of latest unstable _tin_ http://www.logic.univie.ac.at/~ametzler/debian/tin-snapshot/
No crc32 package in Debian?
I was looking for the very simple crc32 binary to compute checksums for files, and couldn't find it. There is a crc32 perl lib, but no crc32 package. I know that md5 (or even sha-160) hash fingerprints are better, but in many cases (like tar archives on tapes, or ftp files) you have only CRC-32. See http://freshmeat.net/projects/checkcrc/ This one is looking good, and was co-written by Mark Adler (who also co-wrote zlib) If it was not packaged by anyone (couldn't find any reference, but it might have been packaged with another one), and if everybody is okay, I will ITP it.
Re: No crc32 package in Debian?
Xavier Roche [EMAIL PROTECTED] writes: I was looking for the very simple crc32 binary to compute checksums for files, and couldn't find it. There is a crc32 perl lib, but no crc32 package. I know that md5 (or even sha-160) hash fingerprints are better, but in many cases (like tar archives on tapes, or ftp files) you have only CRC-32. Doesn't cksfv does the job ? If it was not packaged by anyone (couldn't find any reference, but it might have been packaged with another one), and if everybody is okay, I will ITP it. Please perform according to section 5.1 of the Developer's Reference and fill an ITP. Cheers, Benjamin -- .''`. ; ;' ; Debian GNU/Linux | Benjamin Drieu `. `'http://www.debian.org/ | [EMAIL PROTECTED] `- pgpA60dnBjS6N.pgp Description: PGP signature
Bug#199864: ITP: kahakai -- a highly customisable and scriptable window manager
Package: wnpp Version: unavailable; reported 2003-07-03 Severity: wishlist * Package name: kahakai Version : 0.2.1 Upstream Author : The Kahakai Team * URL : http://kahakai.sf.net/ * License : GPL, v2 or later Description : a highly customisable and scriptable window manager Kahakai is a fork of the Waimea window manager, adding a number of new features, most notably scripting support. It uses Swig, so a number of backend scripting languages are possible, though only the Python bindings are currently working. . It still supports the features that made Waimea so neat: * Xft-based font rendering, for very nice-looking text. * Support for both viewports and virtual desktops. * A very flexible `style' system, including support for Blackbox themes. * Pseudo-transparent window decorations. It currently only builds with libswig1.3 and swig1.3 1.3.17, unfortunately, neither of which are in sid anymore. See http://sourceforge.net/tracker/index.php?func=detailaid=753568group_id=1645atid=101645 for more information. Test packages are available with this sources.list line: http://www.ertius.org.org/packages/kahakai/ ./ Source is available from the same place. pgp30bz6Z24Zx.pgp Description: PGP signature
Re: but I want the GNU versions of packages
On Mon, 30 Jun 2003 00:36:10 +0200, Michael Banck [EMAIL PROTECTED] wrote: On Sat, Jun 28, 2003 at 07:57:55AM +0800, Dan Jacobson wrote: So what is the single command to apt-get install all the GNU versions of everything? Just create and maintain a meta-package that Conflicts/Depends on the stuff you want. Given the current state of affairs, I am pretty sure that such a package will be rejected by ftpmaster. They pretty sure reject almost everything I upload. Greetings Marc, currently seriously pissed -- -- !! No courtesy copies, please !! - Marc Haber |Questions are the | Mailadresse im Header Karlsruhe, Germany | Beginning of Wisdom | Fon: *49 721 966 32 15 Nordisch by Nature | Lt. Worf, TNG Rightful Heir | Fax: *49 721 966 31 29
Re: Debconf or not debconf
On Wed, 02 Jul 2003 19:52:10 +1000, Herbert Xu [EMAIL PROTECTED] wrote: I for one am sick and tired of useless Debconf messages popping up during installation or being sent to me via email when I'm upgrading hundreds of machines automatically. Just go ahead and pre-seed your debconf database appropriately before upgrading. Greetings Marc -- -- !! No courtesy copies, please !! - Marc Haber |Questions are the | Mailadresse im Header Karlsruhe, Germany | Beginning of Wisdom | Fon: *49 721 966 32 15 Nordisch by Nature | Lt. Worf, TNG Rightful Heir | Fax: *49 721 966 31 29
eicar.com installer in Debian, and pre-upload interface to ftpmaster
Hi, In the past years, I have done quite a bit of work with virus scanners on Linux. The company I used to work for has funded most of amavis-ng development before being borged. In the past years, I have found it annoying that the eicar anti-virus testfile is not available as aptable Debian package. Since eicar.com has no license and eicar doesn't seem to be interested in clarifying its license, inclusion of the eicar test string in Debian proper is out of the question, even for non-free. But it is possible to have an eicar-installer package in contrib which is itself dfsg-free and downloads the non-free eicar test string from the Web on installation. After having that installer package rejected by ftpmaster (doesn't make sense to have a 3 KB installer package to install a hundred bytes of code) and been encouraged to take that issue to -devel, I would like to hear other people's opinions. It is my opinion that it would be a good idea to have that installer package in Debian. Heck, if I wouldn't have that opinion, I wouldn't have spent some of my time to build that package. 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. Greetings Marc, somewhat mad at the moment -- -- !! No courtesy copies, please !! - Marc Haber |Questions are the | Mailadresse im Header Karlsruhe, Germany | Beginning of Wisdom | Fon: *49 721 966 32 15 Nordisch by Nature | Lt. Worf, TNG Rightful Heir | Fax: *49 721 966 31 29
Re: Why doesn't libsidplay enter testing?
On Thu, Jul 03, 2003 at 11:37:06AM +0200, Gerfried Fuchs wrote: Yes, I've read the testing page with the FAQ and both the testing_excuses and testing_output, but I can't see the reason why libsidplay doesn't enter testing. It can (or at least it could a few days ago), it just needs a manual hint in update_out.py. I mentioned this to aj on 23 June. -- Colin Watson [EMAIL PROTECTED]
Re: No crc32 package in Debian?
On Thu, Jul 03, 2003 at 04:25:25PM +0200, Benjamin Drieu wrote: Doesn't cksfv does the job ? Absolutely - I did not find it in the first time, as the primary goal was to generate sfv files (but you can get the CRC inside it)
Re: but I want the GNU versions of packages
Marc Haber [EMAIL PROTECTED] writes:
On Mon, 30 Jun 2003 00:36:10 +0200, Michael Banck [EMAIL PROTECTED]
wrote:
On Sat, Jun 28, 2003 at 07:57:55AM +0800, Dan Jacobson wrote:
So what is the single command to apt-get install all the GNU versions
of everything?
Just create and maintain a meta-package that Conflicts/Depends on the
stuff you want.
Given the current state of affairs, I am pretty sure that such a
package will be rejected by ftpmaster. They pretty sure reject almost
everything I upload.
Since you didn't bother with specifics, I can only guess you're
referring to clamav-data and eicar-testfile. I encourage anyone to
check out
auric:/org/ftp.debian.org/queue/reject/{clamav-data,eicar-testfile}*
and judge this troll for themselves...
--
James
Re: Kernel build dependencies for prepackaged modules
David Z Maze [EMAIL PROTECTED] wrote:
My kernel module packages (lm-sensors and i2c) both build-depend on
kernel-build-2.4.20-1, which provides enough bits to build packages
(as far as I can tell, successfully). Problem is, evidence suggests
that kernel-build-2.4.20-1 is i386-only. I'm looking at moving to
2.4.21, but kernel-build-2.4.21-1 also appears to just be an i386
thing. It looked like kernel-tree-2.4.21 might be useful for this,
but it doesn't obviously appear to depend on architecture-specific
patches and doesn't give any clue as to what flavors exist and has *no
documentation at all*.
How many Debian users are there that will use lm-sensors and i2c
modules for a prepackaged kernel on a non-i386 architecture?
--
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: Why doesn't libsidplay enter testing?
On Thu, Jul 03, 2003 at 12:50:50PM +0200, Björn Stenberg wrote: Gerfried Fuchs wrote: Yes, I've read the testing page with the FAQ and both the testing_excuses and testing_output, but I can't see the reason why libsidplay doesn't enter testing. I've written a little script that tries to answer precisely this type of question. You can run it here: http://bjorn.haxx.se/debian/ Thanks for the great script. It shows me that the testing script seems to be buggy, because: - Updating sidplay-base makes 1 packages uninstallable on alpha: sidplay-base Uhm, that is somehow nonsense. How can an update of a package make itself uninstallable? What's the reasoning behind it? - Updating xmms-sid makes 1 packages uninstallable on alpha: xmms-sid - Updating xsidplay makes 1 packages uninstallable on alpha: xsidplay The packages are waiting for each other, so none of them can go in. It looks like a nudge by a maintainer is required. From the texting I would interpret this as they are waiting for _themselfes_, not for the others. What nudge by a maintainer are you talking about? Especially, which maintainer (testing-maintainer?) Platforms are tested in alphabetical order, and only the first that breaks is displayed. Thanks, that explains a lot. But it still doesn't explain why the package holds back itself... Is this a bug in the testing script? From what I understand the testing script should be able to see such circular dependencies -- but a dependency that breaks itself seems to be weird. Have fun, Alfie -- SILVER SERVER \\ \\ \ [EMAIL PROTECTED]www.sil.at keep your backbone tidy
Re: Please remove RFCs from the documentation in Debian packages
Petter Reinholdtsen [EMAIL PROTECTED] wrote:
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.
Do you know that you will be fighting the infamous GFD? Good luck!
--
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: eicar.com installer in Debian, and pre-upload interface to ftpmaster
Am Donnerstag, 3. Juli 2003 16:51 schrieb Marc Haber: [...] 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. [...] Well that's the purpose of ITP-bugs against wnpp I think, because they are CC'd to debian-devel for public review. And since ftpmaster sent you to -devel he would obey the opinion of the list. Tom -- 1024D/8FC03128: 01FA 29EF 7F56 66A8 6596 C501 4322 5D69 8FC0 3128 postfix/src/util/msg.c: msg_panic() 202:abort();/* Die! */ 203:exit(1);/* DIE!! */
Re: Debconf or not debconf
On Thu, Jul 03, 2003 at 12:27:24PM +1000, Herbert Xu wrote: Joe Drew [EMAIL PROTECTED] wrote: On Wed, 2003-07-02 at 17:23, Herbert Xu wrote: I'd prefer no interaction at all during installation. I'm perfectly able to read documenation thank you very much. Happily, the noninteractive debconf frontend exists. And getting hundreds of emails after a mass upgrade? No thanks. man 5 procmailrc Regards: David Weinehall -- /) David Weinehall [EMAIL PROTECTED] /) Northern lights wander (\ // Maintainer of the v2.0 kernel // Dance across the winter sky // \) http://www.acc.umu.se/~tao/(/ Full colour fire (/
Bug#199874: ITP: molmol -- Display and analyze structures of biological macromolecules
Package: wnpp Version: N/A; reported 2003-07-03 Severity: wishlist * Package name: molmol Version : 2k.2.0 Upstream Author : Reto Koradi [EMAIL PROTECTED] et al. * URL : http://www.mol.biol.ethz.ch/wuthrich/software/molmol/ * License : non-free (academic type use me, but cite men in publications) Description : Display and analyze structures of biological macromolecules I'm not a Debian Developer - thus would need a sponsor. In fact the package is quite ready, but the license and distribution permission have to be clarified with the authors. Bye, Frank -- System Information Debian Release: 3.0-bunk-1 Architecture: i386 Kernel: Linux alhambra 2.4.19 #1 Sam Apr 26 21:34:01 CEST 2003 i686 Locale: [EMAIL PROTECTED], [EMAIL PROTECTED]
Re: Debconf or not debconf
On Wed, 02 Jul 2003 22:25:26 +0200 Thomas Viehmann [EMAIL PROTECTED] wrote: Jim Penny wrote: Now, this breakage happens to be somewhat benign, in that without configuration, it does not function at all. But it is also somewhat difficult to test for many uses. Further, when the unconfigured system fails to start, the failure is completely silent. This adds to the problems. What is difficult to test in ssl connections fail? I routinely test mine with telnet-ssl or python scripts (though I remember something about python and IMAP SSL not too long ago)... Well, you have to have a place to launch the scripts from. It the tunnel is at the edge, and listening only to the outward-facing interface, or it is listening only to localhost, and you don't want to have the testing tools on your firewall, or ... Also, the silentness would IMHO be better fixed by adding a big fat NOT to the init script (although anything more than a NOT will be controversial as well...). Reminds me of something I should fix for my packages... This is a completely different complaint, more of an aside that should never have been raised here. It has nothing to do with the change in format of configuration information, debconf-ing or not debconf-ing. It has to do with the experience of making repeated changes to the configuration file, while feeling under some time pressure, running/etc/init.d/stunnel restart, seeing no output, and thinking silence is golden. You know, the usual Unix tradition. Jim Penny
Re: Package Moscow ML and HOL
On Thu, Jul 03, 2003 at 05:36:30PM +0800, ZHAO Wei wrote: On Thu, 2003-07-03 at 14:47, Ralf Treinen wrote: I remember vaguely that there used to be a licence problem with Moscow ML. What is its exact licence now? Under the mosml/copyright directory, there are three license files: 1. gpl2 - which is exactly a copy of GPL v2 2. copyright.att - which covers part of the library come from SML/NJ, and as I read it, it's mostly BSDish 3. copyright.cl - covers code come from CAML Light, which looks a little bit strange, but to my unexperienced eyes, looks like a homebrew GPL Anyway, I think it's generally acceptable to put it in Debian main. What's you opinion? Please send license text that is unfamiliar to the Project to the debian-legal list for vetting. In your list above that would be both items 2) and 3). BSDish is not a guarantee of DFSG-freeness, and furthermore, a license can be DFSG-free but not GPL-compatible, and if a work contains material under the GPL and under a non-GPL-compatible license, the result may not be distributable by the Debian Project at all (or so much may have to be stripped out that there's no point shipping the package). -- G. Branden Robinson| There's nothing an agnostic can't Debian GNU/Linux | do if he doesn't know whether he [EMAIL PROTECTED] | believes in it or not. http://people.debian.org/~branden/ | -- Graham Chapman pgp61otkLpfKB.pgp Description: PGP signature
Re: Please remove RFCs from the documentation in Debian packages
On Thu, Jul 03, 2003 at 01:00:47PM +0200, Petter Reinholdtsen wrote: There seem to be someone believing that standard documents should be treated as software. That would be clause #1 of the Debian Social Contract. -- G. Branden Robinson| Organized religion is a sham and a Debian GNU/Linux | crutch for weak-minded people who [EMAIL PROTECTED] | need strength in numbers. http://people.debian.org/~branden/ | -- Jesse Ventura pgp8FMf9agaBY.pgp Description: PGP signature
Re: eicar.com installer in Debian, and pre-upload interface to ftpmaster
On Thu, 03 Jul 2003, Marc Haber wrote: Since eicar.com has no license and eicar doesn't seem to be interested in clarifying its license, inclusion of the eicar test string in Debian proper is out of the question, even for non-free. Ick. They are included in the amavisd-new _source_ packages. We don't package them in the binary packages, but... From http://www.eicar.org/anti_virus_test_file.htm, I get that while they do not display a license, they explicitly allow us to distribute it. -- 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
Bug#199881: ITP: rhyme -- console based rhyming dictionary
Package: wnpp Version: N/A; reported 2003-07-03 Severity: wishlist Package name: rhyme Version : 0.9 Upstream Author : Brian (tuffy) Langenberger [EMAIL PROTECTED] URL : http://sourceforge.net/projects/rhyme License : GPL Description : console based rhyming dictionary -- System Information Debian Release: 3.0 Architecture: i386 Kernel: Linux bitech88 2.4.18-k7 #1 Sun Apr 14 13:19:11 EST 2002 i686 Locale: LANG=C, LC_CTYPE=C
Re: Please remove RFCs from the documentation in Debian packages
On Jul 03, Petter Reinholdtsen [EMAIL PROTECTED] wrote: I believe this whole case of RFC standards are not confirming to The Debian Free Software Guidelines display a complete lack of understanding of the value of standards, and should be rejected. Standards are not software, nor software manuals, and should not be treated as such. I fully agree. Banning RFCs from debian is just silly. -- ciao, | Marco | [654 deHrl.v0T54n6]
Re: Why doesn't libsidplay enter testing?
Gerfried Fuchs wrote: Thanks for the great script. It shows me that the testing script seems to be buggy, because: - Updating sidplay-base makes 1 packages uninstallable on alpha: sidplay-base Uhm, that is somehow nonsense. How can an update of a package make itself uninstallable? What's the reasoning behind it? Because it breaks testing rule #5: The operation of installing the package into testing must not break any packages currently in testing. Updating sidplay-base alone breaks the current versions of xmms-sid and xsidplay. This is not allowed, and thus sidplay-base is uninstallable. The solution is to update all of the packages at once, which requires manual intervention. As Colin Watson said, this has already been mentioned to the maintainer so the packages should be going in soon. -- Björn
Re: Bug#199874: ITP: molmol -- Display and analyze structures of biological macromolecules
On Thu, 3 Jul 2003, Frank Küster wrote: * License : non-free (academic type use me, but cite men in publications) The license has a statement: This package may only be bundled in other software packages with the explicit permission of the copyright holders. Please make sure that the copyright holders allow inclusion into Debian and add this statement to the debian/copyright file. Kind regards Andreas.
Re: Please remove RFCs from the documentation in Debian packages
On Thu, Jul 03, 2003 at 10:51:15AM -0500, Branden Robinson wrote:
That would be clause #1 of the Debian Social Contract.
Where do you draw the line between software, data and documentation? I
get the impression that you are reading Debian Will Remain 100% Free
Software to mean everything in Debian will be Free Software instead
of all the software in Debian will be Free Software. There's a good
deal of packages in Debian that can't be classified as software no
matter how you twist the definition. WordNet provides a lax
definition:
From WordNet (r) 1.7 [wn]:
software
n : (computer science) written programs or procedures or
rules and associated documentation pertaining to the
operation of a computer system and that are stored in
read/write memory [...]
foldoc has this comment on the subject:
Some claim that {documentation} (both paper and electronic) is
also software. Others go further and define software to be
programs plus documentation though this does not correspond
with common usage.
To be fair, I'm not going to mention anarchism. But what do you do
with all the LG packages? And several kinds of theme packages? And
the fortune packages? And the dictionaries? Think about your answer,
we can't package random data just because it can be consumed by some
program in the distribution.
Marcelo
Re: Debconf or not debconf
#include hallo.h * Herbert Xu [Thu, Jul 03 2003, 12:27:24PM]: I'd prefer no interaction at all during installation. I'm perfectly able to read documenation thank you very much. Happily, the noninteractive debconf frontend exists. And getting hundreds of emails after a mass upgrade? No thanks. We need a mail collector in debconf to send them all in one digest mail. MfG, Eduard. -- claim morgen! weasel was ist morgen? claim aehm, mittwoch!
Debconf or not debconf : Conclusion
Hello, First of all, I present my excuses for having started a new debate about debconf in debian-devel. Secondly, to reply to every person who thinks I should have created a more user friendly migration who did not break backwards compatibility. My answer is that I have no time to implement command line support for stunnel 4.x. Finally, since there is not really a policy about when to use debconf, I will respect the DFSG [1] and add a debconf warning [2] in the stunnel package. Thanks for all your comments. Best Regards. [1] 4. Our Priorities are Our Users and Free Software [2] Description: general notes about stunnel * stunnel 4.x does not support any more command line arguments, so you need to edit /etc/stunnel.conf by hand if you are upgrading from stunnel 3.x * For stunnel versions = 4.04-4, the file /etc/default/stunnel is provided and you need to set ENABLED=1 to allow stunnel to be started from init.d * To set up stunnel for server use, read the /usr/share/doc/stunnel/README.Debian file. -- Julien LEMOINE / SpeedBlue
Re: No crc32 package in Debian?
#include hallo.h * Xavier Roche [Thu, Jul 03 2003, 04:15:22PM]: I was looking for the very simple crc32 binary to compute checksums for files, and couldn't find it. There is a crc32 perl lib, but no crc32 package. I know that md5 (or even sha-160) hash fingerprints are better, but in many cases (like tar archives on tapes, or ftp files) you have only CRC-32. apt-cache search crc check apt-cache show cfv cksfv MfG, Eduard. -- Aquarioph Lieber Kinder zuhause, bitte nicht poppen, da ist am ende alles kleiner als am Anfang :)
Re: Please remove RFCs from the documentation in Debian packages
On Thu, Jul 03, 2003 at 01:00:47PM +0200, Petter Reinholdtsen wrote: 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. There's no need to. But I want to have the right to change a standard slightly, and hand it around, telling people that this is how I would have liked the standard. I also want to have the right to enhance or even change a standard, and use it e.g. for some internal project. I want to quote parts of the standard in other documents or my software (maybe even outside the fair use constraints). I might not be allowed to do that. There might be other restrictions as well. I don't want to have the right to call these modified documents RFCs or standards, though. Please don't confuse these two issues. This is something that we already allow - see some software licenses that we consider free that require derived versions of the software to change the name of the software. - Sebastian
Re: Please remove RFCs from the documentation in Debian packages
On Thu, 3 Jul 2003, Marcelo E. Magallon wrote: software n : (computer science) written programs or procedures or rules and associated documentation pertaining to the operation of a computer system and that are stored in read/write memory [...] So if you print out a program, it is no longer considered software? Or if you burn it to cd or dvd?
Re: Debconf or not debconf : Conclusion
On Thu, Jul 03, 2003 at 04:17:50PM +0200, Julien LEMOINE wrote: Finally, since there is not really a policy about when to use debconf, I will respect the DFSG [1] and add a debconf warning [2] in the stunnel package. [...] [1] 4. Our Priorities are Our Users and Free Software As a user: You are doing me a disservice. That's one more useless debconf warning, especially, since an automatic update is easy to implement. - Sebastian
Re: Please remove RFCs from the documentation in Debian packages
Marco d'Itri [EMAIL PROTECTED] writes: On Jul 03, Petter Reinholdtsen [EMAIL PROTECTED] wrote: I believe this whole case of RFC standards are not confirming to The Debian Free Software Guidelines display a complete lack of understanding of the value of standards, and should be rejected. Standards are not software, nor software manuals, and should not be treated as such. I fully agree. Banning RFCs from debian is just silly. Wait, we're thinking about banning most of the GNU documentation too, since it's GFDL'ed (the libc, emacs, and gdb manuals for example), or putting it under non-free. I like this DFDG idea (Debian Free Documentation Guidelines) :-)... Phil.
Re: Please remove RFCs from the documentation in Debian packages
On Thursday, Jul 3, 2003, at 07:00 US/Eastern, 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. If they are not software, then under clause one of the Social Contract, they don't belong in debian. This has been debated several thousand times on -legal...
Bug#199894: ITP: libtododb -- library that provides access to a to-do list database
Package: wnpp Version: unavailable; reported 2003-07-03 Severity: wishlist * Package name: libtododb Version : 0.02 Upstream Authors: Philip Blundell [EMAIL PROTECTED] Luis Oliveira [EMAIL PROTECTED] * URL : http://gpe.handhelds.org/ * License : LGPL Description : library that provides access to a to-do list database libtododb provides an interface for programs to access and modify a list of tasks which the user needs to carry out. Notes: libtododb is a dependency of more recent versions of gpe-todo. It is also used by other GPE applications not yet in Debian, such as the 'Today' display, to access the to-do database. -- System Information: Debian Release: testing/unstable Architecture: i386 Kernel: Linux ascendit 2.4.21 #4 Sun Jun 22 18:42:14 BST 2003 i686 Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8
Re: Debconf or not debconf
Marc Haber wrote: On Wed, 02 Jul 2003 19:52:10 +1000, Herbert Xu [EMAIL PROTECTED] wrote: I for one am sick and tired of useless Debconf messages popping up during installation or being sent to me via email when I'm upgrading hundreds of machines automatically. Just go ahead and pre-seed your debconf database appropriately before upgrading. Funnily, Russel Coker explained something about this while explaining why he turned away from Micro$oft in the Interview mentioned on debian-planet today... Excessive usage of debconf notices is a bug which should be avoided/fixed, not worked around. Cheers T. pgpvFTqoLkhJL.pgp Description: PGP signature
Sorry.
Sorry, I will try to learn to reply to the correct list. (Incidentally, on my first attempt, I claimed that I will learn but wrote only to myself...) Cheers T. pgpqgdnAkSlw7.pgp Description: PGP signature
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: In the past years, I have found it annoying that the eicar anti-virus testfile is not available as aptable Debian package. Why is this annoying? The virus cannot be detected without it? 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. Frankly, with this particular one, I entirely fail to see why you ignore several perfectly valid reasons laid out in the reasonably polite (if a bit dazzled) rejection notice and go off ranting instead. (I don't want to quote them without permission.) -- 2. That which causes joy or happiness.
Bug#199896: ITP: libdm -- display migration support for GTK
Package: wnpp Version: unavailable; reported 2003-07-03 Severity: wishlist * Package name: libdm Version : 0.25 Upstream Author : Philip Blundell [EMAIL PROTECTED] * URL : http://gpe.handhelds.org/ * License : GPL Description : display migration support for GTK libdm provides support for moving running GTK applications between different X displays. X properties are used to advertise that windows are capable of migration, and to request windows to migrate to a specified display. -- System Information: Debian Release: testing/unstable Architecture: i386 Kernel: Linux ascendit 2.4.21 #4 Sun Jun 22 18:42:14 BST 2003 i686 Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8
Debian XML Catalogs (was Re: OASIS Membership: was ...)
Quoting Jochen Voss [EMAIL PROTECTED]: On Wed, Jul 02, 2003 at 05:13:18PM -0400, [EMAIL PROTECTED] wrote: Also, the Debian implementation of XML catalogs will very likely be included as one example in the OASIS implementation guide for XML Catalogs. So we _are_ making a difference. This is interesting. But is there actually such a thing like a Debian implementation of XML catalogs. I was under the impression that packages like docbook-xml[1] and scrollkeeper[2] prefer to not register their xml files at the moment and that there are currently no working xml catalogs on Debian systems. You're quite right. Ardo I (with helpful input from Adam DiCarlo) have been working on the policy and the infrastructure packages for the last few months. I have the first policy draft complete, but due to the fact that I'm in the process of relocating and job-hunting (and am using someone else's floppy-free Mac to do webmail) I don't presently have the time or the means to check-in or upload any files. Early next week Ardo I should have both of our relative stuff ready and uploaded. At that time I'll post an announcement to debian-devel. Cheers, Mark
Re: Please remove RFCs from the documentation in Debian packages
On Thu, Jul 03, 2003 at 03:38:18PM +0200, Marco d'Itri wrote: On Jul 03, Petter Reinholdtsen [EMAIL PROTECTED] wrote: I believe this whole case of RFC standards are not confirming to The Debian Free Software Guidelines display a complete lack of understanding of the value of standards, and should be rejected. Standards are not software, nor software manuals, and should not be treated as such. I fully agree. Banning RFCs from debian is just silly. So, what other non-DFSG-free stuff is it silly to ban? Netscape Navigator? Adobe Acrobat Reader? -- G. Branden Robinson| Never underestimate the power of Debian GNU/Linux | human stupidity. [EMAIL PROTECTED] | -- Robert Heinlein http://people.debian.org/~branden/ | pgpQ6gvnRN1y2.pgp Description: PGP signature
NEW packages policy.
Hi. (My apologies if -devel is the wrong place to put this - hints for better locations are appreciated.) While I understand that new packages need to be checked, I wondered whether this rule could be relaxed somewhat for soversion-changing of libraries (i.e. the advance from lib(.*)\d+ to lib\1\d+. Is the current policy of treating advances of the soversion as new package a question of principle or implementation? TIA for your answers. Cheers T. pgpkHaJFJn2LG.pgp Description: PGP signature
Re: Why doesn't libsidplay enter testing?
On Thu, Jul 03, 2003 at 01:21:53PM +0200, Gerfried Fuchs wrote: On Thu, Jul 03, 2003 at 12:50:50PM +0200, Bj?rn Stenberg wrote: Gerfried Fuchs wrote: Yes, I've read the testing page with the FAQ and both the testing_excuses and testing_output, but I can't see the reason why libsidplay doesn't enter testing. I've written a little script that tries to answer precisely this type of question. You can run it here: http://bjorn.haxx.se/debian/ Thanks for the great script. It shows me that the testing script seems to be buggy, because: Not really. See my earlier mail. - Updating sidplay-base makes 1 packages uninstallable on alpha: sidplay-base Uhm, that is somehow nonsense. How can an update of a package make itself uninstallable? What's the reasoning behind it? That should be obvious: if sidplay-base is upgraded *by itself* in testing, then it will itself be uninstallable in testing. (libsidplay needs to go in at the same time, and doing such simultaneous source package upgrades generally requires action by the RM or somebody else who can mess with update_out.py directly. This sort of thing happens when library package names change.) Cheers, -- Colin Watson [EMAIL PROTECTED]
Re: Please remove RFCs from the documentation in Debian packages
On Thu, Jul 03, 2003 at 12:35:06PM -0500, Branden Robinson wrote: | So, what other non-DFSG-free stuff is it silly to ban? Netscape | Navigator? Adobe Acrobat Reader? Of course not. They're software. RFCs aren't software, and so applying the Debian Free /Software/ Guidelines to them seems a little odd. Cameron.
Bug#199897: ITP: gpe-filemanager -- file manager for GPE
Package: wnpp Version: unavailable; reported 2003-07-03 Severity: wishlist * Package name: gpe-filemanager Version : 0.09 Upstream Author : Damien Tanner [EMAIL PROTECTED] * URL : http://gpe.handhelds.org/ * License : GPL (version 2 or later) Description : file manager for GPE The GPE Filemanager provides a simple graphical interface for accessing and manipulating files. This package is part of the GPE Palmtop Environment, a free environment intended to be used on palmtop computers. -- System Information: Debian Release: testing/unstable Architecture: i386 Kernel: Linux ascendit 2.4.21 #4 Sun Jun 22 18:42:14 BST 2003 i686 Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8
Re: Please remove RFCs from the documentation in Debian packages
Le jeu 03/07/2003 à 13:00, Petter Reinholdtsen a écrit : 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. There are specific licenses for dealing with this kind of stuff. You can e.g. require modified versions to be clearly marked as such. Or else, if the standards are not free, let them in non-free. We're not going to let non-free documents enter main just because they are called RFC's or W3C recommendations. -- .''`. Josselin Mouette/\./\ : :' : [EMAIL PROTECTED] `. `'[EMAIL PROTECTED] `- Debian GNU/Linux -- The power of freedom signature.asc Description: Ceci est une partie de message =?ISO-8859-1?Q?num=E9riquement?= =?ISO-8859-1?Q?_sign=E9e?=
Bug#199899: ITP: gpe-taskmanager -- lists windows and kills errant programs
Package: wnpp Version: unavailable; reported 2003-07-03 Severity: wishlist * Package name: gpe-taskmanager Version : 0.13 Upstream Author : Philip Blundell [EMAIL PROTECTED] * URL : http://gpe.handhelds.org/ * License : GPL (version 2 or later) Description : lists windows and kills errant programs gpe-taskmanager is part of the GPE Palmtop Environment. It displays a list of windows on the current display, and allows the user to kill the task which owns a particular window. This can be helpful if a program has hung and is no longer responding to direct user actions. -- System Information: Debian Release: testing/unstable Architecture: i386 Kernel: Linux ascendit 2.4.21 #4 Sun Jun 22 18:42:14 BST 2003 i686 Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8
Re: Please remove RFCs from the documentation in Debian packages
On Thu, Jul 03, 2003 at 06:01:08PM +0200, Josselin Mouette wrote: Or else, if the standards are not free, let them in non-free. We're not going to let non-free documents enter main just because they are called RFC's or W3C recommendations. Yet we let them in because they are called licenses. And no, I'm not asking to be able to change the _contract_ between the copyright owner and the licensee. I'm talking about the file. I'm talking about this: Everyone is permitted to copy and distribute verbatim copies of this license document, but changing it is not allowed. It doesn't get any more non-free than that, does it? Marcelo
Re: Please remove RFCs from the documentation in Debian packages
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! -- - mdz
Re: Please remove RFCs from the documentation in Debian packages
On Thu, Jul 03, 2003 at 10:54:00AM -0400, Anthony DeRobertis wrote: If they are not software, then under clause one of the Social Contract, they don't belong in debian. This has been debated several thousand times on -legal... I don't recall a consensus that software documentation does not belong in Debian. -- - mdz
Re: Kernel build dependencies for prepackaged modules
Herbert Xu [EMAIL PROTECTED] writes: How many Debian users are there that will use lm-sensors and i2c modules for a prepackaged kernel on a non-i386 architecture? I've had at least one user ask me about support for powerpc, which is the big thing that's driving me to ask. If it makes you happier, pretend I'm asking about something hardware-independent like openafs. -- David Maze [EMAIL PROTECTED] http://people.debian.org/~dmaze/ Theoretical politics is interesting. Politicking should be illegal. -- Abra Mitchell
Re: Debconf or not debconf
Herbert Xu wrote: And getting hundreds of emails after a mass upgrade? No thanks. Admin-Email The email address Debconf should send mail to if it needs to make sure that the admin has seen an important note. Defaults to root, but can be set to any valid email address to send the mail there. If you prefer to never have debconf send you mail, specify a blank address. This can be overridden on the fly with the DEB- CONF_ADMIN_EMAIL environment variable. -- see shy jo pgphlp3EjL0gH.pgp Description: PGP signature
Re: Please remove RFCs from the documentation in Debian packages
On Thu, Jul 03, 2003 at 12:14:49PM -0500, Adam Heath wrote: On Thu, 3 Jul 2003, Marcelo E. Magallon wrote: software n : (computer science) written programs or procedures or rules and associated documentation pertaining to the operation of a computer system and that are stored in read/write memory [...] So if you print out a program, it is no longer considered software? I'd say not, it's a written document of a program. You can't very well run a piece of paper, can you? :P Or if you burn it to cd or dvd? When the program is run, it gets put in read/write memory. Neil -- A. Because it breaks the logical sequence of discussion Q. Why is top posting bad? gpg key - http://www.halon.org.uk/pubkey.txt ; the.earth.li 8DEC67C5
Re: Please remove RFCs from the documentation in Debian packages
On Thu, Jul 03, 2003 at 06:23:14PM +0200, Marcelo E. Magallon wrote: That would be clause #1 of the Debian Social Contract. Where do you draw the line between software, data and documentation? I get the impression that you are reading Debian Will Remain 100% Free Software to mean everything in Debian will be Free Software instead of all the software in Debian will be Free Software. Well, of *course* we do. It would be idiotic and hypocritical to interpret it as The software in Debian will be free, but the documentation doesn't have to be. We have historically allowed some free non-software things into the archive, since it doesn't matter very much. Why does anybody think that allowing non-free non-software things into the archive is acceptable? -- .''`. ** Debian GNU/Linux ** | Andrew Suffield : :' : http://www.debian.org/ | Dept. of Computing, `. `' | Imperial College, `- -- | London, UK pgpmTN1p4YKMp.pgp Description: PGP signature
Re: Application
Herzlichen Dank für Ihr eMail. Meine eMailadresse hat geändert und ich bitte Sie deshalb, eMails künftig an folgende Adresse zu senden: [EMAIL PROTECTED] Herzlichen Dank! Denis Nordmann
Re: Debconf or not debconf : Conclusion
Hi. Julien LEMOINE wrote: First of all, I present my excuses for having started a new debate about debconf in debian-devel. But then, the last one didn't favor your opinion. Secondly, to reply to every person who thinks I should have created a more user friendly migration who did not break backwards compatibility. My answer is that I have no time to implement command line support for stunnel 4.x. Yes. But you still have the options of: - Publically asking if someone else has time and skill to do it. - Putting off the update and/or packaging the interface incompatible stunnel under a new name. Finally, since there is not really a policy about when to use debconf, I will respect the DFSG [1] and add a debconf warning [2] in the stunnel package. There is a difference between the social contract and the DFSG. As a user of stunnel: Your warning will not help me as it does not keep stunnel from breaking. *Not* installing a totally incompatible program where the stunnel I wanted when I said apt-get install stunnel would. Cheers T. pgpSSwZtIe7kk.pgp Description: PGP signature
Re: Debconf or not debconf : Conclusion
Hi Sebastian! You wrote: On Thu, Jul 03, 2003 at 04:17:50PM +0200, Julien LEMOINE wrote: Finally, since there is not really a policy about when to use debconf, I will respect the DFSG [1] and add a debconf warning [2] in the stunnel package. [...] [1] 4. Our Priorities are Our Users and Free Software As a user: You are doing me a disservice. That's one more useless debconf warning, especially, since an automatic update is easy to implement. Indeed. Please don't display those annoying messages. -- Kind regards, ++ | Bas Zoetekouw | GPG key: 0644fab7 | || Fingerprint: c1f5 f24c d514 3fec 8bf6 | | [EMAIL PROTECTED], [EMAIL PROTECTED] | a2b1 2bae e41f 0644 fab7 | ++
Re: Why doesn't libsidplay enter testing?
On Thu, Jul 03, 2003 at 06:03:38PM +0200, Björn Stenberg wrote: Gerfried Fuchs wrote: Uhm, that is somehow nonsense. How can an update of a package make itself uninstallable? What's the reasoning behind it? Because it breaks testing rule #5: The operation of installing the package into testing must not break any packages currently in testing. Please read the output again. It claims that the install of sidplay-base would render sidplay-base (e.g. _itself_) broken -- that is what I call nonsense for the broken rendered sidplay-base would be replaced, that's what it's all about. A package should never be able to render _itself_ broken. Updating sidplay-base alone breaks the current versions of xmms-sid and xsidplay. This is not allowed, and thus sidplay-base is uninstallable. Please read the documentation for the testing script again -- that should already be triggered by the script. Read the part in the FAQ about the real, non-trivial example. This is exactly that the example describes and what it claims to be able to do already. The solution is to update all of the packages at once, which requires manual intervention. I don't see why it would need manual intervention. Either the documentation is ahead of the script or it is wrong. It is claimed in the documentation for quite some time that this is handled automagically already and this is the whole purpose for why the packages are repeatedly mentioned in the update_output. So simply put: You don't know neither why they don't move to testing automatically like they should (and I'm quite sure that it already worked that way...). I still think that there must be a different problem here, or rather someone b0rked the script. I don't want to accuse anyone to have done it, I don't need anyone responsible for the brokeness, but I'm not sure if it's really b0rked or if there is something that I misunderstood So long, Alfie -- SILVER SERVER \\ \\ \ [EMAIL PROTECTED]www.sil.at keep your backbone tidy
Processed: reassign general
Processing commands for [EMAIL PROTECTED]: reassign 199197 general Bug#199197: bsdgames debian X menu entries depend on gnome-terminal, not in testing (Sarge) Bug reassigned from package `bsdgames' to `general'. thanks Stopping processing here. Please contact me if you need assistance. Debian bug tracking system administrator (administrator, Debian Bugs database)
Re: Why doesn't libsidplay enter testing?
On Thursday, Jul 3, 2003, at 07:21 US/Eastern, Gerfried Fuchs wrote: Uhm, that is somehow nonsense. How can an update of a package make itself uninstallable? What's the reasoning behind it? Easily. Example: Package: foo Version: 1.0.6-4 Depends: libc6 = 2.2.0 vs. Package: foo Version: 1.0.7-1 Depends: libc6 = 2.4.0 Replacing foo-1.0.6-4 with 1.0.7-1 would make foo uninstallable (becasue there is no glibc-2.4.0 in testing) What nudge by a maintainer are you talking about? Especially, which maintainer (testing-maintainer?) ftp master would be a better term. Probably Anthony Towns. Thanks, that explains a lot. But it still doesn't explain why the package holds back itself... Is this a bug in the testing script? No. From what I understand the testing script should be able to see such circular dependencies -- but a dependency that breaks itself seems to be weird. Circular dependencies are not handled well. I suppose the feel free to submit patches thing applies here.
Re: Please remove RFCs from the documentation in Debian packages
On Thu, Jul 03, 2003 at 06:20:02PM +0100, Neil McGovern wrote: | | When the program is run, it gets put in read/write memory. | So embedded firmware running from an EPROM doesn't count as a program then? CP.
Re: Why doesn't libsidplay enter testing?
On Thu, Jul 03, 2003 at 01:49:28PM -0400, Anthony DeRobertis wrote: On Thursday, Jul 3, 2003, at 07:21 US/Eastern, Gerfried Fuchs wrote: Uhm, that is somehow nonsense. How can an update of a package make itself uninstallable? What's the reasoning behind it? Easily. Example: Package: foo Version: 1.0.6-4 Depends: libc6 = 2.2.0 vs. Package: foo Version: 1.0.7-1 Depends: libc6 = 2.4.0 Replacing foo-1.0.6-4 with 1.0.7-1 would make foo uninstallable (becasue there is no glibc-2.4.0 in testing) Please check the update_excuses, it would make package foo _not_ a valid candidate, if that happens. Thanks, that explains a lot. But it still doesn't explain why the package holds back itself... Is this a bug in the testing script? No. What makes you so sure? If it is just a circular dependency problem like Björn said it should be caught already, like documented (and worked before). I never noticed before that a package seems to hold back itself though. So long, Alfie -- SILVER SERVER \\ \\ \ [EMAIL PROTECTED]www.sil.at keep your backbone tidy
Re: Please remove RFCs from the documentation in Debian packages
* Branden Robinson ([EMAIL PROTECTED]) wrote: On Thu, Jul 03, 2003 at 03:38:18PM +0200, Marco d'Itri wrote: On Jul 03, Petter Reinholdtsen [EMAIL PROTECTED] wrote: I believe this whole case of RFC standards are not confirming to The Debian Free Software Guidelines display a complete lack of understanding of the value of standards, and should be rejected. Standards are not software, nor software manuals, and should not be treated as such. I fully agree. Banning RFCs from debian is just silly. So, what other non-DFSG-free stuff is it silly to ban? Netscape Navigator? Adobe Acrobat Reader? Keep in mind that this hard-line stance of applying the DFSG to everything in the archive will probably make it more difficult to gain support for the non-free removal resolution. I think most people perceive RFCs as being free enough for their purpose, even though they are not DFSG-free. Of course you can come up with scenerios where someone could have a completely legitimate desire to use an RFC in a derivative work, but in comparison to situations where one wants to modify software this is extremely infrequent. I think non-free removal will seem more radical if it means that Debian will no longer distribute RFCs on the basis that their licensing is not permissive enough. RFCs are the end product of a community process that represents everything Debian stands for. (Yes, I know that non-free is not part of Debian. All I claim above is that in the status quo Debian distributes non-free.) -- Josh Haberman Debian GNU/Linux developer
Re: Debconf or not debconf
Jim Penny dijo [Wed, Jul 02, 2003 at 06:34:53PM -0400]: My original argument stands: we should not be telling our users that we broke their system, because we shouldn't be breaking it in the first place. In this instance, it sounds to me like a bout of upstream bogosity has resulted in a rather grave regression in the quality of the software. Why would it ever be a good idea to *not* give users the ability to control the program using commandline options? Because of security considerations. The configuration file is read on startup, and then stunnel chroots away, so that it is no longer visible. The command line interface leaked information, internal IP structure, internal ports, etc. that a really paranoid person might prefer not be visible. While it is indeed preferable to not break things, there are times when avoiding breakage is quite difficult. This appears, to me, to be one of those times. Many times this cases are handled by creating a transitional package: 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. Even more, stunnel3 and stunnel4 can coexist - and some users will find it very valuable to have both the newest stunnel features and the ease of keeping their old configurations, or not having to be root to start a temporary or permanent new tunnel. Greetings, -- Gunnar Wolf - [EMAIL PROTECTED] - (+52-55)5630-9700 ext. 1366 PGP key 1024D/8BB527AF 2001-10-23 Fingerprint: 0C79 D2D1 2C4E 9CE4 5973 F800 D80E F35A 8BB5 27AF
