[06:06] <didrocks> good morning!
[07:02] <pitti> Good morning
[07:17] <didrocks> hey pitti
[07:19] <pitti> bonjour didrocks
[07:43] <jibel> good morning
[07:44] <didrocks> salut jibel!
[07:45] <jibel> bonjour didrocks !
[08:59] <chrisccoulson> good morning everyone
[09:02] <Laney> morrrrrrrrrrrning
[09:04] <Sweetshark> seb128: btw https://bugs.launchpad.net/ubuntu/+source/libreoffice/+bug/1037111/comments/38, I hope this is not blocking on anything anymore.
[09:04] <ubot2> Ubuntu bug 1037111 in libreoffice (Ubuntu) "[SRU] LibreOffice 3.5.7 for precise" [High,Confirmed]
[09:04] <Laney> seb128: SRUs> Fix Committed is for "this package is in -proposed", and I don't believe that subscribing ubuntu-sru is necessary
[09:04] <Laney> https://wiki.ubuntu.com/StableReleaseUpdates#Procedure
[09:05] <Laney> https://wiki.ubuntu.com/StableReleaseUpdates#Reviewing_procedure_and_tools says that the accepting tools will do that
[09:05] <Sweetshark> bonjour, goooOOOOood morning, moin a tous!
[09:06] <seb128> hey desktopers
[09:06] <Laney> morning ;-)
[09:06] <seb128> Sweetshark, re 3.5.7, nothing needed/blocking, 12.04.2 was released yesterday but I expect they will resume copies to -updates soon (maybe not today because it's friday though)
[09:07] <seb128> Laney, oh ok, I'm old school again, I should re-read those documents every 6 months to pick the changes to the processes :p
[09:07]  * Laney got re-educated by someone a few months ago
[09:11] <Sweetshark> seb128: k, thanks
[09:15] <didrocks> salut seb128, Laney, Sweetshark :)
[09:15] <didrocks> and chrisccoulson ;)
[09:15] <chrisccoulson> hi didrocks, seb128, Laney, Sweetshark
[09:15] <seb128> hey didrocks, chrisccoulson
[09:15] <seb128> how is everyone doing today?
[09:15] <seb128> happy friday!
[09:16] <seb128> it has been snowing again here, there is like 15 cm of snow on the ground
[09:16] <didrocks> still UTAH not behaving as excepted, so, same sort of thing throughout the week
[09:16] <seb128> didrocks, :-(
[09:19]  * Sweetshark loves his radio paradise playing "while my guitar gently weeps" ...
[09:37] <Laney> hmm
[09:37] <Laney> didrocks: if the autolanding is borked, can/shall I upload libappindicator manually?
[09:37] <didrocks> Laney: no, I'm forcing an update now
[09:40] <Laney> ok, that's a useful capability
[09:43] <didrocks> Laney: yeah :) I wish I wouldn't have to use it though :p
[09:44]  * xnox bzr commit --unchanged ;-)
[09:45] <didrocks> xnox: hey, did you see my comment on the MP btw?
[09:45] <didrocks> for oneconf
[09:45] <didrocks> xnox: seems barry rebased it now, so you only need to refresh your debian/changelog
[09:46] <didrocks> xnox: also, when ubiquity is copying the logs to the home directory, does it wait for the late_command to finish?
[09:46] <didrocks> xnox: we have a case where in the ~, we don't have those copied
[09:47] <didrocks> xnox: where /var/log/syslog contains everything :)
[09:47] <xnox> logs to the home directory - sounds odd, we copy logs to /var/log/installer/*
[09:47] <xnox> we copy logs to /target/var/log/installer/*
[09:47] <xnox> that is.
[09:47]  * xnox checks the code
[09:48] <didrocks> xnox: ah, so something else is doing the copy to the home dir?
[09:48] <didrocks> like ~/installer_syslog
[09:48] <xnox> sounds like utah thing =)
[09:48] <didrocks> possibly :)
[09:49] <didrocks> thought you had a dark and hidden feature for oem/preseeded mode :p
[09:49] <xnox> didrocks: also. in ubiquity we don't have late_command (that's a d-i thing) we have ubiquity/success_command
[09:49] <didrocks> xnox: sorry, I meant success_command
[09:50] <didrocks> late_command is then used, for other things ;)
[09:58] <xnox> looks like we copy_logs before running late_command, but not sure.
[09:58] <xnox> s/late/success/ ;-)
[10:00] <didrocks> xnox: "we" being ubiquity or utah ;)
[10:01]  * xnox uses ubiquity as principal hat
[10:01] <didrocks> ok :)
[10:01] <didrocks> xnox: can you please keep me posted?
[10:01] <xnox> also about oneconf: i saw email about missing commits, didn't notice the update branch yet.
[10:07] <jibel> xnox, actually there is a success_command that copies /var/log/syslog and after installation when you compare this copy with /var/log/installer/syslog, /var/log/installer/syslog is shorter
[10:19] <chrisccoulson> woohoo, http://bazaar.launchpad.net/~mozillateam/firefox/firefox-trunk.head/revision/1540
[10:38] <seb128> chrisccoulson, nice! but still using dbusmenu :p
[10:38] <chrisccoulson> seb128, well, it needs to work on 12.04 (and GMenuModel still can't do icons) ;)
[10:39] <seb128> right
[10:45] <seb128> Sweetshark, https://launchpad.net/ubuntu/precise/+source/libreoffice/1:3.5.7-0ubuntu4
[10:45] <seb128>  1:3.5.7-0ubuntu4
[10:45] <seb128> PUBLISHED: Precise pocket Updates in component main and section editors
[10:45] <seb128> Sweetshark, well done! ;-)
[10:45] <Sweetshark> seb128: \o\ /o/
[10:46] <Sweetshark> timing is perfect: now if there is any issue with it, Ill get physical abuse for it next week in london. ;)
[10:47] <seb128> you know your team! :p
[10:54] <pitti> bonjour seb128
[10:54] <seb128> pitti, salut, ca va ?
[10:55] <pitti> est-ce que tu sais -- où est mon indicateur de bluetooth?
[10:55] <pitti> seb128: je vais bien, merci! mais ma femme est malade :(
[10:55] <seb128> pitti, dpkg -l indicator-bluetooth ?
[10:56] <pitti> martin    2542  0.0  0.1 515584  5672 ?        Sl   08:00   0:00 /usr/lib/x86_64-linux-gnu/indicator-bluetooth/indicator-bluetooth-service
[10:56] <pitti> seb128: oh, it's running, I just don't see it
[10:56] <pitti> started yesterday
[10:56] <pitti> I mean the bug started yesterday, I did see the indicator until yesterday
[10:56] <seb128> pitti, do you have bluetooth hardware?
[10:57] <pitti> seb128: I don't have my headphones nor my mobile's BT on right now, but even if I do it doesn't appear
[10:57] <seb128> pitti, ta femme est malade ? qu'est-ce qu'elle a ?
[10:57] <pitti> bluetoothd is running, too
[10:57] <seb128> pitti, gsettings get com.canonical.indicator.bluetooth visible
[10:57] <pitti> seb128: she's had a cold on and off in the past three weeks, and it got much worse yesterday
[10:57] <seb128> :-(
[10:57] <pitti> seb128: true
[10:58] <pitti> seb128: so it seems you don't know that it's an intended change or so; I'll try with a new user / debug in more detail
[10:59] <pitti> hm, my permanent test user doesn't even have a message indicator
[10:59]  * pitti creates a fresh one
[10:59] <seb128> pitti, no, it's not an intended change
[10:59] <Sweetshark> pitti: bon retablissement a ta femme
[11:00] <seb128> pitti, we recently added support for that gsettings key to hide it, but that's true for you
[11:00] <pitti> Sweetshark: merci!
[11:01] <pitti> no, same with a fresh user -- bt and msg indicators are missing
[11:01] <seb128> oh, msg as well
[11:01] <seb128> starts sounding like an unity/indicator stack issue
[11:01] <pitti> hm, wait
[11:01] <seb128> what updates did you get in the last round?
[11:01] <pitti> $ sudo hcitool  dev
[11:02] <pitti> Devices:
[11:02] <pitti> $
[11:02] <pitti> that's not good
[11:02] <seb128> pitti, https://code.launchpad.net/~robert-ancell/indicator-bluetooth/only-show-when-adapter-present/+merge/147248
[11:02] <pitti> [   12.844516] Bluetooth: hci0 command 0x0c56 tx timeout
[11:02] <seb128> pitti, that landed recently; it hides the indicator if no hardware is available
[11:02] <pitti> seb128: ok, so that confirms that this part is working then, and it's a kernel prob
[11:02] <seb128> pitti, so that's likely what's happening for you
[11:02] <pitti> new kernel?
[11:03] <pitti> I got a new one this morning, rebooting
[11:04]  * Sweetshark is slightly worried about the airport personal strikes and what it means for getting to london on sunday.
[11:04] <pitti> seb128: ooh, je le sais!
[11:05] <seb128> pitti, c'est de ta faute ?
[11:05] <pitti> seb128: so, you know that you can disable BT in the indicator, right? that enables the "soft" kill switch
[11:05] <pitti> seb128: once you do that, the indicator goes away
[11:05] <seb128> oh
[11:05] <seb128> and you can't get it back
[11:05] <pitti> since raring, the soft kill switch isn't very permanent any more
[11:06] <pitti> sometimes after reboot it remembers, but often it doesn't and switches back to "on"
[11:06] <seb128> I guess it should consider no hardware and disabled differently
[11:06] <pitti> so after this reboot it was a case where it was back to on
[11:06] <pitti> but now I don't have an indicator to re-enable it
[11:06] <seb128> I see
[11:06] <seb128> you can probably do it from g-c-c ?
[11:07] <pitti> $ cat /sys/class/rfkill/rfkill0/{type,state}
[11:07] <pitti> bluetooth
[11:07] <pitti> 0
[11:07] <pitti> $ cat /sys/class/rfkill/rfkill0/soft
[11:07] <pitti> 1
[11:07] <pitti> it should probably look at that
[11:07] <seb128> pitti, it's weird, if I disable bluetooth from the indicator the indicator stays but as greyed here
[11:07] <pitti> yes, when I re-enable BT from g-c-c, the indicator comes back
[11:08]  * pitti files bug report
[11:08] <pitti> so regression from bug 1116289
[11:08] <ubot2> Launchpad bug 1116289 in indicator-bluetooth (Ubuntu) "Bluetooth menu appears when there are no Bluetooth adapters" [Medium,Fix released] https://launchpad.net/bugs/1116289
[11:09] <seb128> pitti, I'm still unsure why it behaves different for you
[11:14] <pitti> seb128: filed bug 1126108, sub'ed robert-ancell
[11:14] <ubot2> Launchpad bug 1126108 in indicator-bluetooth (Ubuntu) "0.0.6 regression: disappears entirely when disabling BT" [Undecided,New] https://launchpad.net/bugs/1126108
[11:15] <seb128> pitti, I can't confirm that, it's just greyed for me
[11:15] <seb128> when I disable bluetooth from g-c-c or the indicator
[11:15] <seb128> but it's not hidden
[11:16] <pitti> seb128: not sure what it's looking at
[11:16] <pitti> rfkill or bluetoothd's dbus objects, or sysfs
[11:16] <seb128> pitti, I was trying to understand https://code.launchpad.net/~robert-ancell/indicator-bluetooth/only-show-when-adapter-present/+merge/147248
[11:16] <seb128> bluetooth_service._visible = client.adapter_model.iter_n_children (null) > 0;
[11:16] <pitti> /sys/class/bluetooth/ is empty for me when I soft-rfkill
[11:18] <pitti> that's from bluetooth-client.h
[11:19] <pitti> seb128: if you disable it, do you still see something in "sudo hcitool dev" and/or /sys/class/bluetooth/ ?
[11:19] <seb128> $ sudo hcitool dev
[11:19] <seb128> Devices:
[11:19] <seb128> $
[11:19] <seb128> $ ls /sys/class/bluetooth/
[11:19] <seb128> hci0
[11:19] <seb128> $
[11:20] <pitti> right, I don't have that when it's killed
[11:21] <seb128> well, it any case it seems like the code to detect if hardware is present or not is not clever enough
[11:21] <seb128> I wonder if that's possible to make the difference from the client side though
[11:21] <pitti> right, it needs to look at rfkill in addition
[11:21] <pitti> seb128: I updated the bug, thanks for checking
[11:21] <seb128> pitti, danke!
[11:29] <Sweetshark> seb128: https://bugs.launchpad.net/ubuntu/+source/libreoffice/+bug/628105/comments/40 btw
[11:29] <ubot2> Ubuntu bug 628105 in libreoffice (Ubuntu Quantal) "[Upstream] Text not black in LibreOffice" [Undecided,In progress]
[11:31] <seb128> Sweetshark, thanks!
[12:16] <GunnarHj> seb128: Hi Sebastien! Can you please take a look at bug 1126149.
[12:16] <ubot2> Launchpad bug 1126149 in ibus-chewing (Ubuntu) "Version in raring-proposed dependent on ibus 1.5" [Undecided,New] https://launchpad.net/bugs/1126149
[12:17] <seb128> GunnarHj, hey, see happyaron's comment (he just added it)à
[12:17] <GunnarHj> seb128: Wow, he was fast! :)
[12:18] <seb128> happyaron, hey, why do you need a rebuild because of sid? we don't do binary updates in Ubuntu, just source ones
[12:18] <happyaron> :)
[12:18] <seb128> so what is in sid shouldn't impact us
[12:18] <happyaron> seb128: at that time ibus 1.5 was uploaded to Sid, then ibus-chewing, so it picks up ibus >= 1.5 in generated dependencies
[12:19] <happyaron> ibus-chewing should work with ibus 1.4.2, which we want to keep in Raring, and a rebuild is needed to get everything correct (symbols, depends)
[12:19] <seb128> happyaron, how are the depends generated? if it's at build time it should have picked 1.4 since that's what raring has and what it built with in Ubuntu
[12:20] <happyaron> seb128: ibus 1.5 was auto synced to raring-proposed, I'm not sure whether ibus-chewing will build agaist which version of ibus (release or proposed). Also I need double check if it's hard coded in d/control...
[12:21] <seb128> happyaron, no, it was not, https://launchpad.net/ubuntu/+source/ibus
[12:21] <happyaron> ok, hard coded one.
[12:21] <seb128> happyaron, the only things autosynced are the ones without Debian diff
[12:21] <seb128> Ubuntu diff rather
[12:21] <happyaron> I see.
[12:21] <happyaron> http://anonscm.debian.org/gitweb/?p=pkg-ime/ibus-chewing.git;a=blob;f=debian/control;h=100461e697f582fed346477d0b7940ee5c3ef1cd;hb=HEAD
[12:22] <seb128> if we have changes somebody needs to merge manually
[12:22] <seb128> happyaron, can you just do an upload to Ubuntu with the fix?
[12:22]  * Sweetshark loves building libreoffice in a 32GB tmpfs with ccache ....
[12:22] <happyaron> seb128: sure, but I need test if ibus-chewing really works in VM. recently ibus-table's changes make me a little nervous.
[12:23]  * seb128 things that "love" "libreoffice" and "build" don't go in a same sentence
[12:23] <seb128> happyaron, ok, otherwise I guess we can upload a new.is.old tweaked version
[12:23] <happyaron> ok
[12:24] <happyaron> seb128: if it doesn't work, can we just drop it from proposed? (from the archive side)
[12:25] <GunnarHj> happyaron: Any news about bug 1101836?
[12:25] <ubot2> Launchpad bug 1101836 in im-switch (Ubuntu) "Needs to keep hands off when removed but not purged" [Undecided,Incomplete] https://launchpad.net/bugs/1101836
[12:26] <GunnarHj> happyaron: If there is an issue we should deal with it fast, since it could affect quite a few im users.
[12:26] <happyaron> GunnarHj: the file is modified by the user.
[12:26] <seb128> happyaron, we can yes but I think in this case the next upload will need an higher version that the one dropped
[12:26] <happyaron> seb128: thanks
[12:26] <Laney> I don't think higher but just that that specific version can't be used
[12:26] <Laney> AFAIK
[12:26] <GunnarHj> happyaron: Ok, that's what I suspected.
[12:27] <happyaron> GunnarHj: I don't know the impact of such problem, i.e. how many users may have edited it.
[12:27] <Laney> GunnarHj: I need you!
[12:27] <GunnarHj> happyaron: No, it's not easy to estimate...
[12:27] <GunnarHj> Laney: How? Why?
[12:27] <Laney> GunnarHj: Do you know how to register new IMs with im-config? In this case maliit
[12:27] <happyaron> GunnarHj: there is no migration, and if the file isn't known then the input methods are left in a broken state.
[12:28] <happyaron> Laney: patch im-config
[12:28] <Laney> urg, really?
[12:28] <happyaron> yes
[12:28] <happyaron> there is no registration stuff in im-config anymore, those information is maintained by im-config itself.
[12:28] <GunnarHj> Laney: I think that the im-config docs include some guidance.
[12:29] <Laney> I found loads of huge shell scripts that I didn't really understand
[12:29] <happyaron> :)
[12:29] <happyaron> upstream prefers that way, once I offered to rewrite some of them in C/python, but get gentlely refused.
[12:30] <Laney> bah
[12:32] <happyaron> Laney: I wonder what's the plan for maliit? for phones?
[12:34] <ogra_> happyaron, forst for the nexus7 image we ship since a while
[12:34] <ogra_> *first
[12:34] <seb128> happyaron, we are evaluating options, onboard is nice but it's also python and that's not really mobile friendly
[12:35] <happyaron> ogra_ seb128 thanks
[12:35] <Laney> right, currently just trying to make sure it's integrated properly
[12:35]  * ogra_ hasnt gotten around to it yeat, but also wanted to take a look at florence
[12:36] <Laney> anyway I didn't get IM activation working yet
[12:36] <seb128> ogra_, have enough of the german winter you want to try italy? ;-)
[12:36] <Laney> even with im-switch, so ho hum
[12:36] <ogra_> haha
[12:36] <ogra_> yeah, i woudl love to  :)
[12:36] <GunnarHj> happyaron: Back to im-switch ... How about dropping the md5sum check in im-config? Or would the policy guards scream then?
[12:37] <happyaron> GunnarHj: they sure will scream at Debian, but I doubt that in Ubuntu, ;-)
[12:37] <Laney> some people would
[12:37] <Laney> are you saying it mangles config files of another package?
[12:37] <happyaron> yup
[12:37] <GunnarHj> happyaron: I think there are good arguments in this case. 80im-switch isn't really a config file.
[12:38] <happyaron> GunnarHj: I understand and totally agree.
[12:38] <Laney> why don't you fix im-switch to just do nothing if it's not installed?
[12:38] <Laney> those Xsession things are just shell scripts aren't they ?
[12:38] <GunnarHj> Laney: Too late.
[12:38] <happyaron> Laney: what if someone didn't update im-switch and just upgrade to Raring...
[12:39] <Laney> partial upgrades aren't really something we can support anyway
[12:39] <happyaron> the problem is that 80im-switch will have the effect even the package is removed (not purged)
[12:39] <Laney> add a line to the top of it to exit if im-switch is in that situation
[12:40] <Laney> exit 0
[12:40] <ogra_> err
[12:40] <ogra_> dont add exit statements to Xsession scripts, they are not executed but sourced
[12:40] <Laney> ah
[12:42] <GunnarHj> happyaron, Laney, ogra_: So do we just wait and see what happens then?
[12:42] <happyaron> Laney: we need to make sure the file is gone when im-config is configured, either purging im-switch, or removing the file in im-config. Or input method related variables will be in sorry state.
[12:43] <happyaron> GunnarHj: and we know how many people manually edited that file...
[12:43] <ogra_> oh, that will mean a lot of fun with ucf for you then, if people changed it you will get prompts on upgrades
[12:43] <ogra_> since its a conffile
[12:43] <Laney> I'm saying that you can make it do nothing if im-switch is removed
[12:44] <Laney> it being sourced makes that more grim though - I can't think of an elegant way to bail out of that
[12:45] <Laney> does return work?
[12:45] <happyaron> what about release note?
[12:45] <GunnarHj> Laney: The smartest way would be to let im-config do it without bothering about whether the file was modified.
[12:45] <ogra_> you cant, its a conffile
[12:45] <didrocks> ogra_: is the nexus7 image broken? I tried to reinstall the image from the 14th, after the ubuntu plymouth logo, nothing…
[12:45] <GunnarHj> ogra_: Not really.
[12:46] <ogra_> didrocks, yes, trying to find out whats going on there since yesterday already
[12:46] <ogra_> GunnarHj, not really what ?
[12:46] <didrocks> ogra_: ah ok, not on my end then, thanks :-)
[12:46] <Laney> ah, it seems you can 'return' out of a sourced script
[12:46] <ogra_> GunnarHj, dpkg considers every file under /etc a conffile
[12:46] <Laney> not exactly
[12:47] <Laney> but indeed this one is
[12:47] <GunnarHj> ogra_: It's in /etc, but it's executed. And after a transition to im-config noone will care about 80im-switch.
[12:47] <ogra_> it isnt executed
[12:48] <Laney> if it's sourced you can 'return' out of it
[12:48] <Laney> so check if im-switch is removed but not purged and reutrn if so
[12:48] <ogra_> (and it is actually supposed to say so at the top)
[12:48] <happyaron> Laney: but who to update that file?
[12:48] <Laney> one of you two?
[12:49] <Laney> oh, you mean because the package is removed?
[12:49] <Laney> you can SRU it
[12:49] <ogra_> http://wiki.debian.org/DpkgConffileHandling
[12:49] <Laney> also I just noticed that this is the reason I couldn't test maliit with im-switch
[12:49] <GunnarHj> Are we talking about SRUs in quantal, precice, oneiric... then
[12:49] <ogra_> the runes you will need in your maintainer scripts for removing it
[12:49] <Laney> because you trash the config file in im-config my im-switch configuratino wasn't being applied
[12:50] <happyaron> SRU could be to late...
[12:50] <Laney> you can't reinstall im-switch and have it work ...
[12:50] <GunnarHj> Laney: Why?
[12:50] <Laney> dpkg thinks that I deleted it intentionally
[12:51] <Laney> so doesn't install it again
[12:51] <GunnarHj> Laney: If you purge first, you should be able to install it.
[12:51] <Laney> indeed
[12:51] <happyaron> just tell users sudo dpkg -P im-switch, done. No more im-switch and let's use im-config...
[12:53] <GunnarHj> happyaron: Maybe SRU of some exit code is an option, after all, if just we could have somebody sponsor it rapidly.
[12:54] <happyaron> agreed
[12:55] <Laney> I can add im-switch to your packageset if you want
[12:55] <GunnarHj> We need somebody with full privileges to proposed and updates, then.
[12:55] <happyaron> Laney: not sure if that sufficent for SRU..
[12:55] <Laney> it can be
[12:56] <Laney> we'll have to get someone to copy the packageset back to the stable releases you want to upload to, but that's easy
[12:56] <GunnarHj> Sounds promising.
[12:56] <Laney> if you mail devel-permissions asking for this to be added I will do the needful with the DMB
[12:57] <happyaron> I don't think there will be SRU for other packages, so if someone (say, Laney?) can sponsor im-switch then no need to be this complex.
[12:58] <Laney> if you like
[12:59] <Laney> point me to the bug when you have it filled out with patches and the SRU information then
[12:59] <happyaron> ok
[12:59] <happyaron> thank you.
[13:00] <GunnarHj> happyaron: We are talking about something like:
[13:00] <GunnarHj> test -x /usr/bin/im-switch || exit 0
[13:00] <GunnarHj> right?
[13:01] <happyaron> not "exit 0", but almost, yes.
[13:01] <GunnarHj> Why not "exit 0"?
[13:01] <ogra_> because Xsession.d files arent executed
[13:01] <happyaron> it will stop Xsession startup.
[13:02] <GunnarHj> Aha.
[13:03] <GunnarHj> happyaron: Are you going to do it?
[13:03] <happyaron> GunnarHj: I'm okay, but need next Monday. I've finished my holidays and preparing to travel back to Beijing.
[13:04] <happyaron> (Chinese lunar new year)
[13:04] <GunnarHj> happyaron: Won't be a problem, if you just get the necessary backup from Laney etc.
[13:05] <happyaron> ok
[13:05] <GunnarHj> New year? :)
[13:06] <didrocks> ogra_: FYI, the image from the 13th as well, but I guess you know it :)
[13:07] <ogra_> err, its not
[13:07] <didrocks> ogra_: do you know which latest image is fine?
[13:07] <didrocks> ah
[13:07]  * didrocks checks
[13:07] <ogra_> all current images are unusable
[13:07] <ogra_> the last working one was from the 11th
[13:07] <happyaron> yup, lunar new year, today is the last day of this official holiday, :)
[13:07] <didrocks> ogra_: do you have a link to it?
[13:07] <ogra_> and i'm still hunting for the change that caused it
[13:08] <ogra_> didrocks, we only keep 3 dailies
[13:08] <didrocks> ogra_: at least, no unity upload due to UTAH mostly (and now tests), so not me \o/
[13:08] <ogra_> (since we dont do milesstones anymore, the last working ones are now gone)
[13:08] <didrocks> not fun :/
[13:08] <GunnarHj> happyaron: Thanks for that cultural lesson. :)
[13:08] <ogra_> didrocks, no, its the installer or something related to starting ubiquity-dm
[13:08] <happyaron> GunnarHj: :)
[13:09] <ogra_> didrocks, yes, we need a solution for the future for this
[13:10] <ogra_> didrocks, i think cjwatson brought up to keep one image per month that has been tested or so ...
[13:11] <didrocks> ogra_: yeah, or something running basic tests and the image candidates for being "latest good" if those tests pass
[13:11] <ogra_> hard to do on a device like the nexus7
[13:11] <didrocks> I guess, autoinstalling is hard :/
[13:11] <ogra_> (you cant really check if the display works for example ... or the touchscreen)
[13:12] <ogra_> you can indeed do preseeded installs
[13:12] <didrocks> indeed, but at least, a basic test sshing and running some stuff
[13:12] <ogra_> but they wont tell you if user interaction is possible
[13:12] <didrocks> (like autopilot)
[13:12] <didrocks> will help for a first pass
[13:12] <ogra_> i think thats something plars works on atm
[13:12] <didrocks> ok
[13:13] <ogra_> but for a monthly "milestone" we need at least one manual test on such devices
[13:13] <didrocks> yeah
[13:13]  * ogra_ would like to know why his evo on raring is crashing all day today ... it worked flawless the last weeks
[13:32] <jibel> seb128, do you know if anyone's working on gnome-settings-daemon 3.6.4-0ubuntu6 build failure on armhf?
[13:33] <seb128> jibel, no, I didn't notice it failed, I just retried it
[13:33] <jibel> seb128, thanks
[13:33] <seb128> jibel, it hit a gcc error, with some luck that was transient
[13:33] <seb128> jibel, thanks for pointing it
[13:41] <ogra_> seb128, hmm, ubiquity-dm seems to have started failing to start on the 12th ... i wonder if https://launchpadlibrarian.net/131004748/gnome-settings-daemon_3.6.4-0ubuntu4_3.6.4-0ubuntu5.diff.gz could have something to do with it
[13:43] <seb128> ogra_, g-s-d is not even used for the installer mode iirc
[13:43] <ogra_> i.e. if we dont enable xrandr in the dm session
[13:44] <ogra_> how do we get gtk themeing then ?
[13:44] <ogra_> i thought g-s-d handles that in the installaer too
[13:44] <seb128> custom ubiquity hacks
[13:44] <ogra_> ok
[13:44] <seb128> no, xnox was looking at displayed the wallpaper the other day I think
[13:44] <seb128> xnox, ^ confirm or not?
[13:44] <seb128> displaying*
[13:44] <ogra_> yeah, thats not in the code yet
[13:45] <seb128> he said he could use the g-s-d plugin since ubiquity doesn't use gsd
[13:45] <seb128> couldn't*
[13:45] <seb128> doh, it's friday, I'm tired :p
[13:45] <ogra_> yeah, i'm voting for using the compiz plugin anyway
[13:46] <seb128> ogra_, you are trying to figure out what update broke the installer? can you change vt to look at what is running?
[13:46] <xnox> seb128: g-s-d is started by ubiquity.
[13:46] <seb128> xnox, oh, I though you said you couldn't use it to display the background because you don't depends on g-s-d
[13:47] <xnox> seb128: we depend on it conditionally - e.g. xubuntu/lubuntu doesn't but it's lower priority at this point.
[13:47] <seb128> ok
[13:47] <ogra_> seb128, no VTs once the driver detected that X attempted to start
[13:47] <seb128> ogra_, so I was wrong
[13:47] <ogra_> ok
[13:47]  * xnox was not entirely clear last time we chatted seb128 
[13:47] <seb128> xnox, thanks
[13:47] <xnox> so my fault really.
[13:47] <ogra_> so if we wouldnt have the xrandr plugin enabled ... i wonder if that would make it fall over with this patch
[13:48] <seb128> xnox, is there any way to disable a gsd plugin/change a gsetting key before ubiquity starts?
[13:48] <seb128> xnox, from a current image I mean, without rebuilding one
[13:49] <xnox> yes, we have hooks directory, but it probably will be a bit late.
[13:49] <xnox> let me check.
[13:51] <xnox> drop executable into: /usr/lib/ubiquity/dm-scripts/install or /usr/lib/ubiquity/dm-scripts/oem
[13:51] <xnox> (oem for nexus7 and the like)
[13:52] <xnox> filename cannot have '.' in it.
[13:52] <xnox> so one can change gsettings there as gsd is not started yet.
[13:53] <seb128> ogra_, ^
[13:53] <seb128> xnox, thanks
[13:56] <desrt> morning, peeps
[13:56] <seb128> desrt, hey, how are you?
[13:56] <desrt> xnox: did you fix that raring image tar problem?
[13:56] <desrt> seb128: okay
[13:57] <desrt> yourself?
[13:57] <seb128> jibel, the g-s-d retry on armhf worked
[13:57] <seb128> desrt, I'm good thanks ;-)
[13:57] <xnox> desrt: nexus7 raring image tar - we revert it all, but it may or may not fixed the underlying problem. ogra_ ?!
[13:57]  * desrt wants to get his nexus reinstalled before next week...
[13:57] <ogra_> xnox, it unpacks fine thats not the issue
[13:59] <ogra_> there is a) a /tmp/.X0-lock file that seems to already be in the tarball (or i'm to slow to recognize a failed X startup) and b) there are g-s-d changes that i suspect to play bad
[13:59] <Sweetshark> Bill was really bitten by the George H bug today. While my guitar gently weeps in the original and the ukulele version and now here comes the sun in the live version all in a few hours.
[13:59] <desrt> ogra_: i guess this issue i have is not a g-s-d one since X is not even starting
[14:00] <mterry> Sweetshark, what conversation did I log into here?
[14:00] <mterry> Sweetshark, oh, btw.  In those libreoffice MIRs, you mention an email thread with Rene.  Is that public?
[14:00] <ogra_> desrt, thats the point :)
[14:01] <Sweetshark> mterry: woops. wrong channel. Anyway: you should all listen to radioparadise.com or dubstep.fm. back to the usual progam.
[14:02] <mterry> :)
[14:02] <mterry> Sweetshark, I do like radioparadise
[14:03] <Sweetshark> mterry: saw your ping, but you were offline. Nope, its private. I will follow up on those, but need to recheck.
[14:04] <ogra_> desrt, g-s-d uses consolekit and dbus ... and with the recent rotation patches it  is suppsed to wait until the xrandr plugin writes something to the bus ... my suspicion is that this holds up X startup
[14:05] <ogra_> and makes it fail at some point
[14:05] <mterry> Sweetshark, I just wanted to see his explanation that the hardening-no-fortify warnings were ignorable.  If you can tell me what he said, that's fine
[14:06] <desrt> ogra_: i'm confused -- you're saying g-s-d starts before X?
[14:06] <ogra_> desrt, g-s-d is started by ubiquity-dm
[14:07] <desrt> ogra_: unless you disabled a bunch of plugins, that's not gonna work...
[14:07] <ogra_> i think we do
[14:17]  * ogra_ grumbles about evo ... 
[14:17] <ogra_> so running it from a terminal to see if it prints anything when crashing it indeed stops to crash
[14:20] <xnox> mterry: hardening-no-fortify lintian warnings have a lot of false positives =/
[14:21]  * xnox usually does a full debug build and inspects the build-log
[14:22] <mterry> xnox, yar, even the lintian tag page for it says so
[14:22] <mterry> xnox, but in which case, ideally there's an override  :)
[14:24] <xnox> ogra_: ubiquity-dm start X if fails we try "safe" X config -> we initiate consolekit session (wait) -> run hooks -> start session dbus -> start dconf, gconf, wallpaper app -> start window manager (compiz) -> launch g-s-d -> launch fake-panel app
[14:24] <xnox> desrt: seb128 ^
[14:25] <xnox> then start loads of other applets (e.g. nm, bluetooth etc)
[14:27] <ogra_> hmm
[14:28] <ogra_> does safe xconfig mean we execute xdiagnose to find that config ? there were changes too
[14:28] <ogra_> ah, no]
[14:28] <desrt> why would you start dconf?
[14:28] <ogra_> was uploaded yesterday, cant be at fault
[14:28] <ogra_> desrt, isnt teher a daemon ?
[14:29] <ogra_> i know gconf had one
[14:29] <desrt> yes.  but it should not be running
[14:29] <desrt> and i doubt you need to start gconf either
[14:29] <desrt> these things get activated by dbus
[14:29] <xnox> desrt: we check if it's available on the path and start. It's very cargo-culted.
[14:29] <ogra_> well, i think there is a lot of old and rather obsolete code in ubiquity
[14:29] <xnox> desrt: are you sure all those things get dbus actived in Xubuntu/Lubuntu/Mythbuntu/etc. ?
[14:29] <desrt> the normal state for the dconf service is that it is _not_ running
[14:30] <desrt> xnox: yes... if something is bus activated or not does not depend on desktop environment
[14:30] <desrt> it depends only on the dbus-daemon running
[14:30] <ogra_> i know in pre-dbus times we had to fire up gconfd
[14:30] <xnox> ok.
[14:30]  * xnox takes a note to rip that code out and see if stuff still works.
[14:30] <ogra_> and i think even that code is still there (unused though)
[14:32] <ogra_> but back to my question ...
[14:32] <ogra_> if https://launchpadlibrarian.net/131004748/gnome-settings-daemon_3.6.4-0ubuntu4_3.6.4-0ubuntu5.diff.gz is applied (which it is)
[14:32] <ogra_> and xrandr plugin is disabled or nonexistent ... could g-s-d hang in a wait state ?
[14:33] <ogra_> (and thus hold the whole startup process)
[14:34]  * xnox learns about xsetbd
[14:34]  * xnox learns about xsetbg
[14:34] <ogra_> heh
[14:34] <ogra_> oldschool
[14:34] <xnox> well why do we have three re-writes of wallpaper app in ubiquity (wallpaper, python-qt one and the old-one) when there is xsetbg?
[14:34] <ogra_> xnox, qiv is the new variant of it
[14:35] <ogra_> qiv -x /path/to/wallpaper.png
[14:36] <ogra_> xnox, xloadimage would have to move to main for xsetbg
[14:37] <ogra_> xnox, and i think xserbg is pretty limited in formats it can use ... i would go for qiv if you really want to move to a new tool
[14:37] <xnox> ogra_: and handwritten implemented thing is somehow "more" supportable right?!
[14:37] <ogra_> not saying that
[14:38] <ogra_> but if we go with a new external tool i'd not go with xsetbg
[14:38] <ogra_> oh, but wait ... xloadimage is maintained by elmo
[14:38] <ogra_> that makes it worth including it
[14:38] <ogra_> :)
[14:39]  * xnox likes the idea of putting elmo on the critical path in the installer
[14:39] <ogra_> yeah
[14:39] <ogra_> xloadimage also has fewer build deps
[14:40] <ogra_> (less formats though. but jpeg and png are there)
[14:40] <Laney> looks orphaned to me
[14:40] <ogra_> npot sure how good the zoom is though
[14:40] <xnox> ogra_: qiv is gtk2 which is too heavy for kubuntu and gtk2-less future
[14:40] <ogra_> Laney, well, we have it in the archive still
[14:41] <ogra_> xnox, right, just noticed that when reviewing the deps
[14:41] <ogra_> and even gtk2
[14:41] <ogra_> which we dont want
[14:41] <Laney> i'm sure we do, but "maintained by elmo" doesn't seem correct
[14:41] <Laney> looks like he did do in the past though
[14:41] <ogra_> well, it is what the original maintainer field says
[14:42]  * xnox will just do a bit of qa uploads =)
[14:42] <ogra_> oh
[14:42] <Laney> is dead upstream, orphaned
[14:42] <ogra_> i should have checked on raring :P
[14:42] <Laney> fun mir ;-)
[14:42] <ogra_> Original-Maintainer: Debian QA Group <packages@qa.debian.org>
[14:42] <ogra_> not elmo anymore
[14:43] <ogra_> (i looked on precise)
[14:44]  * Laney always checks the PTS for such things
[14:44] <Laney> pretty sure that is my most visited website after launchpad.net/ubuntu/+source/<stuff>
[14:45] <ogra_> heh
[14:45]  * ogra_ uses apt 
[14:45]  * xnox gives ogra_ a web-browser
[14:45] <ogra_> heh
[14:58] <xnox> between qiv and xloadimage: xloadimage doesn't scale the default wallpaper correctlya and there are white borders on my dual screen rig.
[14:58] <xnox> qiv on the otherhand gets everything right.
[15:06] <Sweetshark> woha thanks raring for gracing the screen of my vm with colorful ASCII art after update/reboot.
[15:08] <happyaron> unity just hang after installing vbox guest addtions... yeah vm again...
[15:11] <ogra_> Sweetshark, thats an early easteregg ;)
[15:44] <xnox> dobey: new pyflakes in raring-release pocket should be on the mirrors near you in less than half an hour
[15:48] <dobey> xnox: thanks!
[16:06] <GunnarHj> happyaron: still there?
[16:08] <happyaron> GunnarHj: yes
[16:09] <GunnarHj> happyaron: Considering that we actually changed 80im-switch not long ago, are there reasons to fear that many users have editied the file _after that_?
[16:10] <xnox> qiv is damn good
[16:10] <happyaron> GunnarHj: To be honest, I don't think people will normally edit that file, since there aren't any tweakable items in.
[16:11] <GunnarHj> happyaron: So, would the SRU thing be do overdo it?
[16:11] <happyaron> GunnarHj: but there are people who have touched it, I'm just wondering what to do for them. Just leave themselves deal with the situation or we can do anything for them.
[16:11] <happyaron> GunnarHj: a bit, and may not be that effective.
[16:12] <GunnarHj> happyaron: Dropping md5sum would be 100% effective.
[16:13] <GunnarHj> happyaron: But maybe that fight wouldn't be worth it.
[16:14] <GunnarHj> happyaron: Or would it?
[16:14] <happyaron> there's doubt for policy guards
[16:14] <happyaron> actually it's the only thing I'm in doubt.
[16:16] <GunnarHj> happyaron: Can we drop the md5sum check in Ubuntu only?
[16:17] <GunnarHj> happyaron: After all it's in Ubuntu im-switch/im-config is provided by default.
[16:17] <happyaron> GunnarHj: if it's okay for us to take the risk of someone screaming about policy then, yes.
[16:18] <Laney> why are you so averse to conffile prompts?
[16:18] <GunnarHj> Laney: Not what you mean now.
[16:18] <happyaron> Laney: it's not prompts, but silently set several variables for you then make input method does not work.
[16:18] <GunnarHj> sure
[16:19] <Laney> but you know how to stop it doing that
[16:19] <GunnarHj> Laney: The way we discussed earlier isn't 100% safe.
[16:19] <Laney> it's pretty bad that im-config doesn't even back up the file it removes btw
[16:20] <GunnarHj> Laney: We can't be sure that people update before dist-upgrade.
[16:21] <GunnarHj> Laney: As long as it hasn't been modified, why is that an issue?
[16:21] <happyaron> But if it's modified... then it's our question now.
[16:22] <Laney> it's an issue if it makes dpkg not put it back if I decide I want im-switch again (and if you do remove that md5sum check)
[16:23] <GunnarHj> Laney: Aha, it's going back to im-switch that worryies you. Then don't. ;-)
[16:23] <GunnarHj> happyaron, Laney: Then: drop the md5sum check in Ubuntu and backup the file if present?
[16:24] <Laney> anyway if you /really/ want (I'm not sure I'd worry about it) you could have im-config insert the guard
[16:24] <Laney> I'd say that is preferable to removing the file
[16:24] <happyaron> Laney: you mean insert to 80im-switch?
[16:24] <Laney> right
[16:24] <Laney> it's probably still policy violating but still less objectionable imho
[16:25] <happyaron> perhaps a better idea. if [ -x /usr/bin/im-config ]; then...
[16:25] <GunnarHj> Sounds like a very nice idea.
[16:26] <Laney> I'm only so keen on this because the current implementation made me waste time by breaking im-switch
[16:27] <happyaron> Laney: forget about im-switch, it makes all dbus based IMF not starting reliably.
[16:28] <Laney> if it's that bad you should have it removed
[16:28] <happyaron> I know little about maliit/onboard, but im-switch is definately a worthy target for dropping from the archive. We are planning to do that in Debian after Wheezy...
[16:29] <GunnarHj> happyaron, Laney: dropping md5sum check, _edit_ 80im-switch if present - can we sell that to Debian, or should we do that in Ubuntu only?
[16:30] <Laney> if you have a robust patch then probably
[16:30] <Laney> im-switch should be fixed too of course (while it still exists)
[16:30] <happyaron> I can talk with Osamu about it.
[16:30] <Laney> happyaron: Kubuntu still appears to use im-switch btw
[16:30] <happyaron> Laney: thanks for the info, don't they use language-selector?
[16:31] <Laney> they got rid of it
[16:31] <happyaron> I see.
[16:31] <Laney> not sure what they use instead
[16:31] <Laney> probably some KDE thing
[16:31] <happyaron> ok
[16:32] <GunnarHj> Laney: I changed the seed for everyone _but_ kde when preparing the transition. We should probably give them a hint.
[16:34] <Laney> yep, feel free
[16:36] <GunnarHj> Laney: Will do.
[17:08] <seb128> xnox, you really though that "eog can't open the default wallpaper" was not filled before? ;-)
[17:08]  * seb128 dups from bug #172416
[17:08] <ubot2> Launchpad bug 172416 in eog (Ubuntu) "eog determines image type from filename" [Low,Triaged] https://launchpad.net/bugs/172416
[17:09] <xnox> seb128: who knew =) failing to draw the default wallpaper started only in raring
[17:09] <seb128> hehe
[17:21] <chrisccoulson> seb128, what time are you arriving on sunday?
[17:33] <seb128> chrisccoulson, I will be at the hotel around 7:30-8pm
[17:33] <seb128> chrisccoulson, you?
[17:33] <chrisccoulson> seb128, i'm getting the train in the afternoon, so i think i'll be there around 3:30ish
[17:37] <chrisccoulson> i hope we can get nice beer not too far from the hotel
[17:37] <chrisccoulson> i'm tempted to bring some of my own ;)
[17:40] <Sweetshark> bdrung: woha! that was quick. ;)
[17:41] <seb128> chrisccoulson, I'm sure London has some decent pubs ;-)
[17:42] <Laney> xnox will show us the local sights ;-)
[17:42] <jcastro> post work Steam testing fellas: http://www.gametracker.com/server_info/54.243.8.249:27015/
[17:42] <jcastro> it'll run all weekend.
[17:43] <seb128> jcastro, nice!
[17:43] <xnox> chrisccoulson: yes.
[17:43] <xnox> Laney: yes.
[17:43] <xnox> Laney: are you in next week?
[17:43] <Laney> yep
[17:43]  * xnox notes down to work from the office next week
[17:44] <Laney> i mean no
[17:44]  * Laney runs
[17:44] <Laney> :P
[17:44] <seb128> xnox, desktop team is having a sprint at the office next week
[17:45] <chrisccoulson> all the awesome people will be there
[17:49] <Sweetshark> bdrung: how/why does setting --libdir= evade the lintian warning?
[18:02]  * didrocks waves good evening, week-end and see you on Sunday evening for most of you! :)
[18:03] <Laney> bye!
[19:00] <mpt> Hey glatzor!
[19:01] <glatzor> hey mpt !
[19:01] <mpt> How's things?
[19:01] <glatzor> mpt, how are you?
[19:01] <mpt> I am hungry.
[19:01] <glatzor> mpt, fine. I am getting back to normal life.
[19:01] <mpt> Is that a good thing, or a letdown?
[19:02] <glatzor> mpt, I am in the lucky position to see a lasagne in front of me backing in the stove :)
[19:03] <glatzor> mpt, to a normal geek life :)
[19:03] <mpt> glatzor, yum. So I suppose now would be completely the wrong time to bother you about a bug? ;-)
[19:03] <glatzor> mpt, it will still take 10 minutes :)
[19:04] <mpt> I'll take that as a "go ahead"
[19:04] <glatzor> mpt, it would be nice if we could talk about the future of s-c and aptdaemon.
[19:04] <mpt> sure
[19:05] <mpt> glatzor, so, USC is not the only graphical UI for installing software -- the Dash is doing it now too
[19:05] <glatzor> mpt, that was my assumption too
[19:06] <mpt> Which means, it would be more economical and consistent, if edge-case stuff like handling conflicts and errors was in aptdaemon widgets rather than USC.
[19:06] <glatzor> mpt, it would be nice if we could make use of the packagekit session api. so we could do all the stuff in session-installer
[19:06] <mpt> So that USC, the Dash, and Software Updater all benefit.
[19:06] <mpt> sure
[19:06] <mpt> I don't really understand where aptdaemon stops and sessioninstaller begins
[19:07] <glatzor> mpt, unity/dash should monitor the system packagekit/aptdaemon interface generally.
[19:07] <glatzor> mpt, the problem with dash is that I would like to avoid having a new API
[19:08] <mpt> okay
[19:08] <mpt> I have no idea what, if any, API the Dash uses
[19:08] <glatzor> a new API to install software :) since we already have got aptdaemon API, the system and session API of packagekit
[19:08] <glatzor> mpt, AFAIK mvo wrote a small helper script.
[19:08] <mpt> ok
[19:09] <mpt> didrocks should be able to point you at the right person, at least
[19:09] <mpt> Meanwhile, at the UI design level, I have been moving stuff from <https://wiki.ubuntu.com/SoftwareCenter#installing> etc to <https://wiki.ubuntu.com/SoftwarePackageOperations>
[19:09] <glatzor> mpt, It would be nice if unity could listen to package management tasks by default and always represent it. so if unity sees a package installation happening on the system it would show a progress bar in the sidebar
[19:10] <mpt> glatzor, that would be nifty indeed.
[19:10] <glatzor> mpt, so it would be nice if the graphically representation of package operation would not depend on the client which triggered the operation
[19:10] <mpt> Currently we have the exact opposite -- USC shows tasks that are being done by other programs, which isn't really what we want.
[19:10] <mpt> (in the "Progress" screen)
[19:11] <glatzor> mpt, uhhh sorry. the lasagne is ready!
[19:11] <mpt> glatzor, I was going to say, the ten minutes is nearly up :-)
[19:11] <glatzor> mpt, I will be hanging around here later too
[19:12] <glatzor> I will write an email to you and didi
[19:12] <glatzor> see you
[19:12] <mpt> glatzor, I'm going home shortly, so I'll just quickly remind you of two bugs: bug 441686 and bug 796193.
[19:12] <ubot2> Launchpad bug 441686 in aptdaemon (Ubuntu) ""Task cannot be monitored or controlled" alert is unhelpful and scary" [Low,Confirmed] https://launchpad.net/bugs/441686
[19:12] <ubot2> Launchpad bug 796193 in sessioninstaller (Ubuntu) "Lack of explicity between singular and plural string" [Low,Confirmed] https://launchpad.net/bugs/796193
[19:12] <mpt> Both of them have questions for you waiting. :-)
[19:13] <mpt> ttyl
[21:43] <m4n1sh> desrt: ping
[21:44] <desrt> m4n1sh: hi
[21:44] <m4n1sh> desrt: I need some help. Do you have 10-15 mins to spare?
[21:44] <desrt> maybe.  what's up?
[21:45] <m4n1sh> remember sometime back you gave me an example of baobab and showed how vala apps should be initialized
[21:45] <m4n1sh> well, I did it
[21:45] <m4n1sh> except that the app doesn't start up
[21:45] <m4n1sh> I can trace the flow of control using stdout.printf but the UI isnt showing up
[21:45] <desrt> paste me your app?
[21:46] <m4n1sh> it is here https://code.launchpad.net/~activity-log-manager/activity-log-manager/redesign
[21:46] <m4n1sh> bzr branch lp:~activity-log-manager/activity-log-manager/redesign
[21:46] <desrt> what is the main file?
[21:46] <desrt> alm.vala?
[21:46] <m4n1sh> the relevant files are src/alm.vala and src/activity-log-manager.vala
[21:46] <m4n1sh> yes
[21:46] <m4n1sh> alm.vala is main file
[21:47] <desrt> public AlmWindow() should take a Gtk.Application argument
[21:47] <m4n1sh> after make, I do a ./src/activity-log-manager, it exits peacefully. Looks like I am not starting the main loop of something
[21:47] <desrt> and do Object(application: app); first thing
[21:47] <desrt> that should fix it
[21:47] <m4n1sh> oh, that is the problem? that's it?
[21:47] <desrt> yup
[21:48] <desrt> you don't associate the new window with the application
[21:48] <desrt> so the application doesn't know any windows are open
[21:48] <desrt> so it has no reason to stay alive and quits
[21:48] <desrt> then change your new AlmWindow() to new AlmWindow(this);
[21:48] <m4n1sh> yeah, done that
[21:49] <m4n1sh> i was going crazy over it for days
[21:49] <m4n1sh> :(
[21:49] <desrt> is it working now?
[21:49] <m4n1sh> I saw the passing of Application instance, but just ignored it thinking that it is baobab specific thing
[21:49] <desrt> nope.  that's important :)
[21:49] <m4n1sh> yup, building it
[21:50] <m4n1sh> desrt: yeah. It worked. yay!!!!
[21:50] <desrt> :)
[21:50] <desrt> ping sooner next time
[21:50] <m4n1sh> desrt: is there a way I can buy you a beer :)
[21:51] <desrt> i won't object next time we meet :)
[21:51] <m4n1sh> exactly. hopefully anytime next uds if possible