Debian Bug report logs - #919057
Qemu GTK display mouse pointer visibility/position problem

Reply or subscribe to this bug.

Toggle useless messages

Message #5 received at submit@bugs.debian.org (full text, mbox, reply):

From: halfdog <me@halfdog.net>

To: submit@bugs.debian.org

Subject: Qemu GTK display mouse pointer visibility/position problem

Date: Sat, 12 Jan 2019 11:51:54 +0000

Package: qemu-system-gui
Version: 1:3.1+dfsg-2

After upgrading from Debian Stretch to Buster, thus changing
the qemu version on host, "-display gtk" has to be used instead
of "sdl" as the later is not available with Buster any more.

Since that switch the mouse behaviour changed, making guest machines
(also Debian Buster) very hard to use. I do not know the old
Stretch behaviour with "gtk" interface as I never used it.

Reproduce: Run a qemu instance with "-vga virtio" and "-display
gtk". Maybe the window manager is relevant also, using fvwm2
with an EdgeScroll configuration on host/guest shows the problematic
behaviour. There are no specific guest additions installed in
the guest nor acceleration in place.



Following options exist for still using the mouse/vm:

a) Using "Grab input" and "fullscreen", the mouse position is
correct, but one cannot see any guest mouse pointer. Only changes
in hilighting or menu popups (when clicking) indicate the current
mouse position.

b) Using "fullscreen" and then "grab input" does show the mouse
pointer but mouse position near the screen edge is not submitted
to the guest, those events seem to be consumed on host before that.
Thus those mouse positions cannot be reached in the guest window.

c) Not using fullscreen: fonts are harder to read due to scaling
on quite small mobile display (that's why the fullscreen preference
to avoid pixel-rot). The mouse pointer is shown and edge detection
would work theoretically, but it usually should happen in some
undistinguishable area where the guest-screen-background color
changes to the same color gtk-window-background, thus it is very
hard to hit it with the pointer.


So essentially one can decide beween working mouse cursor display
or working mouse pointer position, but you cannot have both. The
current workaround is to switch between a) and b) requiring 8
multi-key strokes and one mouse gesture instead of having just
to move the mouse pointer to the edge of the screen (old behaviour
with sdl).

Message #10 received at 919057@bugs.debian.org (full text, mbox, reply):

From: Michael Tokarev <mjt@tls.msk.ru>

To: halfdog <me@halfdog.net>, 919057@bugs.debian.org

Subject: Re: Bug#919057: Qemu GTK display mouse pointer visibility/position problem

Date: Sat, 12 Jan 2019 19:13:43 +0300

12.01.2019 14:51, halfdog wrote:
> Package: qemu-system-gui
> Version: 1:3.1+dfsg-2
> 
> After upgrading from Debian Stretch to Buster, thus changing
> the qemu version on host, "-display gtk" has to be used instead
> of "sdl" as the later is not available with Buster any more.

There's no need to explicitly enable gtk/sdl display, it is the
default if the system has all the necessary packages installed
and if X environment is available.

> Since that switch the mouse behaviour changed, making guest machines
> (also Debian Buster) very hard to use. I do not know the old
> Stretch behaviour with "gtk" interface as I never used it.

I don't remember already if gtk interface has been available in
stretch, I think I tried to switch to gtk but rolled it back at
some time. In previous version of qemu as has been available in
Debian (in buster), gtk interface had a lot of issues (that's why
I had to revert back to sdl, and did that at least twice).

Current 3.1 gtk is quite stable finally, and it is the default
upstream too.

> Reproduce: Run a qemu instance with "-vga virtio" and "-display
> gtk". Maybe the window manager is relevant also, using fvwm2
> with an EdgeScroll configuration on host/guest shows the problematic
> behaviour. There are no specific guest additions installed in
> the guest nor acceleration in place.

So guest is linux too? What's "EdgeScroll"?

Do you use USB Tablet device for guest (which syncronizes host and
guest mouse pointer)?

Does the same erratic behavour occurs with other vga variants,
like std?

