Re: Upcoming Qt switch to OpenGL ES on arm64

[Andy Simpkins]

On 24/11/2018 02:05, 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ó:

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).

Understood


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.

Ack


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.

Yes that sounds right


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.
The time taken for an automated process to run (or fail) should not be a 
justification not to do something.
We need to be able to build the entire archive, not just Qt, and this is 
an automated process.


As an aside: The current arm64 buildd's are plenty fast enough to build 
the entire archive in a few days (IIRC sledge has done this several 
times recently), I also believe that the buildds (and porter boxes?) are 
being (have been?) replaced with newer and faster boxes (also easier for 
DSA to maintain).
I believe that they are also able to build / will build native armhf 
(and armel).  It is my understanding bug reports & fixes are in progress




And a single mistake could be disastrous.
Not relevant - a single mistake in any package is called a bug. As a 
distribution we have many of these; we strive not to introduce new ones 
and fix those that we can...

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.
Absolutely - everything in the subsystem would need to be duplicated 
up-to the point of common API

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.


No. The libraries do not need to have any knowledge about the other 
subsystem / collection of sub modules. i.e. 'desktop' does not need to 
be aware of 'mobile' and vis versa.




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.


Right so this is the crux of the matter.

I am putting words in your mouth here - please accept my apologies I am 
trying to describe how I have perceived your comments, this is clearly 
not the words you have used but that is how I am parsing them.  I have 
tried several times to re-word tjis better, it still feels 
confrontational but 

Re: Upcoming Qt switch to OpenGL ES on arm64

[Simon McVittie]

On Fri, 23 Nov 2018 at 23:12:19 -0300, Lisandro Damián Nicanor Pérez Meyer 
wrote:
> El viernes, 23 de noviembre de 2018 09:23:29 -03 Dmitry Shachnev escribió:
> > 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.

Try it? The mesa-utils-extra package contains es2gears_x11 and
es2gears_wayland, which appear to be GLES equivalents of glxgears,
and work fine in a GNOME/Wayland environent on my (admittedly much more
recent) Intel integrated GPU.

(Of course, you can't expect es2gears_wayland to work in a pure X11
environment, unless you install and run weston, which has an X11 backend
that can be used to provide a Wayland display nested in an X11 window,
like a Wayland equivalent of Xephyr or Xnest.)

smcv

Re: Upcoming Qt switch to OpenGL ES on arm64

[Matthias Klose]

On 24.11.18 11:26, Andy Simpkins wrote:
>> So, again: which of the two flavors is the one that benefits more of our user
>> base?
> 
> BOTH are possible so why dictate only one?
> 
> I would like to see OpenGLES available on all architectures
> 
> I would like to see OpenGL available on all architectures
> 
> I think that there is a relatively painless method to achieve this
> 
> I believe this would also meet your needs

so why not keep GL as it is now, and build the GLES packages from a single
source tarball?  This way you minimize your uploads while having both
implementations in the archive?  Maybe later on, you could even do the same for
the 32bit ARM architectures if these are still release architectures by that 
time.

Matthias

Re: Upcoming Qt switch to OpenGL ES on arm64

[Adam Borowski]

On Sat, Nov 24, 2018 at 01:09:35PM +, Simon McVittie wrote:
> On Fri, 23 Nov 2018 at 23:12:19 -0300, Lisandro Damián Nicanor Pérez Meyer 
> wrote:
> > El viernes, 23 de noviembre de 2018 09:23:29 -03 Dmitry Shachnev escribió:
> > > 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.
> 
> Try it? The mesa-utils-extra package contains es2gears_x11 and
> es2gears_wayland, which appear to be GLES equivalents of glxgears,
> and work fine in a GNOME/Wayland environent on my (admittedly much more
> recent) Intel integrated GPU.

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 dropped from
the official drivers while 2 years old doesn't get Linux support yet -- and
nouveau has problems on its own.

I don't have access to any non-embedded Intel cards so I can't test one in
an arm64 box with a PCIe slot. ;)  But despite apparent insanity of such an
idea, it might be actually the sanest option.

Not a clue about AMD stuff.


Meow!
-- 
Autotools hint: to do a zx-spectrum build on a pdp11 host, type:
  ./configure --host=zx-spectrum --build=pdp11

Re: Upcoming Qt switch to OpenGL ES on arm64

[bret curtis]

> > 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.
>
>  "I have a Raspberry Pi (or similar mobile class system that
> has migrated / is migrating away from armel to arm64) and this has
> forced a move from 'mobile' OpenGLES to 'Desktop' OpenGL.  The result of
> which is that because that platform (and those like it) do not have
> hardware acceleration for OpenGL but DO for OpenGLES you think we should
> change the whole architecture for your use case." 
>

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 accelerated X11 or Wayland, you need
the VC4 driver. You'll need "Desktop" OpenGL otherwise nothing will
work on a RPi system, which as of 2015 has over 5 million units
shipped. This is not an insignificant user base.

IMHO, the decision to switch away from 'Desktop' OpenGL to GLES was
the wrong decision and should be reversed until a solution is found to
support both.

Cheers,
Bret

Re: Upcoming Qt switch to OpenGL ES on arm64

[bret curtis]

Hello Lisandro!

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

Sorry, but this is just not acceptable. There has to be another way.

>
> > 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?

There is a misunderstanding here and also in this thread. The Raspberry Pi has
the VC4 GPU which is hardware accelerated Desktop OpenGL 2.1 via the VC4 Mesa
driver.[1] This driver is fully open-source unlike the binary blob it comes with
that only supports GLESv2, but not via X11 nor Wayland.

So the only way to support Qt with hardware (not software) accelerated GL on
the RPi is with the VC4 mesa driver and Desktop GL.

As for OpenMW running on a RPi, it is fully hardware (GPU) accelerated via the
VC4 driver. It runs pretty darn well. You can walk around Morrowind (with mods)
right now at 25fps @ 1080p using a GPU-based VC4[1] OpenGL 2.0 renderer.
60fps in interiors. This is on a Raspberry Pi 2, likely better with the
RPi3 with VC4 being EoL, the next iteration of the RPi will likely be VC5/6
that is arm64.

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

There are more than 5 million Raspberry Pis were sold as of February 2015. All
of them with a VC4 GPU, Raspbian ships with the VC4 mesa driver enabled!

I'm of the opinion that the switch away from Desktop OpenGL to GLES was a huge
mistake and should be reversed as soon as possible unless there is a way to
provide for both on all archtictures.

Cheers,
Bret

[1] https://github.com/anholt/mesa/wiki/VC4

Review of dwarves 1.12-1 (and sponsoring)

[Domenico Andreoli]

Hi all,

  after some ~7 years of inactivty I've been able to put a new upstream
release of dwarves together. It's at https://salsa.d.o/debian/dwarves.

It has some build reproducibility issue, I'll look at that later. I'll
also go throught the open bugs, they are quite aged and deserve to be
closed asap.

Aside from these issues, it's my first work in the age of >=2048 bits
key, Salsa and gbp. I'm sure some expert eye can find something worth
improving, please give it a glance.

