[00:57] <stgraber> that one is mine, diff should be fairly straightforward. I mostly noticed the crash on Ubuntu Touch, though I've had reports (by e-mail, no bug report) of it also happening on standard machines that have weird network devices.
[00:57] <stgraber> (and yes, I fixed the patch name in the previous changelog entry because it was bugging me)
[02:31] <infinity> stgraber: Accepted.
[02:31] <stgraber> thanks
[10:59] <didrocks> Laney: I guess the qtsystems-opensource-src is easy (and pinned by the lubuntu discussion we had, I didn't check, but that's what Mirv told in term of rdepends)
[11:05] <Laney> +Forwarded: no
[11:07] <Laney> Mirv: know why that's the case?
[11:08] <didrocks> Laney: when I read the diff, I guess it was because it's an hack
[11:09] <Laney> The kernel part got wontfixed
[11:20] <Mirv> Laney: it got wontfixed, but I'm not sure if it's something that wouldn't be fixed later on since it's clear the driver has stubbed functions.
[11:37] <Laney> Mirv: I think that means we'll end up carrying the patch indefinitely until someone else gets around to fixing it
[11:37] <Laney> I'm worried that we change the specification of the function for everyone unilaterally without seeking upstream's input
[11:38] <Laney> ScottK: thoughts?
[11:38] <Laney> Some kind of whitelist of known-broken devices might be ok
[11:48] <ScottK> Laney: I agree with you.
[11:48] <ScottK> Upstream review should be sought before something like this is done.
[11:50] <ScottK> I'll be offline mostly today, so I can't provide much help.
[11:50] <Mirv> Laney: ok, I'll file an upstream bug about it. there's not much people looking at qtsystems though, so there may not be a quick answer. but we essentially took over qtpim development already, so if we need qtsystems a lot we can start pushing that too.
[11:51] <Laney> Mirv: took over upstream?
[11:52] <Mirv> Laney: wrong wording, but I mean renato from our side has become the only upstream contributor pushing changes at the moment.
[11:52] <Laney> ah
[11:52] <Laney> well, having upstream commit is great and the way things should work
[11:53] <Laney> Mainly I think changing behaviour in Ubuntu-specific ways indefinitely is a bad idea
[11:58] <Laney> Mirv: Could you check if it's feasible to do the whitelist?
[11:58] <Laney> QtSystems has API to get the device at least
[11:58] <Laney> (Not sure if it works in this case though)
[12:04] <Mirv> Laney: I now proposed the rsalveti's patch as is to upstream and added the links to the packaging branch. rsalveti may comment on the feasibility of the whitelisting.
[12:04] <Mirv> so both filed a bug https://bugreports.qt-project.org/browse/QTBUG-33748 and a branch fixing it
[12:04] <Laney> Mirv: thanks
[12:21] <Mirv> those ido + indicators miscellaneous small fixes ^ tested by me on desktop (autopilot unity7 + manual tinkering with the indicators) and psivaa on touch
[13:42] <stgraber> oh looks like the queue grew quite a bit overnight, I'll finish to deal with something then go through all of those (in 20min-ish)
[13:53] <rsalveti> Mirv: you probably know more about qtsystems internals than me :-) All I gave at that bug was a workaround to disconnect signal from actually knowing if the device is valid
[13:53] <rsalveti> Mirv: we might just ask help from renato then, as he seems the only one changing it lately
[13:54] <rsalveti> whitelist sounds a better idea, but need to check what api to use, and -enotime this week
[14:00] <Laney> what is the point of that libfriends upload?
[14:00]  * Laney asks in The Other Place
[14:12] <diwic> uhm, are we frozen? We usually unfreeze between "Final Beta" and "Final Freeze"
[14:13]  * diwic just uploaded a PulseAudio to fix a few crashes
[14:14] <smartboyhw> diwic, see https://lists.ubuntu.com/archives/ubuntu-release/2013-September/002605.html
[14:14] <apw> diwic, actually we normally are in this half way not frozen but everything gets looked at phase in between
[14:15] <stgraber> diwic: so the dbus part of the upload seems like a feature change to me (removal of dbus support). Can you confirm that nothing in any of our supported images (all flavours) use that module?
[14:15] <cjwatson> diwic: We haven't unfrozen in this phase since at least the quantal release cycle.
[14:16] <cjwatson> Compare e.g. https://lists.ubuntu.com/archives/ubuntu-devel-announce/2013-April/001030.html
[14:16] <diwic> stgraber, it was not used in 13.04, experimentally enabled in 13.10 because I thought upstream has fixed things, but it still causes crashes.
[14:17] <stgraber> diwic: Based on the changelog it looks like you neabled the module around a month ago, is that right?
[14:17] <diwic> stgraber, so no, I can't give you a guarantee, just that I would be surprised of something in our official flavours actually used it.
[14:18] <cjwatson> diwic: IIRC pulseaudio is in touch images; doesn't this need landing approval from the touch people?
[14:18] <diwic> cjwatson, I asked didrocks on friday if it was okay to upload a PulseAudio with stuff that only touches things that we don't make use of on the phone and he said ok
[14:19] <diwic> stgraber, something like that. If you ask me to verify, I would look into the same changelog to do that :-)
[14:19] <didrocks> yeah, it was okay (and it's still)
[14:20] <cjwatson> diwic: OK, cool
[14:20]  * cjwatson lets stgraber carry on reviewing ...
[14:20] <stgraber> ok, so based on the limited time in the archive (so unlikely that anyone actually noticed and made use of it) and the fact that it's causing a segfault in some cases, I'm granting an FFe on that and will let it through
[14:20] <diwic> stgraber, ok, do I need to do any paperwork for the FFe?
[14:21] <stgraber> diwic: nope, paperwork is the past 10 lines of IRC log
[14:21] <diwic> stgraber, ok, thanks :-)
[14:22] <stgraber> ^ what happened there? :)
[14:24] <Riddell> stgraber: my scripts got ahead of themselves, it's not released upstream yet
[14:24] <stgraber> Riddell: ok :)
[14:24] <Laney> stgraber: btw I queried the libfriends upload, maybe leave that one for now
[14:25] <stgraber> Laney: ok, will do
[14:25] <Laney> (appears to do nothing)
[14:25] <stgraber> seb128: is the Uploaders change intentional in that gtk upload?
[14:25] <diwic> the "Unpacking replacement friends ..." line in my log was slightly amusing. :-)
[14:25] <Laney> stgraber: that is automatic
[14:26] <stgraber> Laney: ah? does it somehow sync that with Debian when generating the source package?
[14:26] <seb128> stgraber, that's control.in->control from the pkg-gnome tools
[14:26] <cjwatson> It's an intersection of a list in pkg-gnome-tools with the last N entries in the changelog, IIRC
[14:26] <seb128> stgraber, it builds the upload list from the changelog most recent entries
[14:26] <Laney> It takes the last x uploaders and intersec
[14:26] <Laney> yeah
[14:26] <stgraber> ah, interesting, ok.
[14:28] <Laney> Mirv: looks like QtSystems can't give you the model on N4
[14:31] <stgraber> hmm, weird that click didn't get auto-accepted, let me quickly check why
[14:31] <stgraber> ok, that's because it's in ubuntu: supported (and as a result in the packageset), alright, waiving through
[14:32] <Laney> there's 10-ish outstanding FFes too
[14:33] <seb128> Laney, it reads the model from /sys/devices/virtual/dmi/id/product_name ... is that available on the n4?
[14:33] <Laney> seb128: nope
[14:34] <seb128> Laney, then it should fallback to libhybris
[14:34] <cjwatson> stgraber: thanks
[14:34] <seb128> Laney, getprop ro.product.model
[14:34] <Laney> seb128: in qtsystems itself?
[14:35] <seb128> Laney, no, u-s-s
[14:35] <Laney> not talking about that
[14:35] <seb128> oh, ok
[14:35] <seb128> sorry, ignore me then
[14:35] <Laney> :P
[14:35] <seb128> qtsystems only knows to read /sys/devices/virtual/dmi/id/product_name
[14:35] <seb128> Laney, that's https://bugs.launchpad.net/ubuntu/+source/qtsystems-opensource-src/+bug/1197542
[14:36] <seb128> Laney, see comment #10 there
[14:36] <stgraber> looking at all those indicator related uploads now
[14:36]  * Laney nods
[14:36] <Laney> so I don't know if this whitelist idea can be implemented in qtsystems
[14:37] <seb128> Laney, I didn't follow the discussion, what's the whitelist for?
[14:38] <Laney> seb128: https://bugs.launchpad.net/ubuntu/+source/qtsystems-opensource-src/+bug/1231196
[14:38] <Laney> it got accepted anyway (should have rejected if I wanted to block it)
[14:38] <seb128> ok
[14:47] <stgraber> and back to an empty queue!
[14:48] <Laney> nice
[14:49] <Laney> Riddell: bug #1222128 might interest you
[14:49] <Laney> (the bot has been irritatingly broken for ages)
[14:50] <Riddell> 15:50 < ubottu> bug 1222128 in Ubuntu "[FFe] [needs-packaging] kqoauth" [Wishlist,New] https://launchpad.net/bugs/1222128
[15:15] <czajkowski> slangasek: ello :)
[15:16] <slangasek> czajkowski: hey there
[15:16] <Laney> I imagine someone other than me would be more qualified to look at http://pad.lv/1218530
[15:22] <slangasek> Laney: ok, done
[15:22] <Laney> ta
[15:27] <czajkowski> slangasek: re the workspace not working and it was last week and now no longer isn't the regression tag a useful tag ?
[15:27] <slangasek> czajkowski: that tag is for regressions in stable updates
[15:28] <czajkowski> ahh
[15:28] <czajkowski> ok
[15:28] <czajkowski> thanks for clearing it up
[15:29] <slangasek> not that your bug shouldn't be fixed, but the SRU team doesn't want to receive bug mail about it ;)
[15:30] <czajkowski> slangasek: good to know :)
[17:58] <stgraber> seb128: what happened to that poor evolution-data-server changelog?
[17:58] <stgraber> (if that's even you who uploaded that one, the diff is pretty confusing ;))
[18:00] <stgraber> Riddell: hmm, that user-manager upload looks like it has new features...
[18:01] <stgraber> Riddell: (if you say it doesn't, I'll read much closer but added dependencies and a bunch of new files isn't usually a very good sign)
[18:02] <infinity> stgraber: That eds looks like an almost-sync-but-not-quite.
[18:03] <infinity> Diff looks fine but, yeah, losing all the Ubuntu history/context in the changelog is a bit irksome.
[18:03] <stgraber> infinity: yeah, looked like a sync at first but not quite, I guess I should pull the resulting changelog to see what's the end result :)
[18:04] <stgraber> it also does say "sync with Debian" and then "remaining changes" which to me sounds wrong, that's a merge and a merge should keep the changelog history (merge-changelog is usually pretty good at that so why not use it...)
[18:06] <infinity> Wait, there's a tool for that?  I always do it by hand when MoM can't do it for me.
[18:10] <stgraber> merge-changelog 1 2 > 3 :)
[18:10] <infinity> Does someone still have a hardy chroot kicking around?
[18:12] <infinity> Oh, nevermind.  I was going to ask if tar's compression autodetection works in hardy, but that was apparently added in 2004...
[18:19] <pleia2> infinity: heads up, http://www.ubuntu.com/community/participate included in release announcements is a 404, I submitted a bug to have them redirect to community.ubuntu.com (it's private, I can sub you if you'd like)
[18:21] <stgraber> pleia2: why is it private?
[18:21] <stgraber> (I don't really care about the bug, just wondeirng why a bug about an existing problem on a public website is private)
[18:21] <infinity> pleia2: Oh, fun.  It should perhaps redirect to http://community.ubuntu.com/contribute/
[18:21] <infinity> Maybe.
[18:22] <pleia2> stgraber: all website content bugs are by default
[18:22] <infinity> Or maybe just to the root.
[18:22] <infinity> I don't remember what was on the old page.
[18:22] <infinity> Yeah, probably best to send it to /contribute/
[18:23] <stgraber> pleia2: that seems wrong, but ok...
[18:24] <balloons> does anyone have an insight on who is doing signoff for the server images?
[18:24] <infinity> balloons: I did for the beta, but we probably want someone from the server team to do it for final.
[18:24] <infinity> rbasak: ^
[18:25] <balloons> infinity, I figured it was you :-) I was hitting a dead end on trying to track someone from the server team down who knew enough to handle this.
[18:26] <infinity> balloons: Well, we could escalate all the way to robbiew if we can't find anyone to take responsibility, but let's see if rbasak responds first. :P
[18:28] <seb128> stgraber, what's wrong with it?
[18:28] <infinity> seb128: It dropped all the Ubuntu changelog entries.
[18:28] <seb128> yeah, we never keep old changelog entries when merging desktop packages
[18:29] <seb128> it's annoying to merge back, it wastes space and it's not useful
[18:29] <seb128> we have launchpad for a record of uploads
[18:29] <seb128> think about it as a direct sync and then, oh, we have a diff again there ;-)
[18:30] <seb128> infinity, stgraber: jbicha has a "sync on debian" stacked in the vcs so I included that rather than having to play revert (the actual diff out of the changelog is quite small)
[18:36] <infinity> It loses history if one wants to know when something was changed.  Digging through all revisions on LP is a pain.
[18:37] <apw> did we say there was a handy tool for the merge
[18:37] <infinity> apw: merge-changelog, apparently.
[18:38] <apw> oh yeah thats the baby, seems to be pretty simple
[18:38] <seb128> infinity, so what do you do when a package can be synced and then has ubuntu diff again?
[18:38] <seb128> infinity, do you go add back all the previous ubuntu diff history to the changelog?
[18:38] <infinity> seb128: That's different.  If it can be synced, one assumes that the Ubuntu bits have ended up in Debian, thus are represented in the Debian changelog.
[18:38] <seb128> well, they are represented in the merge summary the same way they would be in a debian changelog entry
[18:38] <infinity> (including some sort of attribution, perhaps, which one loses if you remove history)
[18:39] <seb128> well, anyway, we have been dropping changelog history consistently for desktop stuff for over 9 years
[18:39] <stgraber> seb128: I don't think your merge summary contains the name of who added the individual bits and when those were introduced, and it turns out it's pretty useful information when debugging stuff
[18:39] <seb128> ^
[18:39] <seb128> that's what we do accross desktop for ever
[18:40] <seb128> you liking it or not doesn't seem a release team topic
[18:40] <seb128> if you want us to change that go to the TB
[18:40] <stgraber> doesn't necessairly make it right ;)
[18:40] <seb128> (sorry, not wanting to be harsh, just trying to not start an endless argument on who prefers what)
[18:40] <seb128> sure
[18:40] <seb128> but let's agree to disagree
[18:40] <seb128> if you care enough, take it to the TB
[18:40] <rbasak> infinity, balloons: I'll raise it in the server team irc meeting tomorrow. Thanks for asking - it'll be nice to have someone lined up and scheduled to do it rather than a last minute scramble to find someone.
[18:41] <stgraber> and have the TB say what? please respect the existing procedures on merges? because I'm pretty sure what infinity and I are saying is what's been documented for ages as the procedure to make merges
[18:41] <stgraber> we've even wrote tools to do just that ;)
[18:41] <rbasak> I wonder how we could make sure that someone is nominated each release for this without you having to chase.
[18:41] <balloons> rbasak, if you can, please let me know who you pick
[18:41] <rbasak> balloons: will do.
[18:41] <infinity> rbasak: Well, it would have been fine if the person who "owned" the product hadn't quit. :P
[18:42] <seb128> stgraber, recommended != required
[18:42] <stgraber> rbasak: so we have a sign-off contact entered next to the product name on the tracker. If you let me know ahead of time I can update the field to reflect reality
[18:42] <rbasak> OK - thanks!
[18:42] <balloons> rbasak, infinity yes, basically we need someone to take over the reins from Daviey on this one :-)
[18:42] <seb128> stgraber, that's a pretty stupid rule imho, because as said, sync loose changelog history anyway and we have full history in launchpad in any case
[18:43] <infinity> seb128: It's not worth arguing about.  My biggest concern is actually just attribution, nothing else.  A sync should retain attribution because the Debian maintainer should mention the patch contributor when he takes the patch.
[18:43] <infinity> seb128: A merge without history makes it look like the last uploader "owns" all the modifications.
[18:44] <infinity> (Proper DEP-3 headers in patches fixes that, but not everyone uses quilt, and not everyone uses proper headers when they do use quilt)
[18:44] <seb128> infinity, would you be happy if we put the author in the merge summary?
[18:44] <infinity> seb128: Or in the patches, if you're doing quilty things (and maybe you already do that religiously).  In which case, meh.  Lost history is annoying, but not world-ending.
[18:45] <infinity> Either way, this isn't worth having a debate about on a Monday.
[18:45] <infinity> Cause, well.  Monday.
[18:45] <infinity> Screw Monday.
[18:45] <seb128> infinity, we tend to do tag patches yes, and as said, launchpad has the history
[18:45] <seb128> -changes lists as well
[18:46] <infinity> LP's history isn't meaningful for someone who downloads a source package.  But properly tagged patches works for me for the blame/attribution game.
[18:46] <seb128> infinity, we have vcses for history as well
[18:47] <seb128> or bzr blame
[20:48] <rsalveti> can someone approve libhybris? adding another functional call needed by gstreamer to fix an issue with playbin/platform-api in touch
[20:48] <stgraber> I'll take a look
[20:49] <rsalveti> thanks
[20:49] <stgraber> done
[21:10] <rsalveti> thanks
[22:36] <cjwatson> infinity: fakeroot/critcl> well spotted
[22:39] <cjwatson> oho, lilypond/i386 stuck to the wall this time
[22:39] <cjwatson> I'm working on a Debian QA upload for kinput2
[22:44]  * infinity is fixing openmpi1.6
[22:45] <infinity> Man, I'd give good money for the new apt-cacher-ng to stop randomly stalling...
[22:46] <infinity> Or maybe I'll just give up on clever caches and run squid on my laptop.
[22:52]  * cjwatson shaves yaks.  Need to QA-upload wnn6-sdk first
[23:03] <infinity> That mpfr4 testsuite hang on armhf isn't making me the happiest of campers.
[23:04] <infinity> 20-to-1 odds say that switching to gcc-4.7 "fixes" it.  And then doko hits me.