> Following options exist for still using the mouse/vm:
> 
> a) Using "Grab input" and "fullscreen", the mouse position is
> correct, but one cannot see any guest mouse pointer. Only changes
> in hilighting or menu popups (when clicking) indicate the current
> mouse position.
> 
> b) Using "fullscreen" and then "grab input" does show the mouse
> pointer but mouse position near the screen edge is not submitted
> to the guest, those events seem to be consumed on host before that.
> Thus those mouse positions cannot be reached in the guest window.
> 
> c) Not using fullscreen: fonts are harder to read due to scaling
> on quite small mobile display (that's why the fullscreen preference
> to avoid pixel-rot). The mouse pointer is shown and edge detection
> would work theoretically, but it usually should happen in some
> undistinguishable area where the guest-screen-background color
> changes to the same color gtk-window-background, thus it is very
> hard to hit it with the pointer.

Here I don't understand. Are your mobile screen SMALLER than the
guest screen, so that qemu has to scale DOWN?

> So essentially one can decide beween working mouse cursor display
> or working mouse pointer position, but you cannot have both. The
> current workaround is to switch between a) and b) requiring 8
> multi-key strokes and one mouse gesture instead of having just
> to move the mouse pointer to the edge of the screen (old behaviour
> with sdl).

Thanks,

/mjt

Message #15 received at 919057@bugs.debian.org (full text, mbox, reply):

From: halfdog <me@halfdog.net>

To: 919057@bugs.debian.org

Subject: Re: Bug#919057: Qemu GTK display mouse pointer visibility/position problem

Date: Sat, 12 Jan 2019 21:46:20 +0000

Michael Tokarev writes:
> 12.01.2019 14:51, halfdog wrote:
> > Package: qemu-system-gui
> > Version: 1:3.1+dfsg-2
> > 
> > After upgrading from Debian Stretch to Buster, thus changing
> > the qemu version on host, "-display gtk" has to be used instead
> > of "sdl" as the later is not available with Buster any more.
>
> There's no need to explicitly enable gtk/sdl display, it is the
> default if the system has all the necessary packages installed
> and if X environment is available.

I see. After upgrading the Stretch nonrequired/nonexisting? package
qemu-system-gui was not installed on Buster, so I installed it
manually and forced the qemu call options as sugessted in forum
posts by people having similar issues.

I guess this might be related to running quite minimalistic window
manager configurations, like mine requiring just ~25MB memory
compared to the multi-100MB full-blown ones. Installing the
"qemu-system-gui" even triggered gtk-base library installation
as thay are not needed by anything else it seems.

> > Since that switch the mouse behaviour changed, making guest machines
> > (also Debian Buster) very hard to use. I do not know the old
> > Stretch behaviour with "gtk" interface as I never used it.
>
> I don't remember already if gtk interface has been available in
> stretch, I think I tried to switch to gtk but rolled it back at
> some time. In previous version of qemu as has been available in
> Debian (in buster), gtk interface had a lot of issues (that's why
> I had to revert back to sdl, and did that at least twice).
>
> Current 3.1 gtk is quite stable finally, and it is the default
> upstream too.

That's why, I would like to switch so that the old sdl stuff can
be abandoned to save open source developers time. But therefore
I have to get it working beforehand.

> > Reproduce: Run a qemu instance with "-vga virtio" and "-display
> > gtk". Maybe the window manager is relevant also, using fvwm2
> > with an EdgeScroll configuration on host/guest shows the problematic
> > behaviour. There are no specific guest additions installed in
> > the guest nor acceleration in place.
>
> So guest is linux too? What's "EdgeScroll"?

That is a window manager behaviour, where you let's say have 9
virtual desktops (3x3) and each one can hold windows. By moving
the mouse on screen (1,1) to the right edige of the desktop, the
window manager will switch to screen (1,2). Also the mouse pointer
placement is adjusted, e.g. assuming a 800x600 screen, visible mouse
position would change e.g. (300,580) -> (310,599) -> (315,5).

