[03:43] <shtylman> ev: I am not able to reproduce bug 556376
[03:44] <shtylman> maybe I don't have a steady enough hand :p
[03:44] <shtylman> I thought you said the problem was during the actual system install?
[09:05] <ev> shtylman: just use alt-f or enter to navigate :)
[09:35] <CIA-3> ubiquity-slideshow-ubuntu: evand * r267 ubiquity-slideshow-ubuntu/ (252 files in 5 dirs): Update translations from Launchpad.
[09:46] <CIA-3> ubiquity: evand * r4047 ubiquity/ (3 files in 3 dirs):
[09:46] <CIA-3> ubiquity: Only show the update link and release notes when a critical update
[09:46] <CIA-3> ubiquity: is available (LP: #554570).
[09:46] <CIA-3> ubiquity-slideshow-ubuntu: evand * r268 ubiquity-slideshow-ubuntu/debian/changelog: releasing version 21
[10:23] <amichair> hi cjwatson
[10:36] <cjwatson> oh, hi
[10:36] <amichair> I didn't realize ubiquity had it's own channel :-)
[10:37] <cjwatson> well, the installer in general, but yeah
[10:37] <amichair> isn't ubiquity == installer?
[10:38] <cjwatson> ubiquity is the desktop CD installer - there's also debian-installer, which it's based on, and which is used on the alternate and server CDs
[10:40] <amichair> oh, good to know
[10:40] <amichair> cjwatson: I'm going over the contributions page thing as you suggested
[10:40] <amichair> never heard of it before (and I did contribute to software-properties, jockey, kubuntu-notification-helper, etc.)
[10:41] <cjwatson> sometimes people are a bit slack :-/
[10:42]  * ev coughs, hides
[10:43] <amichair> cjwatson: btw why is copyright assignment necessary? doesn't gpl give all rights without touching on copyright assignment?
[10:43] <amichair> all freedoms, that is
[10:44] <cjwatson> not if you're in the position of trying to enforce the copyrights against infringement
[10:45] <cjwatson> (unfortunately ...)
[10:48] <amichair> cjwatson: I'm not sure what that means (patents?), but I sent u the agreement as requested :-)
[10:49] <cjwatson> thank you!
[10:49] <amichair> cjwatson: Anything else before we get to the fun stuff?
[10:49] <cjwatson> if you have to claim copyright infringement in court, in some jurisdictions, you have to have "standing", which can end up meaning going around collecting all the copyright holders before you can start
[10:50] <cjwatson> IANAL, that's my understanding
[10:50] <cjwatson> nope, all good ... let's see, there was one comment on your branch last night
[10:50] <cjwatson> shtylman said "the progress bar width is unbounded, which means the progress bar might expand/contract with different text ... which looks weird from a ui perspective"
[10:51] <amichair> cjwatson: which progress?
[10:52] <amichair> the first or the second? btw do u have terminology for the first phase/window vs the second?
[10:54] <cjwatson> that's all he said, I'm just relaying :-)  shtylman's on US East Coast time, should be up in a few hours
[10:54] <amichair> oki
[10:54] <cjwatson> not really, we talk about the "install progress bar" sometimes
[10:54] <cjwatson> versus the bit where we ask questions. :-)
[10:54] <amichair> maybe configuration vs installation or something :-)
[10:55] <cjwatson> or copying, since that's most of the second stage
[10:56] <amichair> both progress bars take up the full width they're allotted, I haven't seen them shrink nor expand just stay fixed
[10:57] <amichair> but then I'm not too familiar with Qt layout idiocyncracies
[10:58] <cjwatson> nor I, so I hope shtylman will expand on his comment
[10:58] <cjwatson> 21:13 <shtylman> other than that.. it seem ok
[10:58] <cjwatson> 21:14 <shtylman> the ui can be tweaked later if needed
[10:58] <amichair> or shrink!
[10:59] <amichair> (sorry, just woke up - my sense of humour doesn't kick in for a couple more hours)
[10:59] <cjwatson> so I'm going to go ahead and merge this for now for post-beta-2, it seems like a net plus and nobody emitted any major screams
[10:59] <CIA-3> tzsetup: evand * r517 tzsetup/ (debian/changelog tzsetup):
[10:59] <CIA-3> tzsetup: Add a 15 second timeout to the wget of geoip.ubuntu.com
[10:59] <CIA-3> tzsetup: (LP: #556890).
[11:00] <cjwatson> it would be great if you could try to keep an eye on new bugs arising from it, but we'll try to let you know if anything seems to regress that's traceable to this branch
[11:00] <amichair> cjwatson: ok, though I don't mind waiting for shtylman and fixing up some more
[11:00] <cjwatson> we can always merge again
[11:01] <amichair> cjwatson: general q, it looks like there's a whole lot of open issues, what ur policy on triaging/testing/fixing?
[11:01] <cjwatson> if you're planning to stick around, after you've been around for a while, we can give you direct commit access
[11:01] <cjwatson> fix as much as possible as quickly as possible? :-)
[11:02] <cjwatson> ubiquity is a bit of a bug magnet because nearly everybody uses it and it has a lot of weird cases
[11:02] <cjwatson> we've been trying to move to pychecker/pyflakes to avoid the more embarrassing errors, but are not quite at the point where we can run them automatically and enforce passes
[11:02] <amichair> cjwatson: yesterday I had the unfortunate experience of trying to install a new kubuntu system with a beta1 live cd. Even using all defaults, it crashed before completion. Hence the question about testing policy, if any...
[11:03] <cjwatson> automatic system testing is fundamentally a bit tricky, although I believe ev had made a start on a test suite
[11:03] <cjwatson> I would dearly love us to be doing better here, but we aren't right now
[11:03] <ev> indeed.  I hope to make progress tomorrow and get that landed by the weekend.
[11:04] <cjwatson> ooh, that close?
[11:04] <amichair> I'm not even referring to unit/auto testing... a standard install, with all default settings, crashed consistently...
[11:04] <cjwatson> also, the closer the GTK and the KDE frontend code can be made to be, the less likely we are to have bugs
[11:04] <amichair> the kubuntu oem doesn't complete either (as of yesterday's daily, I believe)
[11:04] <cjwatson> amichair: all images are smoke-tested and Kubuntu beta-1 did pass that level of testing - I assume it must have been due to some variation that wasn't picked up in smoke-testing
[11:05] <amichair> pressing the skip button crashes the gui as well... it's pretty basic stuff
[11:05] <cjwatson> I was actually in the middle of a Kubuntu OEM run so that I could fix that
[11:05] <amichair> anyway, lucky for everyone, I try not to complain (well just a little), but to fix :-)
[11:06] <CIA-3> ubiquity: cjwatson * r4048 ubiquity/ (5 files in 5 dirs): merge lp:~amichai2/ubiquity/fixes
[11:06] <CIA-3> tzsetup: evand * r518 tzsetup/debian/changelog: releasing version 1:0.26ubuntu7
[11:06] <cjwatson> part of the problem has been that KDE frontend maintenance slipped a bit this cycle, and so it got out of sync with GTK in a few places
[11:06] <amichair> is there a special bot in this channel?
[11:07] <cjwatson> we need to get more of the KDE frontend components moved into the plugin structure so that it's easier to maintain stuff in one place
[11:07] <cjwatson> yes, http://cia.vc/, https://wiki.ubuntu.com/Installer/Development
[11:07] <cjwatson> https://wiki.ubuntu.com/Installer/Development#IRC%20notification indeed
[11:08] <amichair> I see the common backend withe different frontends design, which is pretty sound on its own too
[11:09] <amichair> (some other utilities really lack it)
[11:10] <amichair> cjwatson: as for the oem install, I couldn't reproduce riddell's reported error, but instead I got stuck in a loop (installer seems to end, restart, and installer starts anew)
[11:11] <amichair> btw I'm doing all my testing on a virtualbox for now, if it makes a difference
[11:15] <cjwatson> I normally use kvm
[11:32] <CIA-3> ubiquity: evand * r4049 ubiquity/ (debian/changelog ubiquity/components/ubi-language.py): Fix backing up to the language page in the KDE frontend.
[11:48] <CIA-3> ubiquity: cjwatson * r4050 ubiquity/ (86 files in 4 dirs):
[11:48] <CIA-3> ubiquity: Update handling of "Ready to install" etc. templates to account for the
[11:48] <CIA-3> ubiquity: removal of the separate welcome page.
[11:55] <amichair> cjwatson: going over the docs... the readme discusses backporting in 6.06/6.10/7.04, perhaps this should be updated with newer releases, or removed altogether?
[11:55] <ev> heads up: bug 557210
[11:56] <cjwatson> amichair: maybe, not a high priority though :-)
[11:56] <amichair> cjwatson: nope :-)
[11:57] <amichair> I just call'em as I see'em :-)
[12:15] <CIA-3> ubiquity: cjwatson * r4051 ubiquity/ (debian/changelog ubiquity/frontend/kde_ui.py):
[12:15] <CIA-3> ubiquity: * KDE frontend:
[12:15] <CIA-3> ubiquity:  - Hide install_process_label ("installation process") and
[12:15] <CIA-3> ubiquity:  breadcrumb_install ("Install") when running as oem-config; providing
[12:15] <CIA-3> ubiquity:  alternative strings would break string freeze, and the UI should look
[12:15] <CIA-3> ubiquity:  OK without them (LP: #540929).
[12:26] <CIA-3> ubiquity: evand * r4052 ubiquity/debian/changelog: Add LP bug reference.
[13:05] <CIA-3> ubiquity: evand * r4053 ubiquity/debian/ (changelog ubiquity.templates):
[13:05] <CIA-3> ubiquity: Bring back the debconf translation for password_extra_label. The
[13:05] <CIA-3> ubiquity: KDE frontend still uses it (LP: #557192).
[13:11] <CIA-3> ubiquity: evand * r4054 ubiquity/ (3 files in 3 dirs):
[13:11] <CIA-3> ubiquity: Fix a small typo that was preventing the duration string on the
[13:11] <CIA-3> ubiquity: language page from being translated (LP: #551633).
[13:36] <ara> cjwatson, new logs attached to bug 556555
[13:41] <shtylman> amichair cjwatson: I was referring to the progress bar at the top of the window when going through the steps. It's width is now unbounded and I wasn't sure what that would mean when you started setting and changing the progress text
[13:42] <shtylman> its possible that it will just pick the first width it starts with, but I think that the width needs to be smaller... otherwise the progress bar is too wide which looks weird imho
[13:42] <shtylman> thats all I was referring to
[15:43] <amichair> shtylman: hi there
[15:47] <shtylman> amichair: howdy... thanks for fixing those bugs :)
[15:47] <amichair> shtylman: same to u (times 100?)
[15:47] <shtylman> heh
[15:48] <ev> mpt: http://people.canonical.com/~evand/tmp/timezone-map-10.04.png
[15:49] <amichair> shtylman: 'when going through the steps' is the preparation stage or installation stage?
[15:51] <amichair> or shall we call them "first" and "second" progress bars
[15:53] <amichair> or in other words, can u explain the potential bug scenario?
[15:55] <shtylman> amichair: the progress bar at the top of the preparation stage
[15:56] <shtylman> the one that comes and goes
[15:56] <shtylman> I noticided that its width was changed? correct?
[15:56] <shtylman> and was just wondering how not having a fixed width set would affect its size when the progress text is changed
[15:57] <shtylman> from a gui perspective... it would be nice if the width was always the same (aka fixed width)
[15:58] <amichair> shtylman: yes, it was a bit under half of the window width, and some of the text didn't fit it, so I made it full window length (like the second progress bar)
[15:58] <amichair> shtylman: did u see it not in full width? to my understanding, it exapnds to occupy all available space (which is entire width minus skip button when it is shown)
[15:59] <amichair> in my testing at least, the width remained fixed
[15:59] <shtylman> amichair: full width minus the "installation process" text?
[16:00] <amichair> shtylman: there's installation process text, then a small spacer, then progressbar, then optionally skip button
[16:00] <shtylman> my main concern is that the progress bar is too big and distracting in that case... maybe not tho
[16:00] <shtylman> thats why I limited the size last time... I didn't want it to distract the user too much
[16:01] <shtylman> imho some of the progress text could be made shorter maybe? cause often it may go away before you can even read lots of text
[16:02] <shtylman> but this is something that can be explored later too see what balance of size can be achieved
[16:03] <amichair> ok
[16:03] <amichair> I don't think distracting is a problem, since it's there for the user to look at
[16:04] <shtylman> gotcha
[16:04] <amichair> and I think it's a bit more consistent with the later progress bar 'feel'
[16:05] <amichair> as a matter of fact, i would be nice if the installation phase was not a separate window but the last page in the same preparation window (and without a few seconds of no window in between)
[16:05] <amichair> but that's probably a much bigger change
[16:06] <shtylman> amichair: I have toyed with that idea and the real problem there is informing the user that they are in a live environment and can minimize at an time
[16:06] <shtylman> amichair: I might give that idea a try this weekend
[16:06] <shtylman> it could look quite nice imho
[16:06] <amichair> then they can share the window, progressbar, look-and-feel - I think it's a much smoother experience
[16:06] <shtylman> right
[16:07] <amichair> perhaps it's possible to pop a little bubble near the minimize button saying as much, when the last installation phase is started?
[16:08] <shtylman> amichair: indeed... that may be possible
[16:08] <shtylman> another idea is to ignore that "problem"
[16:08] <shtylman> the user might eventually mouse over that icon
[16:08] <shtylman> and minimize anyway
[16:08] <amichair> I don't remember, does it have a tooltip?
[16:08] <shtylman> iirc the first slideshow page says something about being able to use the live cd?
[16:08] <shtylman> amichair: yea... it should
[16:09] <amichair> then it's less of a problem, indeed.
[16:10] <amichair> a baloon might still be nice though, showing off the 'I'm a live cd' thing explicitly :-)
[16:10] <shtylman> right
[16:10] <shtylman> yea... I think I like some of these ideas.... deff worth a try
[16:10] <amichair> but I want to close issues here, not add extra work :-)
[16:10] <shtylman> right
[16:11] <shtylman> well... from what you have on the branch... it looks fine
[16:12] <ev> install phase in same window> we'll be discussing that at UDS.
[16:12] <amichair> the only thing gui-wise I found disturbing (as a user) is that the window disappears for a few seconds before the other progress window shows up, so streamlining that would be great, all else remaining the same
[16:12] <amichair> ev: yeah, exactly that
[16:13] <amichair> I'm +1 for that, fwiw :-)
[16:13] <ev> indeed, that's a long standing criticism that we'll be fixing in Maverick
[16:13] <shtylman> ev: cool
[16:14] <amichair> but more importantly, how do we get ubiquity to stop crashing?
[16:14] <shtylman> amichair: we want it to stop crashing?
[16:14] <ev> with lots of unit tests
[16:14] <amichair> shtylman: I'm all for random crashes, it's the consistent ones that I dislike :-P
[16:15] <shtylman> ahh
[16:15] <amichair> or the user-initiated ones, like pressing the 'skip' button
[16:15] <amichair> hehe... I got a real quick fix:
[16:15] <amichair> change the label to 'Crash' instead!
[16:16] <cjwatson> is there a traceback from the skip button crash?
[16:16] <cjwatson> or a bug?
[16:16] <amichair> usability at it's best :-)
[16:17] <amichair> I may have been looking in the wrong places, but I think it's a bug. there's an apt cancellation exception that's caught, properly logged, and sometime shortly after the gui disappears while the installation continues
[16:17] <amichair> (I was surprised to see a few minutes later the 'restart now' message box appearing)
[16:18] <cjwatson> any crash is of course a bug.  I meant a filed one, with logs :)
[16:19] <amichair> cjwatson: oh, I thought u meant crash with trace as opposed to hiding the window while still working
[16:19] <cjwatson> well, there's usually some kind of log from things going wrong like that, somewhere
[16:19] <cjwatson> it might not manifest as a crash dialog
[16:22] <amichair> maybe bug #127871
[16:22] <amichair> though it's pretty old
[16:24] <amichair> or bug #530543
[16:26] <cjwatson> well, I mean something current, usually resurrecting old crash bugs isn't too useful
[16:27] <amichair> It's trivial to reproduce, just didn't want to upen multiple duplicate bugs. Will do it gladly if u like.
[16:28] <cjwatson> dups are fine, the thing that sucks is people piling in on existing bugs with multiple problems :-/
[16:28] <amichair> ok, which logs will be useful?
[16:29] <cjwatson> use 'ubuntu-bug ubiquity'
[16:37] <amichair> cjwatson: I run that right after the crash?
[16:38] <ev> yes
[16:38] <cjwatson> yes, after exiting the installer so that it flushes its logs
[16:38] <amichair> ev: Thanks
[16:38] <amichair> cjwatson: how do I exit the installer? wait till it gives the reboot message?
[16:39] <cjwatson> yeah, then say continue
[16:39] <amichair> ok, gotta run out for a bit, bbl
[17:08] <dmarkey> cjwatson: hey there, is there any hope for 531883 before release do you think
[17:09] <dmarkey> i.e. Include Xen Modules in 64bit install initrd
[17:11] <cjwatson> dmarkey: https://lists.ubuntu.com/archives/kernel-team/2010-April/009770.html
[17:12] <cjwatson> I'll mark that bug as a dup
[17:12] <dmarkey> any chance of xenfs aswell? :)
[17:13] <cjwatson> dmarkey: "also" comments like that have a very poor chance of being seen.  You should file a separate bug.  Also :-), you know that this stuff is done by the kernel team, not by us, right?
[17:13] <cjwatson> #ubuntu-kernel
[17:13] <dmarkey> ohh
[17:13] <cjwatson> BTW, is anyone going to care if this stuff is 64-bit only?
[17:14] <dmarkey> well, 32bit needs to be PAE, which is a seperate bug
[17:14] <cjwatson> I'm asking whether that's something we need to do
[17:14] <cjwatson> we won't make the default 32-bit installer kernel PAE, but if it's needed we can build a separate image
[17:14] <cjwatson> I only want to do that if it's actually needed, though
[17:14] <dmarkey> yes please
[17:15] <cjwatson> it will get used, then?
[17:15] <dmarkey> it will, but i've only tested the 64bit installer
[17:15] <dmarkey> would you be able to roll me an image that i can test?
[17:15] <dmarkey> or point me where i could
[17:16] <cjwatson> not today, and there's presumably no point until the kernel change I linked to lands
[17:17] <dmarkey> hmm.. sorry for ingorance, but when will that be
[17:17] <cjwatson> I don't know; ask #ubuntu-kernel?
[17:17] <cjwatson> after beta-2
[17:17] <CIA-3> ubiquity: evand * r4055 ubiquity/ (debian/changelog ubiquity/frontend/gtk_ui.py):
[17:17] <CIA-3> ubiquity: Fix backing up past partitioning when manual partitioning was
[17:17] <CIA-3> ubiquity: selected (LP: #557210).
[17:17] <dmarkey> cool
[17:17] <dmarkey> home time
[17:17] <dmarkey> talk later thanks
[17:17] <cjwatson> oh, hm, will need to get them to produce generic-pae udebs as well
[17:18] <cjwatson> blah.  will do that on the train tomorrow
[17:20] <CIA-3> ubiquity: evand * r4056 ubiquity/ubiquity/frontend/ (gtk_ui.py kde_ui.py): Add missing return and KDE code to previous commit.
[17:21] <cjwatson> anyway, the amd64 side of things should I think happen largely automatically at this point, aside from xenfs
[18:06] <dmarkey> so we have 2 options there, include the module, or find out why its not detecting the console without it
[18:09] <amichair> cjwatson: opened bug #557434
[18:17] <amichair> Is there a list of bugs that need to be squashed before Lucid release?
[18:53] <amichair> shtylman: any other kde frontend bugs I can help with?
[18:54] <rgreening> ev: ping
[18:56] <shtylman> amichair: ev said the frontend hangs on timezone page when you don't move the mouse (bug 556376), if you can reproduce that or look into it that would be good... I will be trying to deal with it as well later today
[18:57] <amichair> shtylman: ok, I'll try
[18:58] <shtylman> amichair: thanks
[18:58] <rgreening> ev: usb-creator seems to mount the partitions from my usb stick automatically. I guess this is ok, however, and interesting side effect is that if I now close usb-creator-kde without making the startup disk, it leaves the partitions mounted. This is problematic for current KDE as KDE's Solid back-end is still using HAL, and Solid/HAL cannot umount any device mounted by UDisks. This leaves the device hanging for the user. Thoughts?
[18:59] <rgreening> ev: I can probably commit a fix for the kde frontend to unmount when Exit or Close button is clicked...
[19:00] <amichair> shtylman: just got a crash instead :-(
[19:05] <shtylman> amichair: heh
[19:06] <shtylman> thats good too :)
[19:06] <amichair> bug #557487
[19:16] <amichair> shtylman: can't recreate the former, but can the latter, consistently - just press back on timezone page.
[19:17] <shtylman> k
[19:38] <amichair> shtylman: I think this bug is related to your recent change in ubi_language, although the code looks protected
[19:39] <amichair> shtylman: so might it be a race condition or something like that?
[19:40] <shtylman> amichair: k... I can take a closer look tonight
[19:52] <amichair> shtylman: actually, I think it might have just been fixed in trunk. Any good trick for testing trunk on a livecd?
[19:53] <shtylman> amichair: haha yea... I do actually
[19:53] <shtylman> it depends on which parts you want to test.. but what I do is generally:
[19:53] <shtylman> branch the code onto my main development machine
[19:53] <shtylman> build the debs from that code
[19:54] <shtylman> that makes sure that components that are not python get updated
[19:54] <shtylman> those debs can be installed into the live cd environment
[19:54] <shtylman> for the python bits, I mount my main box in the livecd environment
[19:54] <shtylman> through sshfs or nfs
[19:55] <shtylman> then I have a script which symlinks the python files to their place in /usr/lib/ubiquity ...etc
[19:55] <amichair> I think I can get away with just python for now :-)
[19:55] <shtylman> this allows me to edit the python files on my main machine, and then just run the installer in a virtual machine
[19:55] <shtylman> with the python updates being instant
[19:56] <amichair> you link all the files by name? is there a shortcut to do them all at once?
[19:56] <shtylman> amichair: I hope that made sense
[19:56] <shtylman> amichair: I have a script which can link and unlink
[19:56] <amichair> shtylman: yeah, it's sortof what I had in mind
[19:57] <shtylman> unfortunately I don't have ssh on my box at home (im at work) ... so I can't get to the script
[19:57] <amichair> sometimes I mount and then copy, change and test etc. and then copy back the final version
[19:57] <shtylman> yea... I never copy... cause then I risk loosing changes
[19:58] <shtylman> this way I can just mount once, link and work
[19:58] <shtylman> and I just have a script that does the mounting and one that does the initial link
[19:58] <amichair> guess I'm not entirely in the linkin' linux state of mind yet
[19:58] <amichair> but getting there...
[19:59] <amichair> but the mounting u have to do manually no? how do u get the script into the live session?
[19:59] <shtylman> copy it manually
[19:59] <shtylman> obviously something has to be done manually :)
[20:00] <amichair> ok, I'll play around with it some more :-)
[20:01] <shtylman> k
[20:01] <amichair> shtylman: Thanks!
[20:01] <shtylman> no prob... I will post my link script when I can get to it
[21:09] <dmarkey> root=(/dev/sda,1) is that valid in grub.cfg?
[21:27] <dmarkey> seemingly not, cjwatson have to talk to you in the moring :)
[22:01] <cjwatson> more or less valid, yes
[22:02] <cjwatson> it's not really relevant since set root is generally superseded by the uuid search right after it
[22:45] <amichair> shtylman: the second bug (crash when pressing back in tz page) was indeed just fixed intrunk. The skip remains. If there's anything u need help with, don't hesitate to ask... (though I might need a tad of guidance)
[22:47] <shtylman> amichair: cool... will do
[22:47] <shtylman> amichair: is the bug where the installer hangs still there?
[22:48] <amichair> shtylman: the one when the mouse doesn't move?
[22:48] <dmarkey> cjwatson: you sure it doesnt have to be a numberic, i.e. (0,1)
[22:48] <amichair> shtylman: couldn't recreate it, tried several times, also in other languages (as riddell's remark said), etc - but nada
[22:49] <dmarkey> numeric*
[22:49] <shtylman> amichair: k thanks for trying
[23:45] <CIA-3> wubi: Agostino Russo * r179 trunk/ (debian/changelog src/wubi/backends/common/backend.py): Avoid error due to null cd_path (LP: #552357)