That is in the OM Issue Tracker. You will need a GitHub account to login, but this is free.
Reports should include:
What you are testing on: What version of OMLx, please include the Build ID number of the iso you used. Is this the iso ‘Live’ or an installed system, is this on hardware or in VirtualBox or other VM?
Detailed description. This does not have to be long but there needs to be enough for someone to work with. This is a work project.
Any and all relevant logs and screen-shots. It would be wise to include the entire journal log with any report or post.
If you do not know how to do any of this please ask here and we will walk you through this.
Any terminal output longer than about 20-30 lines can be put in a .txt file and attached to your report.
Developers can not fix “it’s broke” they need a cause or otherwise something to work on. That is what the screen-shots and especially the logs are for.
How to gather logs and hardware information for your report?
Using the basic system log or journal log this will create a file called journal.txt you can post to your report:
$ journalctl > journal.txt
That is a very long log usually. To limit the log file to the current boot:
$ journalctl -b > journal-b.txt
For basic but thorough hardware information:
$ inxi -F > inxi-F.txt
You can then post the created files in your report. It is a good idea to look at the output of these commands so you know a little about what you are doing.
$ journalctl -b
$ inxi -F
For journal logs you can access previous boots only if needed for a specific problem. Ask and we can explain. We may ask for other logs for certain issues, if you need help with how to do this just ask.