29 Mar
2015
29 Mar
'15
5:52 p.m.
And finally, for the wrap of the pre-LAC2015@JGU-Mainz [1] release
party, no other than the 'crown jewel' of the whole Qstuff* bunch ;)
Qtractor 0.6.6 (lazy tachyon beta) is out!
Release highlights:
* LV2 and VST plugins GUI position persistence (NEW)
* MIDI clip editor record/overdub note rendering (FIX)
* VST plugin recursive discovery/search path (NEW)
* VST-shell sub-plugins support (FIX)
* also some old and new lurking bugs squashed.
Qtractor [2] is an audio/MIDI multi-track sequencer application written
in C++ with the Qt4 framework. Target platform is Linux, where the Jack
Audio Connection Kit (JACK [3]) for audio and the Advanced Linux Sound
Architecture (ALSA [4]) for MIDI are the main infrastructures to evolve
as a fairly-featured Linux desktop audio workstation GUI, specially
dedicated to the personal home-studio.
Website:
http://qtractor.sourceforge.net
Project page:
http://sourceforge.net/projects/qtractor
Downloads:
http://sourceforge.net/projects/qtractor/files
- source tarball:
http://download.sourceforge.net/qtractor/qtractor-0.6.6.tar.gz
- source package (openSUSE 13.2):
http://download.sourceforge.net/qtractor/qtractor-0.6.6-16.rncbc.suse132.sr…
- binary packages (openSUSE 13.2):
http://download.sourceforge.net/qtractor/qtractor-0.6.6-16.rncbc.suse132.i5…
http://download.sourceforge.net/qtractor/qtractor-0.6.6-16.rncbc.suse132.x8…
- quick start guide & user manual (see also: the wiki):
http://download.sourceforge.net/qtractor/qtractor-0.5.x-user-manual.pdf
- wiki (help really wanted!):
http://sourceforge.net/p/qtractor/wiki/
Weblog (upstream support):
http://www.rncbc.org
License:
Qtractor is free, open-source software, distributed under the terms
of the GNU General Public License (GPL [5]) version 2 or later.
Change-log:
- MIDI clip record/reopen to/from SMF format 0 has been fixed.
- LV2 and VST plugins GUI editor widget position is preserved across
hide/show cycles.
- Added application description as freedesktop.org's AppData [6].
- Added a "Don't ask this again" prompt option to zip/archive extrated
directory removal/replace warning messages.
- MIDI clip editor (aka. piano-roll) gets lingering notes properly shown
while on record/overdubbing.
- Current highlighted client/port connections are now drawn with thicker
connector lines.
- Fixing segfaults due to QClipboard::mimeData() returning an invalid
null pointer while on Qt5 and Weston.
- Return of an old hack/fix for some native VST plugins with GUI editor,
on whether to skip the explicit shared library unloading on close and
thus avoid some mysterious crashes on session and/or application exit.
- Force reset of plugin selection list when any of the plugin search
paths change (in View/Options.../Plugins/Paths).
- Recursive VST plugin search is now in effect for inventory and
discovery on path sub-directories (VST only).
- Non-dummy scannig for regular VST, non-shell plugins, were doomed to
infinite-loop freezes on discovery, now fixed.
References:
[1] LAC2015@JGU-Mainz - Linux Audio Conference 2015
The Open Source Music and Sound Conference
April 9-12 @ Johannes Gutenberg University (JGU) Mainz, Germany
http://lac.linuxaudio.org/2015/
[2] Qtractor - An audio/MIDI multi-track sequencer
http://qtractor.sourceforge.net
[3] JACK Audio Connection Kit
http://jackaudio.org
[4] ALSA, Advanced Linux Sound Architecture
http://www.alsa-project.org/
[5] GPL - GNU General Public License
http://www.gnu.org/copyleft/gpl.html
[6] AppData Specification
http://people.freedesktop.org/~hughsient/appdata/
See also:
http://www.rncbc.org/drupal/node/879
Enjoy && keep the fun.
--
rncbc aka. Rui Nuno Capela
29 Mar
29 Mar
8:39 p.m.
Can't compile it here on 64bit debian jessie using sourceforge download.
End of configure messages:
JACK Session support . . . . . . . . . . . . . . .: yes
JACK Latency support . . . . . . . . . . . . . . .: yes
JACK Metadata support . . . . . . . . . . . . . .: yes
Non Session Management (NSM) support . . . . . . .: yes
X11 Unique/Single instance . . . . . . . . . . . .: no
VeSTige header support . . . . . . . . . . . . . .: yes
Gradient eye-candy . . . . . . . . . . . . . . . .: yes
Debugger stack-trace (gdb) . . . . . . . . . . . .: no
Install prefix . . . . . . . . . . . . . . . . . .: /usr/local
Only those two 'no's. Are they significant?
Compile problems start here:
In file included
from /usr/include/x86_64-linux-gnu/qt5/QtWidgets/QApplication:1:0,
from .ui/ui_qtractorMainForm.h:36, from qtractorMainForm.h:25,
from qtractor.cpp:24:
/usr/include/x86_64-linux-gnu/qt5/QtWidgets/qapplication.h:111:24: error:
missing binary operator before token "(" #if QT_DEPRECATED_SINCE(5, 0)
^
/usr/include/x86_64-linux-gnu/qt5/QtWidgets/qapplication.h:151:24: error:
missing binary operator before token "(" #if QT_DEPRECATED_SINCE(5, 0)
^
/usr/include/x86_64-linux-gnu/qt5/QtWidgets/qapplication.h:181:24: error:
missing binary operator before token "(" #if QT_DEPRECATED_SINCE(5, 0)
^
In file included
from /usr/include/x86_64-linux-gnu/qt5/QtWidgets/qabstractitemview.h:47:0,
from /usr/include/x86_64-linux-gnu/qt5/QtWidgets/qheaderview.h:45,
from /usr/include/x86_64-linux-gnu/qt5/QtWidgets/QHeaderView:1,
from .ui/ui_qtractorMainForm.h:38, from qtractorMainForm.h:25,
from qtractor.cpp:24:
/usr/include/x86_64-linux-gnu/qt5/QtCore/qitemselectionmodel.h:93:24: error:
missing binary operator before token "(" #if QT_DEPRECATED_SINCE(5, 0)
9:01 p.m.
On Sunday 29 March 2015 19:39:44 Will Godfrey wrote:
Can't compile it here on 64bit debian jessie using
sourceforge download.
End of configure messages:
JACK Session support . . . . . . . . . . . . . . .: yes
JACK Latency support . . . . . . . . . . . . . . .: yes
JACK Metadata support . . . . . . . . . . . . . .: yes
Non Session Management (NSM) support . . . . . . .: yes
X11 Unique/Single instance . . . . . . . . . . . .: no
VeSTige header support . . . . . . . . . . . . . .: yes
Gradient eye-candy . . . . . . . . . . . . . . . .: yes
Debugger stack-trace (gdb) . . . . . . . . . . . .: no
Install prefix . . . . . . . . . . . . . . . . . .: /usr/local
Only those two 'no's. Are they significant?
Compile problems start here:
In file included
from /usr/include/x86_64-linux-gnu/qt5/QtWidgets/QApplication:1:0,
from .ui/ui_qtractorMainForm.h:36, from qtractorMainForm.h:25,
from qtractor.cpp:24:
/usr/include/x86_64-linux-gnu/qt5/QtWidgets/qapplication.h:111:24: error:
missing binary operator before token "(" #if QT_DEPRECATED_SINCE(5, 0)
^
/usr/include/x86_64-linux-gnu/qt5/QtWidgets/qapplication.h:151:24: error:
missing binary operator before token "(" #if QT_DEPRECATED_SINCE(5, 0)
^
/usr/include/x86_64-linux-gnu/qt5/QtWidgets/qapplication.h:181:24: error:
missing binary operator before token "(" #if QT_DEPRECATED_SINCE(5, 0)
^
In file included
from /usr/include/x86_64-linux-gnu/qt5/QtWidgets/qabstractitemview.h:47:0,
from /usr/include/x86_64-linux-gnu/qt5/QtWidgets/qheaderview.h:45,
from /usr/include/x86_64-linux-gnu/qt5/QtWidgets/QHeaderView:1,
from .ui/ui_qtractorMainForm.h:38, from qtractorMainForm.h:25,
from qtractor.cpp:24:
/usr/include/x86_64-linux-gnu/qt5/QtCore/qitemselectionmodel.h:93:24: error:
missing binary operator before token "(" #if QT_DEPRECATED_SINCE(5, 0)
Those "nos" are correct and not problematic.
This cannot build because no matter what I choose, it is building with qt5
includes!
If I run qmake-qt4 before the ./configure, I can get around that, but then,
other problems begin: The vst, lilv and other includes are not found unless I
copy them to src and in appropriate subdirectories. ./configure responds
problematically but the compilations proceeds. Finally, the distro lacks
lv2_atom_helpers.h so end of trial.
10:07 p.m.
On Sun, 29 Mar 2015 22:00:59 +0300
David Baron <d_baron(a)012.net.il> wrote:
This cannot build because no matter what I choose, it
is building with qt5
includes!
I hadn't noticed that :(
Hmmm.
I thought qt 4 & 5 were supposed to be able to work side-by-side.
--
Will J Godfrey
http://www.musically.me.uk
Say you have a poem and I have a tune.
Exchange them and we can both have a poem, a tune, and a song.
11:57 p.m.
On 03/29/2015 09:07 PM, Will Godfrey wrote:
On Sun, 29 Mar 2015 22:00:59 +0300
David Baron <d_baron(a)012.net.il> wrote:
you can either build for qt4 *or* qt5 but not both.
if you have both development libraries and headers installed, guess it's
libqt4-dev and libqt5-dev on debian, you should state at configure time
which on do you target. eg.
./configure --enable-qt5
./configure --with-qt5=/path/to/qt5 (ie. where bin, lib* and include
sub-directories are located)
nb. configure assumes --enable-qt4 by default.
although all qstuff can be built on qt5 it is still NOT the recommended
target, specially for qtractor where you miss some important lv2 plugin
gui support: libsuil doesn't work with qt5 and probably never will. sorry.
hth.
cheers.
--
rncbc aka. Rui Nuno Capela
--
rncbc aka. Rui Nuno Capela
--
rncbc aka. Rui Nuno Capela
This cannot build because no matter what I
choose, it is building with qt5
includes!
I hadn't noticed that :(
Hmmm.
I thought qt 4 & 5 were supposed to be able to work side-by-side.
30 Mar
30 Mar
9:23 a.m.
On Sunday 29 March 2015 22:57:39 Rui Nuno Capela wrote:
On 03/29/2015 09:07 PM, Will Godfrey wrote:
Yes. Demands Qt5.1. Problem is that specifying qt4 did not work.
On Sun, 29 Mar 2015 22:00:59 +0300
David Baron <d_baron(a)012.net.il> wrote:
you can either build for qt4 *or* qt5 but not both. This cannot build because no matter what I
choose, it is building with
qt5
includes!
I hadn't noticed that :(
Hmmm.
I thought qt 4 & 5 were supposed to be able to work side-by-side.
if you have both development libraries and headers installed, guess it's
libqt4-dev and libqt5-dev on debian, you should state at configure time
which on do you target. eg.
./configure --enable-qt5
./configure --with-qt5=/path/to/qt5 (ie. where bin, lib* and include
sub-directories are located)
nb. configure assumes --enable-qt4 by default.
although all qstuff can be built on qt5 it is still NOT the recommended
target, specially for qtractor where you miss some important lv2 plugin
gui support: libsuil doesn't work with qt5 and probably never will. sorry.
The other dependencies are also not up-to-date, even for qt4. Might need to
wait for the Debian maintainers to update the distro's package (currently
0.6.5, no terribly older).
9:59 a.m.
On Monday 30 March 2015 10:23:01 David Baron wrote:
On Sunday 29 March 2015 22:57:39 Rui Nuno Capela
wrote:
Version available on qt-apps.org also has dependency problems along with other
packages by this author: Wants libjack0, jackd1 while the distro is upt to
jackd2, so will remove the newer for the older.
Unholy mess.
On 03/29/2015 09:07 PM, Will Godfrey wrote:
Yes. Demands Qt5.1. Problem is that specifying qt4 did not work.
On Sun, 29 Mar 2015 22:00:59 +0300
David Baron <d_baron(a)012.net.il> wrote:
you can either build for qt4 *or* qt5 but not both. This cannot build because no matter what I
choose, it is building with
qt5
includes!
I hadn't noticed that :(
Hmmm.
I thought qt 4 & 5 were supposed to be able to work side-by-side. if you have both development libraries and
headers installed, guess it's
libqt4-dev and libqt5-dev on debian, you should state at configure time
which on do you target. eg.
./configure --enable-qt5
./configure --with-qt5=/path/to/qt5 (ie. where bin, lib* and include
sub-directories are located)
nb. configure assumes --enable-qt4 by default.
although all qstuff can be built on qt5 it is still NOT the recommended
target, specially for qtractor where you miss some important lv2 plugin
gui support: libsuil doesn't work with qt5 and probably never will. sorry.
The other dependencies are also not up-to-date, even for qt4. Might need to
wait for the Debian maintainers to update the distro's package (currently
0.6.5, no terribly older).
10:08 a.m.
On 03/30/2015 08:23 AM, David Baron wrote:
maybe you can try the always up-to-date kxstudio repos.?
http://kxstudio.sourceforge.net/Repositories
byee
--
rncbc aka. Rui Nuno Capela
On Sunday 29 March 2015 22:57:39 Rui Nuno Capela
wrote:
maybe debian is promoting libqt5-dev search paths ahead of libqt4-dev ?
what gives when you just type and enter `qmake --version` on regular
terminal console? check if the path is a symlink.
On 03/29/2015 09:07 PM, Will Godfrey wrote:
Yes. Demands Qt5.1. Problem is that specifying qt4 did not work.
On Sun, 29 Mar 2015 22:00:59 +0300
David Baron <d_baron(a)012.net.il> wrote:
you can either build for qt4 *or* qt5 but not both. This cannot build because no matter what I
choose, it is building with
qt5
includes!
I hadn't noticed that :(
Hmmm.
I thought qt 4 & 5 were supposed to be able to work side-by-side.
if you have both development libraries and headers installed, guess it's
libqt4-dev and libqt5-dev on debian, you should state at configure time
which on do you target. eg.
./configure --enable-qt5
./configure --with-qt5=/path/to/qt5 (ie. where bin, lib* and include
sub-directories are located)
nb. configure assumes --enable-qt4 by default.
although all qstuff can be built on qt5 it is still NOT the recommended
target, specially for qtractor where you miss some important lv2 plugin
gui support: libsuil doesn't work with qt5 and probably never will. sorry.
The other dependencies are also not up-to-date, even for qt4. Might need to
wait for the Debian maintainers to update the distro's package (currently
0.6.5, no terribly older).
10:27 a.m.
On 03/30/2015 10:08 AM, Rui Nuno Capela wrote:
maybe you can try the always up-to-date kxstudio
repos.?
http://kxstudio.sourceforge.net/Repositories
If you just want the qtractor deb and not the full kxstudio repos, you
can get the debs from here:
https://launchpad.net/~kxstudio-debian/+archive/ubuntu/apps/+sourcepub/4868…
(you'll see in the qtractor about window that all features are enabled)
10:31 a.m.
On 03/30/2015 10:27 AM, Filipe Coelho wrote:
On 03/30/2015 10:08 AM, Rui Nuno Capela wrote:
errm, if you want to install that you'll also need this:
https://launchpad.net/~kxstudio-debian/+archive/ubuntu/libs/+sourcepub/4811…
(the suil-libs package, ignore the suil-static one).
maybe you can try the always up-to-date kxstudio
repos.?
http://kxstudio.sourceforge.net/Repositories
If you just want the qtractor deb and not the full kxstudio repos, you
can get the debs from here:
https://launchpad.net/~kxstudio-debian/+archive/ubuntu/apps/+sourcepub/4868…
(you'll see in the qtractor about window that all features are enabled)
10:32 a.m.
Am 30.03.2015 um 09:23 schrieb David Baron:
The other dependencies are also not up-to-date, even
for qt4. Might need to
wait for the Debian maintainers to update the distro's package (currently
0.6.5, no terribly older).
Builds just out of the box here on debian/sid
qmake --version
QMake version 2.01a
Using Qt version 4.8.6 in /usr/lib/x86_64-linux-gnu
11:40 a.m.
On Monday 30 March 2015 10:32:34 Hermann Meyer wrote:
Am 30.03.2015 um 09:23 schrieb David Baron:
32bit or 64bit? Believe 64-bit has the problems for whatever reason.
The other dependencies are also not up-to-date,
even for qt4. Might need
to
wait for the Debian maintainers to update the distro's package (currently
0.6.5, no terribly older).
Builds just out of the box here on debian/sid
qmake --version
QMake version 2.01a
Using Qt version 4.8.6 in /usr/lib/x86_64-linux-gnu
11:51 a.m.
Am 30.03.2015 um 11:39 schrieb David Baron:
On Monday 30 March 2015 10:32:34 Hermann Meyer wrote:
/usr/lib/x86_64-linux-gnu -> 64-bit
Am 30.03.2015 um 09:23 schrieb David Baron:
32bit or 64bit? Believe 64-bit
has the problems for whatever reason.
_______________________________________________ The other dependencies are also not up-to-date,
even for qt4. Might need
to
wait for the Debian maintainers to update the distro's package (currently
0.6.5, no terribly older).
Builds just out of the box here on debian/sid
qmake --version
QMake version 2.01a
Using Qt version 4.8.6 in /usr/lib/x86_64-linux-gnu
12:11 p.m.
On Monday 30 March 2015 11:51:13 Hermann Meyer wrote:
Am 30.03.2015 um 11:39 schrieb David Baron:
My qmake --version yields:
QMake version 3.0
Using Qt version 5.3.2 in /usr/lib/x86_64-linux-gnu
So I moved /usr/bin/qmake -> qtchooser out of the way and symlinked to qmake-
qt4
So far, building OK, not kicking at aeffect.h, lilv.h, etc. like it did when I
manually ran qmake-qt4 before ./configure.
Now what would I do when I want qt5 (if it is really ready to play on this
distro).
On Monday 30 March 2015 10:32:34 Hermann Meyer
wrote:
/usr/lib/x86_64-linux-gnu -> 64-bit
Am 30.03.2015 um 09:23 schrieb David Baron:
32bit or 64bit? Believe 64-bit has the problems for whatever reason.
_______________________________________________ The other dependencies are also not up-to-date,
even for qt4. Might need
to
wait for the Debian maintainers to update the distro's package
(currently
0.6.5, no terribly older).
Builds just out of the box here on debian/sid
qmake --version
QMake version 2.01a
Using Qt version 4.8.6 in /usr/lib/x86_64-linux-gnu
12:28 p.m.
On 03/30/2015 11:11 AM, David Baron wrote:
My qmake --version yields:
QMake version 3.0
Using Qt version 5.3.2 in /usr/lib/x86_64-linux-gnu
So I moved /usr/bin/qmake -> qtchooser out of the way and symlinked to qmake-
qt4
So far, building OK, not kicking at aeffect.h, lilv.h, etc. like it did when I
manually ran qmake-qt4 before ./configure.
Now what would I do when I want qt5 (if it is really ready to play on this
distro).
1. revert the symlink switch you've made;
2. ask the debian dudes how to work properly with that "qtchooser" thing
which is said to be a "wrapper to select between qt development binary
versions" according to its own manifest.
byee
--
rncbc aka. Rui Nuno Capela
12:43 p.m.
On Monday 30 March 2015 11:28:22 Rui Nuno Capela wrote:
On 03/30/2015 11:11 AM, David Baron wrote:
Yes, I will file the bug.
Note that after the compile completed successfully, the install failed trying
to do translations off the qt5.
$ sudo make install
lupdate: could not exec '/usr/lib/x86_64-linux-gnu/qt5/bin/lupdate': No such
file or directory
Makefile:314: recipe for target 'translations_lupdate' failed
make: *** [translations_lupdate] Error 1
So I manually ran qmake-qt4, then sudo make install and it worked.
My qmake --version yields:
QMake version 3.0
Using Qt version 5.3.2 in /usr/lib/x86_64-linux-gnu
So I moved /usr/bin/qmake -> qtchooser out of the way and symlinked to
qmake- qt4
So far, building OK, not kicking at aeffect.h, lilv.h, etc. like it did
when I manually ran qmake-qt4 before ./configure.
Now what would I do when I want qt5 (if it is really ready to play on this
distro).
1. revert the symlink switch you've made;
2. ask the debian dudes how to work properly with that "qtchooser" thing
which is said to be a "wrapper to select between qt development binary
versions" according to its own manifest.
byee
3:53 p.m.
On 03/30/2015 11:43 AM, David Baron wrote:
On Monday 30 March 2015 11:28:22 Rui Nuno Capela
wrote:
note that it is not a bug. at least from my pov. what you should do is
about making qtchooser to select the qt4 development environment,
instead of keeping to qt5 as it seems to be the default.
maybe reading `man qtchooser` might help you there
On 03/30/2015 11:11 AM, David Baron wrote:
Yes, I will file the bug. My qmake --version yields:
QMake version 3.0
Using Qt version 5.3.2 in /usr/lib/x86_64-linux-gnu
So I moved /usr/bin/qmake -> qtchooser out of the way and symlinked to
qmake- qt4
So far, building OK, not kicking at aeffect.h, lilv.h, etc. like it did
when I manually ran qmake-qt4 before ./configure.
Now what would I do when I want qt5 (if it is really ready to play on this
distro).
1. revert the symlink switch you've made;
2. ask the debian dudes how to work properly with that "qtchooser" thing
which is said to be a "wrapper to select between qt development binary
versions" according to its own manifest.
byee Note that after the compile completed successfully,
the install failed trying
to do translations off the qt5.
$ sudo make install
lupdate: could not exec '/usr/lib/x86_64-linux-gnu/qt5/bin/lupdate': No such
file or directory
Makefile:314: recipe for target 'translations_lupdate' failed
make: *** [translations_lupdate] Error 1
So I manually ran qmake-qt4, then sudo make install and it worked.
byee
--
rncbc aka. Rui Nuno Capela
4:25 p.m.
On Monday 30 March 2015 14:53:20 Rui Nuno Capela wrote:
On 03/30/2015 11:43 AM, David Baron wrote:
OK. One must set (export) a QT_SELECT=4 or such before running ./configure.
Since qmake never needed such an environment variable or argument before, I do
consider this a bug. An example is that the ./configure here did not set that
variable or supply an argument based on choices made by its qt choice argment.
No one knew one needed it and the ./configure --help said that qt4 was default.
So Rui, please implement (and the default qt4) in the configure.
On Monday 30 March 2015 11:28:22 Rui Nuno Capela
wrote:
note that it is not a bug. at least from my pov. what you should do is
about making qtchooser to select the qt4 development environment,
instead of keeping to qt5 as it seems to be the default.
maybe reading `man qtchooser` might help you there
On 03/30/2015 11:11 AM, David Baron wrote:
Yes, I will file the bug. My qmake --version yields:
QMake version 3.0
Using Qt version 5.3.2 in /usr/lib/x86_64-linux-gnu
So I moved /usr/bin/qmake -> qtchooser out of the way and symlinked to
qmake- qt4
So far, building OK, not kicking at aeffect.h, lilv.h, etc. like it did
when I manually ran qmake-qt4 before ./configure.
Now what would I do when I want qt5 (if it is really ready to play on
this
distro).
1. revert the symlink switch you've made;
2. ask the debian dudes how to work properly with that "qtchooser" thing
which is said to be a "wrapper to select between qt development binary
versions" according to its own manifest.
byee
4:45 p.m.
On 03/30/2015 03:25 PM, David Baron wrote:
On Monday 30 March 2015 14:53:20 Rui Nuno Capela
wrote:
excuse me :)
qtchooser, and thus the QT_SELECT switch, is probably a debian exclusive
thing, meaning that it's specific to some debian packaging policy,
organization and whatever--it is NOT a Qt thing and might not apply to
other distros or environments so easily, mainly because there's no
qtchooser package installed nor even available.
cheers
--
rncbc aka. Rui Nuno Capela
On 03/30/2015 11:43 AM, David Baron wrote:
OK. One must set (export) a QT_SELECT=4 or such before running ./configure.
Since qmake never needed such an environment variable or argument before, I do
consider this a bug. An example is that the ./configure here did not set that
variable or supply an argument based on choices made by its qt choice argment.
No one knew one needed it and the ./configure --help said that qt4 was default.
So Rui, please implement (and the default qt4) in the configure.
On Monday 30 March 2015 11:28:22 Rui Nuno Capela
wrote:
note that it is not a bug. at least from my pov. what you should do is
about making qtchooser to select the qt4 development environment,
instead of keeping to qt5 as it seems to be the default.
maybe reading `man qtchooser` might help you there
On 03/30/2015 11:11 AM, David Baron wrote:
> My qmake --version yields:
> QMake version 3.0
> Using Qt version 5.3.2 in /usr/lib/x86_64-linux-gnu
>
> So I moved /usr/bin/qmake -> qtchooser out of the way and symlinked to
> qmake- qt4
>
> So far, building OK, not kicking at aeffect.h, lilv.h, etc. like it did
> when I manually ran qmake-qt4 before ./configure.
>
> Now what would I do when I want qt5 (if it is really ready to play on
> this
> distro).
1. revert the symlink switch you've made;
2. ask the debian dudes how to work properly with that "qtchooser" thing
which is said to be a "wrapper to select between qt development binary
versions" according to its own manifest.
byee
Yes, I will file the bug.
4:49 p.m.
On 03/30/2015 03:44 PM, Rui Nuno Capela wrote:
might be mistaken however ;)
byee
--
rncbc aka. Rui Nuno Capela
OK. One must set (export) a QT_SELECT=4 or such before running
./configure.
Since qmake never needed such an environment variable or argument
before, I do
consider this a bug. An example is that the ./configure here did not
set that
variable or supply an argument based on choices made by its qt choice
argment.
No one knew one needed it and the ./configure --help said that qt4 was
default.
So Rui, please implement (and the default qt4) in the configure.
excuse me :)
qtchooser, and thus the QT_SELECT switch, is probably a debian exclusive
thing, meaning that it's specific to some debian packaging policy,
organization and whatever--it is NOT a Qt thing and might not apply to
other distros or environments so easily, mainly because there's no
qtchooser package installed nor even available.
5:11 p.m.
On 30/03/15 21:49, Rui Nuno Capela wrote:
On 03/30/2015 03:44 PM, Rui Nuno Capela wrote:
might be mistaken however ;)
byee
Definitely seems to be part of Qt.
https://qt.gitorious.org/qt/qtchooser/source/ae5eeef85c9a818bfa6a3e03511e39…:
http://qt-project.org/search?search=qtchooser
D.
OK. One must set (export) a QT_SELECT=4 or such before running
./configure.
Since qmake never needed such an environment variable or argument
before, I do
consider this a bug. An example is that the ./configure here did not
set that
variable or supply an argument based on choices made by its qt choice
argment.
No one knew one needed it and the ./configure --help said that qt4 was
default.
So Rui, please implement (and the default qt4) in the configure.
excuse me :)
qtchooser, and thus the QT_SELECT switch, is probably a debian exclusive
thing, meaning that it's specific to some debian packaging policy,
organization and whatever--it is NOT a Qt thing and might not apply to
other distros or environments so easily, mainly because there's no
qtchooser package installed nor even available.
5:27 p.m.
On 03/30/2015 04:10 PM, Dale Kazakore Powell wrote:
On 30/03/15 21:49, Rui Nuno Capela wrote:
so i was mistaken when sadd qtchooser is not a qt thing. my bad ;)
but the rest of the excuse still applies:
the onus of the desired/current QT_SELECT setting should be left to the
user and not hard-coded on a configure script, at least for the time being.
byee
--
rncbc aka. Rui Nuno Capela
On 03/30/2015 03:44 PM, Rui Nuno Capela wrote:
might be mistaken however ;)
byee
Definitely seems to be part of Qt.
https://qt.gitorious.org/qt/qtchooser/source/ae5eeef85c9a818bfa6a3e03511e39…:
http://qt-project.org/search?search=qtchooser
OK. One must set (export) a QT_SELECT=4 or such before running
./configure.
Since qmake never needed such an environment variable or argument
before, I do
consider this a bug. An example is that the ./configure here did not
set that
variable or supply an argument based on choices made by its qt choice
argment.
No one knew one needed it and the ./configure --help said that qt4 was
default.
So Rui, please implement (and the default qt4) in the configure.
excuse me :)
qtchooser, and thus the QT_SELECT switch, is probably a debian exclusive
thing, meaning that it's specific to some debian packaging policy,
organization and whatever--it is NOT a Qt thing and might not apply to
other distros or environments so easily, mainly because there's no
qtchooser package installed nor even available.
6:26 p.m.
On Mon, 30 Mar 2015 16:27:16 +0100
Rui Nuno Capela <rui.capela(a)gmail.com> wrote:
On 03/30/2015 04:10 PM, Dale Kazakore Powell wrote:
OK, this now works for me.
Although I can see your argument, it's not much help when the user is quite
unaware of what the issue is. Before compiling unknown software I *always*
checkout the README file (if it exists), and there is no mention there of
possible contention between qt 4 & 5.
Why not simply add something like this at the top:
WARNING
Qtractor is intended to be compiled with qt version 4
Before running config you may need to enter:
export QT_SELECT=4
--
Will J Godfrey
http://www.musically.me.uk
Say you have a poem and I have a tune.
Exchange them and we can both have a poem, a tune, and a song.
On 30/03/15 21:49, Rui Nuno Capela wrote:
so i was mistaken when sadd qtchooser is not a qt thing. my bad ;)
but the rest of the excuse still applies:
the onus of the desired/current QT_SELECT setting should be left to the
user and not hard-coded on a configure script, at least for the time being.
byee On 03/30/2015 03:44 PM, Rui Nuno Capela wrote:
Definitely seems to be part of Qt.
https://qt.gitorious.org/qt/qtchooser/source/ae5eeef85c9a818bfa6a3e03511e39…:
http://qt-project.org/search?search=qtchooser
>
> OK. One must set (export) a QT_SELECT=4 or such before running
> ./configure.
> Since qmake never needed such an environment variable or argument
> before, I do
> consider this a bug. An example is that the ./configure here did not
> set that
> variable or supply an argument based on choices made by its qt choice
> argment.
> No one knew one needed it and the ./configure --help said that qt4 was
> default.
>
> So Rui, please implement (and the default qt4) in the configure.
excuse me :)
qtchooser, and thus the QT_SELECT switch, is probably a debian exclusive
thing, meaning that it's specific to some debian packaging policy,
organization and whatever--it is NOT a Qt thing and might not apply to
other distros or environments so easily, mainly because there's no
qtchooser package installed nor even available.
might be mistaken however ;)
byee
6:47 p.m.
On 03/30/2015 05:27 PM, Will Godfrey wrote:
On Mon, 30 Mar 2015 16:27:16 +0100
Rui Nuno Capela <rui.capela(a)gmail.com> wrote:
because qtractor is not really intended to be strictly compiled with
qt4. it can be compiled to qt5 as well, only that the former is still
the recommended way (as is the default on configure).
one other problem is that the possible values for QT_SELECT might not be
so simple as either "4" or "5" (is it?). it probably depends on what
you
have installed and whether it's provided and available on your distro.
for instance, my distro (opensuse) has no such thing, maybe just yet.
qtchooser doesn't even come with the official/stock/vanilla qt5 binary
packaging (as from qt-project.org and qt.io) which are the ones i've
been testing my qt5 builds. maybe it's considered an extra, an ad-hoc
utility, targeted to distro packagers... i can't really tell.
byee
--
rncbc aka. Rui Nuno Capela
On 03/30/2015 04:10 PM, Dale Kazakore Powell
wrote:
OK, this now works for me.
Although I can see your argument, it's not much help when the user is quite
unaware of what the issue is. Before compiling unknown software I *always*
checkout the README file (if it exists), and there is no mention there of
possible contention between qt 4 & 5.
Why not simply add something like this at the top:
WARNING
Qtractor is intended to be compiled with qt version 4
Before running config you may need to enter:
export QT_SELECT=4
On 30/03/15 21:49, Rui Nuno Capela wrote:
so i was mistaken when sadd qtchooser is not a qt thing. my bad ;)
but the rest of the excuse still applies:
the onus of the desired/current QT_SELECT setting should be left to the
user and not hard-coded on a configure script, at least for the time being.
byee On 03/30/2015 03:44 PM, Rui Nuno Capela wrote:
>>
>> OK. One must set (export) a QT_SELECT=4 or such before running
>> ./configure.
>> Since qmake never needed such an environment variable or argument
>> before, I do
>> consider this a bug. An example is that the ./configure here did not
>> set that
>> variable or supply an argument based on choices made by its qt choice
>> argment.
>> No one knew one needed it and the ./configure --help said that qt4 was
>> default.
>>
>> So Rui, please implement (and the default qt4) in the configure.
>
> excuse me :)
>
> qtchooser, and thus the QT_SELECT switch, is probably a debian exclusive
> thing, meaning that it's specific to some debian packaging policy,
> organization and whatever--it is NOT a Qt thing and might not apply to
> other distros or environments so easily, mainly because there's no
> qtchooser package installed nor even available.
might be mistaken however ;)
byee
Definitely seems to be part of Qt.
https://qt.gitorious.org/qt/qtchooser/source/ae5eeef85c9a818bfa6a3e03511e39…:
http://qt-project.org/search?search=qtchooser
5:24 p.m.
On Monday 30 March 2015 15:49:48 Rui Nuno Capela wrote:
On 03/30/2015 03:44 PM, Rui Nuno Capela wrote:
might be mistaken however ;)
Yeah, there are loads of distros out there (Debian/Ubuntu are major players),
but ...
If things were sooo simple, then a Makefile could be supplied and simply make
and run. Many of the plugins are distributed this way!
Configure is there for a purpose. Does not mean one must cater to every distro-
unique feature, but configure scripts do test OS versions, features, etc., to
enable transportability. So this QT_SELECT maybe does belong there.
OK. One
must set (export) a QT_SELECT=4 or such before running
./configure.
Since qmake never needed such an environment variable or argument
before, I do
consider this a bug. An example is that the ./configure here did not
set that
variable or supply an argument based on choices made by its qt choice
argment.
No one knew one needed it and the ./configure --help said that qt4 was
default.
So Rui, please implement (and the default qt4) in the configure.
excuse me :)
qtchooser, and thus the QT_SELECT switch, is probably a debian exclusive
thing, meaning that it's specific to some debian packaging policy,
organization and whatever--it is NOT a Qt thing and might not apply to
other distros or environments so easily, mainly because there's no
qtchooser package installed nor even available.
3324
days inactive
3325
days old
linux-audio-user@lists.linuxaudio.org
24 comments
6 participants
participants (6)
-
Dale Kazakore Powell -
David Baron -
Filipe Coelho -
Hermann Meyer -
Rui Nuno Capela -
Will Godfrey