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. -- Saludos, Felipe Sateler -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/pulseaudio-discuss/attachments/20150323/2890a1b9/attachment.html>
