[07:02] good morning [07:11] good morning [07:25] hi dpm [07:25] & dholbach :) [07:25] :) [07:25] dpm: I suppose I should file a bug against qreator - close button didn't work when I was testing it :) [07:30] hi ajmitch, sure, and thanks for testing! [07:30] np, once I figured out the double-click, it looks quite nice :) [07:31] ajmitch, yeah, that's an annoyance of the default behaviour of Gtk.IconView. I don't like it, either. I've filed a bug and asked around, but there doesn't seem to be any way around it: https://bugs.launchpad.net/qreator/+bug/1006635 [07:32] yeah I saw that & the question on askubuntu [07:33] can't reproduce the closing button not working here, but I'm on a newer version from the stable PPA [07:34] by the close button, I mean the one of the help screen [07:36] ah, that one, I fixed that in the last version in the PPA, I just haven't released it as an ARB package [07:37] ok [07:37] ajmitch, https://bugs.launchpad.net/qreator/+bug/1001750 [07:38] ah right, I missed that bug :) [07:39] ajmitch, quick question, what happens exactly after an app has been voted and gets the go-ahead? Is the PPA copied from staging to the ARB ppa and then finally uploaded to extras? [07:40] not copied, re-uploaded to the ARB PPA, and as far as I know, it's an automatic copy from there to extras.ubuntu.com [07:40] ah, I see [07:40] assuming it's not the same thing covered up with a different virtualhost [07:40] * dpm was wondering what the purpose of the ARB PPA was [07:40] now I get it [07:42] looks to be a different server, so I'll assume it's copied automatically [07:43] ah, gotcha [07:43] btw, I should have probably re-submitted qreator 12.05.6 (the staging PPA has 12.05.4), but I didn't want to disrupt the testing that had already been done. Furthermore, the idea of the app is to road-test the app developer process and blog about it, so I might as well test the 'submit an update' path after it's been published too :-) [07:44] ok :) [07:44] odd, extras.ubuntu.com reports the apache2 version that's in hardy [07:44] It's been fun so far, can't wait to get it in the SC, so thanks a lot for the review :) [07:44] I didn't think IS still had any hardy servers :) [07:44] * ajmitch is hoping for more people to respond on the mailing list [07:45] I'm pretty sure it's majority vote, so it goes in once there are 4 +1s from ARB members [07:45] yeah, I'm just happy that it's up for vote already :) [07:45] * ajmitch wouldn't mind changing that to 2 or 3 [07:45] :) [07:46] more that we don't want to block too much on waiting for votes, it's generally been 2 MOTU +1s to get a new package through REVU in the past [07:51] * ajmitch also wishes that unity didn't need to be restarted for new lenses :) [08:02] and there goes another app up for voting \o/ [08:06] dpm: yep, got 1 other to vote on also [08:06] awesome [08:06] trying to get faster on them :) [13:28] wendar: ping [13:29] mhall119: hi [13:30] ajmitch: it's 3 +1 votes [13:30] ajmitch: so, doesn't matter how large or small the group grows [13:31] wendar: hi, I heard you already started on an ARB backend for pkgme, I was hoping I could ask you some questions about it [13:31] ajmitch: that feels about right to me, since one of the votes is usually the person who did the fixup work, and a couple of extra sets of eyes on the work are nice [13:31] mhall119: sure [13:31] wendar: I was told you were making kind of a wrapper around the other backends, is that right? [13:31] mhall119: it's just it's own backend [13:32] is it calling scripts in other backends? [13:32] no [13:32] but, most of the code is in pkgme itself [13:32] and it's using all that code the same [13:32] the backends are quite simple [13:32] oh, then how will it deal with differences between C apps and Python apps? [13:33] or, those using different build systems [13:33] ARB apps are *very* simple, they just leave dh to sort out the difference [13:33] dh is very smart about choosing between running a makefile, versus setup.py, etc [13:34] oh, so what does the ARB backend do then? [13:34] writes a simple debian/rules file for dh, and lets dh do the work [13:35] does it just set the install prefix to /opt/extras.ubuntu.com/? [13:35] that's the main thing, yes [13:35] or do anything with dependencies (build and runtime)/ [13:36] we don't need special values in the control file anymore [13:36] it doesn't do anything with dependencies, because doing that requires executing arbitrary code, which we can't do on the MyApps backend [13:37] (that's why we can't use the regular Python backend) [13:38] it could still be done by the app author to create ARB-ready packages though, for uploading to their PPA [13:39] is you backend code somewhere I can look at it? I'm going to write one for Unity Lenses, but trying to figure out how to deal with them being written in different langauges [13:44] I haven't pushed the branch up yet [13:45] I leave for work in about an hour, but I'll try to get it presentable tonight [13:45] mhall119: it would be nice if the lenses backend used the ARB backend [13:46] they're mostly the same [13:46] wendar: I was told the ARB backend was calling other backends, so I was hoping to be able to chain them along [13:46] (unlike the other backends, which are quite different) [13:48] mhall119: all you really need for lenses is to check that a setup.py exists [13:48] (that's what the Python backend does) [13:48] if it's a Python lens, yes [13:49] but it can by C or Vala or some other language [13:50] the Vala backend searches for files with a .vala extension [13:50] The only place you have to worry about that in the pkgme templates is in the debian/rules file where you set the path to /opt [13:51] because each build system has a different way of setting /opt [13:51] you can also do some limited setting of depends in debian/control [13:51] (i.e. python apps depend on Python) [13:52] otherwise, the generated templates will be the same for every app [13:53] mhall119: the ARB templates can be really simple, they don't need to deal with all the odd edge cases of complex packages [13:53] (in fact, we want them to be simple, we tend to reject complex packages) [13:56] mhall119: the way pkgme works, you don't share code by chaining backends [13:57] mhall119: you share it by adding "helpers" which can be called from any backend [13:57] mhall119: so if we find reusable pieces from other backends, we can generalize them as helpers [13:57] ah, ok [13:58] I hadn't seen anythign about "helper" yet [14:09] they live in pkgme/helpers [14:10] some of the other backends have scripts with just one line [14:10] like backends/vala/package_name [14:11] the one line is 'pkgme_autoconf_package_name' [14:11] which is a helper script [14:12] FYI, the way the ARB backend works, is that the 'want' script checks for a file called 'extras.json' [14:12] if that file exists, then the ARB backend is chosen [14:37] and where does extras.json come from? [15:30] wendar: is the arb backend going to provide apparmor profiles? [15:31] mhall119: it won't, but the lens one can. They're really predictable for lenses/scopes [15:31] mhall119: in fact, that'd be a good idea for a helper [15:31] mhall119: I imagine many backends could benefit from apparmor profiles [15:32] mhall119: There might be some way we could insert a default one into every app [15:32] mhall119: if we assume that the Exec path in the .desktop file is the only code that needs to run [15:32] mhall119: but, it's still tricky to figure out what to allow on top of the default [15:33] mhall119: btw, are you assuming the layout we decided on for ARB-managed lenses/scopes? That might make your job easier [15:33] mhall119: (lens files in a lens/ directory, scope files in a scopes/scopename/ directory) [15:37] wendar: yeah, but now I'm thinking I can use the setup.py or equivilent to tell where to install those [15:37] I'm beginning to think a lens backend doesn't even make sense [15:38] mhall119: it's true that I often set the install path in setup.py for lenses [15:38] mhall119: we might be able to handle lenses inside the regular ARB backend [15:38] that's what I'm thinking [15:38] mhall119: just check if there's a lens/ or scopes/ directory if we need any custom packaging [15:40] you'd probably look for .lens and .scopes files, they may not be in directories [16:03] mhall119: sure, that'd work [16:04] mhall119: just remember the directories they were found in [16:04] (if they're needed for anything) [16:05] they're not, they should be copied to /usr/share/unity/ by debhelper [16:05] either by specifying in setup.py or somewhere else [16:33] mhall119: I generally prefer to do it all in setup.py [16:34] mhall119: specify a fixed path for the parts that can be installed outside /opt [16:34] mhall119: and a variable path for the rest, so they respect --prefix in debian/rules [16:34] mhall119: the best example is http://bazaar.launchpad.net/~app-review-board/ubuntu-app-review-board/unity-scopes-music-extras-precise/view/head:/setup.py [16:36] mhall119: (fixed paths start with /, all other paths will be /usr by default, but added to /opt/extras.ubuntu.com/packagename when that's passed as the --prefix [21:36] morning [21:38] "morning" [21:49] stgraber: so I see you're on the 12.04.1 team for awhile? :) [21:50] yeah === jono is now known as Guest23141