[07:50] <Unit193> I'm going to save myself time and pasting.  You know Xfce?  You know the components?  Just presume they're all getting uploaded this week.
[21:41] <bluesabre> Yay!
[21:41] <bluesabre> Thanks Unit193!
[21:42] <Unit193> There's already been some nice bugfixes land.  I haven't picked up 4.19 though..
[22:04] <Unit193> bluesabre: Speaking of which, did you or someone you have contact with hit xfce4-screensaver issue 1?  I don't, but this latest one had some changes and I'm hopeful...
[22:25] <bluesabre> Unit193: Funny enough, I can reproduce it now. But only on my raspberry pi


[02:44] <StevenK> BLEH
[02:45] <StevenK> I wanted buildbot done when I got back from lunch, but it failed PQM due to testfix
[02:45]  * StevenK stabs testfix
[02:46] <StevenK> wallyworld, wgrant: The Top 10 Durations make me very sad. Product, Bug, Bug, Bug, Bug, Bug, Bug, Bug, Distribution, Bug
[02:47] <wallyworld> there's more to do
[02:48] <StevenK> wallyworld: It's LP. There is *always* more to do.
[02:49] <wallyworld> yep
[08:48] <adeuring> good morning
[08:56] <dimitern> adeuring: morning :)
[09:01] <StevenK> adeuring: Could you please please get Aaron to do his QA today? It's been holding up deployments for two days.
[09:01] <adeuring> StevenK: sure
[11:02] <smartboyhw> Hi guys, is the on call reviewer rick_h here?
[11:04] <czajkowski> smartboyhw: nope he's stateside atm
[11:04] <czajkowski> think thats left over from yesterday
[11:04] <smartboyhw> czajkowski, ouch. Want to fix a small bug
[11:05] <smartboyhw> Very small, just a typo thing
[11:05] <czajkowski> adeuring: know who is the on call reviewer today ?
[11:06] <adeuring> czajkowski: nobody right now: https://dev.launchpad.net/ReviewerSchedule
[11:06] <czajkowski> adeuring: cheers
[11:06] <adeuring> smartboyhw: I am a reviewer too. what's up
[11:08] <smartboyhw> adeuring, bug 978002
[11:08] <_mup_> Bug #978002: Incorrect wording in 'Your Launchpad Karma'. <karma> <lp-answers> <trivial> <Launchpad itself:In Progress> < https://launchpad.net/bugs/978002 >
[11:08] <smartboyhw> very small one:P
[11:09] <czajkowski> adeuring: thanks
[11:11] <adeuring> smartboyhw: As Curtis noted in a bug comment, you patch unfortunately does not fix the problem in production
[11:11] <smartboyhw> oh?
[11:11] <adeuring> We need to manually run an SQL command on the production database
[11:11] <smartboyhw> adeuring, eh
[11:11]  * smartboyhw goes crying
[11:12] <smartboyhw> Let me go find another bug to fix then
[11:12] <adeuring> smartboyhw: sure, sounds good. if you have any qestion, feel free to ping me
[11:12] <StevenK> smartboyhw: I will mention that bug to Curtis when I speak to him, too, since he hasn't done it.
[11:12] <smartboyhw> adeuring, StevenK thanks
[11:51] <ev> Hiya. Would someone please create a project group for me: https://answers.launchpad.net/launchpad/+question/213666
[11:52] <czajkowski> ev: sure
[11:54] <ev> czajkowski: cheers
[11:54] <czajkowski> ev: can you pm me a project group summary and a description please.
[11:54] <rick_h> heh, sorry that was Tues
[11:55] <czajkowski> rick_h: morning
[11:55] <rick_h> morning czajkowski
[11:55] <czajkowski> rick_h: whats the state of the nation over there with the electricity
[11:55] <rick_h> czajkowski: came back in the afternoon and all the clocks reset and hopefully the UPS is charged back up
[11:55] <rick_h> kind of strange, we don't lose power much here
[11:55] <czajkowski> sweet
[11:55] <czajkowski> back home home it does reguarly
[11:56] <czajkowski> for hours, and nobody really does the back up generator
[11:56] <czajkowski> not sure why
[11:56] <czajkowski> remember one christmas it was gone for 6 days
[11:56] <czajkowski> pita
[11:56] <rick_h> ouch
[11:56] <rick_h> sucked just to lose it for half a day
[11:56] <rick_h> I think 6 days would kill off the fish
[11:56] <czajkowski> most of the country was hit that year.
[11:57] <dpm> hi Launchpad devs, what's the best way to reassign ownership of a branch in LP from an individual to a team?
[12:00] <bac> rick_h: why did the power go out?
[12:00] <rick_h> bac: no idea. The website showed it hit a couple sqmi but no reason I could find
[12:00] <rick_h> so guess something just went boom
[12:01] <czajkowski> ev: almost there
[12:01] <bac> rick_h: a friend of mine had a *huge* salt water aquarium with lots of exotics and coral.  lost power for 7 days and they were all dead.
[12:01] <czajkowski> just having issues with the name
[12:01] <czajkowski> :/
[12:01] <bac> he went out and bought a $10K generac as soon as possible
[12:01] <rick_h> bac: yea, I think this was our first outage of more than 10min in years so got me thinking about the squarium yesterday
[12:01] <czajkowski> dpm: hmmm
[12:01] <czajkowski> unsure
[12:01] <rick_h> freshwater though, so not that much $$ into it
[12:01] <czajkowski> rick_h: any ideas re dpm
[12:01] <rick_h> but still a couple grand
[12:02] <rick_h> czajkowski: dpm I'd just take the branch and push it to the team if you've got access.
[12:02] <rick_h> bzr push lp:~team/project/branch
[12:02] <dpm> ok, let me try that
[12:02] <dpm> thanks
[12:02] <rick_h> dpm: off the top of my head, errors may ensue :)
[12:02] <czajkowski> bah naturally the first time I go to create a project group it wont work smoothly
[12:03] <czajkowski> keep having an issue at Invalid name 'ubuntu error tracker'. Names must be at least two characters long and start with a letter or number. All letters must be lower-case. The characters +, - and . are also allowed after the first character.
[12:04] <czajkowski> but cant se any other project with the name so no idea why it's clashing :/
[12:05] <czajkowski> ev: I'm gonna wait till sinzui comes online to ask him but it'll be done in the next few hours.
[12:18] <dpm> rick_h, czajkowski, pushing the team branch and then setting the location in the project page worked, thanks!
[12:19] <rick_h> dpm: awesome, glad to hear it
[12:20] <czajkowski> dpm: lovely jubbly
[12:20] <czajkowski> now if all questions could be as simply solved today that would also be great
[12:20] <czajkowski> I know full well sinzui is gonna come along and say someting very simple as to why I cannot create this project group
[12:20] <czajkowski> but for the life of me I've no idea why :/
[12:35] <ev> czajkowski: thanks
[12:54] <czajkowski> Grabbing lunch bbiab
[13:57] <ev> thanks czajkowski, sinzui
[13:57] <czajkowski> sinzui: you did it ?
[13:58] <czajkowski> bah wanted to learn why it wasnt doing it for me :/
[13:58] <sinzui> the form requires a summary and description, and since none was provided in the question, I pasted the display name
[13:59] <sinzui> czajkowski, We don't uses title, but it too is required, so we paste that name in there
[13:59] <czajkowski> yes but I had that pasted in
[13:59] <czajkowski> I pasted the name in there also :/
[14:00] <sinzui> what error did you see? the form will usually state there is a form error?
[14:01] <sinzui> czajkowski, repeat what you did here: https://qastaging.launchpad.net/projectgroups/+new
[14:02] <czajkowski> ok
[14:03] <czajkowski> sinzui: same issue
[14:03] <czajkowski> Invalid name 'ubuntu error tracker staging'. Names must be at least two characters long and start with a letter or number. All letters must be lower-case. The characters +, - and . are also allowed after the first character.
[14:03] <czajkowski> A unique name, used in URLs, identifying the project group. All lowercase, no special characters. Examples: apache, mozilla, gimp.
[14:03] <czajkowski> wit the naming
[14:04] <sinzui> name is launchpad-id
[14:04] <sinzui> ubuntu-error-tracker
[14:04] <czajkowski> ahhhhh
[14:04] <czajkowski> https://qastaging.launchpad.net/launchpad-id
[14:04] <sinzui> ev, wrote the display name and launchpad-id in reverse of what Lp does
[14:05] <czajkowski> *headdes*
[14:05] <czajkowski> ok
[14:05] <czajkowski> will know for future
[14:05] <czajkowski> couldnt see what the issue was
[14:06] <czajkowski> sinzui: thanks for the help
[14:12] <deryck> Morning, all.
[14:51] <tim_> sinzui, any plans on folding blueprints into the new sharing stuff?
[14:52] <sinzui> tim_, deryck's squad have already done that
[14:53] <sinzui> tim_, the porject's +sharing page lets you set the blueprint sharing policy
[14:53] <tim_> sinzui, awesome
[14:53] <deryck> yup, just need to be in beta testers group.
[14:53] <tim_> I think I'm in that group
[14:54] <adeuring> jcsackett: could you please review this MP: https://code.launchpad.net/~adeuring/launchpad/product-lp-limitedview-2/+merge/133481 ?
[15:04] <rick_h> deryck: ping
[15:04] <deryck> rick_h, yo
[15:04] <rick_h> deryck: hey so wiring this into blueprints and noticing the fun part.
[15:05] <rick_h> so if the project is private we show the privacy banner
[15:05] <rick_h> and so when you go to create a new blueprint the privacy banner is already showing
[15:05] <jcsackett> adeuring: you got it.
[15:05] <rick_h> while the type shows public at the moment to start with
[15:05] <adeuring> jcsackett: thanks!
[15:05] <rick_h> have we talked about how we want banners to work in mixed cases?
[15:07] <deryck> rick_h, I think that's correct, right?  If you have a proprietary or embargoed project, the artifacts should be that by default anyway, which means we start with the banner.  right?
[15:08] <rick_h> right, maybe I've just got my self into a strange project setup state.
[15:09] <rick_h> ok, will double check the blueprints widget since it shold have defaulted to non-public since blueprints were configured in sharing to be proprietary only
[15:14] <deryck> rick_h, we may not be consistent in this yet, see bug 1076412 that I just filed.  But what you described sounds like what we expect.
[15:14] <_mup_> Bug #1076412: Proprietary projects should only allow proprietary policies on its artifacts <private-projects> <Launchpad itself:Triaged> < https://launchpad.net/bugs/1076412 >
[15:14] <rick_h> deryck: yea, I see what I did. I have a prop project and I setup in sharing to have blueprints that were public, but could be prop.
[15:14] <rick_h> deryck: so I just got thrown off when I saw the privacy banner, but the information type widget was defaulting to public
[15:45] <jcsackett> adeuring: r=me.
[15:52] <czajkowski> cjwatson: ello any idea when Bug 1071562  might get a look at ?
[15:52] <_mup_> Bug #1071562: UEFI signing failures cause binaries to be republished continuously <oops> <regression> <soyuz-publish> <Launchpad itself:Triaged> < https://launchpad.net/bugs/1071562 >
[15:57] <adeuring> jcsackett: thanks!
[15:57] <cjwatson> czajkowski: yeah, sorry - I plan to get to it tomorrow
[15:58] <czajkowski> cjwatson: excellent thanks colin
[16:01] <deryck> adeuring, I added a hangout to the calendar event for our call.
[16:01] <adeuring> deryck: coming...
[16:13] <benji> bac: sure; when will my new one be?
[16:13] <benji> pfft
[17:04] <jcsackett> sinzui (or anyone else) any idea where bzr branches go when pushed to lp://dev on the local filesystem?
[17:05] <jcsackett> abentley, you might know? ^
[17:53] <abentley> jcsackett: I think it's /var/tmp/bazaar.launchpad.dev/mirrors
[17:54] <abentley> jcsackett: it will be in a numbered subdirectory in there.
[17:55] <jcsackett> abentley: hrm. i looked there earlier i thought.
[17:55] <jcsackett> oh! i didn't check dotfiles.
[17:55] <jcsackett> just checked those in the cache...
[17:56] <abentley> jcsackett: The numbered subdirectories are derived from the hex representation of the branch db id.
[17:56] <jcsackett> abentley: ah, dig. thank you. :-)
[17:56] <abentley> jcsackett: np.
[18:01] <jcsackett> sinzui: i am running to my appt. shall i set you as OCR in the title?
[18:02] <jcsackett> sinzui: i'll review your branch as soon as i can.
[21:22] <jcsackett> sinzui: i am looking at your branch. i am a little confused about what's going on in line 62 of your diff.
[21:23]  * sinzui looks
[21:23] <jcsackett> sinzui: it looks like you call get_msg_ids_to_remove, which calls _get_msg_ids...; but then you call _get_msg_ids again on the return?
[21:24] <sinzui> Yes, by passing a subset of ids, the method will filter out those that became used inbetween transaction calls
[21:25] <sinzui> The list of ids is cached and it contains duplicates
[21:25] <jcsackett> ah, ok.
[21:25] <jcsackett> just making sure i was reading things right.
[21:25] <sinzui> Since the cache is can be invalid the moment we call commit() at the end of the loop, we need to ensure we still only have unused potmsgset ids
[21:26] <jcsackett> dig. r=me, sinzui.
[21:26] <sinzui> thank you
[21:37] <sinzui> jcsackett, do you have a few minutes to talk about this http://paste.ubuntu.com/1343678/
[21:37] <sinzui> its in regards to bug 872335
[21:37] <_mup_> Bug #872335: TypeError raised by rosetta-poimport.py script <lp-translations> <oops> <rosetta-imports> <Launchpad itself:Triaged> < https://launchpad.net/bugs/872335 >
[21:38] <czajkowski> sinzui: is it possible to have private project groups, never heard f them but am getting all sorts of unusal requests today
[21:38] <sinzui> no, we have no plans to make them since project groups are broken by design
[21:39] <czajkowski> nods
[21:39] <czajkowski> grand
[21:39] <sinzui> They don't work for organizations or communities
[21:39] <sinzui> We would remove them if we had time
[21:40] <czajkowski> sinzui: that might upset a lot of people
[21:40] <sinzui> They are upset now that they don't work
[21:41] <sinzui> Organisations cannot trust them since anyone can place their project into your group, and since s project cannot be in more than one group, communities cannot share and plane.
[21:42] <czajkowski> nods
[21:42] <czajkowski> logically it makes sense
[21:46] <lifeless> flacoste: o/
[22:13] <sinzui> StevenK, jcsackett: http://paste.ubuntu.com/1343678/
[22:27] <StevenK> sinzui: http://pastebin.ubuntu.com/1343825/


