[06:33] <CIA-3> ubiquity: superm1 * r3070 ubiquity/ (debian/changelog scripts/mythbuntu/mythbuntu_install.py):
[06:33] <CIA-3> ubiquity: Change the method for mapping role to package removal to something
[06:33] <CIA-3> ubiquity: more scalable.
[11:21] <juanje> hi, guys :-)
[11:21] <juanje> may I ask a couple of questions?
[11:23] <juanje> I was trying to translate some new strings there are in the Ubiquity (user info step) and I dicovered that the strings are in the code since few weeks ago, but not in the rosseta template
[11:24] <juanje> the translations are pulled by hand or each some time?
[12:23] <mpt> juanje, many Ubiquity strings are in the debian-installer template. Did you look there?
[12:24] <juanje> actually, those are there
[12:24] <juanje> but the they are not uploaded to rosseta
[12:25] <juanje> the las update is from month ago, I think
[12:28] <cjwatson> I filed a ticket over the weekend to have them updated
[12:28] <cjwatson> they're mangled semi-automatically; there are scripts to do most of the mangling but they do need to be shovelled about by hand
[12:28] <cjwatson> this is because we incorporate Ubiquity's strings into a single master template for all of the installer, to cope with common strings better
[12:29] <cjwatson> in retrospect it's possible that Ubiquity should be pulled back out of this system, as it doesn't produce as much benefit as it once did
[12:29] <cjwatson> juanje: https://answers.launchpad.net/rosetta/+question/62725, FYI
[12:29] <juanje> cjwatson: thanks :-)
[12:29] <cjwatson> it's my fault that those are late, I hadn't noticed that the cron job was down :-(
[14:11] <CIA-3> clock-setup: cjwatson * r203 ubuntu/ (3 files in 2 dirs):
[14:11] <CIA-3> clock-setup: Use 'update-dev --settle' rather than 'update-dev' after loading rtc
[14:11] <CIA-3> clock-setup: modules. Requires di-utils 1.66.
[14:13] <CIA-3> hw-detect: cjwatson * r108 ubuntu/ (debian/changelog debian/control hw-detect.sh):
[14:13] <CIA-3> hw-detect: Use 'update-dev --settle' rather than 'update-dev' after loading modules
[14:13] <CIA-3> hw-detect: (although not after installing new module packages, which may still
[14:13] <CIA-3> hw-detect: require a trigger). Requires di-utils 1.66.
[15:01] <CIA-3> partman-auto-lvm: cjwatson * r218 ubuntu/ (debian/changelog debian/control lib/auto-lvm.sh):
[15:01] <CIA-3> partman-auto-lvm: Use 'update-dev --settle' rather than 'update-dev' after loading dm-mod
[15:01] <CIA-3> partman-auto-lvm: and lvm-mod. Requires di-utils 1.66.
[15:05] <CIA-3> partman-base: cjwatson * r135 ubuntu/ (commit.d/update-dev debian/changelog debian/control):
[15:05] <CIA-3> partman-base: Use 'update-dev --settle' rather than 'update-dev' during commit.
[15:05] <CIA-3> partman-base: Requires di-utils 1.66.
[15:08] <CIA-3> partman-partitioning: cjwatson * r699 ubuntu/ (debian/changelog debian/control lib/resize.sh):
[15:08] <CIA-3> partman-partitioning: Use 'update-dev --settle' rather than 'update-dev' after resizing or
[15:08] <CIA-3> partman-partitioning: committing. Requires di-utils 1.66.
[15:10] <CIA-3> rootskel: cjwatson * r338 ubuntu/ (3 files in 2 dirs):
[15:10] <CIA-3> rootskel: Use 'update-dev --settle' rather than 'update-dev' after loading fbcon
[15:10] <CIA-3> rootskel: module. Requires di-utils 1.66.
[15:23] <davmor2> cjwatson: I thought that once someone had assigned it to themselves no one was meant to touch the bug anyway or am I mistaken?
[15:26] <cjwatson> davmor2: sorry, I seem to have lost context
[15:27] <davmor2> cjwatson: Sorry I was reading through you blog post and got to the bit about when a dev has picked up the bug don't close it etc.  I forgot you can't actually see what I'm reading and although I expect you to be able to read my mind you haven't perfect the skill yet :D
[15:28] <cjwatson> oh, right
[15:28] <cjwatson> davmor2: well, you might think that
[15:28] <cjwatson> davmor2: my experience is that people often fail to respect that; but even then, I don't always assign a bug to myself after verifying that it exists
[15:28] <cjwatson> sometimes I mark it as triaged, leave a note explaining it, but it's not something I plan to fix myself soon
[15:29] <davmor2> fair enough :)
[15:30] <cjwatson> the problem I have is less one of failing to respect assignment, and more one of "if somebody experienced in the software in question has verified that the bug exists, you might want to stop arguing that it doesn't unless you're really confident that you have better information"
[15:30] <davmor2> :)
[15:32] <davmor2> So software creator is okay to close the bug when he's fixed it but newbie looking for "Low Fruit" bugs shouldn't touch it with a ten foot barge pole
[15:32] <cjwatson> I don't want it to come across as an argument from authority
[15:32] <cjwatson> those are generally fallacious
[15:33] <cjwatson> but it seems to me that if you're looking for invalid bugs to close, the ones that have been confirmed by a developer who probably verified it by looking at the code are not a particularly good place to start
[15:35] <evand> Did that happen and prompt this?
[15:35] <davmor2> :) I'd be temped to agree you might want to get that added to global bug jam notes.  It might help prevent it in the future.  There were a lot of new people who went to them who had never triaged bugs and were shown how but not really told what not to touch
[15:37] <davmor2> cjwatson: ^
[15:37] <davmor2> it might be some of the new bloody getting over zealous
[15:37] <cjwatson> evand: prompted by a series of incidents rather than anything specific
[15:38] <cjwatson> davmor2: I ran my post past Henrik before posting it, and he's going to bring it up in the QA meeting
[15:38] <davmor2> cjwatson:  :)
[15:38] <evand> ah, nothing I've done I hope.  I've been making passes over the ubiquity bugs over the past few days.
[15:38] <cjwatson> since my goal was not just to have a rant but to get practices changed where possible
[15:38] <cjwatson> evand: oh goodness me no
[15:39] <evand> ah, ok
[15:39] <cjwatson> no, it's usually new guy comes along and enthusiastically does a bunch of stuff before somebody manages to have a word with them
[15:39] <evand> ah
[15:41] <stgraber> cjwatson: From mgariepy: The other buggy preseed now works ... :)
[15:44] <kirkland> cjwatson: hi there...  i uploaded a new kvm that fixes some screen corruption issues
[15:45] <kirkland> cjwatson: i suppose there's a distant chance that the problem you were seeing is related
[15:45] <kirkland> cjwatson: let me know if you see your keyboard lockup problem with kvm_84+dfsg-0ubuntu5
[15:46] <cjwatson> stgraber: you mean the one with backslash-space-newline works on which version?
[15:46] <cjwatson> kirkland: ok, will do, thanks
[15:47] <kirkland> cjwatson: thanks.  i did *not* mark your bug as fixed by this, since i couldn't reproduce the problem
[15:55] <stgraber> cjwatson: nope, the other one mgariepy talked about. The one with the backslash-space-newline still doesn't work unless you drop the space.
[15:57] <cjwatson> stgraber: ok, so the one that didn't have an expert recipe is confirmed to work?
[15:57] <cjwatson> backslash-space-newline, as mentioned, not supposed to work
[16:01] <stgraber> cjwatson: yeah for the first and I agree with the second though d-i should have been consistent and always fail :)
[16:09] <cjwatson> I'm probably not going to debug it now
[16:09] <cjwatson> debugging why something that should never have worked nevertheless worked on some old version while it now fails the way it's supposed to is not my idea of fun :-)
[16:20] <stgraber> yeah and there is nothing to fix anyway so ... :)
[16:24] <CIA-3> console-setup: cjwatson * r95 ubuntu/ (debian/changelog setupcon):
[16:24] <CIA-3> console-setup: If reading a user configuration file, disable --save, and don't use
[16:24] <CIA-3> console-setup: /etc/console-setup/boottime.kmap.gz (LP: #332728).
[16:28] <CIA-3> console-setup: cjwatson * r96 ubuntu/ (Keyboard/KeyboardNames.pl debian/changelog): Update Keyboard/KeyboardNames.pl based on xkb-data 1.5-2ubuntu5.
[16:34] <CIA-3> console-setup: cjwatson * r97 ubuntu/debian/changelog: releasing version 1.28ubuntu6
[16:38] <manjo> cjwatson, I am here
[16:38] <cjwatson> ok
[16:39] <cjwatson> manjo: what's the output of 'dmraid -c -s; echo $?' on this system?
[16:40] <manjo> cjwatson, the machine seems to be down... I will need to get in touch with the engg in HP to get it online again...
[16:41] <manjo> that sucks.. let me get back to you on it
[16:41] <cjwatson> ok, no problem
[16:50] <manjo> cjwatson, booting..
[16:54] <manjo> cjwatson, manjo@ubuntu:~$ sudo dmraid -c -s; echo $?
[16:54] <manjo> [sudo] password for manjo:
[16:54] <manjo> no block devices found
[16:54] <manjo> 1
[16:54] <manjo> manjo@ubuntu:~$
[16:55] <manjo> cjwatson, but it asked me raid y/n question... I thought you skip it that is why I asked you the Q
[16:56] <cjwatson> right, it shouldn't be asking it in this case
[16:56] <cjwatson> manjo: what image were you installing?
[16:57] <manjo> its a server insall of jaunty alpha
[16:58] <manjo> jaunty alternate amd64
[16:58] <evand> cjwatson: I really need to start writing better comments in code to remind me of the decisions we made.  Regarding grub-installer r753, do you recall why always installing to the MBR of the device that's going to contain /boot is a bad thing?  It presents a bit of a usability issue for people installing to USB disks where the USB disk ends up as something other than sda.
[16:58] <evand> I do recall this being a "best of a bad set of options" decision.
[16:58] <cjwatson> manjo: but what version of jaunty?
[16:59] <manjo> that is a good question.. trying to find out
[16:59] <cjwatson> evand: we can't reliably determine the GRUB device name for that device if it wasn't the boot device
[16:59] <cjwatson> for ubiquity I have been coming to believe that we're just going to need to have some way for the user to explicitly tell us :-/
[17:00] <cjwatson> i.e. explicitly tell us which device they're going to be booting off as well as which device to install GRUB to
[17:00] <manjo> cjwatson, Jaunty Alpha5 from 25th Feb
[17:00] <manjo> for AMD64
[17:01] <cjwatson> manjo: ok, what was the precise wording of the question it asked you?
[17:03] <cjwatson> manjo: (I'm going out shortly so may not answer immediately, but feel free to dump as much precise information as you can get)
[17:03] <manjo> I dont recall the exact wording.. it was something along the lines of would you like to set up SATA RAID etc..
[17:03] <manjo> I can reinstall and capture it again
[17:03] <cjwatson> manjo: if you have time, then the best way to get us an accurate trace of what's going on is to boot with DEBCONF_DEBUG=developer on the kernel command line, and then extract /var/log/syslog from the running installer (you can use 'anna-install openssh-client-udeb' and then scp it to another machine)
[17:04] <evand> cjwatson: indeed, but perhaps we can just use some space on the summary page to put the drop down there with os-prober / parted device names to make it as easy as possible.
[17:05] <cjwatson> mm, yeah
[17:06] <manjo> cjwatson, ok... need to get permissoin from owner of machine to re-install I will fill you in with details soon (or by mail)
[17:09] <evand> http://pastebin.ubuntu.com/125362/ - just to be sure I understand the problem correctly, is that an accurate statement?
[17:11] <CIA-3> tasksel: cjwatson * r1399 ubuntu/ (debian/changelog tasksel.pl):
[17:11] <CIA-3> tasksel: When doing manual package selection, run aptitude's visual mode via the
[17:11] <CIA-3> tasksel: terminal plugin with --schedule-only, then install the packages
[17:11] <CIA-3> tasksel: separately under the control of debconf-apt-progress so that we get a
[17:11] <CIA-3> tasksel: progress bar.
[17:12] <CIA-3> tasksel: cjwatson * r1400 ubuntu/debian/changelog: last change fixes LP: #330656
[17:25] <cjwatson> evand: I *think* so (except for "reliabily" typo) but have to run. The point to verify is whether the device name is used only locally in grub-installer or whether it also turns into something embedded in the grub stage1
[17:26] <evand> whoops, ok noted
[17:40] <evand> mpt: the gtk-information icon (i) does not exist at a dialog resolution.  Is it ok if I use the light bulb information icon?
[17:40] <mpt> evand, remind me what for?
[17:41] <evand> sorry, ENOCONTEXT: https://bugs.edge.launchpad.net/ubuntu/+source/ubiquity/+bug/258017
[17:42] <mpt> evand, ah right, yes, that's fine
[17:42] <evand> wonderful
[17:47] <CIA-3> grub-installer: evand * r770 ubuntu/ (debian/changelog grub-installer):
[17:47] <CIA-3> grub-installer: Clarify why we cannot always default to the device that contains the
[17:47] <CIA-3> grub-installer: boot partition for grub-installer/bootdev.
[17:52] <CIA-3> ubiquity: evand * r3071 ubiquity/ (3 files in 2 dirs):
[17:52] <CIA-3> ubiquity: Use better descriptions on the finished dialog and show an information
[17:52] <CIA-3> ubiquity: icon to be consistent with other dialogs. Thanks Matthew Paul Thomas
[17:52] <CIA-3> ubiquity: (LP: #258017).
[17:53] <evand> I'll look over the rest tomorrow
[18:28] <mathiaz> Hi - is it possible to use partman-auto-raid when preseeding on hardy netboot install?
[18:28] <mathiaz> partman-auto-raid being in universe in hardy
[18:28] <mathiaz> it works for intrepid+ (since it's in main)
[18:28] <mathiaz> (or should work)
[19:41] <superm1> cjwatson, is there an unseen intrinsic purpose for waiting 60 seconds before declaring that the X server failed to start in ubiquity/bin/ubiquity-dm?  I was trying to look through bzr annotations for notes about it, but  all I see if your initial checkin at revno 2206.  if it's an arbitrary value, would you mind decreasing it to something lower yet still practical?
[21:46] <tjaalton> mathiaz: you need to install the udeb in early_command first
[21:52] <mathiaz> tjaalton: apparently it does work on 8.04 -> https://lists.ubuntu.com/archives/ubuntu-server/2009-February/002646.html
[21:53] <mathiaz> tjaalton: does the fact that the src pkg is in universe means it's not available during the netboot install?
[21:55] <tjaalton> mathiaz: I've forgot the constraints about main/universe in this case, but just running anna-install isn't enough
[21:55] <tjaalton> for instance I need to wget the multipath udebs first and then install them using udpkg
[21:56] <tjaalton> (yeah, I'd appreciate if the multipath-udebs would be in main)
[22:21] <cjwatson> superm1: it's pretty arbitrary, I think. Do you have a specific suggestion?
[23:20] <superm1> cjwatson, i didn't have a specific suggestion other than "lower"  It seemed arbitrary to me in that the X server will fail to startup within a few seconds.
[23:20] <superm1> so maybe 5 or 10 seconds would be better
[23:22] <superm1> normally it's a moot point, but with that patch i put in to fall back to noninteractive, it turns into a lot of time twiddling your thumbs
[23:23] <superm1> i've got a specific case that triggers it happening (no monitor plugged in during install), so i'll do some experiments with lower numbers tomorrow to see what works out well