webbit
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. *) 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. *) 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. *) Mi sembra di capire che abbiamo fatto una buona raccolta di soldi per le magliette, e i CD. La macchina per masterizzare i CD sul luogo era una'idea buona. Sarebbe il caso di pubblicare le somme da qualche parte, in modo di essere 'trasparente' come organizzazione. *) 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. *) Altro? 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 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. *) 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. non mi sembra il caso di dire non andava bene, anche se siamo un'organizzazione a livello mondiale. *) 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? *) Mi sembra di capire che abbiamo fatto una buona raccolta di soldi per le magliette, e i CD. La macchina per masterizzare i CD sul luogo era una'idea buona. Sarebbe il caso di pubblicare le somme da qualche parte, in modo di essere 'trasparente' come organizzazione. domani mando tutto in lista. *) 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. *) 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. federico signature.asc Description: Questa parte del messaggio =?ISO-8859-1?Q?=E8?= firmata
Re: webbit
On May 15, Federico Di Gregorio [EMAIL PROTECTED] wrote: visto che non 1 degli iscritti mi ha mai mandato un messaggio per chiedermi ulteriori informazioni, mi sembra che la cosa non interessi. Concordo. Personalmente vedo webbit principalmente come un evento sociale, quindi in questa ottica l'interesse per uno straniero è bassino... -- ciao, | Marco | [969 ce9.VYL7fPlWY] pgpaZoLfls5ix.pgp Description: PGP signature
Gnome 2 dans SARGE
Bonjour, Ce n'est surement pas le lieu adquat pour poser cette question ... mais quelqu'un aurait-il une ide de la date de transition vers Gnome 2 pour Sarge ? Sinon, il y a des portages de Gnome2 pour Woody mais quid de sarge ??? Merci d'avance Marc Lorber
Re: Gnome 2 dans SARGE
Le Mercredi 14 Mai 2003 08:40, Marc Lorber a crit : Bonjour, Bonjour, Ce n'est surement pas le lieu adquat pour poser cette question ... mais quelqu'un aurait-il une ide de la date de transition vers Gnome 2 pour Sarge ? Sinon, il y a des portages de Gnome2 pour Woody mais quid de sarge ??? Le mieux, c'est d'aller voir sur le Systme de Suivi des Paquets l'adresse suivante : http://packages.qa.debian.org/common/index.html Tu pourras voir les bogue restant corriger et pourquoi le paquet n'est pas encore dans Sarge. -- Michel Grentzinger OpenPGP key ID : B2BAFAFA Available on http://www.keyserver.net
Re: Gnome 2 dans SARGE
* Marc Lorber [EMAIL PROTECTED] [2003-05-14 08:40] : Bonjour, Ce n'est surement pas le lieu adéquat pour poser cette question ... mais quelqu'un aurait-il une idée de la date de transition vers Gnome 2 pour Sarge ? Quand les règles d'inclusion des paquets relatifs à Gnome 2 seront satisfaites, donc pas de date précise. Sinon, il y a des portages de Gnome2 pour Woody mais quid de sarge ??? J'ai fait avant-hier soir un apt-get -t unstable install gnome nautilus sur une sarge (35 Mo à télécharger et 120 Mo à installer), ça s'installe correctement et ça fonctionne plutôt pas mal ensuite. Fred
Re: Gnome 2 dans SARGE
Le Mercredi 14 Mai 2003 10:11, Sven Luther a écrit : Le mieux, c'est d'aller voir sur le Système de Suivi des Paquets à l'adresse suivante : http://packages.qa.debian.org/common/index.html Tu pourras voir les bogue restant à corriger et pourquoi le paquet n'est pas encore dans Sarge. Et specialement le nouveau : http://bjorn.haxx.se/debian/ Te donnera une information bien plus clair que ce que tu peut obtenir a travers le PTS. C'est très bien cet outil !! Je ne connaissais pas, merci ! -- Michel Grentzinger OpenPGP key ID : B2BAFAFA Available on http://www.keyserver.net
Re: Gnome 2 dans SARGE
* Sven Luther [EMAIL PROTECTED] [2003-05-14 10:11] : On Wed, May 14, 2003 at 09:31:11AM +0200, Michel Grentzinger wrote: Le Mercredi 14 Mai 2003 08:40, Marc Lorber a écrit : Bonjour, Bonjour, Ce n'est surement pas le lieu adéquat pour poser cette question ... mais quelqu'un aurait-il une idée de la date de transition vers Gnome 2 pour Sarge ? Sinon, il y a des portages de Gnome2 pour Woody mais quid de sarge ??? Le mieux, c'est d'aller voir sur le Système de Suivi des Paquets à l'adresse suivante : http://packages.qa.debian.org/common/index.html Tu pourras voir les bogue restant à corriger et pourquoi le paquet n'est pas encore dans Sarge. Et specialement le nouveau : http://bjorn.haxx.se/debian/ Te donnera une information bien plus clair que ce que tu peut obtenir a travers le PTS. Justement, j'ai vérifié cela avant de répondre et cela ne donne pas AMA de résultats humainement lisibles pour gnome-core : il parle seulement de paquets non-installables, ce qui n'est pas très parlant si on ne connaît pas précisément les règles de testing (http://www.debian.org/devel/testing, la 5e règle). Fred
Re: Gnome 2 dans SARGE
On Wed, May 14, 2003 at 11:07:53AM +0200, Frédéric Bothamy wrote: * Sven Luther [EMAIL PROTECTED] [2003-05-14 10:11] : On Wed, May 14, 2003 at 09:31:11AM +0200, Michel Grentzinger wrote: Le Mercredi 14 Mai 2003 08:40, Marc Lorber a écrit : Bonjour, Bonjour, Ce n'est surement pas le lieu adéquat pour poser cette question ... mais quelqu'un aurait-il une idée de la date de transition vers Gnome 2 pour Sarge ? Sinon, il y a des portages de Gnome2 pour Woody mais quid de sarge ??? Le mieux, c'est d'aller voir sur le Système de Suivi des Paquets à l'adresse suivante : http://packages.qa.debian.org/common/index.html Tu pourras voir les bogue restant à corriger et pourquoi le paquet n'est pas encore dans Sarge. Et specialement le nouveau : http://bjorn.haxx.se/debian/ Te donnera une information bien plus clair que ce que tu peut obtenir a travers le PTS. Justement, j'ai vérifié cela avant de répondre et cela ne donne pas AMA de résultats humainement lisibles pour gnome-core : il parle seulement de paquets non-installables, ce qui n'est pas très parlant si on ne connaît pas précisément les règles de testing (http://www.debian.org/devel/testing, la 5e règle). As tu clicker sur le lien Expand uninstallable packages, qui te donne la liste complete des problemes, et notament le fait que gnome-vfs depende de fam, qui est bloque par kde 3 qui est a son tour bloque par perl, python et gcc 3.3, entre autre. Sinon, ecris a Björn Stenberg [EMAIL PROTECTED] et fait lui part de tes remarques, peut etre qu'il ajoutera une petite explication ou un lien vers la faq de testing. Personnellement j'espere voir cette page faire partie du PTS definitivement bientot. Amicalement, Sven Luther
[Ann] debian-bts-control.el
I rarely announce software, but this could be useful to DDs. Whenever I wanted to add tags or something to a bug report, I'd start my browser to http://www.debian.org/ - Bug Reports - Developers' information on manipulating bugs by email. Just to get the syntac right. So I wrote debian-bts-control.el, an Emacs interface to build the email messages. It knows all the commands and their options with TAB completions. If you want to try it, install `dpkg-dev-el' from unstable, and do: M-x debian-bts-control Subsequent invocations add a directive to the same email message. Hope you like it! Peter
Re: Debian MIA check
* Graham Wilson [EMAIL PROTECTED] [2003-05-13 21:50]: are you all also checking to see if people in the nm queue are still active? If they have not been approved by their AM yet, their AM will notice and put them on hold and eventually reject them. For those who have been approved by their AM, they have been pinged at some point more or less recently. also, what about people who have a package uploaded (they are listed in Maintainer), but havent started the nm process and dont seem to be active? Yeah, they are currently quite hard to track down. See http://lists.debian.org/debian-qa/2003/debian-qa-200301/msg00040.html for some comments on this. Eventually, I'd like to see sponsorship as a pre-stage to NM so those people would be recorded on nm.debian.org. -- Martin Michlmayr [EMAIL PROTECTED]
Re: The Debian Mentors Project
Hi, On Tue, 13 May 2003, Rene Engelhard wrote: And that looks like it is f*cked. Is this Depends: done manually? I do not thing dpkg-shlibdeps did that. Where is libc6? Actually i was only worried about the licence because i know it can't be there. We use it at work :-) Fabio -- Our mission: make IPv6 the default IP protocol We are on a mission from God - Elwood Blues http://www.itojun.org/paper/itojun-nanog-200210-ipv6isp/mgp4.html
Re: The Debian Mentors Project
Hi, On Tue, 13 May 2003, Emile van Bergen wrote: Hi, On Tue, May 13, 2003 at 10:16:38PM +0200, Fabio Massimo Di Nitto wrote: I think upload must be moderated somehow. Even the uploader himself claim that he is unsure about licence of the product. Well, if the packages can only be downloaded by registered DDs, then the problem's solved I'd say? Yes probably it is. Leaving the upload free and let only DDs download is a solution. Fabio -- Our mission: make IPv6 the default IP protocol We are on a mission from God - Elwood Blues http://www.itojun.org/paper/itojun-nanog-200210-ipv6isp/mgp4.html
Re: The Debian Mentors Project
Hi, On Tue, 13 May 2003, Christoph Haas wrote: Hi, Fabio... On Tue, May 13, 2003 at 10:16:38PM +0200, Fabio Massimo Di Nitto wrote: Really nice job but the first side effect is already there: Package: icaclient Thanks for the hint. That was a test package I was uploading to stress test the dupload process on the server. It wasn't really meant to stay there. :) ehhe well i had no way to know :-) I think upload must be moderated somehow. Let's see. I hope that the users are not misusing our server to upload pornography or warez. In fact we are checking the uploads in regular intervals and will kick those users and their packages out. A completely moderated dupload process will IMHO slow the whole process down. Then i think that the suggestion made in another post to somehow limit the download would be enough. In this way there will be noway to redistribute illegal stuff around and people will not be tempted to do so from the beginning. Fabio -- Our mission: make IPv6 the default IP protocol We are on a mission from God - Elwood Blues http://www.itojun.org/paper/itojun-nanog-200210-ipv6isp/mgp4.html
Re: Returning from vacation. (MIA?)
*sigh* I hate to start off my return to the Project this way, but I just can't let this one go unanswered. :^( On Tue, May 13, 2003 at 10:48:45PM -0400, Matt Zimmerman wrote: On Tue, May 13, 2003 at 07:05:38PM -0500, Clay Crouch wrote: And please don't be offended by the .sig. That .sig is problematic beyond just its content; it is 12 lines long and adds almost 1kb to each of your messages (probably longer than the contents of many messages). Refer to RFC 1855 or any other netiquette document for further information. Hmmm An ettiquette lesson before a welcome back and a work assignemnt, just because you find my anti-spam measures draconian and my filter bypass info in my sig to be annoying. Charming, to be sure Pleased to meet you *plonk* And yes I am fully aware of nettiquette and it's dim view on long sigs. I had planned to trim out the text that caused you so much angst after a few transmissions, once anyone here who might give a damn had actually seen it. I drop that tagline into any new places I venture about 5 times before I trim it, as a standard practice. Since I've been gone a while, d-d sort of qualifies as new for the purpose, don't ya think? Procmail is a godsend, dealing with anywhere between 25 to 100 spams a day on three of my email addresses. I will see anything on debian-devel and on debian-private, but if anyone sends me private mail, please follow the directions below This approach tends to cause a lot of headaches for people who legitimately want to contact you; I do not recommend it. Try bogofilter, spamassassin and the like instead. I receive over 100 spam emails per day, and less than 5% make it past bogofilter, with zero false positives so far. Rest assured, I made my choice of anti-spam tactics while being fully informed about several other filtering options. I couldn't possibly care less what you do or do not recommend for spam filtration techniques. Five percent failure, eh? Try zero percent, with zero false positives. And the headaches for legitimate communications are almost all mine, since I make the choices and adjust ~/.procmailrc accordingly. *plonk* Now Can the QA team use an additional 5-20 hours a week of volunteer help from an already-registered Developer? Could the Project use another Alpha autobuilder? If not Cheers! ___ / Clay Crouch | [EMAIL PROTECTED] \ +--++ | PGP 94781680: 020E 793B 455D 9737 5956 1A3B 0AE8 807A 9478 1680 | | GPG 7D2AD631: 2319 2356 FEDF 4631 63F3 762A E443 1C2A 7D2A D631 | +---+ | I loathe spam. Therefore, I have procmail set up to send mail to | | /dev/null by default, unless your address matches a rule. To send | | me mail, put PASSTHRU-UNFILTERED in the subject line to dodge | | the one-way trip to /dev/null. I will add your address to my | | filter, so you only have to do this once per address. :^) | \___/
Re: Returning from vacation. (MIA?)
On Tue, May 13, 2003 at 11:27:31PM -0500, Clay Crouch wrote: I hate to start off my return to the Project this way, but I just can't let this one go unanswered. :^( Perhaps not, but you could have answered more civilly. A triumphant return, indeed. But, if we must... On Tue, May 13, 2003 at 10:48:45PM -0400, Matt Zimmerman wrote: On Tue, May 13, 2003 at 07:05:38PM -0500, Clay Crouch wrote: And please don't be offended by the .sig. That .sig is problematic beyond just its content; it is 12 lines long and adds almost 1kb to each of your messages (probably longer than the contents of many messages). Refer to RFC 1855 or any other netiquette document for further information. Hmmm An ettiquette lesson before a welcome back and a work assignemnt, just because you find my anti-spam measures draconian and my filter bypass info in my sig to be annoying. It is a gross disservice to your fellow developers who need to contact you in order to do useful work. Do you expect everyone who might ever need to contact you to read debian-devel and find out about this ridiculous practice of yours? Or do you send one of those obnoxious autoreplies asking people to confirm their messages to you? Rest assured, I made my choice of anti-spam tactics while being fully informed about several other filtering options. I couldn't possibly care less what you do or do not recommend for spam filtration techniques. It is reassuring to know that I will not be suffering any disadvantage from being unable to experience the enjoyable and productive experience of exchanging email with you. Clearly your filter is not the only problem in getting through to you. Five percent failure, eh? Try zero percent, with zero false positives. Zero percent? That would imply that you never get any spam via debian-devel, since you said that you do not apply your filter to those messages. Hah. Hahahah. Not to mention the legitimate mail that you lose because people are not interested in jumping through hoops for the pleasure of contacting you. Can the QA team use an additional 5-20 hours a week of volunteer help from an already-registered Developer? I'm afraid they can't hear you. They have their anti-spam filters on, and you forgot to include the magic passphrase in the subject of your message. This week, it's woozle-wuzzle. -- - mdz
Re: Do not touch l10n files (was Re: DDTP issue)
On Tue, May 13, 2003 at 10:36:53PM +0200, Bill Allombert wrote: On Tue, May 13, 2003 at 10:04:43PM +0200, Denis Barbier wrote: On Tue, May 13, 2003 at 05:56:08PM +0200, Bill Allombert wrote: Do we have such standard document for the original english description ? No, and there is no dedicated team to review them. debian-l10n-english There have been no email send to this list from November 2002 to February 2003. Can we call that a team ? This list is stalled when no input is sent, but this is certainly not the fault of those who are kindly reviewing English prose. [...] Telling them 'you do not speak french, so don't try to understand' is not acceptable. Sure it is. If they believe that the translator is wrong, they can ask a trusted person of their own to review the translation. I have done that several time myself. The result was several time that the ddtp translation were sheer nonsense. I am sorry. So I have used my veto right to uploaded meaningful translation. Trust is not given for free, one need to deserve it. I guess that you did it for French translations. Do you imagine sending such a message to a Japanese translator: My description has a comma separated list but your translation does not contain any comma. Moreover there is no space between words which makes your text look ugly. For these reasons I will apply my veto right. ? Here is what I am talking about: some developers alter translations for languages they do not understand, which is silly. If you are not fluent in a given language, do not try to fix translations, it is likely that you will make them worse. [...] For example removing trailing dot of the short description from the french translation is wrong if the english version has it. The dot must first be removed from the english version and then from the translation. So notify the maintainer and wait until he upload a fixed version. Right, but this is not what is discussed here. English description is not wrong, so the translator had no reason to send a bugreport. [...] As far as my experience is concerned, people allows themselves to translate description of packages they do not understand in english instead of giving up and produce nonsense as translation. This is that I would like the reviewers to focus on, not on typographical details. I agree this is a problem, but I do not know how to prevent these people from translating. Telling reviewers to relax grammar rules does not help. OTOH some French maintainers are unable to write plain French but translate their material, this is also a problem. Denis
Re: security in testing
Please get this OFF of debian-private and onto -devel. Quote me anywhere. On Tue, May 13, 2003 at 11:23:52AM +0300, Chris Leishman wrote: Security should be important in the testing distribution. [etc. etc. etc.] If you want to see security updates for 'testing', then start preparing security updates for 'testing'. It does not help to describe in detail what you hope that someone else will do. The best (and often only) way for you to promote your agenda is to start doing the work. 1) People don't run testing, and hence we lose a large portion of our testing process 2) There is more incentive to move to another distribution entirely Market share arguments don't tend to carry much weight in Debian. Developers in general don't stand to lose anything at all if Debian has fewer users. - If a security vulnerability is found in a 'testing' package, then an announcement is made (perhaps a testing-security-announce list?) - The package it is immediately withdrawn from the testing distribution. - If no fixed package is available, an empty 'placeholder' package is installed into testing along with a debconf message to inform the user that the package will be removed for security reasons. The message should also indicate what the problem is, and what actions are required to get a new version into testing. As an alternative, a downgraded version could be provided If you do not accept the arguments against this, then start doing it, and see whether it is worthwhile. I think this process would provide the following advantages: - It would remove the security risk for _all_ testing users Perhaps, but there are far easier ways for users to eliminate this risk, such as running stable, or upgrading problematic packages to the unstable versions. 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. - It would provide strong incentive for people to help out in fixing RC bugs or patching packages in order to get the missing package back into testing. If the package is not fixed by release time, it will be removed anyway. It is the maintainer's responsibility to work toward having the most releasable versions of his packages in 'testing'. -- - mdz -- Please respect the privacy of this mailing list. Archive: file://master.debian.org/~debian/archive/debian-private/ To UNSUBSCRIBE, use the web form at http://db.debian.org/.
security in testing
My 2c worth Security should be important in the testing distribution. I think it's fine to say that testing is not guaranteed to be stable, that bugs in packages may very well be present and that you shouldn't run testing if your not willing to accept that risk. I think it's another thing entirely to say that there may be known security problems in testing that we're not going to fix in a timely fashion. Here's my rationale: People want to run testing, but aren't willing to accept a overwhelming security risk. They run testing to not only get the latest packages, but also to contribute to debian by reporting bugs and _testing_ the new distribution. These people form a pretty significant part of debians testing process. Whilst I think these people are more than happy to put up with weird packaging bugs and broken software, if we indicate that running testing will almost certainly expose you to security vulnerabilities I believe these people are going to be a lot less likely to want to run the testing distribution. Which will result in 2 things: 1) People don't run testing, and hence we lose a large portion of our testing process 2) There is more incentive to move to another distribution entirely With this in mind, I think we MUST avoid making this statement of insecurity and do our best to avoid this situation. As a proposal to remedy this, I think the following actions would be appropriate (although I'm sure others may propose even better schemes): - If a security vulnerability is found in a 'testing' package, then an announcement is made (perhaps a testing-security-announce list?) - The package it is immediately withdrawn from the testing distribution. - If no fixed package is available, an empty 'placeholder' package is installed into testing along with a debconf message to inform the user that the package will be removed for security reasons. The message should also indicate what the problem is, and what actions are required to get a new version into testing. As an alternative, a downgraded version could be provided I think this process would provide the following advantages: - It would remove the security risk for _all_ testing users - It would provide strong incentive for people to help out in fixing RC bugs or patching packages in order to get the missing package back into testing. Obviously there needs to be some more thought put into exactly how the withdrawal/replacement of packages occurs, and I think others out there will have a better idea of how that could work than I. Regards, Chris Leishman PGP.sig Description: Binary data
Re: Do not touch l10n files (was Re: DDTP issue)
On Tue, May 13, 2003 at 05:56:08PM +0200, Bill Allombert wrote:
Bonjour,
I am french and I don't regard the 'Imprimerie Nationale' rules as binding.
We are still a free country.
Do we have such standard document for the original english description ?
No, and there is no dedicated team to review them.
This is not for lack of trying... People keep trying to tie
down the English language with an institution similar to
the one French has (the name of which I can't remember) but
it never sticks. Certain endeavours have English-language
manuals (Journalism, government writing come to mind) but,
as I understand it, there's no authority on English beyond
the Oxford, Webster's and Macquarie (and others I don't know)
Dictionaries for UK, US and Australian English.
On the other hand, what we want in Debian (I presume) is
standard {langauge} which is usually fairly easy to agree
upon. It's the most formal subset spoken by the most people,
I suspect. So in French I understand it's the form dictated
by the language institute in Paris who's name I have not
remembered since I started this email. In English I guess
you'd take the Harvard Dictionary of Style combined with
an appropriate dictionary? In Japanese it would be standard
Japanese (that was easy!) which is pretty much polite
Tokyo-speak, thanks to the agressive attempts of previous
Japanese governments to stamp out all other dialects. ;-)
I daresay the style choice for a given language should be
made by the people on the debian-l10n-{language} mailing
list. And the adhered to by writings in that language...
Presumably a webpage listing such documents would be a
good idea.
As a native English and poor Japanese speaker, this
discussion can only really be of academic interest to me
since Japanese's computer-typographical formatting seems
to have been massively influenced by US English, and so
doesn't present any interesting cases (off the top of my
head) to parallel a marked difference in writing quality
between comma-seperated lists and semicolon/newline
seperated lists apparent in French but not in English.
I think in English semicolons and commas also seperate
different things, but I'd have to go back and reread the
apache description before I can comment on which is correct
in English here.
--
---
Paul TBBle Hampson, MCSE
6th year CompSci/Asian Studies student, ANU
The Boss, Bubblesworth Pty Ltd (ABN: 51 095 284 361)
[EMAIL PROTECTED]
Of course Pacman didn't influence us as kids. If it did,
we'd be running around in darkened rooms, popping pills and
listening to repetitive music.
-- Kristian Wilson, Nintendo, Inc, 1989
This email is licensed to the recipient for non-commercial
use, duplication and distribution.
---
pgp7lFyXqwYFM.pgp
Description: PGP signature
[OT] Storms (Re: Do not touch l10n files (was Re: DDTP issue))
On Tue, May 13, 2003 at 08:05:29PM +0100, Mark Brown wrote: On Tue, May 13, 2003 at 01:27:45PM -0500, Branden Robinson wrote: We have a similar expression in (American) English. It's a tempest in a teapot. Storm in a teacup for British English. :-) Tormenta en un vaso de agua in Spanish. So it seems that french and spanish drink more water than tea. Javi pgps0as7IDTCB.pgp Description: PGP signature
Re: security in testing
On Tuesday, May 13, 2003, at 05:20 PM, Matt Zimmerman wrote: Please get this OFF of debian-private and onto -devel. Quote me anywhere. Redirected thread to debian-devel. If you want to see security updates for 'testing', then start preparing security updates for 'testing'. It does not help to describe in detail what you hope that someone else will do. The best (and often only) way for you to promote your agenda is to start doing the work. Actually - I didn't suggest this. I suggested there should be some consensus on what to do about security problems in testing - my main suggestion is that packages should be simply removed and the user notified of what actions they can do to get it back (such as upgrading to an unstable version, downgrading to a stable version, or fixing the bugs). 1) People don't run testing, and hence we lose a large portion of our testing process 2) There is more incentive to move to another distribution entirely Market share arguments don't tend to carry much weight in Debian. Developers in general don't stand to lose anything at all if Debian has fewer users. The important point was the first one. The 2nd one was just another effect of not doing anything about the issue which some people might care about. - If a security vulnerability is found in a 'testing' package, then an announcement is made (perhaps a testing-security-announce list?) - The package it is immediately withdrawn from the testing distribution. - If no fixed package is available, an empty 'placeholder' package is installed into testing along with a debconf message to inform the user that the package will be removed for security reasons. The message should also indicate what the problem is, and what actions are required to get a new version into testing. As an alternative, a downgraded version could be provided If you do not accept the arguments against this, then start doing it, and see whether it is worthwhile. I can't just start doing it. For one this is the sort of issue that needs a bit of consensus and input from the people actually in charge of the process. It's not like just submitting a patch or uploading a new package. I also clearly stated it's just an example of what could be done, but I think there may be better ways... Another example might be to just replace the package with another version that has a very, very loud debconf warning that it has known security problems and asking if the user really wants to install it. It's more of a policy issue first. Once thats worked out, then we can worry about the how. I think this process would provide the following advantages: - It would remove the security risk for _all_ testing users Perhaps, but there are far easier ways for users to eliminate this risk, such as running stable, or upgrading problematic packages to the unstable versions. Yes, there are. But all of these loose one of the main reasons I feel we even have a testing distribution - to have people testing it. 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. - It would provide strong incentive for people to help out in fixing RC bugs or patching packages in order to get the missing package back into testing. If the package is not fixed by release time, it will be removed anyway. It is the maintainer's responsibility to work toward having the most releasable versions of his packages in 'testing'. Again I agree. All I think is that removal of security issues should be done before it even gets into testing. My suggested policy was that nothing with a security bug should go into testing - and anything with a security bug should be removed via an empty upgrade (and the user informed). Of course there's may be other ways that have the same basic effect. The maintainer can then work towards getting their package back into testing. *shrug* I'm just trying to open a bit of reasonable discussion. I'll summarize so that people replying have less to quote: - 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. - I think there should be
Re: Do not touch l10n files (was Re: DDTP issue)
On Tue, May 13, 2003 at 12:25:24PM +0200, Fabio Massimo Di Nitto wrote: The translation team. Any other scheme is flawed and tends to problems (people doing the same work will collide, it has happened in the past with translations and will happen in the future if the maintainer, and not the translation teams ,is still the one merging changes) The translation team will not get anything from BTS anyway... so i don't see how this can work. the DD will be always the interface in this case. user - BTS - DD - translation team That's why might need a 'translation' tag so that translation teams can subscribe to the PTS for packages they translate and receive the 'translation' bugs directly. Currently, however, the DD does not always have to be the interface, that's what the PTS is for. user - BTS - DD | .- translation team But having a 'translation' tag makes it easier to handle. That's why i was asking information to grisu in the beginning for which is the proper procedure. Only a nice flamewar was born out of it. Grisu is _not_ the translation team coordinator for French. Denis is. Grisu manages the DDTP but that does not mean he gets a decision on how a translation should be made. I did ask for a procedure. not to solve the problem from us. There is a difference. Then you should have asked in debian-i18n, not to the translation team. In my opinion things that happened (like people starting to talk in french and not Cc'ing you) were related to using the translation team address and not the -i18n one. If this was the only point in the entire discussion, sure i can leave it out and we can stop discussing here. It's not the only point, but, as the thread at -l10n-french (and the one at -devel) show you think it's a layout issue whileas the french team thinks it's a typographical issue. Friendly, Javi PS: My (english) typos are not premeditated, I just type too fast and don't red over what I send when time/work is pressing... pgpttwkfEqUK5.pgp Description: PGP signature
Re: Returning from vacation. (MIA?)
On Wed, May 14, 2003 at 01:11:45AM -0400, Matt Zimmerman wrote: On Tue, May 13, 2003 at 11:27:31PM -0500, Clay Crouch wrote: Can the QA team use an additional 5-20 hours a week of volunteer help from an already-registered Developer? I'm afraid they can't hear you. They have their anti-spam filters on, and you forgot to include the magic passphrase in the subject of your message. This week, it's woozle-wuzzle. Great! We can now officially consider you a debian developer. You've been hitten with a cluebat! Send the chopters in. And now for something completely different, friendly Javi pgplUhMiX57L3.pgp Description: PGP signature
Re: Do not touch l10n files
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. I suggest you tune down the confrontational tone. manoj -- Kill files are an expression of resentment by the unmemorable or untalented against the memorable and talented. Your appearance in kill files merely marks the fact that you have more than once tried to make people think, when they really would rather not. It is an honor. Tim Maroney, who is in at least a few... Manoj Srivastava [EMAIL PROTECTED] http://www.debian.org/%7Esrivasta/ 1024R/C7261095 print CB D9 F4 12 68 07 E4 05 CC 2D 27 12 1D F5 E8 6E 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C
Re: Returning from vacation. (MIA?)
Clay Crouch [EMAIL PROTECTED] writes: On Tue, May 13, 2003 at 10:48:45PM -0400, Matt Zimmerman wrote: That .sig is problematic beyond just its content; it is 12 lines long and adds almost 1kb to each of your messages (probably longer than the contents of many messages). Pleased to meet you *plonk* Nice entrance. Let me predict the future. Within a month you have kill-filled anyone in the project who matters more than just maintaining a few packages. And most of us has has given up on you. -- Peter Makholm |According to the hacker ethic, the meaning of life [EMAIL PROTECTED] |is not Friday, but it is not Sunday either http://hacking.dk | -- Peeka Himanen
Re: Do not touch l10n files
On Tue, 13 May 2003 22:04:43 +0200, Denis Barbier [EMAIL PROTECTED] said: Sure it is. If they believe that the translator is wrong, they can ask a trusted person of their own to review the translation. It is silly that people who do not speak a foreign language can have a judgement on what a translation should look like and perform changes in localized files (I am not talking about the Apache description here) without notifying the translator. 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? manoj -- The tree in which the sap is stagnant remains fruitless. Hosea Ballou Manoj Srivastava [EMAIL PROTECTED] http://www.debian.org/%7Esrivasta/ 1024R/C7261095 print CB D9 F4 12 68 07 E4 05 CC 2D 27 12 1D F5 E8 6E 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C
Re: Do not touch l10n files (was Re: DDTP issue)
* (Denis Barbier) | I sent a templates.fr file for cvs in #136340, which has been included | in 1.11.1p1debian-4. I do not know if this file was included verbatim, | but 1.11.1p1debian-8 did not contain any 0xa0 characters (in ISO-8859-1 | encoding) which were replaced by normal spaces. Now Tollef is telling | me that those characters should never have been put into templates.fr, | and removing them was right. The mail sent to me from the BTS did _not_ include any 0xa0 characters at all, and according to my .zsh_history, I did not wget the file off the web, but rather copypasted the template from the mail. (The mail has charset: iso8859-1, so copypasting does not give me any charset issues as warned in the mail). I was confusing the template with the issue in 142665. -- Tollef Fog Heen,''`. UNIX is user friendly, it's just picky about who its friends are : :' : `. `' `-
Re: Please notify the maintainers when removing packages
* Sven Luther [EMAIL PROTECTED] [2003-05-07 12:18]: On Wed, May 07, 2003 at 09:44:54AM +0200, Gerfried Fuchs wrote: But they *should* read the bug mail they receive, and I guess that was Michaels point. If they don't read their bug mails they don't seem to care about their package anyway. Yes, sure. But then again, we only have so much free time, and we prioritize it differently. It happened for me back then, with the active-dvi package. At the time there was a FTBFS bug or something such not really all that problematic, and i knew there was going to be a new upstream release nextly. Well, usually FTBFS bugs _are_ problematic, if people aren't ignorant about other architectures than their own. If i had not noticed it, the package would have been removed without any kind of information to the maintainer, and i would maybe not even have noticed. What makes you think so? I can't follow the reasoning for why you think that it would have been removed right then. We maintainer are recommended to have good comunications channels to our upstream, but i suppose that the release manager should have good comunication channels to the different maintainers to, which doesn't seem to be always the case. O.k., I can understand that request and it makes sense. I was just under the impression that the Release Update mails that the RM sent are much more informative and important to read than the weekly RC bug list. Also, i understand that they are also MIA maintainers, or semi-MIA ones, and that for them it will not make much of a difference, but if we help out even one good-intentioned maintainer, it is already a good thing. The MIA maintainers are a big problem on their own, unfortunately. We definitely should get rid of them or at least be able to get some informations from them to see when they will have time again and suspend them somehow. But that was discussed already quite intensively... If the users may be interested in the package they definitely *should* subscribe to d-d-a. d-d-a does *not* only address the debian developers but all the people that are interested in the development of debian in general. That is, also those interested in any single package. But the bug scan package is not in any readable form. It mostly says the same as last week. If some kind of diff where available, it would make more sense to read it. And again I was not talking about the bug scan mails, I was speaking about the Release Update mails. I still have the impression that a REMOVE tag in the bug scan mail doesn't mean much but just an indicator on how long a RC bug might be open already. I am still not convinced that packages actually were removed with *only* the REMOVE notification in the bug scan mail. Noone has showed me yet that this impression is wrong. About the idea of some kind of diff you got me interested. I might want to take a look on what can be done on that point. Maybe something like (EXAMPLE, there are no such bugreports): Package: t-prot (debian/main) Maintainer: Gerfried Fuchs [EMAIL PROTECTED] New: [REMOVE], 0815 [ + ] Changed: 4711 [P ] (+P) If there are no new RC-bugs or no changes the package shouldn't be listed, if I get you right. I'll take a look on the original script, if I can find it. It is easy to say that everyone should fix bugs, respond quickly to mails, and so one, but the people saying it should be held to the same standard. I try as good as I can ;) Then mail the debian maintainer that you are going to remove their package, is that asked too much ? Some developers seem to consider every additional mail by default as spam and object to anything in that respect. But don't get me wrong, I understand your point here. And beside, it is basic courtesy, but then i have long known that some of the most important debian people have a tendency to be quite rude to other developpers. Did i tell you how i got blacklisted by James Troup when i was too eager to find the reasons for build problems he told me about in not so clear ways. It seems to be a special sort of manners when your higher up, sometimes. Have been in some infight with one of the uppers, too. It's just that because one is longer in the project it doesn't mean that s/he can't be wrong... (and that is no judgement of your problem with elmo; I don't know anything about it) Well, but if you don't get properly informed in the first place, you may not notice, and not everyone can pass hours each day to read all the debian information. Scanning for ones name in the weekly bugscan mail isn't that time intensive, so don't overdo it. This is wrong, sure the package can get removed if there are RC bugs, but when will that be, what release schedule do we have so i can schedule my free time so as to fix that most efficiently ? So simply don't take the REMOVE in the bugscan mail too serious. From what I have understood it was never the last word before a package was
Re: can touch(1) readonly files
I see, if I wanted chmod 444 to stop me from touch(1)ing my files, then I would have to give up $ chmod 0 x; ls -l x -- 1 jidanni jidanni 0 2003-05-14 07:38 x listing my files. Ok, over and out.
Re: Returning from vacation. (MIA?)
On Tue, 13 May 2003 23:27:31 -0500, Clay Crouch [EMAIL PROTECTED] said: Hmmm An ettiquette lesson before a welcome back and a work assignemnt, just because you find my anti-spam measures draconian and my filter bypass info in my sig to be annoying. Charming, to be sure Pleased to meet you *plonk* Ah yes. Another of the special little people for whom the rules of ettiquette do not apply. And yes I am fully aware of nettiquette and it's dim view on long sigs. I had planned to trim out the text that caused you so much angst after a few transmissions, once anyone here who might give a damn had actually seen it. I drop that tagline into any new places I venture about 5 times before I trim it, as a standard practice. Since I've been gone a while, d-d sort of qualifies as new for the purpose, don't ya think? Yes, all the aforementioned lusers always have special circumstances due to which the rules that apply to other do not apply to them, or at least not for this one instance. You better hope to high heaven that you never need har from me or [EMAIL PROTECTED]; for I refuse to jump through silly hoops. manoj -- I am deeply CONCERNED and I want something GOOD for BREAKFAST! Manoj Srivastava [EMAIL PROTECTED] http://www.debian.org/%7Esrivasta/ 1024R/C7261095 print CB D9 F4 12 68 07 E4 05 CC 2D 27 12 1D F5 E8 6E 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C
Re: security in testing
On Wed, May 14, 2003 at 10:07:16AM +0300, Chris Leishman wrote: Actually - I didn't suggest this. I suggested there should be some consensus on what to do about security problems in testing - my main suggestion is that packages should be simply removed and the user notified of what actions they can do to get it back (such as upgrading to an unstable version, downgrading to a stable version, or fixing the bugs). This isn't possible in general; when mysql has a security problem you can't just tell people to (a) not use it, or (b) just run the unstable/stable version anyway, in spite of whatever reasons they based their decision to use testing on in the first place. We already know the right way of dealing with security bugs; we do it for our stable releases. If you care about security and testing, all you have to do is the same thing that's being done there. It's really that simple. 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!''
Re: Please notify the maintainers when removing packages
On Wed, May 14, 2003 at 09:55:36AM +0200, Gerfried Fuchs wrote: * Sven Luther [EMAIL PROTECTED] [2003-05-07 12:18]: On Wed, May 07, 2003 at 09:44:54AM +0200, Gerfried Fuchs wrote: But they *should* read the bug mail they receive, and I guess that was Michaels point. If they don't read their bug mails they don't seem to care about their package anyway. Yes, sure. But then again, we only have so much free time, and we prioritize it differently. It happened for me back then, with the active-dvi package. At the time there was a FTBFS bug or something such not really all that problematic, and i knew there was going to be a new upstream release nextly. Well, usually FTBFS bugs _are_ problematic, if people aren't ignorant about other architectures than their own. Sure, but the solution is often simple. If i had not noticed it, the package would have been removed without any kind of information to the maintainer, and i would maybe not even have noticed. What makes you think so? I can't follow the reasoning for why you think that it would have been removed right then. Well, it was prior to one of our freezes/releases, my package was about to be dropped/removed/whatever, if i had not taken immediate action. It was a few years ago though, and things may have changed some since then, but it remains that it is easier to overlook a mail from one of the mailing lists, even if it is a required read and a simple grep or whatever is needed, than a mail sent to you personnally. We maintainer are recommended to have good comunications channels to our upstream, but i suppose that the release manager should have good comunication channels to the different maintainers to, which doesn't seem to be always the case. O.k., I can understand that request and it makes sense. I was just under the impression that the Release Update mails that the RM sent are much more informative and important to read than the weekly RC bug list. Sure, but it cost nothing, or almost so, so why not send a personal mail to concerned developers ? About the idea of some kind of diff you got me interested. I might want to take a look on what can be done on that point. Maybe something like (EXAMPLE, there are no such bugreports): Package: t-prot (debian/main) Maintainer: Gerfried Fuchs [EMAIL PROTECTED] New: [REMOVE], 0815 [ + ] Changed: 4711 [P ] (+P) If there are no new RC-bugs or no changes the package shouldn't be listed, if I get you right. I'll take a look on the original script, if I can find it. Maybe there could be two sections in the mail, one about changes from the previous week, and the other the global listing as we do now. Sure it repeats some of the data, but is it that problematic ? Maybe the second section could be only for older, not changed problematic packages, or maybe this could be two separate mails. It is easy to say that everyone should fix bugs, respond quickly to mails, and so one, but the people saying it should be held to the same standard. I try as good as I can ;) Then mail the debian maintainer that you are going to remove their package, is that asked too much ? Some developers seem to consider every additional mail by default as spam and object to anything in that respect. But don't get me wrong, I understand your point here. Hah, and one small mail is going to make a difference compared to the huge amount of spam that we get trough the debian lists and mailing addresses ? And anyway, i don't hear the people who would receive such mails objecting, and if they are not doing their work correctly, they deserve a reminder. I think people are just rejecting this idea on principle or something such. Well, but if you don't get properly informed in the first place, you may not notice, and not everyone can pass hours each day to read all the debian information. Scanning for ones name in the weekly bugscan mail isn't that time intensive, so don't overdo it. If we had a .procmail rule that would search for ones maintainer address in the these mails, extract the relevant info and sen it as a separate mail, then it would make things much easier, without needing to try to change something on the sending end. This is wrong, sure the package can get removed if there are RC bugs, but when will that be, what release schedule do we have so i can schedule my free time so as to fix that most efficiently ? So simply don't take the REMOVE in the bugscan mail too serious. From what I have understood it was never the last word before a package was actually removed. But there is no guarantee of that. I have heard reports lately of packages that were silently removed, and remember a maintainer wondering why a package was dropped silently from potato during the release. Friendly, Sven Luther
Re: Debian MIA check
El mar, 13 de 05 de 2003 a las 18:11, Joey Hess escribió: Tor Slettnes mindi mondo smail xcdroast yard zmailer zmailer-ssl I am the maintainer for those packages and I'm not MIA for the moment. Please check your list again. BTW, if someone wants to help testing latest mindi/mondo please check on people.debian.org/~hector/ -- Héctor García Álvarez [EMAIL PROTECTED] signature.asc Description: PGP signature
Re: Returning from vacation. (MIA?)
Hi,
Matt Zimmerman wrote:
Or do you send one of those obnoxious autoreplies asking people to
confirm their messages to you?
FWIW, if they are only sent in reply to spam status dubious messages, I
wouldn't call them obnoxious.
I agree, though, that an auto-bit-bucket, which doesn't _at_least_ send an
autoreply with the information how to bypass the thing, is rather stupid.
--
Matthias Urlichs | {M:U} IT Consulting @ m-u-it.de | [EMAIL PROTECTED]
Disclaimer: The quote was selected randomly. Really. | http://smurf.noris.de
--
You Go Yahweh - and I'll go Mine!
Re: Do not touch l10n files (was Re: DDTP issue)
On Tue, May 13, 2003 at 12:57:51PM +0200, Fabio Massimo Di Nitto wrote:
On Tue, 13 May 2003, Martin Quinson wrote:
On Tue, May 13, 2003 at 09:42:16AM +0200, Fabio Massimo Di Nitto wrote:
If you really believe that the apache description should be improved than
you file a bug against apache asking to changing layout, proposing the
better one so that everyone can be alligned to it.
If I understand well, you are bored because you think that the layout used
in french could be good in all languages, but the french translators sort of
kept it for themselves.
No, I am not bored. People in some msgs wrote that the french layout is
better. I am not against the fact that it can be better. Just use the
right way so that everyone can benefit in a similar way.
But you missed our point saying that we don't want to use it in french
because it looks better, but because we have to. The fact that it looks
better and could be used in the other languages as well is another point,
and nobody in the french team never commented on that.
Again, in french, that's not just esthetical. And we, as french translators,
let you the decision about the esthetic of the thing for the other languages.
I don't want to prevent you to use your language like i wouldn't like the
otherw ay around. Is there any way to be closer to the original esthetical
layout?
Nop. It must be so in French. The previous translation was an obvious error.
And I'm not the right person to decide if it's better looking in other
languages since I'm only native french speaker.
Your engagement for the quality of your package is really great. Only, I
think that you are not responsible of the translation. I know that there is
a lack in debian framework concerning this point, but it really should be so
('cause maintainer cannot be responsible for translations they do not
understand. How do you handle tranlations in russian, japaneese and
bokmal?).
Correcting this lack is a completely other topic, too large to be discussed
here (browse debian-i18n archives if you really care).
As long as this lack isn't corrected, feel free to mark all bugs
concerning the french translation as forwarded to upstream, and forward it
to our mailing list. We will take care of them and help you to correct them.
Bye, Mt.
--
Learning and doing is the true spirit of free software -- learning without
doing gets you academic sterility, and doing without learning is all too
often the way things are done in proprietary software.
-- Raph Levien
Re: Debian MIA check
Hiya, On Wed, May 14, 2003 at 11:25:49AM +0200, Héctor García Álvarez wrote: El mar, 13 de 05 de 2003 a las 18:11, Joey Hess escribió: Tor Slettnes I am the maintainer for those packages and I'm not MIA for the moment. Please check your list again. Héctor García Álvarez [EMAIL PROTECTED] I'm guessing Joey's grep for [EMAIL PROTECTED] wasn't anchored and so picked up [EMAIL PROTECTED] too. -- _[EMAIL PROTECTED] -+*+- fou, con et anglais _ (_) Ah. So you're a waffle man! - Talkie Toaster(_) (_) (_) \______/
DebConf 3 for New Maintainers
Hi, Hi, I tried this already on debian-mentors, but maybe the right persons are here: I am considering going to DebConf 3. Now Oslo is not really close (I live in southern germany), and being a High School student, I would have to argue with my principal whether I may go or not during school time, so it should be worth the money and effort. Well enough introduction; my main question is: Would it make sense for me to attend Debcamp. Maybe my idea about DebCamp is wrong, but it sounds as if it is just a very large debian hacking session, so one needs to have something to hack on, and something to hack with. Would I find a task there, or should I make sure I have one beforehand? Do I have to bring my own PC? What are your experiences, and what would you suggest a debian (the project, not the distro) newbie? Joachim -- Joachim Breitner e-Mail: [EMAIL PROTECTED] | Homepage: http://www.joachim-breitner.de JID: [EMAIL PROTECTED] | GPG-Keyid: 4743206C | ICQ#: 74513189 Geekcode: GCS/IT/S d-- s++:- a--- C++ UL+++ P+++ !E W+++ N-- !W O? M?+ V? PS++ PE PGP++ t? 5? X- R+ tv- b++ DI+ D+ G e+* h! z? Bitte senden Sie mir keine Word- oder PowerPoint-Anhänge. Siehe http://www.fsf.org/philosophy/no-word-attachments.de.html signature.asc Description: Dies ist ein digital signierter Nachrichtenteil
Re: security in testing
On Wednesday, May 14, 2003, at 11:22 AM, Anthony Towns wrote: snip This isn't possible in general; when mysql has a security problem you can't just tell people to (a) not use it, or (b) just run the unstable/stable version anyway, in spite of whatever reasons they based their decision to use testing on in the first place. I'm not sure I see why not. It is testing after all - packages are not required to be functional and people running testing are happy to deal with that situation. And I think its much better than having mysql installed with a security problem and not knowing about it. We already know the right way of dealing with security bugs; we do it for our stable releases. If you care about security and testing, all you have to do is the same thing that's being done there. It's really that simple. I care about security in testing, and I believe others do too. But I don't think the process should be the same as with stable releases. Testing should not become another psudo stable distributionit's for testing. So I don't think security management needs to be anywhere near as comprehensive. *shrug* But maybe I'm wrong and it's just me who likes to run testing (to help out with 'testing' the distribution) but doesn't really like the idea of having to deal with known remote security problems. Maybe nobody else cares and I should just shut up ;-) Regards, Chris PGP.sig Description: This is a digitally signed message part
Gnome2, libgtk2 gtk2 apps like gaim / mozilla
Hi, Since I while I am forced to shut down my Linux workstation when I leave my workplace. And since then I noticed that every time I boot again, and start my X, and open my apps like Gaim and Mozilla, the font used is HUGE (Helvetica, 12px, or something), while I have set the font to be Verdana, 9px using gnome-control-center's font-setting dialog. Changing fontsettings there affects libgtk2-using applications like gaim mozilla. Now, each time I boot and start X, I have to start gnome-control-center atleast once to have my fonts at my own preferred size. The moment I doubleclick the 'AaBb'-Font option and the window pops up, my fonts get set to Verdana, 9px like I want them to be. So, gnome/libgtk2 has stored it somewhere, it just needs to be activated. I don't use Gnome2 as a desktop manager, eg. I don't have panels running, I only use gaim, which links against libgtk2. So the problem is where gaim (and other libgtk2 using apps) don't start some component that gnome-control-center does start to load my own preferences. This is a bug, in my humble opinion. But I am not sure where to report it. Gaim? Mozilla? One of the hundreth gnome packages? :) I could use some advise here. Someone on IRC (IRCName: Tomas Gren, Nick: Stric on #debian-devel) told me it has to do with the X-servers XSETTINGS extension and pointed me to a site[1] where I found a tool to 'play around' with this extension. And indeed, when I run the 'xsettings-client' tool directly after starting X, there are no settings at all. Then when I start gnome-control-center and open the fonts dialog, the settings appear and have the correct values. So, could anyone please help me decide where to report this, and maybe solve this? I'm not that good at libgtk2 and the X server :| I don't think it should be necessary to run the complete gnome2 suite to have my fonts at my own preference ;) TIA, Sander. -- | Waarom worden mensen meteen geloofd als ze zeggen dat er aan de hemel | 400 biljoen sterren zijn, maar als je ze vertelt dat de deurpost pas | geverfd is moeten ze voelen! | 1024D/08CEC94D - 34B3 3314 B146 E13C 70C8 9BDB D463 7E41 08CE C94D
Re: Please notify the maintainers when removing packages
Hi, Richard Braakman wrote:
On Thu, May 08, 2003 at 11:15:44PM +0200, Matthias Urlichs wrote:
They will complain about Debian, not about their package's maintainer,
when they upgrade to Sarge and the program they've been using is
irretrievably auto-deinstalled. :-(
Does this happen a lot? Both apt and dselect are very polite about not
removing my packages. What tool do you use?
The update to sarge will remove a whole lot of pachages because newer,
differently-named packages replace them. Examples: coreutils. All C++
libraries. A whole lot of differently-packaged stuff from KDE2.2.
The fact that one of the programs which you use daily, but have
almost-forgotten the .deb name of, is among the lot of them may well get
lost. After all, apt-get doesn't distinguish, if packages are removed
because of missing dependencies, between those which have been Replaces:'d
and those that haven't.
--
Matthias Urlichs | {M:U} IT Consulting @ m-u-it.de | [EMAIL PROTECTED]
Disclaimer: The quote was selected randomly. Really. | http://smurf.noris.de
--
There is nothing stranger in a strange land than the stranger who comes
to visit.
Re: Do not touch l10n files (was Re: DDTP issue)
On Wed, May 14, 2003 at 08:40:17AM +0200, Denis Barbier wrote: Telling them 'you do not speak french, so don't try to understand' is not acceptable. Sure it is. If they believe that the translator is wrong, they can ask a trusted person of their own to review the translation. I have done that several time myself. The result was several time that the ddtp translation were sheer nonsense. I am sorry. So I have used my veto right to uploaded meaningful translation. Trust is not given for free, one need to deserve it. I guess that you did it for French translations. Do you imagine You guess wrong. I meant I have asked a trusted person (who was a developer of the upstream project and was a native speaker) about the translation. He tell me the translation was nonsense and provided me with a correct one and was reviewed by other upstream developers. Cheers, -- Bill. [EMAIL PROTECTED] Imagine a large red swirl here.
Re: Gnome2, libgtk2 gtk2 apps like gaim / mozilla
On Wed, 2003-05-14 at 12:22, Sander Smeenk wrote: Hi, Since I while I am forced to shut down my Linux workstation when I leave my workplace. And since then I noticed that every time I boot again, and start my X, and open my apps like Gaim and Mozilla, the font used is HUGE (Helvetica, 12px, or something), while I have set the font to be Verdana, 9px using gnome-control-center's font-setting dialog. [snip] If you don't want to start GNOME via gnome-session (you can remove the panel from the session if you wish) you must run gnome-settings-daemon in your startup to populate the XSETTINGS database. Ross -- Ross Burton mail: [EMAIL PROTECTED] jabber: [EMAIL PROTECTED] www: http://www.burtonini.com./ PGP Fingerprint: 1A21 F5B0 D8D0 CFE3 81D4 E25A 2D09 E447 D0B4 33DF signature.asc Description: This is a digitally signed message part
Bug marked as done messages to-be-MIMEified?
I hate inline mail forwarding. It loses information, breaks programs
(inline-quoted mails typically get From: replaced by From: at some
step), and makes things like signature checking needlessly complicated.
debbugs forwards some emails as inline attachments, notably the bug
has been marked 'done' confirmation. I think that's wrong.
Unless there's a strong preference to keep things the way they are, I'd
like to prepare a patch to change that -- so speak up now.
--
Matthias Urlichs | {M:U} IT Consulting @ m-u-it.de | [EMAIL PROTECTED]
Disclaimer: The quote was selected randomly. Really. | http://smurf.noris.de
--
Step by step walk the thousand-mile road.
-- Musashi, Book of Five Rings
Re: Gnome2, libgtk2 gtk2 apps like gaim / mozilla
Quoting Ross Burton ([EMAIL PROTECTED]): Since I while I am forced to shut down my Linux workstation when I leave my workplace. If you don't want to start GNOME via gnome-session (you can remove the panel from the session if you wish) you must run gnome-settings-daemon in your startup to populate the XSETTINGS database. Ok, that sounds logic. Is this documented somewhere? I mean, there must be more users who are likely to run into this problem? (btw, I received your reply *before* my own message returned from the ml! :)) Kind regards, Sander. -- | If space is a vacuum, who changes the bags? | 1024D/08CEC94D - 34B3 3314 B146 E13C 70C8 9BDB D463 7E41 08CE C94D pgp5ernzWZSE3.pgp Description: PGP signature
Re: Gnome2, libgtk2 gtk2 apps like gaim / mozilla
I don't use Gnome2 as a desktop manager, eg. I don't have panels running, I only use gaim, which links against libgtk2. So the problem is where gaim (and other libgtk2 using apps) don't start some component that gnome-control-center does start to load my own preferences. Just set it in ~/.gtkrc-2.0 . -- Mati ([EMAIL PROTECTED]) ycie byoby o wiele atwiejsze do zrozumienia, gdyby matka natura daa nam kod rdowy.
Re: Debian MIA check
On Tue, May 13, 2003 at 11:51:53AM -0500, Branden Robinson wrote: If you know how to reach any of the people listed in [1] and [2] below, please feel free to contact them and get them to reply to [EMAIL PROTECTED] Is there a mnemonic for that? I.e., does wat stand for something? wherefore art thou (see the source for emilie in dak CVS). -- 2. That which causes joy or happiness.
Re: security in testing
Chris Leishman [EMAIL PROTECTED] writes: I care about security in testing, and I believe others do too. But I don't think the process should be the same as with stable releases. Testing should not become another psudo stable distributionit's for testing. So I don't think security management needs to be anywhere near as comprehensive. Why not? Testing would be my personal choice for running a desktop (or laptop) Linux, were I not otherwise involved with Debian development. The only bad thing is the non-existent security (I could live with occasional critical bug but the level of critical bugs in unstable is too much to bear for most users). There are, however, some pre-plans afoot regarding that (more or less running the same process as with stable, of course with different people responsible). -- * Behind every successful man is a woman, behind her is his wife. * * (Groucho Marx) * * PGP public key available @ http://www.iki.fi/killer *
Re: DebConf 3 for New Maintainers
On 14 May 2003, Joachim Breitner wrote: Hi, I tried this already on debian-mentors, but maybe the right persons are here: The best list for this kind of discussion is probably debian-events-eu. I am considering going to DebConf 3. Now Oslo is not really close (I live in southern germany), and being a High School student, I would have to argue with my principal whether I may go or not during school time, so it should be worth the money and effort. I doubt that you will get any better education than at Debcamp. By the way what kind of school is it which has no holidays at this time? Well enough introduction; my main question is: Would it make sense for me to attend Debcamp. Maybe my idea about DebCamp is wrong, but it sounds as if it is just a very large debian hacking session, so one If I guess from the first Debian conference in Bordeaux than a large Debian hacking session might be the right word. At http://www.james.rcpt.to/2001/conf-1.deb/Bordeaux/ you can find some images / impressions by James Bromberger and links to other peoples photo collections. A good feeling about such sessions might give for instance http://www.james.rcpt.to/2001/conf-1.deb/Bordeaux/4th-day/preview-114-1401_IMG.JPG.html and others. (By chance you can find our current DPL in the blue T-Shirt on this image.) If you ask me it was one of my most productive times to work for Debian. needs to have something to hack on, and something to hack with. Would I find a task there, or should I make sure I have one beforehand? The main task I addressed there was fixing RC bugs. We made a list at the white board where people announced to work on a package. (I remember that I was browsing the packages in reverse alphabetical order.) If you look at the current list of RC bugs it is more work than you could manage in this time and this situation will hardly be changing drastically until July. The fun thing is that you have lots of competent people to get help solving bugs and ironing out new bugs you might notice while working on these packages. As I said in the beginning: No better education is possible. Do I have to bring my own PC? 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! What are your experiences, and what would you suggest a debian (the project, not the distro) newbie? If you know the distro you know the unsolved problems. If you have trouble finding problems which might be solved I would volunteer to compile a list. ;-)) Kind regards Andreas.
Re: Returning from vacation. (MIA?)
On Tue, May 13, 2003 at 11:27:31PM -0500, Clay Crouch wrote: *plonk* *plonk* Can the QA team use an additional 5-20 hours a week of volunteer help from an already-registered Developer? Could the Project use another Alpha autobuilder? If not The Project always needs more help, but it sure as hell doesn't need more fucked up attitude. -- 2. That which causes joy or happiness.
Re: Gnome2, libgtk2 gtk2 apps like gaim / mozilla
On Wednesday 14 May 2003 13:22, Sander Smeenk wrote:
Hi,
Since I while I am forced to shut down my Linux workstation when I leave
my workplace. And since then I noticed that every time I boot again, and
start my X, and open my apps like Gaim and Mozilla, the font used is
HUGE (Helvetica, 12px, or something), while I have set the font to be
Verdana, 9px using gnome-control-center's font-setting dialog.
Changing fontsettings there affects libgtk2-using applications like gaim
mozilla.
[snip]
Mozilla is an exception. To change font, you need to edit
${HOME}/.mozilla/profile_name/something.slt/chrome/userChrome.css
adding
* {
font-size: 10pt !important;
font-family: FreeSans;
}
to this file will make Mozilla use FreeSans 10pt font.
--
Mike Hommey [EMAIL PROTECTED]
This will go a long way towards the war on terror. Terrorists won't be able
to install and use unauthorized OS's. This could potentially save thousands
of lives. -- a slashdotter about Trusted Computing
Re: Gnome2, libgtk2 gtk2 apps like gaim / mozilla
On Wed, 2003-05-14 at 12:52, Sander Smeenk wrote: If you don't want to start GNOME via gnome-session (you can remove the panel from the session if you wish) you must run gnome-settings-daemon in your startup to populate the XSETTINGS database. Ok, that sounds logic. Is this documented somewhere? I mean, there must be more users who are likely to run into this problem? Not sure, probably somewhere. It might be in the GNOME Admin Guide. Most people who use just GTK+ apps won't use the GNOME stuff to set the prefs, but edit the traditional ~/.gtkrc-2.0 file by hand. You are weird by using the GNOME control center to configure GTK, but not running it (gnome-settings-daemon) at startup via gnome-session. Ross -- Ross Burton mail: [EMAIL PROTECTED] jabber: [EMAIL PROTECTED] www: http://www.burtonini.com./ PGP Fingerprint: 1A21 F5B0 D8D0 CFE3 81D4 E25A 2D09 E447 D0B4 33DF signature.asc Description: This is a digitally signed message part
Re: security in testing
On Wed, May 14, 2003 at 10:07:16AM +0300, Chris Leishman wrote: Yes, there are. But all of these loose one of the main reasons I feel we even have a testing distribution - to have people testing it. You are falling into the trap of overselling testing. Having people test testing at this point in the development cycle is useless, because the real activity is in unstable. You're trying to make testing something it isn't, then trying to reshape policy to meet your idea of what testing should be. You're hardly the first to do that, but it's no more correct this time. I strongly recommend that *nobody* run testing as a everyday system, because it just isn't a good choice for that. All the complaints we see every couple of weeks about testing would be swept away if people followed this advice and simply didn't use testing. Mike Stone
Re: Do not touch l10n files (was Re: DDTP issue)
On Wed, May 14, 2003 at 12:07:29PM +0200, Martin Quinson wrote:
Your engagement for the quality of your package is really great. Only, I
think that you are not responsible of the translation. I know that there is
a lack in debian framework concerning this point, but it really should be so
('cause maintainer cannot be responsible for translations they do not
understand. How do you handle tranlations in russian, japaneese and
bokmal?).
This is a fundamental question for which there definitely isn't
consensus, and it is a fundamental polity (governance) issue.
One is that the linguistic teams have full and ultimate responsibility
over the translations, and there is no recourse or appeal if the
maintainer doesn't like what they have done.
Another position is that the maintainer is ultimately responsible; he
or she may delegate responsibility to helpers, just as the Debian
Leader may delegate certain responsibilities to subordinates.
However, it is clear that the maintainer or the Debian Leader is
ultimately responsible, even if the wise maintainer and/or Debian
Leader may not choose to exercise his or her perogatives very often.
This point is a subtle one. I will point out that in a corporate
setting, it's quite normal for the employer's manager and or his
manager's manager will not fully understand all of the work that that
the employee does. Yet they are still responsible for the work of the
employee, and if they don't like it, they can tell the employee to do
things a different way, or in the extreme case, they can fire him.
Obviously, if the manager doesn't completely understand what the
employee is doing, there will be a certain negotiation, and a certain
back and forth over goals and directions and what is and isn't
technically possible, etc. Hopefully, said negotiations will be done
in a mutally respectful and civil manner. But that doesn't change the
fact that ultimately the manager gets to have the final say.
Which model people subscribe to makes a lot of difference in how they
communicate. For example, if your manager doesn't like the work that you
do, even if you think his grounds for objecting may not be the best
ones, would you tell him, tough luck? Probably not
- Ted
P.S. To the extent that the DDTP gives the package maintainer veto
rights, it seems pretty clear that at least initially the DDTP
believed that the package maintainer was ultimately responsible.
Given comments and the tenor of the tone made by some of the people on
some of the language teams, it's not clear they believe that as
strongly today.
xf86config bug
Hi, I can't seem to find the package that xf86config belongs to, but the bug is as follows: xf86config writes to /etc/X11/XF86Config, rather than /etc/X11/XF86Config-4, which is the one being read. Anyone know where this bug should be reported to? Many thanks, Neil -- 16 Channels in mode 4 I disclaim everything I can under English law. gpg key - http://www.halon.org.uk/pubkey.txt ; wwwkeys.pgp.net 8DEC67C5
Re: DebConf 3 for New Maintainers
Joachim, I am considering going to DebConf 3. Now Oslo is not really close (I live in southern germany), and being a High School student, I would have to argue with my principal whether I may go or not during school time, so it should be worth the money and effort. I cannot help you on that one. I suspect that DebConf time will be the last possible time for examinations, so better check with your teachers. Other than that, most of us will probably be going to LinuxTag Karlsruhe before, as the flight from Frankfurt to Oslo is probably the cheapest way there. Simon -- GPG Fingerprint: 040E B5F7 84F1 4FBC CEAD ADC6 18A0 CC8D 5706 A4B4 pgp7E9hKtgYeB.pgp Description: PGP signature
Re: security in testing
On Wed, May 14, 2003 at 03:04:10PM +0300, Kalle Kivimaa wrote: Why not? Testing would be my personal choice for running a desktop (or laptop) Linux, were I not otherwise involved with Debian development. The only bad thing is the non-existent security (I could live with occasional critical bug but the level of critical bugs in unstable is too much to bear for most users). There are, however, some pre-plans afoot regarding that (more or less running the same process as with stable, of course with different people responsible). What kind of pre-planning is taking place? The idea of security updates for testing? Every time this appears to have been raised it's usually shot down very quickly; unless I've missed something. Steve --- www.steve.org.uk pgpLOB6IOO6rM.pgp Description: PGP signature
Re: Bug marked as done messages to-be-MIMEified?
On Wed, May 14, 2003 at 01:46:47PM +0200, Matthias Urlichs wrote: Unless there's a strong preference to keep things the way they are, I'd like to prepare a patch to change that -- so speak up now. Many e-mail clients require the user to explicitly open an attached e-mail message in order to view the contents. I'd much rather not have to do that in order to discover why a bug has been closed - it's much more friendly to have the explanation from the e-mail in line in the close message. This needn't exclude the possibilty of having the message as an attachment but it's something that it'd be good to bear in mind. -- You grabbed my hand and we fell into it, like a daydream - or a fever.
Re: Please notify the maintainers when removing packages
On Wed, May 14, 2003 at 01:33:00PM +0200, Matthias Urlichs wrote: Hi, Richard Braakman wrote: On Thu, May 08, 2003 at 11:15:44PM +0200, Matthias Urlichs wrote: They will complain about Debian, not about their package's maintainer, when they upgrade to Sarge and the program they've been using is irretrievably auto-deinstalled. :-( Does this happen a lot? Both apt and dselect are very polite about not removing my packages. What tool do you use? The update to sarge will remove a whole lot of pachages because newer, differently-named packages replace them. Examples: coreutils. fileutils, shellutils, and textutils are still present and not conflicted with. My understanding is that they will still be there in sarge. The fact that one of the programs which you use daily, but have almost-forgotten the .deb name of, is among the lot of them may well get lost. After all, apt-get doesn't distinguish, if packages are removed because of missing dependencies, between those which have been Replaces:'d and those that haven't. Replaces: is frequently misunderstood. On its own (without Conflicts:), it does *not* mean that the whole target package has been superseded, and certainly does not mean that it will be automatically removed on upgrade. Furthermore, apt will tell you before removing packages, unless you have deliberately configured it otherwise. Anyone who ignores this is unwise at best. In addition, we are talking about packages being removed from the archive and you suddenly brought up packages being automatically uninstalled from people's systems. These two events are not directly related. The fact that a package is no longer available in the archive does *not* imply that it will be automatically removed, and in the majority of cases (C++ is unfortunately pathological) packages from woody will continue to work on sarge. In short, I don't think packages are automatically removed from people's systems as easily as you think. -- Colin Watson [EMAIL PROTECTED]
A strawman proposal: testing-x86 (Was: security in testing)
On Wed, May 14, 2003 at 02:22:05PM +0300, Chris Leishman wrote: I care about security in testing, and I believe others do too. But I don't think the process should be the same as with stable releases. Testing should not become another psudo stable distributionit's for testing. So I don't think security management needs to be anywhere near as comprehensive. *shrug* But maybe I'm wrong and it's just me who likes to run testing (to help out with 'testing' the distribution) but doesn't really like the idea of having to deal with known remote security problems. Maybe nobody else cares and I should just shut up ;-) Well, ideally, people could test packages in unstable. When I was first started experimenting with Debian, 4 years ago, I used to use unstable. But there was a time when I got bitten with a succession of bad uploads that trashed my system one way or another --- a buggy perl or lilo upload, that was not easy to repair. So that's why I jumped to testing --- because life was too short to have to stich my system together after a careless maintainer uploaded something that obviously couldn't have been tested before the upload, and that was happening too often. But after a while, I started noticing that way too many packages were never entering testing. In many cases, it was because they were stalled because of a platform-specific bug on another architecture, or because the package depended on a specific version of a very complicated package (such as glibc), and the complicated package was stalled for one or more reasons. If a large number of packages aren't entering testing, then obviously those packages can't get the benefit of wider testing by the people who use testing. In addition, some of my machines aren't necessarily behind firewires some or all of the time. A case in point is my laptop, where I actually do all of my mail reading and most of my developing these days. (With some help from distcc :-). Not being able to get security updates is a real problem those classes of machines where the administrator is willing to be run something bleeding edge, but for which security fixes are hung up because of RC bugs in the package or in some package dependency. I've solved the problem for myself by just simply biting the bullet and using unstable. I either have gotten lucky, or maintainers of core packages have gotten much more careful about testing their packages before uploading, so I haven't gotten screwed by updates as often as I did before. 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: * it's silly to not let a package be tested by a greater number of people if it's being held up due to a failure on an unrelated architecture. * it's silly to not let a package be tested by a greater number of people while we noodle over the question of whether the GNU FDL meets the DFSG, or whether the documentation needs to be eventually split out and put into non-free. So let me make the following modest strawman proposal. Let us posit the existence of a new distribution, which for now I'll name testing-x86. Let's set aside the question of whether there should be testing-arch for every single architecture, and whether this should supplant the existing testing distribution. Is the following feasiable operationally, from an implementation point of view, from a space on ftp servers point of view, etc? Let us assume that there is one or more human(s) in the loop, which server as the the master of the testing-x86 distribution. Once the required time period has been met based on the priority of the upload, if there are no RC bugs, then the package enters testing-x86 immediately. If there *are* RC bugs, notification of this fact plus a list of the RC bugs are sent to the testing-x86 master(s). If the RC bugs are not really critical for testing, then the human(s) in the loop can make a manual decision to allow that package to enter testing-x86. Since the testing-x86 distribution is, as the name suggests, specific only for the x86 architecture, RC bugs which are specific to other platforms needn't prevent the package from entering testing-x86. In practice, does this happen? Well, let's take a look at just one package as an example, glibc. Glibc currently has 4 RC bugs. But none of them would or should prevent the glibc in unstable from this proposed testing-x86 distribution: *) One bug is specific to sparc64 (#18838) *) One bug is specific to m68k (#184048) *) And two bugs are copyright issues; one is the GNU FDL
Re: security in testing
Michael Stone wrote: All the complaints we see every couple of weeks about testing would be swept away if people followed this advice and simply didn't use testing. This brings back the question I never got an answer for: Who is Debian for? If only stable and unstable are supposed to be used, Debian excludes the vast majority of computer users. Is this intentional? Is it desired? -- Björn
Re: Bug marked as done messages to-be-MIMEified?
On Wed, May 14, 2003 at 01:46:47PM +0200, Matthias Urlichs wrote: I hate inline mail forwarding. It loses information, breaks programs (inline-quoted mails typically get From: replaced by From: at some step), and makes things like signature checking needlessly complicated. debbugs forwards some emails as inline attachments, notably the bug has been marked 'done' confirmation. I think that's wrong. Yes, and also it causes nasty problems with character sets. There's at least one bug filed, and I've been meaning to change it for a while now. Unless there's a strong preference to keep things the way they are, I'd like to prepare a patch to change that -- so speak up now. Go ahead. -- Colin Watson [EMAIL PROTECTED]
Re: DebConf 3 for New Maintainers
On Wed, May 14, 2003 at 01:20:20PM +0200, Joachim Breitner wrote: Well enough introduction; my main question is: Would it make sense for me to attend Debcamp. Maybe my idea about DebCamp is wrong, but it sounds as if it is just a very large debian hacking session, so one needs to have something to hack on, and something to hack with. Would I find a task there, or should I make sure I have one beforehand? Do I have to bring my own PC? I'm not sure any of us really know what Debcamp will be like yet, given that it's the first time we've tried it as such. I certainly plan to have things ready for myself to hack on, but it will largely depend on who else is there. If other people on various teams I'm on show up then I'd certainly want to take advantage of that; after all working in closer cooperation with people than you can normally manage is the big advantage of a hackathon-style event. Still, I think it's clear that not everyone there will have projects ready for themselves. There'll be installer and bug-squashing types there at least who could always do with help and who can pass out tasks, and probably other teams I don't know about. If you're capable of diagnosing bugs and preparing patches I don't think you'll find yourself short of work. :) Do bring a laptop, or if necessary another type of machine, if you can. Although we've not had a Debcamp before, we've had smaller fairly disorganized hacking sessions at previous conferences and it would have been a real pain not to have had my laptop with my development environment. It also lets you be much more independent. I'd suggest bringing a wireless network card if you have one, just to avoid the hassle of wires trailing all over the place. (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?) -- Colin Watson [EMAIL PROTECTED]
Re: Bug marked as done messages to-be-MIMEified?
On Wed, May 14, 2003 at 01:59:41PM +0100, Mark Brown wrote: On Wed, May 14, 2003 at 01:46:47PM +0200, Matthias Urlichs wrote: Unless there's a strong preference to keep things the way they are, I'd like to prepare a patch to change that -- so speak up now. Many e-mail clients require the user to explicitly open an attached e-mail message in order to view the contents. I'd much rather not have to do that in order to discover why a bug has been closed - it's much more friendly to have the explanation from the e-mail in line in the close message. 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. -- Colin Watson [EMAIL PROTECTED]
Re: security in testing
On Wed, May 14, 2003 at 01:30:38PM +0100, Steve Kemp wrote: On Wed, May 14, 2003 at 03:04:10PM +0300, Kalle Kivimaa wrote: Why not? Testing would be my personal choice for running a desktop (or laptop) Linux, were I not otherwise involved with Debian development. The only bad thing is the non-existent security (I could live with occasional critical bug but the level of critical bugs in unstable is too much to bear for most users). There are, however, some pre-plans afoot regarding that (more or less running the same process as with stable, of course with different people responsible). What kind of pre-planning is taking place? The idea of security updates for testing? Every time this appears to have been raised it's usually shot down very quickly; unless I've missed something. I haven't seen it be shot down. I've seen people saying the infrastructure's there, it's just that nobody's actually doing the updates, though. However, I wasn't aware of any of the pre-plans Kalle refers to. I didn't think anyone had actually picked up this ball yet. -- Colin Watson [EMAIL PROTECTED]
Re: security in testing
Steve Kemp [EMAIL PROTECTED] writes: What kind of pre-planning is taking place? The idea of security updates for testing? Every time this appears to have been raised it's usually shot down very quickly; unless I've missed something. Actually the last time (if I searched the archives correctly) the response to the suggestion of providing security updates for testing was go ahead and do it, don't just complain. http://lists.debian.org/debian-devel/2003/debian-devel-200301/msg00237.html -- * Zathras is used to being beast of burden to other peoples' needs. Very * * sad life. Probably have very sad death, but at least there is symmetry. * * (Babylon 5, War Without End) * * PGP public key available @ http://www.iki.fi/killer *
Re: Status of Sarge Release Issues (Updated for May)
On Sat, May 10, 2003 at 10:16:40PM -0400, Morgon Kanter wrote: This one time, at band camp, Marc Haber [EMAIL PROTECTED] wrote: On Mon, 5 May 2003 17:17:20 -0500, Chris Cheney [EMAIL PROTECTED] wrote: I have read that Linus is planning to have 2.6 released before July and have 2.7 open for commits by Kernel Summit time (July). Can't remember where I heard it, but it was a reputable source. I heard that 2.6 was for release on the (American) night of Halloween. You're thinking of the feature freeze, which was October 31st (Halloween) of last year (2002). It went fairly well, actually, in terms of discipline of not letting new features after the code freeze. We beat up Linus pretty badly last year about how long the 2.4 freeze cycle went. There is an IRC discussion scheduled today to talk about the 2.5 shutdown / 2.6 release issues, and the current date which is being floated amongst the kernel developers is June or July. The Kernel Summit will be held just before the Ottawa Linux Symposium in July, and both Linus Torvalds and Andrew Morton (the annointed 2.6 maintainer) will be there. There have been jokes that if necessary, we will just get Linus really drunk and then rip it out of his hands and give it to Andrew if Linus 2.6.0 hasn't been released by then. :-) Seriously, although the date is not guaranteed, I think it's very likely that 2.6.0 will be out in Summer 2003. That being said, distro's may want to wait a while before they're confident enough to ship a 2.6 kernel as their default kernel in their distribution. Current guesses are that we'll likely see commercial distributions with 2.6 based releases as early as 2003 Q4, and more likely, 2004 Q1 or Q2. I'll note that with 774 RC bugs in the Debian as of this writing, given the typical rate at which RC bugs seem to being opened as well as closed out, it seems pretty likely that 2.6 will stablize long before Sarge is ready to ship. (This is not meant as a criticism; however, we can all choose to take this as a challenge if we wish. :-) - Ted
Re: Bug marked as done messages to-be-MIMEified?
Hi, Colin Watson wrote:
Yes, and also it causes nasty problems with character sets. There's at
least one bug filed, and I've been meaning to change it for a while now.
True.
Color me embarrassed for not checking the bug list before posting.
(#131881, for reference)
--
Matthias Urlichs | {M:U} IT Consulting @ m-u-it.de | [EMAIL PROTECTED]
Disclaimer: The quote was selected randomly. Really. | http://smurf.noris.de
--
If pro is the opposite of con, what is the opposite of progress?
Re: Bug marked as done messages to-be-MIMEified?
Hi, Mark Brown wrote:
Many e-mail clients require the user to explicitly open an attached e-mail
message in order to view the contents.
IMHO, if your client requires more keystrokes / mouseclicks to open an
attachment at the top than to scroll down to some random place near the
end of a message (depending on how large the close message actually is),
you should switch clients. ;-)
This needn't exclude the possibilty of having the message as an
attachment but it's something that it'd be good to bear in mind.
Hopefully your client honors the Content-Disposition: header, then this
isn't going to be a problem.
--
Matthias Urlichs | {M:U} IT Consulting @ m-u-it.de | [EMAIL PROTECTED]
Disclaimer: The quote was selected randomly. Really. | http://smurf.noris.de
--
Murphy's Last Law: If nothing went wrong today, you're probably dead.
Re: security in testing
On Wed, May 14, 2003 at 10:07:16AM +0300, Chris Leishman wrote: On Tuesday, May 13, 2003, at 05:20 PM, Matt Zimmerman wrote: If you want to see security updates for 'testing', then start preparing security updates for 'testing'. It does not help to describe in detail what you hope that someone else will do. The best (and often only) way for you to promote your agenda is to start doing the work. Actually - I didn't suggest this. I suggested there should be some consensus on what to do about security problems in testing - my main suggestion is that packages should be simply removed and the user notified of what actions they can do to get it back (such as upgrading to an unstable version, downgrading to a stable version, or fixing the bugs). I think that users would react rather negatively to having packages (ones that they use) effectively disappear from their system, but the only way to be certain is to experiment with the process. You can easily simulate this by providing dummy packages in a private repository. 1) People don't run testing, and hence we lose a large portion of our testing process [...] The important point was the first one. The 2nd one was just another effect of not doing anything about the issue which some people might care about. We didn't even have testing until quite recently, and it is likely that unstable users still provide the majority of our testing. IMHO, it is only particularly valuable for users to run testing when a release is approaching (at which point security updates and removals take place en masse). If you do not accept the arguments against this, then start doing it, and see whether it is worthwhile. I can't just start doing it. For one this is the sort of issue that needs a bit of consensus and input from the people actually in charge of the process. It's not like just submitting a patch or uploading a new package. I also clearly stated it's just an example of what could be done, but I think there may be better ways... You can be in charge of the process if you are willing to make the effort. It is a lot like uploading a new package, only outside of the Debian archive. It's more of a policy issue first. Once thats worked out, then we can worry about the how. Debian policy seems to be formed as a result of consensus, to reflect what is already known to work, and usually not as a means to effect widespread change. Debian developers in general should start to do X is often the very last step in the process, not the first. Yes, there are. But all of these loose one of the main reasons I feel we even have a testing distribution - to have people testing it. If testing were to do nothing more than ensure consistency in dependencies, architectures and source/binary relationships, then it would still be very much worthwhile. 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. Again I agree. All I think is that removal of security issues should be done before it even gets into testing. My suggested policy was that nothing with a security bug should go into testing - and anything with a security bug should be removed via an empty upgrade (and the user informed). Of course there's may be other ways that have the same basic effect. If packages in 'testing' were constantly disappearing without warning, this would seem to make it significantly less attractive to users (which you would seem to want to avoid). - 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
Re: security in testing
On Wed, May 14, 2003 at 02:20:51PM +0100, Colin Watson wrote: I haven't seen it be shot down. I've seen people saying the infrastructure's there, it's just that nobody's actually doing the updates, though. Yes I've seen this mentioned previously also. If it's a matter of finding people it should be obvious very quickly whether there are spare resources. I'm honestly not sure how much involvement would be necessary, I guess unlike updates to stable there wouldn't be so many controls upon the testing archive, and uploads could be made directly without any real problem. If it just comes down to applying patches, and doing the rebuilds then it seems to be the kind of job a small team could manage; unless I'm missing something? However, I wasn't aware of any of the pre-plans Kalle refers to. I didn't think anyone had actually picked up this ball yet. Unless somebody steps forward just now I'll asusme that the ball is still dropped ;) Steve -- pgpYxgAV6f1vc.pgp Description: PGP signature
Re: Bug marked as done messages to-be-MIMEified?
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. -- You grabbed my hand and we fell into it, like a daydream - or a fever.
Re: Debian MIA check
Hi, Branden Robinson wrote:
Is there a mnemonic for that? I.e., does wat stand for something?
Is that email address an alias for [EMAIL PROTECTED] ?
(ObTLA: mia == missing in action)
--
Matthias Urlichs | {M:U} IT Consulting @ m-u-it.de | [EMAIL PROTECTED]
Disclaimer: The quote was selected randomly. Really. | http://smurf.noris.de
--
The bad reputation UNIX has gotten is totally undeserved, laid on by people
who don't understand, who have not gotten in there and tried anything.
-- Jim Joyce, owner of Jim Joyce's UNIX Bookstore
Re: security in testing
Hi, Michael Stone wrote:
All the complaints
we see every couple of weeks about testing would be swept away if people
followed this advice and simply didn't use testing.
So why is there a testing in the first place if nobody's supposed to use
it??
Sorry, but I think I agree with the proposal to do security updates for
testing...
--
Matthias Urlichs | {M:U} IT Consulting @ m-u-it.de | [EMAIL PROTECTED]
Disclaimer: The quote was selected randomly. Really. | http://smurf.noris.de
--
Deliver yesterday, code today, think tomorrow.
Re: security in testing
Colin Watson [EMAIL PROTECTED] writes: However, I wasn't aware of any of the pre-plans Kalle refers to. I didn't think anyone had actually picked up this ball yet. Pre-plans in this case means that two people (one DD and one NM) have been talking about it seriously. So, if you want to shoot the idea down, go ahead, no harm done :) And if someone else is thinking about picking up the ball, go ahead, the pre-planners are probably willing to join any other initiative as well. -- * Zathras is used to being beast of burden to other peoples' needs. Very * * sad life. Probably have very sad death, but at least there is symmetry. * * (Babylon 5, War Without End) * * PGP public key available @ http://www.iki.fi/killer *
Re: DebConf 3 for New Maintainers
Hi, Andreas Tille wrote:
By the
way what kind of school is it which has no holidays at this time?
Random factoid: The German sub-states have a staggered school holiday
schedule so that the Autobahn will still be somewhat-free _sometimes_
during these six weeks. (Seriously.)
Bavaria is last; the school holiday here starts sometime late July.
--
Matthias Urlichs | {M:U} IT Consulting @ m-u-it.de | [EMAIL PROTECTED]
Disclaimer: The quote was selected randomly. Really. | http://smurf.noris.de
--
Few people now believe in the devil; but very many enjoy behaving as their
ancestors behaved when the Fiend was a reality as unquestionable as his
Opposite Number.
Re: Do not touch l10n files (was Re: DDTP issue)
Hi, Theodore Ts'o wrote:
To the extent that the DDTP gives the package maintainer veto rights, it
seems pretty clear that at least initially the DDTP believed that the
package maintainer was ultimately responsible.
It's the maintainer's name and signature on the package, after all.
On the other hand, the maintainer has to be able to trust their
translators. They're presumably doing it for the good of Debian and not
because they want to push their own agendas by subverting translations.
To get back to the case which triggered all this (reformatting a
comma-separated enumeration into a list), IMHO there is a perfectly valid
reason to do that -- Engllish-language text typically is shorter than the
equivalent in other languages, and French (with its tendency not to use
any nice short English-language words if it can possibly be helped) is no
exception.
Thus, what might be a nicely concise list of package attributes turns into
an unwieldy mess when translated to French or German. :-/
--
Matthias Urlichs | {M:U} IT Consulting @ m-u-it.de | [EMAIL PROTECTED]
Disclaimer: The quote was selected randomly. Really. | http://smurf.noris.de
--
Someone on IRC was very sad about the uptime of his machine wrapping
from 497 days to 0.
-- linux-kernel
Re: Do not touch l10n files (was Re: DDTP issue)
Hi, Martin Quinson wrote:
It must be so in French.
Sorry for being pedantic, but must is an overly strong word here.
You may have valid reasons for not using a comma-separated list here, but
French grammar certainly allows comma-separated enumerations if one so
desires. (Spoken language, for instance, if nothing else.)
They may be bad style (see my other email on that), but they're not
actually _forbidden_ by anybody.
--
Matthias Urlichs | {M:U} IT Consulting @ m-u-it.de | [EMAIL PROTECTED]
Disclaimer: The quote was selected randomly. Really. | http://smurf.noris.de
--
A paranoid is a man who knows a little of what's going on.
-- William S. Burroughs
Re: security in testing
On Wed, May 14, 2003 at 10:19:08AM -0400, Matt Zimmerman wrote: 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. (emphasis added) http://www.debian.org/security/faq Q: How is security handled for testing and unstable? A: The short answer is: it's not. Testing and unstable are rapidly moving targets and the security team does not have the resources needed to properly support those. If you want to have a secure (and stable) server you are strongly encouraged to stay with stable. However, the security secretaries will try to fix problems in testing and unstable after they are fixed in the stable release. What is missing is a statement warning users that testing is less secure than unstable. Friendly, Sven Luther
Re: security in testing
On Wed, May 14, 2003 at 10:19:08AM -0400, Matt Zimmerman wrote: On Wed, May 14, 2003 at 10:07:16AM +0300, Chris Leishman wrote: On Tuesday, May 13, 2003, at 05:20 PM, Matt Zimmerman wrote: If you want to see security updates for 'testing', then start preparing security updates for 'testing'. It does not help to describe in detail what you hope that someone else will do. The best (and often only) way for you to promote your agenda is to start doing the work. Actually - I didn't suggest this. I suggested there should be some consensus on what to do about security problems in testing - my main suggestion is that packages should be simply removed and the user notified of what actions they can do to get it back (such as upgrading to an unstable version, downgrading to a stable version, or fixing the bugs). I think that users would react rather negatively to having packages (ones that they use) effectively disappear from their system, but the only way to be certain is to experiment with the process. You can easily simulate this by providing dummy packages in a private repository. 1) People don't run testing, and hence we lose a large portion of our testing process [...] The important point was the first one. The 2nd one was just another effect of not doing anything about the issue which some people might care about. We didn't even have testing until quite recently, and it is likely that unstable users still provide the majority of our testing. IMHO, it is only particularly valuable for users to run testing when a release is approaching (at which point security updates and removals take place en masse). Yes, but this is not something that is clearly said. Many people run testing without even being aware that there may be security issues, or more precisely, that the security issues are orders of magnitude worse than even what is in sid. Friendly, Sven Luther
Re: Bug marked as done messages to-be-MIMEified?
On Wed, May 14, 2003 at 03:57:09PM +0200, Matthias Urlichs wrote: Hi, Colin Watson wrote: Yes, and also it causes nasty problems with character sets. There's at least one bug filed, and I've been meaning to change it for a while now. True. Color me embarrassed for not checking the bug list before posting. (#131881, for reference) No, that's decoding of MIME messages in the CGI scripts, which is completely different. At the moment the only thing I can find is buried in the middle of #136654, so maybe it was actually only filed in my brain (which has no web interface) ... -- Colin Watson [EMAIL PROTECTED]
Re: security in testing
On Wed, May 14, 2003 at 03:00:17PM +0100, Steve Kemp wrote: I'm honestly not sure how much involvement would be necessary, I guess unlike updates to stable there wouldn't be so many controls upon the testing archive, and uploads could be made directly without any real problem. There certainly should be controls, if package uploads were to be allowed to bypass the normal delay in unstable. If it just comes down to applying patches, and doing the rebuilds then it seems to be the kind of job a small team could manage; unless I'm missing something? So far nobody has lifted a finger as far as I know, though many people talk about how critically important it is (cough). -- - mdz
Re: Debian MIA check
* Matthias Urlichs [EMAIL PROTECTED] [2003-05-14 16:00]: Is there a mnemonic for that? I.e., does wat stand for something? Is that email address an alias for [EMAIL PROTECTED] ? No. -- Martin Michlmayr [EMAIL PROTECTED]
Re: Debian MIA check
On Wed, 14 May 2003, Matthias Urlichs [EMAIL PROTECTED] wrote... Hi, Branden Robinson wrote: Is there a mnemonic for that? I.e., does wat stand for something? Is that email address an alias for [EMAIL PROTECTED] ? (ObTLA: mia == missing in action) Or should that be awol@ ? (Absent with-out leave) -- dopey!debian.org http://www.debian.org/
Re: security in testing
[Back story: this thread started because there is still a vulnerability in the version of Samba in testing, which has been fixed in both stable and unstable. Collateral bugs prevent Samba from propagating from unstable to testing any time soon.] On Wed, May 14, 2003 at 06:22:26PM +1000, Anthony Towns wrote: On Wed, May 14, 2003 at 10:07:16AM +0300, Chris Leishman wrote: Actually - I didn't suggest this. I suggested there should be some consensus on what to do about security problems in testing - my main suggestion is that packages should be simply removed and the user notified of what actions they can do to get it back (such as upgrading to an unstable version, downgrading to a stable version, or fixing the bugs). This isn't possible in general; when mysql has a security problem you can't just tell people to (a) not use it, or (b) just run the unstable/stable version anyway, in spite of whatever reasons they based their decision to use testing on in the first place. We already know the right way of dealing with security bugs; we do it for our stable releases. If you care about security and testing, all you have to do is the same thing that's being done there. It's really that simple. I'm not sure what you mean by the same thing, but as I see it, there are three possible ways to get a fixed package into testing: an upload to security.debian.org, an upload to testing-proposed-updates that's accepted into the main archive, or via the normal unstable-testing propagation. Figuring that a security upload would be preferable, I approached the security team and offered to prepare an upload. I was effectively told that this isn't done, and because it isn't done, most testing users don't have security.d.o in their sources.list, so don't bother. Since the security.debian.org site is under the administrative control of the security team, it doesn't seem like this is going to go anywhere without their acquiescence. That leaves t-p-u, or the normal unstable-testing route. Well, as release manager, I would expect you to be the one to approve an upload to t-p-u. If the right way to handle this is via security.d.o, presumably you think an upload to t-p-u is the wrong way? The only remaining option is to get a dependency chain that passes muster with the testing scripts. While this is a goal anyway, and while fixing the RC bugs in other packages is good for the release as a whole :), it's certainly the least efficient way to make a fixed package available and does nothing to help those testing users whose machines are being compromised today because they had no reason to believe they should add deb http://security.debian.org/ woody/updates main on a machine running testing. So, I guess I'll be filing with ftp.d.o to have the vulnerable Samba package removed from testing. -- Steve Langasek postmodern programmer pgpYlemQyr5og.pgp Description: PGP signature
Re: Bug marked as done messages to-be-MIMEified?
On Wed, May 14, 2003 at 03:58:44PM +0200, Matthias Urlichs wrote: attachment at the top than to scroll down to some random place near the end of a message (depending on how large the close message actually is), you should switch clients. ;-) Not everyone will be able to do that, of course. If people don't think users with problem mail clients are going to be that big a deal then I'd say go for it. -- You grabbed my hand and we fell into it, like a daydream - or a fever.
Re: Do not touch l10n files (was Re: DDTP issue)
On Wednesday 14 May 2003 14:27, Theodore Ts'o wrote:
On Wed, May 14, 2003 at 12:07:29PM +0200, Martin Quinson wrote:
Your engagement for the quality of your package is really great. Only, I
think that you are not responsible of the translation. I know that there
is a lack in debian framework concerning this point, but it really should
be so ('cause maintainer cannot be responsible for translations they do
not understand. How do you handle tranlations in russian, japaneese and
bokmal?).
This is a fundamental question for which there definitely isn't
consensus, and it is a fundamental polity (governance) issue.
Yes, it is also linked with the problem of Translators' status in Debian.
The Constitution says :
Developers are volunteers who agree to further the aims of the Project
insofar as they participate in it, and who maintain package(s) for the
Project or do other work which the Project Leader's Delegate(s) consider
worthwhile.
So if a Delegate consider Translators' work worthwile or if Translators
maintain packages, they should be given the Developer status (if they follow
the same kind of new maintainer process of course) and then be responsible
for their work as well as Developers.
One is that the linguistic teams have full and ultimate responsibility
over the translations, and there is no recourse or appeal if the
maintainer doesn't like what they have done.
There can be some recourse or appeal (to some committee or to the Project
Leader) and the translator teams still maintain full and ultimate
responsibility as well as Developers do. Don't give us false alternatives.
Another position is that the maintainer is ultimately responsible; he
or she may delegate responsibility to helpers, just as the Debian
Leader may delegate certain responsibilities to subordinates.
This would clearly create 2 class of citizens within Debian or at least
another hierachical level.
I wont go further discussing your message. The problem exists and has been
ignored for a (too) long time. And my preference is clear.
Regards anyway,
Christian Couder (translator of Debian web pages since 1999 and still not
Developer, so with no vote).
Re: security in testing
On Wed, May 14, 2003 at 06:35:46PM +0200, Sven Luther wrote: Yes, but this is not something that is clearly said. Many people run testing without even being aware that there may be security issues, or more precisely, that the security issues are orders of magnitude worse than even what is in sid. This is documented prominently on the website. If people do not look before they leap, there is little we can do. -- - mdz
Re: security in testing
Michael Stone dijo [Wed, May 14, 2003 at 08:25:45AM -0400]: Yes, there are. But all of these loose one of the main reasons I feel we even have a testing distribution - to have people testing it. You are falling into the trap of overselling testing. Having people test testing at this point in the development cycle is useless, because the real activity is in unstable. You're trying to make testing something it isn't, then trying to reshape policy to meet your idea of what testing should be. You're hardly the first to do that, but it's no more correct this time. I strongly recommend that *nobody* run testing as a everyday system, because it just isn't a good choice for that. All the complaints we see every couple of weeks about testing would be swept away if people followed this advice and simply didn't use testing. 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. Of course, currently it is not due to debian-installer is still not ready for human consumption... But the bulk of testing should always be usable. Testing was introduced because the inadequacy of freezing unstable for months in order to get a release done. -- Gunnar Wolf - [EMAIL PROTECTED] - (+52-55)5630-9700 ext. 1366 PGP key 1024D/8BB527AF 2001-10-23 Fingerprint: 0C79 D2D1 2C4E 9CE4 5973 F800 D80E F35A 8BB5 27AF
Re: xf86config bug
On Wed, May 14, 2003 at 01:43:10PM +0100, Neil McGovern wrote: I can't seem to find the package that xf86config belongs to, but the bug is as follows: apt-get install reportbug reportbug `which xf86config` reportbug will allow you to look at existing bug reports (which you should) before filing the bug. -- - mdz
Re: security in testing
Hi, Matt Zimmerman wrote:
IMHO, it is
only particularly valuable for users to run testing when a release is
approaching (at which point security updates and removals take place en
masse).
Wasn't testing supposed to be a perpetually mostly-releasable Debian?
Anyway, a release is _always_ approaching (until the time Debian dies, of
course...) -- the question is how far away it is. ;-)
--
Matthias Urlichs | {M:U} IT Consulting @ m-u-it.de | [EMAIL PROTECTED]
Disclaimer: The quote was selected randomly. Really. | http://smurf.noris.de
--
Disc space -- the final frontier!
Re: DebConf 3 for New Maintainers
Hi, Am Mit, 2003-05-14 um 14.22 schrieb Andreas Tille: On 14 May 2003, Joachim Breitner wrote: I am considering going to DebConf 3. Now Oslo is not really close (I live in southern germany), and being a High School student, I would have to argue with my principal whether I may go or not during school time, so it should be worth the money and effort. I doubt that you will get any better education than at Debcamp. By the way what kind of school is it which has no holidays at this time? Gymnasium in Baden-Würtemberg (For our english-speakers: Gymnasium in German is not the gym, but a kind of public High School) Do I have to bring my own PC? 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*) What are your experiences, and what would you suggest a debian (the project, not the distro) newbie? If you know the distro you know the unsolved problems. If you have trouble finding problems which might be solved I would volunteer to compile a list. ;-)) 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. 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. Joachim -- Joachim Breitner e-Mail: [EMAIL PROTECTED] | Homepage: http://www.joachim-breitner.de JID: [EMAIL PROTECTED] | GPG-Keyid: 4743206C | ICQ#: 74513189 Geekcode: GCS/IT/S d-- s++:- a--- C++ UL+++ P+++ !E W+++ N-- !W O? M?+ V? PS++ PE PGP++ t? 5? X- R+ tv- b++ DI+ D+ G e+* h! z? Bitte senden Sie mir keine Word- oder PowerPoint-Anhänge. Siehe http://www.fsf.org/philosophy/no-word-attachments.de.html -- Joachim Breitner e-Mail: [EMAIL PROTECTED] | Homepage: http://www.joachim-breitner.de JID: [EMAIL PROTECTED] | GPG-Keyid: 4743206C | ICQ#: 74513189 Geekcode: GCS/IT/S d-- s++:- a--- C++ UL+++ P+++ !E W+++ N-- !W O? M?+ V? PS++ PE PGP++ t? 5? X- R+ tv- b++ DI+ D+ G e+* h! z? Bitte senden Sie mir keine Word- oder PowerPoint-Anhänge. Siehe http://www.fsf.org/philosophy/no-word-attachments.de.html signature.asc Description: Dies ist ein digital signierter Nachrichtenteil
Re: Do not touch l10n files (was Re: DDTP issue)
[I only speak for myself, and not for the french translation team neither
for the ddtp, in which I'm not involved at all. Please flame *me* for what I
say]
On Wed, May 14, 2003 at 08:27:02AM -0400, Theodore Ts'o wrote:
On Wed, May 14, 2003 at 12:07:29PM +0200, Martin Quinson wrote:
Your engagement for the quality of your package is really great. Only, I
think that you are not responsible of the translation. I know that there is
a lack in debian framework concerning this point, but it really should be so
('cause maintainer cannot be responsible for translations they do not
understand. How do you handle tranlations in russian, japaneese and
bokmal?).
This is a fundamental question for which there definitely isn't
consensus, and it is a fundamental polity (governance) issue.
One is that the linguistic teams have full and ultimate responsibility
over the translations, and there is no recourse or appeal if the
maintainer doesn't like what they have done.
Another position is that the maintainer is ultimately responsible; he
or she may delegate responsibility to helpers, just as the Debian
Leader may delegate certain responsibilities to subordinates.
However, it is clear that the maintainer or the Debian Leader is
ultimately responsible, even if the wise maintainer and/or Debian
Leader may not choose to exercise his or her perogatives very often.
This point is a subtle one. I will point out that in a corporate
setting, it's quite normal for the employer's manager and or his
manager's manager will not fully understand all of the work that that
the employee does. Yet they are still responsible for the work of the
employee, and if they don't like it, they can tell the employee to do
things a different way, or in the extreme case, they can fire him.
Obviously, if the manager doesn't completely understand what the
employee is doing, there will be a certain negotiation, and a certain
back and forth over goals and directions and what is and isn't
technically possible, etc. Hopefully, said negotiations will be done
in a mutally respectful and civil manner. But that doesn't change the
fact that ultimately the manager gets to have the final say.
Which model people subscribe to makes a lot of difference in how they
communicate. For example, if your manager doesn't like the work that you
do, even if you think his grounds for objecting may not be the best
ones, would you tell him, tough luck? Probably not
- Ted
P.S. To the extent that the DDTP gives the package maintainer veto
rights, it seems pretty clear that at least initially the DDTP
believed that the package maintainer was ultimately responsible.
Given comments and the tenor of the tone made by some of the people on
some of the language teams, it's not clear they believe that as
strongly today.
Please keep in mind that I have nothing to do with the DDTP. My advice is
personal.
I completely agree with you on several points, like the fact that there is
no special reason in the constitution or in policy or in BCP or in any
official Debian writting to say that the maintainer is not responsible for
the content of the translations.
I only meant that it's rather illogical to ask to maintainer to review texts
in languages he/she don't understand. I know that this issue is related to
what can be found for porting to architectures the maintainer does not know,
but still, there is some quite fundamental differences here.
Thanks to the wonderfull dbuild architecture, it is very easy to know if
there *is* a problem on a given architecture, and what the right solution
is (apply patches as long as dbuild repports an error).
This is not true for translations, since no mecanical validation is enough.
Even if a text is ispell-clean, there might be a ton of gramatical error,
typographical ones and even badly constructed sentences which do not sound
well.
Moreover, languages are sometimes difficult even for native speaker. French
is a rather good example of this complexity, and explains why we cam up with
so complicated reviewing processes within our team: webpages are posted at
least three time to the ML, in [ITT] mails for 'intend to translate', [DDR]
for 'ask for review', and [RELU] for 'reviewed, ready to be commited'
emails ; the DDTP integrate a reviewing process where all description have to
be accepted by 3 other translators before being declared as usable by the
end user.
So, if we need so much work to find a good translation when all involved
people are native french speaker, how can you explain that maintainers can
'detect errors in our work' (like the use of the non breaking space ASCII
code to follow our typographical rules), and corrupt our work so easily?
Please note that this discussion, like most of the previous ones on this
topic, is moving from a very simple problem (maintainer shouldn't try to
fix translation when they are not native
Re: Do not touch l10n files
On Wed, 14 May 2003 12:07:29 +0200, Martin Quinson [EMAIL PROTECTED] said:
Your engagement for the quality of your package is really
great. Only, I think that you are not responsible of the
translation.
The maintainer is responsible for the package. And, unless the
translation is not part of the package, the maintainer is responsible
for it.
I know that there is a lack in debian framework concerning this
point, but it really should be so ('cause maintainer cannot be
responsible for translations they do not understand. How do you
handle tranlations in russian, japaneese and bokmal?).
Heck, there are parts of the code for packages that I maintain
that I may not totally understand; but I am still responsible for
the package. When there are things I think the upstream has done
incorrectly, I ask for help, or do research, and learn ennough to
modify things, or revert recent changes.
The same applies to translations.
manoj
--
Old soldiers never die. Young ones do.
Manoj Srivastava [EMAIL PROTECTED] http://www.debian.org/%7Esrivasta/
1024R/C7261095 print CB D9 F4 12 68 07 E4 05 CC 2D 27 12 1D F5 E8 6E
1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C
Re: Do not touch l10n files
On Wed, 14 May 2003 16:27:53 +0200, Matthias Urlichs [EMAIL PROTECTED] said: Hi, Theodore Ts'o wrote: To the extent that the DDTP gives the package maintainer veto rights, it seems pretty clear that at least initially the DDTP believed that the package maintainer was ultimately responsible. It's the maintainer's name and signature on the package, after all. Quite so. On the other hand, the maintainer has to be able to trust their translators. They're presumably doing it for the good of Debian and not because they want to push their own agendas by subverting translations. I trust my upstreams too. But I always look through the diffs on updates, and I have local patches to fix upstream bugs all the time. I may not undestand intricate upstream code, but that does not prevent me from fixing obvious bugs. I see the translations as upstream. A different upstream, perhaps, than the rest of the code, but I retain control of what goes in my packages. manoj -- I don't make the rules, Gil, I only play the game. Cash McCall Manoj Srivastava [EMAIL PROTECTED] http://www.debian.org/%7Esrivasta/ 1024R/C7261095 print CB D9 F4 12 68 07 E4 05 CC 2D 27 12 1D F5 E8 6E 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C
Re: xf86config bug
On Wed, May 14, 2003 at 01:43:10PM +0100, Neil McGovern wrote: I can't seem to find the package that xf86config belongs to dpkg -S `which xf86config` xbase-clients: /usr/X11R6/bin/xf86config Christoph -- ~ ~ .signature [Modified] 3 lines --100%--3,41 All
Re: A strawman proposal: testing-x86 (Was: security in testing)
On Wed, 2003-05-14 at 09:14, Theodore Ts'o wrote: I've solved the problem for myself by just simply biting the bullet and using unstable. I either have gotten lucky, or maintainers of core packages have gotten much more careful about testing their packages before uploading, so I haven't gotten screwed by updates as often as I did before. I think the latter is generally the case. People who upload broken stuff to unstable get berated pretty heavily. So here are my questions. Is the testing-x86 distribution a crazy idea? How hard would it be to implement it? Actually adding a distribution is pretty easy. All it really needs is Packages and Sources files for the most part, which are very small relative to the archive size. The only negative consequence I can think of is that the real testing would probably get less, well, testing.
Re: A strawman proposal: testing-x86
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. manoj -- The scientific theory I like best is that the rings of Saturn are composed entirely of lost airline luggage. Mark Russell Manoj Srivastava [EMAIL PROTECTED] http://www.debian.org/%7Esrivasta/ 1024R/C7261095 print CB D9 F4 12 68 07 E4 05 CC 2D 27 12 1D F5 E8 6E 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C
Re: Returning from vacation. (MIA?)
On Wed, 14 May 2003 11:45:48 +0200, Matthias Urlichs [EMAIL PROTECTED] said: Hi, Matt Zimmerman wrote: Or do you send one of those obnoxious autoreplies asking people to confirm their messages to you? FWIW, if they are only sent in reply to spam status dubious messages, I wouldn't call them obnoxious. I am not sure I understand. If such a message is sent to me, I certainly find them obnoxious. I have low-scored all sauce messages away to oblivion. manoj -- One may desire a spurious respect and precedence among one's fellow monks, and the veneration of outsiders. Both monks and laity should think it was my doing. They should accept my authority in all matters great or small. This is a fool's way of thinking. His self-seeking and conceit just increase. 73, 74 Manoj Srivastava [EMAIL PROTECTED] http://www.debian.org/%7Esrivasta/ 1024R/C7261095 print CB D9 F4 12 68 07 E4 05 CC 2D 27 12 1D F5 E8 6E 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C
Re: security in testing
On Wed, 14 May 2003 15:16:38 +0200, Björn Stenberg [EMAIL PROTECTED] said: Michael Stone wrote: All the complaints we see every couple of weeks about testing would be swept away if people followed this advice and simply didn't use testing. This brings back the question I never got an answer for: Who is Debian for? Isn't is obvious? Me, of course. Y'all are working to provide a stable environment for my machines at home. Least ways, that's what I am working for. ;-) manoj -- Now I'm having INSIPID THOUGHTS about the beatiful, round wives of HOLLYWOOD MOVIE MOGULS encased in PLEXIGLASS CARS and being approached by SMALL BOYS selling FRUIT ... Manoj Srivastava [EMAIL PROTECTED] http://www.debian.org/%7Esrivasta/ 1024R/C7261095 print CB D9 F4 12 68 07 E4 05 CC 2D 27 12 1D F5 E8 6E 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C