In the meanwhile that I resurrect my old 1024 bits key, sign the new one
and also get some signatures I might have somewhere, I need a sponsor
to upload this package. Any volunteer?

Thanks for all the help.

Kind regards,
Domenico

-- 
3B10 0CA1 8674 ACBA B4FE  FCD2 CE5B CF17 9960 DE13

Bug#914527: dwarves: update package description

[Holger Levsen]

package: dwarves
severity: minor
x-debbugs-cc: Domenico Andreoli , 
debian-devel@lists.debian.org

On Sat, Nov 24, 2018 at 03:28:37PM +0100, Domenico Andreoli wrote:
>   after some ~7 years of inactivty I've been able to put a new upstream
> release of dwarves together. It's at https://salsa.d.o/debian/dwarves.

this made me read the package description which reads/starts:

Description-en: set of advanced DWARF utilities
 This package contains tools that use the DWARF debugging information
 inserted in ELF binaries by the compiler. This information is already
 used by debuggers (e.g. GDB), and more recent tools such as systemtap.

I'd suggest you update this to

Description-en: set of advanced DWARF utilities
 This package contains tools that use the DWARF debugging information
 inserted in ELF binaries by the compiler. This information is used by
 debuggers (e.g. GDB), and other tools such as systemtap.

or some such.

> In the meanwhile that I resurrect my old 1024 bits key, sign the new one
> and also get some signatures I might have somewhere, I need a sponsor
> to upload this package. Any volunteer?

sorry, not me.


-- 
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: Upcoming Qt switch to OpenGL ES on arm64

[Lisandro Damián Nicanor Pérez Meyer]

Hi Andy!

El sábado, 24 de noviembre de 2018 07:26:34 -03 Andy Simpkins escribió:
> On 24/11/2018 02:05, 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ó:
> >> 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).
> 
> Understood
> 
> > 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.
> 
> Ack
> 
> > 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.
> 
> Yes that sounds right
> 
> > 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.
> 
> The time taken for an automated process to run (or fail) should not be a
> justification not to do something.
> We need to be able to build the entire archive, not just Qt, and this is
> an automated process.

Except for the *manpower* needed behind it. We are currently 2 to 3 active 
developers for the whole Qt stack and we can't certainly add more work to our 
stack. We are really behind what we would really like to be doing, like 
enabling all the source's tests.

> As an aside: The current arm64 buildd's are plenty fast enough to build
> the entire archive in a few days (IIRC sledge has done this several
> times recently), I also believe that the buildds (and porter boxes?) are
> being (have been?) replaced with newer and faster boxes (also easier for
> DSA to maintain).
> I believe that they are also able to build / will build native armhf
> (and armel).  It is my understanding bug reports & fixes are in progress
> 
> > And a single mistake could be disastrous.
> 
> Not relevant - a single mistake in any package is called a bug. As a
> distribution we have many of these; we strive not to introduce new ones
> and fix those that we can...
>
> > 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.
> 
> Absolutely - everything in the subsystem would need to be duplicated
> up-to the point of common API
> 
> > 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.
> 
> No. The libraries do not need to have any knowledge about the other
> subsystem / collection of sub modules. i.e. 'desktop' does not need to
> be aware of 'mobile' and vis versa.

Except a whole lot of libraries would need double build. Ideallistically 
doable, but not with the current manpower behind it.

> > 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

Re: Upcoming Qt switch to OpenGL ES on arm64

[Andy Simpkins]

On 24/11/18 14:14, bret curtis wrote:
>>> 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.
>>
>>  "I have a Raspberry Pi (or similar mobile class system that
>> has migrated / is migrating away from armel to arm64) and this has
>> forced a move from 'mobile' OpenGLES to 'Desktop' OpenGL.  The result of
>> which is that because that platform (and those like it) do not have
>> hardware acceleration for OpenGL but DO for OpenGLES you think we should
>> change the whole architecture for your use case." 
>>
> 
> 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 accelerated X11 or Wayland, you need
> the VC4 driver. You'll need "Desktop" OpenGL otherwise nothing will
> work on a RPi system, which as of 2015 has over 5 million units
> shipped. This is not an insignificant user base.
> 
> IMHO, the decision to switch away from 'Desktop' OpenGL to GLES was
> the wrong decision and should be reversed until a solution is found to
> support both.
> 
> Cheers,
> Bret
> 

Apologies for using the RaspberryPi as my example of a 'mobile' class SoC.

IIRC the Pi was being used as the primary argument for switching away
from OpenGL to OpenGLES as this is selling in large volumes.  If the Pi
already supports OpenGL then the argument to move solely to OpenGLES is
reduced somewhat.

I will try OpenGL on a RPi this week (I normally run RPi headless so no
desktop installed).

/Andy

Re: Upcoming Qt switch to OpenGL ES on arm64

[Lisandro Damián Nicanor Pérez Meyer]

El sábado, 24 de noviembre de 2018 11:23:51 -03 bret curtis escribió:
> Hello Lisandro!
> 
> > Yes, that's a drawback we are not hiding. Applications needing Desktop
> > OpenGL would be left out. But...
> 
> Sorry, but this is just not acceptable. There has to be another way.
> 
> > > 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?
> 
> There is a misunderstanding here and also in this thread. The Raspberry Pi
> has the VC4 GPU which is hardware accelerated Desktop OpenGL 2.1 via the
> VC4 Mesa driver.[1] This driver is fully open-source unlike the binary blob
> it comes with that only supports GLESv2, but not via X11 nor Wayland.

Ok, that's totally new for me. And indeed it changes the way (at least I) see 
things.

> So the only way to support Qt with hardware (not software) accelerated GL on
> the RPi is with the VC4 mesa driver and Desktop GL.

Point taken.

> As for OpenMW running on a RPi, it is fully hardware (GPU) accelerated via
> the VC4 driver. It runs pretty darn well. You can walk around Morrowind
> (with mods) right now at 25fps @ 1080p using a GPU-based VC4[1] OpenGL 2.0
> renderer. 60fps in interiors. This is on a Raspberry Pi 2, likely better
> with the RPi3 with VC4 being EoL, the next iteration of the RPi will likely
> be VC5/6 that is arm64.
> 
> > > 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.
> 
> There are more than 5 million Raspberry Pis were sold as of February 2015.
> All of them with a VC4 GPU, Raspbian ships with the VC4 mesa driver
> enabled!
> 
> I'm of the opinion that the switch away from Desktop OpenGL to GLES was a
> huge mistake and should be reversed as soon as possible unless there is a
> way to provide for both on all archtictures.

Well, f you can prove this for armhf and/or armel, we can certainly do it.

-- 
7: Hay diferencia entre "cortar" un archivo y "borrarlo" o "eliminarlo"
* Depende cuando se "cuelgue" Windows
Damian Nadales
http://mx.grulic.org.ar/lurker/message/20080307.141449.a70fb2fc.es.html

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]

