=== freeflying_away is now known as freeflying === Nisstyre-laptop is now known as nisstyre === freeflying is now known as freeflying_away [04:37] I've forgotten how to mark a bug as applicable to multiple releases of Ubuntu, can someone help jog my memory? [04:45] Caesar: Also affects series [04:45] Hm. IIRC. [04:52] RAOF: Is the UI for that access restricted? [04:53] Caesar: It's “Nominate for series”, and the nomination is not restricted (AFAIK), but acceptance of the nomination is restricted. [04:54] Aha. https://answers.launchpad.net/launchpad/+question/152525 [04:55] I'm not a bug supervisor === freeflying_away is now known as freeflying === freeflying is now known as freeflying_away === freeflying_away is now known as freeflying === Guest40875 is now known as NCommander === NCommander is now known as Guest33707 [06:32] good morning === steveire_ is now known as steveire === MacSlow is now known as MacSlow|lunch === gusch is now known as gusch|lunch [12:10] Good morning [12:19] Hi, does anyone know when the netboot image for Ubuntu 13.10 is going to be built? === gusch|lunch is now known as gusch === MacSlow|lunch is now known as MacSlow [12:24] ivebeenlinuxed: The final one will only be days before final release, but you can always use the development one [12:24] 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] Yeah - even going to a logical direct link (netbook/saucy) doesn't give anything either [12:27] ivebeenlinuxed: I've updated that page now [12:28] 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 === _salem is now known as salem_ [12:31] 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] @pilot in === udevbot changed the topic of #ubuntu-devel to: Ubuntu 13.10 Beta 1 released | Archive: Open, FF | Devel of Ubuntu (not support or app devel) | build failures -> http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of lucid -> raring | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: infinity [13:12] 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. === mzanetti is now known as mzanetti|otp [13:31] rsalveti: what should be done about the 'elementary' package since enna and intone ftbfs against the new version? [13:33] jbicha: hm, let me take a look [13:45] jbicha: yeah, would need some porting, and upstream for both seems to be dead, and not following the latest efl changes [13:45] will give it a try later today [13:49] rsalveti: ok, otherwise we can remove it from saucy-proposed since it's only in Debian experimental [13:49] jbicha: yeah === mzanetti|otp is now known as mzanetti === kentb-out is now known as kentb === mzanetti is now known as mzanetti|food === kentb is now known as kentb-afk === Guest33707 is now known as NCommander === NCommander is now known as Guest84948 === mzanetti|food is now known as mzanetti === dpm_ is now known as dpm-pc === steveire is now known as someone_else === someone_else is now known as steveire === kentb-afk is now known as kentb === cr3_ is now known as cr3 === cr3 is now known as Guest54483 === Guest84948 is now known as NCommander === zyga_ is now known as zyga === Guest54483 is now known as cr3 === cr3 is now known as Guest68546 [16:50] what does "xxx has no binaries on any arch " mean? [16:52] probably that it failed to build === Guest68546 is now known as cr3 === cr3 is now known as Guest53341 [17:14] 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:14] bug 982889 in xorg-server-lts-quantal (Ubuntu Saucy) "X trying to start before plymouth has finished using the drm driver" [Undecided,New] https://launchpad.net/bugs/982889 [17:15] barry: did you notice the tox build failure? [17:25] cjwatson: i didn't. looking now === Guest53341 is now known as cr3 [18:13] cjwatson: looks like we'll need to syncpackage python-pip 1.4.1 to fix the tox ftbfs [18:30] seb128: hey, I think the retraces are busted agaiun [18:32] sarnold, we need to get you access to those ;-) [18:33] sarnold, yeah, the amd64 one is down for a week :/ [18:33] they are down more often than running nowadays [18:34] 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] seb128: that sounds like it might help... but then, I'm still not getting emails about it when there are locks [18:35] so our monitoring should apparently be fixed [18:35] seb128: where exactly to the locks show up? Maybe we should set up another cronjob to notify when there's a deadlock [18:36] slangasek, right, I've no idea about that, the crontab has MAILTO properly filed from what I can tell [18:37] slangasek, ~ubuntu-archive/lock. ... but how do you tell a valid lock apart from a leftover? [18:37] seb128: check for a running process? (Does the lockfile contain a pid?) [18:38] slangasek, no, it's an empty file [18:38] hmm, how indeed then [18:38] well, that's open source, you can submit a patch to apport to make it write the pid in the lock :p [18:38] seb128: down for a week, ouch.. they do a lot of awesome magic in the background when they just work.. [18:38] seb128, slangasek: the main idea about stopping the retracer was to avoid untagging five hundred crashes and failing on them [18:39] sarnold, yeah, they do, and I expect there are not so many problems but they keeping hitting the same ones [18:39] seb128: or maybe it holds the lock open while running? either way would be reasonable [18:39] seb128, slangasek: but we can certainly grep out the failures from the logs and re-tag them [18:39] pitti, do we need to untag on failures? [18:39] pitti, or said differently "why does it untag if the retracing doesn't success"? [18:40] it should be the last thing in the process [18:40] before going to next one in the queue [18:40] (in discussion, just reading with half an eye) [18:40] seb128: if you don't, you need additional smarts to not re-process them over and over again [18:40] infinite loop [18:40] in fact, if the cron mail was working reliably, this wouldn't be such a problem [18:41] pitti, seems like we could change the tag rather than remove it [18:41] seb128: yes, we could [18:41] pitti, http://paste.ubuntu.com/6084644/ is the current log ... it's not really verbose on the issue :/ [18:41] 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] pitti, the recent failures are mostly like that [18:41] presumably these days the errors that we'll see are mostly not systematic any more, but glitches in LP/network [18:42] right [18:42] recently I just remove the lock [18:42] and it's going through again for a few days [18:42] it's not like it was hitting bugs on specific bugs [18:42] yeah, then we could just change it to not stop at an error, but just log it instead [18:42] +1 [18:42] but we need to ensure it doesn't loop on a particular bug [18:42] I would still like to figure why emailing is not working [18:43] pitti, slangasek: did you try to ask IS if emails where going through from that box? [18:43] seb128: no, not yet [18:43] no, was going to send test mails first [18:43] seb128: sometimes I do get mail, but it seems most often I don't [18:43] pitti, I would rather change the tag, e.g put it retrace-need-review or something [18:43] seb128: there's an apport-retrace-failed tag already [18:44] slangasek, ok, I'm going to let you do that then [18:44] but we use that mostly for "gdb didn't figure out a good stack trace' [18:44] pitti, right [18:44] pitti, we might want to tag bugs differently because those might be apport issues [18:44] bugs in the retracing [18:44] seb128: right [18:44] e.g that list is worth reviewing [18:44] like, in the LP/launchpadlib/network chain [18:44] pitti, should I open a wishlist about it? [18:45] sure [18:46] osageorange log shows mail being relayed, but it hasn't been delivered to me [18:46] oh, there it is now [18:46] so cron mail delivery seems to be ok [18:47] From ubuntu-archive@osageorange.canonical.com Mon Sep 9 20:45:03 2013 [18:47] Subject: Cron echo "testing cron mail" >&2 [18:47] this one? [18:47] yep [18:47] slangasek: yes, as I said I do get the cron fail mail sometimes, but not reliably [18:47] well, but maybe that's because apport isn't reliably generating any output on failure? [18:48] well, exceptions are being shown in the log, so the exit status ought to be non-zero [18:49] does that generate a mail from cron? I thought the trigger for mail was output on std{err,out} [18:49] oh, I see how the i386 one would do that [18:49] as after crash-digger it runs the duplicate db without saving the exit stauts [18:49] but the amd64 retracer only calls crash-digger [18:51] pitti, https://bugs.launchpad.net/ubuntu/+source/apport/+bug/1222978 [18:51] Launchpad bug 1222978 in apport (Ubuntu) "Should tag retracing problems rather than stop on them" [Undecided,New] [18:51] From ubuntu-archive@osageorange.canonical.com Wed Sep 4 20:48:05 2013 [18:51] Subject: Cron schroot -q -c quantal-amd64 -- sh - [18:51] that's the last one which I got [18:52] seb128: merci [18:52] pitti, de rien ;-) [18:52] pitti, same for me, most recent was sep 4 20:48 [18:54] pitti, the content of that email doesn't even really makes sense to me [18:54] oh, it's from the dup checking job [18:55] cjwatson: s/pip/virtualenv/ but i still think we need to sync pip too. sign. ffe's coming [18:57] infinity, you're sru teaming today, could you please look at https://bugs.launchpad.net/ubuntu/+source/ubuntu-cloudimage-keyring/+bug/1218963 ? [18:57] Launchpad bug 1218963 in ubuntu-cloudimage-keyring (Ubuntu Raring) "SRU ubuntu-cloudimage-keyring into archive" [Medium,In progress] [18:57] seb128: ah, the sep 4 one was dupcheck? === zyga is now known as zyga-afk [18:57] pitti, yes [18:58] pitti, in fact it seems I receive only dupchecks emails [18:58] hm, that also redirects output and stderr to a log file [18:58] it's not structurally different to the amd64 one [18:58] so I wonder why one is sending mails, but not the other [18:58] pitti, that box goes back to 30/04/2013 here and I only got dupcheck emails [18:59] so we never receive retracing emails anymore [18:59] but it's certainly more likely that the cron jobs are wrongly defined than mails only being sent sometimes [19:00] it seems that cron doesn't actually care about the exit status? [19:00] pitti: right, I believe that's correct [19:00] so that's probably it [19:00] it only mails you when there's output [19:00] so since all the output is redirected... :) [19:00] we probably need something like crash-digger || tail -n 10 logfile ? [19:01] yeah, that should do the job [19:01] curious why I sometimes do get mail then [19:01] how did it use to work? [19:01] pitti, you get emails from the dupchecker [19:01] right, but that's also doing >> log/dupcheck.log 2>&1 [19:01] right, I haven't gotten any mails about these locks at all since being added to the crontab [19:02] pitti, hum, indeed [19:02] weird [19:02] pitti: https://code.launchpad.net/~vorlon/apport/crashdigger-proper-lockfile/+merge/184660 [19:03] changed the crontabs [19:03] with the || tail approach [19:03] so it now ought to send cron mail [19:04] slangasek: I think os.write is expecting bytes, not str [19:04] pitti: the whole program is currently python2... would you like me to fix that? :) [19:05] slangasek: ah, it's python3 in the saucy branch [19:05] ah [19:05] but we use a trunk checkout [19:05] indeed [19:05] 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] slangasek: see setup.py, it fixes the shebangs during install, depending on which py version you called setup.py installwith [19:06] "install with" [19:07] slangasek: honestly I need a way to reproduce it :s [19:07] slangasek: and no the bugfix won't help [19:07] pitti: aha, ok, so the code is actually bilingual on trunk - will fix [19:08] slangasek: yeah, for releasing I run the test suite for both py2 and py3 [19:08] slangasek: probably easiest to just append an .encode() [19:08] brb [19:10] right, encode, sigh [19:10] slangasek, pitti: \o/ emails work (ignore the email, I just stopped it manually to test) [19:21] seb128: yay [19:24] slangasek: cheers, merged (with NEWS) and rolled out [19:27] Just curious, why were the alternative install images removed as an option? [19:28] smoser: Maaaaybe. [19:28] SuperLag: because two images take more effort to maintain than 1, and the desktop images now supported all our major use cases [19:29] And any usecases the desktop images don't cover is still covered by the d-i netboot images. [19:29] Are they supported? [19:29] They're not not supported. === Ursinha is now known as Ursinha-afk [19:30] infinity: Because you want to avoid an unconditional »yes«? :P [19:30] 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] I have a specific commercial customer in mind, which is why I ask. [19:31] pkern: subtle [19:31] slangasek: He brought it up. [19:31] :) [19:31] it's ok, your secret is safe with me [19:32] Pah [19:32] Heh. [19:32] 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] We do some d-i QA for sure, plus rely on it heavily internally, plus are happy to address bugs filed. [19:33] So, it's fairly supported, it's just not as heavily focused on as the live images by certain people. [19:34] It also breaks less spectacularly and less often, mind you. :P [19:34] Apparently beating d-i into shape for a realease can also be some significant effort. :) [19:34] *release [19:35] smoser: Is ubuntu-cloudimage-keyring meant to live in universe, or will that be changing? [19:36] pkern: We put remarkably little effort into it, actually, except when introducing new targets (which I'm doing this afternoon...) [19:36] pkern: generally not when one only has 4-5 archs to support :) [19:36] qengho, seems like you moved files between binaries and forgot a Replaces: https://bugs.launchpad.net/ubuntu/+source/chromium-browser/+bug/1222488 [19:36] Launchpad bug 1222488 in chromium-browser (Ubuntu) "package chromium-browser-l10n 28.0.1500.71-0ubuntu3 failed to install/upgrade: trying to overwrite '/usr/lib/chromium-browser/remoting_locales/th.pak', which is also in package chromium-browser 28.0.1500.71-0ubuntu3" [Undecided,Confirmed] [19:36] qengho, (it just happened there as well) [19:36] infinity, ideally main. i probably should file MIR bug for that. [19:36] (i can do that RSN) [19:36] 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] 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] smoser: s/saucy SRU/saucy MIR/ [19:38] ok. i'll file MIR. [19:38] smoser: Cool. I'll go have a smoke while you do that. [19:38] it will be a depends of MAAS but currently is not. [19:42] infinity, bug 1222997. [19:42] bug 1222997 in ubuntu-cloudimage-keyring (Ubuntu) "[MIR] ubuntu-cloudimage-keyring" [Undecided,New] https://launchpad.net/bugs/1222997 [19:49] barry, heyo. I assume that python-oauthlib still doesn't have the server OAuth bits that a package like keystone would need? [19:49] barry, keystone wants to be in main and it wants to pull in python-oauth2... [19:49] zul, ^ [19:50] mterry: hi. zul just pvtmsg'd me about it :) === Ursinha-afk is now known as Ursinha [19:51] 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] smoser: MIR approved, promoted in saucy, and accepted in p/q/r. [19:51] gracias. [19:52] barry, not that server cares yet about py3, but I feel ya [19:52] mterry: yeah ;) [19:53] zul, are you in a position to determine if the latest python-oauthlib from Debian has enough/any server OAuth support? [19:55] mterry, zul: very high level, but https://github.com/idan/oauthlib/blob/master/README.rst#changelog [19:56] barry, zul: sounds like they have *some* provider (server) support [19:57] mterry: right, that's what it looks like. is it enough for you? [19:58] * mterry shrugs [20:00] smoser: And shuffled through binary NEW as well now. [20:14] mterry/barry: im not sure yet ill poke at it tonight [20:16] 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] barry: https://bugs.launchpad.net/ubuntu/+source/keystone/+bug/1223010 [20:18] Launchpad bug 1223010 in keystone (Ubuntu) "Use oauthlib rather than oauth." [Undecided,New] [20:22] barry: OK, I'll leave the fix up to you if you're on it :) === zyga-afk is now known as zyga [21:06] 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] this is still bug 50437 [21:06] bug 50437 in initramfs-tools (Ubuntu) "Resume from hibernation may fail because swap partition UUID does not match /etc/initramfs-tools/conf.d/resume" [Medium,Triaged] https://launchpad.net/bugs/50437 [21:06] xnox: could it be that ubiquity is calling mkswap after ./scripts/plugininstall.py (where it detects the UUID)? [21:07] 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] zul, mterry: LP: #1223004 [21:08] Launchpad bug 1223004 in python-oauthlib (Ubuntu) "[FFe] sync with debian which has 0.5.1" [Undecided,New] https://launchpad.net/bugs/1223004 === salem_ is now known as _salem [21:28] pitti, does logind have an equivalent to ck-list-sessions ? [21:29] ogra_: yes, "loginctl" [21:29] mterry, ^^^ [21:29] ogra_: or "loginctl show-session c1" (or another session name) [21:30] pitti, thanks [22:14] oh what happened with Bug #1189309? It seemed to be uploaded to raring-proposed instead of saucy? [22:14] bug 1189309 in libappindicator "nm-applet crashed with SIGSEGV in gtk_status_icon_set_visible()" [High,Confirmed] https://launchpad.net/bugs/1189309 [22:20] pitti, hi [22:26] pitti, https://bugzilla.gnome.org/707769, we inhibit the lid switch, which stops the screen from locking [22:26] Gnome bug 707769 in power "Lid close doesn't lock screen if lid-close-action not set to suspend" [Major,Unconfirmed] [22:29] pitti, seems like we should instead take a suspend inhibitor from do_lid_closed_action()? does that sound right? === vibhav is now known as Guest45453 [23:46] pitti, nm, was just a silly bug === Nisstyre-laptop is now known as nisstyre [23:49] infinity, can you take a look at Bug #1189309? It seemed to be uploaded to raring-proposed instead of saucy? [23:49] bug 1189309 in libappindicator "nm-applet crashed with SIGSEGV in gtk_status_icon_set_visible()" [High,Confirmed] https://launchpad.net/bugs/1189309 [23:52] darkxst: Want that rejected from raring-proposed and reuploaded to saucy? [23:52] darkxst: I assume the bug should also move from libappindicator to network-manager-applet?