Re: (forw) Re: @euro support with new languagechooser (was: dropping tc1)
Quoting Steve Langasek ([EMAIL PROTECTED]): > Even though there are different locale variants available for historical > reasons, I think there is no reason we need to support more than one > variant for each locale in new installs. So a simple mapping list in > countrychooser should be sufficient. Or trigger reconfiguring locales in base-config with prefeeded debconf values, maybejust an idea : I didn't examine all possible consequences. After all, having the variant properly chosen is only meaningful in 2nd-stage, not in 1st-stage -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: (forw) Re: @euro support with new languagechooser (was: dropping tc1)
On Tue, Jun 22, 2004 at 07:12:27AM +0200, Christian Perrier wrote: > Quoting Denis Barbier ([EMAIL PROTECTED]): > > But generated locales differ because different encodings are passed to > > localedef: > > $ LANG=fr_FR locale charmap > > ISO-8859-1 > > $ [EMAIL PROTECTED] locale charmap > > ISO-8859-15 > > Steve mentions in another message that switching fr_FR encoding to > > ISO-8859-15 cannot be done without discussion, but glibc upstream > > has a definitive position: encodings are never changed, period. > > (It recently surfaces again about et_EE) > > So this discussion is over before it begins ;) > So, as a conclusion, these @euro locales are only motivated because > they are associated with different encodings, not because of their > contents. > So I guess we have to find a way to deal with variants in the > Installer.. > variantchooser ? :-) Even though there are different locale variants available for historical reasons, I think there is no reason we need to support more than one variant for each locale in new installs. So a simple mapping list in countrychooser should be sufficient. -- Steve Langasek postmodern programmer signature.asc Description: Digital signature
Re: dropping tc1
Quoting Christian Perrier ([EMAIL PROTECTED]): > Which I currently do not understand really. I suspect this is because > all countries that are likely to be displayed in this short list do > not have their name translated in Arabic but I'm unsure No, this is because countrychooser does not have an Arabic translation yet (debian/po/ar.po). I added a fake one with 0 strings translated and the short list is now built and will be shown (in English because ISO-3166 remains to be translated). -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: (forw) Re: @euro support with new languagechooser (was: dropping tc1)
Quoting Denis Barbier ([EMAIL PROTECTED]): > But generated locales differ because different encodings are passed to > localedef: > $ LANG=fr_FR locale charmap > ISO-8859-1 > $ [EMAIL PROTECTED] locale charmap > ISO-8859-15 > > Steve mentions in another message that switching fr_FR encoding to > ISO-8859-15 cannot be done without discussion, but glibc upstream > has a definitive position: encodings are never changed, period. > (It recently surfaces again about et_EE) > So this discussion is over before it begins ;) So, as a conclusion, these @euro locales are only motivated because they are associated with different encodings, not because of their contents. So I guess we have to find a way to deal with variants in the Installer.. variantchooser ? :-) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: dropping tc1
Quoting Steve Langasek ([EMAIL PROTECTED]): > Just to confirm, there are a fair number of translations available for > languagechooser, and the reason for the full countrychooser list was > that I was testing Arabic, which doesn't have a shortlist yet. :) Which I currently do not understand really. I suspect this is because all countries that are likely to be displayed in this short list do not have their name translated in Arabic but I'm unsure Indeed, we should record this as a minor bug against countrychooser. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: dropping tc1
On Mon, Jun 14, 2004 at 10:32:51PM +0200, Christian Perrier wrote: > Quoting Steve Langasek ([EMAIL PROTECTED]): > > In the tests I've done with the new languagechooser, almost all of the > > entries are displayed in English, and there doesn't seem to be a short > > list provided by countrychooser. This seems like a significant > > regression for the common case; I think it's better to delay the new > > languagechooser until rc2. > Hmmm, I'm surprised of this > Currently, things are OK with sid_d-i builds... Just to confirm, there are a fair number of translations available for languagechooser, and the reason for the full countrychooser list was that I was testing Arabic, which doesn't have a shortlist yet. :) -- Steve Langasek postmodern programmer signature.asc Description: Digital signature
Re: (forw) Re: @euro support with new languagechooser (was: dropping tc1)
On Mon, Jun 21, 2004 at 05:46:25PM +0200, Christian Perrier wrote: > (I announced a CC and forgot to really do it) > > - Forwarded message from Christian Perrier <[EMAIL PROTECTED]> - > > Date: Mon, 21 Jun 2004 17:45:21 +0200 > From: Christian Perrier <[EMAIL PROTECTED]> > To: [EMAIL PROTECTED] > Subject: Re: @euro support with new languagechooser (was: dropping tc1) > > Quoting Steve Langasek ([EMAIL PROTECTED]): > > (comparing fr_FR and [EMAIL PROTECTED] more generally all @euro > variants of locales) > > > So there's no difference in the actual charset that each is pointed to, > > the only difference is in a comment about the charset? > > Yes, as far as I understand. [EMAIL PROTECTED] only uses > > copy "fr_FR" > > everywhere But generated locales differ because different encodings are passed to localedef: $ LANG=fr_FR locale charmap ISO-8859-1 $ [EMAIL PROTECTED] locale charmap ISO-8859-15 Steve mentions in another message that switching fr_FR encoding to ISO-8859-15 cannot be done without discussion, but glibc upstream has a definitive position: encodings are never changed, period. (It recently surfaces again about et_EE) So this discussion is over before it begins ;) Denis -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: @euro support with new languagechooser (was: dropping tc1)
On Mon, Jun 21, 2004 at 05:45:21PM +0200, Christian Perrier wrote: > Quoting Steve Langasek ([EMAIL PROTECTED]): > (comparing fr_FR and [EMAIL PROTECTED] more generally all @euro > variants of locales) > > So there's no difference in the actual charset that each is pointed to, > > the only difference is in a comment about the charset? > Yes, as far as I understand. [EMAIL PROTECTED] only uses > copy "fr_FR" > everywhere > While fr_FR LC_MONETARY section refers to the Euro currencywhich > is logical in 2004..:-) > same for nl_NL and all [EMAIL PROTECTED] locales > I guess @euro variants were basically transition variants. They are > now useless.except that many users still continue to use them > pointlessly. > This is my understanding of all these things, of course. Well, the ISO-8859-15 charset contains a codepoint for the euro symbol, and the ISO-8859-1 charset does not, so as long as fr_FR maps to ISO-8859-1, it cannot support the euro; and changing it to point to ISO-8859-15 is probably something that needs to be discussed. -- Steve Langasek postmodern programmer signature.asc Description: Digital signature
Re: @euro support with new languagechooser (was: dropping tc1)
Quoting Steve Langasek ([EMAIL PROTECTED]): (comparing fr_FR and [EMAIL PROTECTED] more generally all @euro variants of locales) > So there's no difference in the actual charset that each is pointed to, > the only difference is in a comment about the charset? Yes, as far as I understand. [EMAIL PROTECTED] only uses copy "fr_FR" everywhere While fr_FR LC_MONETARY section refers to the Euro currencywhich is logical in 2004..:-) same for nl_NL and all [EMAIL PROTECTED] locales I guess @euro variants were basically transition variants. They are now useless.except that many users still continue to use them pointlessly. This is my understanding of all these things, of course. Let's CC debian-i18n just to check if others have complements to this. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: @euro support with new languagechooser (was: dropping tc1)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Monday 21 June 2004 17:20, Steve Langasek wrote: > So there's no difference in the actual charset that each is pointed to, > the only difference is in a comment about the charset? Well, the line definitely is a comment. I don't see a reference to a charset elsewhere in the file. I would say the comment is there to signal 'this file is based on the ISO-8859-15 charset' (see e.g. /usr/share/i18n/locales/[EMAIL PROTECTED]). Hmmm. If I run dpkg-reconfigure locales, I do get: nl_NL ISO-8859-1 [EMAIL PROTECTED] ISO-8859-15 So there still _is_ a relation somewhere between the @euro suffix and the charset. Don't know if that's taken from the comment or somewhere else. Maybe, as the nl_NL locale (and those for other Euro-countries) now also uses the Euro sign, nl_NL itself should refer to ISO-8859-15 rather than ISO-8859-1? Problem is, I don't know enough about locales, charsets and encoding to tell. Maybe there is a very good reason why nl_NL still refers to 8859-1. For X of course we still have the seperate 'transcoded' font packages for 8859-15... Cheers, FJP -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.1 (GNU/Linux) iD8DBQFA1wlwgm/Kwh6ICoQRAplBAJ9Ulo5VYqptH2W5E36ufv1zLDD7NACgsvde +nlzEDHxbfGmRA0WY1mY0jw= =+Drh -END PGP SIGNATURE-
Re: @euro support with new languagechooser (was: dropping tc1)
On Mon, Jun 21, 2004 at 04:40:50PM +0200, Frans Pop wrote: > On Monday 21 June 2004 16:06, Christian Perrier wrote: > > [EMAIL PROTECTED] basically is a copy of fr_FR:-) > Hmm yes, I see what you mean. > The same goes for nl_NL and nl_BE (and for de_LU and es_ES which I checked at > random). There's really only the comment that you're supposed to use charset > ISO-8859-15 and not ISO-8859-1. > I guess the difference used to be in LC_MONETARY, but that contains just a > reference to the basic config now. So there's no difference in the actual charset that each is pointed to, the only difference is in a comment about the charset? -- Steve Langasek postmodern programmer signature.asc Description: Digital signature
Re: @euro support with new languagechooser (was: dropping tc1)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Monday 21 June 2004 16:06, Christian Perrier wrote: > [EMAIL PROTECTED] basically is a copy of fr_FR:-) Hmm yes, I see what you mean. The same goes for nl_NL and nl_BE (and for de_LU and es_ES which I checked at random). There's really only the comment that you're supposed to use charset ISO-8859-15 and not ISO-8859-1. I guess the difference used to be in LC_MONETARY, but that contains just a reference to the basic config now. Maybe the transition period is over :-) and the @euro variants are only there for compatibility reasons. So, no more reasons not to switch to new languagechooser? -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.1 (GNU/Linux) iD8DBQFA1vNygm/Kwh6ICoQRAiDcAKDZPKH9ZW9UPtslDmeSngjaboH9swCgx5cP +fzbZvcLDgGLtHdNCwPfcGo= =QUiP -END PGP SIGNATURE-
Re: @euro support with new languagechooser (was: dropping tc1)
Quoting Frans Pop ([EMAIL PROTECTED]): > Is there some table available that lists primary currency for a country? Not afaik Funnily, I indeed begin to wonder whether we still need these "@euro" variants. When comparing fr_FR and [EMAIL PROTECTED] I only see the comment about Charset to be different..:-) [EMAIL PROTECTED] basically is a copy of fr_FR:-) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
@euro support with new languagechooser (was: dropping tc1)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Tuesday 15 June 2004 06:46, Christian Perrier wrote: > Quoting Frans Pop ([EMAIL PROTECTED]): > > Maybe one issue: I now get LANG=nl_NL in /etc/environment; I think this > > used to be [EMAIL PROTECTED]; was that changed ?? > > The way the locale is built. It is now language_COUNTRY, built from > the languagechooser choices. > > Here, you're right, we lose the variant part. I currently do not have > a good idea for re-adding it I'm not sure where the locale is currently determined, but I understand there is a test to see if the locale is supported. If so, could we add code something like this: determine locale as currently done case countrycode in AT BE DE FI FR GR IR IT LU NL PT SP)) if [EMAIL PROTECTED] supported by locales ; then [EMAIL PROTECTED] fi ;; esac Downside is that this list would have to be updated if more countries join the Euro. Is there some table available that lists primary currency for a country? -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.1 (GNU/Linux) iD8DBQFA1t+Kgm/Kwh6ICoQRAkYjAKCzKFgeX4qTdVxyaUZsxxYn4TP7qACgjaCI a/PQVj48TYOZLBACJ2iturU= =0qDx -END PGP SIGNATURE-
Re: dropping tc1
* Joey Hess <[EMAIL PROTECTED]> [2004-06-14 13:13]: > - some broken m68k images (unknown mke2fs fix needed) Vince, since you debugged genext2fs a bit already, maybe you could take a look at this? -- Martin Michlmayr [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Proposal for a d-i IRC meeting (was: Re: dropping tc1)
On Wed, Jun 16, 2004 at 07:00:59AM +0200, Christian Perrier wrote: > Quoting Colin Watson ([EMAIL PROTECTED]): > > I can't make that, I'm afraid. Of your other slots, 23:00 UTC on > > Saturday is fine, and 16:00 UTC works practically every day apart from > > this Wednesday and Saturday. > Hmm, you were among my key people...:-). If Steve isn't available, > we'll either cancel or reschedule (at 23:00UTC). We need at least one > of the people who are able to move packages from unstable to > testingand who are more aware of the build process than me..:-) Well, I unfortunately can't commit to any of these times, my schedule is just too up in the air right now while we're preparing to move. But FWIW, I also don't have the ability to propagate udebs to testing, this is something that currently requires direct intervention of an ftpmaster; to date, I believe James has been handling most of these at Joey's request. -- Steve Langasek postmodern programmer signature.asc Description: Digital signature
Re: Proposal for a d-i IRC meeting (was: Re: dropping tc1)
Quoting Kenshi Muto ([EMAIL PROTECTED]): I prefer Saturday 23:00 UTC than Saturday 16:00 UTC. > > Because I have a party with friends and drinks at Saturday evening > (noon in UTC). :-) As the meeting has been announced on IRC /topic, I prefer currently leaving this hour of 16:00. If too much people are missing we'll reschedule to 23:00 (01:00 for me, sigh). -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Proposal for a d-i IRC meeting (was: Re: dropping tc1)
At 16 Jun 04 05:00:59 GMT, Christian Perrier wrote: > Quoting Colin Watson ([EMAIL PROTECTED]): > > I can't make that, I'm afraid. Of your other slots, 23:00 UTC on > > Saturday is fine, and 16:00 UTC works practically every day apart from > > this Wednesday and Saturday. > > Hmm, you were among my key people...:-). If Steve isn't available, > we'll either cancel or reschedule (at 23:00UTC). We need at least one > of the people who are able to move packages from unstable to > testingand who are more aware of the build process than me..:-) I prefer Saturday 23:00 UTC than Saturday 16:00 UTC. Because I have a party with friends and drinks at Saturday evening (noon in UTC). :-) Thanks, -- Kenshi Muto [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Proposal for a d-i IRC meeting (was: Re: dropping tc1)
On Tue, Jun 15, 2004 at 08:40:06PM +0200, Christian Perrier wrote: > I currently propose Saturday June 19th, 16:00 UTC as a first > possibility.?#debian-boot channel, of course. > > > > Folks, please confirm wheher you can attend this meeting. > (Joey already counted as not attending) > > 1) Christian Perrier / bubulle I can attend. -- Matt Kraai[EMAIL PROTECTED]http://ftbfs.org/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Proposal for a d-i IRC meeting (was: Re: dropping tc1)
Quoting Colin Watson ([EMAIL PROTECTED]): > I can't make that, I'm afraid. Of your other slots, 23:00 UTC on > Saturday is fine, and 16:00 UTC works practically every day apart from > this Wednesday and Saturday. Hmm, you were among my key people...:-). If Steve isn't available, we'll either cancel or reschedule (at 23:00UTC). We need at least one of the people who are able to move packages from unstable to testingand who are more aware of the build process than me..:-) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Proposal for a d-i IRC meeting (was: Re: dropping tc1)
Hi, I also have interest to participate on meeting (specially about the install manual translation topic). I agreed with being on Saturday - 19 June - if possible (for most people is the best time to participate, because is a non work hour). > Folks, please confirm wheher you can attend this meeting. > (Joey already counted as not attending) > > 1) Christian Perrier / bubulle >2) Gleydson Mazioli / gleydson --- Gleydson Mazioli da Silva [EMAIL PROTECTED] [EMAIL PROTECTED] * "Covardes não são homens que choram por amor,mas sim homens que não amam por medo de chorar" pgpv458Ca5JzZ.pgp Description: PGP signature
Re: Proposal for a d-i IRC meeting (was: Re: dropping tc1)
On Tue, Jun 15, 2004 at 08:40:06PM +0200, Christian Perrier wrote: > I currently propose Saturday June 19th, 16:00 UTC as a first > possibility. #debian-boot channel, of course. > > > > Folks, please confirm wheher you can attend this meeting. > (Joey already counted as not attending) I can't make that, I'm afraid. Of your other slots, 23:00 UTC on Saturday is fine, and 16:00 UTC works practically every day apart from this Wednesday and Saturday. -- Colin Watson [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Proposal for a d-i IRC meeting (was: Re: dropping tc1)
Il Tue, Jun 15, 2004 at 08:40:06PM +0200, Christian Perrier ha scritto: [...] > I currently propose Saturday June 19th, 16:00 UTC as a first > possibility. #debian-boot channel, of course. > > > Folks, please confirm wheher you can attend this meeting. > (Joey already counted as not attending) > > 1) Christian Perrier / bubulle 2) Giuseppe Sacco / eppesuig (I will have more time available from now on) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Proposal for a d-i IRC meeting (was: Re: dropping tc1)
On Tue, Jun 15, 2004 at 08:40:06PM +0200, Christian Perrier wrote: > Quoting Joey Hess ([EMAIL PROTECTED]): > > > I hope if it's a formal meeting that there are some known topics for us > > to discuss. This could be a good idea, at least it can't hurt to try it. > > Basically, I think your "dropping tc1" mail could be a start. Just get > all the points one by one and assign ourselves tasks. > > This is probably, imho, what's currently missing : have assigned tasks > and regular points for confirming what is advancing and what is > not. > > Not easy to achieve as, by definition, we all do all this basiucally > on our free timebut, well, we can try..:-) I think it is a good thing to have more or less regular meetings. I hope it will be easier for myself to come back to d-i developement. Currently I'm a bit lost in the huge mass of mails and don't know where help is most needed. > > I currently propose Saturday June 19th, 16:00 UTC as a first > possibility. #debian-boot channel, of course. Sorry, I will be away this week-end. So I cannot attend this meeting. > > > > Folks, please confirm wheher you can attend this meeting. > (Joey already counted as not attending) > > 1) Christian Perrier / bubulle > > > > -- > To UNSUBSCRIBE, email to [EMAIL PROTECTED] > with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED] signature.asc Description: Digital signature
Re: Proposal for a d-i IRC meeting (was: Re: dropping tc1)
Quoting Joey Hess ([EMAIL PROTECTED]): > I hope if it's a formal meeting that there are some known topics for us > to discuss. This could be a good idea, at least it can't hurt to try it. Basically, I think your "dropping tc1" mail could be a start. Just get all the points one by one and assign ourselves tasks. This is probably, imho, what's currently missing : have assigned tasks and regular points for confirming what is advancing and what is not. Not easy to achieve as, by definition, we all do all this basiucally on our free timebut, well, we can try..:-) > > > As Joey leaves on Thursday, I'd like to propose something before that > > moment (which means tomorrow 6/16, Wednesday). If you all agree this > > could be a Good Thing for sure. > > I was probably unclear, I leave Wednesday morning. I have an 11 hour > drive and I need to get to my campsite before dark. Hmmm, thus it will be hard to have something organised before you leave. > > > 1) 16:00 UTC, which means from 09:00 to 12:00 in USA, 17:00 or 18:00 in > > Europe and 01:00 the day after in Japan > > I can probably make part of this timeslot, and no others. Please don't let > my absense stop you from doing anything though. Sure.but as "release manager appointed by all of us", you being present is a must have Let's see others reactions. It seems that the 16:00 UTC is the most probable correct timeslot (though, well, not that easy for mebecause this is usually my "travel back home" timeand I need 1h30 for going back home daily). I currently propose Saturday June 19th, 16:00 UTC as a first possibility. #debian-boot channel, of course. Folks, please confirm wheher you can attend this meeting. (Joey already counted as not attending) 1) Christian Perrier / bubulle -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Proposal for a d-i IRC meeting (was: Re: dropping tc1)
Christian Perrier wrote: > It seems to me that a kind of "formal" meeting on IRC would help all > of us in organising our work. > > We maybe lack that kind of formal stuff (just an idea "en l'air"). I hope if it's a formal meeting that there are some known topics for us to discuss. This could be a good idea, at least it can't hurt to try it. > As Joey leaves on Thursday, I'd like to propose something before that > moment (which means tomorrow 6/16, Wednesday). If you all agree this > could be a Good Thing for sure. I was probably unclear, I leave Wednesday morning. I have an 11 hour drive and I need to get to my campsite before dark. > 1) 16:00 UTC, which means from 09:00 to 12:00 in USA, 17:00 or 18:00 in > Europe and 01:00 the day after in Japan I can probably make part of this timeslot, and no others. Please don't let my absense stop you from doing anything though. -- see shy jo signature.asc Description: Digital signature
Re: Proposal for a d-i IRC meeting (was: Re: dropping tc1)
Hi, At 15 Jun 04 07:31:49 GMT, Christian Perrier wrote: > Quoting Joey Hess ([EMAIL PROTECTED]): > It seems to me that a kind of "formal" meeting on IRC would help all > of us in organising our work. > > We maybe lack that kind of formal stuff (just an idea "en l'air"). > > As Joey leaves on Thursday, I'd like to propose something before that > moment (which means tomorrow 6/16, Wednesday). If you all agree this > could be a Good Thing for sure. > > The major problem is the time slot of course. > > We have people on USA (UTC -0700 to -0400) > Europe (UTC +0200), Britain (UTC +0100) and Japan (UTC +0900), so this > is very tricky...:-) (do we have people in Australia/NZ?) > > This basically gives us three time slots: > > 1) 16:00 UTC, which means from 09:00 to 12:00 in USA, 17:00 or 18:00 in > Europe and 01:00 the day after in Japan > > 2) 23:00 UTC, which means from 16:00 to 19:00 in USA, 00:00 or 01:00 in > Europe and 08:00 the day after in Japan > > 3) 06:00 UTC, which means from 23:00 to 02:00 in USA, 07:00 to 08:00 in > Europe and 15:00 in Japan > > My own preference is for 1) though it's not the best hour for mer > personnally (I have to leave work earlier than usually) I like 1) or 2). > If we drop support for Kenshi (who is the only one in Japan), we get > more possibilities by using something like 19:00 UTC (by far the most > convienient for me:-))). AM 4:00... Oh NO, I'm not a morning person! :-) Thanks, -- Kenshi Muto [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Proposal for a d-i IRC meeting (was: Re: dropping tc1)
Quoting Joey Hess ([EMAIL PROTECTED]): > It looks like we have to throw out tc1 as not good enough for release. > The release critical problems include: It seems to me that a kind of "formal" meeting on IRC would help all of us in organising our work. We maybe lack that kind of formal stuff (just an idea "en l'air"). As Joey leaves on Thursday, I'd like to propose something before that moment (which means tomorrow 6/16, Wednesday). If you all agree this could be a Good Thing for sure. The major problem is the time slot of course. We have people on USA (UTC -0700 to -0400) Europe (UTC +0200), Britain (UTC +0100) and Japan (UTC +0900), so this is very tricky...:-) (do we have people in Australia/NZ?) This basically gives us three time slots: 1) 16:00 UTC, which means from 09:00 to 12:00 in USA, 17:00 or 18:00 in Europe and 01:00 the day after in Japan 2) 23:00 UTC, which means from 16:00 to 19:00 in USA, 00:00 or 01:00 in Europe and 08:00 the day after in Japan 3) 06:00 UTC, which means from 23:00 to 02:00 in USA, 07:00 to 08:00 in Europe and 15:00 in Japan My own preference is for 1) though it's not the best hour for mer personnally (I have to leave work earlier than usually) What do you folks thinks about this? If we drop support for Kenshi (who is the only one in Japan), we get more possibilities by using something like 19:00 UTC (by far the most convienient for me:-))). We are maybe short of time. If so, I propose we schedule a meeting when Joey will be back, next week. Such meetings could be scheduled on a regular basis. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: dropping tc1
Quoting Frans Pop ([EMAIL PROTECTED]): > Maybe one issue: I now get LANG=nl_NL in /etc/environment; I think this used > to be [EMAIL PROTECTED]; was that changed ?? The way the locale is built. It is now language_COUNTRY, built from the languagechooser choices. Formerly, in "all in one" combinations such as nl_NL we had, the locale was fixed by languagechooser and never touched after. Here, you're right, we lose the variant part. I currently do not have a good idea for re-adding it -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: dropping tc1
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Monday 14 June 2004 22:32, Christian Perrier wrote:
> Quoting Steve Langasek ([EMAIL PROTECTED]):
> > In the tests I've done with the new languagechooser, almost all of the
> > entries are displayed in English, and there doesn't seem to be a short
> > list provided by countrychooser. This seems like a significant
> > regression for the common case; I think it's better to delay the new
> > languagechooser until rc2.
>
> Hmmm, I'm surprised of this
>
> Currently, things are OK with sid_d-i builds...
Looks OK to me (sid_d-i, 20040613). If I select Dutch I get the correct
shortlist with Belgium, Netherlands and Other (translated into Dutch of
course ;-).
I see two minor encoding problems in the translated longlist, for which I will
submit a bug report.
I also now get the correct keyboard layout ('us') :-)
The font settings in /etc/console-tools/config _after_ installation look OK
(no borders during 2nd stage installation, but debconf and dselect are OK
after an extra reboot).
Maybe one issue: I now get LANG=nl_NL in /etc/environment; I think this used
to be [EMAIL PROTECTED]; was that changed ??
I think the new language list is a lot cleaner and easier to select from.
Cheers,
FJP
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.2.1 (GNU/Linux)
iD8DBQFAzh1agm/Kwh6ICoQRAsm4AJ0XlRfKlpHy/W4ZkkMs75xkMZ/2AQCgpEMK
UojJzCPcYA9OsDjFjqn+Jfg=
=1TqJ
-END PGP SIGNATURE-
Re: dropping tc1
Quoting Steve Langasek ([EMAIL PROTECTED]): > In the tests I've done with the new languagechooser, almost all of the > entries are displayed in English, and there doesn't seem to be a short > list provided by countrychooser. This seems like a significant > regression for the common case; I think it's better to delay the new > languagechooser until rc2. Hmmm, I'm surprised of this Currently, things are OK with sid_d-i builds... -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: dropping tc1
On Mon, Jun 14, 2004 at 08:18:26PM +0200, Christian Perrier wrote: > > I'll be away for a week after Tuesday. I hope some of these issues are > > resolved when I get back so that we can begin getting a tc2 ready. In > > the meantime, tbm and kamion have the ability to get fixed udebs into > > testing. Since tc1 is a lost cause, there's no reason not to start with > > getting some of the abovementioned udebs, if the other changes in them > > are small enough (if not, consider an upload to t-p-u with only the > > required fixes) and if they've been well enough tested in unstable to be > > known safe. > On my side, I'm exploring the locales-related problems and issues. > The most important choice here is whether we use languagechooser > >=1.23 and countrychooser >=0.020 (both *have* to be used together). > IMHO, it's worth it as it definitely solves the "invalid locales" > problems when choosing unsupported combinations such as English in > Brazil. In the tests I've done with the new languagechooser, almost all of the entries are displayed in English, and there doesn't seem to be a short list provided by countrychooser. This seems like a significant regression for the common case; I think it's better to delay the new languagechooser until rc2. Cheers, -- Steve Langasek postmodern programmer signature.asc Description: Digital signature
Re: dropping tc1
Quoting Christian Perrier ([EMAIL PROTECTED]): > IMHO, it's worth it as it definitely solves the "invalid locales" > problems when choosing unsupported combinations such as English in > Brazil. But, well, I would perfectly understand if this is delayed because of potential unknown implications (such as the lowmem issue recently re-discovered). -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: dropping tc1
> I'll be away for a week after Tuesday. I hope some of these issues are > resolved when I get back so that we can begin getting a tc2 ready. In > the meantime, tbm and kamion have the ability to get fixed udebs into > testing. Since tc1 is a lost cause, there's no reason not to start with > getting some of the abovementioned udebs, if the other changes in them > are small enough (if not, consider an upload to t-p-u with only the > required fixes) and if they've been well enough tested in unstable to be > known safe. On my side, I'm exploring the locales-related problems and issues. The most important choice here is whether we use languagechooser >=1.23 and countrychooser >=0.020 (both *have* to be used together). IMHO, it's worth it as it definitely solves the "invalid locales" problems when choosing unsupported combinations such as English in Brazil. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
dropping tc1
It looks like we have to throw out tc1 as not good enough for release. The release critical problems include: - some broken m68k images (unknown mke2fs fix needed) - broken sparc64 module loading (fix: busybox-cvs 20040415-3) - messed up line drawing characters in base-config (fix: base-config 2.29) - broken support for 100 gb partitions on i386 (fix: base-installer 0.083) - the above problem seems to affect nearly any size partitions on alpha and probably other 64 bit systems (workaround: base-installer 0.083; also needs *-installer fixes) Some items that I do not consider release critical, but are still pretty bad and potentially worth fixing: - 2.6 lvm and raid segfaults and hangs (fix: lvm2 2.00.16-2) - airport module not available post-reboot on powerpc (fix: ddetect 0.101) - firewire cd support (fix: ddetect 0.101) - mips Installs on r4k-ip22 needs 36 mb ram (fix: unknown -- new glibc?) - broken ataraid and ida support (fix: libdebian-installer 0.26.really.0.22) The fact that we still lack a fix for the m68k images problem, and that, 2 weeks after tc1 was released, we still lack any test reports for sparc64, ia64, or hppa, makes me question whether we can expect to release at all in the immediate future. I'm not going to bother with a tc2 until the m68k problem has a solution, and until we know whether tc1 or current sarge_d-i works or fails on sparc64, ia64, and hppa; more than likely one of the three has some problem that would require more changes, and I want to know about it in time for tc2. I'll be away for a week after Tuesday. I hope some of these issues are resolved when I get back so that we can begin getting a tc2 ready. In the meantime, tbm and kamion have the ability to get fixed udebs into testing. Since tc1 is a lost cause, there's no reason not to start with getting some of the abovementioned udebs, if the other changes in them are small enough (if not, consider an upload to t-p-u with only the required fixes) and if they've been well enough tested in unstable to be known safe. -- see shy jo signature.asc Description: Digital signature