El sábado, 24 de noviembre de 2018 10:40:37 -03 Matthias Klose escribió:
> On 24.11.18 11:26, Andy Simpkins wrote:
> >> So, again: which of the two flavors is the one that benefits more of our
> >> user base?
> > 
> > BOTH are possible so why dictate only one?
> > 
> > I would like to see OpenGLES available on all architectures
> > 
> > I would like to see OpenGL available on all architectures
> > 
> > I think that there is a relatively painless method to achieve this
> > 
> > I believe this would also meet your needs
> 
> so why not keep GL as it is now, and build the GLES packages from a single
> source tarball?  This way you minimize your uploads while having both
> implementations in the archive?  Maybe later on, you could even do the same
> for the 32bit ARM architectures if these are still release architectures by
> that time.

Because that single source tarball would alone take more than a day to do a 
test build. At our current maintainer's build/man power, it's unfeasible.



-- 
"No es el crecimiento de la tecnología lo que excluye, sino la
protección sistemática de los derechos de uso de la misma,
lo cual se puede aplicar al arte."
  David Cuartielles

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

[Simon McVittie]

On Sat, 24 Nov 2018 at 15:10:47 +0100, Adam Borowski wrote:
> I don't have access to any non-embedded Intel cards

Do those exist? I thought Intel only made GPUs that are integrated into
their CPUs (the "HD Graphics" series). Presumably that's what you meant
when you said embedded?

As far as I understand it the usual PC terminology is that a GPU built
into your CPU (as seen in low-end or ultraportable laptops) is an
"integrated GPU", and a separate module like all(?) NVidia hardware or
most AMD hardware (in gaming/high-end laptops, or a PCIe card in desktops)
is a "discrete GPU". Some AMD CPUs have integrated AMD GPUs.

> Not a clue about AMD stuff.

Recent AMD GPUs use the "amdgpu" kernel driver and its accompanying Mesa
user-space driver, which is an open source stack if you don't count the
GPU firmware. It should be comparable to the situation on Intel integrated
GPUs (but a lot faster and more featureful, and probably with more bugs,
because the hardware is faster and more featureful). Expect to need a
recent (buster/sid) kernel, particularly for newer hardware.

Old ATI/AMD GPUs can use the radeon driver stack, which is also open
source (except for firmware) and comparable to Intel integrated GPUs
(generally faster and more featureful for hardware of equivalent age).

I think there might be some intermediate models that are too new for
radeon but too old for amdgpu; if they exist, those will be stuck with
the proprietary fglrx driver, which as far as I can tell is like the
NVidia proprietary driver, but worse. fglrx is no longer supported by
Debian contrib/non-free.

smcv

Re: NEW and RC bugs (Re: julia_1.0.0-1_amd64.changes REJECTED)

[Guido Günther]

Hi,
On Thu, Nov 22, 2018 at 12:52:48PM +, Ian Jackson wrote:
> Holger Levsen writes ("Re: julia_1.0.0-1_amd64.changes REJECTED"):
> > On Wed, Nov 21, 2018 at 03:19:33PM +, Ian Jackson wrote:
> > > Why is any of this a reason for an ftpmaster REJECT ?  I still think
> > > all of this should be handled as bugs (possibly RC bugs) in the BTS
> > > in the conventional way, after ACCEPT.
> > 
> > because why accept rc-buggy software in the archive (when we know it's
> > rc-buggy), whether at NEW time or with any following upload?
> 
> Because:
> 
>  * Discussions about the RC bugs can be more effectively dealt with
>using our existing discussion mechanisms, including primarily the
>Debian BTS.  Compared to REJECT mails:
>  - Discussions in the BTS are more transparent
>  - Discussions in the BTS are better organised
>  - Discussions in the BTS can have wider participation
>  - Discussions in the BTS are better archived
>  - Discussions in the BTS have better metadata
> 
>  * Publishing a work-in-progress in the Debian archive enables more
>people to more easily help improve and fix it.

The experimental distribution is a good place for work in
progress. Maybe the rules for automatic rejects can be relaxed for
experimental so a package can go into the archive (and have e.g. the BTS
used for that version) if the maintainer doesn't want to fix the reject
right away.

Cheers,
 -- Guido

> 
>  * Once a package is accepted metadata about it, and parts of it, are
>automatically published by a variety of Debian services, making it
>much easier to work with - for example, one can see who the
>maintainer is and what its issues are.
> 
>  * ftpmasters are already far too overloaded looking for problems like
>unredistributability, dfsg-nonfreeness, malformed packages,
>breakages of the archive, etc.
> 
>  * It is not ftpmasters' role to determine whether a package is
>RC-buggy; that task is for the Release Team.
> 
> > (in that sense I would appreciate packages getting automatically tested
> > (and rejected if needed) before they enter *unstable*, and then again,
> > with stricter automatic tests before they enter testing.)
> 
> I agree that automatic checking is fine, but humans should be able to
> override it.  I have no problem with auto-REJECTs, which are generally
> either for really serious problems, or can be overridden.
> 
> 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: NEW and RC bugs (Re: julia_1.0.0-1_amd64.changes REJECTED)

[Sean Whitton]

Hello,

On Sat 24 Nov 2018 at 04:29PM +0100, Guido Günther wrote:

> The experimental distribution is a good place for work in
> progress. Maybe the rules for automatic rejects can be relaxed for
> experimental so a package can go into the archive (and have e.g. the BTS
> used for that version) if the maintainer doesn't want to fix the reject
> right away.

Cool idea!

-- 
Sean Whitton


signature.asc
Description: PGP signature

Re: Upcoming Qt switch to OpenGL ES on arm64

[The Wanderer]

On 2018-11-24 at 10:21, Simon McVittie wrote:

> On Sat, 24 Nov 2018 at 15:10:47 +0100, Adam Borowski wrote:
> 
>> I don't have access to any non-embedded Intel cards
> 
> Do those exist? I thought Intel only made GPUs that are integrated
> into their CPUs (the "HD Graphics" series). Presumably that's what
> you meant when you said embedded?

I don't know of any which exist currently, but a naive Google search for
'discrete Intel GPU' turns up news articles from this past August
reporting that they've teased one coming out in ~2020.

-- 
   The Wanderer

The reasonable man adapts himself to the world; the unreasonable one
persists in trying to adapt the world to himself. Therefore all
progress depends on the unreasonable man. -- George Bernard Shaw



signature.asc
Description: OpenPGP digital signature

Re: Re: usrmerge -- plan B?

[Alexander E. Patrakov]

Marco d'Itri wrote:


On Nov 21, Michael Stone  wrote:


How many long-running production systems do you think people have run
usrmerge on? I'd guess close to zero, since there is no advantage whatsoever

Actually I have quite a lot personally, with exactly zero problems.
On some of them I also enjoy advantages of merged-/usr, like having 
multiple containers share the same /usr.


