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 speaks
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
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 op
Marc Mutz wrote:
> Hi,
>
> We repeatedly have the problem that timeouts that developers think are
> ample (because they exceed typical runtime by, say, two orders of
> magnitude) are found to be insufficient on the CI.
>
> Latest example:
> http://testresults.qt.io/coin/integration/qt/qtbase/tas
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 allow
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/i
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 -Wp,-D_FORTI
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
Devel
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):
>&
Sune Vuorela wrote:
> On 2015-02-16, Rex Dieter wrote:
>> * QT_BUILD_KEY handling
>>
>> Similar to webkit above, the configure bits about QT_BUILD_KEY only
>> handles up to gcc-4.x.
>>
>> For fedora 22, our gcc5 builds are done in a way that is (suppos
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
..
&g
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):
http://pkgs.fedoraproject.org/cgit/qt.git/tree/qt-fix_detection
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_template >(unsigned
int*, Operator const*, Q
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 cas
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 inst
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
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
>
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?
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
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 somethin
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,
https://bugreports.qt-project.org/browse/QTBUG-32
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.
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, w
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 al
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,
>>
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
http://lists.qt-project.org/mailman/listinfo/develop
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
>>
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 inst
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
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
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_depe
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
>
> Interesting that you don't us
Rex Dieter wrote:
> 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 i
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)
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:
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
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
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 th
41 matches
Mail list logo
