> Solution:
>
> qmake renamed to qmake5 and lives with the other binaries in /bin
> Create /usr/bin/qmake5 as a symlink to /bin/qmake5 for Linux
> distro builds - triggered by some set of configure flags, NOT default
> behaviour for a source build
You definitely don't want support multiarch config
On terça-feira, 23 de outubro de 2012 23.12.58, André Pönitz wrote:
> Moreover, it is a reasonable assumption that only few Qt based
> Windows-only projects supporting VS use qmake at all, and that most
> non-trivial cross-platform Qt based projects supporting VS maintain a
> "real" .vcproj in para
On terça-feira, 23 de outubro de 2012 21.40.41, Oswald Buddenhagen wrote:
> > The difference is that xmlpatterns, like qdbus and the other
> > applications, can be updated by the Debian alternatives mechanism.
>
> yes, debian. have you checked that this is true for all relevant
> downstreams?
The
On 10/23/12, Lincoln Ramsay wrote:
> We're not renaming things or creating new lists just to match the
> names you think we should have.
>
*sigh*, I had a feeling someone would say something like that.
The changes are trivial at a glance, yes
...but what the Qt Project officially endorses/re
On 24/10/12 04:33, Thiago Macieira wrote:
> I think we are keeping it simple. The current proposal is the simplest
> that still works. If you can come up with something even simpler, I'll
> gladly accept it.
>>> If the option is required in one platform and does not cause anything but
>>> a minor
On 24/10/12 07:01, d3fault wrote:
> If you discover a vulnerability, please report it to
> secur...@qt-project.org and we'll take care of the rest. You can of
> course join in on the discussion and suggest fixes etc, as Qt is a
> COLLABORATIVE PROJECT.
>
> If you think the vulnerability would cause
Thiago Macieira schreef op ma 22-10-2012 om 11:33 [-0700]:
> Question to distros: what's the proper way to solve the "config tool"
> multiarch
> problem? TBH, this looks like an unsolved problem:
>
> $ i386 pkg-config --cflags dbus-1
> -I/usr/include/dbus-1.0 -I/usr/lib64/dbus-1.0/include
> $
Thiago Macieira schreef op zo 21-10-2012 om 10:51 [-0700]:
> I'm waiting for packagers and
> others to comment on the proposal.
Hi,
I think that having a centralized qmake wrapper is a nice compromise.
The distro package maintainers can then provide a /usr/bin/qmake wrapper
which by default poin
On Mon, Oct 22, 2012 at 01:46:09PM -0700, Thiago Macieira wrote:
> On segunda-feira, 22 de outubro de 2012 21.21.17, André Pönitz wrote:
> > On Mon, Oct 22, 2012 at 09:08:38AM -0700, Thiago Macieira wrote:
> > > On segunda-feira, 22 de outubro de 2012 15.45.56, Oswald
> > >
> > > Buddenhagen wrote
On 10/23/12, Donald Carr wrote:
> life is clearly not a popularity contest for d3fault.
rofl thank you for that compliment. better than Charley telling me I'm
smart repeatedly -_-
I agree completely!!! It's just that the
recommended/officially-endorsed way of reporting security
vulnerabilities
On Tue, Oct 23, 2012 at 10:18:38AM -0700, Thiago Macieira wrote:
> On terça-feira, 23 de outubro de 2012 18.29.34, Oswald Buddenhagen wrote:
> > > We've been over this: because I'd rather do this right and once and for
> > > all. Who are the best people to make sure that all tools continue to work
Harg; like so many things, this can be a meritocratic system. That is
to say, if you discover the vulnerability, or simply learn about it,
there is either a public channel (dev mailing list) or a non-public
mailing list. It is at the discretion of the person reporting this
kind of bug which channel
On terça-feira, 23 de outubro de 2012 10.42.58, BRM wrote:
> > In any case, "-qt5" may not mean "latest", but simply
> > "default 5.x version".
> > The implementation will decide what that means.
>
> How is this any better then updating LSB/FHS with guidelines on how to
> properly install Qt on a U
On Tuesday 23 October 2012 16:17:30 Mitch Curtis wrote:
> After https://codereview.qt-project.org/#change,37988, the "Serializing Qt
> Data Types" page lists the QDataStream version as 13. I thought it'd be a
> good idea to ask everyone who is interested to take a look and see if the
> descriptions
> How is this any better then updating LSB/FHS with guidelines on how to
> properly install Qt on a Unix/Linux system?
> Is it not easier to simply say install to /usr/share/qt-5.0.0.0 with a
> symlink to /usr/share/qt5, and require that distro specific tools manage
> symlinks to qmake/etc in th
On 10/23/12, d3fault wrote:
> You're like the priests in the early days hiding information (the
> ability to read and write) and trying to convince us it's for our own
> good. Time will tell who is right. su time; echo "d3fault is right";
> exit;
>
That analogy fits better than I first realized.
> From: Thiago Macieira
> Sent: Tuesday, October 23, 2012 1:03 PM
> Subject: Re: [Development] New proposal for the tool naming
>
> On terça-feira, 23 de outubro de 2012 16.33.05, Ziller Eike wrote:
>> >> So that if you happen to have a "real" qmake instead of
> the wrapper in
>> >> the
>> >
On Tue, 23 Oct 2012, Mitch Curtis wrote:
> After https://codereview.qt-project.org/#change,37988, the "Serializing
> Qt Data Types" page lists the QDataStream version as 13. I thought it'd
> be a good idea to ask everyone who is interested to take a look and see
> if the descriptions of the dat
On terça-feira, 23 de outubro de 2012 18.29.34, Oswald Buddenhagen wrote:
> > We've been over this: because I'd rather do this right and once and for
> > all. Who are the best people to make sure that all tools continue to work
> > under those conditions? Upstream is.
>
> the thing is that this is
On terça-feira, 23 de outubro de 2012 16.33.05, Ziller Eike wrote:
> >> So that if you happen to have a "real" qmake instead of the wrapper in
> >> the
> >> PATH on linux, you don't realize that when you are doing "qmake -qt5" to
> >> force "most current qt5 version" (or whatever the semantics woul
On 22 Oct 2012, at 17:11, Thiago Macieira wrote:
> On segunda-feira, 22 de outubro de 2012 14.59.09, Ziller Eike wrote:
Just as a side note, that requires that Windows and Mac to also have this
tool, and e.g. on Windows to have that tool in the PATH and pointing to
the
corres
On Tue, Oct 23, 2012 at 08:25:19AM -0700, Thiago Macieira wrote:
> On terça-feira, 23 de outubro de 2012 15.04.10, Oswald Buddenhagen wrote:
> > > Because qdbus should be in /usr/bin but the version- and arch-specific
> > > qmake should be somewhere in /usr/lib*/qt5.
> >
> > ok, i can buy that as
> From: Thiago Macieira
>Subject: Re: [Development] New proposal for the tool naming
>On segunda-feira, 22 de outubro de 2012 21.21.17, André Pönitz wrote:
>> On Mon, Oct 22, 2012 at 09:08:38AM -0700, Thiago Macieira wrote:
>> > On segunda-feira, 22 de outubro de 2012 15.45.56, Oswald
>> > Budden
On terça-feira, 23 de outubro de 2012 15.04.10, Oswald Buddenhagen wrote:
> > Because qdbus should be in /usr/bin but the version- and arch-specific
> > qmake should be somewhere in /usr/lib*/qt5.
>
> ok, i can buy that as such.
> however, i totally see no point in us doing this upstream, and why q
On Oct 23, 2012, at 2:34 PM, Ziller Eike wrote:
>
> On 23 Oct 2012, at 14:28, Daniel Molkentin
> wrote:
>
>> On 23.10.2012, at 14:27, Daniel Molkentin wrote:
>>
>>>
>>> I propose that Thomas should be my successor, since he has practically
>>> filled that role for more than half a year by
After https://codereview.qt-project.org/#change,37988, the "Serializing Qt
Data Types" page lists the QDataStream version as 13. I thought it'd be a good
idea to ask everyone who is interested to take a look and see if the
descriptions of the data types serialised are still accurate. If they're
Re on adjusting all the documentation to say "run qmake -qt5":
Let's count who will have Qt5 co-/installed:
1) Those who's DE is built against Qt5 and thus Qt5 is the default Qt
there; though, they may have Qt4 co-installed until all the qt-apps
in-use are ported to Qt5;
2) Those who are still on Q
On Mon, Oct 22, 2012 at 01:38:56PM -0700, Thiago Macieira wrote:
> On segunda-feira, 22 de outubro de 2012 20.52.49, Oswald Buddenhagen wrote:
> > > I can't fix what's already broken due to the Qt 3 and Qt 4 mess. I can
> > > only fix going forward for Qt 5.
> > >
> >
> > i fail to see your argu
On 23 Oct 2012, at 14:28, Daniel Molkentin
wrote:
> On 23.10.2012, at 14:27, Daniel Molkentin wrote:
>
>>
>> I propose that Thomas should be my successor, since he has practically
>> filled that role for more than half a year by now.
>
> Thomas being Thomas Hartmann obviously, since I forgo
On 23.10.2012, at 14:27, Daniel Molkentin wrote:
>
> I propose that Thomas should be my successor, since he has practically
> filled that role for more than half a year by now.
Thomas being Thomas Hartmann obviously, since I forgot to set him on CC before
sending, that context got lost.
__
Hi,
since I am no longer working full time on Qt Creator, I am hereby
stepping back from my position as the maintainer of the Qt Creator
Welcome Mode (http://qt-project.org/wiki/Maintainers) to ensure it
doesn't get blocked by me not being able to respond in a timely manner
or to maintain it.
2012/10/23 Jason Barron
> It works on MSVC and MinGW (both 32-bit and 64-bit).
Sounds great!
But I thought it should only work with mingw-w64 (support directx9), not
mingw.org, that right?
--
*Please don't ask where I come from, It's a shame!*
Best Regards
Yuchen
Hi all,
Now there are Qt 4.8.4 release candidate packages available for public review.
These are not yet the official release packages and should not be used as such.
Packages are built against SHA1: 8869b3b30a29b1dd4218b3f5ac0bec9dd936b664
and are available at http://origin.releases.qt-project.o
On Oct 23, 2012, at 11:38 AM, Sean Harmer wrote:
> On Tuesday 23 October 2012 08:26:51 Jason Barron wrote:
>> This is just a heads up for people developing Qt on Windows. We will shortly
>> add a copy of the ANGLE project into the Qt 3rdparty tree and make it the
>> default OpenGL configuration
On Tuesday 23 October 2012 08:26:51 Jason Barron wrote:
> This is just a heads up for people developing Qt on Windows. We will shortly
> add a copy of the ANGLE project into the Qt 3rdparty tree and make it the
> default OpenGL configuration if no other option is given.
Hmm, I would much rather t
> Dear Qt developers,
> I got a new toy at work -- a 27" LCD with some crazy resolution
> (2560x1440 IIRC), i,e. its pixel density is roughly 109 PPI. The LCD I
> use at home has got a 94 PPI grid. I frequently move my laptop between
> these two places and I have yet to make my KDE 4.9 use fonts w
This is just a heads up for people developing Qt on Windows. We will shortly
add a copy of the ANGLE project into the Qt 3rdparty tree and make it the
default OpenGL configuration if no other option is given. If you're not
familiar with ANGLE, you can read about it here:
http://code.google.com/
> You haven't earned the trust of the people in charge.
>
> The current security team members have earned the trust of the people in
> charge.
>
> No contradictions there.
Why do they need to trust me?
Because the information is dangerous.
By admitting that the information is dangerous, they are
38 matches
Mail list logo
