Re: Upcoming Qt switch to OpenGL ES on arm64

[Lisandro Damián Nicanor Pérez Meyer]

Hi Bret!

El viernes, 23 de noviembre de 2018 11:14:34 -03 psi...@gmail.com escribió:
> Just chiming in here as package maintainer of an effected package, OpenMW
> and also an upstream developer of said software, along with contributor to
> OpenSceneGraph.
> 
> Here are some related open bugs involving Qt and GLESv2 and arm*:
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=850021
> ^-- RM: openmw [armhf] -- RoQA; needs OSG built against libGL
[snip]

Yes, that's a drawback we are not hiding. Applications needing Desktop OpenGL 
would be left out. But...


> If you say that arm64 has to be GLESv2 as well, then that is yet another
> arch that OpenMW can't be built for.  Before the GLESv2 switch, OpenMW
> worked just fine on arm* hardware, including the Raspberry Pi/Raspbian with
> the VC4 mesa driver that has OpenGL 2.0 support.

...one thing is running and quite another is: how well does it performs when 
doing 100% CPU-based OpenGL? Are your users *really* interested to use your 
application when all drawing must be CPU-based?

[snip]
 
> I beg you, please either reverse the GLES decision in Qt or provide two
> separate packages for GL or GLES support.

I'm afraid providing two set ups is a non-go (alas, we would be doing that 
already and avoiding all this). And I don't there are many armel/armhf users 
with hardware Desktop OpenGL in their boards.



signature.asc
Description: This is a digitally signed message part.

Re: Upcoming Qt switch to OpenGL ES on arm64

[Lisandro Damián Nicanor Pérez Meyer]

El viernes, 23 de noviembre de 2018 09:23:29 -03 Dmitry Shachnev escribió:
> On Fri, Nov 23, 2018 at 01:08:03PM +0100, Marcin Juszkiewicz wrote:
> > W dniu 23.11.2018 o 13:00, Dmitry Shachnev pisze:
> > > I would still like to know if the upcoming arm64 desktop devices have
> > > any problems working with OpenGL ES.
> > 
> > Arm64 desktop systems use Radeon or NVidia cards with same opensource
> > drivers as x86-64 systems. So you can check how it goes with OpenGL ES
> > on your amd64 desktop.
> 
> I have an embedded Intel card right now :)

Same here, 10 years old machine with an embedded Intel video card. I don't 
think I can expect it to work with GLES.

-- 
Lisandro Damián Nicanor Pérez Meyer
http://perezmeyer.com.ar/
http://perezmeyer.blogspot.com/


signature.asc
Description: This is a digitally signed message part.

Re: Upcoming Qt switch to OpenGL ES on arm64

[Lisandro Damián Nicanor Pérez Meyer]

Hi Wookey!

El viernes, 23 de noviembre de 2018 12:26:49 -03 Wookey escribió:
> On 2018-11-23 03:27 +0300, Dmitry Eremin-Solenikov wrote:
> > Hello,
> > 
> > > - Qt is tied to either Desktop or GLES: yes
> > > 
> > > So we need to pick one. The question is then which one will benefit our
> > > users most.
> > > 
> > > So far I personally know 0 people with an arm64 board with PCI slots,
> > > while I know many with arm64 boards with hardware GLES support.
> 
> My main desktop is now an arm64 machine with an nvidia PCI graphics
> card. These are fairly new (and currently expensive), but I have
> reason to believe there is more of this sort of thing coming, and
> laptop-format machines.

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?

> I need to investigate this further, but changing from GL to GLES just
> at the moment where desktop hardware starts to make inroads could be a
> big own goal on arm64.

That's *exactly* what I have been reading since I filled the bug I mentioned 
before in... 2015. So far all I could see are embedded boards.

But hey, we can change it now and always go back in the future if arm64 
motherboards become ubiquitous.

> I recall Linaro doing some work on this back
> when it started (to make it easier to switch between GL and
> GLES). Possibly that work never actually got done, just talked out.

It would really help, indeed.

-- 
Lisandro Damián Nicanor Pérez Meyer
http://perezmeyer.com.ar/
http://perezmeyer.blogspot.com/


signature.asc
Description: This is a digitally signed message part.

Re: Upcoming Qt switch to OpenGL ES on arm64

[Lisandro Damián Nicanor Pérez Meyer]

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ó:
> On Fri, Nov 23, 2018 at 03:27:57AM +0300, Dmitry Eremin-Solenikov wrote:
[snip]
> >Can you build two packages and allow user to select, which one he wants to
> >install? Or those packages will be binary incompatible?
> 
> That's a good question, yes. It'w ahst I was wondering too.

And that's a perfectly valid question, one we did in 2015, Ubuntu tried out 
(as Dmitry pointed out) and did not work.

Why?

Short story: really *too* complicated and error prone.

Long story:

Please first check this image:



That's almost all of Qt for 5.10 (we have now new submodules, so I need to 
update it).

The Desktop/GLES decision is done at the root of the graph, qtbase. This 
decision changes the API/ABI of libqt5gui5, one of the libraries provided by 
qtbase.

So, as the API/ABI changes then we would need to (probably) ship two set of 
headers and (for sure) two different libraries, let's say libqt5gui5 for 
Desktop and libqt5gui5gles for GLES.

But it doesn't ends there. The whole graph you saw is actually the *entire* 
Qt. Upstream provides it either as a big fat tarball or as submodules. We took 
the submodules route because building the whole tarball as one would take 
literally days in slow arches. And a single mistake could be disastrous.

Now whatever switch is applied to qtbase it's "inherited" by the rest of the 
submodules. So if we ship two versions of libqt5gui5 then we would probably 
need to ship two versions of the libs provided by qtdeclarative, which is 
affected by this switch.

This waterfall schema means *multiple* libraries would have to start doing 
this two-binaries thing, as Ubuntu devs discovered. But remember that Qt is 
really a set of submodules, so in any later version any submodule could start 
using this switch for something. So whatever change could mean yet another set 
of binaries with a transition with multiple rebuilds of the big part of rdeps 
of Qt... no, we don't want to enter that mess.

So we either keep the status quo of keeping arm64 in Desktop GL or switch to 
GLES. The question is: which use case gives more benefit for our users for the 
next stable release?

