Вышел OpenRC 0.12

надо будет keyword под чрут добавить, если кому не лень багрепорт сделайте, щас такого нету. Может там есть и более хитрые проблемы, которых я сейчас не вижу.

про сеть rc_provide=«net» должно помочь.

А внезапно там делая возможным глобальное USE="-openrc" с последующим выпиливанием opernc не посмотреть в чем же там могут быть возможные проблемы от этого шага это ВНЕЗАПНО тоже нормаль так да?

А ты на 100% уверен что эти проблемы воспроизводимы без установленного systemd? А теперь посчитай сколько разработчиков в Gentoo занимаются systemd.

Орать как всё плохо могут все. Приносить пользу проекту и работать с community, внося нужные фиксы - осиливают не все. Как поступишь ты - решать только тебе, но по твоим постам я уже это понял. Пили свои локальные фиксы и радуйся жизни от того, что у тебя всё хорошо. А я и остальные разработчики продолжим работать для себя и для всего остального community

А внезапно там делая возможным глобальное USE="-openrc" с последующим выпиливанием opernc не посмотреть в чем же там могут быть возможные проблемы от этого шага это ВНЕЗАПНО тоже нормаль так да? Ну ок чо.

какого хрена это делает в _этой_ теме?

rc_provide=«net»

Это я и проделал :-). Но согласись - это не решение. Насчет отдельного keyword - не уверен, хотя это кажется самым простым выходом, ибо keyword lxc заюзать под чруты всё-таки ИМХО не получится.

какого хрена это делает в _этой_ теме?

... а не на багзилле :-D

А ты на 100% уверен что эти проблемы воспроизводимы без установленного systemd?

Я на 100% уверен что эти проблемы воспроизводимы без установленного openrc.

Я на 100% уверен что эти проблемы воспроизводимы без установленного openrc.

А теперь посчитай разработчиков имеющих подобные конфигурации

Это я и проделал :-). Но согласись - это не решение.

как это не решение? самое, что ни на есть решение - отметить, что контейнер сам реализует сетевую подсистему, и opernc не управляет ей.

Насчет отдельного keyword - не уверен, хотя это кажется самым простым выходом

ну keyword это прямое указание на отключение скриптов на определенных конфигурациях, т.е. служит именно для этого. Другое дело, что keyword anything точно не будет стоять в net.

, ибо keyword lxc заюзать под чруты.

тоже вариант кстати.

на багзилле этого тоже не надо, оно там есть при чем давно, более-менее активно за эту работу взялись неделю назад, во всяком случае баг действительно стал треккером и стали создаваться баги на приложения, которые неправильно используют functions.sh.

как это не решение?

Я имел ввиду что нужно сделать не только это. При старте любого сервиса в чруте openrc ругается на отсутствие директории /run/openrc/softlevel(и предлагает решение, да). Сделать это более user-friendly что-ли, за счет keyword было бы неплохо. А так если всё сделать ручками - оно работает, вопросов нет :-D

на багзилле этого тоже не надо, оно там есть при чем давно, более-менее активно за эту работу взялись неделю назад, во всяком случае баг действительно стал треккером и стали создаваться баги на приложения, которые неправильно используют functions.sh.

кстати да, проглядел совершенно

init6, тебе сюда -> https://bugs.gentoo.org/show_bug.cgi?id=373219

хак:

cat chroot-init:
#!/bin/sh
[ -f /run/openrc/softlevel ] || touch /run/openrc/softlevel
$@

а вообще, да, надо подумать.

он знает, я ему туда показывал больше 2 недель назад.

этот хак можно уложить в скрипт run-chroot.local из набора gentoo-chrootiez, да, об этом я как-то забыл, а как ты запостил - вспомнил. Вот что значит, поделиться проблемой - сам находишь решение :-D

но вообще init-система, работающая в чруте - это немного не стандартный use-case

Да, это обычно какие-то тесты для себя. В продакшен оно не особо нужно, да и все варианты невозможно предусмотреть (особенно если разные системы инициализации).

Тогда я ВООБЩЕ не понимаю чего он кричит. Баг есть, работа ведется. Да, медленно. Но про недостаток рук мы уже говорили.

Ну тогда смотри «костыли» выше :-)

Как я уже говорил, я тоже использую openrc в чрутах - для тестов пакетов с init-скриптами при стабилизации

init6, тебе сюда -> https://bugs.gentoo.org/show_bug.cgi?id=373219

Вот забавно! А мне это зачем? УМВР если чо.

УМВР если чо.

Вышел OpenRC 0.12 (комментарий), второй абзац

понимаешь, смешались люди, кони:

1). openrc поставляет functions.sh это не баг, а фича

2). ebuild openrc создает симлинк functions.sh -> на openrc-шный скрипт. Это.. не знаю скорее всего не баг

3). куча прог использовали functions.sh без зависимости от openrc - это проблема прог, и неправильно.

