[08:11] good morning all [08:15] hi dpm [08:18] hey ajmitch [12:56] goor morning [12:56] *good [17:53] mhall119: the community lens was out for changes, is it ready now for re-review? [17:54] wendar: no, I haven't had a change to make the requested changes to it yet [17:56] mhall119: okay, I'll add a comment to it [17:56] thanks [17:56] wendar: it's currently precise-only anyway [17:56] mhall119: yup, no rush [17:57] has david calle submitted any more? [17:59] mhall119: not yet [17:59] mhall119: I'm nearly done packaging the scopes for the music lens [20:00] wendar: have you been re-poking people who've submitted applications? [20:01] ajmitch: like, reminding them that we haven't heard from them in a while? [20:01] ajmitch: not yet, but I was thinking about doing that for guallet today [20:01] it's really close to ready to go [20:02] I was just seeing the flood of information needed requests, they were all pending review/ [20:02] ? [20:02] yeah, that's me [20:03] * ajmitch had talked to the hacketyhack submitter a couple of days ago about shoes & offered help [20:03] ajmitch: cool [20:03] I didn't see any activity in the comments [20:03] sorry I hadn't copied it in there [20:04] I always forget too :) [20:04] he will have to wait until P+1 to get into Ubuntu, unfortunately [20:04] yeah [20:04] but, he could get into Debian quite quickly [20:04] once we learn what the name is :) [20:04] as soon as shoes is updated [20:05] thanks for the harmonyseq vote on the list, too [20:05] thanks for shepherding it through, it's looking great [20:17] hmmm... anyone have any ideas where this launchpad branch went? lp:~app-review-board/ubuntu/oneiric/unity-lens-graphicdesign/trunk/ [20:19] Okay, it's https://code.launchpad.net/~app-review-board versus https://code.launchpad.net/ubuntu-app-review-board [20:20] but the packaging-tools branch shows up on both [20:21] because lp:~app-review-board/ubuntu/oneiric/unity-lens-graphicdesign/trunk/ is against ubuntu [20:53] ajmitch: so, launchpad is setting the project based on the path [20:53] ajmitch: the bigger question is, do we want these branches for ARB maintained lens/scope packages to be tagged as Ubuntu project? [20:54] ajmitch: or, should we use bzr paths that avoid the auto-categorization? [20:55] lp branches are always lp:~person/project/branch_name, I think we make them be under the ubuntu-app-review-board project rather than ubuntu/release [20:55] mostly because these are for extras [20:57] ajmitch: makes sense, I'll move them over [20:57] ajmitch: but, I'll keep the Ubuntu release name in the path for sanity [20:58] so, lp:~app-review-board/ubuntu-app-review-board/oneiric/unity-lens-graphicdesign [20:59] because there's a decent chance we may be releasing an update to the Oneiric version of the lens, even after we've moved on to the Precise version of the lens [21:02] can you name the branch like that? [21:03] * ajmitch assumed that you could only name a release with a distro in LP branches [21:08] hmmm... I get a "Permission denied" error when I try to push any branch with "oneiric" in the path [21:09] I'll just have to encode it in the name of the branch [21:12] We've now got lp:~app-review-board/ubuntu-app-review-board/unity-lens-graphicdesign-oneiric and lp:~app-review-board/ubuntu-app-review-board/unity-scopes-music-extras-oneiric [21:15] alright, thanks [21:16] I'll set aside some time this weekend to attack the queue & try & catch up on where things are at [21:16] as a bonus it's a 3-day weekend again :) [21:29] wendar: yes, I *finally* dealt with terraview, what others should I look at? :) [21:30] ajmitch: awesome! [21:30] I feel worst about the oldest ones [21:30] it'd be nice to get them either published, or rejected [21:30] yep [21:30] whichever is appropriate [21:30] pac, TetraCity, or Qoobar? [21:30] like pac, I know that was sitting around on LP for quite awhile [21:31] yeah, sounds good [21:31] the feeback on that was problematic [21:32] I don't recall, was it too large/complex? [21:32] " Your "source package" contains some binaries (/opt/pac/lib/ex/vte32/auto/Gnome2/Vte at least), this shouldn't be the case. - Your source package also includes .deb files in /opt/pac/res, this looks wrong. [21:32] " [21:32] or, security concerns around passwords and connections? [21:32] oooh, packaging problems [21:33] https://myapps.developer.ubuntu.com/dev/apps/179/feedback/ indicates that he couldn't find those binaries anywhere [21:33] well, except on getdeb.net [21:34] so, he's got dependencies that aren't in Ubuntu [21:34] are they small, or likely to be added to Debian at some point? [21:34] I'll need to pull apart the package to see [21:35] it's hard when he's included them as binary .so files [21:35] he's not even pulling in the source... blech [21:36] right, and they're some libraries for libvte which is a core package for ubuntu-desktop [21:36] * ajmitch can't pull enough info out with objdump [21:37] hmmmm... it's a terminal emulator widget [21:37] yep [21:38] Technically, this did come in before we required a PPA, but I'm leaning toward reject. [21:38] libvte is definitely in ubuntu, but I can't tell how different the one he's packaged is (apart from a large size difference in the .so) [21:40] If you're inclined toward due-diligence, I'd say try running the software using the Ubuntu version of the library, and if it works go ahead and package it. [21:40] Otherwise, reject it on the grounds that software has to work on the current version of all dependencies in the current release of Ubuntu. [21:41] I feel bad doing so, but we really can't ship unknown binaries in source packages like that [21:42] Yeah [21:42] And, don't feel bad, it's part of the policy. [21:42] We're not allowed to ship updated versions of standard system libraries. [21:42] I feel bad about the time between last feedback & rejection :) [21:42] even if he included the source, we couldn't do it. [21:42] yeah, me too [21:43] but, we're doing better on that now [21:43] mostly your work [21:43] You gave a great apologetic message to the TerraView developer, that tone really helps. [21:44] And, so does the suggestions for what to do next. [21:44] that's why I took so long to respond [21:45] Yup, it's worth taking the time to phrase kind rejection messages, it makes a huge difference in the developer experience. (And in whether they're likely to learn and do better from it, or give up in frustration.) [21:47] so it looks like libgnome2-vte-perl was on getdeb.net but is no longer there [21:47] I think most of what I'm doing at the moment is trailblazing. Setting up easy, repeatable patterns for future apps. [21:47] Ah, so the source isn't even available anymore. [21:47] Maybe dropped when it made it in to the live distro? [21:48] there's no perl vte bindings in precise [21:48] do you know the state of gobject introspection & perl? [21:49] if I can suggest an alternative way to use the system libvte, I won't feel so bad rejecting :) [21:50] AFAIK, Perl is farther behind than Python in support for gtk3 [21:51] http://comments.gmane.org/gmane.comp.gnome.gtk%2B.perl/12474 [21:52] ah, wait http://search.cpan.org/~tsch/Gtk3-0.004/ [21:52] right, he's the author of the vte-perl bindings tshipped as binaries in pac [21:54] then maybe suggest to the pac developer to get in touch with Torsten? [21:54] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=647711 [21:54] so as of a week ago, there's progress in debian [21:55] excellent. So, that's something to say: watch the progress of the bug, and use the new versions of the libraries when they come out [22:00] ok, have added notes on that to my todo list, I won't write it up just yet