[16:13] <mhall119> wendar: ajmitch: stgraber: ping
[16:14] <mhall119> Someone on G+ is asking for some clarification about what his package should put in /opt/
[16:14] <mhall119> https://plus.google.com/108728447943307421833/posts
[16:15] <mhall119> can one of you give him an answer, of give me the answer and I'll give it to him
[16:15] <mhall119> http://paste.ubuntu.com/884992/ is you can't see that
[16:16] <stgraber> mhall119: in most cases, it's simply everything except the .desktop file
[16:17] <stgraber> mhall119: we also now allow /usr/share/doc/<packagename> but it's debhelper's default anyway so I don't think I ever saw someone actually put them in /opt (we always had to do it for them)
[16:40] <mhall119> stgraber: so the binary goes in /opt/ too?
[16:41] <mhall119> and the .desktop just points to it there?
[16:43] <stgraber> mhall119: yes
[16:44] <mhall119> stgraber: how about icons? Do they all go into /opt/ too, and if so does GTK know to find them there if you reference them by name instead of path?
[16:44] <stgraber> mhall119: "everything" :)
[16:44] <mhall119> ok
[16:44] <mhall119> thanks, I'll let him know
[16:44] <stgraber> mhall119: you need to put the path in the .desktop for it to work
[16:45] <mhall119> for Exec only, or Exec and Icon?
[16:46] <stgraber> both
[16:46] <stgraber> gtk doesn't know to look in /opt and we don't really want it to either
[16:47] <stgraber> the whole idea behind using /opt is to avoid having any of them automatically found/loaded by the OS unless you're calling them by their path
[16:47] <mhall119> ok
[19:42] <wendar> mhall119: there are more details at https://wiki.ubuntu.com/AppReviewBoard/Review/Guidelines
[19:43] <wendar> I forgot to ask about chairs for the next meeting at the end of last month's meeting
[19:43] <wendar> (I've added it back into the end of the agenda, so I'll remember in the future)
[19:44] <wendar> Anyone want to volunteer?
[19:44]  * ajmitch checked next meeting date
[19:44] <ajmitch> we're keeping it at the same UTC time?
[19:44] <wendar> yeah, same time
[19:44] <ajmitch> ok, I can do it then
[19:44] <wendar> cool, thanks!
[19:44] <ajmitch> next month I'll be back to UTC+12
[19:45] <wendar> love those international daylight saving time shifts :)
[19:46] <ajmitch> yeah, it's just great :)
[19:46] <wendar> I recovered some lost action items
[19:46] <ajmitch> oh, what'd we miss?
[19:46] <wendar> apparently our "emergency" meeting in January wiped out several pending action items
[19:46] <wendar> I had one to ask about the deprecation cycle for python-support
[19:46] <ajmitch> ok, I did follow up with dpitkin at least :)
[19:47] <wendar> (I've just emailed doko and barry to check in on that)
[19:47] <wendar> lfaraone had one about python-support in Quickly
[19:48] <wendar> actually, in python-distutils-extra, which Quickly uses
[19:48] <wendar> https://bugs.launchpad.net/python-distutils-extra/+bug/894582
[19:48] <ajmitch> I asked about #927588, #915902, #926032 to see if he'd prioritise getting those 3 fixed
[19:48] <wendar> you had one about asking (someone, I'm not sure who) about ARB packages depending on backports
[19:49] <wendar> but, I'm  pretty sure the answer to that one is "no"
[19:49] <wendar> at least, if it came to a vote, I'd be against ARB packages depending on backports
[19:49] <ajmitch> right, I asked broder & michag about the state of that, it's ok for runtime dependencies, but there's a LP bug that blocks build-dependencies
[19:50] <wendar> ah, okay
[19:50] <wendar> I remember, it was a question of whether it was even possible for ARB packages to depend on backports
[19:50] <wendar> should we keep a note of that somewhere?
[19:50] <ajmitch> right, but we mostly wanted it for the case of new libraries being added via backports, iirc
[19:51] <wendar> yup
[19:51] <ajmitch> https://bugs.launchpad.net/launchpad/+bug/888665 is the LP bug, it's due to it using an ancient forked sbuild
[19:51] <wendar> so, to say if it's safe, and non-disruptive, we could have an ARB depend on a backported library
[19:52] <wendar> if it's a new library, and not an updated version of an existing library in the old release
[19:52] <ajmitch> it'd just be hard to build against that library
[19:52] <wendar> so, at this point we'd be stuck with runtime python libraries
[19:53] <wendar> and no build-time C, etc libraries
[19:53] <ajmitch> actually a new library would likely work
[19:53] <ajmitch> since the PPA can have backports dependencies turned on, and the backports version would be the only version to satisfy the requirement, it ought to work :)
[19:54] <wendar> i.e. it's hard to give a one-size-fits all answer
[19:54] <ajmitch> yeah
[19:54] <wendar> How about this addition to the ARB guidelines: right after "If your app depends on external libraries, please make sure that your app runs on the current versions shipped in Ubuntu."
[19:56] <ajmitch> we do currently have "Applications must be able to be built with tools & libraries in the Ubuntu archive. Apps may bundle additional libraries they depend on, but may not include new versions of already packaged libraries."
[19:56] <wendar> we add "(We're open to considering dependencies on backported libraries, on a case-by-case basis, only if the backport is a new library and not an updated version of an existing library.)
[19:56] <ajmitch> ok
[19:57] <wendar> that leaves it open for the devs to either bundle the library or backport it
[19:57] <wendar> with the same effect, they can only depend on existing libraries, or a new library
[19:57] <wendar> but not updated versions of existing libraries
[19:58] <ajmitch> that's fair - no depending on a new version of Qt & boost :)
[19:58]  * wendar shudders ;)
[19:58] <ajmitch> it'd be nice to get the LP bug fixed, but it's not a simple fix that just anyone can pick up & do, I suspect
[20:11] <ajmitch> wendar: so I didn't really get round to doing any ARB work last night (wasn't feeling great), but I've pushed the icon change I did yesterday to the staging PPA & my branch, if you have time to take a look
[20:12] <ajmitch> once we vote on it I'll need to know the right buttons to push in myapps to get it published :)
[20:13] <wendar> ajmitch: sure, I'll take a look
[20:13] <ajmitch> thanks
[20:17] <wendar> ajmitch: in override_dh_gencontrol, you do need to keep that cp line
[20:17] <wendar> ajmitch: it's obtuse, but what that does is copy the image *outside* the package directory
[20:17] <wendar> ajmitch: so it can be added to the package metadata
[20:18] <wendar> (stgraber had to fix one of my earlier packages)
[20:18] <ajmitch> right, that is a bit special
[20:18] <ajmitch> but this is why I'm checking with you first, thanks :)
[20:19] <ajmitch> it does mean I have to bump the ppa version again, which is a bit of a pain
[20:19] <wendar> you can use $CURDIR
[20:20] <wendar> see http://bazaar.launchpad.net/~allison/+junk/extras-framingham/revision/13
[20:21] <ajmitch> in which case I ought to put it in the debian/directory as well
[20:26] <wendar> I like the way you've used patches for all changes outside the debian/ directory
[20:27] <wendar> in the debian/changelog, merge his changes and yours into one changelog entry (since there's only one Extras release)
[20:27] <wendar> you can note who did what with [ Author Name ]
[20:28] <wendar> and a quick scan of postinst and postrm, I wonder if they could be removed?
[20:29] <wendar> we don't technically allow custom maintainer scripts, but this looks like standard desktop stuff
[20:29] <wendar> probably automatically generated
[20:29] <ajmitch> this is what I was checking with stgraber - they're boilerplate postinst/postrm
[20:31] <wendar> with debhelper 8, a lot of stuff that used to be in generated maintainer scripts is now handled automatically behind the scenes
[20:32] <ajmitch> yeah, I was debating whether they'd be needed at all due to the non-standard directories
[20:32] <wendar> not sure that's the case with these specific pieces, but seems worth checking
[20:32] <wendar> ah, yeah, I noticed one of the commands was acting on /usr/share/icons/gnome
[20:33] <wendar> which we don't modify
[20:33] <wendar> so, that one could certainly go
[20:33] <wendar> the mime database is modifying /usr/share/mime, which we don't modify
[20:35] <ajmitch> right, stripped out all but #DEBHELPER#
[20:35] <wendar> let's see, update-desktop-database modifies the cache of MIME types handled by desktop files, so that can go too
[20:35] <wendar> cool, yeah, makes sense
[20:37] <wendar> ajmitch: overall, it looks great. I'd +1 it.
[20:37] <ajmitch> good, it's nearly all cielak's work, so thank him for a good submission :)
[20:37] <wendar> thanks, cielak!
[20:38] <cielak> no problem, did my best to get it as good as I could ;)
[20:48] <ajmitch> cielak: it does make our lives easier, I'll put this up for vote & we should be able to get it uploaded :)
[20:48] <cielak> nice! thanks for handling that :)
[20:51]  * ajmitch could really do with some more RAM, running a couple of VMs doesn't help when firefox & chrome are both open
[21:14] <wendar> ajmitch: yeah, both firefox and chrome are total memory hogs, very annoying
[21:22] <ajmitch> especially the way I use them, where I often can't see the icons on the chrome tabs because I have so many open :)
[22:08] <ajmitch> wendar: just checking, you marked the next meeting as the 23rd rather than the 30th?
[22:09] <wendar> ajmitch: well, that's what Ubuntu Fridge says
[22:09] <wendar> ajmitch: but it could be wrong
[22:09] <ajmitch> that seems a bit broken, it's meant to be the last friday of the month
[22:09] <wendar> ajmitch: is it supposed to be... ah yea
[22:09] <ajmitch> who sets up the fridge calendar entry?
[22:09] <wendar> Fridge won't let me do anything more complicated than "3rd Friday"
[22:09] <ajmitch> great :)
[22:09] <wendar> anyone who has access can edit it
[22:10] <ajmitch> it doesn't allow 5th friday?
[22:10] <wendar> go ahead and update the wiki page
[22:10] <wendar> I suspect it would just drop off the calendar when there is no 5th friday
[22:10] <wendar> what we want is the -1th friday :)
[22:11] <wendar> the 30th actually works better for me this month, I won't have to rush out after the meeting to drive to Seattle
[22:14]  * ajmitch can see where to add an event, but it looks to only be editable by its creator, sorry :)
[22:39] <wendar> ajmitch: I think I actually can't edit it anymore, I only had admin priviledges on my canonical google account, which is gone now
[22:39] <wendar> ajmitch: but, I'll find someone else to edit it
[22:39] <ajmitch> now that is a pain
[22:40] <ajmitch> your membership application is coming up in a meeting today, isn't it?
[22:40] <wendar> ah, yeah
[22:40] <wendar> if I get membership I'll see about getting  calendar editing access again
[22:41] <wendar> or, you or stgraber could get it
[22:47]  * ajmitch shall try & be around at meeting time
[23:45] <ajmitch> stgraber: thanks for looking at harmonySEQ - the postinst/postrm aren't empty unless debhelper is not putting anything in them - I thought that I'd leave in the #DEBHELPER# tags for now
[23:47] <wendar> ajmitch: it's probably safe to remove them entirely
[23:47] <wendar> ajmitch: I've been erring on the side of "rip it out" for ARB apps, just on the general principle of "they're supposed to be dumb and simple"
[23:48] <ajmitch> fair enough
[23:48] <ajmitch> I don't think there are any dh calls in the package at this time which put anything in postinst
[23:52]  * ajmitch shall see if he can get it to ~ppa99 before it even makes it into extras
[23:55] <ajmitch> I see you've got a couple of other testimonials from some well-known ubuntu contributors now