[07:48] <jderose> xnox: sorry about that, didn't know what channel was appropriate :)
[07:48]  * jderose tries debug-ubiquity
[07:49] <xnox> jderose: well it's ok =) not sure what's worse doing context-less jump across channels or over-using #ubuntu-devel =)
[07:52] <infinity> Using ubuntu-devel for devel stuff is never wrong.  Just gets a bit noisy sometimes.
[08:15] <jderose> infinity: :)
[11:21] <xnox> cjwatson: re: bug #1237694, the culprit is ubi-ubuntuone.py plugin, which defines plugin_skip_page when offline, but i guess something/somewhere is not done right as the installer is stuck after completing plugin.py and doesn't progress to plugininstall.py.
[11:21] <ubot2> Launchpad bug 1237694 in System76 "Installation fails without Internet" [Critical,Triaged] https://launchpad.net/bugs/1237694
[11:21] <xnox> am I missing exiting a main-loop? or is it not possible to skip the last page?
[11:27] <cjwatson> My suspicion is the latter
[11:27] <cjwatson> I think something is missing a call to find_next_step
[11:28] <cjwatson> Possibly in this bit?
[11:28] <cjwatson>             if self.backup or self.dbfilter_handle_status():
[11:28] <cjwatson>                 if self.current_page is not None and not self.backup:
[11:28] <cjwatson>                     self.process_step()
[11:28] <cjwatson>                     if not self.stay_on_page:
[11:28] <cjwatson>                         self.pagesindex = self.pagesindex + 1
[11:28] <cjwatson> But if you change that, be careful to test backup
[11:28] <cjwatson> The frontend state machine is such a mess :-(
[12:32] <xnox> cjwatson: if i am skipping the last step, we should go to slideshow with no way to backup.
[12:32] <cjwatson> xnox: Yes, but I mean, that code handles backup in other circumstances too
[12:33] <xnox> ok.
[14:26] <xnox> 158 files changed, 72122 insertions(+), 43043 deletions(-), ouch.
[14:27] <xnox> most of it is debconf-updatepo bug #1235192
[14:27] <ubot2> Launchpad bug 1235192 in Ubuntu Translations "Strings in U1 window for 13.10 installer are not in pot file" [High,Triaged] https://launchpad.net/bugs/1235192
[14:27] <infinity> debconf-updatepo is a harsh mistress.
[18:02] <jderose> xnox: er, problem i just found with the oem-config fix... because that upstart job always runs, the "oem" user gets deleted the first time you install 2.15.23
[18:03] <jderose> xnox: so you can't do any image customization, provide QA workflow via the "oem" user, etc
[18:04] <jderose> so it needs to be conditional base on whether it's just a normal auto-login into the oem account, or whether we're actually running the end customer user config
[18:05] <jderose> or maybe the extra "userdel --once-more-with-feeling" needs to be somewhere other than the upstart script
[18:11] <jderose> or maybe systemd-ify ubiquity-dm, assuming systemd/logind/systemd-pam is the underlying culprit
[18:12] <jderose> in which case, also cry a little on the inside over the fact a systemd related fix is needed on a distro that doesn't uses systemd for init :P
[19:04] <infinity> Intrusive things like better logind integration probably won't happen.
[19:05] <infinity> But dropping a simple "we're done now" semaphore in /var/lib at the spot where the userdel *used* to be, and then guarding the init post-script userdel with a check for said sempahore file would work fine.
[19:05] <infinity> jderose: xnox ^
[19:05] <infinity> s/won't happen/won't happen for 13.10/
=== kentb-out is now known as kentb
[19:15] <jderose> infinity: what's the magic file that determins whether the customer config UI is run?
[19:16] <jderose> infinity: and yeah, i understand the "right" fix probably wont happen for 13.10, i'm just trying to understand how things work a bit better, what the underlying problem is :)
[19:16] <cjwatson> jderose: /var/lib/oem-config/run
[19:16] <cjwatson> could easily just check for that I expect?
[19:18] <jderose> cjwatson:  yeah, that's what i'm going try, same post-start, but with a test for /var/lib/oem-config/run
[19:20] <jderose> cjwatson: am i right that post-start should use the same [ -f /var/lib/oem-config/run ] condition as script? http://bazaar.launchpad.net/~ubuntu-installer/ubiquity/trunk/view/head:/debian/oem-config.oem-config.upstart
[19:22] <cjwatson> Mm, yeah, maybe post-start runs despite the script "failing" because of the "normal exit 0 1"
[19:23] <cjwatson> So yeah, certainly worth a try
[19:23] <infinity> Except invert the test.
[19:23] <infinity> You only want to remove the user if /run has been removed.
[19:24] <jderose> infinity: but then it will userdel oem whenever you boot the image prior to "Prepare for shipping to end user"
[19:24] <cjwatson> Oh, yeah, that's the problem
[19:24] <infinity> jderose: Ahh.  Hrm.  But /run will be removed before you get to that point.
[19:24] <cjwatson> /var/lib/oem-config/run will exist in neither case
[19:24] <cjwatson> So it's not a useful test
[19:24] <infinity> So, the extra semaphore would work better.
[19:24] <jderose> ah, okay
[19:25] <jderose> or setting a flag in side script/end script? I'm not super upstart savy... can you do that?
[19:25] <infinity> Wherever the userdel used to be, make that a touch /var/run/oem-config-remove and then test for it in post-start, userdel, and rm it.
[19:25] <cjwatson> I don't understand why this was done in an Upstart job, rather than in oem-config-firstboot
[19:26] <jderose> cjwatson: it was xnox's idea far a work-around as for whatever reason, userdel isn't working here - http://bazaar.launchpad.net/~ubuntu-installer/ubiquity/trunk/view/head:/bin/oem-config-wrapper
[19:27] <cjwatson> No, it can't be done in oem-config-wrapper because the display manager is still running, I expect
[19:27] <jderose> if you remove the "|| true", line 14 is always failing
[19:27] <cjwatson> But oem-config-firstboot is outside that
[19:27] <infinity> Ahh, yes.  firstboot looks like the right place.
[19:27] <infinity> It even knows if the installation was successful.
[19:27] <infinity>         if [ "$CODE" -eq 0 ]; then
[19:27] <infinity>                 exit 0
[19:27] <infinity> The userdel should go in that block.
[19:28] <infinity> Before the exit, obviously. :P
[19:28] <cjwatson> Yep
[19:28] <jderose> infinity: cjwatson: so oem-config-firstboot runs during the *customer* first boot then?
[19:28] <cjwatson> Right
[19:28] <cjwatson> # Run oem-config on the first boot after shipping to the end user.
[19:28] <infinity> Actually, it needs to be sprinkled a few places in here.
[19:29] <jderose> so, should the userdel bit be in oem-config-wrapper at all?
[19:29] <cjwatson> infinity: Probably not - oem-config-wrapper was only ever running it on success
[19:29] <cjwatson> jderose: I suspect not
[19:29] <infinity> cjwatson: Yeah?  Okay.  I would have also put it in the panic section at the end.
[19:29] <cjwatson> Oh, there's another reason it doesn't work - Mario changed that script to run as the oem user :P
[19:29] <infinity> cjwatson: Since the panic section essentially duplicates oem-config-remove.
[19:30] <cjwatson> So it can't deluser/userdel
[19:30] <cjwatson> infinity: Maybe, yeah, in the oem-config/remove == true case
[19:30]  * infinity nods.
[19:31] <cjwatson> And we should go back to deluser if possible
[19:31] <cjwatson> +  * Remove oem user with userdel rather than deluser (the latter didn't support
[19:31] <cjwatson> +    doing it while oem was logged in) (LP: #624888)
[19:31] <cjwatson> that should no longer apply
[19:31] <ubot2> Launchpad bug 624888 in ubiquity (Ubuntu) "if oem user is logged in more than one tty when oem-config is set up, the oem user is never completely removed" [Undecided,Fix released] https://launchpad.net/bugs/624888
[19:31] <cjwatson> Oh, maybe it does, from that bug description
[19:31] <cjwatson> OK, leave it at userdel
[19:31] <cjwatson> even though it makes me feel dirty
[19:31] <jderose> hehe
[19:32] <jderose> cjwatson: so at some point things are running as root, then su oem, then that process exists.... shouldn't the usedel oem be right after the su oem process exists? also, where would that be? :)
[19:33] <jderose> *exits*, then no longer exists :P
[19:33] <cjwatson> jderose: oem-config-wrapper (nowadays, though not when I originally put the user deletion there) runs as oem.  oem-config-firstboot runs as root and the bit we're pointing at is "right after".
[19:34] <jderose> okay, gotcha... so the block at line 121? http://bazaar.launchpad.net/~ubuntu-installer/ubiquity/trunk/view/head:/bin/oem-config-firstboot
[19:34] <cjwatson> It's slightly more complicated, on inspection.  One moment
[19:35] <jderose> cjwatson: infinity: thanks for all the help!
[19:35] <cjwatson> jderose: Something like http://paste.ubuntu.com/6223900/ ?
[19:35] <cjwatson> I don't have time to test this evening
[19:36] <jderose> cjwatson: i'll test in in a moment, got a vm ready for this very thing...
[19:36] <cjwatson> Great
[19:53] <jderose>  cjwatson: hmm, no luck. good: it no longer removes oem user when it shouldn't; bad: it no longer removes oem user when it should
[19:54] <jderose> although i manually edited the files in place, so i might have made a goof
[19:54] <jderose> cjwatson: you have this in a branch already?
[19:54] <jderose> if so, i'll do a build from there, test that way
[19:55] <jderose> (er, i edited the installed files rather than building the package)
[19:57] <infinity> cjwatson: oem-config remove runs before this, doesn't it (on a successful install), so your debconf check on RET=0 probably won't work, if the templates were purged.
[19:57] <infinity> That check probably only makes sense in the panic section, where we still might have oem-config/ubiquity installed because it broke.
[20:20] <cjwatson> infinity: oh could be, might need to remember that in a file somewhere then :/
[20:20] <cjwatson> no more time to work on this today I'm afrad
[20:20] <cjwatson> +i
[20:23] <jderose> cjwatson: thanks again for the help, i'll poke around at this more over the weekend, see if i can come up with something
=== kentb is now known as kentb-out