[01:14] <Geo> hi, does anyone know a good code snippet manager on ubuntu ?
[03:12] <robert_ancell> RAOF, what makes Vala code unreviewable for SRUs?
[03:13] <RAOF> robert_ancell: The only thing I see is the generated C code, and relatively small changes to the vala code make drastic changes to the C.
[03:13] <robert_ancell> RAOF, also, prepare for some serious convincing
[03:13] <robert_ancell> RAOF, Don't you just ignore the .c code?
[03:13] <RAOF> Do you even ship the vala code?
[03:14] <robert_ancell> RAOF, yes
[03:14] <RAOF> It's possible that I didn't notice that because the pages and pages of C.
[03:14] <robert_ancell> yeah, autotools is stupid and likes to ship the .c
[03:15] <robert_ancell> I did try a hack that mterry came up with to stop it doing that, but it's a bit dodgu
[03:15] <RAOF> Also, I was predisposed to reject it, as “rewrite feature X to prevent slowness caused by feature X” starts from a position of ‘that's probably not SRUable’ :)
[03:16] <robert_ancell> ah, unity-greeter doesn't ship the .c files. I'll copy that for new versions
[03:16] <RAOF> Yeah, please do so.
[03:16] <robert_ancell> RAOF, the slowness is critical (i.e. it easily becomes unusable after more than a page or using high res colour pages)
[03:16] <robert_ancell> RAOF, so the only real option is to disable the autosave or use the new version
[03:17] <robert_ancell> Given it's not a critical app and it's so broken I opted for the latter
[03:17] <RAOF> Deleting the file on clean exit doesn't resolve that?
[03:17] <robert_ancell> RAOF, no, it already does that
[03:17] <RAOF> Ok.
[03:19] <RAOF> So now you get to convince me that "all new shiny autosave code" is more appropriate than "disabling autosave" :)
[03:20] <robert_ancell> Well, it can't be worse than broken autosaving code?
[03:21]  * robert_ancell can't wait until we don't have to do SRU's anymore
[03:22] <robert_ancell> RAOF, the main reason I want the new autosave code is it will be a better experience for users
[03:22] <robert_ancell> And as the upstream, I'm happy to weather any problems that may arise from that
[03:23] <RAOF> Of course it can be worse than no autosaving code! It can *crash* :)
[03:24] <robert_ancell> The SANE drivers crash all the time, much more often than simple-scan. Which is why the autosave code is there
[03:24] <RAOF> What does the autosave do, anyway? I've never hit it (nor the problem, obviously)
[03:24] <RAOF> Ah, SANE.
[03:24] <robert_ancell> errors.ubuntu.com shows all the SANE errors
[03:24] <RAOF> Such a terrible name.
[03:24] <robert_ancell> The API isn't bad, it's just the awful implementations
[03:24] <robert_ancell> I found a char[7] code that reads from the *network* and doesn't have any bounds checking in a HP driver
[03:25] <RAOF> ...!
[03:26] <robert_ancell> it was getting "HTTP/1." before it crashes. Probably some proxy or something in the middle. It was expecting "n\r\n" where n is an integer
[03:27] <robert_ancell> RAOF, so, what's it going to be? How many beers will this cost?
[03:27] <RAOF> Let me have another look at the diff...
[03:34] <robert_ancell> bbl
[03:34] <RAOF> I particularly like the way Vala leaks the details of your development directory structure :)
[03:41] <RAOF> robert_ancell: That's a sizeable chunk of code :/
[04:21] <robert_ancell> RAOF, the autosaving?
[04:21] <pitti> Good morning
[04:33] <robert_ancell> Trevinho, all those u-g branches are good to land - feel free to push whenever you want
[04:33] <robert_ancell> I thought I'd got u-g setup with Jenkins, but apparently not
[04:33] <RAOF> robert_ancell: Yeah, the autosaving.
[04:34] <robert_ancell> RAOF, the delta or the module?
[04:35] <Trevinho> robert_ancell: ah, cool... thanks for the reviews...
[04:35] <Trevinho> robert_ancell: I was waiting for jenkins as well, but if it's not the case, should I proceed with manual merge?
[04:36] <RAOF> robert_ancell: The delta. Well, and the module :)
[04:37] <robert_ancell> Trevinho, yes, go for manual
[04:37] <Trevinho> robert_ancell: ok, perfect
[04:43] <robert_ancell> Trevinho, are you looking after u-g now?
[04:44] <Trevinho> robert_ancell: ehm, what you mean?
[04:44] <robert_ancell> Trevinho, I wondered if bregma had assigned it to you or you were just fixing the dialogs :)
[04:45] <Trevinho> robert_ancell: oh, no.. I did that by myself
[04:45] <Trevinho> robert_ancell: I think andyrock will work on the locker side
[04:45] <robert_ancell> ok, cool
[04:45] <Trevinho> screensaver I mean
[04:46] <Trevinho> I just saw your initial work and I put some efforts in improving it to match unity..
[04:49] <robert_ancell> Trevinho, much appreciated! I wasn't sure if I could get all those features in there
[04:50] <Trevinho> robert_ancell: me neither :) but I wanted to give a try, and see if everything was feasible without much time... and it was :)
[04:55] <robert_ancell> bye all
[09:00] <seb128> good morning desktopers!
[09:02] <seb128> oh,pitti is piloting
[09:02] <pitti> rroooooooarrrrrr!
[09:02] <seb128> ;-)
[09:02] <pitti> 52 -> 32 so far:)
[09:03] <seb128> pitti, I unsubscriber sponsors from https://code.launchpad.net/~timchen119/gnome-settings-daemon/gnome-settings-daemon.precise.lp1055874/+merge/194661 yesterday, but it still needs reviewing ... if you feel bored (not sure how well you know that part of the gsd code)
[09:03] <didrocks> seb128: he's exceeding mac2 at the moment, but still accelerating to mac3 :)
[09:03] <seb128> (I subscribed sponsors because I started having a look/it seemed a desktopish one)
[09:03] <didrocks> hey btw!
[09:03] <seb128> didrocks, good morning, and no I was not drinking, I was doing exercice, and by the time I was back seems like you left to drink :p
[09:04] <didrocks> seb128: ahah! ;)
[09:04] <seb128> didrocks, what's the bug btw?
[09:04] <didrocks> if you go to the g-c-c shorcuts panel
[09:04] <didrocks> you can't assign alt (alone) to anything anymore
[09:04] <didrocks> like "to show the HUD"
[09:05] <Laney> howdy
[09:05] <seb128> didrocks, I can...
[09:05] <seb128> didrocks, well, it writes "mod2+alt L" but that works (e.g "alt" opens the HUD)
[09:06] <didrocks> interesting, latest trusty, right?
[09:06] <seb128> didrocks, for desktop components, yes
[09:06] <didrocks> "disabled" here…
[09:06] <didrocks> Laney: hey! mind trying assigning alt to a shorcut in g-c-c?
[09:06] <seb128> Laney, good morning ;-)
[09:06] <Laney> haha
[09:08] <Laney> it goes to "disabled"
[09:10] <Laney> I think you can't have modifiers alone
[09:10] <Laney> isn't that known?
[09:10] <seb128> Laney, you can, we have a GTK patch for that case
[09:10] <Laney> like a known bug
[09:10] <seb128> and it's working for me
[09:10] <Laney> seems to be the case here
[09:10] <seb128> but didrocks has the same issue than you
[09:10] <Laney> unless it got lost in T?
[09:10] <seb128> wfm
[09:11] <Laney> hmm
[09:11] <seb128> but I'm running GTK 3.10 pre packages atm
[09:13] <Laney> want to share those?
[09:13] <Laney> can check if it gets fixed
[09:15] <seb128> Laney, well ... I've only a local build and it's i386, so don't bother, I'm downgrading GTK to see if that's fixed
[09:15] <seb128> Laney, https://code.launchpad.net/~ubuntu-desktop/gtk/ubuntugtk310 has the current version if you want to build it yourself
[09:15] <Laney> ok
[09:15] <seb128> Laney, https://code.launchpad.net/~larsu/gtk/3.10/+merge/194619 has some review comments/the list of bugs that need to be fixed before we upload to the ppa for more testing
[09:17] <darkxst> Laney, should jenkins automatically pick up the autopkgtests? (in gjs)
[09:17] <seb128> Laney, didrocks: wfm with gtk from trusty, so that's not this one either
[09:18] <Laney> darkxst: in theory, but it doesn't always work
[09:18] <Laney> darkxst: oh, that stuff might be down atm?
[09:19] <Laney> there's QA lab maintenance
[09:19] <darkxst> well gjs was in -proposed for more than a week, surely it should have picked it up then?
[09:20] <Laney> mmm
[09:20] <Laney> jibel: ^^^ is there a problem with adt job creation?
[09:23] <pitti> Laney: -ENODATACENTER
[09:23] <Laney> pitti: See darkxst's previous line
[09:23] <Laney> was around before that was true
[09:24] <pitti> darkxst: ah, was that the first version to introduce an autopkgtest?
[09:24] <Laney> yeah
[09:24] <Laney> ubuntu1 was
[09:24] <pitti> there's a known bug that the first upload isn't being tested
[09:24] <pitti> first upload to introduce a test ,that is
[09:25] <Laney> unrelated: looks like indicator-application libdbusmenu ubuntu-download manager are saucy > trusty
[09:28] <seb128> bah, something made my xorg unhappy
[09:28] <seb128> Laney, saucy > trusty, yeah, that's thanks to trusty autolanding not happening anymore for over a week and being blocked on a touch image to be green
[09:28] <seb128> I was pondering doing a pocket copy of those SRUs
[09:28] <Laney> mmm
[09:29] <seb128> but didrocks is going to be unhappy if I do that (or we need to merge the SRU changelog back in trunk which is a pain to do)
[09:29] <didrocks> seb128: I don't think that you blocked on touch image to be green
[09:29] <didrocks> are*
[09:30] <seb128> didrocks, I asked on -ci-eng on monday and somebody told me that there was no landing of things that are not helping the image to be back to green
[09:30] <didrocks> seb128: that's not what I wrote on the email
[09:30] <didrocks> but monday is not a week
[09:30] <seb128> didrocks, can we do a landing of indicator's stack today then?
[09:30] <didrocks> seb128: is the CI engine back?
[09:31] <seb128> dunno
[09:31] <didrocks>  I didn't see any email
[09:31] <seb128> didrocks, well, my "a week" is based on how long my u-s-s landing ask has been sitting without change in the landing ask table
[09:32] <didrocks> seb128: yeah, blocked first on autopilot 1.4
[09:32] <didrocks> seb128: you can thanks the QA team
[09:32] <didrocks> and then the CI went down
[09:32] <pitti> didrocks: no, CI isn't back
[09:32] <didrocks> not fair to blame on other things like "we are blocking for a green image"
[09:32] <seb128> didrocks, I'm not blaming anyone, but it feels like we are stucked atm to land stuff from the indicator stack in trusty
[09:33] <didrocks> seb128: right
[09:33] <didrocks> nothing we can do about it
[09:33] <didrocks> and clearly not blocked on a green image
[09:33] <Laney> could copy the packages
[09:33] <didrocks> is there any urgency to do that?
[09:33] <didrocks> is it blocking anything?
[09:33] <didrocks> are you going to merge back with the current info?
[09:33] <didrocks> exact*
[09:33] <didrocks> (knowing that the commit numbers don't match)
[09:34] <seb128> it's blocking high e-u-c-ranked segfaults fix to land
[09:34] <didrocks> if you can answer to "yes" for all of this, I'm fine
[09:34] <seb128> no
[09:34] <seb128> I'm not going to bother merging thing back, I'm just going to let those segfaults in and wait, no big deal
[09:34] <didrocks> ok then, no need for that discussion in the end :)
[09:34] <seb128> I just never though we would see a day with SRUs either to get it than uploads to unstable series
[09:35] <seb128> well, it's very frustrating to let know high visibility segfault in because our processes are so tedious
[09:35] <didrocks> we should maybe revisit the rule to block to unstable series in those circumstances
[09:35] <seb128> but yeah, sorry for the ranting
[09:35] <didrocks> oh come on
[09:35] <didrocks> don't start…
[09:35] <didrocks> sigh
[09:35] <didrocks> ok, back to the meeting that is delayed because of that discussion
[09:36] <jibel> Laney, hm, first trace of gjs in britney's logs are yesterday, nothing before that day. Has 1.38.1-0ubuntu1 been ever published?
[09:36] <Laney> jibel: in proposed, didn't migrate to release
[09:36] <Laney> because of ppc ftbfs
[09:36] <jibel> Laney, ok
[09:45] <didrocks> seb128: ev suggests that you talk with him directly about the CI shutdown
[09:46] <seb128> didrocks, I've no problem with the CI shutdown, it's maintenance and needed, I've a problem with the fact that we can't pocket copy good fixes from saucy-proposed to trusty (at least without having to then do manual merging of changelog hackery)
[09:47] <Laney> Those fixes are in trunk
[09:47] <didrocks> seb128: you can ignore if you do the landing yourself the changelog, remember?
[09:47] <Laney> You should be able to just override the changelog check
[09:48] <seb128> Laney, right, but we can't land trunk because of the CI (and because there are changes to use upstart for indicator that probably need a bit more thinking/testing for landing)
[09:48] <didrocks> Laney: you can
[09:48] <Laney> seb128: I just mean that the copy shouldn't create any work if the fixes are already in trunk
[09:48] <Laney> because they're not going to be lost
[09:49] <seb128> Laney, well, last time I did that I got sil2100 and cyphermox pinging me a few hours later to get the changelog of the copy merged back in trunk
[09:49] <seb128> which is not the end of the world, but it's annoying still
[09:50] <Laney> right, suggesting we could be more relaxed about that
[09:50] <didrocks> again, you can ignore the destination if you handle the landing
[09:50] <didrocks> but seems nobody reads
[09:50] <didrocks> anyway, continuing doing work, all the MP would have been done by the time we discussed it
[09:50] <Laney> it's quite hard to have discussions about this if people are touchy
[09:51] <seb128> Laney, yeah :/
[09:51] <seb128> didrocks, let's forgot about it and wait for the CI to be back (I don't want to have to handle the next landing of the indicator stack since there is an upstart-job transition in there that I didn't follow)
[09:51] <didrocks> ok, fine :)
[09:52] <seb128> ok, let's move on
[09:52] <seb128> didrocks, sorry about the discussion
[09:52] <didrocks> seb128: no worry, we'll be better tomorrow with the CI back (I hope :))
[09:53] <didrocks> seb128: we are trying to still spin images without results to dogfood if something horrible broke
[09:53] <didrocks> FYI
[09:53] <didrocks> (which totally destroyed ogra_'s week-end FYI ;))
[09:53] <Laney> Constructively, it'd make it easy for manual uploads (from the point of view of cu2d) if all uploaders could set some flag saying 'please overwrite this archive upload'
[09:53] <Laney> which the vanguard / whatever they're called doesn't need to care about
[09:53] <ogra_> didrocks, not that much though, i shared the pain with rsalveti
[09:53] <Laney> just happens at the next normal run
[09:54] <didrocks> Laney: you think the override should be in the upload?
[09:54] <didrocks> it means that the next commit can revert your fix
[09:54] <didrocks> ogra_: pairing pain
[09:54] <didrocks> :)
[09:54] <Laney> Not necessarily
[09:54] <ogra_> :)
[09:54] <diwic> larsu, seb128 hi
[09:54] <larsu> seb128: so diwic started implementing https://wiki.ubuntu.com/Sound#Handling_unknown_audio_jack_devices
[09:54] <didrocks> Laney: ok, in CI "new world", this will be accessible by all core dev in the system FYI
[09:55] <larsu> do you think g-s-d is the best place to have this? (a new plugin?)
[09:55] <diwic> larsu, at least implementation planning
[09:55] <seb128> diwic, hey
[09:55] <didrocks> to tell "please ignore v<foo>"
[09:55] <larsu> diwic: heh, ya
[09:55] <Laney> yeah
[09:55] <didrocks> like the hinting in britney
[09:55] <Laney> that's what I'm asking for
[09:55] <larsu> seb128: we were thinking indicator-sound first, bt that can't have a gtk dep anymore
[09:55] <Laney> so I can do an upload, handle it in trunk, and then flag cu2d to ignroe that
[09:55] <Laney> ignore the manual upload
[09:55] <didrocks> Laney: yeah, that's planned in the UI
[09:55] <Laney> so the pipe is unblocked as it were
[09:55] <Laney> nice
[09:56] <Laney> oh poop, webkitgtk migrated
[09:56] <Laney> without an arm64 build
[09:57] <diwic> seb128, what larsu said, do you think gnome-settings-daemon would be a good place for a "What did you plugin?"-dialog ?
[09:57] <seb128> Laney, it's a new package, it never built on that arch
[09:57] <Laney> yes but it makes binaries on arm64 outdated
[09:57] <Laney> the old webkit1 ones
[09:57] <diwic> seb128, and I've been asked to this for our pre-installs, which still ship with 12.04, so an SRU back to 12.04 will probably be necessary
[09:58] <seb128> didrocks, btw found back the "can't land stuff that don't help the image to be green", that was from ogra
[09:58] <seb128> nov. 08 14:28:45 <ogra_>        though the current word is, only stuff that improves the image to go gree on the dashboard is allowed to enter
[09:58] <didrocks> bad bad ogra_ :)
[09:58] <Laney> that's why I thought it would be stopped
[09:58] <didrocks> in my email, it was:
[09:58] <seb128> Laney, ok, dunno about that :/
[09:58] <Laney> well, it's probably a misunderstanding on my part
[09:58] <seb128> Laney, did we have webkitgtk ever building on arm64?
[09:58] <Laney> yes
[09:58] <didrocks>  Here is what I think we should do:
[09:58] <didrocks> 1. ubuntu-ui-toolkit should their backward compatibility issue and shipping that (I heard this is already under work)
[09:58] <didrocks> 2. balloons is going to coordinate the core apps team side (ubuntu-weather-app, ubuntu-terminal, ubuntu-rssreader, ubuntu-filemanager, calendar-app)
[09:58] <Laney> but now it's more complicated
[09:58] <didrocks> 3. bfiller is going to get his team fixing notes-app and mediaplayer-app. webbrowser-app will be fixed in image 15.
[09:58] <didrocks> Please until then, refrain from merging/releasing anything that can impact those component test results. We need to ensure we are progressing quickly.
[09:59] <didrocks> I don't think the indicators is going to impact ubuntu-ui-toolkit, not those apps
[09:59] <didrocks> nor*
[09:59] <ogra_> sorry !
[09:59] <Laney> the current series looks like it'll fix it though, so I guess we should take that
[09:59] <didrocks> ogra_: don't make the seb angry! :)
[09:59] <ogra_> didrocks, it was what i understood from the meeting ...
[09:59] <Laney> means taking a dev series which isn't the best, checking in #debian-gnome if it's going to be stable
[09:59] <seb128> Laney, define "current serie", please tell me it's not the GNOME 3.12 one
[09:59] <Laney> & test building
[09:59] <ogra_> (though that was before CI went down)
[09:59] <didrocks> ogra_: I think the written down part will help more ^
[09:59] <ogra_> k
[09:59] <seb128> didrocks, ogra_: ok, thanks for clarification
[10:00] <didrocks> FYI 1 and 3 are done
[10:00] <didrocks> so, only 2
[10:00] <didrocks> (and I don't think apart from the toolkit, anything will impact 2)
[10:01] <seb128> diwic, larsu: sorry, lot of discussions happening here atm, a bit difficult to keep track ... let me think
[10:01] <diwic> seb128, no worries
[10:02] <seb128> diwic, larsu: ideally any new code would be though with ubuntu-touch in mind, and g-s-d is not going to be available there ...
[10:02] <seb128> diwic, larsu: could we get the logic/detection in the indicator and have a separate UI or would that be too complex?
[10:03] <diwic> seb128, we don't want it on ubuntu touch for the foreseeable future
[10:04] <diwic> seb128, all phones can successfully distinguish between headphones and headsets AFAIK
[10:04] <seb128> diwic, why not? (keep in mind that touch is going to be our desktop after the coming LTS, we for sure don't want to regress that feature under unity8?)
[10:05] <seb128> diwic, touch->unity8 if that helps btw
[10:06] <larsu> seb128: would that mean that indicator-sound would need to show qml dialogs?
[10:06] <seb128> diwic, e.g the goal is to make sure new features are made with unity8 sessions in mind, which means either have the choice of the frontend or make easy to replace the GTK bits by Qt ones
[10:06] <larsu> hm, fair point.
[10:06] <seb128> larsu, ^ under unity8 it would make sense
[10:06] <seb128> no?
[10:07] <seb128> larsu, that's not something we need to focus on for the LTS
[10:07] <diwic> seb128, I've never even heard of unity8 sessions...seems I have some catching up to do
[10:07] <seb128> but if we write new code I would rather to have most of it re-usable
[10:07] <seb128> rather than having to throw it away and rewrite for unity8 in one cycle
[10:07] <seb128> diwic, larsu: does that make sense?
[10:08] <larsu> I agree, but not as long as we need to have it running on the current desktop
[10:08] <larsu> which is what I focussed on when thinking about this
[10:08] <seb128> right
[10:08] <larsu> we could have indicator-sound have the logic an hit a name up on the bus that activates an executable which shows the dialog
[10:08] <seb128> well my point is that it would be nice to do it in a way where the device detection would be in the backend
[10:08] <larsu> slightly cringeworthy...
[10:09] <diwic> I think most of the code here is actually dialog layout.
[10:09] <larsu> seb128: I don't think there's that much detection
[10:09] <seb128> ok
[10:09] <diwic> sure, there'll have to be something talking to pulseaudio too, I guess
[10:09] <larsu> it'll be more or less like "pulse, what kind of device is this? Ah, a shitty one. Show a dialog please"
[10:09] <seb128> how much work is that stuff?
[10:09] <larsu> diwic: correct me if I'm wrong^^
[10:10] <seb128> I would almost recommend doing it in the indicator with a Qt dialog
[10:10] <seb128> though I would prefer a GTK UI for unity7/the LTS
[10:10] <diwic> larsu, I think that anything that's not GUI wise can be directly in pulseaudio.
[10:10] <larsu> I'd be fine with having a separate executable though
[10:11] <diwic> larsu, so if the dialog is in a separate executable, maybe PA can fire that dialog rather than the indicator?
[10:11] <larsu> diwic: can it? I'm not too familiar with what you can do on pulse events
[10:12] <seb128> Laney, do you suggest taking the webkit matching GNOME 3.12? how sure are we that they are not going to make change that imply apps porting?
[10:12] <Laney> seb128: That's what I asked & pochu pinged kov about
[10:13] <Laney> Otherwise try to backport the arm64 porting patches which sounds hairy
[10:13] <diwic> larsu, well, PA modules can fire executables. I just wonder if that executable will have the right environment set etc for doing GUI stuff.
[10:14] <diwic> larsu, but PA does talk to X11 at least. Maybe that is enough to do GUI stuff as well?
[10:14] <seb128> Laney, another of those fun situations :/
[10:14] <Laney> yeah
[10:14] <Laney> hopefully we get the right answer
[10:15] <seb128> diwic, larsu: that dialog seems little enough code that it should be easy to redo a qt version next cycle if needed, so do whatever is easier (might be less work to do 2 frontends that to over-engineer it)
[10:15] <larsu> diwic: should be if it starts anything from inside the session. Is it smart enough to only start the executable when that type of device shows up?
[10:15] <diwic> larsu, seb128 and then we try to do as much logic as possible in PA, leaving only the dialog layout to the executable
[10:16] <seb128> +1
[10:16] <larsu> diwic: I wouldn't like a solution where pulse always starts that binary and the binary would need to find out whether to show the dialog or not. Seems wasteful on machines with proper audio hardware
[10:16] <larsu> diwic: yeah, that sounds good to me. (To be honest, that's my favorite solution so far)
[10:16] <diwic> larsu, no; I'll write the PA module so that it only fires the dialog if the dialog should actually be shown
[10:16] <larsu> diwic: awesome!
[10:17] <larsu> seb128: I totally agree. It's a window with five buttons and a checkbox
[10:17] <seb128> seems like a plan then
[10:17] <seb128> larsu, diwic: thanks ;-)
[10:18] <diwic> larsu, seb128 and the dialog result would be communicated back by...
[10:18] <larsu> diwic: couldn't the app just use pulse's api to switch device type?
[10:18] <diwic> larsu, sure, but then the dialog needs to connect to PA, which makes it more code in that app
[10:20] <diwic> larsu, I'm thinking maybe one could just communicate back through reading the exit code from the executable
[10:20] <larsu> diwic: right. I can't think of another clean solution though
[10:23] <Laney> seb128: btw, I think webkitgtk & webp need promoting to main
[10:23] <diwic> larsu, or reading stdout/stderr perhaps
[10:23] <seb128> Laney, oh, right, new source ... I'm on it
[10:23] <Laney> ty
[10:24] <larsu> diwic: I recommend against doing that. Is it really that much hassle to connect to pulse?
[10:24] <larsu> diwic: ad-hoc results on stdout sounds like a debugging nightmare down the line to me
[10:26] <diwic> larsu, it is a bit of hassle, but overcomable. Could you elaborate on why you think using stdout is bad? Are you afraid something else will output there too?
[10:34] <larsu> diwic: it sounds less robust to me, because now the pulse module must keep state about that application (to wait for it to return; and handle error cases)
[10:34] <larsu> ideally, it would just do this over dbus
[10:35] <larsu> that would also fix the case of me unplugging and replugging the cable while the dialog is up
[10:35] <larsu> so that we don't show two dialogs
[10:36] <larsu> (I mean using dbus would solve this)
[10:36] <seb128> Laney, did you look at merging epiphany-browser (just asking because you did webkit), if not don't worry about it, I started the other day (before noticing it needed the new webkit)
[10:36] <diwic> larsu, hmm, that's an interesting corner case. In that case the PA module should kill the dialog, in my scenario
[10:37] <larsu> diwic: in mine, it would simply activate the same name again on the bus, but since the dialog is already running and owning the name, nothing would happen
[10:37] <Laney> seb128: nope, not yet
[10:37] <larsu> diwic: I just feel like having state inside the pulse module and this weird interaction between the two might get cumbersome
[10:37] <seb128> Laney, ok, I'm going to do that one then
[10:38] <larsu> diwic: in all fairness, you don't have to do it my way. I'm just thinking out loud :)
[10:38] <diwic> larsu, you'll need to have some state inside the pulse module anyway - because you have the "remember my choice" checkbox, which is an interesting twist
[10:38] <larsu> diwic: can't that be a dconf key?
[10:39] <larsu> ah wait, pulse doesn't do dconf I guess?
[10:39] <larsu> but it must have some way to store configuration, no?
[10:40] <diwic> larsu, sure, it stores configuration
[10:41] <larsu> diwic: can that be set by the public API? (i.e., could the dialog set it?)
[10:42] <diwic> larsu, might require a protocol extension unfortunately - but I might have to do that anyway for sound settings
[10:44] <larsu> diwic: it occurs to me, if we're separating the logic from the ui anyway, we might as well do it in indicator-sound
[10:44] <larsu> diwic: it already has a gsettings schema. The dialog could just write into that
[10:45] <larsu> problem solved
[10:45] <larsu> the code for the dialog executable could even live inside the same source package
[10:50] <diwic> larsu, I'm thinking that maybe I should start writing the backend logic and then, in a first iteration, have PA fire up a zenity dialog. In next iteration, replace the zenity dialog with something that looks more like mpt's design. Upstream might even like the zenity version and accept it
[10:53] <larsu> diwic: sounds good to me :)
[10:54] <Laney> oh cool, gnome-online-accounts is already split in experimental
[10:54] <Laney> fatal++
[10:54] <diwic> larsu, seb128  ok, thanks for the chat. Seems like we come up with a different solution every time we talk about it :-)
[11:16] <seb128> mvo, hey, how are you?
[11:31] <Laney> xnox: feel free to mangle imagemagick
[11:31] <Laney> for webp
[11:32] <seb128> Laney, ok, so epiphany-browser depwait on arm64 due to webkit not building here ... do you think we should block migration on that? (or should we just delete the old arm64 epiphany-browser binary so it can migrate?)
[11:33] <Laney> Give me a bit to test build this current webkit
[11:35] <seb128> ok
[11:36] <Laney> btw I test built gtk and it hung in the testsuite, was giving errors about unavailable schemas too
[11:37] <Laney> probably should look at that list of issues before raising things ;-)
[11:39] <xnox> Laney: \o/
[11:40] <seb128> Laney, the schemas errors didn't fail the build here and I didn't get the hung
[11:41] <larsu> Laney: in which test? I thought I had gotten them all...
[11:42] <Laney> let me see if it saved a log
[11:42] <xnox> Laney: https://bugs.launchpad.net/ubuntu/+source/imagemagick/+bug/1117481/comments/3    ... and we moved webp into main =/
[11:42] <ubot2> Launchpad bug 1117481 in imagemagick (Ubuntu) "Imagemagick lacks support for webp" [Undecided,Opinion]
[11:42] <Laney> haha
[11:43] <seb128> xnox, hopefully we can move webkitgtk to universe once we have our own bindings...
[11:45] <xnox> Laney: then again https://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=imagemagick is not exactly stellar =)
[11:45] <xnox> seb128: while webp is in main, I'd take the opportunity.
[11:45] <Laney> mmm, I don't find many CVEs
[11:46] <seb128> chrisccoulson, hey, is there any way you could use your magical powers to see if https://bugs.launchpad.net/ubuntu/+source/firefox/+bug/1200272 is known upstream? I didn't find it in their bugzilla but I've a feeling bugzilla is not the place to check for that
[11:46] <ubot2> Launchpad bug 1200272 in firefox (Ubuntu) "firefox crashed with SIGSEGV" [Medium,Confirmed]
[11:47] <Laney> don't have a log for gtk, will need to rebuild
[11:56] <Laney> larsu: http://people.canonical.com/~laney/weird-things/gtk+3.0_3.10.2-0ubuntu1~local0_amd64.build
[11:56] <Laney> large file, don't open it in your browser
[11:57] <larsu> too late :D
[11:57] <Laney> heh
[11:58] <seb128> Laney, what's weird in it?
[11:58] <Laney> nothing
[11:59] <Laney> I can't remember why I called that directory weird-things
[11:59] <Laney> there was probably a good reason at the time
[11:59] <seb128> heh
[11:59] <larsu> ah, settings schemas again
[11:59] <Laney> oh yeah, they are kerrrrrrrrrrrazy
[11:59] <larsu> I'm guessing my patch simply doesn't install them right
[12:00] <larsu> I'll will have a more detailed look after lunch
[12:00] <seb128> larsu, Laney: debian workaround it in debian/rules if we want to copy that
[12:00] <seb128> they do
[12:00] <seb128> # So that gsettings can find the (uninstalled) gtk schemas
[12:00] <seb128> pre-build::
[12:00] <seb128>         mkdir -p debian/build/glib-2.0/schemas/
[12:00] <seb128>         cp gtk/org.gtk.* debian/build/glib-2.0/schemas/
[12:00] <seb128>         glib-compile-schemas debian/build/glib-2.0/schemas/
[12:00] <seb128> # So that gsettings can find the (uninstalled) gtk schemas
[12:00] <seb128> export XDG_DATA_DIRS=/usr/share:$(CURDIR)/debian/build
[12:00] <Laney> oh yeah, it's not a merge, right
[12:01] <larsu> seb128: ah thanks. I've tried fixing it in the build system: https://bugzilla.gnome.org/show_bug.cgi?id=711715
[12:01] <seb128> Laney, I looked at the diff between both though
[12:01] <ubot2> Gnome bug 711715 in general "gtk object tests: run under local environment" [Normal,New]
[12:01] <seb128> Laney, pochu went for the workaround and larsu was trying to get those fixed upstream so I was not sure if we should take the rules hacks
[12:01] <seb128> Laney, ^ see that bug
[12:01] <seb128> larsu, thanks, I saw it while reviewing your changes the other day ;-)
[12:02] <Laney> upstream would be ideal indeed
[12:03] <seb128> larsu, enjoy lunch ;-)
[12:03]  * seb128 should get something to eat as well
[12:49] <chrisccoulson> seb128, in a bit. we really should find a resolution for https://bugzilla.mozilla.org/show_bug.cgi?id=888840 though, so we can just send these back upstream again where people see them
[12:49] <ubot2> Mozilla bug 888840 in General "Crash reports from Ubuntu builds of Firefox beta are not listed in aggregations" [Normal,New]
[12:50] <chrisccoulson> i have about zero hours per week to spend on firefox atm ;)
[12:50] <seb128> chrisccoulson, :-(
[12:56] <ogra_> chrisccoulson, just hand it back to asac, managers have all that spare time, y'know ;)
[12:57] <chrisccoulson> lol
[12:57] <chrisccoulson> i don't think asac would like that ;)
[12:57] <ogra_> hehe
[12:57] <asac> thx :)
[12:58] <chrisccoulson> asac, CONGRATULATIONS. You just volunteered to be our new firefox maintainer :)
[12:58] <seb128> ogra_, well, I've been told asac is going to be active in the MIR review team again, that's a first step I guess ;-)
[12:58] <seb128> asac, thanks for helping on MIR reviews!
[12:58] <ogra_> lol
[12:58] <ogra_> yeah
[12:58] <chrisccoulson> here's a game. the next person to speak in this channel gets firefox
[12:59] <sabdfl> hey guys!
[12:59]  * Laney thinks about doing actions from now on, instead of speaking
[12:59] <chrisccoulson> lol
[12:59]  * Laney laughs
[12:59]  * ogra_ giggles
[13:08] <Sweetshark> pitti: the great pretender!
[13:09]  * pitti innocently bats his eyelashes
[13:09] <Sweetshark> ;)
[13:09]  * Laney has nick changes off so didn't see that it wasn't real :P
[13:10] <pitti> Laney: so have I, they are rather unnerving in public channels
[13:10] <pitti> "joe is now known as joe_at_the_loo", thank you, TMI
[13:10] <Laney> haha
[13:11] <Laney> 13/11 13:10:52   44 *: JOINS PARTS QUITS KICKS NICKS
[13:11] <ogra_> isnt the short form of at_the_loo actually _otp (out to pee) ?
[13:11] <Laney> a noise free IRC experience, but it does mean that you miss when people impersonate the big boss
[13:11] <pitti> ogra_: haha
[13:11] <ogra_> :)
[13:11] <pitti> TGIF (or actually, it isn't yet!)
[13:12] <pitti> proxy + NickServ FTW!
[13:12] <pitti> Laney: it would be much funnier doing that with pinging poettering in #systemd :)
[13:13] <Laney> :D
[13:13] <Laney> "Let's talk about job opportunities"
[13:14] <mlankhorst> Laney: actually i keep parts and kicks enabled, very few people part
[13:14] <mlankhorst> or get kicked :P
[13:15] <pitti> weechat has some intelligent mode where it only shows parts/joins of people that recently spoke
[13:15] <pitti> that filters out almost all the noise, but makes you aware that you are about to reply to someone who just talked and ran
[13:16] <Laney> clever
[13:16]  * Laney wonders why panel BDs on e-d-s
[13:16] <Laney> for the clock applet I guess
[13:17] <seb128> Laney, likely indeed
[13:17] <Laney> doing test rebuilds for that now
[13:18] <Laney> managed to make webkit build fail by running out of memory :|
[13:22] <asac> seb128: i am not even a core-dev :)
[13:23] <seb128> asac, https://launchpad.net/~ubuntu-mir/+members#active has you though
[13:23] <mlankhorst> it has me too :P
[13:24] <Laney> http://ubuntuone.com/7NFYjuZl0FCJf8rAr7ZR9R
[13:28] <seb128> Laney, ;-)
[13:28] <seb128> asac, ^ problem solved
[13:28] <pitti> desrt: so, I had to run last night; wrt. the sendsigs.omit stuff, should I just clean up my patch a bit and push, or do you want to rewrite that somehow? I can certainly change it to use g_file_set_contents or something similar, if that's more palatable
[13:31] <Sweetshark> heh, "I take an old version of a lib, monkey patch it and then inject the binary it on top of a newer version of a 10 million LOC (plus deps) project"  http://nabble.documentfoundation.org/Replacing-one-DLL-from-official-build-td4082935.html
[13:31] <Sweetshark> #whatcouldpossiblygowrong
[13:33] <Laney> Sweetshark: reminds me of https://github.com/abock/clutter-sharp/commit/3bb49743d89f0a3f8fb4b26208735589a2a2f2a1
[13:34] <Sweetshark> Laney: heh, nice.
[13:35] <asac> Laney: omg... did you hit the button for real>?
[13:35] <asac> ":)
[13:36]  * ogra_ makes a note to assign a bunch of MIRs  mlankhorst  and asac 
[13:36] <asac> i dont think he hit the button
[13:36] <Laney> asac: haha, no
[13:36] <asac> see
[13:37] <seb128> Laney, you should do it
[13:37] <seb128> ;-)
[13:38] <Laney> we have been expecting an email
[13:38] <ogra_> seb128, ++
[13:38] <ogra_> all of ubuntu touch will have to go to main this cycle ... the MIR team definitely needs asac and mlankhorst
[13:38] <seb128> asac, joke aside, MIR team is understaffed seing the number of touch component that are going to be reviewed, you are sure you don't have free slot to help there?
[13:39] <ogra_> heh, snap
[13:39] <seb128> asac, if you don't you are going to hit the issue from a management side and need to find manpower to do reviews before it blocks things for touch
[13:40] <asac> ogra_: i really cant do it... really. if i do that i will drop the balls on many other things wehere i shouldnt do it
[13:40] <asac> seb128: who sets the standards for MIR?
[13:40]  * asac will chat about that with core leads today
[13:41] <ogra_> a wikipage that was designed over the years
[13:41] <seb128> asac, https://wiki.ubuntu.com/MainInclusionProcess
[13:41] <ogra_> https://wiki.ubuntu.com/UbuntuMainInclusionRequirements
[13:41] <asac> well. lets take a step back... the MIR team is basically delegated to commit canonical to support them, correct?
[13:41] <seb128> ogra_, snap :p
[13:41] <asac> err
[13:41] <ogra_> :)
[13:42] <asac> MIR is a delegate entitled to commit on behalf of canonical that we will support it with our paid engineering force
[13:42] <asac> or not?
[13:42] <ogra_> yes
[13:42] <seb128> asac, well, the MIR team is just made of trusted people doing review to ack that those source are maintainable
[13:42] <seb128> not sure if that's Canonical supported
[13:43] <seb128> I though we only supported a subset of main?
[13:43] <asac> important difference
[13:43] <asac> i will check with steve/colin today on my call
[13:43] <mdeslaur> seb128: we support all of main
[13:43] <seb128> you better talk to slangasek or cjwatson
[13:43] <seb128> right
[13:44] <seb128> mdeslaur, what was the archive reorg about then?
[13:44] <seb128> mdeslaur, do we support everything at the same level?
[13:44] <asac> mdeslaur: why do we not just auto approve everything that comes from our own engineering teams and rather fight the "quality of code/maintainability" at a different level?
[13:44] <mdeslaur> seb128: we want to be able to not support everything at the same level
[13:44] <asac> e.g. imo its wrong to put something in place that does a final review if we want to support software that we have put manyears of development into :)
[13:44] <pitti> because we at least need to do a check for dependencies in main, and some packaging/security check
[13:45] <mdeslaur> asac: because the mir process is where we audit the security saneness of code and is where we discover issues
[13:45] <mdeslaur> asac: also, our stuff tends to pull in massive amounts to dependencies which we don't control
[13:45] <mdeslaur> asac: so we need to make a decision on those dependencies also
[13:45] <asac> mdeslaur: yeah. so in general i think it makes sense to have a check for "3rd party software"
[13:45] <asac> for our software if its just about dependencies, this should be automatically done continuously elsewhere ...
[13:46] <asac> e.g. before the damage is done
[13:46] <ogra_> asac, what prevents us from doing bad stuff in non third party SW ?
[13:46] <mdeslaur> asac: yes, that would be nice :)
[13:46] <ogra_> even our own packages will have issues that will only be discovered by peer reviews of MIR and security people
[13:46] <jdstrand> fyi, the archive reorg is still incomplete akaik
[13:47] <asac> ogra_: nothing, but we have many other places where we should put such quality control in place
[13:47] <ogra_> asac, it is also about packaging quality etc
[13:47] <asac> instead of creating this big bottleneck
[13:47] <asac> every core dev should be able to produce good enough packaging quality, no?
[13:47] <ogra_> asac, i.e. imagine the unity team wants to be clever and switches the packages to cdbs ...
[13:47] <mdeslaur> asac: so this is where, in the process, that it's decided that stuff is good enough to officially say we're going to support it
[13:47] <jdstrand> much of what is requested for main is not core-dev
[13:47] <asac> ogra_: every packaging change gest reviewd by core-devs
[13:47] <asac> as part of CI already
[13:48] <asac> we just have to tell them what rules to apply
[13:48] <ogra_> asac, and ? being core-dev wont make you errorproof
[13:48] <mdeslaur> asac: there's no sense in doing a security audit of v 0.0.1 of something when none of that code remains once we hit a version that's ready
[13:48] <seb128> asac, well, even core dev make errors, that's the same reason we have NEW review before entering the archive
[13:48] <ogra_> ++
[13:48] <asac> seb128: sure, but for that we can establish a more scalable peer review system
[13:48] <seb128> yeah, that would work
[13:48] <seb128> we need reviews somewhere
[13:48] <asac> e.g. if you want to go for main, find 1 or two other core devs that +1 your packaging
[13:49] <ogra_> in fact NEW and MIR are largely the same, just that NEW is a lot looser
[13:49] <seb128> I don't care much where they happen/how we call the team doing those
[13:49] <jdstrand> actually, MIR assumes NEW has happened usually
[13:49] <ogra_> indeed
[13:49] <ogra_> but their processes are similar
[13:49] <seb128> asac, well, except that most packagers don't care/are not careful about e.g licenses compatibility
[13:50] <seb128> asac, we often caught errors in NEW from coredevs there
[13:50] <jdstrand> NEW deals with suitability for the archive. MIR deals with supportability primarily
[13:50] <jdstrand> (there is of course overlap)
[13:50] <asac> for me everything that we have in CI is supportable :)
[13:50] <ogra_> jdstrand, right, a new review system could offer both though ... just with more stricter rules for MIR
[13:50] <mdeslaur> asac: oh geez, no :)
[13:51] <asac> mdeslaur: why not? we have developed it, we will support it
[13:51] <mdeslaur> asac: you wouldn't believe the security state of dependencies in universe
[13:51] <jdstrand> but NEW doesn't care about security reviews and testsuites and bug subscribers for example. and MIR isn't looking at licensing unless it is in multiverse or restricted already
[13:51] <ogra_> asac, what does CI do to prevent code backdoors being introduced ?
[13:51] <asac> mdeslaur: ok its about new dependencies not in CI
[13:51] <asac> thats beter and might reduce the set of things that need thorough review
[13:51] <mdeslaur> asac: again, it's not really the canonical developed stuff that is the usual bottleneck, it's the cascade dependencies
[13:52] <ogra_> (or code that obviously does silly things)
[13:52] <asac> ogra_: if people introduce backdoors in our upstream code base we have a bigger problem :)
[13:52] <ogra_> (which only a security person might recognize)
[13:52] <asac> and MIR is probably the wrong place to solve that :)
[13:52] <asac> rather random security audits of random trees
[13:52] <mdeslaur> wow, it would be nice to have the manpower to do that :)
[13:52] <ogra_> well, i just want to know what makes CI so much more trustworthy
[13:53] <jdstrand> asac: backdoors> it is a different problem yes. cause once a MIR is ack'd there are no more security reviews
[13:53] <asac> right
[13:53] <asac> lets not mix things up :)
[13:53] <jdstrand> but, the MIR security audit is valuable
[13:53] <ogra_> ++
[13:53] <jdstrand> if done at the right time. it is not hugely valuable if done too early and everything is rewritten in a month
[13:53] <asac> jdstrand: right. but the value can probably also be created outside a bottleneck :)
[13:54] <asac> actually should
[13:54] <jdstrand> we find more security issues in our own stuff than in dependencies needing to move to main tbh
[13:54] <ogra_> well, watever system you use, you need humans to do the actual audit in the end
[13:54] <asac> i really what you really want is a scheduling of security audits that happens exactly once
[13:54] <ogra_> which iis your bottleneck
[13:54] <asac> doesnt need to be hooked up to the MIR bottleneck
[13:54] <ogra_> asac, but code changes ...
[13:54] <mdeslaur> so you want two bottlenecks? :)
[13:55] <asac> no
[13:55] <jdstrand> there are two reasons for that: a) because Canonical is on the hook and we have no other upstream help, we look harder and b) the code is newer
[13:55] <ogra_> so security holes might be introduced later again
[13:56] <mdeslaur> also, this is the point at which the teams in question have an incentive to fix the issues we find :P
[13:56] <asac> ogra_: right. hence the MIR security audit thing doesnt really help much. I think the main value is to really look at random code regularly and then educate upstreams about wrong pattenrs etc.
[13:56] <ogra_> the MIR audit is at least a stop gap so we know when a package enters the supported set it is good
[13:56] <mdeslaur> asac: I disagree, this is the point at which we software is at a point where it's relatively stable, at which point the security audit is an important part of the process
[13:56] <ogra_> we should definitely have more and regular audits
[13:56] <jdstrand> I might also point out that if something is a 'must have' for main, we've said "go ahead, we'll do the security review later, but please address any security concerns if we find them"
[13:57] <ogra_> but that will require more security staff
[13:57] <jdstrand> this happened with mir for example. we knew we wanted to take a long look at it
[13:57] <jdstrand> we should have more regular audits
[13:57] <asac> jdstrand: rihght. thats more like the model i have ... a decoupled audit
[13:57] <jdstrand> we can't do it now
[13:57] <asac> that you can handle with continous flat load
[13:57] <asac> if you block on this you get those awful peaks
[13:58] <asac> which you cant measure and hence you cant argue for staffing
[13:58] <ogra_> but you need to do an audit when it enters supported
[13:58] <ogra_> or at least one thats tied to the entering
[13:58] <asac> if everyone agrees that everythging needs to have 1 audit per year and you run that with constant load, then you can easily measure the overload and staff accordingly
[13:58] <jdstrand> asac: there is a problem with that in the general sense though. if it is already in main, there is less incentive to fix it. I could pull out bugs from various teams that are still open
[13:58] <mdeslaur> we'll end up supporting something that may have a serious design flaw, and we'll need to support it for 5 years without the major changes required to fix it
[13:58] <jdstrand> we can't do 1 audit per year
[13:58] <asac> jdstrand: this again is a separate problem
[13:58] <jdstrand> there are thousands of packages in main
[13:59] <ogra_> details :P
[13:59] <mdeslaur> getting rid of the mir process isn't going to magically fix the mir team staffing issues, it just makes the whole process go away
[14:00] <ogra_> which wont help the quality
[14:00] <mdeslaur> then we'll end up shipping stuff with design flaws and major security issues
[14:00] <mdeslaur> and libraries where upstream has stopped development years ago and which contain security flaws
[14:01] <mdeslaur> and we'll end up with 15 javascript engines to support :)
[14:01] <jdstrand> 1219164, 1226569, 1230091, 1236912
[14:01] <jdstrand> those are from this cycle. I could find more
[14:02] <jdstrand> I acknowledge there are problems
[14:02] <asac> let me think a bit
[14:03] <jdstrand> archive reorg is not done yet and build-deps (ie, non-runtime) are still requiring support
[14:03] <jdstrand> so there is a ton of effort spent on sorting out build dependencies, when we should only be caring about runtime dependencies
[14:04] <jdstrand> if we sorted that out, there would be much less wasted time for the developers and the reviewers
[14:05] <mdeslaur> yes, a large quantity of MIRs are for build depends which aren't important
[14:05] <mdeslaur> that would definitely lighten the load for the mir team
[14:05] <jdstrand> I'm hoping that after application/webapps/scopes confinement (ie, anything we ship in the appstore) works on converged, then my team will be able to be more proactive with audits. but that is several cycles away
[14:07] <jdstrand> I don't know that we have to mandate a certain number of audits a year or anything. I do think a security audit for sensitive things going in to main is useful. every major project we develop that has run across our desks has benefited from that review
[14:07] <jdstrand> especially because the code is so new
[14:08] <mdeslaur> it's not as if most get though without changes
[14:09] <jdstrand> yes-- when they do, it is usually due to an established piece of software that has had years of production use and an active upstream
[14:09] <mdeslaur> yep
[14:12] <mdeslaur> one of the criteria to having the process successful is to not have a conflict of interest between the developers wanting the package in main and the team reviewing it
[14:14] <jdstrand> also, I think if we are seriously considering finishing archive reorg, then we need to weigh the cost of that work and the distraction against the actual pain felt. I'm not sure where the scale will tip to be honest-- there is a lot of development effort spent on sorting out build-dep MIRs or their avoidance
[14:15] <jdstrand> but the people doing the reorg would not be able to do their important work
[14:15] <jdstrand> (which is why we are still where we are)
[14:29] <desrt> pitti: i was going to do it myself but if you want to do it i'd recommend the following:
[14:29] <desrt> 1) use g_file_set_contents()
[14:30] <desrt> 2) do it just before the call to shutdown/reboot and don't bother with the unlink
[14:31] <pitti> desrt: makes sense, yes
[14:35] <desrt> pitti: so i'm happy to do it, but if you want to, you can :)
[14:38] <pitti> desrt: might just as well finish this up myself now :)
[14:39] <pitti> desrt: btw, did you put the 4 tarball anywhere? the debian/watch address disappeared, so I just ran make dist myself
[14:39] <desrt> pitti: i forgot that i was publishing tarballs before :)
[14:39] <desrt> i'll do a 5 release after this fix
[14:39] <desrt> lemme guess; was at ~ryanl?
[14:40] <pitti> desrt: yes
[14:40] <desrt> my gnome account got renamed to 'desrt'
[14:40] <pitti> aah
[14:40] <desrt> (finally)
[14:41] <pitti> so let's put the 5 tarball there once that bug gets fixed
[14:41] <pitti> I'll update debian/copyright and watch next time
[14:52] <didrocks> jdstrand: btw, if you have critical bugs on components we are upstream for, you can just signal them to me and we can block their release until it's fixed
[14:52] <didrocks> jdstrand: this will be a good incentive :)
[14:53] <jdstrand> ack, thanks
[15:06] <seb128> jdstrand, did you see my ping about telepathy-mission-control yesterday?
[15:06] <Laney> kenvandine: robru: Just noticed that friends fails to build in trusty :(
[15:07] <kenvandine> again?
[15:09] <Laney> kenvandine: http://people.canonical.com/~laney/weird-things/friends_0.2.0+14.04.20131108.1-0ubuntu1_amd64-20131113-1343.build.gz
[15:10] <jdstrand> seb128: I did not
[15:13] <seb128> 	jdstrand, hey, I want to update telepathy-mission-control-5 to the current stable serie (5.16) ... is that something you started on/are interested doing (I guess not)? if not, how do you usually test that the apparmor profile needs tweak? just running empathy&co and checking that everything work/the logs have no DENY?
[15:13] <kenvandine> Laney, thanks... i wonder if there are GI changes that broke libaccounts
[15:16] <Laney> kenvandine: hmm, looks like the build in trusty built against libaccounts-glib (and other things) from the PPA which isn't in T yet
[15:17] <kenvandine> «BUILDDIR»/friends-0.2.0+14.04.20131108.1/friends/utils/authentication.py:39: Warning: Custom constructor for class AgManager returned NULL (which is invalid).  Unable to remove object from construction_objects list, so memory was probably just leaked.  Please use GInitable instead.
[15:19] <jdstrand> seb128: I've not done a merge on it. If I were, I would just test it in empathy, yes
[15:20] <seb128> jdstrand, ok, do you want me to steal the merge/update from you? ;-)
[15:20] <jdstrand> seb128: please feel free- I am behind on merges atm
[15:21] <seb128> jdstrand, ok, I'm doing that one then, thanks ;-)
[15:21] <jdstrand> seb128: I'm on trusty already if you want me to help test. thanks!
[15:21] <seb128> jdstrand, ok, I might give you a ping for a round of testing once I've the update ready, thanks
[15:40] <Sweetshark> anyone knows by chance if/why/how much debians git hosting is down?
[15:41] <happyaron> Sweetshark: http://lists.debian.org/debian-infrastructure-announce/2013/11/msg00001.html
[15:42] <seb128> hum
[15:43] <seb128> Laney, https://launchpadlibrarian.net/156496401/buildlog_ubuntu-trusty-i386.empathy_3.8.5-0ubuntu1_FAILEDTOBUILD.txt.gz
[15:43] <seb128> Laney,  libwebkitgtk-3.0-dev : Depends: libwebkitgtk-common-dev (= 2.2.1-2ubuntu2) but it is not installable
[15:43] <seb128> Laney, is that expect/a known issue?
[15:43] <Laney> no
[15:43] <seb128> wait, let me guess, I didn't promote some of the binaries I guess
[15:43] <Laney> is that in main?
[15:43] <Laney> ;-)
[15:43] <seb128> Laney, empathy? yes
[15:43] <Laney> the package it is complaining about
[15:44] <seb128> Laney, it's empathy (cf the build log)
[15:44] <Sweetshark> happyaron:thanks
[15:44] <Laney> no, it's complaining about libwebkitgtk-common-dev
[15:44] <Laney> libwebkitgtk-common-dev | 2.2.1-2ubuntu2 | trusty/universe | amd64, armhf, i386, powerpc
[15:44] <seb128> Laney, right, as said I missed some binaries earlier, fixing it
[15:44]  * Laney nod
[15:44] <seb128> Laney, I wish there was a command to tell "promote only the binaries that are useful in main"
[16:40] <Laney> SSSSSSSSssooooooooooooooooooo
[16:40] <Laney> why do we still have evolution-indicator?
[16:46] <Laney> ah, well, the port was easy
[16:46] <Laney> it lives to die another day
[16:47] <davmor2> Laney: incase someone install evolution :)
[16:48] <seb128> Laney, because without it we wouldn't have messaging menu integration
[16:48] <Laney> I see, it's not providing its own indicator
[16:51] <seb128> no
[16:51] <seb128> why would it?
[16:51] <seb128> messages go in the messaging menu ;-)
[16:51] <Laney> it's called evolution-indicator
[16:51] <Laney> not evolution-messaging-menu
[16:51] <seb128> yeah, the name is misleading
[16:51] <Laney> sounded like some crufty thing
[16:51] <seb128> it's like telepathy-indicator
[16:53] <Laney> alright
[16:53] <Laney> well, we should start using the upstream project again then ;-)
[16:55] <Laney> Okay, everything apart from friends is built for new e-d-s
[17:15] <pitti> seb128: uploading g-icon-theme 3.10, FTR
[17:15] <seb128> pitti, danke!
[17:15] <pitti> so that and g-i-t-symbolic should become installable again, and thus deja-dup's test should be back to green soon
[17:16] <seb128> pitti, there is a new gvfs out if you feel like doing another desktop update this week btw ;-)
[17:16] <pitti> mterry: ^
[17:16] <pitti> if we ever get back our DC, that is :)
[17:22] <pitti> seb128: not today any more, but I'll keep it in mind
[17:22] <seb128> pitti, yeah, no hurry, thanks ;-)
[17:22] <asac> pitti: which systems do you miss the most in the DC?
[17:22] <seb128> I might get to it, but I've a bunch of others one on my list before
[17:22] <seb128> larsu, btw how is GTK going?
[17:22] <asac> pitti: please let ev know which ones we should prioritize to come back first for you
[17:24] <pitti> asac: autopkgtest (aldebaran, alderamin, wazn, and albali), as we currently promote packages into ubuntu wihtout checks
[17:24] <pitti> asac: and the upstream merge proposal machines
[17:24] <pitti> asac: so I guess "half the DC" :)
[17:24] <asac> pitti: any subset of the autopkttest infrastructure that would be helpful in the first batch?
[17:24] <asac> pitti: or is it an either all or nothing thing?
[17:25] <pitti> asac: we need at least one slave (one of these four), and 10.189.74.2 for the jenkins controller, I suppose
[17:25] <mterry> pitti, ah thanks!  I was wondering why deja-dup was failing
[17:25] <pitti> mterry: it's in the log, it can't install gnome-icon-theme
[17:26] <mterry> pitti, I saw the log, but couldn't see which specific package was at fault.  And I was able to install things locally, so I was confused
[17:26] <pitti> mterry: it runs with proposed enabled
[17:26] <mterry> pitti, ah fair.  I forgot that
[17:27] <pitti> mterry: see http://people.canonical.com/~ubuntu-archive/testing/trusty-proposed_probs.html
[17:27] <pitti> that has the deja-dup install error
[17:37] <robru> Laney, hmmm, neither ken nor I can reproduce that friends failure locally.
[17:37] <Laney> I just used a clean schroot
[17:38] <Laney> let me upload to a PPA
[17:38] <robru> Laney, I confirmed I had the same version of libaccounts-glib mentioned in that build log...
[17:48] <asac> seb128: the latest X makes my system be crashy
[17:49] <asac>  6209.979215] [drm] stuck on render ring
[17:49] <asac> [ 6209.979217] [drm] capturing error event; look for more information in /sys/class/drm/card0/error
[17:49] <asac> [ 6209.989170] [drm:i915_set_reset_status] *ERROR* render ring hung inside bo (0x30386000 ctx 1) at 0x303861d8
[17:49] <asac> [ 6209.989194] [drm:i915_set_reset_status] *ERROR* render ring hung flushing bo (0x2d633000 ctx 0) at 0x303861d8
[17:49] <asac> second time my system frooze today
[17:49] <asac> err first time it was a hard reset
[17:49] <asac> this time the X session froze
[17:49] <asac> seb128: who is doing X?
[17:49] <seb128> asac, mlankhorst
[17:49] <asac> mlankhorst: ^
[17:49] <seb128> asac, we didn't get a new xorg/intel driver though
[17:49] <seb128> asac, did you get a new kernel?
[17:49] <asac> what shall i do? ubuntu-bug xort?
[17:50] <asac> seb128: thats odd ... it was rock solid until today when i got a hard reset
[17:50] <seb128> could be https://launchpad.net/ubuntu/trusty/+source/libdrm/2.4.46-4 I guess
[17:50] <asac> seb128: maybe just coincident
[17:50] <seb128> though that seems for nvidia cards
[17:50] <seb128> asac, what did you update today?
[17:50] <seb128> dpkg.log should tell you
[17:51] <asac> http://paste.ubuntu.com/6411824/
[17:51] <asac> thats the package update log from yesterday and today
[17:51] <asac> (term.log)
[17:52] <asac> grub triggered new initramfs updates
[17:52] <asac> Setting up xserver-xorg-glamoregl:i386 (0.5.1-0ubuntu4.1) ...
[17:52] <asac> not sure what that is
[17:52] <seb128> that's for nvidia cards/nouveau IIRC
[17:53] <seb128> but your log suggest you are on intel
[17:53] <asac> yeah its a nice x220 :)
[17:53] <asac> thinki
[17:53] <asac> so today my USB ports started to power off etc.
[17:53] <asac> and i get freezes/crashes
[17:54] <seb128> when did you get a kernel update?
[17:54] <asac> seb128: do you know how i can figure when i last rebooted?
[17:54] <asac> maybe i had a new kernel ages ago and never rebooted
[17:54] <asac> is there like a "reboot" log?
[17:55] <Laney> robru: did you try building friends in a clean chroot?
[17:56] <seb128> asac, "uptime"?
[17:56] <robru> Laney, no. should i try it in pbuilder?
[17:56] <Laney> robru: yeah, see if it happens tehre
[17:56] <asac> seb128: well, i surely rebooted after the hard crash :)
[17:56] <Laney> if not I've just done it on a canonistack instance that you can have access to
[17:56] <asac> because it just resetted
[17:56] <asac> i wonder how long i didnt do that before though so i can find the kernel update
[17:57] <robru> Laney, bah, gonna take a minute to update my pbuilder image
[17:58] <seb128> asac, grep "/proc/kmsg started" /var/log/syslog*
[17:58] <seb128> seems like that would do it
[17:59] <asac> seb128: had to use zgrep :)... otherwise just one result
[17:59] <Laney> robru: Ah, the messages from libaccounts-glib were correct
[18:00] <asac> seems before the hard reset i rebooted on nov 8
[18:00] <Laney> robru: Try building with HOME=/something/that/doesnt/exist
[18:00] <Laney> well, running the testsuite I guess
[18:00] <asac> seb128: i got a new kernel on nov 12
[18:00] <robru> Laney,
[18:00] <robru> Laney, ahhh
[18:00] <asac> Preparing to replace linux-image-3.12.0-2-generic 3.12.0-2.5 (using .../linux-image-3.12.0-2-generic_3.12.0-2.7_i386.deb) ...
[18:00] <asac> Done.
[18:00] <asac> seb128: you think that doesnt touch intel drivers?
[18:00] <Laney> I'd try the old kernel and see if it goes away
[18:01] <seb128> asac, I would blame the kernel
[18:01] <seb128> asac, try booting the previous one
[18:01] <asac> i cant reproduce easily :)
[18:01] <asac> just happens every few hours
[18:01] <asac> so yeah i can go back, but then i cant get infos for ogasawara
[18:01] <seb128> well, boot the previous one and see if you are still happy in a few days
[18:02] <seb128> ok, keep running the new one and ask the kernel team what infos they need maybe?
[18:02] <asac> ok i got the USB port powering down problem again
[18:02] <asac> running ubuntu-bug linux
[18:03] <seb128> shrug
[18:03] <seb128> "dpkg-shlibdeps: error: no dependency information found for debian/empathy/usr/lib/empathy/libempathy-3.8.5.so (used by debian/nautilus-sendto-empathy/usr/lib/nautilus-sendto/plugins/libnstempathy.so)"
[18:03] <seb128> what's going on there
[18:04] <asac> recently i was ranting about windows requiring you to install mouse drivers because their "default" usb stack seems flaky
[18:04] <asac> now we have a broken USB too :)
[18:04] <asac> lol
[18:04] <asac> never had that for ages
[18:05]  * Laney waves
[18:05] <Laney> uploaded webkit & blocked it in proposed for some more manual testing
[18:05] <Laney> see you tomorrow
[18:10]  * asac on 3.11 kernel now
[18:10] <asac> so far pretty good stuff
[18:10] <asac> :)
[18:10] <mlankhorst> back :P
[18:11] <mlankhorst> pinging me after EOD is not guaranteed to give a reply
[18:11] <mlankhorst> but looks like a kernel issue
[18:11] <asac> mlankhorst: dont worry. i am fully aware about the hit/miss ratio on IRC :)
[18:12] <asac> in reality its much better than email though :)
[18:12] <asac> hehe
[18:23] <robru> Laney, looks fine in pbuilder. you were saying $HOME needs to not exist?
[18:24] <robru> Laney, i'm not sure how to override $HOME inside pbuilder. pbuilder fails to even start if I do it the obvious way.
[18:40] <robru> Laney, kenvandine wants to know in what kind of build environment you found this bug
[18:40] <kenvandine> reading back he said in a clean schroot
[18:40] <kenvandine> Laney, did you try in a PPA?
[19:38] <mfisch> Is there a tool I can use to see where the icons I specify come from, as in the order?
[19:38] <mfisch> Something like fc-list but for icons
[19:39] <mfisch> I specify "Foo" and it's finding Foo in ~ rather than /usr/share/icons, and I'm curious why
[19:44] <seb128> mfisch, wget https://launchpad.net/icon-library/trunk/lucid-release/+download/iconlibrary02052010.tar.gz; tar xvf iconlibrary02052010.tar.gz; cd iconlibrary; ./icon-library.py
[19:44] <seb128> mfisch, not sure that does what you want but that's an useful tool/likely to help you
[19:48] <mfisch> seb128: thanks, I'll take a look
[19:49] <mfisch> seb128: I was quite surprised to see it finding icons in a random . folder in ~
[19:49] <mfisch> something about my main icons unity does not like
[19:49] <mfisch> unity-2d is cool with them though
[21:35] <tedg> mterry, I've got deja-dup giving me a "Permission Denied" error dialog.  I can't seem to figure out what it is getting denied on.  How do I find that out?
[21:36] <mterry> tedg, huh.  This is during backup?  Try: DEJA_DUP_DEBUG=1 deja-dup --backup
[21:36] <tedg> mterry, Yeah, nothing there.
[21:36] <mterry> nothing?
[21:36] <mterry> that's crazy talk
[21:36] <tedg> Nope
[21:37] <mterry> tedg, that means we aren't actually getting to the point of calling duplicity
[21:37] <mterry> tedg, where is the backup?
[21:37] <tedg> Ha, you're just saying it's crazy because it's your bug?  ;-)
[21:37] <mterry> tedg, :)
[21:37] <tedg> mterry, I'm trying to back up over SSH.
[21:37] <tedg> Well SFTP, but yeah.
[21:37] <mterry> tedg, can you mount it in nautilus fine?
[21:38] <mterry> and then try backing up again?
[21:39] <tedg> Yeah, works in nautilus but not deja-dup
[22:28] <Trevinho> robert_ancell: hey, I've forgot one branch of the series.. this should be the last one :P
[22:28] <Trevinho> https://code.launchpad.net/~3v1n0/unity-greeter/shutdown-better-bg-color/+merge/195150
[22:29] <robert_ancell> ok