I agree with the argument in this thread that usrmerge should be either 
Essential or not in Buster at all. I have no Debian systems in 
production, but the company that I have a contract with has some Ubuntu 
systems, and we are considering (as in: there is a successful PoC) the 
use of OSTree for deployment of some production systems. OSTree folks 
recommend merged /usr, so I do install usrmerge in the LXC container 
that is being used as a "golden" tree for deployment. And it works quite 
well for us with just a few extra moves and symlinks, and extlinux as 
the boot loader (to work around removal of GRUB2-related files from the 
Debian package).


So: my opinion is that I would prefer usrmerge in Essential in Buster, 
for the benefit of people who use OSTree for deployment, and to reduce 
divergence between Debian and Ubuntu plans.


--
Alexander E. Patrakov

Re: Re: usrmerge -- plan B?

[Alexander E. Patrakov]

Russ Allbery wrote:


The reason why I personally jumped into this thread is that I don't think
the initial fix proposed for R was good engineering.  We should not be
doing that sort of fragile machinations in Autoconf configuration.  It
will end in tears.  We will miss some other binary later, or Autoconf will
change flags or how it probes, and we won't catch the breakage.


We could catch some of it automatically by creating /dontuse/bin and 
/dontuse/usr/bin as symlinks to /bin and /usr/bin on all buildds (and 
the sbin equivalents, too), adding that first to the PATH, and 
auto-rejecting any package that has these strings in it. I understand 
that there will be lots of FTBFS from doing that, so it may or may not 
be a good idea, especially because this covers only "we won't catch the 
breakage" point, but not "we should not be doing that".


--
Alexander E. Patrakov

Re: Upcoming Qt switch to OpenGL ES on arm64

[Rebecca N. Palmer]

Lisandro Damián Nicanor Pérez Meyer wrote:

El viernes, 23 de noviembre de 2018 09:23:29 -03 Dmitry Shachnev escribió:

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.
Wikipedia says Intel GPUs support OpenGL ES 2 since gen3 (~2004)[0] or 
gen4 (~2006)[1] (yes, this is inconsistent), and Nvidia GPUs since NV40 
(~2004)[1] (they don't specify whether this is with Nouveau or 
closed-source Nvidia).  They don't obviously say for ATI/AMD, but the 
Mesa source code says[3] that "all Gallium drivers" (which appear[4][5] 
to include Intel from i915 = ~2004, Nouveau from nv30 = ~2003 and 
ATI/AMD from r300 = ~2002) support GL_ARB_ES2_compatibility.


Simon McVittie wrote:

Try it? The mesa-utils-extra package contains es2gears_x11 and
es2gears_wayland, which appear to be GLES equivalents of glxgears,
and work fine in a GNOME/Wayland environent on my (admittedly much more
recent) Intel integrated GPU.


On my system (Intel gen7, stretch kwin-wayland), both correctly display 
their main animation.  es2gears_x11 has a window frame and responds to 
Esc, but es2gears_wayland doesn't: is that intended, a full-GL window 
manager not being able to add a frame to a GL ES window, or a bug 
somewhere else?


[0] 
https://en.wikipedia.org/wiki/List_of_Intel_graphics_processing_units ; 
this is based on the Mesa source code [2], though I don't actually know 
if GL_ARB_ES2_compatibility = "can create a full-GL context that 
includes the functionality of ES2 as extensions" implies 
GLX_EXT_create_context_es_profile = "can create a true ES2 context".

[1] https://en.wikipedia.org/wiki/OpenGL_ES
[2] 
https://sources.debian.org/src/mesa/18.2.5-3/src/mesa/drivers/dri/i915/intel_extensions.c/#L84
[3] 
https://sources.debian.org/src/mesa/18.2.5-3/src/mesa/state_tracker/st_extensions.c/#L875

[4] https://sources.debian.org/src/mesa/18.2.5-3/src/gallium/drivers/
[5] https://gallium.readthedocs.io/en/latest/distro.html

Re: usrmerge -- plan B?

[Alexander E. Patrakov]

On 11/24/18 8:51 PM, Alexander E. Patrakov wrote:

Marco d'Itri wrote:


On Nov 21, Michael Stone  wrote:


How many long-running production systems do you think people have run
usrmerge on? I'd guess close to zero, since there is no advantage 
whatsoever

Actually I have quite a lot personally, with exactly zero problems.
On some of them I also enjoy advantages of merged-/usr, like having 
multiple containers share the same /usr.


I agree with the argument in this thread that usrmerge should be either 
Essential or not in Buster at all. I have no Debian systems in 
production, but the company that I have a contract with has some Ubuntu 
systems, and we are considering (as in: there is a successful PoC) the 
use of OSTree for deployment of some production systems. OSTree folks 
recommend merged /usr, so I do install usrmerge in the LXC container 
that is being used as a "golden" tree for deployment. And it works quite 
well for us with just a few extra moves and symlinks, and extlinux as 
the boot loader (to work around removal of GRUB2-related files from the 
Debian package).


So: my opinion is that I would prefer usrmerge in Essential in Buster, 
for the benefit of people who use OSTree for deployment, and to reduce 
divergence between Debian and Ubuntu plans.


Based on reading the other messages in this thread, I changed my 
opinion. The new opinion is that any of the following outcomes is OK, 
with no specific preference:


1. mandatory usrmerge in Buster
2. usrmerge available from somewhere for installation in Buster, but not 
installed on buildds, and dpkg-buildpackage should refuse to build 
anything if /usr is merged and the user does not say "please".


--
Alexander E. Patrakov

Re: usrmerge -- plan B?

[Gabriel F. T. Gomes]

On 23 Nov 2018, Michael Stone wrote:

>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).

Has this option been given enough attention?  It sounds appealing in
two ways: 1. it would work as an incentive for people who want to
install usrmerge (be it because they are curious about the results or
because they wish to help), but are not in a mood to reinstall their
systems *if* the merge causes trouble; 2. it would serve as a place to
collect the feedback and summarize the potential problems.

Maybe I'm just asking because I'm one of those not in a mood to
reinstall, but it does sound appealing to me.

Re: Upcoming Qt switch to OpenGL ES on arm64

[Rebecca N. Palmer]

Would packaging Regal solve any of this?

https://github.com/p3/regal

It claims to implement OpenGL on top of OpenGL ES, but I don't know if 
it is complete enough or efficient enough to be useful in this context.


Dmitry Shachnev wrote:

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


Would it also break packages that directly call OpenGL functions that 
are not in ES?  e.g. 3D applications that were initially created under 
OpenGL 1 and never completely moved away from the old fixed-function / 
immediate-mode interfaces.


I don't know how many of these there are: the one I know about 
(FlightGear) is already on your list because it also has a GLU 
dependency.  Trying to find them via codesearch (taking the intersection 
of packages matching "glBegin[^A-Z]|glLight|glFog" and 
"path:debian/control libqt|qtbase|qml-module") finds


