(Not sure if I should have CCed debian-wb-team too, please CC-me on reply)
Hello,
pyside's standard test suite is failing on our arm64 buildd (at least
on arm-conova-01.debian.org) as shown by this log:
https://buildd.debian.org/status/fetch.php?pkg=pyside2=arm64=5.13.2-1=1574206970=0
We
Hello,
On Thu, 29 Nov 2018, Adrian Bunk wrote:
> Qt already supports runtime ES/non-ES in the same library build on
> Windows [2], something like that might also be doable for Linux if
> anyone (Linaro? Canonical?) with a real interest in that would work
> on making it happen.
>
> Some of the
Hello Lisandro,
TLDR: thank you for starting this discussion, it was required as it's not
an easy decision to take as there is no realistic perfect solution, but I
believe you took the wrong decision. Please consider deferring the
decision to the technical committe by seeking his advice (point
Hello,
On Sat, 24 Nov 2018, bret curtis wrote:
> Moving Qt back to using Desktop GL from GLES is going to have zero
> impact performance on the RPi since the VC4 supports up to OpenGL 2.1
> and and GLES 2.0 [1]
That's a different claim to what you made in a former message.
> The problem is that
Hi,
On Fri, 23 Nov 2018, Dmitry Shachnev wrote:
> According to config_help.txt [1], Qt uses ES2 by default on Windows.
Interesting.
> But as Lisandro says, such a change in Debian will break many packages
> (which are currently broken on ARM only), so we are definitely not
> considering it at
Hi,
thanks for the feedback.
On Sat, 23 Apr 2016, Julien Cristau wrote:
> I think one of the contentious points is how "Freexian raising funds to
> work on Debian LTS" is already too close to calling itself "Debian LTS
> fundraising", so I'm not sure bringing them closer would alleviate
>
Hi,
On Fri, 22 Apr 2016, Tollef Fog Heen wrote:
> I am not speaking on behalf of DSA here.
Thanks for making this clear. I also want to explain why I included DSA
in the discussion: I wanted to make sure that the fact that we run wheezy
armel/armhf buildd for two more years do not go against
On Mon, 18 Apr 2016, Raphael Hertzog wrote:
> In the mean time, the sponsor clarified that they will join as "gold
> sponsor" so they are effectively sponsoring 8 hours of work per month,
> which seems to be enough to cover for the increased work that those
>
Hello,
On Fri, 15 Apr 2016, Raphael Hertzog wrote:
> armhf users to run jessie and armel users to be only hobbyists). But here
> we have a sponsor willing to sign on a contract saying us « our customers wish
> to use Debian 7 OS continuously so that we are planning to sponsor the LTS
Hello,
I know that we decided to not support arm* for wheezy-lts during last
Debconf but it turns out that Freexian has been contacted by a potential LTS
sponsor selling arm* products:
Openblocks A7 (armel)
http://openblocks.plathome.co.jp/products/obs_a/a7/spec.html
Opneblocks AX3 (armhf)
Hello David,
On Thu, 27 Jun 2013, Lennart Sorensen wrote:
Would http://packages.debian.org/jessie/linux-image-3.9-1-vexpress by
any chance be a valid kernel image for the highbank? I see in the git
logs of Linus's tree that there is a v7 multiplatform config that is
supposed to cover the
Hello,
OffensiveSecurity owns a Calxeda Highbank cluster of ARM machines[1] and is
willing to dedicate one of the nodes to Debian. I believe it would make a
relatively fast ARM autobuilder or porter box. The specs of the hardware (4GB
RAM, 500 GB SATA drives, 4 Cortex A9 cores at 1.1 to 1.4 GHz)
On Sat, 24 Jul 2010, Steve Langasek wrote:
On Mon, Jul 19, 2010 at 07:02:32PM +0100, Hector Oron wrote:
2010/7/18 Steve Langasek vor...@debian.org:
I'm puzzled why dpkg needs a unique triplet for a port. dpkg needs to map
port names to triplets, but why does it need to do the inverse?
On Sat, 20 Jun 2009, Matthias Klose wrote:
Under normal curcumstances, I'd expect every shared library and application
to
require __aeabi_* from libgcc. Under normal circumstances these will come
from
libgcc_s.so, but if you link with --static-libgcc then you'll get your own
clone 533642 -1
reassign -1 libgcc1 1:4.4.0-7
retitle -1 Ensure __aeabi_* symbols are listed in libgcc1.symbols for armel
severity -1 important
thanks
On Sat, 20 Jun 2009, Raphael Hertzog wrote:
I think that to properly resolve my issue I have to allow you to export
those blacklisted symbols
On Fri, 19 Jun 2009, Christoph Egger wrote:
Building the NEW package I'm working on (irrlicht [3]) on my
ARM(el)[4] box (up-to-date sid pbuilder) causes dpkg-shlibdeps to
complain about missing symbols [0]. These symbols seem to be some gcc
internals that should be covered by libgcc_s.so
On Fri, 19 Jun 2009, Paul Brook wrote:
Now it seems that the irrlicht library depends on those symbols
provided by libgcc_s.so.1 (and does not define them locally contrary to
what was seen by Aurélien in libvorbis in #462318) and of course
dpkg-shlibdeps complains because they can't be found
Le Mon, Jun 17, 2002 at 05:35:11PM -0500, The Doctor What écrivait:
Not yet. I'm a little disappointed that I can't just apt-get
install arm-x-compile-task in debian-x86
I'm surprised that nobody in this thread mentionned the work of
wookey on emdebian. It provides a packaged ARM cross
Le Tue, Jun 18, 2002 at 09:48:28AM +0200, Andreas Schuldei écrivait:
* Raphael Hertzog ([EMAIL PROTECTED]) [020618 09:43]:
I'm surprised that nobody in this thread mentionned the work of
wookey on emdebian. It provides a packaged ARM cross compiler.
perhaps because it is dead?
Wookey
19 matches
Mail list logo
