[05:16] c === davmor2 is now known as davmor2_lunch [13:08] :( LP doesn't like my comments... Got me to retype half a page... Third time today. [13:09] evand pls see my last couple of comments on #217348 === davmor2_lunch is now known as davmor2 [13:14] davmor2: have a new build for you [13:14] didn't have time to test it myself though [13:14] xivulon: is it the one attached to the bug report ? [13:14] wubi-selfextract.exe [13:15] might want to rename it wubi.exe [13:15] xivulon: yes I'll try it in a bit I got a few things going on today but I'll let you know as soon as I've tested it. [13:15] try it first standalone, you should see a small dialog with progress bar, then wubi [13:15] np [13:17] incidentally upx didn't work because the unpacked copy is not bit identical to the initial file, and nsis uses CRC check which will obviously fail [13:17] the new one uses 7z for packaging [13:18] xivulon, what happened to your comment exactly? Did Launchpad give you an error message? [13:19] mpt, that happens very often when I take some action such as adding a comment or editing a bug properties. I think the error is cannot show the page. [13:19] I will pay close attention next time [13:20] thanks, even a screenshot of the error would help [13:20] (if that's easier than transmitting the text) [13:21] ha got it again [13:21] Cannot find server or DNS Error [13:24] might be our network/proxy [13:26] mpt http://paste.ubuntu.com/9180/ [13:31] You're using Internet Explorer!!! [13:31] There's your problem ;-) [13:33] hehe like I have a choice in the matter :( [14:16] xivulon: ok, I'd like to see more testing (no response from #ubuntu-testing, unfortunately, but I'll give it a go after my OpenWeek session today) [14:17] Once you, davmor2 and myself have tested it, we can start the SRU process [14:17] err s/more testing/testing/, since the patch has changed. [14:43] evand, in the last comment I suggest using find --set-root --relative to set both root partition and relative path [14:43] as opposed of only setting the relative path using: root ()/relative/path [14:43] as suggested previously [14:43] but... [14:44] find --relative requires a new grub4dos, which is not yet in wubi (I am waiting for them to upload onto SVN first) [14:44] ah, ok [14:44] root ()/relative/path [14:44] ^ seems to work by the way [14:45] and it does not require a new grub4dos, I have been suggested that to people with drive order problems and nobody complained so far ;) [14:46] ok, but --set-root --relative is the route you'd like to take, correct? [14:47] it is more general, being egoistic, root ()/relative/path is perfectly adequate for wubi, but it assumes that root has already been set beforehand [14:47] so it is wubi-specific (and do not think cjwatson would like that) [14:48] right, so lets go with the more general solution. [14:49] yep, hopefully I will have the new grub4dos code soon [14:51] indeed, keep me posted and we'll get it tested and in the archive. [15:25] evand: any luck with #222690? [15:25] I asked the users to try to sanitize the os_prober output http://ubuntuforums.org/showpost.php?p=4843938&postcount=47 and installation does go through (even though the guy that tested that had rebooting problems) [15:31] some luck [15:31] even with set -x shoved in there, I'm not entirely sure what the problem is and why it would fail with accented characters. [15:32] At any rate, using expr isn't ideal for that and I've replaced it with something more sane in trunk. [15:40] unfortunately, I cannot reproduce the bug myself and replacing os-prober with a shell script that outputs an accented character in the line does not reproduce the bug. [15:41] yay rendundancy [16:23] evand I think that the expr match fails [16:23] you can use http://paste.ubuntu.com/9227/ to reproduce [16:23] and instead of os-prober you can feed some line with UTF-8 chars [16:25] That's essentially what I did, and it did not reproduce the bug. Did it for you? [16:25] As I said above, I replaced the expr match with something slightly more sane, so if that is indeed the problem, it should be fixed in trunk, but I'd first like to get a better handle on why it's failing in the first place. [16:28] yep saw the code, loc="${line%%:*}" makes sense [16:28] I didn't try to trigger an error, since I am not on linux at the moment [16:29] but I would expect $(expr match "$line_with_unicode" '\(.*\):.*:.*:.*') to fail [16:29] I wonder if it's actually non-UTF-8 data [16:30] in the case of the chaps it's an accented capital E [16:30] Edicion in french [16:31] I bet there's a file in the Windows filesystem with that text in non-UTF-8 form [16:31] try running the text through 'iconv -f UTF-8 -t ISO-8859-1' before you feed it to os-prober [16:32] that would make sense... [16:32] and it explains why evan cannot reproduce [16:32] if you know the filename os-prober scans I can have them to upload [16:35] guessing encoding of arbitrary data is basically impossible (at least in the worst case) but os-prober should at least cope with non-UTF-8 data somehow; that said heuristics are sometimes possible [16:35] beware that d-i doesn't have iconv [16:37] is sanitizing unproper chars as opposed to converting them an option? It was tested and it works [16:47] sanitising how? [16:47] I mean, sure, you can drop anything that isn't valid UTF-8 data [16:48] it'll look pretty poor though, so if heuristics are possible that would be better [16:50] yep I intended to drop/replace unconvertable chars as a safenet if proper conversion is not possible [17:09] such safenet should be added anyway (and should already produce a fix for 222690) [17:09] is there any reason/use to pass raw uncovenrted chars? [17:10] I don't quite understand what/why you're asking [17:10] that the string should first go through convet_to_unicode(raw_str) and then through sanitaize(str) [17:11] I'm afraid I'm not familiar with those functions [17:11] you can't "convert a raw string to Unicode" [17:11] just made the name up [17:11] there is no such function with only that input [17:11] you need to know the source encoding as well [17:11] in this case it happens to be ISO-8859-1 (I'm guessing), but in general there is no way to tell [17:12] well in our case we do not know right? so the convert_to_unicode has to use heuristic (I assume) [17:12] so, yes, you want "Windows XP Édition familiale" to show up that way in the boot menu rather than as "Windows XP dition familiale" as it would be if you just dropped the character [17:12] that said, I'm not sure whether grub will display UTF-8 text (this isn't me saying it doesn't, I just don't know) [17:13] yes I am saying we can add the sanitize(str) function immediately, and worry later about convert_to_unicode() [17:13] there is a decent chance that if you pass "Windows XP Édition familiale" to grub (as UTF-8) then it will show up as "Windows XP Ã�dition familiale" in the boot menu [17:13] so somebody needs to test this [17:14] the safest approach is to make the change at the migration-assistant/ubiquity level, but to leave os-prober's output just the way it is [17:14] IMO [17:14] then we're leaving the boot loader menu the way it is too [17:14] that's more than good enough :) [17:14] and worst case the output looks a bit wrong in the installer, but nobody will care after the installer's finished [23:22] evand https://bugs.launchpad.net/wubi/+bug/217348/comments/9 [23:22] this is wubildr including new grub4dos patches for relative-path in find [23:23] I have also asked #ubuntu-testing to give it a go