> Do you use USB Tablet device for guest (which syncronizes host and
> guest mouse pointer)?

No, it is enabled as all USB features are disabled for security
reasons.

> Does the same erratic behavour occurs with other vga variants,
> like std?

I tried "-vga std" but it seems, that this one is completely broken
when you have a non-standard real-hardware display size and want to
use a guest display covering the full host-hardware-display in
fullscreen mode (no pixel-rot on a quite small "1366x768" display).

With "-vga std" the mouse positioning and display seems to work
both in window and full-screen mode (as far as I can guess from
the reproducible/stable bute quite distorted graphics output).

> > Following options exist for still using the mouse/vm:
> > 
> > a) Using "Grab input" and "fullscreen", the mouse position is
> > correct, but one cannot see any guest mouse pointer. Only changes
> > in hilighting or menu popups (when clicking) indicate the current
> > mouse position.
> > 
> > b) Using "fullscreen" and then "grab input" does show the mouse
> > pointer but mouse position near the screen edge is not submitted
> > to the guest, those events seem to be consumed on host before that.
> > Thus those mouse positions cannot be reached in the guest window.
> > 
> > c) Not using fullscreen: fonts are harder to read due to scaling
> > on quite small mobile display (that's why the fullscreen preference
> > to avoid pixel-rot). The mouse pointer is shown and edge detection
> > would work theoretically, but it usually should happen in some
> > undistinguishable area where the guest-screen-background color
> > changes to the same color gtk-window-background, thus it is very
> > hard to hit it with the pointer.
>
> Here I don't understand. Are your mobile screen SMALLER than the
> guest screen, so that qemu has to scale DOWN?

Yes, it is smaller, when not in full-screen mode: both screens
(real hardware and virutal screen) have exactly the same size.
When not in full screen mode, the top/bottom part of the GTK
window reduces the usable real-screen size about 10%, thus the
guest screen content has to be scaled down by 10$.

> ...

Thanks for your great committment to Debian package quality!

hd

Message #20 received at 919057@bugs.debian.org (full text, mbox, reply):

From: Michael Tokarev <mjt@tls.msk.ru>

To: halfdog <me@halfdog.net>, 919057@bugs.debian.org

Subject: Re: Bug#919057: Qemu GTK display mouse pointer visibility/position problem

Date: Sun, 13 Jan 2019 10:07:24 +0300

13.01.2019 0:46, halfdog wrote:
> Michael Tokarev writes:
[]
>> There's no need to explicitly enable gtk/sdl display, it is the
>> default if the system has all the necessary packages installed
>> and if X environment is available.
> 
> I see. After upgrading the Stretch nonrequired/nonexisting? package
> qemu-system-gui was not installed on Buster, so I installed it
> manually and forced the qemu call options as sugessted in forum
> posts by people having similar issues.

qemu-system-gui is a recommended package. Usually and by default,
apt installs recommended packages. These are not installed only if
you explicitly disable this, by adding APT::Install-Recommends=0
to /etc/apt.conf. But this is explicitly warned against, as you're
now supposed to watch for such "missing" packages for functionality
you might be missing.

Forcing the options is still not needed, as were with the sdl display
before buster. BTW, qemu dropped sdl1 display support completely (the
one used on Debian since the beginning) with 3.0 version iirc.

> I guess this might be related to running quite minimalistic window
> manager configurations, like mine requiring just ~25MB memory
> compared to the multi-100MB full-blown ones. Installing the
> "qemu-system-gui" even triggered gtk-base library installation
> as thay are not needed by anything else it seems.

No, not installing qemu-system-gui is only related to your apt
configuration, you explicitly told it to stop installing packages
which are recommended.

The large amount of deps for qemu-system-gui is the exact reason
why this whole thing popped out, why this package has been separated
in the first place. Many people use qemu on headless machines, where
no X components are installed at all. These people (rightly) complained
over the years that qemu forces them to install a ton of X support.
Hence once this become possible we separated whole X support into a
separate package. Now with some guest 3D support too, and with other
extra features people asked about but I were unable to enable due to
old sdl1 display on debian which doesn't have this stuff, and due to
larger set of deps for gtk display.

