So, I think I finally found a real bug!

KGIII · November 18, 2020, 9:31pm

First, let it be known that I know very little about making video - but I made one.

https://bayfiles.com/D7N9k7rfpf/simplescreenrecorder-2020-11-18_16.13.18_mkv

I also wasn’t sure where to upload it, so I picked there. Sadly, it means you have to download it to view it.

But, it’s a real wild bug! I’m pretty sure. Obviously, I was in a VM and using LMDE as the host, but that shouldn’t matter.

I’m still leery of posting bugs. I also have no way to describe this one - but it is reproducible! Either of the options result in entirely unexpected behavior.

wxl · November 18, 2020, 9:35pm

I get a 503 from there.

Generally videos are not considered an acceptable method of describing a bug anyways. They can act as a supplement, but a textual description is the essential piece. This should include:

enumerated steps to reproduce
a description of required conditions
expected results
actual results

More details on the wiki.

Also, we don’t support LMDE. There have been many times that Mint has shown itself to be dramatically different. If you find a bug there, before filing it, you should confirm it within the Ubuntu landscape.

guiverc · November 18, 2020, 9:36pm

I’m getting 503 (Service Unavailable) too

KGIII · November 18, 2020, 9:37pm

http://s000.tinyupload.com/index.php?file_id=05027986387342261584

Try that one.

I’m not really sure how to describe it with text. I’ll think of a way.

wxl · November 18, 2020, 9:39pm

How about “confirming the monitor settings results in system tray dialog menus opening up?”

Either way, that’s a Mint-only bug (meaning you file it with them) unless you can confirm it in Lubuntu.

KGIII · November 18, 2020, 9:41pm

It’s a VM with Mint as the host. The VM is entirely Lubuntu. I hardly think that can be blamed on Mint?!?

wxl · November 18, 2020, 9:43pm

Oops, sorry, misread that. So what version is this? Does it work the same regardless of the resolution you select? What about using different pointing devices? Does it happen with any other dialogs? What if you just use the keyboard?

KGIII · November 18, 2020, 9:46pm

Dunno yet. I’m gonna do a bunch of testing.

It only happens on higher resolutions. So, I’ll eliminate things and get a more precise result.

And, it’s the version that dropped today. The one zsync’ed from the URL with an 18 in it, so it’s today’s version.

guiverc · November 18, 2020, 9:50pm

I would file against lxqt-config as the package, ie. ubuntu-bug lxqt-config

Why? I looked and saw /usr/bin/lxqt-config-monitor running when I tried to re-create the issue, then a dpkg -S told me the package that contains the program.

How it interferes with the panel I don’t know… but I’d file against that package & describe it as best you can.

If it’s the wrong package, it’ll get changed (don’t take offense if that occurs), and if @wxl’s advice differs to mine - take his advice over mine!

I would likely try and re-create it on a live session on real hardware (not VM) on the same hardware, likely different hardware too later.

Comments on bug reports can’t be edited, however the original description can.

KGIII · November 18, 2020, 9:52pm

Again, thanks for the hand holding. I checked and that’s the only bug I found.

Oddly, if I use a keyboard (as suggested) nothing happens. It only happens when attempting to set it to high resolutions.

I’m going to check on bare metal after the ISO is written by Etcher.

So, I’m not done testing. I want to verify if it’s there on bare metal or not. And, I’d have no idea what package to file against, so thanks for that as well. I’m certainly not gonna get offended if it’s changed. I don’t actually get offended. (Offense is taken, never given!)

wxl · November 18, 2020, 9:59pm

@guiverc is right that the package in question is lxqt-config but this could potential be a VirtualBox issue which is a whole different ball of wax. I can’t reproduce the exact same behavior but what I do find is that in the top 3 highest resolutions, left clicking works fine up until the confirmation dialog. To me it seems like it’s stuck trying to drag something. If I use the keyboard to accept, then left clicking seems permanently screwed up. FWIW I’m using 6.1.14 r140239 from the upstream VirtualBox repos.

KGIII · November 18, 2020, 10:06pm

I can’t confirm it happens on bare metal - because I can’t do it on bare metal.

On bare metal, the only resolutions listed are reasonable resolutions for my monitor.

In the VM, I can scale them up to a large resolution that probably doesn’t even work well.

When using the keyboard, nothing happens - including not doing what I’d expect it to do, such as close the window when enter is pressed while that is highlighted.

So, how do I proceed?

wxl · November 18, 2020, 11:15pm

Are there any other apps this happens to? Can you use xrandr to include larger resolutions?

