Sorry for the mis-threading (my replies to this list haven't been working
right recently), but...
As for thiago's proposal:
> 1) the binaries from Qt company must also perform this step
> 2) the documentation has to be updated to include the "6" at the end too
+1 (+million),
this proposal
Thiago Macieira wrote:
> On quarta-feira, 11 de outubro de 2017 13:39:03 PDT Rex Dieter wrote:
>> The patch's purpose looks appealing, are there "reasons(tm)" it cannot be
>> used by default upstream?
>
> Yeah: we don't want to.
>
> It would make the lives
Thiago Macieira wrote:
> On terça-feira, 10 de outubro de 2017 23:56:08 PDT Martin Koller wrote:
>> Hi,
>>
>> on openSuse 42.2 I have a self-built 5.9.1 version and also the openSuse
>> 5.9.1 installed one. For some reason (which is not important for my
>> question) my application picks up the
Curious what plans or eta is for a Qt 5.6.1 release?
http://wiki.qt.io/Qt-5.6-release
doesn't mention it.
-- Rex
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
Takahiro Hashimoto wrote:
> And I don't know if the older version of Qt5(5.0,5.1..) could be built
> with gcc 4.4...
They could, including Qt 5.5.x. I am currently providing RHEL 6/7 Qt5
packages via
https://fedoraproject.org/wiki/EPEL
I started this thread because EPEL by policy doesn't
Rex Dieter wrote:
> I'm trying to build(bootstrap) qt-5.6.0-beta stack on rhel6, and have run
> into a build failure in qtdeclarative,
...
> Is this some platform/compiler issue?
>
> fwiw, using gcc-4.4.7-16.el6.
It would appear that
http://doc.qt.io/QtSupportedPlatforms/index.
I'm trying to build(bootstrap) qt-5.6.0-beta stack on rhel6, and have run
into a build failure in qtdeclarative,
make[2]: Entering directory `/builddir/build/BUILD/qtdeclarative-opensource-
src-5.6.0-beta/x86_64-redhat-linux-gnu/tools/qmlimportscanner'
g++ -c -pipe -O2 -g -pipe -Wall
Lisandro Damián Nicanor Pérez Meyer wrote:
Hi! GStreamer 0.1 will get removed from Debian unstable soon. Is there any
chance to have GStreamer 1.0 support in 5.5.0?
qtmultimedia 5.5 branch supports gst-1.x
-- rex
___
Development mailing list
Thiago Macieira wrote:
On Monday 16 February 2015 08:55:14 Rex Dieter wrote:
* webkit components don't build, this is due to a configure check for
gcc-4.x, here's my quick-n-dirty fix (for g++ stanza only, others
probably should get touched too):
http://pkgs.fedoraproject.org/cgit/qt.git
Found a couple more gcc5-related issues with qt-4.8.x builds:
* webkit components don't build, this is due to a configure check for
gcc-4.x, here's my quick-n-dirty fix (for g++ stanza only, others probably
should get touched too):
Frederik Gladhorn wrote:
On Monday, February 16, 2015 08:55:14 AM Rex Dieter wrote:
Found a couple more gcc5-related issues with qt-4.8.x builds:
* webkit components don't build, this is due to a configure check for
...
* QT_BUILD_KEY handling
..
Both of these are fairly simple/obvious
Fedora development has recently adopted gcc5, and we've run into several
problems, one of which is that qt-4.8.6 fails to build, when linking
libQtGui:
.obj/release-shared/qdrawhelper_sse2.o: In function `unsigned int const*
qt_fetch_radial_gradient_templateQRadialFetchSimdQSimdSse2 (unsigned
Thiago Macieira wrote:
If we get any issues reported to us about Fedora or RHEL's non-renamed
binaries, we'll send back to you, with the recommendation that people file
bug reports about not using qtchooser. I already do that.
Now you're being a little over-dramatic, imo.
Users in this case
Thiago Macieira wrote:
So, yes, qtchooser is the next best thing. But you're refusing to adhere
to the common way. Fair enough, I'll just recommend anyone using Fedora
packages in #qt to go to #fedora, since you're refusing to standardise...
qtchooser is available in fedora, but is opt-in.
Thiago Macieira wrote:
On Monday 17 November 2014 02:55:33 Kevin Kofler wrote:
Yet Phonon officially supports GStreamer 1 now, QtMultimedia still
doesn't. These are the kinds of things we notice as GNU/Linux
distributors, not whether some developer adds some new feature to the
legacy
Lisandro Damián Nicanor Pérez Meyer wrote:
On Friday 17 October 2014 17:02:04 Kevin Kofler wrote:
Hi,
tl;dr; We have found the same problem in Debian, but steveire told us that
the idea of those CMake files is to provide a way to find the plugins if a
developer is doing it's own installer.
Ruslan Nigmatullin wrote:
If the changes will be done and accepted is there any hope to have them in
Qt 5.2.*
It's a bug fix rather than a new feature, so yeah, I'd expect it could be
included in a subsequent bugfix release (assuming there is one).
May be worth actually filing a bug to both
Thiago Macieira wrote:
3bis) distro builds Qt once with -no-sse2 and then some libs with -config
sse2
How could this be implemented exactly?
I know qtbase supports
./configure -(no-)sse2
but how for other modules like qtdeclarative that uses pure qmake?
-- Rex
Oswald Buddenhagen wrote:
On Thu, Dec 12, 2013 at 07:18:55AM -0600, Rex Dieter wrote:
Thiago Macieira wrote:
3bis) distro builds Qt once with -no-sse2 and then some libs with
-config sse2
How could this be implemented exactly?
I know qtbase supports
./configure -(no-)sse2
Rex Dieter wrote:
Oswald Buddenhagen wrote:
On Thu, Dec 12, 2013 at 07:18:55AM -0600, Rex Dieter wrote:
Thiago Macieira wrote:
3bis) distro builds Qt once with -no-sse2 and then some libs with
-config sse2
How could this be implemented exactly?
I know qtbase supports
./configure
Lisandro Damián Nicanor Pérez Meyer wrote:
On Tuesday 10 December 2013 14:18:39 Lisandro Damián Nicanor Pérez Meyer
wrote:
[snip]
He also gave us some directions on how we could achieve this, feel free
to ping me if you need them.
The idea (and please correct me if I've got something
Using qttools-5.1.1... In short, Qt5LinguistToolsConfig.cmake ends up
defining
Qt5::lrelease to point to
/usr/lib64/cmake/Qt5LinguistTools/bin/lrelease
instead of
/usr/lib64/qt5/bin/lrelease
It would appear this was supposed to be fixed in 5.1.1,
Stephen Kelly wrote:
On Wednesday, April 10, 2013 17:35:19 Rex Dieter wrote:
Please try the attached instead. I can't update the patch in gerrit
until it finishes integrating.
confirmed, test passes now. thanks again.
Great. If you do run the tests from the build tree during packaging
Stephen Kelly wrote:
On Tuesday, April 02, 2013 22:03:14 Stephen Kelly wrote:
However, there is also an upstream bug for me to fix here. The
Config.cmake files contain incorrect arguments to find_package, so they
are not able to find their dependencies (eg, Qt5Gui cmake package can't
find
Stephen Kelly wrote:
Note that it is not in Qt 5.0.2, so you may want to cherry-pick it into
the package for that.
I did just that.
-- rex
___
Development mailing list
Development@qt-project.org
Stephen Kelly wrote:
On Saturday, March 30, 2013 13:39:20 Rex Dieter wrote:
Stephen Kelly wrote:
On Saturday, March 30, 2013 10:25:58 Rex Dieter wrote:
What is in your configure line?
gory detail here,
http://pkgs.fedoraproject.org/cgit/qt5-qtbase.git/tree/qt5-qtbase.spec
Stephen Kelly wrote:
On Wednesday, April 10, 2013 09:23:10 Rex Dieter wrote:
As a followup, qt-5.0.2 + the cmake patch mentioned elsewhere in this
thread, we're down to a single failure (which looks a *lot* like the
problem of the other modules we fixed already):
Great! That's progress
Stephen Kelly wrote:
On Wednesday, April 10, 2013 17:14:53 Rex Dieter wrote:
Stephen Kelly wrote:
On Wednesday, April 10, 2013 09:23:10 Rex Dieter wrote:
As a followup, qt-5.0.2 + the cmake patch mentioned elsewhere in this
thread, we're down to a single failure (which looks a *lot* like
Stephen Kelly wrote:
I find it odd that you package the bootstrap library:
http://koji.fedoraproject.org/koji/rpminfo?rpmID=3892227
I guess I just naively packaged whatever 'make install' puts into the
system. Begs the question, if it's not needed or nothing needs it, why does
it get
Stephen Kelly wrote:
On Tuesday, April 02, 2013 15:18:30 Rex Dieter wrote:
Thanks. Your package seems to be missing libQt5Gui.so, libQt5OpenGL.so,
libQt5PrintSupport.so and libQt5Widgets.so. (Unless I misunderstood
something)
Those symlinks (and headers and other developer-related items
Stephen Kelly wrote:
On Sunday, March 31, 2013 13:24:47 Stephen Kelly wrote:
Thanks. Eep, I do see a bunch of failures with my initial
qtbase-5.0.2-rc1
build:
The following tests FAILED:
1 - test_use_modules_function (Failed)
3 - test_dependent_modules
Stephen Kelly wrote:
On Tuesday, April 02, 2013 14:37:33 Rex Dieter wrote:
Can I download this package from somewhere so I can extract it and have
a look?
Here's my first try in the fedora buildsystem,
http://koji.fedoraproject.org/koji/buildinfo?buildID=408328
Thanks. Your package
Stephen Kelly wrote:
On Friday, March 29, 2013 10:33:01 Rex Dieter wrote:
During packaging qt5 for fedora, someone noticed that cmake .config files
seemingly set incorrect _install_prefix variables. One example is in
qtbase, cmake files installed (on x86_64) as:
/usr/lib64/cmake/Qt5Core
During packaging qt5 for fedora, someone noticed that cmake .config files
seemingly set incorrect _install_prefix
variables. One example is in qtbase, cmake files installed (on x86_64) as:
/usr/lib64/cmake/Qt5Core/Qt5CoreConfig.cmake
/usr/lib64/cmake/Qt5Core/Qt5CoreConfigExtras.cmake
contain:
During review for qt5 packaging in fedora, we noticed qt5 includes a bundled
copy of harfbuzz in src/3rdparty/harfbuzz/, and there currently doesn't seem
to be --system-harfbuzz type build option available.
In order to justfify an exception to our usual no bundled libraries rule,
I would need
Rex Dieter wrote:
During review for qt5 packaging in fedora, we noticed qt5 includes a
bundled copy of harfbuzz in src/3rdparty/harfbuzz/, and there currently
doesn't seem to be --system-harfbuzz type build option available.
svuorela poked me on irc, and seems it's clear now that qt (4 and 5
Stephen Kelly wrote:
On Friday, September 28, 2012 13:25:42 Thiago Macieira wrote:
I've already contacted several downstreams: Sune for Debian, Will for
OpenSUSE, Raphael for FreeBSD; the Fedora people were the originators of
the bug report and have posted here.
All have given their +1 to
37 matches
Mail list logo
