[00:57] 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] (and yes, I fixed the patch name in the previous changelog entry because it was bugging me) [02:31] stgraber: Accepted. [02:31] thanks === FourDollars_ is now known as FourDollars === doko_ is now known as doko [10:59] 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] +Forwarded: no [11:07] Mirv: know why that's the case? [11:08] Laney: when I read the diff, I guess it was because it's an hack [11:09] The kernel part got wontfixed [11:20] 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] Mirv: I think that means we'll end up carrying the patch indefinitely until someone else gets around to fixing it [11:37] I'm worried that we change the specification of the function for everyone unilaterally without seeking upstream's input [11:38] ScottK: thoughts? [11:38] Some kind of whitelist of known-broken devices might be ok [11:48] Laney: I agree with you. [11:48] Upstream review should be sought before something like this is done. [11:50] I'll be offline mostly today, so I can't provide much help. [11:50] 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] Mirv: took over upstream? [11:52] Laney: wrong wording, but I mean renato from our side has become the only upstream contributor pushing changes at the moment. [11:52] ah [11:52] well, having upstream commit is great and the way things should work [11:53] Mainly I think changing behaviour in Ubuntu-specific ways indefinitely is a bad idea [11:58] Mirv: Could you check if it's feasible to do the whitelist? [11:58] QtSystems has API to get the device at least [11:58] (Not sure if it works in this case though) [12:04] 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] so both filed a bug https://bugreports.qt-project.org/browse/QTBUG-33748 and a branch fixing it [12:04] Mirv: thanks [12:21] those ido + indicators miscellaneous small fixes ^ tested by me on desktop (autopilot unity7 + manual tinkering with the indicators) and psivaa on touch === jhodapp|afk is now known as jhodapp [13:42] 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] 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] Mirv: we might just ask help from renato then, as he seems the only one changing it lately [13:54] whitelist sounds a better idea, but need to check what api to use, and -enotime this week [14:00] what is the point of that libfriends upload? [14:00] * Laney asks in The Other Place [14:12] 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] diwic, see https://lists.ubuntu.com/archives/ubuntu-release/2013-September/002605.html [14:14] diwic, actually we normally are in this half way not frozen but everything gets looked at phase in between [14:15] 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] diwic: We haven't unfrozen in this phase since at least the quantal release cycle. [14:16] Compare e.g. https://lists.ubuntu.com/archives/ubuntu-devel-announce/2013-April/001030.html [14:16] 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] diwic: Based on the changelog it looks like you neabled the module around a month ago, is that right? [14:17] 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] diwic: IIRC pulseaudio is in touch images; doesn't this need landing approval from the touch people? [14:18] 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] stgraber, something like that. If you ask me to verify, I would look into the same changelog to do that :-) [14:19] yeah, it was okay (and it's still) [14:20] diwic: OK, cool [14:20] * cjwatson lets stgraber carry on reviewing ... [14:20] 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] stgraber, ok, do I need to do any paperwork for the FFe? [14:21] diwic: nope, paperwork is the past 10 lines of IRC log [14:21] stgraber, ok, thanks :-) [14:22] ^ what happened there? :) [14:24] stgraber: my scripts got ahead of themselves, it's not released upstream yet [14:24] Riddell: ok :) [14:24] stgraber: btw I queried the libfriends upload, maybe leave that one for now [14:25] Laney: ok, will do [14:25] (appears to do nothing) [14:25] seb128: is the Uploaders change intentional in that gtk upload? [14:25] the "Unpacking replacement friends ..." line in my log was slightly amusing. :-) [14:25] stgraber: that is automatic [14:26] Laney: ah? does it somehow sync that with Debian when generating the source package? [14:26] stgraber, that's control.in->control from the pkg-gnome tools [14:26] It's an intersection of a list in pkg-gnome-tools with the last N entries in the changelog, IIRC [14:26] stgraber, it builds the upload list from the changelog most recent entries [14:26] It takes the last x uploaders and intersec [14:26] yeah [14:26] ah, interesting, ok. [14:28] Mirv: looks like QtSystems can't give you the model on N4 [14:31] hmm, weird that click didn't get auto-accepted, let me quickly check why [14:31] ok, that's because it's in ubuntu: supported (and as a result in the packageset), alright, waiving through [14:32] there's 10-ish outstanding FFes too [14:33] Laney, it reads the model from /sys/devices/virtual/dmi/id/product_name ... is that available on the n4? [14:33] seb128: nope [14:34] Laney, then it should fallback to libhybris [14:34] stgraber: thanks [14:34] Laney, getprop ro.product.model [14:34] seb128: in qtsystems itself? [14:35] Laney, no, u-s-s [14:35] not talking about that [14:35] oh, ok [14:35] sorry, ignore me then [14:35] :P [14:35] qtsystems only knows to read /sys/devices/virtual/dmi/id/product_name [14:35] Laney, that's https://bugs.launchpad.net/ubuntu/+source/qtsystems-opensource-src/+bug/1197542 [14:36] Laney, see comment #10 there [14:36] looking at all those indicator related uploads now [14:36] * Laney nods [14:36] so I don't know if this whitelist idea can be implemented in qtsystems [14:37] Laney, I didn't follow the discussion, what's the whitelist for? [14:38] seb128: https://bugs.launchpad.net/ubuntu/+source/qtsystems-opensource-src/+bug/1231196 [14:38] it got accepted anyway (should have rejected if I wanted to block it) [14:38] ok [14:47] and back to an empty queue! [14:48] nice [14:49] Riddell: bug #1222128 might interest you [14:49] (the bot has been irritatingly broken for ages) [14:50] 15:50 < ubottu> bug 1222128 in Ubuntu "[FFe] [needs-packaging] kqoauth" [Wishlist,New] https://launchpad.net/bugs/1222128 [15:15] slangasek: ello :) [15:16] czajkowski: hey there [15:16] I imagine someone other than me would be more qualified to look at http://pad.lv/1218530 [15:22] Laney: ok, done [15:22] ta [15:27] 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] czajkowski: that tag is for regressions in stable updates [15:28] ahh [15:28] ok [15:28] thanks for clearing it up [15:29] not that your bug shouldn't be fixed, but the SRU team doesn't want to receive bug mail about it ;) [15:30] slangasek: good to know :) === Ursinha is now known as Ursinha-afk === Ursinha-afk is now known as Ursinha === rtg is now known as rtg-afk === fginther is now known as fginther|lunch === jdstrand_ is now known as jdstrand === psivaa is now known as psivaa-afk === fginther|lunch is now known as fginther [17:58] seb128: what happened to that poor evolution-data-server changelog? [17:58] (if that's even you who uploaded that one, the diff is pretty confusing ;)) [18:00] Riddell: hmm, that user-manager upload looks like it has new features... [18:01] 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] stgraber: That eds looks like an almost-sync-but-not-quite. [18:03] Diff looks fine but, yeah, losing all the Ubuntu history/context in the changelog is a bit irksome. [18:03] 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] 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] Wait, there's a tool for that? I always do it by hand when MoM can't do it for me. [18:10] merge-changelog 1 2 > 3 :) [18:10] Does someone still have a hardy chroot kicking around? [18:12] Oh, nevermind. I was going to ask if tar's compression autodetection works in hardy, but that was apparently added in 2004... [18:19] 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] pleia2: why is it private? [18:21] (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] pleia2: Oh, fun. It should perhaps redirect to http://community.ubuntu.com/contribute/ [18:21] Maybe. [18:22] stgraber: all website content bugs are by default [18:22] Or maybe just to the root. [18:22] I don't remember what was on the old page. [18:22] Yeah, probably best to send it to /contribute/ [18:23] pleia2: that seems wrong, but ok... [18:24] does anyone have an insight on who is doing signoff for the server images? [18:24] balloons: I did for the beta, but we probably want someone from the server team to do it for final. [18:24] rbasak: ^ === rtg-afk is now known as rtg [18:25] 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] 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] stgraber, what's wrong with it? [18:28] seb128: It dropped all the Ubuntu changelog entries. [18:28] yeah, we never keep old changelog entries when merging desktop packages [18:29] it's annoying to merge back, it wastes space and it's not useful [18:29] we have launchpad for a record of uploads [18:29] think about it as a direct sync and then, oh, we have a diff again there ;-) [18:30] 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] It loses history if one wants to know when something was changed. Digging through all revisions on LP is a pain. [18:37] did we say there was a handy tool for the merge [18:37] apw: merge-changelog, apparently. [18:38] oh yeah thats the baby, seems to be pretty simple [18:38] infinity, so what do you do when a package can be synced and then has ubuntu diff again? [18:38] infinity, do you go add back all the previous ubuntu diff history to the changelog? [18:38] 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] well, they are represented in the merge summary the same way they would be in a debian changelog entry [18:38] (including some sort of attribution, perhaps, which one loses if you remove history) [18:39] well, anyway, we have been dropping changelog history consistently for desktop stuff for over 9 years [18:39] 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] ^ [18:39] that's what we do accross desktop for ever [18:40] you liking it or not doesn't seem a release team topic [18:40] if you want us to change that go to the TB [18:40] doesn't necessairly make it right ;) [18:40] (sorry, not wanting to be harsh, just trying to not start an endless argument on who prefers what) [18:40] sure [18:40] but let's agree to disagree [18:40] if you care enough, take it to the TB [18:40] 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] 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] we've even wrote tools to do just that ;) [18:41] I wonder how we could make sure that someone is nominated each release for this without you having to chase. [18:41] rbasak, if you can, please let me know who you pick [18:41] balloons: will do. [18:41] rbasak: Well, it would have been fine if the person who "owned" the product hadn't quit. :P [18:42] stgraber, recommended != required [18:42] 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] OK - thanks! [18:42] rbasak, infinity yes, basically we need someone to take over the reins from Daviey on this one :-) [18:42] 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] 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] seb128: A merge without history makes it look like the last uploader "owns" all the modifications. [18:44] (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] infinity, would you be happy if we put the author in the merge summary? [18:44] 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] Either way, this isn't worth having a debate about on a Monday. [18:45] Cause, well. Monday. [18:45] Screw Monday. [18:45] infinity, we tend to do tag patches yes, and as said, launchpad has the history [18:45] -changes lists as well [18:46] 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] infinity, we have vcses for history as well [18:47] or bzr blame [20:48] can someone approve libhybris? adding another functional call needed by gstreamer to fix an issue with playbin/platform-api in touch [20:48] I'll take a look [20:49] thanks [20:49] done [21:10] thanks [22:36] infinity: fakeroot/critcl> well spotted [22:39] oho, lilypond/i386 stuck to the wall this time [22:39] I'm working on a Debian QA upload for kinput2 [22:44] * infinity is fixing openmpi1.6 [22:45] Man, I'd give good money for the new apt-cacher-ng to stop randomly stalling... [22:46] 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] That mpfr4 testsuite hang on armhf isn't making me the happiest of campers. [23:04] 20-to-1 odds say that switching to gcc-4.7 "fixes" it. And then doko hits me.