[04:37] <Caesar> I've forgotten how to mark a bug as applicable to multiple releases of Ubuntu, can someone help jog my memory?
[04:45] <RAOF> Caesar: Also affects series
[04:45] <RAOF> Hm. IIRC.
[04:52] <Caesar> RAOF: Is the UI for that access restricted?
[04:53] <RAOF> Caesar: It's “Nominate for series”, and the nomination is not restricted (AFAIK), but acceptance of the nomination is restricted.
[04:54] <Caesar> Aha. https://answers.launchpad.net/launchpad/+question/152525
[04:55] <Caesar> I'm not a bug supervisor
[06:32] <dholbach> good morning
[12:10] <pitti> Good morning
[12:19] <ivebeenlinuxed> Hi, does anyone know when the netboot image for Ubuntu 13.10 is going to be built?
[12:24] <cjwatson> ivebeenlinuxed: The final one will only be days before final release, but you can always use the development one
[12:24] <cjwatson> ivebeenlinuxed: Oh, I see that http://cdimage.ubuntu.com/netboot/ doesn't link to it yet - is that what confused you into thinking it was unavailable?
[12:26] <ivebeenlinuxed> Yeah - even going to a logical direct link (netbook/saucy) doesn't give anything either
[12:27] <cjwatson> ivebeenlinuxed: I've updated that page now
[12:28] <cjwatson> ivebeenlinuxed: You will have to make sure to update any images you download frequently though, as they'll get out of sync with newer kernels uploaded to saucy
[12:31] <ivebeenlinuxed> Awesome! I'm just interested to see how Mir/XMir is coming along (without burning the CD, as I have a TFTP server already set up for development). In another note, I am interested in getting into Ubuntu development, but need to find a good way of starting...
[13:12] <infinity> @pilot in
[13:12] <infinity> FYI: I'm at a sprint right now, so my patch piloting will be spotty, but if anyone needs something specifically from me, nick highlight me.
[13:31] <jbicha> rsalveti: what should be done about the 'elementary' package since enna and intone ftbfs against the new version?
[13:33] <rsalveti> jbicha: hm, let me take a look
[13:45] <rsalveti> jbicha: yeah, would need some porting, and upstream for both seems to be dead, and not following the latest efl changes
[13:45] <rsalveti> will give it a try later today
[13:49] <jbicha> rsalveti: ok, otherwise we can remove it from saucy-proposed since it's only in Debian experimental
[13:49] <rsalveti> jbicha: yeah
[16:50] <zul> what does "xxx has no binaries on any arch " mean?
[16:52] <Laney> probably that it failed to build
[17:14] <slangasek> mlankhorst: hi, can you have a look at bug #982889 and tell me what needs to happen?  According to Franz, this bug still affects the quantal X stack in precise.  I guess we need a quantal SRU followed by an enablement stack update?  Not sure if the 12.04.0 X also needs an update
[17:15] <cjwatson> barry: did you notice the tox build failure?
[17:25] <barry> cjwatson: i didn't.  looking now
[18:13] <barry> cjwatson: looks like we'll need to syncpackage python-pip 1.4.1 to fix the tox ftbfs
[18:30] <sarnold> seb128: hey, I think the retraces are busted agaiun
[18:32] <seb128> sarnold, we need to get you access to those ;-)
[18:33] <seb128> sarnold, yeah, the amd64 one is down for a week :/
[18:33] <seb128> they are down more often than running nowadays
[18:34] <seb128> slangasek, pitti, I wonder if we should just skip over bugs rather than stop the retracers until somebody goes to look at the log/remove the lock
[18:35] <slangasek> seb128: that sounds like it might help... but then, I'm still not getting emails about it when there are locks
[18:35] <slangasek> so our monitoring should apparently be fixed
[18:35] <slangasek> seb128: where exactly to the locks show up?  Maybe we should set up another cronjob to notify when there's a deadlock
[18:36] <seb128> slangasek, right, I've no idea about that, the crontab has MAILTO properly filed from what I can tell
[18:37] <seb128> slangasek, ~ubuntu-archive/lock.<arch> ... but how do you tell a valid lock apart from a leftover?
[18:37] <slangasek> seb128: check for a running process?  (Does the lockfile contain a pid?)
[18:38] <seb128> slangasek, no, it's an empty file
[18:38] <slangasek> hmm, how indeed then
[18:38] <seb128> well, that's open source, you can submit a patch to apport to make it write the pid in the lock :p
[18:38] <sarnold> seb128: down for a week, ouch.. they do a lot of awesome magic in the background when they just work..
[18:38] <pitti> seb128, slangasek: the main idea about stopping the retracer was to avoid untagging five hundred crashes and failing on them
[18:39] <seb128> sarnold, yeah, they do, and I expect there are not so many problems but they keeping hitting the same ones
[18:39] <slangasek> seb128: or maybe it holds the lock open while running?  either way would be reasonable
[18:39] <pitti> seb128, slangasek: but we can certainly grep out the failures from the logs and re-tag them
[18:39] <seb128> pitti, do we need to untag on failures?
[18:39] <seb128> pitti, or said differently "why does it untag if the retracing doesn't success"?
[18:40] <seb128> it should be the last thing in the process
[18:40] <seb128> before going to next one in the queue
[18:40] <pitti> (in discussion, just reading with half an eye)
[18:40] <pitti> seb128: if you don't, you need additional smarts to not re-process them over and over again
[18:40] <pitti> infinite loop
[18:40] <pitti> in fact, if the cron mail was working reliably, this wouldn't be such a problem
[18:41] <seb128> pitti, seems like we could change the tag rather than remove it
[18:41] <pitti> seb128: yes, we could
[18:41] <seb128> pitti, http://paste.ubuntu.com/6084644/ is the current log ... it's not really verbose on the issue :/
[18:41] <pitti> but still, the "stop at exception" was still from times when LP changed every other day, and the apport retracing itself was being developed
[18:41] <seb128> pitti, the recent failures are mostly like that
[18:41] <pitti> presumably these days the errors that we'll see are mostly not systematic any more, but glitches in LP/network
[18:42] <seb128> right
[18:42] <seb128> recently I just remove the lock
[18:42] <seb128> and it's going through again for a few days
[18:42] <seb128> it's not like it was hitting bugs on specific bugs
[18:42] <pitti> yeah, then we could just change it to not stop at an error, but just log it instead
[18:42] <seb128> +1
[18:42] <pitti> but we need to ensure it doesn't loop on a particular bug
[18:42] <seb128> I would still like to figure why emailing is not working
[18:43] <seb128> pitti, slangasek: did you try to ask IS if emails where going through from that box?
[18:43] <pitti> seb128: no, not yet
[18:43] <slangasek> no, was going to send test mails first
[18:43] <pitti> seb128: sometimes I do get mail, but it seems most often I don't
[18:43] <seb128> pitti, I would rather change the tag, e.g put it retrace-need-review or something
[18:43] <pitti> seb128: there's an apport-retrace-failed tag already
[18:44] <seb128> slangasek, ok, I'm going to let you do that then
[18:44] <pitti> but we use that mostly for "gdb didn't figure out a good stack trace'
[18:44] <seb128> pitti, right
[18:44] <seb128> pitti, we might want to tag bugs differently because those might be apport issues
[18:44] <seb128> bugs in the retracing
[18:44] <pitti> seb128: right
[18:44] <seb128> e.g that list is worth reviewing
[18:44] <pitti> like, in the LP/launchpadlib/network chain
[18:44] <seb128> pitti, should I open a wishlist about it?
[18:45] <pitti> sure
[18:46] <slangasek> osageorange log shows mail being relayed, but it hasn't been delivered to me
[18:46] <slangasek> oh, there it is now
[18:46] <slangasek> so cron mail delivery seems to be ok
[18:47] <pitti> From ubuntu-archive@osageorange.canonical.com  Mon Sep  9 20:45:03 2013
[18:47] <pitti>  Subject: Cron <ubuntu-archive@osageorange> echo "testing cron mail" >&2
[18:47] <pitti> this one?
[18:47] <slangasek> yep
[18:47] <pitti> slangasek: yes, as I said I do get the cron fail mail sometimes, but not reliably
[18:47] <slangasek> well, but maybe that's because apport isn't reliably generating any output on failure?
[18:48] <pitti> well, exceptions are being shown in the log, so the exit status ought to be non-zero
[18:49] <slangasek> does that generate a mail from cron?  I thought the trigger for mail was output on std{err,out}
[18:49] <pitti> oh, I see how the i386 one would do that
[18:49] <pitti> as after crash-digger it runs the duplicate db without saving the exit stauts
[18:49] <pitti> but the amd64 retracer only calls crash-digger
[18:51] <seb128> pitti, https://bugs.launchpad.net/ubuntu/+source/apport/+bug/1222978
[18:51] <pitti> From ubuntu-archive@osageorange.canonical.com  Wed Sep  4 20:48:05 2013
[18:51] <pitti>  Subject: Cron <ubuntu-archive@osageorange> schroot -q -c quantal-amd64 -- sh -
[18:51] <pitti> that's the last one which I got
[18:52] <pitti> seb128: merci
[18:52] <seb128> pitti, de rien ;-)
[18:52] <seb128> pitti, same for me, most recent was sep 4 20:48
[18:54] <seb128> pitti, the content of that email doesn't even really makes sense to me
[18:54] <seb128> oh, it's from the dup checking job
[18:55] <barry> cjwatson: s/pip/virtualenv/ but i still think we need to sync pip too.  sign.  ffe's coming
[18:57] <smoser> infinity, you're sru teaming today, could you please look at https://bugs.launchpad.net/ubuntu/+source/ubuntu-cloudimage-keyring/+bug/1218963 ?
[18:57] <pitti> seb128: ah, the sep 4 one was dupcheck?
[18:57] <seb128> pitti, yes
[18:58] <seb128> pitti, in fact it seems I receive only dupchecks emails
[18:58] <pitti> hm, that also redirects output and stderr to a log file
[18:58] <pitti> it's not structurally different to the amd64 one
[18:58] <pitti> so I wonder why one is sending mails, but not the other
[18:58] <seb128> pitti, that box goes back to 30/04/2013 here and I only got dupcheck emails
[18:59] <seb128> so we never receive retracing emails anymore
[18:59] <pitti> but it's certainly more likely that the cron jobs are wrongly defined than mails only being sent sometimes
[19:00] <pitti> it seems that cron doesn't actually care about the exit status?
[19:00] <slangasek> pitti: right, I believe that's correct
[19:00] <pitti> so that's probably it
[19:00] <slangasek> it only mails you when there's output
[19:00] <slangasek> so since all the output is redirected... :)
[19:00] <pitti> we probably need something like crash-digger || tail -n 10 logfile ?
[19:01] <slangasek> yeah, that should do the job
[19:01] <pitti> curious why I sometimes do get mail then
[19:01] <seb128> how did it use to work?
[19:01] <seb128> pitti, you get emails from the dupchecker
[19:01] <pitti> right, but that's also doing >> log/dupcheck.log 2>&1
[19:01] <slangasek> right, I haven't gotten any mails about these locks at all since being added to the crontab
[19:02] <seb128> pitti, hum, indeed
[19:02] <seb128> weird
[19:02] <slangasek> pitti: https://code.launchpad.net/~vorlon/apport/crashdigger-proper-lockfile/+merge/184660
[19:03] <pitti> changed the crontabs
[19:03] <pitti> with the || tail approach
[19:03] <pitti> so it now ought to send cron mail
[19:04] <pitti> slangasek: I think os.write is expecting bytes, not str
[19:04] <slangasek> pitti: the whole program is currently python2... would you like me to fix that? :)
[19:05] <pitti> slangasek: ah, it's python3 in the saucy branch
[19:05] <slangasek> ah
[19:05] <pitti> but we use a trunk checkout
[19:05] <slangasek> indeed
[19:05] <pitti> slangasek: still from the days when we used older chroots for retracing; at this point we can probably switch trunk to py3, thanks for reminding
[19:06] <pitti> slangasek: see setup.py, it fixes the shebangs during install, depending on which py version you called setup.py installwith
[19:06] <pitti> "install with"
[19:07] <mlankhorst> slangasek: honestly I need a way to reproduce it :s
[19:07] <mlankhorst> slangasek: and no the bugfix won't help
[19:07] <slangasek> pitti: aha, ok, so the code is actually bilingual on trunk - will fix
[19:08] <pitti> slangasek: yeah, for releasing I run the test suite for both py2 and py3
[19:08] <pitti> slangasek: probably easiest to just append an .encode()
[19:08] <pitti> brb
[19:10] <slangasek> right, encode, sigh
[19:10] <seb128> slangasek, pitti: \o/ emails work (ignore the email, I just stopped it manually to test)
[19:21] <pitti> seb128: yay
[19:24] <pitti> slangasek: cheers, merged (with NEWS) and rolled out
[19:27] <SuperLag> Just curious, why were the alternative install images removed as an option?
[19:28] <infinity> smoser: Maaaaybe.
[19:28] <slangasek> SuperLag: because two images take more effort to maintain than 1, and the desktop images now supported all our major use cases
[19:29] <infinity> And any usecases the desktop images don't cover is still covered by the d-i netboot images.
[19:29] <pkern> Are they supported?
[19:29] <infinity> They're not not supported.
[19:30] <pkern> infinity: Because you want to avoid an unconditional »yes«? :P
[19:30] <infinity> Or, to put it differently, we have some very large commercial customers who depend on the d-i images working correctly, so if someone tells you they're not "supported", that's a bit of a lie. :P
[19:31] <pkern> I have a specific commercial customer in mind, which is why I ask.
[19:31] <slangasek> pkern: subtle
[19:31] <pkern> slangasek: He brought it up.
[19:31] <slangasek> :)
[19:31] <slangasek> it's ok, your secret is safe with me
[19:32] <pkern> Pah
[19:32] <infinity> Heh.
[19:32] <pkern> I wonder if that means that d-i QA remains in place or if commercial customers could still file issues if they're broken. Which seem to be two different things. ;)
[19:33] <infinity> We do some d-i QA for sure, plus rely on it heavily internally, plus are happy to address bugs filed.
[19:33] <infinity> So, it's fairly supported, it's just not as heavily focused on as the live images by certain people.
[19:34] <infinity> It also breaks less spectacularly and less often, mind you. :P
[19:34] <pkern> Apparently beating d-i into shape for a realease can also be some significant effort. :)
[19:34] <pkern> *release
[19:35] <infinity> smoser: Is ubuntu-cloudimage-keyring meant to live in universe, or will that be changing?
[19:36] <infinity> pkern: We put remarkably little effort into it, actually, except when introducing new targets (which I'm doing this afternoon...)
[19:36] <slangasek> pkern: generally not when one only has 4-5 archs to support :)
[19:36] <seb128> qengho, seems like you moved files between binaries and forgot a Replaces: https://bugs.launchpad.net/ubuntu/+source/chromium-browser/+bug/1222488
[19:36] <seb128> qengho, (it just happened there as well)
[19:36] <smoser> infinity, ideally main. i probably should file MIR bug for that.
[19:36] <smoser> (i can do that RSN)
[19:36] <infinity> pkern: And I don't mean "we put little effort in, therefor it's buggy", I mean it mostly Just Works.  Except when doing new features.
[19:37] <infinity> smoser: Well, given its contents, I'd happily just NEW it to main in the 3 SRUs, and approve your saucy SRU.  File it now.  And seed it to supported.
[19:37] <infinity> smoser: s/saucy SRU/saucy MIR/
[19:38] <smoser> ok. i'll file MIR.
[19:38] <infinity> smoser: Cool.  I'll go have a smoke while you do that.
[19:38] <smoser> it will be a depends of MAAS but currently is not.
[19:42] <smoser> infinity, bug 1222997.
[19:49] <mterry> barry, heyo.  I assume that python-oauthlib still doesn't have the server OAuth bits that a package like keystone would need?
[19:49] <mterry> barry, keystone wants to be in main and it wants to pull in python-oauth2...
[19:49] <mterry> zul, ^
[19:50] <barry> mterry: hi.  zul just pvtmsg'd me about it :)
[19:51] <barry> mterry: a couple of things: idk if oauthlib has grown much server side support (or the support you need).  our oauthlib is way behind debian, so i need to file an ffe to get that updated/sync'd (i'm working on a stack of python packages today, so i'll add that to the list).  it's a bummer that python-oauth2 doesn't have py3 support afaict
[19:51] <infinity> smoser: MIR approved, promoted in saucy, and accepted in p/q/r.
[19:51] <smoser> gracias.
[19:52] <mterry> barry, not that server cares yet about py3, but I feel ya
[19:52] <barry> mterry: yeah ;)
[19:53] <mterry> zul, are you in a position to determine if the latest python-oauthlib from Debian has enough/any server OAuth support?
[19:55] <barry> mterry, zul: very high level, but https://github.com/idan/oauthlib/blob/master/README.rst#changelog
[19:56] <mterry> barry, zul: sounds like they have *some* provider (server) support
[19:57] <barry> mterry: right, that's what it looks like.  is it enough for you?
[19:58]  * mterry shrugs
[20:00] <infinity> smoser: And shuffled through binary NEW as well now.
[20:14] <zul> mterry/barry: im not sure yet ill poke at it tonight
[20:16] <barry> zul: np.  if expediency requires continued use of python-oauth2, i think that'll be fine for saucy, but please put a bug on the radar for porting to oauthlib for treading tiger
[20:18] <zul> barry:  https://bugs.launchpad.net/ubuntu/+source/keystone/+bug/1223010
[20:22] <cjwatson> barry: OK, I'll leave the fix up to you if you're on it :)
[21:06] <pitti> xnox: jibel and I just debugged a 5 s boot hang, and it's the ancient "/etc/initramfs-tools/conf.d/resume has wrong UUID" problem again
[21:06] <pitti> this is still bug 50437
[21:06] <pitti> xnox: could it be that ubiquity is calling mkswap after ./scripts/plugininstall.py (where it detects the UUID)?
[21:07] <pitti> xnox: but perhaps we should fix initramfs-tools to update the UUID at update-initramfs time, so that it will also survive changes to swap partitions?
[21:08] <barry> zul, mterry: LP: #1223004
[21:28] <ogra_> pitti, does logind have an equivalent to ck-list-sessions ?
[21:29] <pitti> ogra_: yes, "loginctl"
[21:29] <ogra_> mterry, ^^^
[21:29] <pitti> ogra_: or "loginctl show-session c1" (or another session name)
[21:30] <mterry> pitti, thanks
[22:14] <darkxst> oh what happened with Bug #1189309? It seemed to be uploaded to raring-proposed instead of saucy?
[22:20] <darkxst> pitti, hi
[22:26] <darkxst> pitti, https://bugzilla.gnome.org/707769, we inhibit the lid switch, which stops the screen from locking
[22:29] <darkxst> pitti, seems like we should instead take a suspend inhibitor from do_lid_closed_action()? does that sound right?
[23:46] <darkxst> pitti, nm, was just a silly bug
[23:49] <darkxst> infinity, can you take a look at Bug #1189309? It seemed to be uploaded to raring-proposed instead of saucy?
[23:52] <infinity> darkxst: Want that rejected from raring-proposed and reuploaded to saucy?
[23:52] <infinity> darkxst: I assume the bug should also move from libappindicator to network-manager-applet?