[00:39] <shtylman_> cjwatson: is it too late to do a sync with debian?
[00:39] <shtylman_> http://packages.debian.org/sid/libluabind-dev
[00:40] <shtylman_> http://packages.ubuntu.com/search?keywords=libluabind-dev&searchon=names&suite=all&section=all
[00:40] <shtylman_> the luabind in ubuntu is older
[00:40] <shtylman_> cjwatson: I don't know much about when those syncs happen
[00:40] <shtylman_> or how
[09:13] <CIA-52> ubiquity-slideshow-ubuntu: evand * r192 ubiquity-slideshow-ubuntu/ (8 files in 8 dirs): Bump release in welcome.html to 10.04.
[09:13] <ev_> ^ shtylman: fixed
[09:16] <cjwatson> shtylman: https://wiki.ubuntu.com/SyncRequestProcess
[10:04] <CIA-52> ubiquity: evand * r3728 plugins-conversion/debian/ubiquity.install-any: Add back accidentally removed partman_commit to debian/ubiquity.install-any.
[11:17] <ogra> ev_, hey, so i tested the debconf frontend yesterday on my minimally built rootfs
[11:17] <ogra> (talking about oem-config here)
[11:18] <ev_> okay
[11:18] <ogra> the system is a basic debootstrapped rootfs with a small amount of configuration (loopback interface, minimal fstab etc) but without user keyboard or timezone setup
[11:18] <ogra> the plan was to do these through oem-config which i preinstall by default
[11:18] <ogra> it runs fine ... but ...
[11:19] <ogra> it seems to forcefully go into tasksel at some point and tries to configure network etc and in the end it loops back to the beginning
[11:19] <ogra> though it apparently uses the settings i chose from debconf
[11:20] <ogra> i.e. the second run is in german, preseeds from the first run are set in the ui
[11:20] <ogra> am i missing something i.e. a preseed file that tells oem-config to actually write its stuff and remove itself ?
[11:21] <ogra> and how do i avoid the tasksel run
=== ev_ is now known as ev
[11:22] <ogra> oh, and on a sidenote installing the -gtk frontend pulls in fvwm1 by default (which is ok dpendency wise (metacity pulls in 300M of recommends) but didnt seem to run properly)
[11:23] <ev> ogra: you can remove /usr/lib/ubiquity/plugins/ubi-network.py and /usr/lib/ubiquity/plugins/ubi-tasks.py if you don't need them.
[11:24] <ogra> does that also affect the debconf ui ?
[11:24] <ev> yes
[11:24] <ogra> cool !
[11:24] <ogra> i'll probably keep network for the time server stuff ...
[11:24] <ogra> just occurs to me it might be helpful :)
[11:25] <ogra> how do i tell it to actually write the configs to disk and restart ?
[11:29] <ev> I'm confused as to what you're asking.  Once oem-config gets to the install component, it writes the configuration you've selected to the disk.  Please provide logs if it's not getting that far.
[11:29] <ev> (/var/log/oem-config.log, /var/log/syslog)
[11:30] <ogra> ok, it might be qemu being at fault, i didnt test the whole thing on real HW yet ... will do that today and we'll see
[11:30] <ogra> the qemu arm kernel for arm we use has a weird hack to emulate a v7 CPU on HW thats actually not capable of doing so
[11:30] <ogra> that might have bad sideeffects
[11:44] <CIA-52> ubiquity: evand * r3729 plugins-conversion/ubiquity/components/ubi-partman.py: Fix partition create dialog.
[12:16] <CIA-52> ubiquity: evand * r3730 plugins-conversion/gui/gtk/ (stepPartAdvanced.ui stepReady.ui ubiquity.ui): Move alignments to the right place.
[12:25] <CIA-52> ubiquity: evand * r3731 plugins-conversion/gui/gtk/ (stepPartAdvanced.ui stepReady.ui): It is not necessary to disable the minimize button for GTK+ dialogs, as it is done so automatically.
[13:50] <shtylman> cjwatson: thanks
[16:59] <ogra> ev, ok, finally got to test the thing on real HW, one obvious thing i see in the log (apart from locale errors) is:
[16:59] <ogra> grep: /target/etc/apt/sources.list: No such file or directory
[16:59] <ogra> indeed there is no /target dir on a oem system
[16:59] <ev> don't worry about that one
[16:59] <ogra> there is a traceback directly below ...
[16:59]  * ogra pastes
=== michaelforrest1 is now known as michaelforrest
[16:59] <ogra> http://paste.ubuntu.com/372590/
[16:59] <ogra> ev, ^^
[17:00] <ogra> and after that the whole app restarts and i have to re-select everything again
[17:01] <ogra> (thats with network and tasksel bits removed btw
[17:01] <ogra> )
[17:01] <ev> ogra: ah, can you file a new bug with that, so I can look at it in earnest tomorrow?  I have to leave shortly.
[17:01] <ogra> ok, will do, i just wanted to be sure its not me missing something
[17:02] <ev> thanks
[17:02] <ev> it's definitely a bug
[17:02] <ogra> since i dont use d-i to set up the system that could well be
[17:02] <ogra> ok
[17:03]  * ogra will try the gtk ui now ... and file bugs on the go if i see any
[17:29] <ogra> hmm, gtk even fails earlier, no log at all
[17:29] <ogra> seems like the DM doesnt come up
[17:34] <ogra> hmm, does oem-config-gtk essentially need an oem user being created in advance ? the code looks like its trying to start the -dm process with a username
[17:34] <cjwatson> yes
[17:34] <cjwatson> it assumes that that was created during installation
[17:34] <cjwatson> and indeed further that no ordinary user was created during installation
[17:35] <ogra> hmm, k, is there any documentation how to create this user ?
[17:35] <ogra> i wonder why the debconf frontend doesnt need it too ...
[17:36] <persia> ogra: Look at oem-config-prepare
[17:36] <cjwatson> no, oem-config-prepare doesn't do it
[17:36]  * persia fails
[17:36] <ogra> right
[17:36] <ogra> thats only touching a file that upstart reads on next boot
[17:36] <ogra> i already create that file in rootstock
[17:36] <cjwatson> no docs that I know of - try 'sudo adduser --uid 29999 oem'
[17:36] <ogra> ok
[17:38] <ogra> any specific password ?
[17:38] <cjwatson> doesn't matter
[17:38] <ogra> k
[17:38]  * ogra treis to boot that 
[17:39] <shtylman_> ev: how goes the plugin migration?
[17:39] <cjwatson> I'm confused about where the oem user is used right now, though
[17:39] <cjwatson> I can't actually find it dropping to that user any more
[17:40] <ogra> well, and i still see the same python backtrace on the screen
[17:40] <ogra> sadly it doesnt go into the log
[17:40] <ogra> hard to capture it ...
[17:41] <ogra> i think ubiquity-dm uses the user
[17:41] <cjwatson> maybe I just did that because you have to have *some* user created during installation
[17:41] <cjwatson> except it doesn't
[17:41] <cjwatson> we tell it 'root' as the username
[17:41] <ogra> oh
[17:41] <ogra> well, root exists with locked pw as it should be
[17:41] <cjwatson> what is the traceback?
[17:42] <ogra> let me try if i can capture it on a serial console
[17:42] <ogra> i dont have a separate monitor for my babbage so would have to actually write it down on paper and switch modes back and forth :)
[17:43] <cjwatson> the last couple of function names and line numbers, and the exception type would do
[17:45] <ogra> http://paste.ubuntu.com/372619/
[17:45] <ogra> voila
[17:45] <ogra> :)
[17:45] <ogra> dm.run(*sys.argv[4:]) made me suspect the user
[17:46] <ogra> though its probably more related to OSError: [Errno 2] No such file or directory
[17:48] <cjwatson> no X server installed
[17:48] <ogra> urgh
[17:48] <cjwatson> you wouldn't normally run ubiquity-dm for debconf_ui
[17:48] <ogra> i installed metacity ...
[17:48] <cjwatson> and oem-config-firstboot doesn't run ubiquity-dm in the debconf_ui case
[17:48] <ogra> indeed i didnt check it doesnt pull in X
[17:48] <cjwatson> so if you're trying to use debconf_ui, you're Doing It Wrong somehow :)
[17:48] <ogra> yeah, indeed
[17:48] <ogra> i had debconf ui
[17:49] <ogra> that had a looping bug i just filed
[17:49] <ogra> and now wanted to try the gtk ui
[17:49] <ogra> oh silly me, sorry for wasting your time
[17:49]  * ogra installs xorg
[17:49] <cjwatson> fwiw oem-config bugs should go on ubiquity now
[17:49] <ogra> oh, ok
[17:50] <ogra> the new deps are horrid though ... i liked the old oem-config a lot more in that regard
[17:51] <ogra> oem-config-gtk pulls in fvwm1 by default if you dont specify a perticular WM ... not sure you consider that a bug
[17:51] <ogra> (i know i produce very special usecases here anyway)
[17:54] <cjwatson> oem-config used to have pretty similar dependencies; attributing this to the merge is wrong
[17:54] <ogra> things like crypto-disks ?
[17:54] <cjwatson> from before the merge:
[17:54] <cjwatson> Package: oem-config-gtk
[17:54] <cjwatson> Depends: ${shlibs:Depends}, ${python:Depends}, oem-config (= ${binary:Version}), xserver-xorg, python-gtk2, python-glade2, python-cairo, metacity
[17:55] <ogra> that looks a lot smaller to what i get
[17:55] <cjwatson> x-window-manager is just more generic; deal with it :)
[17:55] <ogra> yeah, i will indeed
[17:55] <cjwatson> encrypted disks: yes, that's true; I'd prefer the guts to be in ubiquity-common
[17:56] <ogra> i'm not sure yet i'll use the gtk-ui at all ... all i need is TZ/lang/kbd and user setup
[17:56] <cjwatson> that would make more sense in some ways
[17:56] <ogra> and it somehow feels bloated to pull in X for it by default
[17:56] <cjwatson> for your use case it's probably more sensible to use debconf_ui, once we fix it
[17:56] <ogra> OTOH its tricky to find out if the user wanted X or just a minimal debootstrap for his arm board
[17:57] <ogra> well, if X and a WM are there and all of oem-config is removed cleanly, why not use it ... but its painful to decide in advance when i bootstrap the system
[17:58] <cjwatson> I'd be happy for us to try to shrink oem-config down a bit, if it's useful to your team
[17:58] <ogra> it definately is
[17:58] <persia> ogra: Can you use your tasksel interface to get a hint?  If some -desktop or -netbook task is installed, use an X gui?
[17:58] <ogra> i think the usecase for armel stuff will move more and more to cross-rolled images built by OEMs
[17:59] <cjwatson> so the question in that bug you filed is why it's touching install.py at all; that's ubiquity-only code
[17:59] <ogra> persia, i could even put the install of oem-config till very late in the build and check if xorg and a WM are there
[17:59] <ogra> strikes me ...
[17:59] <ogra> hmm, i'll do exactly that  :D
[17:59] <cjwatson> this is probably a regression introduced by superm1 converting Install to be a plugin
[17:59] <cjwatson> superm1: ^-
[17:59] <cjwatson> (bug 519398)
[17:59] <persia> ogra: That's even better.  You probably want to have some logic that does gtk/qt detection as well.
[17:59] <ubottu> Launchpad bug 519398 in ubiquity "oem-config with debconf frontent goes into endless loop" [Undecided,New] https://launchpad.net/bugs/519398
[18:00] <cjwatson> the approach taken by us in d-i is to select the oem-config frontend by preseeding
[18:00] <ogra> persia, yeah, thats easy, it just didnt occur to me that i could just run a second apt-get install after the rootfs is there and check whats installed
[18:01] <ogra> persia, so thanks for your question, it gave me the right idea :)
[18:02] <superm1> cjwatson, those changes were only made to gtk_ui
[18:03]  * ogra sees a oem-config screen \o/
[18:05] <ogra> looks awful when unthemed but it seems to do its job ...
[18:06] <ogra> hmm, does it expect K/GDM to be there at the end ?
[18:07] <ogra> it just loops as well now
[18:07]  * ogra grabs the log
[18:08] <ogra> argh
[18:08] <ogra> it wipes the log on restart it seems
[18:09] <cjwatson> superm1: hmm
[18:09] <ogra> nothing useful in there
[18:11] <cjwatson> ah, sorry, looks like maybe a regression due to the big merge
[18:12] <cjwatson> I'm obviously confused, since Install *is* meant to be called in oem-config - it just does less
[18:12]  * cjwatson blames having a wriggling child in his lap
[18:13] <ogra> http://paste.ubuntu.com/372649/ is the log thats left over after gtk-ui restarted
[18:14] <ogra> seems its removed before the new startup
[18:14] <ogra> since i ran through all steps
[18:14] <cjwatson> but PROGRESS REGION obviously can't work with debconf_ui
[18:15] <cjwatson> I'll abstract that, I guess
[18:15] <cjwatson> will make the code clearer anyway
[18:23] <ogra> can we have a change to not delete the log with the next upload so i can get some erros msg more easily for you guys ?
[18:38] <CIA-52> ubiquity: cjwatson * r3746 ubiquity/ (debian/changelog scripts/install.py): Don't issue PROGRESS REGION command under debconf_ui (LP: #519398).
[18:39] <cjwatson> ogra: which log are you seeing being deleted?  all the code I can find that writes to oem-config.log is careful to append
[18:48] <cjwatson> ogra: (if you answered, I missed it, sorry)
[19:57] <ogra> cjwatson, http://paste.ubuntu.com/372649/ has the full log after i went though a full oem-install-gtk run that restarted, thats after the restart and i would expect to simply have some more content in it
[20:03] <cjwatson> ogra: definitely not being erased - you can see that it has "Ubiquity 2.1.16 (oem-config)
[20:03] <cjwatson> " in there multiple times, which is only emitted at the start of a run
[20:04] <ogra> ah
[20:04] <cjwatson> ogra: you'll get more if you run in debug mode
[20:04] <ogra> well, then i wonder why its so empty
[20:04] <ogra> debconf is clearly more noisy
[20:04] <cjwatson> because you aren't running in debug mode :-)
[20:04] <ogra> yeah
[20:04] <ogra> understood
[20:04] <ogra> the last line is intresting though
[20:05] <ogra> given my HW doesnt deal with any grub stuff
[20:05] <cjwatson> fairly cosmetic, I'd expect
[20:05] <cjwatson> the code in question is run unconditionally
[20:05] <ogra> yes, likely, since thats at the start
[20:05] <ogra> i'll do some debug runs tomorrow
[20:05] <cjwatson> it doesn't imply that that bit of the UI is actually used
[20:06] <ogra> effectively it feels like it behaves the same as the debconf ui
[20:06] <cjwatson> is that a feature or a bug? :)
[20:07] <ogra> it seems to get a little further before restarting, but that might be caused by the separate progressbar that pops up
[20:07] <ogra> well, i mean the same in the way it restarts
[20:07] <ogra> :)
[20:07] <ogra> which would indeed be a bug
[20:08] <cjwatson> must be a different crash, since the one I just fixed is definitely specific to debconf_ui
[20:09] <cjwatson> exactly what command are you using to start it?
[20:09] <ogra> none, i boot the image
[20:09] <cjwatson> ok, and please confirm which log file you're looking at there?
[20:10] <ogra> in advance i run "touch /var/lib/oem-config/run" at the end of the image build
[20:10] <ogra> the log file is oem-config.log
[20:10] <ogra> in /var/log
[20:10] <ogra> so upstart starts it
[20:10] <cjwatson> please check if there's anything of interest in syslog
[20:11] <ogra> oh, a *lot* !
[20:19] <ogra> hmm, it seems to try to run update-initramfs
[20:19] <ogra> http://paste.ubuntu.com/372712/
[20:20] <ogra> but that doesnt seem to stop it ...
[21:19] <cjwatson> locking trouble?  odd
[21:26] <cjwatson> ogra: is libc6-vfp gone for good?  if so, there's an installer patch I can drop
[21:29] <cjwatson> ogra: configure_hardware might just be wrong for the oem-config case.  I think running *some* of it is deliberate but it might need some thought ...
[21:30] <cjwatson> and certainly, anything that involves debconf access there by reconfigured packages can never have worked since the merge, since it doesn't go to the effort of setting up a throwaway db
[21:30] <joshk> cjwatson: hey, what more useful information can be provided here? https://bugs.launchpad.net/ubuntu/+source/ubiquity/+bug/517797
[21:30] <ubottu> Ubuntu bug 517797 in ubiquity "apt does not time out during initial update" [Undecided,Incomplete]
[21:31] <joshk> i feel like it's pretty obvious what's going on
[21:31] <joshk> i can attach syslog but it just sounds like a waste of time
[21:31] <joshk> it's a regression from karmic and earlier, the same code still hangs on earlier releases but eventually times out, which is fine by me
[21:34] <cjwatson> joshk: gently larted bug triager and reassigned to apt
[21:35] <cjwatson> oh, and tagged regression-potential
[21:37] <cjwatson> nothing jumps out at me, mvo will have to look at this one
[21:47] <joshk> cjwatson: thank you!
[21:47] <joshk> yeah, 9.10 uses the same flag