amarok apitrace aseba avogadro ball bino camitk cgal choreonoid 
clementine cloudcompare colmap connectome-workbench csoundqt digikam 
doomsday dpuser dustrac enki-aseba flightgear fmit fracplanet freecad 
freemat gambas3 gle-graphics gnuradio goldencheetah gr-fosphor 
gst-plugins-good1.0 gudhi hedgewars iannix ifrit imagevis3d itksnap 
klatexformula kstars ksudoku kubrick lazarus leocad libqglviewer 
libreoffice libterralib mame mathgl mcrl2 meshlab mixxx mldemos mlt mm3d 
mudlet mumble obs-studio octave opencolorio openimageio openjfx openms 
openscad openscenegraph openscenegraph-3.4 osmose-emulator otb ovito 
paraview pcl pfstools pianobooster projectm pyqt5 pyqwt3d pyside pyside2 
python-qt4 qt4-x11 qtbase-opensource-src qtiplot qtsvg-opensource-src 
qttools-opensource-src qtwebengine-opensource-src qtwebkit qwtplot3d 
renderdoc retroarch ring sdrangelove shelxle sleepyhead sofa-framework 
soqt soundscaperenderer starpu stellarium structure-synth tulip uranium 
utopia-documents v4l-utils virtualjaguar vite viva vlc vtk6 vtk7 
warzone2100 webcamoid wireshark woo xflr5 yabause


but as some of these are available with a Qt dependency on armel/armhf, 
I suspect they include false positives that use GL1 only in 
optional/example code or contain an embedded copy of the OpenGL headers.

Re: Upcoming Qt switch to OpenGL ES on arm64

[Ben Hutchings]

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, which is an open source stack if you don't count the
> GPU firmware. It should be comparable to the situation on Intel integrated
> GPUs (but a lot faster and more featureful, and probably with more bugs,
> because the hardware is faster and more featureful). Expect to need a
> recent (buster/sid) kernel, particularly for newer hardware.

I installed an AMD RX550 based card last year.  It required updates to
the kernel, firmware, X driver, and Mesa, which are all available in
stretch-backports.

> Old ATI/AMD GPUs can use the radeon driver stack, which is also open
> source (except for firmware) and comparable to Intel integrated GPUs
> (generally faster and more featureful for hardware of equivalent age).
> 
> I think there might be some intermediate models that are too new for
> radeon but too old for amdgpu; if they exist, those will be stuck with
> the proprietary fglrx driver, which as far as I can tell is like the
> NVidia proprietary driver, but worse. fglrx is no longer supported by
> Debian contrib/non-free.

I'm not aware of any gap.  In fact, at the kernel level, there is some
overlap where the newest models supported by radeon are also supported
(on an opt-in basis) by amdgpu.

The proprietary AMD graphics stack now depends on the amdgpu kernel
driver rather than replacing it.

Ben.

-- 
Ben Hutchings
I'm always amazed by the number of people who take up solipsism because
they heard someone else explain it. - E*Borg on alt.fan.pratchett




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

Re: Upcoming Qt switch to OpenGL ES on arm64

[Adrian Bunk]

On Sat, Nov 24, 2018 at 02:40:37PM +0100, Matthias Klose wrote:
> On 24.11.18 11:26, Andy Simpkins wrote:
> >> So, again: which of the two flavors is the one that benefits more of our 
> >> user
> >> base?
> > 
> > BOTH are possible so why dictate only one?
> > 
> > I would like to see OpenGLES available on all architectures
> > 
> > I would like to see OpenGL available on all architectures
> > 
> > I think that there is a relatively painless method to achieve this
> > 
> > I believe this would also meet your needs
> 
> so why not keep GL as it is now, and build the GLES packages from a single
> source tarball?  This way you minimize your uploads while having both
> implementations in the archive?  Maybe later on, you could even do the same 
> for
> the 32bit ARM architectures if these are still release architectures by that 
> time.

Putting all KDE packages plus all other Qt-using packages into one 
monster source tarball for building them a second time sounds like
a nightmare impossible to maintain.

Like how would security updates of gst-plugins-good1.0 in stable work
when a second copy of it is in the monster tarball due to gstreamer1.0-qt5?

libqt5gui5 has > 1k rdeps, the sanest way forward for providing two 
different ABI versions of libqt5gui5 at the same time would be two
architectures for arm64.

And that is not a realistic option.

> Matthias

cu
Adrian

-- 

   "Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
   "Only a promise," Lao Er said.
   Pearl S. Buck - Dragon Seed

Re: Upcoming Qt switch to OpenGL ES on arm64

[bret curtis]

> >
> > There are more than 5 million Raspberry Pis were sold as of February 2015.
> > All of them with a VC4 GPU, Raspbian ships with the VC4 mesa driver
> > enabled!
> >
> > I'm of the opinion that the switch away from Desktop OpenGL to GLES was a
> > huge mistake and should be reversed as soon as possible unless there is a
> > way to provide for both on all archtictures.
>
> Well, f you can prove this for armhf and/or armel, we can certainly do it.
>

The Raspberry Pi is armhf. What would you like me to prove? Sadly I
can't help you with armel, but with armhf, according to some sources
the number of RPi's sold in the last 5 years is 12 million [1].
Admidetly, not all of them will be used as a desktop, but it is still
nothing to sneeze at and it is shame that we've had to prevent
compiling OpenMW on armhf and armel just because Qt was compiled
against GLES. We've had to introduce "libqt5opengl5-dev,
libqt5opengl5-desktop-dev [armel armhf]" in the debian/control file as
a result. [2] This makes sure that OpenMW can't ever be built on on
armel and armhf with "BD-Uninstallable". [3]

openmw build-depends on missing:
- libqt5opengl5-desktop-dev:armhf
^-- sad state of affairs that this even exists!

[1] 
https://www.theverge.com/circuitbreaker/2017/3/17/14962170/raspberry-pi-sales-12-5-million-five-years-beats-commodore-64
[2] https://salsa.debian.org/games-team/openmw/blob/master/debian/control#L12
[3] https://buildd.debian.org/status/package.php?p=openmw

Re: Upcoming Qt switch to OpenGL ES on arm64

[Scott Kitterman]

On Saturday, November 24, 2018 08:36:11 PM bret curtis wrote:
> > > There are more than 5 million Raspberry Pis were sold as of February
> > > 2015.
> > > All of them with a VC4 GPU, Raspbian ships with the VC4 mesa driver
> > > enabled!
> > > 
> > > I'm of the opinion that the switch away from Desktop OpenGL to GLES was
> > > a
> > > huge mistake and should be reversed as soon as possible unless there is
> > > a
> > > way to provide for both on all archtictures.
> > 
> > Well, f you can prove this for armhf and/or armel, we can certainly do it.
> 
> The Raspberry Pi is armhf. What would you like me to prove? Sadly I
> can't help you with armel, but with armhf, according to some sources
> the number of RPi's sold in the last 5 years is 12 million [1].
> Admidetly, not all of them will be used as a desktop, but it is still
> nothing to sneeze at and it is shame that we've had to prevent
> compiling OpenMW on armhf and armel just because Qt was compiled
> against GLES. We've had to introduce "libqt5opengl5-dev,
> libqt5opengl5-desktop-dev [armel armhf]" in the debian/control file as
> a result. [2] This makes sure that OpenMW can't ever be built on on
> armel and armhf with "BD-Uninstallable". [3]
> 
> openmw build-depends on missing:
> - libqt5opengl5-desktop-dev:armhf
> ^-- sad state of affairs that this even exists!