> >> So far I personally know 0 people with an arm64 board with PCI slots,
> >> while I know many with arm64 boards with hardware GLES support.
> >
> >I'm working with big arm64 iron, so for me a server arm64 board with PCIe
> >slots (and thus PCIe graphic cards) and on-board Aspeed "VGA card" is more
> >common compared to GLES-enabled arm64 SoC.

How many Qt-based applications do you use there? Which ones use OpenGL?

> Yeah - it depends exactly on your background. There's a small (but
> growing) set of arm64 desktop users, and it would be unfortunate to
> cut them off.

Let's be fair: I live almost at the end of the world, probably at very least 
600 km away from the next DD and in a country in which buying new hardware 
it's not exactly the easiest thing (my current machine, currently the only one 
I have working, is now 10 years old...). So yes, as Steve says, it depends on 
your background.

But even here in this place I have seen *a lot* of "cheap" arm64 boards. Yes, 
the RPI3[+] is ubiquitous. And having to render Open GL stuff by CPU is 
precisely not the fastest thing around.

But on the other hand most PCI video cards out there can do both GLES and 
Desktop OpenGL. So an arm64-based motherboard which needs nice graphics could 
surely use GLES.

Yes, might not be the best thing out there, but: how many of you are using it 
to render OpenGL stuff with Qt?

