[01:36] casper: cjwatson * r698 trunk/ (debian/changelog scripts/casper-bottom/19keyboard): [01:36] casper: Extend our hack that arranges to run setupcon after usplash exits to [01:36] casper: cover the new Upstartified usplash as well. [01:37] casper: cjwatson * r699 trunk/debian/changelog: releasing version 1.196 [05:59] box PXE boots, can load both ibex and karmic installers, run them, but can't get a dhcp response. I just installed karmic from cd, it booted and got a dhcp response [06:01] Intel 82557 Ethernet pro 100mb nic [06:04] 03:04.0 Ethernet controller: Intel Corporation 82557/8/9/0/1 Ethernet Pro 100 (rev 08) [09:32] evand, hi, where is your gallery of Ubiquity screenshots of each stage? [09:33] mpt: http://people.canonical.com/~evand/screenshots/ [09:34] I should probably update some of those (the slideshow especially). I'll pull down the latest daily-live and do that now. === cjwatson_ is now known as cjwatson [09:34] evand, yes, I see 8.10 there, I think the text has changed a bit since then [09:35] http://people.canonical.com/~evand/screenshots/ubiquity/1.12.3/ is Jaunty, but the point still stands. [09:35] ah, thanks [09:36] cjwatson, d-i is quite unhappy on armel (imx51, vfat image) due to the fact that there is no dist/stable symlink to dist/karmic, ghiven that vfat doesnt support symlinking, is there any way around that ? i tried moving karmic -> stable which gets me through partman but then debootstrap cant find the codename for the release [09:37] ogra: are you using cdrom-detect? [09:37] i thought lool added that recently [09:38] it's a question suggesting a yes or no answer ;-) [09:38] actually, not sure that's relevant. could I please have a full syslog [09:41] evand, sorry for the silly question, but is Wubi on the live CD? [09:41] yes [09:41] mpt: indeed it is. In the root of the CD. [09:42] thanks [09:42] cjwatson, i see cdrom-detect in the log and indeed its the part that fails when looking for dist/stable, i'll save the log somewhere, d-i installs are not a high prio on armel atm [09:43] well, it was my memory that cdrom-detect would be the relevant bit, but on looking at the code I can't see exactly which bit might fail. that's why I asked for the log [09:46] cjwatson: Do you remember that weird missing font issue I had a while ago on lpia? I just hit the same on armel alternates: black squares when prompted by to type some keys to detect my layout [09:46] bug #357630 [09:46] Launchpad bug 357630 in kvm "fonts don't match chars used in d-i" [Wishlist,Invalid] https://launchpad.net/bugs/357630 [09:48] cjwatson, http://people.canonical.com/~ogra/syslog dont handle it as high prio though, armel alternate is just a nice to have [09:51] ogra: why did you say that cdrom-detect is the part that fails? (it isn't) [09:51] in the UI it seems to be the part that fails [09:51] it fails due to something else [09:51] i have to mount /dev/mmcblk0p2 manually and move the dir [09:51] at least so the log suggests? [09:51] what is the error message in the UI? [09:52] * lool managed to load components from CDROM with the latest dove alternate, yeah! [09:52] Just need a preseed fix for cdrom-detext [09:52] well, that it could not detect a cd i then get offered to load cd drivers from removable media [09:53] please don't paraphrase error messages [09:53] sorry, i dont recall the exact text and already overwrote my SD [09:53] ok, can't help then, sorry [09:53] feel free to come back when you have the exact text [09:53] i'll do it again later [09:53] and then I can grep for the relevant code paths [09:54] I'd like to fix this but since you say it's not high-priority I don't want to spend too much time investigating something that might turn out to be a red herring [09:54] right [09:55] i'll test again after the live test [09:55] which is the actual image we care about [10:06] cjwatson: good morning, I've just been pointed out by translators that there is something wrong with the ubiquity templates, now both 'ubiquity-desktop' and 'ubiquity' are the same templates. It seems that the wrong template was uploaded for 'ubiquity' -> https://translations.edge.launchpad.net/ubuntu/karmic/+source/ubiquity [10:06] how could that have happened? [10:06] do you mean I did a wrong manual upload or something? [10:06] I don't know, it seems to have happened 13 hours ago. Was there an upload at about that time? [10:07] a package upload yes, but I didn't do anything manual [10:07] if the package upload caused something bad to happen, then metadata in Launchpad must be wrong [10:07] let me grab some launchpadders... [10:08] and it wasn't the first package upload since I was last aware of the metadata being changed around [10:10] dpm, you called? [10:10] yes, thanks for coming, jtv, here's the issue: [10:10] https://translations.edge.launchpad.net/ubuntu/karmic/+source/ubiquity [10:11] has 2 templates [10:11] which are now identical [10:11] the 'ubiquity' one is wrong [10:11] it used to be a much bigger template [10:12] and we don't know what has caused to change it [10:12] there was a package upload about 13 hours ago [10:12] but cjwatson hadn't done any manual uploads [10:13] The configuration is pretty weird. [10:14] The ubiquity-desktop template has domain "ubiquity" [10:14] whereas the ubiquity template has domain "debconf" [10:14] The ubiquity-desktop template also has filename po/ubiquity.pot [10:16] so somebody screwed up the rename [10:16] po/ubiquity.pot is correct for ubiquity-desktop [10:16] I see two uploads, both approved to be imported into the ubiquity template. [10:16] the ubiquity template should come from debian/real-po/templates.pot [10:17] I have no idea what its domain should be, domains aren't significant to debconf translations so it would be an artificial construction [10:17] I'm editing the entry. [10:18] jtv: how do we avoid losing translation data here? [10:18] can we revert that part of the db to before the incorrect import? [10:18] cjwatson: the translation data should come back instantly when the templates are set right again. [10:33] jtv: I just got disconnected. Just to make sure, did you get my previous messages with the description of the issue? [10:33] dpm: I'll paste you the relevant bits in /msg [10:33] dpm: no [10:34] dpm: unless you mean the one 22 minutes ago [10:34] nothing after that [10:34] we got everything up to "but cjwatson hadn't done any manual uploads" [10:34] to clarify, I did manual uploads *ages* ago [10:34] Meanwhile I've approved the new uploads to go into the right templates. [10:34] jtv: any ideas on what could have happened here? [10:34] I see that https://translations.edge.launchpad.net/ubuntu/karmic/+source/ubiquity/+imports?field.filter_status=all&field.filter_extension=pot shows two approved templates [10:34] To further confuse matters, it seems that debian/real-po/templates.pot will be imported into 'ubiquity' (which would be the correct template) [10:34] whereas po/ubiquity.pot seems that will _also_ be imported into 'ubiquity' <- that might be the problem. That template should be imported into 'ubiquity-desktop' [10:34] weeks, I think [10:35] dpm: I thought I just fixed that!? [10:35] I *think* I did check after that and observed sane output, though I don't remember for sure [10:35] jtv: what did you fix and what needed fixing? [10:35] jtv: he's pasting what he said between being disconnected and realising he was disconnected [10:35] phew, still fixed [10:36] cjwatson: silly me! thanks [10:36] dpm: somehow, both templates got approved for the same template. I can't think why, but given the strange configuration it's not entirely unthinkable [10:38] Figuring this out could take some effort. Normally template approvals are based on paths, which in this case shouldn't present a problem (even if they are weird). [10:38] So _if_ this was an auto-approval, why was it not based on paths? [10:38] Or was it based on paths, and have the paths changed since? [10:39] they haven't changed since the last time we worked on the configuration here; they have certainly not *exchanged* [10:40] Evan Dandrea also uploaded a template btw [10:41] That was on Friday. It was po/ubiquity.pot but it went into the ubiquity template, not the ubiquity-desktop one. [10:43] that would have been a package upload [10:43] so that just means we know the configuration was broken at least back to Friday [10:43] Evan's package upload was actually on Thursday but I guess it took a while to get through the queue [10:45] May be timezones as well. The time I see is localized for me and says Friday 01:03 ICT, so that's Thursday for you. [10:45] Yeah, I was in PDT on Thursday. [10:46] So that was a package upload? [10:47] yes [10:48] tasksel: cjwatson * r1422 ubuntu/ (6 files in 3 dirs): [10:48] tasksel: Omit tasks with no descriptions (namely ubuntu-edu-preschool, [10:48] tasksel: ubuntu-edu-primary, ubuntu-edu-secondary, and ubuntu-edu-tertiary; [10:48] tasksel: LP: #438546). [10:50] I'm digging through the templates approval logic a bit [10:51] tasksel: cjwatson * r1423 ubuntu/debian/changelog: releasing version 2.73ubuntu22 [10:53] Nope, no way that could have gotten auto-approved without a path match [10:55] Which leaves 2 possibilities: manual approval, or an upload to a page for the wrong template. [10:55] cjwatson: do you still use the lp translations tools for uploading these files? [10:56] yes [10:56] jtv: is there a way to track if it was manually approved? I'm not concerned about who did it, I'm only interested to see if we'll have to keep an eye on this template [10:56] I no longer have the command lines to hand [10:56] dpm: we'd have to ask the sysadmins to dig through access logs. Ugly. [10:56] Anyway, what if the confusion happened because a translation domain got confused with a template name? [10:56] jtv: don't worry, I'll ask at the u-t-c list [10:57] One template is name ubiquity and the other has domain ubiquity, that's bound to cause trouble somewhere. [10:58] What do we know about when this template started being wrong? [10:58] cjwatson, mind if i make the "debian/genbuilddeps" instructions more explicit when i actully do the missing run for my last b-d change from yesterday ? [10:58] "Note that this comment can also be used to generate a Build-Depends line, by running the debian/genbuilddeps program." makes it sound very optional and i always forget it [10:59] jtv: the template was renamed from "debconf" to "ubiquity" a while back because "debconf" was 'confusing'. [10:59] I think that was not clearly the best possible decision [11:00] ogra: I'd prefer you didn't introduce another thing to make that file more complicated to merge [11:00] cjwatson: ubiquity-debconf might have been safer [11:00] ogra: if you want it changed, mail me improved text and I'll look at changing it upstream [11:00] dpm: ^- [11:00] ok, couldnt debian/genbuilddeps be run automatically ? [11:00] no. [11:00] leave that alone please :) [11:00] ok [11:01] generating build-deps entirely automatically tends to be bad and wrong; I expect people to read comments [11:01] i wasnt planning to :) [11:01] (it causes problems with timestamp ordering in builds) [11:01] cf. why that cdbs debian/control generation option is generally considered forbidden [11:03] ah [11:04] cjwatson: jtv, I still believe that 'debconf' alone might be confusing to translators when it appears in the global list of templates to translate, as there is no connection to the ubiquity source package there. jtv: I'd be more than happy to have 'ubiquity-debconf' and 'ubiquity-desktop' if necessary, but I don't see the problem in the previous name. What is confusing right now is the domain name, but if I understand it correctly, it is not releva [11:04] nt in those particular templates, so we could change the domain names to match the template names [11:04] dpm: having them match would be best from my perspective, yes. [11:07] so, jtv, cjwatson, would you agree if I do the following changes? [11:07] Template name: ubiquity-debconf (renamed from ubiquity) [11:07] Domain name: ubiquity-debconf (renamed from debconf) [11:07] Template name: ubiquity-desktop (stays the same) [11:07] Domain name: ubiquity-desktop (renamed from ubiquity) [11:08] dpm: wonderful [11:08] molt bé [11:08] thanks :) [11:09] hang on, what's the effect of changing the ubiquity -> ubiquity-desktop domain in Launchpad? [11:09] BTW I think it's a bug that 'debconf' is displayed to translators on its own without the context of the package name as well [11:09] s/is/was/ [11:10] I mean, no wonder they were confused if they weren't told what package it was in :) [11:13] Changing the domain means that the MO files will be installed with a different name. [11:14] But if this is apparently an installer thing, does that matter? [11:14] this isn't in language packs [11:14] so I assume the answer to that is roughly "what MO files?" [11:14] right, in this case they just get merged into a .desktop file [11:14] or files === ogra_ is now known as ogra [11:18] oh dear my connection is flaky today, too much rain, I guess. jtv, I'm not trying to be annoying, just checking if you had the chance to answer the last question :) [11:18] dpm: last I saw from you was "thanks" [11:19] Then from cjwatson, what's the effect of changing the domain? [11:19] yes, then I said [11:19] jtv: in that particular case, since ubiquity-desktop is not exported in language packs, there will be no effect in that, I guess? [11:19] dpm: missed that, but based on what colin says, that's right. [11:21] ok, thanks. [11:21] so those changes sound fine then; presumably translators will need to be notified again [11:22] cjwatson: yes, I have to respond the e-mail in which they were wondering about the duplicate templates, so I'll announce that there [11:23] I can do the domain name changes straight away, but for the template name changes do you think it's better if I wait until the templates have been imported, jtv? [11:24] dpm: doesn't matter. The uploads are attached to templates. They don't remember domain names as such. [11:25] jtv: that's what I meant, the domain name changes are ok, but the template name changes, can I do them straight away or better wait until the approved templates in the queue have been imported? [11:26] dpm: no need to wait. [11:26] great, thanks [11:32] * jtv goes hunter-gathering [11:35] cjwatson: and the last question on this: in the e-mail where the duplicate template was pointed out, Timo was also mentioning that there are some untranslated items. Is the next translation export scheduled, so that I could tell translators to test them? (once the templates issue has been sorted). Or would you rather prefer to have a bug filed for all untranslated strings? [11:35] https://lists.ubuntu.com/archives/ubuntu-translators/2009-September/002784.html [11:37] dpm: I *hate* *hate* *hate* combined bugs for translation issues [11:37] they're abysmally painful to deal with [11:37] good that I asked :) [11:37] one bug per problem would be easier, after somebody has confirmed that they aren't just missing translations - i.e. that the string in question is actually not translatable [11:38] we have lots of old translation bugs lying around because we haven't quite fixed one out of seven issues reported or something [11:38] it's just hopeless [11:39] ok, I'll recommend that, then [11:39] thanks [11:41] np, just so I or the other translators can figure out whether the translations do not appear simply because they haven't been exported, where is the best place to quickly track the dates in which there were translation exports? The package changelogs? [11:41] yes [11:41] great, thanks [11:41] I'd look now but I'm doing wubi testing [11:45] hmm, wubi just sits there at the end of partman for me [11:46] * cjwatson tries it not in verbose mode [11:47] ah, there we go [11:48] cjwatson: thanks for unbreaking oem-config (whereby it would go straight into oem-config rather than the preparation desktop). That one had me scratching my head a bit. [11:50] yeah, I screwed up the job a bit [11:58] evand: could you upload a new wubi soonest, please? [11:58] the current image still has grub 1.97~beta2 [11:59] ubiquity shutdown is still messy :-/ [11:59] cjwatson: very [11:59] weird. I uploaded a new one this morning [11:59] I guess it didn't pick it up [11:59] or something is still pulling the wrong version [11:59] * evand digs [12:00] flickering between desktop and shutdown text. Should xsplash take over on shutdown cjwatson [12:00] no the problem is that gdm keeps respawning [12:00] evand: was the last desktop CD build since then? [12:03] cjwatson: 20090929.1 was, yes [12:04] I don't think that's the sole cause of the problems here though [12:04] though it would impede a fix [12:29] hrm, using wubi from rookery shows grub 1.97~beta3 [12:29] * evand grabs the actual cd image [12:32] oh, I have 20090929 here [12:32] not .1 [12:32] ah, that would do it [12:34] I guess I'll rsync that quickly then [13:00] hrm, automatic-ubiquity is broken [13:01] evand1: is that what wubi uses? [13:01] yes === evand1 is now known as evand [13:10] ah, maybe it's not broken after all [13:10] ignore me for the time being :) [13:13] I think we're using g-i for amd64 netboots, it there a way to disable it? [13:13] mpt: http://people.canonical.com/~evand/screenshots/ubiquity/9.10-beta-candidate/ [13:16] ubiquity-slideshow-ubuntu: evand * r157 ubiquity-slideshow-ubuntu/debian/changelog: Use correct version number in the changelog. === jtv is now known as jtv-afk [13:47] evand, thanks -- why does not include the side-by-side option? === jtv-afk is now known as jtv [13:52] Ah, I know why I get the issue with the fonts [13:52] It happens in non-fb mode [13:52] non fb defaults to vt102 [13:53] (for TERM) [13:57] ogra: Funny, it's in that piece of code you quoted the otherday [13:58] readlink /proc/self/fd/0 returns /dev/console which d-i understands as a serial console [13:58] yeah [13:58] whyevery though [13:58] *ever [13:58] Hmm no, that's only if I break with init=/bin/sh [13:58] Bah [14:08] mpt: I'm assuming that the partition is too small to fit 2 installs side-by-side [14:09] mpt: if you would like I can take a shot that shows up as many different install methods as possible for you? [14:16] ate [14:16] oops, sorry [14:16] davmor2, thanks but no, I was just wondering why it is missing [14:17] davmor2, if it's hidden for that reason, probably there should be an explicit explanation of why it's not there [14:17] otherwise people who are expecting it will wonder why [14:18] mpt: that's what I'm assuming the issue is. But I'll be running a whole heap of installs so I can take a quick screenshot if you change your mind [14:25] mpt: I didn't have enough space on the existing partition for both. [14:26] Yay assumption correct :) === robbiew-afk is now known as robbiew [14:29] evand, would you like a bug report for explaining that in Lucid then? [14:30] mpt: please [14:30] k [14:32] ah, looks like "splash" breaks the ubiquity upstart job somehow. [14:54] evand, reported bug 438709 [14:54] Launchpad bug 438709 in ubiquity "No explanation on partitioning screen of why dual-booting option isn't available" [Undecided,New] https://launchpad.net/bugs/438709 [14:55] mpt: thanks! [15:05] casper: cjwatson * r700 trunk/ (debian/changelog scripts/casper-bottom/25configure_init): Fix tty device name construction to work with new upstart (LP: #438678). [15:07] evand: maybe ubiquity's upstart job needs to emit starting-dm [15:07] cf. recent gdm change [15:07] same for oem-config I suppose [15:09] something like http://paste.ubuntu.com/281338/ maybe? [15:09] cjwatson: cool, I'll look into that. Thanks [15:09] maybe we should turn off splash for the beta [15:09] for the live CD [15:10] yeah, ugly, but I agree [15:11] actually, let me see if this really fixes it [15:11] oddly, using break=bottom also makes it disappear [15:11] so I'll have to repack the squashfs [15:13] break=bottom kills usplash I think [15:13] so if my speculation is right, that the problem is that usplash doesn't get killed at the right time ... [15:13] ahhh [15:20] * cjwatson wonders why c-a-f1 doesn't work in wubi [15:21] while installing, I mean [15:27] it doesn't work anywhere [15:27] ogra posted a bug [15:27] bug 438678 [15:27] Launchpad bug 438678 in casper "25configure_init uses /dev/ttyN.conf instead of /dev/ttyN for /etc/init/tty*.conf mangling" [Medium,Fix committed] https://launchpad.net/bugs/438678 [15:27] cjwatson fixed it already :) [15:28] that wasn't quite what I meant though, I don't think [15:28] in this case, it simply doesn't switch away from X at all [15:28] it's not that it switches away but the command that's running is broken [15:29] which is what I'd expect from a bogus upstart job - unless upstart is taking the trouble to notice the failure and actively tear down the termianl [15:29] oh, my apologies [15:31] * ogra is confused ... [15:31] /usr/share/initramfs-tools/scripts/casper-bottom/22serialtty is clearly in the package ... buildlog and dpkg -L both agree [15:31] but i dont see it in my livefs [15:31] nor in initramfs [15:32] evand: bug 438316 [15:32] Launchpad bug 438316 in udev "hal does not properly present USB media on Acer Aspire 6930" [Undecided,New] https://launchpad.net/bugs/438316 [15:32] and i definately have the right casper version [15:33] evand: that's the info we discussed the other day regarding my usb issue.. if you have any other suggestions... or ideas [15:41] cjwatson: that indeed fixes it [15:42] rgreening: cool, I'll take a look in a bit [15:42] evand: much appreciated. you'll likely have a better idea where to go next.... more so than I [15:42] * rgreening is stumped! [15:43] ogra: lool made it executable recently in bzr; I can't immediately see a mechanism by which that would cause that particular failure, but I suppose it's possible [15:43] lool: could you do the CIA stuff in http://wiki.ubuntu.com/Installer/Development to your casper branch so that commits show up here, please? [15:43] evand: on another note, this Acer issue prompted me to buy a Dell... hahah [15:43] cjwatson, yeah, and not seeing it atm was just my stipidity [15:44] heh [15:44] *stupidity [15:44] cjwatson, i did /usr/share/initramfs-tools/scripts/casper-bottom/ ... which indeed doesnt show nonexecutable files (do'h) [15:47] ubiquity: evand * r3489 ubiquity/debian/ (3 files): [15:47] ubiquity: Emit starting-dm in the ubiquity and oem-config upstart jobs. [15:47] ubiquity: Thanks Colin Watson! [16:07] evand: can you confirm that simply removing splash makes it work ok? [16:07] cjwatson: already have [16:07] I can double-double check though :) [16:08] ok, good - slangasek sounded like he didn't want to rebuild the livefs if possible [16:08] nah, that's ok :) [16:08] okay [16:08] any idea why wubi installations often seem to hang on "Checking the installation..."? [16:09] should I upload this change to ubiquity just in case we need to rebuild anyway? [16:09] not sure offhand. [16:09] cjwatson: is that about the 7% mark? [16:09] I didn't notice it in my testing [16:10] davmor2: no [16:10] evand: might as well get it into the queue, yes [16:11] okay [16:11] it's immediately after "Computing the new partitions..." as a secondary progress message, and that progress message isn't cleared, but the progress bar sits at 100% and it says "Checking the installation..." as a primary progress message [16:11] BTW, as a general rule, progress percentages aren't necessarily all that useful - they often aren't quite the same between systems. The text of the message is more useful [16:12] you can't easily get from a percentage to the place in the code that's responsible [16:13] cjwatson: cool remember that for future reference [16:14] evand: I'm not sure it's entirely reproducible, as I've been seeing it intermittently, although more often than not [16:17] of course "Checking the installation..." is a fairly long set of steps at the start - perhaps more informative to say that it happens after guided partitioning [16:18] ah, now after rebooting into Windows and back, it works. maybe a filesystem needed checking? ugh [16:18] I imagine the lack of a vt doesn't help here [16:20] that may have been why I was pondering this, yes :) [16:20] oh well, let's see if it manages to comprehend my hacked cd [16:33] j,, [16:33] oops [16:33] hmm. I see the wubi bug. now I wonder how I fix it [16:34] oh? [16:34] when lupin-support is installed, /host isn't bind-mounted onto /target [16:34] onto /target/host that is [16:35] and so /etc/grub.d/10_lupin ignores the device [16:37] ubiquity: evand * r3490 ubiquity/debian/changelog: releasing version 1.99.27 [16:40] ah [16:41] if I'm very lucky, it's a one-liner [16:41] but a livefs rebuild, sadly [17:23] cjwatson: Sure; is there a list of packages for which we use CIA? [17:23] cjwatson: I now realize casper is an installer-ish package [17:23] there isn't [17:23] sorry [17:23] cjwatson: (You're aware we cant rebuild the armel livefses?) [17:23] yes [17:23] wubi is not used on armel, last I checked :) [17:24] casper: lool * r701 trunk/ (debian/changelog scripts/casper-bottom/22serialtty): scripts/casper-bottom/22serialtty: pass -L to getty and set term to vt100. [17:24] casper: lool * r702 trunk/ (debian/changelog scripts/casper-bottom/22serialtty): scripts/casper-bottom/22serialtty: set +x... [17:24] cjwatson: Ok; just making sure you dont rebuild all livefses or something [17:25] cjwatson: Not something you'd do, but I wasn't sure there werent other changes :) [18:12] partman-auto-loop: cjwatson * r53 ubuntu/ (debian/changelog finish.d/create_host_mountpoint): [18:12] partman-auto-loop: Bind-mount /host on /target/host during installation, to match the [18:12] partman-auto-loop: installed system after reboot (LP: #435153). [18:13] partman-auto-loop: cjwatson * r54 ubuntu/debian/changelog: releasing version 0ubuntu18 [18:15] ubiquity: cjwatson * r3491 ubiquity/ (d-i/manifest debian/changelog): [18:15] ubiquity: Automatic update of included source packages: partman-auto-loop [18:15] ubiquity: 0ubuntu18. [18:19] lool, there is a list in the filter on the cia website [18:20] (in the custom filter, not the one you get on the first page) [18:21] ubiquity: cjwatson * r3492 ubiquity/debian/changelog: releasing version 1.99.28 [18:26] ogra: Oh right [18:26] * lool would love colours [18:27] * ogra hands lool some pots with paint [18:28] I remember playing with setting up my own cia server when it was regularly going down and setting up some cute colours for committer/project etc.; it's certainly nice to have so much time on one's hands :-) === nxvl_ is now known as nxvl === robbiew is now known as robbiew-afk === robbiew-afk is now known as robbiew [21:16] evand1: hey [21:17] evand1: you know that USB issue I have? If I insert a CD and then plug in the stick it works. But I must insert a CD device first.. that is bizarre. [21:31] evand1: I've updated the bug 438316 with newer narrowed down info. Im so stumped .. haha [21:31] Launchpad bug 438316 in udev "hal does not properly enumerate USB devices unless CD-ROM inserted as first device" [Undecided,New] https://launchpad.net/bugs/438316 [22:41] davmor2: and grub.cfg? [22:43] cjwatson: that should be in the disks/boot/grub folder right? [22:44] no, it's inside root.disk [22:44] ignore disks/boot/grub, I know it's an empty directory and it's a minor wubi bug that it's still being created [22:45] under boot/grub on root.disk there is only grubenv [22:46] wuh [22:46] well that would explain the problem, but it didn't happen to me [22:46] I wonder if you have filesystem corruption [22:47] *is* there anything in /ubuntu/disks/boot/grub/ ? [22:47] no [22:47] ok, I don't know what the problem might be :( [22:48] there's no indication in the logs [22:48] I'll wipe wubi run a check on the vista fs and reinstall and see if it was just a glitch [22:49] what size is your installation? [22:49] just in case I can reproduce it with a larger installation or something [22:49] although that'll be tomorrow at this point, not today [22:50] whatever the default is I think it's 16gig [22:50] 2 ticks and I'll tell you [22:50] hmm, I won't be able to manage that here [22:51] I can do up to about 8GB [22:52] 17 gb infact [22:52] but mine is 5GB right now, and there shouldn't be any intrinsic difference ther [22:52] e [23:22] davmor2: hmm, also you can't have been seeing this problem last time because you *did* have a grub.cfg then [23:22] I dunno, wubi just anecdotally seems not very stable to me - I suspect there's some underlying kernel issue [23:22] I'll do another test with a non-hacked-up image tomorrow [23:23] cjwatson: vista sack of crap disk check utility is just finishing off after hmm 30 minutes of running so I'll be able to re run the install maybe today :( [23:37] I don't understand why it doesn't say anywhere what's needed to compile wubi [23:37] On the wiki it says to do: make prerequisites, but it doesnt work [23:37] ramvi: that's out of date documentation [23:37] What's needed? mingw32.. [23:38] I'm still getting errors [23:38] build-essential, grub-pc [23:39] evand1: thank you === robbiew is now known as robbiew-afk [23:40] evand1: Sorry to bother you, but I'm still getting the error: [23:40] sh: msgfmt: not found [23:41] make: *** [translations] Error 127 [23:41]