We have a Rasberry Pi working as a desktop here at my house.  It's quite 
usable as long as you only try to do a few things at a time, but it's not by 
any means zippy.  I strongly suspect that moving back from GLES would move it 
from "reasonable for limited use" to "pointless".  Please don't do anything to 
make things even slower.

Scott K

Re: Upcoming Qt switch to OpenGL ES on arm64

[Sune Vuorela]

On 2018-11-24, Adrian Bunk  wrote:
> libqt5gui5 has > 1k rdeps

I think this is a fact that many people haven't grasped.

And some of those are libraries...

/Sune

Re: Upcoming Qt switch to OpenGL ES on arm64

[Adam Borowski]

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, which is an open source stack if you don't count the
> > GPU firmware. It should be comparable to the situation on Intel integrated
> > GPUs (but a lot faster and more featureful, and probably with more bugs,
> > because the hardware is faster and more featureful). Expect to need a
> > recent (buster/sid) kernel, particularly for newer hardware.
> 
> I installed an AMD RX550 based card last year.  It required updates to
> the kernel, firmware, X driver, and Mesa, which are all available in
> stretch-backports.

Oooh, sounds like you have at least some clue here -- _and_ there are
non-trivial things one should know.  As you can tell from my vitriol,
there's no way I'm going to use anything from nVidia -- yet I need to
replace most of my main home box quite badly.

Thus, are there any particular setups you'd recommend for someone running
unstable and Linus' current kernels?

Running -rc kernels is especially unfun if your card requires nVidia's
proprietary drivers (and so are X transitions in unstable).  Nouveau on the
other hand has problems on this own, usually crashes -- some reproducible
(like enabling xfce's compositor), some random.

The card I have right now crashed under load roughly once a week -- until I
got a higher resolution monitor.  Afterwards, the card can handle static
images (editor, browser, ...), but if I try a video or such, it crashes
every ~10 minutes bringing the whole kernel down.  Speak about "replacement
needed urgently"...

But, I don't blame this particular card.  Its predecessor went down in a
fire (thick smoke for the entire room, small but visible actual flame) so
it's likely the PCIe slot is suspect, not worth the risk replacing just the
GPU without a whole new motherboard (I put in an old but unopened card I
happened to have on storage).  I think I get the message this machine is
telling me...

A decade ago, ATI/AMD drivers were abysmal.  If I understand you right,
they have recently massively improved -- for the values of "recently" of
"not yet in Stretch" (which is fine for the likes of us).  After a string of
4 nVidia cards that brought me nothing but woe, I wish for something that
actually works.  And it'd be so nice if instead of having to do the
research, this here Ben guy told me "do this" so I can return to hacking on
things that have nothing in common with graphics drivers. :)

[Not so unrelated to copying in a restaurant. :p]


Meow!
-- 
⢀⣴⠾⠻⢶⣦⠀ 
⣾⠁⢰⠒⠀⣿⡁ Imagine there are bandits in your house, your kid is bleeding out,
⢿⡄⠘⠷⠚⠋⠀ the house is on fire, and seven big-ass trumpets are playing in the
⠈⠳⣄ sky.  Your cat demands food.  The priority should be obvious...

Re: Upcoming Qt switch to OpenGL ES on arm64

[Adam Borowski]

On Sat, Nov 24, 2018 at 09:51:49PM +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, which is an open source stack if you don't count the
> > > GPU firmware.

> > I installed an AMD RX550 based card last year.  It required updates to
> > the kernel, firmware, X driver, and Mesa, which are all available in
> > stretch-backports.
> 
> Oooh, sounds like you have at least some clue here -- _and_ there are
> non-trivial things one should know.  [...]
> Thus, are there any particular setups you'd recommend for someone running
> unstable and Linus' current kernels?

> 4 nVidia cards that brought me nothing but woe, I wish for something that
> actually works.  And it'd be so nice if instead of having to do the
> research, this here Ben guy told me "do this" so I can return to hacking on
> things that have nothing in common with graphics drivers. :)

Just so this doesn't sound like shoving all effort onto you: even if you
won't provide us with a ready answer on a golden platter, any research is so
much easier if we can start from some advice.  And it's so much better to be
aware of problems _before_ buying stuff.

And it sounds like problems there are.

Thus, knowing what can go bad would be nice for any reader of this list
who's about to look for a GPU.

Which was never a nice thing -- back in the days of Trident/SiS, today
with Mali on ARM or the usual culprits on x86...


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).

Bug#914555: ITP: node-lunr -- simple full-text search

[Jonas Smedegaard]

Package: wnpp
Severity: wishlist
Owner: Jonas Smedegaard 

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

* Package name: node-lunr
  Version : 2.3.5
  Upstream Author : Oliver Nightingale 
* URL : https://lunrjs.com/
* License : Expat
  Programming Lang: JavaScript
  Description : simple full-text search

 Lunr.js is a small, full-text search library for use in the browser.
 It indexes JSON documents and provides a simple search interface
 for retrieving documents that best match text queries.
 Async is a utility module which provides straight-forward, powerful
 functions for working with asynchronous Javascript.
 .
 This package provides Lunr for use directly in web browsers.

