Re: webbit
Federico Di Gregorio [EMAIL PROTECTED] writes: Ero un po' stanco ieri sera e ho dimenticato di dire una cosa importante, cioe`, grazie, Federico, per il lavoro svolto. Il gio, 2003-05-15 alle 00:16, David N. Welton ha scritto: Finito il webbit, direi che e` ora di parlare di cosa e` andato bene, cosa e` andato male, e cosa possiamo fare per migliorare. *) L'organizzazione ha messo tutti i gruppi di 'volontari' (anche dei cani e porci) in quello spazio dove non era neanche chiaro che c'erano degli stand fra i tavoli di computer. Direi che questo non ci ha aiutato molto. l'organizzazione ha fatto overbooking, lo sanno e si sono scusati. speriamo che l'inconveniente non si ripeta l'anno prossimo. IMO, sarebbe utile separare completamente anche quegli stand come il nostro da 'la massa di gente'. Ma e` chiaramente compito degli organizzatori fare un cambiamento simile. O non farlo, se non gli va. Quello dipende poco da noi. *) Noi abbiamo avuto uno stand con 3 o 4 altri gruppi. Questo, secondo me non andava bene. La Debian e` un'organizzazione al livello mondiale. noi (non solo Debian ma i 13 gruppi del software libero italiano presenti) eravamo gli **unici** ad aver avuto tutto gratis. Anche il Pluto/unesco. non mi sembra il caso di dire non andava bene, anche se siamo un'organizzazione a livello mondiale. Magari in quel caso era meglio concentrarsi un po' invece di rapprasentare in modo poco efficace 13 gruppi. Magari fare lo stand 'software libero' e basta, e avere un po' di cose in comune. Non so esattamente, ma cosi` era un po' troppo poco chiaro chi faceva cosa. E sicuramente non superava il test spiega in una frase chi siete. *) Il nostro stand era troppo mescolato con l'area hackers (non so come si chiama). Questo impediva, IMO, alla gente normale di passare e dare un'occhiata. Sarebbe il caso di avere solo alcune persone allo stand, e gli altri fuori, altrove. Era molto confusa la situazione. vedi sopra overbooking. comunque di gente normale ne e` passata tantissima. senza offesa, ma ti ho visto pochissimo allo stand, come fai a sapere che la gente era poca? Quando c'ero, erano in pochi che passavano. Io mi sentivo scomodo a stare in cosi` tanti. Avevo promesso anche a quelli del Pluto a stare un po' nel loro stand. Neanche la` passava moltissima gente. *) Io sto molto scomodo dicendo qualcosa che vale a dire 'scrivete in inglese', ma debian-events-eu in teoria era il posto piu` adatto per organizzare la nostra partecipazione al webbit. no. scrivo sempre su debian-events-eu, prima alcuni mesi prima, poi pochi giorni prima ed infine dopo l'evento. e` un evento assolutamente italiano ed e` perfetto per debian-devel-italian. se qualcuno vuole riportare tutte le discussioni su debian-events-eu lo faccia pure ma visto che non 1 degli iscritti mi ha mai mandato un messaggio per chiedermi ulteriori informazioni, mi sembra che la cosa non interessi. Se non c'e` interesse, lasciamo stare - effettivamente e` uno spreco di tempo. Concetualmente preferisco l'idea dell'altra lista, ma se non rispecchia la realta`, cosi` sia. *) Altro? si. ci vorrebbe qualche proposta per l'anno prossimo. a parte la disorganizazione dello stand dovuta all'overbooking i sembra che siamo andati bene, ma sicuramente si puo` fare di meglio. pero` ci vogliono idee. Alcune idee: Se siamo in tanti (cosa buona che mi ha fatto molto piacere!), magari e` il caso di stabilire dei turni, in modo di lasciare un po' piu` libero lo stand. Sarebbe carino anche trovare un posto dove nascondere tutti i bagagli - anche sotto un tavolo con qualcosa davanti. Fa sembrare piu` professionale avere meno roba. Uno striscione Debian mi sembra fattibile in qualche modo. Pensavo addirittura ce ne fosse uno in giro. Non permettere alla gente di sedersi ai tavoli con la schiena rivolta al pubblico. Probabilmente questo era piu` che altro risultato dell'overbooking e mancanza di spazio. Fare dei depliant. Ci vuole tempo e soldi per questi... due anni fa avevamo trovato uno sponsor per farli. Oltre al computer che funzionava da masterizzatore (gran bella cosa!), averne un paio da 'demo' non sarebbe stato brutto. Magari con sopra Gnome/KDE o qualcos'altro di carino. Forse la mappa di tutti i debian developers del mondo. Sono disponibile per aiutare con il webbit nel 2004 (a patto che non ci rompiamo di cercare casa e ce ne andiamo in Oregon). Ciao, -- David N. Welton Consulting: http://www.dedasys.com/ Personal: http://www.dedasys.com/davidw/ Free Software: http://www.dedasys.com/freesoftware/ Apache Tcl: http://tcl.apache.org/
Re: webbit
Il gio, 2003-05-15 alle 10:19, David N. Welton ha scritto: Federico Di Gregorio [EMAIL PROTECTED] writes: *) Altro? si. ci vorrebbe qualche proposta per l'anno prossimo. a parte la disorganizazione dello stand dovuta all'overbooking i sembra che siamo andati bene, ma sicuramente si puo` fare di meglio. pero` ci vogliono idee. Alcune idee: Se siamo in tanti (cosa buona che mi ha fatto molto piacere!), magari e` il caso di stabilire dei turni, in modo di lasciare un po' piu` libero lo stand. era previsto ma, come ho detto, hanno fatto overbooking e la gente del turno out non aveva nessun posto in cui andare. l'idea e` di avere gli stand con poche persone e le altre distribuite nell'isola. i visitatori si avvicinano allo stand ese poi vogliono approfondire vengono mandati dalle persone nell'isola che cazzeggiano, spiegano, etc. purtroppo non abbiamo potuto farlo funzionare cosi`. Sarebbe carino anche trovare un posto dove nascondere tutti i bagagli - anche sotto un tavolo con qualcosa davanti. Fa sembrare piu` professionale avere meno roba. giusto. dovremmo chiedere uno sgabuzzino oppure uno spazio a parte. oppure trovare un modo noi di lasciare tutto il materiale. ricordiamolo. Uno striscione Debian mi sembra fattibile in qualche modo. Pensavo addirittura ce ne fosse uno in giro. li avevo fatti io per terni, 3 anni fa. quest'anno ho avuto cosi` tante cose da fare che non ho avuto tempo. Non permettere alla gente di sedersi ai tavoli con la schiena rivolta al pubblico. Probabilmente questo era piu` che altro risultato dell'overbooking e mancanza di spazio. idem. un pochino + di professionalita` sarebbe stato meglio. Fare dei depliant. Ci vuole tempo e soldi per questi... due anni fa avevamo trovato uno sponsor per farli. il progetto gadgets prosegue. dopo le magliette e CD pensiamo a depliant, tazze, spillette. se trovate degli sponsor bene, altrimenti ci arrangiamo qui e vi faro` sapere. Oltre al computer che funzionava da masterizzatore (gran bella cosa!), averne un paio da 'demo' non sarebbe stato brutto. Magari con sopra Gnome/KDE o qualcos'altro di carino. Forse la mappa di tutti i debian developers del mondo. le demo c'erano (tipo il computer con 9 xine che giravano, alla faccia di BeOS) solo che non si vedevano! sigh... Sono disponibile per aiutare con il webbit nel 2004 (a patto che non ci rompiamo di cercare casa e ce ne andiamo in Oregon). eheh. ok. continuiamo a discuterne in lista. -- Federico Di Gregorio Debian GNU/Linux Developer[EMAIL PROTECTED] INIT.D Developer [EMAIL PROTECTED] The number of the beast: vi vi vi. -- Delexa Jones signature.asc Description: Questa parte del messaggio =?ISO-8859-1?Q?=E8?= firmata
Re: webbit
- [EMAIL PROTECTED] : Se siamo in tanti (cosa buona che mi ha fatto molto piacere!), magari e` il caso di stabilire dei turni, in modo di lasciare un po' piu` libero lo stand. era previsto ma, come ho detto, hanno fatto overbooking e la gente del turno out non aveva nessun posto in cui andare. l'idea e` di avere gli stand con poche persone e le altre distribuite nell'isola. i visitatori si avvicinano allo stand ese poi vogliono approfondire vengono mandati dalle persone nell'isola che cazzeggiano, spiegano, etc. purtroppo non abbiamo potuto farlo funzionare cosi`. Io mi propongo come isolano :p, sperando di non avere i casini di quest'anno che mi hanno impedito di fare i 3 giorni. snip Uno striscione Debian mi sembra fattibile in qualche modo. Pensavo addirittura ce ne fosse uno in giro. li avevo fatti io per terni, 3 anni fa. quest'anno ho avuto cosi` tante cose da fare che non ho avuto tempo. Posso farlo. Fare dei depliant. Ci vuole tempo e soldi per questi... due anni fa avevamo trovato uno sponsor per farli. il progetto gadgets prosegue. dopo le magliette e CD pensiamo a depliant, tazze, spillette. se trovate degli sponsor bene, altrimenti ci arrangiamo qui e vi faro` sapere. Io posso propormi come sponsor a livello di supporti, posso farveli pagare a prezzo poco più alto del prezzo d'acquisto.[1] Parliamo di meno di un euro a CD con inserto, CD-Wallet, etichetta e yadayadayada, o 0.30 euro a CD.[2] Per i Gadgets ho qualche contatto e inizio a chiedere, ma attenzione, non è cosa facile: si parla di prodotti personalizzati e la maggiorparte si muove ai 1000 pezzi. BTW: io ho il prezzo da rivenditore, quindi secondo me è meglio che non vi muoviate da privati. Ciao, Nicholas [1] Il problema è la SIAE e la nuova tassa sui supporti vergini: un modo di fotterla sarebbe mettere il bollino omaggio (costa 0.02 contro 0.25 della tassa). E' un po' un calcio nelle palle per Debian, vedete voi, IMHO se c'è da risparmiare se po' fà (posso occuparmene). Sto comunque scartabellando per ovviare al problema, ma, ragazzi miei, siamo in Italia e *pare* che anche se duplico io in azienda, a differenza che nel resto d'Europa, mi becco la tassa. Una cosa la posso dire: non potete fare quello che avete fatto quest'anno altrimenti i CD vi vengono a costare un occhio, solo la tassa mi alza la torre di 40 euro (al pubblico). [2] Indicativamente: devo sentire i capoccia. Dovete esplicitarmi il concetto 'sponsorizzare'.
magazzino e contabilita`
ciao a *, per il webb.it 2002 eravamo senza soldi degli sponsor e decidemmo (alcuni qui a torino) di far fare noi le magliette e recuperare i soldi dopo la vendita. con l'andar del tempo quelle magliette le abbiamo vendute tutte e per questo webb.it le abbiamo rifatte (e vendute tutte) usando i soldi dell'anno prima. col tempo si e` sviluppata l'idea di gestire una specie di magazzino di gadget per le varie manifestazioni e di mandare i soldi in eccesso a Debian (attraverso il conto di assoli). ecco la situazione attuale e la contabilità, che nei primi tempi era un po' confusa, grazie al fatto che eravamo confusi noi e non sapevamo bene come avremmo trattato la cosa (all'inizio ci bastava vendere magliette debian e recuperare i costi). inoltre spesso alcune magliette vengono regalate allo staff (usanza da lungo tempo adottata) e che alcune persone (debian developers, organizzazione) le pagano al prezzo di costo. questo solo per dire che se fate i conti, ci possono essere piccole discrepanze, ma *nessuno* si e` intascato dei soldi. il primo periodo dopo il webbit 2002 (112 tshirt e qualche distro su cdrom), la vendita delle magliette presso il gnug e a vari privati, di cui una per corrispondenza a roma, (105 tshirt e qualche distro su cd), la vendita delle magliette presso il lime (58 tshirt) e dopo avere trattenuto i soldi della stampa delle 360 magliette, che ci erano costate 1865 euro ci rimanevano 996 euro e un numero imprecisato di magliette (qualche decina). il periodo contabilizzato * saldo iniziale 996 vendita magliette e cdrom al linux day 2002 380 acquisto 3 masterizzatori ide + scheda ide-pci -350 vendita 20 tshirt per corrispondenza (lug siena) 209 vendita 11 tshirt a milano 110 vendita 2 tshirt al mercatino equo e solidale all'hiroshima a torino20 acquisto 270 tshirt-1241 acquisto 500 cdrom vergini -190 trasporto del materiale al webbit 2003 -80 vendita tshirt al webbit 2003 2510 vendita distro debian su cdrom al webbit 2003220 totale 2584 attualmente abbiamo a magazzino 0 magliette (vendute tutte!) e circa 250 CDROM vergini da masterizzare + l'hardware che portiamo alle fiere (tower nostro con 3 masterizzatori comunitari). -- Federico Di Gregorio Debian GNU/Linux Developer[EMAIL PROTECTED] INIT.D Developer [EMAIL PROTECTED] Don't dream it. Be it. -- Dr. Frank'n'further signature.asc Description: Questa parte del messaggio =?ISO-8859-1?Q?=E8?= firmata
Question de confiance ...
Bonjour, J'ai récemment rencontré un développeur Debian qui vient d'arriver à Paris et nous avons échangé nos empreintes GPG selon la procédure habituelle. Ma carte de visite, sur laquelle est incrite mon empreinte, ne mentionne que mon adresse @debian.org. Le développeur en question a récupéré ma clé mais ne l'a signée que pour l'UID @debian.org alors que celle-ci contient d'autres UID, et ceci pour des raisons de sécurité. Je n'ai pas réussi à obtenir d'explications convaincantes sur les problèmes liés à la sécurité. Est-ce quelqu'un saurait expliquer les problèmes et risques ou pourrait me diriger vers une documentation claire ? Merci d'avance. -- Jérôme Marant
Re: Question de confiance ...
On Thu, May 15, 2003 at 09:37:02AM +0200, Jérôme Marant wrote: Bonjour, J'ai récemment rencontré un développeur Debian qui vient d'arriver à Paris et nous avons échangé nos empreintes GPG selon la procédure habituelle. Ma carte de visite, sur laquelle est incrite mon empreinte, ne mentionne que mon adresse @debian.org. Le développeur en question a récupéré ma clé mais ne l'a signée que pour l'UID @debian.org alors que celle-ci contient d'autres UID, et ceci pour des raisons de sécurité. Je n'ai pas réussi à obtenir d'explications convaincantes sur les problèmes liés à la sécurité. Est-ce quelqu'un saurait expliquer les problèmes et risques ou pourrait me diriger vers une documentation claire ? Supposons : * une des UID corresponde à une adresse [EMAIL PROTECTED], qui ne t'appartient plus (tu as changé de boulot) * ancien_employeur a réassigné cette adresse à quelqu'un d'autre * tu n'as pas supprimé cette adresse de ta clé. J'imagine que c'est assez improbable (surtout le dernier point), mais pas impossible. Il y a dans ce cas un problème de sécurité. Une solution valable serait que ce développeur envoie un mail encrypté avec ta clé publique individuellement à toutes les adresses de ta clé, et que tu répondes en signant les messages. Il pourra alors vérifier que toutes les UID correspondent bien et les signer. -- Alexandre Fayolle LOGILAB, Paris (France). http://www.logilab.com http://www.logilab.fr http://www.logilab.org Développement logiciel avancé - Intelligence Artificielle - Formations
Re: Question de confiance ...
En réponse à Pierre Machard [EMAIL PROTECTED]: Note qu'en reprenant les arguments que tu as cité, si le mec se fait virer après que la personne qui veut signer la clé ait sondé l'adresse email, le problème est le meme :-) deluid fonctionne bien, autant l'utiliser :p Donc pour répondre à Jérôme, il n'y a pas de bonnes raisons pour qu'il ne signe pas tous tes UID :-p Jusqu'ici, c'est ce que je me disais. :-) -- Jérôme Marant [EMAIL PROTECTED] [EMAIL PROTECTED] http://marant.org
Re: Question de confiance ...
Salut, On Thu, May 15, 2003 at 09:37:02AM +0200, Jérôme Marant wrote: Le développeur en question a récupéré ma clé mais ne l'a signée que pour l'UID @debian.org alors que celle-ci contient d'autres UID, et ceci pour des raisons de sécurité. Je n'ai pas réussi à obtenir d'explications convaincantes sur les problèmes liés à la sécurité. Je fais pareil, c'est-à-dire je ne signe que pour les UID pour lesquelles la personne m'a dit (au moment où on s'est vu) qu'il veut que je les signe. La raison est simplement que avec ma signature je confirme que la personne a fait une certaine assertion ( « ceci est ma clef » ). Avec ma signature je ne peux pas signer plus que ça. Est-ce quelqu'un saurait expliquer les problèmes et risques ou pourrait me diriger vers une documentation claire ? Je ne peux pas te desiner concrètement une attacke. À mon avis le dout est suffisant pour ne pas le faire, et je felicite la personne en question d'avoir insisté sur son doute et pas avoir signé tes autres UID. Amicalement -Ralf. --
Re: Question de confiance ...
Georges Khaznadar [EMAIL PROTECTED] writes: Arnaud Vandyck a écrit : | Est-ce quelqu'un saurait expliquer les problèmes et risques ou | pourrait me diriger vers une documentation claire ? Imaginons que je sois très méchant, et que j'aie réussi à trouver un ... ne reçois aucun message, donc tu ne te doute pas de l'arnaque qui se monte. OK. Merci pour l'explication. Donc ça veut dire que : 1) on m'a volé ma clé 2) on m'a volé mon mot de passe de protection de clé Si 1) est possible, 2) l'est beaucoup moins en revanche car c'est quand même nécessaire pour signer. Donc quand bien même le voleur aurait réussi à ajouter un UID, sera t-il en mesure de signer à ma place ? Donc la personne qui signe tes uids ne doit le faire qu'après t'avoir regardé dans le blanc des yeux, puis demandé : c'est bien à toi, le premier uid ? C'est bien à toi le suivant ? etc. Il ne peut s'y fier que si tu le lui confirmes par un canal impossible à trafiquer. Et si je tombe sur un homonyme ou que l'on me présente une carte d'identité étrangère dont je ne doute pas de la validité ? -- Jérôme Marant http://marant.org
Re: Question de confiance ...
Ralf Treinen [EMAIL PROTECTED] writes: Salut, On Thu, May 15, 2003 at 09:37:02AM +0200, Jérôme Marant wrote: Le développeur en question a récupéré ma clé mais ne l'a signée que pour l'UID @debian.org alors que celle-ci contient d'autres UID, et ceci pour des raisons de sécurité. Je n'ai pas réussi à obtenir d'explications convaincantes sur les problèmes liés à la sécurité. Je fais pareil, c'est-à-dire je ne signe que pour les UID pour lesquelles la personne m'a dit (au moment où on s'est vu) qu'il veut que je les signe. La raison est simplement que avec ma signature je confirme que la personne a fait une certaine assertion ( « ceci est ma clef » ). Avec ma signature je ne peux pas signer plus que ça. Oui, mais si tu récupères la clé sur keyring.debian.org, que tu vois d'autres UID sur cette clé et que le fingerprint correspond, où est le doute ? Est-ce quelqu'un saurait expliquer les problèmes et risques ou pourrait me diriger vers une documentation claire ? Je ne peux pas te desiner concrètement une attacke. À mon avis le dout est suffisant pour ne pas le faire, et je felicite la personne en question d'avoir insisté sur son doute et pas avoir signé tes autres UID. Oui mais là, tu ne m'expliques pas l'attaque. On reste donc au niveau de la paranoïa ;-) -- Jérôme Marant http://marant.org
Re: Returning from vacation. (MIA?)
On Thu, 15 May 2003 07:17, Matthias Urlichs wrote: Hello. My spam protection system is unsure about your message. Since you're reading this, your email isn't spam ;-) -- please either sign your emails to me, or send a short confirmation to the address my name-abqux at domain so that and your mails will be whitelisted. Sorry about this, but there's no other way. I fail to see how a text like that can be called obnoxious, but that's just me. Your system is not quite as bad, but it is still bad and should not be used in forums such as this one. One of the many problems inherant in such systems is that they encourage false headers in spam. If a spammer notices that you are involved in a dialogue on a mailing list with another person then they can expect that your anti-spam system is configured to accept mail from them, so they will be likely to put that person's email address in the from field of their spam. So the end result if such things become popular is that spam will be more noxious. -- http://www.coker.com.au/selinux/ My NSA Security Enhanced Linux packages http://www.coker.com.au/bonnie++/ Bonnie++ hard drive benchmark http://www.coker.com.au/postal/Postal SMTP/POP benchmark http://www.coker.com.au/~russell/ My home page
Re: Returning from vacation. (MIA?)
On Thu, 15 May 2003 05:27, Chad Walstrom wrote: It is a shame that such a simple scuffle on-list has sent you packing. Someone who gives up so easily would never last. Everyone gets flamed on occasion, if you can't deal with it you can't survive on a popular mailing list. The Internet is not suitable for overly thin-skinned people. -- http://www.coker.com.au/selinux/ My NSA Security Enhanced Linux packages http://www.coker.com.au/bonnie++/ Bonnie++ hard drive benchmark http://www.coker.com.au/postal/Postal SMTP/POP benchmark http://www.coker.com.au/~russell/ My home page
debian-devel@lists.debian.org
http://www.richful-hk.com 16Alexa
Re: security in testing
Hi, Matt Zimmerman wrote:
There is no shortage of opinions about what we should do, but there is
unlikely to be any action until an I arises who actually does the work.
This has been discussed over and over with the same result each time
(i.e., no action).
Two answers:
(a) Before I do something like that, I'd need to be accepted as DD.
(b) Before I do something like that, I'd like to get some sort of rough
consensus that this is in fact a good idea, i.e. nobody has serious
problems with the approach.
Take your pick.
--
Matthias Urlichs | {M:U} IT Consulting @ m-u-it.de | [EMAIL PROTECTED]
Disclaimer: The quote was selected randomly. Really. | http://smurf.noris.de
--
Good day, eh?
Re: Returning from vacation. (MIA?)
Hi, Manoj Srivastava wrote:
I would. If I ever get a message like that, I would be
grateful -- It'll allow me to add yet another obnoxious auto-reply to
my spam filters.
Well, thanks for the feedback.
Rest assured you shall never get email from me, or any official
posiiton I may happen to hold while your filter is in place.
Ahem. Your email wouls have to contain a few highly unlikely phrases to be
classified as uncertain by me. FWIW, yours ends up as
X-Spam-Status: No, hits=-42.6 required=5.0
Besides, unlike certain others, I am not going to /dev/null the
uncertain emails.
--
Matthias Urlichs | {M:U} IT Consulting @ m-u-it.de | [EMAIL PROTECTED]
Disclaimer: The quote was selected randomly. Really. | http://smurf.noris.de
--
Let a fool hold his tongue and he will pass for a sage.
Re: security in testing
* Matthias Urlichs ([EMAIL PROTECTED]) wrote: Hi, Matt Zimmerman wrote: There is no shortage of opinions about what we should do, but there is unlikely to be any action until an I arises who actually does the work. This has been discussed over and over with the same result each time (i.e., no action). Two answers: (a) Before I do something like that, I'd need to be accepted as DD. False statement. (b) Before I do something like that, I'd like to get some sort of rough consensus that this is in fact a good idea, i.e. nobody has serious problems with the approach. Don't believe anyone has any serious problems with the approach and, honestly, if you care enough about what other people think to not take any action on your own chances are pretty good whatever you did wouldn't get very far anyway. Stephen pgpCW19Wpo4z1.pgp Description: PGP signature
Re: security in testing
On Wed, May 14, 2003 at 11:59:49PM -0400, Matt Zimmerman wrote:
There are no mirrors of security.debian.org, and have not been for as long
as I have been aware. See the security team FAQ.
deb http://mirror.pacific.net.au/debian-security/ stable/updates main
Do you honestly think would be a good idea to use testing-security this way
on a continual basis?
Yes, I do. I think we should release DSA's for security problems in
testing, too.
Such an endeavor would not seem to require any of the
facilities which make foo-security different from foo{,-proposed-updates}.
The same applies to stable: the key differences are immediacy,
announcements and control, all of which are equally valuable for testing
as stable. In any event, testing-proposed-updates exists and works at
present, the only thing missing is people reliably uploading to it, and
evaluating whether uploads work well enough to be included in testing
or not. All the technical issues have already been addressed.
This is a related, more general issue, of how to minimize the blockage
introduced by package dependencies. I think this problem is much more
worthwhile to address than security updates targeted at 'testing'.
You're wrong: blockages can never be cleared quickly enough to make for
timely security fixes. For security fixes, timely is same day; for
testing, timely is a couple of weeks.
Finding ways to minimize these blockages would benefit all packages'
progress into testing, security fixes included, and thereby greatly benefit
'testing' users, whatever their motivation might be.
Except that there can be no testing users while we don't provide security
updates. Using testing on a multi-user machine, or one that provides any
network services on a machine connected to the network is not something
anyone can recommend in good conscience, and that rules out almost
everything Debian's actually good at.
Sidestepping the process to provide this kind of timely security update
for unreleased software, on the other hand, doesn't seem particularly
valuable to me.
What, precisely, is unreleased about it?
Cheers,
aj
--
Anthony Towns [EMAIL PROTECTED] http://azure.humbug.org.au/~aj/
I don't speak for anyone save myself. GPG signed mail preferred.
``Dear Anthony Towns: [...] Congratulations --
you are now certified as a Red Hat Certified Engineer!''
pgp72RIkWpFap.pgp
Description: PGP signature
Re: security in testing
On Wed, May 14, 2003 at 11:59:49PM -0400, Matt Zimmerman arranged a set of bits into the following: There are no mirrors of security.debian.org, and have not been for as long as I have been aware. See the security team FAQ. FALSE. There are at least several mirrors. I myself use them as for some reason I can never keep a reliable connection to s.d.o. I know of at least two in .au (Pacific Internet and PlanetMirror). PlanetMirror is ftp.au.debian.org as well. Whether or not these are official mirrors is besides the point, there ARE mirrors and they ARE used and ARE required. pgp073mG3CVkH.pgp Description: PGP signature
Re: Do not touch l10n files
Manoj Srivastava wrote : On Tue, 13 May 2003 09:12:25 +0200, Javier Fernández-Sanguino Peña [EMAIL PROTECTED] said: Maintainers or developers do not have a say on how translations are done except for gettext sintax errors. If you do not like how a translation team works, but you do not understand the language, tough luck. If this is a turf war between translators and developers; then the person with upload rights shall win. As a package developer I hold veto powers over anything shipped in my package, since it is my signature that goes with it, and I am responsible for all bugs. and On Wed, 14 May 2003 19:25:20 +0200, Denis Barbier [EMAIL PROTECTED] said: On Wed, May 14, 2003 at 02:22:36AM -0500, Manoj Srivastava wrote: Silly? My, we must have a chip on our choulder. Equally silly as non-maintainers having delusions of control over what gets shipped with a package? Where did I say that? I am only requesting that developers who do not speak a given language do not edit their related l10n files, but ask first a trusted person fluent in this language if changes are needed. This is no different from code: if I maintian software, and I may not understand all the complexities of the package in question, but when I think I discover a problem, I send a notice to the upistream (coder, translator), and, if I am not fluenbt in the language, I ask someone to help (who may not be the upstream code/translator). I then add a local patch correcting the issue until the matter is resolved upstream. This is a far cry from ``Do not touch l10n files''. No one expects a maintainer to change code files either if they result is incorrect; that is just a bug. But maintainers are not admonished to never touch upstream files. If ever a translation is included in my packages, I certainly am not going to respect such a restriction against modifying files in my package. The situation is very different from the situation maintainer face with upstream code because in fact apt should be able to install l10n packages related to a given program package when it installs the program package. So if l10n materials are currently integrated into program packages, instead of being in separate l10n packages, it's because of this lack in apt. It's not because the program package maintainer should also be responsible for l10n stuff related to the program, like he is responsible for the code in the program. This lack in apt is very bad because : - users get lot of l10n that is mostly useless for them, - program packages are bloated with l10n stuff, - maintainers' job is more difficult because they have to deal with stuff they don't understand, - maintainer feel they are responsible for l10n material in _their_ package and feel the right to mess with the l10n material in _their_ package or to refuse l10n stuff, - Translators do not maintain packages so are not considered Developers and have no vote, - Translators have to deal with maintainers jealous of their rights on _their_ package. Maintainers should realize that the current situation is (or should be) temporary and so that the power they currently have on l10n stuff is something temporary, something that they shouldn't have if things were done properly. So Denis is very right to say Do not touch l10n files. Regards, Christian.
Re: Returning from vacation. (MIA?)
Clay Crouch [EMAIL PROTECTED] wrote: My most humble apologies. It has become quite clear that the culture that the DD community shares has evolved in my absence. My absence disallowed me to evolve with it. The culture you now enjoy is not the one I left. I truly didn't expect to be attacked on my first post. I also truly didn't expect to be further lambasted from all quarters for responding to them. [...] I don't get it. I can't see an attack in [EMAIL PROTECTED]. There was some critique, but it was not hostile at all. OTOH [EMAIL PROTECTED] _was_ evidently written to be offensive. If people are telling you that you might be wrong they aren't attacking you. cu andreas
Re: Returning from vacation. (MIA?)
On Thu, 15 May 2003 14:37, Matthias Urlichs wrote: Ahem. Your email wouls have to contain a few highly unlikely phrases to be classified as uncertain by me. FWIW, yours ends up as X-Spam-Status: No, hits=-42.6 required=5.0 Sorry, if you are only using that when spamassasin records it as a likely spam then that's OK. Most people who use spamassasin just bounce or discard the message if it matches. Using such a process instead is not so bad. -- http://www.coker.com.au/selinux/ My NSA Security Enhanced Linux packages http://www.coker.com.au/bonnie++/ Bonnie++ hard drive benchmark http://www.coker.com.au/postal/Postal SMTP/POP benchmark http://www.coker.com.au/~russell/ My home page
Re: Answers to Why is package X not in testing yet?
Joe Buck wrote: However, the output is redundant in many cases. Fixed now. -- Björn
RE
80 20 100M+100M asp/php/cgi/access 200/ 999+++ 100/ ! QQ 9651016 [EMAIL PROTECTED]
Re: Bug marked as done messages to-be-MIMEified?
On Wednesday 14 May 2003 16:05, Mark Brown wrote: On Wed, May 14, 2003 at 02:24:25PM +0100, Colin Watson wrote: Usually this is controlled by the Content-Disposition: header. Content-Disposition: inline should be displayed inline; Content-Disposition: attachment will often be hidden until explicitly opened. Assuming the mail client pays attention, of course. I guess using MIME structures like that more would make more people complain to devlopers of MUAs that don't handle this properly... I don't know many MUAs, but perhaps others do. Q: is content-disposition handled properly, especially for messag/rfc822 type attachments? (Or if not, are message attachments displayed inline by default?) KMail 1.5.1: yes Evolution: yes (already in 1.0.x IIRC) sylpheed? mozilla mail? (whatever the name of that thing is right now...) I guess quite critical would be mutt pine as especially developers are known to use textmode mail readers quite a lot. (Yes, I've stopped caring about users of a certain other widespread MUA, as you've probably guessed anyway when you notice me using PGP/MIME to sign messages...) cheers -- vbi -- random link of the day: http://fortytwo.ch/sienapei/laegoong pgp8HVqzpTEpK.pgp Description: signature
Re: security in testing
On Wed, May 14, 2003 at 03:57:58PM -0400, Michael Stone wrote: On Wed, May 14, 2003 at 10:14:53AM -0500, Gunnar Wolf wrote: I'm sorry, I am on a public terminal, and can't quite remember where I read it - But testing should always be close to a releasable state. That assumption is both false and absurd. Testing has exactly two advantages over unstable--1) all dependencies are satisfied and 2) known rc bugs don't propagate to testing. In all other respects unstable is better. (Security problems, rc bugs not noticed during the first two weeks, etc.) But we don't advertize this, so it is natural that people make the mistake and use testing instead of unstable. Friendly, Sven Luther
Re: security in testing
Manoj Srivastava wrote: This is, after all, more than just a herd of cats. How on earth did you get that quaint idea? From looking at Debian. It is far more structured, organised and controlled than the great majority of free software projects out there. If you want a universally held firm direction, go read the social contract. That is as close as you are going to get. I disagree. There is obviously a consensus on a number of important issues, such as that making all ports adhere to the lowest common denominator is more important than letting a few ports catch up with time. Direction need not come from on high, it more often evolves from long discussions in developer mailing lists. That does not mean it does not exist. -- Björn
Re: Do not touch l10n files [without notifying translators]
On Wed, May 14, 2003 at 01:03:07PM -0500, Manoj Srivastava wrote: On Wed, 14 May 2003 19:17:50 +0200, Javier Fernández-Sanguino Peña [EMAIL PROTECTED] said: On Wed, May 14, 2003 at 02:18:04AM -0500, Manoj Srivastava wrote: As a package developer I hold veto powers over anything shipped in my package, since it is my signature that goes with it, and I am responsible for all bugs. You do hold upstream responsible for the bugs in their software right? I don't shrug off my responsibilities so lightly. I am responsible for all my packages. I may need help to solve or diagnose some bugs, but every single bug on my packages receives my attention, and I work on trying to gather enough information to help upstream debug those issues. In case the upstream does not respond, or does not think it is a bug, I create local patches. From my point of view, same should go for translators. Sure. When (if?) translated descriptions are included in packages, I'll contact the translators fiirst, perhaps including local changes until the matter is resolved. Just like I do with upstream code. So, I would say that you are handling translations right, and there is no need to get hurt by Denis's complain. It wasn't directed at all maintainers, but to the ones feeling confident enough to corrupt l10n files *without informing the translator of their changes*. I admit that his tone was quite categorical, but he was only repporting a problem which exists (we have some example of bad habits, but giving any name would only lead to more people feeling insulted, and a bigger flamewar, which would help nobody). If you don't do the stuff he is complaining about, if, as Colin said, the collaboration between you and the tranlators colaborating on your packages is based on mutual respect, everything is perfect, and there is no need for yet another flamewar here. Please don't get me wrong. I understand that the tone of the complain may lead too easily to such flamewar (ie, I don't say that you or anybody else wanted to get this flamewar), but I would like people to understand that instead of flooding -devel yet another time, we should document somewhere what the best current practices are concerning l10n (yours are good candidate), and try to ease the collaboration needed to achieve the l10n goals. Translation-related bugs should be the responsibility of the translation teams (and should be forwarded to them). While translations reside outside my package, the bugs shall be reassigned (or closed), not forwarded. When the translation is in my package, the bug shall be forwarded, and perhaps I'll use local patches to correct the issue. That's an interesting point. I asked for a translation pseudo package, so that developpers can reassign bug repports about translations to somewhere where translators can be made aware of the issue and work on it to help the maintainer, but this request never leaded to any concret decision. :) In my opinion, one of the problems here is that we have no infrastructure at all to ease the l10n work, neither do we have any infrastructure to handle properly the l10n bugs. I dream of something like the dbuild and packages.qa.debian.org or qa.debian.org/developer.php for translators, but there is still a very long road until there. First step being to create a DT (debian translator) status, or renaming Debian Developers to Debian Contributor, since the former name clearly do not capture all the ways to contribute to Debian. You may think that it's a dummy name problem, but the problem more complicated. In the past, I applyed to become DD with stating that I do not want to maintain any package, only become translator. And most of the questions I was asked was how to deal with bug repports against my packages, and how to use lintian and yada to increase the quality of my packages... [in the meanwhile, I begun helping to fix RC bugs, and repackaged doc-rfc to solve the issues repported against it, for example, so those questions where not that useless to that extend, but that's another story] So, to summarize myself, if we would live in a perfect world, we would: 1. Document the BCP concerning l10n, and repport as bug any maintainer or translator not sticking to it (and only them) 2. Think about improving (creating?) the l10n infrastructure within Debian. Much more thinkings (=flamewar? ;) are needed for that. Bye, Mt. -- Computers are not intelligent. They only think they are.
Re: security in testing
Hi, Stephen Frost wrote:
(a) Before I do something like that, I'd need to be accepted as DD.
False statement.
So non-DDs can get accounts on Debian machines to setup something like
this (install FTP directories, setup autobuilders, etc.)?
If that's so, cool, I'll have free time in two weeks or so.
I assume debian-admin are the correct people to talk further.
--
Matthias Urlichs | {M:U} IT Design @ m-u-it.de | [EMAIL PROTECTED]
Disclaimer: The quote was selected randomly. Really. | http://smurf.noris.de
--
If you are shooting under 80 you are neglecting your business;
over 80 you are neglecting your golf.
-- Walter Hagen
Re: security in testing
Keegan Quinn wrote: Funny how myself and every admin I know have only very minor issues with running unstable. What, pray tell, makes it such an 'obvious' non-option for end users? How about constantly repeated statements to the effect? So you did not even look at the release announcement, and yet you run unstable. You are luck that all that happened was that you had extra copies of mail. People had had much worse happen to them running unstable, -- Manoj Srivastava, linux.debian.bugs.dist, 1999-07-02 Newbies are constantly told don't run unstable by all clued users. The ones that persist are either very dumb, and fail. Or very intelligent, and succeed after mastering the learning curve. -- Stephen R. Gore, debian-devel 2000-06-05 Don't run unstable - it's normal that unstable sometimes breaks. -- Adrian Bunk, muc.lists.debian.user, 2001-02-16 The real moral: if you don't have a good chance of figuring out what's wrong on your own, and fixing, backing out of, or jury-rigging around it without outside help... don't run unstable. -- Craig Dickson, muc.lists.debian.user, 2002-11-14 there are risks associated with running unstable, if you're not willing or not able to deal with those risks then DON'T RUN UNSTABLE. -- Craig Sanders, debian-devel 2002-12-13 The list can be made much longer, but I think you get the idea. End users are discouraged from running unstable, and for good reasons. I do like the sound of this, but saying it has a place and actually making it happen are very different things. There seems to be a lot of the former, and little of the latter That tired old argument doesn't bite on me since I have already volunteered to set up a testing-i386 release. :-) -- Björn
Re: security in testing
Hi, Stephen Frost wrote:
honestly, if you care enough about what other people think to not take
any action on your own chances are pretty good whatever you did wouldn't
get very far anyway.
My approach is somewhat different. I freely admit that I'm fairly new to
Debian and probably have some misconceptions about how Things Are Done.
(That wouldn't be the first time...)
So I'd rather ask first than to step on somebody's toes.
Besides, somebody might have a better idea how to do that. They should
have a chance to speak up _before_ I do all the work. ;-)
--
Matthias Urlichs | {M:U} IT Design @ m-u-it.de | [EMAIL PROTECTED]
Disclaimer: The quote was selected randomly. Really. | http://smurf.noris.de
--
The trouble with having an open mind, of course, is that people
will insist on coming along and trying to put things in it.
[Terry Pratchett, Diggers]
Re: security in testing
Hi, Chris Leishman wrote:
- If the build is successful, it's available for apt-getting from
testing-updates; otherwise the maintainer gets a helpful ;-) email.
I'm just curious why the updates couldn't just go straight into testing
itself. It's not as if the testing distribution is frozen in any way -
and that would deal with the problem of people not getting updates for
s.d.o.
The current unstable-testing process might work for testing-updates too --
I haven't thought that far. The main problem I see with this approach is
that testing might get out-of-sync with unstable.
Something to think about for the next step, anyway.
--
Matthias Urlichs | {M:U} IT Design @ m-u-it.de | [EMAIL PROTECTED]
Disclaimer: The quote was selected randomly. Really. | http://smurf.noris.de
--
I'm CONTROLLED by the CIA!! EVERYONE is controlled by the CIA!!
-- Zippy the Pinhead
mailcap next step
Hello! I was wondering how to improve mailcap system to become useful. First step was to able mc use mailcap. Now, I want to make nautilus to use mailcap. And I have a few questions. 1. Where nautilus (gnome2?) keeps info about mime types? 2. (more complicated) Does run-mailcap differs x and non x applications? Could be posible run ie. links in mc and galeon in nautilus by the same run-mailcap command? Regards. Marcin -- .--, --: mcINEK :-- / ,. \ ' T h e O w l s a r e n o t | | ; ;W h a t T h e y S e e m . . . ' \ `._ /wrote on Debian GNU/Linux SID signature.asc Description: PGP signature
Re: conflicts-based solution (was Re: security in testing)
On Thu, May 15, 2003 at 01:13:19PM +1000, Anthony Towns wrote: On Wed, May 14, 2003 at 07:12:15PM -0400, Joey Hess wrote: Take the harden package, or create something similar: a package that conflicts with all versions of packages with known security holes. Why not just /fix/ the holes? Is uploading a package with a well known patch _really_ that hard? Because the resulting package will be built on unstable and may have dependency problems that will stop it from entering testing for long times (month ?). sure you can argue that we should then fix the dependent packages, but this may take time, more time than what is reasonable for a security update anyway. The fact is, we don't have a security architecture, or even autobuilders for testing, and thus fixing the bug is no problem, but getting it in testing is, and even with an override from the RM this could cause problem. A propper solution would be to have an additional build structure, where you could upload to testing-proposed-updates, or something such, and where the autobuilder would build these packages in a testing environment, and which will follow the exact same rules for migration as the unstable-testing one, except that all dependencies should be always fullfilled, leaving only architecture rebuild problems. Sure this is not bullet proof, and maybe it should be monitored to make sure someone doesn't misuse this to get things in testing, but it would enable the package maintainers to do RC and security bug fixing in testing without being held back by this or that library/build-tool package that just got a new version which will stop anything built with it to enter testing. If this works well, it could be possible to extend this for the next release to have a dual build system, one for library/build-tool stuff, and the other for the rest of the packages. But then, this is a discussion for another time. Friendly, Sven Luther
Re: Questions regarding utf-8
Bob Hilliard [EMAIL PROTECTED] wrote: Thanks to all who replied to my recent question on this subject. Andreas Metzler [EMAIL PROTECTED] wrote: With glibc I'd use iconv --from=SRC-ENCODING --to=DST-ENCODING//TRANSLIT if it is acceptable to change the length of strings. This will replace e.g. the Euro-Symbol with EUR. Without //TRANSLIT, iconv fails if DST-ENCODING is US or ASCII, but with //TRANSLIT, all characters that aren't included in ASCII are rendered as `?'. I was not aware of that, but you are right. This useful, but not as useful as the conversions performed by recode. -- *prompt* echo ö§ | recode latin1..ascii oSS *prompt* echo ö§ | iconv -f latin1 -t ascii//TRANSLIT ; echo $? oe? -- »oe« is much better than »o« and »SS« is no usable replacement for »§« (I do not think there is one), it would be nice if iconv's exit-status reflected whether questionmarks were used, but changing this would probably break existing software. Where is `//TRANSLIT' documented? In former times it was documented in the manpages but afaict it is not documented anywhere anymore (I checked the respective manpages and the contents of glibc-doc 2.2.5-11.2) *prompt* zgrep -li translit `dlocate -L glibc-doc` /usr/share/doc/glibc-doc/ChangeLog.11.gz /usr/share/doc/glibc-doc/ChangeLog.12.gz /usr/share/doc/glibc-doc/ChangeLog.10.gz cu andreas -- Hey, da ist ein Ballonautomat auf der Toilette! Unofficial _Debian-packages_ of latest unstable _tin_ http://www.logic.univie.ac.at/~ametzler/debian/tin-snapshot/
Re: A strawman proposal: testing-x86
On Wed, May 14, 2003 at 10:51:42AM -0500, Manoj Srivastava wrote: On Wed, 14 May 2003 09:14:20 -0400, Theodore Ts'o [EMAIL PROTECTED] said: If that's the case, then maybe the testing distribution has outlived its usefulness. But if people feel otherwise, then it would make sense to think of ways in which testing might be able to be more true to its original goals --- which is to expand the number of people who can test out packages before a stable release. If that's the case, then for a giving platform: Hmm. I always thought that testing was a tool for release management, and a replacement of the freeze mechanism. If so, it is really only ready for extensive use and testing close to a stable release -- when the RM calls uponm and lets lose the hrdes on testing to sniff out undiscovered bugs. Untl then, it is a no mans land where the ravening winds howl and moan. That is what it really is, but not what we advertized when testing was first introduced. We told back then that the aim of testing was dual, and in addition to what you said, it would also be a place for people who want to run things newer than stable to go without getting the breakage of unstable they may not handle. By saying that, we encouraged people to use testing instead of unstable, none of which have security updates, and gave the impression that testing was more stable/secure/preferable/whatever to unstable, which is contrary to what you are saying. I don't say that what you say is wrong, just that people are not aware of it, because we did tell them differently back then. Friendly, Sven Luther
Re: security in testing
On Thu, May 15, 2003 at 03:19:02PM +1000, Anthony Towns wrote:
On Wed, May 14, 2003 at 11:59:49PM -0400, Matt Zimmerman wrote:
There are no mirrors of security.debian.org, and have not been for as long
as I have been aware. See the security team FAQ.
deb http://mirror.pacific.net.au/debian-security/ stable/updates main
Do you honestly think would be a good idea to use testing-security this way
on a continual basis?
Yes, I do. I think we should release DSA's for security problems in
testing, too.
Such an endeavor would not seem to require any of the
facilities which make foo-security different from foo{,-proposed-updates}.
The same applies to stable: the key differences are immediacy,
announcements and control, all of which are equally valuable for testing
as stable. In any event, testing-proposed-updates exists and works at
present, the only thing missing is people reliably uploading to it, and
evaluating whether uploads work well enough to be included in testing
or not. All the technical issues have already been addressed.
Are the testing-proposed-updates autobuilt on all arches ? I got the impression
that this was not the case, but i may be wrong.
Friendly,
Sven Luther
Re: security in testing
On Wed, May 14, 2003 at 05:37:51PM -0700, Keegan Quinn wrote: On Wednesday 14 May 2003 04:53 pm, Björn Stenberg wrote: What's worse, saying testing is not for public use means there is _no_ place to get updates, since unstable is obviously not an option for end users. This makes Debian the only linux distribution I know of that completely eschews software updates between frozen releases (except for security fixes). Hmm. Funny how myself and every admin I know have only very minor issues with running unstable. What, pray tell, makes it such an 'obvious' non-option for end users? Well-timed unstable snapshots are often more 'stable' than commercial Linux releases, in my limited experience. Because we give them the impression that testing is more adapted to them than unstable. Friendly, Sven Luther
Re: Do not touch l10n files
On Thu, May 15, 2003 at 01:10:35AM +0100, Colin Watson wrote: On Thu, May 15, 2003 at 12:22:27AM +0200, Denis Barbier wrote: On Wed, May 14, 2003 at 02:02:27PM -0500, Manoj Srivastava wrote: This is a far cry from ``Do not touch l10n files''. Hey, this was the subject, I had to get it short. My original post contained the following paragraph: So I would like to ask developers not to edit l10n files (templates, PO files, etc) themselves; if you believe that something goes wrong, notify the translator or his translation team (or any other trusted person). If you disagree, think twice before applying your changes, you are certainly wrong. Oh, rubbish. I won't claim to be able to deal with l10n files in every language under the sun, but I'm familiar enough with several European languages to be able to correct minor errors, make cautious small updates when something has changed globally, and so on. And you could also have mentioned that you pointed out an error I made when merging two translations. Of course I am grateful to developers who take care of l10n, but from my experience I was corrected once and my files were corrupted many times. Again my complaint goes against people who do not fully understand foreign languages and believe that they know what they should look like, see e.g. http://lists.debian.org/debian-l10n-french/2003/debian-l10n-french-200305/msg00161.html As long as I'm careful, I believe that this improves the state of l10n. Sure, I'll usually remember to tell the translator about it too, but I have many things to do, and translations are often the last thing I do before making a release in order to make sure that they're as up to date as possible so I'm often in a hurry. Perhaps this is just a translation problem itself, but you are certainly wrong has an incredibly arrogant tone. As said above this assumption is based on my own statistics, others may differ. Denis
partimage on powerpc
Hello, # partimage Error: volume hedaer size != 512 (520) This version has been compiled with an uncompatible version of gcc. I received this bug report (#193391) today and I cannot reproduce it on i386. Looks like a problem on powerpc. I'm not very familiar with powerpc. Could somebody help me? Thanks. Note: I'm not subscribed to the list at this moment. Please Cc me. -- Kind regards, Sergio Rua
Re: Do not touch l10n files
On Wed, May 14, 2003 at 07:17:50PM +0200, Javier Fernández-Sanguino Peña wrote: [...] As a package developer I hold veto powers over anything shipped in my package, since it is my signature that goes with it, and I am responsible for all bugs. You do hold upstream responsible for the bugs in their software right? From my point of view, same should go for translators. Translation-related bugs should be the responsibility of the translation teams (and should be forwarded to them). Some other projects (like GNOME [1] or KDE [2]) understand this and the translation (l10n work) translators get access to the source code CVS and whatever they do gets merged with the programs if it works (syntactically correct, compiles, etc..) This is fully right. Some Debian projects work this way (I know debian-www, debian-installer and debian-doc, are there others?) and it eases everyone's life. Denis
possible problem for debian was [NTP considered basic] misc@openbsd.org
Hi, I just catched this conversation on the misc OpenBSD mailinglist. Does this in any way afflict debian? greets Uwe -- X-Tec GmbH Institute for Computer and Network Security WWW : http://www.x-tec.de/ IPv6: http://www.ipv6.x-tec.de/ ---BeginMessage--- I'd like to encourage the OpenBSD developers to move NTP support into the base package. We cannot. The code is not free enough. ---End Message--- ---BeginMessage--- Theo de Raadt Wednesday, May 14, 2003 10:14 AM I'd like to encourage the OpenBSD developers to move NTP support into the base package. We cannot. The code is not free enough. I'm curious if you could be more specific here, because at first glance it seems the NTP copyright is at even less restrictive than the berkeley copyright (i.e. it does not require mention in advertising as bsd's does). I copy the entirety below. Rick *** * * * Copyright (c) David L. Mills 1992-2003 * * * * Permission to use, copy, modify, and distribute this software and * * its documentation for any purpose and without fee is hereby * * granted, provided that the above copyright notice appears in all* * copies and that both the copyright notice and this permission * * notice appear in supporting documentation, and that the name* * University of Delaware not be used in advertising or publicity * * pertaining to distribution of the software without specific,* * written prior permission. The University of Delaware makes no * * representations about the suitability this software for any * * purpose. It is provided as is without express or implied * * warranty. * * * *** ---End Message--- ---BeginMessage--- * Permission to use, copy, modify, and distribute this software and * * its documentation for any purpose and without fee is hereby * * granted, provided that the above copyright notice appears in all* this is a misplaced modifier that has a 2nd meaning -- that it cannot be sold. i've talked to lawyers. it's a real problem, and they say they won't fix it. sorry. ---End Message---
Bug#193399: ITP: latex209 -- macro files of LaTeX 2.09 25-mar-1992 version
Package: wnpp Severity: wishlist * Package name: latex209 Version : 25.mar.1992 Upstream Author : Leslie Lamport * URL or Web page : ftp://ctan.tug.org/tex-archive/obsolete/macros/latex209/distribs/latex209.tar.gz * License : Public Domain Description : Commands and macro files of LaTeX 2.09 25-mar-1992 version
Where are translated man pages packaged?
Hi, There is currently no consensus whether translated man pages should be shipped along with original man pages or within manpages-xx packages. Unfortunately this leads to conflicts when a translation is first shipped by the latter, then incorporated into the former (e.g. when it becomes part of upstream tarball). Some developers are reluctant to include French translated man pages and ask me to ship them in manpages-fr. How can I make them change their mind? Is there a consensus that translated man pages must go with original man pages? Are exceptions needed for some packages? Denis
Re: Debian MIA check
There must be some mistake :-m Joey Hess dijo: Tor Slettnes mindi mondo smail xcdroast yard zmailer zmailer-ssl These are Héctor García's and he is not MIA at all. What happened? -- I would rather starve than lose your acceptance .''`.My eyes will always show my empty soul : :' :- Boy Sets Fire `. `' Proudly running Debian GNU/Linux (Sid 2.4.20 Ext3) `- www.amayita.com www.malapecora.com www.chicasduras.com
RE
80 20 100M+100M asp/php/cgi/access 200/ 999+++ 100/ ! QQ 9651016 [EMAIL PROTECTED]
Re: mailcap next step
On Thu, May 15, 2003 at 10:04:39AM +0200, mcINEK wrote: Hello! I was wondering how to improve mailcap system to become useful. First step was to able mc use mailcap. Now, I want to make nautilus to use mailcap. And I have a few questions. 1. Where nautilus (gnome2?) keeps info about mime types? 2. (more complicated) Does run-mailcap differs x and non x applications? If you already parsed mailcap into mc's configuration, you should've seen this (picking out a random one): application/vnd.sun.xml.draw; openoffice '%s'; edit=openoffice '%s'; test=test $DISPLAY != ; description=OpenOffice.org 1.0 Drawing; nametemplate=%.sxd Take extra care to the 'test' parameter. Could be posible run ie. links in mc and galeon in nautilus by the same run-mailcap command? If you can create a test to accomplish that, sure. -- Debian GNU/Linux -- http://www.debian.org Nederlandstalige Linux-documentatie -- http://nl.linux.org An expert can usually spot the difference between a fake charge and a full one, but there are plenty of dead experts. -- National Geographic Channel, in a documentary about large African beasts.
Re: Where are translated man pages packaged?
On Thu, May 15, 2003 at 11:24:14AM +0200, Denis Barbier wrote: Hi, There is currently no consensus whether translated man pages should be shipped along with original man pages or within manpages-xx packages. Unfortunately this leads to conflicts when a translation is first shipped by the latter, then incorporated into the former (e.g. when it becomes part of upstream tarball). Some developers are reluctant to include French translated man pages and ask me to ship them in manpages-fr. How can I make them change their mind? Is there a consensus that translated man pages must go with original man pages? Are exceptions needed for some packages? As the new maintainer of manpages-nl... I'd say, and so did Joost Van Baal, the previous maintainer, that translated manpages belong with the original. This way, it's easier to keep track of changes, manpages don't take up space documenting programs or -dev library packages that aren't installed, and, most importantly: people that don't know about the manpages-xx package will get the translated manpages if they set their $LANG, since it's with the 'normal' package. People that set their $LANG will probably prefer that anyway. With regard to those conflicting pages: that's just temporary; once manpages have been incorporated in the right package, one can easily remove the manpage from the manpages-xx package, and upload a new package. -- Debian GNU/Linux -- http://www.debian.org Nederlandstalige Linux-documentatie -- http://nl.linux.org An expert can usually spot the difference between a fake charge and a full one, but there are plenty of dead experts. -- National Geographic Channel, in a documentary about large African beasts. pgpEdp39Uc05y.pgp Description: PGP signature
Re: Where are translated man pages packaged?
On Thu, May 15, 2003 at 11:24:14AM +0200, Denis Barbier wrote: There is currently no consensus whether translated man pages should be shipped along with original man pages or within manpages-xx packages. Unfortunately this leads to conflicts when a translation is first shipped by the latter, then incorporated into the former (e.g. when it becomes part of upstream tarball). Some developers are reluctant to include French translated man pages and ask me to ship them in manpages-fr. How can I make them change their mind? Is there a consensus that translated man pages must go with original man pages? Are exceptions needed for some packages? I think it is proper to include translated man pages with original man pages, and to use apt-localepurge (now) or dpkg exclusions (when they're implemented) if people are worried about space. My gut feeling is that the manpages-LL packages should cover roughly the same topics as the English manpages package. My experience has been that refusing to include translated man pages makes it much harder to tell when the man pages have got out of date. However, I'm not sure how to go about persuading reluctant developers of this. -- Colin Watson [EMAIL PROTECTED]
Re: mailcap next step
W licie z czw, 15-05-2003, godz. 11:54, Wouter Verhelst pisze: If you already parsed mailcap into mc's configuration, you should've seen this (picking out a random one): application/vnd.sun.xml.draw; openoffice '%s'; edit=openoffice '%s'; test=test $DISPLAY != ; description=OpenOffice.org 1.0 Drawing; nametemplate=%.sxd Take extra care to the 'test' parameter. Could be posible run ie. links in mc and galeon in nautilus by the same run-mailcap command? If you can create a test to accomplish that, sure. Yes, I've seen it. BUT... This is galeon entry in /etc/mailcap: text/html; /usr/bin/galeon '%s'; description=HTML Text; test=test -n $DISPLAY; nametemplate=%s.html Even if I change it, to run links if not $DISPLAY it would be bad solution. User can't choose which browser use. In addition, it's another record from the same file. text/html; /usr/bin/mozilla '%s'; description=HTML Text; test=test -n $DISPLAY; nametemplate=%s.html We see a conflict. It doesn't matter how many browser user installed, always will be run galeon (it's above so it's first - am I right?). The best solution, I think, is that galeon (mozilla, etc) shouldn't provide a /etc/mailcap record, but just alternatives. And then in /etc/mailcap should be (just ONE) record, like (sorry, I don't know syntax) text/html; if DISPLAY run x-www-browser else run www-browser that's all. When user want to change one of browsers just use update-alternatives --config. This mechanism may be applied not only for browser, but image-viewers etc. What do you think about that? (I hope you understanded me ;) Regards. Marcin -- .---, --: mcINEK :-- / ,. \ ' T h e O w l s a r e n o t | | ; ;W h a t T h e y S e e m . . . ' \ `._ /wrote on Debian GNU/Linux SID signature.asc Description: PGP signature
Re: Debian MIA check
Sorry, my terminal was too small to check all the replies in the thread, including Hector's himself 0:-) Glad to see this clarified. -- I would rather starve than lose your acceptance .''`.My eyes will always show my empty soul : :' :- Boy Sets Fire `. `' Proudly running Debian GNU/Linux (Sid 2.4.20 Ext3) `- www.amayita.com www.malapecora.com www.chicasduras.com
Re: DebConf 3 for New Maintainers
* Colin Watson ([EMAIL PROTECTED]) [030514 15:42]: organization, though. Tollef, do you know if there'll be wireless base stations around or, will we be doing ad-hoc mode?) yes, there will be wlan. not user about the mode of operation. and there will also be some stationary pcs there.
Re: conflicts-based solution (was Re: security in testing)
On Thu, May 15, 2003 at 08:09:48AM +0200, Sven Luther wrote: On Thu, May 15, 2003 at 01:13:19PM +1000, Anthony Towns wrote: On Wed, May 14, 2003 at 07:12:15PM -0400, Joey Hess wrote: Take the harden package, or create something similar: a package that conflicts with all versions of packages with known security holes. Why not just /fix/ the holes? Is uploading a package with a well known patch _really_ that hard? The fact is, we don't have a security architecture, or even autobuilders for testing, Uh, actually, we have both these things. We've had them for almost a year now, although they haven't been used. Cheers, aj -- Anthony Towns [EMAIL PROTECTED] http://azure.humbug.org.au/~aj/ I don't speak for anyone save myself. GPG signed mail preferred. ``Dear Anthony Towns: [...] Congratulations -- you are now certified as a Red Hat Certified Engineer!'' pgpiCQsHLXZ2A.pgp Description: PGP signature
Re: fwctl and ipchains-perl - any takers?
* Bernd Eckenfels [EMAIL PROTECTED] [2003-04-27 18:12]: Martin, while maintaining the archive, contacted me, because he wanted to remove the orpahaned ipchains-perl module. He noticed, that my fwctl is depending on it. So here is my question, is anybody willing to take over fwctl/ipchains-perl and add iptables support, or has anybody some ideas what to do? No one seems to have responded, or? -- Martin Michlmayr [EMAIL PROTECTED]
Re: Do not touch l10n files
Ok, I've been trying to stay out of this as much as possible, since I think Denis' original post: So I would like to ask developers not to edit l10n files (templates, PO files, etc) themselves; if you believe that something goes wrong, notify the translator or his translation team (or any other trusted person). If you disagree, think twice before applying your changes, you are certainly wrong. is exactly what we did. I'm sorry that an aparently simple request has descended into mud-slinging and general hostility, but it certainly wasn't our intention. I'm also quite upset to see off hand insults - I've never claimed to know what a foreign language should look like, what we've asked is for a rational explanation as to why when we removed a single character, (a 3 as it happens) the layout of the french translation changed dramatically and to a form that the maintainers do not view as ideal. I hesitate to comment on the ownership of the translation, but would like to point out that the package maintainer is the one whose name is on the package; thus I think in the final analysis it's the maintainers call. If the maintainer has concerns about the translation, then the *least* the translation team could do is respond in a civil manner with the reasons behind the decision and work *with* the maintainer to resolve the problem. Cheers -Thom (sorry if the threading is broken - i'm replying based on the web archive. Please cc me on responses, too)
Re: mailcap next step
On Thu, May 15, 2003 at 12:11:03PM +0200, mcINEK wrote: W li?cie z czw, 15-05-2003, godz. 11:54, Wouter Verhelst pisze: If you already parsed mailcap into mc's configuration, you should've seen this (picking out a random one): application/vnd.sun.xml.draw; openoffice '%s'; edit=openoffice '%s'; test=test $DISPLAY != ; description=OpenOffice.org 1.0 Drawing; nametemplate=%.sxd Take extra care to the 'test' parameter. Could be posible run ie. links in mc and galeon in nautilus by the same run-mailcap command? If you can create a test to accomplish that, sure. Yes, I've seen it. BUT... This is galeon entry in /etc/mailcap: text/html; /usr/bin/galeon '%s'; description=HTML Text; test=test -n $DISPLAY; nametemplate=%s.html Even if I change it, to run links if not $DISPLAY it would be bad solution. User can't choose which browser use. In addition, it's another record from the same file. text/html; /usr/bin/mozilla '%s'; description=HTML Text; test=test -n $DISPLAY; nametemplate=%s.html We see a conflict. It doesn't matter how many browser user installed, always will be run galeon (it's above so it's first - am I right?). Yes. The best solution, I think, is that galeon (mozilla, etc) shouldn't provide a /etc/mailcap record, but just alternatives. And then in /etc/mailcap should be (just ONE) record, like (sorry, I don't know syntax) text/html; if DISPLAY run x-www-browser else run www-browser that's all. When user want to change one of browsers just use update-alternatives --config. Here's your error: if you do that, it's not the user who can change his browser, but the system administrator. Those two are not always the same. However, there's a better way. From mailcap(5): FILES $HOME/.mailcap:/etc/mailcap:/usr/share/etc/mailcap:/usr/local/etc/mail- cap -- default path for mailcap files. In other words: you can create a ~/.mailcap, with the same syntax as /etc/mailcap, and copy your preferred entries from /etc/mailcap there -- or create new ones. -- Debian GNU/Linux -- http://www.debian.org Nederlandstalige Linux-documentatie -- http://nl.linux.org An expert can usually spot the difference between a fake charge and a full one, but there are plenty of dead experts. -- National Geographic Channel, in a documentary about large African beasts. pgpSpNlEjOEBj.pgp Description: PGP signature
Re: conflicts-based solution (was Re: security in testing)
On Thu, May 15, 2003 at 09:03:06PM +1000, Anthony Towns wrote: On Thu, May 15, 2003 at 08:09:48AM +0200, Sven Luther wrote: On Thu, May 15, 2003 at 01:13:19PM +1000, Anthony Towns wrote: On Wed, May 14, 2003 at 07:12:15PM -0400, Joey Hess wrote: Take the harden package, or create something similar: a package that conflicts with all versions of packages with known security holes. Why not just /fix/ the holes? Is uploading a package with a well known patch _really_ that hard? The fact is, we don't have a security architecture, or even autobuilders for testing, Uh, actually, we have both these things. We've had them for almost a year now, although they haven't been used. So, the infrastructure is there, but not turned on ? What about woody-proposed-updates ? Are the autobuilders available for it ? I rememeber having to hand build some of the packages for it sometime ago. Friendly, Sven Luther
Re: conflicts-based solution (was Re: security in testing)
On Thu, May 15, 2003 at 09:03:06PM +1000, Anthony Towns wrote: On Thu, May 15, 2003 at 08:09:48AM +0200, Sven Luther wrote: On Thu, May 15, 2003 at 01:13:19PM +1000, Anthony Towns wrote: On Wed, May 14, 2003 at 07:12:15PM -0400, Joey Hess wrote: Take the harden package, or create something similar: a package that conflicts with all versions of packages with known security holes. Why not just /fix/ the holes? Is uploading a package with a well known patch _really_ that hard? The fact is, we don't have a security architecture, or even autobuilders for testing, Uh, actually, we have both these things. We've had them for almost a year now, although they haven't been used. They're testing-proposed-updates is documented in Section 5.5.2 of the Developer's Reference, but it says that they should only be used in case of a freeze. You should not upload to testing-proposed-updates when you can update your packages through unstable. is also a prominent quote from that section. Nothing specifying security updates, although it does discuss that these updates require manual intervention. Maybe a specific reference to managing security updates to testing in this section would be helpful? It'd finally put it down somewhere where people can point to, and maybe cut a few of these debates a little shorter. - David Nusinow (going to file a wishlist bug for this)
Re: mailcap next step
W licie z czw, 15-05-2003, godz. 13:00, Wouter Verhelst pisze: Here's your error: if you do that, it's not the user who can change his browser, but the system administrator. Those two are not always the same. But, does it eliminate my soluton? As you wrote later, user always can change /etc/mailcap. I didn't wonder how it would be on multi-users machines but I don't think it could be 'worse'. On the contrary, for one-user machines it will be very good and fast solution to make their programs runing apps like they want. The don't need to wonder what app will be starded, just that what they choose by update-alternatives. And also, this apps may be different for xwindows or console. What is more, everything will be doing automatically. I think it can be interesting. Regards, Marcin -- .---, --: mcINEK :-- / ,. \ ' T h e O w l s a r e n o t | | ; ;W h a t T h e y S e e m . . . ' \ `._ /wrote on Debian GNU/Linux SID signature.asc Description: PGP signature
Re: mailcap next step
On Thu, May 15, 2003 at 01:24:42PM +0200, mcINEK wrote: W li?cie z czw, 15-05-2003, godz. 13:00, Wouter Verhelst pisze: Here's your error: if you do that, it's not the user who can change his browser, but the system administrator. Those two are not always the same. But, does it eliminate my soluton? As you wrote later, user always can change /etc/mailcap. I didn't wonder how it would be on multi-users machines but I don't think it could be 'worse'. On the contrary, for one-user machines it will be very good and fast solution to make their programs runing apps like they want. The don't need to wonder what app will be starded, just that what they choose by update-alternatives. And also, this apps may be different for xwindows or console. I really think it would be a bad idea to go the alternatives road here. If you must, you could write a front-end that parses /etc/mailcap, and for a given MIME type, allows a user to pick the application of his/her choice; the front-end could then write that to ~/.mailcap. What is more, everything will be doing automatically. I think it can be interesting. We disagree, then. -- Debian GNU/Linux -- http://www.debian.org Nederlandstalige Linux-documentatie -- http://nl.linux.org An expert can usually spot the difference between a fake charge and a full one, but there are plenty of dead experts. -- National Geographic Channel, in a documentary about large African beasts. pgpFd1QMfATGB.pgp Description: PGP signature
Re: mailcap next step
W licie z czw, 15-05-2003, godz. 13:30, Wouter Verhelst pisze: I really think it would be a bad idea to go the alternatives road here. But why? Could you give me any reasons? I've said why yes, so you tell why not ;] If you must, you could write a front-end that parses /etc/mailcap, and for a given MIME type, allows a user to pick the application of his/her choice; the front-end could then write that to ~/.mailcap. It won't work, because the aren't any 'standards'. I don't have idea how make x/non-x choice from mailcap. I REALLY think alternatives could be good. Regards, Marcin -- .---, --: mcINEK :-- / ,. \ ' T h e O w l s a r e n o t | | ; ;W h a t T h e y S e e m . . . ' \ `._ /wrote on Debian GNU/Linux SID signature.asc Description: PGP signature
Re: mailcap next step
On Thu, 15 May 2003 12:11:03 +0200, mcINEK wrote: [...] We see a conflict. It doesn't matter how many browser user installed, always will be run galeon (it's above so it's first - am I right?). The best solution, I think, is that galeon (mozilla, etc) shouldn't provide a /etc/mailcap record, but just alternatives. And then in /etc/mailcap should be (just ONE) record, like (sorry, I don't know syntax) Assuming you think one setting for all users is enough, you already have a solution: man mailcap.order Otherwise ~/.mailcap is the way to go, as has been already suggested. -- Micha Politowski -- [EMAIL PROTECTED] Warning: this is a memetically modified message
Re: mailcap next step
On Thu, May 15, 2003 at 01:35:22PM +0200, mcINEK wrote: W li?cie z czw, 15-05-2003, godz. 13:30, Wouter Verhelst pisze: I really think it would be a bad idea to go the alternatives road here. But why? Could you give me any reasons? I've said why yes, so you tell why not ;] Alternatives are meant for something else. I could want to run a small HTML viewer when I get a HTML-encoded mail, but could want to run mozilla or konqueror as my 'default' webbrowser, when an other application tries to run one. Yes, you could create /another/ alternative for /every/ MIME type in your mailcap, but that would bloat the alternatives system. Also, going the alternatives way would result in a *lot* of work (you'd have to remove all other mailcap entries, since they'd conflict with your work), and would not really be an improvement, since only the sysadmin could change preferences, and users would still be where they are today: having to copy lines from /etc/mailcap to ~/.mailcap. Worse; now they can copy lines; then, they'd have to edit them to be useful, else they'd /still/ run the sysadmin's preferences. Alternatives and mailcap are two different worlds. Please keep them separated. If you must, you could write a front-end that parses /etc/mailcap, and for a given MIME type, allows a user to pick the application of his/her choice; the front-end could then write that to ~/.mailcap. It won't work, because the aren't any 'standards'. I don't have idea how make x/non-x choice from mailcap. I REALLY think alternatives could be good. It's done in there, all over the place! There's a 'test' option, which is meant to use a line conditionally; it's commonly used to test whether $DISPLAY is set, which is *exactly* what you need. -- Debian GNU/Linux -- http://www.debian.org Nederlandstalige Linux-documentatie -- http://nl.linux.org An expert can usually spot the difference between a fake charge and a full one, but there are plenty of dead experts. -- National Geographic Channel, in a documentary about large African beasts. pgpEjFHyNsreI.pgp Description: PGP signature
Re: conflicts-based solution (was Re: security in testing)
On Thu, May 15, 2003 at 11:13:59AM +0200, Sven Luther wrote: On Thu, May 15, 2003 at 09:03:06PM +1000, Anthony Towns wrote: On Thu, May 15, 2003 at 08:09:48AM +0200, Sven Luther wrote: On Thu, May 15, 2003 at 01:13:19PM +1000, Anthony Towns wrote: On Wed, May 14, 2003 at 07:12:15PM -0400, Joey Hess wrote: Take the harden package, or create something similar: a package that conflicts with all versions of packages with known security holes. Why not just /fix/ the holes? Is uploading a package with a well known patch _really_ that hard? The fact is, we don't have a security architecture, or even autobuilders for testing, Uh, actually, we have both these things. We've had them for almost a year now, although they haven't been used. So, the infrastructure is there, but not turned on ? No, it's sitting there, waiting for someone to use it. After a year's neglect it might need some metaphorical oil on its hinges and some dusting, but it really is there. I'm not just saying this for rhetorical value. Cheers, aj -- Anthony Towns [EMAIL PROTECTED] http://azure.humbug.org.au/~aj/ I don't speak for anyone save myself. GPG signed mail preferred. ``Dear Anthony Towns: [...] Congratulations -- you are now certified as a Red Hat Certified Engineer!'' pgpRc4xTImQn5.pgp Description: PGP signature
Re: mailcap next step
W licie z czw, 15-05-2003, godz. 13:49, Wouter Verhelst pisze: Alternatives and mailcap are two different worlds. Please keep them separated. OK, so leave alternatives. It won't work, because the aren't any 'standards'. I don't have idea how make x/non-x choice from mailcap. I REALLY think alternatives could be good. It's done in there, all over the place! There's a 'test' option, which is meant to use a line conditionally; it's commonly used to test whether $DISPLAY is set, which is *exactly* what you need. No, it doesn't. There can be more tjan one line describing the same mime type. And what then? Solving this problem will be sorting content of /usr/lib/mime/packages by appropiate types, such as: /usr/lib/mime/packages/text-html/mozilla, content (example): x,/usr/bin/mozilla /usr/lib/mime/packages/text-html/links content: text,/usr/bin/mozilla And on that base update-mime can generate /etc/mailcap. Of course if they'd be more browsers it only can choose one, but in the present time it's the same. If there'd be a types tree like that making front-end will make sense, otherwise no. User'd choose a program from that directory structure. Regards, Marcin -- .---, --: mcINEK :-- / ,. \ ' T h e O w l s a r e n o t | | ; ;W h a t T h e y S e e m . . . ' \ `._ /wrote on Debian GNU/Linux SID signature.asc Description: PGP signature
Re: Do not touch l10n files
On Thu, May 15, 2003 at 12:04:14PM +0100, Thom May wrote: Ok, I've been trying to stay out of this as much as possible, since I think Denis' original post: So I would like to ask developers not to edit l10n files (templates, PO files, etc) themselves; if you believe that something goes wrong, notify the translator or his translation team (or any other trusted person). If you disagree, think twice before applying your changes, you are certainly wrong. is exactly what we did. I'm sorry that an aparently simple request has descended into mud-slinging and general hostility, but it certainly wasn't our intention. I'm also quite upset to see off hand insults - I've never claimed to know what a foreign language should look like, what we've asked is for a rational explanation as to why when we removed a single character, (a 3 as it happens) the layout of the french translation changed dramatically and to a form that the maintainers do not view as ideal. It has already been told more than once: in French, an itemized list is preferred over a comma separated list when it gives a very long sentence. Denis
Re: Do not touch l10n files
* Denis Barbier ([EMAIL PROTECTED]) wrote : On Thu, May 15, 2003 at 12:04:14PM +0100, Thom May wrote: I'm also quite upset to see off hand insults - I've never claimed to know what a foreign language should look like, what we've asked is for a rational explanation as to why when we removed a single character, (a 3 as it happens) the layout of the french translation changed dramatically and to a form that the maintainers do not view as ideal. It has already been told more than once: in French, an itemized list is preferred over a comma separated list when it gives a very long sentence. Now, preferred, in English, means more desirable than another not we must use this at all costs. So, again. We have said we don't like the layout and would *prefer* that the translators change it. -Thom
Re: mailcap next step
On Thu, May 15, 2003 at 02:13:32PM +0200, mcINEK wrote: It won't work, because the aren't any 'standards'. I don't have idea how make x/non-x choice from mailcap. I REALLY think alternatives could be good. It's done in there, all over the place! There's a 'test' option, which is meant to use a line conditionally; it's commonly used to test whether $DISPLAY is set, which is *exactly* what you need. No, it doesn't. There can be more tjan one line describing the same mime type. And what then? The first one will be used. Solving this problem will be sorting content of /usr/lib/mime/packages by appropiate types, such as: /usr/lib/mime/packages/text-html/mozilla, content (example): x,/usr/bin/mozilla /usr/lib/mime/packages/text-html/links content: text,/usr/bin/mozilla And on that base update-mime can generate /etc/mailcap. Of course if they'd be more browsers it only can choose one, but in the present time it's the same. You don't need to do that. Leave /etc/mailcap the way it is; system-wide preferences wrt default applications suck anyway :-) If there'd be a types tree like that making front-end will make sense, otherwise no. User'd choose a program from that directory structure. Uh. You can create such a tree in-memory, no? Parsing the file is not *that* hard. -- Debian GNU/Linux -- http://www.debian.org Nederlandstalige Linux-documentatie -- http://nl.linux.org An expert can usually spot the difference between a fake charge and a full one, but there are plenty of dead experts. -- National Geographic Channel, in a documentary about large African beasts. pgpcIpVqYnnIK.pgp Description: PGP signature
Re: DebConf 3 for New Maintainers
* Colin Watson | (I'm not involved with the organization, though. Tollef, do you know | if there'll be wireless base stations around or, will we be doing | ad-hoc mode?) The area is covered with WLANs already, but we'll have a few switches for people who don't have wireless. -- Tollef Fog Heen,''`. UNIX is user friendly, it's just picky about who its friends are : :' : `. `' `-
Re: mailcap next step
W licie z czw, 15-05-2003, godz. 14:30, Wouter Verhelst pisze: Uh. You can create such a tree in-memory, no? Parsing the file is not *that* hard. Of course, I can. But I don't understand why don't improve BAD mechanism. If sth is bad and doesn't pass our requests we should change it. Is update-mime a 'holy cow'? Nevertheless if it's just my opinion I won't argue and don't touch anything. Regards, Marcin -- .---, --: mcINEK :-- / ,. \ ' T h e O w l s a r e n o t | | ; ;W h a t T h e y S e e m . . . ' \ `._ /wrote on Debian GNU/Linux SID signature.asc Description: PGP signature
Re: conflicts-based solution (was Re: security in testing)
On Thu, May 15, 2003 at 10:26:35PM +1000, Anthony Towns wrote: On Thu, May 15, 2003 at 11:13:59AM +0200, Sven Luther wrote: On Thu, May 15, 2003 at 09:03:06PM +1000, Anthony Towns wrote: On Thu, May 15, 2003 at 08:09:48AM +0200, Sven Luther wrote: On Thu, May 15, 2003 at 01:13:19PM +1000, Anthony Towns wrote: On Wed, May 14, 2003 at 07:12:15PM -0400, Joey Hess wrote: Take the harden package, or create something similar: a package that conflicts with all versions of packages with known security holes. Why not just /fix/ the holes? Is uploading a package with a well known patch _really_ that hard? The fact is, we don't have a security architecture, or even autobuilders for testing, Uh, actually, we have both these things. We've had them for almost a year now, although they haven't been used. So, the infrastructure is there, but not turned on ? No, it's sitting there, waiting for someone to use it. After a year's neglect it might need some metaphorical oil on its hinges and some dusting, but it really is there. I'm not just saying this for rhetorical value. Ok, i had the impression this was not the case, but then, maybe i misremembered or something such. So, the right and easy solution for the samba security bug is to upload the source package to testing-proposed-update, and it will get rebuild on all testing supported architectures in time. What happens then, will it stay apart, or get transitioned into testing when all arches have rebuilt ? I suppose a testing pbuilder or something such would be needed for the initial upload and not pure source, since we don't have a arch: all autobuilder. What about version numbers ? Should the same version number as the unstable package be used, or only the minor debian version number be bumped, with maybe an additional testing or security part ? Also, should we use this only for security fixes, or also for other RC bugs or even non RC bugs ? Where is the limit and if there is one, who will enforce it ? Friendly, Sven Luther
Re: possible problem for debian was [NTP considered basic] misc@openbsd.org
On Thu, May 15, 2003, Uwe A. P. Wuerdinger wrote: I just catched this conversation on the misc OpenBSD mailinglist. Does this in any way afflict debian? This subject has already been discussed forever on debian-legal. The general consensus is that without fee does not mean you may redistri- bute as long as it is without a fee but rather the rights are granted to you without having to pay a fee to the author. See for instance: http://lists.debian.org/debian-legal/1999/debian-legal-199908/msg00049.html Or search the -legal archives for without a fee. Regards, -- Sam.
Re: security in testing
* Matthias Urlichs ([EMAIL PROTECTED]) wrote: Hi, Stephen Frost wrote: (a) Before I do something like that, I'd need to be accepted as DD. False statement. So non-DDs can get accounts on Debian machines to setup something like this (install FTP directories, setup autobuilders, etc.)? You can set up your own, you don't need access to Debian machiens to build security updates and make them available for testing. If that's so, cool, I'll have free time in two weeks or so. Great, glad to hear it. I assume debian-admin are the correct people to talk further. If you need space to host the site I may be willing to help you out once you've shown that you're producing something. Stephen pgpSwH7ACxNQ3.pgp Description: PGP signature
Re: security in testing
On Wed, May 14, 2003 at 05:37:51PM -0700, Keegan Quinn wrote: Hmm. Funny how myself and every admin I know have only very minor issues with running unstable. What, pray tell, makes it such an 'obvious' non-option for end users? Well-timed unstable snapshots are often more 'stable' than commercial Linux releases, in my limited experience. As you say, mostly unstable is just fine but... Sure, every now and then a badly-broken package makes it in for a day or two. This seems to be far less harmful than the massive headache that treating 'testing' as a usable release seems to be causing. ...when things go wrong they can *really* go wrong. I've had my system rendered unbootable by unstable packages before and while I've not had a problem coping with things yet I'd not J. Random User to cope. You'll also find that applications can be completely broken for extended periods of time in unstable which is a tad inconvenient if you're trying to use them (for example, gnucash has been segfaulting on startup on PowerPC for a while now). Again, I can cope but I don't think it's a good idea to suggest people run it without giving the matter some thought. One of the things that people were hoping for with testing when it was first introduced was that the crippling bugs where thing just don't work would get caught before things hit testing. If testing were actually getting prompt updates most of the time that'd make it a slightly less current alternative to unstable with much reduced risk of something overly nasty happening. Most of the problems that have come up (like the big holdups) weren't as widely discussed. -- You grabbed my hand and we fell into it, like a daydream - or a fever.
Re: Where are translated man pages packaged?
On Thu, May 15, 2003 at 11:09:08AM +0100, Colin Watson wrote: I think it is proper to include translated man pages with original man pages, and to use apt-localepurge (now) or dpkg exclusions (when they're implemented) if people are worried about space. My gut feeling is that I believe this was the consensus in the last big translation discussion - where possible translations should be integrated with the package being translated. This has been happening again with Debconf templates, for example. -- You grabbed my hand and we fell into it, like a daydream - or a fever.
Re: DebConf 3 for New Maintainers
Le jeu 15/05/2003 à 14:49, Tollef Fog Heen a écrit : The area is covered with WLANs already, but we'll have a few switches for people who don't have wireless. Side question: will there be a few machines for people who can't bring a laptop ? -- .''`. Josselin Mouette/\./\ : :' : [EMAIL PROTECTED] `. `'[EMAIL PROTECTED] `- Debian GNU/Linux -- The power of freedom signature.asc Description: PGP signature
Re: mailcap next step
On Thu, May 15, 2003 at 02:46:34PM +0200, mcINEK wrote: W li?cie z czw, 15-05-2003, godz. 14:30, Wouter Verhelst pisze: Uh. You can create such a tree in-memory, no? Parsing the file is not *that* hard. Of course, I can. But I don't understand why don't improve BAD mechanism. I fail to see why it would be bad. It's not perfect, but that's far from the same thing. Moreover, I think your ideas would make things worse, rather than better. If sth is bad and doesn't pass our requests we should change it. Is update-mime a 'holy cow'? Certainly not. -- Debian GNU/Linux -- http://www.debian.org Nederlandstalige Linux-documentatie -- http://nl.linux.org An expert can usually spot the difference between a fake charge and a full one, but there are plenty of dead experts. -- National Geographic Channel, in a documentary about large African beasts. pgpM5KEp94Ay2.pgp Description: PGP signature
Re: security in testing
On Thu, May 15, 2003 at 08:52:26AM -0400, Stephen Frost wrote: * Matthias Urlichs ([EMAIL PROTECTED]) wrote: Hi, Stephen Frost wrote: (a) Before I do something like that, I'd need to be accepted as DD. False statement. So non-DDs can get accounts on Debian machines to setup something like this (install FTP directories, setup autobuilders, etc.)? You can set up your own, you don't need access to Debian machiens to build security updates and make them available for testing. You again forget that debian is not x86 only, or do you expect Matthias to have access to machines of all the supported arches ? Friendly, Sven Luther
Re: security in testing
On Thu, May 15, 2003, someone calling themselves LapTop006 wrote: On Wed, May 14, 2003 at 11:59:49PM -0400, Matt Zimmerman arranged a set of bits into the following: There are no mirrors of security.debian.org, and have not been for as long as I have been aware. See the security team FAQ. FALSE. Official mirrors. I should have known someone would jump on this. -- - mdz
Re: mailcap next step
W licie z czw, 15-05-2003, godz. 15:23, Wouter Verhelst pisze: I fail to see why it would be bad. It's not perfect, but that's far from the same thing. Moreover, I think your ideas would make things worse, rather than better. It's not perfect. Importand bugs are for me: * doesn't allow to choose what program use * it skip more than one application for one type Our task is to think, when it would be good, and what we're gonna do. Of course, we can leave it as it is now, but then we won't go further in making Debian better and more and more useful. Regards, Marcin -- .---, --: mcINEK :-- / ,. \ ' T h e O w l s a r e n o t | | ; ;W h a t T h e y S e e m . . . ' \ `._ /wrote on Debian GNU/Linux SID signature.asc Description: PGP signature
Re: Do not touch l10n files
On Thu, May 15, 2003 at 07:32:55AM +0200, Christian Couder wrote: The situation is very different from the situation maintainer face with upstream code because in fact apt should be able to install l10n packages related to a given program package when it installs the program package. So if l10n materials are currently integrated into program packages, instead of being in separate l10n packages, it's because of this lack in apt. It's not because the program package maintainer should also be responsible for l10n stuff related to the program, like he is responsible for the code in the program. I'm sure the apt maintainers will be happy to know you think the inclusion of debconf template translations in packages indicates a deficiency in their code. -- Steve Langasek postmodern programmer pgpBkZdv65Y5I.pgp Description: PGP signature
Re: Bug marked as done messages to-be-MIMEified?
On Wed, May 14, 2003 at 11:27:07PM +0100, Darren Salt wrote: so maybe it was actually only filed in my brain (which has no web interface) ... We need a bug system for developer's brains. Agreed... $ mail [EMAIL PROTECTED] -s Misplacement of apostrophes Package: doogie developers' brains, surely. Cc: $ ;-) But... maybe the developer in question really has 1 brain. (Incidentally, that might explain a few other things as well :) -- 2. That which causes joy or happiness.
Re: Do not touch l10n files
On Thu, May 15, 2003 at 01:25:56PM +0100, Thom May wrote: * Denis Barbier ([EMAIL PROTECTED]) wrote : On Thu, May 15, 2003 at 12:04:14PM +0100, Thom May wrote: I'm also quite upset to see off hand insults - I've never claimed to know what a foreign language should look like, what we've asked is for a rational explanation as to why when we removed a single character, (a 3 as it happens) the layout of the french translation changed dramatically and to a form that the maintainers do not view as ideal. It has already been told more than once: in French, an itemized list is preferred over a comma separated list when it gives a very long sentence. Now, preferred, in English, means more desirable than another not we must use this at all costs. So, again. We have said we don't like the layout and would *prefer* that the translators change it. Following your definition of prefer, you ask us to change it, but will accomodate otherwise. This is fine with me, let's see what the translator will decide. Denis
Re: mailcap next step
On Thu, May 15, 2003 at 03:35:33PM +0200, mcINEK wrote: W li?cie z czw, 15-05-2003, godz. 15:23, Wouter Verhelst pisze: I fail to see why it would be bad. It's not perfect, but that's far from the same thing. Moreover, I think your ideas would make things worse, rather than better. It's not perfect. Importand bugs are for me: * doesn't allow to choose what program use Yes it does. Create a ~/.mailcap with the application of your choice for a given MIME-type at the top. My suggestion of a front-end was to create some application that would help $USER to manage ~/.mailcap. * it skip more than one application for one type That's actually the same thing as above, unless I don't understand what you mean. Our task is to think, when it would be good, and what we're gonna do. Of course, we can leave it as it is now, but then we won't go further in making Debian better and more and more useful. Please point me to where I said we should leave things as they are. -- Debian GNU/Linux -- http://www.debian.org Nederlandstalige Linux-documentatie -- http://nl.linux.org An expert can usually spot the difference between a fake charge and a full one, but there are plenty of dead experts. -- National Geographic Channel, in a documentary about large African beasts. pgpLZhMBTb0Bp.pgp Description: PGP signature
Re: security in testing
On Thu, May 15, 2003 at 03:19:02PM +1000, Anthony Towns wrote:
On Wed, May 14, 2003 at 11:59:49PM -0400, Matt Zimmerman wrote:
Do you honestly think would be a good idea to use testing-security this way
on a continual basis?
Yes, I do. I think we should release DSA's for security problems in
testing, too.
There's that we again. Why not unstable, too? Round it out to a nice,
even four distributions to simultaneously support, and 40 or so
distribution*architectures. As if it doesn't take enough time already.
Such an endeavor would not seem to require any of the facilities which
make foo-security different from foo{,-proposed-updates}.
The same applies to stable: the key differences are immediacy,
announcements and control, all of which are equally valuable for testing
as stable.
No, it is not at all the same as stable. The problem that is being
discussed in this thread is the presence of known, publicized security holes
in testing.
In any event, testing-proposed-updates exists and works at
present, the only thing missing is people reliably uploading to it, and
evaluating whether uploads work well enough to be included in testing
or not. All the technical issues have already been addressed.
In that case, I invite any maintainer with a security fix for their package
in 'testing' to upload it to testing for testing-proposed-updates. Problem
solved. Are you the one who will be responsible for reviewing the packages?
Except that there can be no testing users while we don't provide security
updates. Using testing on a multi-user machine, or one that provides any
network services on a machine connected to the network is not something
anyone can recommend in good conscience, and that rules out almost
everything Debian's actually good at.
This does not trouble me in the least.
Sidestepping the process to provide this kind of timely security update
for unreleased software, on the other hand, doesn't seem particularly
valuable to me.
What, precisely, is unreleased about it?
release
programming (Or released version, baseline) A version of
a piece of software which has been made public (as opposed to
a version that is in development, or otherwise unreleased).
A release is either a {major release}, a {revision}, or a
{bugfix}.
Pre-release versions may be called {alpha test}, or {beta
test} versions.
See {change management}.
released, as in no longer under development, as in not changing on a
DAILY BASIS (as testing does), and so actually supportable. testing is a
moving target.
--
- mdz
Re: security in testing
On Wed, May 14, 2003 at 05:53:50PM -0400, Don Armstrong wrote: Manoj's answer, while witty, is closer to the mark than you may realize. Debian will always be for whoever the people contributing to Debian are willing/want it to be for. No more, no less. Um, when we all agreed to be Debian Developers, we agreed to the following from the social contract: * Our Priorities are Our Users and Free Software We will be guided by the needs of our users and the free-software community. We will place their interests first in our priorities. We will support the needs of our users for operation in many different kinds of computing environment. So what does that mean? If the we define our users as ourselves, then the social contract reduces to we will place our interests first in our priorities, and that doesn't sound so good, does it? :-) If our users include those who want something that is less stale than stable, but where they don't want to deal with having to stich together their system after an update to perl or lilo leaves their system completely unusable, how do we meet their needs? There are certainly disagreements at the tactical level (we could solve this problem by applying pressure to people to not upload broken packages to unstable; we could solve the problem by fixing enough RC bugs that packages flow into testing much more reliably and quickly; we could solve the problem by recruiting people to upload into testing-security). But the first question before we discuss tactics is whether or not we should do it. Does the fact that we've accept the Social Contract put any kind of moral claim on what we as an organization do? If the question to that question is yes, then individual developers will need to search their souls and decide whether or not this means they are feeling called to put in the time to fix an RC bug, or work to NMU or otherwise clear a blocked, critical package, or contribute to security or testing-security, or do something else to further the goal. I'd argue that the converse is more important. [Unless most developers do everything they do for purely altruistic reasons. I know I do what I do for selfish reasons first.] That may be true, but the ideals articulated in the Social Contract aspire to something a higher more than that. - Ted
Re: mailcap next step
W licie z czw, 15-05-2003, godz. 15:42, Wouter Verhelst pisze: Yes it does. Create a ~/.mailcap with the application of your choice for a given MIME-type at the top. My suggestion of a front-end was to create some application that would help $USER to manage ~/.mailcap. I think it's good idea too. It could be done even now. But that what I'm trying to say, is we shouldn't use long ways. Solution you suggested is a 'little bubble' which you wan't stick to exist mechanism. I will work, however, it's just a bypass. It's a fine frontend to ulgy mechanism, which indeed doesn't work (if you have to parse generated file, it doesn't work). The clue is to think about efficient mechanism, which works globally and can be adapted by user in *simple* ways (not by a giant/slow script which parse conf file). Please point me to where I said we should leave things as they are. You didn't say that, but you want use *minimal* solution, which aren't always good. PS1. Windows are done this way. MS created took w2k and sticked more,more and more programmic 'bubbles' and created one big shit :) PS2. Maybe I wrote my definition of 'bubble': 'Bubble' is a short code, which you can put(stick) to original code without changing anything. Regards, Marcin -- .---, --: mcINEK :-- / ,. \ ' T h e O w l s a r e n o t | | ; ;W h a t T h e y S e e m . . . ' \ `._ /wrote on Debian GNU/Linux SID signature.asc Description: PGP signature
Re: security in testing
On Wed, May 14, 2003 at 05:37:51PM -0700, Keegan Quinn wrote: Sure, every now and then a badly-broken package makes it in for a day or two. This seems to be far less harmful than the massive headache that treating 'testing' as a usable release seems to be causing. Something that would make unstable much more useful is if dpkg had a reliable undo capability. It's unpleasant when you update a broken package, and large number of packages break, and you can't necessarily find a copy of the older, non-broken version of the package to re-install. If you're not a developer, you don't have access to archives, so your choice is to either go back to the stable or testing version of the package, or try to find a mirror that still has the n-1 release of the unstable package. So simply making it easier for people to get a previous version of a package when the current version in unstable is borked would probably take away many of the reasons why people might want to use testing instead of unstable. The harder disaster scenario to deal with is when after an update, your system is so totally borked that recovering requires use of a rescue disk, or other manual interventions. As I mentioned, there was a time some years ago, when I was first getting involved with Debian, where broken perl uploads (which broke dpkg so it was painful to back out of such a situation), and broken lilo uploads. Both were screwing up my system to such an extent that I was spending far more time than I liked doing manual wizardry just to get my system back to a recoverable state. At the time, when I whined and complained, the response I was given from my Debian mentors at time was to use the testing distribution instead. (I was also told, jokingly, that the all of the LILO breakages was because the lilo maintainer was really a secret GRUB supporter, and was breaking LILO just to get people to convert over to GRUB, and that I should just get with the program and switch over to GRUB. :-) But now people are saying that using testing is a bad thing. Part of the problem is that different people have very different ideas about exactly what testing is useful for. Hmm. Funny how myself and every admin I know have only very minor issues with running unstable. What, pray tell, makes it such an 'obvious' non-option for end users? Well-timed unstable snapshots are often more 'stable' than commercial Linux releases, in my limited experience. Clearly you didn't use unstable when I did several years ago, or you're just remembering those days through rose-colored glasses. :-) But seriously, if the right answer is that people just shouldn't be using testing, we should say that, in big letters. And then perhaps there ought to be tools that make it easier for someone to get their system functioning again after an unstable package update leaves them screwed over. Ideally, that should never happen, but hey, people make mistakes. We just need a way to make sure that such mistakes are recoverable. - Ted
Proposal of removing MOSIX stuff
Hi all Currently we have both OpenMosix and Mosix in our main archive. See http://openmosix.sourceforge.net/ and http://www.mosix.com/ for background information. Both software provide the same features for clustering (but IMHO OpenMosix is more actively developed and has more prospectives, e.g. ia64 support). Historically, OpenMosix has been a fork of Mosix, when Prof. Barak changed license into a proprietary one :-/ The OM project leader Moshe Bar was the co-author of Mosix. Currently, Mosix should be removed from main, because http://www.mosix.com/LICENSE denies redistribution of modifications without author's permission. OpenMosix is fully GPL, instead. I'm simply proposing the complete removing of mosix from archive, if none could adopt it and manage properly its moving in non-free. Ciao -- Francesco P. Lovergine pgpi5sg3X0F01.pgp Description: PGP signature
Re: DebConf 3 for New Maintainers
On 14 May 2003, Joachim Breitner wrote: I would recommend this. When I was in Bordeaux in 2000 without my own Laptop it was much less fun. :-( The educational effect decreases drastically! Well, that sould definatly interesting. I just hope I manage to get a laptop 'till then. Or would you think a zaurus with debian is sufficient :-) (Actually, why not: One might allow me to ssh on his machine so I can actually compile stuff *g*) Honestly: I do not know Zaurus except that I had my hands on it for a minute (which was quite impressive). But I think it could be a very intersting test to install and use Debian on it. I think the problem is that for most bugs you need either very deep knowledge of the program or of some language or (mostly) both. Definitely not. Just have a deeper look and you will find that many bugs are easy to fix. (If you would know my limited skills and compare it with the bugs I fixed in Bordeaux you would believe me. ;-)) ) So if you can't do much C, a lot of bug fixing is out of your reach. Well, maybe I can find some bugs I can fix with perl or shell etc until then. You will find those und probably others which are easy to fix. Kind regards Andreas.
Re: security in testing
Hi,
Sven Luther wrote:
You again forget that debian is not x86 only, or do you expect Matthias
to have access to machines of all the supported arches ?
Right.
Besides, I don't want to do this on my own, I want to do this as part of
Debian. I don't yet know enough about the setup of testing-proposed-updates
and the whole build structure in general to see clearly what needs to be done
to automate the process, or indeed whether the people responsible for it
would be OK with enhancing that along the lines of my proposal; my impression
is that t-p-o is mostly processed manually at the moment, like
stable-proposed-updates is, and it's under-used (t-p-o/main has a whopping
TWO source packages). That may be a chicken-and-egg problem.
In other words, I don't want to reinvent any wheels -- I want to help make the
existing wheels run more smoothly.
Anyway, I plan to start learning how to do this by setting up an autobuilder
for m68k (the machine which replaces my broken IIfx (you have no idea how
corrosive a run-down-and-leaking battery is -- I'll put some pics on my
homepage later today :-/ ) should arrive tomorrow.) and proceed from there.
--
Matthias Urlichs | {M:U} IT Design @ m-u-it.de | [EMAIL PROTECTED]
Disclaimer: The quote was selected randomly. Really. | http://smurf.noris.de
--
I've been WRITING to SOPHIA LOREN every 45 MINUTES since JANUARY 1ST!!
-- Zippy the Pinhead
Re: mailcap next step
On Thu, May 15, 2003 at 04:05:28PM +0200, mcINEK wrote: Please point me to where I said we should leave things as they are. You didn't say that, but you want use *minimal* solution, which aren't always good. PS1. Windows are done this way. MS created took w2k and sticked more,more and more programmic 'bubbles' and created one big shit :) What's that supposed to mean? Doing that does have its advantages, too (such as you don't have to re-integrate everything with the new system). Granted, pushing that to extremes will end you up with an unworkable system with hundreds of incompatible API's. That's not what this does. -- Debian GNU/Linux -- http://www.debian.org Nederlandstalige Linux-documentatie -- http://nl.linux.org An expert can usually spot the difference between a fake charge and a full one, but there are plenty of dead experts. -- National Geographic Channel, in a documentary about large African beasts. pgpMuVzjax1Di.pgp Description: PGP signature
Michael-John Turner MIA? (was: Debian MIA check)
On Tue 13 May 2003, James Troup wrote: Of the 191 pings were sent out: o 34 people's ping bounced[1]. o 28 people replied asking to be retired. o 29 people replied with various different responses. o 10 people replied who were active. o 90 people didn't reply within the 2 month deadline[2]. I've not had any response to a message I sent Michael-John Turner [EMAIL PROTECTED] a couple of months ago, asking him about his status. However, I don't see him on James' list. According to echelon he's not been seen since 10 Feb 2002. It's about bugs in mrtg that caused me to look for him. It may be necessary to hijack his packages if he is in fact MIA. A search on Google doesn't show any recent activity either. Paul Slootman pgpBUYYSNPpCQ.pgp Description: PGP signature
Re: Bug marked as done messages to-be-MIMEified?
Adrian 'Dagurashibanipal' von Bidder [EMAIL PROTECTED] writes: Q: is content-disposition handled properly, especially for messag/rfc822 type attachments? (Or if not, are message attachments displayed inline by default?) Gnus: yes (since 5.8.0, the first MIME-aware version) (Yes, I've stopped caring about users of a certain other widespread MUA, as you've probably guessed anyway when you notice me using PGP/MIME to sign messages...) I'm not actually clear how much this is a good thing; at some level, we do want people reporting bugs. (Though at the same level, we also want them reading and using debian-user, and get a real MUA is a common sentiment there.) But yeah, its unnamed inbound MIME handling is pretty terrible; content-disposition is completely ignored, so if I attach a file to mail, the recipient sees my .signature as a separate attachment... -- David Maze [EMAIL PROTECTED] http://people.debian.org/~dmaze/ Theoretical politics is interesting. Politicking should be illegal. -- Abra Mitchell
Re: mailcap next step
W licie z czw, 15-05-2003, godz. 16:38, Wouter Verhelst pisze: What's that supposed to mean? Doing that does have its advantages, too (such as you don't have to re-integrate everything with the new system). Granted, pushing that to extremes will end you up with an unworkable system with hundreds of incompatible API's. That's not what this does. But only if this API is good. If API is wrong and don't have support for new useful options, should be changed or improved. API is a solid, stable base for building additions, however, it must be simple and thought over. Besides, it's not such a basic feature, which requires change system core. Regards, Marcin -- .---, --: mcINEK :-- / ,. \ ' T h e O w l s a r e n o t | | ; ;W h a t T h e y S e e m . . . ' \ `._ /wrote on Debian GNU/Linux SID signature.asc Description: PGP signature
Re: security in testing
On Wed, May 14, 2003 at 10:19:08AM -0400, Matt Zimmerman wrote: If unstable has a fix for the bug, then it is a waste of time to work on testing because users can just upgrade. If unstable does not have a fix for the bug, then it is still a waste of time because unstable needs to be fixed anyway, and that package will replace the one in testing once it has survived in unstable. I don't disagree. Thats why I didn't suggest a policy of creating patched versions for testing. Instead, simply remove and inform the user that it's a problem. What value does this provide for the users? It may incite them to complain to the maintainer, who might (if they are active) try to get a fixed version into testing, and disrupt their work, but this is not a good way to motivate maintainers. As for the user's security, this is like amputating a limb as treatment for a fracture. *My* primary goals are to protect Debian's (and the maintainer's) reputation, and to fulfill my civic duty to not increase the number of compromised machines in the world being used to clog the Internet. The needs of people trying to use testing for production use contrary to all admonitions are secondary, IMHO; and by the sound of things, making testing less suitable for the casual user in the process might be a benefit, not a detriment. - I believe that people who are willing to run the testing distribution are happy to assume the risk of problematic packages and broken packaging - and are in usually happy to contribute bug reports where appropriate. - I also believe that the majority of these people are NOT willing to accept this risk when it comes to known security issues. They're happy to deal with packages not working right, or the inability to install something for various reasons, but they're not willing to have their box compromised. The people I know who run testing do it on single-user or trusted-users-only machines, on rather tightly controlled local networks. They do not notice or care about security problems for the most part. We can both hypothesize about testing users in general, but our guesses don't carry much weight unless they are backed up by real data from a significant number of real users. I am not hypothesizing. I am getting reports from and about people who are running the version of Samba from testing, whose machines have been compromized because they were exposed to the Internet. Given that the only users of testing I know are those I hear about through such reports, if I *were* to extrapolate, my conclusions about testing's userbase would be quite different from yours; but the real point is that there is a non-zero number of users who have been compromised by the Samba vulnerability, that I cannot turn around to and say you should have known better in good conscience because we as a community are sending mixed signals to our users about testing's suitability. It makes no difference to me personally *which* way we clarify the matter, but I think the lack of consensus is a serious problem. There are already very clear statements about this. http://www.debian.org/releases/ testing The ``testing'' distribution contains packages that haven't been accepted into a ``stable'' release yet, but they are in the queue for that. The main advantage of using this distribution is that it has more recent versions of software, and the main disadvantage is that it's not completely tested and has no official support from Debian security team. Out of curiosity, what *un*official support does testing receive from the Debian security team? This statement on the website does a rather weak job of capturing the true state of affairs, IMHO, if maintainers offering to prepare testing security uploads for their packages are being turned away. -- Steve Langasek postmodern programmer pgpQn9hzlDoJx.pgp Description: PGP signature
Re: partimage on powerpc
Hi, Sergio Rua wrote:
# partimage
Error: volume hedaer size != 512 (520)
This version has been compiled with an uncompatible version of
gcc.
I'll check. Sergio: Which source package from where, please?
--
Matthias Urlichs | {M:U} IT Design @ m-u-it.de | [EMAIL PROTECTED]
Disclaimer: The quote was selected randomly. Really. | http://smurf.noris.de
--
Why won't sharks eat lawyers? Professional courtesy.
Re: security in testing
On Thu, May 15, 2003 at 10:08:03AM -0400, Theodore Ts'o wrote: On Wed, May 14, 2003 at 05:37:51PM -0700, Keegan Quinn wrote: Sure, every now and then a badly-broken package makes it in for a day or two. This seems to be far less harmful than the massive headache that treating 'testing' as a usable release seems to be causing. Something that would make unstable much more useful is if dpkg had a reliable undo capability. It's unpleasant when you update a broken package, and large number of packages break, and you can't necessarily find a copy of the older, non-broken version of the package to re-install. If you're not a developer, you don't have access to archives, so your choice is to either go back to the stable or testing version of the package, or try to find a mirror that still has the n-1 release of the unstable package. It seems to me that this is one of the reasons for the existence of snapshot.debian.net. Cheers, -- Steve Langasek postmodern programmer pgpuRA6QkNQKc.pgp Description: PGP signature
Re: security in testing
On Thu, May 15, 2003 at 10:08:03AM -0400, Theodore Ts'o wrote: On Wed, May 14, 2003 at 05:37:51PM -0700, Keegan Quinn wrote: Sure, every now and then a badly-broken package makes it in for a day or two. This seems to be far less harmful than the massive headache that treating 'testing' as a usable release seems to be causing. Something that would make unstable much more useful is if dpkg had a reliable undo capability. It's unpleasant when you update a broken package, and large number of packages break, and you can't necessarily find a copy of the older, non-broken version of the package to re-install. If you're not a developer, you don't have access to archives, sure you do. snapshot.debian.net -- Debian GNU/Linux -- http://www.debian.org Nederlandstalige Linux-documentatie -- http://nl.linux.org An expert can usually spot the difference between a fake charge and a full one, but there are plenty of dead experts. -- National Geographic Channel, in a documentary about large African beasts. pgpLP3Up2zlQR.pgp Description: PGP signature
Re: security in testing
On Thu, May 15, 2003 at 10:08:03AM -0400, Theodore Ts'o wrote: package to re-install. If you're not a developer, you don't have access to archives, so your choice is to either go back to the stable or testing version of the package, or try to find a mirror that still With the pool system the old package will kick around on the mirrors for a while. Knowing that they're there is a bit of a trick, mind you. But now people are saying that using testing is a bad thing. Part of the problem is that different people have very different ideas about exactly what testing is useful for. I think some of this is that ideas have changed over time - when testing was new there were high hopes for what it could achieve that haven't been delivered on. -- You grabbed my hand and we fell into it, like a daydream - or a fever.
Re: mailcap next step
On Thu, May 15, 2003 at 04:53:32PM +0200, mcINEK wrote: W li?cie z czw, 15-05-2003, godz. 16:38, Wouter Verhelst pisze: What's that supposed to mean? Doing that does have its advantages, too (such as you don't have to re-integrate everything with the new system). Granted, pushing that to extremes will end you up with an unworkable system with hundreds of incompatible API's. That's not what this does. But only if this API is good. It is, IMHO. If API is wrong and don't have support for new useful options, Who says it doesn't? should be changed or improved. API is a solid, stable base for building additions, however, it must be simple and thought over. Besides, it's not such a basic feature, which requires change system core. No, but lots of applications use it. -- Debian GNU/Linux -- http://www.debian.org Nederlandstalige Linux-documentatie -- http://nl.linux.org An expert can usually spot the difference between a fake charge and a full one, but there are plenty of dead experts. -- National Geographic Channel, in a documentary about large African beasts. pgph9f3pasBML.pgp Description: PGP signature