[14:17] <fbond> keesj: Sorry, which contradiction?
[15:28] <keesj> start on stopped rc2 RESULT=ok
[15:28] <keesj>  stop on runlevel [!2]
[15:30] <keesj> but I have simliar thing/problems.
[15:31] <keesj> I do emit sometimes from within the "script" method of command. but to prevent deadlocks I need to make ohter emits having a "emit --no-wait blabla"
[20:21] <fbond> keesj: Oh, that's not a contradiction... (rc2 runs at the beginning of runlevel 2 but the ends and runlevel 2 continues)


[05:53] <fo0bar> for bug 946067, am I responsible for changing the statuses back from Incomplete to Confirmed, once the the SRU prep is finished?
[05:57] <micahg> fo0bar: once it's ready for sponsorship, yes
[05:59] <fo0bar> micahg: ok, thanks
[06:00] <micahg> fo0bar: this looks fine for inclusion in precise final I think, unseeded universe doesn't freeze for about 48 more hours
[06:03] <micahg> although, I think I'd prefer an upstream blessed patch
[06:07] <fo0bar> micahg: it's actually patched upstream, but the debian maintainer for libsnmp-session-perl appears to be MIA.  I should probably poke the debian bug, and if that doesn't go anywhere, maybe get the MRTG maintainer to adopt it (since they're closely related)
[06:08] <micahg> ok, I was trying to link the upstream bug and am failing (will try again in a bit), let me go look at it
[06:08] <micahg> the upstream bug is stil open though
[06:09] <fo0bar> http://oss.oetiker.ch/mrtg-trac/ticket/45
[06:09] <fo0bar> closed/fixed
[06:09] <micahg> fo0bar: that's in mrtg's tree, not snmp-session :)
[06:10] <micahg> https://code.google.com/p/snmp-session/issues/detail?id=5
[06:10] <fo0bar> ahh oops, I was taking MRTG's word for it.  I probably should have actually checked to see if it really was fixed upstream :(
[06:11] <micahg> fo0bar: they probably use an in-tree version for their stuff
[06:11] <micahg> libsnmp-session-perl upstream seems pretty dead
[06:11] <fo0bar> ahh yes, you're right.  they do, but debian disables it in favor of libsnmp-session-perl
[06:11] <fo0bar> everything is horrible, hooray! ;)
[06:13] <micahg> that upstream is dead as well
[06:17] <micahg> fo0bar: since everyone seems to be stalled, I'll take the patch
[06:18] <fo0bar> micahg: thanks.  it's not the best situation, but I can probably push for some sort of decision to be made at the debian level by Q
[06:19] <micahg> fo0bar: any chacne you've tested the other reverse dependencies (cricket, iog, smokeping)
[06:19] <fo0bar> though I'm not too enthusiastic about it, since a similar situation happened a few weeks ago, and as a result I'm now the debian maintainer for digitemp
[06:19] <micahg> fo0bar: congrats :)
[06:20] <micahg> fo0bar: maybe you can get a new upstream in for Q and drop our diff :)
[06:21] <fo0bar> micahg: lamont tested the patch for cricket with success, but independent of me.  I don't think he's tested the debdiff in the patch, but since the debdiff is the patch + changelog, it's effectively confirmed
[06:21] <micahg> yeah, no worries about that, what about the other 2
[06:21] <fo0bar> I have not tested, I can probably get some setups going
[06:22]  * fo0bar has no idea what iog is, actually
[06:22] <fo0bar> ahh, yet another grapher
[06:23] <micahg> both have low popcon, I'm not going to worry too much
[06:23] <fo0bar> without a manpage, even
[06:24] <micahg> alright, let me get a test build going, then I'll sponsor
[06:24] <fo0bar> ok.  I'll check smokeping, since I've at least heard of that, but never used it
[06:27] <fo0bar> micahg: hope I get to see you at UDS :)
[06:27] <micahg> fo0bar: I should be there :)
[06:28] <fo0bar> I'm not an Ubuntu developer, and I won't be going for IS duties, but it's my first UDS and I'm only a 3 hour drive from oakland, so what the heck
[06:30] <micahg> fo0bar: cool, there are many other ways to help Ubuntu besides being a dev and there are quite a few people at UDS who are not Ubuntu devs
[06:30] <micahg> in fact most aren't :)
[06:30] <fo0bar> yep
[06:36] <micahg> fo0bar: thanks for the debdiff, it's uploaded, waiting approval from an archive admin (since the archive is frozen for final), I changed it back to the release pocket (since it's arch:all it doesn't need staging), and the version back to ubuntu1
[06:36] <fo0bar> micahg: smokeping's SNMP_Session functionality is limited to some specific use cases (Cisco and JunOS "pings", neither of which I have equipment set up for currently), and from grepping the code, neither use Socket6 before SNMP_Session (or at all), which is triggering the problem in mrtg and cricket.  I have confidence the fix will not affect smokeping
[06:37] <micahg> fo0bar: thanks for checking that out
[06:37] <fo0bar> micahg: excellent, thanks
[09:58] <micahg> laney: what's the trick to seeing if haskell uploads are featureful again?
[09:58] <Laney> read the diff :P
[09:59] <micahg>  73 files changed, 7603 insertions(+), 4494 deletions(-), I'd rather not...
[09:59] <Laney> which one is it?
[09:59] <micahg> threadscope
[09:59] <Laney> aha, well sadly I don't know of a trick
[10:01] <micahg> meh, let
[10:01] <micahg> let's hope fixes FTBFS + no rdeps is good enough
[10:01] <Laney> if it fixes that
[10:01] <Laney> then yes that sounds good to me
[10:02] <vibhav> debuild -S -sa
[10:02] <vibhav> oops
[10:02] <vibhav> sorry guys
[10:02] <micahg> laney: bug #986803, care for a quick approval?
[10:03] <Laney> yes sir
[10:03]  * micahg has a few others in teh queue as well
[10:03] <Laney> might look at the queue later
[10:04] <Laney> currently seeing about importing ubuntu description translations into udd
[10:05] <Laney> I also found out that you can fix gitit's build by commenting out that type signature and letting ghc infer the type instead, but haven't packaged that up (if anyone has the inclination to do so)
[10:26] <vibhav> Laney: sure
[11:40] <jtaylor> anyone want to upload ipython in debian so I can sync it? else I'll upload ubuntu only and wait for my dm powers to kick in
[11:40] <jtaylor> my sponsor has no time
[11:41] <Laney> did you ask d-python?
[11:43] <jtaylor> yes but there is no urgency there
[11:44] <Laney> there are ubuntuish python people :-)
[11:44] <jtaylor> who are also here :)
[11:45] <Laney> ._,
[12:11] <Laney> ScottK: would you care to look at bug #986772? It looks like it will require an archive admin.
[12:32] <vibhav> Is it nice to provide debdiff for sync requests?
[13:00] <cjwatson> Laney: why does that require an archive admin (other than maybe NEW processing after the sync)?
[13:36] <Laney> cjwatson: exactly for that
[13:36] <Laney> I didn't want to approve it this late without someone lined up to do it.
[13:38] <cjwatson> Laney: it'll be fine
[13:38] <cjwatson> NEW processing from syncs is easy
[13:40] <Laney> I know. I thought it prudent to ask in the final week though
[13:44] <cjwatson> Laney: you can pencil me in if that helps; if somebody else beats me, all to the good, but I'll make sure NEW is clear
[13:45] <Laney> cjwatson: Thanks. I'll try to get to it later.
[13:45] <Laney> Frittata first. Om nom nom.
[13:46]  * cjwatson is waiting for very slow builds
[13:46] <cjwatson> generally trying to clear outdate_all
[13:47] <cjwatson> I think I have fixes for qemu-linaro/powerpc and visualvm
[13:48] <cjwatson> and I know roughly what to do about libsignatures-perl
[13:48] <cjwatson> wagon has me a bit stumped at the moment
[13:49] <cjwatson> java--
[13:52] <vibhav> Is there any option for showing bugs fixed upstream excluding debian?
[13:57] <vibhav> If I fix a typo in a certain program, do I need to change the .pot file too?
[14:29] <jtaylor> last chance for an ipython sponsor to step up :)
[14:37] <jtaylor> and uploaded
[14:39] <Laney> it's reasonable to upload directly if it's urgent
[14:39] <Laney> just make sure to sync again when you can
[18:51] <micahg> jbicha: any comments before I sync bug 986800
[18:59] <jbicha> micahg: no, I couldn't figure out how to use rygel ;)
[18:59]  * micahg hasn't used it either, but it builds now :)