[00:39] <isamar> hi folks
[00:39] <isamar> using jaunty 9.04.. my installer is freezing while load bash package...
[00:39] <isamar> this is my first try making a custom cd install..
[00:40] <isamar> anyone can give a hand here ?
[01:31] <isamar> hi folks
[02:17] <isamar> I need a hand with jaunty installer.. crashing with me...
[09:34] <davmor2> evand: umenu works now :)
[09:34] <evand> fantastic
[11:18] <kim0> Hi there, I'm trying to preseed a partition that extends till the end of the disk
[11:19] <kim0> Isn't that the correct syntax: 1000 500 15000000 raid $primary{ } method{ raid } .
[11:21] <cjwatson> kim0: as of jaunty you can just use -1 instead of 15000000; but I don't think that's your question really
[11:22] <cjwatson> yes, that should work fine on reasonably-sized disks
[11:23] <cjwatson> where reasonable < 15TB
[12:16] <kim0> cjwatson: well the thing is that that partition was created only 1G (ie the minimum) .. and I'm on hardy
[12:16] <cjwatson> kim0: you might want to make the second number (500) much bigger; that's a weight
[12:16] <kim0> cjwatson: the middle number (500) is how likely that partition is to be resized wrt to others ?
[12:16] <cjwatson> if it's << the other weights in your preseed file then it probably won't get a very big share of any leftover space
[12:17] <kim0> ah .. so it should be relatively huge
[12:17] <cjwatson> yes, basically the algorithm assigns the minimum sizes to everything, then takes the remaining space and tries to share it out according to the weights
[12:17] <kim0> ok then .. will try thanks
[12:17] <kim0> I see .. thanks
[12:40] <kim0> cjwatson: I'm sorry man, can you please take a look at http://paste.ubuntu.com/217841/
[12:40] <kim0> I keep getting this error: "Can't have a partition outside the disk!""
[12:41] <cjwatson> I need the ENTIRE syslog
[12:41] <cjwatson> I think there may be a bug about this though, which I haven't looked into yet
[12:41] <kim0> cjwatson: ok will
[12:44] <kim0> cjwatson: here's the full syslog http://paste.ubuntu.com/217849/
[12:45] <kim0> cjwatson: do you need it with debconf_debug=developer ?
[12:46] <CIA-8> partman-md: cjwatson * r932 mdcfg-merge/choose_partition/md/do_option: typo that broke RAID0 creation
[12:47] <cjwatson> kim0: I'm not sure if that will help (BTW the name is case-sensitive, DEBCONF_DEBUG=developer); /var/log/partman might help though
[12:49] <kim0> cjwatson: Here it is http://paste.ubuntu.com/217867/
[12:51] <njueyt> http://tinyurl.com/nkypfa
[12:58] <cjwatson> kim0: some kind of rounding error :-( I think you may need to specify an exact size unfortunately
[12:58] <cjwatson> parted_server: add_primary_partition(disk(41943040),29431080-41950611)
[12:58] <cjwatson> note specified upper limit suspiciously close to maximum
[12:59] <kim0> cjwatson: although I am specifiying 1.5T
[12:59] <kim0> which is NOT equal to the disk size
[12:59] <kim0> so it did shrink it .. but not enough it seems ?!
[12:59] <kim0> that's too bad .. coz I don't want to embed the disk size in there
[12:59] <kim0> disks can vary in size
[12:59] <kim0> I just want a partition extended till the end
[13:00] <cjwatson> 21467980799-15068712960 == 6399267839
[13:00] <cjwatson> but it seems to have rounded it UP to 6410000001
[13:00] <cjwatson> kim0: yes I realise that - it's clearly an installer bug
[13:00] <cjwatson> absolutely no argument there, but presumably you have to work with what you've got, i.e. hardy
[13:00] <kim0> if the partition is 99% of the disk .. that would be acceptable to
[13:00] <kim0> anyway to get that
[13:01] <cjwatson> not really
[13:01] <cjwatson> please give me a little while to look at this
[13:01] <kim0> ok man .. thanks
[13:10] <cjwatson> kim0: you can work around the bug by not unnecessarily forcing all of your partitions to be primary
[13:11] <cjwatson> just remove all the "$primary{ } " bits - the partitioner will automatically make the first one primary and leave the rest as logical
[13:11] <cjwatson> and this happens to work around the broken code path
[13:17] <cjwatson> this is bug 287571 and friends
[13:46] <rgreening> evand: ping
[13:47] <evand> rgreening: pong
[13:47] <rgreening> evand: how is the new backend progressing? Should we upload the HAL backend in the meantime?
[13:47] <rgreening> we really want to get something up for alpha 3... :)
[13:49] <rgreening> Im guessinbg by the silence not so good huh evand...
[13:49] <evand> just busy in the immediate moment...
[13:49] <rgreening> :)
[13:51] <rgreening> evand: when you have a moment then, can you let me know where we stand... :)
[13:51] <evand> absolutely
[13:51] <rgreening> kk
[13:53] <mterry> evand, goodness, I should have been asking all my questions here, instead of #ubuntu-devel.  :-/
[13:53] <evand> mterry: Regarding your questions in #ubuntu-devel on test cases, I sent this to you a few weeks back:
[13:53] <evand> Ubiquity and oem-config could really use a unit test framework.  Colin
[13:53] <evand> and I spoke about this at UDS and the plan we came up with is to test
[13:53] <evand> on both ends.  That is, assuming I remember this correctly, we test
[13:53] <evand> that given a certain set of inputs, the d-i component hands exactly
[13:53] <evand> what we expect to get in ubiquity, and the other end we test that
[13:53] <evand> given said expected input in the ubiquity code, it doesn't explode.
[13:53] <evand> Obviously, this can be further refined :).
[13:53] <evand> mterry: no worries
[13:53] <mterry> evand, yeah, I remember you mentioning it
[13:54] <mterry> evand, I also value things like actually driving the UI with ldtp
[13:54] <mterry> evand, as kind of a 'story' or 'use case' test
[13:55] <mterry> evand, helps catch stuff like missing summary pages.  /.\
[13:55] <evand> heh
[13:56] <evand> absolutely
[13:57] <evand> rgreening: I've been jumping from area to area as of the immediate past and have been focusing my usb-creator time on the windows backend.  I'm weary of releasing the HAL backend.  Given the bugs on the GTK side, I'm worried about getting bogged down in HAL bugs, when we're moving to DeviceKit in the short term.
[13:58] <evand> mterry: I'm not sure if we've pointed you at this yet, but https://wiki.ubuntu.com/Installer/Development is a good read.  We keep track of what each other are up to by registering branches with CIA, which reports changes in this channel.
[13:58] <mterry> evand, do we have easy access to a group of people with vested interests in testing oem-config?  Like, mention that some architectural changes went in and they might want to make sure it still works for them?
[13:59] <mterry> evand, ok
[13:59] <evand> mterry: perhaps the ubuntu-installer mailing list.  superm1 might be interested in giving it a test as well.
[14:00] <mterry> evand, OK.  I'll sign up for that and give a help-wanted email, then?
[14:00] <evand> sure
[14:00] <mterry> deal
[14:01] <mterry> evand, once the merge settles and everything is hunky-dory, I suppose we ought to phase out the oem-config code/port bugs to ubiquity component?  I don't have experience with phasing out an LP project
[14:02] <evand> mterry: ah, good point.  Indeed, I have no experience with that either.  cjwatson, any idea or should we talk to gmb to see if there's a way of automating that?
[14:02] <cjwatson> once the new ubiquity is uploaded, get the oem-config source package and any remnants removed from Ubuntu, and then just reassign all the bugs over using a launchpadlib script
[14:02] <cjwatson> should be straightforward
[14:02] <evand> cool, thanks
[14:03] <cjwatson> of course this won't make the bug list any easier to manage, but hey ...
[14:03] <evand> to the interested> After moving the install progress dialog into the main window in support of the slideshow work, I no longer think it makes sense.  We need the maximum amount of screen space for the slideshow, which means removing the superfluous heading, and we'd be removing the back, forward, and quit buttons as they don't make sense in this context.  So I'm going to continue with the slideshow as part of the old, separate, progress window.
[14:04] <evand> indeed, that's going to get even messier
[14:04]  * evand really needs to lock himself in a room over a long weekend and pear that down
[14:08] <evand> rgreening: I think if we don't finish the devicekit work by the end of the week, we should release from trunk, as you suggest
[14:09] <rgreening> ok, I'm all for that.
[14:09] <cjwatson> gah. I KNOW bug 287571 exists. I even have the fix for it in my tree. I just can't reproduce it in a VM so that I can commit the fix
[14:09] <cjwatson> silly rounding errors
[14:10] <rgreening> evand: want to take a snapshot of the trunk and mark the current as a new branch - 2.0.0 beta or something. then merge your changes (cleanup) into trunk?
[14:10] <rgreening> or leave it for now...?
[14:11] <evand> okay, lets just release 0.2.0 from trunk.  I can always deal with the HAL bugs by asking people to try the devicekit backend when it's released.
[14:12] <rgreening> evand: hehe. sounds good. At least it will aloow users to test Kubuntu Netbook easier via install of usb-creator-kde :)
[14:12] <evand> I'll upload it today, barring finding any problems with a transition from 0.2.0 to what we have in cleanup
[14:13] <rgreening> ty. at least it will be in in some shape for alpha3. better than none at all.
[14:14] <rgreening> evand: if you let me know what bits you need help with, I can try and see if I can figure them out. Im not familiar with devidekit, but some small bits I can probably figure out if you like...
[14:15] <evand> rgreening: there's a link to the API in the devicekit backend code.  Any help on finishing that would be much appreciated.
[14:16] <evand> the devicekit backend, that is.  It should just be a matter of following the hal backend and writing the necessary methods using devicekit dbus calls instead of hal ones.
[14:16] <evand> we can refine from there
[14:18] <rgreening> I'll see what I can do...
[14:18] <evand> thanks.  I'll keep working at it as well
[14:25] <rgreening> ty evand
[14:26] <rgreening> evand: have you pushed the latest from cleanup branch?
[14:26] <rgreening> if not, can you?
[14:26] <rgreening> ty
[14:44] <CIA-8> ubiquity: mterry * r3308 prettier-gtk/ (159 files in 19 dirs): merge with trunk
[14:47] <rgreening> evand: looking at the backend.. I have no idea where to start .. hahaha
[14:48] <CIA-8> ubiquity: mterry * r3320 translated-timezones/ (159 files in 19 dirs): merge with trunk
[14:57] <kim0> cjwatson: Thanks a million man .. skipping that code path did help
[14:57] <kim0> cjwatson: d-i is a bit too buggy though :D
[14:57] <cjwatson> good
[14:57] <cjwatson> I just fixed that bug upstream
[15:01] <evand1> rgreening: latest code is already there.
[16:29] <evand1> cjwatson: do we have a hard minimum screen resolution requirement?  The CD sleeve for 9.04 doesn't list one and https://help.ubuntu.com/community/Installation/SystemRequirements seems to suggest 640x480, which I think is a little too aspirational.  I'm trying to determine the size we should aim for slides in the slideshow.  I expect the slides to scale, but we'll want to set a minimum bound.
[16:32] <cjwatson> I'm not sure. I think of late it's been 800x600. I suggest that anything smaller than that simply doesn't get a slideshow
[16:38] <evand1> okay, works for me
[16:38] <evand1> thanks
[16:43] <CIA-8> ubiquity: mterry * r3314 modelines/ (54 files in 6 dirs): add more complete modelines
[17:44] <CIA-8> partman-lvm: cjwatson * r1220 ubuntu/choose_partition/lvm/do_option: only need to invoke sed once here
[21:15] <persia> For slideshow, might I suggest 800x576?  There's a few devices that only have 576 vertical, with significantly wider horizontal resolutions.
[23:08] <CIA-8> partman-auto: cjwatson * r297 ubuntu/ (4 files in 3 dirs): merge from Debian 87
[23:10] <eeejay> preseed/early_command is not working in ubiquity preseed, is this known? is it being run from inside initrd?
[23:11] <CIA-8> partman-auto: cjwatson * r298 ubuntu/debian/changelog: releasing version 87ubuntu1
[23:13] <cjwatson> eeejay: it is called, but I think it's (possibly mistakenly?) executed in the initramfs
[23:13] <cjwatson> eeejay: you might try putting 'chroot /root' at the front of your early_command
[23:13] <cjwatson> (e.g. 'd-i preseed/early_command string foo bar baz' => 'd-i preseed/early_command string chroot /root foo bar baz'
[23:14] <cjwatson> )
[23:14] <cjwatson> eeejay: it's also the responsibility of casper, not ubiquity
[23:14] <eeejay> cjwatson: ah, cool. thanks. would have taken me ages to figure that out myself
[23:14] <cjwatson> I'm not 100% sure why we did it that way; I'm slightly concerned that changing it now would cause compatibility problems though :-/
[23:15] <cjwatson> feel free to file a bug on casper about it though ...
[23:17] <eeejay> cjwatson, so casper is responsible for preseed/*, that is what you mean?
[23:18] <cjwatson> no, just that casper implements that particular one
[23:19] <cjwatson> though as it happens preseed/late_command isn't implemented at all in the live CD; https://wiki.ubuntu.com/UbiquityAutomation offers some replacements
[23:21] <eeejay> cjwatson: another question, does specifying the preseed file with dhcp work with the live CD, couldn't get that to work either
[23:23] <cjwatson> I strongly suspect not; that's implemented by network-preseed in d-i and I imagine casper would have to duplicate that
[23:24] <eeejay> cjwatson: so your chroot suggestion didn't work
[23:24] <cjwatson> assuming that the network is being brought up at the casper stage at least ... hmm, pretty tricky
[23:24] <eeejay> cjwatson: i also tried "touch /root/tmp/test". that didn't work either
[23:24] <cjwatson> eeejay: exactly what is your preseed/early_command?
[23:25] <eeejay> cjwatson: a simple wget, just to so i could see it in the apache log on the other end
[23:25] <cjwatson> (also, it's after 11pm here, sorry but you might be better off filing a bug which I can deal with when more awake :-) )
[23:25] <eeejay> cjwatson: but touch does not work either
[23:25] <eeejay> cjwatson: no prob, thanks for the help
[23:25] <cjwatson> please attach /var/log/casper.log to any bug report
[23:25] <cjwatson> with any luck the problem will show up there
[23:26] <eeejay> cjwatson: thanks, i'll look at that file myself
[23:26] <davmor2> xivulon: how's things
[23:27] <cjwatson> eeejay: you can compare with scripts/casper-bottom/24preseed in the casper source package
[23:27] <cjwatson> reply="$(echo "GET preseed/early_command" | chroot /root debconf-communicate -fnoninteractive casper)"
[23:27] <cjwatson> if [ "${reply#0 }" != "$reply" ]; then
[23:27] <cjwatson> (pass the sickbag)
[23:27] <cjwatson>         reply="${reply#0 }"
[23:27] <cjwatson>         sh -c "$reply"
[23:27] <cjwatson> fi
[23:28] <cjwatson> (hmm, that really ought to check for the value being non-empty too ...)
[23:33] <xivulon> hi davmor2
[23:33] <xivulon> all good thanks
[23:34] <davmor2> xivulon: hardy.3 finally tested now so yes :)
[23:35] <xivulon> good, new version are less stringent on point releases and should not create such trouble
[23:43] <davmor2> xivulon: I'm glad to hear that