ent@qt-project.org
> Subject: Re: [Development] Qt5 combined source package - Perl dependency
>
> On terça-feira, 30 de abril de 2013 18.30.08, Oswald Buddenhagen wrote:
> > On Tue, Apr 30, 2013 at 08:59:47AM -0700, Thiago Macieira wrote:
> > > On terça-feira, 30 de abril
On terça-feira, 30 de abril de 2013 18.30.08, Oswald Buddenhagen wrote:
> On Tue, Apr 30, 2013 at 08:59:47AM -0700, Thiago Macieira wrote:
> > On terça-feira, 30 de abril de 2013 17.24.29, Oswald Buddenhagen wrote:
> > > > Can we do it somehow less magically? Isn't there a way to do it if it
> > >
On Tue, Apr 30, 2013 at 08:59:47AM -0700, Thiago Macieira wrote:
> On terça-feira, 30 de abril de 2013 17.24.29, Oswald Buddenhagen wrote:
> > > Can we do it somehow less magically? Isn't there a way to do it if it
> > > needs to be done, and not do it if it doesn't need to be done?
> >
> > no, be
On terça-feira, 30 de abril de 2013 17.24.29, Oswald Buddenhagen wrote:
> >
> >
> > Can we do it somehow less magically? Isn't there a way to do it if it
> > needs to be done, and not do it if it doesn't need to be done?
> >
> >
>
> no, because latest on the second in-source build it would not be
>
On Tue, Apr 30, 2013 at 08:12:36AM -0700, Thiago Macieira wrote:
> On terça-feira, 30 de abril de 2013 11.00.11, Oswald Buddenhagen wrote:
> > ones can simply delete include/ (and configure.exe) from the extracted
> > source tree,
>
> They have to know that those exist in the first place and shoul
On terça-feira, 30 de abril de 2013 11.00.11, Oswald Buddenhagen wrote:
> On Mon, Apr 29, 2013 at 11:25:14AM -0700, Thiago Macieira wrote:
> > Adding a random file somewhere *usually* isn't a problem. It is a problem
> > only if the presence of a file changes the output of the build. And
> > that's
On Mon, Apr 29, 2013 at 11:25:14AM -0700, Thiago Macieira wrote:
> Adding a random file somewhere *usually* isn't a problem. It is a problem
> only
> if the presence of a file changes the output of the build. And that's exactly
> what configure.exe and the include/ dir do: they change the output
On segunda-feira, 29 de abril de 2013 17.47.06, d3fault wrote:
> Paddles!
>
> On Mon, Apr 29, 2013 at 11:25 AM, Thiago Macieira
>
> wrote:
> > A determined hacker could infiltrate Digia's network and tamper with their
> > email server. When an email is received for secur...@qt-project.org, it
>
Paddles!
On Mon, Apr 29, 2013 at 11:25 AM, Thiago Macieira
wrote:
> A determined hacker could infiltrate Digia's network and tamper with their
> email server. When an email is received for secur...@qt-project.org, it could
> then forward the vuln to the hacker's own email address. This way, the
>
On segunda-feira, 29 de abril de 2013 19.34.45, Oswald Buddenhagen wrote:
> would it be terribly hard to add a filter step that throws out include/
> (and configure.exe) when zcat-ing the archive?
That's the second choice I listed: do a file-by-file comparison, knowing which
files are acceptable
On Mon, Apr 29, 2013 at 09:25:15AM -0700, Thiago Macieira wrote:
> On segunda-feira, 29 de abril de 2013 18.09.14, Oswald Buddenhagen wrote:
> > i'll rethink my stance if you answer my questions regarding the
> > verification process to my satisfaction.
>
> I want the source tarballs to have the G
On segunda-feira, 29 de abril de 2013 18.09.14, Oswald Buddenhagen wrote:
> On Mon, Apr 29, 2013 at 07:44:18AM -0700, Thiago Macieira wrote:
> > On segunda-feira, 29 de abril de 2013 11.06.11, Oswald Buddenhagen wrote:
> > > my current solution is entirely predictable: git builds always run
> > > s
On Mon, Apr 29, 2013 at 07:44:18AM -0700, Thiago Macieira wrote:
> On segunda-feira, 29 de abril de 2013 11.06.11, Oswald Buddenhagen wrote:
> > my current solution is entirely predictable: git builds always run
> > syncqt, while other builds never do. this makes a very clear statement:
> > if you
On segunda-feira, 29 de abril de 2013 11.06.11, Oswald Buddenhagen wrote:
> my current solution is entirely predictable: git builds always run
> syncqt, while other builds never do. this makes a very clear statement:
> if you want to modify qt (or at least its apis), use git.
Please note that this
On Fri, Apr 26, 2013 at 02:30:10PM -0700, Thiago Macieira wrote:
> With that, Ossi's patch is one step in the right direction and one step in
> the
> wrong direction. We should not re-generate the headers if they are present,
> but we should still do it if they aren't -- and that includes shadow
On 26/04/2013 19:06, BRM wrote:
> Not everyone using the non-git source deliveries (e.g. the ZIP file on the
> website) can install anything they want on their computers.
Understood. I consider this point valid. For those people we can provide
an all-in-one pre-syncqt-ed source package.
> The
I think that the main issue with webkit is that the generated files change
depending on the system configuration and the consequently enabled or disabled
web-facing APIs.
Simon
Knoll Lars wrote:
On 4/26/13 3:00 AM, "Anttila Janne" wrote:
>Hi,
>
>As you probably are aware, there has been a
What about the dependency we have on python? Is that a problem as well?
(I'm referring to the fact that even a build without webkit still requires Perl
and python)
Simon
Anttila Janne wrote:
Hi,
As you probably are aware, there has been a long thread on interest
list about Qt dependency blo
On 4/26/13 3:00 AM, "Anttila Janne" wrote:
>Hi,
>
>As you probably are aware, there has been a long thread on interest
>list about Qt dependency bloat. One of the most commented problems
>has been Perl dependency, especially on Windows.
>
>We have had similar feedback on commercial support chan
On sexta-feira, 26 de abril de 2013 10.00.42, Anttila Janne wrote:
> Hi,
>
> As you probably are aware, there has been a long thread on interest
> list about Qt dependency bloat. One of the most commented problems
> has been Perl dependency, especially on Windows.
>
> We have had similar feedback
Exactly. No-one benefits in making things hard for the users.
I hope we can fix this for 5.1 and more for the subsequent releases.
Even though there is an increasing number of pre-build binaries it should be
easy and fast to build Qt when needed, as well as to choose which parts are
taken in.
Having participated in the discussion on the Interests list...
Aside from what Andre' said...
> From: Joerg Bornemann
>To: Friedemann Kleint
>Cc: development@qt-project.org
>Sent: Friday, April 26, 2013 11:35 AM
>Subject: Re: [Development] Qt5 combined source package -
On Fri, Apr 26, 2013 at 05:35:01PM +0200, Joerg Bornemann wrote:
> I personally don't see where exactly the point of pain is... other than
> "something I was used to changed". Downloading and installing Perl on
> Windows is really straight-forward.
The point of pain is that something that used t
On Fri, Apr 26, 2013 at 04:57:23PM +0200, Friedemann Kleint wrote:
> >One of the most commented problems has been Perl dependency,
> >especially on Windows.
>
> I have to admit I do not really see the point of it as long as QtWebKit
> requires Ruby and Python. In my view, requiring a scripting
On 26/04/2013 16:57, Friedemann Kleint wrote:
> I have to admit I do not really see the point of it as long as QtWebKit
> requires Ruby and Python. In my view, requiring a scripting language it
> is acceptable as long as a single, unified language is used. Most
> projects on Windows require script
Hi,
>One of the most commented problems has been Perl dependency,
especially on Windows.
I have to admit I do not really see the point of it as long as QtWebKit
requires Ruby and Python. In my view, requiring a scripting language it
is acceptable as long as a single, unified language is used.
ct: [Development] Qt5 combined source package - Perl dependency
>
> Hi,
>
> As you probably are aware, there has been a long thread on interest list
> about Qt dependency bloat. One of the most commented problems has
> been Perl dependency, especially on Windows.
>
> We ha
On Fri, Apr 26, 2013 at 10:00:42AM +, Anttila Janne wrote:
> Qt-Project now provides split source packages, the split packages
> do not and should not have syncqt executed. Thus they would make
> it possible to cryptographically verify that the sources match
> exactly the repository with no mo
Hi,
As you probably are aware, there has been a long thread on interest
list about Qt dependency bloat. One of the most commented problems
has been Perl dependency, especially on Windows.
We have had similar feedback on commercial support channels.
One quite simple change what we could do alrea
29 matches
Mail list logo
