Please don't misuse the debian/changelog to close bugs!
Hi! Alright, this happened far too often lately to be ignored. This must stop, pretty please. The developers-reference[1] isn't written just for fun. Yes, writing closes: #123 in a changelog a really easy way to close a bugreport. But it is not the golden calf! Don't overdo it, don't overuse it. Thinks like this don't have to do anything in a debian/changelog: * This isn't really a bug (closes: #123) * The foo program does indeed work as intended (closes: #123) * This is on purpose and not a bug (closes: #123) Simple rule: If there are no changes in the package (by either yourself or upstream) that makes the bug (or no bug) go away, then _DON'T_ close it with the changelog. The reason for the changelog is to list *changes*. If there aren't any changes then it must not be listed in there. Please read developers-reference section 5.8.4., especially the later paragraphs. (especially the first listed example is almost identically listed in the developers-reference section 6.3.3., which *everyone* has read, right?) So, how to resolve such bugs, then? Quite simple: Write to [EMAIL PROTECTED] and add a note about why you think the bug is fixed and doesn't need a change in the package. I hope the people that weren't sure about this get it this time, and don't take it too personal. But it is sad that it seems to be needed to be written. During some of the discussions lately on debian-devel another usage of the changelog has risen interest: * New upstream release (closes: #123, #124, #125) This has also raised some discussions. The thing is this: If #123, #124 and #125 aren't just New upstream version available bugreports then quite some people dislike this behavior. It shouldn't be too much hazzle for the maintainer to rewrite this as follows: * New upstream release (closes: #123) which includes: - tmpfile race condition fix (closes: #124) - manual page included (closes: #125) The thing is: It helps the users and the person who reported the bug to see what bug exactly was closed without the need for them to dig in the BTS. This is no must but it is something your users would be greatful if you could do it. Thanks for the attention, Alfie [1] apt-get install developers-reference -- Frage: Wie heisst der Mann beim Krippenspiel? Manu: Jesus. -- Manu, Kontainerblondie in Hast Du Töne pgpde1eTO3SVA.pgp Description: PGP signature
Re: Package.. ma si pu
On Tue, Jun 24, 2003 at 12:16:21AM +0200, Samuele Giovanni Tonon wrote: io non ho capito bene questa storia del pacchettizzare solo la versione binaria .. nell'upload ufficiale a debian di solito bisogna fornire comunque i src che poi viene trasformato in deb-src e compilato dai BD se non sbaglio i sorgenti vanno forniti comunque .. http://www.debian.org/social_contract#guidelines Le DFSG sono le linee guida per cio' che e' considerato parte di Debian. Tutto cio' che trovi in contrib e non-free non e' considerato parte di Debian, e' formalmente software non-debian pacchettizzato in modo che sia facile da utilizzare per gli utenti ed in modo che possa beneficiare dell'infrastruttura della debian (e.g. BTS). in questo caso dovrebbe distribuire solo il deb binario e i sorgenti a se stanti (o comunque non compilabili in automatico, il che mi fa pensare a metterlo nel non-free anche se non e' propriamente un non-free) La distinzione tra deb e deb-src a livello di sources.list e' dal punto di vista della creazione del .deb. Non c'e' nessuna necessita' che il deb-src (tanto per capirci) contenga veramente i sorgenti, basta che contenga cio' che serve per creare un .deb (ovvero una dir debian contenente un eseguibile rules con i target obbligatori). Anche per i pacchetti solo binari (che quindi vanno giustamente in non-free come hai sottolineato), esistera' un deb-src che probabilmente non fara' altro che copiare roba precompilato nelle directory giuste per poi invocare dpkg-deb. Ciao -- Stefano Zacchiroli -- Master in Computer Science @ Uni. Bologna, Italy [EMAIL PROTECTED],debian.org,bononia.it} - http://www.bononia.it/zack/ I know you believe you understood what you think I said, but I am not sure you realize that what you heard is not what I meant! -- G.Romney pgpNsJ1VoRlQ0.pgp Description: PGP signature
Re: contiamoci...
On Mon, Jun 23, 2003 at 11:58:54AM +0200, Francesco P. Lovergine wrote: Ciao, Allora che delegazione del 'chapter IT' ci sara' ad Oslo? zufus enrico fabbione frankie who else? ultrotter Ciao, Guido
packaging + kernel patches
ciao a tutti, sto debianizzando un demone che ho scritto (http://sf.net/project/cpufreqd) e mi sorge qualche domanda: 1- mi sto *aiutando* con dh_make, e' cosa buona e giusta? (in realta' e' dh_make che sta facendo tutto, ma tant'e' :) 2- il demone fa uso di una feature dei kernel 2.5 e disponibile come patch per i 2.4, CPUFreq. Questa feature e' in varie patch cumulative (ck, ac) o come patch a se stante, comunque in qualcosa non disponibile in debian (AFAIK). Che fare? pacchettizare anche una di queste? quale sarebbe meglio accettata? e poi la metto come Suggests o Reccomends? grazie a tutti -- mattia
Re: packaging + kernel patches
On Tue, 24 Jun 2003 18:09:38 +0200 Enrico Zini [EMAIL PROTECTED] wrote: On Tue, Jun 24, 2003 at 05:40:19PM +0200, Mattia Dongili wrote: sto debianizzando un demone che ho scritto (http://sf.net/project/cpufreqd) e mi sorge qualche domanda: 1- mi sto *aiutando* con dh_make, e' cosa buona e giusta? (in realta' e' dh_make che sta facendo tutto, ma tant'e' :) Non solo è buono e giusto, ma direi quasi necessario: e poi chi l'ha detto che per impacchettare un programma bisogna soffrire? :) mah... non la vedo proprio come un sofferenza, ha la sua utilita' fare le cose a mano, almeno per i primi tempi :) Mi raccomando di lanciare lintian per farti dire dove sono rimasti dei template di dh_make che ti sei scordato di riempire o cancellare. E non sentirti ferito nell'orgoglio dall'output di lintian: ne rimane *sempre* qualcuno :) CVD :) oltre a questo mi e' sorto un'altro problema: il demone fa uso di 2 librerie dinamiche. La debian-policy mi pare di aver capito che imponga di pacchettizzare separatamente le librerie, ma e' veramente eccessivo per quello che fanno le mie... si puo' raggirare in qualche maniera questa necessita? chesso'... considerarle file di supporto di altro tipo... hmmm... [...] Per pacchettizzare kernel patch, so che ultimamente c'è stata un po' di discussione su come fare, ma non l'ho seguita. Qualcuno può postare un riassunto? O:-) su debian-devel? (a me gli archivi!) grazie ancora -- mattia
Re: Possibiltés avec Alioth
Michel Grentzinger [EMAIL PROTECTED] a tapoté : Bonjour, Un developpeur Debian a annoncé que ses paquets sont disponibles sur CVS et m'a indiqué qu'il pourrait me donner accès au CVS. Comment fonctionne Alioth pour les non développeurs Debian ? D'après ce que j'ai compris, je dois créer un compte sur Alioth et demander au mainteneur de me permettre l'accès en écriture. Une fois cette étape réalisée, j'aurai accès à l'éciture via CVS, c'est bien ça ? Mais comment le mainteneur peut-il vérifier ce que je vais proposer, changer ou casser ?? Il regardera le diff et adaptera en fonction. -- Mathieu Roy Homepage: http://yeupou.coleumes.org Not a native english speaker: http://stock.coleumes.org/doc.php?i=/misc-files/flawed-english
Re: Possibiltés avec Alioth
* Michel Grentzinger [EMAIL PROTECTED] [2003-06-24 13:07] : Bonjour, Un developpeur Debian a annoncé que ses paquets sont disponibles sur CVS et m'a indiqué qu'il pourrait me donner accès au CVS. Comment fonctionne Alioth pour les non développeurs Debian ? Comme un CVS normal. D'après ce que j'ai compris, je dois créer un compte sur Alioth et demander au mainteneur de me permettre l'accès en écriture. Une fois cette étape réalisée, j'aurai accès à l'éciture via CVS, c'est bien ça ? Oui. Mais comment le mainteneur peut-il vérifier ce que je vais proposer, changer ou casser ?? Il ne peut pas : il te fait confiance pour ne pas casser trop les paquets, il peut également facilement revenir à une version précédente du CVS. Après, si tu casses trop souvent le paquet intentionnellement, il est probable que ton accès en écriture dans le CVS sera rapidement supprimé ... :-) Fred
Re: Possibiltés avec Alioth
Le Mardi 24 Juin 2003 15:51, Frédéric Bothamy a écrit : Un developpeur Debian a annoncé que ses paquets sont disponibles sur CVS et m'a indiqué qu'il pourrait me donner accès au CVS. Comment fonctionne Alioth pour les non développeurs Debian ? Comme un CVS normal. D'après ce que j'ai compris, je dois créer un compte sur Alioth et demander au mainteneur de me permettre l'accès en écriture. Une fois cette étape réalisée, j'aurai accès à l'éciture via CVS, c'est bien ça ? Oui. Mais comment le mainteneur peut-il vérifier ce que je vais proposer, changer ou casser ?? Il ne peut pas : il te fait confiance pour ne pas casser trop les paquets, il peut également facilement revenir à une version précédente du CVS. Après, si tu casses trop souvent le paquet intentionnellement, il est probable que ton accès en écriture dans le CVS sera rapidement supprimé ... :-) Merci à tous pour vos éclairages, je vais commencer par m'inscrire et à essayer de travailler avec alioth. -- Michel Grentzinger OpenPGP key ID : B2BAFAFA Available on http://www.keyserver.net
Re: maildirmake
On Tue, Jun 24, 2003 at 01:12:04PM +1000, Matthew Palmer wrote: On Mon, 23 Jun 2003, David B Harris wrote: Exim is capable of handling Maildir mailboxes. It's Priority: important. I don't know if that counts as shipping it by default or not, but I would certainly say that it's the closest thing around. Capable of handling, yes, but then, so is cat. g Once delivered, though, there's no way of getting it back out again unless you're running something like courier or similar. Or most modern local MUAs... after all, most folks don't read their mbox with cat, either (though it's equally possible). My logic was that, from the basic system, Maildir mailboxes are no use. Things like courier make Maildir useful, so that's where the maildirmake script should live. It *might* make sense to put it in exim where people can run it to make their mailboxes, but since the delivery is useless without other programs to post-process, I'm still not won over on the idea... It is, to within a close order, as useful as mbox mail delivery; however, it probably isn't worthy of it's own package, and having multiple MTAs (or MUAs) provide it makes little sense, really... perhaps it belongs in one of the general utility packages? -- Joel Baker [EMAIL PROTECTED] pgpEAWccWVLSz.pgp Description: PGP signature
Re: maildirmake
On Tue, 24 Jun 2003 13:12:04 +1000 (EST) Matthew Palmer [EMAIL PROTECTED] wrote: Capable of handling, yes, but then, so is cat. g Once delivered, though, there's no way of getting it back out again unless you're running something like courier or similar. Or Mutt, or a halfdozen other MUAs. :) My logic was that, from the basic system, Maildir mailboxes are no use. Things like courier make Maildir useful, so that's where the maildirmake script should live. It *might* make sense to put it in exim where people can run it to make their mailboxes, but since the delivery is useless without other programs to post-process, I'm still not won over on the idea... Well, it's a standard format, and it's a trivial shell script. The options are either including maildirmake(1) in each and every MUA that understands Maildir formats (understanding here that imapds perform many/most functions traditionally assigned to an MUA), and having them all either Conflicts: with one another or using alternatives. Given how simple it is, makes more sense to have it in one place. I don't know where it should be (in all the MTAs?), but there you go :) pgpmJKfebDkaV.pgp Description: PGP signature
Re: Bug#198158: architecture i386 isn't i386 anymore
At Sat, 21 Jun 2003 12:11:36 +0200, Erwan MAS wrote: Please keep , a i386 or i586 architecture , for the via C3 processor . i686 architecture is not compatible with C3 . This processor is very used in the Via EPIA motherboard : See : http://www.viavpsd.com/product/epia_mini_itx_spec.jsp?motherboardId=21 http://www.mini-itx.com/ You confused. VIA C3 Ezra (not Nehemiah) does not have CMOV instruction, and gcc create assembler code including CMOV if you set --cpu=i686. It's i686 processor, but it does not support full i686 capability. Regards, -- gotom
Re: Bug#198158: architecture i386 isn't i386 anymore
At 21 Jun 2003 00:27:18 +0200, Mathieu Roy wrote: RedHat provide glibc for i386, i586 and i686. Why doesn't Debian provide several packages for i*86 when the package can be optimized a lot depending on the CPU type? We're planning. i686 optimized binary does not work on my machine, so it's currently dropped. We need to check whether it's ok to upgrade smoothly or not. Regards, -- gotom
Re: maildirmake
On Mon, 23 Jun 2003, David B Harris wrote: Given how simple it is, makes more sense to have it in one place. I don't know where it should be (in all the MTAs?), but there you go :) Well I have one in dovecot but I don't see why it couldn't be in e.g. debianutils. -- Jaldhar H. Vyas [EMAIL PROTECTED] La Salle Debain - http://www.braincells.com/debian/
Re: Can a polish speaker please translate this?
On Sun, 22 Jun 2003, Marek Habersack wrote: thanks Marek. Can you ask him if he installed webmin updates without using .debs? This is the most probable cause of his problem. It is a bad idea because the packaging system is unaware of the changes and can, like in this case, accidently overwrite files. (A gentle hint that not everyone understands Polish would be good too. :-) -- Forwarded message -- From: [EMAIL PROTECTED] Resent-From: [EMAIL PROTECTED] To: [EMAIL PROTECTED] Resent-cc: [EMAIL PROTECTED] (Jaldhar H. Vyas) Date: Sat, 21 Jun 2003 10:58:40 +0200 Resent-Date: Sat, 21 Jun 2003 09:03:05 UTC Subject: Bug#198276: Blad przy instalacji pakietu webmin_094woody1 Package: webmin Version: 0.94-7woody1 Wystepuje blad przy instalacji pakietu. Pakiet nie jest instalowany w calosci There has been an error installing the package. The package isn't entirely installed. Powoduje to ze zaden pakiet dodatkowy nie jest instalowany It will cause that none of the additional (probably meant - depending upon this package) packages will be installed. Brakuje plikow webmin.acl, update.conf i innych The webmin.acl, update.conf and other files are missing Zapis sesji : Session transcript: [EMAIL PROTECTED]:~/webmin# dpkg -i webmin_0.94-7woody1_all.deb Zaznaczenie poprzednio nieznaznaczonego pakietu webmin. (Odczytywanie bazy danych ... 60487 plików i katalogów obecnie zainstalowanych.) Rozpakowanie webmin (z webmin_0.94-7woody1_all.deb) ... Konfigurowanie webmin (0.94-7woody1) ... the usual dpkg blurb [EMAIL PROTECTED]:~/webmin# dpkg -i webmin-core_0.94-7woody1_all.deb Zaznaczenie poprzednio nieznaznaczonego pakietu webmin-core. (Odczytywanie bazy danych ... 61146 plików i katalogów obecnie zainstalowanych.) Rozpakowanie webmin-core (z webmin-core_0.94-7woody1_all.deb) ... Konfigurowanie webmin-core (0.94-7woody1) ... the same blurb /etc/webmin/webmin.acl: Nie ma takiego pliku ani katalogu File or directory not found dpkg: b³±d przetwarzania webmin-core (--install): podproces post-installation script zwróci³ kod b³êdu 2 Wyst±pi³y b³êdy podczas przetwarzania: webmin-core and blurb again U¿ywam Debiana GNU/Linux 3.0, j±dra 2.4.20 (wlasna kompilacja) I'm using , kernel (own compilation) -- Jaldhar H. Vyas [EMAIL PROTECTED] La Salle Debain - http://www.braincells.com/debian/
Re: C++ Java IDE
* Jan Schulz | * David Goodenough wrote: | | KDevelop comes as part of KDE, Eclipse is only available in unstable at the | moment (I don't think it has made it into testing yet but I may be wrong). | | Nope... On the other hand it is no problem to recompile it on woody | systems. Only thing is to have a gnome2.2 backport in your | sources.list. Unfortunatelly I don't have that much webspace to do | a woody backport myself... http://lists.debian.org/debian-user/2003/debian-user-200302/msg03865.html or just deb http://mirror.raw.no/ gnome2.2/ deb-src http://mirror.raw.no/ gnome2.2/ -- Tollef Fog Heen,''`. UNIX is user friendly, it's just picky about who its friends are : :' : `. `' `-
Re: maildirmake
[EMAIL PROTECTED] wrote: [...] But, I was looking around and wondering about that I couldn't find any `maildirmake' for Debian, excluding qmail-src, courier and maildrop, which I don't want/don't need to use. [...] You could start by telling us what maildirmake is supposed to do. Why do we need it? Any program I know of which can handle Maildir is not only capable of storing messages in Maildir folders but also of generating them. This includes e.g. the exim(4) MTA, MDAs like procmail or maildrop, and the MUA mutt. cu andreas
Re: maildirmake
On Tue, Jun 24, 2003 at 01:12:04PM +1000, Matthew Palmer wrote: My logic was that, from the basic system, Maildir mailboxes are no use. Can I have a bit of the weed you are smoking? Seems to be good. Package: mutt Priority: standard `standard' These packages provide a reasonably small but not too limited character-mode system. This is what will be installed by default if the user doesn't select anything else. It doesn't include many large applications. -- Marcelo
Re: Packages: an average 66321 bytes per line of description
I was hoping large package developers would write longer descriptions.
Re: maildirmake
* Andreas Metzler [EMAIL PROTECTED]: You could start by telling us what maildirmake is supposed to do. Why do we need it? Any program I know of which can handle Maildir is not only capable of storing messages in Maildir folders but also of generating them. This includes e.g. the exim(4) MTA, MDAs like procmail or maildrop, and the MUA mutt. Same for Postfix. Who needs maildirmake? -- Ralf Hildebrandt (Im Auftrag des Referat V a) [EMAIL PROTECTED] Charite Campus MitteTel. +49 (0)30-450 570-155 Referat V a - Kommunikationsnetze - Fax. +49 (0)30-450 570-916 AIM: ralfpostfix
Re: maildirmake
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Am Dienstag, 24. Juni 2003 09:45 schrieb Ralf Hildebrandt: * Andreas Metzler [EMAIL PROTECTED]: You could start by telling us what maildirmake is supposed to do. Why do we need it? Any program I know of which can handle Maildir is not only capable of storing messages in Maildir folders but also of generating them. This includes e.g. the exim(4) MTA, MDAs like procmail or maildrop, and the MUA mutt. Same for Postfix. Who needs maildirmake? I wonder how all this MTAs and MDAs create shared folders automatically ... Michael - -- Homepage: http://www.worldforge.org/ -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.1 (GNU/Linux) iD8DBQE++AgNWSOgCCdjSDsRAm+DAJ9XRo8aq74uAEVwU0RyuLe/YLnDIwCeOkmq 10rdjVBmsVbKTlGipjnBNUM= =Z/jm -END PGP SIGNATURE-
Re: maildirmake
On Tue, Jun 24, 2003 at 09:45:30AM +0200, Ralf Hildebrandt wrote: * Andreas Metzler [EMAIL PROTECTED]: You could start by telling us what maildirmake is supposed to do. Why do we need it? Any program I know of which can handle Maildir is not only capable of storing messages in Maildir folders but also of generating them. This includes e.g. the exim(4) MTA, MDAs like procmail or maildrop, and the MUA mutt. Same for Postfix. Who needs maildirmake? Same for masqmail... But why not create a small utility that creates it? It's trivial, and I can recycle some code from masqmail. Greetings, Oliver -- .''`. : :' :Oliver Kurth [EMAIL PROTECTED] `. `' Debian GNU/Linux maintainer - www.debian.org `- pgpfGn8NFLXoE.pgp Description: PGP signature
Re: maildirmake
On Tue, Jun 24, 2003 at 09:45:30AM +0200, Ralf Hildebrandt wrote: * Andreas Metzler [EMAIL PROTECTED]: You could start by telling us what maildirmake is supposed to do. Why do we need it? Any program I know of which can handle Maildir is not only capable of storing messages in Maildir folders but also of generating them. This includes e.g. the exim(4) MTA, MDAs like procmail or maildrop, and the MUA mutt. Same for Postfix. Who needs maildirmake? IIRC courier-imap expects ~/Maildir to exist before you can check your mail (but maildirmake ships with courier-base). -- sam clegg :: [EMAIL PROTECTED] :: http://superduper.net/ :: PGP : D91EE369 $superduper: .signature,v 1.13 2003/06/17 10:29:24 sam Exp $ pgpjWcShwCS3a.pgp Description: PGP signature
Re: maildirmake
* Michael Koch [EMAIL PROTECTED]: You could start by telling us what maildirmake is supposed to do. Why do we need it? Any program I know of which can handle Maildir is not only capable of storing messages in Maildir folders but also of generating them. This includes e.g. the exim(4) MTA, MDAs like procmail or maildrop, and the MUA mutt. Same for Postfix. Who needs maildirmake? I wonder how all this MTAs and MDAs create shared folders automatically ... In that special case you need maildirmake, but not the simple shell script, but the version that comes with maildrop. -- Ralf Hildebrandt (Im Auftrag des Referat V a) [EMAIL PROTECTED] Charite Campus MitteTel. +49 (0)30-450 570-155 Referat V a - Kommunikationsnetze - Fax. +49 (0)30-450 570-916 AIM: ralfpostfix
Re: Packages: an average 66321 bytes per line of description
I was hoping that maintainers of multi-megabyte packages would do the package justice by giving an adequate description. The Packages file could very well be the source for decisions on what gets chosen or not for ones system.
Re: Packages: an average 66321 bytes per line of description
On Tue, Jun 24, 2003 at 03:29:23PM +0800, Dan Jacobson wrote: I was hoping that maintainers of multi-megabyte packages would do the package justice by giving an adequate description. File wishlist bugs with a patch for the long description then. Michael
Bug#198602: ITP: debbackup -- Backup and restore Debian specifics (package status, conffiles)
Package: wnpp Version: unavailable; reported 2003-06-24 Severity: wishlist * Package name: debbackup Version : 0.1 Upstream Author : Daniel Stone [EMAIL PROTECTED] * URL : http://www.trinity.unimelb.edu.au/~dstone/debbackup/ (not functional yet) * License : GPL Description : Backup and restore Debian specifics (package status, conffiles) debbackup is a supplemental, Debian-specific, backup program. It backs up only what is needed to restore from a fresh install, with data recovered - package information (including holds/etc), conffile changes, Debconf information, and more. debrestore will restore this information - installing/updating required packages, restoring configuration files, and more. -- System Information: Debian Release: testing/unstable Architecture: i386 Kernel: Linux nanasawa 2.5.72-mm3 #1 Mon Jun 23 21:43:29 EST 2003 i686 Locale: LANG=C, LC_CTYPE=C -- Daniel Stone [EMAIL PROTECTED] Developer, Trinity College, University of Melbourne pgpYc1ZAUSf7Q.pgp Description: PGP signature
Re: EPSON appreciates your feedback by June 30, '03 - Debian
[Ob-lists: if replying publicly, please reply to -devel only] Farideh Sherbaf [EMAIL PROTECTED] wrote: Dear Linux Developer and Distributor, Hi, Please allow me to introduce myself. My name is Farideh Sherbaf and I am your contact for EPSON Worldwide Developer Relations for scanners and All-In-One (Multifunction) products. The EPSON Developer Relations Group would like to obtain your feedback on your support of scanners in the Linux environment. I am the maintainer of the SANE packages in the Debian distribution ; nice to see some communication from Epson Kowa ! SANE maintainer hat on Your prompt answers to the following questions are appreciated (Yes/No): 1. Do you include the SANE backend (scanner driver) within your Linux distribution package? Yes. This is a must-have for any Linux distribution that wants to be used on the desktop. 2. Which SANE frontends (applications) do you include within your Linux distribution package? The standard frontends from the SANE project are available (scanimage, scanadf, xscanimage, xcam, saned), along with XSane, QuiteInsane and Kooka. 3. Do you include Epson's Image Scan! for Linux? (Image Scan! for Linux is a graphical frontend for Epson scanners.) No. Although further explanation does not seem to be requested by your survey, let me explain why the Epson Kowa backend and frontend aren't included in Debian. To be included in the Debian distribution, a software basically needs to fulfill 2 conditions : - its license must be considered Free by Debian (see [1] for details) - somebody has to volunteer to maintain the packages The latter would probably be no problem for the Epson Kowa softwares if the former point was fulfilled. The Epson Kowa Public License that covers the distribution of the Epson Kowa softwares isn't Free ; it forbids reverse-engineering or any form of analysis of the binary-only modules that ship with the software. This is the first showstopper. The second one is that the source distribution ships binary-only modules, which makes it impossible to build the softwares for anything else than Linux/x86 ; in its latest release, Debian supports 11 hardware architectures, and portability is something very important for us. We have a special section in our archive for softwares that do not meet our requirements in terms of license, but are nonetheless freely redistributable and potentially useful to our users ; it's the non-free section. Should somebody be willing to maintain packages of the Epson Kowa softwares, they could be included in the non-free section. However, note that the non-free section isn't distributed on the release CDs. Now, apart from this, looking at my 6-months-old notes on the subject, it seems that the scanners supported by the Epson Kowa backend are already supported (to some point) by the regular SANE backends. The same applies to the frontend, with the powerful frontends already available. Again, my notes are somewhat dated by now, so feel free to correct me if I'm wrong on this point. Feel free to contact me if you have any questions. Regards, JB. [1] http://www.debian.org/doc/debian-policy/ch-archive.html#s2.1.1 -- 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: Bug#198158: architecture i386 isn't i386 anymore
Hi Arnd Bergmann, On Tuesday 24 June 2003 02:00, Adam Heath wrote: On Tue, 24 Jun 2003, Martin v. Löwis wrote: In g++ 3.2, this code was distributed as i386, and nobody noticed that it doesn't work on i386 for quite some time. In gcc 3.3, an implementation is provided that works on i386, and this implementation here is declared i486. Unfortunately, the two implementations are not binary compatible. Debian has to pick one of these, and it needs to pick the i486 version for compatibility with other Linux distributions (which either ship with gcc 3.2 today, or target i586+ only, anyway). Er, if this function is inlined, then how can it be part of some published api? If it's not part of some published api, then how can using an i386 variation cause problems with other distributions? The API requires that access to atomic variables is truly atomic. The i386 version uses a semaphore to synchronize the access to an atomic variable, the i486+ version uses the lock prefix. When you mix these two in one program, two threads might access the variable without locking against each other because the code inside the semaphore does not lock the memory bus. This has been a very informative discussion. While hesitant about dropping i386 support I am now convinced that: (a) i386 support should be dropped so that binary compatibility can be maintained with other Linux distributions. Debian's binary compatibility is a very important feature, especially as a lot of proprietary Linux software companies provide no official support for Debian. Binary compatibility helps fulfil the social contract where although non-free software isn't a part of Debian, we support its use, and we provide infrastructure (such as our bug-tracking system and mailing lists) for non-free software packages. (b) i486+ should be targeted, but GCC-compiled code optimised for either i586 or i686 (consider whichever is also best for P4 and Athlon). Debian has the goal of being a universal distribution and operating system, and even ditching i386 support is chilling enough. Pragmatically, even though i486 desktops are now relatively scarce i486 laptops still make very useful portable routers. (c) Just keep the i386 name. Changing it will break too many scripts when all that is needed to resolve confusion is a release note. i486+ would still be misleading to those who need to understand that even though i486 is supported the binaries are still optimised for a more recent architecture. One day support for i486 will be dropped and then we also won't need to worry about changing the architecture name. I'd appreciate replies to this message to be CCed to my email address. Regards, Adam
Re: Accepted vile 9.3-s1 (sparc source all)
In article [EMAIL PROTECTED] you wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Mon, 23 Jun 2003 23:29:15 +1000 Source: vile Binary: xvile vile-filters vile vile-common Architecture: source sparc all Version: 9.3-s1 Distribution: unstable Urgency: low Maintainer: Brendan O'Dea [EMAIL PROTECTED] Changed-By: Brendan O'Dea [EMAIL PROTECTED] Description: vile - VI Like Emacs - vi work-alike vile-common - VI Like Emacs - support files for vile/xvile vile-filters - VI Like Emacs - highlighting filters for vile/xvile xvile - VI Like Emacs - vi work-alike (X11) Changes: vile (9.3-s1) unstable; urgency=low 9.3s is looking pretty stable (one ifdef fix was needed for win32). I'm mostly working to setup a new machine (seems that the power supply on the backup machine where I was building OS/2 stuff is broken, but since it's my backup machine I don't have time to fix _that_ until I have a newer machine up). So that's driving my schedule for 9.4 (pre)release. -- Thomas E. Dickey [EMAIL PROTECTED] [EMAIL PROTECTED] http://dickey.his.com ftp://dickey.his.com
Re: [devel] Packages: an average 66321 bytes per line of description
Re: Re: [devel] Packages: an average 66321 bytes per line of description [Dan Jacobson [EMAIL PROTECTED], Tue, Jun 24, 2003 at 03:17:27PM +0800, [EMAIL PROTECTED]] I was hoping large package developers would write longer descriptions. Where are the statistics for that? You only gave the average. Christoph -- Christoph Berg [EMAIL PROTECTED], 0681/9657944 http://rw4.cs.uni-sb.de/~cb/ Universität des Saarlandes, Compiler Design Lab pgpeNwBSMlouI.pgp Description: PGP signature
Re: [mass bug filing?] Short descriptions being used as long descriptions and other policy violations
Andreas Metzler [EMAIL PROTECTED] writes: [...] I was wondering, should I make a mass filing of bugs for those packages who fail to produce a proper description? [...] I doubt that just filing bugs without fix makes sense, OTOH if you planned to submit 10 reports with the description sucks, here is better one - tags:patch instead of 100 simply stating the description sucks, please go ahead. ;-) [...] I'd say that writing a meaningful package description is certainly the duty of the individual package maintainer. A package maintainer should usually have an idea of what his/her package is good for, while Javier would probably have to spend a lot more time to figure that out, at least for lesser known packages. I don't think that filing a bug saying that Your extended package description does not meet Debian policy requirements. Please consider writing 4-5 lines to give sysadmins an idea what your package can do for them. means asking too much from a Debian maintainer. You don't have to write Your package sucks, there certainly are more polite and less offensive ways. I would e.g. tell them that a nice description might motivate more people to use and install your package. And BTW: Thanks, Johannes
Re: Packages: an average 66321 bytes per line of description
Dan Jacobson writes: I was hoping that maintainers of multi-megabyte packages would do the package justice by giving an adequate description. While extremely short descriptions might be a cause for concern regardless of the size of the package, I don't see why larger packages should need longer descriptions. A one-of-a-kind special-purpose package is likely to need a much longer description than yet another Web browser. Why not go through your list, read all the descriptions that seem suspiciously short, and file bugs if justified? -- John Hasler [EMAIL PROTECTED] (John Hasler) Dancing Horse Hill Elmwood, WI
Re: CGI:IRC on Debian
On Mon, 2003-06-23 at 14:28, Guilherme de S. Pastore wrote:
Hello people! =)
I became a maintainer recently, when I took the prozilla package from Gustavo
Noronha Silva (kov), a few days ago. I am now trying to finish my second
Debian Package: cgiirc.
Unfortunately, the program puts all its files in the same directory, causing
problems with the FHS. I contacted the upstream author, asking for changes,
and even offering myself to do the job.
I got surprised when I received his response, telling me he wanted the
program to be entirely coded by him, following his own coding style, but he
wouldn't do anything by now.
I said what? I hadn't replied at all until a few minutes ago when
someone mentioned this post on IRC..
My main concern is keeping CGI:IRC easy to install for people who just
want to be able to install it easily as a user and simply saying upload
all these files into your cgi-bin directory works well. Nor have I ever
been particularly convinced that system-wide CGI scripts are a good
idea..
However I'd be happy to apply a patch which puts the locations of the
modules and so on into the config file..
I think I'm going to release the first version of the package dodging the
problem with sym links, and start changing the code from the second release
on, if I don't get a better answer from him.
A better workaround I can think of is simply adding to the top of each
script:
BEGIN { chdir(/usr/lib/cgiirc) }
(Assuming /usr/lib/cgiirc is the right place to put
modules/interfaces/formats) and then adjust the path to the
configuration file that is used (to /etc/cgiirc.config or whatever)..
What do you all think I should do?
Get your facts right first ;)
Re: Packages: an average 66321 bytes per line of description
* Dan Jacobson ([EMAIL PROTECTED]) wrote: I was hoping large package developers would write longer descriptions. Too bad. The two are not, should not, and should never be related. Stephen pgpiYTdDuqfg2.pgp Description: PGP signature
Re: Packages: an average 66321 bytes per line of description
* Dan Jacobson ([EMAIL PROTECTED]) wrote: I was hoping that maintainers of multi-megabyte packages would do the package justice by giving an adequate description. The description is adequate. The size of the package has nothing to do with it. The Packages file could very well be the source for decisions on what gets chosen or not for ones system. It probably is. Stephen pgpTFR8fC313L.pgp Description: PGP signature
Re: Packages: an average 66321 bytes per line of description
On Mon, Jun 23, 2003 at 09:10:09PM -0500, Steve Langasek wrote: On Tue, Jun 24, 2003 at 07:56:42AM +0800, Dan Jacobson wrote: Fellas, looking in the Packages files, some big packages have little descriptions, some little packages have big descriptions, and this package description went wee wee wee, all the way home. Why does this belong on debian-devel instead of debian-curiosa? because some packages have really crappy useless descriptions. the worst culprits are usually sets of binary packages from the one source file which have package descriptions like libfoo-dev = dev files for libfoo, libfoo-doc = documention for libfoo, and libfoo = runtime files for foo library, without bothering to describe what foo actually is. well, duh! like nobody would ever guess that a package called libfoo-doc was the documentation for libfoo. tell the reader something we DON'T know. a package description is supposed to tell someone who has never heard of foo before a little bit about it, not just multiple variations of foo's name. craig
Re: no freshness dating inside Packages.gz
Martin Schulze wrote: Bernd Eckenfels wrote: On Tue, Jun 17, 2003 at 08:29:14PM -0400, Joey Hess wrote: He wants to know when a particular package was last updated, without having to download it and examine the gzip time stamp and/or changelog. It is unfortunate, that there is no easy access to the changelog, I know of, but all other infos can be seen on the package tracking system: I guess that you've never heard of http://changelogs.credativ.org/ ... and now I had to find out that this service went offline a while ago... Regards, Joey -- WARNING: Do not execute! This call violates patent DE10108564. http://www.elug.de/projekte/patent-party/patente/DE10108564 wget -O patinfo-`date +%Y%m%d`.html http://patinfo.ffii.org/
Re: C++ Java IDE
Hallo Tollef, * Tollef Fog Heen wrote: * Jan Schulz | sources.list. Unfortunatelly I don't have that much webspace to do | a woody backport myself... deb http://mirror.raw.no/ gnome2.2/ deb-src http://mirror.raw.no/ gnome2.2/ Was more meant to supply a eclipse backport for woody. :) My webspace hardly is enough for the deb-src repository for eclipse... Jan -- Jan Schulz [EMAIL PROTECTED] Wer nicht fragt, bleibt dumm.
Re: no freshness dating inside Packages.gz
On Mon, Jun 23, 2003 at 03:14:26PM +0200, Martin Schulze wrote: Bernd Eckenfels wrote: On Tue, Jun 17, 2003 at 08:29:14PM -0400, Joey Hess wrote: He wants to know when a particular package was last updated, without having to download it and examine the gzip time stamp and/or changelog. It is unfortunate, that there is no easy access to the changelog, I know of, but all other infos can be seen on the package tracking system: I guess that you've never heard of http://changelogs.credativ.org/ Correct, most people have never heard of this thing. Furthermore, it's broken (zero-sized replies). -- .''`. ** Debian GNU/Linux ** | Andrew Suffield : :' : http://www.debian.org/ | Dept. of Computing, `. `' | Imperial College, `- -- | London, UK pgp3C912GkzJX.pgp Description: PGP signature
Re: maildirmake
Am Die, 2003-06-24 um 03.46 schrieb Matthew Palmer: On Tue, 24 Jun 2003 [EMAIL PROTECTED] wrote: Now I'm wondering about it even more. IMHO `maildirmake' is _very_ necessary for any mail and as it seems to be only a 2-line-shell-script why it isn't included anywhere and anyway in the base-system? As I recall, maildirmake is only needed if you are running Maildir-based MDAs, which Debian does not by default[1]. That is enough of a reason not to ship it in the base system, regardless of whether it's a two line shell script or not. I use offlineimap to get my remote IMAP Folders synced with my laptop. Offlineimap writes directly to maildirs. So I think there _are_ cases where no courier is needed, but a maildirmake program. I installed another package thats comes with a maildirmake program, but a real maildirmake package would be nicer ;), maybe a maildir toolbox or something like that would be usefull. *snip* formorer -- Alexander formorer Wirt KeyID: BC7D020A EMail: [EMAIL PROTECTED] ICQ: 28651245 WWW: http://www.formorer.de Encrypted and Signed Email preferred. signature.asc Description: Dies ist ein digital signierter Nachrichtenteil
Re: no freshness dating inside Packages.gz
Martin Schulze wrote: Bernd Eckenfels wrote: On Tue, Jun 17, 2003 at 08:29:14PM -0400, Joey Hess wrote: He wants to know when a particular package was last updated, without having to download it and examine the gzip time stamp and/or changelog. It is unfortunate, that there is no easy access to the changelog, I know of , but all other infos can be seen on the package tracking system: I guess that you've never heard of http://changelogs.credativ.org/ You can get the changelog with qa.debian.org: 1) go to http://packages.debian.org/foo 2) go to link 'developer information for foo' 3) go to link Accepted foo 17.42-143 (i386 source) And here is the last changelogs entry Alternatively, you can replace step 1-2) with 1-2) go to link http://packages.qa.debian.org/foo Cheers, -- Bill. [EMAIL PROTECTED] Imagine a large red swirl here.
Re: Bug#198158: architecture i386 isn't i386 anymore
On Tue, Jun 24, 2003 at 01:47:55PM +0900, GOTO Masanori wrote: At 21 Jun 2003 00:27:18 +0200, Mathieu Roy wrote: RedHat provide glibc for i386, i586 and i686. Why doesn't Debian provide several packages for i*86 when the package can be optimized a lot depending on the CPU type? We're planning. i686 optimized binary does not work on my machine, so it's currently dropped. We need to check whether it's ok to upgrade smoothly or not. There used to be libc6-686 and so on, but they caused a lot of problems with upgrades. Then they were re-enabled, then disabled again in the same release. I wasn't able to measure a significant performance increase with the optimized library anyway, so I haven't missed it. -- - mdz
Re: Bug#198602: ITP: debbackup -- Backup and restore Debian specifics (package status, conffiles)
On Tuesday 24 June 2003 11:51, Daniel Stone wrote: Package: wnpp Version: unavailable; reported 2003-06-24 Severity: wishlist * Package name: debbackup Version : 0.1 Version 0.1... How much of it does already work? How much is sid specific and won't work on woody/sarge? From the description, this sounds like a very essential package, I'll definitely have a look at it when it hits the archive (or at the latest when it hits testing). cheers -- vbi -- OpenPGP encrypted mail welcome - my key: http://fortytwo.ch/gpg/92082481 pgpQYmYLzz4tc.pgp Description: signature
Re: Bug#198602: ITP: debbackup -- Backup and restore Debian specifics (package status, conffiles)
On Tue, 24 Jun 2003, Daniel Stone wrote: Package: wnpp Version: unavailable; reported 2003-06-24 Severity: wishlist * Package name: debbackup Version : 0.1 Upstream Author : Daniel Stone [EMAIL PROTECTED] * URL : http://www.trinity.unimelb.edu.au/~dstone/debbackup/ (not functional yet) * License : GPL Description : Backup and restore Debian specifics (package status, conffiles) debbackup is a supplemental, Debian-specific, backup program. It backs up only what is needed to restore from a fresh install, with data recovered - package information (including holds/etc), conffile changes, Debconf information, and more. debrestore will restore this information - installing/updating required packages, restoring configuration files, and more. Tell me when you upload this, so I can file an rc bug against it, for modifying other packages conffiles.
Re: EPSON appreciates your feedback by June 30, '03 - Debian
Dear Matt, Thank you for responding to my email. I will use Julien as scanner contact person. However, if possible I appreciate if I could also obtain your signature info for our database. Best regards, Farideh - Original Message - From: Matt Zimmerman [EMAIL PROTECTED] To: Farideh Sherbaf [EMAIL PROTECTED] Cc: debian-project@lists.debian.org; debian-devel@lists.debian.org; [EMAIL PROTECTED]; Ray Hsu [EMAIL PROTECTED]; Farideh Sherbaf [EMAIL PROTECTED] Sent: Monday, June 23, 2003 8:09 PM Subject: Re: EPSON appreciates your feedback by June 30, '03 - Debian On Mon, Jun 23, 2003 at 04:15:25PM -0700, Farideh Sherbaf wrote: Dear Linux Developer and Distributor, Please allow me to introduce myself. My name is Farideh Sherbaf and I am your contact for EPSON Worldwide Developer Relations for scanners and All-In-One (Multifunction) products. The EPSON Developer Relations Group would like to obtain your feedback on your support of scanners in the Linux environment. Your prompt answers to the following questions are appreciated (Yes/No): 1. Do you include the SANE backend (scanner driver) within your Linux distribution package? 2. Which SANE frontends (applications) do you include within your Linux distribution package? 3. Do you include Epson's Image Scan! for Linux? (Image Scan! for Linux is a graphical frontend for Epson scanners.) I have forwarded your request to the developer responsible for SANE in Debian, Julien BLACHE [EMAIL PROTECTED]. -- - mdz
Re: [mass bug filing?] Short descriptions being used as long descriptions and other policy violations
Johannes Rohr wrote: I'd say that writing a meaningful package description is certainly the duty of the individual package maintainer. A package maintainer should usually have an idea of what his/her package is good for, while Javier would probably have to spend a lot more time to figure that out, at least for lesser known packages. However, not providing a better description will (likely) not get anything done. I don't think that filing a bug saying that Your extended package description does not meet Debian policy requirements. Please consider writing 4-5 lines to give sysadmins an idea what your package can do for them. means asking too much from a Debian maintainer. You don't. But I can't help but think that there are a lot of obvious maintainer's duties more or less neglected - often by simple obmission, but sometimes patterns show. Cheers T. pgpbUT5AjVPEd.pgp Description: PGP signature
Re: Bug#198602: ITP: debbackup -- Backup and restore Debian specifics (package status, conffiles)
* Adam Heath ([EMAIL PROTECTED]) [030624 18:50]: On Tue, 24 Jun 2003, Daniel Stone wrote: Package: wnpp Version: unavailable; reported 2003-06-24 Severity: wishlist * Package name: debbackup Version : 0.1 Upstream Author : Daniel Stone [EMAIL PROTECTED] * URL : http://www.trinity.unimelb.edu.au/~dstone/debbackup/ (not functional yet) * License : GPL Description : Backup and restore Debian specifics (package status, conffiles) debbackup is a supplemental, Debian-specific, backup program. It backs up only what is needed to restore from a fresh install, with data recovered - package information (including holds/etc), conffile changes, Debconf information, and more. debrestore will restore this information - installing/updating required packages, restoring configuration files, and more. Tell me when you upload this, so I can file an rc bug against it, for modifying other packages conffiles. When did you fill an rc bug against tar for modifiying other packages conffiles? Cheers, Andi -- http://home.arcor.de/andreas-barth/ PGP 1024/89FB5CE5 DC F1 85 6D A6 45 9C 0F 3B BE F1 D0 C5 D1 D9 0C
Re: Bug#198602: ITP: debbackup -- Backup and restore Debian specifics (package status, conffiles)
Le mar 24/06/2003 à 18:44, Adam Heath a écrit : Tell me when you upload this, so I can file an rc bug against it, for modifying other packages conffiles. In the meantime, you can still file RC bugs against all text editors that allow to modify conffiles. Hint: maybe this package won't modify conffiles in the maintainer scripts. -- .''`. 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?=
Re: Bug#198602: ITP: debbackup -- Backup and restore Debian specifics (package status, conffiles)
On Tue, Jun 24, 2003 at 11:44:51AM -0500, Adam Heath wrote: On Tue, 24 Jun 2003, Daniel Stone wrote: Package: wnpp Version: unavailable; reported 2003-06-24 Severity: wishlist * Package name: debbackup Version : 0.1 Upstream Author : Daniel Stone [EMAIL PROTECTED] * URL : http://www.trinity.unimelb.edu.au/~dstone/debbackup/ (not functional yet) * License : GPL Description : Backup and restore Debian specifics (package status, conffiles) debbackup is a supplemental, Debian-specific, backup program. It backs up only what is needed to restore from a fresh install, with data recovered - package information (including holds/etc), conffile changes, Debconf information, and more. debrestore will restore this information - installing/updating required packages, restoring configuration files, and more. Tell me when you upload this, so I can file an rc bug against it, for modifying other packages conffiles. That's very silly. Would you file an RC bug against restore(1) for modifying other packages' conffiles? The conffile editing restriction is there to stop other packages' postinsts from messing about with conffiles, not to stop anybody from ever writing any program which touches a conffile. -- Colin Watson [EMAIL PROTECTED]
Re: EPSON appreciates your feedback by June 30, '03 - Debian
Hi Farideh, On Mon, Jun 23, 2003 at 04:15:25PM -0700, Farideh Sherbaf wrote: Please allow me to introduce myself. My name is Farideh Sherbaf and I am your contact for EPSON Worldwide Developer Relations for scanners and All-In-One (Multifunction) products. The EPSON Developer Relations Group would like to obtain your feedback on your support of scanners in the Linux environment. Let me add to Juliens opinion a note from a user of those scanner tools: I own an Epson 1640SU scanner with automatic document feeder. And it is really great to have it supported by Linux. With the scanimage tool we wrote a script to scan our lecture notes and generate PDF files in no time - something we failed to implement with *cough* Windows. It really helps to have them archived in binary form instead of paper so a big thank you for making it possible by at least providing development information for your hardware. Greetings Torsten pgpkbjU2OWNd6.pgp Description: PGP signature
Re: Packages: an average 66321 bytes per line of description
On Tue, Jun 24, 2003 at 11:56:03PM +1000, Craig Sanders wrote: the worst culprits are usually sets of binary packages from the one source file which have package descriptions like libfoo-dev = dev files for libfoo, libfoo-doc = documention for libfoo, and libfoo = runtime files for foo library, without bothering to describe what foo actually is. well, duh! like nobody would ever guess that a package called libfoo-doc was the documentation for libfoo. tell the reader something we DON'T know. But he knows what libfoo is - or at least he is just a $ apt-cache show libfoo away from that information. Do we need to duplicate the description of a library package in each and every supporting package? Greetings Torsten pgpq7kdiZI429.pgp Description: PGP signature
Re: Bug#198602: ITP: debbackup -- Backup and restore Debian specifics (package status, conffiles)
On Tue, Jun 24, 2003 at 11:44:51AM -0500, Adam Heath wrote: On Tue, 24 Jun 2003, Daniel Stone wrote: [snip] debbackup is a supplemental, Debian-specific, backup program. It backs up only what is needed to restore from a fresh install, with data recovered - package information (including holds/etc), conffile changes, Debconf information, and more. debrestore will restore this information - installing/updating required packages, restoring configuration files, and more. Tell me when you upload this, so I can file an rc bug against it, for modifying other packages conffiles. In that case you'd better file rc bugs against passwd, webmin, etc.. :) -- Brett pgpvF72xMXQzm.pgp Description: PGP signature
Re: [mass bug filing?] Short descriptions being used as long descriptions and other policy violations
On Tue, Jun 24, 2003 at 06:41:21PM +0200, Thomas Viehmann wrote: I'd say that writing a meaningful package description is certainly the duty of the individual package maintainer. A package maintainer should usually have an idea of what his/her package is good for, while Javier would probably have to spend a lot more time to figure that out, at least for lesser known packages. However, not providing a better description will (likely) not get anything done. You don't know that. If we agreed to such a sweeping generalization, we would not have the vast majority of bug reports in the BTS. -- 2. That which causes joy or happiness.
Re: Bug#198602: ITP: debbackup -- Backup and restore Debian specifics (package status, conffiles)
Adam Heath wrote: On Tue, 24 Jun 2003, Daniel Stone wrote: * Package name: debbackup - installing/updating required packages, restoring configuration files, and more. Tell me when you upload this, so I can file an rc bug against it, for modifying other packages conffiles. let's file a bug against vim, since it changes conffiles also. you are making an assumtion that this program will modify conffiles by the simple act of being installed. Debian Policy v 3.5.10.0 § 11.7.4. Sharing configuration files The maintainer scripts must not alter a `conffile' of _any_ package, including the one the scripts belong to. adam, are you willing to state, package unseen, that the maintainer scripts are modifying any conffiles? if so, could you please send me next week's California Lottery numbers? daniel, i for one think that this package will be a very welcome addition to the archive, and could have used it about three weeks ago. -john
Re: Bug#198602: ITP: debbackup -- Backup and restore Debian specifics (package status, conffiles)
Hi, On Tue, Jun 24, 2003 at 11:44:51AM -0500, Adam Heath wrote: On Tue, 24 Jun 2003, Daniel Stone wrote: Package: wnpp Version: unavailable; reported 2003-06-24 Severity: wishlist * Package name: debbackup Version : 0.1 Upstream Author : Daniel Stone [EMAIL PROTECTED] * URL : http://www.trinity.unimelb.edu.au/~dstone/debbackup/ (not functional yet) * License : GPL Description : Backup and restore Debian specifics (package status, conffiles) debbackup is a supplemental, Debian-specific, backup program. It backs up only what is needed to restore from a fresh install, with data recovered - package information (including holds/etc), conffile changes, Debconf information, and more. debrestore will restore this information - installing/updating required packages, restoring configuration files, and more. Tell me when you upload this, so I can file an rc bug against it, for modifying other packages conffiles. *g* 5 serious replies already -- sorry Adam, I'm afraid there are just too many people that lack even the most basic sense of humour. Cheers, Emile. -- E-Advies - Emile van Bergen [EMAIL PROTECTED] tel. +31 (0)70 3906153 http://www.e-advies.nl pgpeChrcNkxJV.pgp Description: PGP signature
Re: Bug#198602: ITP: debbackup -- Backup and restore Debian specifics (package status, conffiles)
On Tuesday 24 June 2003 10:59 am, Emile van Bergen wrote: Hi, On Tue, Jun 24, 2003 at 11:44:51AM -0500, Adam Heath wrote: Tell me when you upload this, so I can file an rc bug against it, for modifying other packages conffiles. *g* 5 serious replies already -- sorry Adam, I'm afraid there are just too many people that lack even the most basic sense of humour. Or perhaps not everyone thinks a threat of an RC bug is a laughing matter. - Keegan
Re: Bug#198602: ITP: debbackup -- Backup and restore Debian specifics (package status, conffiles)
I've been meaning to write this for a while. I wrote up a procecure and I may have even posted it. I include files indicated by cruft in my backups. I'm also looking at checking md5sums and atimes to help decide if backups of files like conf files is neccisary or if they're just the defaults from the package(s). I use dpkg-repackage (or something like that) to repackage packages that aren't in the archive anymore so I can back them up in a more friendly way. If you need any help with debbackup, please let me know. I was also hoping to have a nice front end with the ability to veto or include backing up things... Since I do most of it manualy this hasn't been a problem. It'd be nice if debbackup would suggest some good backends to store the backups incrementaly, on special media (CD's...)... I'd also like to plug ppmd as probably the best compression available (slow, less tested, but compresses on average much smaller than gzip or bzip2). The ability to have a rescue backup disc that's bootable and could restore would be ideal. I have also been thinking about creating a complimentary program that would help cleanup the system by finding unused packages, seldom used packages, cruft, unnessisary files... As with debbackup, there are things to do some of the functons already. Drew Daniels
Re: advise for packaging duali arabic spell checker
On Mon, Jun 23, 2003 at 11:09:25AM -0700, Keegan Quinn wrote: On Sunday 22 June 2003 12:48 am, Mohammed Sameer wrote: i was thinking about splitting duali itself into 2 packages: 1- duali the main dictionary 2- duali-dev contain the script duali-data build-depends on duali-dev while duali itself depend only on duali-data I really don't know what to do so i thought about asking here for help. The plan you outlined seems quite sensible to me. - Keegan Many thanks for replying to me. i think now that i should try and talk to the author again ;-) -- -- Katoob Main Developer Linux registered user # 224950 ICQ # 58475622 FIRST make it run, THEN make it run fast Brian Kernighan. -- Don't send me any attachment in Micro$oft (.DOC, .PPT) format please Read http://www.fsf.org/philosophy/no-word-attachments.html Preferable attachments: .PDF, .HTML, .TXT Thanx for adding this text to Your signature pgpJHInFjjpeO.pgp Description: PGP signature
favicon resource
Hi! I was just looking for a 'open use' debian favicon. But i can't find it on http://www.debian.org/logos/index.en.html Is it ok to use the resource from http://www.debian.org/favicon.ico ? Shouldn't it also be published on the logo page? Regards Henning
Bug#198665: ITP: pmk -- The pmk project aims to be an alternative to GNU/autoconf (configure scripts).
Package: wnpp Version: unavailable; reported 2003-06-24 Severity: wishlist * Package name: pmk Version : 0.4.5 Upstream Author : Damien Couderc Xavier Santolaria * URL : http://premk.sf.net/ * License : BSD Description : The pmk project aims to be an alternative to GNU/autoconf (configure scripts). First a quote from the about page for the project: Our primary goals are : * Avoid the use of scripts in packages that can hide trojans. * Try to keep the needed dependancies near from zero (actually we're at zero). * Make it easy to use for users and developpers. * Provide the package in a free and usable license for everybody (BSD). Their goals seem to be met so far. The whole thing is written in C, doesn't depend on perl/m4/shell etc., it's rather easy to use featuring a simple config file format, autoconf compatibility (output-wise), is supported on quite a few software platforms (including Debian). The system defaults are configured in a global config file which makes the usage pretty consistent accross all the installations. -- System Information: Debian Release: testing/unstable Architecture: i386 Kernel: Linux beowulf 2.5.73-mm1 #1 Tue Jun 24 15:31:14 CEST 2003 i686 Locale: LANG=pl_PL, LC_CTYPE=pl_PL
Re: [mass bug filing?] Short descriptions being used as long descriptions and other policy violations
On Tue, Jun 24, 2003 at 06:41:21PM +0200, Thomas Viehmann wrote: Johannes Rohr wrote: I'd say that writing a meaningful package description is certainly the duty of the individual package maintainer. A package maintainer should usually have an idea of what his/her package is good for, while Javier would probably have to spend a lot more time to figure that out, at least for lesser known packages. However, not providing a better description will (likely) not get anything done. First, my guess is that it will be more effective than seem to imply. Second, pointing out bugs without fixes is certainly what the bug tracking system facilitates. I don't think that filing a bug saying that Your extended package description does not meet Debian policy requirements. Please consider writing 4-5 lines to give sysadmins an idea what your package can do for them. means asking too much from a Debian maintainer. You don't. But I can't help but think that there are a lot of obvious maintainer's duties more or less neglected - often by simple obmission, but sometimes patterns show. Often, as in this case, those lapses in obvious (and documented) maintainer duties, constitute bugs in a package. Maybe I'm misunderstanding something in your argument here. Regards, Mako -- Benj. Mako Hill [EMAIL PROTECTED] http://mako.yukidoke.org/ pgpMck5SBQbc0.pgp Description: PGP signature
Re: Bug#198665: ITP: pmk -- The pmk project aims to be an alternative to GNU/autoconf (configure scripts).
On Tue, Jun 24, 2003 at 09:30:31PM +0200, Marek Habersack wrote: [...] Description : The pmk project aims to be an alternative to GNU/autoconf (configure scripts). Description field is inappropriate, use something like: Description: A GNU/autoconf alternative. ciao, -- Luca - De Whiskey's - De Vitis | Elegant or ugly code as well aliases: Luca ^De [A-Z][A-Za-z\-]*[iy]'\?s$ | as fine or rude sentences have Luca, a wannabe ``Good guy''. | something in common: they local LANG=[EMAIL PROTECTED] | don't depend on the language.
Re: Bug#198665: ITP: pmk -- The pmk project aims to be an alternative to GNU/autoconf (configure scripts).
On Tue, Jun 24, 2003 at 02:44:17PM -0500, Luca - De Whiskey's - De Vitis scribbled: On Tue, Jun 24, 2003 at 09:30:31PM +0200, Marek Habersack wrote: [...] Description : The pmk project aims to be an alternative to GNU/autoconf (configure scripts). Description field is inappropriate, use something like: Description: A GNU/autoconf alternative. Good point. I just cut and pasted it from their about page out of laziness :) thanks, marek pgpEEQwotSBt8.pgp Description: PGP signature
Re: Bug#198665: ITP: pmk -- The pmk project aims to be an alternative to GNU/autoconf (configure scripts).
On Tue, Jun 24, 2003 at 02:44:17PM -0500, Luca - De Whiskey's - De Vitis wrote: On Tue, Jun 24, 2003 at 09:30:31PM +0200, Marek Habersack wrote: [...] Description : The pmk project aims to be an alternative to GNU/autoconf (configure scripts). Description field is inappropriate, use something like: Description: A GNU/autoconf alternative. Try an alternative to GNU autoconf or a substitute for GNU autoconf, to avoid confusion with Debian's alternatives system. -- Steve Langasek postmodern programmer pgpXrPRquyWJ3.pgp Description: PGP signature
Re: [mass bug filing?] Short descriptions being used as long descriptions and other policy violations
Josip Rodin wrote: On Tue, Jun 24, 2003 at 06:41:21PM +0200, Thomas Viehmann wrote: I'd say that writing a meaningful package description is certainly the duty of the individual package maintainer. A package maintainer should usually have an idea of what his/her package is good for, while Javier would probably have to spend a lot more time to figure that out, at least for lesser known packages. However, not providing a better description will (likely) not get anything done. You don't know that. If we agreed to such a sweeping generalization, we would not have the vast majority of bug reports in the BTS. Admittedly, I don't know that. Only one way to find out. Cheers T. pgpTI9QfTmq27.pgp Description: PGP signature
Re: Bug#198665: ITP: pmk -- The pmk project aims to be an alternative to GNU/autoconf (configure scripts).
On Tue, Jun 24, 2003 at 09:46:52PM +0200, Marek Habersack wrote: On Tue, Jun 24, 2003 at 02:44:17PM -0500, Luca - De Whiskey's - De Vitis scribbled: On Tue, Jun 24, 2003 at 09:30:31PM +0200, Marek Habersack wrote: [...] Description : The pmk project aims to be an alternative to GNU/autoconf (configure scripts). Description field is inappropriate, use something like: Description: A GNU/autoconf alternative. Good point. I just cut and pasted it from their about page out of laziness :) That's inappropriate as well. Rather than saying this is an alternative to foo, say what it does, and then say similar to foo. thanks, marek
Re: Packages: an average 66321 bytes per line of description
On Tue, Jun 24, 2003 at 07:17:58PM +0200, Torsten Landschoff wrote: the worst culprits are usually sets of binary packages from the one source file which have package descriptions like libfoo-dev = dev files for libfoo, libfoo-doc = documention for libfoo, and libfoo = runtime files for foo library, without bothering to describe what foo actually is. well, duh! like nobody would ever guess that a package called libfoo-doc was the documentation for libfoo. tell the reader something we DON'T know. But he knows what libfoo is - or at least he is just a $ apt-cache show libfoo away from that information. Do we need to duplicate the description of a library package in each and every supporting package? Not all of it, but you can't object to duplicating a single sentence saying what it is. -- 2. That which causes joy or happiness.
Re: Please don't misuse the debian/changelog to close bugs!
On Tue, Jun 24, 2003 at 01:23:25PM +0200, Gerfried Fuchs wrote: Alright, this happened far too often lately to be ignored. This must stop, pretty please. The developers-reference[1] isn't written just for fun. [snip] /me stands up _ _ _ _ _ / \ _ __ ___ ___ _ __ | |__ _ __ ___ | |_| |__ ___ _ __| | / _ \ | '_ ` _ \ / _ \ '_ \| '_ \| '__/ _ \| __| '_ \ / _ \ '__| | / ___ \| | | | | | __/ | | |_ | |_) | | | (_) | |_| | | | __/ | |_| /_/ \_\_| |_| |_|\___|_| |_( ) |_.__/|_| \___/ \__|_| |_|\___|_| (_) |/ -- G. Branden Robinson| You live and learn. Debian GNU/Linux | Or you don't live long. [EMAIL PROTECTED] | -- Robert Heinlein http://people.debian.org/~branden/ | pgpxiNYmo9Zke.pgp Description: PGP signature
Re: [mass bug filing?] Short descriptions being used as long descriptions and other policy violations
Benj. Mako Hill wrote: I don't think that filing a bug saying that Your extended package description does not meet Debian policy requirements. Please consider writing 4-5 lines to give sysadmins an idea what your package can do for them. means asking too much from a Debian maintainer. You don't. But I can't help but think that there are a lot of obvious maintainer's duties more or less neglected - often by simple obmission, but sometimes patterns show. Often, as in this case, those lapses in obvious (and documented) maintainer duties, constitute bugs in a package. Maybe I'm misunderstanding something in your argument here. My argument was based on a matrix lintian error tags - maintainers. There's lintian tags practically owned by maintainers. That's what I meant with patterns. In those cases, pointing things out directly will help more. In some cases, description deficiencies may be related to English skills (I'm not a native speaker myself). In those cases patches can achieve much more than bugs without patches. Cheers T. pgpxwD0sISNKF.pgp Description: PGP signature
Re: Bug#198665: ITP: pmk -- The pmk project aims to be an alternative to GNU/autoconf (configure scripts).
On Tue, Jun 24, 2003 at 02:52:20PM -0500, Steve Langasek scribbled: On Tue, Jun 24, 2003 at 02:44:17PM -0500, Luca - De Whiskey's - De Vitis wrote: On Tue, Jun 24, 2003 at 09:30:31PM +0200, Marek Habersack wrote: [...] Description : The pmk project aims to be an alternative to GNU/autoconf (configure scripts). Description field is inappropriate, use something like: Description: A GNU/autoconf alternative. Try an alternative to GNU autoconf or a substitute for GNU autoconf, to avoid confusion with Debian's alternatives system. It's not quite a substitute, as it won't reuse autoconf's configs etc. How about A tool for configuring software source similar to GNU Autoconf? marek pgpfTbKKcA2ES.pgp Description: PGP signature
Re: Update re: read-only root filesystem
Hello
On Sat, Jun 21, 2003 at 01:12:20PM +0200, Thomas Hood wrote:
Some progress has been made toward the goal of making
Debian easier to use with a read-only root filesystem.
Action has been taken to remove variable files from /etc/,
or at least to make it possible to do so locally, in the
following packages: cupsys, laptop-net, pppconfig, sysvinit.
Packages that still employ variable files in /etc/ include:
mount, ifupdown, dhcpcd, linuxlogo, ppp, util-linux.
Fortunately, some of the files can be replaced by symlinks.
See my README file at
http://panopticon.csustan.edu/thood/readonly-root.html
for (incomplete) information.
Many thanks to the maintainers who have been supporting
this effort.
Thanks a lot. I'll refer to that in the nfsboot{ed,} packages.
They just have some rudimental things.
It is possible to make a package that does all this things for
you?
Like a root-read-only package?
Regards,
// Ola
--
Thomas Hood
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
--
- Ola Lundqvist ---
/ [EMAIL PROTECTED] Annebergsslingan 37 \
| [EMAIL PROTECTED] 654 65 KARLSTAD |
| +46 (0)54-10 14 30 +46 (0)70-332 1551 |
| http://www.opal.dhs.org UIN/icq: 4912500 |
\ gpg/f.p.: 7090 A92B 18FE 7994 0C36 4FE4 18A1 B1CF 0FE5 3DD9 /
---
Re: Packages: an average 66321 bytes per line of description
On Tue, Jun 24, 2003 at 10:41:59PM +0200, Josip Rodin wrote: On Tue, Jun 24, 2003 at 07:17:58PM +0200, Torsten Landschoff wrote: the worst culprits are usually sets of binary packages from the one source file which have package descriptions like libfoo-dev = dev files for libfoo, libfoo-doc = documention for libfoo, and libfoo = runtime files for foo library, without bothering to describe what foo actually is. well, duh! like nobody would ever guess that a package called libfoo-doc was the documentation for libfoo. tell the reader something we DON'T know. But he knows what libfoo is - or at least he is just a $ apt-cache show libfoo away from that information. Do we need to duplicate the description of a library package in each and every supporting package? Not all of it, but you can't object to duplicating a single sentence saying what it is. When the sentence in question is the one that goes in the short description, and already fills the available space without prepending runtime files for foo ? Is the concern here with the short descs (I don't expect much from short descs of affiliate packages), or with the long descs? -- Steve Langasek postmodern programmer pgpF1u9eloX6p.pgp Description: PGP signature
Re: [mass bug filing?] Short descriptions being used as long descriptions and other policy violations
On Mon, Jun 23, 2003 at 03:25:23PM -0500, Adam Heath wrote:
Use ${description}, and debian/substvars. This is already supported.
RTFM.
is there FM in the form of an example package? or can you
think of a method of finding packages that use this
technique?
dpkg-souce(1) implies that substitution variables are
limited to a single line (which seems poorly suited to long
descriptions). An example would likely clear this up
easily.
thanks,
-neil
Re: Developer Accessible Hurd Machine
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Benj. Mako Hill [EMAIL PROTECTED] writes: Some time ago, Martin Schulze pointed out that there is no developer accessible Hurd machine available. I am happy to coordinate the donation of hardware for this if it is this something that you (developers, Hurd and otherwise) feel would be useful and possible? However, I've heard that Hurd is still unstable enough that we will probably need to place the machine at a Hurd developer's home or work. -devel: Is this something developers would like? I'd like to see something like this happening. I've already wanted a developer accessible Hurd machine several times, for investigating the possibility to port some of my packages. I think such a machine would be valuable to increase the quality of the Hurd port overall. Most of my packages do never get built on hurd, although that might actually be related to a lack of buildds? - -- CYa, Mario -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.2 (GNU/Linux) Comment: Processed by Mailcrypt 3.5.8 http://mailcrypt.sourceforge.net/ iD8DBQE++MLI3/wCKmsRPkQRAjlWAJ9zAMgaML0MueADLfHiDijYRqRKXQCfRymO 1XALGh626gJQkT3KHV+SgYk= =EKkC -END PGP SIGNATURE-
Re: Bug#198665: ITP: pmk -- The pmk project aims to be an alternative to GNU/autoconf (configure scripts).
On Tue, Jun 24, 2003 at 10:59:19PM +0200, Marek Habersack wrote: On Tue, Jun 24, 2003 at 02:52:20PM -0500, Steve Langasek scribbled: On Tue, Jun 24, 2003 at 02:44:17PM -0500, Luca - De Whiskey's - De Vitis wrote: On Tue, Jun 24, 2003 at 09:30:31PM +0200, Marek Habersack wrote: [...] Description : The pmk project aims to be an alternative to GNU/autoconf (configure scripts). Description field is inappropriate, use something like: Description: A GNU/autoconf alternative. Try an alternative to GNU autoconf or a substitute for GNU autoconf, to avoid confusion with Debian's alternatives system. It's not quite a substitute, as it won't reuse autoconf's configs etc. How about A tool for configuring software source similar to GNU Autoconf? That seems sensible. -- Steve Langasek postmodern programmer pgpf3PbZOw2hz.pgp Description: PGP signature
Bug#198682: ITP: kernel-patch-2.4-low-latency -- Reduces the latency of the Linux kernel
Package: wnpp Version: unavailable; reported 2003-06-25 Severity: wishlist * Package name: kernel-patch-2.4-low-latency Upstream Author : Andrew Morton [EMAIL PROTECTED] * URL : http://www.zip.com.au/~akpm/linux/schedlat.html * License : GPL Description : Reduces the latency of the Linux kernel This patch adds a far greater degree of real-time responsiveness to the standard Linux kernel, by finding hot spots in the scheduling code and trying to reduce their impact. It can get latencies down to 1 to 4 ms in most situations. It can be applied to the following Linux kernel sources: 2.4.13, 2.4.14, 2.4.15, 2.4.16, 2.4.17, 2.4.18, 2.4.19, 2.4.20 and 2.4.21. -- System Information: Debian Release: testing/unstable Architecture: i386 Kernel: Linux pc.aurel32 2.4.20 #1 mar jun 24 21:29:28 CEST 2003 i686 Locale: [EMAIL PROTECTED], [EMAIL PROTECTED] (ignored: LC_ALL set)
Re: Bug#198665: ITP: pmk -- The pmk project aims to be an alternative to GNU/autoconf (configure scripts).
On Tue, Jun 24, 2003 at 10:59:19PM +0200, Marek Habersack wrote: It's not quite a substitute, as it won't reuse autoconf's configs etc. How about A tool for configuring software source similar to GNU Autoconf? I see your point, but your suggestion is still too long: it should be rephrased to stay within 60-65 characters. What about A source configuring tool like GNU/Autoconf? ciao, -- Luca - De Whiskey's - De Vitis | Elegant or ugly code as well aliases: Luca ^De [A-Z][A-Za-z\-]*[iy]'\?s$ | as fine or rude sentences have Luca, a wannabe ``Good guy''. | something in common: they local LANG=[EMAIL PROTECTED] | don't depend on the language. pgp17SXQXTPUn.pgp Description: PGP signature
Old bugs related to translated debconf templates
Hi, Here is a list of bugs older than a year; most of them are related to translated debconf templates, so fixing them is trivial and I might NMU some of these packages soon. #BRDate Package Maintainer 103324 (03 Jul 2001) diald Jeff Licquia 106150 (21 Jul 2001) nis Miquel van Smoorenburg 107023 (29 Jul 2001) kdm Christopher L Cheney 107730 (06 Aug 2001) diald Jeff Licquia 110178 (26 Aug 2001) postfix LaMont Jones 116433 (21 Oct 2001) gnapsterDebian QA Group 128933 (12 Jan 2002) kdm Christopher L Cheney 132615 (06 Feb 2002) kdm Christopher L Cheney 134460 (17 Feb 2002) arla-modules-source Mikael Andersson 134506 (18 Feb 2002) fcron Russell Coker 135965 (27 Feb 2002) xfree86v3 Branden Robinson 136919 (05 Mar 2002) arla-modules-source Mikael Andersson 137613 (10 Mar 2002) arla-modules-source Mikael Andersson 137637 (10 Mar 2002) diffmon Jeff Bailey 137648 (10 Mar 2002) fonty Piotr Roszatycki 137652 (10 Mar 2002) gnapsterDebian QA Group 137655 (10 Mar 2002) gnome-pilot Mike Markley 137658 (10 Mar 2002) htdig Robert Ribnitz 137662 (10 Mar 2002) hwtools Christoph Lameter 137663 (10 Mar 2002) interchange-ui Stefan Hornburg 137690 (10 Mar 2002) taper Piotr Roszatycki 137698 (10 Mar 2002) vflib2 Masato Taruishi 137707 (10 Mar 2002) xtelEric Delaunay 137940 (12 Mar 2002) kdm Christopher L Cheney 138321 (14 Mar 2002) aeromailJim Studt 140888 (02 Apr 2002) aideMike Markley 142540 (12 Apr 2002) kdm Christopher L Cheney 148086 (25 May 2002) mozilla-browser Takuo KITAME Denis
Re: Bug#198665: ITP: pmk -- The pmk project aims to be an alternative to GNU/autoconf (configure scripts).
On Tue, Jun 24, 2003 at 10:59:19PM +0200, Marek Habersack wrote: It's not quite a substitute, as it won't reuse autoconf's configs etc. How about A tool for configuring software source similar to GNU Autoconf? Sorry for my previous reply to this message, your suggestion is definitely good. ciao, -- Luca - De Whiskey's - De Vitis | Elegant or ugly code as well aliases: Luca ^De [A-Z][A-Za-z\-]*[iy]'\?s$ | as fine or rude sentences have Luca, a wannabe ``Good guy''. | something in common: they local LANG=[EMAIL PROTECTED] | don't depend on the language. pgpYTsqJvgowt.pgp Description: PGP signature
Re: Bug#198665: ITP: pmk -- The pmk project aims to be an alternative to GNU/autoconf (configure scripts).
On Tue, Jun 24, 2003 at 10:59:19PM +0200, Marek Habersack wrote: On Tue, Jun 24, 2003 at 02:52:20PM -0500, Steve Langasek scribbled: On Tue, Jun 24, 2003 at 02:44:17PM -0500, Luca - De Whiskey's - De Vitis wrote: On Tue, Jun 24, 2003 at 09:30:31PM +0200, Marek Habersack wrote: [...] Description : The pmk project aims to be an alternative to GNU/autoconf (configure scripts). Description field is inappropriate, use something like: Description: A GNU/autoconf alternative. Try an alternative to GNU autoconf or a substitute for GNU autoconf, to avoid confusion with Debian's alternatives system. It's not quite a substitute, as it won't reuse autoconf's configs etc. How about A tool for configuring software source similar to GNU Autoconf? No, actually, that is ambiguous. Read literally, it means that only software source similar to GNU Autoconf can be configured with this tool. You really mean: A tool, similar to GNU Autoconf, for configuring software Admittedly this is ugly. It may also be really inaccurate. I have no idea of how similar to GNU Autoconf the tool is. I hope that it is not very similar at all. Perhaps: A tool to configure software (GNU Autoconf also has this purpose) Jim Penny
Re: [mass bug filing?] Short descriptions being used as long descriptions and other policy violations
On Tue, Jun 24, 2003 at 02:25:03PM -0700, Neil Spring [EMAIL PROTECTED] was
heard to say:
dpkg-souce(1) implies that substitution variables are
limited to a single line (which seems poorly suited to long
descriptions).
Then as long as the shared part is a single paragraph you should be fine.
Actually, it looks like you could use ${Newline} and friends to
include multiple lines (I haven't tried this myself, though)
Daniel
--
/ Daniel Burrows [EMAIL PROTECTED] ---\
|After the game, the king and |
|the pawn go in the same box. |
| -- Italian proverb |
\--- (if (not (understand-this)) (go-to http://www.schemers.org)) /
Re: Packages: an average 66321 bytes per line of description
On Tue, Jun 24, 2003 at 04:15:29PM -0500, Steve Langasek [EMAIL PROTECTED] was heard to say: Not all of it, but you can't object to duplicating a single sentence saying what it is. When the sentence in question is the one that goes in the short description, and already fills the available space without prepending runtime files for foo ? Is the concern here with the short descs (I don't expect much from short descs of affiliate packages), or with the long descs? Long descriptions. See, eg, bnlib1-dev (not the problem discussed above, but still has problems with its description) imlib1-dev libast2-dev libcdaudio0-dev libcelsius-dev libchipcard20-dev Daniel -- / Daniel Burrows [EMAIL PROTECTED] ---\ | I haven't lost my mind, | | I know exactly where I left it. | \-Evil Overlord, Inc: planning your future today. http://www.eviloverlord.com-/
kernel 2.5.73+, fakeroot, debuild - a small problem
Hey list, Running debuild as normal user under the 2.5.73+ kernel results in fakeroot actually setting the file ownership to root (or any other uid/gid for that matter). The result is that the parts which don't run under fakeroot - e.g. debian/rules won't be able to write to the debian/packagename/ subdirs sometimes. It happens only when the filesystem on which the build is taking place is XFS. This is due to the restrict_chown sysctl which was present in XFS before but never actually implemented. Starting with 2.5.73 XFS does use the setting which works in the way that allows the owner of the directory to give away its subdirectories/files to other users. If restrict_chown is enabled then the old behavior is back, however it defaults to disabled. The problem will affect any situation which involves using fakeroot or other similar packages. I see several solutions to that problem, but none of them seem perfect: 1. Warn the users about the above issue and have them always use fakeroot explicitly in situations like building a deb. This is the worst solution, I think, as it would require all of the debian source packages to be modified. 2. Modify fakeroot to check the kernel version, the type of fs on which it is currently working and have it issue a sysctl to enable restricted_chown. It looks better than #1 but it might incurr performance penalty. OTOH, this solution would be the most painless for the users and the most seamless. 3. Modify debuild or even dpkg-buildpackage to do what fakeroot would do in #2. It would be a partial solution since it would affect only the deb build process. 4. Add code to /etc/init.d/ (mountfs.sh or mountall.sh) to perform the checks from #2 and enable the restricted chown. This would be the most global solution effectively setting a policy for Debian systems. It would have the additional effect of maintaining consistency with the old behavior and other filesystems. 5. Influence the XFS/kernel maintainers to change the default value of restrict_chown to enabled. Comments? marek pgpLJr1EiKlFD.pgp Description: PGP signature
Re: Bug#198665: ITP: pmk -- The pmk project aims to be an alternative to GNU/autoconf (configure scripts).
On Tue, Jun 24, 2003 at 05:14:56PM -0500, Luca - De Whiskey's - De Vitis scribbled: On Tue, Jun 24, 2003 at 10:59:19PM +0200, Marek Habersack wrote: It's not quite a substitute, as it won't reuse autoconf's configs etc. How about A tool for configuring software source similar to GNU Autoconf? Sorry for my previous reply to this message, your suggestion is definitely good. OK, so if there are no more objections, I will proceed with uploading the tool to Debian RSN :) marek pgp4pJwGjpJeA.pgp Description: PGP signature
Re: Bug#198665: ITP: pmk -- The pmk project aims to be an alternative to GNU/autoconf (configure scripts).
On Tue, Jun 24, 2003 at 10:59:19PM +0200, Marek Habersack [EMAIL PROTECTED] was heard to say: On Tue, Jun 24, 2003 at 02:52:20PM -0500, Steve Langasek scribbled: Try an alternative to GNU autoconf or a substitute for GNU autoconf, to avoid confusion with Debian's alternatives system. It's not quite a substitute, as it won't reuse autoconf's configs etc. How about A tool for configuring software source similar to GNU Autoconf? Ugh. That's awfully wordy. I don't think there's that much danger of confusion with the alternatives system, and IMO the slight risk is outweighed by how cumbersome the sentence above is. I think an alternative to GNU autoconf is a better choice. Daniel -- / Daniel Burrows [EMAIL PROTECTED] ---\ | The spork is strong with him... -- Fluble | \- Debian GNU/Linux http://www.debian.org -- Because. /
Re: Bug#198665: ITP: pmk -- The pmk project aims to be an alternative to GNU/autoconf (configure scripts).
On Tue, Jun 24, 2003 at 06:21:18PM -0400, Jim Penny scribbled: [snip] Description field is inappropriate, use something like: Description: A GNU/autoconf alternative. Try an alternative to GNU autoconf or a substitute for GNU autoconf, to avoid confusion with Debian's alternatives system. It's not quite a substitute, as it won't reuse autoconf's configs etc. How about A tool for configuring software source similar to GNU Autoconf? No, actually, that is ambiguous. Read literally, it means that only software source similar to GNU Autoconf can be configured with this True tool. You really mean: A tool, similar to GNU Autoconf, for configuring software Admittedly this is ugly. It may also be really inaccurate. I have no idea of how similar to GNU Autoconf the tool is. I hope that it is not very similar at all. Not in the way it works, but similar in the function it performs. Perhaps: A tool to configure software (GNU Autoconf also has this purpose) It lacks 'source' which would be a misinformation, maybe: A tool to configure software source, functional equivalent to GNU Autoconf Exactly 75 chars and quite to the point, IMHO. marek pgp5de9q69GdB.pgp Description: PGP signature
Re: Developer Accessible Hurd Machine
On Tue, Jun 24, 2003 at 11:30:26PM +0200, Mario Lang wrote: I think such a machine would be valuable to increase the quality of the Hurd port overall. Maybe. But also keep in mind that porting to GNU/Hurd is a bit more complicated than porting to just another Linux architecture, because of some things GNU/Hurd does differently, see http://hurd.gnufans.org/bin/view/Distrib/PortingIssues Most of my packages do never get built on hurd, although that might actually be related to a lack of buildds? That probably the case, the buildd is not running at the moment :) I build important packages (like the toolchain) infrequently though. Anyway, you can still try to install the Hurd yourself on a free partition, for example using the crosshurd package. Most people have an i386, so it's just a matter of perhaps freeing some disk-space and reading the docs. If it doesn't work with your hardware or you run into big problems, you will not have lost a lot of time. See http://hurd.gnu.org and http://hurd.gnufans.org for further information. Michael
Re: EPSON appreciates your feedback by June 30, '03 - Debian
Dear Julien, Thank you for responding to my email. We understand the existing issues which you have explained below and to make this more clear is that EPSON Kowa handles the License agreement. We have nothing to do with the licensing agreement for the Image Scan! for Linux. We're sure that there are reasons behind it since Linux is an open source. However, if you are still interested and would like to discuss this further, please contact EPSON Kowa directly. We appreciate if you could cc: us on the communication between yourself and EPSON Kowa. It is indeed a pleasure getting to know you and please feel free to contact me at anytime. We will do our best to help. http://www.epkowa.co.jp/english/linux_e/lsd_dwn_e.html You may use the software subject to the three licenses below depending on configured module. GNU General Public License GNU Lesser General Public License EPSON KOWA Public License Best regards, Farideh Sherbaf (Ms.) Sr. Product Engineer EPSON Worldwide Developer Relations 150 River Oaks Parkway, Suite #200 San Jose, CA 95134 Tel: 408-576-4135 Fax: 408-474-0511 E-mail: [EMAIL PROTECTED] ~~~ - Original Message - From: Julien BLACHE [EMAIL PROTECTED] To: Farideh Sherbaf [EMAIL PROTECTED] Cc: debian-project@lists.debian.org; debian-devel@lists.debian.org Sent: Tuesday, June 24, 2003 3:05 AM Subject: Re: EPSON appreciates your feedback by June 30, '03 - Debian [Ob-lists: if replying publicly, please reply to -devel only] Farideh Sherbaf [EMAIL PROTECTED] wrote: Dear Linux Developer and Distributor, Hi, Please allow me to introduce myself. My name is Farideh Sherbaf and I am your contact for EPSON Worldwide Developer Relations for scanners and All-In-One (Multifunction) products. The EPSON Developer Relations Group would like to obtain your feedback on your support of scanners in the Linux environment. I am the maintainer of the SANE packages in the Debian distribution ; nice to see some communication from Epson Kowa ! SANE maintainer hat on Your prompt answers to the following questions are appreciated (Yes/No): 1. Do you include the SANE backend (scanner driver) within your Linux distribution package? Yes. This is a must-have for any Linux distribution that wants to be used on the desktop. 2. Which SANE frontends (applications) do you include within your Linux distribution package? The standard frontends from the SANE project are available (scanimage, scanadf, xscanimage, xcam, saned), along with XSane, QuiteInsane and Kooka. 3. Do you include Epson's Image Scan! for Linux? (Image Scan! for Linux is a graphical frontend for Epson scanners.) No. Although further explanation does not seem to be requested by your survey, let me explain why the Epson Kowa backend and frontend aren't included in Debian. To be included in the Debian distribution, a software basically needs to fulfill 2 conditions : - its license must be considered Free by Debian (see [1] for details) - somebody has to volunteer to maintain the packages The latter would probably be no problem for the Epson Kowa softwares if the former point was fulfilled. The Epson Kowa Public License that covers the distribution of the Epson Kowa softwares isn't Free ; it forbids reverse-engineering or any form of analysis of the binary-only modules that ship with the software. This is the first showstopper. The second one is that the source distribution ships binary-only modules, which makes it impossible to build the softwares for anything else than Linux/x86 ; in its latest release, Debian supports 11 hardware architectures, and portability is something very important for us. We have a special section in our archive for softwares that do not meet our requirements in terms of license, but are nonetheless freely redistributable and potentially useful to our users ; it's the non-free section. Should somebody be willing to maintain packages of the Epson Kowa softwares, they could be included in the non-free section. However, note that the non-free section isn't distributed on the release CDs. Now, apart from this, looking at my 6-months-old notes on the subject, it seems that the scanners supported by the Epson Kowa backend are already supported (to some point) by the regular SANE backends. The same applies to the frontend, with the powerful frontends already available. Again, my notes are somewhat dated by now, so feel free to correct me if I'm wrong on this point. Feel free to contact me if you have any questions. Regards, JB. [1] http://www.debian.org/doc/debian-policy/ch-archive.html#s2.1.1 -- 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: Packages: an average 66321 bytes per line of description
On Tue, Jun 24, 2003 at 04:15:29PM -0500, Steve Langasek wrote: On Tue, Jun 24, 2003 at 10:41:59PM +0200, Josip Rodin wrote: On Tue, Jun 24, 2003 at 07:17:58PM +0200, Torsten Landschoff wrote: the worst culprits are usually sets of binary packages from the one source file which have package descriptions like libfoo-dev = dev files for libfoo, libfoo-doc = documention for libfoo, and libfoo = runtime files for foo library, without bothering to describe what foo actually is. well, duh! like nobody would ever guess that a package called libfoo-doc was the documentation for libfoo. tell the reader something we DON'T know. But he knows what libfoo is - or at least he is just a $ apt-cache show libfoo away from that information. Do we need to duplicate the description of a library package in each and every supporting package? not much use when you're in dselect, wondering what foo is and whether it's a good or useful thing to install. also not much use when the description for libfoo just says runtime files for foo, and none of the other obviously associated packages bother to describe it either. the person who packages it knows what it is, but he/she has to assume that the reader doesn't and should therefore provide a brief but useful description. not everyone catches every single announcement on slashdot or freshmeat or sourceforge, not everyone is fully aware of every project in every niche. Not all of it, but you can't object to duplicating a single sentence saying what it is. When the sentence in question is the one that goes in the short description, and already fills the available space without prepending runtime files for foo ? Is the concern here with the short descs (I don't expect much from short descs of affiliate packages), or with the long descs? the concern is with package descriptions that assume that the reader knows what foo is. just having a brief description in one of 3 or 4 or more packages (and some i've seen don't even bother describing it in one) isn't good enough. each individual package needs that brief description. craig
Re: maildirmake
On Tue, Jun 24, 2003 at 08:19:35AM +0200, Andreas Metzler wrote: You could start by telling us what maildirmake is supposed to do. Why do we need it? Any program I know of which can handle Maildir is not only capable of storing messages in Maildir folders but also of generating them. This includes e.g. the exim(4) MTA, MDAs like procmail or maildrop, and the MUA mutt. As far as I am aware, maildrop does *not* support creating Maildirs. Even if it does support creating top level Maildir (last I tested it didn't seem to), it doesn't support creating a maildir within a maildir (this apparently is a bit different, and it used by courier-imap). You do with with maildirmake (or at least the version I have installed) with the -f option. See bug #68685 for details. -- Brian May [EMAIL PROTECTED]
Re: Bug#198602: ITP: debbackup -- Backup and restore Debian specifics (package status, conffiles)
On Tue, Jun 24, 2003 at 11:15:42AM -0700, Keegan Quinn wrote: On Tuesday 24 June 2003 10:59 am, Emile van Bergen wrote: Hi, On Tue, Jun 24, 2003 at 11:44:51AM -0500, Adam Heath wrote: Tell me when you upload this, so I can file an rc bug against it, for modifying other packages conffiles. *g* 5 serious replies already -- sorry Adam, I'm afraid there are just too many people that lack even the most basic sense of humour. Or perhaps not everyone thinks a threat of an RC bug is a laughing matter. Sure, people who have sticks up their arses don't. Mocking them is great fun. -- .''`. ** Debian GNU/Linux ** | Andrew Suffield : :' : http://www.debian.org/ | Dept. of Computing, `. `' | Imperial College, `- -- | London, UK pgpDxIcyo6AJZ.pgp Description: PGP signature
Re: Packages: an average 66321 bytes per line of description
avg. bytes per description lines 66321.8 A Is that just a meaningless number, or is there actually a correlation A between package size and description length? Somebody with statistics experience might go further and see if little packages have big descriptions and visa versa etc. Anyway, one liner snob descriptions just have to go. $ apt-cache show emacs21 Description: The GNU Emacs editor GNU Emacs is the extensible self-documenting text editor. Oops, I see, it is self-documenting.
Re: Packages: an average 66321 bytes per line of description
On Wed, Jun 25, 2003 at 07:07:46AM +0800, Dan Jacobson wrote: Anyway, one liner snob descriptions just have to go. $ apt-cache show emacs21 Description: The GNU Emacs editor GNU Emacs is the extensible self-documenting text editor. Oops, I see, it is self-documenting. that's actually a perfectly adequate description. it tells someone who has never heard of emacs before that it is an editor. good enough. a description doesn't have to (and shouldn't!) summarise all of a package's features, all it needs to do is give someone a rough idea of what kind of beastie it is. for a package like emacs, it's basically impossible to summarise all of its features anyway. craig
Re: maildirmake
On Tue, 24 Jun 2003, Marcelo E. Magallon wrote: My logic was that, from the basic system, Maildir mailboxes are no use. Can I have a bit of the weed you are smoking? Seems to be good. They're pine needles. I really do need to get off them, they're keeping my brain in the 70's... inertia can be hard to beat... Yes, I now know that decent MUAs can handle Maildir locally, so I'd like to remove my objection to putting maildirmake in the base system. Debianutils seems like the place for it to go, since there are other not-really-debian-specific utils in there already, although my aesthetic antennae are twitching... -- --- #include disclaimer.h Matthew Palmer, Geek In Residence http://ieee.uow.edu.au/~mjp16
Re: kernel 2.5.73+, fakeroot, debuild - a small problem
On Tue, 2003-06-24 at 18:34, Marek Habersack wrote: 5. Influence the XFS/kernel maintainers to change the default value of restrict_chown to enabled. I think they really should do this. Having people be able to give away files is something that you usually *don't* want by default. If they give away a file in XFS, does it still count against their quota?
Re: Packages: an average 66321 bytes per line of description
I demand that Dan Jacobson may or may not have written... I was hoping that maintainers of multi-megabyte packages would do the package justice by giving an adequate description. I have here a 20K package. Should it have a 1/3-line description? ;-) -- | Darren Salt | nr. Ashington, | linux (or ds) at | woody, sarge, | Northumberland | youmustbejoking | RISC OS | Toon Army | demon co uk | Retrocomputing: a PC card in a Risc PC B Integer out of range, 0:1
Re: kernel 2.5.73+, fakeroot, debuild - a small problem
On Tue, Jun 24, 2003 at 09:17:36PM -0400, Colin Walters scribbled: On Tue, 2003-06-24 at 18:34, Marek Habersack wrote: 5. Influence the XFS/kernel maintainers to change the default value of restrict_chown to enabled. I think they really should do this. Having people be able to give away files is something that you usually *don't* want by default. Indeed. I'm wondering what's the reason for that option. If they give away a file in XFS, does it still count against their quota? Not from what I see. It seems that the quota is updated. Now that can be a nice way to hog somebody else's quota... marek pgpeHX9WdOdY2.pgp Description: PGP signature
Re: Please don't misuse the debian/changelog to close bugs!
Gerfried Fuchs [EMAIL PROTECTED] wrote:
During some of the discussions lately on debian-devel another usage of
the changelog has risen interest:
* New upstream release (closes: #123, #124, #125)
This has also raised some discussions. The thing is this: If #123,
#124 and #125 aren't just New upstream version available bugreports
then quite some people dislike this behavior. It shouldn't be too much
hazzle for the maintainer to rewrite this as follows:
I strongly disagree with your view. Please respond to my points
that have been raised previously rather than repeating this dogma.
* New upstream release (closes: #123) which includes:
- tmpfile race condition fix (closes: #124)
- manual page included (closes: #125)
The thing is: It helps the users and the person who reported the bug to
see what bug exactly was closed without the need for them to dig in the
BTS. This is no must but it is something your users would be greatful if
you could do it.
As I have said before, this is incomplete: only bugs that were reported
and identified are listed, and redundant: these changes should be in
the upstream changelog already.
--
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: kernel 2.5.73+, fakeroot, debuild - a small problem
Marek Habersack [EMAIL PROTECTED] writes: 2. Modify fakeroot to check the kernel version, the type of fs on which it is currently working and have it issue a sysctl to enable restricted_chown. It looks better than #1 but it might incurr Er, is this even possible as an ordinary user? 5. Influence the XFS/kernel maintainers to change the default value of restrict_chown to enabled. I agree that this is the best solution. -- Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org) Finger [EMAIL PROTECTED] (NOT a valid e-mail address) for more info.
Bug#198706: ITP: libebml -- Extensible Binary Meta Language access library
Package: wnpp Version: unavailable; reported 2003-06-25 Severity: wishlist * Package name: libebml Version : CVS Upstream Author : Steve Lhomme [EMAIL PROTECTED] * URL : http://www.matroska.org/ * License : dual GPL/QPL Description : Extensible Binary Meta Language access library The libebml library allows to read and write files using the Extensible Binary Meta Language, a binary pendant to XML. Using libebml makes it easier to extend a file format without breaking support in older parsers. -- System Information: Debian Release: testing/unstable Architecture: i386 Kernel: Linux c18 2.4.21-rc5 #2 Wed May 28 22:10:14 CEST 2003 i686 Locale: LANG=C, LC_CTYPE=fr_FR
