[02:33] <psusi> cjwatson, what do you think about adding a test to partman-ext3's check.d to tell you ( roughly ) "hey dummy, you didn't set up an efi system partition and mount it in /boot/grub/efi"?
[02:33] <psusi> err, partman-efi rather
[02:51] <happyaron> infinity: beta image
[03:17] <smoser> slangasek, https://pastebin.canonical.com/107156/
[03:17] <smoser> that make any sense to you?
[03:17] <smoser> or anhyone else have ideas on how /etc/mtab got foobar'd to not include /
[03:17] <smoser> that is precise
[03:30] <psusi> smoser, that's odd.. I don't have access to that pastebin
[03:30] <smoser> bah.
[03:30] <smoser> yeah, that sucks.
[03:30] <smoser> here, repaste
[03:30] <psusi> smoser, but as a general rule, mtab gets foobared all kinds of ways, which is why upstream removed it some time ago
[03:30] <psusi> but we're still stuck on a very old util-linux
[03:31] <smoser> and replaced with link to /proc/mounts ?
[03:31] <psusi> yep
[03:31] <smoser> http://paste.ubuntu.com/7154679/
[03:32] <psusi> I've been trying to get it updated for some time... spoke with infinity last week and he said he would block out some time to do it properly instead of my kind of hackish update soon
[03:34] <psusi> ( basically I gave up on trying to identify which of the 1000+ commits in the debian repo that diverge from upstream actually matter and aren't already upstreamed and just threw them all out and copied the debian/ dir into the new upstream source and changed it to 3.0 quilt format )
[03:36] <psusi> which probably would have introduced a regression or two, but I thought was worth it to get a clean start on an updated upstream rather than spending days analyzing that many bloody commits to pick out the handful that actually needed ported to quilt
[04:42] <slangasek> smoser: if the rootfs was already mounted rw in the initramfs; or if the rootfs isn't listed at all in /etc/fstab; maybe that would account for it?
[05:51] <pitti> Good morning
[06:01] <pitti> Noskcaj: oh, what were the objections against uploads for xubuntu?
[06:02] <Noskcaj> ?
[06:06] <Noskcaj> pitti, Do you mean in my dmb meeting?
[06:10] <pitti> Noskcaj: yes
[06:11] <Noskcaj> The exact same reasons as with motu. Three out of four present members said they thought my quality of work wasn't enough
[06:12] <Noskcaj> I ended up with rights for 4 packages, when i'm the debian maintainer for nearly all of xubuntu's apps
[06:13] <pitti> yeah, I can understand the reason for waiting with MOTU TBH, but the xubuntu apps are pretty much all the same, packaging and policy wise
[06:13] <pitti> anyway, just try again in half a year or so
[06:13] <Noskcaj> yep
[06:14] <pitti> Noskcaj: I'm curious, how well does the sponsoring process work from your perspective? I. e. whats the usual delay?
[06:14] <Noskcaj> pitti, anywhere from 12 hours (for easy syncs) to a month (merges and patches)
[06:15] <Noskcaj> The sponsoring process is good for syncs, since nearly all are done in a few days, but merges average 1 week or more
[06:15] <Noskcaj> Unrelated, would it be worth syncing gnome-icon-theme-extras? build fixes + icons for SSDs
[06:18] <pitti> sounds harmless enough
[06:30] <Noskcaj> pitti, Will you sync the new glib releases? glib2.0 is fixes to docs, tests, and translations, and -networking is just translations the depends change you made
[06:30] <Noskcaj> actual, beta freeze, so ignore the above for this week
[06:30] <Noskcaj> *actually
[06:41] <pitti> Noskcaj: yes, we most definitively want to do that; no worries, that's what we have -proposed for :)
[06:41]  * pitti will package gobject-introspection too and upload it to exp/sync to trusty
[06:41] <Noskcaj> ok. I'm just looking for 3.12 stuff we want.
[06:41] <pitti> ah, someone already did,  nice
[06:43] <pitti> Noskcaj: so yes, will do that tomorrow, when the images are set and there is no chance that we'll need -proposed for an urgent fix for beta-2
[06:43] <Noskcaj> ok, cool
[06:43] <Noskcaj> glibmm can probably get one more experimental point release (doc fixes) but not all the way to 3.12
[06:43] <Noskcaj> I'm just using the irc logs as a reminder to myself now
[07:37] <zyga> good morning
[07:57] <dholbach> good morning
[09:56] <menace> Hi, there were security announces about initramfs-tools and openssh on the Ubuntu Security Announce. But i see the updated packets for precise not in precise-security, but in precise-updates. Why? I would have assumed, it comes with the Security Repository? Do i understand something the wrong way?
[09:56] <pitti> menace: they should be in both repositories
[09:56] <pitti> menace: confirm with apt-cache policy openssh
[09:57] <pitti> menace: -updates are mirrored, so they can usually be downloaded faster than from security.u.c.
[09:57] <pitti> menace: I meant apt-cache policy openssh-server
[09:57] <menace> ah, okay, that could explain why it was not in my security mirror.
[09:58] <menace> another question: is there any "garantued" time from security announcement til appearance in the update/security repository?
[09:58] <pitti> menace: when the announcement goes out, the update is alreayd on security.u.c
[09:59] <pitti> menace: it of course may take some time until it is in -updates on your mirror
[09:59] <pitti> until then, you'll download from -security; from then on, you'll download from -updates
[09:59] <pitti> (that's the point of having it in both)
[10:00] <pitti> sforshee: can such an iwlfifi error be triggered synthetically for testing?
[10:01] <pitti> sforshee: e. g. on my system the /iwlwifi/iwlmvm/fw_error_dump path doesn't exist, I only have a "iwldvm" directory (not iwlmvm)
[10:04] <pitti> sforshee: I replied on the MP, better keep the discussion at one place
[10:09] <smoser> slangasek, possibly root was mounted rw in initramfs, but i'm not sure why that would have occurred. /etc/fstab never channged and the initramfs successfully found the root (missing data from that paste then is /proc/cmdline).
[10:40] <zyga> pitti: what decides which gettext domains are added to language packs? just being in main or is there a secondary mechanism
[10:46] <Saviq> can anyone make bug# 1232146 public please?
[10:47] <zyga> Saviq: I can, it seems
[10:47] <zyga> Saviq: are you sure?
[10:47] <Saviq> zyga, dunno, not my bug :D
[10:47] <Saviq> zyga, I can't see it
[10:47] <Laney> I did it
[10:47] <pitti> zyga: being in main, plus the ones whose source packages declare X-Ubuntu-Use-Langpack: yes
[10:47] <Saviq> Laney, thanks
[10:48] <zyga> oohhh
[10:48] <zyga> pitti: ah, I misread you, ok
[10:49] <zyga> pitti: so all I need is to wait for the next langpack rebuild, I was looking at plainbox packages and they lost their translations as compared to debian
[10:49] <pitti> zyga: i.e. "plus" == "or", not "and"
[10:49] <zyga> pitti: right
[10:49] <zyga> pitti: thanks
[10:49] <pitti> zyga: did plainbox recently move to main?
[10:50] <pitti> zyga: yesterday's langpack build (with data from March 20) does not  have any trace of "plainbox"
[10:50] <zyga> pitti: not recently, but only recently it gained i18n (after 0.5~b2 was synced to main by doko a few days ago)
[10:51] <pitti> zyga: no templates available: https://translations.launchpad.net/ubuntu/trusty/+source/plainbox
[10:51] <zyga> hmm
[10:51] <zyga> how can I debug that?
[10:51] <pitti> zyga: there are some at https://translations.launchpad.net/ubuntu/trusty/+source/plainbox/+imports
[10:51] <zyga> oh
[10:51] <zyga> so I need to manage that now?
[10:51] <pitti> at this point I don't know any more what needs to happen; dpm ^
[10:51] <pitti> zyga: that's an one-time thing AFAIK
[10:52] <zyga> pitti: I don't seem to have the rights to approve those
[10:52] <pitti> neither have I
[10:53] <zyga> pitti: thanks for helping, I'll try to understand how this works
[10:53] <pitti> zyga: dpm should know how to proceed from that
[10:58] <dpm> pitti, zyga, let me see if I can have a look before my next call in a few mins
[10:58] <zyga> dpm: thanks
[11:00] <dpm> zyga, ok, I've approved the po/plainbox.pot template. It's a bit of a pain that it's a manual approval for each new template, but it should be done now. I guess the other 2 .pot files are a product of the build and can be ignored?
[11:00] <dpm> https://translations.launchpad.net/ubuntu/trusty/+source/plainbox/+imports?field.filter_status=all&field.filter_extension=pot
[11:00] <zyga> yes
[11:00] <zyga> all the debian ones are dupes
[11:01] <zyga> (I wonder if we should strip those during the build now)
[11:08] <zyga> dpm: could you also approve 'stubbox.pot', the one in  plainbox/impl/providers/stubbox/po/stubbox.pot
[11:08] <zyga> dpm: it is a part of the same package
[11:17] <doko> will make a component-mismatch day today ...
[11:18] <zbenjamin> cjohnston: ping, can you help me with some ideas about a sdk-launcher, that allows me to run and monitor a application in a special way?
[11:18] <zbenjamin> cjohnston: sorry wrong nick
[11:18] <zbenjamin> cjwatson: ping, can you help me with some ideas about a sdk-launcher, that allows me to run and monitor a application in a special way?
[11:19] <zbenjamin> cjwatson: i wrote down what i need, its point 4 in this document: https://docs.google.com/a/canonical.com/document/d/1hCWBkCu81lEQMqhQ0TnxMvBmGrvsHnpBeWJmeXGDC8I/edit
[11:26] <dholbach> jodh, is anything else required on https://bugs.launchpad.net/ubuntu/+source/upstart/+bug/1256949?
[11:29] <jodh> dholbach: that's probably a question for the kernel team - maybe they need to blacklist the default driver for that users wifi card?
[11:30] <dholbach> jodh, it's just that the bug tasks both went to "expired"
[11:30] <dholbach> so I'm not quite sure what's still missing on there
[11:32] <jodh> dholbach: I too was slightly confused - the user found the solution to be a bad driver issue and already has a fix for it. It's not an upstart issue, hence my thought on the kernel team blacklisting.
[11:33] <dholbach> ok
[11:33] <dpm> zyga, done
[11:33] <dpm> https://translations.launchpad.net/ubuntu/trusty/+source/plainbox/+imports?field.filter_status=all&field.filter_extension=pot
[11:34] <zyga> dpm: thanks
[11:42] <zyga> dpm: do the two 'aubuntnu archive auto sync' templates also need to be imported?
[11:45] <dpm> zyga, yes. I approved the oldest ones and the newest will be imported subsequently. And from now on, no more manual approvals will be required, unless you change the name of the template or something like that
[11:46] <zyga> ok, that should be it then, thanks :)
[11:58] <cjwatson> zbenjamin: I would have thought that that should be done by extensions to upstart-app-launch (-> tedg)
[11:59] <zbenjamin> cjwatson: yeah basically i need something like upstart-app-launch <appid> <pkgdir> that does the same as launching a click package just from the given directory
[11:59] <zbenjamin> cjwatson: i can myself register listener for app-start stop signals
[11:59] <cjwatson> Seems like something UAL could probably support without too much trouble, but you should talk with Ted about it
[11:59] <zbenjamin> cjwatson: ok thx
[12:50] <seb128> zyga, hey, could you have a look to https://bugs.launchpad.net/ubuntu/+source/checkbox-ng/+bug/1297118 ? e.u.c suggest that started recently, it looks like it might be your plainbox sync
[12:52] <zyga> seb128: looking
[12:53] <zyga> seb128: I beliveve this will be fixed by checkbox-ng sync (there's a bug about that)
[12:54] <zyga> seb128: checkbox-ng and plainbox are closely tied and after the latter was synced into ubuntu we were doing our best to sync the former as well
[12:54] <zyga> seb128: note, there are also two merge requests to ubuntu branches to correct (one liners) some data sets to get the whole pack to work
[12:54] <zyga> seb128: can we sync it over and see if that goes away?
[12:54] <seb128> zyga, sure, you might want to ask #ubuntu-release to let that in for beta though
[12:55] <seb128> zyga, do you have the bug number for the sync?
[12:55] <zyga> yes looking
[12:55] <zyga> bug 1297665
[12:57]  * zyga looks at the crash dump to see if that might be anything other than misalignment
[13:00] <zyga> seb128: ok, I've asked in #ubuntu-release, I'll go to test locally built packages
[13:01] <seb128> zyga, I've synced checkbox
[13:01] <seb128> let's see what release does
[13:01] <seb128> zyga, thanks
[13:01] <zyga> seb128: thanks
[13:01] <zyga> seb128: can you look at the two merge requests listed in the same bug?
[13:02] <seb128> zyga, if you approve them can you comment saying so? I can sponsor an upload with those then
[13:03] <zyga> seb128: sure
[13:04] <zyga> seb128: done
[13:04] <seb128> zyga, thanks
[13:08] <zyga> seb128: yeah, that particular crash is gone
[13:09] <seb128> great
[13:10] <zyga> seb128: quick question about those ubuntu branches, how does that work, after they get merged, will launchpad automatically build packages and upload them to the archive or is that just source that needs to be uploaded separately?
[13:11] <cjwatson> it's just source
[13:11] <zyga> cjwatson: ok, so to finish that, we need someone to sponsor those upload, correct?
[13:11] <cjwatson> the automation is the other way round - the branches are (supposed to be) automatically updated from uploads
[13:11] <cjwatson> I expect so, I haven't followed this discussion
[13:12] <zyga> cjwatson: ok, the reason we poposed those changes  to ubuntu rather than debian is speed, we hoped that those could be quickly approved and land to trusty before beta (to fix the mismatch we're trying to resolve)
[13:12] <zyga> cjwatson: so after they are merged, how should we proceed? just ask for sponsorship here?
[13:13] <cjwatson> sorry, I was just drive-by commenting, don't have brainspace to think about this
[13:13] <zyga> cjwatson: understood, sorry for keeping you busy
[13:14] <cjwatson> but it does sound like you need a sponsor (not me :-) )
[13:14]  * cjwatson goes back to doing battle with ubiquity
[13:15] <seb128> zyga, don't worry about the lp:ubuntu vcs, we usually don't use those much, I'm going to sponsor the source and that should result in an autoimport in the vcs (if udd doesn't hit import bugs)
[13:18] <zyga> seb128: sponsor the source, -> upload the merged sources as packages (which will trigger that autoimport to bzr that you mentioned)
[13:19] <zyga> seb128: sorry for asking novice questions all the time, delivering *to* ubuntu wasn't something I did heavily before
[13:19] <seb128> zyga, right, I'm just going to take the diff from those merge requests, apply them to the current packages and dput that
[13:19] <zyga> ok
[13:19] <zyga> sounds good
[13:19] <seb128> I might just close the merge requests by hand with a comment when I do that
[13:19] <seb128> to avoid confusion
[13:19] <zyga> ok
[13:33] <zbenjamin> tedg: hey ted did you receive my mail ?
[13:33] <zbenjamin> tedg: it was about the sdk-launcher
[13:34] <tedg> zbenjamin, My mail is being wonky... so not yet.
[13:34] <zbenjamin> tedg: i can pastebin you the contents if you want
[13:34] <tedg> Sure
[13:34] <zbenjamin> tedg: http://pastebin.ubuntu.com/7156716/
[13:51] <tedg> zbenjamin, In general, I think what you're asking for is very orthogonal to what we're trying to achieve with application startup in general.
[13:51] <tedg> zbenjamin, Let me see if I can come up with some way for you guys to get what you need while not breaking standard startup.
[13:52] <tedg> zbenjamin, Is there a reason that you're not making a click package and installing that?
[13:56] <pitti> fginther, ev: does rabbitmq have some kind of builtin failover? or does every consumer just try to connect to a set of servers in an agreed-upon order, so that the primary queue server can go down?
[13:57] <pitti> (that would still not synchronize the queues between the different servers)
[13:58] <pitti> fginther, ev: my other question is: is there some best practice how to detect that a worker node went AWOL (grabbing but never ack'ing a ticket, or just stopped grabbing tickets), so that you get notified to fix it?
[13:58] <pitti> fginther, ev: where "worker node" == thing that consumes requests from a queue
[14:02] <zbenjamin> tedg: even if i would install the click package i still need to have that controller process and i still need to change the exec line
[14:02] <tedg> zbenjamin, You can change the exec line before building the click package.
[14:02] <zbenjamin> tedg: i think patching the desktop file would not be such a good idea for a installed click package
[14:03] <zbenjamin> tedg: that would force me to rebuild the package every time even if no code changed
[14:03] <tedg> zbenjamin, Yes
[14:03] <tedg> zbenjamin, Seems like that'll be lower cost that copying it over USB.
[14:04] <zbenjamin> tedg: its copying over ssh not over usb
[14:04] <tedg> zbenjamin, Oh, then building the package is much lower cost than networking.
[14:05] <zbenjamin> tedg: however we think it would be better to not install the package , because we would need to remove it later then again
[14:05] <zbenjamin> tedg: zoltan had some more comments on this, maybe he should join the discussion
[14:05] <tedg> zbenjamin, I would hope you already plan to remove what ever you install :-)
[14:05] <cjwatson> I don't know if it helps, but note that it would be entirely possible to create another click database just for tests and install packages in there
[14:06] <chrisccoulson> anyone have any idea why https://errors.ubuntu.com/oops/28760226-a973-11e3-b754-2c768aafd08c failed to retrace?
[14:06] <cjwatson> we already have three click databases (core, custom, default), doing one more on the fly isn't hard
[14:06] <chrisccoulson> note, this machine has submitted lots of thunderbird crashes, but all of the traces are useless :(
[14:06] <zbenjamin> tedg: with my approach the is no install ;)
[14:06] <tedg> cjwatson, Hmm, that's interesting. Not sure, it seems to me like people would have a test user, so putting it in that user's account is probably good.
[14:07] <cjwatson> I don't much care, just letting you know it's an option :)
[14:07] <tedg> zbenjamin, Copying is installing in your approach
[14:07] <zbenjamin> tedg: but only a directory in /home/phablet/dev_tmp
[14:07] <cjwatson> (since it isn't necessarily obvious to people)
[14:07] <tedg> cjwatson, Yes, thanks, it is an interesting idea.
[14:07] <zbenjamin> tedg: the current deploy method also just uploads what has changed, so that is very fast if only small parts have changed instead of the whole app
[14:08] <zbenjamin> tedg: i'll be back in a few, lunch is already waiting ;)
[14:08] <tedg> zbenjamin, K, bring bzoltan :-)
[14:21] <Laney> zyga: seb128: did those MRs get uploaded?
[14:22] <directhex> am i missing something, or do LTS enablement kernels not include firmware updates?
[14:25] <zyga> Laney: not sure,
[14:25] <Laney> Looks like not
[14:25] <seb128> Laney, zyga: sorry, I got sidetracked, doing it
[14:25] <Laney> If someone that's not me does it then I can review them
[14:25] <Laney> for slippage innage
[14:26] <infinity> directhex: Firmware updates happen in linux-firmware, generally.
[14:26] <infinity> directhex: Though, some stuff is in the linux-lts-* kernel image packages directly, sometimes.
[14:27] <directhex> infinity, i'm failing to see an iwlwifi-7260-*.ucode anywhere for precise :/
[14:27] <infinity> directhex: That's in proposed.
[14:27] <seb128> Laney, zyga, do you have changelog entries suggestion?
[14:27] <directhex> infinity, oh :)
[14:28] <infinity> directhex: Err, also in updates...
[14:28] <infinity> Binary files /tmp/nKPVQdZgw6/linux-firmware-1.79.9/iwlwifi-3160-7.ucode and /tmp/diu29w0zXj/linux-firmware-1.79.10/iwlwifi-3160-7.ucode differ
[14:28] <infinity> Binary files /tmp/nKPVQdZgw6/linux-firmware-1.79.9/iwlwifi-7260-7.ucode and /tmp/diu29w0zXj/linux-firmware-1.79.10/iwlwifi-7260-7.ucode differ
[14:28] <directhex> infinity, huh. wonder why packages.ubuntu.com doesn't find it
[14:29] <infinity> iwlwifi-7260-8.ucode in proposed.
[14:29] <infinity> So, depends on which one you need (-7 or -8)
[14:31] <directhex> does packages.u.c. file search not consider -updates?
[14:31] <infinity> directhex: I assume you need -7, if you're using it with lts-saucy (ie: 3.11)
[14:31] <seb128> zyga, btw, why did debian update checkbox but not plainbox-provider-checkbox? seems like that should be updated in debian and synced
[14:31] <infinity> directhex: If you're using lts-trusty from the kernel team PPA, you'll need the linux-firmware in proposed.
[14:32] <directhex> infinity, i'm working blind on new hardware, i don't know yet what level of kernel backportery it needs - just that the wifi is too new for the default kernel
[14:33] <directhex> canonical certified, apparently. huh. wonder when i last updated my base installer image
[14:33] <infinity> http://packages.ubuntu.com/search?searchon=contents&keywords=iwlwifi-7260-7.ucode&mode=exactfilename&suite=precise-updates&arch=any
[14:34] <infinity> directhex: Well, if you're using lts-saucy, you need linux-firmware from updates, if you use lts-trusty (which isn't in the archive yet), you'll need linux-firmware from proposed.  Now you know. :)
[14:34] <directhex> \o/
[14:35] <directhex> looks like currently my default install kernel is... linux-lts-quantal. guess that answers the "when did i last update it" question.
[14:38] <infinity> directhex: There's also the option of 3.2.0 or 3.5.0 with linux-backports-modules.
[14:38] <infinity> Oh, I guess just 3.2.0.  There's no LBM for lts-quantal.
[14:39] <directhex> infinity, i'm not at all opposed to a new kernel. using lts-quantal is because i haven't updated my installer image since raring shipped
[14:39]  * infinity nods.
[14:39] <directhex> anyway, thanks for the user support
[14:39] <infinity> Pay it forward by documenting something somewhere for someone. :P
[14:40] <zyga> seb128: we are working on updates to debian but we though that waiting for sponsorship was risky at this time
[14:40] <zyga> seb128: updates to debian will include more features, this is really a bugfix for trusty
[14:41] <seb128> zyga, how come debian doesn't have the same bug/need for fix if they have the same checkbox version
[14:41] <seb128> zyga, ok anyway, but having a changelog entry would be handy, I'm unsure how to describe the change
[14:41] <zyga> seb128: so it does but nobody needs that in debian yet :)
[14:41] <zyga> seb128: and the update will be ready in a few days
[14:42] <zyga> seb128: changelog 'correct namespace to match expected namespace in checkbox-ng'
[14:42] <seb128> zyga, thanks
[14:42] <zyga> seb128: that is fixed in trunk, we'll release updates to debian soon, this is safe to drop on next sync
[14:47] <ev> pitti: http://www.rabbitmq.com/ha.html - though I'm sure #webops will have some thoughts.
[14:47] <ev> possibly wgrant as well
[14:48] <ev> pitti: back in the day, lifeless' suggestion was to write to both rabbit and cassandra. That way you could replay from cassandra when rabbit came back into existence.
[14:48] <ev> I'd love to see that sort of thing generalised and reused in the many places we're using a queue model
[14:48] <wgrant> In LP we store all jobs in postgres, and the rabbitmq jobs reference those
[14:49] <wgrant> It's a bit bad, but less bad than rabbit HA was at the moment.
[14:49] <wgrant> s/moment/time/
[14:50] <ev> pitti: to your latter point, we probably want metrics of the workers via (tx)statsd. You could have another process watching the metrics for all the workers and if any of them failed to update the processed count in N minutes, you'd know it was wedged.
[14:50] <ev> or something less rube goldberg-y
[14:50] <ev> because when I think HA, I definitely think postgres :-P
[14:52] <maco> ev: weird the things hanging out with historical reenactors instead of programmers does to your brain. "because when I think historically accurate, I definitely think postgres"
[14:53] <cjwatson> kirkland: so, bug 1172014
[14:54] <cjwatson> kirkland: this change caused a regression in ubiquity; not really your fault, ubiquity needed to resolve the UUID= in crypttab because it explicitly zeroes the device
[14:54] <cjwatson> kirkland: but more importantly, I can't actually make the swap setup work properly even after fixing that ubiquity bug
[14:56] <cjwatson> kirkland: I think https://bugs.launchpad.net/ubuntu/+source/ecryptfs-utils/+bug/1172014/comments/9 has the right of it; the swap space is set up with a random key, there's no container, so how can it have a stable UUID?
[14:57] <pitti> ev: thanks for the HA link, will digest in the next days
[14:57] <ev> maco: :)
[14:57] <bzoltan> zbenjamin: here
[14:57] <zbenjamin> bzoltan: meh [15:43:29] <-- tedg (~ted@ubuntu/member/ted) hat das Netzwerk verlassen (Quit: Ex-Chat)
[14:58] <cjwatson> kirkland: indeed when I reboot after installation, re-point crypttab to /dev/sda5 so that I can cryptdisks_start, copy the new UUID into /etc/crypttab, and reboot, it still doesn't work
[14:58] <pitti> ev: ack, so a monitoring cron job/process (and who watches the watchers? :-) )
[14:58] <zbenjamin> cjwatson: do you have a idea when tedg will be back?
[14:58] <cjwatson> zbenjamin: no, sory
[14:58] <cjwatson> *sorry
[14:59] <ev> pitti: you could equally make the processes watch themselves. Spin off a thread that does it.
[14:59] <ev> but python, threading, yay
[15:23] <zbenjamin> tedg: bzoltan: ping
[15:24] <tedg> zbenjamin, bzoltan, howdy folks
[15:25]  * zbenjamin just waits for zoltan to arrive
[15:32] <Chipaca> are files in /usr/share/upstart/sessions considered conffiles?
[15:32] <cjwatson> No
[15:33] <cjwatson> I mean, whether something is a conffile is governed by whether it's in the package's "conffiles" control file (/var/lib/dpkg/info/*.conffiles)
[15:33] <cjwatson> but conffiles are generally configuration files, and configuration files must reside in /etc
[15:33] <cjwatson> https://www.debian.org/doc/debian-policy/ch-files.html#s-config-files
[15:34] <Chipaca> right
[15:34] <Chipaca> cjwatson: i'm wondering how to point to a multiarch binary from an upstart session file
[15:34] <Chipaca> not finding much info
[15:34] <cjwatson> files in /usr/share shouldn't be architecture-specific
[15:34] <cjwatson> put a wrapper somewhere else?
[15:35] <cjwatson> I can't really fathom how being a conffile would help :)
[15:35] <zbenjamin> tedg: ok seems bzoltan is busy right now, lets move the discussion to tomorrow then, or maybe a ML don't know which approach is better
[15:35] <Chipaca> cjwatson: there seems to be support for having multiarch conffiles in multiple packages not break dpkg
[15:36] <cjwatson> you are going down a rabbit hole
[15:36] <Chipaca> cjwatson: yes
[15:36] <cjwatson> I suggest climbing the other way
[15:36] <cjwatson> conffiles will at best fail to hinder you
[15:36] <Chipaca> cjwatson: I'm not sure what value I'm giving users by making my package multiarch
[15:36] <cjwatson> (and even that is unlikely)
[15:36] <Chipaca> so I might just make it not be multiarch
[15:36] <cjwatson> could you make all this concrete, please?  what package is this?
[15:36] <Chipaca> cjwatson: ubuntu-push-client
[15:37] <tedg> zbenjamin, K, I'll reply to your mail and CC him.
[15:37] <cjwatson> Chipaca: does it have any reverse-dependencies?
[15:37] <zbenjamin> tedg: yeah thats maybe easier thx :)
[15:37] <cjwatson> it's not in the archive at the moment, I see
[15:37] <Chipaca> cjwatson: no
[15:37] <Chipaca> cjwatson: it's in NEW, afaik
[15:37] <Chipaca> or maybe in proposed?
[15:37] <cjwatson> Chipaca: I can't really see why a leaf client package would need to be Multi-Arch: same
[15:37]  * Chipaca looks
[15:38] <cjwatson> Chipaca: it perhaps ought to be Multi-Arch: foreign
[15:38] <cjwatson> huh, it is in trusty, I'm obviously just not quite up to date
[15:38] <Chipaca> it is?
[15:38] <pitti> ev: we could also think about a "ping" fanout queue (with timeout of e. g. 30 s) and find broken workers that way; no response -> really broken, and on ack the worker coudl check if it has a running job for more than N hours
[15:38]  * Chipaca refreshes
[15:39] <cjwatson> hah, that package is nonsensically laid out
[15:39] <cjwatson> it's using Multi-Arch: same style paths while being Multi-Arch: foreign
[15:39] <Chipaca> cjwatson: :) I am but an egg
[15:39] <cjwatson> move the executable to /usr/lib/ubuntu-push-client/ubuntu-push-client
[15:39] <cjwatson> this is probably just a libexecdir accident
[15:39] <ev> pitti: so the workers tell the watchdog about their state? And if the watchdog dies we just point a new one at the queue the workers are submitting state to?
[15:39] <cjwatson> perhaps dh_auto_configure -- --libexecdir=/usr/lib
[15:40] <Chipaca> cjwatson: i'm putting it there by hand
[15:40] <cjwatson> sorry,  dh_auto_configure -- --libexecdir=\$${prefix}/lib  I mean
[15:40] <cjwatson> ok, don't :)
[15:40] <Chipaca> cjwatson: ok :)
[15:40] <cjwatson> /usr/lib/<multiarch triplet> paths only make sense in Multi-Arch: same packages
[15:40] <cjwatson> which would generally be libraries
[15:41] <cjwatson> I see that /usr/share/upstart/sessions/ubuntu-push-client.conf already points to /usr/lib/ubuntu-push-client/ubuntu-push-client
[15:41] <pitti> ev: dying watchdog is of course a recursive problem; but cron failing ought to be a really rare event
[15:41] <cjwatson> Chipaca: so, the whole conffiles thing is a red herring anyway because /usr/share/upstart/sessions/ubuntu-push-client.conf is in the very same architecture-dependent package so it could just be built to embed whichever paths you need; but that would be a different kind of policy violation and as I say doesn't actually make sense, so better to simplify
[15:42] <pitti> ev: I mean, someome will notice if packages/MPs don't get through, it woudl just be nice to have a place to look for the worker status; so I think with statd or a ping queue or something similar whose ping fanout requests come from cron we should be good enough
[15:42] <Chipaca> cjohnston: and it's already multiarch:foreign, so all i ineed to du is remove the triplet
[15:42] <cjwatson> exactly
[15:42] <Chipaca> cjwatson: ^
[15:42] <pitti> ev: and we can figure out the set of "expected" workers from the existing logs (they contain host names)
[15:42] <Chipaca> cjohnston: sorry :)
[15:42] <ev> pitti: the watchdog dying due to busted code in it? Yeah, but the beauty of that is that all we lose is the ability to kill wedged workers
[15:42] <ev> we can have a nagios alert on the watchdog process
[15:42] <ev> which in turn sends to pagerduty
[15:43] <pitti> ev: so as soon as a worker submits one result into swift, it'll be in the set of "expected to be there" workers
[15:43] <cjwatson> golang-ubuntu-push-dev arguably ought to be M-A: foreign too, but that's not very important
[15:43] <pitti> ev: right; at that point I'll gladly hand that over to the CI experts for this :)
[15:43] <ev> and we get a text message saying, "hey fool, the watchdog is down. We're not going to kill any hung workers until you fix it. But take your time."
[15:43] <ev> heh
[15:43] <ev> the experts in being woken up in the middle of the night, you mean
[15:43] <pitti> ev: I'll think about a proper design on Friday when I'll be typing impaired anyway, just collecting various Lego blocks now to build it with :)
[15:44] <cjwatson> actually, since golang-ubuntu-push-dev has no dependencies it really doesn't matter
[15:44] <pitti> ev: no, I mean telling me how to design teh watching of the watchers, etc. :)
[15:44] <ev> I'll start putting that on job profiles. Must have skills in sleep deprivation.
[15:44] <ev> oh right
[15:44] <ev> vila: ^ you're the point of contact on this one :)
[15:44] <ev> I think we've got the outline of a sensible model there, but we'll need to make sure it's interfaced with nagios
[15:44] <pitti> ev: watchdog dying should be an once-in-a-year condition (unless it's the whole server itself which goes down), and then it shouldn't be a "ring people out of bed" conditiona s long as the actual tests still come in
[15:45] <ev> yeah
[15:45] <pitti> ev: i. e. we expect to have enough redundatn workers that we cna easily get along with 20% of them failing
[15:45] <ev> we can keep the watchdog code simple
[15:45]  * ev nods
[15:45]  * vila reads backlog
[15:45] <Chipaca> cjwatson: thanks a ton
[15:45] <cjwatson> np
[15:46] <ev> I'm super encouraged by how much you get this need for resilience to failure and graceful degradation
[15:46] <pitti> ev: yes, that was the idea; send a "ping" to a fanout queue, wait 30 s for acks, consider the missing ones as dead; sounds like a 15 line thing
[15:46]  * ev nods
[15:46] <pitti> ev: well, so far jibel and I have taken the penalty of not having such a system, so I'm notivated :)
[15:46] <ev> :)
[15:48] <pitti> ev: as for nagios: can we tell it something like "the latest report (URL to text file or so) from the watchdog is older than 30 minutes, it must be dead"?
[15:48] <ev> pitti: it's probably best to have the watchdog touch a file for that, but yes
[15:48] <pitti> ev: right, I meant something like that
[15:49] <ev> yeah, entirely doable
[15:51] <vila> pitti: so, as of today (things will change) the way we do that in the ci engine is to have the test runner monitor the testbed (where the test actually run) and we have a 'engine health' page monitoring the workers (the test runner is the worker reading the rabbit queue)
[15:52] <vila> pitti: so feedback from adt-run goes to the test runner which can decide the testbed is dead if nothing comes in for too long
[15:52] <pitti> vila: right, adt-run already has timeouts for everythign it does to the testbed
[15:53] <vila> pitti: in 2.3.7 already ?
[15:53] <pitti> vila: forever really
[15:55] <vila> pitti: hmm, never ran into them then
[15:55] <fginther> pitti, (sorry your ping was off my page).  rabbitmq can be built for HA, but I haven't looked into that yet. For the second question, there is a way for the server to know that a worker has died (the server recognizes that the other end of the connection is no longer active), but we're not using this now. I'd have to look it up again
[15:55] <pitti> fginther: thanks
[16:01] <vila> pitti: ack, I see them now, and the cmdline options too ;)
[16:11] <vila> exit
[16:12] <vila> damn focus
[16:22] <hallyn> if i need to ship a helper script for a udev hook to call, is there a particular place it should go?
[16:29] <stgraber> hallyn: /lib/udev I believe
[16:33] <hallyn> just right in there, no subdir?  cool, thanks.
[16:34] <mpt> “div.table-of-contents {…max-width: 50%;…}” — oh dear
[16:55] <xyzzymaze> Greetings ... trying to install Trusty BuildDate Mar 25 .. it boots, I can do disc-check, but selecting install ends up black screen. I have Nvidia Geforce 210 card installed. Live sys looks 'up' as ctrl-alt-F2 gets to a session prompt .. thank you!
[17:30] <doko> zul, python-oslotest wants a python3-hacking b-d ...
[17:31] <zul> doko:  ok ill fix it up
[17:34] <jamespage> jdstrand, slangasek: can we get a definitive position on the golang discussion in bug 1267393 for the context of 14.04 please?
[17:34] <jdstrand> I plan on responding soon-- I am looking into a few things
[17:34] <jamespage> jdstrand, thanks
[17:34] <jdstrand> it is very high on my todo
[17:34] <jamespage> jdstrand, appreciated
[17:46] <infinity> jdstrand: To be fair, even fixing dynamic linking in golang (which we're not going to do, and even if we help with, won't do in time) doesn't fix the biggest issue.
[17:47] <infinity> jdstrand: golang upstream is a typical Google project that gives exactly zero shits about stable release support, so we'd be on the hook for digging out and backporting fixes ourselves.  Or give it a firefox/chromium-style upstream version exception, which is madness for a compiler.
[17:50] <mdeslaur> hehe
[17:52] <infinity> I'm going to stay out of the compiler argument on that MIR, and jump on the whole "juju-core doesn't ship all its binaries in the archive" thing which, amazingly, no one's even mentioned.
[17:57] <jamespage> infinity, I think I've pointed at it enough
[18:03] <infinity> jamespage: Honestly, I think it's a major blocker, and I don't grasp why people seem to handwave over it with a "yeah, we'll fix it some day".
[18:04] <infinity> jamespage: Cause, either it's not a problem at all, and they can package the binaries, or it's an excuse to hide much bigger problems that need fixing.
[18:04] <infinity> jamespage: It's pretty black and white in my mind.
[18:04] <jamespage> infinity, I commented on how that binary is built; but I've left it to the upstream dev team to explain why
[18:20] <alow> infinity: looking at this patch stuff for libv8 again. You had mentioned whitespace issues, which files?
[18:23] <infinity> alow: Oh, err.  I'd given up caring and was going to just generate my patch with diff -w
[18:23] <infinity> alow: But there were a few bits.  Lemme find the tree.
[18:26] <alow> infinity: I suspect there were one or two
[18:26] <infinity> Argh.  Total context switch fail...
[18:26] <infinity> alow: Which branch is the branch I care about again?
[18:26] <alow> infinity: https://github.com/andrewlow/v8ppc/tree/libv8-3.14
[18:27] <infinity> src/jsregexp.cc
[18:28] <alow> yup - I can 'fix' that
[18:28] <infinity> src/objects.cc
[18:28] <infinity> src/serialize.cc
[18:28] <alow> infinity: what diff command are you using to compare the two git repos again?
[18:28] <infinity> Those three all have a few instances of indentation going wonky.
[18:28] <alow> infinity: let me fix those 3.. can't be hard
[18:28] <infinity> alow: That was 'git diff d8d994ca1752c530d2cbf8d9b43b1881b642ddf9 remotes/origin/libv8-3.14' (ie: the diff from my last update and your current HEAD)
[18:30] <infinity> alow: Of course, if those were whitespace cleanups that you missed in the last update, maybe it's actually fixing something.  Guess I should compare back to the original...
[18:30] <infinity> alow: Oh, and that might be the case.
[18:31] <infinity> alow: Yeah, ignore me.
[18:31] <infinity> alow: That was you cleaning up better, and my diff method finding the cleanups.
[18:31] <alow> infinity: I'm doing a diff from the original git://anonscm.debian.org/collab-maint/libv8.git and mine https://github.com/andrewlow/v8ppc/tree/libv8-3.14
[18:31] <infinity> alow: (ie: if I diff from 6b10fef46edfb4dc2a7aed389d75574c40a14243 to your HEAD, those changes aren't there)
[18:32] <infinity> alow: Diff from 6b10fef46edfb4dc2a7aed389d75574c40a14243 to you is what matters, as 6b10fef46edfb4dc2a7aed389d75574c40a14243 is what the orig.tar.gz is built against.
[18:32] <alow> infinity: shmm.. when I did this work a while back, I thought I had found more "whitespace" errors in mine.. that I was trying to correct
[18:33] <infinity> alow: Doing the full diff (instead of the incremental I shouldn't have been doing), the only wonky whitespace I see in your stuff is trailing spaces in a few places.
[18:33] <infinity> Like aix_gyp.patch, which shouldn't be in the tree at all, probably.
[18:33] <alow> true
[18:34] <infinity> alow: Do you know if bumping the v8 version like your current HEAD does has any actual impact on anything (symbol versions, etc), or if it's just cosmetic?
[18:36] <alow> infinity: it should be cosmetic
[18:36] <alow> infinity: it should be just the patch level we're bumping here
[18:36] <infinity> -#define IS_CANDIDATE_VERSION 1
[18:36] <infinity> +#define IS_CANDIDATE_VERSION 0
[18:36] <infinity> That may have an impact, though.
[18:36] <infinity> Ahh, but you backed that out.
[18:37] <alow> infinity: it was a series of commits I was applying
[18:37] <alow> infinity: this allowed me to keep the original commits from the master v8 repo
[18:37] <infinity> Or... IS_CANDIDATE_VERSION has always been 0 in our packages.  Whee.
[18:38] <infinity> So, neevrmind.
[18:38] <alow> infinity: exactly :)
[18:38] <infinity> Maybe I'm reading that boolean backwards, and "1" is used to define "RCs" or something.
[18:38] <infinity> Or, we've always shipped something that thinks it's a dev/trunk/beta thing.  Whatever.
[18:38] <infinity> If it works, it works.
[18:39] <alow> infinity: 0 should be the right value for libv8
[18:40] <infinity> alow: Anyhow, your current HEAD looks fine to me, now that I rediffed to my base instead of to our last update.  So, ignore my previous whining.
[18:40] <infinity> alow: I don't suppose you know much about Corentin's mongo/ppc port.  That's much scarier than your v8 stuff. :P
[18:41] <alow> infinity: uh... I think i've talked with him, but mostly to help him get libv8 building
[18:42] <infinity> alow: Do you know how much (if any) of it has been submitted/accepted upstream for future versions?
[18:42] <alow> infinity: of 'it' being what?
[18:42] <infinity> alow: He's pretty much wrapped every call to anything anywhere in some endian check/flip madness, which makes for a pretty hard to audit diff.
[18:42] <infinity> alow: "it" being his mongo work.
[18:42] <alow> infinity: oh.. the mongo stuff. no idea sorry
[18:43] <infinity> Also the occasional signed/unsigned char fix in here.  It's pretty clear that no one's heavily tested Mongo on ARM either, if they think any of this works today.
[18:44] <alow> infinity: I'm assuming you're looking at the mongo code. Again, it's pretty foreign to me, haven't looked at it in any detail
[18:44] <infinity> alow: It's foreign to me too.  And I wish it would stay that way. :)
[18:45] <infinity> alow: Anyhow, I don't think I have any more to bug you about WRT V8.  I might have questions about node if it doesn't Just Work later today, but the "port" seems pretty simple, given an externally-linked-and-functional libv8, so I doubt it'll give me troubles.
[18:46] <alow> infinity: sure.. catch me here or drop an email if node has problems
[18:46] <alow> infinity: oh.. you might need one or two endian changes for BE in the Node code
[18:47] <infinity> alow: Above and beyond the v0.10.25-release-ppc branch?
[18:47] <alow> infinity: You can sniff around here https://github.com/andrewlow/node for some of them.
[18:48] <alow> we have a v0.10.26-release-ppc branch - it includes the endian changes (as does 25)
[18:48] <alow> compare against v0.10.26-release
[18:48] <alow> to see the deltas
[18:48] <infinity> alow: Well, we ship .25, so that's the one I was looking in.
[18:48] <alow> we also have unstable 0.11.x
[18:50] <infinity> alow: So, my hope here is that " git diff remotes/origin/v0.10.25-release remotes/origin/v0.10.25-release-ppc | filterdiff -x '*deps/v8ppc/*'" gives me basically what I need.
[18:50] <seb128> cjwatson, stgraber: hey, could one of you have a look to https://bugs.launchpad.net/ubuntu/+source/gnome-session/+bug/1244736 ? there is a simple suggested change, not sure if it makes sense (basically bailing out of starting the agent if there is already another one running)
[18:51] <alow> infinity: I bow to your git diff mastery - yes, it should work
[18:55] <infinity> alow: Alright, cool.  Will whine later if we're wrong. ;)
[19:58] <kirkland> cjwatson: yes, this is an unfortunate one
[19:58] <kirkland> cjwatson: your analysis is correct, we use a random key (and throw that key away) at each boot
[19:59] <kirkland> cjwatson: otherwise, we have a key management problem
[21:17] <doko> zul, test failures, missing b-d on six? https://launchpad.net/ubuntu/+source/python-oslotest/0.1-1ubuntu1/+build/5851799