This package is needed by recent releases of mkdocs (see bug#907256).

The package will be maintained in the JavaScript team.

 - Jonas

-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEn+Ppw2aRpp/1PMaELHwxRsGgASEFAlv5xF0ACgkQLHwxRsGg
ASE5kA/+MMuMsObJdO6CctkzN3qh4tpQYWAk4Z3tRGfoiC6rNHIsZI9fxHEncTcf
n+r7CchTiG9XiZvUftG+TCZ/9Sy34oQ+x1RbfZbO9dU5bX1tandNXvwtyJ2IN27V
RQi91gN22gvZ0qbeozYDHcLJoe2EoYfVlGe6bkE3mqgHZjW/iwztoRP2OPgLHXnl
C8MYAhhHi0zRVdSAMcTmY28TPRyb/nHBFup7J47bpd8F6V/p2Py7KgOcFHPbmZvN
5hRo0kX8uebpgRLp9gHrXR7aQzKKIu8es9OVv6SX2h5D78cnSJoznw4NXB0DRJ5A
CdtimHlpxheTJzIsMUAxyn5qZyacEsjFAjNMiOdfp4wm7JkRk8VyXFACF8zHheke
8XztQ87GIPoXup8Ifj+rhEZVUZVelVDyztdyfgEfRiAcGQlU0gHbXKOT1C7VqyQy
GEnqa7g61mZFrAwdrp+BJX/nlJxI50iFK+hBwjK9XDTvuNuXRoDYtoHtcMxgm41E
BR5UdKnOfFqP70R97zZ397V10UF8KU65fpXxDpUXsqWAPhIOAnjcH7JaQu/v3f4d
p81K+XHO0l+OS+VFCqTZ8zyGlOmmQ5lHsSPUjj3oVToXG1/VbG9Xm64wbTfTOW8q
qvuSbDxN1TtEODdBiyNWCGiTAaO79vRFRXvT6+DUx+gRhOMW7xc=
=f0Xz
-END PGP SIGNATURE-

Re: usrmerge -- plan B?

[Marco d'Itri]

On Nov 24, "Gabriel F. T. Gomes"  wrote:

> Has this option been given enough attention?  It sounds appealing in
Yes. I would love to implement a --dry-run mode, but I still need to 
figure out how much complex it would be and if it could actually cover 
all cases.

-- 
ciao,
Marco


signature.asc
Description: PGP signature

Re: Upcoming Qt switch to OpenGL ES on arm64

[bret curtis]

Hey Scott,


On Sat, Nov 24, 2018 at 9:01 PM Scott Kitterman  wrote:
>
> On Saturday, November 24, 2018 08:36:11 PM bret curtis wrote:
>
> We have a Rasberry Pi working as a desktop here at my house.  It's quite
> usable as long as you only try to do a few things at a time, but it's not by
> any means zippy.  I strongly suspect that moving back from GLES would move it
> from "reasonable for limited use" to "pointless".  Please don't do anything to
> make things even slower.
>
> Scott K
>

It's because of the VC4 mesa driver that the RPi is usable for you,
reasonable for limited use. Not using VC4, but the CPU based llvmpipe,
is what makes it pointless and almost too slow to use as a desktop. If
you don't have VC4 enabled, I suggest you give it a try, it's a world
of difference.

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]

The 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?

Cheers,
Bret

[1] https://github.com/anholt/mesa/wiki/VC4-OpenGL-support

Re: usrmerge -- plan B?

[Theodore Y. Ts'o]

On Thu, Nov 22, 2018 at 11:27:46AM -0800, Russ Allbery wrote:
> > My position as a usrmerge sceptic, of letting them get on with doing
> > their thing, now seems to have been unwise.  The idea that it would be
> > optional mutated, without proper discussion, and without a transition
> > plan, into it being the default for new installs.
> 
> I agree with wanting more discussion and more of a plan before making it
> the default for new installs, and I'm skeptical this is a good idea for
> buster.

Given that one of my packages had a bug filed against it that was
caused by usrmerge, and while I *can* fix it, I am also getting a bit
skeptical about trying to rush the usrmerge for buster --- and
**definitely** if it is a mandatory merge.  I'd be OK usrmerge being
in buster so long as it has a big huge, fat warning of the form, "if
it breaks your system you get to keep both pieces".  So if things
break in usrmerge system on Buster, they would ***not*** be RC, at
least not for the next 3 months.

Post-buster, I agree doing a mandatory usrmerge transition makes
sense, and this should be done very early in the development cycle,
and not at the very end of the development cycle.

> That idea makes me wince.  This will just result in the same thing
> happening again.  Let's have the discussion *now*, when the problems are
> fresh in our mind, and then defer *action* to early in the bullseye
> release cycle (which I suspect is likely to happen anyway given how long
> it usually takes us to sort through questions of large migrations like
> this).

Agreed, completely.  If we leave usrmerge in buster as a "use at your
own risk", then the people who are the most passionate can try it on
their production systems.  That will hopefully give us more feedback,
which will significantely reduce risk for bullseye.

- Ted

wxWidgets GTK+ 3 build available

[Scott Talbert]

Hi,

Since ~March, we have a GTK+ 3 build of wxWidgets in Unstable/Testing. 
Packages that use wxWidgets may switch over to this build if they desire, 
although we are not pushing to remove the wx GTK+ 2 package in Buster, so 
packages can continue to use the GTK+ 2 build for Buster.


To switch a package over to the GTK+ 3 build, it could be as simple as 
changing the Build-Depends from libwxgtk3.0-dev to libwxgtk3.0-gtk3-dev, 
rebuilding, and testing.


A couple of known issues:
1) If your package uses wxSpinCtrl and hard-codes the widget size, or does 
not have additional horizonal space, the size may have to be adjusted. 
This is due to the underlying GtkSpinButton having switched to a wider 
layout in GTK+ 3.


2) If your package uses wxGLCanvas, it won't work under Wayland.  This is 
due to wxGLCanvas (currently) requiring X11 to function.  This can be 
worked around by forcing the GDK backend to X11.  Here's one example of 
how this has been done: [1]


We have set up a tracker to track the progress of moving to the GTK+ 3 
package here: [2]


Here is a dd-list output for the packages that build-depend on wxWidgets:

A. Maitland Bottoms 
   freedv (U)

Adrien Cunin 
   filezilla

Alastair McKinstry 
   mathgl (U)

Alec Leamas 
   wxsvg (U)

Alessio Treglia 
   sooperlooper (U)

Alexander Kojevnikov 
   spek

Alexander Wirt 
   icinga2 (U)

Andreas Bombe 
   cubicsdr (U)
   limesuite (U)

Andreas Metzler 
   hugin (U)

Andreas Rönnquist 
   poedit (U)

Andreas Tille 
   ctsim (U)
   gentle (U)
   ginkgocadx (U)
   lamarc (U)
   sitplus (U)
   treeviewx (U)

Andrej Shadura 
   wxhexeditor

Anthony F McInerney 
   sandboxgamemaker

Anton Gladky 
   gnuplot (U)

Axel Beckert 
   gnudatalanguage (U)

Barak A. Pearlmutter 
   ucblogo

Barry deFreese 
   plee-the-bear (U)

Bas Couwenberg 
   spatialite-gui (U)
   thuban (U)

Bas Wijnen 
   openmsx-catapult

Benjamin Drung 
   audacity (U)

Brandon Barnes 
   dolphin-emu (U)

Bruno "Fuddl" Kleinert 
   scorched3d (U)

Carlo Segre 
   fityk (U)
   objcryst-fox

Carsten Schoenert 
   kicad (U)

Charles Plessy 
   treeviewx (U)

Chow Loong Jin 
   mediainfo

Christoph Berg 
   pgadmin3 (U)

Christoph Feenders 
   ebook2cwgui (U)

Colin Tuckley 
   trustedqsl (U)

D Haley 
   3depict (U)

Damyan Ivanov 
   flamerobin

Daniel Echeverry 
   tintii

Daniel Leidert 
   openbabel (U)

David Henningsson 
   audacity (U)

David Paleino 
   codeblocks
   spatialite-gui (U)

Debian Accessibility Team 
   espeakedit

Debian Astronomy Team 
   gnudatalanguage
   munipack

Debian Electronics Team 
   kicad

Debian Erlang Packagers 
   erlang

Debian Games Team 
   scorched3d

Debian Games Team 
   0ad
   darkradiant
   dolphin-emu
   freedink-dfarc
   jugglemaster
   megaglest
   openyahtzee
   pcsx2
   plee-the-bear
   scummvm-tools
   springlobby

Debian GIS Project 
   saga
   spatialite-gui
   thuban

Debian Hamradio Maintainers 
   cubicsdr
   ebook2cwgui
   freedv
   limesuite
   trustedqsl

