| === freeflying_away is now known as freeflying | ||
| === Nisstyre-laptop is now known as nisstyre | ||
| === freeflying is now known as freeflying_away | ||
| Caesar | I've forgotten how to mark a bug as applicable to multiple releases of Ubuntu, can someone help jog my memory? | 04:37 |
|---|---|---|
| RAOF | Caesar: Also affects series | 04:45 |
| RAOF | Hm. IIRC. | 04:45 |
| Caesar | RAOF: Is the UI for that access restricted? | 04:52 |
| RAOF | Caesar: It's “Nominate for series”, and the nomination is not restricted (AFAIK), but acceptance of the nomination is restricted. | 04:53 |
| Caesar | Aha. https://answers.launchpad.net/launchpad/+question/152525 | 04:54 |
| Caesar | I'm not a bug supervisor | 04:55 |
| === 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 | ||
| dholbach | good morning | 06:32 |
| === steveire_ is now known as steveire | ||
| === MacSlow is now known as MacSlow|lunch | ||
| === gusch is now known as gusch|lunch | ||
| pitti | Good morning | 12:10 |
| ivebeenlinuxed | Hi, does anyone know when the netboot image for Ubuntu 13.10 is going to be built? | 12:19 |
| === gusch|lunch is now known as gusch | ||
| === MacSlow|lunch is now known as MacSlow | ||
| 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:24 |
| ivebeenlinuxed | Yeah - even going to a logical direct link (netbook/saucy) doesn't give anything either | 12:26 |
| cjwatson | ivebeenlinuxed: I've updated that page now | 12:27 |
| 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:28 |
| === _salem is now known as salem_ | ||
| 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... | 12:31 |
| infinity | @pilot in | 13:12 |
| === 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 | ||
| 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:12 |
| === mzanetti is now known as mzanetti|otp | ||
| jbicha | rsalveti: what should be done about the 'elementary' package since enna and intone ftbfs against the new version? | 13:31 |
| rsalveti | jbicha: hm, let me take a look | 13:33 |
| 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:45 |
| jbicha | rsalveti: ok, otherwise we can remove it from saucy-proposed since it's only in Debian experimental | 13:49 |
| rsalveti | jbicha: yeah | 13:49 |
| === 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 | ||
| zul | what does "xxx has no binaries on any arch " mean? | 16:50 |
| Laney | probably that it failed to build | 16:52 |
| === Guest68546 is now known as cr3 | ||
| === cr3 is now known as Guest53341 | ||
| 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:14 |
| ubottu | 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:14 |
| cjwatson | barry: did you notice the tox build failure? | 17:15 |
| barry | cjwatson: i didn't. looking now | 17:25 |
| === Guest53341 is now known as cr3 | ||
| barry | cjwatson: looks like we'll need to syncpackage python-pip 1.4.1 to fix the tox ftbfs | 18:13 |
| sarnold | seb128: hey, I think the retraces are busted agaiun | 18:30 |
| seb128 | sarnold, we need to get you access to those ;-) | 18:32 |
| seb128 | sarnold, yeah, the amd64 one is down for a week :/ | 18:33 |
| seb128 | they are down more often than running nowadays | 18:33 |
| 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:34 |
| 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:35 |
| seb128 | slangasek, right, I've no idea about that, the crontab has MAILTO properly filed from what I can tell | 18:36 |
| 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:37 |
| 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:38 |
| 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:39 |
| 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:40 |
| 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:41 |
| 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:42 |
| 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:43 |
| 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:44 |
| pitti | sure | 18:45 |
| 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:46 |
| 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:47 |
| pitti | well, exceptions are being shown in the log, so the exit status ought to be non-zero | 18:48 |
| 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:49 |
| seb128 | pitti, https://bugs.launchpad.net/ubuntu/+source/apport/+bug/1222978 | 18:51 |
| ubottu | Launchpad bug 1222978 in apport (Ubuntu) "Should tag retracing problems rather than stop on them" [Undecided,New] | 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:51 |
| pitti | seb128: merci | 18:52 |
| seb128 | pitti, de rien ;-) | 18:52 |
| seb128 | pitti, same for me, most recent was sep 4 20:48 | 18:52 |
| 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:54 |
| barry | cjwatson: s/pip/virtualenv/ but i still think we need to sync pip too. sign. ffe's coming | 18:55 |
| 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 |
| ubottu | Launchpad bug 1218963 in ubuntu-cloudimage-keyring (Ubuntu Raring) "SRU ubuntu-cloudimage-keyring into archive" [Medium,In progress] | 18:57 |
| pitti | seb128: ah, the sep 4 one was dupcheck? | 18:57 |
| === zyga is now known as zyga-afk | ||
| seb128 | pitti, yes | 18:57 |
| 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:58 |
| 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 | 18:59 |
| 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:00 |
| 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:01 |
| seb128 | pitti, hum, indeed | 19:02 |
| seb128 | weird | 19:02 |
| slangasek | pitti: https://code.launchpad.net/~vorlon/apport/crashdigger-proper-lockfile/+merge/184660 | 19:02 |
| pitti | changed the crontabs | 19:03 |
| pitti | with the || tail approach | 19:03 |
| pitti | so it now ought to send cron mail | 19:03 |
| 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:04 |
| 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:05 |
| 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:06 |
| 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:07 |
| 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:08 |
| slangasek | right, encode, sigh | 19:10 |
| seb128 | slangasek, pitti: \o/ emails work (ignore the email, I just stopped it manually to test) | 19:10 |
| pitti | seb128: yay | 19:21 |
| pitti | slangasek: cheers, merged (with NEWS) and rolled out | 19:24 |
| SuperLag | Just curious, why were the alternative install images removed as an option? | 19:27 |
| 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:28 |
| 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:29 |
| === Ursinha is now known as Ursinha-afk | ||
| 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:30 |
| 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:31 |
| 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:32 |
| 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:33 |
| 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:34 |
| infinity | smoser: Is ubuntu-cloudimage-keyring meant to live in universe, or will that be changing? | 19:35 |
| 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 |
| ubottu | 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 |
| 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:36 |
| 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:37 |
| 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:38 |
| smoser | infinity, bug 1222997. | 19:42 |
| ubottu | bug 1222997 in ubuntu-cloudimage-keyring (Ubuntu) "[MIR] ubuntu-cloudimage-keyring" [Undecided,New] https://launchpad.net/bugs/1222997 | 19:42 |
| 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:49 |
| barry | mterry: hi. zul just pvtmsg'd me about it :) | 19:50 |
| === Ursinha-afk is now known as Ursinha | ||
| 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:51 |
| mterry | barry, not that server cares yet about py3, but I feel ya | 19:52 |
| barry | mterry: yeah ;) | 19:52 |
| mterry | zul, are you in a position to determine if the latest python-oauthlib from Debian has enough/any server OAuth support? | 19:53 |
| barry | mterry, zul: very high level, but https://github.com/idan/oauthlib/blob/master/README.rst#changelog | 19:55 |
| mterry | barry, zul: sounds like they have *some* provider (server) support | 19:56 |
| barry | mterry: right, that's what it looks like. is it enough for you? | 19:57 |
| * mterry shrugs | 19:58 | |
| infinity | smoser: And shuffled through binary NEW as well now. | 20:00 |
| zul | mterry/barry: im not sure yet ill poke at it tonight | 20:14 |
| 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:16 |
| zul | barry: https://bugs.launchpad.net/ubuntu/+source/keystone/+bug/1223010 | 20:18 |
| ubottu | Launchpad bug 1223010 in keystone (Ubuntu) "Use oauthlib rather than oauth." [Undecided,New] | 20:18 |
| cjwatson | barry: OK, I'll leave the fix up to you if you're on it :) | 20:22 |
| === zyga-afk is now known as zyga | ||
| 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 |
| ubottu | 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 |
| pitti | xnox: could it be that ubiquity is calling mkswap after ./scripts/plugininstall.py (where it detects the UUID)? | 21:06 |
| 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:07 |
| barry | zul, mterry: LP: #1223004 | 21:08 |
| ubottu | Launchpad bug 1223004 in python-oauthlib (Ubuntu) "[FFe] sync with debian which has 0.5.1" [Undecided,New] https://launchpad.net/bugs/1223004 | 21:08 |
| === salem_ is now known as _salem | ||
| ogra_ | pitti, does logind have an equivalent to ck-list-sessions ? | 21:28 |
| pitti | ogra_: yes, "loginctl" | 21:29 |
| ogra_ | mterry, ^^^ | 21:29 |
| pitti | ogra_: or "loginctl show-session c1" (or another session name) | 21:29 |
| mterry | pitti, thanks | 21:30 |
| darkxst | oh what happened with Bug #1189309? It seemed to be uploaded to raring-proposed instead of saucy? | 22:14 |
| ubottu | bug 1189309 in libappindicator "nm-applet crashed with SIGSEGV in gtk_status_icon_set_visible()" [High,Confirmed] https://launchpad.net/bugs/1189309 | 22:14 |
| darkxst | pitti, hi | 22:20 |
| darkxst | pitti, https://bugzilla.gnome.org/707769, we inhibit the lid switch, which stops the screen from locking | 22:26 |
| ubottu | Gnome bug 707769 in power "Lid close doesn't lock screen if lid-close-action not set to suspend" [Major,Unconfirmed] | 22:26 |
| darkxst | pitti, seems like we should instead take a suspend inhibitor from do_lid_closed_action()? does that sound right? | 22:29 |
| === vibhav is now known as Guest45453 | ||
| darkxst | pitti, nm, was just a silly bug | 23:46 |
| === Nisstyre-laptop is now known as nisstyre | ||
| darkxst | infinity, can you take a look at Bug #1189309? It seemed to be uploaded to raring-proposed instead of saucy? | 23:49 |
| ubottu | bug 1189309 in libappindicator "nm-applet crashed with SIGSEGV in gtk_status_icon_set_visible()" [High,Confirmed] https://launchpad.net/bugs/1189309 | 23:49 |
| 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? | 23:52 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!