Re: enable/disable flags in /etc/default
Am 22.03.2011 07:10, schrieb Tollef Fog Heen: > ]] Micah Anderson > > Hi, > > | Also insserv is Priority: optional, so we can't count on that being on > | every system. > > http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=551745 is already > filed. I have no idea why it hasn't been fixed yet, it looks like a > trivial change. Imho the fix for 551745 is not to bump the severity of insserv but to not call insserv directly in crosshurds's maintainer scripts. Implementation details like the usage of insserv should be hidden by the update-rc.d interface. -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth? signature.asc Description: OpenPGP digital signature
Re: Need for automatic USB stick backup package
On 22 March 2011 00:49, Paul Wise wrote: > I personally wouldn't use that script for a number of reasons: I adapted the script, changing various things. In particular, I use unison-gtk, which means that nothing is done until you confirm the changes. > The mount could trigger unknown kernel vulnerabilities in filesystem code The USB Stick would be automounted anyway. How is this different? Thanks for the feedback Jeff -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/AANLkTikQo=0ohafbvrqmmn-4nleeenm7ksphvmfp1...@mail.gmail.com
Re: Need for automatic USB stick backup package
On Tue, Mar 22, 2011 at 4:57 PM, Jeffrey Ratcliffe wrote: > On 22 March 2011 00:49, Paul Wise wrote: > >> The mount could trigger unknown kernel vulnerabilities in filesystem code > > The USB Stick would be automounted anyway. How is this different? Automounting is disabled on desktops that do the right thing and when people want their desktop to do the right thing and so turned it off. This would mean turning it back on again. -- bye, pabs http://wiki.debian.org/PaulWise -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/AANLkTimVpgTCOi=4N4--sb_Di+9=QAAZios0U1j_r4=h...@mail.gmail.com
Re: Cross compiler ITP (armel)
On Mon, 14, Mar, 2011 at 02:04:30PM +, Hector Oron spoke thus.. > Hi, > > 2009/11/2 Mark Hymers : > > On Mon, 02, Nov, 2009 at 12:43:42PM +, Philipp Kern spoke thus.. > >> Of course it is a sane approach but very special care needs to be taken > >> when > >> releasing to ensure GPL compliance. So what we should get is support in > >> the > >> toolchain to declare against what source package the upload was built to > >> keep that around. Ok, I'm only going to comment on this part. This is nearly implemented and should be there by the end of the day (I need to run up some test packages to work with). The current design is the Binary packages can contain an additional control field: Built-Using. The specification of this field is that it *must* contain only strict version dependencies and these must be to source packages. I.e. Built-Using: gcc-4.5 (= 4.5.2-5) If dak can't parse this field, or the source versions which are declared are not present when the binary package is uploaded, it will reject the upload. If it can parse and find these dependencies, it stores them in an extra table in projectb which prevents us from throwing away the relevant source files until these binaries no longer exist anywhere in the archive, the same way as we handle it for the normal source case. I'm not entirely sure where this should be documented, it's not really a policy thing as it's specific to the archive. Suggestions welcome. We'll obviously include it in the minutes to d-d-a at the end of the meeting (the main people this should be used by, as far as I know are cross-compiler builders and the d-i and kernel-wedge people). Mark -- Mark Hymers "I never make predictions. I never have and I never will." Tony Blair -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110322115447.ga15...@hymers.org.uk
Re: Cross compiler ITP (armel)
On Tue, 22 Mar 2011 at 11:54:47 +, Mark Hymers wrote: > the main people [Built-Using] should be used by, as far as I know are > cross-compiler builders and the d-i and kernel-wedge people Also the ia32-libs family of packages, until they get superseded by multiarch? S -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110322121831.ga12...@reptile.pseudorandom.co.uk
Re: Cross compiler ITP (armel)
On 22.03.2011 12:54, Mark Hymers wrote: > On Mon, 14, Mar, 2011 at 02:04:30PM +, Hector Oron spoke thus.. >> Hi, >> >> 2009/11/2 Mark Hymers : >>> On Mon, 02, Nov, 2009 at 12:43:42PM +, Philipp Kern spoke thus.. Of course it is a sane approach but very special care needs to be taken when releasing to ensure GPL compliance. So what we should get is support in the toolchain to declare against what source package the upload was built to keep that around. > > Ok, I'm only going to comment on this part. This is nearly implemented > and should be there by the end of the day (I need to run up some test > packages to work with). > > The current design is the Binary packages can contain an additional > control field: Built-Using. > > The specification of this field is that it *must* contain only strict > version dependencies and these must be to source packages. I.e. > > Built-Using: gcc-4.5 (= 4.5.2-5) > > If dak can't parse this field, or the source versions which are declared > are not present when the binary package is uploaded, it will reject the > upload. If it can parse and find these dependencies, it stores them in > an extra table in projectb which prevents us from throwing away the > relevant source files until these binaries no longer exist anywhere in > the archive, the same way as we handle it for the normal source case. > > I'm not entirely sure where this should be documented, it's not really a > policy thing as it's specific to the archive. Suggestions welcome. > We'll obviously include it in the minutes to d-d-a at the end of the > meeting (the main people this should be used by, as far as I know are > cross-compiler builders and the d-i and kernel-wedge people). that would be too strict for e.g. gcj-4.5 Built-Using: gcc-4.5 (>= 4.5.2-1~), gcc-4.5 (<< 4.5.3) would be correct, however this already can be expressed in the build dependencies, so I assume packages like gcj-4.x, gdc-4.x, gnat-4.x don't need to be changed. Matthias -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4d889b34.1070...@debian.org
Re: Cross compiler ITP (armel)
On Tue, 22, Mar, 2011 at 12:18:31PM +, Simon McVittie spoke thus.. > On Tue, 22 Mar 2011 at 11:54:47 +, Mark Hymers wrote: > > the main people [Built-Using] should be used by, as far as I know are > > cross-compiler builders and the d-i and kernel-wedge people > > Also the ia32-libs family of packages, until they get superseded by multiarch? Good point, but I'm hopeful that the m-a packages will start landing pretty soon now :-) Mark -- Mark Hymers "'I regret nothing?' That's not a song, that's an idiots charter." Andy Hamilton, Old Harry's Game -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110322123754.ga17...@hymers.org.uk
Re: Cross compiler ITP (armel)
On 2011-03-22, Matthias Klose wrote: >> The current design is the Binary packages can contain an additional ^^ >> control field: Built-Using. [...] > that would be too strict for e.g. gcj-4.5 > Built-Using: gcc-4.5 (>= 4.5.2-1~), gcc-4.5 (<< 4.5.3) > would be correct, however this already can be expressed in the build > dependencies, so I assume packages like gcj-4.x, gdc-4.x, gnat-4.x don't need > to > be changed. They'd need to *generate* them in the *binary* packages. So you "just" declare the one that was installed at the time of building and you're set. Kind regards Philipp Kern -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/slrnioh8hj.f4q.tr...@kelgar.0x539.de
Re: Cross compiler ITP (armel)
On Tue, 22, Mar, 2011 at 01:51:00PM +0100, Matthias Klose spoke thus.. > that would be too strict for e.g. gcj-4.5 > > Built-Using: gcc-4.5 (>= 4.5.2-1~), gcc-4.5 (<< 4.5.3) > > would be correct, however this already can be expressed in the build > dependencies, so I assume packages like gcj-4.x, gdc-4.x, gnat-4.x don't need > to > be changed. This is nothing to do with Build-Depends. This is simply informing the archive what *happened* during the build. The obvious case is when someone Build-Depends on gcc-4.5-source (a binary package), they should then tell us in the control file of their Binary packages that they used gcc-4.5 (the source package) and the exact version they used. This means that we'll ensure that we hold that version of the source around correctly until we no longer need it. It has no effect on the end-user's system, it simply allows us to automatically ensure GPL compliance (and means we're doing the right thing) Mark -- Mark Hymers "Well, the thing about a black hole - it's main distinguishing feature - is it's black. And the thing about space, your basic space colour is black. So how are you supposed to see them?" Holly, Red Dwarf Series III - Marooned -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110322131535.ga19...@hymers.org.uk
Re: Cross compiler ITP (armel)
On 22.03.2011 14:20, Philipp Kern wrote: > On 2011-03-22, Matthias Klose wrote: >>> The current design is the Binary packages can contain an additional > ^^ >>> control field: Built-Using. > [...] >> that would be too strict for e.g. gcj-4.5 >> Built-Using: gcc-4.5 (>= 4.5.2-1~), gcc-4.5 (<< 4.5.3) >> would be correct, however this already can be expressed in the build >> dependencies, so I assume packages like gcj-4.x, gdc-4.x, gnat-4.x don't >> need to >> be changed. > > They'd need to *generate* them in the *binary* packages. So you "just" > declare > the one that was installed at the time of building and you're set. no, they are not needed at all for these packages. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4d88a515.2040...@debian.org
Re: Cross compiler ITP (armel)
Hi Mark, 2011/3/22 Mark Hymers : > The current design is the Binary packages can contain an additional > control field: Built-Using. First of all, thanks very much for taking care of it, that probably will get us going. I just would like to point out that current design solves half of the problem (being GPL compliant), but it does not solve code duplication in the archive, which it can also be useful for large datasets. IMHO, we do not want source and binary packages containing the same bits, bytes and nibbles, problem which might be solved by the multiarch specification, treating 'source' as yet another architecture (in next couple years?) :-) Best regards, -- Héctor Orón "Our Sun unleashes tremendous flares expelling hot gas into the Solar System, which one day will disconnect us." -- Day DVB-T stop working nicely Video flare: http://antwrp.gsfc.nasa.gov/apod/ap100510.html -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/AANLkTinD9_7yBScA-MPEOAgREnyjXQbh7znfDRYLeF=r...@mail.gmail.com
Re: Cross compiler ITP (armel)
On Tue, Mar 22, 2011 at 14:33:09 +0100, Matthias Klose wrote: > On 22.03.2011 14:20, Philipp Kern wrote: > > On 2011-03-22, Matthias Klose wrote: > >>> The current design is the Binary packages can contain an additional > > ^^ > >>> control field: Built-Using. > > [...] > >> that would be too strict for e.g. gcj-4.5 > >> Built-Using: gcc-4.5 (>= 4.5.2-1~), gcc-4.5 (<< 4.5.3) > >> would be correct, however this already can be expressed in the build > >> dependencies, so I assume packages like gcj-4.x, gdc-4.x, gnat-4.x don't > >> need to > >> be changed. > > > > They'd need to *generate* them in the *binary* packages. So you "just" > > declare > > the one that was installed at the time of building and you're set. > > no, they are not needed at all for these packages. > If that's not needed for those packages then why bring them up? Cheers, Julien -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110322140709.ga3...@radis.liafa.jussieu.fr
Re: Cross compiler ITP (armel)
>> The current design is the Binary packages can contain an additional >> control field: Built-Using. > First of all, thanks very much for taking care of it, that probably > will get us going. > I just would like to point out that current design solves half of > the problem (being GPL compliant), No, it solves all of the problem, cos > but it does not solve code duplication in the archive, this is a different thing entirely. B-U is solely mean of ensuring to do what the licenses want us to do. Getting sanity into packages providing source around and duplication is different to that. -- bye, Joerg [Talking about Social Contract]: We will not discriminate noone[...] [So we discriminate anyone?] -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/877hbrxn3b@delenn.ganneff.de
Re: Cross compiler ITP (armel)
On Tue, 22, Mar, 2011 at 01:57:42PM +, Hector Oron spoke thus.. > Hi Mark, > > 2011/3/22 Mark Hymers : > > > The current design is the Binary packages can contain an additional > > control field: Built-Using. > > First of all, thanks very much for taking care of it, that probably > will get us going. > > I just would like to point out that current design solves half of > the problem (being GPL compliant), but it does not solve code > duplication in the archive, which it can also be useful for large > datasets. IMHO, we do not want source and binary packages containing > the same bits, bytes and nibbles, problem which might be solved by the > multiarch specification, treating 'source' as yet another architecture > (in next couple years?) :-) I'd have thought the right answer to that was to allow some form of Build-Depends-Source mechanism where the source is unpacked at build time in a known place or something. Of course, the problem with this is that we traditionally haven't allowed network access to be required during a build so the exact semantics would have to be worked out. Maybe something like, if a package declares Build-Depends-Source: gcc-4.5 the source code must be available under debian/external-source/gcc-4.5 and then leave it up to the builder to sort that out. That's a rough (and probably bad) idea off the top of my head - I'm sure the buildd team at least will have other thoughts on the matter. Mark -- Mark Hymers "But Yossarian *still* didn't understand either how Milo could buy eggs in Malta for seven cents apiece and sell them at a profit in Pianosa for five cents." Catch 22, Joseph Heller -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110322140347.ga21...@hymers.org.uk
Needed input from Australian users and developers:; choosing timezones for Australia in D-I
Hello, I need some help from Australian people. Debian Installer includes (in tzsetup) a way to choose a timezone among multiple timezones, when users have picked a country that has more than one timezone. I'm currently working on this as things change constantly in such matters. As preliminary, please notice that the point is not giving a full choice within the gazillion of possible timezones. See "dpkg-reconfigure tzdata". The timezone choice in D-I is supposed to be user-friendly and easy to understand for the average citizen of the said country. When it comes at Australia, the choice was, up to now: Lord Howe Island Hobart Melbourne Sydney Broken Hill Brisbane Lindeman Adelaide Darwin Perth Canberra Eucla Currie Yancowinna That's indeed insane..:-). Hobart (Tasmania), Melbourne (Victoria), Sydney (NSW) and Canberra (ACT) have the *exact* same time rules (including DST). Lindeman island is in Queensland and uses the same time than it. Broken Hill is only specific because, even if it's in NSW, it follows South Australia time.. Indeed, after some study, Australia (excluding outside territories that have their own ISO code anyway) has only 7 different time "zones", as of 2011: 5 for the "continent"+Tasmania: - Eastern Time with use of DST: Victoria, NSW, ACT, Tasmania - Eastern Time withouty use of DST: Queensland - Central Time with use of DST: South Australia - Central Time without use of DST: Northern Territory - Western Time without use of DST: Western Australia 2 more specific: - Lord Howe Island - Eyre Highway (also known as Eucla) using a funky UTC+8:45. That's about 200 people, according to Wikipedia. This "timezone" is unofficially called Central Western I currently propose to offer the following choices in D-I: Victoria, ACT, NSW, Tasmania (Eastern Time, DST) Queensland (Eastern Time, no DST) South Australia (Central Time, DST) Northern Territory (Central Time, no DST) Western Australia (Western Time) Central Western Standard Time (Eucla) Lord Howe Island Do you guys think this would be understandable to the average Australian? Would something hurt some feelings (such as mentioning Victoria before NSW)? An alternative was: Eastern Time with DST Eastern Time without DST Central Time with DST Central Time without DST Western Time Central Western Standard Time Lord Howe Island PS: for those nitpicking folds among you, Cocos (Keeling), Christmas and Norfolk Islands as well as the three Australian Antarctic Territories are supposed to be covered by different choices when it comes at "country". -- signature.asc Description: Digital signature
Re: Needed input from Australian users and developers:; choosing timezones for Australia in D-I
Christian PERRIER wrote: > I currently propose to offer the following choices in D-I: > > Victoria, ACT, NSW, Tasmania (Eastern Time, DST) > Queensland (Eastern Time, no DST) > South Australia (Central Time, DST) > Northern Territory (Central Time, no DST) > Western Australia (Western Time) > Central Western Standard Time (Eucla) > Lord Howe Island > > Do you guys think this would be understandable to the average > Australian? Yes, that sounds fine. > Would something hurt some feelings (such as mentioning Victoria before > NSW)? No, but I live in NSW :-). > An alternative was: > Eastern Time with DST > Eastern Time without DST > Central Time with DST > Central Time without DST > Western Time > Central Western Standard Time > Lord Howe Island I prefer the former options to this one, Cheers, Erik -- -- Erik de Castro Lopo http://www.mega-nerd.com/ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110323071700.436781e8.mle+deb...@mega-nerd.com
Bug#619327: ITP: macwidgets -- Collection of Mac style widgets written in Java
Package: wnpp Severity: wishlist Owner: Gilles Filippini -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 * Package name: macwidgets Version : 0.9.5 Upstream Author : Kenneth Orr * URL : http://code.google.com/p/macwidgets/ * License : LGPL Programming Lang: Java Description : Collection of Mac style widgets written in Java Mac Widgets for Java are a collection of widgets seen in OS X applications, offered in a Java API. These widgets help Java developers create more Mac-like applications. Their usage is not restricted to Mac though, as they will render across platforms. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) iQEcBAEBCAAGBQJNiSVvAAoJEO/obGx//s+D4KYH/2qs/9N1G2vskeCLqkRTsPtd ocBGxKxQqv0qeOpnGrDu9IUGbQ3hpjuaraoEwkY2n5mRvIqs1kdtMkvmDVg7cMT9 OZsX4Vhv9wjfPjsY9VJD88PvLIO/KVG2NlIYOwFzxCgC2x8ke5Jgnc0uB8BWyro6 KUohnXRosYQFzQ9ePVMvaQkuWmktYVXeV3TLFWLfoTSJVtvwe5VYVLevif8+C0jE aozys8M4LwlVew1fthbWbeocMSWqFoBSOTQxYHXK0BqL/EEzj8wRmMpZ67IGc5Se MyuOhJQ/QhL+SJK8cZ2fMPDDyQsd226dG0r57Is4slTnkTbETNgjaVXMBZM7tsg= =phmh -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/2011034059.19573.20993.report...@pini.bou-fi.net
Re: Cross compiler ITP (armel)
Le Tue, Mar 22, 2011 at 11:54:47AM +, Mark Hymers a écrit : > > I'm not entirely sure where this should be documented, it's not really a > policy thing as it's specific to the archive. Suggestions welcome. Dear all, Since the binary package control files is documented in the Policy, that will also document the archive-related DM-Upload-Allowed field in its next version (see #588014), I think that it would be nice to have the Built-Using field documented there too. I find it inconvenient to have the syntax of a file scattered accross documents. I can write a patch for the Policy according to the minutes you will publish later. Have a nice day, -- Charles Plessy Tsurumi, Kanagawa, Japan -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110322231552.gb21...@merveille.plessy.net
Bug#619335: ITP: libhttp-cookies-perl -- HTTP cookie jars
Package: wnpp Owner: Nicholas Bamber Severity: wishlist X-Debbugs-CC: debian-devel@lists.debian.org,debian-p...@lists.debian.org * Package name: libhttp-cookies-perl Version : 6.00 Upstream Author : Gisle Aas * URL : http://search.cpan.org/dist/HTTP-Cookies/ * License : Artistic or GPL-1+ Programming Lang: Perl Description : HTTP cookie jars This class is for objects that represent a "cookie jar" -- that is, a database of all the HTTP cookies that a given LWP::UserAgent object knows about. Cookies are a general mechanism which server side connections can use to both store and retrieve information on the client side of the connection. For more information about cookies refer to http://curl.haxx.se/rfc/cookie_spec.html> and http://www.cookiecentral.com/>. HTTP::Cookies also implements the new style cookies described in RFC 2965. The two variants of cookies are supposed to be able to coexist happily. Instances of the class HTTP::Cookies are able to store a collection of Set-Cookie2: and Set-Cookie: headers and are able to use this information to initialize Cookie-headers in HTTP::Request objects. The state of a HTTP::Cookies object can be saved in and restored from files. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4d892b9e.7060...@periapt.co.uk
Re: Needed input from Australian users and developers:; choosing timezones for Australia in D-I
On Tue, 22 Mar 2011 19:54:05 +0100, Christian PERRIER writes: >I currently propose to offer the following choices in D-I: > > Victoria, ACT, NSW, Tasmania (Eastern Time, DST) > Queensland (Eastern Time, no DST) > South Australia (Central Time, DST) > Northern Territory (Central Time, no DST) > Western Australia (Western Time) > Central Western Standard Time (Eucla) > Lord Howe Island > >Do you guys think this would be understandable to the average >Australian? that'll work fine. >An alternative was: > Eastern Time with DST > Eastern Time without DST > Central Time with DST > Central Time without DST > Western Time > Central Western Standard Time > Lord Howe Island not so great, because these are very uncommon. for example, you never hear "eastern time" being used on the radio; here (qld/nsw border) they say "it's hh:mm, that's hh+1:mm in nsw" when we're in that fun period of the year where there are two time zones within the reception area. regards az -- + Alexander Zangerl + DSA 42BD645D + (RSA 5B586291) Anyway the :// part is an 'emoticon' representing a man with a strip of sticky tape across his mouth. -- R. Douglas signature.asc Description: Digital Signature
Bug#619336: ITP: libhttp-negotiate-perl -- implementation of content negotiation
Package: wnpp Owner: Nicholas Bamber Severity: wishlist X-Debbugs-CC: debian-devel@lists.debian.org,debian-p...@lists.debian.org * Package name: libhttp-negotiate-perl Version : 6.00 Upstream Author : Gisle Aas * URL : http://search.cpan.org/dist/HTTP-Negotiate/ * License : Artistic or GPL-1+ Programming Lang: Perl Description : implementation of content negotiation HTTP::Negotiate provides a complete implementation of the HTTP content negotiation algorithm. Content negotiation allows for the selection of a preferred content representation based upon attributes of the negotiable variants and the value of the various Accept* header fields in the request. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4d89332d.4080...@periapt.co.uk
Re: Needed input from Australian users and developers:; choosing timezones for Australia in D-I
On Wed, Mar 23, 2011 at 09:34, Alexander Zangerl wrote: > not so great, because these are very uncommon. for example, you never > hear "eastern time" being used on the radio; here (qld/nsw border) they > say "it's hh:mm, that's hh+1:mm in nsw" when we're in that fun period > of the year where there are two time zones within the reception area. > Actually, I regularly hear programs being advertised as starting at (for example) "1pm eastern time" or "1pm AEST" when they actually mean "1pm AEDST".
Re: Needed input from Australian users and developers:; choosing timezones for Australia in D-I
Christian PERRIER writes: > The timezone choice in D-I is supposed to be user-friendly and easy to > understand for the average citizen of the said country. FWIW: the existing Australian timezone choice in D-I seems fine from the point of view of the Australians I've seen do installs (including myself). > When it comes at Australia, the choice was, up to now: > > Lord Howe Island > Hobart > Melbourne > Sydney > Broken Hill > Brisbane > Lindeman > Adelaide > Darwin > Perth > Canberra > Eucla > Currie > Yancowinna > > That's indeed insane..:-). Hobart (Tasmania), Melbourne (Victoria), > Sydney (NSW) and Canberra (ACT) have the *exact* same time rules > (including DST). But they didn't always; and with the tendency of governments to flex their arbitrary timezone powers, they may be different again in future. People's knowledge of timezone rules tends (IME) to stick at the point where they learned about a particular change which they had to learn; it rarely gets updated. Hobart people will probably not know that Melbourne's timezone is the same now, for example. > Indeed, after some study, Australia (excluding outside territories > that have their own ISO code anyway) has only 7 different time > "zones", as of 2011: Which will likely change again in the future. We are cursed with arbitrary government intervention in timezone rules, implemented with little advance notice. > I currently propose to offer the following choices in D-I: > > Victoria, ACT, NSW, Tasmania (Eastern Time, DST) > Queensland (Eastern Time, no DST) > South Australia (Central Time, DST) > Northern Territory (Central Time, no DST) > Western Australia (Western Time) > Central Western Standard Time (Eucla) > Lord Howe Island > > Do you guys think this would be understandable to the average > Australian? Yes. However, please ensure that no-one working on this gets the impression this reduction in options is to be relied on; it's at the whim of government that demonstrates frequent whimsy in adding as well as reducing options. > Would something hurt some feelings (such as mentioning Victoria before > NSW)? Inter-state rivalry is not something Australians get particularly upset about; at least, not for something as inconsequential as which one gets mentioned first in a list. Maybe mention ACT first to defer to the nominal capital of the country. Or not, as you choose; I doubt anyone will be upset. > An alternative was: > Eastern Time with DST > Eastern Time without DST > Central Time with DST > Central Time without DST > Western Time > Central Western Standard Time > Lord Howe Island −1 for that. Average citizens can't be expected to know any name for their time zone that isn't their name they for the region in which they live (e.g. “Melbourne” or “Victoria”). -- \ “I have never imputed to Nature a purpose or a goal, or | `\anything that could be understood as anthropomorphic.” —Albert | _o__)Einstein, unsent letter, 1955 | Ben Finney pgpqbDE3Fc8Y2.pgp Description: PGP signature
Re: Needed input from Australian users and developers:; choosing timezones for Australia in D-I
On Wed, Mar 23, 2011 at 12:28:18PM +1100, Ben Finney wrote: >Christian PERRIER writes: >>[...] >>That's indeed insane..:-). Hobart (Tasmania), Melbourne (Victoria), >>Sydney (NSW) and Canberra (ACT) have the *exact* same time rules >>(including DST). > >But they didn't always; and with the tendency of governments to flex >their arbitrary timezone powers, they may be different again in future. I fully agree with Ben. >People's knowledge of timezone rules tends (IME) to stick at the point >where they learned about a particular change which they had to learn; it >rarely gets updated. Hobart people will probably not know that >Melbourne's timezone is the same now, for example. In 2006 we had to rush to update the zoneinfo data as the Victorian government decided to have an extra week of Daylight Savings for the Commonwealth Games. In Victoria we were on a different timezone to that of the folks in New South Wales. http://wiki.debian.org/TimeZoneChanges http://lists.linux.org.au/pipermail/debian-au/2006-March/000289.html signature.asc Description: Digital signature
Bug#619347: ITP: jappix -- The first full-featured XMPP web-client in the world
Package: wnpp Severity: wishlist Owner: Philippe Gauthier * Package name: jappix Version : 0.4 Upstream Author : Valérian Saliou * URL : http://project.jappix.com/ * License : AGPL Programming Lang: PHP, JavaScript Description : The first full-featured XMPP web-client in the world Jappix is a fresh new open social platform which enables you to create your own cloud, wherever you want to. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110323015831.21447.84035.reportbug@phil-ThinkPad-T500
Bug#619348: ITP: drupal6-trans-pt-br -- Brazilian Portuguese translation for Drupal 6
Package: wnpp Severity: wishlist Owner: Thadeu Lima de Souza Cascardo * Package name: drupal6-trans-pt-br Version : 1.5 Upstream Author : Portuguese, Brazil translation team * URL : http://drupal.org/project/pt-br * License : GPL Programming Lang: po Description : Brazilian Portuguese translation for Drupal 6 Drupal uses English by default, but may be translated to many other languages. . This is the Brazilian Portuguese translation. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110323021454.3487.25846.report...@nautilus.holoscopio.com
Re: Needed input from Australian users and developers:; choosing timezones for Australia in D-I
I agree with the other Australians in the thread; the east-coast timezones are currently all the same but might not be in the future so we shouldn't rely on them being the same and we should allow selection of Australia/Sydney vs Australia/Melbourne. I would suggest doing what Ubuntu do for timezone & locale selection; have a geographical map that you click on that picks you a timezone and probable locale bits. It could even zoom in to a specific region for selection of those weird timezones like Eyre Highway. Obviously this would only work for g-i not the text-based installer. The text-based installer could use the GNOME strategy of providing a search box to input your city/country and a list of possibly corresponding timezones/locales. -- bye, pabs http://wiki.debian.org/PaulWise -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/AANLkTi=zOgYHduxP_Ewf40DfLiY=1H=vc2v451jx2...@mail.gmail.com
Re: Needed input from Australian users and developers:; choosing timezones for Australia in D-I
On Wed, Mar 23, 2011 at 10:18:04AM +0800, Paul Wise wrote: > I agree with the other Australians in the thread; the east-coast > timezones are currently all the same but might not be in the future so > we shouldn't rely on them being the same and we should allow selection > of Australia/Sydney vs Australia/Melbourne. > > I would suggest doing what Ubuntu do for timezone & locale selection; > have a geographical map that you click on that picks you a timezone > and probable locale bits. It could even zoom in to a specific region > for selection of those weird timezones like Eyre Highway. Obviously > this would only work for g-i not the text-based installer. The > text-based installer could use the GNOME strategy of providing a > search box to input your city/country and a list of possibly > corresponding timezones/locales. Then you have to maintain geographical coordinates for all those regions. And then you can get this sort of problem: http://blogs.msdn.com/b/oldnewthing/archive/2003/08/22/54679.aspx This may not apply to selection of cities, but then if one can only select a city then it's not much of an improvement over the current list. Ben. -- Ben Hutchings We get into the habit of living before acquiring the habit of thinking. - Albert Camus -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110323024429.gi2...@decadent.org.uk
Re: Needed input from Australian users and developers:; choosing timezones for Australia in D-I
Quoting Paul Wise (p...@debian.org): > I agree with the other Australians in the thread; the east-coast > timezones are currently all the same but might not be in the future so > we shouldn't rely on them being the same and we should allow selection > of Australia/Sydney vs Australia/Melbourne. Sure. That was an option I was considering, too. I'm just not fond of "Australia/Sydney" presented as a choice, I'd rather have "New South-Wales". Given that the map idea is great...but just an idea which I certainly am unable to implement, and that I have to deal with what we have *now*, I hereby propose selecting states: New South-Wales Victoria Australian Capital Territory Queensland Tasmania South Australia Northern Territory Western Australia Eyre Highway Yancowinna county Lord Howe Island I will probably propose the same for some federal countries where timzeone and DST rules are set by states/provinces: Brazil and Argentina come to mind (Russia is too complicated for this to be a sane option). So could Mexico. USA and Canada are a fairly different case: the overall use of Atlantic/Eastern/Central/Moutain/Pacific is quite well known among the countries. We may just need to deal with specific exception (Navajo nation not following DST, the Indiana nightmare, etc.) I'll open separate thread for each country to avoid something too messy. signature.asc Description: Digital signature
Problem with ccache
Hi I have a strange problem when building the sdcc package. Compilation fails with the following message: ccache i486-linux-gnu-gcc -pipe -ggdb -g -O2 -Wall -I. -I../.. - I./../../support/Util -I. -c sdcclib.c -o sdcclib.o i486-linux-gnu-gcc: No such file or directory but if I manually enter the directory and run $ i486-linux-gnu-gcc -pipe -ggdb -g -O2 -Wall -I. -I../.. - I./../../support/Util -I. -c sdcclib.c -o sdcclib.o the file compiles without a problem. Can anyone explain to me why ccache fails. Regards Gudjon -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/201103230713.30159.gud...@gudjon.org
