[06:09] <pitti> Noskcaj_: merge flashplugin-nonfree-extrasound> am I touched-it-last? sure, please do
[06:10] <Noskcaj_> pitti, You were the last to look at it. oneric i think
[06:25] <pitti> apachelogger, ScottK: do you mind if I upload kde-workspace to put back the init.d script? (needed for insserv compatibility, it won't actually ever run on Ubuntu)
[06:25] <pitti> for bug 1323274, blocking https://code.launchpad.net/~ubuntu-core-dev/ubuntu/utopic/sysvinit/unreviewed/+merge/219999
[06:39] <dholbach> good morning
[06:39] <pitti> apachelogger, ScottK: well, I'll just do and take the bullets (it's just reverting that particular delta to Debian)
[06:56] <TheMuso> greyback: happy to meet up with you out where the coffee break is held.
[06:57] <greyback> TheMuso: ok, see you there
[07:21] <dholbach> @pilot in
[07:21] <apachelogger> pitti: I'll only mind if you break something, that's my job :P
[07:22] <pitti> apachelogger: hehe; yes, of course
[07:22] <pitti> apachelogger: if it ever finishes building :)
[07:33] <mterry> jjohansen1, is there a bug for those lxc test failures?
[07:36] <jjohansen1> mterry: 1323528
[07:40] <ogra_> xnox, where are you hiding ?
[07:41] <jjohansen1> mterry: btw I am testing and will submit the fix for it soon
[07:41] <mterry> jjohansen1, cool, thanks
[07:42] <Shock> pitti: can you take a look at bug #1247584 and tell me if there's anything else I need to do or I can consider it done?
[07:42] <pitti> Shock: hey! yes, I saw your response yesterday
[07:42] <pitti> Shock: thanks for your patch!
[07:42] <Shock> pitti: sure
[07:42] <pitti> Shock: I probably won't get around it this week (sprint), but it's on my TODO list now
[07:43] <pitti> Shock: so from your POV it's "done"
[07:43] <Shock> pitti: cool, thanks
[07:43] <xnox> ogra_: studio 8 at the moment
[07:43] <xnox> (on the sunset strip)
[07:44] <xnox> wgrant: http://people.canonical.com/~ubuntu-archive/germinate-output/ubuntu-touch.utopic/touch.sources ~ 226 source packages
[07:45] <ogra_> xnox, we need to talk if you are not in a meeting anymore
[07:45] <wgrant> xnox: Plus core, I suppose?
[07:45] <xnox> wgrant: yeah.
[07:46] <wgrant> Right, vaguely manageable.
[07:46] <xnox> wgrant: yeah, i would have thought some of kde ppas are bigger.
[07:47] <wgrant> They're a bit of a problem, but yeah.
[07:51] <cjwatson> doko: Would you mind having a look at the wxwidgets3.0/arm64 build failure?  ICE, I'm seeing something that looks similar in redeclipse/arm64, but am in meetings and haven't had a chance to investigate properly yet
[07:52] <cjwatson> xnox,wgrant: touch inherits from sdk-libs, so I think you need to count that too
[07:53] <pitti> xnox: could you put a quick look at http://paste.ubuntu.com/7527535/ ?
[07:53] <cjwatson> little things like qtbase there
[07:53] <pitti> xnox: in particular, for the "shim" nfs-common upstart job I supposed I should add a "stop on" for maybe runlevels 0 and 6?
[07:54] <cjwatson> So more like ~600 ...
[07:54] <pitti> xnox: stop on runlevel [016] ?
[07:58] <xnox> pitti: no, no stop on needed.
[07:58] <xnox> pitti: let me double check.
[08:00] <xnox> pitti: actually it should be "stop on (stopped idmapd and stopped gssd and stopped statd)" no?
[08:01] <wgrant> cjwatson: That'll be in the top 10, and might end up kicking me into making NMAF suck slightly less, but shouldn't be fatal. Thanks for the details.
[08:01] <pitti> xnox: ah, I think an "or" in that case
[08:01] <pitti> xnox: stop on (stopped idmapd or stopped gssd or stopped statd)
[08:01] <cjwatson> wgrant: ok, sorry to accidentally blindside you
[08:02] <pitti> xnox: cause if either is down, nfs-common is not "fully" running any more
[08:02] <xnox> pitti: ack.
[08:02] <cjwatson> wgrant: I think I tacitly assumed "will probably fit within default quota => not a problem"
[08:02] <wgrant> It's number of packages rather than size of packages.
[08:02] <wgrant> NMAF index generation is unbelievably terrible.
[08:03] <xnox> pitti: i'm ok with that, and that's a good state approximation.
[08:03] <pitti> xnox: ack, thanks; testing now
[08:05] <cjwatson> wgrant: yeah, that's obvious now you say it
[08:05] <cjwatson> hmm.  struggling to think of an alternative, all the same
[08:06] <wgrant> Nah, it's easy to make it not suck.
[08:06] <cjwatson> derived distros obviously wouldn't work, and I don't think we should be creating extra distroseries for vendor-specific RTM projects
[08:06] <wgrant> But if you were looking at more than a couple of thousand packages I would have died :)
[08:06] <cjwatson> yeah, I think it will be impractical to make the PPA build entirely standalone for that reason
[08:06] <zyga> ara: my desktop died
[08:06] <wgrant> Imight get bored on the plane and fix it.
[08:06] <evfool> does anyone know about docs on how to do ubuntu online accounts integration?
[08:06] <cjwatson> (i.e. full germinate-speak depends+build-depends closure)
[08:07] <zyga> ara: I managed to log in to see a stream of kernel errors related to NMI and USB
[08:07] <zyga> ara: I need to have a look at it, maybe the fan is stuck or something
[08:07] <cjwatson> wgrant: benefit of living in .au, lots of plane time to get bored in?
[08:07] <wgrant> I attempted it back in '09, but that was before anybody cared about performance, so it was never acceptable to people who could land it.
[08:07] <wgrant> Indeed.
[08:08] <seb128> evfool, try asking mardy maybe, he can probably point you to the right direction
[08:09] <evfool> thanks seb128, I'll ask mardy
[08:09] <mardy> evfool: hi! There aren't many docs at the moment, but I can hopefully help you :-)
[08:10] <pitti> slangasek: do you have a minute to review http://paste.ubuntu.com/7527609/ ? that's a nontrivial (but not too complicated either) diff for nfs-utils
[08:10] <mardy> evfool: do you want to add support for a new service, or are you developing an application?
[08:10] <evfool> mardy: I have found an html5 tutorial
[08:10] <pitti> slangasek: I tested it in a VM (upgrade, various start/stop), and it works fine here
[08:10] <evfool> mady: would like to add uoa integration for an existing app
[08:10] <evfool> mardy^
[08:13] <mardy> evfool: OK. What application is it? Is it a HTML5 one?
[08:14] <evfool> mardy: that would be straightforward based on the HTML5 tutorial, it's Vala, but C code would also help me
[08:18] <evfool> mardy: just found your signong-glib-google-demo, trying to decipher it :)
[08:19] <mardy> evfool: there's a patch for shotwell (it's written in Vala) to add support for Online Accounts
[08:19] <mardy> evfool: you could do "apt-get source shotwell" to get it
[08:21] <evfool> mardy: found it on launchpad already, in the deb folder, I assume 06_uoa.patch is the thing to look at ;)
[08:21] <mardy> evfool: yep :-)
[08:27] <evfool> mardy: thanks, I'll try some stuff, and will ping you if I get into trouble
[08:36] <doko> cjwatson, arm64 recently has issues with precompiled headers, not reliably reproducible.  as a workaround build without pch. would like to wait until 4.9 is the default and see if this persists
[08:43] <darkxst> dholbach, infinity while your piloting would be nice if you could look at the mega cleanup of g-s-d! seems no one else wants to!
[08:43] <darkxst> https://bugs.launchpad.net/ubuntu/+source/gnome-settings-daemon/+bug/1318539
[08:46] <zyga> 4~/exit
[08:50] <dholbach> darkxst, I'll have a look, but I could imagine that I won't know enough about it to make a good decision
[08:52] <pete-woods> mardy: hi, I'm trying to add a SSO provider for vimeo
[08:52] <pete-woods> but the process doesn't quite complete
[08:53] <pete-woods> I have logging output from the signon-ui: https://pastebin.canonical.com/110741/
[08:53] <pete-woods> it seems to get most of the way through the process
[08:54] <pete-woods> but the https://wiki.ubuntu.com/?=&code=4ee3705aabf48607fb237a925f9fd68b4a0f2d7a URL looks a bit weird to me
[08:54] <pete-woods> I can provide the provider / service files if that will help
[08:55] <jamesh> jdstrand: hi.  Would you know how to debug why dbus on my laptop doesn't seem to be handling apparmor?
[08:55] <mardy> pete-woods: hi! It's not clear from the logs what's happening; do you get to enter your username and password?
[08:55] <mardy> pete-woods: yes please, so I can try here
[08:55] <pete-woods> mardy: yes, I enter the credentials on the first page, it then does the usual "would you like to authorise this app" stuff
[08:56] <pete-woods> mardy: but then when I click accept it dumps me out with no error
[08:56] <mardy> pete-woods: it actually seems that the process completed successfully, I can see an authentication token in line 89
[08:56] <jamesh> mardy: I passed on your debug tips to pete-woods.  It is handling the authorize workflow, but never converting the access code into a token
[09:00] <cjwatson> doko: this one seems pretty reliable, FWIW ...
[09:00] <doko> cjwatson, ok, will try a local build
[09:01] <cjwatson> doko: I don't see a gcc option to disable precompiled headers - am I missing it?
[09:04] <pitti> cjwatson: would you happen to know why this isn't in -proposed yet? it got uploaded yesterday: https://launchpad.net/ubuntu/+source/autopilot-gtk/1.4+14.10.20140526-0ubuntu1
[09:04] <thomi> pitti: the langing hasn't completed yet
[09:04] <pitti> it seems LP doesn't want to publish it?
[09:04] <thomi> *landing
[09:05] <pitti> thomi: oh wow, you can upload something to Ubuntu and then kind of hold it back in limbo somehow?
[09:05] <thomi> pitti: check silo 19 on the SS
[09:05] <thomi> pitti: it didn't get uploaded to ubuntu
[09:05] <thomi> yet
[09:05] <pitti> ah, so that LP page is just utterly confusing then
[09:06] <thomi> hmmm, yeah, it's odd that LP shows it has been uploaded
[09:06] <cjwatson> pitti: The build was 22 hours old, but it was only very recently copied to -proposed
[09:06] <thomi> surely that doesn't include PPAs?
[09:06] <cjwatson> pitti: https://launchpad.net/ubuntu/+source/autopilot-gtk/+publishinghistory makes it clearer
[09:06] <cjwatson> thomi: Sure it does :)
[09:06] <thomi> oh, ok, cool
[09:06] <cjwatson> The buildd still has to upload builds for PPAs
[09:06] <pitti> cjwatson: aah, that makes much more sense now; thanks!
[09:07] <cjwatson> And indeed in this case it was uploaded by the jenkins bot
[09:07] <mardy> jamesh, pete-woods: the token is there, but somehow after receiving it, the authentication plugin gets an error serverReply : "{"error":"application/vnd.vimeo.auth"}"
[09:07] <cjwatson> You have to get the source into LP somehow at some point
[09:07] <jdstrand> jamesh: I am going to point you at tyhicks
[09:07] <cjwatson> Though you can then copy it around as much as you like later
[09:08] <pitti> cjwatson: yeah, I was confused by "uploaded by ps-jenkins bot 22 hours ago"
[09:08] <cjwatson> Right, that was the original source upload to the PPA
[09:08] <cjwatson> But yeah, I tend to reach for +publishinghistory pretty quickly
[09:08] <cjwatson> Since that's comprehensible :)
[09:08] <jdstrand> jamesh: though, I'm curious what you mean by 'handling apparmor'
[09:09] <jamesh> jdstrand: I'm getting errors when trying to execute org.freedesktop.DBus.GetConnectionAppArmorSecurityContext
[09:09] <jdstrand> jamesh: is this on utopic or trusty?
[09:09] <jamesh> e.g. "dbus-send --session --print-reply --dest=org.freedesktop.DBus /org/freedesktop/DBus org.freedesktop.DBus.GetConnectionAppArmorSecurityContext string::1.1" returns an error
[09:10] <jamesh> jdstrand: utopic.
[09:10] <jdstrand> jamesh: and you said on desktop?
[09:10] <jamesh> that command returns "unconfined" on my phone hardware, and an error on desktop
[09:10] <jdstrand> actually, I don't think tyhicks is needed after all
[09:11] <sarnold> how up-to-date is your utopic desktop? apparmor hasn't been adapted to the changes in the new 3.15.x kernel yet
[09:11] <jdstrand> jamesh: the utopic desktop kernel does not yet have all the apparmor patches (it has what is upstream, not the additional stuff we are in the process of upstreaming)
[09:11] <jamesh> ahh.
[09:11] <jamesh> and the phone has a completely different kernel
[09:11] <jdstrand> jamesh: that coming. if you boot a trusty kernel, that should unblock you
[09:11] <jdstrand> jamesh: yes
[09:12] <jdstrand> s/that/that is/
[09:12] <jamesh> thank you.
[09:13] <jamesh> jdstrand: fyi: we should have the mediascanner QML bindings going through D-Bus shortly.  I'm now working on adding the apparmor hooks to it
[09:13] <jamesh> the next step is to get every client of the mediascanner going through d-bus
[09:15] <jdstrand> jamesh: nice! that sounds great :)
[09:16] <jamesh> jdstrand: I'm a little concerned about encoding security policy directly into the daemon though (in particular, making decisions for particular security context labels)
[09:16] <jdstrand> jamesh: that is a workaround until there is trusted session support
[09:16] <jamesh> okay
[09:17] <jdstrand> jamesh: in mir. that isn't intended to be there forever. we don't now have a way to prompt the user if the access is ok (ie, you can't use trust-store) and we don't want to break the music-app, so we just do this
[09:17] <jdstrand> it is icky, but temporary
[09:18] <doko> cjwatson, it should be in the packaging. configure.in: bk_use_pch=no
[09:18] <doko> but I'll try to reproduce it first
[09:19] <jamesh> jdstrand: I was thinking more about the way media-hub encodes knowledge that an app has access to ~/.local/share/$package and ~/.cache/$package
[09:19] <jamesh> which presumably wouldn't invoke a trust-store dialog
[09:19] <jdstrand> let me look at the code real quick
[09:20] <slangasek> pitti: hmm, so, nfs-utils is a mess.  Are you readding the nfs-common init script because something depends on it?
[09:20] <pitti> slangasek: yes
[09:20] <xnox> slangasek: yeah.
[09:20] <slangasek> pitti: because we need to split this init script for proper systemd integration too, so I'd greatly prefer to move the other direction
[09:20] <slangasek> ah, what depends on it?
[09:21]  * pitti tries to find the pastebin again, hang on
[09:21] <xnox> slangasek: but pitti only created a dummy upstart job (ala mountall.sh)
[09:21] <slangasek> right
[09:21] <slangasek> but IIRC, idmapd may not always start?
[09:21] <slangasek> ditto statd
[09:21] <xnox> slangasek: should it be just or'ed ?
[09:21] <pitti> utopic/etc/init.d/umountnfs.sh:# Should-Stop:       $network $portmap nfs-common
[09:21] <pitti> utopic/etc/init.d/nfs-kernel-server:# Required-Start:    $remote_fs nfs-common $portmap $time
[09:21] <pitti> utopic/etc/init.d/nfs-kernel-server:# Required-Stop:     $remote_fs nfs-common $portmap $time
[09:21] <pitti> slangasek: ^
[09:22] <slangasek> ah, nfs-kernel-server, hah
[09:22] <xnox> slangasek: (sure the dependnecy will fire earlier then.....)
[09:22] <slangasek> so we at least could fix that in one place ;)
[09:22] <pitti> slangasek: so, not that much, but these could still creep in with syncs/merges from other packages, so I thought it'd be cleaner to keep Debian's and shadow it
[09:22] <cjwatson> doko: oh, you meant turn off pch in the gcc build, I thought you meant turn it off in the wxwidgets3.0 build
[09:22] <slangasek> pitti: right, but as nfs-utils comaintainer ;P, I'm planning to move this in the other direction in Debian
[09:22] <jdstrand> jamesh: ok, right. the point of media-hub and mediascanner is that they are trusted helpers. they are purposefully there to enforce access controls beyond the static apparmor policy. since media-hub and mediascanner2 allow access to other files, they need to be careful about how they do so
[09:23] <pitti> slangasek: other direction sounds even better, of course
[09:23] <jamesh> jdstrand: http://bazaar.launchpad.net/~phablet-team/media-hub/trunk/view/head:/src/core/media/player_skeleton.cpp#L153 <- that's the code
[09:23] <pitti> slangasek: do you plan to do that "soon", or can/should we use this to unblock the insserv transition (it
[09:24] <pitti> 's the last affected package)
[09:24] <slangasek> pitti: I was certainly planning on doing it "soon", and think it would be easier if we didn't then have to unpick another Ubuntu-specific upstart job in the process
[09:24] <jamesh> jdstrand: It just seems a bit weird to be repeating these parts of the security policy in each daemon (determining package names based on apparmor contexts, what files those contexts automatically have access to, etc)
[09:24] <jdstrand> jamesh: every trusted helper will be a little different. some, like location service, won't need to have more logic because they don't give out more access
[09:24] <jamesh> because if we change details of the policy, we'd need to go through each of these services and update it
[09:26] <jdstrand> jamesh: most trusted helpers don't have to do this
[09:26] <jamesh> okay
[09:26] <jdstrand> jamesh: and we don't expect the paths to change, cause the specification is using standard XDG directories
[09:26] <pitti> slangasek: so the other option which wouldn't introduce blocking right now is to drop that shim upstart job and just drop the dependency in nfs-kernel-server?
[09:27] <slangasek> pitti, xnox: anyway, I'm not exactly sure which of the components of nfs-common is a prereq for nfs-kernel-server, but each of these is possibly not going to start on boot and could block
[09:27] <slangasek> pitti: I wouldn't want to just drop the dep either
[09:29] <pitti> slangasek: ATM we only have an init.d for nfs-kernel-server and upstart jobs for nfs-"common"; how is that dependency being enforced right now?
[09:31] <doko> cjwatson, no, turn it off in the wxwidgets build
[09:32] <slangasek> pitti: because the nfs-kernel-server init script starts in runlevel 2 and the upstart jobs 'start on local-filesystems'.  If you have both nfs mounts and nfs-kernel-server there's guaranteed ordering, if you don't have nfs mounts there's a race but nfs-common has a head start
[09:32] <pitti> slangasek: ah, ok; so isn't that the same with changing nfs-kernel-server to either drop the nfs-common dep or drop it to should-start?
[09:33] <pitti> slangasek: (to avoid having to clean up nfs-common.conf later on after you do the split)
[09:33] <cjwatson> doko: oh, ok.  let me know if you want me to upload that then
[09:34] <cjwatson> (--disable-precomp-headers apparently)
[09:34] <slangasek> pitti: as long as you're on upstart, yes; will do the wrong thing on systemd, but that's a deeper problem which I suppose we can deal with a little bit later
[09:34] <pitti> slangasek: *nod*
[09:34] <slangasek> hmm, so did you already upload this?
[09:35] <pitti> slangasek: yes, but with block-proposed, so easy to change
[09:35] <slangasek> mmk
[09:37] <pitti> slangasek: so the total delta to what's currently in utopic would just be th drop the LSB header dep of kernel-server
[09:37] <pitti> s/th/to/
[09:37] <pitti> thomi: "Jenkins Fixed - utopic-adt-autopilot-gtk 13" \o/
[09:38] <slangasek> pitti: makes sense
[09:38] <thomi> pitti: virtual high-five!   o/
[09:38] <pitti> slangasek: ack
[09:38] <pitti> thomi: ^5s
[09:38] <thomi> :-/
[09:40] <pitti> thomi: I think that warrants a :-)
[09:40] <thomi> ...
[09:53] <mterry__> ogra_, any objections if I make /var/lib/lightdm (the greeter user's HOME dir) persistent?
[09:53] <mterry__> ogra_, in touch
[09:54] <ogra_> is there much stuff in it ... ?
[09:57] <ogra_> mterry__, (also do we need to wipe it for factory reset ? if so, please tell sergiusens )
[09:57] <mterry__> ogra_, just some typical cruft from being a user (some junk in .cache/.config)
[09:58] <mterry__> ogra_, for factory reset...  hmm  I guess -- I had assumed we just wipe disk and reinstall base system image?
[10:00] <xnox> stgraber: how does system image update
[10:01] <xnox> stgraber: does shutdown?
[10:01] <xnox> (reboot)
[10:04] <doko> cjwatson, please do. is not reproducible, and segfaults on a different file each time
[10:20] <GunnarHj> Hi pitti
[10:20] <pitti> hey GunnarHj
[10:20] <GunnarHj> pitti: Did you see this:
[10:20] <brendand> anyone come across this error before? dpkg-source: error: cannot represent change to trunk/.bzr/repository/packs/9245e3e3055bac62bf0c407a72389cbc.pack: binary file contents changed
[10:20] <GunnarHj> https://lists.ubuntu.com/archives/ubuntu-translators/2014-May/006512.html
[10:20] <brendand> why does debuild care about what's in .bzr?
[10:21] <cjwatson> use the exclude option
[10:21] <cjwatson> debuild -S -i -I
[10:21] <stgraber> or call bzr bd if it's that kind of branch
[10:21] <cjwatson> $ grep BUILDPACKAGE .devscripts
[10:21] <cjwatson> DEBUILD_DPKG_BUILDPACKAGE_OPTS="-i -I -uc -us"
[10:21] <cjwatson> or that yeah
[10:26] <Wellark> doko: which room are you in?
[10:27] <Wellark> there is something weird going on with gcc -dbg package dependencies
[10:29] <jamesh> jdstrand: thanks for your help.  I've got an MP for mediascanner here: https://code.launchpad.net/~jamesh/mediascanner2/dbus-apparmor/+merge/221058
[11:36] <dholbach> hey seb128 - I'm sure you're busy sprinting, but do you think somebody could take a look at https://bugs.launchpad.net/ubuntu/+source/gnome-settings-daemon/+bug/1318539? attente seems to have ACKed it already, but I personally can't judge if it should be uploaded or not
[11:36] <seb128> dholbach, go for it
[11:36] <seb128> dholbach, it's basically up to the GNOME remix team and it has been acked by attente
[11:36] <infinity> @pilot out
[11:37] <seb128> +1 on the principle from me, but I didn't do a detailed review
[11:38] <dholbach> @pilot out
[11:38] <dholbach> seb128, we could probably take a look and see what still depends on gnome-settings-daemon
[11:39] <dholbach> seb128, I had to "dpkg -P gnome-settings-daemon gnome-packagekit-session gnome-session ubuntu-system-settings gnome-control-center gnome-packagekit ubuntu-system-settings-online-accounts  account-plugin-ubuntuone  unity-scope-click" - I probably still had it installed from some older installation
[12:08] <ScottK> pitti: That's fine, the only thing is to please commit the changes to our bzr repo.
[12:08] <ScottK> (didn't check if you did already)
[12:09] <mterry__>  sergiusens, talk to me about factory reset when you get a chance
[12:09] <mterry__> sergiusens, on the phone
[12:10] <sergiusens> mterry__: sure, just come by 2c... I have only one meeting today; everything else is adhoc
[12:11] <seb128> dholbach, sorry, I got disconnected, not sure you got my reply (guess so from your upload)
[12:12] <pitti> ScottK: ah, will do
[12:12] <ScottK> pitti: Thanks.
[12:19] <xnox> slangasek: nexus 5 works
[12:19] <xnox> slangasek: bregma is not online =)
[12:30] <pitti> infinity: argh, I just noticed that I didn't bump the copy limits of eglibc, which explains the timeouts
[12:31] <infinity> pitti: Meh, it'll be "fixed" after I merge from Debian anyway.
[12:31] <pitti> infinity: while I'm at it, if I give the VM 4 CPUs, does the build make use of that?
[12:31] <infinity> pitti: Yeahp, the build will happily eat more cored.
[12:31] <infinity> pitti: cores, too.
[12:32] <pitti> infinity: ack, config pushed (with 4 cores)
[12:32] <pitti> infinity: current build cancelled and restarted, I think/hope it'll succeed now
[12:33] <pitti> argh, I thought we already had an override; for that it held up surprisingly well..
[12:39] <pitti> ... or I would if jenkins wouldn't be nasty again
[12:47] <mardy> pete-woods: hi! According to https://developer.vimeo.com/api/authentication, it should be possible to find the authorization header on the application webpage
[12:47] <mardy> pete-woods: could you please tell me the code? I'm generating it according to the instructions, but vimeo stills gives me an error, so maybe I'm doing it wrong
[12:54] <Mirv> hmm, I'm getting chroot error on amd64, i386 and ppc64el builders: https://launchpadlibrarian.net/176409150/buildlog_ubuntu-utopic-amd64.qtbase-opensource-src_5.3.0%2Bdfsg-2ubuntu1~utopic1~test1_CHROOTWAIT.txt.gz
[12:57] <jamesh> jdstrand: the d-bus AppArmor stuff doesn't seem to work in Jenkins builds.  Do you have any suggestions on how to handle that?
[12:58] <jamesh> jdstrand: allowing everything when the AA check fails would work, but sounds like something that could be used in an exploit.
[13:02] <sarnold> jamesh: are they perhaps using the 3.15-ish kernels?
[13:03] <jamesh> sarnold: I don't know.
[13:04] <jamesh> IIRC, it runs the tests in a chroot so I don't know what the host system is
[13:06] <shadeslayer> pitti: re autopkgtests , what happens if a autopkgtest fails? Does it block package migration from proposed to release?
[13:10] <tyhicks> jamesh: can you give me more detail on why you think dbus mediation isn't working with jenkins?
[13:11] <pitti> shadeslayer: if it ever succeeded, i. e. it's a regression, then yes
[13:11] <shadeslayer> aha
[13:11] <pitti> shadeslayer: if it always failed, we consider the test broken and ignore it
[13:12] <shadeslayer> cool, thanks
[13:12] <GunnarHj> pitti: Did you forget about the link I posted?
[13:12] <shadeslayer> pitti: and just so I understand correctly, autopkg tests are run separately from the actual build on launchpad correct?
[13:12] <pitti> shadeslayer: yes
[13:12] <shadeslayer> ack, thanks
[13:12] <pitti> GunnarHj: sorry, probably drowned (sprint/discussions here)
[13:13] <GunnarHj> pitti: https://lists.ubuntu.com/archives/ubuntu-translators/2014-May/006512.html
[13:13] <pitti> GunnarHj: yep, got your mail, just didn't find time to respond yet
[13:13] <GunnarHj> pitti: Ok.
[13:14] <GunnarHj> pitti: One thing I wonder about is who is supposed to initiate translation updates. I haven't found any schedule for when things are copied to -proposed for testing.
[13:15] <jamesh> tyhicks: https://jenkins.qa.ubuntu.com/job/mediascanner2-utopic-amd64-ci/19/consoleFull <- right at the bottom one of the erros is "Error getting apparmor context: org.freedesktop.DBus.Error.AppArmorSecurityContextUnknown: Could not determine security context for ':1.1'"
[13:15] <pitti> GunnarHj: there's nobody right now; it used to be dpm, but he works on other stuff now
[13:15] <GunnarHj> pitti: Just as I feared, then.
[13:15] <jamesh> tyhicks: which is the error I was getting locally with the Utopic kernel (I reverted locally to the trusty kernel at jdstrand's suggestion)
[13:29] <infinity> xnox: Where are you?
[13:29] <shadeslayer> looks like something went kaput https://launchpad.net/ubuntu/+source/kde4libs/4:4.13.0-0ubuntu4
[13:29] <infinity> xnox: Making everything in the archive have a versioned upstart dependency seems like exactly the opposite of what we want.
[13:30] <shadeslayer> seems like what I'm facing ^^
[13:30] <infinity> shadeslayer: Oh, fun.
[13:34] <stgraber> xnox: thanks for breaking the archive
[13:46] <tyhicks> jamesh: I suspect that securityfs is not mounted (or bind mounted) in the chroot
[13:47] <tyhicks> jamesh: the apparmor dbus mediation sees that and can't determine if it should enforce rules so, by default, it disables the apparmor checks
[13:48] <tyhicks> (there is an option in the bus config file to not fall open like that, but that's not the issue here...)
[13:48] <tyhicks> jamesh: the only issue is when you're asking for the apparmor confinement context of a given connection
[13:49] <tyhicks> jamesh: IMO, it is currently doing the right thing by returning a DBUS_ERROR_APPARMOR_SECURITY_CONTEXT_UNKNOWN error
[13:50] <tyhicks> jamesh: I think the best fix here would be to get securityfs mounted in the chroot
[13:53] <xnox> infinity: sorry........... =)
[13:59] <tyhicks> jamesh: but... it is completely possible that the jenkins kernel is the 3.15 utopic kernel that doesn't have the necessary apparmor patches
[13:59] <tyhicks> jamesh: I just don't know enough about that environment or how to find more info on it
[14:01] <jamesh> tyhicks: okay, I'll try following up there.  Thanks for the help.
[14:01] <jjohansen1> tyhicks, jamesh: the 3.15 utopic kernel is missing the necessary patches, that will be fixed soon
[14:05] <pitti> xnox: oh, you still want to block sysvinit? kde-workspace went in
[14:06] <dpm> GunnarHj, pitti, exactly. A community member used to help creating the schedule in later times, but he got busy with other stuff too. Here's an example of the release schedule we set up for releases a while ago: https://wiki.ubuntu.com/Translations/NattyLanguagePackReleaseSchedule
[14:08] <GunnarHj> dpm, pitti: Thanks, that's exactly what I had in mind. Would you recommend that we basically copy it for trusty?
[14:11] <pitti> infinity: https://launchpad.net/ubuntu/utopic/+source/systemd/204-10ubuntu5 -> "Broke the world from the new upstart dependency" ?
[14:12] <pitti> infinity: do you have some details on that? I've run this for 2 days now
[14:13] <pitti> or did that interact badly with the dh_installinit upload or something?
[14:16] <infinity> pitti: See the build log for https://launchpad.net/ubuntu/+source/kde4libs/4:4.13.0-0ubuntu4 for instance.
[14:16] <rbasak> What do people use to get the source package name of a binary package? chdist bin2src is crashing on me.
[14:16] <infinity> pitti: Dep loop that triggered an apt bug.
[14:16] <infinity> pitti: But, apt bug notwithstanding, having everything with an upstart job have a dep on upstart is just plain wrong.
[14:17] <infinity> pitti: So, we're moving that lsb init snippet to lsb-base, and moving the dep there instead.
[14:17] <pitti> infinity: ah, perhaps we could turn this into a Breaks: upstart (<<)
[14:17] <infinity> pitti: And rebuilding everything with the upstart dep.
[14:17] <infinity> pitti: We thought about a breaks, but can't quite sort out WHAT would break upstart.
[14:17] <pitti> infinity: ah, even better
[14:18] <pitti> infinity: with breaks: we'd need sourceful changes, so depends: indeed would be better
[14:18] <pitti> infinity: are xnox and you already at it? anything I should do now?
[14:18] <infinity> pitti: stgraber and I are on it.
[14:20] <infinity> pitti: How did you notice the systemd deletion, BTW? :P
[14:20] <infinity> pitti: Oh, I guess you nogticed me copying in the old one.
[14:20] <pitti> infinity: I got a "released to utopic" mail for ubuntu4, and wondered where ubuntu5 went to
[14:23] <diwic> hmm, I thought we were all going to ditch upstart for systemd but now it seems things are going the other way around...
[14:23] <pitti> diwic: how so?
[14:23] <pitti> diwic: it's just a rather long dependency chain
[14:24] <diwic> pitti, you were adding empty upstart scripts and infinity talks about systemd deletion? :-)
[14:24] <pitti> diwic: fixing our packages to comply to Debian init.d/upstart/systemd policy → moving from legacy init.d ordering to insserv → merging sysvinit → adding systemd equivalents to upstart jobs
[14:24] <pitti> diwic: ah, I didn't see the implied :)
[14:25] <pitti> it's kind of weird that we have to fix sysvinit first, but overall that's the path of least resistance/work/delta to Debian
[14:25] <pitti> (in fact it's mostly "remove some Ubuntu delta")
[14:26] <diwic> pitti, okay, looks like you have it all under control then ;-)
[14:27] <pitti> kind of, except for details like breaking all builds (thanks infinity for quick action!)
[14:27] <pitti> diwic: so, let's say we know the path now :)
[14:27] <diwic> pitti, all right then :)
[14:29] <pitti> infinity: I suppose we can retry https://launchpad.net/ubuntu/+source/debhelper/9.20140228ubuntu3/+build/6045112 now :)
[14:30] <shadeslayer> so is the brokenness fixed now?
[14:30] <pitti> shadeslayer: AFAICS, yes
[14:30] <pitti> udev | 204-10ubuntu4   | utopic          | amd64, arm64, armhf, i386, powerpc, ppc64el
[14:30] <pitti> and nothing in -proposed
[14:30] <shadeslayer> hm
[14:30] <pitti> i. e. the apt dependency loop should be gone
[14:31] <pitti> and debhelper is happily installing its build deps now
[14:31] <shadeslayer> rebuilding kdelibs, lets see
[14:31] <shadeslayer> because it doesn't work locally
[14:31] <pitti> shadeslayer: wait
[14:31] <shadeslayer> oh
[14:31] <pitti> https://launchpadlibrarian.net/176413792/buildlog_ubuntu-utopic-i386.debhelper_9.20140228ubuntu3_CHROOTWAIT.txt.gz still failed, hmm
[14:32] <shadeslayer> pitti: http://paste.ubuntu.com/7529745/
[14:32] <dpm> GunnarHj, sorry for the delay. I'd say yes, but let me find you a more recent template than the one for natty
[14:32] <pitti> Unpacking udev (204-10ubuntu5) over (204-10ubuntu1) ...
[14:33] <pitti> shadeslayer: ^ your build log still has the ubuntu5 version which infinity removed
[14:33] <shadeslayer> pitti: yeah, trying to figure out why
[14:33] <pitti> shadeslayer: probably just mirror lag; the LP buildds use ftpmaster.internal
[14:33] <shadeslayer> yeah
[14:33] <shadeslayer> pitti: https://launchpadlibrarian.net/176413830/buildlog_ubuntu-utopic-amd64.kde4libs_4%3A4.13.0-0ubuntu4_CHROOTWAIT.txt.gz  < plymouth issue
[14:33] <pitti> yes, same as debhelper
[14:34] <shadeslayer> yep
[14:34] <dpm> GunnarHj, here's the raring one: https://wiki.ubuntu.com/Translations/RaringRingtail/ReleaseSchedule
[14:35] <GunnarHj> dpm: It says raring in the URL, but it's actually precise. ;)
[14:36] <pitti> probably this:
[14:36] <pitti>  initscripts depends on upstart (>= 1.12.1-0ubuntu6); however:
[14:36] <pitti>   Package upstart is not configured yet.
[14:36] <dpm> GunnarHj, I guess it was copied from Precise and we never actually used that one :)
[14:36] <pitti> thus we need to rebuild the latest sysvinit upload against the reverted debhelper, and need the rebuilt sysvinit to build debhelper; yay loops
[14:37] <GunnarHj> dpm: I see. So there hasn't been any systematic translation updates since 12.04?
[14:40] <dpm> GunnarHj, most probably no. I know we've done some updates, but as you're saying, not systematically
[14:40] <GunnarHj> dpm: Ok. Anyway, thanks for the link. I'll make a proposal for trusty based on it.
[14:41] <dpm> GunnarHj, sounds great, thanks!
[14:42] <shadeslayer> pitti: hah :D
[14:43] <xnox> pitti: sysvinit must depend on new upstart though....
[14:43] <xnox> pitti: if that's bad, we'd need to move the hook elsewhere.
[14:43] <xnox> pitti: sysvinit is currently blocked from migrating.
[14:43] <pitti> xnox: the hook is being moved to lsb-base AFAIUI
[14:43] <pitti> xnox: hm, it did migrate already
[14:43] <pitti> I can't reproduce the upgrade failure in a schroot
[14:44] <Elv1313> I got this while accessing errors.ubuntu.com for a little while http://pastebin.com/2s4ud5rk as an error message, it look as a hack, might not be the brightest idea ever
[14:44] <xnox> pitti: ok, i hread that mentioned, but it was not definitive at the time, i don't think.
[14:44] <xnox> slangasek: infinity: stgraber: what's the current plan for unbreaking & steps that we need to do to land insserv?
[14:45] <xnox> pitti: cause e.g. adding in sysv-rc breaks upstart << (version with hook) was also offered.
[14:45] <xnox> which shouldn't have any side-effects if upstart is not installed to begin with, and triggers the update otherwise.
[14:46] <pitti> infinity, stgraber, xnox: so I'm trying to understand the current failure, did you already reproduce this somehow?
[14:46] <pitti> [-upstart,-] {+upstart (>= 1.12.1-0ubuntu6),+}
[14:46] <pitti> I figure it's somehow related to this change initscripts, but I don't understand why
[14:46] <xnox> pitti: that's manual change in the debdiff.
[14:46] <infinity> pitti: It's actually probably the sysv-rc/initscripts loop, I'm doing some reversions.
[14:47] <infinity> xnox: stgraber and I are sorting this out.
[14:47] <xnox> infinity: ok. thanks.
[14:47] <xnox> pitti: let's wait for inifinity & stgraber to unwind this =)
[14:49] <mdeslaur> infinity, pitti, stgraber, slangasek: are we still having a tech board meeting in an hour?
[14:50] <pitti> mdeslaur: yes, I think so; we can have it IRL, maybe at the nice patio in front of the coffee area?
[14:50] <mdeslaur> pitti: sounds good to me
[14:50] <Laney> is the whole tb here?
[14:51] <pitti> infinity: wow, I didn't know we could do this now (revert ubuntu13 to ubuntu12 in the release)
[14:51] <pitti> Laney: yes
[14:51] <pitti> mdeslaur: and I expect today's meeting to be < 15 mins :)
[14:53] <infinity> pitti: We can't.  You didn't see anything.
[14:54] <pitti> infinity: /me performs self-lobotomy
[14:54] <infinity> pitti: Good job.
[14:54] <infinity> xnox: Was there a reason you decided sysv-rc needed a dep on initscripts?
[14:54] <infinity> xnox: Before I tear that right out again? :P
[14:56] <xnox> infinity: yes, cause insserv in sysv-rc may not be enabled without the update initscripts.
[14:57] <xnox> infinity: initsctipts & sysv-rc can instead both break "upstart (<< magic-version number)" (the version that first introduced the hook)
[14:57] <infinity> xnox: Well, that introduces a dep loop, so won't do what you wanted even if it worked.
[14:57] <xnox> infinity: would the two breaks do what I want?
[14:58] <infinity> xnox: initscripts will depend on the lsb-base where we moved the hook.
[14:58] <xnox> infinity: ok, that works fine then.
[14:58] <infinity> xnox: But what does sysv-rc have to do with it?
[14:58] <xnox> infinity: that mean that initscripts can be upgraded independant of sysv-rc.
[14:59] <pitti> so breaks: then?
[14:59] <infinity> xnox: Right, so sysv-rc breaks initscripts << foo.
[14:59] <infinity> I'll give that a spin.
[14:59] <xnox> infinity: yes.
[15:00] <xnox> (which should result in the same desired final outcome)
[15:01] <xnox> cyphermox: can you take this patch into urfkill http://paste.ubuntu.com/7529928/ ? to potentially remove two races.
[15:03] <cyphermox> xnox: sure
[15:03] <cyphermox> xnox: where did you see these issues?
[15:08] <xnox> cyphermox: this is by inspection, not from real problem.
[15:09] <cyphermox> ok
[15:09] <xnox> cyphermox: awe_ and I were inspecting things trying to find a race, and these are two minor but potential issues.
[15:09] <cyphermox> well, I have them applied here, will include in the next upload
[15:09] <xnox> cyphermox: tah.
[15:09] <zbenjamin> sarnold: any luck yet? :)
[15:09] <cyphermox> I'm testing some other fixes that could correct races
[15:10] <cyphermox> xnox: awe_ should know, I have a package ready to test in my PPA
[15:13] <sarnold> zbenjamin: no, sorry :)
[15:13] <zbenjamin> sarnold: ok thx
[15:14] <zbenjamin> sarnold: would it be different if i would ship gdbserver inside the click package? Or would the ptrace still fail?
[15:16] <zbenjamin> sarnold: not that i want to do that because with fat packages it would be a mess. But would be interesting to know
[15:16] <sarnold> zbenjamin: the ptrace operations should still fail, yeah
[15:17] <sarnold> zbenjamin: probably the 'right' approach would be to create a new child profile for gdb or gdbserver. it might be worth going down that road a little bit to see what's required inside the child profile.
[15:18] <sarnold> zbenjamin: http://wiki.apparmor.net/index.php/QuickProfileLanguage#Child_profiles
[15:19] <zbenjamin> sarnold: that means gdbserver would run unconfined but the click app would not?
[15:20] <sarnold> zbenjamin: well, I got to thinking that perhaps the gdbserver Ux, might actually run the whole thing unconfined.
[15:20] <zbenjamin> ok that would make the whole effort pointless
[15:20] <sarnold> yeah
[15:21] <sarnold> zbenjamin: creating a child profile for gdbserver would let us keep it in a profile and keep the 'main' profile clean -- if we added the needed privileges right to the profile, the program may not behave the same when the debug group is added
[15:22] <zbenjamin> sarnold: true, that sounds good to me.
[15:32] <rbasak> What do people use to get the source package name of a binary package? chdist bin2src is crashing on me.
[15:33] <rbasak> (before I go and write my own grep-dctrl wrapper...)
[15:33] <xnox> rbasak: is it crashing because source has been removed.... ?!
[15:34] <rbasak> xnox: I just filed https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=749504
[15:35] <xnox> rbasak: such package does not exist in debian?! $ rmadison -S apache2-bin -u debian
[15:36] <xnox> rbasak: however, it exists in at least saucy, trusty and utopic.
[15:37] <sarnold> rbasak: I've got an 'lpsrc' shell function: apt-cache showsrc "$*" | grep --color=auto '^Binary: ' | sed -e 's/Binary: //' -e 's/ //g' -e 's/,/\n/g' | sort -u
[15:37] <sarnold> rbasak: it's far from perfect but I can usually spot the source pcakage I need with it..
[15:37] <infinity> xnox: Eh?  It's a binary package.
[15:37] <infinity> xnox: You might be rmadisoning incorrectly. :P
[15:40] <xnox> infinity: oh, rmadisoning against ubuntu and debian is different. =)))) on ubuntu -S is like a modifier (iff source, also print all binaries). Cause against ubuntu "rmadison libc6" & "rmadison -S libc6" for example return the same thing.
[15:40] <infinity> xnox: That would be a bug in the Ubuntu madison.cgi
[15:41] <xnox> infinity: =(
[16:00] <pitti> slangasek, infinity, kees, mdeslaur, stgraber: reminder that TB meeting is in #ubuntu-meeting-2 (collision with server meeting in #u-m)
[16:00] <stgraber> pitti: oh, is that going to be happening every week? we probably should have considered that when doing the doodle :)
[16:01] <pitti> stgraber: well, we already had few enough options without considering meeting channel colissions :)
[16:02] <sarnold> pitti: mdeslaur may have taken the physical meeting suuggestion literally :)
[16:02] <ogra_> slangasek, bug 1323732 for you
[16:02] <sarnold> mdeslaur: #ubuntu-meeting-2
[16:03] <mdeslaur> sarnold: thanks!
[16:04] <jdstrand> jamesh: hey, so I got the MR, I'll look at it when I have a moment
[16:05] <jamesh> jdstrand: thanks.
[16:05] <jdstrand> jamesh: I did want to mention that I was thinking about your question about the policy in the trusted helper, and I remembered that we are introducing the apparmor query interface
[16:05] <jamesh> jdstrand: in case I have more questions, which room are you in this week?
[16:06] <jdstrand> jamesh: we have a bit of it now, but when it is done, we will have libapparmor api such that you can ask 'hey can this process running under this profile access this file?"
[16:06] <jdstrand> jamesh: once we have that, we can clean up mediascanner and media-hub. however, that isn't going to be fixed super soon
[16:06] <jdstrand> jamesh: just fyi
[16:06] <jdstrand> jamesh: I am in 2C when I am not in meeting
[16:06] <jamesh> jdstrand: sounds good.
[16:06] <jdstrand> meetings
[16:07] <tyhicks> jamesh: fyi, I'm in 2C this week, too
[16:08] <mhall119> slangasek: ping
[16:10] <ogra_> hallyn, we see a new cgmanager crash during image tests ... http://ci.ubuntu.com/smokeng/utopic/touch/mako/50:20140527:20140523/8241/click_image_tests/ (scroll to the bottom)
[16:10] <hallyn> "pass rate 100%"  /me doens't know how to interpret that
[16:10] <slangasek> mhall119: hi
[16:11] <hallyn> oh that one
[16:11] <ogra_> hallyn, well, the test itself passes but alongside that .crash file appears
[16:11] <mhall119> slangasek: hey, every track but Platform Dev has at lest one non-Canonical track lead, do you have any recommendations for who in the community (Ubuntu's or Debian's) would be a good candidate for that?
[16:12] <mhall119> I'd very much like to get more community participation in the call for and scheduling of sessions
[16:13] <hallyn> ogra_: there is a new version in utopic-proposed.  i'm hoping that''ll fix that (though no guaarentees)
[16:13] <hallyn> it looks like genuine stack corruption...  hm
[16:13] <hallyn> ogra_: can you run a set of tests with the -proposed version?
[16:13] <slangasek> mhall119: what's "platform dev"?
[16:13] <hallyn> (I assume this is not 100% reliably failing, so it wouldnt guarantee anything, but...)
[16:14] <ogra_> hallyn, well, we'll just wait til it lands then
[16:14] <slangasek> mhall119: has the core track been renamed, or is this something else?
[16:14] <ogra_> hallyn, our nightly automated image build will pick it up anyway
[16:14] <hallyn> ogra_: ok, thanks  (i also need ot sru that to trusty today, though it'll be a tough one to write a testcase for :)
[16:14] <ogra_> :)
[16:15] <ogra_> hallyn, oh, does that also include the fix for mterry__ ?
[16:15] <mhall119> slangasek: it's a combination of foundations, client and server tracks
[16:15] <hallyn> ogra_: yeah that's his in fact
[16:15] <ogra_> yay, thats grat
[16:15] <ogra_> *great too :)
[16:15] <mhall119> slangasek: so basically everything from past vUDS except community and appdev is now "Platform Development"
[16:16] <hallyn> i have a feeling there's another bug which may be responsible for yours - i'm guessing similar to the one mterry__ fixed
[16:16] <hallyn> i.e. due to my mis-use of nih
[16:16] <ogra_> heh, k ... we'll see
[16:16] <slangasek> mhall119: hmm. and where can I see a list of the other tracks (to understand who from the community might relevantly fit under this umbrella, vs. being on a different track)?
[16:17] <mhall119> slangasek: http://summit.ubuntu.com/uos-1406/tracks
[16:17] <mterry__> hallyn, we need lxc/kernel fixes to unblock cgmanager  :(
[16:18] <mhall119> slangasek: anything that's historically  been considered "Ubuntu development" would fall under this track
[16:18] <hallyn> mterry__: hm?
[16:18] <hallyn> why would cgmanager be blocked on lxc?
[16:18] <mterry__> hallyn, cgmanager has been in the proposed queue for days
[16:18] <slangasek> mhall119: ok; off the top of my head, maybe ScottK?
[16:18] <hallyn> mterry__: exactly waht is it blocked on?
[16:18] <mterry__> hallyn, http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html
[16:18] <mterry__> hallyn, lxc's autopkgtest fails
[16:18] <mterry__> hallyn, due to some kernel issues
[16:19] <mhall119> ScottK: would you be interested in being a track lead for Platform Development in the next UDS? It'll be June 10-12, but your main responsibility would be in asking people to propose sessions and getting them approved & scheduled
[16:19] <hallyn> hm there's an open bug for that right?  i guess that should move to the top of my queue then
[16:19] <ogra_> ++
[16:20] <mterry__> hallyn, ogra_, bug 1323528
[16:20] <mterry__> hallyn, ogra_, additionally there was a needed lxc update (but that's sitting in proposed too)
[16:21] <hallyn> mterry__: d'oh.  ok i can't do anything about that one
[16:21] <mterry__> hallyn, yeah  :(  me neither
[16:21] <hallyn> back to packaging netcf then - thanks, ttyl
[16:24] <ogra_> mterry__, you actually can ... pay beers to the kernel team till they agree on fixing it asap
[16:24] <ogra_> beer always works
[16:24] <ogra_> at least on them
[16:25] <mterry__> :)
[16:40] <brendand> ogra_, just remember to do it during happy hour :)
[20:43] <ScottK> mhall119: Sorry. No time in the near term for something like that.
[20:44] <mhall119> ScottK: even just recruiting sessions and approving them?
[20:44] <mhall119> ScottK: anybody else from the Kubuntu devs you think would be good for me to ask?
[20:46] <ScottK> Kubuntu has already had its planning session for the cycle.
[20:47] <ScottK> I think the only thing we really care about is getting moving on Qt5 5.3.
[20:48] <ScottK> mhall119: Even that. I expect to be offline more than on between now and then.
[20:51] <mhall119> ScottK: how about presentation-style sessions like how to get involved
[20:52] <ScottK> Ask Riddell.