=== shadeslayer_ is now known as shadeslayer === Ursinha_ is now known as Ursinha === rsalveti_ is now known as rsalveti === Tonio_ is now known as Tonio_aw === Tonio_aw is now known as Tonio_ === mmrazik is now known as mmrazik|lunch === Tonio_ is now known as Tonio_aw === mmrazik|lunch is now known as mmrazik === Zic is now known as Guest73291 === Guest73291 is now known as Zic === Tonio_aw is now known as Tonio_ === yofel_ is now known as yofel === LordOfTime is now known as TheLordOfTime === 20WABM4XS is now known as jussi === jussi is now known as jussi01 === jussi01 is now known as jussi === Tonio_ is now known as Tonio_aw [16:00] Laney: dholbach: micahg: bdrung: Hello, MOTU =) [16:01] * xnox is not sure who else to ping =) [16:01] hello hello [16:01] ScottK: welcome =) [16:01] #startmeeting [16:01] \o [16:01] o/ [16:01] Welcome to the MOTU meeting! :) [16:02] Hey, we actually remembered to have it. [16:02] no bots still... [16:02] #startmeeting weekly MOTU meeting [16:02] [16:09] Meeting started Thu Sep 6 16:09:16 2012 UTC. The chair is tumbleweed. Information about MeetBot at http://wiki.ubuntu.com/meetingology. [16:02] [16:09] Available commands: #accept #accepted #action #agree #agreed #chair #commands #endmeeting #endvote #halp #help #idea #info #link #lurk #meetingname #meetingtopic #nick #progress #rejected #replay #restrictlogs #save #startmeeting #subtopic #topic #unchair #undo #unlurk #vote #voters #votesrequired [16:02] ScottK: luckily the xnox bot is working :) [16:02] * xnox giggles [16:02] wow, how did tumbleweed chair this? [16:02] zorg =) [16:02] there must be a secret bar-to-bot connection [16:02] Apparently it involves beer. He said he was going to the pub. [16:03] tumbleweed, here's your agenda: https://wiki.ubuntu.com/MOTU/Meetings === doko_ is now known as doko [16:04] let's start with something fresh [16:04] ok, I have no idea what's going - xnox: do you want to chair (with or without bot)? [16:04] # topic Discuss contents of http://bazaar.launchpad.net/~harvest-dev/harvest-data/lintian-tags-data/files (dholbach) [16:04] yes [16:04] so I wrote a script which gets us fresh opportunities from lintian into Harvest [16:04] it works, but it'd be good if we could define a number of tags we want fixed [16:04] very-easy: [16:04] no-homepage-field [16:04] debhelper-but-no-misc-depends [16:04] -- [16:04] seems fine & useful =) [16:05] yes, it's very empty - I just used it for example data - I'm happy for it to be overridden [16:05] what we still need is: https://bugs.launchpad.net/harvest/+bug/1081997 [16:05] Launchpad bug 1081997 in harvest "Provide fake package set 'ubuntu-only'" [High,New] [16:05] which would help new contributors to spot stuff which can be integrated in Ubuntu directly [16:05] dholbach: does it need to be a set? I thought udd/ubuntuwire already know about ubuntu only packages. [16:05] harvest doesn't know about any of these things [16:06] it will be a "fake" package set [16:06] Harvest will just believe there's a package set [16:06] because that's one of the few things it knows about :) [16:06] xnox: I think those really, really easy ones aren't things that are worth carrying a diff from Debian for. Certainly for Ubuntu only packages though. [16:06] it already has a fake "unseeded" package set [16:06] easy has: debian-rules-ignores-make-clean-error [16:06] the rest of lintian tags are empty. [16:07] ScottK: sure, but we should fix them in ubuntu-only packages. [16:07] as I said: what's in the branch is just example data and I'm happy for it to be overridden [16:07] Agreed. [16:07] and we should make our docs clear enough to explain this [16:07] http://developer.ubuntu.com/packaging/html/fixing-a-bug-example.html already explains how to figure out if something should go to Debian or not [16:07] but I can try to make it clearer on https://wiki.ubuntu.com/UbuntuDevelopment/BugFixingInitiative too [16:08] what I just need help with is updating http://bazaar.launchpad.net/~harvest-dev/harvest-data/lintian-tags-data/files because I feel it will be useful for both us and contributors [16:08] for bug 1081997 I'm working on a fix [16:08] Launchpad bug 1081997 in harvest "Provide fake package set 'ubuntu-only'" [High,New] https://launchpad.net/bugs/1081997 [16:09] sounds good. [16:09] What I would like to see is lintian tags which are introduced in ubuntuX revisions and are not present in Debian. [16:10] xnox, can you elaborate? [16:10] As the next level after / in-addition to fixing ubuntu-only packages. [16:10] dholbach: for example package 1.0-1 is lintian clean, yet 1.0-1ubuntu1 has spelling mistakes. [16:10] sounds like a job for lintian.uw.org [16:10] dholbach: while the package is not "ubuntu-only" the lintian bugs are not debian specific. [16:11] Also need to be careful of the differences betwen the Ubuntu and Debian lintian profiles. [16:11] what I'm looking for right now is some help from everyone - if we all spend 10 minutes on http://lintian.ubuntuwire.org/quantal/tags-all.html and file an MP on http://bazaar.launchpad.net/~harvest-dev/harvest-data/lintian-tags-data/files that'd be great [16:11] sure. [16:11] Stuff that's only flagged in the Ubuntu profile should not go to Debian. [16:11] ScottK: that as well. [16:12] #action everyone submit 2 (or more =) ) lintian tags into the harvest branch ^^^^ [16:13] rock! [16:13] ScottK: do we need to review our current ubuntu lintian profile? [16:13] * xnox is not sure how well that is maintained. [16:13] possibly [16:13] * ScottK neither [16:13] #action Daniel to work on #1081997 and update bugfixinginitiative wiki page. [16:14] e.g. I don't know if it is possible, but some of the emitted tags do not apply any more since precise got released. [16:14] I think bdrung was doing some work with that [16:15] Looking at https://bugs.launchpad.net/ubuntu/+source/lintian I don't see a few pet-peaves of mine. So I guess: [16:15] #action xnox to file bugs about lintian ubuntu profile [16:15] * tumbleweed waves from the pub [16:15] Anything else? about lintian tags, harvest and lintian? =) [16:15] I'm all set. [16:15] * xnox cheers tumbleweed [16:16] .. [16:16] #topic Update NEW package workflow page, to reflect our current requirements (e.g. a bug subscriber) [16:17] what's this? What new workflow? =) [16:17] * xnox is not up to date. [16:17] me neither [16:17] we've been very discouraging of new packages [16:17] Is that with respect to the dawn of ubuntuwire & ability to create new packages by pushing to lp:~/ubuntu/raring/newpackage/new [16:17] ? [16:17] not ubuntuwire, the REVU service on ubuntuwire. [16:18] xnox: you shoudn't be able to do that... [16:18] *shouldn't [16:18] we've been telling many people that we'll only sponsor their package if they promise to look after it for future (essentially, maintain it) [16:18] if that's actually a requirement we want to enforce, it should be documented [16:18] micahg: it's currently possible and would be a massive fail if it wasn't possible to do that. Or does one need magic dev powers? [16:18] Yes. We do new packages all the time, we just try to avoid drive bys. [16:19] xnox: the namespace under Ubuntu should be limited to source packages in teh archive I would think [16:19] * xnox thought extras is the new drive-by target? [16:19] Extras is not part of Ubuntu. [16:19] * micahg starts a list of bugs to file against LP [16:19] extras also isn't appropriate for some packages [16:20] micahg: the fact that this feature exist, is beyond MOTU power, and you cannot create an lp:ubuntu/package, you can only create a "personal" branch whether that has any connection with the real archive package (with or without nameclash) is not important. [16:20] xnox: it's a namespace issue... [16:20] technically, it's not important, but it appears to be a bug IMHO [16:21] micahg: sure. well regardless of the naming one can use junk branches to submit new packages. [16:21] xnox: and lp:ubuntu/foo is just an alias anyways... [16:21] So I guess I diverged. [16:21] xnox: right, that's how it's commonly done [16:21] What is our current NEW packages policy w.r.t. to what we will, will not accept and where (archive vs extras) [16:21] well, for those using the bzr workflow... [16:22] I guess extras has their own policy. [16:22] in my mind, the policy is we want the package to go to Debian, unless there's a good reason why it can't [16:22] What is our policy? doesn't fit in debian nor extras? [16:22] * xnox wonders where the current policy is. [16:22] extras would be an approiate target for packages that can't get into Debian [16:23] for *many packages [16:23] xnox: https://wiki.ubuntu.com/UbuntuDevelopment/NewPackages [16:23] so, the two MOTU signoff requirement - I've never seen that actually enforced [16:24] (and I wish it was, sometimes) [16:24] oh, right, it only applies to non-MOTUs [16:24] it was in the REVU days [16:24] but that's pretty bogus, as it has to be sponsored by a MOTU at some point... [16:24] not at the AA level, mind [16:24] well ubuntu-devs package and upload their toy projects, then we have kde/gnome/etc packaging new upstream releases with added new packages. So it may appear as if you can just do it. [16:25] tumbleweed: well, I was under the impression it applied to everyone, just that the AA could serve as the second signoff if they so desired [16:25] micahg: it doesn't appear to be stated explicitly [16:25] tumbleweed: hrm, I thought I fixed that at some point :) [16:25] but probably not anywhere that anyone reads [16:25] It was never a REQUIREMENT for ubuntu-dev to get a second. Just highly suggested. [16:26] that's pretty bogus and renders the policy worthless [16:26] right [16:26] because then you always have two signoffs [16:26] which is the current status basically :) [16:26] AA review isn't the same as two-MOTU for REVU review, though [16:26] there's no point in having these legalistic hacks - if the policy doesn't happen then it's no policy [16:26] I can upload it to Debian with no other reviews and it'll get autosync'ed in, so why should it be harder to upload to Ubuntu? [16:27] ScottK: because nobody will maintain it? [16:27] ScottK: maybe to force you to push through Debian :) [16:27] the problem stays the same, wherever it's uploaded [16:27] tumbleweed: Second signoff has no effect on maintenance. [16:27] but yes, that's why I raised this, having a consistent policy that we can all agree with would be nice [16:28] Should we bring this problem higher up? E.g. with devel board / release / tech-board? [16:28] Cause what we really want is "Universe Inclusion Report" =) [16:28] with completely different and more relaxed rules, but still enforced by Archive Admins (e.g. incomplete Universe Report) [16:29] yes, it might be worth to raise this problem in another forum [16:29] that can be easly referenced. [16:29] .. [16:29] any takers? [16:30] I would suggest having slightly more croncrete plan first [16:30] Sure. So we should draft Universe Inclusion Report - what we think should be enforced and what exceptions apply. [16:31] E.g. autosyncs from Debian is fair game, but not from NEW queue. [16:31] I'd rather no bureaucracy and sponsors/uploaders just do it right [16:31] is there any evidence that we're /still/ doing this badly? [16:31] E.g. if appropriate redirect to extras. [16:31] it's been some time since we started being hard about pushing people to debian [16:32] Otherwise the ITP bug report needs 2 Acks for sanity. [16:32] Laney: good point is this still a problem? [16:33] * xnox doesn't monitor new queue, not sure how many there were last cycle. [16:33] you can't tell until some time later anyway [16:34] if someone cares, they should look at all of the ubuntu uploaded packages in the last year or so and see what's happened [16:34] anyway, I saw a message on G+ the other day (yesterday?) where someone was complaining about the ARB backlog [16:35] it strikes me that MOTU could use this as an opportunity to show ourselves as a better alternative to that :-) [16:35] we don't appear to have the will for that [16:35] Laney: by redirecting to frozen Debian? [16:35] * xnox wants to move on. [16:35] frozen debian can still receive new packages [16:35] sure, move on [16:35] maybe let's just bring it up on ubuntu-devel@ [16:36] The agenda point is a bit sloppy, maybe it needs to be improved first. Cause the discussion we just had lacked focus a little =) [16:36] dholbach: maybe. [16:36] I think we should first have a least some rough consensus between 4 people before taking it up to ubuntu-devel, otherwise we will simply flame there =)))) [16:36] heh [16:37] I'm sure we would also have folded under the weight of 300 submissions at once :-) [16:37] =)))) [16:37] .. [16:37] #topic Killing off sqlite 2 (src:sqlite) [16:37] So one of the big items on the list is Asterisk 11 which is now released. [16:37] Anybody knows the state of the art with Asterisk 11 packaging? [16:37] is that in raring? [16:38] micahg: nope, nor in experimental. [16:38] I see no Debian bug about it [16:39] to be honest I wouldn't expect it yet. [16:39] As it was only released on Halloween. [16:39] http://blogs.digium.com/2012/10/31/asterisk-11-now-available/ [16:40] carry over [16:40] .. [16:41] # Fixed items [16:41] * xnox anybody knows what happens here? [16:41] dholbach: ? bugfixinginitiative? well lintian was a big item... [16:41] from the Dev Advisory Team: Business as usual. Reaching out to new/experienced contributors. [16:41] xnox, yes, I'll update the page [16:42] dholbach: hmmm... can we nominate logan for motu? [16:42] =))))) [16:42] xnox, haha [16:42] great [16:42] YOU mentioned it, bdrung did, seb128 did [16:42] and I just mailed him as part of my d-a-t activities today :) [16:42] so let's see what he says :) [16:42] * xnox thinks it's a long term solution for the sponsorship queue size for a good few months I think ;-) [16:43] it might help a bit [16:43] # AOB =) [16:43] * xnox who will update minutes? chair next meeting? [16:43] * xnox chaired today, so I am out :DDDD [16:44] I'm still looking for speakers for https://wiki.ubuntu.com/UbuntuDeveloperWeek/Timetable [16:44] and would love to have more guests in https://wiki.ubuntu.com/UbuntuDevelopment/Hangouts [16:44] but that's all the AOB I have [16:44] dholbach: what are you covering in your two introduction sessions? [16:45] http://developer.ubuntu.com/packaging/html/introduction-to-ubuntu-development.html and http://developer.ubuntu.com/packaging/html/getting-set-up.html - maybe a bit of http://developer.ubuntu.com/packaging/html/fixing-a-bug.html if time permits [16:45] :) [16:45] * xnox thinks to cover mk-sbuild & pbuilder-dist for multi-distro & compiling for armhf. [16:46] that'd be awesome [16:46] dholbach: I'll email you =) [16:46] you're a hero! [16:46] End meeting? === Tonio_aw is now known as Tonio_ [16:47] yep [16:47] should we address the queue issue dholbach brought up on the ML? [16:47] thanks a lot xnox [16:47] micahg: which one? [16:48] https://lists.ubuntu.com/archives/ubuntu-devel-announce/2012-November/000993.html [16:48] #action micahg to sponsor everything from the queue. ;-) [16:48] ah yes - basically: everyone should feel really invited to help with sponsoring - if you have upload rights, please help out - it's worth the time! [16:48] =))))))))))))))) [16:49] xnox: not this week :) [16:49] /msg micahg shall I be scared about CVEs in emacs24? [16:49] =) [16:50] xnox: nah, we can just make it a transitional package to vim :) [16:51] micahg: to provide similar experience you will need to add memory leaks to vim and sleep() on startup =) [16:51] does anyone have any questions or concerns about the sponsoring situation we should discuss? [16:51] #endmeeting [16:51] * xnox fail [16:51] dholbach: well we should sponsor stuff, there aren't many other options to be honest. === Tonio_ is now known as Tonio_aw [16:52] dholbach: there's an issue with stuff lingering in the queue after it's been looked at (usually incomplete) [16:52] is https://wiki.ubuntu.com/UbuntuDevelopment/CodeReviews#Keeping_the_Sponsoring_Queue_manageable insufficient? [16:54] dholbach: can't say that I've read that before... [16:55] ok, maybe I should follow up on the post and point to it explicitly :) [16:55] dholbach: doesn't say anything about if something needs tweaking if ubuntu-sponsors should be left or removed [16:55] I can do that [16:55] any suggested wording? I can put it in there [16:56] I usually unsubscribe sponsors, but can't say that I always do it [16:56] ok, I'll just cook up something [16:56] if you come across something which hasn't been changed in a longer while it might make sense to do it [16:56] thanks for the suggestion [16:57] xnox, looks like that's it [16:57] . [16:58] .. [16:58] ... [16:59] #endmeeting really now =) [16:59] thanks everyone! thanks xnox === tyhicks` is now known as tyhicks === Ursinha is now known as Ursinha-afk === Ursinha-afk is now known as Ursinha [19:01] alright, so who's there for the meeting? [19:02] I forgot to send a meeting reminder yesterday [19:03] * mfisch waves [19:03] hey! [19:03] hi jono, great to see you! [19:03] ditto cielak :-) [19:03] today is my first day back, so I am going to be multitasking a little with this meeting :-) [19:03] is there an agenda? [19:04] not really, I did not have specific topics to discuss [19:04] so I guess this meeting is a chance to sync up with others [19:05] we can discuss the status of the 0.4 goals [19:05] I am a little behind on things as I haven't been keeping up with email [19:05] I see that there is a flurry of new people interested in participating :-) [19:05] yes [19:05] jono: this is right, we had an unexpectedly high number of interested contributors [19:05] awesome! [19:06] what areas are these folks working on? [19:06] we had someone fix all the pep8 stuff in the viewer [19:06] there is Zilvador working on new accomps, Marqin helps to create a HTML template for viewer's accom details display [19:06] cielak and i also caught up on some submitted accomplishments [19:06] we're also getting in touch with interested designers [19:07] Robin did the pep8 stuff [19:07] a friend of mine is very interested in redesigning trophy icons, she will probably contact us within few days [19:07] do we need new trophy icons? [19:08] actually what we need are trophy silhouette templates [19:08] gotcha [19:08] currently all icons look exactly the same [19:08] right [19:08] and variety would make them much more interesting [19:08] I agree that nicer icons would be great [19:08] so one thing I wanted to discuss with you cielak and mfisch [19:08] is transitioning the server over to you [19:09] right now I am becoming a bottleneck [19:09] maybe we can schedule a hangout next week and I can show you how it works [19:09] since we are speaking about the icons, I have currently applied a fix to both daemon and collections - the -locked icon variations are now provided by collection and not the daemon [19:09] right [19:09] cielak, what is the purpose of the lock icon change? [19:10] what about this time next week? I guess this time would be probably fine to us all [19:10] cielak, great idea [19:10] lets do that [19:10] oh actually I cant [19:10] I will be at an event [19:10] how about 1pm Pacific on Tues next week cielak, mfisch? [19:11] I think that works [19:11] mfisch, cool [19:11] jono: basically the point is that the icons are 'static' data, and regenerating them everytime daemon starts takes additional time, is prone to bugs, and pulls in unwanted dependencies on image manipulation libraries [19:12] jono: I've posted a broader explanation here: https://lists.launchpad.net/ubuntu-accomplishments-contributors/msg00480.html [19:12] * cielak converts pacific to utc [19:12] cielak: it's 11:12 AM pacific right now [19:12] cielak: I'd like to add a new test during the package build to ensure that every trophy has a locked and unlocked version [19:12] cielak, right, the reason I did it that way was that it only generates the icons once, but then we don't have different lock icons in different sets [19:13] cielak, I don't see why we would not just use the same lock icon and I wanted to keep the bar low for creating collections [19:13] hence why the daemon generates the lock icons [19:13] also, in terms of the deps, because we deploy on Ubuntu, this isnt an issue really as the dep is satisfied by the archive [19:14] okay, I am fine with that meeting time [19:14] cielak, awesome! [19:14] mfisch, jono: okay, let me explain few more details about my implementation [19:14] cielak, cool :-) [19:14] first, the -locked version is not necessary [19:15] if it's not present, nothing bad will happen, the standard version will be used instead [19:15] second: I made a script that automatically creates -locked images applying the lock icon [19:15] it's bundled with the collection, alongside trophy images [19:15] but you run that before checkin? [19:16] cielak, ahhh I see [19:16] third: one may want to substitute the autogenerated icon, in such case using own -locked will result in it being shown in the viewer, instead of the auto-generated one [19:16] mfisch: nope, it does not get run automatically [19:16] cielak, but one problem is if we want to change the locked icon across all collections [19:17] we then rely on the collection author changing it [19:17] speaking personally, I am happy if you make this change, I just don't really see the need for it [19:18] my worry is that people will forget to make a locked icon [19:18] I even feel that third-party collections may want to use their custom images which won't match our style at all [19:18] mfisch, that is my concern too [19:18] cielak: did you also change the server's unit tests? theres one for locked icons I think [19:18] I don't think people should be able to use custom lock icons [19:18] the lock icon is part of the view UI in my mind [19:19] if we have a locked trophy w/o a lock icon someone will file a bug [19:19] mfisch: nope, I am not touching server source at all [19:19] cielak: I thought you removed the lock generation code? [19:20] aah, you mean the daemon, thought you were speaking about the validation server [19:20] the tests are not adjusted, but they did not fail for me, though [19:20] (maybe I am running them a wrong way?) [19:20] cielak, my concern here is that this provides an opportunity for different lock icons in different collections, which will make the experience less consistent [19:21] this is why I wrote it the way it is, to prevent this risk [19:21] alright, then let's at least move the icon manipulation to the viewer [19:21] as a part of UI [19:21] cielak, right, but what about other viewers? [19:22] it would be a shame to expect every viewer to implement support for a lock icon [19:22] such as the lens [19:22] or the web gallery [19:22] well I feel they should be totally free to use their own icon [19:22] cielak, so maybe we do this: [19:23] so maybe the daemon has its default lock icon, as it is now [19:23] but then the viewer can override this icon if needed [19:24] so the viewer can say (I have my own icon) and it does the work of overlaying it on the stock trophies [19:24] then we get the best of both worlds [19:24] hmm, alright, though this two-way communication may be difficult [19:25] cielak, is this lock icon issue a problem we need to solve? [19:25] it seems like so far all our viewers are fine with the current lock icon [19:25] I just wonder if we are simly trying to solve a hypothetical problem [19:25] it was something that caused us some problems in the past [19:26] has it? [19:26] when? [19:26] and I do not really enjoy having the daemon recalculate exactly the same images on my other machine, which is slow, and that increases daemon startup time [19:27] the viewer tends to have problems if the icon cache is not ready [19:27] we have some workarounds for that [19:27] I think the processing time, start-up time and extra deps are the issues [19:27] cielak, but it only recalculates them once [19:28] cielak, it should only do it if the icons are not there [19:28] jono: true, but this `once` is 5-10 more secs for startup [19:28] otherwise it skips recreating them [19:28] cielak, I don't think that is a big deal [19:28] how can it know the icons are not outdated? [19:28] cielak, that is a good point, but I think the icons will be rarely outdated [19:28] and a postinst script could regen them [19:29] hm, they are stored in ~/... so postinst scripts are not ideal solution [19:29] well, maybe indeed I've been solving a problem that is only hypotetical [19:29] no we can't use post-inst [19:30] but then again, I still consider it more elegant to give collection full control over it's icons [19:30] cielak, I think it is cool you are wanting to fix up all the loose ends, but I am not sure this this that big of a deal [19:32] I'm pretty neutral on this [19:33] are we finished on this topic? [19:33] I guess so [19:34] jono: I need to change the meeting, I have a dr appt at 12:30 Pacific on tuesday [19:34] I also propose that we think more about this icon thing and perhaps discuss more via email [19:36] we may have lost jono momentarily [19:36] apparently [19:36] cielak: I still need to try to re-review Tony Vec's accomplishments [19:37] I'm not sure what state they're in, but perhaps I can make them work [19:37] sorry had to give a status update [19:37] that would be great, they have been stuck for some time already [19:37] mfisch, can you do 30mins later? [19:38] jono: possibly, but it's a 20 min, drive, doing it an hour would be safer [19:38] cielak, is doing it an hour later ok for you? [19:39] it should be [19:42] mfisch: what is the state of PEP8 fixes? did that recent MP bring all what we need, or can't be yet marked as done? [19:42] I haven't checked [19:42] I think they're all fixed [19:42] but I'll check [19:42] give me 2 mins [19:43] cielak: whats the progress on the web gallery? [19:43] I have no idea [19:43] I know janos commits stuff regurarly [19:43] not frequently, but regurarly [19:43] cielak, awesome, I will change the time [19:44] so I also heard that the RT for the server is going through [19:44] so we should have the Canonical deployed accom server up and running soon [19:44] nice [19:45] mhall119, is away today, but we can sync up next week on this [19:45] I am really keen for us to roll out accomplishments more widely to the community [19:45] that's cool [19:45] it will get more people interested in getting involved too :-) [19:46] cielak: so the pep8 stuff is fixed aside from some long lines that will be annoying to split [19:47] there's no pretty way to split this line up [19:47] self.cb_daemonsessionstart.set_active(bool(self.libaccom.get_daemon_session_start())) [19:48] renaming stuff to shorter names would solve this [19:48] but it's not really what we may want [19:49] we dont need to do that just for pep8 [19:49] sorry guys, I am in a team meeting right now too [19:50] cielak: did we have much else? [19:50] I guess not [19:50] cielak: I closed the pep8 bug [19:50] thanks [19:50] cielak: lets also close this bug [19:51] https://bugs.launchpad.net/ubuntu-accomplishments-viewer/+bug/1030437 [19:51] Launchpad bug 1030437 in Ubuntu Accomplishments Viewer "accomplishments viewer icon looks bad in unity-2d" [Low,Confirmed] [19:51] hmm [19:51] this is actually a hilarious stuff [19:51] do you realise why it actually renders incorrectly? [19:51] no [19:52] here's a hint: on a Windows machine, it renders as a trophy *without* ubuntu logo [19:52] empty space instead of it [19:52]