[08:28] <ev> Thanks for the fixes, stgraber
[12:26] <jibel> auto login is gone again on latest ISOs bug 837165
[12:26] <ubot2`> Launchpad bug 837165 in ubiquity ""Log in automatically" option in Ubiquity not honored by LightDM" [High,Confirmed] https://launchpad.net/bugs/837165
[12:55] <ev> jibel: thanks, will get on that one today
[13:00] <ev> could've sworn there was a bug for the timezone map not defaulting to a location
[13:00] <ev> but I can't find it
[13:00] <ev> hm
[13:00] <CIA-31> ubiquity: evand * r4901 trunk/ (debian/changelog ubiquity/plugins/ubi-timezone.py): Set the timezone location to the default.
[13:24] <ev> oh yay, lightdm doesn't support a custom.conf
[13:28] <jibel> ev, timezone without default location bug 830940
[13:28] <ubot2`> Launchpad bug 830940 in ubiquity "Where are you: No location selected by default" [Medium,Confirmed] https://launchpad.net/bugs/830940
[13:31] <ev> ah thanks
[13:32] <CIA-31> ubiquity: evand * r4902 trunk/debian/changelog: Add LP bug reference.
[13:36] <stgraber> ev: yeah, the current way of doing things is to directly modify /etc/lightdm/lightdm.conf (which isn't shipped by any package)
[13:36] <stgraber> ev: I already did that in casper, so I can have a look at doing it in ubiquity too if that helps
[13:37] <ev> it's shipped by lightdm
[13:37] <stgraber> oh, is it now?
[13:37] <ev> dpkg -S /etc/lightdm/lightdm.conf
[13:37] <ev> lightdm: /etc/lightdm/lightdm.conf
[13:37] <stgraber> stgraber@castiana:/etc/lightdm$ dpkg -S /etc/lightdm/lightdm.conf
[13:37] <stgraber> dpkg-query: no path found matching pattern /etc/lightdm/lightdm.conf.
[13:37] <ev> apparently so :-/
[13:37] <ev> interesting
[13:38] <stgraber> I know it used to, but I think robert dropped it so we can just generate it to set whatever defaults we need
[13:38] <ev> oh, I'm a few versions behind
[13:38] <ev> awesome
[13:39] <stgraber> the postinst script actually moves lightdm.conf using dpkg-maintscript-helper when upgrading from very old version of the package. So it's possible dpkg thinks it's maintained if you upgrade from an old version of the package.
[13:39] <stgraber> my laptop is running a clean install from last week and was updated yesterday
[13:40] <stgraber> ev: so, want me to look at adding some lightdm.conf generation/update code to ubiquity? :)
[13:40] <ev> that's okay, already on it
[13:40] <ev> cheers though
[13:40] <stgraber> ok, cool
[13:40] <ev> welcome to tackle any of the rest of these though: https://bugs.launchpad.net/ubuntu/oneiric/+source/ubiquity  :)
[13:43] <stgraber> yeah, syncing all my images at the moment.
[13:44] <stgraber> you don't happen to know how gtk css is working, do you? I spent/wasted a lot of time yesterday afternoon poking at bug 830923 :)
[13:44] <ubot2`> Launchpad bug 830923 in ubiquity "Create partition: FS and mount point lists not legible" [High,Confirmed] https://launchpad.net/bugs/830923
[13:44] <stgraber> I know where the bug is, just can't figure out the right way of fixing that css...
[13:46] <stgraber> gtk's lack of documentation (especially 3.0 + gi) is starting to get really annoying...
[13:46] <ev> yeah, welcome to my hell over the past few months
[13:46] <ev> it might be easier to just rework the actual UI, so that we can apply the CSS to a child of the window rather than the window itself
[13:47] <ev> as I can't find a way to not have children inherit the properties of the parent
[14:05] <kyleN> stgraber, initial result is that ubiquity 2.7.20 fixed the problem. that is I have a first boot into oem-config.
[14:12] <superm1> ev, for the user-setup fix, could you plan to just adopt something like what casper does?  a bunch of derivatives that use lightdm do ship a file and the casper method does it correctly for both scenarios
[14:12] <ev> superm1: already doing just that
[14:12] <ev> just verifying the fix:
[14:12] <superm1> cool
[14:12] <ev> http://paste.ubuntu.com/678006/
[14:13] <superm1> that will be fine for mythbuntu, xubuntu will need to add a commented out #autologin-user= line to their default conf
[14:14] <superm1> charlie-tca, ^ any opinions there
[14:14] <stgraber> kyleN: good to hear
[14:14] <stgraber> ev: http://paste.ubuntu.com/678010/ works for me but is a bit ugly. Should I commit that for now?
[14:14] <ev> stgraber: yeah, do
[14:14] <ev> thanks
[14:14] <kyleN> stgraber, can oem-config be told to run full screen?
[14:17] <stgraber> kyleN: no idea, sorry
[14:17] <charlie-tca> Yet another late change to lightdm?
[14:18] <ev> kyleN: not without modification to ubiquity
[14:18] <stgraber> ev, superm1: Too bad dealing with ini files in shell is a pain. Would have been quite easy to make something clean in python (as in, only change the required entries, add the sections when missing, ...) :)
[14:19] <kyleN> ok
[14:19] <ev> patches welcome, should be fairly straightforward
[14:19] <kyleN> it seems (and always has) a little cramped
[14:19] <kyleN> I imagine its just a gtk window setting
[14:20] <ev> stgraber: indeed, but for our shell pain we largely get someone else dealing with many of the lower level bits
[14:20] <ev> kyleN: ubiquity is locked to a specific size at the moment because of bugs in a text wrapping workaround and, if memory serves, the way the user setup page is laid out
[14:20] <superm1> actually stgraber's method of just >>'ing into the file from casper might be better for user-setup
[14:21] <superm1> is the text wrapping still really a problem with gtk3 and pygi?
[14:21] <ev> these can probably go away with the move to GTK3, but probably in Peachy
[14:21] <kyleN> ev, yes, gtk has never donw a great job with text wrapping
[14:21] <kyleN> gtk 2
[14:22] <superm1> kyleN, if you ship less languages in your pool or image and turn on the option to only show installable languages, the first page fits more nicely
[14:22] <charlie-tca> So, what effect does this have on the beta1 images?
[14:22] <charlie-tca> Do we have to get a patch in to be able to use them ?
[14:22] <ev> superm1: I don't see the difference between >> + sed and cat <<EOF, can you elaborate?
[14:23] <kyleN> superm1, how do I: create that pool, and: turn on that option to only show installable? we have our own mechanisms for that that but if it is supported out of the box we should probably use that
[14:23] <superm1> ev, sed'ing depends on the #autologin-user being there.  xubuntu uses lightdm-set-default-session or so so they can't easily add commented out lines in their postinst
[14:24] <superm1> kyleN, i have no idea how you build your apt pool, only show installable languages is a preseedable option
[14:25] <kyleN> i can make an on-disk apt archive for lang packs. (we already do). We have a seperate program that runs after oem-config to install the one for the lang the user selected.
[14:26] <kyleN> superm1, but if oem-config already supports that, I'd like to know so we can consider migrating to this approach
[14:27] <superm1> oh yeah you don't need to run a separate program after that to install the language.  that's what oem config will do.  maybe something to clear the apt archive of the stuff you didn't need though
[14:28] <superm1> in my scenario all the languages stay on a recovery partition in case they recover later they get a chance to reinstall with all the same languages
[14:31] <kyleN> superm1, where does oem=config expect to find that on-disk archive? Can the location be preseeded?
[14:31] <superm1> oem-config doesn't look in a specific location currently, it expects to be part of the apt cache currently.
[14:32] <superm1> you can add it to the apt-cache as a source in /etc/apt/sources.list.d/ and apt-get update in an early command
[14:35] <kyleN> interesting.
[14:35] <kyleN> our code does that too. and later we delete the on-disk archive, to free up space
[14:36] <kyleN> superm1, how does oem-config know which lang packs to install (they vary by lang)
[14:36] <kyleN> (and by installed pkgs in the system)
[14:36] <superm1> the language you pick on the first page will tell it which packs to install
[14:37] <kyleN> for a given langauge, there are different sets of lang packs that need to be unstalled to support the current system.
[14:37] <superm1> can you elaborate on what you mean with an example?
[14:38] <kyleN> i wonder, does it use the check-language-support tool (from language-selector-common)?
[14:38] <kyleN> yes
[14:38] <kyleN> for example, chinese langs reqiure input method pkgs, whereas French does not.
[14:38] <kyleN> each language has different sets of writing aid packages as well
[14:38] <superm1> yeah the chinese langs also install the input method pkgs
[14:38] <jibel> ev, bug 837288 on session start after an OEM installation.
[14:39] <ubot2`> Launchpad bug 837288 in ubiquity "oem-config-remove-gtk crashed with SystemExit in _on_failure(): 1" [Medium,New] https://launchpad.net/bugs/837288
[14:39] <kyleN> in addition, let's say you don'e have gnome installed, then you don't need to install the language-pack-gnome-XX pkg
[14:39] <jibel> ev, I don't see any side effect though
[14:39] <kyleN> so the way to find the lang packs that should be installed for the Current system and Current langauges is with check-language-suport
[14:39] <kyleN> p
[14:39] <ev> jibel: awesome
[14:39] <kyleN> and I wonder if oem-config uses that
[14:39] <ev> will look into it
[14:40] <kyleN> Current Langauge (not plural)
[14:40] <superm1> kyleN, it does use check-language-support
[14:40] <kyleN> nice
[14:40] <kyleN> i can't type my way out of a paper bag some days ;)
[14:40] <superm1> look at ubiquity/install_misc.py to see how it works
[14:40] <kyleN> thx
[14:41] <jibel> ev, and on DVDs, there is no 'prepare for shipping' shortcut nor launcher during an OEM install
[14:46] <stgraber> ev: starting to poke at bug 771401. I'll probably end up setting a maximum size of 8GB for any given install, that should be safe with our current images (even our biggest DVD should fit in that)
[14:46] <ubot2`> Launchpad bug 771401 in ubiquity "Ubiquity disk requirements are excessive" [Medium,Confirmed] https://launchpad.net/bugs/771401
[14:47] <jibel> oem-config packages are not on DVDs
[14:47] <jibel> or at least not installed
[15:09] <ev> superm1: looking at the code for lightdm-set-defaults, I fail to see how it helps us here.  My code is busted though
[15:10] <ev> just wondering if it's worth the pain to do a check for the variable being set and either set it or write it for each one using sed and grep for lack of a better set of tools
[15:12] <stgraber> jibel: do you remember seeing that issue while testing? bug 807636
[15:12] <ubot2`> Launchpad bug 807636 in ubiquity "ubiquity doesn't show console when clicking in detailed view" [Medium,Triaged] https://launchpad.net/bugs/807636
[15:13] <superm1> ev, the code for lightdm-set-defaults doesnt' really help here, but i was meaning it might just be easiest to copy the casper code
[15:13] <superm1> it works for all the necessary scenarios
[15:14] <jibel> stgraber, this issue is fixed, but in return you win bug 830946
[15:14] <ubot2`> Launchpad bug 830946 in ubiquity "Nothing displayed on embedded terminal." [Medium,New] https://launchpad.net/bugs/830946
[15:14] <stgraber> jibel: great...
[15:14] <stgraber> can we revert to having it not display anything, that issue seemed easier to fix ;)
[15:15] <charlie-tca> superm1: Xubuntu is not shipping any lightdm.conf file
[15:16] <superm1> charlie-tca, yeah you are, the postinst creates it
[15:16] <superm1> via lightdm-set-defaults
[15:17] <stgraber> edubuntu probably doesn't though, we only call lightdm-set-defaults if the user explicitly chooses to go with gnome session fallback
[15:29] <kyleN> hi folks. I dropped two oem-config pluging pages into place (and preseeded them). it worked in natty. now I get this bug: 837288
[15:30] <kyleN> specifically this line in /var/log/oem-config.log:  Pango-WARNING **: error opening config file '/root/.pangorc': Permission non accordée
[15:30] <kyleN> (in english)
[15:30] <ev> don't worry about that one
[15:31] <kyleN> ev, how do I get past it so I can test/use my plugins?
[15:31] <ev> the pango warning, that is
[15:31] <ev> it always comes up
[15:31] <kyleN> ok. so it is something else that is dying now that I've added my two plugins.
[15:31] <ev> I'm looking into that bug next
[15:31] <ev> correct
[15:31] <kyleN> ok
[15:33] <kyleN> ev: ah, global name 'Gtk' is not defined (in gtk_ui.py)
[15:34] <stgraber> kyleN: if 'DISPLAY' in os.environ: from gi.repository import Gtk, Gdk, GObject
[15:34] <stgraber> kyleN: do you have DISPLAY in your environment?
[15:35] <kyleN> stgraber, well, I can't get to a tty to check after the crash or before it.
[15:36] <kyleN> i am testing in a kvm vm.
[15:36] <superm1> the DISPLAY check is so that oem-config -q works
[15:36] <kyleN> however, when I boot in recovery mode, and echo $DISPLAY, it is not defined
[15:37] <kyleN> superm1, do you think the vm is implicated?
[15:37] <kyleN> i can test on hw
[15:37] <kyleN> if sensible
[15:38] <superm1> DISPLAY will only be in the environment if you're running in X, so you won't have DISPLAY in recovery mode
[15:38] <kyleN> right.
[16:11] <ogra_> hmm, is CIA broken or is it my local setup ?
[16:16] <CIA-31> ubiquity: evand * r4905 trunk/ (d-i/manifest debian/changelog):
[16:16] <CIA-31> ubiquity: Automatic update of included source packages: user-setup
[16:16] <CIA-31> ubiquity: 1.28ubuntu19.
[16:17]  * ev kicks CIA-31 
[16:17] <CIA-31> ow
[16:17] <ev> he's alive, ogra_
[16:17] <ogra_> bah, then my side is broken ;(
[16:18] <ogra_> (i touch these branches so rarely i dont even know when it broke)
[16:33] <CIA-31> ubiquity: evand * r4906 trunk/debian/changelog: releasing version 2.7.21
[17:02] <bdmurray> ev: Does the syslog info regarding ubiquity no longer have the oem-config string in it?
[17:04] <bdmurray> it used to say something like this with oem-config also in it
[17:04] <bdmurray> Aug 29 21:13:58 ubuntu ubiquity[2829]: Ubiquity 2.7.17
[17:14] <ev> bdmurray: what would that give you?
[17:14] <ev> when oem-config is running it writes to /var/log/oem-config.log
[17:14] <bdmurray> ev: well I was tagging bugs oem-config
[17:14] <ev> so you could just look fro that
[17:14] <ev> for*
[17:15] <bdmurray> ev: okay, thanks
[17:20] <CIA-31> ubiquity: evand * r4907 trunk/ (3 files in 3 dirs): Add back accidentally deleted build_timezone_list call.
[17:23] <kyleN> stgraber, superm1, after a few python changes, my plugin pages work and all is well. thx
[17:29] <superm1> cool
[17:30] <kyleN> by the way, the main fix was to 'from gi.repository import Gtk' instead of simple import gtk (my head still swims in natty land ;)
[17:33] <superm1> yeah all plugins need to be converted to pygi now,
[17:40] <CIA-31> ubiquity: evand * r4908 trunk/debian/changelog: releasing version 2.7.22
[18:02] <CIA-31> ubiquity: evand * r4909 trunk/ (bin/oem-config-remove-gtk debian/changelog):
[18:02] <CIA-31> ubiquity: Use the correct API for manipulating the finished dialog for oem-
[18:02] <CIA-31> ubiquity: config-remove-gtk.
[18:10] <CIA-31> ubiquity: evand * r4910 trunk/debian/changelog: releasing version 2.7.23
[18:11] <superm1> ev, that fix is importing both gtk2 and gtk3 though no?
[18:12] <ev> argh, damn
[18:12] <ev> AptProgressDialog seems to use gtk2 internally
[18:12] <superm1> it shouldn't i'd think?  it's being imported from the aptdaemon gtk3widgets collection
[18:13] <ev> yeah, I'm screwing this up somehow
[18:13] <ev> don't have time to investigate though as I have a gig to get to
[18:13] <ev> but I've asked pitti to kill that version
[18:57] <CIA-31> ubiquity: superm1 * r4911 ubiquity/ (bin/oem-config-remove-gtk debian/changelog): Use only gtk3 in oem-config-remove-gtk (2.7.23 was also using gtk2).
[19:04] <CIA-31> ubiquity: superm1 * r4912 ubiquity/ (debian/changelog src/panel/panel.c): Update the directory for the panel to search for indicators.
[19:04] <CIA-31> ubiquity: superm1 * r4913 ubiquity/debian/changelog: releasing version 2.7.24
[23:04] <CIA-31> debian-installer: cjwatson * r1525 ubuntu/debian/changelog: releasing version 20101020ubuntu60