Lines Matching full:but
29 The issue was fixed there, but you would like to see it resolved in a still
120 approach, but in that development phase it can be an even better idea to
207 above, but failed to reproduce your issue there; at the same time you want to
238 should be enough for most people. But sometimes there are situations where even
242 from top to bottom. But it's mainly meant to skim over and a place to look up
248 demands more than other FLOSS projects. We'd love to make it simpler. But
316 regular Fedora releases, and openSUSE Tumbleweed. But keep in mind, you better
322 or heavily modified vendor kernel to the upstream Linux developers. But note,
323 those often get rejected or ignored, so consider yourself warned. But it's still
355 But its exact brand name (say 'ASUS Red Devil Radeon RX 5700 XT Gaming OC')
417 runtime environment. It's hard to rule out that problem completely, but you
522 But don't invest too much time into this at this point of the process, as
608 You can do that with the help of a script (see below), but it mainly targets
617 code it builds upon, but unless you suspect something like that stick to the
636 But this approach won't work if your WiFi chip is connected over USB or some
653 but before doing so, try a somewhat shorted or modified name when searching the
726 question, as they might be able to help. But use these results with care, as it
746 But some list are hosted in different places. That for example is the case for
747 the ath10k WiFi driver used as example in the previous step. But you'll often
777 approach, but in that development phase it can be an even better idea to
787 before reporting it. You are free to ignore this advice, but as outlined
793 * Install a mainline kernel; the latest stable kernel can be an option, but
799 It also outlines that using a pre-compiled kernel are fine, but better are
828 That's why it might make sense to wait till the merge window is over. But don't
860 But you are in luck if you are using a popular Linux distribution: for quite a
883 development cycle is currently in the middle of a merge window. But even then
894 but quicker to compile.
899 latter is the relevant one of those two, but can only be reached if you enable
901 build a kernel by quite a bit. But that's worth it, as these options will allow
905 But keep in mind: Always keep a record of the issue encountered in case it is
933 line and abandoning your plan to report the issue. But keep in mind that other
952 thus easy to understand in written form. Include all important details, but at
968 source code that triggered the issue and shows how it was called. But that only
1025 get something quickly fixed. But for that to happen the change that's causing
1034 some time, but don't worry, it works a lot quicker than most people assume.
1052 process. But keep in mind: it depends on the issue at hand if the developers
1111 but there are some things you should include always:
1167 laptop mention its name, but try to make sure it's meaningful. 'Dell XPS 13'
1169 not that different from the one sold today, but apart from that the two have
1195 attach, but you have to think yourself what will be helpful for others to know.
1197 additional details they need. But making everything important available from
1269 the report's text to these addresses; but on top of it put a small note where
1292 But this ideal scenario rarely happens. That's why the job is only starting
1294 but often it will be the things listed below. But before digging into the
1317 * You were told to send something, but noticed it contains sensitive
1319 in private to the developer that asked for it. But note in the ticket or a
1327 a reply asking for instructions how to do that. But before going that route try
1333 within a few hours. But most of the time it will take longer, as maintainers
1364 idea, but only report your results if something relevant changed or if you are
1376 developer of the particular code area that will respond to your report. But as
1378 including people that want to help, but in the end might guide you totally off
1379 track with their questions or requests. That rarely happens, but it's one of
1393 possible fix, try to test it in timely manner, too. But do it properly and make
1396 proposed patch with a fix was applied, but in fact wasn't. Things like that
1397 happen even to experienced testers occasionally, but they most of the time will
1404 developers; or a discussion around the issue evolved, but faded out with
1440 react somehow to every issue report, but they are only obliged to fix those
1448 a fix. Such situations can be devastating, but is within the cards when it
1488 kernel.org front page for a week or two, but are unsuitable for testing and
1540 stable and regressions mailing list is all it takes; but in case you suspect
1570 reproduce your issue with a mainline kernel, but want to see it fixed in older
1587 longterm kernels, but too risky to integrate into older ones. So be aware the
1621 In a lot of cases the issue you deal with will have happened with mainline, but
1640 weeks, but sometimes it takes a bit longer.
1684 other issues as well. But be aware that sometimes they can't or won't help; and
1693 report. But nobody can force them to do, as they are contributing voluntarily.
1696 but can't: sometimes they lack hardware programming documentation to do so.
1711 work on the Linux kernel. Those contribute most changes these days. But their
1717 longer time period, but in new versions often leave support for old and rare
1719 a company orphans some code, but as mentioned above: sooner or later they will
1730 But don't worry too much about all of this, a lot of drivers have active
1739 document and the implications between the lines illustrate that. But that's how
1750 want to contribute changes to the text, but for copyright reasons please CC