[]
Thank you for the explanation about your window manager behavour.

>> Do you use USB Tablet device for guest (which syncronizes host and
>> guest mouse pointer)?
> 
> No, it is enabled as all USB features are disabled for security
> reasons.

Please try it with -usb -usbdevice tablet to see whenever it fixes
your issues.

>> Does the same erratic behavour occurs with other vga variants,
>> like std?
> 
> I tried "-vga std" but it seems, that this one is completely broken
> when you have a non-standard real-hardware display size and want to
> use a guest display covering the full host-hardware-display in
> fullscreen mode (no pixel-rot on a quite small "1366x768" display).

Yes that's lovely thing, stdvga only knows about standard VGA
sizes where the key point is that amount of horizontal dots must
be dividable by 8, so each display line ends on whole byte.  I don't
know where this 1366 come from but it was quite often requested
size and it really does not work. It is a nightmare to code this
size in the bios, I've no idea how real hw does that.

BTW, I didn't know about -vga virtio, the first time I come across
it is this your bugreport. And yes this exact thing is done differently
in virtio vga, in a way which is incompatible with old VESA/VGA
interface (in particular there's no BitBLT operations there which
are mandated by VESA standard - that's the main reason why the
horisontal size should be dividable by 8, for bitblt to work right).
Note that -vga std uses a separate video bios code (coming from
seabios project) - this is the code which implements all the video
handling.

> With "-vga std" the mouse positioning and display seems to work
> both in window and full-screen mode (as far as I can guess from
> the reproducible/stable bute quite distorted graphics output).

So it is still distorted...

[]>> Here I don't understand. Are your mobile screen SMALLER than the
>> guest screen, so that qemu has to scale DOWN?
> 
> Yes, it is smaller, when not in full-screen mode: both screens
> (real hardware and virutal screen) have exactly the same size.
> When not in full screen mode, the top/bottom part of the GTK
> window reduces the usable real-screen size about 10%, thus the
> guest screen content has to be scaled down by 10$.

Aha. So the real problem is that the menu bar, which is actually
not useful in your configuration, occupes space. There should be
a way to turn it off I guess.

Why -vga std output is distorted in full-screen mode? Because of
the non-standard resolution?  BTW, I have the same screen size
on my laptop, 1366x768.

Thanks!

/mjt

Message #25 received at 919057@bugs.debian.org (full text, mbox, reply):

From: halfdog <me@halfdog.net>

To: 919057@bugs.debian.org

Subject: Re: Bug#919057: Qemu GTK display mouse pointer visibility/position problem

Date: Sun, 13 Jan 2019 10:05:41 +0000

Michael Tokarev writes:
> 13.01.2019 0:46, halfdog wrote:
> > Michael Tokarev writes:
> []
> >> There's no need to explicitly enable gtk/sdl display, it is the
> >> default if the system has all the necessary packages installed
> >> and if X environment is available.
> > 
> > I see. After upgrading the Stretch nonrequired/nonexisting? package
> > qemu-system-gui was not installed on Buster, so I installed it
> > manually and forced the qemu call options as sugessted in forum
> > posts by people having similar issues.
>
> qemu-system-gui is a recommended package. Usually and by default,
> apt installs recommended packages. These are not installed only if
> you explicitly disable this, by adding APT::Install-Recommends=0
> to /etc/apt.conf. But this is explicitly warned against, ...
>
> The large amount of deps for qemu-system-gui is the exact reason
> why this whole thing popped out, ...

I know that and REALLY appreciate the current behaviour! "Recommends"
gives normal users good default setups, that work (but might be
large, slow or security risks). Disabling "Recommends" just makes
me search forums once each time packages change their "package ABI",
but afterwards the automated installs will do exactly the right
thing, depending on headless or graphical desktop configuration.

