Lines Matching refs:bug

7 A new bug can be filed here:
11 	   own interest to follow the steps here precisely to ensure your bug can be
16 - a reliable :ref:`reproducer <reporting_bugs_reproducer>` for the bug
17 - a :ref:`recording <libinput-record>` of the device while the bug is reproduced
57 Try to identify the bug by reproducing it reliably. Bugs without a
58 reliable reproducer will have lowest priority. The more specific a bug
61 Try to replicate the series of events that lead to the bug being triggered.
62 Narrow it down until you have a reliable sequence that can trigger the bug.
72 The output is textual and can help identify whether the bug is in libinput
78 If the bug cannot be reproduced with the :ref:`libinput-debug-events` helper,
79 even with the correct configuration options set, it is likely not a bug in
93 You must provide these options in the bug report, otherwise a developer
109 When you file a bug, please attach the following information:
120 If you are reporting a bug related to button event generation:
133 When you file a bug, please attach the following information:
140 If the bug is related to the :ref:`speed of the mouse <motion_normalization_customization>`:
151 Is your bug related to a keyboard layout? libinput does not handle keyboard
152 layouts and merely forwards the physical key events. File the bug with your
156 When you file a bug, please attach the following information:
167 When you file a bug, please attach the following information:
185 When you file a bug, please attach the following information:
233 and re-play the event sequence, hopefully triggering the same bug.
260 Select the device that triggers the issue, then reproduce the bug and Ctrl+C
262 contain the sequence required to reproduce the bug. If the bug fails to
269           sequence triggering the bug. Please keep the event sequence as short
272 To verify that the recording contains the bug, you can replay it on your
278 If the bug is triggered by replaying on your device, attach the recording to
279 the bug report.
291 My bug was closed as fixed, what now?
294 libinput's policy on closing bugs is: once the fix for a given bug is on git
295 master, the bug is considered fixed and the gitlab issue will be closed
298 Of course, unless you actually run git master, the bug will continue to
303 .. warning:: Do not re-open a bug just because it hasn't trickled down to
306 Whether the bug fix ends up in your distribution depends on a number of
307 things. Any given bug fix **may** be cherry-picked into the current stable
312 .. warning:: Do not re-open a bug because it wasn't picked into a stable branch
322 .. hint:: If a bug needs to be fixed urgently, file a bug in your
323           distribution's bug tracker.
329 .. warning:: Do not re-open a bug because your distribution didn't update to
339 When is it ok to re-open a fixed bug?
342 Any time the bug was considered fixed but it turns out that the fix is
346 usually better to file a new bug to reduce the noise. For example, if a fix
348 new bug but reference the original bug.
363 - **bug**: issue is confirmed to be a bug
364 - **cantfix**: for technical reasons, this bug cannot be fixed, or at least
366 - **enhancement**: this issue describes a future feature, not a bug.
372   bug, not a software bug. Often these needs to be worked around in libinput
376 - **kernel**: this issue is a kernel bug, not a libinput bug. Often closed
379 - **needs triage**: bug has not yet been confirmed by a core developer.
380 - **not our bug**: the issue is in some other component of the stack and
389   Where a bug is left in this state for too long, the bug will be closed as