При этом он искренне считает, что вначале разработки openrc Робин должен был каким-то чудом решить, что functions.sh нужен всем и держать 2 пакета вместо одного :)

Вышел OpenRC 0.12 (комментарий), второй абзац

А вы тупо баги лишний раз не плодите на ровных местах и все будет ок.

При этом он искренне считает, что вначале разработки openrc Робин должен был каким-то чудом решить, что functions.sh нужен всем и держать 2 пакета вместо одного :)

По факту functions.sh был и есть часть openrc. Однако чуть менее чем всему что я перечислил во втором абзаце стоят там зависимости от openrc или нет не важно. Важно то что всему этому сам openrc нафиг не нужен а нужны только функции которые предоставляет functions.sh. Сам собой напрашивается вывод разделить openrc на functions.sh и openrc. И все проблема исчерпана.

Сам собой напрашивается вывод разделить openrc на functions.sh и openrc. И все проблема исчерпана.

это не верно. functions.sh должен предоставлять другой пакет, а пакет openrc (возможно) просто не будет устанавливать functions.sh. Что и делается. Вот это вот _правильное_ решение.

я не случайно сказал, что это относится к проблеме пакетирования, а не openrc, подумай пожалуйста об этом надосуге.

functions.sh должен предоставлять другой пакет, а пакет openrc просто не будет устанавливать functions.sh

т.е. «разделить openrc на functions.sh и openrc» это не то же самое? ну ок.

нет, не тоже самое. Ты ведь понимаешь, почему?

нет, не тоже самое. Ты ведь понимаешь, почему?

А ты ведь понимаешь что в данный момент проблема из-за того что functions.sh является частью openrc и самое очевидное это отделить эту часть functions.sh от openrc в отдельный проект/ebuild/библиотеку и это решит проблему.

И очевидно что если openrc сам тоже использует functions.sh то да безусловно должен быть ebuild предоставляющий functions.sh а в депенденсы opernc этот ebuild нужно добавить.

ясно.. не понимаешь.. </subthread>

ясно.. не понимаешь.. </subthread>

ясно и ты тоже не понимаешь

я понимаю, что ты хочешь, и понимаю, что ты не прав, хотя и близок. И то, что ведётся работа в правильном направлении, и что она ведётся не смотря на то, что ты тут вопишь.

А вы тупо баги лишний раз не плодите на ровных местах и все будет ок.

Во-первых, учитывая ситуацию с зависимостями это нихрена не «ровное место». Во-вторых, как ты уже убедился - работа ведется.

А ты ведь понимаешь что в данный момент проблема из-за того что functions.sh является частью openrc и самое очевидное это отделить эту часть functions.sh от openrc в отдельный проект/ebuild/библиотеку и это решит проблему.

Ну, это потипу как с системде, удевом, hwdb итд :]

действительно, выделить gentoo-base-functions и таскать везде вместе с пакетом openrc :), а чо gentoo-base-functions же и в других дистрибутивах нужны.

Нужно.

О, фуррятина...

На баг-трекере уже есть сообщение о проблеме, зачем мне дублировать его?

На баг-трекере уже есть сообщение о проблеме, зачем мне дублировать его?

А я то чо? У ваще то и opernc уже давно нет и ничего не ломалось. :)

Ну и молчи в тряпочку.

Ну и молчи в тряпочку.

С чего бы мне молчать если в результате с этой радостью сталкивается каждый кто ставит глобально -openrc а затем его выпиливает.

Вопрос к местным разработчикам-гентушникам: почему паралельная загрузка в openrc считается нестабильной, и когда ждать ее полного запила?

потому, что иногда встречаются странные баги.. в общем-то пока явных планов все дебажить и править нет, но сейчас несколько человек к проекту добавились может и изменится ситуация.

Добавились? это хорошо. У меня кстати есть возможность тестить оперц, так что если что надо проверить - пиши в джаббер, я на работе посмотрю) Сам кстати не наталкивался на баги, даже и писать в багзиллу нечего)

Хотя помнится ловил баг - если нет сети и должна монтироваться nfs - затык на пару минут гарантирован. Было год назад, потом я свалил на более секурный вариант в виде sshfs.

всё хорошо, но эти сраные cgroups... вот нахрена это дерьмо тут!?

Почему cgroups - дерьмо? Обоснуй

Я вот помню странное...сделал я softlevel, а оно заработало только после пересборки openrc. Оно так быть не должно же..

Даже на десктопе приходится усмирять прожорливый до ресурсов софт как раз юзая цгрупз. Про серверы вообще молчу. Выходи из криокамеры.

лечись!

проблемы создаёт
мне за тебя поиск осилить!? о_О

Ну какие проблемы? Приведи примеры) Я наоборот, включаю в ядре cgroups на автоматическое использование, и для планировщиков CFQ/BFQ включаю соответственные пункты меню.

слабо нормально вопрос задать? оно тут, чтобы давать профиты пользователям. и это cgroups не дерьмо.