Hello,
On Thu, 29 Nov 2018, Adrian Bunk wrote:
> Qt already supports runtime ES/non-ES in the same library build on
> Windows [2], something like that might also be doable for Linux if
> anyone (Linaro? Canonical?) with a real interest in that would work
> on making it happen.
>
> Some of the
On Wed, Nov 28, 2018 at 12:32:51PM -0800, Steve Langasek wrote:
> I would caution against prematurely optimizing for build-time. Yes,
> building the entire source package twice is a waste of resources, but it's
> probably a drop in the bucket.
My mail concert was not build-time, but our
On Wed, Nov 28, 2018 at 11:46:21PM +0200, Adrian Bunk wrote:
> On Tue, Nov 27, 2018 at 02:06:27PM -0800, Steve Langasek wrote:
> >...
> > Hmm, so I'm not sure this reflects the actual state of the art wrt dual Qt
> > stacks as it existed in Ubuntu at the time Ubuntu Touch was sunsetted.
> >...
>
On 2018-11-27 21:19 -0300, Lisandro Damián Nicanor Pérez Meyer wrote:
> El martes, 27 de noviembre de 2018 20:39:58 -03 Steve Langasek escribió:
> > prepare dual stack packages that use the symbols file magic from
> > Ubuntu, rebuild all the reverse-dependencies, and identify all those
> >
On Wed, Nov 28, 2018 at 05:03:51PM +0300, Dmitry Shachnev wrote:
> On Tue, Nov 27, 2018 at 11:00:52PM -0800, Steve Langasek wrote:
> > $ grep-dctrl -n -sSource:Package -FDepends \
> > -e
> > 'libqt5(gui|3drenderer|quick|quickparticles|quickwidgets|multimediawidgets)5[[:space:]]*(\(>=
> >
On Tue, Nov 27, 2018 at 02:06:27PM -0800, Steve Langasek wrote:
>...
> Hmm, so I'm not sure this reflects the actual state of the art wrt dual Qt
> stacks as it existed in Ubuntu at the time Ubuntu Touch was sunsetted.
>...
Is there some rationale documented somewhere why this wasn't used in
On Wed, Nov 28, 2018 at 05:03:51PM +0300, Dmitry Shachnev wrote:
> On Tue, Nov 27, 2018 at 11:00:52PM -0800, Steve Langasek wrote:
> The amount of packages will probably be larger in the current sid,
> but it should not be more than 20 packages.
> Plus there are packages which are using
On Tue, Nov 27, 2018 at 11:00:52PM -0800, Steve Langasek wrote:
> $ grep-dctrl -n -sSource:Package -FDepends \
> -e
> 'libqt5(gui|3drenderer|quick|quickparticles|quickwidgets|multimediawidgets)5[[:space:]]*(\(>=
> 5\.[0-9.]*\))(?|$),' \
>
>
Hi Steve and all,
On Tue, Nov 27, 2018 at 03:39:58PM -0800, Steve Langasek wrote:
> It is actually fairly easy to answer this question as well: simply identify
> all the packages in the archive that depend on one of the known dual-stack
> libraries, prepare dual stack packages that use the
Hi Steve!
El miércoles, 28 de noviembre de 2018 04:00:52 -03 Steve Langasek escribió:
[snip]
> > At this point I really feel that, except I am missing something, double
> > building is just not a good idea :-/
>
> Ok, I don't think you've understood then. Perhaps a further example from
> the
On Tue, Nov 27, 2018 at 10:13:06PM -0300, Lisandro Damián Nicanor Pérez Meyer
wrote:
> El martes, 27 de noviembre de 2018 21:51:47 -03 Lisandro Damián Nicanor Pérez
> Meyer escribió:
> [snip]
> > > > prepare dual stack packages that use the symbols file magic from
> > > > Ubuntu, rebuild all the
El martes, 27 de noviembre de 2018 21:51:47 -03 Lisandro Damián Nicanor Pérez
Meyer escribió:
[snip]
> > > prepare dual stack packages that use the symbols file magic from
> > > Ubuntu, rebuild all the reverse-dependencies, and identify all those
> > > packages which are libraries and which end
El martes, 27 de noviembre de 2018 21:19:20 -03 Lisandro Damián Nicanor Pérez
Meyer escribió:
> El martes, 27 de noviembre de 2018 20:39:58 -03 Steve Langasek escribió:
> > On Tue, Nov 27, 2018 at 07:58:17PM -0300, Lisandro Damián Nicanor Pérez
>
> Meyer wrote:
> [snip]
>
> > > Yes, we are :-)
El martes, 27 de noviembre de 2018 20:39:58 -03 Steve Langasek escribió:
> On Tue, Nov 27, 2018 at 07:58:17PM -0300, Lisandro Damián Nicanor Pérez
Meyer wrote:
[snip]
> > Yes, we are :-) Dmitry has been working on them (he is also an Ubuntu Qt
> > maintainer). He points me out that those 7
On Tue, Nov 27, 2018 at 07:58:17PM -0300, Lisandro Damián Nicanor Pérez Meyer
wrote:
> > https://launchpad.net/ubuntu/+source/qtbase-opensource-src-gles/5.7.1+dfsg->
> > 2ubuntu4~1
> > And here is the list of all packages that required dual-stack at least as of
> > 2017, when Ubuntu stopped
Hi Lisandro,
On Fri, Nov 23, 2018 at 11:05:11PM -0300, Lisandro Damián Nicanor Pérez Meyer
wrote:
> Andy: explicitly CCing you because I think it answers part of a question you
> did but in another part of the thread.
> El viernes, 23 de noviembre de 2018 06:58:13 -03 Steve McIntyre escribió:
Hi,
On 2018-11-27 02:46 +, Wookey wrote:
> >
> > Well, that's at very least an interesting data point. So yes, they exist,
> > but
> > they are new and expensive. Can I assume that this means most of our arm64
> > users do not yet get to them?
> Not yet, no although I think you can just
Hi,
On 26/11/18 8:58 pm, Riku Voipio wrote:
> On Thu, Nov 22, 2018 at 07:14:44PM -0300, Lisandro Damián Nicanor Pérez Meyer
> wrote:
>> El jueves, 22 de noviembre de 2018 18:30:39 -03 Marcin Juszkiewicz escribió:
>
>> The real issue here is that *many* arm64 boards currently do not support
>>
On Tue, Nov 27, 2018 at 7:54 AM Gene Heskett wrote:
> Not in that light, but would sinking the pi foundation make us look any
> better? I think not.
the rule i go by is that of the "bill of ethics" [1] - which is both
simple and puzzling at the same time. if you're familiar with the
"New Law"
On Tuesday 27 November 2018 02:04:33 Luke Kenneth Casson Leighton wrote:
> On Tue, Nov 27, 2018 at 6:47 AM Gene Heskett
wrote:
> > On Monday 26 November 2018 22:04:04 Luke Kenneth Casson Leighton
wrote:
> > > On Fri, Nov 23, 2018 at 12:18 AM Lisandro Damián Nicanor Pérez
> > > Meyer
> > >
> >
On Tue, Nov 27, 2018 at 6:47 AM Gene Heskett wrote:
>
> On Monday 26 November 2018 22:04:04 Luke Kenneth Casson Leighton wrote:
>
> > On Fri, Nov 23, 2018 at 12:18 AM Lisandro Damián Nicanor Pérez Meyer
> >
> > wrote:
> > > So: what's the best outcome for our *current* users? Again, pick
> > >
On Monday 26 November 2018 22:04:04 Luke Kenneth Casson Leighton wrote:
> On Fri, Nov 23, 2018 at 12:18 AM Lisandro Damián Nicanor Pérez Meyer
>
> wrote:
> > So: what's the best outcome for our *current* users? Again, pick
> > only one.
>
> here's a perspective that may not have been considered:
On Fri, Nov 23, 2018 at 12:18 AM Lisandro Damián Nicanor Pérez Meyer
wrote:
> So: what's the best outcome for our *current* users? Again, pick only one.
here's a perspective that may not have been considered: how much
influence and effect on purchasing decisions would the choice made
have?
we
On 2018-11-23 23:10 -0300, Lisandro Damián Nicanor Pérez Meyer wrote:
> El viernes, 23 de noviembre de 2018 12:26:49 -03 Wookey escribió:
> >
> > My main desktop is now an arm64 machine with an nvidia PCI graphics
> > card. These are fairly new (and currently expensive), but I have
> > reason to
On Monday 26 November 2018 16:16:40 Alan Corey wrote:
> I think not pulling it to full screen puts everybody in the same boat
> by using the default size.
It also hands you figures not achievable in the real world, often off by
20x.
> But I can watch videos with smplayer on my
> Rock64, on a
I think not pulling it to full screen puts everybody in the same boat
by using the default size. But I can watch videos with smplayer on my
Rock64, on a Pi I need to use omxplayer because smplayer is too low.
There was some mention on the pine64.org page about using the Rock64
as a multimedia
On Monday 26 November 2018 09:40:34 Alan Corey wrote:
> Try glxgears and es2gears on few different platforms. On a Pi 3b
> glxgears runs at about 45 FPS, es2gears slightly lower. On my Rock64
> it's in the hundreds of FPS but that's Mali. Look at omxplayer, full
> screen HD video while the CPU
Try glxgears and es2gears on few different platforms. On a Pi 3b
glxgears runs at about 45 FPS, es2gears slightly lower. On my Rock64
it's in the hundreds of FPS but that's Mali. Look at omxplayer, full
screen HD video while the CPU idles (on a Pi). The GPU is more
capable than the CPU. You
Hello Ian,
On Mon, Nov 26, 2018 at 2:04 PM Ian Campbell wrote:
>
> On Mon, 2018-11-26 at 12:07 +0100, bret curtis wrote:
> > The hardware that supports GLES also supports OpenGL because GLES is
> > a subset of OpenGL.
>
> I'm confused by this inference. If GLES is a subset of OpenGL then
>
On Mon, 2018-11-26 at 12:07 +0100, bret curtis wrote:
> The hardware that supports GLES also supports OpenGL because GLES is
> a subset of OpenGL.
I'm confused by this inference. If GLES is a subset of OpenGL then
surely hardware which claims to implement GLES is at liberty to only
implement that
Hi!
On Mon, Nov 26, 2018 at 11:40 AM Raphael Hertzog wrote:
> >
> > What applications does Debian have in its repo that only support GLES?
>
> Wrong question. Maybe it makes sense for you at the application level for
> the application that are hooking into OpenGL directly. But we are speaking
>
> On Sat, 24 Nov 2018, bret curtis wrote:
> > This is a very wrong assumption, the OpenGL on a RPi (all of them) is
> > hardware accelerated via the VC4 mesa driver by Eric Anholt which is
> > shipped, by default, on by Raspbian. It supports up to OpenGL 2.1 and
> > if you plan on having hardware
Hello,
On Sat, 24 Nov 2018, bret curtis wrote:
> Moving Qt back to using Desktop GL from GLES is going to have zero
> impact performance on the RPi since the VC4 supports up to OpenGL 2.1
> and and GLES 2.0 [1]
That's a different claim to what you made in a former message.
> The problem is that
On Thu, Nov 22, 2018 at 07:14:44PM -0300, Lisandro Damián Nicanor Pérez Meyer
wrote:
> El jueves, 22 de noviembre de 2018 18:30:39 -03 Marcin Juszkiewicz escribió:
> > Does it mean that arm64 box with PCI Express graphics card will be not
> > able to use Qt based software? I can put Radeon or
Hi,
On Fri, 23 Nov 2018, Dmitry Shachnev wrote:
> According to config_help.txt [1], Qt uses ES2 by default on Windows.
Interesting.
> But as Lisandro says, such a change in Debian will break many packages
> (which are currently broken on ARM only), so we are definitely not
> considering it at
On Saturday 24 November 2018 14:36:11 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
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
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
> >
> > 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
On Saturday 24 November 2018 10:29:08 Steve McIntyre wrote:
> On Sat, Nov 24, 2018 at 10:10:04AM -0500, Gene Heskett wrote:
> >And the OpenGL driver is of zero use to me until a preemp-rt, or full
> >RTAI kernel accompanies it. Once that becomes available, and more
> > pi's are in the supply
On Sat, Nov 24, 2018 at 10:10:04AM -0500, Gene Heskett wrote:
>
>And the OpenGL driver is of zero use to me until a preemp-rt, or full
>RTAI kernel accompanies it. Once that becomes available, and more pi's
>are in the supply line, you will see an explosion of pi's running cnc
>machinery. Why?
On Saturday 24 November 2018 09:14:48 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
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
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
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
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
> > 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
On 2018-11-24, Andy Simpkins wrote:
> BOTH are possible so why dictate only one?
Because it would require two flavours of all users.
/Sune
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
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
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
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
> > >
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
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,
On 2018-11-23, Julien Cristau wrote:
> 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?
Because most people on arm64 don't have the hardware.
Rather give them fewer packages that works great rather than many
packages that
-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*:
> Yeah - it depends exactly on your background. There's a small (but
> growing) set of arm64 desktop users,
Apparently none of them are here, tho.
> and it would be unfortunate to cut them off.
But would it? IIUC this proposed change only impacts Qt applications,
and it's not clear whether it
On Friday 23 November 2018 06:37:28 Dmitry Shachnev wrote:
> 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
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
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
> >
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
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
>
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
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
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
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
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
>> >
On Thursday 22 November 2018 19:17:29 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
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?
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
On Thursday 22 November 2018 17:27:35 Lisandro Damián Nicanor Pérez Meyer
wrote:
> El jueves, 22 de noviembre de 2018 19:05:27 -03 Julien Cristau
escribió:
> > On 11/22/18 10:30 PM, Marcin Juszkiewicz wrote:
> > > W dniu 22.11.2018 o 19:37, Dmitry Shachnev pisze:
> > >> The Qt framework can be
On Thursday 22 November 2018 17:33:50 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
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
El jueves, 22 de noviembre de 2018 19:05:27 -03 Julien Cristau escribió:
> On 11/22/18 10:30 PM, Marcin Juszkiewicz wrote:
> > W dniu 22.11.2018 o 19:37, Dmitry Shachnev pisze:
> >> The Qt framework can be built either with “desktop” OpenGL, or with
> >> OpenGL ES support. At the moment we are
On 11/22/18 10:30 PM, Marcin Juszkiewicz wrote:
> W dniu 22.11.2018 o 19:37, Dmitry Shachnev pisze:
>
>> 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
> On Nov 22, 2018, at 10:30 PM, Marcin Juszkiewicz
> wrote:
>
> W dniu 22.11.2018 o 19:37, Dmitry Shachnev pisze:
>
>> 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
W dniu 22.11.2018 o 19:37, Dmitry Shachnev pisze:
> 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.
>
> However we have received a
77 matches
Mail list logo
