[08:51] <jibel> ev, morning. bug 743359 looks popular these days. I've been able to reproduce and attached the logs in debug mode if that helps.
[08:51] <ubot2> Launchpad bug 743359 in ubiquity "Installer: LockFailedException: Failed to lock /target/var/cache/apt/archives/lock" [High,Triaged] https://launchpad.net/bugs/743359
[08:53] <ev> jibel: thanks, I'll have a look at it after bug 820514, bug 781385, and bug 855685
[08:53] <ubot2> Launchpad bug 820514 in ubiquity "oem-config-remove-gtk not found during preinstalled desktop initialization" [High,Confirmed] https://launchpad.net/bugs/820514
[08:53] <ubot2> Launchpad bug 781385 in ubiquity "Ubiquity GTK should have useful accessible names set in the Glade .ui files instead of using the variable names" [Medium,Confirmed] https://launchpad.net/bugs/781385
[08:53] <ubot2> Launchpad bug 855685 in ubiquity-slideshow-ubuntu "Slideshow: "Ubuntu is all about working for real people"" [Undecided,Fix committed] https://launchpad.net/bugs/855685
[08:57] <jibel> thanks
[09:30] <CIA-45> ubiquity-slideshow-ubuntu: evand * r383 ubiquity-slideshow-ubuntu/ (debian/changelog slideshows/ubuntu/slides/accessibility.html): Ubuntu is people! Thanks Dylan McCall (LP: #855685).
=== mpt_ is now known as mpt
[10:03] <CIA-45> ubiquity: evand * r4983 trunk/ (4 files in 3 dirs):
[10:03] <CIA-45> ubiquity: Only set the ATK widget names to their GtkBuilder counterparts when
[10:03] <CIA-45> ubiquity: --ldtp is set (LP: #781385)
[10:08] <CIA-45> ubiquity-slideshow-ubuntu: evand * r384 ubiquity-slideshow-ubuntu/ (381 files in 7 dirs): Update translations from Launchpad.
[10:13] <jibel> ev, about wubi, I looked at bug 842397. a call to find_iso is missing from cache_cd_path
[10:13] <ubot2> Launchpad bug 842397 in wubi "Offline Wubi install no longer works in Oneiric Wubi.exe rev225" [High,Confirmed] https://launchpad.net/bugs/842397
[10:14] <jibel> but there is a chicken-egg problem. the search path for ISOs includes backup_dir
[10:14] <jibel> which is defined later in the task create_dir_structure
[10:14] <jibel> The simplest fix would be to restore the call to find_iso and remove backup_dir from the search path
[10:15] <jibel> From the comment in unstallation_page.py ISO backup is disabled anyway
[10:15] <jibel> ev, what do you think ?
[10:15] <CIA-45> ubiquity-slideshow-ubuntu: evand * r385 ubiquity-slideshow-ubuntu/debian/changelog: releasing version 47
[10:39] <ev> jibel: looking
[11:31] <CIA-45> netcfg: cjwatson * r1276 ubuntu/ (debian/changelog dhcp.c static.c): Don't preseed IP addresses as hostnames (LP: #856088).
[11:34] <CIA-45> netcfg: cjwatson * r1277 ubuntu/debian/changelog: releasing version 1.68ubuntu5
[12:15] <jibel> ev, I pushed https://code.launchpad.net/~jibel/wubi/lp-842397 but the real fix would be to implement offline support for disk images. I can look at it later this week if you wish.
[12:37] <ev> jibel: so I just tried running wubi with --isopath= and it works fine.
[12:39] <ev> ah, I see now
[12:39] <ev> I was confusing find_cd for find_iso in the code
[12:39] <ev> nothing calls out to find_iso at the moment
[12:41] <Peanut> Hi again - I'm trying to install Natty 32-bit server on a diskless box - everything works fine until after telling it what the install-server is going to be, a bit later the ethernet interface goes down and it complains about not being able to reach the install server (gosh). The interface in question is a tigon/tg3 (BCM95702A20). Originally the kernel is fine with this card though complaining about missing firmware (for TSO etc.), but once that firmw
[12:44] <Peanut> sorry, with diskless I mean it has no floppy or CD drive, it does have harddisks.
[12:47] <jibel> ev, I tried again with r234 and it doesn't use a local iso, but will use a local CD.
[12:48] <ev> jibel: are you passing --isopath=?
[12:48] <ev> or are you putting the iso in the same directory and expecting it to work
[12:48] <jibel> ev, I tried both
[12:48] <ev> isopath should work
[12:49] <ev> as it worked for me with r234
[13:14] <jibel> ev, are you testing on windows or wine ?
[13:14] <ev> windows
[13:19] <ev> r223.1.1 is where I seem to have gone at find_iso with a hatched, but helpfully I didn't explain why in the commit log
[13:19] <ev> hatchet*
[13:20] <ev> and no thanks to bzr search there, as it was pretty much useless
[13:20] <Peanut> Ah, I'm being bitten by https://bugs.launchpad.net/ubuntu/+source/debian-installer/+bug/760887
[13:20] <ubot2> Ubuntu bug 760887 in debian-installer "Unable to network install on natty" [Undecided,New]
[13:27] <jibel> it works with wine but fails on windows with the same binary :(
[13:28] <jibel> iso_path is None on windows
[13:30] <ev> interesting
[13:30] <ev> just trying to get a handle on why I ripped out this part of use_iso and use_cd
[13:30] <ev> given that they're not touched by the disk image stuff
[13:32] <ev> ah, refactoring.
[13:39] <jibel> stupid me, that's a silly path mapping error between cygwin and windows
[13:40] <jibel> it used to work because wubi.exe and the iso were in the same directory
[13:41] <jibel> ev, anyway, you might be interested by http://bazaar.launchpad.net/~jibel/wubi/lp-842397/revision/235/data/images/Ubuntu.ico#data/images/Ubuntu.ico
[13:41] <jibel> it fixes the blurry icon in Windows taskbar
[13:41] <ev> AWESOME!
[13:41] <ev> how did you do that?
[13:41] <ev> it was confusing me to no end
[13:42] <jibel> the application icon is the distro icon and it must be a multi-resolution icon.
[13:43] <jibel> derivatives need to update their icon too.
[13:44] <ev> ahhh
[13:44] <ev> I was updating wubi.iso
[13:44] <ev> oop
[13:44] <ev> s
[14:03] <ev> jibel: okay, I see how this is overlapping with what you were saying before about the backup dir
[14:03] <ev> sorry about not quite understanding earlier
[14:11] <CIA-45> wubi: evand * r235 trunk/src/wubi/ (4 files in 4 dirs): Unbreak finding a local ISO and remove the backup directory code. find_iso would depend on it, but we don't create that directory so early on and we're not backing up ISOs, so there's no sense in keeping it around.
[14:15] <CIA-45> wubi: evand * r236 trunk/data/images/Ubuntu.ico: Provide a better Ubuntu icon. Thanks Jean-Baptiste Lallement
[14:18] <jibel> ev, sorry for the confusion :)
[14:18] <ev> entirely on me :)
[14:18] <ev> fixed now
[14:18] <ev> the next cd spin will have the change
[14:18] <jibel> ev, I'm updating the automated test to work with a disk image
[14:19] <jibel> is there something like 'custom-installation' with disk images to load additional data at installation time
[14:19] <jibel> ?
[14:20] <ev> at what point in the installation? Windows or in the initramfs?
[14:28] <jibel> any. Previously, I copied a "custom-installation" directory to c:/ubuntu/install/ and a casper-hook copies the data to the target. Does it still work with disk images ?
[14:29] <jibel> I need to add unittests to the installed system and some test settings (jenkins id, what's being tested, ...)
[14:29] <ev> hm
[14:29] <ev> the second stage of the installation for disk images is entirely in the initramfs
[14:30] <ev> we could reuse early_command though
[14:30] <jibel> I looked at it but found nothing that could copy data from the host system.
[14:32] <jibel> the best solution I came with so far, is to mount the disk image. Not ideal and of course, there is no ext2 driver for windows 7.
[14:43] <CIA-45> ubiquity: evand * r4984 trunk/ (3 files in 2 dirs): Provide a means of preseeding an oem-config frontend (LP: #820514).
[14:44] <CIA-45> console-setup: cjwatson * r421 ubuntu/debian/ (70 files in 2 dirs): merge lp:~vorlon/console-setup/lp.838669
[14:46] <CIA-45> console-setup: cjwatson * r422 ubuntu/debian/changelog: releasing version 1.57ubuntu26
[15:00] <CIA-45> installation-guide: cjwatson * r498 ubuntu/ (4 files in 4 dirs):
[15:00] <CIA-45> installation-guide: Replace 'netcfg/disable_dhcp' with 'netcfg/disable_autoconfig'
[15:00] <CIA-45> installation-guide: throughout. (We could probably do with some description of the new IPv6
[15:00] <CIA-45> installation-guide: behaviour as well, but this is better than nothing.)
[15:05] <CIA-45> installation-guide: cjwatson * r499 ubuntu/ (debian/changelog en/appendix/preseed.xml):
[15:05] <CIA-45> installation-guide: Replace 'console-setup/modelcode', 'console-setup/layoutcode', and
[15:05] <CIA-45> installation-guide: 'console-setup/variantcode' with 'keyboard-configuration/modelcode',
[15:05] <CIA-45> installation-guide: 'keyboard-configuration/layoutcode', and
[15:05] <CIA-45> installation-guide: 'keyboard-configuration/variantcode' respectively (LP: #800822).
[15:07] <CIA-45> installation-guide: cjwatson * r500 ubuntu/debian/changelog: releasing version 20100518ubuntu5
[15:40] <CIA-45> ubiquity: evand * r4985 trunk/ (debian/changelog scripts/install.py):
[15:40] <CIA-45> ubiquity: Terminate the updates download process before we get to
[15:40] <CIA-45> ubiquity: remove_extras (LP: #743359).
[15:40] <ev> jibel: ^ I hope that fixes it, but I have no way of verifying
[16:18] <jibel> ev, I still get the error when I run the installer with 'download updates while installing' checked. I copied install.py from r4985 to /usr/share/ubiquity/ on a live session then ran ubiquity
[16:23] <ev> argh
[16:57] <infinity> ev: *poke*
[16:57] <ev> infinity: about to leave soon, but pong
[16:57] <infinity> ev: Untested, but if your "export FRONTEND" in the upstart script (for preseeding) works, wouldn't exporting the FRONTEND in oem-config-firstboot have the same effect?
[16:58] <infinity> ev: Which would force consistency (finishing with whatever frontend you start with), and kill the bug?
[16:59] <ev> what effect would that have that my change didn't cover?
[17:00] <infinity> It would mean that a non-preseeded frontend would remain consistent.
[17:00] <infinity> Since the problem for us seems to be randomly switching from gebconf to gtk halfway through.
[17:00] <infinity>  # TODO: will this work for X-based frontends when X isn't up yet?
[17:00] <infinity>  if [ -z "$FRONTEND" ]; then
[17:00] <infinity> -	FRONTEND="$(/usr/sbin/oem-config -q)"
[17:00] <infinity> +	export FRONTEND="$(/usr/sbin/oem-config -q)"
[17:00] <infinity>  fi
[17:00] <infinity>  
[17:00] <infinity> debconf, even.
[17:00] <ev> but what isn't getting FRONTEND that's spawned from oem-config-firstboot?
[17:01] <infinity> oem-config-remove, one would assume, from the bug.
[17:02] <ev> but that's selected based on the value of FRONTEND, no?
[17:02] <infinity> But you don't export FRONTEND after selecting it in firstboot.
[17:03] <infinity> So, subprocesses won't inherit it.
[17:03] <ev> it doesn't need to...
[17:03] <ev> unless I'm missing something
[17:04] <ev> oem-config-remove-gtk wont be called because the frontend will be debconf or whatever you set
[17:04] <infinity> Well, then I'm at a loss as to how this bug is occurring at all.
[17:04] <ev> because oem-config -q returns the gtk frontend
[17:04] <ev> at least that was my impression
[17:04] <ogra_> on headless it cant
[17:04] <infinity> We're not setting a frontend.  But one is set by "/usr/sbin/oem-config -q"
[17:04] <ogra_> we dont install it there
[17:04] <cjwatson> I thought the frontend was meant to be set by preseeding
[17:05] <ogra_> we are setting a d-i frontend iirc
[17:05] <ogra_> or unset it ...
[17:05] <cjwatson> d-i  oem-config-udeb/frontend        string debconf
[17:05]  * ogra_ checks the code
[17:05] <cjwatson> et al
[17:05] <cjwatson> maybe you don't do that in preinstalled
[17:05] <ogra_> no. that was for fixing serial vs framebuffer
[17:05] <infinity> Well, okay.  I'm getting confused.
[17:05] <infinity> We don't fail to run oem-config.
[17:06] <cjwatson> ah, actually, all that does is control which oem-config-$frontend gets installed, so never mind me
[17:06] <infinity> Which means the frontend IS being set correctly, even if by accident.
[17:06] <ev> gotta run!
[17:06] <infinity> And it's not remaining consistent.
[17:06] <infinity> The lack of consistency is the bug.  Whether we should be explicitely setting it is another possible bug.
[17:06] <cjwatson> we explicitly say FRONTEND="$FRONTEND" ... when calling oem-config-wrapper
[17:06] <cjwatson> so I don't see how it can be a lack-of-export bug
[17:06] <infinity> But the part where oem-config starts in a debconf UI, and then swaps halfway through is... Wrong.
[17:07] <ogra_> well, the consistency is that we keep ubiquity installed on all preinstalled images atm
[17:07] <infinity> cjwatson: And that call obviously works, or we'd not get oem-config at all.
[17:07] <ogra_> though i suspect there are different bugs
[17:07] <cjwatson> has anyone done set -x here?
[17:07] <infinity> No, I haven't debugged at all.  Just chaed the bug a bit.  I might abuse it now. :P
[17:08] <infinity> s/chaed/chased/
[17:08] <infinity> Still, lack-of-export would be a reasonable explanation if oem-config-wrapper forks or re-execs at any point.
[17:09] <ogra_> ahm, found it
[17:09] <ogra_> debian-installer/framebuffer=false
[17:09] <infinity> And, conversely, if lack-of-export isn't the issue, then the upstart preseeding fix wouldn't help any, even if we preseed.
[17:09] <ogra_> thats what we set on headless, i dont think that has any influence on oem-config though
[17:12] <infinity> ogra_: Apparently, we want "ubiquity/frontend=debconf_ui", looking at the code.  But, like I said, if that works, and the current bit doesn't, it would only be because the upstart job has an "export", and oem-config-firstboot doesn't, and that's still broken from a consistency standpoint.  But I'm going to play here for a sec.
[17:13] <cjwatson> re-exec preserves the environment
[17:13] <cjwatson> and it doesn't fork and re-exec itself
[17:14] <cjwatson> ogra_: certainly has zero influence on whether oem-config-remove-gtk is called
[17:15] <infinity> cjwatson: I dunno, maybe I'm misunderstanding how this all works, but I would assume that if our FRONTEND was set to gtk_ui, the first call to oem-config in -wrapper would fail, and we'd never actually get anywhere, right?
[17:16] <infinity> cjwatson: Or is it, perhaps, that ubiquity does sanity checking on the environment and goes debconf in the absense of $DISPLAY, so the only bit that actually breaks is oem-config-remove*?
[17:16] <cjwatson> it might fall back to debconf automatically if it can't find gtk
[17:16] <cjwatson> although in that case you'd expect -q to say that
[17:17] <infinity> Yeah.  Hence why (while I'm willing to admit we should be preseeding this) it still feels like a ubiquity bug somewhere too.
[17:17] <cjwatson> I expect so, yes
[17:17] <infinity> But I'll write a daily to an SD and trace a bit.
[17:19] <cjwatson> ev's preseeding (well, cmdline-parsing) fix looks right to me, and I can see why it's different from exporting FRONTEND in oem-config-firstboot
[17:20] <cjwatson> oem-config-firstboot only ever does detection; this lets you override
[17:20] <cjwatson> though I think there's a bug that the detected FRONTEND isn't passed to oem-config
[17:20] <infinity> Well, yes, I can see why it needs to export, since it's not directly calling.
[17:21] <cjwatson> I think the fix for that is http://paste.ubuntu.com/697385/
[17:21] <infinity> To make it universally fail? :)
[17:22] <CIA-45> ubiquity: cjwatson * r4986 trunk/debian/ (changelog ubiquity.install-amd64 ubiquity.install-i386): Install new files from grub-installer >= 1.66.
[17:22] <cjwatson> Well, if detection is failing you need to fix that too
[17:22] <cjwatson> But it would eliminate the inconsistency
[17:25] <infinity> I'll play locally a bit and follow up to the bug later today.
[17:25]  * infinity downloads images.
[17:25] <infinity> cjwatson: Agreed on the consistency thing, though, it's frustrating.
[17:27] <infinity> (Though, it does lead the the followup of "why does ubiquity appear to magically DTRT without a frontend specified?"
[17:27] <infinity> )
[17:28] <cjwatson> 'cos it tries gtk_ui then kde_ui then debconf_ui; it's congruent with debconf itself in this respect
[17:29] <infinity> So, one could perhaps change -wrapper to do the same thing for remove, and all would be shiny.
[17:30] <infinity> remove-gtk || FRONTEND=kde remove || FRONTED=dialog remove || true
[17:31] <cjwatson> there should be no need for that; that's why we call oem-config -q and record what it sayd
[17:31] <cjwatson> *says
[17:31] <infinity> (And then we'd still want to preseed to avoid all those try/fail codepaths, but at least the behaviour of both tools would be consistent.
[17:31] <infinity> )
[17:31] <cjwatson> let's not add more autodetection, let's fix what we have
[17:31] <infinity> cjwatson: Kay.  In circles, I guess, then.  Shouldn't -q output the value of "I tried everything, and only N worked"?  ie: outputting the same frontend it would end up actually using, not the first it finds?
[17:32] <cjwatson> oem-config -q should list the frontend that's actually going to be used
[17:32] <cjwatson> yes, it should
[17:32] <cjwatson> if it's not, fix it :)
[17:32] <infinity> :)
[17:32] <infinity> Pointer at where that detection bit might live?
[17:32] <infinity> Vaguely.
[17:33] <cjwatson> search for query in bin/ubiquity
[17:35] <infinity> Danke.
[17:35]  * infinity goes to smoke while cards flash.
[19:35] <CyON> hai guys !! I have a ubuntu 11.10  installed on , one of my partition and now I want to install xp on my other partition..any one can help me !!
[19:37] <cjwatson> For installing Windows, you'll need help from a channel that knows about Windows, rather than one that knows about Ubuntu
[19:38] <CyON> ok ..
[21:12] <CIA-45> debian-installer: cjwatson * r1443 natty-proposed/debian/changelog: releasing version 20101020ubuntu29.1