Debian l10n developers 
   poedit

Debian Med Packaging Team 
   ctsim
   gentle
   ginkgocadx
   lamarc
   mriconvert
   sitplus
   treeviewx

Debian Multimedia Maintainers 
   audacity
   wxsvg

Debian Multimedia Maintainers 

   sooperlooper

Debian Nagios Maintainer Group 
   icinga2

Debian PhotoTools Maintainers 
   hugin

Debian PostgreSQL Maintainers 
   pgadmin3

Debian Science Maintainers 
   3depict
   bossa
   cba
   fityk
   mathgl

Debian Science Team 
   gnuplot
   plplot
   wxastrocapture

Debichem Team 
   openbabel
   qutemol

Denis Briand 
   pgadmin3 (U)

Dimitrios Eftaxiopoulos 
   mathgl (U)

Dmitry Smirnov 
   freespace2-launcher-wxlauncher

Dr. Tobias Quathamer 
   silverjuke

Ferdinand Griffon 
   cba (U)

Filip Hroch 
   munipack (U)

Francesco Paolo Lovergine 
   saga (U)
   thuban (U)

Franck Joncourt 
   fwknop-gui

Free Ekanayaka 
   audacity (U)

Georges Khaznadar 
   kicad (U)

Gert Wollny 
   ginkgocadx (U)

Gianfranco Costamagna 
   poedit (U)

Gonéri Le Bouder 
   plee-the-bear (U)

Graham Inggs 
   qutemol (U)

Gudjon I. Gudjonsson 
   gspiceui

Gunter Königsmann 
   wxmaxima

Helmut Grohne 
   jugglemaster (U)

Jaime Robles 
   trustedqsl (U)

James Cowgill 
   codelite
   dolphin-emu (U)

Jan Wagner 
   icinga2 (U)

Jaromír Mikeš 
   audacity (U)
   sooperlooper (U)

Jerry Stueve 
   trustedqsl (U)

Johan Van de Wauw 
   saga (U)

Jose G. López 
   pgn2web

José Luis Blanco Claraco 
   mrpt

Julien Jorge 
   plee-the-bear (U)

Kamal Mostafa 
   ebook2cwgui (U)
   trustedqsl (U)

Kartik Mistry 
   xchm

Kevin M. Rosenberg 
   ctsim (U)

Laszlo Boszormenyi (GCS) 
   delaboratory
   wxsqlite3

Ludovic Rousseau 
   0ad (U)

Luis Rivas Vañó 
   sitplus (U)

Luke Faraone 
   chipw

Mark Vejvoda 
   megaglest (U)

Markus Frosch 
   icinga2 (U)

Markus Koschany 
   megaglest (U)
   openyahtzee (U)
   springlobby (U)

Michael Banck 
   openbabel (U)
   qutemol (U)

Michael Casadevall 
   codeblocks (U)

Miguel A. Colón Vélez 
   pcsx2 (U)

Miriam Rui

Bug#914573: ITP: mongo-cxx-driver -- MongoDB C++ client library

[Roberto C. Sanchez]

Package: wnpp
Severity: wishlist
Owner: "Roberto C. Sanchez" 

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

* Package name: mongo-cxx-driver
  Version : 3.4.0
  Upstream Author : Mongo C++ Driver Team 

* URL : http://mongocxx.org/
* License : Apache License 2.0
  Programming Lang: C++
  Description : MongoDB C++ client library

libmongocxx is the officially supported MongoDB client library for C++
applications.

This package will be maintained by the upstream development team.

-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEz9ERzDttUsU/BH8iLNd4Xt2nsg8FAlv6ICYACgkQLNd4Xt2n
sg/rEw/+K1c56nrVyuD/pvKu7hvfrIdbv2NYtTzi6Pkxx8mgaWghE+xNGninaEpi
9kxZqeTLeSH/FDzJuN/9ZvCcR7p+muoDBX70sRt+bKoDTq1BTCTmIflm9E/XjA0n
01R4+QtYhNgtkFR9XMuThTTei9xamDVLrsguTr4PzN+u0b1/iWZUV1ZCsWoxKJtq
T5BiqGWUtiD0r1VpyTgsrU5CEY+WbKgTVVhAJc4pFFP1BporUwXaCGiyMbmmpiX9
D8RsV9c3CUDPmiLaGIGcX8Ejuy/mM2DOZLIGfI9K4oWuiSKpaTVk+Nrz9RYZ+dGZ
0hb32qtZOJO9rX7SzNS87hCxSRaIKDUtd9AvNHHhaYgBHUExTTNeiXFJrz8CICnG
vefH8+9TyK6VQvnJ1gmYS20/M538fA9mT/70pAnMezTiplCy2m43KeE9RIryNH/Z
qgh9IXGO0zmSq/YkdSp8tRXbf5uKmxTPZavZj3HVeMAAH9BwpNLit2VvmYSvHbB0
4P5PjfOBJ6iQCJNmYQY0VLPq9FKRmBaUZVTwI+jB3zcj5K0zFcUFPLBrCGeY4DEu
QUXWowsBYy3zm99eC/So48neMRVGIB+pGgs6TGzSMbL+Aoou77DKhZKpVajrw1/C
eN+zFrTYHMcI+XL/adKsTuRPq3S8xP32xeRwAgvoP3F7RnIGlGI=
=qTa1
-END PGP SIGNATURE-

Handling library with unstable ABI in experimental -- suggestions?

[Roberto C . Sánchez]

I have filed an ITP [0] for the Mongo C++ Driver.  So far upstream has
not yet declared a stable ABI.  As a result, I intend to upload to
experimental.

I am curious if anyone has suggestions for naming the library package in
experimental in such a way that it handles the currently unstable ABI
and also leaves the way clear for a properly named library package once
the ABI stabilizes and it becomes appropriate to upload to unstable.

That said, upstream intends to declare a stable ABI in some months,
after which the ABI, SONAME, etc. will be managed sensibly.  The upload
to unstable will not happen until that has been fully sorted out.

Regards,

-Roberto

[0] https://bugs.debian.org/914573

-- 
Roberto C. Sánchez

Re: Upcoming Qt switch to OpenGL ES on arm64

[Tollef Fog Heen]

]] 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 dropped from
> the official drivers while 2 years old doesn't get Linux support yet -- and
> nouveau has problems on its own.

es2gears_x11 works fine on my GF116 board (release date: 2011-03-15)
using the proprietary drivers (on an otherwise testing system).

-- 
Tollef Fog Heen
UNIX is user friendly, it's just picky about who its friends are

Re: Review of dwarves 1.12-1 (and sponsoring)

[Paul Wise]

On Sat, Nov 24, 2018 at 10:28 PM Domenico Andreoli wrote:

> I need a sponsor to upload this package. Any volunteer?

The standard RFS process should still work in your case:

https://mentors.debian.net/sponsors/rfs-howto
https://mentors.debian.net/intro-maintainers

-- 
bye,
pabs

https://wiki.debian.org/PaulWise