> ...
> >> Do you use USB Tablet device for guest (which syncronizes host and
> >> guest mouse pointer)?
> > 
> > No, it is enabled as all USB features are disabled for security
> > reasons.
>
> Please try it with -usb -usbdevice tablet to see whenever it fixes
> your issues.

I tried it. With that device the pointer is invisible with both
[Grab]-[Fullscreen] and [FS]-[Grab] control sequence.

> >> Does the same erratic behavour occurs with other vga variants,
> >> like std?
> > 
> > I tried "-vga std" but it seems, that this one is completely broken
> > when you have a non-standard real-hardware display size and want to
> > use a guest display covering the full host-hardware-display in
> > fullscreen mode (no pixel-rot on a quite small "1366x768" display).
>
> Yes that's lovely thing, stdvga only knows about standard VGA
> sizes where the key point is that amount of horizontal dots must
> be dividable by 8, so each display line ends on whole byte.

Thanks for that hint! I guess wasting 6 horizontal pixels would
be completely OK, so running guest on "1360x768" might be another
workaround.

> I don't
> know where this 1366 come from but it was quite often requested
> size and it really does not work...

I do not know why Lenovo selected that size for all the small size
Thinkpads, but it is really convenient :-)

> BTW, I didn't know about -vga virtio, the first time I come across
> it is this your bugreport. And yes this exact thing is done differently
> in virtio vga, in a way which is incompatible with old VESA/VGA
> interface (in particular there's no BitBLT operations there which
> are mandated by VESA standard - that's the main reason why the
> horisontal size should be dividable by 8, for bitblt to work right).

Ah, that was helpful to locate more information, e.g.
http://qemu.11.n7.nabble.com/Can-t-see-mouse-cursor-on-VNC-viewer-td612906.html

When reconfiguring the server to use

Section "Device"
         Option      "SWcursor" "True"
         Identifier  "Card0"
...

the sequence [Grab]-[Fullscreen] restores the old sdl behaviour,
which seems to be the best (and even an acceptable workaround)
so far. This works both with and without the "usb tablet". As
automated setup creates a stripped down, hardened X config anyway,
adding this option is no real burden.

It would be interesting to know, why the "hardware-cursor" is
not displayed by the host gtk interface - maybe the graphics
card on the host requires similar "hardware-cursor" support for
that? Strange that completely identical X configuration worked
with sdl.

BTW why I wanted to switch std -> virtio: I would hope, that
the attack surface of specialized virtual hardware is smaller
as it does not have to "fake" 20 years of BIOS/bus/hardware
specifics, which may all contain exploitable bugs.

> ...
> > With "-vga std" the mouse positioning and display seems to work
> > both in window and full-screen mode (as far as I can guess from
> > the reproducible/stable bute quite distorted graphics output).
>
> So it is still distorted...

Maybe not, if I try to apply your modulo(8) trick (after others).

> []>> Here I don't understand. Are your mobile screen SMALLER than the
> >> guest screen, so that qemu has to scale DOWN?
> > 
> > Yes, it is smaller, when not in full-screen mode: both screens
> > (real hardware and virutal screen) have exactly the same size.
> > When not in full screen mode, the top/bottom part of the GTK
> > window reduces the usable real-screen size about 10%, thus the
> > guest screen content has to be scaled down by 10$.
>
> Aha. So the real problem is that the menu bar, which is actually
> not useful in your configuration, occupes space. There should be
> a way to turn it off I guess.

Yes. In general I want to completely get rid of pixel-rot, therefore
the fullscreen setups. Apart from that while in fullscreen mode,
it shall not be possible to click/activate anything outside the
guest display (activate a host window frame, a background menu,
send a keystroke) ... Any data transfer or interactions concearning
both guest and host have to be done via separate filter transports
that enforce strict security policies. Thus as a guest user it
should be harder to be tricked into executing/transfering control
commands to the host on error.

> ...

hd

Message #30 received at 919057@bugs.debian.org (full text, mbox, reply):

From: Marc Lehmann <debian-reportbug@plan9.de>

To: Debian Bug Tracking System <919057@bugs.debian.org>

Subject: Re: Qemu GTK display mouse pointer visibility/position problem

