On 23 March 2015 at 18:05, Felipe Sateler <fsateler at debian.org> wrote: > > > On 23 March 2015 at 03:15, David Henningsson > <david.henningsson at canonical.com> wrote: >> >> >> >> On 2015-03-16 14:49, David Henningsson wrote: >>> >>> >>> >>> On 2015-03-13 14:28, Peter Mattern wrote: >>>> >>>> Hello. >>>> >>>> The number of commits since last pavucontrol release isn't that high but >>>> they do comprehend quite a lot of rather important bug fixes, imo. >>>> >>>> A probably related finding is that compiling 2.0 code on recent systems >>>> seems to have issues. >>>> E. g. on up-to-date Arch Linux x86_64 compiling the usual way seems to >>>> work flawlessly but yields a binary segfaulting right upon start >>>> (systemd journal: 'kernel: traps: pavucontrol[4102] general protection >>>> ip:7f34c9809f3f sp:7fffd8d80820 error:0 in libgobject-2.0.so.0.4200.2'). >>>> Problem can't be seen with Git code. >>>> >>>> So all in all I'm wondering whether a minor or point release of >>>> pavucontrol wouldn't make sense. >>> >>> >>> Indeed it would. I was actually about to do so, but then this flu thing >>> went viral. I'm working on rebuilding myself into a less buggy state >>> again before sneezing out an rc. >> >> >> Hrm, this pavucontrol application seems a bit difficult to test (and I do >> want to test it before I release it...) >> >> How do you others do it? First, if I try an out-of-tree build, it fails >> updating some README file. Second, if I don't, it does compile, but running >> from build directory fails with Gtk::Builder::add_from_file throwing a >> Glib::FileError. Any tricks I'm missing here? > > > In src/Makefile.am a flag is set to point pavucontrol to the glade file: > > pavucontrol_CXXFLAGS+=-DGLADE_FILE=\"$(gladedir)/pavucontrol.glade\" > #pavucontrol_CXXFLAGS+=-DGLADE_FILE=\"pavucontrol.glade\" > > Comment the first and uncomment the second and you will be able to run it. > > That is what I've done to test. Also works to make install first (prefixed install) and then run from the build dir. -- Arun
