[00:42] <CarlFK> alt installer too
[00:42] <CarlFK> it sees disks, but not the partitions
[00:43] <CarlFK> http://dpaste.com/83067/
[00:44] <CarlFK> the cd errors might be relevant... let me reboot without that
[00:46] <CarlFK> hmm... partman found them: Guided - resize SCSI1 (0\,1\,0)\, partition #1 (sdb)
[00:47] <CarlFK> fdisk -l sees them now too.  guess something found them much later than I expected
[01:11] <yannickm> hi, anyone here that i could ask a few questions about the installer (tasksel in particular)
[01:18] <CarlFK> Oct  8 00:14:39 grub-installer: You shouldn't call /sbin/grub-install. Please call /usr/sbin/grub-install instead!
[01:19] <CarlFK> does that apply to the installer?
[01:20] <CarlFK> Oct  8 00:14:39 grub-installer: /dev/sdb1 does not have any corresponding BIOS drive.
[01:20] <CarlFK> that's a problem.  off to lp I go...
[01:27] <CarlFK> https://bugs.launchpad.net/ubuntu/+source/grub-installer/+bug/262816 bug #262816
[01:27] <CarlFK> "grub-install failed: "/dev/sda1 does not have any corresponding BIOS drive"
[01:28] <CarlFK> cjwatson: I just got this too with alt - want logs? http://dev.personnelware.com/carl/a/dhcp91/
[05:03] <Samah> hello there, need help with ubuntu, anybody here?
[06:57] <lukehasnoname> Hello, I had some trouble immediately after install. One is with the oem-config, and one with... something else. The full description of my problem is here: http://mibbit.com/pb/3ui0Ts
[07:04] <evand> lukehasnoname: please file a bug on Launchpad.  It's near-impossible to track bugs via IRC.
[07:05] <persia> In at least the case of the VBE issue, you may find the bug already filed, and some discussion.
[07:06] <evand> good afternoon persia
[07:06] <persia> good night evand
[07:06] <persia> Hmm.  Somehow that doesn't seem to be as much of a greeting when reread as when typed.
[07:06] <evand> heh
[07:07] <evand> odd that you cannot use night in a greeting though.
[07:08] <persia> It's the rampant hegemony of the diurnalists.
[07:08] <StevenK> If mornings really exist, why are there only 12 hours on a clock?
[07:09] <evand> haha
[07:16] <persia> evand, while you're still up: I'm looking at allowing limitation of the requirement for passwords to not be blank.  The remaining spot seems to be a check in ubiquity to verify that username, password, verified_password, and hostname contain values.  Do you think it would be better to try to check the SEEN values for these, or change the logic to honor the preseeding hint I prepared for user-setup?
[07:18]  * evand thinks
[07:18]  * persia is around line 919 of gtk_ui.py if that helps
[07:20] <evand> I think we can remove that chunk of code
[07:20] <persia> Just drop the check entirely, and rely on the interaction with user-setup?
[07:20] <evand> as user-setup/password-empty will be shown in ubiquity anyway, IIRC
[07:20] <evand> ja
[07:20]  * persia tries that
[07:21] <evand> do let me know how that goes
[07:21] <evand> I suspect we should still leave it for username and hostname though.
[07:23] <persia> Is that because there aren't such errors reported for those, or because double-checking is a good idea?  If the latter, I'd rather just split the check, and inspect the preseed value.
[07:24] <evand> because we save the user the trouble of clicking next and finding out that those values cannot ever be blank
[07:24] <evand> I'm not sure I understand what you mean by split the check
[07:26] <persia> Something like http://paste.ubuntu.com/55186/
[07:27] <evand> I don't think the latter half of that is necessary.  user-setup should take care of that for us.
[07:27] <evand> as it will ask an error question, which should show up next to the appropriate field and grey out the next button
[07:27]  * evand pokes at the code to be sure
[07:29] <persia> Oh, the error question does show after clicking next, or if one tries to preseed blank in --automatic without telling user-setup that it's allowed.  I was thinking more about the avoidance of having the user click next and get the error.
[07:29] <evand> err it doesn't grey the button, but loops back, meaning that you'll stay on the page until you fix the error
[07:30] <evand> personally I think it's best to leave that code in user-setup-ask, rather than duplicate it somewhat in ubiquity.
[07:30] <persia> OK.  I like that, because it's easier for me :)  It's just a question of user experience of pressing Next and looping back.
[07:30] <evand> but you're welcome to form a mob and overrule me :)
[07:31] <evand> indeed
[07:36] <persia> Just removing the checks works for me for an --automatic install.  Once that completes, I'll try again interactively without allowing the password to be empty to verify.  Thanks for the guidance.
[07:37] <evand> anytime
[07:37] <StevenK> Bit early isn't it, evand? :-)
[07:37] <evand> I'll call it late, as I do plan to go to bed at some point. :)
[07:39] <persia> Is the distinction between "early" and "late" only in whether one has yet to sleep?  What about the poor folk at wedontsleep.org ?
[07:39] <evand> hahaha
[07:39] <evand> noted
[08:14] <CIA-52> ubiquity: evand * r2875 ubiquity/ubiquity/frontend/noninteractive.py: Add missing initialization of self.auto_login in noninteractive.
[08:15] <StevenK> Is the evand the IRC nick, or just that the LP name and IRC nick are the same?
[08:16] <CIA-52> ubiquity: evand * r2876 ubiquity/ (configure configure.ac): Bump to 0.10.4
[08:17] <evand> StevenK: latter
[08:17] <evand> whoops, that should read 1.10.4
[08:17] <StevenK> Haha. persia kept doing that.
[08:18] <evand> oh well, I got it right in the actual code.
[08:18] <StevenK> It's contagious!
[08:18] <evand> haha
[08:18] <CIA-52> ubiquity: evand * r2877 ubiquity/ (d-i/manifest debian/changelog):
[08:18] <CIA-52> ubiquity: Automatic update of included source packages: partman-ext3
[08:18] <CIA-52> ubiquity: 52ubuntu3, partman-jfs 26ubuntu2, partman-reiserfs 41ubuntu3,
[08:18] <CIA-52> ubiquity: partman-xfs 41ubuntu2, user-setup 1.20ubuntu8.
[08:19] <persia> evand, Please consider bug 280014 before you release.
[08:19] <persia> evand, Also, you want to pull my partman-efi trunk, as 1.10.4 FTBFS on lpia with the current one.
[08:20] <evand> ah, will do
[08:20] <persia> Oh, no partman-efi got merged.  It probably just needs an upload.
[08:22] <evand> uploading partman-efi now.
[08:23] <persia> Thank you.
[08:25] <evand> persia: hrm, perhaps I'm just tired and screwing things up, but the debdiff of partman-efi 17ubuntu2 and partman-efi 18ubuntu1 doesn't show the changes you mention in the changelog.
[08:26] <persia> What!
[08:26]  * persia checks the branch
[08:27] <persia> evand, Which change?  I intended to pull translations from Debian and to modify line 7 in commit.d/format_efi
[08:29] <evand> indeed, that's what it shows, but your changelog entry is as such:
[08:29] <evand> +partman-efi (18ubuntu1) intrepid; urgency=low
[08:29] <evand> +
[08:29] <evand> +  * Resynchronise with Debian. Remaining changes:
[08:29] <evand> +    - Automatically use existing EFI system partitions on Intel Macs as EFI
[08:29] <evand> +      boot partitions.
[08:29] <evand> +    - Create fat32 EFI partitions with the name "EFI System Partition" by
[08:29] <evand> +      default on Intel Macs.
[08:29] <evand> +    - choose_method/efi/do_option: Make sure no mountpoint is set.
[08:29] <evand> +    - Remove efi-modules dependency; it seems to be built into Ubuntu
[08:30] <evand> +      intrepid kernels now
[08:30] <evand> +
[08:30] <evand> + -- Emmet Hikory <persia@ubuntu.com>  Tue, 07 Oct 2008 15:06:58 +0900
[08:30] <evand> oh
[08:30] <evand> I'm just tired
[08:30] <evand> ignore me
[08:30] <evand> :/
[08:30] <persia> No problems :)  You'd see those changes if you compared to 18 :)
[08:31] <persia> Basically, I generated a lot of debdiffs, and then applied them in between commits to construct a bzr branch for the Ubuntu changes, which should be a sane basis for future updates using a bzr workflow.
[08:32] <persia> I only started from 17, as I didn't think anyone was going to want to try to rebase from earlier versions.
[08:33] <evand> indeed
[08:36] <evand> uploaded
[08:36] <persia> Thank you.  I presume there's a wait for the buildd before it can be pulled into ubiquity?
[08:38] <evand> indeed
[08:39] <persia> Oh well.  Sorry about that.
[08:40] <evand> no worries
[08:41] <persia> I'm fine with a push to address the auto-login issue for noninteractive, and the lpia FTBFS can be resolved on another day, if there's a reason things should happen that way.
[08:43] <evand> I should be able to get both in a build and new DVDs made before Dell can use them (US Central), I think
[08:43] <persia> OK.  I just don't like to deprive anyone else of sleep just because I've not been pushy enough about uploads.
[08:45] <evand> oh no worries there, I had planned to be up anyway to tackle grub UUID issues, but KVM hates me so this is the best use of my time at the moment
[08:45] <persia> Are you looking at something that would autodetect the installation medium, and not install grub there?
[08:45] <evand> that's one of a few bugs that need to be fixed, yes.
[08:46] <evand> that one is tricky as there's a request to not filter out disks entirely, but rather just partitions
[08:46] <persia> Oh cool.  I'd resigned to writing an installation note telling people to be careful about where they install grub when using KVM and USB images.
[08:46] <evand> https://bugs.launchpad.net/ubuntu/+source/partman-base/+bug/276656 FWIW
[08:47] <persia> So if one has an installer on one partition of a disk, one can install to another partition of the same disk?  Interesting.
[08:47] <evand> well, I'm not sure it will end that way
[08:47] <evand> I need input from cjwatson on it, as I believe it's not possible to have the installation medium on the same disk you're partitioning
[08:47] <evand> as then the kernel wont be able to re-read the partition table
[08:48] <evand> and if that's the case, my job is really easy as it's a simple matter of filtering out any disk with mounted partitions (the original patch specifically looked for /cdrom and /hd-media)
[08:49] <persia> It's at least tricky, but I can see the possible advantage for a "recovery partition" or the like.
[08:49] <evand> still need to get update-grub writing UUIDs instead of root= though, and teach ubiquity/grub-installer to pick something a little more sane than (hd0) every time.
[08:50] <persia> Actually, that somewhat confused me : there's the opportunity to adjust with the Advanced... button at the end of the installation, but it doesn't seem to work when installing grub to ! hd0
[08:50] <persia> (or maybe it's just the way I've used it)
[08:51] <evand> it works for me.  How did it fail for you?
[08:51] <evand> it should ensure you enter a sane value and give you a drop down of suggested sane values
[08:52] <evand> something like (hd[0-9]*,[0-9]) (slightly more complicated than that, iirc) or /dev/whatever
[08:52] <persia> It gave me a drop-down.  I just got a "grub couldn't install" error in the last stage.  As I know I've had this working with some changes to grub-installer itself, but which changes aren't preserved in my ubiquity branch, I suspect I got the error from incorrectly stacking versions of things.
[08:53] <evand> hrm, ok
[08:53] <evand> do let me know if it persists
[08:53] <lukehasnoname> persia: Under where will I file my report on oem-config and vbe_init?
[08:53] <lukehasnoname> What "project"?
[08:54] <persia> lukehasnoname, For oem-config, I'd start from bugs.launchpad.net/ubuntu/+source/oem-config/+bugs  I'm not so sure for vbe_init
[08:54] <persia> evand, Certainly.  It's not yet at the point where I consider it a bug.
[08:55] <lukehasnoname> mk, I'll do that tomorrow afternoon. It's 3am in Texas... I'm out. Thanks.
[09:27] <cjwatson> Fragadelic: copy directly from squashfs> evand's answer, plus we were very concerned about the support implications of installs not being pristine. No, we didn't actually try it the other way, but we had enough experience by then to be able to reason out the implications first
[09:28] <cjwatson> TheMuso: I think the current behaviour has user-friendliness problems too - maybe we should detect the metadata and, if we find it, ask the user if they want to enable dmraid?
[09:29] <cjwatson> CarlFK: the grub-install error is just noisy, it doesn't actually cause any problems
[09:30] <cjwatson> evand,persia: I think I'd rather have ubiquity check passwd/allow-password-empty and continue to disable the next button if it's false
[09:31] <cjwatson> if you don't know about the allow-password-empty change, it's a bit of a weird UI change, if my reasoning
[09:31] <cjwatson> is my reasoning
[09:32] <cjwatson> StevenK: in fact the CIA username is also independent; see bzr help cia
[09:33] <cjwatson> evand: 276656> I'm happy for there to be some kind of "I know what I'm doing" override that Dell can set to have the installation medium on the disk being partitioned
[09:33] <cjwatson> persia: yeah, I suspect the reason that installing to non-first disk is broken is that grub fails to find its stage 1.5; all part of the same horrible ball of wax
[09:39] <CIA-52> debian-installer: cjwatson * r972 ubuntu/debian/changelog: releasing version 20080522ubuntu18
=== nasrat_ is now known as nasrat
[11:58] <CIA-52> ubiquity: cjwatson * r2878 ubiquity/ (debian/changelog scripts/install.py):
[11:58] <CIA-52> ubiquity: Check whether log files exist before copying them (thanks, Vitaly
[11:58] <CIA-52> ubiquity: Petrov; see LP #279003).
[12:01] <CIA-52> ubiquity: cjwatson * r2879 ubiquity/ (debian/changelog scripts/install.py):
[12:01] <CIA-52> ubiquity: Adjust live filesystem mounting for Debian (thanks, Vitaly Petrov; see
[12:01] <CIA-52> ubiquity: LP #279003).
[12:05] <CIA-52> ubiquity: cjwatson * r2880 ubiquity/ (debian/changelog scripts/install.py): Reconfigure splashy (thanks, Vitaly Petrov; see LP #279003).
[12:36] <CIA-52> user-setup: cjwatson * r120 ubuntu/debian/changelog: merge from lp:~persia/user-setup/ubuntu (changelog bug number only)
=== davmor2 is now known as davmor2_away
[14:36] <evand> cjwatson: noted, thanks
[14:45] <persia> cjwatson, OK.  I'll put together a UI check for that : probably be at least a few hours.
=== davmor2_away is now known as davmor2
[15:08] <CarlFK> cjwatson: you mean grub did get installed?  (box is still sitting with the installer error, haven't tried to boot it yet)
[15:10] <Fragadelic-1> cjwatson: did you take a look at my remastersys script?  http://pastebin.com/f78cff54b  - I don't think I'm doing anything to break popularity-contest or anything else really but I could be wrong and if I am I'd love to correct it.
[15:19] <cjwatson> CarlFK: yes
[15:20] <cjwatson> CarlFK: err, no, I mean that the /sbin/grub-install message did not change whether it was installed or not
[15:20] <cjwatson> CarlFK: it's entirely possible that some later error broke it, it just wasn't the one you quoted
[15:20] <cjwatson> Fragadelic-1: no, sorry
[15:20] <Fragadelic-1> cjwatson: no problme - I know you are busy
[15:58] <kirkland> cjwatson: the daily server iso isn't detecting network or hard disks ... is this known?
[15:59] <CarlFK> kirkland: the installer, or the system that gets installed?
[16:00] <kirkland> CarlFK: installer
[16:00] <cjwatson> kirkland: probably just kernel skew, fixed this morning
[16:00] <cjwatson> kirkland: see if 'uname -a' matches the kernel udebs on the CDs
[16:01] <kirkland> cjwatson: uname says -4 ... looks like there's both a -4 and -5 kernel udeb
[16:04] <cjwatson> yeah, it'll just be skew
[16:04] <cjwatson> should be sorted out tomorrow
[16:07] <kirkland> cjwatson: k, thanks.
[16:15] <evand> persia: is it likely that you'll have time to update your ubiquity branch to relfect the suggestion cjwatson made in bug 280014
[16:15] <evand> I'd like to get an upload in soonish.
[16:15] <evand> err, that you'll have time today*
[16:16] <CarlFK> cjwatson: sorry if I am missing something... installer syslog: Oct  8 00:14:39 grub-installer: error: Running 'grub-install  --no-floppy  "(hd0)"' failed.
[16:16] <CarlFK> should I open a bug?
[16:18] <persia> evand, I'm working on it now, but both tired and a little distracted.  If I don't finish in the next 3 hours, I'm happy to miss this next push.
[16:18] <cjwatson> CarlFK: I'm in a meeting
[16:18] <evand> persia: noted
[16:19] <CarlFK> k - I'll hold.
[16:20] <cjwatson> CarlFK: ... and after that I'll be going out. Do whatever seems reasonable to you.
[16:38] <TheMuso> cjwatson: A good idea, but we would have to ask the question for every array thats found, as a user may want one, but not another. We also would have to carry that through to the installed system. I think thats probably something for Jaunty.
[16:39] <cjwatson> TheMuso: I'm really concerned that this is a regression on systems that used to work; I don't think we can defer it
[16:41] <TheMuso> cjwatson: Ok, since disk-detect is what brings up the arrays, it needs to be done there. When I'm awake later today, i.e not for the meeting, I'll take a look at writing the debconf template for it. I'll also need help to figure out how to get such a setting for which arrays are wanted through to the installed system.
[16:41] <TheMuso> cjwatson: This will need a UI freeze exception I'm assuming.
[16:42] <cjwatson> for intrepid we might be OK with just a global on/off switch
[16:42] <cjwatson> then it'd just be a matter of deciding whether to use dmraid or not, right?
[16:42] <TheMuso> Yes, if the user says no, we don't activate.
[16:42] <cjwatson> I think that would cover most of the affected users, and certainly 279288
[16:42] <TheMuso> Simple as that.
[16:42] <cjwatson> err, I mean "whether to install dmraid on the target system"
[16:42] <cjwatson> then you don't have to worry about any more complicated propagation
[16:43] <TheMuso> Right, but that toggle would also be askign if the user wants to use an array for the install.
[16:43] <cjwatson> yes.
[16:44] <TheMuso> Ok then that should be easy, by adding a new template to disk-detect.
[16:44] <TheMuso> Will look at it later today.
[16:44] <cjwatson> just "you seem to have dmraid stuff on your disks; do you want to use it?"
[16:45] <TheMuso> eah similar to what I was thinking.
[17:07]  * ogra waves
[17:09] <ogra> so i have some reports of users that end up with cdrom entries for a nnexistin /dev/sdb on their UMPC/MID after install ... do we use some kind of hardcoding there ? (that prevents usb keys that show up as sdb from being mounted)
[17:09] <cjwatson> no, that just means it happened to be sdb during the install
[17:09] <cjwatson> we were just talking about this in the foundations meeting; it may be possible to strip that out at the end of USB installs
[17:10] <cjwatson> or, if we're very lucky, to use /dev/disk/by-path/ or similar
[17:10] <cjwatson> but the real fix needs to be proper cdrom detection in apt, and is for jaunty
[17:10] <ogra> udev should know if its really a cdrom, no ?
[17:10] <ogra> so we should be able to look there
[17:11] <cjwatson> apt's cdrom method needs to do it
[17:11] <ogra> ah, k
[17:11] <cjwatson> right now, it doesn't, and the installer needs apt to work
[17:11] <ogra> indeed
[17:11] <cjwatson> <cjwatson@sarantium ~>$ ls -l /dev/disk/by-path/
[17:11] <cjwatson> total 0
[17:11] <cjwatson> lrwxrwxrwx 1 root root 10 2008-10-08 09:59 pci-0000:00:1f.1-scsi-0:0:0:0 -> ../../scd0
[17:11] <cjwatson> ... would work on my system
[17:12] <cjwatson> I think that's stable
[17:12] <ogra> yeah
[17:12] <ogra> well, if thats addressed and known i wont bug further
[17:12] <ogra> if you need testers, i have them in the community, wiling to help
[17:12] <ogra> *willing
[17:12] <cjwatson> it's one of the oldest bugs in Ubuntu, actually :)
[17:12] <cjwatson> you're just running into it now ...
[17:12] <ogra> well, we didnt have USB installs before
[17:13] <ogra> at least not in a sane manner :)
[17:14] <cjwatson> that's just one of the many possible scenarios
[18:13] <persia> Remembering the issue with auto_login for noninteractive, if I want to use self.frontend.set_allow_password_empty, should this be defined in all frontends?
[18:14] <evand> including base.py, yes
[18:14] <evand> any time the components call a function in the frontend, that is
[18:14] <persia> So put it in base.py and each of the frontends?
[18:14] <evand> ja
[18:16] <persia> Should I be concerned that auto_login isn't defined in mythbuntu.py?
[18:17] <persia> Or is that special in lots of ways.
[18:17] <evand> special.  It derives from the gtk_ui frontend.
[18:17] <persia> OK.  That makes it easier.  Thanks.
[18:25] <persia> Right.  Now to check if this works.
[18:47] <persia> evand, Please don't wait for me on 280014 anymore.  I'm not going to get it quickly.  My first attempt was to set an attribute in components/usersetup.py based on a db_get of the preseed value, and then check that attribute, but I'm getting runtime errors, and will need to track them down (for which I'm probably too tired to be either quick or effective).  Maybe tomorrow, but that can wait for the 1.10.5 or so.
[18:48] <evand> ok
[18:48] <evand> thanks for the heads up
[18:48] <persia> No problem.  Thanks for waiting for me to try to get it tonight.
[18:51] <evand> anyone else have changes they want to land before I upload ubiquity?
[18:52] <evand> (no need to respond with "no", I'll just wait a few minutes before kicking off the commits)
[18:52] <persia> evand, Please do refresh the d-i components again, but that's it from me.
[18:55] <evand> will do (it's part of the release process for ubiquity)
[18:56] <persia> OK.  Sorry for the noise then :)
[18:56] <evand> no worries
[19:01] <CIA-52> ubiquity: evand * r2881 ubiquity/ (d-i/manifest debian/changelog): Automatic update of included source packages: partman-efi 18ubuntu1.
[19:06] <CIA-52> ubiquity: evand * r2882 ubiquity/debian/changelog: releasing version 1.10.4
[19:53] <evand> yikes, i386 build took 47 minutes.
[19:59] <persia> And amd64 41 minutes, and lpia 6 minutes.  Something seems wrong with this picture.
[20:01] <evand> hahaha
[20:03] <persia> Well, if i386 took a long time, and everything else was quick, I'd blame arch: all stuff taking the extra time.  In this case, I can't explain it.  lpia is fast, but the buildd isn't actually lpia, and the discrepancy is just too big.
[20:16] <pmatulis_t60> pmatulis... http://groups.google.co.kr/group/linux.samba/browse_thread/thread/0f1526049ab53ac6
[23:06] <kirkland> evand: hiya, are you around?
[23:11] <kirkland> cjwatson: hi, how much trouble would it be to spin off another set of intrepid server builds?
[23:11] <kirkland> cjwatson: the broken install iso is blocking some of my work, at the moment
[23:12] <kirkland> cjwatson: the daily builds have the kernel mismatch problem we discussed this morning, leading to network and hard disks not being detected
[23:12] <cjwatson> yeah, I only just killed the stuck process on cdimage a few minutes ago, which is what was causing it
[23:12] <kirkland> cjwatson: i tried to fall back to the beta iso's, but those are failing looking for dmraid
[23:12] <kirkland> cjwatson: http://launchpadlibrarian.net/18298386/syslog
[23:13] <kirkland> cjwatson: i'm hoping thats been fixed in the daily iso's?
[23:13] <cjwatson> I've kicked off Ubuntu server and alternate builds
[23:13] <cjwatson> yes, that's fixed
[23:13] <cjwatson> it was due to server-ship not depending on d-i-requirements in ubuntu.intrepid/STRUCTURE
[23:16] <kirkland> cjwatson: pfft, the nerve :-)
[23:17] <cjwatson> (d-i-requirements is the seed that contains random stuff that d-i might need depending on circumstances)
[23:21] <kirkland> cjwatson: k, thanks