Date: Mon, 18 Feb 2019 13:37:20 +0100

Package: qemu-system
Version: 1:3.1+dfsg-4
Followup-For: Bug #919057

Dear Maintainer,

I have similar problems as the original reporter, specifically, after
upgrading to qemu 3.1 from stretch, mouse pointer is invisible in guest
systems iff the pointer is grabbed, with -display gtk and qxl is used.

When using -vga std, both linux and windows guests show a mouse pointer.
likewise, with -vga qxl and/or additional -device qxl, a mouse pointer is
shown *iff* the input isn't grabbed.

The behaviour is perfectly repeatable here: if I press ctrl-alt-g, mouse
pointer becomes invisible, ctrl-alt-g again, pointer becomes visible
again.

Note that the mouse otherwise behaves normally, i.e. with -device
usb-tablet it is where the X11 pointer is, and it is "fully usable" in the
guest, if you ignore the fact that you have to work blind :)

This happens regardless of -device usb-tablet.

I have tried this with both ubuntu 17.10 and windows 10 + qxl-dod driver
(virtio 0.141 and 0.164), and the behaviour is consistent, so I think
this is a bug in the gtk+ interface of qemu when qxl is used (or when a
hardware pointer is used, as I guess -vga std does not emulate a hardware
pointer).

Basically, it seems that the gtk+ interface simply doesn't show the
hardware pointer when input is grabbed, for whatever reason.

