Hi!
On Wed, 2024-11-06 at 17:28:38 +0500, Andrey Rakhmatullin wrote:
> On Wed, Nov 06, 2024 at 10:43:07AM +0100, Emanuele Rocca wrote:
> > As a final thought, given that new toolchain versions bring multiple
> > improvements over the years it's perhaps worth thinking about rebuilding
> > the archi
On Wed, Nov 06, 2024 at 10:43:07AM +0100, Emanuele Rocca wrote:
> As a final thought, given that new toolchain versions bring multiple
> improvements over the years it's perhaps worth thinking about rebuilding
> the archive on some sort of regular basis to make sure we get the
> benefits?
"Let's a
Am Wed, Nov 06, 2024 at 01:16:57PM + schrieb Holger Levsen:
> On Wed, Nov 06, 2024 at 05:28:38PM +0500, Andrey Rakhmatullin wrote:
> > "Let's at least force rebuilds all packages not rebuilt since stable
> > before every freeze starts" is a popular opinion.
>
> true. and "let's not do that" is
On Wed, Nov 06, 2024 at 01:16:57PM +, Holger Levsen wrote:
> On Wed, Nov 06, 2024 at 05:28:38PM +0500, Andrey Rakhmatullin wrote:
> > "Let's at least force rebuilds all packages not rebuilt since stable
> > before every freeze starts" is a popular opinion.
>
> true. and "let's not do that" is
On Wed, Nov 06, 2024 at 05:28:38PM +0500, Andrey Rakhmatullin wrote:
> "Let's at least force rebuilds all packages not rebuilt since stable
> before every freeze starts" is a popular opinion.
true. and "let's not do that" is even more popular, else why haven't we
done this in three decades?
--
On 2024-10-28 10:55, Sebastian Ramacher wrote:
> since dpkg 1.22.0 the additional hardening flags to enable Pointer
> Authentication (PAC) and Branch Target Identification (BTI)
> on arm64 are enabled by default.
Some more background and an update on this.
Both PAC and BTI are enabled
On Mon, Oct 28, 2024 at 10:55:57PM +0100, Sebastian Ramacher wrote:
> since dpkg 1.22.0 the additional hardening flags to enable Pointer
> Authentication (PAC) and Branch Target Identification (BTI)
> on arm64 are enabled by default. See [1] for the discussion to enable
> these flags
Hi,
since dpkg 1.22.0 the additional hardening flags to enable Pointer
Authentication (PAC) and Branch Target Identification (BTI)
on arm64 are enabled by default. See [1] for the discussion to enable
these flags.
To have the desired effect for the next release and have some time
to catch
Hi Vincent,
Quoting Vincent Bernat (2024-09-21 14:55:36)
> I am using qemu-user-static to compile to ARM64 from AMD64. There is a
> long-time bug with recent versions of QEMU where you would get a segfault:
>
> https://gitlab.com/qemu-project/qemu/-/issues/1913
>
> I w
Hi Vincent,
On 21-09-2024 14:55, Vincent Bernat wrote:
I am using cowbuilder. What would be the most straightforward way to
compile packages to ARM64? Would it be allowed to use ARM64 porter boxes
for this? This is mostly for HAProxy packages, so I don't intend to
compile a lot of pac
Hey!
I am using qemu-user-static to compile to ARM64 from AMD64. There is a
long-time bug with recent versions of QEMU where you would get a segfault:
https://gitlab.com/qemu-project/qemu/-/issues/1913
I was using qemu-user-static_7.2+dfsg-7+deb12u5_amd64.deb for quite some
time, but
icense : MIT (Expat)
Programming Lang: C++, CMake
Description : Aarch64 (arm64) code emitter
Oaknut is a header-only C++20 assembler for arm64 systems. It is designed to
process C++ code and emit it to memory at runtime.
I am in the process of packaging Citra, the Nintendo 3DS em
Hi Guillem,
On Thu, Aug 31, 2023 at 02:12:51AM +0200, Guillem Jover wrote:
> So this happened, and Johannes reported that this seems to be breaking
> cross-building. :(
>
> The problem, which is in fact not new, but is made way more evident
> now, is that the flags used are accepted only per arch
Hi Guillem,
On 2023-08-31 02:12, Guillem Jover wrote:
> So this happened, and Johannes reported that this seems to be breaking
> cross-building. :(
>
> The problem, which is in fact not new, but is made way more evident
> now, is that the flags used are accepted only per arch, so when
> passing f
Hi!
On Sun, 2023-08-27 at 12:51:53 +0200, Guillem Jover wrote:
> On Tue, 2023-06-27 at 16:09:40 +0100, Wookey wrote:
> > OK. We're all agreed on that then. Guillem can stick it in the next
> > dpkg upload.
So this happened, and Johannes reported that this seems to be breaking
cross-building. :(
Hi!
On Tue, 2023-06-27 at 16:09:40 +0100, Wookey wrote:
> On 2023-06-27 16:58 +0200, Moritz Mühlenhoff wrote:
> > Am Wed, Jun 21, 2023 at 05:41:36PM +0200 schrieb Emanuele Rocca:
> > > On 2022-10-26 08:20, Moritz Mühlenhoff wrote:
> > > > I think this should rather be applied early after the Bookw
On 2023-06-27 16:58 +0200, Moritz Mühlenhoff wrote:
> Am Wed, Jun 21, 2023 at 05:41:36PM +0200 schrieb Emanuele Rocca:
> > Hey Moritz,
> >
> > On 2022-10-26 08:20, Moritz Mühlenhoff wrote:
> > > I think this should rather be applied early after the Bookworm
> > > release (and ideally we can also f
Am Wed, Jun 21, 2023 at 05:41:36PM +0200 schrieb Emanuele Rocca:
> Hey Moritz,
>
> On 2022-10-26 08:20, Moritz Mühlenhoff wrote:
> > I think this should rather be applied early after the Bookworm
> > release (and ideally we can also finish off the necessary testing
> > and add -fstack-clash-protec
Hey Moritz,
On 2022-10-26 08:20, Moritz Mühlenhoff wrote:
> I think this should rather be applied early after the Bookworm
> release (and ideally we can also finish off the necessary testing
> and add -fstack-clash-protection at least for amd64 and other archs
> which are ready for it (#918914)).
Package: dpkg-dev
Followup-For: Bug #1021292
X-Debbugs-Cc: woo...@wookware.org, debian-devel@lists.debian.org
> We decided that the best thing to do was create a new hardening flags
> feature called 'branch' to add to the existing set. This enables
> -mbranch-protection=sta
Programming Lang: C
Description : run amd64 binaries on arm64 without emulating library calls
Using DynaRec on arm64, box64 will dynamically recompile x64_64 code to
aarch64 but will also translate calls to foreign library functions to
native library calls. This usually makes amd64 executables
wrong to me:
on a dual-architecture amd64/i386 system (or arm64/armhf or any other
combination), there is no point in running more than one architecture's
copy of the MATE polkit authentication agent. They'll all have the same
UI and the same behaviour, so any single architecture is eno
Hi Thomas, dear DD colleagues (et al.),
On Fr 18 Nov 2022 20:55:39 CET, Thomas Uhle wrote:
Dear maintainers,
in addition to Christian Britz' report, the autostart desktop file
should also be in mate-polkit because of the architecture triplet in
the path to polkit-mate-authentication-agent
On Nov 01, Sebastian Ramacher wrote:
> > this change is only targeted at two archs, which I'd hope could cope with
> > it.
> If we ignore/break MA: same co-installability, sure.
Sure, but this means that a much smaller subset of packages will need to
be rebuilt on all architectures.
--
ciao,
On Tue, Nov 01, 2022 at 01:09:39AM +0100, Sebastian Ramacher wrote:
> > this change is only targeted at two archs, which I'd hope could cope with
> > it.
> If we ignore/break MA: same co-installability, sure.
point taken, thanks!
--
cheers,
Holger
⢀⣴⠾⠻⢶⣦⠀
⣾⠁⢠⠒⠀⣿⡁ holger@(debian|rep
On 2022-10-31 23:28:21 +, Holger Levsen wrote:
> On Thu, Oct 27, 2022 at 12:27:12AM +0200, Sebastian Ramacher wrote:
> > Some of the architectures already have a hard time keeping up with the
> > normal load.
>
> this change is only targeted at two archs, which I'd hope could cope with it.
If
On Thu, Oct 27, 2022 at 12:27:12AM +0200, Sebastian Ramacher wrote:
> Some of the architectures already have a hard time keeping up with the
> normal load.
this change is only targeted at two archs, which I'd hope could cope with it.
> Enabling these flags as soon as the trixie release cycle star
On 2022-10-26 20:20:48 +0200, Moritz Mühlenhoff wrote:
> Wookey wrote:
> > So the immediate issue now is whether or not to enable this by default
> > in bookworm?
>
> The majority of packages will not be rebuilt until the release, so
> if we add this now it means that packages pick up the change w
On 2022-10-26 14:23 -0500, Richard Laager wrote:
>
> How hard would it be to rebuild everything?
>
> I don't actually know what facilities Debian has for that. Would it be a
> binNMU of everything?
It would. We don't do that.
In the past it would have wildly overloaded our buildds. Such a thing
On 10/26/22 13:20, Moritz Mühlenhoff wrote:
Wookey wrote:
So the immediate issue now is whether or not to enable this by default
in bookworm?
The majority of packages will not be rebuilt until the release
How hard would it be to rebuild everything?
I don't actually know what facilities Debi
Wookey wrote:
> So the immediate issue now is whether or not to enable this by default
> in bookworm?
The majority of packages will not be rebuilt until the release, so
if we add this now it means that packages pick up the change when
they are rebuilt in stable via a security update or point relea
and are non-baseline (illegal instruction)
> on older or more-embedded i386 like the ones in our current i386 baseline?
I'm not sure (I know a lot more about the arm64 side of this than the
amd64 side), but we are only enabling this on amd64, not i386. amd64
binaries don't run on i
On Tue, 25 Oct 2022 at 15:34:26 +0100, Wookey wrote:
> These are hardware features (new instructions) that 'tag' pointers and
> branch targets to make it much harder for malicious code to implement
> ROP (return oriented programming) and JOP (Jump oriented programming)
> attacks.
>
> They have bee
been enabled in other distros for some time and
we've done an archive rebuild of arm64 to check that there was not
significant breakage.
There is a lot of discussion of the details of this and the pros/cons
of enabling this by default in the thread so I will try to keep this
mail as a summar
Hi,
On 11/27/18 2:38 AM, Re4son wrote:
>
> I have previously compiled this excel sheet with data relevant to this thread:
>
> https://github.com/Re4son/kali-gemini-multistrap-config/raw/files/Arm64List.xls
>
> Any feedback, correction and addition that could benefit this discussion
> would be
On Mon, Jan 7, 2019 at 11:30 PM Mike Hommey wrote:
> > it would be extremely useful to confirm that 32-bit builds can in fact
> > be completed, simply by adding "-Wl no-keep-memory" to any 32-bit
> > builds that are failing at the linker phase due to lack of memory.
>
> Note that Firefox is built
https://sourceware.org/bugzilla/show_bug.cgi?id=22831 sorry using phone to
type, mike, comment 25 shows some important options to ld gold would it be
possible to retry with those? 32 bit. Disabling mmap looks really important
as clearly a 4gb+ binary is guaranteed going to fail to fit into 32bit mm
On Tue, Jan 8, 2019 at 7:26 AM Luke Kenneth Casson Leighton
wrote:
>
> On Tue, Jan 8, 2019 at 7:01 AM Luke Kenneth Casson Leighton
> wrote:
> trying this:
>
> $ python evil_linker_torture.py 3000 400 200 50
>
> running with "make -j4" is going to take a few hours.
ok so that did the trick:
On Tue, Jan 8, 2019 at 7:01 AM Luke Kenneth Casson Leighton
wrote:
> i'm going to see if i can get above the 4GB mark by modifying the
> Makefile to do 3,000 shared libraries instead of 3,000 static object
> files.
fail. shared libraries link extremely quickly. reverted to static,
trying this
$ python evil_linker_torture.py 3000 100 100 50
ok so that managed to get up to 1.8GB resident memory, paused for a
bit, then doubled it to 3.6GB, and a few seconds later successfully
outputted a binary.
i'm going to see if i can get above the 4GB mark by modifying the
Makefile to do 3,000 sh
On Tue, Jan 8, 2019 at 6:27 AM Luke Kenneth Casson Leighton
wrote:
> i'm just running the above, will hit "send" now in case i can't hit
> ctrl-c in time on the linker phase... goodbye world... :)
$ python evil_linker_torture.py 2000 50 100 200
$ make -j8
oh, err... whoopsie... is this norm
$ python evil_linker_torture.py 2000 50 100 200
ok so it's pretty basic, and arguments of "2000 50 10 100"
resulted in around a 10-15 second linker phase, which top showed to be
getting up to around the 2-3GB resident memory range. "2000 50 100
200" should start to make even a system
On Tuesday, January 8, 2019, Mike Hommey wrote:
> On Mon, Jan 07, 2019 at 11:46:41PM +, Luke Kenneth Casson Leighton
> wrote:
>
> > At some point apps are going to become so insanely large that not even
> > disabling debug info will help.
>
> That's less likely, I'd say. Debug info *is* getti
On Mon, Jan 07, 2019 at 11:46:41PM +, Luke Kenneth Casson Leighton wrote:
> On Tuesday, January 8, 2019, Mike Hommey wrote:
>
> > .
> >
> > Note that Firefox is built with --no-keep-memory
> > --reduce-memory-overheads, and that was still not enough for 32-bts
> > builds. GNU gold instead of
On Tuesday, January 8, 2019, Mike Hommey wrote:
> .
>
> Note that Firefox is built with --no-keep-memory
> --reduce-memory-overheads, and that was still not enough for 32-bts
> builds. GNU gold instead of BFD ld was also given a shot. That didn't
> work either. Presently, to make things link at a
the
> > rebuilds that I'd just started. Here they are, after a few false
> > starts. I've been rebuilding the archive *specifically* to check if we
> > would have any problems building our 32-bit Arm ports (armel and
> > armhf) using 64-bit arm64 hardware. I might have foun
(hi edmund, i'm reinstating debian-devel on the cc list as this is not
a debian-arm problem, it's *everyone's* problem)
On Mon, Jan 7, 2019 at 12:40 PM Edmund Grimley Evans
wrote:
> > i spoke with dr stallman a couple of weeks ago and confirmed that in
> > the original version of ld that he wro
cally* to check if we
> would have any problems building our 32-bit Arm ports (armel and
> armhf) using 64-bit arm64 hardware. I might have found other issues
> too, but that was my goal.
very cool.
steve, this is probably as good a time as any to mention a very
specific issue with binu
d way back before DC18 that I'd publish the results of the
rebuilds that I'd just started. Here they are, after a few false
starts. I've been rebuilding the archive *specifically* to check if we
would have any problems building our 32-bit Arm ports (armel and
armhf) using 64-bit arm64 ha
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 l
On Wed, Nov 28, 2018 at 12:32:51PM -0800, Steve Langasek wrote:
> I would caution against prematurely optimizing for build-time. Yes,
> building the entire source package twice is a waste of resources, but it's
> probably a drop in the bucket.
My mail concert was not build-time, but our (maintain
Ubuntu Touch was sunsetted.
> >...
> Is there some rationale documented somewhere why this wasn't used in
> Ubuntu for the arm64 port?
Documented - no.
The rationale was that the X stack on ARM64 in Ubuntu was enabled
specifically to support mobile, where, just like for armhf, the rel
On 2018-11-27 21:19 -0300, Lisandro Damián Nicanor Pérez Meyer wrote:
> El martes, 27 de noviembre de 2018 20:39:58 -03 Steve Langasek escribió:
> > prepare dual stack packages that use the symbols file magic from
> > Ubuntu, rebuild all the reverse-dependencies, and identify all those
> > package
On Wed, Nov 28, 2018 at 05:03:51PM +0300, Dmitry Shachnev wrote:
> On Tue, Nov 27, 2018 at 11:00:52PM -0800, Steve Langasek wrote:
> > $ grep-dctrl -n -sSource:Package -FDepends \
> > -e
> > 'libqt5(gui|3drenderer|quick|quickparticles|quickwidgets|multimediawidgets)5[[:space:]]*(\(>=
> >
is wasn't used in
Ubuntu for the arm64 port?
arm64 in Ubuntu (including the current LTS) does diverge from the arm64
in Debian - but Ubuntu uses ES-only, not the dual stack solution you are
referring to.
cu
Adrian
--
"Is there not promise of rain?" Ling Tan asked suddenly ou
ource packages, in order to avoid having to make a choice
> > between GL and GLES on arm64.
> I wonder if these can be new binaries in existing source packages, instead
> of separate source packages. Otherwise we will have too much code duplication,
> and also wasted time: for examp
wayland-opensource-src
qtcharts-opensource-src
> So perhaps someone in this thread is willing to put in this effort to
> maintain 6 source packages, in order to avoid having to make a choice
> between GL and GLES on arm64.
I wonder if these can be new binaries in existing source packages,
ly on the particular binary package name, e.g.:
(optional)_ZN25QOpenGLFunctions_3_2_Core14versionProfileEv@Qt_5 5.2.0 2
→ gets a dependency on libqt5gui5 only
(optional|arch=!armhf !arm64
!armel)_ZN20QOpenGLFunctions_ES214versionProfileEv@Qt_5 5.2.0 3
→ gets a dependency on libqt5gui5-gles only
each of those gles source packages is a purely mechanical transformation
> of the base Qt source package.
>
> So perhaps someone in this thread is willing to put in this effort to
> maintain 6 source packages, in order to avoid having to make a choice
> between GL and GLES on arm64.
lding Qt with GLES we'd still be able to make use of mesa as it
provides both GL and GLES capabilities, while also allowing Qt to make use
of blobs if a user so chooses.
> > By choosing to build Qt with GLES on ARM64, we make Debian a more
> > attractive platform for vendors who&#x
f analysis as above, so
anyone interested in doing this in Debian can reasonably work out the scope.
And each of those gles source packages is a purely mechanical transformation
of the base Qt source package.
So perhaps someone in this thread is willing to put in this effort to
maintain 6 source
On Wed, Nov 28, 2018 at 7:30 AM Lisandro Damián Nicanor Pérez Meyer wrote:
> Just curious: is there any project alive for the PowerVR SGX530 ?
There used to be a very brief effort around PowerVR devices but it
looks like that has died now. Some of the project site was captured by
archive.org and
El martes, 27 de noviembre de 2018 21:51:47 -03 Lisandro Damián Nicanor Pérez
Meyer escribió:
[snip]
> > > prepare dual stack packages that use the symbols file magic from
> > > Ubuntu, rebuild all the reverse-dependencies, and identify all those
> > > packages which are libraries and which end up
El martes, 27 de noviembre de 2018 21:19:20 -03 Lisandro Damián Nicanor Pérez
Meyer escribió:
> El martes, 27 de noviembre de 2018 20:39:58 -03 Steve Langasek escribió:
> > On Tue, Nov 27, 2018 at 07:58:17PM -0300, Lisandro Damián Nicanor Pérez
>
> Meyer wrote:
> [snip]
>
> > > Yes, we are :-) D
El martes, 27 de noviembre de 2018 20:39:58 -03 Steve Langasek escribió:
> On Tue, Nov 27, 2018 at 07:58:17PM -0300, Lisandro Damián Nicanor Pérez
Meyer wrote:
[snip]
> > Yes, we are :-) Dmitry has been working on them (he is also an Ubuntu Qt
> > maintainer). He points me out that those 7 packa
On Tue, Nov 27, 2018 at 07:58:17PM -0300, Lisandro Damián Nicanor Pérez Meyer
wrote:
> > https://launchpad.net/ubuntu/+source/qtbase-opensource-src-gles/5.7.1+dfsg->
> > 2ubuntu4~1
> > And here is the list of all packages that required dual-stack at least as of
> > 2017, when Ubuntu stopped deve
El martes, 27 de noviembre de 2018 17:19:32 -03 Dmitry Shachnev escribió:
> Hi Rohan!
>
> On Tue, Nov 27, 2018 at 04:24:43PM +0100, Rohan Garg wrote:
> > [...]
> >
> > I concur here. It was correctly pointed out in another reply that by using
> > OpenGL we're specifically catering to software tha
El domingo, 25 de noviembre de 2018 21:18:39 -03 Paul Wise escribió:
> On Sun, Nov 25, 2018 at 8:58 PM Lisandro Damián Nicanor Pérez Meyer wrote:
> > Both Dmitry and I just learned that the RPI has the VC4 driver which
> > enables it to do hardware acceleration for Desktop OpenGL, we must admit
> >
Hi Steve!
First of all: thanks for chiming in!
El martes, 27 de noviembre de 2018 19:06:27 -03 Steve Langasek escribió:
> Hi Lisandro,
[snip]
> > This waterfall schema means *multiple* libraries would have to start doing
> > this two-binaries thing, as Ubuntu devs discovered. But remember that Qt
Hi Lisandro,
On Fri, Nov 23, 2018 at 11:05:11PM -0300, Lisandro Damián Nicanor Pérez Meyer
wrote:
> Andy: explicitly CCing you because I think it answers part of a question you
> did but in another part of the thread.
> El viernes, 23 de noviembre de 2018 06:58:13 -03 Steve McIntyre escribió:
>
not support the GPU.
Here I agree with Luke Kenneth Casson Leighton’s opinion [1].
I think we should aim to provide the best possible experience with the free
software ecosystem. The experience with proprietary drivers should be the
second priority, if priority at all.
> By choosing to build Qt w
On Mon, Nov 26, 2018 at 03:39:03PM -0800, Keith Packard wrote:
> Steve Langasek writes:
> > Long ago I heard rumors of development work on mesa that would allow it to
> > function as a proxy library, so that apps would link against libGL as needed
> > and the GL implementation would use a hardwar
n Sun, 25 Nov 2018, Lisandro Damián Nicanor Pérez Meyer wrote:
> > It seems now clear that the general consensus seems to expect:
> > = Qt available for both Desktop and ES OpenGL flavours
> > = If no change is possible, keep arm64 with Desktop OpenGL support
>
> I'm not p
Hi,
On 2018-11-27 02:46 +, Wookey wrote:
> >
> > Well, that's at very least an interesting data point. So yes, they exist,
> > but
> > they are new and expensive. Can I assume that this means most of our arm64
> > users do not yet get to them?
> Not
place.
>
>> I also invited someone else who is working on a concrete project involving
>> Kali Linux (Debian derivative) and off-the-shelf arm64 hardware available
>> now but he also did not have the time to contribute to the discussion.
>> Software can be fix
Hi,
On 26/11/18 8:58 pm, Riku Voipio wrote:
> On Thu, Nov 22, 2018 at 07:14:44PM -0300, Lisandro Damián Nicanor Pérez Meyer
> wrote:
>> El jueves, 22 de noviembre de 2018 18:30:39 -03 Marcin Juszkiewicz escribió:
>
>> The real issue here is that *many* arm64 boards cur
On Fri, Nov 23, 2018 at 12:18 AM Lisandro Damián Nicanor Pérez Meyer
wrote:
> So: what's the best outcome for our *current* users? Again, pick only one.
here's a perspective that may not have been considered: how much
influence and effect on purchasing decisions would the choice made
have?
we k
On 2018-11-23 23:10 -0300, Lisandro Damián Nicanor Pérez Meyer wrote:
> El viernes, 23 de noviembre de 2018 12:26:49 -03 Wookey escribió:
> >
> > My main desktop is now an arm64 machine with an nvidia PCI graphics
> > card. These are fairly new (and currently expensive), but
Steve Langasek writes:
> Long ago I heard rumors of development work on mesa that would allow it to
> function as a proxy library, so that apps would link against libGL as needed
> and the GL implementation would use a hardware-accelerated GLES driver where
> possible, falling back to software GL
Sun, 25 Nov 2018, Lisandro Damián Nicanor Pérez Meyer wrote:
> >> > It seems now clear that the general consensus seems to expect:
> >> > = Qt available for both Desktop and ES OpenGL flavours
> >> > = If no change is possible, keep arm64 with Desktop OpenGL support
&g
On Sat, 2018-11-24 at 21:51 +0100, Adam Borowski wrote:
> On Sat, Nov 24, 2018 at 06:06:16PM +, Ben Hutchings wrote:
> > On Sat, 2018-11-24 at 15:21 +, Simon McVittie wrote:
> > [...]
> > > Recent AMD GPUs use the "amdgpu" kernel driver and its accompanying Mesa
> > > user-space driver, whi
evel/constitution.en.html#item-6).
>
> Will "kind of" do. Read below.
>
>
>> On Sun, 25 Nov 2018, Lisandro Damián Nicanor Pérez Meyer wrote:
>> > It seems now clear that the general consensus seems to expect:
>> > = Qt available for both Desktop and E
El lunes, 26 de noviembre de 2018 14:21:25 -03 Alan Corey escribió:
> Why couldn't you choose QT for Desktop or QT for ES OpenGL when you
> compile your program?
It's a Qt build-time option. This in an upstream choice, not ours and not up
to us to fix.
> Supply both libraries?
Already answered
Try glxgears and es2gears on few different platforms. On a Pi 3b
glxgears runs at about 45 FPS, es2gears slightly lower. On my Rock64
it's in the hundreds of FPS but that's Mali. Look at omxplayer, full
screen HD video while the CPU idles (on a Pi). The GPU is more
capable than the CPU. You ca
nd of" do. Read below.
> On Sun, 25 Nov 2018, Lisandro Damián Nicanor Pérez Meyer wrote:
> > It seems now clear that the general consensus seems to expect:
> > = Qt available for both Desktop and ES OpenGL flavours
> > = If no change is possible, keep arm64 with Desktop O
Hello Ian,
On Mon, Nov 26, 2018 at 2:04 PM Ian Campbell wrote:
>
> On Mon, 2018-11-26 at 12:07 +0100, bret curtis wrote:
> > The hardware that supports GLES also supports OpenGL because GLES is
> > a subset of OpenGL.
>
> I'm confused by this inference. If GLES is a subset of OpenGL then
> surely
n a concrete project involving
> Kali Linux (Debian derivative) and off-the-shelf arm64 hardware available
> now but he also did not have the time to contribute to the discussion.
> Software can be fixed/improved to also work with OpenGL ES. However
> hardware, once bought, cannot be fixed t
On Mon, 2018-11-26 at 12:07 +0100, bret curtis wrote:
> The hardware that supports GLES also supports OpenGL because GLES is
> a subset of OpenGL.
I'm confused by this inference. If GLES is a subset of OpenGL then
surely hardware which claims to implement GLES is at liberty to only
implement that
Quoting Raphael Hertzog (2018-11-26 12:37:57)
> Software can be fixed/improved to also work with OpenGL ES. However
> hardware, once bought, cannot be fixed to support Desktop OpenGL when
> it has been designed for OpenGL ES only.
Is some _hardware_ really "designed for OpenGL ES only"?
I guess
ge is possible, keep arm64 with Desktop OpenGL support
I'm not pleased with how this discussion was handled. First of all,
you did not leave enough time for all stakeholders to participate in
the discussion (started on November 22th, closed November 25th, 3 days,
that's not a reasonable
Hi!
On Mon, Nov 26, 2018 at 11:40 AM Raphael Hertzog wrote:
> >
> > What applications does Debian have in its repo that only support GLES?
>
> Wrong question. Maybe it makes sense for you at the application level for
> the application that are hooking into OpenGL directly. But we are speaking
> o
e problem is that there are applications that make use of Qt that do
> not support GLES while Qt can support both. So these things can't be
> shipped on armel and armhf and now possibly arm64.
>
> What applications does Debian have in its repo that only support GLES?
Wrong questio
> On Sat, 24 Nov 2018, bret curtis wrote:
> > This is a very wrong assumption, the OpenGL on a RPi (all of them) is
> > hardware accelerated via the VC4 mesa driver by Eric Anholt which is
> > shipped, by default, on by Raspbian. It supports up to OpenGL 2.1 and
> > if you plan on having hardware a
On Thu, Nov 22, 2018 at 07:14:44PM -0300, Lisandro Damián Nicanor Pérez Meyer
wrote:
> El jueves, 22 de noviembre de 2018 18:30:39 -03 Marcin Juszkiewicz escribió:
> > Does it mean that arm64 box with PCI Express graphics card will be not
> > able to use Qt based software? I ca
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 th
Hello Bret,
On Sat, 24 Nov 2018, bret curtis wrote:
> This is a very wrong assumption, the OpenGL on a RPi (all of them) is
> hardware accelerated via the VC4 mesa driver by Eric Anholt which is
> shipped, by default, on by Raspbian. It supports up to OpenGL 2.1 and
> if you plan on having hardwar
On Sun, Nov 25, 2018 at 8:58 PM Lisandro Damián Nicanor Pérez Meyer wrote:
> Both Dmitry and I just learned that the RPI has the VC4 driver which enables
> it to do hardware acceleration for Desktop OpenGL, we must admit that this is
> a game changer in many ways, even if we are talking on just on
On Sun, Nov 25, 2018 at 06:28:45AM +0100, Tollef Fog Heen wrote:
> ]] Adam Borowski
>
> > Tested on an early bronze age i386 box with an "82915G/GV/910GL"; both
> > glxgears and es2gears_x11 work fine. I don't think anyone is going to run a
> > modern desktop environment on a machine older than
e, if the goal is achieved, it will be certainly
targeted for Buster+1.
= If no change is possible, keep arm64 with Desktop OpenGL support
That seems to be what most of you want, and to say the truth, the easiest for
us: we just keep status quo, no transition needed. We just package the next
]] Adam Borowski
> Tested on an early bronze age i386 box with an "82915G/GV/910GL"; both
> glxgears and es2gears_x11 work fine. I don't think anyone is going to run a
> modern desktop environment on a machine older than that.
>
> But that's an Intel card -- with nVidia, stuff 3 years old gets
1 - 100 of 190 matches
Mail list logo
