[04:36] <pitti> Good morning
[05:07] <tvoss_> ScottK, ping
[05:09] <tvoss_> ScottK, for the effects/compositing setup: should be what comes as default when installing kubuntu-desktop
[05:14] <ScottK> tvoss_: OK.  Thanks.  In the video, the effects looked less transparent, but that may just be the video.  It would have been nice to see more actual compositing effects demonstrated and some KDE apps.
[05:15] <ScottK> I don't feel like I got much of a feel for it as it was.
[05:20] <tvoss_> ScottK, hmmm, I can try with vanilla X and see if I notice any changes
[05:20] <tvoss_> ScottK, any particular operation you want me to check except for playing around with it a little longer?
[05:24] <ScottK> I'd be interested to see various window switching effects, like present windows, , box switch, cover switch, as well as some of the other effects like the outline effect on a focused window and the dialog darken effect.
[05:24] <ScottK> I think seeing things like that are directly driven by kwin when using KDE apps would be more representative.
[05:27] <ScottK> superm1: Would you please update the mythbuntu metapackage/seeds: http://people.canonical.com/~ubuntu-archive/NBS/ttf-droid
[05:34] <tvoss_> ScottK, happy to do that, a screen cap is fine with you?
[05:35] <ScottK> tvoss_: Sure.  Just trying to get a better idea of it.
[05:45] <tvoss_> ScottK, mind pointing me at the keyboard shortcuts to activate the effects you want to see?
[05:46] <ScottK> For present windows, I normally move my cursor to the upper left corner.
[05:46] <ScottK> The window switching ones are alt-tab
[05:47] <ScottK> I think ctrl f10 for present windows
[05:47] <tvoss_> ScottK, cool, thx :)
[05:47] <ScottK> the outline effect should be visible if you have multiple overlapping apps in the screen and one has focus.
[05:48] <ScottK> For the darken dialog one, you'll have to arrange to have something pop up a diaglog
[05:48] <tvoss_> ScottK, ack, any specific kde app you want to see?
[05:49] <ScottK> No, it's more about the windeco/window than the contents.
[05:49] <ScottK> Trying to exercise the things that kwin has direct control over.
[05:51] <tvoss_> ScottK, sure
[06:00]  * tvoss_ is off to kubuntu land for a minute or two :)
[07:06] <tvoss_> ScottK, uploading to u1
[07:06] <ScottK> Does that result in it going somewhere I can see it?
[07:07] <tvoss_> ScottK, hmmm, I assumed you would have a u1 account
[07:07] <tvoss_> ScottK, if not, where do you want me to put it?
[07:07] <ScottK> Nope.
[07:07] <ScottK> Anywhere public is fine.
[07:07] <tvoss_> ScottK, let me see, youtube should work
[07:07] <ScottK> I don't believe in storing data on systems I don't control.
[07:07] <ScottK> Yeah.
[07:08] <ScottK> At least not anything that shouldn't be public.
[07:08] <tvoss_> ScottK, fair
[07:11] <tvoss_> ScottK, I noticed that tracker is using quite a lot of cpu in the background. do you kick it off by default on session login?
[07:23] <tvoss_> ScottK, hth: https://www.youtube.com/watch?v=8sKQnDAPEA4
[07:31] <ScottK> I don't think nepomuk uses that normally, but that's probably what it is.  It can bog things down a bit on first run.
[07:32] <ScottK> tvoss: Looks pretty good.  I get a much better sense of it from that.
[07:33] <tvoss> ScottK, cool, glad that I could help
[07:33] <ScottK> You might want to mention that in the comments to the first one or something.
[07:33] <tvoss> ScottK, I will drop a mail to Jono
[07:48] <dholbach> good morning
[07:48] <seb128> dholbach, good morning my german friend! wie gehts?
[07:50] <dholbach> hey seb128 - good good - yourself?
[07:50] <seb128> dholbach, I'm good thanks ;-)
[09:55] <brendand> why is openssh-server not in saucy?
[09:56] <pitti> brendand: err, it better was.. and it is
[09:56] <pitti> openssh-server |  1:6.2p2-5 |         saucy | amd64, armhf, i386, powerpc
[09:56] <brendand> pitti, apt-cache search doesn't find it
[09:57] <brendand> neither devscripts!
[09:57] <brendand> something is wrong with my install then (most recent daily image)
[09:58] <xnox> brendand: did you run apt-get update to get the package lists?!
[09:58] <brendand> nothing wrong with sources.list
[09:58] <xnox> ah, snap.
[09:58] <brendand> xnox, doing that now
[09:59] <brendand> xnox, that's a bug then, no?
[10:01] <xnox> brendand: apt-cache is fully offline, it only looks up things in the downloaded package files.
[10:02] <brendand> xnox, ah i know now - i couldn't get a connection during install because of a bug in ubiquity
[10:03] <brendand> xnox, ergo it didn't run apt-get update during install (succesfully anyway)
[10:03] <xnox> brendand: hence..... no caches. I do think that ubiquity in those cases should copy the stale cache from the cd though.
[10:03] <xnox> but not sure if this should be implemented or not.
[10:03] <ogra_> is there one ?
[10:03] <xnox> ogra_: let me check.
[10:03] <ogra_> i thought the cache is wiped during build
[10:04] <ogra_> to save space
[10:05] <xnox> ogra_: in /var/cache/apt/ pkgcache.bin is 5.1M and srcpkgcache.bin is 5.0M and nothing under archives/
[10:05] <xnox> is that installed packages though?!
[10:06] <xnox> ogra_: all is there for main and restricted under /var/lib/apt/lists/ 12M
[10:06] <ogra_> hmm, could be a full cache should be bigger
[10:07] <ogra_> we wipe /var/lib/apt/lists/ though
[10:07] <ogra_> not sure the cache helps much without the list files
[10:08] <xnox> but lists files are there as well.
[10:08] <ogra_> oh ?
[10:08] <ogra_> inside the squashfs ?
[10:08] <xnox> yeap.
[10:08] <ogra_> i always thought apt-setup handles them
[10:08] <ogra_> from casper
[10:09] <xnox> ogra_: http://paste.ubuntu.com/5807347/
[10:09] <ogra_> yeah, i see
[10:12] <ogra_> jodh, hey ho
[10:16] <rbasak> So cgroups' kernel interface is changing, and non-systemd systems will need new code to cope: https://lwn.net/Articles/555920/
[10:17] <rbasak> How much does this affect Ubuntu? Do we now need to write a cgroup manager?
[10:18] <rbasak> hallyn: ^^ will this affect LXC at all?
[10:18] <pitti> rbasak: I don't think it affects upstart a lot, but ICBW; it will affect containers (but that's being discussed upstream) and logind (but that will be handled by upstream, too)
[10:18] <xnox> pitti: rbasak: It would be interesting to know if/how it affects lxc on ubuntu and nested-lxc on ubuntu.
[10:19] <pitti> I asked stgraber about this the other day
[10:19] <ogra_> definitely
[10:19] <ogra_> given an essential bit of our stuff today depends on lxc
[10:19] <ogra_> (touch, cloud)
[10:20] <rbasak> How much do we need cgroup support in LXC?
[10:20] <xnox> .... all of it?
[10:21] <ogra_> yeah
[10:21] <ogra_> without it it is just a chroot :)
[10:22] <pitti> rbasak: for us this mostly amounts to pay attention to shipping matching kernel and lxc versions, AFAICS
[10:22] <rbasak> Without cgroups there's still namespacing and apparmor
[10:23] <rbasak> I guess on phone it'll be bad if an app uses 100% CPU or something
[10:23] <ogra_> on the phone you will get issues with the running android init
[10:23] <rbasak> Thanks for the comments anyway. I just saw the article and thought we might want to pay attention. I guess hallyn is the expert here for the LXC end of things
[10:40] <jodh> ogra_: hi
[10:41] <ogra_> jodh, so we have some slight probs with the container handling on ubuntu touch ... and i was wondering if upstart could help us ...
[10:41] <ogra_> effectively we do not want the ubuntu system to handle certain things while android does the same inside the container
[10:41] <ogra_> i.e. see bug 1190792
[10:41] <ogra_> (we have plenty of such stuff)
[10:42] <ogra_> jodh, i was wondering if it would be possible to have something like an init-to-init-bridge between the two so we can see in upstart what happens inside the container to then adjust our event handling accordingly
[10:44] <jodh> ogra_: so you're talking about having androids init in lxc emitting events to the host systems upstart?
[10:44] <ogra_> right
[10:44] <ogra_> some kind of communication layer between host and container
[10:46] <ogra_> currently we have a lot of override jobs that i.e. look for the existence of a socket and then fire the ubuntu process ... thats horridly racy
[10:48] <ogra_> also bringing up the container on boot indeed costs several seconds, atm we can just wait for lxc-wait to make sure the OS inside the container is up, but that doesnt tell us if there is still stuff being processed ... racy again ...
[10:49] <ogra_> if we could instead have a listener for the specific in-conrainer job to start when the services inside the container runs we wouldnt have to wait for the whole container to be up and could start bits in parallel
[10:55] <jodh> ogra_: I guess the hacky way might be to poll with tools like lxc-ls/lxc-ps/lxc-nestat, but awe mentioned that some android services aren't even ready when the sockets appear so maybe we'd need to consider some sort of android service that talks back to the host? don't know enough about this tbh.
[10:56] <ogra_> well, thats what i'm proposing :)
[10:57] <ogra_> have either a hook in androids init (if it knows enough to give us any info) or have a watcher process that tells upstart about started processes
[10:57] <ogra_> and yeah, apps can indeed create sockets before they are ready and fully attached, thats one of the probs we have
[11:00] <ogra_> what we currently plan (and wich is really ugly) is for i.e. ueventd have it create a file in a shared space once it is done (kind of a udevadm settle with files) and have udev have a file-bridge handler watching it
[11:01] <ogra_> i'm not proposing this for 13.10 but i think we should plan something similar for 14.04
[11:01] <ogra_> (unless you think it's super easy and a thing of a days work to implement :) )
[11:06] <doko> jamespage, could you have a look at all the maven build failures in the test rebuild?
[11:07] <jodh> ogra_: you could do that now:
[11:07] <jodh> ogra_: 'start on file FILE=/var/lib/lxc/raring/rootfs/tmp/foo EVENT=created'
[11:08] <ogra_> not really, /var/lib/lxc/raring/rootfs/tmp/foo would never show up
[11:08] <jodh> ogra_: ?
[11:09] <ogra_>  /var/lib/lxc/raring/rootfs is only the input  your container runs somewhere in /proc
[11:09] <ogra_> so files created in /tmp would show up in /proc/$lxc-pid/root/tmp ...
[11:10] <ogra_> but we dont have $lxc-pid unless we explicitly process lxc-info output
[11:13] <jodh> ogra_: a watcher process sounds like it would get more traction that hacking androids init, but I don't know what env is available to allow it to talk back to the host. maybe those that know lxc+android better than I could comment on a bp if you raise one?
[11:13] <ogra_> you can create a socket in /dev/socket, thats shared for example
[11:14] <ogra_> and /data will always be a shared dir since binary blobs depend on it on both sides
[11:15] <ogra_> but while we will likely use the file approach through /data i dont think thats a proper solution
[11:15] <ogra_> (in the long term)
[11:47] <ogra_> jodh, oh, btw, i had tried to watch a socket with the file bridge ... seems i cant, it only seems to act on regular files, do you consider that a bug ?
[12:35] <hallyn> rbasak: pitti: the actual kernel cgroups changes are somewhat independent of the systemd announcement
[12:36] <hallyn> at some point it'll require a single unified hierarchy - that's no problem for us
[12:36] <hallyn> lemme find the most soothing email in the thread,
[12:37] <hallyn> http://lkml.org/lkml/2013/6/27/527
[12:37] <hallyn> rbasak: ^ tl;dr : we'll all be experimenting for awhile and coming up wtih a new api
[12:37] <jodh> ogra_: the bridge is using inotify, so I guess it's a limitation of inotify.
[12:37] <ogra_> ah
[12:37] <hallyn> the api is to set on *top* of cgroupfs, and we do want such a thing.  But if we want to be phillistines, we can always keep using cgroupfs :)
[13:19] <tvoss_> didrocks, what is the blessed way to install a symlink from a packaging setup?
[13:19] <didrocks> tvoss_: just do it like in a file, ship it, then dh_links will do the right thing for you :)
[13:19] <didrocks> dh_link*
[13:20] <didrocks> tvoss_: you can force creating some shipping debian/<package>.links (man dh_link)
[13:20] <tvoss_> didrocks, thx
[13:20] <didrocks> yw :)
[13:53] <roadmr> xnox: hi! about bug 1194195, the binary package depending on gksu was checkbox-gtk, so all should be peachy if I remove that particular dep, right? (I'll be adding a depends on policykit-1 instead, in addition to code changes)
[14:19] <xnox> roadmr: yes.
[14:19] <roadmr> xnox: ok, great! thanks. A fix should land in a few days then :)
[14:20] <xnox> roadmr: awesome.
[14:22] <jdstrand> mdeslaur: I've created a apparmor-easyprof-ubuntu package to ship our templates and policygroups
[14:22] <infinity> mterry: To be clear on bug #1188935, were you okay with that being promoted despite the testsuite bug, or did you want that fixed first?
[14:22] <mdeslaur> jdstrand: ok
[14:22] <jdstrand> mdeslaur: the current version is 'ubuntu-0'. ie, things are installed in:
[14:22] <jdstrand> /usr/share/apparmor/easyprof/templates/ubuntu-0/ubuntu-sdk
[14:22] <jdstrand> /usr/share/apparmor/easyprof/policygroups/ubuntu-0/qmlscene
[14:22] <mterry> infinity, I'm OK despite the test suite bug.  I just want the test suite bug fixed this cycle ideally
[14:23] <mdeslaur> jdstrand: version 0? :P
[14:23] <mdeslaur> jdstrand: odd choice :P
[14:23] <infinity> mterry: Check.  Promoting, then.
[14:23] <mterry> Or whenever gnome-keyring can be run under xvfb
[14:23] <jdstrand> mdeslaur: I used 'ubuntu-0' just for namespacing. ie, the json manifest would use '"policy_version": "ubuntu-0"'
[14:23] <mdeslaur> oh, yuck
[14:24] <mdeslaur> why not just an integer there?
[14:24] <mdeslaur> compating strings is painful
[14:24] <mdeslaur> comparing
[14:24] <jdstrand> easyprof supports that fine, I chose ubuntu-0 for namespacing
[14:26] <mdeslaur> *cough*ugly*cough*
[14:26] <jdstrand> mdeslaur: eg, if Debian wanted to ship easyprof templates, we would need to not collide
[14:26] <mdeslaur> ok, if you want to do that, then do policy_vendor and policy_version
[14:26] <jdstrand> jeez, you keep making me do more work :P
[14:26] <mdeslaur> because now we have to start parsing strings all over if we want to do "older than version 3" checks
[14:26] <mdeslaur> jdstrand: well, do it right the first time :)
[14:26] <jdstrand> meh
[14:26] <mdeslaur> hehe
[14:27]  * mdeslaur hugs jdstrand
[14:37] <sergiusens> cjwatson: hey, recalling the question about sdk apps and click, the fat package format is supposed to solve the arch specific packages right? I see there's an architecture entry I could add to the manifest today to workaround that until it's ready if that's the case
[14:41] <cjwatson> sergiusens: fat packages are only needed if you want to ship multiple arches.  if you just need to ship one then you can just say "architecture": "armhf"
[14:42] <cjwatson> the "problem" of shipping packages for a single architecture isn't one that needs solving :)
[14:43] <sergiusens> cjwatson: great, so my temporary hack would be to use arch: armhf, but these apps would eventually need to be fattened up
[14:44] <cjwatson> or linked or something
[14:44] <cjwatson> we don't need to solve that problem just yet
[14:45] <sergiusens> one less problem to deal with for now, I'll table it
[14:55] <ev> manish: so this is going to be tricky. Since
[14:56] <ev> activity log manager by itself is only vala code, not a c shim like the control center integration, it means extern'ing enough c code in alm.vala to get the diagnostics page up
[14:56] <ev> manish: I'll keep at it, but can we release what we have? As the previous release disabled the diagnostics page, GNOME Ubuntu would be no worse off.
[14:59] <jbicha> ev: that release wasn't in Ubuntu because it had a regression like that
[14:59] <ev> jbicha: what's the regression?
[14:59] <ev> the diagnostics page never appeared in a-l-m standalone.
[15:00] <jbicha> what I meant was that alm 0.9.5 wasn't in Ubuntu
[15:00] <ev> oh, right
[15:02] <jbicha> ev: based on what you've said, I'm ok with releasing to saucy now with bug 1192778 unfixed but I'd really like it fixed before saucy is released
[15:03] <ev> jbicha: *nods* I'm working on it, I just don't want the release to block on it. :)
[15:13] <barry> jbicha: the debdiff in lp: #1194526 comment #4 doesn't apply cleanly to the current saucy branch of libgsf.  can you generate a new patch?  if not, i will adapt it
[15:20] <infinity> barry: Meh, I'll just do that merge myself right now, it's trivial.
[15:21] <barry> infinity: thanks
[15:22] <jbicha> thanks
[15:28]  * infinity resurrects a lost changelog entry while he's at it.
[15:33] <smoser> slangasek, what would be in local-filesystems that is not in filesystems ?
[15:33] <smoser> ie, i have a system hung where local-filesystems ahs fired but not filesystems
[15:54] <smoser> hm..
[15:57] <xnox> what is responsible for clearing /forcefsck after it's been done?
[15:58] <slangasek> smoser: I guess you mean the other way around?  things in filesystem but not in local-filesystems; that would be network filesystems, by and large... 'filesystem' should be the union of 'local-filesystems' and 'remote-filesystems' IIRC
[16:01] <smoser> yeah.
[16:01] <smoser> slangasek, do you have a minute
[16:01] <jodh> smb: we even have a picture: http://upstart.ubuntu.com/cookbook/#mountall-event-summary :)
[16:01] <slangasek> smoser: ok
[16:02] <smoser> ssh test@gwaclhostblkhljy4re3yp9swkdwp63kswkss9bqhn0zm3f3gunipzu5vwdr8qzw.cloudapp.net
[16:02] <smoser> that system i think has not run rc yet. and i *thoht* had not emitted filesystme, but i don thtink thats rignht
[16:03] <slangasek> smoser: cannot resolve hostname
[16:03] <jodh> smb: oops - should have been smoser ;)
[16:03] <smb> jodh, Very ..err nice. Why would we want that again. :)
[16:03] <smb> ah
[16:03] <smoser> slangasek, would it seem odd or bad for
[16:03] <smoser> lockfile-create /var/lock/ntpdate-ifup
[16:03] <smoser> to have been hung
[16:03] <smoser> jodh, that 'last spoken tab completion' thing causes problems when both smb and i are talking
[16:03] <smoser> i often say things to myself in that situation
[16:03] <smb> smoser, Hey I haven't said a thing today. :)
[16:04] <jodh> smb: we can hear your thoughts!
[16:04] <smoser> slangasek, sorry. test@cf96b6aab6fe4ca8943422ee34fbca4b.cloudapp.net
[16:04] <smoser> md5 hostnames for the win!
[16:04] <smb> jodh, must be a lot of <beep>ing
[16:05] <jodh> smb: hey, I like techno :)
[16:05] <smb> :)
[16:05] <slangasek> smoser: 'status mountall' -> stop/waiting; what do you see here that points to filesystem not having fired?
[16:07] <smoser> slangasek, well, i think i have retracted that thought
[16:07] <smoser> but
[16:07] <smoser> $ ls -altr /var/run/landscape
[16:07] <smoser> ls: cannot access /var/run/landscape: No such file or directory
[16:07] <smoser> S45landscape should have created that.
[16:07] <smoser> so it would seem it didn't run
[16:08] <slangasek> smoser: if you run the script manually, what do you get?
[16:09] <smoser> i haven tried. cause i didn't want ot ruin state
[16:09] <slangasek> I see that the script will exit before creading the pidfile if check_config() failed
[16:09] <smoser> ah. ok. then maybe i'm barking up the wrong tree then.
[16:09] <smoser> why would lockfile hang ?
[16:09] <smoser> the 2 instances i see hung like this have a lockfile pid hung
[16:10] <ev> manish, jbicha I think I've got it. Just cleaning it up.
[16:10] <slangasek> smoser: /etc/default/landscape-client doesn't exist; therefore RUN==0, CLOUD==0, and landscape-client won't start
[16:10] <smoser> good enough.
[16:10] <smoser> lockfile ?
[16:11] <slangasek> not sure
[16:11] <slangasek> strace?
[16:11] <slangasek> futex(0x7f06a7d1f720, FUTEX_WAIT_PRIVATE, 2, NULL
[16:11] <slangasek> looking pretty broken
[16:12] <smoser> oh. the other thing . the otriginal thing that lead me to thinking filesystems hadnt been emited.
[16:13] <smoser> cloud-init-config.conf hasn't run (or if it did, it didn't successfully log anything to /var/log/cloud-init.log)
[16:13] <smoser> hm..
[16:13] <smoser> i dont know
[16:13] <smoser> i'm messed up.
[16:14] <smoser> wait it did.
[16:14] <smoser> i'm sorry.
[16:15] <slangasek> smoser: so if I run lockfile-create directly under strace, it gives me this:
[16:15] <slangasek> open("/dev/tty", O_RDWR|O_NOCTTY|O_NONBLOCK) = 5
[16:15] <slangasek> writev(5, [{"*** glibc detected *** ", 23}, {"lockfile-create", 15}, {": ", 2}, {"malloc(): memory corruption (fas"..., 34}, {": 0x", 4}, {"00000000023e8100", 16}, {" ***\n", 5}], 7*** glibc detected *** lockfile-create: malloc(): memory corruption (fast): 0x00000000023e8100 ***
[16:15] <slangasek> ) = 99
[16:16] <slangasek> rather rude of it to write to /dev/tty, I think
[16:18] <smoser> cmdline has 'console=tty1 console=ttyS0'
[16:18] <smoser> and that is probably coming through a console output job i suspect
[16:18] <smoser> maybe ? trying to come up with some reason for it to be doing that.
[16:20] <slangasek> no, the console settings don't explain why it would open /dev/tty which is the generic device
[16:46] <xnox> hallyn: jdstrand: shadow with user name space support is in the archive ;-)
[16:51] <jdstrand> neat
[16:51] <jdstrand> sarnold: ^
[16:52] <sarnold> jdstrand: woo :)
[16:52] <sarnold> xnox: thanks :)
[16:52] <sarnold> hallyn: thanks :)
[16:57] <hallyn> xnox: woot, thanks!
[17:00] <xnox> that's quite a party =)
[17:01] <stgraber> yay!
[17:47] <slangasek> infinity: upstream found the plymouth problem... no prototype for ply_get_timestamp() means that the double being returned by the function plays silly buggers with the floating point state
[17:47] <slangasek> apparently we ought to be building plymouth with -Werror ;)
[17:48] <sarnold> slangasek: wow...
[17:48] <infinity> slangasek: Ah-ha.
[18:13] <ogra_> root@ubuntu-phablet:/# dpkg -S /etc/rc6.d/S31umountnfs.sh
[18:13] <ogra_> dpkg-query: no path found matching pattern /etc/rc6.d/S31umountnfs.sh
[18:13] <ogra_> does anyone know from the top of his head where that comes from ?
[18:14] <infinity> (base)adconrad@cthulhu:~$ dpkg -S /etc/init.d/umountnfs.sh
[18:14] <infinity> initscripts: /etc/init.d/umountnfs.sh
[18:14] <infinity> ogra_: Following the symlink would help. :)
[18:14] <ogra_> oh
[18:14] <ogra_> silly me
[18:14] <ogra_> i should have looked in init.d
[18:14] <ogra_> i wonder how even it would be to divert it ... it causes issues on phones
[18:15] <ogra_> *evil
[18:15] <ogra_> (reboot hangs at times)
[18:15] <infinity> Perhaps sorting out WHY it causes problems would be good.
[18:16] <ogra_> well, we will hopefully not offer nfs cloud access via mobile data :)
[18:16] <ogra_> but yeah, if i could find that out i'd be happy as well
[18:16] <infinity> Sure, but it does a bit more than the name would imply.
[18:16] <infinity> So, it would be good to sort out what's breaking.
[18:17] <infinity> As it may also affect other LXC setups or even normal desktops in some cases, etc.
[18:17] <ogra_> http://paste.ubuntu.com/5808502/ is the processlist of a hanging boot
[18:17] <ogra_> http://paste.ubuntu.com/5808513/ is the tail end of syslog
[18:18] <infinity> sh -x /etc/rc6.d/S31umountnfs.sh stop ?
[18:18] <infinity> Oh, wait.
[18:18] <infinity> It's the very end that's hanging.
[18:18] <infinity> So, blame it on upstart.
[18:19] <infinity> Indeed, that's not the only initctl call that's hung.
[18:19] <ogra_> right
[18:19] <infinity> So, yeah, that's something we really should want to fix, not hackishly work around.
[18:20] <infinity> I'd recommend filing an upstart bug and poking jodh and stgraber.
[18:20] <ogra_> well, i would like to work around it for dogfooders ... indeed i did plan to research the cause and get it fixed
[18:20] <infinity> ogra_: The problem I have with workarounds is that they seem to persist for two years before anyone notices and backs them out again.
[18:20] <ogra_> heh
[18:21] <ogra_> or even become permanent
[18:21] <ogra_> for the phone stuff i have all of them in the lxc-android-config package ... and i expect the workaround part to be empty by release :)
[18:21] <infinity> Anyhow, that's pretty clearly either an upstart bug, or a self-imposed mess due to container madness.
[18:21] <stgraber> so if it's hanging on the emit for unmounted-remote-filesystems, that's because a job that's start on unmounted-remote-filesystems won't return
[18:21] <ogra_> i doubt the container is involved
[18:22] <infinity> stgraber: There's also a hung "initctl emit deconfiguring-networking" in his ps output.
[18:22] <ogra_> stgraber, why would we have such a job ?
[18:22] <infinity> stgraber: http://paste.ubuntu.com/5808502/ if you missed it.
[18:22] <stgraber> right, same thing, unless you call emit with --no-wait, a broken job can make the emit hang
[18:22] <stgraber> it's by design
[18:23] <infinity> I suspect that doesn't want to change to --no-wait in either case, before someone hunts down what's halting the process.
[18:23] <stgraber> so it's typically an issue with whatever job is started on that event more than upstart's fault (or maybe it's a case where we want it non-blocking, though for those two, I doubt it)
[18:23] <stgraber> yeah, I think we want those shutdown related events to be blocking as they're there to cleanly bring things down and unmount network fs before the kernel cuts the power
[18:24] <stgraber> in that ps dump, the problem appears to be dbus
[18:25] <stgraber> dbus is supposed to stop on deconfiguring-networking and based on that ps, it didn't
[18:25] <ogra_> right
[18:25] <ogra_> thats why NM respawns
[18:25] <ogra_> (in the syslog above)
[18:26] <ogra_> i dont see much in the upstart log for dbus apart from moaning about no whoopsie user being present
[18:27] <ogra_> but i think thats from startup anyway
[18:27] <stgraber> just looked a bit closer, unmounted-remote-filesystems causes networking to stop which causes deconfiguring-networking to be emitted which should cause dbus to go away and the system to shutdown
[18:28] <stgraber> so it looks like if we can figure out what's keeping dbus from stopping, the whole thing will be solved, all the blocking events will return and the system will shutdown
[18:30] <stgraber> ogra_: btw, shutdown works fine here on mako, though that's a slightly older image (I don't appear to have powerd)
[18:32] <slangasek> stgraber, ogra_: yes, those events are absolutely supposed to be blocking; the whole reason they exist is to ensure ordering of shutdown, making them non-blocking would reintroduce races :P
[18:34] <ogra_> stgraber, it mostly seems to happen on maguro and also only every nth boot
[18:34] <ogra_> though i think awe said he also saw it on mako
[18:35] <awe> ogra_, ack
[18:37] <ogra_> slangasek, into the races we have you mean ?
[18:37] <ogra_> :P
[18:38] <slangasek> ogra_: well, the standard Ubuntu shutdown scripts are race-free, so whatever races you're seeing are bugs in your stuff ;-)
[18:39] <ogra_> right, seems something keeps dbus alive
[18:39] <slangasek> keeps it alive, or respawns it somehow?
[18:40] <ogra_> hard to tell
[18:40] <ogra_> the info in the upstart dbus.log is pretty sparse, it doesnt show it respawned
[18:41] <ogra_> only moans about whoopsie absence
[18:42] <ogra_> Unknown username "whoopsie" in message bus configuration file
[18:42] <ogra_> to be exact
[18:42] <ogra_> (and indeed it is right, no whoopsie on the phones)
[18:44] <awe> ogra_, you might need to run upstart with --verbose or --debug to catch the respawning...
[18:45] <slangasek> or just run 'initctl log-priority info' after boot
[18:45] <ogra_> awe, well, i rather would think i want a verbose dbus that logs somewhere
[18:45] <slangasek> and this won't be logged to /var/log/upstart/dbus.log in any case, as that just captures the log output from dbus itself - it does not give you any information from upstart about the job respawning, etc.
[18:45] <slangasek> ogra_: which image first introduced this problem?
[18:46] <ogra_> i think tony reported it with his first test of flipped
[18:46] <ogra_> i havent seen it until today
[18:48] <slangasek> ok
[18:48] <slangasek> which devices is it seen on?
[18:48] <ogra_> maguro more often than mako
[18:48] <slangasek> ok
[18:48] <ogra_> i have never seen it on grouper
[18:49] <ogra_> oh, wait
[18:49] <ogra_> doesnt powerd use dbus ?
[18:49] <sforshee> ogra_: yes
[18:49] <ogra_> its in the processlist as well
[18:50] <slangasek> what does that have to do with the dbus shutdown being blocked?
[18:50] <ogra_> powerd has no "stop on" stanza
[18:50] <slangasek> so?  dbus shouldn't care
[18:50] <ogra_> hmm
[18:50] <slangasek> that just means dbus will stop, and powerd will be left crying in the dark
[18:50] <slangasek> it's the things that *do* have 'stop on stopping dbus' that are going to be the problem
[18:51] <ogra_> oh, right
[18:59] <ogra_> root@ubuntu-phablet:/# stop dbus
[18:59] <ogra_> stop: Job has already been stopped: dbus
[18:59] <ogra_> root@ubuntu-phablet:/# ps ax|grep dbus
[18:59] <ogra_>   515 ?        Ss     0:00 dbus-daemon --system --fork
[18:59] <ogra_> ...
[19:02] <slangasek> ogra_: 'status dbus'?
[19:02] <stgraber> ogra_: that means it's busy shutting down and not stopped yet
[19:02] <stgraber> ogra_: if it was really stopped and all events processed, you'd get "stop: Unknown instance:"
[19:02] <ogra_> root@ubuntu-phablet:/# status dbus
[19:02] <ogra_> dbus stop/stopping, process 515
[19:03] <ogra_> ah, k
[19:03] <stgraber> right, so stuck in the stopping event as we suspected
[19:04]  * ogra_ adds some verbosity to dbus
[19:04] <ogra_> i bet now i cant reproduce the issue anymore ... :P
[19:06] <slangasek> what jobs are 'stop on stopping dbus'?
[19:08] <ogra_> http://paste.ubuntu.com/5808713/
[19:08] <stgraber> ogra_: can you also paste a full "initctl list" when the system's stuck
[19:08] <ogra_> likely something in the session then, but i dont see anything running
[19:08] <slangasek> wow, trying to turn on -Werror for plymouth is spectacular fail
[19:09] <slangasek> why is upstream building with -Wall by default and not cleaning up the resulting warnings?
[19:09] <ogra_> http://paste.ubuntu.com/5808716/
[19:09] <slangasek> ogra_: ofono stop/killed, process 864
[19:10] <slangasek> it's all awe's fault ;-)
[19:11] <infinity> slangasek: It seems that some people don't make the jump from -Wall to "I should fix those".
[19:12] <infinity> slangasek: I've been helping a friend off and on with his CompSci homework, where one prof insists they always build with -Wall.  The comment he got back after a few assignments was "you're the only student who actually makes sure everything builds cleanly and addresses all the warnings".
[19:12] <infinity> slangasek: Perhaps because I made him do so.
[19:12] <slangasek> :)
[19:13] <awe> my fault??  ;D
[19:13] <slangasek> awe: ofono is refusing to die on shutdown, which blocks dbus, which blocks /etc/rc6.d
[19:13] <stgraber> slangasek: well, actually it looks dead, I'm wondering if it's not a expect fork vs expect daemon issue
[19:13] <awe> sigh...
[19:14] <ogra_> i guess we could just leave it to sendsigs
[19:14] <ogra_> and pull the stop on stanza
[19:14] <slangasek> stgraber: presumably not, if ofono was working at all during the system's run
[19:14] <awe> stgraber, slangasek... there's definitely an issue with ofono & upstart that I haven't been able to debug yet
[19:14] <slangasek> ogra_: no, that's a wrong solution
[19:14]  * awe is currently doing an evil ofono merge for PIN/PUK support
[19:15] <ogra_> slangasek, well, we rip the socket out underneath it
[19:15] <slangasek> sendsigs *deliberately* skips upstart jobs that don't have a 'stop' target
[19:15] <slangasek> you want the opposite, you want to ensure the service shuts down
[19:15] <ogra_> if it needs a stop on, that should probably the container
[19:15] <awe> slangasek, I added code to ofono to exit on RILD socket errors, and was relying on upstart to respawn
[19:15] <awe> it does this once, and then seems to get confused
[19:15] <slangasek> awe: hmm, ok
[19:15] <awe> ...thinking that ofono is still running
[19:16] <slangasek> awe: my devices are not at easy reach at the moment; could you pastebin /etc/init/ofono.conf?
[19:16] <awe> ( ie. initctl status ofono returns a PID, and says it's running, when it's not )
[19:16] <awe> yea, one sec...
[19:17] <slangasek> infinity: oh, so half of these warnings are actually from the ubuntu-text plugin, teehee
[19:18] <awe> slangasek, http://pastebin.ubuntu.com/5808742/
[19:18] <stgraber> awe: also paste the .override
[19:18]  * awe knew someone was going to ask for that
[19:18] <stgraber> as the whole job is overriden
[19:18] <awe> one more sec...
[19:18] <ogra_> yeah
[19:18] <ogra_> the override is my fault :)
[19:19] <awe> http://pastebin.ubuntu.com/5808747/
[19:19] <ogra_> but that only adds a loop to wait for the socket
[19:19] <ogra_> (and a start on for the socket dir(
[19:20] <stgraber> ogra_: you know that a .override doesn't need to duplicate anything that exists in the original conf right? :)
[19:20] <ogra_> stgraber, but its much more readable to have it all in the same file
[19:20] <awe> slangasek, stgraber... the expect is correct, as if ofono is running, the correct PID/status is returned... but after the first respawn, it seems upstart gets confused
[19:20] <awe> I see this on maguro, flipped
[19:20] <stgraber> ogra_: until someone dumps a post-stop in the archive ofono.conf, then it's going to be very confusing :)
[19:21] <ogra_> stgraber, well, i have hope that we can somehow merge the jobs before release
[19:21] <awe> I checked and confirmed that ofono uses the daemon() call, so the 'expect fork' should be correct
[19:21] <stgraber> ogra_, awe, slangasek: there's the problem, look at PID: http://paste.ubuntu.com/5808753/
[19:21] <ogra_> 80% of lxc-android-config is throw away stuff
[19:22] <slangasek> right, that looks like it should actually be 'expect daemon'
[19:23] <stgraber> slangasek: well, strangely enough the initial startup worked with expect fork, but the second run appears to need expect daemon
[19:23] <slangasek> hmm
[19:23] <awe> yea..that's what I originally thought too
[19:23] <slangasek> that doesn't make much sense
[19:23] <stgraber> otherwise the PID for the instance running after boot would be wrong too and the first stop would hang
[19:23] <ogra_> lovely
[19:23] <awe> that said, when upstart respawns, does that cause a double fork that's not accounted for?
[19:24] <awe> s/double/extra/
[19:24] <slangasek> well, in stgraber's example, it's not using an upstart respawn
[19:24] <awe> right...
[19:24] <slangasek> oh
[19:24] <slangasek> this is a bug that was just reported on upstart-devel
[19:24] <slangasek> Subject: upstart shell magic for exec line
[19:25] <awe> yea??
[19:25] <slangasek> https://lists.ubuntu.com/archives/upstart-devel/2013-June/002554.html
[19:25] <slangasek> I don't understand how a bug like that went unnoticed for as long as it did
[19:25] <slangasek> unless something regressed somewhere along the line
[19:26] <rsalveti> ouch
[19:26] <slangasek> awe: there's a one-line change proposed there (dropping line 268 of job_process.c); I haven't evaluated this, but I guess you could try it out and see what else might explode
[19:26] <awe> sure...
[19:26] <slangasek> stgraber: can you follow up on bug #1181789, please?
[19:27] <stgraber> slangasek: I think we did some changes in that part of upstart when fixing some build issues in 1.8 (or 1.7), so it's not impossible that we introduced the bug at that time
[19:29] <infinity> slangasek: is this expect daemon/fork thing new, or did I just not know about it when I tore a deamon() call out of something that was driving us insane?
[19:30] <infinity> slangasek: (And does it allow for a double-fork of 'exec shell-script-that-execs-daemon'?)
[19:30] <ogra_> it has been in the cookbook for a while
[19:30] <stgraber> slangasek: I'm fairly sure just dropping the line will cause test failures, finishing some loop-mount stuff and I'll take a look after that
[19:30] <slangasek> infinity: you apparently just didn't know about it :P
[19:31] <slangasek> infinity: exec shell-script-that-execs-daemon> there's a bug about that, I have a patch for it but I hadn't landed it because it was only useful to me if we fixed exit tracking at the same time; let me dig it up
[19:31] <awe> stgraber, slangasek, I have to head out in ~20min or so, but can test later.  Totally explains the weirdness I was seeing with my socket retry scenario
[19:31] <awe> also fyi, I'm out next week
[19:32] <infinity> slangasek: Oh, kay, if that case still doesn't work, I don't feel bad about my workaround, then.
[19:32] <stgraber> slangasek: IIRC the bug that cause that change (and introduced this bug in the process) was when your working dir contains a shell character (like the ~ in our daily builds). That was the bug that drove us insane for a couple of days a while back (upstart failing for dailies but not for distro upload)
[19:32] <slangasek> infinity: lp:~vorlon/upstart/lp.855010
[19:32] <slangasek> stgraber: right.  Can you please take care of fixing this? :)
[19:33] <stgraber> awe: well, the job is correct, once we fix upstart it'll just work (I expect the patch to be pretty easy to backport to saucy and raring).
[19:33] <awe> whew...
[19:33] <awe> cool
[19:34]  * awe spent lots of time reading, and re-reading the upstart cookbook this week
[19:34] <infinity> slangasek: I suppose shell-that-calls-daemon would be a triple-fork, which is the problem (and why it cleared up when I removed the daemon() call).  Couldn't one just allow 'expect fork' to take an integer argument, so I can say "dude, this forks 17 times, that last one's what you want"?
[19:35] <awe> lol
[19:35] <slangasek> infinity: shell-that-calls-daemon would be a triple-fork, and that won't work; shell-that-execs-daemon *should* work fine and we just need to support that; letting things fork more than twice is a total non-starter until we properly add exit tracking
[19:36] <slangasek> which is bug #530779
[19:36] <awe> and everyone on my team thought I was seeing pink elephants when I kept claiming shutdown was broken...
[19:36] <slangasek> these are not mutually exclusive
[19:36] <sergiusens> awe: I didn't, I just couldn't reproduce it anymore until today
[19:37] <stgraber> awe: well, it's only broken if ofono crashes, so fix ofono and your shutdown will work reliably :)
[19:37] <slangasek> hah
[19:37] <slangasek> stgraber: ofono is exiting because of rild, I don't think that's ofono's fault ;)
[19:37] <seb128> stgraber, when do you guys plan to update upstart?
[19:37] <ogra_> but we love pink elephants
[19:37]  * seb128 is getting tired of logout taking ages because init segfaults and apport block the logout while dealing with the issue
[19:38] <stgraber> seb128: I plan to land the fix for the respawn issue as soon as I have it but that's probably unrelated to what you're talking about
[19:38] <ogra_> seb128, come over to the phone team ... no apport here
[19:38] <ogra_> *g*
[19:39] <awe> stgraber, ofono wasn't crashing, it was exiting on purpose when the RILD socket operations returned errors while running in flipped
[19:39] <awe> this is 'cause we had no way to reliably know that RILD had started in the flipped container
[19:39] <slangasek> see, upstart should supervise rild too :P
[19:40] <awe> ;D
[19:40] <seb128> stgraber, I want http://bazaar.launchpad.net/~jamesodhunt/upstart/bug-1190526/revision/1481 in saucy ;-)
[19:40] <infinity> slangasek: Well, I'm "happy" enough with the 1-line hack we're carrying in the kernel source for now, this conversation just reminded me of it.
[19:40] <awe> well, now that chromeos an android are under the same mgmt, that's not too far-fetched...  ;)
[19:41] <slangasek> infinity: ok.  but now that I know that bug has affected more than just cups, for which it's not a complete solution, I'll probably bump it up my list
[19:41] <stgraber> seb128: I should be able to cherry-pick that one at the same time assuming I debug the other issue before we upload 1.9 to Ubuntu
[19:41] <seb128> stgraber, thank you!
[19:43] <ogra_> slangasek, well, i was asking jodh today about an upstart-container-bridge for us :)
[19:43] <slangasek> ogra_: no, that's not what I'm talking about
[19:44] <slangasek> I'm talking about rild being an upstart job that just happens to run in an android chorot
[19:44] <slangasek> chroot
[19:44] <ogra_> yes
[19:44] <ogra_> thats what i wanted that bridge to be
[19:44] <slangasek> it shouldn't be done by any bridge at all
[19:44] <slangasek> you just need an upstart job with a 'chroot' stanza
[19:44] <bregma> hey guys I'm trying to run valgrind on armhf under quemu (ie. in a pbuilder) but I always get an Out Of Memory error....  anyone else seen this?
[19:44] <stgraber> slangasek: I have a kernel patch here that'd let us do that but only for mako/manta
[19:44] <slangasek> (well, except you really need a container, but meh :P)
[19:44] <ogra_> heh, if chrooting would work that way into lxc containers
[19:45]  * awe heads out
[19:45] <ogra_> but i see what you mean
[19:45] <stgraber> slangasek: exec lxc-attach -n android --clear-env -- /system/xbin/env PATH=/system/bin:/system/xbin INSERT-YOUR-COMMAND-HERE
[19:46] <rsalveti> that would require changes in the android side as well
[19:46] <rsalveti> I'd just prefer a way to know when it's up from the android side
[19:47] <rsalveti> which you can get via properties, we just need to hook that up somehow
[19:56] <slangasek> sigh.  did firefox just change to no longer allow me to hide the tabs when I only have one tab in the window?
[19:56] <lifeless> slangasek: firefix is intent on becoming a copy of chrome
[19:57] <lifeless> slangasek: but badly; e.g. when you copy an http url it now copies it without the http://
[19:57] <lifeless> slangasek: so it looks like chrome, but behaves worse.
[19:57] <slangasek> chrisccoulson: ^^ do you know if this behavior is still controllable in ff 23? :/
[19:58] <slangasek> http://forums.mozillazine.org/viewtopic.php?f=23&t=2687123
[19:58] <slangasek> argh
[19:58] <slangasek> yeah, might as well switch to chrome now
[19:59] <ScottK> You might want to consider how rapidly and consistently we get security updates out first.
[20:00] <slangasek> surely it's simpler to assume that any browser is compromised
[20:01] <ScottK> That would be one way to approach it.
[20:01] <mlankhorst> that's what I assume anyway
[20:02] <debfx> lifeless: at least firefox has an about:config option to get the http:// in the location bar back
[20:03] <chrisccoulson> lifeless, i've no idea why that doesn't work for you, but it works fine here...
[20:04] <lifeless> debfx: yes, which is a saving grace
[20:04] <lifeless> chrisccoulson: let me double check then.
[20:05] <lifeless> chrisccoulson: and now my running ff makes a liar of me. NFI
[20:05] <chrisccoulson> ;)
[20:38] <ScottK> lamont: Can haz postfix 2.10.1?
[21:00] <luist> anyone familiar with multistrap?
[21:07] <lamont> ScottK: added to my weekend fun
[21:07] <ScottK> lamont: Thanks.
[21:32]  * xnox let's see if this works as well
[21:32] <xnox> lamont: Can haz util-linux 2.23.1 ?