Interestingly enough, when I change the shape of the pointer under both
ubuntu and windows 10 guests, the shape is reflected by qemu (as long
as input isn't grabbed, orf course), so the gtk interface is able to
corretcly access the hardware pointer graphics form the guest.

Googling around, I saw recommendations to use -show-cursor - I have no
clue what it does, it didn't have any effect, either.

-- System Information:
Debian Release: 9.6
  APT prefers stable
  APT policy: (990, 'stable'), (500, 'unstable-debug'), (500, 'testing-debug'), (500, 'stable-updates'), (500, 'stable-debug'), (500, 'unstable'), (500, 'testing'), (1, 'experimental-debug'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386, x32

Kernel: Linux 4.18.20-041820-generic (SMP w/8 CPU cores)
Locale: LANG=C, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=C (charmap=UTF-8)
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages qemu-system depends on:
ii  qemu-system-arm    1:2.8+dfsg-6+deb9u5
ii  qemu-system-mips   1:2.8+dfsg-6+deb9u5
ii  qemu-system-misc   1:3.1+dfsg-2+b1
ii  qemu-system-ppc    1:2.8+dfsg-6+deb9u5
ii  qemu-system-sparc  1:2.8+dfsg-6+deb9u5
ii  qemu-system-x86    1:3.1+dfsg-2+b1

qemu-system recommends no packages.

qemu-system suggests no packages.

-- no debconf information

Message #35 received at 919057@bugs.debian.org (full text, mbox, reply):

From: Gerd Hoffmann <kraxel@redhat.com>

To: qemu-devel qemu-devel <qemu-devel@nongnu.org>, 919057@bugs.debian.org

Subject: Re: Qemu GTK display mouse pointer visibility/position problem

Date: Thu, 21 Feb 2019 15:18:41 +0100

  Hi,

> I have similar problems as the original reporter, specifically, after
> upgrading to qemu 3.1 from stretch [from qemu 2.8 -- mjt], mouse pointer
> is invisible in guest systems iff the pointer is grabbed,
> with -display gtk and qxl is used.

> When using -vga std, both linux and windows guests show a mouse pointer.
> likewise, with -vga qxl and/or additional -device qxl, a mouse pointer is
> shown *iff* the input isn't grabbed.
> 
> The behaviour is perfectly repeatable here: if I press ctrl-alt-g, mouse
> pointer becomes invisible, ctrl-alt-g again, pointer becomes visible
> again.

Why do you grab in the first place?

> I have tried this with both ubuntu 17.10 and windows 10 + qxl-dod driver
> (virtio 0.141 and 0.164), and the behaviour is consistent, so I think
> this is a bug in the gtk+ interface of qemu when qxl is used (or when a
> hardware pointer is used, as I guess -vga std does not emulate a hardware
> pointer).

Yes, -vga std has no hardware cursor support.

qxl has two modes: "server mouse mode" where the guest/spice-server
renders the cursor (effectively software cursor), and "client mouse
mode" where the spice-client renders the cursor (effectively hardware
cursor, typically done by setting the window cursor to the guest
cursor).

"client mouse mode" is used in case a absolute pointing device is
present, "server mouse mode" otherwise.

Likewise qemu UIs (both gtk and sdl) do not grab the pointer in case a
absolute pointing device is present, otherwise they do automatically
grab the pointer on mouse clicks.

So typically you run either in server mouse mode with grab or client
mouse mode without grab.  The gtk ui has some logic to handle that,
specifically it hides the cursor in some cases to avoid that you see
both software and hardware cursor.  When manually activating the grab
you are confusing that logic ...

> Googling around, I saw recommendations to use -show-cursor - I have no
> clue what it does, it didn't have any effect, either.

Try "-display gtk,grab-on-hover=on"?

That'll activate the *keyboard* grab in case the mouse pointer is within
the qemu window, so hotkeys go to the guest instead of being captured by
the hosts window manager.  Then you don't have to manually activate the
grab via Ctrl-Alt-G (which grabs both keyboard and pointer) for that.

HTH,
  Gerd

Message #40 received at 919057@bugs.debian.org (full text, mbox, reply):

From: top top <top-manufacturer46@hotmail.com>

Subject: LED Product Sell.

Date: Sun, 19 Jul 2020 08:39:05 +0000

[Message part 1 (text/plain, inline)]

Hello,
Good day!
This is Top LED Product Factory from in China.
We are specialize in LED Product for 10years,and capable production,promised delivery time and high level quality!
Please sent purchase detail info(as type/specifications/quantity Ect).We can provide you with the best price.

Also we have our own professional designers to meet any of your requirements.
Sincerely,
Andy

[Message part 2 (text/html, inline)]

Message #45 received at 919057@bugs.debian.org (full text, mbox, reply):

From: top top <top-manufacturer79@hotmail.com>

Subject: Led LTD.

Date: Tue, 30 Mar 2021 01:57:57 +0000

[Message part 1 (text/plain, inline)]

Hello,
Good day.
We are manufacturers of all kinds of LED PRODUCT in China.
If you are interested.kindly reply to know more about us and contact us for your order.
We deliver worldwide at the cheapest prices.

Also we have our own professional designers to meet any of your requirements.
Sincerely,
Andy

[Message part 2 (text/html, inline)]

Message #50 received at 919057@bugs.debian.org (full text, mbox, reply):

From: top top <top-manufacturer84@hotmail.com>

Subject: LED Product Factory

Date: Fri, 12 Aug 2022 00:13:52 +0000

[Message part 1 (text/plain, inline)]

Hello,
How are u!
We are a manufacturer of LED Product from China, if you need to buy it,
And inform us of the item/s and quantities required, including your details and we will be more then willing to quote you.

We look forward to a wonderful relationship together and success for all concerned.
Best regards,
Andy

[Message part 2 (text/html, inline)]

Message #55 received at 919057@bugs.debian.org (full text, mbox, reply):

From: sales sales <salesbest62@outlook.com>

Subject: LIGHT

Date: Sun, 6 Aug 2023 01:53:37 +0000

[Message part 1 (text/plain, inline)]

Hi There,
Wish you have a nice day.
Knowing you are in business of Lighting
We are Manufacturer and Exporter in all kinds of Lighting.

1. Customized is acceptable.
2. OEM service is provided.
3. High Quality and Stabled delivery is ensured.
Any interest pls reply then we quote good price.

So we want to avail ourselves of opportunity establishing business relation with you.
Best regards,
Andy

[Message part 2 (text/html, inline)]

Send a report that this bug log contains spam.