Hello Raphaël, > Simple, that's because the mainline kernel in Stretch is still 4.9, and > 1.1.0-3 does compile correctly with it. If you use a backported kernel, > you should also use backported versions of many packages needed by the > kernel, among them are the kernel modules like acpi-call. > [...]> Backports and experimental are two totally different things in Debian > ;) I know, but there is something more.
Quote from backports.debian.org: > Backports cannot be tested as extensively as Debian stable, and backports are > provided on an as-is basis, with risk of incompatibilities with other > components in Debian stable. Use with care! > > It is therefore recommended to only select single backported packages that > fit your needs, and not use all available backports. For business users (like me), backports packages are not stable and therefore are still in the testing phase. From the point of view of those who configure the machines in the company it is always convenient to reduce the number of experimental packages in use, even if - for obvious security and compatibility reasons - on the most used machines the kernel must be recent (of course the longterm branch of the Linux kernel is always well tested). > Also, similarly to what you did, I received half a dozen reports from > Launchpad for the very same bug around the time the HWE kernel (which is > some kind of backport if I understand correctly) hit Xenial, whereas the > fix was already available in Artful. I hate that both BTSs default to > hide closed bugs, but on the other hand, bugs are supposed to be > reported against unstable, not stable. Kernel modules are peculiar in > this regard, because people often need to run backported kernels due to > hardware support needs. The only permanent solution is to refine and unify the BTS, because users must always be able to report a bug. If the reporting procedure is not easy, simple and stupid, users will desist and change software or - worse - they will downgrade or be reluctant to update. The user will report the bug if the BTS allows it and will do so for the version that he considers to be the most recent based on his environment. Not necessarily this is bad: it allows to improve the statistics on the packages, to determine those that need more care and those that users want to use more; they also allow to determine which points of the sources require more attention and must be refined at the structural level, through the use of patterns. I can only suggest you take advantage of the priority queue system provided by BTS (including this old and confusing email-based BTS), taking into consideration that utilities such as "reportbug" suggest the user the priority to choose: in my case the tool has suggested the critical priority, which is the one recommended by the guidelines for compilation problems. Probably a more refined subdivision of the reports (obviously assisted by a nice and healthy pizza) will facilitate your work. ;-) > Sorry if I've been a bit harsh. I rarely use reportbug, I do prefer > relying on the good old BTS, with its web and mail interfaces. I didn't > even know that there was no way in reportbug to search for closed and/or > archived bugs. Don't worry, in your shoes I would not have behaved differently. :-) > Thanks, but this was not needed, the bug was already closed when I > force-merged it with #868110. You are welcome. It was my responsibility and I wanted to close with the exact version number. :-) Thank you for all, Lorenzo Il 04/04/2018 02:11, Raphaël Halimi ha scritto: > Le 04/04/2018 à 01:26, Lorenzo Ancora a écrit : >> I was not able to find bug #868110 in reportbug: >> As you can see the list is blank, except for this and another bug >> report. Probably due to the version mismatch. >> Next time I will make the archaeologist directly on the website, >> ignoring the official app. :-) > > Hi Lorenzo, > > Sorry if I've been a bit harsh. I rarely use reportbug, I do prefer > relying on the good old BTS, with its web and mail interfaces. I didn't > even know that there was no way in reportbug to search for closed and/or > archived bugs. > > Also, similarly to what you did, I received half a dozen reports from > Launchpad for the very same bug around the time the HWE kernel (which is > some kind of backport if I understand correctly) hit Xenial, whereas the > fix was already available in Artful. I hate that both BTSs default to > hide closed bugs, but on the other hand, bugs are supposed to be > reported against unstable, not stable. Kernel modules are peculiar in > this regard, because people often need to run backported kernels due to > hardware support needs. > >>> [...] a backport for Stretch is available since August 28th, 2017. >> We are in 2018 and it dates back to 8 months ago. Why is not part of >> Stable after so much time? >> Good to know there is a quick solution. :-) > > Simple, that's because the mainline kernel in Stretch is still 4.9, and > 1.1.0-3 does compile correctly with it. If you use a backported kernel, > you should also use backported versions of many packages needed by the > kernel, among them are the kernel modules like acpi-call. > >> Thank you, the experimental version compiles correctly. > > Backports and experimental are two totally different things in Debian ;) > > Regards, >