KGIII · November 18, 2020, 11:31pm

There were no other apps that that happened to. I didn’t think to try xrandr - but I am pretty confident it’s just some bug with the window itself when one tries to select a large display resolution. I’ve stepped away from that hardware for a while, largely for dinner which is now eaten.

If you have VirtualBox, you can probably replicate it. I could replicate it consistently, across multiple reboots, waiting for it to check integrity, and then opening up the monitor preferences and changing the resolution to a giant resolution.

Sadly, I didn’t keep yesterday’s ISO to check against. My plan is to check again with tomorrow’s ISO (or the next one to come down the pipe), wait for more suggestions (such as your suggestion), and then file the bug if it still exists.

I’m being extra cautious about filing bugs. I do not want to waste the time of the devs. As I’m new to this, I’m erring on the side of caution and want to do thorough testing before filing bugs.

wxl · November 19, 2020, 12:21am

First off, when in doubt as to whether or not you should file a bug, DO IT.

Secondly, I don’t have a lot of time to devote to this today but lxqt-config hasn’t changed since Groovy so I’m inclined to believe that’s not it.

There’s at least one or two old images here but obviously they don’t last there forever.

KGIII · November 19, 2020, 12:52am

Alright…

I’m gonna need some hand holding. I’m at the page to report the bug.

It didn’t ‘fail’ but there is a bug. It’s definitely not a severe bug, but it’s a bug.

I have three choices: Passed, Failed, and In Progress.

I then have two fields Critical Bugs and Bugs.

I can’t intuit my way to filling those out. The rest of it, I have already filled out and it’s ready to go.

guiverc · November 19, 2020, 1:03am

I think you’re talking about iso.qa.ubuntu.com (QA or Quality Assurance tracker).

In that case I’d PASS the test, as it worked.

The bug can still be linked in the bug section (not CRITICAL as that would mean you were unable to complete the test; it was a show-stopper level bug). My 2c anyway.

– IN PROGRESS

I use this status when I start the test, it contains a copy of the hardware (copied from a text file with my ~27 boxes), eg. if I was using this box I’d use the line

dell [optiplex] 960 (c2q-q9400, 8gb, amd/ati cedar radeon hd 5000/6000/7350/8350)

(just copy & paste that detail; most is from lshw namely make/model (cpu, ram, video))

If it’s a install QA-test, I’d next add a line representing the test from our checklist, eg. if box was in BIOS mode, I was doing a full disk install, no encryption, no internet I’d use something like

testcase: full disk, no encryption, BIOS, no internet

In the checklist I can see I performed that test last for groovy using the 2020-10-22 ISO on a dell optiplex 755 (one I label 8). We’ve not started recording that information yet for 20.04.2 or 21.04.

For live I may write what I plan to do, then when I’ve done it, either amend or add some details. Not everything needs to go there … or many people just leave it blank. It’s up to you.

– PASSED or FAILED

When test is completed; it’s PASS usually. If you were unable to complete test (show-stopper bug, install failed, or system crashed/locked-up, then it’s a FAIL).

Bugs go in “bug section” unless critical.

KGIII · November 19, 2020, 1:11am

Alright. I’ll go ahead and finish this up.

I guess I’m a bit confused. Where do I go to file the bug? (I was under the impression they went into that form right there.)

So, just to be sure, the bug will be filed by this:

https://help.ubuntu.com/community/ReportingBugs#Development_release

Is that correct?

Again, I should only need to ask these questions once and I appreciate the assistance in making sure I do it properly.

guiverc · November 19, 2020, 1:14am

It’s best if you file the bug on your actual machine.

ie.

ubuntu-bug lxqt-config

is what I provided in a prior comment (it wasn’t spaced out thus may have been missed, sorry). That will provide details of your system (release, package details etc) and then switch to firefox for login & completion of details.

Once the bug has been filed, it’s ID is what gets copied across to the iso.qa.ubuntu.com page, if it was a QA-test, and not general testing.

I’ve probably provided this already, but I’ll provide it again, as it’s extremely useful for Lubuntu bugs.

https://phab.lubuntu.me/w/bugs/

KGIII · November 19, 2020, 1:32am

Thanks.

I have done it and done it properly! (I’m pretty sure.)

It gets a bit confusing as the computer I’m using at the moment is in an entirely different room. I’m also only logged in on certain devices. My passwords are usually pretty complex, so I don’t remember them and I rely on a password manager.

But, not to worry. I’ve done it and I think I have the workflow down for future reference. Thanks again!