[00:07] dhillon-v10: incorrect because grub is still present [00:07] dhillon-v10: many people are still using grub rather than grub2 for one reason or another. please don't be discourteous and just close all their bugs [00:10] dhillon-v10: please reopen any bugs you've closed for this reason [00:10] I also especially love the way you asked me a question and then waited under ten minutes for a reply before closing the bug :-( [00:11] anyway the fundamental issue in that bug still exists in grub2 [00:12] cjwatson: sorry about that, that's the only one I closed, I should have waited longer I guess, sorry again [00:13] in general closing bugs is at the significantly more experienced end of bug work [00:14] cjwatson: I should have waited longer before closing that bug, will keep that in mind [00:14] closing a bug is essentially taking an item off somebody's to-do list; welcome if it's accurate, but you have to have an excellent correctness rate otherwise developers will get a bit annoyed at having to rewrite their to-do list all the time :-) [00:15] cjwatson: true, I am used to the kernel-bug-day style of triaging so now I know that doesn't apply to the installer team :) [00:15] in this case there are probably a zillion other instances of the same underlying bug, but it's best not to give the reporter the impression that it's fixed when it isn't [00:15] cjwatson: do you have anything in mind that I can work on? [00:15] not at quarter-past-midnight when I'm about to go to bed, sorry ;) [00:16] cjwatson: sorry about that, good night :) [00:16] I made some specific comments the other day when you asked, though [00:17] well, sort of specific [00:17] cjwatson: yeah, I need to read up more and I did that [00:17] cjwatson: and the idea I want to work on requires discussion and time [00:18] so I suggested that there are really quite a lot of crash reports, many of which can be addressed by smallish patches to ubiquity [00:18] so work on those [00:18] then [00:19] 19:41 there's a great deal of bug-fixing to be done, and I would recommend starting with that [00:19] 19:42 we could do with people verifying that old crashes have been fixed, *including references to the commits that fixed them* (this is important; don't just say "I can't reproduce this any more" because it's very common for installer bugs to only reproduce in pretty specialised circumstances) [00:19] 19:43 we could also do with people going through crashes that still exist and fixing them [00:19] 19:43 don't get too enthusiastic about closing bugs, it's better for us to improve the software than to keep the bug count artificially low [00:19] I remeber that :) [00:20] in general you will find that it's easier (involves less discussion and time) to make changes that make the installer more robust, versus changes that involve user interface changes [00:21] and actually it's quite possible that robustness improvements benefit more people, even if they aren't as sexy [00:21] which is for example why one of my current projects is fixing the class of grub bugs that includes your bug above, for good [00:22] :) okay, the only problem I have sometimes is that i classify bugs wrong, so that leads to a wrong comment, but that was the *only* bug I worked on so that's good :) [00:23] if you find you sometimes classify bugs wrongly, then maybe bug triage is not the thing you should be doing at the moment [00:23] it's much easier to classify bugs after you have experience working on the software, anyway [00:23] I don't in general subscribe to the theory that bug triage is some kind of practice for being a developer; it's a skilled discipline in its own right [00:24] much as being a nurse isn't practice for being a doctor - they're different skills :-) [00:24] cjwatson: so what should I focus on then, I did get the code for ubiquity, should I read up on that, I mostly do packaging and documentation atm [09:38] hi cjwatson, a bit late, but I just noticed that the grub gettext support was implemented around December. Is that upstream version going to make it into Lucid? I'm going to point translators to the upstream translation, and I thought I'd just ask, out of curiosity [09:39] dpm: it's already in lucid [09:41] cjwatson, ah great, thanks. I did not see the translation template on the imports queue, it's probably not yet generating the .pot template on build [09:42] yeah, could be, please file a bug about that [09:43] cjwatson, sure, I was about to do it :) [09:43] it's moving pretty fast right now so for the moment it would be good for translators to go upstream anyway [09:43] yeah, I'll point them to go to upstream first [09:43] thanks [09:44] cjwatson, and another question, do you know if the 'debian/pobuild/templates.pot' template in localechooser is merged into any other template, so I can block it from the imports queue? [09:46] yes, please block that - it's just the result of merging localechooser's ordinary templates with iso-codes [09:47] ok, thanks! [13:30] cjwatson: if you have a brief moment, can you just eyeball this to make sure it's in line with your expectations of how it would be implemented: http://paste.ubuntu.com/362594/ [13:31] http://paste.ubuntu.com/362596/ - sorry, this one has syntax highlighting [13:31] ev: looks plausible [13:31] ev: in ubiquity, can we use the city information as well? [13:32] nit: the default should be prefixed with http:// [13:32] what for? [13:32] ah, fixed [13:32] to plot the correct point on the map, and to select the correct country [13:33] ah, duhh. Sure, I'll work that in [13:33] thanks [13:33] otherwise woo [13:35] indeed, I was very excited to get that email from IS [15:16] cjwatson: perhaps I don't understand after all. What does the full timezone, say "America/New_York" for Boston, not give you that "Boston" does? Or are you requesting that we use the (lon, lat) pair and the city name to better position the dot? [15:16] Perhaps I'm just failing to think of the example that invalidates this [15:19] ev: Europe/Berlin and Europe/Vienna are the same time zone, but different countries [15:20] I'm requesting that we use the full timezone information to deal with the default for country selection as well as the default for the timezone [15:42] cjwatson: Apologies, but I still don't follow. The database returns zoneinfo entries, not UTC offsets (http://pastebin.com/f55679749). Cities in Germany will return Europe/Berlin, not Europe/Vienna. But assuming this is still just an issue of me being thick, what do I need to preseed, debian-installer/country? [15:43] cities in Austria will return Europe/Vienna, though :-) [15:45] ah, maybe you don't need to do anything. I think the timezone component already handles converting the selected timezone into a country [15:46] which was the bit I had forgotten was there [15:46] okay [15:53] tzsetup: evand * r507 tzsetup.ubuntu/ (debian/changelog debian/tzsetup-udeb.templates tzsetup): Support getting the timezone from a geoip server (LP: #229884). [16:02] tzsetup: evand * r508 tzsetup/debian/changelog: releasing version 1:0.26ubuntu2 [16:06] ubiquity: evand * r3713 ubiquity/ (debian/changelog ubiquity/components/ubi-timezone.py): Support getting the timezone from a geoip server (LP: #229884). [16:09] ubiquity: cjwatson * r3714 ubiquity/scripts/tzsetup: update path === roobiew_ is now known as robbiew [22:15] looking for a little help with preventing the main menu from always being prompted at netboot of lucid - jumped thru every hoop I've found, and I continue to be prompted for it.. [22:15] copying boot args and preseed somewhere in a sec [22:19] http://paste.ubuntu.com/362900/ - if someone has a hint, it would be appreciated - I've tried many combinations of $LANG stuff in boot args - getting a little frustrated at this point.. [22:26] if you're seeing the main menu presented with that, it probably means the installer is hitting an error somehow. use 'save debug logs' to copy out the syslog and post it for us to see [22:37] I have an install running - interesting thing is that all I need to do is hit the configure network option and everything rolls on as I intended [22:38] mashing on the configure the keyboard option does nothing but dump back to the main menu [22:39] we'll see what the logs look like - I've looked through 'em several times and can't put my finger on it [22:46] exlt: I'm used to interpreting the logs [22:47] there are several flaws with your locale and keyboard preseeding which I can tell you right off, though [22:47] firstly, locale and keyboard stuff needs to be preseeded on the kernel command line, not in the preseed file (unless you're doing initrd preseeding - if you don't know, you aren't) [22:48] secondly, discard all of debian-installer/keymap, console-keymaps-at/keymap, console-setup/layout, console-setup/model, and console-setup/variant [22:48] thirdly, console-setup/modelcode needs to be pc105 rather than pc104 [22:49] (I'm reasonably sure, anyway - I know pc104 is technically probably more accurate, but I think pc105 is what we generally set it to anyway) [22:50] http://12.am/etc/lucid/syslog.txt [22:50] I added all those trying to get rid of the menu - only had I think 2 lines in there when I started [22:53] right, put the console-setup preseeding on the kernel command line rather than in the preseed file [22:53] its basic complaint is that you've asked it to do noninteractive installation at priority critical but it doesn't know the answers to the questions yet [22:58] know what the bare minimum args would be to satisfy? [22:58] I've added and removed a bunch - or if the console-setup/ask_detect=false is required there? [23:02] console-setup/layoutcode=us should be sufficient [23:02] ditch console-setup/ask_detect=false, you don't need it [23:03] that was another punt.. [23:03] hmm, there may be something else wrong [23:03] you said lucid, I hadn't noticed that before [23:04] we recently landed support for translated keyboard names, which could well have broken this [23:04] yes, I think so [23:05] yeah - this is lucid installer testing which may go to production prior to lucid release [23:05] ev: ^- could you have a look at this? seems to me that the format of $kbdnames has changed, but ask_debconf hasn't changed along with it [23:11] interesting [23:31] is "INFO: Menu item 'network-preseed' selected" the point where the preseed is actually beginning to be processed? [23:32] yes [23:38] I wonder if doing something like an oem-config/enable=true and skipping the keyboard step would get me past that - these are headless servers anyway ;) [23:44] nah, doesn't seem to [23:53] you're probably stuck until we fix the bug, I'm afraid