[00:16] <Hobbsee> intrepid ibex, hey?
[00:17] <infinity> Yeah, my suggestion of Incontinent Imbecile was rejected.
[00:17] <StevenK> Hah
[00:18] <Hobbsee> HAHA
[00:18] <Hobbsee> oops, caps
[00:41]  * lamont kicks /etc/event.d.
[00:41] <lamont> how do I get the system to reconize changes there?
[00:41] <lamont> short of reboot, that is
[02:58] <Chipzz> ScottK: errr, yes it (maintaining a mixed system) IS documented; it's called pinning and is documented in man apt_preferences
[02:59] <ion_> FSVO documented
[02:59] <Chipzz> although I should poorly documented :P
[02:59] <Chipzz> ion_: ;)
[02:59] <ScottK> Not supported though
[02:59] <Chipzz> ion_: I found that manpage to be really confusing ;)
[02:59] <Chipzz> ScottK: yeah but the guy was asking about documentation ;)
[03:00] <Chipzz> s/confusing/complex and lacking examples/
[03:01] <ScottK> K.  I took it more as I did this really odd thing to my system, I want to do something odder, and want it to work.  Please help.
[03:01] <Chipzz> question of interpretation I guess ;)
[03:08] <Chipzz> the one thing I did try to achieve with apt/preferences, I failed at :P
[03:08] <Chipzz> which was trying to convince apt that packages recompiled locally and installed with dpkg -i should take precedence
[03:11] <Chipzz> but then, I don't even know if that's possible (or if apt/preferences is the right way to do that)
[04:31] <superm1> slangasek, still going to have time to look over the changes to cdimage with me?
[04:55] <choudesh_> Anyone around?
[04:55] <Hobbsee> no
[04:55] <choudesh> heh. ;-)
[04:55] <choudesh> Is the 8.04 kernel compiled with the HIGHMEM flag?
[05:03] <emgent> heya Hobbsee :)
[05:03] <Hobbsee> hey emgent!
[05:15] <_MMA_> choudesh: I believe it is for 32-bit.
[05:58] <slangasek> superm1: is there a branch I can look at?  I think I can squeeze in looking at the changes, but only asynchronously
[05:58] <superm1> slangasek, yeah there is.
[05:58] <superm1> slangasek, let me get you a url
[05:59] <superm1> http://bazaar.launchpad.net/~mythbuntu/ubuntu-cdimage/mythbuntu-cdimage/
[05:59] <slangasek> superm1: thanks, pulling for later
[06:00] <superm1> slangasek, thanks.  let me know if you have any questions or concerns.  i'll be up for 1-2 more hours, otherwise i'll answer in the morning
[06:01] <slangasek> yah, I don't think I'll get to it until tomorrow anyway, I'm a bit sleep-deprived ATM
[07:08] <pitti> Good morning
[07:11] <warp10> Hi all!
[07:25] <tjaalton> pitti, slangasek: the latest xorg-server upload is not built yet?
[07:25] <tjaalton> -intel needs that
[07:26] <pitti> tjaalton: built everywhere
[07:26] <dholbach> good morning
[07:26] <pitti> hey dholbach
[07:27] <dholbach> hey pitti
[07:27] <tjaalton> pitti: but not published? -1ubuntu4 is the one
[07:30] <slangasek> tjaalton: published too.  there've been some mirror pulse issues, I know; perhaps your local mirror is lagged as a result of that
[07:31] <tjaalton> slangasek: ah ok, I'm using archive.u.c ;)
[07:31] <pitti> tjaalton: ah, just wanted to say the same
[07:32] <tjaalton> slangasek: I uploaded a new -intel which build-deps on the latest xserver-xorg-dev, and drops the patch which forces XAA on !965
[07:32] <slangasek> tjaalton: perhaps archive.u.c is lagged as a result of that ;-P
[07:32] <tjaalton> hope it's ok..
[07:32] <tjaalton> we discussed these with bryce
[07:33] <slangasek> tjaalton: is that a new new -intel, or the new -intel that I know about already from talking to bryce ~24h ago?
[07:33] <bryce> same -intel
[07:33] <slangasek> ok
[07:33] <slangasek> that one's built & published, but perhaps not published as far as we'd like
[07:34] <tjaalton> slangasek: it's the same, but with the latest patch disabled since it turns out that compiz has issues with XAA&Xv at least on some i9xx in addition to 965
[07:35] <tjaalton> it's published, but doesn't do what we'd like it to do :)
[07:35] <tjaalton> ie. force greedy EXA
[07:35] <bryce> yeah users are reporting that our fix for 965 also works great on other intel chips
[07:36] <slangasek> so what you're saying is that you want a -2ubuntu7?
[07:36] <tjaalton> exactly
[07:37] <slangasek> the current behavior isn't a regression, right?
[07:38] <bryce> it's not a regression from gutsy (we had been running XAA there)
[07:39] <slangasek> so no urgent reason to try to squeeze it into alpha5..?
[07:39] <bryce> but for alpha3 and 4 we'd turned EXA on for everyone, which we assumed worked no differently than XAA
[07:40] <tjaalton> exa has been there since 2.2.0 was uploaded..
[07:40] <slangasek> ah
[07:40] <bryce> however users are saying they had been finding EXA fixed things for them, they just hadn't really told us until this patch to put them back to XAA went in
[07:40] <slangasek> heh. :)  ok, go ahead and upload 7 and I'll try to see that it gets squeezed onto the ISOs
[07:40] <Fujitsu> Is XAA actually meant to work with Xv? It never has for me.
[07:41] <bryce> ok cool
[07:41] <bryce> Fujitsu: I only knew that it didn't work with 965.
[07:42] <bryce> (but then, on my 945 where I play video regularly, compiz had been crashing left and right anyway)
[07:45] <tjaalton> slangasek: already did, I assumed that you'd put it on hold if not acceptable for a5 :)
[07:58] <Pete_B> can anyone please tell me the dependencies of the lamp-server virtual package? (I'm not running Ubuntu so can't check myself)
[08:10] <sladen> peter_b:  http://packages.ubuntu.com/hardy/lamp-server  except that doesn't return any results, did it get renamed?
[08:19] <sladen> pete_b: grep -A8 lamp-server /usr/share/tasksel/ubuntu-tasks.desc
[08:22] <pitti> infinity: gcc-3.3 upload> ... but it already was in universe before?
[08:28] <\sh> asac: ff3 + flash + usb headset (in this case a sennheiser) doesn't work...I wonder if it's a regression of gnome/ff3+flash or something else
[08:45] <soren> pitti: Now that the gcc issue is taken care of in kvm, everything is fine, right?
[08:46] <pitti> soren: yes, it is; I'll get to review/promoting it soon
[08:46] <soren> pitti: Cool. Thanks.
[08:47] <soren> Just wanted to make sure it wasn't blocking on me somehow.
[08:52] <davmor2> Do we have stable images across the board now, for testing purposes?
[08:52] <mvo> hey sladen! will you be at fosdem?
[08:53] <sladen> mvo: a bit late if I do turn up.  Ferry to Rostock left 22:00 last night and I was too busy watching the fresh snow to watch it
[08:54] <sladen> s/watch/catch the ferry/
[08:54] <mvo> sladen: heh :) ok
[08:54] <slytherin> Does a MIR bug need to be marked confirmed?
[08:57] <sladen> silly Deutsch Bahn site is suggesting I go via St. Petersburg.  meh germany technology.
[08:58] <seb128> do we have anybody looking to fuse in ubuntu?
[08:58] <davmor2> sladen: it's a long bike ride any way you look at it ;)
[08:58] <seb128> looks like the rmdir behaviour on ntfs fuse mounts is not correct
[08:58] <seb128> I would like to know if that's a known issue
[08:59] <pitti> seb128: you mean ntfs-3g or fuse proper?
[08:59] <seb128> pitti: no idea, whatever we use to mount ntfs partitions
[08:59] <seb128> ntfs-3g likely
[08:59] <seb128> rmdir gives a  = -1 EEXIST (File exists)
[08:59] <seb128> instead of a = -1 ENOTEMPTY (Directory not empty)
[09:00] <seb128> when used on a non empty directory
[09:00] <seb128> that breaks gvfs
[09:00] <slytherin> And I thought only I was having this problem
[09:00] <seb128> slytherin: ?
[09:01] <slytherin> ntfs-3g here (default install)
[09:01] <slytherin> seb128: I get error when trying to delete folders with files inside
[09:01] <seb128> slytherin: you are the one who opened the bug?
[09:02] <slytherin> seb128: No. I didn't
[09:04] <pitti> seb128: yep, ntfs-3g likely
[09:04] <pitti> seb128: there is a new upstream version allegedly, which we should update anyway
[09:04] <pitti> (not for alpha5, though)
[09:05] <pitti> seb128: aside from that it seems easy enough to fix; can you subscribe me to the bug #?
[09:05] <pitti> I'm happy to take a look
[09:06] <carlos> pitti: hi, should I accept translations for x264 package? it's in multiverse
[09:06] <pitti> carlos: good question; why not?
[09:07] <carlos> pitti: it's not a package in main, so I just wanted to check it ;-)
[09:07] <seb128> pitti: bug #186569, I've subscribed you
[09:07] <ubotu> Launchpad bug 186569 in ntfs-3g "cannot delete files off of an Fuse mounted NTFS partition in nautilus" [High,Confirmed] https://launchpad.net/bugs/186569
[09:07] <pitti> carlos: you are afraid of violating LP's usage policy or so?
[09:07] <carlos> pitti: no, there is no problem in Launchpad side
[09:07] <pitti> seb128: taking
[09:07] <carlos> pitti: I was more worried in the fact that the translations will be installed in language packs
[09:08] <pitti> oh
[09:08] <carlos> which are in main
[09:08] <pitti> carlos: no, that shouldn't happen
[09:08] <pitti> I thought LP would import universe translations, but not export them to langpacks?
[09:08] <carlos> we ignore those imports to prevent translation effort lose
[09:08] <carlos> until we implement a way to deploy it
[09:12] <asac> \sh: hard to tell.
[09:16] <\sh> asac: i test it a bit later with loudspeakers attached to the default soundcard, so i can trace this problem
[09:27] <pitti> carlos: ok, then we better ignore it
[09:28] <carlos> ok
[09:30] <geser> good morning
[09:38] <pitti> hi geser
[09:53] <geser> Hi pitti
[09:54] <Hobbsee> guten tag pitti
[09:55]  * pitti hugs Hobbsee
[09:56]  * Hobbsee hugs pitti back!
[10:55] <lool> pitti: elisa dep changes applied with | python >= 2.5 (as also mentionned by pochu); thanks
[10:55] <pitti> lool: great, thanks; I'm not fussed about python2.5 or python (>= 2.5)
[10:56] <pitti> the latter is better for forwards compatibility, right
[10:56] <lool> Well elisa runs with the default python ATM, so these are only optional if it's >= 2.5
[10:57] <pitti> StevenK: oh, the joys of de-yada-ifying (just did it for ossp-uuid)
[10:57] <StevenK> Yay!
[11:11] <pitti> soren: I wonder whether kvm-source should better stay in universe? I take it on hardy release kvm-source and l-u-m should ideally be synchronized?
[11:12] <soren> pitti: Well, not l-u-m, but yes.
[11:12] <soren> And that is currently the case.
[11:12] <pitti> right, it's in linux proper
[11:12] <pitti> ok, done
[11:12] <soren> Feel free to leave kvm-source in universe.
[11:12]  * soren hugs pitti
[11:12] <pitti> soren: can you please get it seeded?
[11:12] <soren> Sure.
[11:30] <davmor2> Can anyone tell me please if the Ubuntu cd's are safe for testing?
[11:32] <dredg> depends what you mean by safe. there's always the chance a cd could shatter and cut you
[11:32] <Hobbsee> davmor2: slangasek should be able to answer you
[11:34] <soren> dredg: I hate that :(
[11:56] <cjwatson> mvo: 'apt-get install ubuntu-desktop' installs recommends from the metapackage. 'apt-get install ubuntu-desktop^' does not.
[11:56] <cjwatson> mvo: this feels like an apt bug to me?
[12:07] <cjwatson> mvo: this happens even if I set APT::Install-Recommends=true. I think perhaps MarkInstall never gets called with AutoInst==true?
[12:15] <cjwatson> mvo: http://paste.ubuntu.com/4824/ seems to fix it, but I'm not entirely certain what other effects it would have?
[12:17] <cjwatson> mvo: (this is alpha-5-critical, by the way; we're only running into it as a consequence of other problems, but those seem a lot harder to address)
[12:31] <ogra_cmpc> cjwatson, oh, you pushed kdeedu completely into desktop-kde ... if i add it to desktop-addon now that will pull in the deps i guess ?
[12:32] <sabdfl> Riddell: help re displayconfig
[12:33] <sabdfl> Riddell: is there a known issue with the display configuration in Hardy?
[12:33] <sabdfl> complaining about being unable to find libpython2.5.so, iirc
[12:33] <cjwatson> ogra_cmpc: I don't think I made any changes as far as the position of kdeedu is concerned
[12:34] <cjwatson> ogra_cmpc: yes, seed dependency resolution works as normal
[12:34] <ogra_cmpc> cjwatson, no, that change was made before aolready (it was in live and the old addon seed)
[12:34] <ogra_cmpc> we did that for gutsy
[12:35] <ogra_cmpc> hmm, unpredictable growth then, i'll keep it for after alpha then
[12:35] <ogra_cmpc> the desktop install works fine from g-a-i now :)
[12:36] <cjwatson> excellent
[12:36] <davmor2> The new ubiquity doesn't set the country and keyboard defaults after the world map anymore.  Is this known?
[12:37] <ogra_cmpc> having .desktop files for -desktop metapackages seems worth to have for all of them imho
[12:37] <ogra_cmpc> we should discuss that at UDS
[12:37] <cjwatson> davmor2: #ubuntu-installer
[12:37] <davmor2> cjwatson: ta
[12:39] <Riddell> sabdfl: yes, that's a known issue, it's on my todo for fixing
[12:39] <Riddell> sabdfl: but it has larger problems too due to changes in xorg.conf files so it may disappear altogether
[12:40] <Riddell> sabdfl: you can install python2.5-dev to work around that issue
[12:41] <__keybuk> asac: default firefox launcher is broken, known?
[12:42] <mvo> cjwatson: thanks, sorry I was at lunch, checking it now
[12:43] <asac> __keybuk: yes we will go back to firefox.desktop in next upload
[12:43] <asac> (if that is what you mean)
[12:43] <mvo> Riddell: what are your plans re> displayconfig? is there someone working on fixing it?
[12:45] <DktrKranz> pitti, it seems SRU candidate in bug 41491 is not sufficient, what's the procedure in these cases?
[12:45] <ubotu> Launchpad bug 41491 in wzdftpd "Dapper: Broken dependencies for some wzdftpd modules" [Medium,Fix released] https://launchpad.net/bugs/41491
[12:45] <Riddell> mvo: there is not
[12:45] <Riddell> mvo: bryce wants to replace it with improved xrandr tools
[12:46] <pitti> DktrKranz: upload a fixed one
[12:46] <mvo> Riddell: yes, I have seen that (and think that its the right way) - is there a kde version for this in the works too?
[12:47] <pitti> DktrKranz: we can kill the version in -proposed if it is worse than the one in -release
[12:47] <Riddell> mvo: not that I know of
[12:47] <pitti> cjwatson: yay, I just wrote "msgequal" to weed out msgid == msgstr
[12:47] <cjwatson> mvo: the two commands I gave are enough to reproduce in a clean debootstrap
[12:47] <DktrKranz> pitti, it's not worse, because now there's only one packae which has unmetdeps (against three than -release)
[12:47] <cjwatson> pitti: ooh, neat
[12:48] <pitti> cjwatson: /usr/include/gettext-po.h FTW :)
[12:48] <mvo> cjwatson: thanks, doing that now
[12:53] <pochu> doko: are you aware of bzrtools 1.2.0-1ubuntu1 failing to upgrade with latest pycentral? I get this: http://paste.ubuntu.com/4826/plain/
[12:55] <ogra_cmpc> wow, virtualbox through ssh -X works really well :)
[12:59] <doko> pochu: yes, we (mvo and me) don't yet understand why the preinst is not run. this only happens for upgrades from 1.2.0-1build1. you can work around by using apt-get --reinstall install bzrtools
[13:00] <edsiper> is *jemalloc* going to be integrated in ubuntu 8.04 ?
[13:02] <pochu> doko: ok, nice that you are aware of it. do you want me to submit it to lp (via apport) ?
[13:07] <mvo> cjwatson: I can reproduce the different behavior here, I looked closer and it seems that the Task: in the Packages file is incorrect (or not in sync with the metapackages). if you look at e.g. landscape-client, that one is part of ubuntu-desktop as a recommends but in my chroot apt-cache show landscape-client does not list ubuntu-desktop as a task
[13:07] <mvo> cjwatson: apt-get install ubuntu-desktop^ is really just using the task information from the packages file
[13:07] <cjwatson> mvo: yes, that is a bug (harder to fix), and is triggering the bug in apt; but I think it is nevertheless a bug in apt
[13:08] <cjwatson> mvo: the ubuntu-desktop metapackage is part of the ubuntu-desktop task, and as such apt should honour Install-Recommends-Sections and install Recommends from the ubuntu-desktop metapackage
[13:08] <cjwatson> even if they aren't in the task
[13:08] <davmor2> Ubiquity is frozen at 94% on ubuntu 32 bit and 64 bit
[13:08] <cjwatson> mvo: I wrote an analysis of the bug you describe to #ubuntu-release; it's going to take some seed changes and a Launchpad change to fix
[13:09] <mvo> cjwatson: thanks, I see. let me look a bit closer at the code so that I can get a better idea why it is run this way
[13:10] <cjwatson> 12:28 <cjwatson> the underlying problem here is that the seed_map stuff in *-meta/update.cfg is only there, and not in the seeds, so Launchpad is unable to make use of it for generating Task fields
[13:10] <cjwatson> 12:29 <cjwatson> it's actually not a new problem - note the lack of Task field in base-files which strictly speaking should have Task: ubuntu-minimal
[13:10] <cjwatson> 12:29 <cjwatson> err, Task: minimal I mean
[13:10] <cjwatson> 12:30 <cjwatson> but in order to fix it we'll need a Launchpad change, and if we can work around it by fixing the apt bug it appears to be triggering, I'd prefer that to having to ask for a cherry-pick
[13:10] <cjwatson> this is in turn triggered by the seed reorganisation which split part of the desktop seed out into desktop-common (and desktop-kubuntu-common for kubuntu/kubuntu-kde4)
[13:18] <mvo> cjwatson: thanks for the background. I think I wrote the code under the assumption that the task header would be present on the packages, your change is fine if that assumption is incorrect. I can do a upload with that fix
[13:22] <cjwatson> mvo: I think the best way to describe it is "incorrect for the time being" :-)
[13:22] <cjwatson> mvo: I'll definitely try to get the systemic and Launchpad bugs fixed. Thanks!
[13:24] <mvo> cjwatson: ok .) let me do a final test and then I do the upload
[13:41] <mvo> cjwatson: hrm, your fix helps, but its not perfect, there is still a delta between the task install and the meta-package (also smaller) - I look a bit deeper
[13:42] <cjwatson> mvo: hmm, ok
[13:42] <cjwatson> I admit I didn't do a proper comparison, I was just looking for ones I knew were left out by mistake
[13:43] <ogra_cmpc> mvo, do we have *any* GL checks left in compiz (read: is there still a blacklist where we could add xephyr) ?
[13:44] <ogra_cmpc> seems the desktop crashes in xephyr sessions with a message about texture_from_pixmap (which i belive comes from compiz)
[13:45] <mvo> cjwatson: wdiff with fix compared to metapkg http://paste.ubuntu.com/4827/
[13:46] <mvo> ogra_cmpc: yes and yes
[13:46] <ogra_cmpc> ok
[13:46] <mvo> ogra_cmpc: it crashes?
[13:46] <ogra_cmpc> wait a sec
[13:46] <mvo> ogra_cmpc: no fallback to metacity?
[13:46] <ogra_cmpc> apparently no fallback
[13:46] <johnny> beep
[13:46] <ogra_cmpc> johnny is the guy who works on sabayon atm
[13:47] <johnny> one of the guys..
[13:47] <ogra_cmpc> which is supposed to switch to xephyr at some point
[13:47] <mvo> ogra_cmpc: strange, it should fall back
[13:47] <johnny> we hope..
[13:47] <ogra_cmpc> johnny, *the* guy in ubuntu :)
[13:47] <johnny> im a guy in ubuntu?
[13:47] <ogra_cmpc> :P
[13:48] <johnny> not officially at least
[13:48] <johnny> my main OS is gentoo, i just happen to use ubuntu all over the place elsewhere :)
[13:48] <ogra_cmpc> mvo, can we blacklist it (likely post alpja stuff though)
[13:48] <ogra_cmpc> *alpha
[13:49] <johnny> is this a place where you guys talking about issues you have with specific apps in hardy?
[13:49] <johnny> i'm still having troubles with 2.22 and sabayon that i have replicated with hardy
[13:49] <cjwatson> johnny: no, this is the Ubuntu developer coordination channel
[13:49] <johnny> but i don't know anybody familiar with gvfs to know what should happen
[13:50] <ogra_cmpc> cjwatson, he cares for our sabayon package a lot
[13:50] <johnny> got some patches merged in
[13:51] <johnny> hmm.. need to find the guy who maintains the current sabayon dev, gotta tell him that i removed gnomesu from the desktop file
[13:51] <cjwatson> mvo: odd, fontconfig depends on fontconfig-config; why would the latter ever not be installed?
[13:51] <johnny> now you can add gksu or not.. depending on the setup
[13:51] <mvo> ogra_cmpc: sure
[13:52] <ogra_cmpc> thanks
[13:52] <mvo> cjwatson: I have no idea at the moment, I'm looking at it, sorry
[13:52] <cjwatson> mvo: fontconfig-config is installed in both cases for me
[13:53] <mvo> cjwatson: with -o APT::Install-Recommends=true or without?
[13:54] <cjwatson> mvo: without
[13:54] <cjwatson> just with the default install-recommends-sections stuff
[13:55] <cjwatson> mvo: the only difference for me with my patch is mousetweaks, which was a recent addition and I think the metapackage just hasn't been updated yet
[13:55] <cjwatson> mvo: http://paste.ubuntu.com/4829/
[13:56] <mvo> cjwatson: thanks, maybe something odd in my chroot
[13:56]  * mvo investigates
[13:58] <mvo> cjwatson: right, my bad. the fix is fine
[13:59] <ogra_cmpc> johnny, btw, could you try setting /desktop/gnome/applications/window_manager/current and /desktop/gnome/applications/window_manager/default to metacity and see if it doesnt crash with that ?
[13:59] <ogra_cmpc> (in gconf-editor)
[14:00] <johnny> it crashes before i get a chance
[14:00] <johnny> i'm just going to put at-properties in /etc/xdg/autostart
[14:00] <ogra_cmpc> it uses your default desktiop
[14:00] <johnny> with autostart disabled
[14:02] <johnny> oh.. that's a seperate thing
[14:02] <johnny> i was thinking of something else
[14:02] <johnny> oops
[14:02] <johnny> what uses my default desktop?
[14:02] <cjwatson> mvo: ok, cool
[14:03] <ogra_cmpc> johnny, sabayon should use your default desktop
[14:03] <ogra_cmpc> as starting point
[14:03] <mvo> cjwatson: preparing the upload now
[14:03] <johnny> it says that key has been deprecated?
[14:03] <ogra_cmpc> if you switch the default to metacity it shouldnt choke on compiz
[14:04] <ogra_cmpc> johnny, thats an upstream comment ... its still used regardless
[14:04] <johnny> ok
[14:04] <pitti> ArneGoetje, cjwatson: I rolled out the langpack-o-matic fix to eliminate msgid==msgstr translations, FYI
[14:04] <ogra_cmpc> (we should probably fix teh text for final release)
[14:06] <johnny> same diff
[14:07] <johnny> it says it aborts and uses metacity, but that is too late
[14:08] <cjwatson> pitti: nice
[14:10] <pitti> cjwatson: ah, thanks for devscripts
[14:26] <mvo> ogra_cmpc: just tested it with Xepyhr and compiz, the fallback works ok for me
[14:27] <ogra> hmm, then it must be the way sabayon calls it i guess
[14:28] <mvo> ogra: if you can give me instructions how to reproduce I'm happy to have a look
[16:30] <emgent`work> packages.ubuntu.com is down ?
[16:30] <cjwatson> not run by us, the same guy who runs packages.debian.org runs it
[16:30] <dholbach> Ubuntu Developer Week is going on, join #ubuntu-classroom
[16:33] <selckin> really sucks ubuntu.org isn't what i think it is every time i type it in
[16:36] <infinity> pitti: gcc-3.3 was moved to universe without anyone realising that libgcc1 builds from gcc-3.3 on hppa.  We ended up with override mismatches, DAK exploded, I cried.
[16:36] <pitti> infinity: oh, erk; thanks
[17:06] <slangasek> tjaalton: eh... soft freeze, so I wouldn't have had any way to put it on hold if we needed to roll new CDs
[17:06] <mario_limonciell> slangasek, is there currently any intention of DVDs with this release?
[17:06] <mario_limonciell> <this alpha>
[17:07] <slangasek> mario_limonciell: no, that would get me yelled at about disk space
[17:10] <Chipzz> (sorry for the off-topic question; but does anyone know if there's a channel where the opers hang out?)
[17:11] <Chipzz> (#opers appears to be a no-go)
[17:18] <Pici> Chipzz: If you need to speak to freenode staff, #freenode is the place, for Ubuntu operators, you can try #ubuntu-irc or #ubuntu-ops. (depending on the type of issue, see the channel topics)
[17:23] <Chipzz> Pici: thx!
[17:23] <Chipzz> (I needed #freenode ;))
[17:42] <pranith> hello, which channel do i join for the developer week irc's?
[17:42] <pranith> the bughelper session in particular?
[17:42] <Mithrandir> 17:30 < dholbach> Ubuntu Developer Week is going on, join #ubuntu-classroom
[17:43] <pranith> thank you
[18:21] <Mithrandir> do we yet have any way to modify pam configs when packages get installed?
[18:21] <Mithrandir> I'd like libpam-ck-connector.so to be added, either programatically or to the default config
[18:24] <slangasek> there's auth-client-config
[18:25] <slangasek> for intrepid I'm hoping for a reworked pam config framework
[18:25] <slangasek> but that didn't come along quickly enough for hardy
[18:27] <Mithrandir> this is for mobile, so I'd rather not install too much stuff like auth-client-config
[18:27] <Mithrandir> (and is that supposed to be driven from maintainer scripts?)
[18:29] <slangasek> dunno.  that's all that exists today, though; the proper in-pam solution is still a cycle away
[18:33] <Riddell> evand, cjwatson: I've got a patch to add proxy support to ubiquity's qt side, is now a suitable time to commit it?
[18:34] <evand> Riddell: should be.  I've already uploaded the fixed ubiquity for bug 193986
[18:34] <ubotu> Launchpad bug 193986 in ubiquity "Ubiquity is locking up at 94% Configuring Hardware" [Critical,Fix released] https://launchpad.net/bugs/193986
[18:35] <Riddell> evand: committed, hugs to nixternal
[18:36] <davmor2> yeah
[18:36] <davmor2> evand does that mean we'll have a new cd in a bit :)
[18:37] <evand> thanks Riddell and nixternal
[18:37] <evand> davmor2: eventually.  ubiquity needs to build and the cd build system needs time to get the update and then make new images.
[18:37] <davmor2> cool :)
[18:40] <bryce> cjwatson: you about?  perhaps this would be a good time to talk with tjaalton about input-hotplug?
[18:40] <evand> bryce: I believe he left around :15
[18:41] <tjaalton> slangasek: uh ok, will remember it the next time ((=won't happen again)
[18:41] <evand> not sure when he'll be back though
[18:41] <bryce> oh, ok, too bad
[18:41] <tjaalton> bryce: my gprs-connection is busy downloading a java-plugin for FF, so it's quite laggy atm :)
[18:42] <bryce> boo java ;-)
[18:43] <bryce> tjaalton: anyway, with input-hotplug the question is how to get to a stable point - would it be easier to revert back to having input stuff specified in xorg.conf, or to complete the work for making input-hotplug function properly?
[18:44] <tjaalton> bryce: it would be easier to revert back
[18:45] <bryce> tjaalton: given that we may not know what bugs may appear even after turning input-hotplug on, maybe that would be the safest thing to do?
[18:48] <tjaalton> bryce: indeed
[18:48] <bryce> tjaalton: what is your opinion?
[18:51] <tjaalton> bryce: I'm leaning towards status quo, and bringing back the synaptics entries to dexconf
[18:51] <tjaalton> since hal upstream is not helping
[18:52]  * bryce nods
[18:52] <bryce> tjaalton: I think I agree; last I talked with cjwatson he was of similar mind
[18:54] <tjaalton> maybe we could ship a script which generates an fdi-file from xkb configuration so people can start using it if they like
[18:55] <bryce> that's a good idea
[18:58] <bryce> tjaalton: also expectations are going to be that with input-hotplug that things work at least as well as in gutsy, but since things are still not fully matured upstream with this, it's hard to guarantee
[18:59] <bryce> also, I'm a bit worried about that we don't have config utilities yet, so even with input-hotplug working, people will find it difficult to customize beyond the defaults
[18:59] <tjaalton> yeah, and because upstream input maintainers hate every single component that is related... even the evdev driver deserves a rewrite :P
[19:00] <bryce> yup
[19:00] <bryce> ok sounds like a decent plan - do you want to do the dexconf reverts, or would you like my help with that?
[19:01] <tjaalton> either works, although I'm away most of this week so it would have to wait until Monday
[19:02] <bryce> I think Monday would be soon enough
[19:02] <tjaalton> yeah
[19:02] <bryce> I'll go ahead and outline this plan to cjwatson and on the bug report
[19:03] <tjaalton> ok cool
[19:04] <jdong> hey while I have you two here.... I'm having an intriguing xorg-video-intel bug
[19:04] <jdong> seems like if I use xvideo,  suspend and resume then use xvideo again, X hangs and only lets me move the mouse
[19:04] <jdong> I can't click anything, keyboard totally locked, power button doesn't respond either
[19:05] <jdong> (Compiz, EXA, greedy migration). Any clues?
[19:09] <tjaalton> jdong: doesn't sound familiar.. filed a bug yet?
[19:10] <jdong> tjaalton: not yet, I'll reconfirm a few times and then file a bug if it's reproducible
[19:11] <tjaalton> ok
[19:18] <jdong> tjaalton: actually, the problem is more trivial than that to reproduce
[19:18] <jdong> tjaalton: xv+compiz seems to randomly
[19:18] <jdong> destroy the display
[19:19] <jdong> ~.
[19:19] <jdong> ~.
[19:22] <bryce> jdong, check through the bugs against -input; xvideo issues after suspend/resume sounds vaguely familiar
[19:24] <bryce> jdong: I've not looked into that issue myself yet, but it is likely an acpi and/or kernel issue (and so probably highly chipset-specific)
[19:24] <jdong> bryce / tjaalton after today's updates it seems like compiz+xvideo = hardlock on my macbook
[19:24] <jdong> it wasn't like this a few days ago
[19:24] <bryce> jdong: well the only change we've put in recently is the greedy patch stuff
[19:24] <bryce> which only affects 965
[19:28] <jdong> bryce: hmm just rolled back to -video-intel 2ubuntu6 and that worked fine
[19:28] <jdong> lemme apply the upgrade again and see what happens
[19:30] <bryce> jdong, hmm also try out 2ubuntu5.  iirc 2ubuntu7 merely reverted the patch in 2ubuntu6
[19:36] <jdong> nope 6 and 7 both happen
[19:36] <jdong> but it's all pretty random
[19:41] <bryce> hrm
[19:42] <bryce> ok, so it still happens with both 2ubuntu6 and 2ubuntu7?
[19:43] <bryce> 2ubuntu2 would probably be the next to try - 3 and 4 were mainly quirk releases iirc
[19:44] <bryce> jdong, ok anyway, please file a bug with as much info as you can gather (I'll probably forget our discussion here, so please summarize), and I'll take a look into it when I get a chance
[19:49] <jdong> bryce: indeed, I'll have to find some time to look into this more thoroughly
[20:02] <jdong> bryce: the combination core 1ubuntu3 and intel ubuntu6 seems to work
[20:02] <jdong> but core 1ubuntu4 with all intel versions seems to fail
[20:03] <jdong> I'll test this for the rest of the afternoon and let you know if this is wrong
[20:03] <bryce> cool thanks
[20:04] <bryce> so it is starting to sound like the issue may be that greedy fails on your hardware..... something I worried about
[20:05] <bryce> you might also try setting your migration heuristic to "always" (see man exa)
[20:06] <bryce> jdong: what does your `lspci | grep VGA` say?
[20:34] <alex-weej> debugging network-manager via my mum on the phone is not even funny
[20:36] <mrsno> alex-weej :) i was doing tech support via sms the other day, /sys/bus/pci/drivers/ipw3945/0000:02:01.0 is not easy to type :<
[20:36] <alex-weej> hehe
[20:37] <Elly> which package do the man pages for the pthreads functions (e.g.: pthread_create) live in?
[20:41] <Chipzz> Elly: off-hand, without checking, I would say manpages-dev
[20:42] <Chipzz> Elly: but this is not the right channel blablabla :), use http://packages.ubuntu.com/ ;)
[20:53] <Elly> Chipzz: I have manpages-dev installed already :P I just noticed there are no man pages for pthreads only - I have manpages for all the system calls and stuff, just pthreads docs appear to be missing
[20:54] <Chipzz> I betcha I can find it with one google search and one lookup on p.u.c :P
[20:54] <Chipzz> so, so should you :P
[20:55] <Elly> aha
[20:55] <Elly> thanks :)
[20:56] <davmor2> slangasek: You'll be glad to hear that Ubuntu Alt's aren't too bad.  Firefox applet is missing and bluetooth applet has vanished.
[21:01] <TheMuso> Do we have CDs tat need testing?
[21:03] <slangasek> TheMuso: more testing wouldn't hurt; I'm about to reroll all the images and the liveCDs are currently uninstallable, but more feedback on the current alternates could still be useful
[21:03] <slangasek> otherwise, give it a couple of hours and we'll have a whole new set
[21:03] <TheMuso> slangasek: I can wait, thanks for the heads up.
[21:03] <NthDegree> Got a technical question:  Is there any plans to add more proactive security to future compiles of Ubuntu? (Sorry if this is OT, but neither the wiki or the support channels really seem to know)
[21:03] <slangasek> davmor2: hopefully the changes that cjwatson_ made fix that problem for Ubuntu as well as Kubuntu
[21:04] <NthDegree> by proactive security I mean fortify_source and other such compiler features
[21:04] <davmor2> slangasek: we shall see in a bit I'm sure :)
[21:05] <ScottK2> NthDegree: Try in #ubuntu-hardened
[21:10] <doko> Mithrandir: thanks for the brightness fix!
[21:10] <Mithrandir> doko: it helps you too?
[21:11] <doko> Mithrandir: package is not yet available, but currently the screen is dimmed after about 5sec of inactivity and doesn't come back to full brightness after pressing a key
[21:12] <Mithrandir> ugh, ok.  I'm not sure it'll fix that.
[21:18] <slangasek> new kubuntu alternate CDs are up for testing, now with a properly-sized amd64 ISO
[21:19] <slangasek> davmor2: ^^ if you're keen to test whether the task issue is resolved for kubuntu alternate
[21:19]  * Treenaks pokes >5 of his own bugs (does that count? :))
[21:19] <RussellGee> Hi huys
[21:19] <slangasek> TheMuso: for 5-a-day? yes... :)
[21:19] <slangasek> er
[21:19] <Treenaks> slangasek: whoo :)
[21:19] <Treenaks> slangasek: the other t<tab> :)
[21:19] <slangasek> TheMuso: sorry, that was for Treenaks
[21:19] <davmor2> cool I'll check it out in a second
[21:21] <Gee> Hi guys
[21:21] <Gee> When will alpha 5 be released now ?
[21:23] <Gee> Anyone ?
[21:23] <Treenaks> Gee: well.. I guess when people get around to it
[21:23] <NthDegree> ScottK2: what's the development status of hardy like for a user interested in KDE 3.5.x?
[21:24] <ScottK2> NthDegree: --> #kubuntu-devel
[21:25] <ScottK2> NthDegree: If you join in #kubuntu-devel we can discuss there.
[21:25] <slangasek> Gee: tomorrow, as noted at https://lists.ubuntu.com/archives/ubuntu-devel-announce/2008-February/000381.html
[21:26] <persia> slangasek: It's already "tomorrow" for some of us :p
[21:26]  * persia isn't advocating early release, just global timezones
[21:26] <Treenaks> persia: those people just need some adjustment to proper time zones ;)
[21:27] <slangasek> persia: yes, but not in Ubuntu Temps Coordonné
[21:27] <Gee> Weird, Im on the mailing list but i never got the announcement
[21:27] <Gee> Ok, thanks
[21:27] <Treenaks> the mailinglist is slow somehow
[21:27] <Treenaks> I got sabdfl's "intrepid" announcement this morning
[21:27] <persia> slangasek: Fair, but I thought releases happened in -9 or something these days anyway :)
[21:28] <slangasek> persia: -8, yes... :)
[21:28] <slangasek> Treenaks: sabdfl's mail to u-d-a was delayed because it hadn't been moderated; I moderate my own mails to u-d-a so that's not related
[21:28] <Treenaks> slangasek: US/West?
[21:28] <slangasek> Treenaks: US/Pacific, yes
[21:29] <Treenaks> slangasek: sabdfl's mail to u-d-a was in the archives >12hrs before I received it
[21:30] <Treenaks> slangasek: but I admit I might have to spank my postfix, because it does weird things (like giving spurious 4xx statuses) sometimes
[21:32] <davmor2> slangasek: do you know if the images are on the rsync server?
[21:37] <slangasek> davmor2: well, you should be able to find out quickly enough if you use the date serial (20080221.1) in your rsync command
[21:37] <slangasek> it's either there or it's not :)
[21:37] <Treenaks> slangasek: ooh.. suspense! :)
[21:39] <slangasek> mr_pouit, somerville32: any plans to fix the size problems on xubuntu alternate for alpha-5?
[21:52] <emgent> heya
[21:53] <Nafallo> emgent: hiya
[21:56] <jdong> bryce: just an update, it's neither -core nor intel causing the problem, I experienced a freeze on a subsequent reboot using the setup I detailed above. Looks like on some reboots though the system works like a dream while on others just starting up mplayer hardlocks the system
[21:56] <jdong> bryce: so yeah, I'll try setting migration heuristics to Always when I get a chance to and report back
[21:56] <bryce> weird, ok
[21:57] <jdong> yeah this is really strange, because before everything worked fine
[21:57] <jdong> I did apply the keyboard firmware and "video update" from OS X this morning
[21:58] <jdong> the former sounds irrelevant, the latter sounds fishy
[21:58] <jdong> though I understood it as an OS X driver update that should not do anything to the hardware
[21:58]  * jdong cries a bit
[22:11] <TheMuso> Does anybody knw why -es langpacks are broken?
[22:11]  * TheMuso is looking at UbuntuStudio's disk report.
[22:17] <slangasek> TheMuso: which package, specifically?
[22:19] <TheMuso> language-support, language-support-translations language-support-writing, mozilla locales, and thunderbird locales, all the -es stuff.
[22:20] <geser> TheMuso: LP ate ispanish
[22:21] <geser> (and some other ispell dicts)
[22:21] <TheMuso> geser: THanks, I'll just yank that langpack for now.
[22:23] <geser> TheMuso: I see now that it should be back
[22:23] <geser> it has a published record again
[22:25] <slangasek> geser: hrm, still missing from the Packages file though
[22:26] <TheMuso> Meh, I'll just yank it for now, we can do without it for an alpha.
[22:26] <geser> hmm, when I look at the dates at https://edge.launchpad.net/ubuntu/hardy/i386/ispanish/+index for the first entry, I'm not sure it should be there or not
[22:26] <Keybuk> ?!
[22:26] <Keybuk> we don't put users in the users group?
[22:27] <geser> "Published  on 2008-02-14" and "Removed from disk  on 2008-02-16"
[22:28] <Nafallo> Keybuk: defaults to their own group AFAIK.
[22:28] <Nafallo> Keybuk: I usually change that first thing on servers though ;-)
[22:28] <geser> cprov: do you know how the current status of ispanish is? should it appear on a.u.c. again?
[22:29] <cprov> geser: what does LP say ?
[22:30] <geser> the status column says published but when I expand the entry and look at the dates I'm not sure anymore
[22:30] <geser> cprov: because of "Published  on 2008-02-14" and "Removed from disk  on 2008-02-16"
[22:31] <cprov> geser: it was badly rescued by me, let me fix it.
[22:34] <cprov> geser: I will fix it later LPDB is down and I have to go. What matters  is the date published ... it should be in the a.u.c, it looks like a mirroring issues
[22:36] <geser> cprov: thanks, I see that idutch has a date for "removal request" after the date of "published". Could it make a problem it the future? it is currently on a.u.c
[22:38] <cprov> geser: yes, it's very confusing I will make it pending again (with empty dates) so we can be sure it will end up in the archive pool
[22:40] <geser> cprov: icatalan and ilithuanian are in the same situation as idutch (with ispell that are the four package I could find which were affected)
[22:40] <cprov> geser: sure, the ones that I've changes before.
[22:40] <geser> s/ispell/ispanish/
[22:41] <geser> cprov: thanks for fixing it
[22:53] <cprov> geser: the files will be published correctly in the next publishing cycle, they should reach the mirror in 1 hour or so.
[23:14] <slangasek> oh argh, now why do I have an oversized amd64 liveCD where it wasn't before?
[23:15]  * Nafallo is not sure he will even try to answer that one ;-)
[23:49] <Keybuk> pitti: not around I guess?


[05:49] <RAOF> Damnit, mir_demo_client_eglplasma! Why can't you find the socket?
[06:00] <duflu> RAOF: Cos we moved it in the server but failed to update libmirclient, I think
[06:01] <duflu> I would have pointed that out if the MP didn't fly by and land without me noticing
[06:02] <duflu> RAOF: If that's right, can you log a bug?
[06:03] <RAOF> duflu: I don't think it's a new change. This *should* be all code that worked on another laptop.
[06:03]  * RAOF is not running this from trunk, but from nested-spike.
[06:03] <duflu> Sounds pointy
[06:26] <tvoss_> good morning :)
[06:27] <RAOF> Dear gdb: plz learn to C++.
[06:27] <RAOF> No love, Chris.
[06:30] <tvoss_> RAOF, for printing values?
[06:30] <RAOF> tvoss_: Indeed.
[06:30]  * tvoss_ always forgets the package that adds pretty printing of stl containers
[06:31] <RAOF> To gdb?
[06:31] <tvoss_> RAOF, yup
[06:32] <duflu> tvoss_: When you remember, do tell
[06:33] <duflu> Cos I've tried dropping the STL from a great height and it just won't die. So being able to debug would be next best thing
[06:35] <RAOF> Hm.
[06:35] <RAOF> Looks like it might be in libstdc++-4.8-dbg?
[06:36] <tvoss_> RAOF, just pinged doko
[06:36] <duflu> Surely pretty-printing is a generic template thing? Should be...
[06:36] <duflu> i.e. Not STL-specific
[06:36] <tvoss_> duflu, it relies on python to do the pretty printing
[06:37] <duflu> Hah
[06:37] <tvoss_> RAOF, that would  be libstdc++6-4.8-dbg, correct?
[06:37] <RAOF> tvoss_: Yeah. Just trying to get it to actually work :)
[06:37] <tvoss_> RAOF, likewise
[06:38] <RAOF> duflu: But you'd really really like STL-specific pretty printers, so that your std::map<foo, bar> doesn't expand to 200 characters of entirely impenetrable implementation details.
[06:38] <duflu> RAOF: No, I'd like pretty printing for any template. Not just the STL. Just like clang does
[06:39] <RAOF> I'd like that too.
[06:39] <RAOF> I'd like both less stupid template expansions, *and* std::map<int, string> = [{1, "one"}, {2, "two"}, …]
[06:41] <tvoss_> RAOF, duflu this mail also helps: http://lists.kde.org/?l=kdevelop&m=125326438617051&w=2
[06:42] <tvoss_> although I would have thought that we have packaged that functionality, too
[06:43] <RAOF> tvoss_: I can only get python syntax errors out of that. :(
[06:43] <RAOF> Sadness ☹
[06:46] <RAOF> tvoss_: Ah. The pretty printers aren't python3 code.
[06:46] <tvoss_> ah
[06:47] <RAOF> And since gdb links to the 3.3 runtime...
[06:47] <tvoss_> RAOF, now that's a bit annoying then
[06:50] <RAOF> tvoss_: Ah, but running 2to3 on it appears to work.
[06:50] <tvoss_> RAOF, got a nice pastebin?
[06:51]  * tvoss_ wonders whether having pretty printers in our retracing-infrastructure would result in more easily readable stacktraces
[06:51] <RAOF> tvoss_: sudo 2to3 --write /usr/share/gcc-4.8/python/libstdcxx/v6/printers.py
[06:51] <tvoss_> RAOF, that's easy :)
[06:56] <tvoss_> RAOF, I get http://paste.ubuntu.com/6234780/
[07:00] <RAOF> tvoss_: Oh, you do 2. from http://sourceware.org/gdb/wiki/STLSupport, but with /usr/share/gcc-4.8/python
[07:01] <tvoss_> RAOF, nope, that's from libstdc++-4.8-dbg
[07:03] <RAOF> tvoss_: Yeah, but the python path is wrong (specifically, /usr/lib/debug/usr/lib/x86_64-linux-gnu/libstdc++.so.6.0.18-gdb.py appears to not add the sys path correctly)
[07:04] <RAOF> Hm. Do we build without rtti? The pretty-printer is an ugly-printer without it :)
[07:05] <tvoss_> RAOF, nope, we never disabled rtti
[07:06] <RAOF> Sayeth the pretty-printer: std::shared_ptr (count 2, weak 0) 0x60dbd8, surface_map = warning: RTTI symbol not found for class 'std::_Sp_counted_ptr_inplace<mir::client::ConnectionSurfaceMap, std::allocator<mir::client::ConnectionSurfaceMap>, (__gnu_cxx::_Lock_policy)2>'
[07:08] <om26er> duflu, re: bug 1227739 I assume that work will go in after 13.10 release ?
[07:09] <duflu> om26er: Unclear. I'm told the current work is exceptional to the freeze. But really I can't even get the prereq branches landed yet
[07:10] <duflu> ... everyone's too busy to review them one way or the other
[07:10] <tvoss_> RAOF, https://sourceware.org/bugzilla/show_bug.cgi?id=14235
[07:11] <om26er> duflu, right. there is still work in unity-mir needed after your branches get merged?
[07:11] <om26er> or any other component
[07:11] <duflu> om26er: Yeah, *maybe*. Would be unpredictable as to whether the fix works otherwise.
[07:12] <duflu> The unity-mir fix is trivial. I'm just not familiar with building/testing that project
[07:12] <duflu> Umm, I mean platform-api?
[07:16] <Saviq> hey folks, is anyone looking at https://bugs.launchpad.net/ubuntu/+source/maliit-framework/+bug/1238107 - it's the most visible hang/crash at the moment for me - since it happens almost every time you stop unity8
[07:17] <tvoss_> Saviq, alf_ was looking into a similar issue
[07:18] <alf_> Saviq: I was planning to look into at after updating the phone
[07:18] <alf_> s/at/it/
[07:18] <Saviq> alf_, great thanks, let me know if you need help!
[07:18] <alf_> Saviq: will do
[07:19] <alf_> Saviq: so, just 'stop unity8' to reproduce?
[07:19] <jibel> I got a webbrowser crash with the same trace on build 95 this morning bug 1239522
[07:20] <Saviq> alf_, yeah
[07:20] <Saviq> jibel, yeah, it's something in mirclient most probably
[07:20] <alf_> jibel: @1239522, is the webbrowser-app reproducible consistently?
[07:20] <alf_> jibel: the crash I mean
[07:21] <jibel> alf_, no, I was trying all the apps to verify none of them was completely trashed. I'm searching a way to reproduce.
[07:41] <Saviq> duflu, re: bug #1238107 I believe alf_ said bug #1233988 was slightly different
[07:41] <Saviq> actually
[07:41]  * Saviq builds platform-api
[07:42] <alf_> Saviq: ah, so the fix for 1233988 is not yet in?
[07:42] <duflu> Saviq: I'm not convinced. But I'm also not convinced we fixed it properly first time. We should at least get to the stage where the known fixes are released, then re-assess if there's still a problem
[07:42] <Saviq> alf_, it's Fix committed everywhere
[07:42] <Saviq> duflu, +1
[07:42] <alf_> Saviq: but not released...
[07:42] <Saviq> alf_, yup
[07:43] <duflu> alf_: I assume you verified the platform-api was smart enough to at least check for connect failure?
[07:43] <duflu> .. i.e. returning false is not in vain
[07:45] <Saviq> alf_, actually it's released in platform-api https://code.launchpad.net/~phablet-team/platform-api/trunk
[07:45] <alf_> duflu: Saviq: yes, it fails an assertion... but now that I think about it, I think I tried it in debug mode, not sure if the assertion is fired in the package version too
[07:45] <Saviq> on Thursday
[07:46] <duflu> Right, but the bug may still exist. Only as an error now rather than a crash
[07:47] <duflu> Although platform-api could still be abusing libmirclient and cause it to crash elsewhere
[07:47] <duflu> Perhaps we should strengthen libmirclient so it doesn't get blamed for bad parms...
[07:47] <Saviq> alf_, duflu, I'm still getting that crash reliably in maliit-server when stopping unity8
[07:47] <alf_> Saviq: what about 1233988 ?
[07:47] <Saviq> somewhat reliably at least
[07:47] <Saviq> bug #1233988
[07:48] <Saviq> alf_, I never knew how to reproduce it... the trace seems exactly the same..
[07:48] <duflu> Saviq: I'm not confident the fixes so far are sufficient so maybe just reopen instead of duplicating in new bugs
[07:48] <Saviq> duflu, sure - your call
[07:48] <alf_> duflu: Let me investigate a bit further today, and I will merge as needed
[07:50] <duflu> Saviq: Most importantly I just want to prevent people from working on duplicates. They're unaware of duplicating effort etc
[07:50] <Saviq> duflu, I understand
[07:50] <Saviq> duflu, works for me
[07:50] <duflu> alf_: Should we be looking up valid_connections for all libmirclient API calls?
[07:51] <duflu> Probably wouldn't hurt
[07:51] <duflu> And it would stop crash reports from landing in Mir
[07:52] <duflu> Hmm, actually it wouldn't. But it would allow us to instantly say "not a Mir bug"
[07:59] <Saviq> duflu, alf_ I still get the maliit-crash on reboot
[07:59] <Saviq> so sounds like not fixed indeed
[07:59] <duflu> Saviq: No problem, just reopen
[08:00] <alf_> Saviq: at least my part of the fix was not about not getting a crash, but getting a better crash (and not in Mir ;))
[08:00] <Saviq> alf_, ok ;)
[08:01] <Saviq> alf_, http://pastebin.ubuntu.com/6234953/
[08:02] <alf_> Saviq: so is this with the default platform-api package, or something you built?
[08:02] <Saviq> alf_, default papi, my mir trunk + https://code.launchpad.net/~kdub/mir/android-buffer-syncfence/+merge/189717
[08:02] <Saviq> alf_, can downgrade mir if you think it matters
[08:04] <alf_> Saviq: Can you try with a custom built platform-api? Just the package version but with -DCMAKE_BUILD_TYPE=Debug, to ensure the assertion for invalid connections is actually compiled in.
[08:05] <Saviq> alf_, will do
[08:06] <alf_> Saviq: hmm, just a moment to check something
[08:07] <Saviq> alf_, holding
[08:11] <alf_> Saviq: ok, please continue :) You may want to add a debug message for 'connect_suceeded' in u_application_instance_new_from_description_with_options src/ubuntu/mirclient/ubuntu_application_api_mirclient.cpp (that's where the assertion should fire, but no harm in having an extra message there)
[08:12] <duflu> alf_: One of the duplicates today clearly showed MirConnection's this==NULL
[08:14] <alf_> duflu: ok, so the problem probably is that platform-api should handle connection failures better. I wonder... is u_application_instance_new_from_description_with_options supposed to return NULL if the call fails?
[08:14] <alf_> tvoss_: ^^ ?
[08:14] <alf_> right now it just asserts
[08:15] <tvoss_> alf_, yes, returning null would be correct
[08:15] <tvoss_> alf_, admittedly, error handling should be better, but right now, NULL indicates error
[08:15] <duflu> I think we need to protect libmirclient from false accusations and error-check the connection parameters
[08:20] <alf_> duflu: +1
[08:48] <tvoss_> alan_g, ping
[08:48] <alan_g> tvoss_: hi
[08:49] <tvoss_> alan_g, hey there, can I ask you to review https://code.launchpad.net/~kdub/mir/android-buffer-syncfence
[08:49] <alan_g> tvoss_: it is on my list
[08:49] <tvoss_> alan_g, ack, we would like to land the mp asap, so would be great if you could bump priority
[08:52] <alan_g> tvoss_: OK. Do you know the best place to ask about network problems? (I'm a bit distracted by: my desktop stopped connecting to wired or wireless after I crashed X on Friday. Even installing a fresh image didn't fix - even though it works fine off the memory stick image)
[08:52] <tvoss_> alan_g, #ubuntu-desktop
[08:53] <alan_g> tvoss_: ta
[08:59]  * duflu sees clipping bugs on iOS 7 and feels better about life
[09:00] <alf_> duflu: :)
[09:01] <duflu> It's kind of nice generally that Apple has lowered the bar/standard for UIs :)
[09:06] <alan_g> My wire dislikes iOS7 nearly as much as Windows8
[09:06] <duflu> -r +f?
[09:09] <duflu> I'm not convinced Win8 was a step backwards compared to Win7. But Apple have killed a large chunk of their distinctiveness and competitive advantage with iOS7. And that's good for Ubuntu.
[09:21] <alan_g> duflu: she's comparing Win8 with WinXP (but IMO win8 introduced a lot of silly traps for the user - e.g. two independent IE installs)
[09:22] <duflu> To Microsoft's credit, at least with Win8 you generally don't need to install drivers any more. And the compositing feels nice and smooth
[10:11] <duflu> alan_g: I've got to run, but would you be able to check this out and see why it's hanging in integration-tests?...
[10:11] <duflu> lp:~mir-team/mir/verify-MirConnection
[10:12] <alan_g> duflu: Sure, I'll have a look later
[10:12] <alf_> Saviq: https://code.launchpad.net/~afrantzis/platform-api/fix-1233988-more/+merge/190908 and
[10:12] <alf_> Saviq: https://code.launchpad.net/~afrantzis/qtubuntu/fix-1233988-more/+merge/190907
[10:12] <duflu> alan_g: Cool, ta
[10:13] <Saviq> alf_, cool!
[10:14] <Saviq> alf_, will test asap
[10:14] <alf_> Saviq: note: this is not a fix of why maliit-server can't connect to the mir server, but at least now you should be getting a clear FATAL message from Qt (which is what the xcb backend does when it fails to connect)
[10:15] <Saviq> alf_, so a better message at least
[10:15] <Saviq> alf_, and no crash
[10:15] <Saviq> alf_, well, I *know* why it can't connect - it's being shut down :)
[10:16] <alf_> Saviq: There will be a crash == qFatal() == abort(). But we can change this to just print a message and exit cleanly... although the right solution here is to find why maliit is trying to connect to a server that is shutting down.
[10:17] <Saviq> alf_, indeed
[10:28] <alf_> Saviq: the problem is that I can't reproduce the maliit crash with 'stop unity8'. Of course, the maliit crash is very easy to recreate in general: just run maliit-server manually after 'stop unity8'.
[10:29] <alf_> Saviq: some kind of race perhaps? How does upstart now when unity8 has started, so it can start maliit-server?
[10:29] <Saviq> alf_, they stop "in concert" and indeed it's not 100% reproducible
[10:29] <Saviq> alf_, but you can run the unity8 ap tests suite - should get you some .crash files
[10:36] <alf_> Saviq: In upstart unity8.conf, we call 'exec unity8'. How does upstart know when unity8 has *really* started (i.e. it's ready to accept client connections?), so it can start maliit-server (maliit-server.conf: 'start on started unity8')?
[10:36] <Saviq> ogra_, ↑ can you shed some light there?
[10:37] <ogra_> it waits until the PID it got returns something ...
[10:39] <ogra_> Saviq, alf_ http://upstart.ubuntu.com/cookbook/#expect
[10:40] <alf_> ogra_: thanks
[10:40] <alf_> Saviq: "If your daemon has a "don't daemonize" or "run in the foreground" mode, then it's much simpler to use that and not run with fork following. One issue with that though, is that Upstart will emit the started JOB=yourjob event as soon as it has executed your daemon, which may be before it has had time to listen for incoming connections or fully initialize."
[10:40] <Saviq> alf_, yeah, I know
[10:41] <alf_> Saviq: does unity8 daemonize?
[10:41] <Saviq> alf_, nope
[10:41] <ogra_> so tracking the first PID should be fine then
[10:42] <ogra_> (i.e no need to set "exepect")
[10:42] <alf_> ogra_: yes, but we fall into the "Upstart will emit the started JOB=yourjob event as soon as it has executed your daemon, which may be before it has had time to listen for incoming connections or fully initialize." case
[10:42] <ogra_> (except if you fork more than once)
[10:45] <ogra_> i know slangesek is on a querst to look through all ubuntu touch upstart session jobs, you probably want to wait for his input
[10:45] <ogra_> *quest
[10:45] <ogra_> is teher a sprecific socket or file maliit should wait for ?
[10:46] <ogra_> upstart has ways to make it do that
[10:46] <ogra_> (you could drop "on started unity8" and make it ie "start on created socket file")
[10:47] <ogra_> (and stop on removed ...)
[11:14] <Saviq> alf_, arguably, since mir clients are not supposed to die when mir dies, shouldn't it also just wait for it to be ready and reconnect?
[11:19] <alan_g> Saviq: alf_ we're a long way from that scenario working. (I'm currently fixing a client-side hang in the API when the server dies)
[11:19] <Saviq> alan_g, got it
[11:32] <tvoss_> alan_g, for kdub's branch: could you give it a more detailed review before kdub fixes the tests?
[11:34] <alan_g> tvoss_: that was my plan
[11:34] <tvoss_> alan_g, thx, would help a lot
[11:38] <Saviq> tvoss_, btw, https://bugs.launchpad.net/unity8/+bug/1238645 is apparently valid for mir/qtubuntu/somewhere
[11:39] <tvoss_> Saviq, looking
[11:39] <Saviq> tvoss_, and I think we're seeing the result of it https://jenkins.qa.ubuntu.com/job/generic-mediumtests-runner-maguro/2412/?#showFailuresLink
[11:39] <Saviq> even with the workaround that we have
[11:39] <Saviq> or workaround--, but upstart++ starting maliit-server for us
[11:40] <tvoss_> hmmm, so key events are sent via uinput?
[11:42] <ogra_> just add an env var check to maliits upstart job
[11:43] <ogra_> make it a no-op if the var is set ... export it from AP
[11:46] <tvoss_> Saviq, what ogra_ said ^?
[11:46] <Saviq> tvoss_, yes they are
[11:46] <Saviq> ogra_, it's not about maliit not being started
[11:46] <Saviq> ogra_, it should be unrelated
[11:46] <ogra_> ah, k
[11:46] <ogra_> i thought maliit blocks uinput
[11:48] <tvoss_> ogra_, that's actually an interesting idea. Saviq, didn't we see the permissions on /dev/uinput change recently?
[11:49] <Saviq> tvoss_, well, yeah, it changes to "bluetooth" for me
[11:49] <Saviq> tvoss_, but works regardless of that
[11:50] <Saviq> i.e. perms no perms, if maliit is working - input is delivered (generally - as we can see there are still failures) - if not - no
[11:53] <tvoss_> Saviq, ack, looking into it
[12:00] <ogra_> root@ubuntu-phablet:/# grep uinput /lib/udev/rules.d/*
[12:00] <ogra_> /lib/udev/rules.d/61-autopilot-uinput.rules:# Creates autopilot group specific access to /dev/uinput
[12:00] <ogra_> /lib/udev/rules.d/61-autopilot-uinput.rules:KERNEL=="uinput", SUBSYSTEM=="misc", SYMLINK="autopilot-uinput", GROUP="autopilot", MODE="0660"
[12:00] <ogra_> /lib/udev/rules.d/70-android.rules:ACTION=="add", KERNEL=="uinput", OWNER="system", GROUP="bluetooth", MODE="0660"
[12:01] <ogra_> Saviq, tvoss|dentist ^^^
[12:01] <ogra_> i guess we should drop it from the android rules :)
[12:02] <ogra_> (and if GROUP=autopilot is wrong adjust thios too)
[12:53] <alf_> Saviq: I wonder if what's happening with maliit etc is that the server crashes, maliit aborts, it's respawn and then fails to connect to the non-existent mir server.
[12:57] <alf_> Saviq: because, all the backtraces we have for this issue point to this happening during application (Qt platform) setup
[12:58] <alf_> Saviq: in any case, the new MPs for platform-api and qtubuntu should make this clearer
[13:09] <Saviq> alf_, might be indeed, am building them now
[13:11] <alf_> Saviq: Unfortunately, I am not able to get maliit to crash with 'stop unity8' (tried about 20 times now). I do get https://bugs.launchpad.net/ubuntu/+source/unity8/+bug/1238116 all the time though...
[13:12] <Saviq> alf_, right, that one's solved with https://code.launchpad.net/~aacid/unity-mir/waitforme/+merge/190716
[13:13] <Saviq> alf_, and it uncovered a few other bugs now indeed
[13:13] <Saviq> alf_, since we're destroying stuff proper now
[13:14] <Saviq> alf_, I'm just building qtubuntu now and will let you know of what changed asap
[13:15] <alf_> Saviq: thanks (note you need both the MPs to see the effect)
[13:15] <Saviq> alf_, yup, papi already built
[13:25] <tvoss> Saviq, I do see events getting into mir with autopilot and maliit not running
[13:26] <Saviq> tvoss, yeah, we need to track them up the stack
[13:27] <jibel> greyback, I added a video to bug 1234538
[13:27] <tvoss> Saviq, I have a gut feeling that maliit goes away and the focus chain in unity is not correctly restored or something
[13:28] <greyback> jibel: thanks. That video I guess with a recent image?
[13:28] <jibel> greyback, 96
[13:28] <greyback> jibel: perfect, thanks. Will look
[13:28] <Saviq> tvoss, if maliit is stopped *before* unity8 starts
[13:29] <Saviq> tvoss, it doesn't work either
[13:29] <tvoss> Saviq, hmmm ... which would then mean, that qt/qml somewhere checks if an input-method is available
[13:35] <greyback> jibel: last question: that a galaxy nexus or nexus4?
[13:35] <jibel> greyback, mako/nexus4
[13:36] <greyback> jibel: Ok, I'll try it there.
[13:39] <greyback> mzanetti: that one new to me, thanks for that
[13:40] <greyback> mzanetti: is it logged? I can't find it?
[13:40] <mzanetti> greyback: noticed when developing the Ubuntu Authenticator on the weekend
[13:40] <mzanetti> greyback: no, didn't report it yet
[13:40] <mzanetti> greyback: it doesn't really hit users, but it
[13:40] <mzanetti> is annoying for app developers
[13:40] <greyback> mzanetti: every fix is a good fix
[13:42] <davmor2> mzanetti: what issue is that?
[13:42] <mzanetti> davmor2: run an app from the command line, lock the screen, press ctrl+c to stop the app, unlock the screen -> Boom!
[13:43] <tvoss> Saviq, got it
[13:47] <Saviq> alf_, so yeah, "FATAL: QUbuntu: Could not create application instance", but still getting crashes
[13:47] <Saviq> alf_, and/or unity8 locking up
[13:47] <Saviq> collecting .crashes now
[13:50] <alf_> Saviq: ok, so if the hypothesis is correct, the "FATAL: QUbuntu: Could not create application instance" should be from the second (respawned) run of maliit-server. Can we verify this, e.g., by getting the stack trace of the first run if it crashed, or some kind of upstart log?
[13:51] <Saviq> alf_, I can get you both, yeah
[13:51] <Saviq> alf_, I can also get you packages I'm seeing that in, if you want them
[13:52] <alf_> Saviq: yes, a cross check with what I have would be good, since I can't get the crash...
[13:58] <Saviq> alf_, so... http://people.canonical.com/~msawicz/repo.tar.gz  - still uploading
[13:58] <Saviq> alf_, that is:
[13:58] <Saviq> mir + https://code.launchpad.net/~kdub/mir/android-buffer-syncfence/+merge/189717
[13:59] <Saviq> platform-api + https://code.launchpad.net/~afrantzis/platform-api/fix-1233988-more/+merge/190908
[13:59] <Saviq> qtubuntu + https://code.launchpad.net/~afrantzis/qtubuntu/fix-1233988-more/+merge/190907
[13:59] <Saviq> unity8 + https://code.launchpad.net/~unity-team/unity8/ap_launch_unity_with_upstart/+merge/190886
[14:00] <Saviq> session-manager-touch + https://code.launchpad.net/~saviq/session-manager-touch/drop-unity8
[14:00] <Saviq> Friday's unity-api + https://code.launchpad.net/~aacid/unity-mir/waitforme/+merge/190716
[14:00] <Saviq> alf_, you can just add it as a repo in sources.list and upgrade from it
[14:01] <Saviq> alf_, you can disregard unity8 and session updates, though
[14:01] <Saviq> alf_, will ping you when it uploads
[14:05] <Saviq> alf_, https://bugs.launchpad.net/ubuntu/+source/maliit-framework/+bug/1239712 here is the current trace
[14:11] <Saviq> alf_, uploaded
[14:12] <mlankhorst> hm
[14:12] <mlankhorst> I think I understand the gbm fail
[14:14] <mlankhorst> this makes it a bit harder though
[14:25] <alf_> mlankhorst: what's the cause for the gbm fail?
[14:27] <mlankhorst> the gbm piping expects a gbm surface type
[14:28] <mlankhorst> but I think it can be workarounded..
[14:29] <mlankhorst> hold on
[14:31] <mlankhorst> in particular the createNewDrawable call, I'm writing a workaround atm..
[14:39] <mlankhorst> well that was easy
[14:39] <mlankhorst> now both work
[14:40] <mlankhorst> http://paste.debian.net/57430/ gg hf kthxbye
[14:41] <mlankhorst> the #if 0 code can be removed or kept, it works either way
[14:42] <mlankhorst> alf_/RAOF: ^
[14:43] <alf_> mlankhorst: \o/, so this fixes the nested mir case totally?
[14:46] <mlankhorst> it fixed eglflash unnested for me, so I would assume so
[14:48] <alf_> mlankhorst: awesome, I will try when the phone drops in priority, probably near EOW
[14:50] <mlankhorst> the code inside #if 0 was the former default, the #if 0 simply allowed me to test any client without starting nested mir
[14:50] <alf_> mlankhorst: is the diff against egl-platform-mir-egl-image-i965-experiment ?
[14:54] <mlankhorst> hm no it's a diff against my previous diff :P
[14:54] <mlankhorst> I think I had some changes on top
[14:56] <mlankhorst> alf_: yeah, apply this one first http://paste.debian.net/57441/
[15:01] <alf_> Saviq: with your packages what I am seeing is that the maliit-server crash is happening when starting up 'start unity8' not when stopping, reinforcing that maliit tries to connect too soon, fails/aborts, gets respawned and manages to connect
[15:01] <alf_> Saviq: can you verify that you get a maliit crash after 'start unity8' and not after 'stop unity8'?
[15:03] <Saviq> alf_, trying
[15:03] <Saviq> alf_, it'd make sense indeed
[15:09] <tvoss> kdub, hey there :)
[15:09] <kdub> hello tvoss
[15:10] <tvoss> kdub, so you are the most wanted person today :)
[15:12] <tvoss> kdub, would be great if you could jump on fixing the test failures on https://code.launchpad.net/~kdub/mir/android-buffer-syncfence
[15:13] <tvoss> kdub, if that is fixed, we could land the branch
[15:13] <kdub> yep, #1 on the list for today
[15:13] <tvoss> kdub, cool
[15:13] <tvoss> kdub, let me know if I can help
[15:18] <Saviq> alf_, confirmed
[15:18] <Saviq> alf_, /me adds "sleep 2" to maliit job...
[15:19] <Saviq> damn
[15:19] <Saviq> alf_, yeah, confirmed
[15:19] <Saviq> alf_, could we not SIGABRT when can't connect to server?
[15:19] <Saviq> ogra_, can we add "sleep 2" to maliit-server before starting?
[15:19] <ogra_> ergh, why is that
[15:21] <ogra_> that adds 2 secs to the session startup, can you solve it in any other way ?
[15:21] <ogra_> (i just spent two weeks to get the boot below 30sec again)
[15:22] <Saviq> ogra_, maliit starts too early
[15:23] <Saviq> ogra_, Mir in unity8 isn't yet ready
[15:23] <ogra_> Saviq, then fix unity to not tell upstart it is started when it is notz
[15:23] <Saviq> ogra_, how?
[15:23] <ogra_> make it wait ? dunno
[15:24] <ogra_> did you try different expect lines for the upstart job (and did you check the double fork stuff etc as explained in the upstart cookbook)
[15:24] <Saviq> ogra_, nope
[15:24] <Saviq> ogra_, we're not forking at all, though
[15:24] <Saviq> ogra_, we're not daemonizing
[15:25] <Saviq> ogra_, but will look through upstart cbook
[15:25] <ogra_> please ask slangasek how to do it right then
[15:25] <ogra_> i think he can help here
[15:26] <ogra_> (or if slangasek isnt around, probably xnox or stgraber can help they are both upstart aces :) )
[15:26] <ogra_> (or even jodh as upstart upstream)
[15:26] <xnox> hm?
[15:27] <ogra_> xnox, the unity8 upstart job seems to return before unity8 is actualyl ready ... causing dependent jobs to start to early
[15:27] <xnox> ogra_: invoke tedg =) unity8 should emit started unity8, until ready =)
[15:27] <xnox> ogra_: if there is a dbus known-name that unity8 exports, jobs can start on started that.
[15:27] <xnox> ogra_: thanks to the dbus bridge.
[15:28] <tedg> Or we could ask unity8 to emit sigstop when ready and have the job wait on that.
[15:28] <tedg> I believe upstart has a mode for that.
[15:28] <ogra_> well, any kind of landmark will do i guess
[15:28] <tvoss> xnox, would initctl emit --no-wait unity8_ready (in unity) with a corresponding start on unity8_ready in maliit upstart conf work?
[15:28] <tvoss> Saviq, ^
[15:28] <ogra_> i'm just opposed to add sleeps back into upstart jobs
[15:29] <tedg> Yup, here it is: http://upstart.ubuntu.com/cookbook/#expect-stop
[15:29] <xnox> tvoss: sure, but also ugly. And please add "emits unity8_ready" in the unity8.conf, for documentation purposes to know which job is expected to emit that event.
[15:29] <xnox> tvoss: tedg: expect stop is far better.
[15:30] <ogra_> tvoss, seriously, unity8 should just DTRT :)
[15:30] <tvoss> ogra_, we are trying to find out what the right thing is :)
[15:30] <ogra_> before we write 100 line upstart jobs
[15:30] <tvoss> ogra_, *you* might know, but simple question: how does a process signal "I'm ready" back to upstart?
[15:30] <tedg> tvoss, There seems to be three idioms used here: 1) be fast, 2) sigstop, 3) fork but not until you're ready
[15:31] <ogra_> right
[15:32] <tvoss> tedg, why not emit an expicit signal? sounds like the best solution in an event-based job control system? ;)
[15:32] <tvoss> tedg, s/signal/event
[15:32] <ogra_> tvoss, thats the sigstop ...
[15:33] <tvoss> ogra_, yeah, I meant event then
[15:33] <tedg> tvoss, I think it depends on the case, if it's just "when it starts" there's no reason to have anything other than the "started" signal, and we should make that better.
[15:33] <ogra_> from where ?
[15:33] <tedg> tvoss, For indicators I added one, and my logic there was that Unity8 may start and do other stuff before it wants the indicator services.
[15:33] <tvoss> ogra_, from unity8, just calling "initctl emit --no-wait unity8_ready"
[15:33] <tvoss> whenever that is the case
[15:33] <ogra_> ugh
[15:34] <tedg> tvoss, Then what would people use the "started unity8" event for?  It seems like we'd be wasting that one.
[15:34] <ogra_> just make your binary DTRT ... if there is no expect mode for your binary behavior, ask jodh to add one
[15:35] <ogra_> tvoss, i think tedg's sigstop suggestion is the best we can do as a quick solution
[15:35] <Saviq> sounds clean enough, yeah
[15:37] <tvoss> Saviq, if you are happy, I'm too
[15:37]  * Saviq wonders when to emit it ;D
[15:38] <tvoss> Saviq, whenever qtguiapplication is constructed I would think
[15:39] <kdub> alan_g, alf_, pushed fixes for the unit tests... they were just test problems, no code change
[15:39] <alf_> kdub: ok
[15:40] <tedg> tvoss, Throw in an idle event, then the first time you hit the mainloop without events...
[15:40] <Saviq> tvoss, don't we need to spin the loop?
[15:41] <alan_g> kdub: @ServerShutdown/OnSignal.* - can you confirm that test works fine when run on its own? (I've seen similar problems on the desktop - https://code.launchpad.net/~alan-griffiths/mir/fix-client-hang-on-server-death/+merge/190935/comments/438530)
[15:41] <kdub> testing... one minute
[15:42] <tvoss> Saviq, not sure ...
[15:43] <kdub> alan_g, yes, with running the test on its own, I see it pass in 2-3 seconds, when ran with the group, it appears to hang
[15:44] <alan_g> kdub: thanks (I'm trying to track down the interaction - at least this should require the same fix)
[15:51] <tvoss> ogra_, can upstart check if a file exists?
[15:52] <ogra_> tvoss, yes, with the file bridge
[15:52] <ogra_> (as long as it is a regular file)
[15:52] <tvoss> ogra_, yup, we just need to check if we are running on mir
[15:53] <Saviq> ogra_, can we check if file && socket exist?
[15:53] <ogra_> Saviq, socket is tricky
[15:53] <ogra_> file is easy
[15:53] <Saviq> ogra_, basically, if [ -e ~/.display-mir ] wait_for(/run/user/32011/mir_socket)
[15:54] <ogra_> Saviq, and on my tablet where i have two users ? :)
[15:54] <tvoss> ogra_, I don't think that's a valid use-case right now
[15:54] <ogra_> tvoss, Saviq is adding the SIGSTOP in the code right after the file creation not an option ?
[15:55] <tvoss> ogra_, I think Saviq is looking for a way to live without the sigstop for now
[15:55] <ogra_> :(
[15:57] <Saviq> no I'm not
[15:57] <Saviq> I'm just looking for a good way to do it
[15:57] <Saviq> and asking *when* to safely emit the sigstop
[15:58] <Saviq> I'm fine with emitting it wherever - but someone knowing Mir needs to tell me when is it safe already
[15:58] <alf_> tvoss: Saviq: (async ping for a review of https://code.launchpad.net/~afrantzis/qtubuntu/fix-1233988-more/+merge/190907 and https://code.launchpad.net/~afrantzis/platform-api/fix-1233988-more/+merge/190908)
[15:58] <Saviq> alf_, is this ping cancellable?
[15:58] <Saviq> alf_, you got a +1 from me 30s ago :)
[15:59] <alf_> Saviq: the .wait() will just return immediately, no need to cancel :)
[16:00] <Saviq> :)
[16:02] <tvoss> alan_g, alf_ do we signal back to mir if the communicator is ready to take connections?
[16:02] <tvoss> alf_, approved and top-approved
[16:03] <alan_g> tvoss: Who is this "mir" you refer to
[16:03] <tvoss> alan_g, the "rest" of the system, and the shell sitting on top
[16:05] <alan_g> tvoss: the connector is ready as soon as "start()" returns - what other signal do you want?
[16:05] <tvoss> alan_g, ack. Saviq, would that help?
[16:06]  * Saviq looks
[16:08] <Saviq> greyback, help
[16:08] <greyback> Saviq: whassup?
[16:08] <Saviq> greyback, in unity-mir, are we calling start() anywhere explicitly?
[16:08] <alan_g> tvoss: Saviq connector->start() is called in DisplayServer::run() before main_loop->run()
[16:08] <greyback> Saviq: no
[16:09] <Saviq> greyback, we're trying to find a place to emit a SIGSTOP for upstart to know we're ready
[16:09] <Saviq> to accept client connections
[16:10] <Saviq> greyback, any ideas where to put it?
[16:10] <greyback> run_mir ?
[16:11] <Saviq> greyback, and that is called where?
[16:12] <greyback> Saviq: called by unity-mir, in QMirServer::runWithClient
[16:12] <Saviq> greyback, mhm, so basically just before returning from main()_
[16:12] <greyback> Saviq: yeah. That too late?
[16:13] <Saviq> greyback, no, not unless it's unity-mir that emits the SIGSTOP
[16:13] <Saviq> greyback, since we can't do it in unity8's main, as we're looping there
[16:13] <greyback> Saviq: it /could/
[16:13] <greyback> but seems to be something that Mir should do, no?
[16:14] <ogra_> greyback, mir isnt started by upstart
[16:14] <Saviq> ogra_, it is ;) unity8 == mir
[16:14] <Saviq> greyback, we'd need it for sflinger, too
[16:14] <ogra_> greyback, the prob we try to solve is that upstart needs to know when unity is ready to only then start all the depending jobs
[16:15] <greyback> ogra_: yep, that's understood. I'm trying to decide if it's Mir's job to send that signal, or instead the user of Mir (i.e. unity8) does it
[16:15] <Saviq> greor well
[16:15] <Saviq> greyback, that means we should be able to emit it in startShell, no?
[16:16] <greyback> Saviq: yes
[16:16] <Saviq> greyback, since by that time mir will be running already
[16:16] <Saviq> orks
[16:16] <greyback> yep, that'll work
[16:16] <greyback> and yeah, I'm fine with that
[16:16] <ogra_> greyback, the PID that upstart fired up needs to return the info
[16:16] <Saviq> ogra_, it's the same PID
[16:17] <Saviq> ogra_, there is no separate process for Mir
[16:17] <ogra_> greyback, (i dont care about internals the SIGSTOP needs to come from unity itself)
[16:17] <ogra_> oh, ok
[16:17] <ogra_> well then whatever :)
[16:17] <greyback> ogra_: mir is just a library, unity8 loads it.
[16:17] <greyback> :)
[16:17] <Saviq> ok, /me emits in startShell()
[16:17] <Saviq> but first - food
[16:18] <tvoss> Saviq, enjoy :)
[16:19] <ogra_> yay
[16:19] <ogra_> :)
[16:21] <alf_> Saviq: greyback: Reading the code I don't think startShell will do
[16:22] <alf_> Saviq: greyback: the startShell is invoked through a thread which is called in the *init_server* callback of run_mir
[16:23] <Saviq> alf_, ;(
[16:23] <alf_> Saviq: greyback: the server object will have been created at the point, but not run
[16:23] <alf_> Saviq: greyback: server objects
[16:24] <Saviq> ok, you guys talk, me really food
[16:25] <alf_> Saviq: greyback: I think the sanest way is for the shell server configuration to subclass the Connector class and override start() to emit the signal after calling the parent start()
[16:25] <greyback> alf_: well I expected the server to be running, as startShell creates a mir client which connects ok
[16:25] <Saviq> greyback, yeah, but only when we exec(), no?
[16:26] <Saviq> greyback, so it might be sheer luck
[16:26] <alf_> greyback: Isn't that an inprocess client? It doesn't go through the socket I think.
[16:26] <greyback> alf_: aha
[16:26] <alan_g> alf_: there are probably saner ways
[16:26] <greyback> ok yes I see startShell will be called before server.run()
[16:27] <racarr> Morning
[16:28] <alan_g> Evening
[16:28] <greyback> alf_: yes your suggestion would work. alan_g what's a better way?
[16:28] <alf_> alan_g: probably, but without changing the mir code?
[16:30] <alf_> greyback: alan_g: ideally, we could emit some kind of event when the server starts up fully, e.g., by injecting an event in our main_loop?
[16:31] <alan_g> alf_: The thing is that implementing Connector (as a proxy for the_connector()?) only tells about part of the initialization
[16:32] <alan_g> I'd imagine implementing MainLoop would be better - as everything is started by the time run() is called.
[16:34] <alan_g> But really I think there should be some sort of status notification (and also for pause/resume)
[16:34] <tvoss> alan_g, +1
[16:34] <greyback> +1
[16:35] <alf_> alan_g: so extending pause_resume_listener I guess
[16:36] <alan_g> alf start_pause_resume_stop_listener?
[16:36] <alf_> alan_g: server_status_listener?
[16:38] <alan_g> alf_: lgtm
[16:39] <alf_> alan_g: ok, tomorrow then :)
[16:40] <kgunn> alf_: you approve kdub's fence improvements now too ?
[16:41] <alf_> kgunn: yeap, thanks for reminding me
[16:41] <alf_> kgunn: done
[16:42] <kgunn> alf_: efharisto
[16:43] <tvoss> kgunn, wow, I'm impressed
[16:45] <alan_g> "Ευχαριστώ" would be impressive
[16:46] <kgunn> :) ...i'll let that merge...gonna run, then i'll do the all the prep to get it in
[17:04] <racarr> tvoss: So was there practice ont he static initialization dealio
[17:04] <racarr> progress&
[17:04] <racarr> *
[17:05] <tvoss> racarr, nope, I think we need to transition papi over to gcc 4.8
[17:05] <tvoss> racarr, post v1, though
[17:06] <racarr> tvoss: Hmm ok
[18:44] <om26er> is there a ppa for Mir development branch somewhere ?
[19:23] <thomi> morning
[19:40] <racarr> Morning thomi
[19:50] <kgunn> racarr: would you mind a review & hopefully approve of https://code.launchpad.net/~mir-team/mir/bump-deb-changelog14-mirserver6/+merge/189990
[19:50] <kgunn> racarr: oops
[19:50] <kgunn> sorry...wrong link
[19:51] <kgunn> racarr: i meant this one https://code.launchpad.net/~mir-team/mir/bump-deb-changelog15-mirserver7/+merge/191029
[19:51] <racarr> kgunn: oi
[19:53] <racarr> kgunn:  looks ok to me
[19:54] <kgunn> racarr: gracias
[20:52] <racarr> thomi: How can I use autopilot and a python console
[20:53] <racarr> to make key events :D
[20:56] <thomi> racarr: like this:
[20:57] <thomi> from autopilot.input import Keyboard; kbd = Keyboard.create(); kbd.type("some text")
[20:57] <thomi> or: kbd.press_and_release("Delete")
[20:57] <thomi> ... for "special" keys etc
[20:59] <racarr> thomi: Perfect. Thanks
[21:15] <kgunn> racarr: ok...one more...merging from dev to trunk...mind approving https://code.launchpad.net/~mir-team/mir/development-branch/+merge/191055
[21:15] <kgunn> robert_ancell: hey...was just merging to trunk, how did duflu know there were merge conflicts that one time ?
[21:16] <robert_ancell> kgunn, the MP in Launchpad showed errors
[21:16] <robert_ancell> that one does not
[21:16] <kgunn> robert_ancell: that's what i thot....was just double checking
[21:16] <kgunn> what does it look like ?? yellow or something in the diff ?
[21:17] <kgunn> robert_ancell:
[21:17] <robert_ancell> kgunn, there are errors in the diff, i.e. "[21:17] <kgunn> robert_ancell: ah!! thanks...
[21:18] <robert_ancell> but also the list of files with conflicts is at the top under the "Merge Into" heading
[21:18] <kgunn> robert_ancell: same as when you do merge on bzr
[21:18] <robert_ancell> or somewhere nearby that
[21:18] <robert_ancell> yes
[21:24] <racarr> kgunn: mergemergemerge
[21:25] <kgunn> racarr: thanks dude
[21:30] <racarr> kgunn: Do you know of a bug # for the thing where autopilot tests and sometimes apps
[21:30] <racarr> are getting
[21:30] <racarr> extra key events?
[21:30] <kgunn> racarr: let me dig one moment
[21:36] <kgunn> racarr: i don't see a bug like that...was it reported against a specific app ?
[21:46] <racarr> kgunn: I'm not sure it ever was
[21:47] <racarr> its just shown up in a bunch of autopilot tests failures
[21:47] <racarr> somewhat intermittently it seems
[21:47] <racarr> and apparently riccm ses it on real usage sometimes
[21:47] <racarr> ill sync with him when he gets back
[22:03] <kgunn> racarr: cool...do you have a fix ? or you're just aware of it as a legit problem ?
[22:03] <kgunn> racarr: maybe log a bug to track ?
[22:04] <racarr> kgunn:  https://code.launchpad.net/~robertcarr/platform-api/fix-event-translation/+merge/191059 hopefully a fix :)
[22:41] <racarr> kgunn: I think the remaining half of the autopilot keyboard issues
[22:41] <racarr> is just key repeat...
[22:41] <racarr> since the OSK doesn't use this code path
[22:41] <racarr> or X mir -.-
[22:41] <racarr> I am trying to decide
[22:42] <racarr> if it's ok to just turn off key repeat
[22:42] <racarr> for now
[22:42] <racarr> basically autopilot presses, releases key, maybe that takes a long time to run
[22:42] <racarr> you get repeats
[22:42] <kgunn> racarr: ok...you're saying turn off key repeat only for AP's ?
[22:43] <kgunn> i would think folks would probably wig out if you turned it off all the time
[22:44] <racarr> well the thing is, then we would have to add it as an option, etc which is more stuff
[22:44] <racarr> but really
[22:44] <racarr> xmir uses it's own input, so it doesnt change xmir
[22:44] <racarr> the osk uses the seperate codepath so it doesn't change the osk
[22:44] <racarr> Is there actually any using
[22:45] <racarr> mir input with physical keyboards
[22:45] <racarr> for 13.10?
[22:46] <racarr> I guess it doesn't hurt to just make it an option...
[22:46] <racarr> thomi: IF we make a mir option for disabling key repeat, can things be set up so all the autopilot runs configure mir this way?
[22:47] <racarr> press("K") release("K") is always a race with key repeat enabled
[22:48] <thomi> racarr: but aren't key repeats at that level handled by separate key repeat events?
[22:49] <thomi> racarr: also, I'm not sure what the key repeat timeout is set to in mir, but if you look at the autopilot logs, the press & release events are pretty close together.
[22:49] <racarr> thomi: In cases where we get extra events I mean?
[22:49] <racarr> thomi: No what the timeout is set to, there is always a case
[22:50] <racarr> press("K")
[22:50] <racarr> autopilot gets preempted
[22:50] <racarr> stuff happens
[22:50] <racarr> release("K) happens after the timeout
[22:50] <racarr> you get repeat.
[22:50] <thomi> racarr: right, but I'm saying that the AP logs look like the press and release happens pretty close together.
[22:50] <thomi> hmmmm
[22:51] <thomi> veebers: perhaps we should just turn on the OSK backend by default?
[22:51] <thomi> oh, right - he went to the gym
[22:52] <racarr> thomi: I guess it's a half second
[22:52] <racarr> I don't know if it's really key repeat causing this...there was also this other bug that the fix-event-translation bug above is about that could be pretty related
[22:53] <thomi> racarr: so... can you actually reproduce this, or are you guessing that this is the cause?
[22:53] <veebers> thomi: I'm just out the door now, right now the OSK backend won't work until this MR is merged: https://code.launchpad.net/~veebers/ubuntu-keyboard/update_autopilot_emulators/+merge/190319
[22:53] <racarr> so unless we have some logs of test failures with the duplicated events and key press differences greater than .5 second (where can I find such detailed logs/produce them myself?)
[22:53] <veebers> thomi: so I'm gonig to approve it now
[22:53] <veebers> going*
[22:53] <racarr> thomi: No! Just guessing. I can't reproduce it at all
[22:53] <thomi> racarr: ahh, ok
[22:53] <thomi> racarr: I'd be surprised if we saw > 500ms lag between press and release
[22:54] <thomi> not saying it can't happen, but...
[22:54] <thomi> I think something else is at fault here
[22:54] <racarr> mm
[22:54] <racarr> maybe it was fix-event-translation *Crosses fingers*
[22:54] <racarr> i need to find a test I can trigger it on and
[22:54] <racarr> dig down
[22:59] <racarr> it seems like it can show up in ubuntu-ui-toolkit so ill try that over and over again :p
[23:40] <racarr> out for some excercise brb
[23:40] <racarr> perhaps really more of a bbiab situation :p
[23:58] <lool> mir building in PPA