Created attachment 8725 [details] не отключается bluetooth Не работает отключение и включение Bluetooth (rfkill soft lock), пока не установишь gnome-settings-daemon или mate-settings-daemon. Установка cinnamon-settings-daemon не помогает. В cinnamon-regular проявляется.
g-s-d с собой таскает /lib/udev/rules.d/61-gnome-settings-daemon-rfkill.rules, наверное, стоит в cinnamon-settings-daemon такой же конфиг положить.
(Ответ для Владимир Диденко на комментарий #1) > g-s-d с собой таскает > /lib/udev/rules.d/61-gnome-settings-daemon-rfkill.rules, наверное, стоит в > cinnamon-settings-daemon такой же конфиг положить. Подождите. Надо проверить. Если этого файла достаточно без settings-daemon, то такой файл должен быть в пакете у blueberry.
Возможно, относится и к Simply -- пронаблюдал что-то такое на 9.0 недавно.
(In reply to Антон Мидюков from comment #2) > Подождите. Надо проверить. Если этого файла достаточно без settings-daemon, > то такой файл должен быть в пакете у blueberry. Ну это дискуссионный вопрос. Если брать подход Gnome - то они разрешают работу с rfkill всем приложениям. Если поместить правило в blueberry - то получится, что приложение (а не DE) разрешает всем пользоваться rfkill. По мне, так первый подход логичней получается.
Единственное что, возможно, правило стоит поместить в отдельный пакет, а потом зависимость на него где нужно поставить, чтобы не плодить дубликаты.
(Ответ для Владимир Диденко на комментарий #5) > Единственное что, возможно, правило стоит поместить в отдельный пакет, а > потом зависимость на него где нужно поставить, чтобы не плодить дубликаты. Да, это разумно. Можно тогда хоть в брендингах прописать эту зависимость или метапакете, который вытянул blueberry.
(In reply to Антон Мидюков from comment #6) > (Ответ для Владимир Диденко на комментарий #5) > > Единственное что, возможно, правило стоит поместить в отдельный пакет, а > > потом зависимость на него где нужно поставить, чтобы не плодить дубликаты. > > Да, это разумно. Можно тогда хоть в брендингах прописать эту зависимость или > метапакете, который вытянул blueberry. Осталось только решить, кто это будет делать:)
(Ответ для Владимир Диденко на комментарий #7) > (In reply to Антон Мидюков from comment #6) > > (Ответ для Владимир Диденко на комментарий #5) > > > Единственное что, возможно, правило стоит поместить в отдельный пакет, а > > > потом зависимость на него где нужно поставить, чтобы не плодить дубликаты. > > > > Да, это разумно. Можно тогда хоть в брендингах прописать эту зависимость или > > метапакете, который вытянул blueberry. > > Осталось только решить, кто это будет делать:) Мне несложно, соберу. Тогда будем считать, что тут notabug. Напишу сюда про собранный пакет.
Собрал и проверил: [#250144] DONE (try 3) rfkill-users-udev-rules.git=1.0-alt1 Для p9: #250157 AWAITING #1 p9 rfkill-users-udev-rules.git=1.0-alt1
(Ответ для Антон Мидюков на комментарий #9) > [#250144] DONE (try 3) rfkill-users-udev-rules.git=1.0-alt1 Опять префиксы-суффиксы, как в пакетах с настройками, намешал. Смотри, в именах лучше идти от общего к частному -- поэтому лучше setup-*, чем *-setup, и udev-rules-rfkill-users, чем rfkill-users-udev-rules. Заодно по udev* будет легче заметить (я помню, что пакет rfkill у нас тоже есть). Ну и если не пугать юзеров, которых убьёт радиоизлучением (RF) -- то, может, лучше даже udev-rules-rfkill. :)
(Ответ для Michael Shigorin на комментарий #10) > (Ответ для Антон Мидюков на комментарий #9) > > [#250144] DONE (try 3) rfkill-users-udev-rules.git=1.0-alt1 > Опять префиксы-суффиксы, как в пакетах с настройками, намешал. > > Смотри, в именах лучше идти от общего к частному -- поэтому лучше setup-*, > чем *-setup, и udev-rules-rfkill-users, чем rfkill-users-udev-rules. Заодно > по udev* будет легче заметить (я помню, что пакет rfkill у нас тоже есть). > > Ну и если не пугать юзеров, которых убьёт радиоизлучением (RF) -- то, может, > лучше даже udev-rules-rfkill. :) Это твои хотелки. В реальности у нас: 3dprinter-udev-rules vhba-udev-rules segger-jlink-udev-rules st-stlink-udev-rules
(Ответ для Антон Мидюков на комментарий #11) > Это твои хотелки. Ну должен же хоть кто-то головой думать ;-] > В реальности у нас: > 3dprinter-udev-rules Это не у нас, а из-под fcimport. > vhba-udev-rules Это десять лет назад упаковали, видимо, не вдаваясь в такие подробности. > segger-jlink-udev-rules > st-stlink-udev-rules Этого в сизифе вообще не нашёл. Ладно, завязываю с офтопиком, это всё равно культурологическое. Отвечай где и как угодно, если охота :-)
(Ответ для Michael Shigorin на комментарий #10) > Ну и если не пугать юзеров, которых убьёт радиоизлучением (RF) -- то, может, > лучше даже udev-rules-rfkill. :) Даже udev-rules-rfkill-uaccess Предлагаю таки переименовать.
(Ответ для Yuri N. Sedunov на комментарий #13) > (Ответ для Michael Shigorin на комментарий #10) > > Ну и если не пугать юзеров, которых убьёт радиоизлучением (RF) -- то, может, > > лучше даже udev-rules-rfkill. :) > > Даже udev-rules-rfkill-uaccess > > Предлагаю таки переименовать. [#250168] DONE (try 2) udev-rules-rfkill-uaccess.git=1.0-alt1 [#250163] DONE del=rfkill-users-udev-rules
Спасибо, дружище :-)
(Ответ для Антон Мидюков на комментарий #14) > > Предлагаю таки переименовать. > > [#250168] DONE (try 2) udev-rules-rfkill-uaccess.git=1.0-alt1 > [#250163] DONE del=rfkill-users-udev-rules Теперь его следует употребить в {g,m}-s-d в качестве зависимости исключив собственные *-rfkill.rules.
