[00:39] cjwatson, I am seeing a few reports about problems creating swap file [00:41] might be some regression in 222546, I tried to contact lamont, could you maybe remind him to have a quick look? [08:32] did you plan to get new debian-installer to Rosetta still with the "removes / installs" string translatable still? [08:32] (not seeing anything in the import queue) [11:45] Mirv: I'm on holiday, but I'll see what I can do; I think it's ... optimistic to hope for new translations of that to be imported for jaunty mind you [11:46] * cjwatson runs 'installer-po-update jaunty' [11:48] Hmm I see a warning during install that isn't translated, should I be worried? [11:48] It's the "The installer currently runs from partition foobar" warning above the partitioning screen in ubiquity [11:48] lool: French? [11:48] Yes [11:49] lool: exact string? [11:49] is it "Your installation medium is on ..."? [11:49] Something like that [11:49] I need to reproduce to tell you, will take me some time to reach that screen [11:50] lool: it just wasn't translated into French when I last did an import [11:50] it's in the .po file with an empty msgstr [11:50] Oh ok [11:50] Well so is life then [11:50] I can go and translate it I guess [11:51] it was a late string addition [11:52] cjwatson: FYI I filed a bug on broken window icon in ubiquity [11:52] I couldn't blame it on a recent ubiquity change though [11:52] But I think we want to fix this for release [11:53] cjwatson: Yes, it was the Your installation medium string [11:55] Anyway, enjoy your deserved long week end :) [11:57] broken window icon> *blink* didn't think we'd changed anything there, indeed ... [11:58] but yeah, unlikely to look at it today :) [12:27] cjwatson: password weak buttons make a lot more sense now :) [12:27] good, thanks [12:28] Mirv: should be in the import queue or imported now [13:01] lool: debian-installer failed to build on armel [13:03] Crap [13:04] cjwatson: Shall we revert that change immediately or do I have time to look into it? [13:04] I think you have time to look into it [13:10] lool: I think the problem may be that KERNELNAME is not set correctly for imx51 [13:11] oh, and that was what you changed [13:11] Yes [13:11] KERNELNAME must match what's in the kernel .deb [13:12] so you can't unilaterally change this in d-i - if you want to change the filename, that has to be done in the kernel [13:12] cjwatson: I copied KERNELNAME = vmlinuz from lpia, and thought it was ok [13:12] (which will mean it'll conflict with other kernels doing the same thing, etc.) [13:12] I think it's KERNELVERSION being incorrect [13:12] Oh I see [13:13] hm, that's odd, lpia has a versioned vmlinuz in its .deb too [13:13] have you read the documentation? [13:13] KERNELVERSION [13:13] The version of the kernel .udeb package, like "2.4.26-r4k-ip22" [13:13] I'm reading it [13:13] KERNELNAME [13:13] The full name of the kernel image. If you build an EXTRA target (e.g. [13:13] for a driver floppy), this variable has to be empty. [13:14] I'd rather stick to what lpia and i386 do, even if that seems to contradict the recommendations of the docs [13:14] you might be right that KERNELVERSION is wrong [13:14] ... except it isn't [13:14] armel/imx51.cfg sets it correctly [13:15] armel has SUBARCH, but not lpia [13:15] you can't easily compare across architectures unfortunately [13:15] the different variables interact in subtle ways [13:16] oh, I have an idea [13:17] Did you find where lpia was being renamed? I didn't so far [13:17] it isn't being renamed, in d-i [13:17] you need to look at the kernel-image udeb, not at the linux-image deb [13:17] ahhhh [13:17] lp_archive@cocoplum:/tmp/cjwatson$ dpkg -c /home/lp_archive/ubuntu/pool/main/l/linux/kernel-image-2.6.28-11-lpia-di_2.6.28-11.41_lpia.udeb | grep /boot/ [13:17] drwxr-xr-x root/root 0 2009-04-08 06:20 ./boot/ [13:17] -rw-r--r-- root/root 2810416 2009-04-08 06:20 ./boot/vmlinuz [13:17] -rw-r--r-- root/root 1225020 2009-04-08 06:20 ./boot/System.map [13:17] lp_archive@cocoplum:/tmp/cjwatson$ dpkg -c /home/lp_archive/ubuntu/pool/main/l/linux/kernel-image-2.6.28-11-imx51-di_2.6.28-11.41_armel.udeb | grep /boot/ [13:17] But we're past kernel freeze [13:17] drwxr-xr-x root/root 0 2009-04-08 12:13 ./boot/ [13:17] -rw-r--r-- root/root 1005417 2009-04-08 12:13 ./boot/System.map-2.6.28-11-imx51 [13:17] -rw-r--r-- root/root 1949080 2009-04-08 12:13 ./boot/vmlinuz-2.6.28-11-imx51 [13:17] I *think* there's going to be one last upload [13:18] It's my impression as well, but that's quite a bet :) [13:18] the place where this is controlled is in debian/d-i/kernel-versions.in [13:18] I'll find out in the release meeting [13:18] the last field [13:20] see kernel-wedge/REAMDE [13:20] README [13:20] in the meantime, I'll revert that d-i change so that it can build [13:22] debian-installer: cjwatson * r1085 ubuntu/ (build/config/arm.cfg build/config/armel.cfg debian/changelog): [13:22] debian-installer: Revert arm KERNELVERSION change for now; this needs to be done in sync [13:22] debian-installer: with a change in debian/d-i/kernel-versions.in in the kernel. [13:23] So -.+ has a special meaning in this file, but "-" alone doesn't mean anything [13:23] However an empty value like on lpia doesn't seem to be a good idea [13:23] debian-installer: cjwatson * r1086 ubuntu/debian/changelog: releasing version 20081029ubuntu33 [13:23] what would be wrong with "-"? [13:24] that makes it impossible to build multi-subarchitecture images - but we never try to do that anyway [13:24] indeed, "-" would be my recommendation [13:24] unless you're seeing something I'm missing [13:24] I didn't say there's anything wrong with -, it's what we should use (or n or anything really) [13:24] Just not y or -something [13:25] I'm saying the lpia line doesn't look good [13:25] oh, I see what you mean, lpia actually leaves out the field [13:25] Because it doesn't even have the - [13:25] Yes [13:25] as it happens, that's harmless [13:25] Hmm I wonder why tabs work [13:26] the reason "-" is there is that there's space for a build-dependency field after that, which is used when udebs are being built outside the kernel packaging [13:26] I think it would cause a perl warning in kernel-wedge if it were to use these [13:26] why so? [13:26] (Hmm it does, perhaps in strict mode then :) [13:27] cjwatson: Because $suffix would be undef and it's used in tests [13:27] Ah the split with 6 probably avoids that; damn I'm at bad perl [13:28] Anyway, will recommend moving from y to - [13:28] cjwatson: Only imx51? [13:28] no, split(,,6) doesn't avoid that. In fact it probably will generate a warning, but will continue successfully anyway [13:29] we should do it consistently for all subarchitectures, for minimum confusion [13:29] Ok [13:29] well, the only concern is whether booting will still work [13:29] if you want to minimise retesting time, then just imx51 [13:29] We need to test all anyway [13:30] ok [13:30] (Why wouldn't booting work?) [13:30] bootloader configuration would need to point to the right kernel ... [13:30] anyway, off to do housework [13:30] Indeed [13:31] cjwatson: What about -imx51? [13:31] Sorry, that was stupid [13:36] Actually it wasn't [13:37] cjwatson: Using -imx51, -ixp4xx etc. would allow us to do multi-flavours images in the future if we ever needed to (which was actually an idea we had for a single armel livefs) [13:37] So there's the same risk of regressions, but we only lose the possibility of having different kernel versions for the same arch [13:38] or subarch [13:42] lool, The trick is that one needs to mangle the image to make the multi-flavour image bootable on the target flavour. [13:43] Probably saves space over pushing images for each flavour to cdimage, but still. [13:43] persia: It's already useful if we can do a single buildlive and host a single livefs for all flavours [13:44] /lib/modules/* aside, yes. [13:44] nevermind: seems we already have cooperative kernels. [13:47] I had the /vmlinuz link in mind personally [13:47] Bug #359049 [13:48] Launchpad bug 359049 in linux "imx51 udeb hardcodes linux version in vmlinuz binary name" [Undecided,New] https://launchpad.net/bugs/359049 [13:49] Um, images for *every* arch are built on cdimage.ubuntu.com. MInd you, the live images for some arches fail so miserably that they are commented out (I think). [13:50] But anyway, I think vmlinuz-2.6.28-11-imx51 maps nicely to vmlinuz-2.6.28-11-generic, and that it's just the target of the symlink that needs changing. [13:50] Although your option D sounds interesting. [13:52] It might be interesting to check the ports kernel udebs, and see what happens there as well. [13:52] I'd think powerpc would be the most interesting, as we do two flavours of powerpc images. [13:53] persia: There's no vmlinuz-2.6.28-11-generic currently [13:54] PPC doesn't change anything, because the two flavours are in two images [13:54] It's only of interest when we want to build a single image with a single livefs, but booting two kernels [13:54] Hrm. [13:54] ps3 has a different livefs [13:55] * persia blesses d-i for supporting emacs keybindings [13:55] Full images for every arch are built on cdimage, but d-i images are built by debian-installer [14:09] lool, I see the issue now. I agree that it's a bug. I'm not sure which of option B or option D is correct, although I still prefer option D. [14:09] s/B/C/ [14:11] I fear that changing linux + d-i + cdimage is too much before release [14:13] I share your fear. The risk of having d-i not work during this time of greatest testing is too high. [14:39] lool: up to you [14:39] I'm about to go out to church so don't really have time to think about it now [14:40] "-imx51" as the suffix sounds pretty reasonable to me [14:40] livefses are not directly relevant here since we're talking about the udebs [14:50] I think I'm going to recommend only renaming imx51 to -imx51 or not doing anything this cycle [14:51] Based on the fact that probably all flavours except imx51 and perhaps versatile will be dropped next cycle [16:06] cjwatson: So we don't touch anything and we keep the names with the version for jaunty [16:08] cjwatson I will be away next week, I am not aware of any annoying bug left (there are a couple of ui glitches only), feel free to send me an email if anything turns up [16:08] r120 is the one that should be used [17:16] lool: ok [17:26] cjwatson: wubi-r120.exe works very well infact :) [18:57] cjwatson: while fixing the bug, I think I have found another (not cause by me). .. I run ubiquity (kde or gtk one...doesn't matter) and even though I select "No" to unmount my current disk, that disk still shows up as both the resize choice and the use entire disk choice...I am thinking that is not the desired behavior..?? [19:13] cjwatson: lp:~shtylman/ubiquity/autopartition <-- fix for the partition bug, I want to do some more cleanup to make the kde side match the gtk side a bit more, but I went ahead and pushed that branch for the bugfix [19:23] shtylman: did you make a change to the colour of the default kubuntu partition? [19:23] davmor2: not exactly sure what you mean...but no...not that I am aware of... (change from what version?) [19:23] shtylman: the grey that is currently displayed makes it look like an empty drive. [19:25] Daviey: I see...what would you recommend? I can change it very easily... [19:26] davmor2: ^ my bad [19:26] shtylman: ubuntu got changed to orange so the obvious would be blue [19:27] davmor2: ok...you don't happen to know the rgb? for that blue do you :) [19:29] shtylman: rgb or html code? [19:29] davmor2: either or...they are the same [19:29] try 1125e7 see what you think [19:30] shtylman: it might be a bit dark [19:35] davmor2: seems a bit off...I will ask in the kubuntu-devel channel for the official color...I am sure someone knows... [19:36] shtylman: probably a better move :) [20:42] for those interested, here is the latest design of the time zone map http://sinecera.de/time_zones.png ...not signed off yet though [21:06] kwwii: nice [21:13] I like that, kwwii [21:19] thnx, hopefully that will be accepted and included in jaunty :-) [21:26] shtylman: mm, it's sort of questionable because if the mounted filesystem is something other than the installation medium (which it must be, I think, otherwise you wouldn't see this behaviour) then the user might well choose to unmount it [21:26] shtylman: I don't think I'll risk changing this for jaunty, but do file a bug on partman-base with more details if it bothers you [21:28] cjwatson: will do...my only concern was that even though I said no to unmount, it seems like the installer will install onto my main disk. This was not how it behaved before and would never use the main disk that currently has root on it [21:29] well, it doesn't do anything unless you tell it that it can [21:30] this was a response to a number of other bugs and the balance is rather delicate, which is why I don't just want to go ahead and fix it [21:30] happy to review it for karmic [21:30] cjwatson: I understand...so what will happen if I proceeed with the install even though I didn't unmount? will it install over or error out? [21:31] it'll change the partition table and then error (unfortunately) [21:31] you should use manual partitioning if you don't like the available automatic choices [21:32] shtylman: the resize choice is known to only offer one disk, but surely the "use entire disk" choice should have a drop-down or radio button or something that lets you pick a disk [21:33] thanks for the branch; I'll merge that now [21:33] ubiquity: cjwatson * r3210 ubiquity/ (debian/changelog ubiquity/frontend/kde_ui.py): merge from lp:~shtylman/ubiquity/autopartition [21:34] cjwatson: right...ok, cool, I guess it will be something to think about for karmic [21:34] shtylman: assuming that you have more than one disk in your test setup, does the "use entire disk" option let you select a disk in Kubuntu? [21:35] cjwatson: yes [21:35] ok, phew [21:35] that's something, at least [21:35] cjwatson: currently it uses radio buttons like we did before, but I think I might change it to drop down like in the gtk one, thoughts? [21:35] cjwatson: yea...I make sure to test in virtual machines with many disks to try and catch weird outlying behaviors [21:36] the change to drop-down was to work better with smaller screen sizes [21:36] as I figured [21:36] so up to you but generally consistency between the frontends seems like a good idea, unless local HIGs say otherwise [21:36] IMO [21:36] I wouldn't change it for jaunty though [21:37] thats why I asked...probly a bit late in the game for such a change [21:37] kwwii: so is this purely colour changes? [21:38] kwwii: any chance I could have a branch with updates to the images in pixmaps/timezone/ in lp:~ubuntu-installer/ubiquity/trunk ? [21:38] I've not touched this before and Evan is away ... [21:39] cjwatson: yes, these are color changes and some slight tweaks to the local time overlay (the placement of the dot in respect to the box and the exact color of the box as well as, if it is not hard to do a slight shadow behind the box [21:39] cjwatson: sorry to bug you on a holiday but this was important to me [21:40] this version is my design so I want to wait until mark signs off on it. I sent him an email earlier this evening [21:40] kwwii: I haven't touched this code *at all* and really have no clue how to do so - I'm happy to merge a branch but can't realistically do it myself [21:40] I think I will go ahead and make the 30 or so pics in case he does [21:40] (plus this is the main religious holiday of the year, I'm definitely not doing any serious work even if it is a Mark request) [21:41] well, I made the last pics and I assume that just updating them would be enough...I can look at the stuff in bzr and figure that out pretty easy [21:41] cjwatson: right, that has been quite hard for me to explain to my wife as well [21:41] just updating the pictures should be fine for the colours; the box stuff requires code [21:42] I might look into the cairo code to see how he is offsetting the dot...it is probably not rocket science and I've seen this stuff before...maybe I can be of help in that respect as well [21:42] it's in either ubiquity/frontend/gtk_ui.py or ubiquity/segmented_bar.py, probably spread across both [21:43] or offsetting the box, as the case may be [21:43] oh, or else ubiquity/timezone_map.py [21:43] right, look for "def do_expose_event" in the latter [21:44] and "def rounded_rectangle" in ubiquity/segmented_bar.py, would be my guess [21:44] excellent, thanks for the help [21:44] is there some easy way to build this and test it? [21:45] TBH the easiest way by far is to boot a live CD and make the changes on the fly (in /usr/lib/ubiquity/) before starting the installer [21:45] I can do a lot of stuff, but it has been a while since I built a whole distribution :p [21:45] since it's all Python that's a lot easier than building yourself a custom live CD [21:46] I think Evan actually makes most of his code changes that way and then copies them out, which does occasionally mean he loses stuff when his live CD crashes ;-) [21:46] so if I boot into it and make the necessary changes before starting the install process it will apply without any extra effort? [21:46] lol, I can imagine [21:46] that's the same way i make changes too, but i've learned to scp it out regularly when possible [21:47] in this case, it is the perfect way to test these changes without bogging down in extra work [21:54] I make the changes outside and then copy them in, largely [21:54] kwwii: without any extra effort> right [21:55] kwwii: if you need to test how it looks in "Install Ubuntu" mode as well, running 'ubiquity --only' from the command line is a not entirely terrible approximation [21:55] cjwatson: excellent, thanks for the info and sorry again for interupting good friday...it would be a really good friday if mark replied and said he liked it :p [21:55] should at least deal with fullscreening it, anyway [21:56] kwwii: but that would be convenient ;-) [21:56] it's not your fault, I know [21:57] kwwii: fortunately (from your POV) there are a couple of other changes we need to make to ubiquity anyway before release, so there is an opportunity for piggybacking [21:57] great. I will work on making the pixmaps tonight and then on the other bits tomorrow [21:57] cjwatson: that is the best news all day :) [21:58] I have found that mounting my non-virtual drive in ssh in the live environment and the making symlinks works great to prevent data loss :) [21:59] I assumed I could make a backup, then change things, see if it worked, do a diff if it does, copy that to a USB stick, apply it to my bzr branch [22:00] erm, well, pixmaps don't diff well [22:00] but you get the point [22:00] are the pixmaps UU encoded or such? [22:01] guess not [22:03] no, just plain png files [22:03] I assumed you'd want to change the pixmaps outside the live environment anyway, to save you having to install your favourite image editor inside the live CD [22:03] it'd probably be a lot faster [22:06] cjwatson: right, that was a stupid question and I would have figured it out myself anyway...thanks for the all the info and help. I will be in touch :-) [22:24] cjwatson: you going to UDS? [22:25] yes [22:25] cool === mpt_ is now known as mpt