=== dendrobates is now known as dendro-afk === Torpedo_Skyline is now known as TorpedoSkyline === bazhang_ is now known as bazhang [01:47] is this a good place to ask upstart questions? [01:47] yes, though not the ideal time :) [01:48] i guess that [01:49] slangasek: do you know things about job instances? [01:49] yes [01:49] so we have a lava-instance job that has [01:49] instance $LAVA_INSTANCE [01:49] and lava-instance-uwsgi that has [01:50] instance $LAVA_INSTANCE [01:50] start on starting lava-instance [01:50] stop on stopping lava-instance [01:50] when we do start lava-instance LAVA_INSTANCE=foo a lava-instance-uwsgi instance with LAVA_INSTANCE=foo is started [01:51] when we do stop lava-instance LAVA_INSTANCE=anything, all lava-instance-uwsgi jobs stop [01:51] hmm, really? [01:51] i guess this isn't so surprising, and we should say stop on stopping lava-instance LAVA_INSTANCE=$LAVA_INSTANCE ? [01:51] oh [01:51] slangasek: well, that's what seems to happen [01:51] try 'stop lava-instance anything' instead [01:52] uh really? [01:52] IIRC yes [01:52] stop: Env must be KEY=VALUE pairs [01:52] oh, n/m, I think I see the issue [01:52] lava-instance-uwsgi should be [01:53] stop on stopping lava-instance LAVA_INSTANCE=$LAVA_INSTANCE [01:53] ok [01:53] thats what i was leaning towards suspecting [01:53] or something like that [01:54] slangasek: it's slightly funny that the instance-ness propagates 'down' [01:54] but i guess that's because there are really environment variables involved here? [01:54] yes, there are [01:54] well, at some stages ;) [01:54] at other stages it's just key,value pairs being passed in a dbus call [01:54] and when you do start on starting , you inherit the env mumble starts in? [01:55] hmm, not entirely... I think init(5) explains the various idiosyncracies [01:55] sorry, afk now :) [01:55] ok [01:59] ahah [01:59] we also have [01:59] export LAVA_INSTANCE [01:59] in lava-instance [01:59] the murk parts, slightly === bladernr_afk is now known as bladernr_ [02:25] @pilot out === udevbot changed the topic of #ubuntu-devel to: Precise Feature Freeze in effect. Archive: open | Development of Ubuntu (not support, not app development) | build failures -> http://bit.ly/or6CHJ | #ubuntu for support and general discussion for hardy -> oneiric | #ubuntu-app-devel for app development on Ubuntu | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: === bladernr_ is now known as bladernr_afk [02:37] argl bargl === Torpedo_Skyline is now known as TorpedoSkyline [05:12] broder: http://paste.ubuntu.com/844050/ looks good to me for sysvinit, yes [05:12] slangasek: ok, cool. i'll go ahead and upload it [05:12] and i'll start working on the srus for that as well [05:19] broder: thanks :) [05:19] thanks for the review [05:33] slangasek: oh, hmm. is there any way for me to ensure that the sysvinit update gets taken after the insserv update? i could do a breaks, but that wouldn't technically prohibit, e.g., not-fixed-oneiric insserv + fixed-natty sysvinit [05:35] why wouldn't sysvinit breaks << fixed precise insserv prevent oneiric insserv + precise sysvinit/ [05:36] it would, but i also need to sru this fix to lucid through precise, inclusive [05:36] broder: you could breaks: insserv (<< 1.14.0-2ubuntu1), insserv (= 1.14.0-2.1) [05:36] ooh, breaks with an =. never thought of that [05:37] although breaks doesn't actually require the broken insserv to be /removed/, just /deconfigured/, so it is technically possible to still get breakage after initscripts has been upgraded [05:38] well, seemingly, each release gets its proper breaks (is there any problem with insserv getting upgraded before sysvinit on dist-upgrade? [05:39] if necessary, we could have initscripts use a versioned depends on insserv; initscripts already depends on sysv-rc | file-rc and sysv-rc depends on insserv and file-rc isn't actually installable in Ubuntu because upstart depends on sysv-rc [05:39] so it wouldn't break the world to have initscripts depend on insserv directly [05:40] micahg: the problem is that the old insserv breaks things and the new initscripts tries to clean it up... we don't want to leave insserv in a position to break things again and force us to do /another/ round of srus to clean up [05:41] so what would i do in that case? oneiric's initscripts would depend: insserv (>= 1.14.0-2.1ubuntu1) | insserv (= 1.14.0-2.1ubuntu0.1) ? [05:41] and then i keep adding disjunctions as i go further back? [05:41] yeah [05:41] fugly, innit :) [05:41] yeah... [05:42] Is there any way I can check the HUD's development? Like its stages? (Alpha, beta, etc.) [05:42] slangasek: we could survive without that dependency in precise, right? which at least means that the fugliness is temporary? [05:43] that would also couple any other insserv SRU with an initscripts upload [05:43] broder: yes, for precise I think it's fine to drop the disjunctions [05:43] Good morning [05:43] micahg: this is the only time we've done an insserv SRU to date [05:43] * slangasek waves to pitti [05:43] yay empty precise_probs \o/ [05:44] and that at FF time [05:44] pitti: new glib-networking broke ia32-libs, I subscribed you to the bug, needs multiarching [05:44] err..deps need multiarching [05:44] micahg: for libproxy? I thought that already was [05:44] micahg: thanks, will have a look [05:44] yeah [05:45] libproxy's deps I think [05:45] slangasek: ok. well, for starters, would you mind rejecting the oneiric initscripts i just uploaded? [05:45] err, sysvinit that is, of course [05:45] micahg: ah, libjavascriptcoregtk-1.0-0 [05:45] broder: done [05:45] i. e. webkit [05:46] micahg: acually, I'd rather not have it depend on that in the first place, it's rather big [05:46] will ask Laney about it when he comes online [05:47] sounds good [05:47] slangasek: and you think the depends is the best option here? [05:48] broder: I think it's the safest option that's most certain to kill this bug dead [05:54] slangasek: do you think it's an acceptable risk that this would break users who have their own insserv (e.g. from a ppa) installed? [05:55] heh [05:55] yes [05:55] worst case, they need to either rev their ppa build of insserv, or do a ppa build of sysvinit with it [05:59] slangasek: ok, really bad idea: have initscripts trigger on /usr/lib/insserv? [05:59] yuck :) [05:59] but...i think it would work, no? [06:00] I can see a couple ways that could be made to work; none of them appeal to me [06:00] why do anything with a trigger that could be expressed as a declarative package relationship [06:01] because the declarative syntax only lets me express an approximation of what i'm really trying to say? [06:02] ok, but suppose the user upgrades insserv to a version (local or otherwise) that doesn't include /usr/lib/insserv [06:02] this may or may not trigger [06:02] and it may or may not result in insserv being run and breaking things again afterwards [06:04] we could clean up the rc*.d links in the initscripts upgrade case and the trigger case [06:04] yes [06:04] but the point at which things get *broken* again is when $random_other_thing calls insserv [06:04] and there's no way to ensure the postinst is called at that point to fix it up [06:05] but that's still a problem with the dependency plan [06:05] how? [06:06] the only versions satisfying the dependency are ones that have moved insserv off the path [06:06] unless it moves back into the path in the future, which i thought was what you were worried about [06:07] broder: I'm not worried about it moving back into the path in an *archive* version [06:07] but a *ppa* version could be doing the wrong thing [06:07] hmm, let me check if that makes sense [06:08] nah, I officially don't care about any broken versions of insserv packages in anyone's ppa [06:09] what if the user installs the initscripts SRU but not the insserv one though? [06:09] with the dependency approach, they can't [06:09] are you doing the dependencies? [06:09] with the triggers approach, they're still screwed until they get the insserv update, but when they do, it'll be cleaned up [06:09] I thought that's what you were trying to talk me out of [06:09] right [06:10] i'm currently banging my head against a table trying to keep all of this straight :) [06:10] but not yet writing any code [06:10] I would prefer to deliver an SRU that forces the upgrade to a good version of insserv immediately, so that their shutdown is un-screwed and stays that way [06:11] ok. i think that seems right [06:13] ok [06:13] fwiw I wouldn't reject either approach if uploaded [06:13] I also wouldn't accept them at the moment, because I'm headed for bed ;) [07:00] micahg: uploaded a fixed libproxy which drops the webkit dependency FYI, I updated bug 933913 [07:00] Launchpad bug 933913 in libproxy (Ubuntu) "libjavascriptcoregtk-1.0-0, libicu48 need to be multiarched" [Undecided,In progress] https://launchpad.net/bugs/933913 [07:01] pitti: great, thanks [07:25] pitti, nice to wake up to a beer this morning! http://people.canonical.com/~ubuntu-archive/testing/precise_probs.html [07:25] rickspencer3: indeed! [07:25] rickspencer3: we got new armel panda buildds yesterday, they nicely managed to catch up with the backlog [07:25] and compiz fixed [07:26] yeah! [07:29] pitti, looks like the server smoke tests are in less good shape [07:29] * rickspencer3 braces for the desktop tests to run [07:30] rickspencer3: these look odd; maybe the same QA lab problem that didrocks was experiencing with his unity mergers? [07:30] error: internal error process exited while connecting to monitor: libvir: error : cannot execute binary /usr/local/bin/kvm: Permission denied [07:30] err [07:30] no, doesn't seem the same issue [07:30] rickspencer3: so, once the alternates and desktops build, that'll hit them as well [07:30] oops, looks like a lab issue, indeed [07:30] (it was a network one) [07:30] didrocks: right, sorry; should have checked logs before [07:30] jibel: ^ halp [07:31] no worry :) [07:31] day after FF, bad luck! [07:32] pitti, did 10.04.4 go out as expected? [07:32] rickspencer3: yes, it's out and announced [07:32] sweet! [07:32] big day yesterday [07:32] http://releases.ubuntu.com/10.04.4/ [07:33] http://releases.ubuntu.com/kubuntu/10.04.4/, too [07:34] good morning [07:34] * pitti hugs dholbach [07:35] * dholbach hugs pitti back [07:36] morning dholbach [07:36] hey rickspencer3 [07:39] Riddell, debfx_: hmm, kubuntu-docs wants to go to universe; is that intended? === smb` is now known as smb [08:11] pitti, good morning [08:11] bonjour jibel === david is now known as davidcalle [08:14] pitti, permission denied on kvm in the lab. that's weird. === jodh is now known as jhunt [08:53] YokoZar: indeed, http://people.canonical.com/~ubuntu-archive/nbs.html now has dssi-vst which needs to change its b-dep to wine1.4 [08:53] pitti: Aye, I'll get it right after I get this wine1.4 upload going. [08:55] does anybody else have issues with thunderbird too? [08:56] as in widgets being completely empty? [08:56] dholbach: bug 933951 [08:56] Launchpad bug 933951 in thunderbird (Ubuntu Precise) "Messaging menu extension interacts badly with lightning in precise making thunderbird unusable" [High,Triaged] https://launchpad.net/bugs/933951 [08:56] ah, thanks micahg [08:58] it's a real friday when you don't have to cram as much email as possible in between conversations [08:58] thanks, somebody :) [08:58] haha, thanks sabdfl :) [08:59] luckily it's easy to workaround it [09:17] pitti: kubuntu-docs rescued [09:19] cheers [09:45] cjwatson: any opinion on https://bugs.launchpad.net/ubuntu/+source/kickseed/+bug/810068/comments/13 ? I'm inclined to just reject the maverick-proposed uploads; we had enough trouble verifying this for lucid already [09:45] Launchpad bug 810068 in partman-iscsi (Ubuntu Maverick) "kickstart iscsi option broken" [High,In progress] [09:45] pitti: it would have been OK were that still a module [09:46] but I think disabling mozjs stops that being so [09:46] Laney: this probably needs to be split into several source packages at some point? [09:46] why source packages? [09:47] having them in separate binaries was alright wasn't it? [09:47] Laney: you can't build-dep on universe packages, though [09:47] it would be good to disable mozjs and have webkit still be a plugin [09:47] i. e. if we want the mozjs plugin in universe, it needs to be in an universe source package [09:47] Laney: yes, but webkit doesn't build without mozjs apparently [09:47] when I disabled mozjs, webkit wasn't built [09:47] it was [09:47] it's just a part of the main package now [09:48] ah; could this be split out again somehow? [09:48] I think — let me check [09:48] pulling in an extra > 1 MB package just for this seems a little exaggerated [09:48] having it in the plugin would be fine [09:49] also, we shoudl check whether it builds against libwebkitgtk-3.0-dev [09:49] for ubunt2 we had " * pacrunner_webkit" [09:49] i.e. webkit is builtin [09:51] I'm pretty sure it has webkit3 support [09:51] ok, SRU queues processed as much as possible [09:51] next week I'll speak to upstream about the module thing [09:52] thanks [09:52] or … actually, see libproxy/cmake/modules.cmk:21 [10:07] any archive admins around? I'm reviewing a proposed new package (see bug 930422) and wanted a second opinion on what they are doing with qtrpc2 [10:07] Launchpad bug 930422 in Ubuntu "[needs-packaging] rds Resara Server" [Wishlist,New] https://launchpad.net/bugs/930422 === debfx_ is now known as debfx [10:27] pitti: bug #934088 [10:27] Launchpad bug 934088 in libproxy (Ubuntu) "Re-enable webkit plugin as a module (and build against webkit3)" [Undecided,New] https://launchpad.net/bugs/934088 [10:28] pitti: did you see my ping before? [10:28] micahg: only the one about libproxy [10:28] pitti: can you please copy firefox/lucid-oneiric from ubuntu-mozilla-security to $RELEASE-security? [10:28] Laney: sweet, thanks! sponsoring [10:28] micahg: uh, not in backscroll; weird [10:28] cheers! [10:28] micahg: sure, doing [10:29] pitti: I've been having IRC issues, I'm hoping after I dist-upgrade they'll go away :) [10:33] optimism seems to die last... :-P [10:40] micahg: done [10:40] pitti: thanks [10:41] ~curse thunderbird [10:42] hrw: fix already uploaded and buidling [10:43] micahg: cool [10:43] time to run dget - will be faster then waiting for archive [10:44] micahg: can TB be built in 7GB of disk space? [10:44] * micahg checks [10:46] hrw: umm, cutting it very clsoe [10:46] hope it will fit - 7GB is my pbuilder tmpfs [10:47] oh, on armhf it's less [10:48] hrw: Someone has too much ram! [10:48] RAOF: 16GB was <100€ so why bother with 8GB :D [10:49] Fair call! [10:49] RAOF: when 8GB DDR3 sticks will be around price of 2x4GB DDR3 I will consider 16->24/32GB [10:49] Yeah, I guess I could build a desktop... :) [10:51] hrw: "swap? what is that?" [10:52] pitti: can you speak english? :) [10:53] pitti: with low price of ram I do not see sense in having swap [11:00] err -- WTH [11:00] all my copying of kernels to -proposed were just silently forgotten by LP [11:01] ah, no, seems just the publisher is veeery behind [11:11] bdrung: http://paste.ubuntu.com/845621/ [11:11] pitti: maverick> I guess; I was just uploading it for everything without especially thinking about it, really [11:16] According to omgubuntu (http://goo.gl/vXnPf) the sun java packages were going to be pulled from the partner repos yesterday. [11:17] It appears they're still there for natty. Can anyone enlighten me if they are going to be removed there as well? [11:33] go, ev, go! [11:34] haha === _salem is now known as salem_ [11:42] micahg: thx - ubuntu3 tb package works [11:47] hrw: chrisccoulson fixed it [11:53] could someone please close https://code.launchpad.net/~marcelstimberg/ubuntu/precise/scribus/merge-1.4-from-debian/+merge/92623 [11:53] chrisccoulson: thx for fix [11:53] a newer version has already been merged, see bug #930639 [11:53] Launchpad bug 930639 in scribus (Ubuntu) "Please merge scribus 1.4.0.dfsg+r17287-1 (main) from Debian sid (main)" [Undecided,Invalid] https://launchpad.net/bugs/930639 [11:53] micahg: and you confirmed that this version will work === MacSlow is now known as MacSlow|lunch === Torpedo_Skyline is now known as TorpedoSkyline [12:33] doko_, you around? [12:38] * TorpedoSkyline thinks doko_ disappeared. === dendro-afk is now known as dendrobates [13:12] bdmurray: sorry, the oneiric update-manager security update superseded your package in -proposed... === doko_ is now known as doko [13:15] chrisccoulson, yes, what's the issue? [13:29] doko - i could use some help on https://bugzilla.mozilla.org/show_bug.cgi?id=694594 :) [13:29] Mozilla bug 694594 in JavaScript Engine "Crashes with gcc 4.4.3" [Critical,New: ] [13:30] chrisccoulson, that's what you get when backporting new upstream versions :-/ [13:30] heh [13:33] chrisccoulson, did you test vanilla 4.4.6, or the Ubuntu packages? does 4.5.x work? [13:33] doko, i tested the ubuntu 4.4.6 package. i've not tested a vanilla gcc yet [13:33] 4.5.x seems to work though [13:33] note that there are backports for lucid in the ubuntu-toolchain-r/test repository, and in ubuntu-toolchain-r/ppa for gcc-4.4 [13:34] at least, we don't get any crashes from builds that are built with 4.5 :) [13:34] ok, but maybe not an option or the upload [13:34] thanks, i'll try a vanilla build too === MacSlow|lunch is now known as MacSlow [13:35] chrisccoulson, from the bug report I understand that you can work-around the issue? [13:36] doko, sort of. it's not a good long term solution, as this code is pretty performance optimized. and there's no guarantee that we don't see the same problem in other places too [13:36] understood === Ursinha` is now known as Ursinha === dendrobates is now known as dendro-afk [14:05] bdmurray, 933946 was closed with the wrong text (talking about apport, while it's a corrupt archive) === bladernr_afk is now known as bladernr_ === dendro-afk is now known as dendrobates === sikon_ is now known as lucidfox [14:39] hello, base-files fails to install on precise, when /var/run is not empty dir, there is a patch attached to a BR, is there something special that needs doing to get this applied? (BR: https://bugs.launchpad.net/ubuntu/+source/multistrap/+bug/874505) [14:39] Launchpad bug 874505 in multistrap (Ubuntu) "Native Multistrap oneiric chroots have an error configuring base-files" [Undecided,Confirmed] [14:43] zumbi: looks like it needs to be reviewed, I see the review team is already subscribed so it should get some attention soon [14:44] roadmr: ah! thanks [14:50] Riddell: ah, has there been a decision for telepathy-KDE now? [14:50] Riddell: (I'm just curious) [14:50] I read your blog a few days ago, and it didn't seem obvious which one was better [14:51] pitti: not yet, I'm still a fan of telepathy-KDE because it's maintained but others are more cautious for the LTS. It might come down to whether we can convince upstream to add message indicator integration :) [14:52] we'll make a decision in plenty time either way [14:52] Riddell: ah, I was just reading your -release@ mail [14:53] pitti: I still hope to have it in but happy to accept if it can't be done [14:53] Riddell: tricky situation indeed; we had pretty much the same a few cycles ago [14:54] at least the telepathy stack settled down since then, it's actually surprisingly stable these days [14:54] video connections used to be a bit unstable (sometimes you needed to try connecting twice), but that was some time ago; I don't use them often [14:54] the tubes for sharing your desktop etc. are really cool, though [14:55] * pitti goes back offline until release meeting, bbl [15:01] Riddell: good to see you got a version of telepathy uploaded that fixes the failure. i got as far as disabling the fix_test_linkage.patch and getting that built in my ppa. if you're happy with your fix, i'll move on to other things [15:03] barry: oh do I? clever me! [15:03] barry: where is this? === tomreyn_ is now known as tomreyn [15:12] Riddell: https://launchpad.net/ubuntu/precise/+source/telepathy-qt4/0.9.0+repack-0ubuntu2 [15:13] cking: I have a first version of a power-usage-report script (WI in that spec) in https://code.launchpad.net/~pitti/+junk/power-usage-report/ [15:14] cking: it can be run without arguments, does its thing (fatrace, powertop, and post-processing), and gives a reasonably meaningful output [15:14] cking: I'd appreciate comments and suggestions that you might have [15:15] cking: today I overheard in a bug report that you have an events-something script yourself, perhaps we can combine this somehow? [15:15] pitti, yes, that's doable - my code is free to be used + reworked [15:16] pitti, I will look at this in ~40 mins - I'm halfway through making a load of edits to a document that needs to be completed today [15:16] cking: oh, not urgent at all [15:16] I'll go offline again until release meeting, and won't re-look at this until Tuesday anyway [15:16] cking: thanks in advance! [15:17] Heh. By chance the nicks of everyone who has been discussing here for the last 25 minutes end up having the same appearance in WeeChat. (It uses nick hashes to select attributes such as color for nicks.) [15:17] cking: there's another WI to add stracing for the worst offenders, but that'll introduce some interesting problems (reporting passwords and what not), so that'll need some thought [15:17] ok - well, I'm off on monday, so I will either get back to you end of day or on tuesday [15:17] cking: I'm off on Monday as well [15:17] cking: but I think in the end the automatic stracing might be overkill -- at that point it's better to analyze the offending processes individually anyway in bug reports, I think [15:18] this script should give a good overview where the problems are on a particular system [15:18] anyway, /me waves, bbl [15:18] pitti, yep, I think one can has tools to identify rogue processes, debugging it is a strace + gdb effort [15:19] pitti, thanks for letting me know - I shall look at the tool with great interest! \o/ [15:22] Does "pull-lp-source" fail for anyone else? Eg: "pull-lp-source hello". [15:24] barry: yeah but that has led to a new problem, needing LD_LIBRARY_PATH or something [15:25] It seems to work from my machine (authenticated) but not from an anonymous machine [15:27] Riddell: yep. but hey, a built package is a built package, right? :) [15:30] Hmm...rm -Rf ~/.launchpadlib fixed it. [15:37] barry: it's not built [15:37] mdeslaur: in oneiric or lucid? [15:38] ivoks: I've merged your livecd-rootfs change, but two things [15:38] cjwatson: sure? [15:38] ivoks: firstly, in order to get a BuildLiveCD change deployed, you'll need to raise an RT [15:38] bdmurray: oneiric...oh, looks like your lucid -proposed package dropped the new security update too [15:39] bdmurray: d'oh...sorry about that [15:39] Riddell: okay. let me look in more detail [15:39] ivoks: secondly, the rest of Ubuntu nowadays only uses livecd-rootfs as a wrapper for live-build - the code for that is in the live-build/ subdirectory [15:39] ivoks: so in some ways you seem to be going in the wrong direction [15:39] bdmurray: publishing security updates when there are packages in -proposed is painful :( [15:39] barry: it's cdbs so actually mine and debfx's preference is just to turn it into dh9 and hope that helps [15:39] mdeslaur: the lucid was just approved and had been pending queue [15:39] cjwatson: mrmh... ok :) [15:39] ivoks: live-build/auto/config is probably the main one to edit [15:40] cjwatson: ok, thanks i'll do that [15:40] Riddell: i definitely support that choice :). shall i just leave this one to you guys then? [15:40] bdmurray: yeah, but while it was in the queue, a security update got published, and since you bumped the major version instead of the minor version, it superseded the security update [15:41] cjwatson: atm cloud-live is build with live-build; does that make any difference? should i still change livecd-rootfs? [15:41] mdeslaur: Is there anything for me to do besides upload new versions to -proposed? [15:41] I mean in addition to [15:42] bdmurray: no, you just need to remerge the security update and re-upload it [15:43] ivoks: how are you configuring live-build right now? [15:45] cjwatson: (sorry, i'm otp) i have whole live-build tree (lp:cloud-live) [15:46] ivoks: you mean you branched the whole thing? [15:50] ivoks: wow, that's ... interesting [15:50] ivoks: what I'd suggest is that you figure out how to do this with the stock live-build package in precise, using suitable 'lb config' parameters and possibly the odd hook [15:50] ivoks: then it should be a short step from there to expressing that in livecd-rootfs/live-build/auto/config [15:50] cjwatson: let me get back to you in few minutes (on the phone) [15:50] ivoks: sure, no rush [15:51] ivoks: ah, looks like you checked in the result of running lb config and creating hooks [15:51] ivoks: so that could be done on the fly in auto/config instead [15:51] dobey: ping. do you have time to review the proposed merge for bug #856728? [15:52] Launchpad bug 856728 in Ubuntu Translations "Missing translations (Learn more, Install) in ubuntuone-installer window" [Medium,Triaged] https://launchpad.net/bugs/856728 [15:52] kelemengabor: yep, i will poke at it shortly. i am working on installer right now :) [15:53] kelemengabor: thanks for the reminder [15:53] yw :) [15:53] bdmurray: i'll try to poke at your lptools branch today too === warp11 is now known as warp10 [15:55] dobey: thanks [16:01] cjwatson: sorry, i had a meeeting [16:01] cjwatson: all those changes are now in the package, so that build mechanism is kind of obsolete [16:01] cjwatson: s/changes/hooks [16:12] Little question before I file a bug report: why are the category icons for gnome-control-center named like preferences-desktop-personal-directory instead of preferences-desktop-personal ? [16:13] ev: test_run_crash_known() test case in ui.py works for you? I still get a KeyError (just re-merged your branch 5 mins ago) === EyesIsServer is now known as Eyes|Infinite [16:15] pitti: ah, I wasn't sure if that one was related to the gdb weirdness I was seeing. When I poked at it last night, it was raising an IOError inside collect() [16:15] I'll have another look [16:15] apols for that [16:15] ev: no, I get KeyError: 'KnownReport' [16:15] PYTHONPATH=. python apport/ui.py -v _T.test_run_crash_known [16:16] ev: that looks like a regression in the dupe detection [16:16] yes, but if memory serves, it's because the IOError is raised, setting self.report to None [16:16] (and thus the KeyError) [16:24] ev: bug report window looking nicely now, thanks for fixing that up! [16:25] ev: btw, I'm not getting the gdb failures; I suspect it's a race condition, but I don't think that's related to your work at all [16:30] pitti: cheers! [16:31] ev: I'm currently walking through all {bug, crash, symptoms} x {gtk, cli, qt} cases [16:32] thanks for that - I tried to understand them as best I could, to ensure I wasn't just making the test pass, but it was getting on in the evening and I could've made a mistake somewhere. [16:34] Ugh [16:34] why does apt want to remove unity-2d?! [16:34] gnome-session: Breaks: unity-2d (< 5.4~) but 5.2.1-0ubuntu2 is installed. [16:34] ahh, that [16:36] buildd lag [16:41] cjwatson, is it possible to increase 'something' on key packages like ubuntu-desktop to encourage apt's conflict resolution to prefer not to remove it [16:43] SpamapS, around ? [16:43] smoser: I am [16:43] /etc/network/if-up.d/upstart [16:43] i'm looking tat that and wondering [16:43] yes [16:44] is there any unity dev around, who could take a look at the merge proposal in bug #923762 ? [16:44] Launchpad bug 923762 in unity (Ubuntu) "Files missing from Unity's POTFILES.in" [Medium,In progress] https://launchpad.net/bugs/923762 [16:44] if no interfaces are auto, will all interfaces ever be noticed as up? [16:44] kelemengabor: try #ubuntu-desktop [16:44] smoser: lo is always going to be auto [16:45] well.. yeah. [16:45] smoser: and actually no, if there are no auto interfaces, all_interfaces_up will return 0 [16:45] so here s what i'm looking at right now. [16:45] because the for loop will be skipped [16:45] its mostly an edge case [16:45] err [16:45] actually this script will never be called in that case [16:46] and you'll failsafe boot [16:46] but in cloud-init, i can now take an /etc/network/interfaces file from "config drive" or from DataSourceNoCloud [16:46] jdstrand / mdeslaur (barry for info): bug 934295, not proud that i got it to build by giving back.. but you might want to be aware if it's not fixed before release. [16:46] Launchpad bug 934295 in python-django (Ubuntu) "FTBFS on buildd's testsuite (FAIL: test_timeuntil)" [Undecided,New] https://launchpad.net/bugs/934295 [16:46] the order would then be boot... likely lo up, mount / , cloud-init, cloud-init writes /etc/network/interfaces and runs 'ifup --all' [16:47] but if the new /etc/network/interfaces does not have any auto (other than lo) then nothing would emit that. [16:47] Daviey: gotta love it! thanks :) [16:47] hm.. [16:47] ev: for a crash report I still get the second window with the info colelction progress bar [16:48] ev: you don't? [16:48] but i guess that snot really all that bad, because anything waiting on that is probably actually expecting network. [16:49] pitti: Do you not get that error in test_run_crash_known with trunk? the error it's attempting to raise (but which gets swallowed by the except clause around collect_info) in both trunk and my branch is 'CRC check failed 0x6d754465 != 0x0L' [16:49] pitti: I do not. What's the command you're running where you're seeing that? [16:49] ev: gedit &; killall -SEGV gedit [16:49] PYTHONPATH=. gtk/apport-gtk [16:49]