On Saturday, 6 May 2017 13:06:59 PDT Thiago Macieira wrote:
> On Saturday, 6 May 2017 12:48:57 PDT Thiago Macieira wrote:
> > First, because the CI stops at the moment the first problem happens. So we
> > don't know where else it may have happened. We only know where it did
> > happen.
> >
> >
ose'd) style plugin causing
crash during application exit?
On Sunday, 7 May 2017 22:56:53 PDT Sergio Martins wrote:
> On 2017-05-06 16:00, Thiago Macieira wrote:
> > Someone could do that. I'd even appreciate just a backtrace from the
> > deadlocked application.
>
> Have you ask
On Sunday, 7 May 2017 23:56:19 PDT Kari Oikarinen wrote:
> The failures of https://codereview.qt-project.org/#/c/180231/ and
> https://codereview.qt-project.org/#/c/180232/ happened on Ubuntu Touch
> builds.
>
> That platform is not part of 5.9 CI anymore. So as far as I understand
> it hasn't
On 08.05.2017 09:47, Thiago Macieira wrote:
On Sunday, 7 May 2017 22:56:53 PDT Sergio Martins wrote:
On 2017-05-06 16:00, Thiago Macieira wrote:
Someone could do that. I'd even appreciate just a backtrace from the
deadlocked application.
Have you asked the CI guys for such backtrace ? Why
On Sunday, 7 May 2017 22:56:53 PDT Sergio Martins wrote:
> On 2017-05-06 16:00, Thiago Macieira wrote:
> > Someone could do that. I'd even appreciate just a backtrace from the
> > deadlocked application.
>
> Have you asked the CI guys for such backtrace ? Why isn't there a JIRA
> issue for this ?
On 2017-05-06 16:00, Thiago Macieira wrote:
Someone could do that. I'd even appreciate just a backtrace from the
deadlocked application.
Have you asked the CI guys for such backtrace ? Why isn't there a JIRA
issue for this ?
Regards,
--
Sérgio Martins | sergio.mart...@kdab.com | Senior
On Sunday, 7 May 2017 12:43:39 PDT Konstantin Tokarev wrote:
> 07.05.2017, 22:43, "Thiago Macieira" :
> > On Sunday, 7 May 2017 12:26:02 PDT Konstantin Tokarev wrote:
> >> I'm doing embedded software development, and wouldn't even consider
> >> including emulated
07.05.2017, 22:43, "Thiago Macieira" :
> On Sunday, 7 May 2017 12:26:02 PDT Konstantin Tokarev wrote:
>> I'm doing embedded software development, and wouldn't even consider
>> including emulated builds into my pipeline.
>
> Then if you have a need for QtDBus, you'll
On Sunday, 7 May 2017 12:26:02 PDT Konstantin Tokarev wrote:
> I'm doing embedded software development, and wouldn't even consider
> including emulated builds into my pipeline.
Then if you have a need for QtDBus, you'll maybe step up and help us solve
this one-year-old issue.
--
Thiago
07.05.2017, 19:24, "Thiago Macieira" :
> On Sunday, 7 May 2017 03:20:26 PDT Ville Voutilainen wrote:
>> On 6 May 2017 at 22:48, Thiago Macieira wrote:
>> > Second, compiling to ARM requires cross-compilation. Since the problem
>> >
On Sunday, 7 May 2017 03:20:26 PDT Ville Voutilainen wrote:
> On 6 May 2017 at 22:48, Thiago Macieira wrote:
> > Second, compiling to ARM requires cross-compilation. Since the problem
> > happens because of cross-compilation, it happens for all ARM builds.
>
> Perhaps
On 7 May 2017 at 18:36, René J. V. Bertin wrote:
> Ville Voutilainen wrote:
>
>> Perhaps we should get ARM hardware so that we can do ARM builds
>> without cross-compilation. :)
>
> Not a single Qt dev who'd be willing to donate his/her old phone or Raspberry
> for this
Ville Voutilainen wrote:
> Perhaps we should get ARM hardware so that we can do ARM builds
> without cross-compilation. :)
Not a single Qt dev who'd be willing to donate his/her old phone or Raspberry
for this purpose? ;)
___
Development mailing list
On 6 May 2017 at 22:48, Thiago Macieira wrote:
> Second, compiling to ARM requires cross-compilation. Since the problem happens
> because of cross-compilation, it happens for all ARM builds.
Perhaps we should get ARM hardware so that we can do ARM builds
without
Thiago Macieira wrote:
> > First, because the CI stops at the moment the first problem happens. So we
> > don't know where else it may have happened. We only know where it did
happen.
Oh, right. I assumed that there were independent builders for the different
platforms.
> Ok, here you go:
On Saturday, 6 May 2017 12:48:57 PDT Thiago Macieira wrote:
> First, because the CI stops at the moment the first problem happens. So we
> don't know where else it may have happened. We only know where it did
> happen.
>
> Second, compiling to ARM requires cross-compilation. Since the problem
>
On Saturday, 6 May 2017 12:20:29 PDT René J. V. Bertin wrote:
> Thiago Macieira wrote:
> > At the risk of repeating myself, it has nothing to do with ARM.
>
> Does it happen on any of the other builders? If so, apologies, if someone
> had pointed that out I wouldn't have fixated so much on ARM.
Thiago Macieira wrote:
> At the risk of repeating myself, it has nothing to do with ARM.
Does it happen on any of the other builders? If so, apologies, if someone had
pointed that out I wouldn't have fixated so much on ARM.
> The difference is that in a cross-compilation setting, qdbusxml2cpp
On Saturday, 6 May 2017 05:14:30 PDT René J. V. Bertin wrote:
> But since you repeat this: what's different with that xml2cpp code generator
> in the cross-compilation setting? Does it contain/run ARM-conditional code
> (built for X86), for instance? Is there no way to figure that out without
>
Thiago Macieira wrote:
> Be my guest. I can't test this, so I don't have a way to even try whether it
Actually I think you could. Testing this would mean implementing a version of
the patches that does nothing on ARM, and then getting that to run that on the
ARM CI. The only thing I could
Em sexta-feira, 28 de abril de 2017, às 02:32:04 PDT, René J.V. Bertin
escreveu:
> Together with the principal maintainer I am looking into issues in a style
> plugin related to its use of DBus (to be informed of desktop-wide changes):
>
> https://bugs.kde.org/show_bug.cgi?id=363753
i don't
Em sexta-feira, 5 de maio de 2017, às 01:47:53 PDT, René J. V. Bertin
escreveu:
> Thiago Macieira wrote:
> >> Indeed. Does it even need to link to QtDbus then?
> >
> > It links to QtBootstrapDBus.
>
> That looks like an internal library which itself links to QtDBus, right?
No, it's a
Thiago Macieira wrote:
>> Indeed. Does it even need to link to QtDbus then?
>
> It links to QtBootstrapDBus.
That looks like an internal library which itself links to QtDBus, right?
Some more thoughts how to work around this:
- include only those required bits and pieces into QtBootstrapDBus
Em quinta-feira, 4 de maio de 2017, às 11:33:44 PDT, René J. V. Bertin
escreveu:
> Thiago Macieira wrote:
> > How could it be? The problem happens with a host application that is a
> > code
> > generator that doesn't connect to the bus.
>
> Indeed. Does it even need to link to QtDbus then?
It
Thiago Macieira wrote:
> How could it be? The problem happens with a host application that is a code
> generator that doesn't connect to the bus.
Indeed. Does it even need to link to QtDbus then?
R.
___
Development mailing list
Em quinta-feira, 4 de maio de 2017, às 11:06:54 PDT, René J. V. Bertin
escreveu:
> Thiago Macieira wrote:
> > I think our ARM builds are little-endian, so endianness cannot be an
> > issue.
> >
> > The problem happens before any ARM code is run, so it's not an emulation
> > or
> > processor
04.05.2017, 21:07, "René J. V. Bertin" :
> Thiago Macieira wrote:
>
>> I think our ARM builds are little-endian, so endianness cannot be an issue.
>>
>> The problem happens before any ARM code is run, so it's not an emulation or
>> processor issue. It must be a
Thiago Macieira wrote:
> I think our ARM builds are little-endian, so endianness cannot be an issue.
>
> The problem happens before any ARM code is run, so it's not an emulation or
> processor issue. It must be a cross-compilation (bootstrapping) issue.
So it cannot be something that has to do
Em quinta-feira, 4 de maio de 2017, às 08:03:47 PDT, René J. V. Bertin
escreveu:
> Here's another shot in the dark: that's a 64bit Intel host running an ARM
> cross build, maybe even for 32bit. I don't really know how you run tests on
> there (emulation?) but couldn't this be something that has
Thiago Macieira wrote:
> I could start firing in the dark. For example, one characteristic of the above
> build that never matches any of my local tests is that it's a cross-
> compilation to ARM. So we could disable QtDBus by default when cross-
> compiling.
I noticed that, and wondered if the
Em quarta-feira, 3 de maio de 2017, às 08:45:42 PDT, René J.V. Bertin
escreveu:
> On Wednesday May 03 2017 12:08:49 Edward Welbourne wrote:
> >https://testresults.qt.io/logs/qt/qtbase/74dfb52faa8370b61de9eb89947bfdd473
> >fe4986/LinuxUbuntu_15_04x86_64LinuxUbuntuTouch_15_04armv7GCCqtci-linux-Ubun
Em quarta-feira, 3 de maio de 2017, às 05:08:49 PDT, Edward Welbourne
escreveu:
> Thiago Macieira wrote:
> >> In 5.8, the build deadlocks, so
> >> we can't even just disable a test.
>
> René J. V. Bertin (3 May 2017 13:28) replied:
> > How is that even possible?
>
> We don't know. And yet:
>
Em quarta-feira, 3 de maio de 2017, às 04:28:30 PDT, René J. V. Bertin
escreveu:
> Thiago Macieira wrote:
> > The commercial client will complain to paid support, support will
> > investigate the issue and figure out what the regression is.
>
> And if they can't reproduce it either?
Then they
Thiago Macieira wrote:
>> In 5.8, the build deadlocks, so
>> we can't even just disable a test.
René J. V. Bertin (3 May 2017 13:28) replied:
> How is that even possible?
We don't know. And yet:
Thiago Macieira wrote:
> The commercial client will complain to paid support, support will investigate
> the issue and figure out what the regression is.
And if they can't reproduce it either?
> In 5.8, the build deadlocks, so
> we can't even just disable a test.
How is that even possible?
On Tuesday, 2 May 2017 02:48:15 CDT René J. V. Bertin wrote:
> I'm aware of the direct reason. Apparently you're sure enough that the CI
> failure is without consequence to put the burden and responsibility of
> incorporating the patch on end-users. That's what I mean with getting an
> internal
On Tuesday, 2 May 2017 06:32:48 CDT Thiago Macieira wrote:
> On Tuesday, 2 May 2017 02:48:15 CDT René J. V. Bertin wrote:
> > Thiago Macieira wrote:
> >
> > At the very least there should be alternative binaries (QtCore? QtDBus?)
> > available for download with the patch applied to which you can
On Tuesday, 2 May 2017 02:48:15 CDT René J. V. Bertin wrote:
> Thiago Macieira wrote:
>
> At the very least there should be alternative binaries (QtCore? QtDBus?)
> available for download with the patch applied to which you can point people
> who report related issues, and the patch itself should
Thiago Macieira wrote:
At the very least there should be alternative binaries (QtCore? QtDBus?)
available for download with the patch applied to which you can point people who
report related issues, and the patch itself should be provided with the sources
(in the tarball or clearly listed on
On Sunday, 30 April 2017 10:46:04 -03 René J. V. Bertin wrote:
> Thiago Macieira wrote:
> > Every Linux distribution should apply the patch. No one should use QtDBus
> > without them. I will not support any use or investigate any crash report
> > of a build that doesn't have them applied.
>
> If
Thiago Macieira wrote:
> Every Linux distribution should apply the patch. No one should use QtDBus
> without them. I will not support any use or investigate any crash report of a
> build that doesn't have them applied.
If you're so certain of the patches why haven't they still been
On Saturday, 29 April 2017 16:46:16 -03 René J. V. Bertin wrote:
> Are those patches in any way a possible fix for DBus signals being delivered
> to slots in libraries that have already been dlclose'd? The fact this can
> happen suggests QtDbus is still very much up and running, no?
They may be
Thiago Macieira wrote:
> 5.6: https://codereview.qt-project.org/157488 &
> https://codereview.qt-project.org/161056
>
> 5.8: https://codereview.qt-project.org/180231 &
> https://codereview.qt-project.org/180232
I have, and that's the reason I cannot easily attempt to produce backtraces
myself
On Friday April 28 2017 12:27:48 Shawn Rutledge wrote:
>That says that this fixes it https://codereview.qt-project.org/#/c/161056/ and
>that in turn says that https://codereview.qt-project.org/#/c/180232/ is the
>equivalent for 5.8. So I suppose we’d better get it into 5.9 then, right?
> On 28 Apr 2017, at 11:32, René J.V. Bertin wrote:
>
> Hello,
>
> Together with the principal maintainer I am looking into issues in a style
> plugin related to its use of DBus (to be informed of desktop-wide changes):
>
> https://bugs.kde.org/show_bug.cgi?id=363753
On Friday, 28 April 2017 06:32:04 -03 René J.V. Bertin wrote:
> Together with the principal maintainer I am looking into issues in a style
> plugin related to its use of DBus (to be informed of desktop-wide changes):
>
> https://bugs.kde.org/show_bug.cgi?id=363753
Before I read any of the rest:
Hello,
Together with the principal maintainer I am looking into issues in a style
plugin related to its use of DBus (to be informed of desktop-wide changes):
https://bugs.kde.org/show_bug.cgi?id=363753
The ticket above is about a reproducible issue in a custom cleanup handler that
is designed
47 matches
Mail list logo