[07:37] #team - do we have any update on the session bugs in the live sessions ? [10:00] brainwash: in case Noskcaj is around again and i'm not until then, the gtk3 indicator patch should be applied as a patch for now (although obviously the goal is a new panel release, but that might take too long, we need testing now rather than after the release) [10:20] morning all [10:20] jjfrv8: ping [12:05] Checked the website - is anyone else having problems with mousepad? [12:50] bbl [13:32] ochosi: not sure I understand what you've said to brainwash - surely what we need is it released properly so that it can be tested, not rely on people fiddling with ppa's and patches [15:46] any xfce upstream devs here? [15:47] who do I need to bribe that upstream releases something which can be rebuilt using dh-autoreconf? [15:47] currently, I need changes like this: http://launchpadlibrarian.net/160507329/xfconf_4.10.0-2_4.10.0-2ubuntu1.diff.gz [15:52] doko, that's a patch against configure script, can you post a patch against configure.ac/Makefile.am? [15:53] andrzejr, no, see http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=726404 [15:53] Debian bug 726404 in libtool "libtool: Backport a new architecture (ppc64le) to Debian" [Wishlist,Open] [15:54] and do you have problem only with xfconf? [15:54] andrzejr, which autoconf and automake versions does xfce require to build the autofiles? [15:54] andrzejr, no, with every package [15:55] so I would prefer if you would use dh-autoreconf for the packaging [15:55] if so, go to #xfce-dev and ping NSchermer, or better drop him an email. [15:55] provided that you can make it work [16:07] doko, this *may* be an issue with xfce4-dev-tools but I am not the person to help you with that [16:10] ok [16:36] hi guys [16:36] https://bugzilla.xfce.org/show_bug.cgi?id=10566 that might be of interest [16:36] bugzilla.xfce.org bug 10566 in General "Display Power Percentage" [Enhancement,New] [17:05] doko, what version of xfce4-dev-tools are you using? [17:14] doko, if you are using a released version (with configure script etc.) it means someone has already used xfce4-dev-tools+autotools. So the version of the latter does not matter. [17:15] I guess that part of the problem is that most of the releases were made quite some time ago, so whoever run "make distcheck" was likely using an old version of autotools. [17:17] It would be interesting if you could re-run autogen.sh and check if the output matches your expectations. [17:22] andrzejr, do you do the ubuntu packaging? [17:22] because dh-autoreconf is supposed to do that. but doesn't. could you give me a recipy what to do for every package? [17:23] no, don't know how dh-* stuff works [17:24] you said you are modifying ./configure script - this script is generated using autotools and xfce-dev-tools. So if it is wrong then something happened when a developer run "make distcheck" when releasing a package. [17:25] andrzejr, sure, but it very depends on the versions of the autotools, not all of them available in ubuntu [17:27] autotools (from the distribution) are only used before making configure script. Once it is ready, the package includes its own copy of all scripts it needs. (which may be out of date if it was released long time ago) [17:29] andrzejr, yes, that's the problem. what's the solution? ;p [17:31] I wonder if just recreating configure script would help. If so, the only thing needed would be another *.1 release. [17:31] Can you try running autogen.sh on your side and see if that helps? [17:32] or git clone the package and run "make distcheck" -> this should produce a ready to use tarball for you. [17:35] hmm, I think I'll wait for one of the xfce packagers. it's not that urgent. let's pick it up later [18:05] andrzejr: the problem is with packaging, not the upstream. A new point upstream release will not help, as we need to update libtool with unreleased libtool-patch (as in not released libtool patch). Unless upstream uses libtool from trusty to generate the tarballs. [19:00] xnox, I see, thank you. Is libtool going to be released anytime soon? We could update dependencies to require it. [22:54] lderan, Any chance you could help me with the gthumb testcase? [22:54] sure thing [22:59] How can i find if an app is open, via app_proxy? There aren't any tests i can base this on [23:05] theres something for getting an app that isn't created by autopilot mmm [23:12] http://paste.ubuntu.com/6626082/ is what i have so far (the fullscreen bit is broken, but that's for later) [23:12] I'm slowly trying to fill in http://packages.qa.ubuntu.com/qatracker/testcases/1588/info [23:15] shall see what i can do :) [23:16] thanks [23:19] Also, how do i find the properties of a window, so i can actually test things? [23:29] mmm [23:31] i shall have to ask the autopilot guy some questions on that front, from the last we talked it he confirmed that we will be able to test it if opens [23:37] lderan, i was talking to dan and elfy, We'll probably make a xubuntu autopilot branch eventually, but catfish, gthumb, and simple scan are what we should start on, since they introspect [23:37] aye [23:58] lderan, Next time you make an autopilot test, could you use docstrings instead of comments to describe each function? [23:59] of course