And again: you *can* convince me that we better not do the switch, that's 
exactly why we created this thread: we wanted fellow Debian users/developers 
to share their thoughts (and it's working!).

So, again: which of the two flavors is the one that benefits more of our user 
base?

-- 
She got her good looks from her father. He's a plastic surgeon.
 -- Groucho Marx

Lisandro Damián Nicanor Pérez Meyer
http://perezmeyer.com.ar/
http://perezmeyer.blogspot.com/


signature.asc
Description: This is a digitally signed message part.

Bug#914464: ITP: python-milksnake -- A setuptools/wheel/cffi extension to embed a binary data in wheels

[Jelmer Vernooij]

Package: wnpp
Severity: wishlist
Owner: Jelmer Vernooij 

* Package name: python-milksnake
  Version : 0.1.5
  Upstream Author : Armin Ronacher 
* URL : https://github.com/getsentry/milksnake
* License : Apache
  Programming Lang: Python, Rust
  Description : A setuptools/wheel/cffi extension to embed a binary data in 
wheels

Milksnake is an extension for setuptools that allows distributing dynamic
linked libraries in Python wheels in the most portable way imaginable.

It gives you a hook to invoke your own build process and to then take the
resulting dynamic linked library.

(This is a new dependency for vdirsyncer)

Re: usrmerge -- plan B?

[Daniele Nicolodi]

Hello Adam,

On 23/11/2018 08:19, Adam Borowski wrote:
> On Fri, Nov 23, 2018 at 03:14:44PM +0100, Matthias Klumpp wrote:
>> Am Fr., 23. Nov. 2018 um 14:47 Uhr schrieb Stephan Seitz
>> :
>>>
>>> On Fr, Nov 23, 2018 at 02:04:05 +0100, Matthias Klumpp wrote:
 If there are actual issues encountered, we can always revert a change
>>>
>>> And how do you revert this change? As far as I have understand you can’t
>>> remove the usrmerge package and have your system in the old state again.
>>
>> You don't - it's unstable, for testing these things. If it breaks, you
>> file a bug and fix the system.
> 
> Fix -- not completely restore from backups.  This is not an option with
> usrmerge; we have severity:critical for bugs with such a fallout.

I've seen this repeated multiple times in this thread, where does your
assessment that the usrmerge package can leave the system in a non
working state comes from?

In my experience, usrmerge stops the merge if it encounters some
unforeseen difficulty and hints to how to resolve the problem. Once the
problem has been resolved, usrmerge can be run again and it will pick up
from where it left.

Is your experience different? Can you be more precise on the kind of
errors or system breakage you encountered?

Thank you.

Best,
Daniele

Re: usrmerge -- plan B?

[Guillem Jover]

Hi!

On Wed, 2018-11-21 at 10:23:46 +0100, Adam Borowski wrote:
> with less confidence:
>  • making usrmerge Essential (large amount of effort, known issues)

Oh dear, no, please!

First off, as I've said in the past, I have no problem whatsoever with
the concept, I think it brings both advantages (cleans up the FHS,
makes some things easier, etc) and disadvantages (makes Debian perhaps
a worse development environment for upstreams that want to target other
systems, easier to miss pathnames that should not be under /usr leaking
over, or a proper conversion making it not possible to keep unmerged
/usr for those that would prefer that, for whatever reason, etc).

As a proof-of-concept to make it possible to test the thing, to unearth
bugs, as a quick way to deploy on throwaway containers, or even as a
pragmatic way to switch ones system if there's a need for that no
matter what, right now, the usrmerge package is great.

But I do have a very big problem with us even considering using it as
a way to deploy this change as part of our standard installation or
upgrade. This is a hack, it's subverting the dpkg view of the world,
and while this is intended to be supported somehow from dpkg PoV, I
consider that to be on best-effort basis. For example I still have
not merged the branch [Q] to make dpkg-query cope with the symlink
stuff, as I was waiting for some feedback, and it still has some
conceptual problems. Making usrmerge Essential is the "we cannot be
bothered to do a proper transition and move things to their proper
place" kind of plan. :(

  [Q] 


Please, if we decide we want to do merged /usr, let's do it properly.
I'm still quite appalled that debootstrap has been change *again*
(after it got reverted for stretch) to default to use this method for
new installations…

Thanks,
Guillem

Re: Upcoming Qt switch to OpenGL ES on arm64

[Wookey]

On 2018-11-23 03:27 +0300, Dmitry Eremin-Solenikov wrote:
> Hello,
> > - Qt is tied to either Desktop or GLES: yes
> >
> > So we need to pick one. The question is then which one will benefit our 
> > users
> > most.
> >
> > So far I personally know 0 people with an arm64 board with PCI slots, while 
> > I
> > know many with arm64 boards with hardware GLES support.

My main desktop is now an arm64 machine with an nvidia PCI graphics
card. These are fairly new (and currently expensive), but I have
reason to believe there is more of this sort of thing coming, and
laptop-format machines.

I need to investigate this further, but changing from GL to GLES just
at the moment where desktop hardware starts to make inroads could be a
big own goal on arm64. I recall Linaro doing some work on this back
when it started (to make it easier to switch between GL and
GLES). Possibly that work never actually got done, just talked out.

Wookey
-- 
Principal hats:  Linaro, Debian, Wookware, ARM
http://wookware.org/


signature.asc
Description: PGP signature

Re: usrmerge -- plan B?

[Adam Borowski]

On Fri, Nov 23, 2018 at 03:14:44PM +0100, Matthias Klumpp wrote:
> Am Fr., 23. Nov. 2018 um 14:47 Uhr schrieb Stephan Seitz
> :
> >
> > On Fr, Nov 23, 2018 at 02:04:05 +0100, Matthias Klumpp wrote:
> > >If there are actual issues encountered, we can always revert a change
> >
> > And how do you revert this change? As far as I have understand you can’t
> > remove the usrmerge package and have your system in the old state again.
> 
> You don't - it's unstable, for testing these things. If it breaks, you
> file a bug and fix the system.

Fix -- not completely restore from backups.  This is not an option with
usrmerge; we have severity:critical for bugs with such a fallout.

And yeah, bugs of this severity prevent a package from being a part of the
next stable release.


Meow!
-- 
⢀⣴⠾⠻⢶⣦⠀ I've read an article about how lively happy music boosts
⣾⠁⢰⠒⠀⣿⡁ productivity.  You can read it, too, you just need the
⢿⡄⠘⠷⠚⠋⠀ right music while doing so.  I recommend Skepticism
⠈⠳⣄ (funeral doom metal).

Re: [Pkg-julia-devel] julia_1.0.0-1_amd64.changes REJECTED

[Ian Jackson]

Graham Inggs writes ("Re: [Pkg-julia-devel] julia_1.0.0-1_amd64.changes 
REJECTED"):
> On 2018/11/21 16:11, Bastian Blank wrote:
> > I have not seen a real explanation why it needs to be this and exactly
> > this way.  This setup was explained as either
> > - a workaround for a bug,
> > - a way to get stacktraces from users or
> > - a way to make autopkgtest run.
> 
> Stripping sys.so breaks one of Julia's language features, which is the 
> ability to  trace into its standard library.  An example [1] is found in 
> the documentation.

This seems like a good reason to me to override the lintian warning.

In any case, please can we have the package ACCEPTed and bugs filed so
that we can discuss this in the BTS ?

Ian.

-- 
Ian JacksonThese opinions are my own.

If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.

Re: [Pkg-julia-devel] julia_1.0.0-1_amd64.changes REJECTED

[Graham Inggs]

Hi Bastian

On 2018/11/21 16:11, Bastian Blank wrote:

I have not seen a real explanation why it needs to be this and exactly
this way.  This setup was explained as either
- a workaround for a bug,
- a way to get stacktraces from users or
- a way to make autopkgtest run.


Stripping sys.so breaks one of Julia's language features, which is the 
ability to  trace into its standard library.  An example [1] is found in 
the documentation.


One of Julia's tests checks this, and hence autopkgtests fail if debug 
symbols are missing from sys.so, which is compiled from .jl scripts, not 
C/CXX source.


We could strip sys.so and create a manual debug symbols package, but in 
order to make the Debian package have the same features as upstream,  we 
would make the Julia package depend on it.


We would prefer to ship sys.so unstripped, but if you insist on having 
an extra binary package in the archive in order to silence Lintian, we 
will do it.


Regards
Graham


[1] https://docs.julialang.org/en/v1.0.0/manual/stacktraces/

Bug#914443: usrmerge: run dry-mode first and only if this succeeds, do actual changes

[Holger Levsen]

package: usrmerge
severity: wishlist
x-debbugs-cc: debian-devel@lists.debian.org

On Fri, Nov 23, 2018 at 03:28:37PM +0100, Stephan Seitz wrote:
> > at the moment, the only issues that are known when installing the
> > usrmerge package is when there are different binaries with the same
> > name in /bin and /usr/bin (or /sbin), and I really don't think that
> > this is actually a likely scenario.
> I don’t know but I’ve seen enough strange installations.
 
indeed, life is strange.

> It would be good if the usrmerge package would do a dry-run as part of the
> installation. If there are duplicate files the list will be printed (or
> mailed) and the installation will fail without breaking the whole upgrade
> process. The the admin can fix the problem later.

filing this idea as a wishlist bug against the usrmerge package.

btw: what do you think about providing usrmerge in stretch-backports?


-- 
cheers,
Holger

---
   holger@(debian|reproducible-builds|layer-acht).org
   PGP fingerprint: B8BF 5413 7B09 D35C F026 FE9D 091A B856 069A AA1C


signature.asc
Description: PGP signature

Re: usrmerge -- plan B?

[Stephan Seitz]

On Fr, Nov 23, 2018 at 03:14:44 +0100, Matthias Klumpp wrote:

There are always unforseen issues to be expected when upgrading. And


Of course, and since a dist-upgrade will bring newer software you may 
already have to fix configuration files.



at the moment, the only issues that are known when installing the
usrmerge package is when there are different binaries with the same
name in /bin and /usr/bin (or /sbin), and I really don't think that
this is actually a likely scenario.


I don’t know but I’ve seen enough strange installations.

It would be good if the usrmerge package would do a dry-run as part of 
the installation. If there are duplicate files the list will be printed 
(or mailed) and the installation will fail without breaking the whole 
upgrade process. The the admin can fix the problem later.


Shade and sweet water!

Stephan

--
| Public Keys: http://fsing.rootsland.net/~stse/keys.html |


smime.p7s
Description: S/MIME cryptographic signature

Re: usrmerge -- plan B?

[Michael Stone]

On Fri, Nov 23, 2018 at 03:14:44PM +0100, Matthias Klumpp wrote:

For these cases though maybe the usrmerge script could ask the admin
on what to do to handle these particular binaries, instead of failing.


Maybe, as I suggested upthread, there could be a preview mode in which 
the admin could be told what would happen, alerted if the process is 
going to fail, and given some guidance as to what to do--*before* 
blindly pulling the trigger. We could even ask people to report on 
whether the preview mode predicts issues on their systems in order to 
gather data--which I think is far more likely than people letting us 
know whether the process broke (past tense) their systems (for the sake 
of science).

Re: usrmerge -- plan B?

[Stephan Seitz]

On Fr, Nov 23, 2018 at 03:02:00 +0100, Hans wrote:

Am Freitag, 23. November 2018, 14:47:28 CET schrieb Stephan Seitz:
And how do you revert this change? As far as I have understand you 
can’t remove the usrmerge package and have your system in the old 
state again.

Making an image of the whole hard drive is always a good idea.


While this is easy done if the system is a VMware VM I know my fellow 
admins well enough that they will simply cancel the update because they 
are not interested in debugging the upgrade process for a single package 
they don’t need.



So, that is, where "testing" is standing for. Testing before release


You know I don’t have doubts that you won’t have problems (or very few) 
if you do a new testing installation. I don’t like Marco’s attitude but 
he is doing a good job. If he has tested his package as he said this 
isn’t the problem.


But Debian/testing doesn’t mean testing on real servers which have 
„survived” different Debian releases, where different admins copied files 
from one location to another, or with some third-party software.


If the update of 2% of our systems won’t work because of failing 
usrmerge I would be asked if Debian is the right distribution.

Good point. However, this should be told to Microsoft admins or their
deciders.


;-) But while there are no alternative Windows distributions Debian isn’t 
the only one and can be changed.


Shade and sweet water!

Stephan

--
| Public Keys: http://fsing.rootsland.net/~stse/keys.html |


smime.p7s
Description: S/MIME cryptographic signature

Re: usrmerge -- plan B?

[Matthias Klumpp]

Am Fr., 23. Nov. 2018 um 14:47 Uhr schrieb Stephan Seitz
:
>
> On Fr, Nov 23, 2018 at 02:04:05 +0100, Matthias Klumpp wrote:
> >If there are actual issues encountered, we can always revert a change
>
> And how do you revert this change? As far as I have understand you can’t
> remove the usrmerge package and have your system in the old state again.

You don't - it's unstable, for testing these things. If it breaks, you
file a bug and fix the system.

> As others in the thread have mentioned they don’t see the risk with new
> installations but with old systems with different admins and third-party
> software.
>
> >anyway. During distribution upgrades there is a lot that can be wrong
> >and a lot of stuff the administrator needs to care about (config file
>
> Right, and it means he has enough to do and doesn’t want to debug the
> usrmerge. I don’t want to have a usrmerge at a dist-upgrade. You don’t
> really know the sequence of the package updates. I think the risk is too
> big to have a partial upgraded system.

For the sequence of installations, the APT maintainers can shed light
on what the proper plan could be to ensure the usrmerge update happens
at the right time.

> >with information to the system administrator on what to do in case of
> >an error, and works for 98% of all users anyway, I see no reason not
>
> If the update of 2% of our systems won’t work because of failing usrmerge
> I would be asked if Debian is the right distribution.

There are always unforseen issues to be expected when upgrading. And
at the moment, the only issues that are known when installing the
usrmerge package is when there are different binaries with the same
name in /bin and /usr/bin (or /sbin), and I really don't think that
this is actually a likely scenario.
For these cases though maybe the usrmerge script could ask the admin
on what to do to handle these particular binaries, instead of failing.

I am not strongly advocating for going down this route and actually
migrating all systems on update, but I do not want us to dismiss that
option because we are scared that something might go wrong without
actually knowing that there are unfixable cases where the update might
inevitably break on older installations. Instead, I would rather want
to try out the migration on a bigger scale - potentially and
temporarily break unstable (with a warning, of course), instead of
discussing over and over again potential issues that might not
actually be real and delaying a useful change because of that.

(TBH, for the buster release not switching the buildds to usrmerge and
keep debootstrap/the installer to install in an usrmerged
configuration and then do the final switch during bullseye seems
sensible and I don't see any issue this would cause. Of course if the
reproducible-builds test turns out that we only need to fix a small
amount of packages to make the usrmerge happen on buildds as well,
switching them as well could make sense still)

Cheers,
Matthias

-- 
I welcome VSRE emails. See http://vsre.info/

Re: Upcoming Qt switch to OpenGL ES on arm64

[psi29a]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Just chiming in here as package maintainer of an effected package, OpenMW
and also an upstream developer of said software, along with contributor to
OpenSceneGraph.

Here are some related open bugs involving Qt and GLESv2 and arm*:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=850021
^-- RM: openmw [armhf] -- RoQA; needs OSG built against libGL

The editor of OpenMW uses osgQt, which is provided by OSG. OSG has to pick,
Desktop GL or GLESv2 it can't be both and because GLESv2 was forced on
armhf and armel for Qt, then OSG had to do the same because of one of their
plugins (now deprecated in OSG-3.6) links against Qt. The result is that
OpenMW can't be built/shipped on armhf/armel on Debian because it only
supports OpenGL 2.0 fixed function pipeline.

If you say that arm64 has to be GLESv2 as well, then that is yet another
arch that OpenMW can't be built for.  Before the GLESv2 switch, OpenMW
worked just fine on arm* hardware, including the Raspberry Pi/Raspbian with
the VC4 mesa driver that has OpenGL 2.0 support.

Another related bug:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=852423
^--  revert all arm* changes to OSG and drop osgQt support in order to
compile against libGL (Desktop GL). A radical solution, but it would allow
for applications like OpenMW to run (but not the editor).

My merge-request on Salsa was already merged in for OSG-3.6 that does this,
since osgQt is no longer shipped with OSG, we no longer needed Qt nor the
GLESv1/2 support.
https://salsa.debian.org/openscenegraph-team/openscenegraph-3.6/merge_requests/1


I beg you, please either reverse the GLES decision in Qt or provide two
separate packages for GL or GLES support.

Cheers,
Bret
-BEGIN PGP SIGNATURE-
Version: FlowCrypt 6.3.2 Gmail Encryption
Comment: Seamlessly send and receive encrypted email

wsFcBAEBCAAQBQJb+AtICRDCN3t9WEy5MAAAaK8QAIKCkxpHlsI2uVB+K9HE
g1RFUShdMJWUtjgIZ6ngNshB1vqzbzQd6zOAxkJGo8ydO5yFYiIOtlc9pODx
rUZOLob9M+XLkB5ISrYuNtOF22CpRreKhvFV8dDxiUkRLd6AI6G39KubpB/w
WVYNFldg5u0CweGabUIBxKvkdS9NKSMMPbtSDsZP/jpNrRIxqX8rU3WfZfPu
x7LPJGG7lNRzAAIAcZTphhbW+mlFfaxVXw5Qt0WLuhDDr8WLoM65SNHL5Zox
mHTxVfoGDQoQv0OnL1ytqBpSLEksq7lZC3D+5XpjvxM8rPAVCk0Sa6FZ6mUy
g6ktvP0BmWb/M+CfyzPYocfyD5VJMAXtVhc2KqC0AmlWgggGph8YxWkHK3yW
dYxf9P65FBPtx4y5oX5OqVbvRPaLcOk9q8AgciAPZi1RgWqfou02wKCQqICk
N2Un/8RUhJUfHBHxTusbLLqLLFtIw6VVwqoIed3jIFCjUP0QJCh/Nwk4UpxK
714mxFVuJoaYFHQvLJOak8WbsDU6eGfs04sHM5AAfwJdO9pDRcKTMCP/Q4SC
9Nvc/dYQpoXn+AAFvEHqPZKHYkngwQD2vijrwduD6Iu2eehVMnM4ck5FDDwg
+QNiZCukrkg2iayn/xrwguEtPmI8acK2ttCEElij38kOzIVsPyO6n3Je55Ax
ZRKC
=7v54
-END PGP SIGNATURE-

Re: usrmerge -- plan B?

[Hans]

Am Freitag, 23. November 2018, 14:47:28 CET schrieb Stephan Seitz:
> On Fr, Nov 23, 2018 at 02:04:05 +0100, Matthias Klumpp wrote:

> And how do you revert this change? As far as I have understand you can’t
> remove the usrmerge package and have your system in the old state again.

Making an image of the whole hard drive is always a good idea.

> As others in the thread have mentioned they don’t see the risk with new
> installations but with old systems with different admins and third-party
> software.
> 

Changes are always coming with a risk. However, ones who fear, should try on a 
canary. This is, what I would do. Ok, this might be a little more work, but it 
is is worth. 

> Right, and it means he has enough to do and doesn’t want to debug the
> usrmerge. I don’t want to have a usrmerge at a dist-upgrade. You don’t
> really know the sequence of the package updates. I think the risk is too
> big to have a partial upgraded system.
> 

So, that is, where "testing" is standing for. Testing before release
 
> If the update of 2% of our systems won’t work because of failing usrmerge
> I would be asked if Debian is the right distribution.

Good point. However, this should be told to Microsoft admins or their 
deciders.

> 
> Shade and sweet water!
> 
>   Stephan

I think, we have now 2-3 moths for testing until freeze begins. Shouldn't this 
time not beeing well used, to eliminate all issues?

Best 

Hans

Re: usrmerge -- plan B?

[Stephan Seitz]

On Fr, Nov 23, 2018 at 02:04:05 +0100, Matthias Klumpp wrote:

If there are actual issues encountered, we can always revert a change


And how do you revert this change? As far as I have understand you can’t 
remove the usrmerge package and have your system in the old state again.


As others in the thread have mentioned they don’t see the risk with new 
installations but with old systems with different admins and third-party 
software.



anyway. During distribution upgrades there is a lot that can be wrong
and a lot of stuff the administrator needs to care about (config file


Right, and it means he has enough to do and doesn’t want to debug the 
usrmerge. I don’t want to have a usrmerge at a dist-upgrade. You don’t 
really know the sequence of the package updates. I think the risk is too 
big to have a partial upgraded system.



with information to the system administrator on what to do in case of
an error, and works for 98% of all users anyway, I see no reason not


If the update of 2% of our systems won’t work because of failing usrmerge 
I would be asked if Debian is the right distribution.


Shade and sweet water!

Stephan

--
| Public Keys: http://fsing.rootsland.net/~stse/keys.html |


smime.p7s
Description: S/MIME cryptographic signature

Re: usrmerge -- plan B?

[Matthias Klumpp]

Am Fr., 23. Nov. 2018 um 13:45 Uhr schrieb Ian Jackson
:
> Russ Allbery writes ("Re: usrmerge -- plan B?"):
> > This is a much better summary of the thread, and I wish that you would
> > have said this instead of claiming incorrectly that those same people are
> > the ones advocating for a full merge of all systems.
>
> Marco d'Itri writes ("Re: usrmerge -- plan B?"):
> > If you are seriously concerned with the small issuses caused by the
> > transition to merged-/usr then I have a better proposal.
> > Plan C: just stop supporting non-merged-/usr systems since these
> > problems are caused by having to support both, and there is no real
> > benefit in doing that other than pleasing the few people who are scared
> > by changes.

For this I actually wonder: Why don't we just do that and enforce the
usrmerge on unstable?
I think we are caring too much about the stability of the unstable
suite, and absolutely miss the chance of just running experiments to
gather data on the feasibility of changes.
What we could do in this case is for example to just make the usrmerge
migration mandatory for users of the unstable suite and see what kind
of issues and how many of them users will actually encounter. The
suite is called unstable afterall :-)
If there are actual issues encountered, we can always revert a change
and not have it go into stable, but in any case we will get a lot
better testing on the migration and a lot more data on whether there
actually are any issues.

Since new installations will be usrmerged by default anyway and there
is no reason or easy way to swich back to a split-usr system, I think
the issues related to a split-usr-system will go away in the long run
anyway. During distribution upgrades there is a lot that can be wrong
and a lot of stuff the administrator needs to care about (config file
changes, different featuresets of tools, software being removed from
the archive, ...), so if the usrmerge package has a sensible fallback
with information to the system administrator on what to do in case of
an error, and works for 98% of all users anyway, I see no reason not
to try using it and save us from an eternal transition period or pain
of maintaining two configurations.

Cheers,
Matthias

-- 
I welcome VSRE emails. See http://vsre.info/

Re: usrmerge -- plan B?

[Ansgar Burchardt]

On Fri, 2018-11-23 at 12:45 +, Ian Jackson wrote:
> Russ Allbery writes ("Re: usrmerge -- plan B?"):
> > This is a much better summary of the thread, and I wish that you would
> > have said this instead of claiming incorrectly that those same people are
> > the ones advocating for a full merge of all systems.
> 
> Marco d'Itri writes ("Re: usrmerge -- plan B?"):
> > If you are seriously concerned with the small issuses caused by the 
> > transition to merged-/usr then I have a better proposal.
> > Plan C: just stop supporting non-merged-/usr systems since these 
> > problems are caused by having to support both, and there is no real 
> > benefit in doing that other than pleasing the few people who are scared 
> > by changes.

What is this quote supposed to tell us?

Ansgar

Re: individual packages moving binaries from /bin to /usr/bin (was: Re: usrmerge -- plan B?)

[Ian Jackson]

Simon McVittie writes ("Re: individual packages moving binaries from /bin to 
/usr/bin (was: Re: usrmerge -- plan B?)"):
> I'm not sure yet what the best plan for merged /usr is. I would definitely
> like to make sure it's at least possible to continue to use merged
> /usr for special-purpose systems (particularly containers and embedded
> systems), even if it comes with major caveats like "can't reliably build
> Debian packages suitable for other systems";

To be very clear: I have no problem with this at all.

> I personally think everyone
> should be using sbuild or equivalent, either on a buildd or locally,
> to build "release-quality" packages suitable for distribution to other
> systems *anyway*, but I know that view isn't necessarily universal.

"Suitable for distribution to other systems" is rather a moveable
feast.  I absolutely agree if you mean formal publication as part of
some kind of release.

But I'm sure all of us have on occasion done ad-hoc builds and then
copied the .deb somewhere else to install it.  Indeed my own
experience is that during development I rarely use a chroot.  I think
someone should be able to build some software on their own computer
and give the binaries to a friend, without having to set up a chroot.

I also think that setting up a chroot should be made easier and that
more people should use chroots.  I don't think these views conflict.

> For at least special-purpose systems, merged /usr seems to work fine with
> stretch, and I was able to get it working in an Ubuntu 12.04 derivative
> by backporting a single-digit number of changes, so that particular genie
> has been out of the bottle for quite some time anyway.

Would it be helpful to make some of this explicit in Debian policy ?

IMO binary packages shipped by Debian should certainly support
installation on both merged-usr and separate-usr systems.

And I wouldn't object to a rule that our source packages must build
`correctly' on both such systems, subject to the caveat that the
results from a merged-usr build are not of general applicability and
should be used only in a closed environment where all the target
systems are also merged-usr.

Does that make sense ?

Ian.

-- 
Ian JacksonThese opinions are my own.

If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.

Bug#914437: ITP: gnome-shell-extension-desktop-icons -- desktop icon support for GNOME shell

[Iain Lane]

Package: wnpp
Severity: wishlist
Owner: Iain Lane 

* Package name: gnome-shell-extension-desktop-icons
  Version : 18.11~rc1
  Upstream Author : Carlos Soriano , Sergio Costas 

* URL : https://gitlab.gnome.org/World/ShellExtensions/desktop-icons
* License : GPL-3+
  Programming Lang: Javascript
  Description : desktop icon support for GNOME shell

This package provides a GNOME Shell extension for showing the contents
of ~/Desktop on the desktop of the Shell. Common file management
operations such as launching, copy/paste, rename and deleting are
supported.

This is replacing functionality that was in Nautilus prior to 3.28. It
uses D-Bus APIs provided by Nautilus to implement some of the features
mentioned above.

The GNOME team will maintain this package. I'll initially upload to
experimental, probably at least until there is a stable release as
opposed to a release candidate.

Re: usrmerge -- plan B?

[Ian Jackson]

Russ Allbery writes ("Re: usrmerge -- plan B?"):
> This is a much better summary of the thread, and I wish that you would
> have said this instead of claiming incorrectly that those same people are
> the ones advocating for a full merge of all systems.

Marco d'Itri writes ("Re: usrmerge -- plan B?"):
> If you are seriously concerned with the small issuses caused by the 
> transition to merged-/usr then I have a better proposal.
> Plan C: just stop supporting non-merged-/usr systems since these 
> problems are caused by having to support both, and there is no real 
> benefit in doing that other than pleasing the few people who are scared 
> by changes.

Ian.

Re: Upcoming Qt switch to OpenGL ES on arm64

[Dmitry Shachnev]

On Fri, Nov 23, 2018 at 01:08:03PM +0100, Marcin Juszkiewicz wrote:
> W dniu 23.11.2018 o 13:00, Dmitry Shachnev pisze:
> > I would still like to know if the upcoming arm64 desktop devices have
> > any problems working with OpenGL ES.
>
> Arm64 desktop systems use Radeon or NVidia cards with same opensource
> drivers as x86-64 systems. So you can check how it goes with OpenGL ES
> on your amd64 desktop.

I have an embedded Intel card right now :)

What is the status of OpenGL ES support with these drivers?

--
Dmitry Shachnev


signature.asc
Description: PGP signature

Re: Upcoming Qt switch to OpenGL ES on arm64

[Dmitry Shachnev]

On Fri, Nov 23, 2018 at 12:25:51PM +0100, Julien Cristau wrote:
> > According to config_help.txt [1], Qt uses ES2 by default on Windows.
> > It probably means that it will work fine with most desktop video cards.
> >
> > 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 this point.
>
> Why is it OK to break them on arm64 if it's not OK to break them on
> amd64?  Do you have a list of those packages?

The majority of arm64 devices are mobile/embedded, which cannot be said
about amd64.

Of course it is bad to break packages, but leaving arm64 users with
non-working Qt graphics is also not ideal. So we are trying to find a
compromise solution here.

We do not have a final list yet, but packages that may get broken will
likely belong to one of these two groups:

- Packages that build-depend on both qtbase5-dev and libglu1-mesa-dev:

  cgal, flightgear, fraqtive, kalgebra, kstars, ksudoku, kubrick, paraview,
  simplescreenrecorder, starpu, starpu-contrib, structure-synth, vtk6, vtk7

- Packages that build-depend on libqt5opengl5-desktop-dev:

  bino, deepin-movie-reborn, enki-aseba, fracplanet, fraqtive, freecad,
  krita, libconfig-model-dpkg-perl, mldemos, mm3d, openms, qwtplot3d,
  shelxle, soundscaperenderer, tetzle, virtualjaguar, vite, vtk7

This is not a final list yet, but should be enough to get an estimate.

--
Dmitry Shachnev


signature.asc
Description: PGP signature

Re: Upcoming Qt switch to OpenGL ES on arm64

[Marcin Juszkiewicz]

W dniu 23.11.2018 o 13:00, Dmitry Shachnev pisze:
> I would still like to know if the upcoming arm64 desktop devices have
> any problems working with OpenGL ES.

Arm64 desktop systems use Radeon or NVidia cards with same opensource
drivers as x86-64 systems. So you can check how it goes with OpenGL ES
on your amd64 desktop.

Re: Upcoming Qt switch to OpenGL ES on arm64

[Dmitry Shachnev]

On Fri, Nov 23, 2018 at 09:34:44AM +, Andy Simpkins wrote:
> I do understand that there would be a lot of effort required to support OGL
> and OGLES but as you have already pointed out "you are doing this already"
> because OGL is provided for all platforms except armel & armhf which have
> OGLES - that means you are already tracking changes for *BOTH* ecosystems.
>
> Having OGL & OGLES available on the same architecture would be setup
> involved in creating two package streams, but once done the actual build
> process is automated. Yes there are now twice as many resulting sets of
> binaries for this layer, but it is reasonable to assume that functional
> test of each strand can be split across the testing for all architectures
> (where not automated), so the increased workload again shouldn't differ by
> much (just the supporting of the automation).
>
> I am sure my view is nieve and a little too simplistic...

Please keep in mind that not only we (the Qt maintainers) should maintain two
sets of packages, but also maintainers of third party Qt libraries and
applications.

Even in Ubuntu where the core developers can upload any package, this setup
did not work fine (they tried to maintain twin -gles packages for x86 for the
Ubuntu touch port to these architectures).

> As of today there are considerably more 'mobile' arm devices.  I suspect
> that this will continue because they are lower cost mass market products.
> Full 'desktop' on arm64 has felt very close for the last few years, but
> hardware isn't there just yet.
> There are some quite big server SoCs out there, but the desktop & laptop
> world isn't well serviced.
>
> [...]
>
> If you want to look at sheer numbers then OGLES will 'win' hands down, but
> my gut tells me that long term excluding OGL from the arm64 architecture
> would be the wrong decision

Thanks, this information is useful!

I would still like to know if the upcoming arm64 desktop devices have any
problems working with OpenGL ES.

Anyway, the decision we are making now is not permanent, we can always
revisit it in a few years like we are now revisiting the decision to stick
with desktop OpenGL.

--
Dmitry Shachnev


signature.asc
Description: PGP signature

citadel packages

[Michael Meskes]

Hi all,

is anyone still interested in the citadel packages? I stopped using them ages
ago and finally ran out of time maintaining them. If anyone has interest and is
willing to put a bit of time into them, be my guest. They are in a decent
shape, but a new upstream version needs to get uploaded. If not I'm going to
orphan them or even ask for their removal from the archive. 

Michael
-- 
Michael Meskes
Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org)
Meskes at (Debian|Postgresql) dot Org
Jabber: michael at xmpp dot meskes dot org
VfL Borussia! Força Barça! Go SF 49ers! Use Debian GNU/Linux, PostgreSQL

Re: Upcoming Qt switch to OpenGL ES on arm64

[Dmitry Shachnev]

On Thu, Nov 22, 2018 at 06:01:14PM -0500, Gene Heskett wrote:
> I think a better question would be: Does it improve, or disable, decent
> video support for the dozens of arm64 cards in the r-pi format, such as
> the arm64 based $44 rock64? [...]

As far as I know Raspberry Pi 3 and similar devices work fine with OpenGL ES.

E.g. Raspbian does not override our choice to build qtbase with OpenGL ES
on armhf.

--
Dmitry Shachnev


signature.asc
Description: PGP signature

Re: Upcoming Qt switch to OpenGL ES on arm64

[Julien Cristau]

On 11/23/18 12:18 PM, Dmitry Shachnev wrote:
> On Thu, Nov 22, 2018 at 11:05:27PM +0100, Julien Cristau wrote:
>> At least mesa drivers can be used for desktop GL or GLESv2 just fine,
>> AFAIK.  Maybe the answer for Qt is to switch to GLESv2 for all
>> architectures, to stop the special-casing madness, instead of making it
>> spread? :)
> 
> According to config_help.txt [1], Qt uses ES2 by default on Windows.
> It probably means that it will work fine with most desktop video cards.
> 
> 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 this point.
> 
Why is it OK to break them on arm64 if it's not OK to break them on
amd64?  Do you have a list of those packages?

Cheers,
Julien

Re: Upcoming Qt switch to OpenGL ES on arm64

[Dmitry Shachnev]

On Thu, Nov 22, 2018 at 11:05:27PM +0100, Julien Cristau wrote:
> At least mesa drivers can be used for desktop GL or GLESv2 just fine,
> AFAIK.  Maybe the answer for Qt is to switch to GLESv2 for all
> architectures, to stop the special-casing madness, instead of making it
> spread? :)

According to config_help.txt [1], Qt uses ES2 by default on Windows.
It probably means that it will work fine with most desktop video cards.

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 this point.

[1]: https://code.qt.io/cgit/qt/qtbase.git/tree/config_help.txt#n271

--
Dmitry Shachnev


signature.asc
Description: PGP signature

Re: Upcoming Qt switch to OpenGL ES on arm64

[W. Martin Borgert]

Quoting John Paul Adrian Glaubitz :
Granted, I don’t really know what the real world distribution of  
embedded and desktop/server/laptop devices of arm64 is.  But I could  
imagine that there will be more arm64 devices in the future which  
are desktops, servers or laptops.


There is e.g. this project from Berlin:

https://mntmn.com/reform/

It says:

 * Vivante GC3000 GPU
   Fully open source drivers in the Linux kernel (etnaviv)
   and OpenGL (mesa)

I will buy one as soon as available.

There is also Novena:

https://www.crowdsupply.com/sutajio-kosagi/novena

No idea what they use for graphics.

Cheers

Re: individual packages moving binaries from /bin to /usr/bin (was: Re: usrmerge -- plan B?)

[W. Martin Borgert]

Quoting Holger Levsen :

On Thu, Nov 22, 2018 at 10:11:24PM +0100, W. Martin Borgert wrote:

Reminds me of the long /usr/doc -> /usr/share/doc transition in potato
times. And we did not even have dh in those days. Sounds good to me!


ITYM s#potato#slink, potato, woody, sarge, etch and lenny#

(Started in 1999 and finally fully finished on Sep 25th 2008 with
closing #322762.)

So I don't think this transition is such a positive example :-D


Why not positive? Yes, it took some time, but it worked out
without breakage. As we say: Gut Ding will Weile haben! :—)
(for non-Germans: "it takes time to do a thing well")

Re: Upcoming Qt switch to OpenGL ES on arm64

[Steve McIntyre]

On Fri, Nov 23, 2018 at 03:27:57AM +0300, Dmitry Eremin-Solenikov wrote:
>Hello,
>пт, 23 нояб. 2018 г. в 03:18, Lisandro Damián Nicanor Pérez Meyer
>:
>>
>> Hi! Please let me reply first to your last part:
>>
>> > Is there any possible way to support *BOTH* OpenGL / OpenGLES?  Mutually
>> > exclusive from an install POV, but give the end user the choice which to
>> > install?  Why should we have one Architecture forced down a path
>> > different to another architecture?
>>
>> No, I'm afraid there is no way to do that. We did consider it many times, but
>> is definitely too much work to hack on.
>>
>> So we need to force an architecture (actually, all of them!) to either one or
>> the other.
>
>Can you build two packages and allow user to select, which one he wants to
>install? Or those packages will be binary incompatible?

That's a good question, yes. It'w ahst I was wondering too.

...

>> So far I personally know 0 people with an arm64 board with PCI slots, while I
>> know many with arm64 boards with hardware GLES support.
>
>I'm working with big arm64 iron, so for me a server arm64 board with PCIe slots
>(and thus PCIe graphic cards) and on-board Aspeed "VGA card" is more common
>compared to GLES-enabled arm64 SoC.

Yeah - it depends exactly on your background. There's a small (but
growing) set of arm64 desktop users, and it would be unfortunate to
cut them off.

-- 
Steve McIntyre, Cambridge, UK.st...@einval.com
"... the premise [is] that privacy is about hiding a wrong. It's not.
 Privacy is an inherent human right, and a requirement for maintaining
 the human condition with dignity and respect."
  -- Bruce Schneier

Re: Upcoming Qt switch to OpenGL ES on arm64

[Andy Simpkins]

On 23/11/2018 00:17, Lisandro Damián Nicanor Pérez Meyer wrote:

Hi! Please let me reply first to your last part:


Is there any possible way to support *BOTH* OpenGL / OpenGLES?  Mutually
exclusive from an install POV, but give the end user the choice which to
install?  Why should we have one Architecture forced down a path
different to another architecture?

No, I'm afraid there is no way to do that. We did consider it many times, but
is definitely too much work to hack on
So this is a large parcel of work that the team doesn't want to do, but 
it is possible.


I do understand that there would be a lot of effort required to support 
OGL and OGLES but
as you have already pointed out "you are doing this already" because OGL 
is provided for
all platforms except armel & armhf which have OGLES - that means you are 
already tracking

changes for *BOTH* ecosystems.

Having OGL & OGLES available on the same architecture would be setup 
involved in creating

two package streams, but once done the actual build process is automated.
Yes there are now twice as many resulting sets of binaries for this 
layer, but it is
reasonable to assume that functional test of each strand can be split 
across the testing
for all architectures (where not automated), so the increased workload 
again shouldn't

differ by much (just the supporting of the automation).

I am sure my view is nieve and a little too simplistic...



So we need to force an architecture (actually, all of them!) to either one or
the other.


El jueves, 22 de noviembre de 2018 20:04:33 -03 Andy Simpkins escribió:

On 22/11/18 22:33, Lisandro Damián Nicanor Pérez Meyer wrote:

El jueves, 22 de noviembre de 2018 15:37:29 -03 Dmitry Shachnev escribió:

Hi all!

The Qt framework can be built either with “desktop” OpenGL, or with
OpenGL
ES support. At the moment we are building it with OpenGL ES on armel and
armhf, and with desktop OpenGL on all other architectures

Maybe we missed to properly explain the main point of this change:
currently most arm64 boards are using software rasterization because
their video cards do not support Desktop OpenGL.

I am not sure that is correct.  I certainly don't agree...

There is no special case here.  If you have a video card in your ARM64
PC then it is likely the same video card that you have for an AMD64 PC -
i.e. it is an off the shelf PCIe card.

Now it is correct that there is a large number of ARM64 based SoC
solutions out there with an embedded GPU - these are aimed mainly at the
mobile market (but as the computational power in these SoCs increases we
are already seeing that is enough for a lot of peoples 'PC' needs)

I guess what I am trying to say here is the GPU architecture is NOT tied
to the CPU architecture.

- GPU architecture is not tied to the arch: right.
- Qt is tied to either Desktop or GLES: yes

So we need to pick one. The question is then which one will benefit our users
most.

So far I personally know 0 people with an arm64 board with PCI slots, while I
know many with arm64 boards with hardware GLES support.
I have quite a lot of ARM boards (for the record I am neither an ARM or 
Lenaro

employee, but I do design hardware using ARM cores).

I have 2 arm64 motherboards - both have PCIe slots and no GPU built into 
the SoC
these are Both MiniITX form factor boards and are drop-in replacements 
for amd64 based

systems.  They both have multiple SATA interfaces, DIMM slots etc etc.

I have several armhf boards - these all have OpenGLES supporting GPUs on 
the SoC.
Only one of them has a (single) SATA interface, none of them have DIMM 
slots (instead
having between 512MB and 2GB LPDDR soldered to the board)  None of these 
are desktop
PC replacements - they are embedded systems (think tablet / mobile / 
dedicated task

systems).

As of today there are considerably more 'mobile' arm devices.  I suspect 
that this
will continue because they are lower cost mass market products. Full 
'desktop' on
arm64 has felt very close for the last few years, but hardware isn't 
there just yet.
There are some quite big server SoCs out there, but the desktop & laptop 
world isn't

well serviced.



If we switch to GLES then most amr64 boards


will be able to render using their video hardware, thus greatly improving
speed to the point of being actually usable for some stuff.

I imagine (but would *love* hard data) that any PCI video card added to an
arm64 machine will probably also support GLES, so they will still have
use.

So 
any PCI video card added to s/amr64/AMD64 machine will probably also
support GLES, so they will still have use.
OK that is true - lets enact this across ALL architectures, but I
suspect that there may be a bit of pushback from the AMD64 heavy graphic
users...


No need to use sarcasm. Yes, it's a matter of choice. No one noted yet that
all archs except armel and armhf have Desktop support and not GLES. And this
is because, so far and to the best of our knowledge, that has been the right
thing to do