From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Date: Thu, 5 Dec 2019 12:38:40 +0300 From: Michael Shigorin To: devel-distro@lists.altlinux.org Message-ID: <20191205093840.GD29047@imap.altlinux.org> References: <3112610.ESP07HXmkQ@zerg.malta.altlinux.ru> MIME-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.10.1 (2018-07-13) Subject: Re: [devel-distro] =?koi8-r?b?8NLP0MHWwSDRxMXSzs/HzyDNz8TVzNEg1yDQ?= =?koi8-r?b?0s/GyczFIMnaIM/C0sHawQ==?= X-BeenThere: devel-distro@lists.altlinux.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Distributions development List-Id: Distributions development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Dec 2019 09:38:40 -0000 Archived-At: List-Archive: On Thu, Dec 05, 2019 at 04:18:39PM +0700, Антон Мидюков wrote: > > У меня в > > http://git.altlinux.org/people/zerg/packages/?p=mkimage-profiles-kworkstation.git;a=blob;f=features.in/wireless/config.mk > > указан rtl8723de, но в образ дистрибутива молча не попадает. > > Как такое может быть? Из KFLAVOURS и KMODULES в image.in/functions.mk порождается регулярное выражение -- кто подошёл, тот и попал. > > P.S. Собираю с ядром un-def и в данный момент > > kernel-modules-rtl8723de-un-def отсутствует в репозитории. > Потому что отсутствует в репозитории. Собственно, а чего ты хотел -- или вопрос именно в _молча_? > Действует принцип: есть модуль добавляем, нет - ну и фиг с ним. > Согласен, надо хоть warning какой сделать. С текущей реализацией kpackages это не будет тривиально. Думаю, тут есть примерно два (сочетаемых) пути: 1) сделать тесты по содержимому, см., к примеру, features.in/rescue/rescue/image-scripts.d/00-test-rescue; 2) сделать гарантирующий механизм, который вместо регэкса будет раскрывать вводные в список (или ручку, которая будет переключать режим из "по возможности" в гарантию, и по ней брать ту или иную реализацию функции kpackages). Для совсем хорошего первого варианта хорошо бы сперва привести в приличный вид подсистему логирования: а) сейчас все warning'и попадают в build.log, где их мало кто будет искать при _каждой_ сборке (или просто никто); б) сейчас есть только ручка DEBUG о трёх положениях (0, 1, 2), а хорошо бы придумать или набор ручек, или тщательно выверенный "светофор", когда можно было бы системно включать, например, -x для запускаемых скриптов (сюда же и проблемка с выхлопом при создании чрутов, на которую обратил внимание boyarsh@ и которую я признал, но сейчас не возьмусь точно формализовать); в) возможно, после решения (а) и фильтра заведомого шума получится сделать что-то вроде -Werror. Но если тесты будут выдавать не предупреждения, а обрыв сборки, то можно и далее откладывать логи на светлое будущее (tm). --  ---- WBR, Michael Shigorin / http://altlinux.org   ------ http://opennet.ru / http://anna-news.info