I'm not sure where to assign this, but ... there are too many packages in Debian that ask for your location or variants thereof, all in an uncoordinated fashion. To whit: time zone latitude/longitude (wmmoonclock, wmsun, various mapping programs) nearest ICAO station (wmweather) paper size a4 vs letter (papersize library, and a couple stragglers) language (locale, and a couple stragglers) country (something must request this I'll bet) altitude (again I bet something uses this) Right now, this stuff is easy to get inconsistent, and each one requires effort to figure out. Some of them are even tricky to change, or even to remember. It would be nice if these would *ALL* assume default values given just one, on both a global system-wide basis and over-ridable on a per-user and per-session basis. In other words, when I move my laptop I should be able to put in the new lat/long and, assuming everything else is set up to default, all these other things should be filled in with their most probably values. Eg the nearest ICAO station, the most popular language in the location I'm in, the size of paper they use there, etc. Similarly, if I fill in just a country and it is a small country, and I haven't filled in lat/long or anything else, everything should snap to reasonable values. If that's not enough to figure out eg the time zone, at least the timezone menu should start with a list of timezones in that country. If I fill in a lat/long outside that country, it should give me a warning. If I fill in a city it should take the lat/long in the center of that city. If some user fills in a different country & city, blam everything should "just work" for that user. I think this could be accomplished with appropriate debconf stuff and a "location-related-query" executable that looks at global info, per-user files in their home directory, and environment variables. Or maybe a library, for easier retrofitting into little programs. With some modular architecture so one can add new location-related values which can be derived from lat/long/alt, and which therefore if filled in can also be used to constrain this and therefore other derivable values.
Defaults should be reasonable, and not kick the user. While it is reasonable to assume the user will want weather forecasts for hir current location, a laptop that starts speaking Mongolian to me when I do a trip to Oulan-Bator certainly doesn't look user-friendly to me.
Well okay, granted ... but the locale would almost always be explicitly set, and wouldn't change when eg the lat/long are modified.
I disagree on that particular point. If someone installs a Debian, and the install programs asks for lat/long, and then the system starts speaking the "right" language to the user, he will never have set the locale explicitly. Two solutions: - Have the install program infer the (default) locale from the lat/long, but the lat / long changing program doesn't touch locale. - Don't mix coordinates and language at all. The install program asks for the default system locale as it does now.
I think that's the best solution. There are parts of the world with more than one official language, and in some of those parts (such as Quebec, or Belgium), guessing incorrectly may be a good way to severely piss off a user.
And if gpstrans is installed, query the GPS receiver directly for the current lat/long :-) Paul Slootman
Hi, I'm closing this bug because basically it's too broad (it belongs into many packages) and also because these are upstream issues, nothing Debian can or should really do about this. It's a nice idea, but IMO nothing more than that at the moment. And it's an idea which should be dealt with upstream. regards, Holger
What makes Debian a "distribution" rather than just a random collection of miscellaneous software is integration. This is an integration wishlist. It has to happen at the distribution level if it is to happen anywhere. I don't understand why you want to close this issue---the logic seems to be just that it's hard to address, but that doesn't seem like a very compelling reason. And I don't see how it can be filed against any (or many) particular packages---it is an issue that requires policy and coordination between many packages, and hence belongs on Package: general.
Hi Barak, As said, feel free to reopen. And, as usual.., are you willing to work on this goal? Also IMO it's not really about integration (yet). First, some general plan and then an implementation needs to be found, maybe within freedesktop.org, maybe not. Then, packages would need to be changed to implement this plan. And then a mass bug filing could be done, if there is consensus on debian-devel@ that this should be done. In the bug report I read no consensus _and_ no activity since 5 years. But, as said, feel free to reopen. regards, Holger
Debian has made analogous contributions in similar domains: see package libpaper, or tempfile(1) in debianutils, or emacsen-common. So it not just our mandate; we even have a history. spinning in the air. But I'm happy to bounce things around with people. taken, and it is unclear which would be most sensible. (Library, like papersize? Executable, like tempfile? Location network server and protocol?) But at root, we should recognize that this is not a very hard problem; merely a tedious one. Like many design decisions, it would be good for a group to talk through some options in order to come up with a minimal but extensible (eg, accept and/or broadcast location via avahi) design appropriate to this particular problem. That's what debian-devel is for, at its best. Then the real hassle starts: rejiggering all the plumbing to hook things into a shiny new system.
Hi Barak, And you did :-) If there are people who are willing and able to do the work... that was actually part of the reason I closed it. Appearantly for years there was no one to tackle this. (And if there is no progress again within the next two years or so, I'll likely close this again.) But no one did. Maybe it's worth having a BoF about this at next DebConf? good luck & have fun, Holger
Guess we have different ideas about what "wishlist" bugs are for. My attitude is they're for wishes, like the sea is for fishes. Sometimes someone picks one up, perhaps even a big wily old fat one. Maybe takes it on as a summer-of-code project, or whatever. It might swim around for many years, that's okay. They form a pool of ideas, and sometimes someone fishes around and finds one they want to take to heart.
Wishes should still have some possibility of attainment, otherwise it is wishful-thinking not wishlist. (Subtle difference, at least to me - and Holger by the sounds of it too). Issues that get no response in years, despite all the changes that happen between the releases that occur within that time, should just be considered as 'dead'. They had their time, nobody thought they were good enough ideas to be worth investing any significant amounts of effort. If it was a good idea, the bug report is still there, it is still archived. Someone can reopen it *IF* they can make time available to turn the wish into a proposal. If ideas get positive feedback and the bug report has lots of discussion, maybe it is worth making a Wiki page for the idea (as long as the discussion has moved beyond painting the bike-shed).
Hi, Yup. Sorry for the low signal here, but I thought I should state this as I have been dealing with those general bugs a lot recently. I do consider the general bugs everyDDs bugs though and if there is consensus to leave such bugs open forever, I'm happy to let them be. I just think what Neil summarized above... :-) regards, Holger P.S.: please respect the reply-to: header and don't cc: this bug on replies.
Sehr geehrter Käufer, Sie haben eine nicht bezahlte Forderung bei unseren Mandanten Ebay eG. Ihr Kreditinstitut hat die Lastschrift storniert, da Ihr Bankkonto zur Zeit der Buchung nicht genügend gedeckt war. Wir erwarten die gesamte Überweisung zuzüglich der Mahnkosten bis spätestens 29.06.2015 auf unser Konto. Aufgrund des bestehenden Zahlungsausstands sind Sie verpflichtet außerdem, die durch unsere Tätigkeit entstandenen Gebühren von 65,70 Euro zu tragen. Namens unseren Mandanten Ebay eG fordern wir Sie auf, die noch offene Forderung schnellstens zu bezahlen. Bei Fragen oder Unklarheiten erwarten wir eine Kontaktaufnahme innerhalb von drei Werktagen. Eine vollständige Forderungsausstellung, der Sie alle Einzelpositionen entnehmen können, ist beigefügt. Nach Ablauf der festgelegten Frist wird die Angelegenheit dem Staatsanwalt und der SCHUFA übergeben. Mit besten Grüßen Abrechnung Thurn Elias