URL: https://www.opennet.ru/cgi-bin/openforum/vsluhboard.cgi
Форум: vsluhforumID3
Нить номер: 111341
[ Назад ]

Исходное сообщение
"Релиз Debian 9.0 'Stretch' намечен на 17 июня"

Отправлено opennews , 27-Май-17 09:09 
Разработчики проекта Debian назначили (https://lists.debian.org/debian-devel-announce/2017/05/msg00...) дату релиза Debian 9.0 "Stretch". Релиз планируется выпустить 17 июня, в связи с чем запущена инициатива по проведению в этот день мероприятий (https://wiki.debian.org/ReleasePartyStretch), приуроченных к выходу Debian 9.0. В странах бывшего СССР мероприятий пока не назначено.

В настоящее время насчитывается (http://bugs.debian.org/release-critical/) 120 критических для формирования релиза ошибок. До 6 июня планируется закрыть все эти ошибки. Проблемы которые не удастся устранить до этого дня будут помечены флагами  stretch-ignore или stretch-will-remove. За неделю до намеченного релиза (9 июня) все пакеты, помеченные флагом stretch-will-remove, будут удалены из репозитория, если в ветке Testing для них не будут предложены исправления критических проблем. Начиная с 9 июня ветка Testing будет полностью заморожена от внесения изменений (исключение делается только для экстренных вмешательств)

URL: https://lists.debian.org/debian-devel-announce/2017/05/msg00...
Новость: http://www.opennet.ru/opennews/art.shtml?num=46606


Содержание

Сообщения в этом обсуждении
"Релиз Debian 9.0 Stretch намечен на 17 июня"
Отправлено Аноним , 27-Май-17 09:09 
Праздник!Вкатываю его сейчас на пролиант. Как раз к релизу заработает на боевом месте.

"Релиз Debian 9.0 Stretch намечен на 17 июня"
Отправлено Меломан1 , 27-Май-17 10:11 
> Праздник!

Через 3 месяца релизнется CentOS 7.4 - будет настоящий праздник. Network Bound Disk Encryption, RAID Takeover и много-много обновлений и нового полезного функционала.
В то время когда дебианщики готовы половину обновлений выкинуть лишь бы как-нибудь слатать релиз.



"Релиз Debian 9.0 Stretch намечен на 17 июня"
Отправлено Аноним , 27-Май-17 10:35 
После выхода свежей версии CentOS тяну месяц-другой с обновлением,и всё равно непременно что-нибудь отваливается. Debian обновляю, не дожидаясь релиза, через некоторое время после заморозки, и как правило всё работает. Такая вот обратная (а кому и лицевая) сторона медали.

"Релиз Debian 9.0 Stretch намечен на 17 июня"
Отправлено _ , 30-Май-17 17:21 
Так было до 8-ки с систымдым. Это был первый за всю жизнь демьян который сам не перешел, ваааще анатендед, на новую версию. Пришлось засучить и белыми ручентками :-(
Будем посмотреть что выйдет с 9-кой. Надеюсь вылижут как это было в преждние ...

"Релиз Debian 9.0 Stretch намечен на 17 июня"
Отправлено Andrey Mitrofanov , 30-Май-17 17:51 
> Так было до 8-ки с систымдым. Это был первый за всю жизнь
> демьян который сам не перешел, ваааще анатендед, на новую версию.

Никакого "анатендед" и "ваще сам" у них никогда не было.

У вас - могабыть, а у них -- отдельная глава про Upgrading в ... то ли R.N., то ли в U.M., навскидку не помню сейчас. С пошаговыми "делай раз", "делай два" и приглащениями писать письма-баги, ежели что не так. И бэкапами -- обязательно в рекомендациях == "мы в домике".

//Disclosure: Здесь wheezy 7.11 + LTS. Уверен, что в 8+ это не поменялось.


"Релиз Debian 9.0 Stretch намечен на 17 июня"
Отправлено _ , 30-Май-17 17:23 
>Через 3 месяца релизнется CentOS 7.4

... и перечислил фичи ядра :-)
Ну я возьму из бэк-портов такую же версию - и у меня все эти фишки будут :-р


"Релиз Debian 9.0 Stretch намечен на 17 июня"
Отправлено Аноним , 27-Май-17 12:08 
> Вкатываю его сейчас на пролиант

Удачи
https://bugs.debian.org/cgi-bin/bugreport.cgi?archive=no&bug...
> failed to boot in HP Proliant DL380 G5, but previous kernel does boot

 


"Релиз Debian 9.0 Stretch намечен на 17 июня"
Отправлено Аноним , 27-Май-17 21:29 
>> Вкатываю его сейчас на пролиант
> Удачи
> https://bugs.debian.org/cgi-bin/bugreport.cgi?archive=no&bug...
>> failed to boot in HP Proliant DL380 G5, but previous kernel does boot
>  

Всё как по маслу. У меня ген9 580.


"Релиз Debian 9.0 Stretch намечен на 17 июня"
Отправлено _ , 30-Май-17 17:27 
Не расстраивайся! Бедность - не порок! (С) Теллер в одном швейцарском банке :)

"Релиз Debian 9.0 Stretch намечен на 17 июня"
Отправлено бедный буратино , 27-Май-17 11:09 
на моём основном компьютере - ниработаит. так что или обновлю всё, кроме ядра (останусь на 3.16), или буду искать другое ядро.

сначала не работало, пока не заблеклистишь звук, а теперь не работает видео, если не уберёшь kms, и тогда можно только сидеть в консоли 80x25


"Релиз Debian 9.0 Stretch намечен на 17 июня"
Отправлено Аноним , 27-Май-17 11:34 
Основной - Пентиум?
Может пришло время что то менять?

"Релиз Debian 9.0 Stretch намечен на 17 июня"
Отправлено бедный буратино , 27-Май-17 12:09 
такой, какой мне более удобен, тот и основной

работает, меня устраивает. а вот новое ядро почему-то не устраивает. значит, основной ОС там будет не Debian, а OpenBSD. а Debian 8, который будет ещё поддерживаться в рамках LTS, будет на случай, когда понадобится kvm/virtualbox или флеш-видео


"Релиз Debian 9.0 Stretch намечен на 17 июня"
Отправлено Аноним , 27-Май-17 20:26 
man reportbug

"Релиз Debian 9.0 Stretch намечен на 17 июня"
Отправлено ryoken , 29-Май-17 07:44 
> на моём основном компьютере - ниработаит. так что или обновлю всё, кроме
> ядра (останусь на 3.16), или буду искать другое ядро.

(aptosid или liquorix в помощь)


"Релиз Debian 9.0 Stretch намечен на 17 июня"
Отправлено Аноним , 27-Май-17 11:49 
Пока не понял в чём проблема, но в новой версии systemd перестало работать оповещение о старте процесса через systemd-notify --ready (ну и пробовал READY=1 через socat в bash, и вариант через python).

У процесса Type=notify, NotifyAccess=all. Переменную окружения с путём к сокету проверял, передаёся. Но из дочернего процесса сообщение через сокет не приходит, похоже. При этом в списке дочерних процессов по команде статуса дочерний процесс значится. Сервис завершается по таймауту. При этом сама команда systemd-notify --ready успешно завершается, что очень удивляет. Но если запустить службу заново, то всё работает.

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


"Релиз Debian 9.0 Stretch намечен на 17 июня"
Отправлено danonimous , 27-Май-17 14:06 
Переходи на Devuan - там нет этих проблем.

"Релиз Debian 9.0 Stretch намечен на 17 июня"
Отправлено Аноним , 27-Май-17 16:09 
Вообще, достаточно бессмысленные советы. Чтобы реализовать то же самое на скриптах bash мне понадобилось бы гораздо больше времени и строчек кода. Как минимум мне самому пришлось бы реализовывать межпроцессное взаимодействие для распараллеленной загрузки моих служб по событийной модели. Мне и так хватает этого в коде на Си. И если с парой-тройках служб это ещё можно сделать без автоматизации, то с 10-ю мне пришлось бы уже сильно поднапрячься и реализовывать свою систему загрузки с зависимостями. Ну и зачем мне это, если такую систему уже изобрели до меня? Меньше времени уж тогда займёт, разобраться с исходниками, сделать и отправить патч, если там есть ошибка. Я понимаю, что это деление на за и против - вроде субкультур, но тут дела программистов. Если для обычного человека при переходе на двухядерный процессор с меньшей частотой всё просто стало работать медленнее, то программист знает, что на тот момент разработчики ПО просто не заморачивались на многопоточность. Это просто аналогия, но, думаю, вы поняли идею.

"Релиз Debian 9.0 Stretch намечен на 17 июня"
Отправлено freehck , 27-Май-17 17:42 
> Чтобы реализовать то же самое на скриптах bash мне понадобилось бы гораздо больше времени и строчек кода.
> (ну и пробовал READY=1 через socat в bash, и вариант через python).

socat-то конечно "проще", чем netstat -nxp | grep ...

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

LSB-заголовки в run-скриптах init.d обеспечивают загрузку по зависимостям.


"Релиз Debian 9.0 Stretch намечен на 17 июня"
Отправлено Аноним , 27-Май-17 19:03 
Система зависимостей предполагает оповещение о том, что процесс проинициализировался (например, сервер проинициализировал сокет к нему можно подключаться), а не просто запустился. Не успел столкнуться в с этим в SysV, но может расскажете, как там процесс оповещает о том, что он готов? У systemd описание unit-файлов в этом плане достаточно простым и понятным оказалось. Есть, конечно много спорных моментов, но в целом пригодно к использованию.

"Релиз Debian 9.0 Stretch намечен на 17 июня"
Отправлено Аноним , 27-Май-17 20:36 
> Система зависимостей предполагает оповещение о том, что процесс проинициализировался
> (например, сервер проинициализировал сокет к нему можно подключаться), а не просто
> запустился. Не успел столкнуться в с этим в SysV, но может
> расскажете, как там процесс оповещает о том, что он готов? У
> systemd описание unit-файлов в этом плане достаточно простым и понятным оказалось.
> Есть, конечно много спорных моментов, но в целом пригодно к использованию.

Если есть зависимость от сокета, решается вбиванием перед запуском костыля типа

while ! [ -S "$SOCKET" ]; do sleep 1; done

Но на самом деле ситуация довольно редкая. Большинство демонов пытаются подключиться к сокету не сразу при запуске, а только когда возникает необходимость, и если им это не удалось — спокойно переподключаются позднее. Если там наколенная поделка — лучше её допилить, чтобы она вела себя именно так, даже при использовании systemd.


"Релиз Debian 9.0 Stretch намечен на 17 июня"
Отправлено Аноним , 27-Май-17 22:16 
Большая часть межпроцессного взаимодействия в Линуксе построена на сокетах (unix-). Если есть зависимость, значит она вероятнее всего будет связана с запуском сервера. Костыли со sleep - это бред. Допускаются только блокирующиеся операции. Полагаю, что большая часть ПО в дистрибутиве будет использовать сокеты. Самый простой пример - Иксы. Другой пример - d-bus. И как думаете, что будет, если сначала стартануть Иксы, а затем openbox? openbox попытается подключиться к иксам, которые ещё не успели начать прослушивать unix-сокет. Конечно, в дистрибутивах так не делают (openbox скорее всего будет просто дочерним процессом для иксов), это вполне допустимая ситуация.

"Релиз Debian 9.0 Stretch намечен на 17 июня"
Отправлено Аноним , 27-Май-17 23:04 
И как же, по-Вашему, все жили без systemd?
Недоступность сокета — это рядовая ситуация, а не фатальная ошибка, особенно если учесть, что сокет может быть не только локальным, но и сетевым. Все демоны (именно демоны, запускаемых руками клиентских приложений это не касается) должны уметь обрабатывать такую ситуацию.

"Релиз Debian 9.0 Stretch намечен на 17 июня"
Отправлено Аноним , 28-Май-17 08:42 
Может приведёте хотя бы один пример? Я по опыту не помню подобных ситуаций. Обычно  просто делается завершение работы и всё.

"Релиз Debian 9.0 Stretch намечен на 17 июня"
Отправлено Аноним , 28-Май-17 12:03 
Приведите пример того, что завершается.

"Релиз Debian 9.0 Stretch намечен на 17 июня"
Отправлено Аноним , 28-Май-17 15:16 
openbox, x11vnc, zenity и скорее всего любое графическое приложение, если сокет иксов не создан. Это из того, с чем сталкивался на своём опыте.

Другой пример, посерьёзнее. Что будет, если прокси-сервер nginx стартанёт после сервера bind9, в котором локальная доменная зона, указанная в конфигурации nginx?

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


"Релиз Debian 9.0 Stretch намечен на 17 июня"
Отправлено Аноним , 28-Май-17 18:36 
> openbox, x11vnc, zenity и скорее всего любое графическое приложение, если сокет иксов не создан

А что системде уже и их сам запускает? Вообще это совершенно не дело системы инициализации. Я, повторюсь, писал про

>> именно демоны, запускаемых руками клиентских приложений это не касается
> Что будет, если прокси-сервер nginx стартанёт после сервера bind9, в котором локальная доменная зона, указанная в конфигурации nginx?

Думаю, выдаст на пришедший в этот момент запрос 502, после поднятия бинда заработает нормально. Разве не так?

> попробуйте запустить какой-нибудь сервис, работающий через dbus, а только потом запустите сам dbus

Много ли системных сервисов используют dbus, кроме системде? Я ни одного не припоминаю, так что сделать этого, увы, не смогу.


"Релиз Debian 9.0 Stretch намечен на 17 июня"
Отправлено Аноним , 28-Май-17 21:09 
> Думаю, выдаст на пришедший в этот момент запрос 502, после поднятия бинда заработает нормально. Разве не так?

Ну, вы так думаете из-за того, что не знаете, как работает ДНС и как делается обработка ошибок в ПО (lazy). nginx в Debian 7 делает запрос ip-адреса, чтобы начать прослушивание. Но т.к. адреса нет просто завершается по ошибке. И сюрприз, сайт лежит. Но достаточно его стартануть опять, как он снова работает. И не каждый сисадмин догадается в чём дело. А проблема проявлялась, когда сервер DNS включали после того, как включали сервер, на котором nginx был в роли прокси-сервера. Обычное состояние гонки. Даже не обязательно, чтобы это были зависимости процессов, проблема может быть даже на разных компьютерах.

Но да, есть ПО, которое корректно обрабатывает такие ситуации. Например, openvpn.

> Много ли системных сервисов используют dbus, кроме системде? Я ни одного не припоминаю, так что сделать этого, увы, не смогу.

Хм. Убейте демон dbus и попробуйте сделать что-нибудь через NetworkManager. ;)


"Релиз Debian 9.0 Stretch намечен на 17 июня"
Отправлено Аноним , 28-Май-17 12:06 
Просто вот даже растерялся как-то, всё тупо работает, и никогда не задумывался, что там с сокетами на момент запуска... Ну скажем nginx и не подумает завершаться, если не достучится до сокета какого-нибудь php-fpm.

"Релиз Debian 9.0 Stretch намечен на 17 июня"
Отправлено Аноним , 27-Май-17 22:23 
>> Чтобы реализовать то же самое на скриптах bash мне понадобилось бы гораздо больше времени и строчек кода.
>> (ну и пробовал READY=1 через socat в bash, и вариант через python).
> socat-то конечно "проще", чем netstat -nxp | grep ...

Сначала не обратил внимания, причём тут netstat вообще? Название сокета в переменной окружения есть. Права доступа я могу через консоль посмотреть.


"Релиз Debian 9.0 Stretch намечен на 17 июня"
Отправлено freehck , 29-Май-17 16:29 
>>> Чтобы реализовать то же самое на скриптах bash мне понадобилось бы гораздо больше времени и строчек кода.
>>> (ну и пробовал READY=1 через socat в bash, и вариант через python).
>> socat-то конечно "проще", чем netstat -nxp | grep ...
> Сначала не обратил внимания, причём тут netstat вообще?
> Название сокета в переменной окружения есть.
> Права доступа я могу через консоль посмотреть.

Соображений тут много. Начнём с того, что файл unix-сокета может уже быть, но его не обязательно слушают. Проверяется легко: между bind() и listen() вставьте usleep в тысячу секунд. (Это я пишу для комментаторов выше, которые рекомендуют [ -S "$socket" ] в цикле).

Я берусь утверждать, что socat использовать для проверки сокета хуже по причине того, что он в обязательном порядке пытается что-либо послать, то есть непосредственно устанавливает соединение. В то же время netstat проверяет состояние сокета без установки соединения.

Вот Вы посылаете, как я понял, строку "READY=1" через socat. Откуда нам знать, что демон на той стороне корректно реагирует на это сообщение? Если уж использовать socat, то я бы воздержался от посылки чего бы там ни было, ограничившись чем-то вроде echo -n | socat - UNIX-CLIENT:/tmp/checker.socket

Это безопаснее, хотя и не лишено недостатков: что, если демон при отсутствии ввода после установки соединения зависает? Мне вот когда-то такой демон попадался. Давно, правда, дело было, я уже не вспомню название. Но такое бывает.

Посему во избежание проблем всё-таки правильнее имхо использовать netstat, грепая по имени сокета и слову LISTEN. Этот вариант безопасен и не вызывает проблем от слова совсем: грепнуть вывод netstat гораздо проще, чем разгребать возможные проблемы, связанные с использованием socat.


"Релиз Debian 9.0 Stretch намечен на 17 июня"
Отправлено Аноним , 29-Май-17 19:42 
socat был необходим лишь для эксперимента, чтобы убедиться, что данные в сокет вообще уходят. То, что они приходят к демону понятно и так, т.к. не было возвращено ошибок. Соответственно на стороне сервера была исполнена read().

Вообщем, обходной путь найден, но в systemd ошибка присутствует. systemd-notify абсолютно неработоспособна. Пока могу предполагать, что проблема из-за того, что systemd пытается определить принадлежность к cgroups по PID. Но делает это после того, как сообщение было получено. Соответственно, процесс уже завершился, а сообщение игнорируется, т.к. невозможно было определить cgroup. Идея интересная, - один сокет на все процессы, но реализация, похоже, неграмотная. Я бы в протокол добавил обязательно ожидание подтверждения от демона того, что сообщение получено. Блокирующийся read() не дал бы процессу завершиться и можно было бы определить его cgroup. Но как именно там реализовано пока не знаю.

Обходной путь - переписать скрипт c bash на python и использовать systemd.daemon.notify('READY=1'). Пока устраивает.

Отчёт об ошибке отправлен в Debian. Сам я пытался найти место, где происходит приём сообщений, но пока не нашёл. Код там нельзя назвать интуитивно понятным. Нашёл функцию, которая определяет cgroup по PID, но по её вызовам не нашёл абсолютно ничего полезного. Даже по слову READY я не смог найти место, где данная строка обрабатывается.


"Релиз Debian 9.0 Stretch намечен на 17 июня"
Отправлено Аноним , 29-Май-17 19:55 
Учитывая, что тут любят придираться к мелочам, поправлю себя и уточню: read(), либо же recv().

"Релиз Debian 9.0 Stretch намечен на 17 июня"
Отправлено Аноним , 27-Май-17 11:51 
автомонтирование флешек работает? В jessie сломали.

"Релиз Debian 9.0 Stretch намечен на 17 июня"
Отправлено Аноним , 27-Май-17 12:03 
Не подтверждаю. Jessie, KDE, systemd, все работает.

"Релиз Debian 9.0 Stretch намечен на 17 июня"
Отправлено бедный буратино , 27-Май-17 12:10 
> автомонтирование флешек работает? В jessie сломали.

зато wget починили - а то у них была фирменная фишка в чётных версиях ломать wget - так было и в squeeze и в jessie


"Релиз Debian 9.0 Stretch намечен на 17 июня"
Отправлено Аноним , 27-Май-17 15:54 
а прогрессбар при скачивание в несколько строчек?

"Релиз Debian 9.0 Stretch намечен на 17 июня"
Отправлено бедный буратино , 27-Май-17 16:41 
> а прогрессбар при скачивание в несколько строчек?

в том-то и дело, что починили :)


"Релиз Debian 9.0 Stretch намечен на 17 июня"
Отправлено Аноним , 27-Май-17 20:39 
> автомонтирование флешек работает? В jessie сломали.

Не то чтобы совсем сломали, но без systemd не работало. Полагаю, что не работает по-прежнему. Починить можно только пересборкой policykit без systemd или переходом на devuan.


"Релиз Debian 9.0 Stretch намечен на 17 июня"
Отправлено Аноним , 27-Май-17 13:18 
Есть ли смысл переходить с Devuan? Есть ли значительные преимущества?

"Релиз Debian 9.0 Stretch намечен на 17 июня"
Отправлено Отражение луны , 27-Май-17 13:25 
- 10 к интеллекту
+ 25% лайков на опеннете
Активная способность: рассказать всем как сильно ты ненавидишь systemd. Возможно использовать когда всем окружающим на$рать.

"Релиз Debian 9.0 Stretch намечен на 17 июня"
Отправлено Аноним , 27-Май-17 14:29 
>> смысл переходить с Devuan?
> - 10 к интеллекту

Т.е. использование системДы делает глупее. Что-то такое я подозревал.
> + 25% лайков на опеннете

Засилье фанатов Лёни на опеннете трудно отрицать.
> Активная способность: рассказать всем как сильно ты ненавидишь systemd.

Т.е. у системдышнеков наклонности мазохистов или же просто некоторые психологические отклонения, типа раздвоения личности? Спасибо за откровения, буду и далее держаться от них подальше!



"Релиз Debian 9.0 Stretch намечен на 17 июня"
Отправлено username , 27-Май-17 15:01 
Интересно чтобы он сказал про переход на runit. Наверное минус 90 к интеллекту.

"Релиз Debian 9.0 Stretch намечен на 17 июня"
Отправлено Аноним , 27-Май-17 20:12 
*что бы

"Релиз Debian 9.0 Stretch намечен на 17 июня"
Отправлено Отражение луны , 27-Май-17 16:30 
Ты не уловил суть) Системд хейтеры играются со своими девуанами, а затем переходят на настоящие дистрибутивы, засирая при этом все новости постами о том, как они этим недовольны)

"Релиз Debian 9.0 Stretch намечен на 17 июня"
Отправлено Аноним , 27-Май-17 14:00 
Если Вас не волнует скорость загрузки системы, не интересуют новые версии ПО, и Вы не занимаетесь администрированием, - то нет, никакого смысла  переходить нет.

"Релиз Debian 9.0 Stretch намечен на 17 июня"
Отправлено Аноним , 27-Май-17 14:48 
> Если Вас не волнует скорость загрузки системы,

Это вот так, да?
https://www.youtube.com/watch?v=hx30Z7_G-vk
> archbang - systemd vs openRC (speed load sytem)

да не расстраивайтесь вы, ваш любимый системд только немного медленне ... хотя да, он же вроде вначале пропихивался именно под таким соусом - обеспечить быструю загрузку. Получается, Рыжий в Красной Шляпочке вас немножечко на***л, да? =)

> не интересуют новые версии ПО,

Про новые версии ПО - это конечно мечта всех Истинно Верующих Последователей Рыжего, но пока что еще далеко не всем сумели запихнуть свою привязку, хотя стараются, да:
https://github.com/tmux/tmux/issues/428
> With systemd 230 we switched to a default in which user processes started as part of a
> login session are terminated when the session exists (KillUserProcesses=yes).
> []
> Unfortunately this means starting tmux in the usual way is not effective, because it will
> be killed upon logout. There are a few option to avoid that, the best being:
> systemd-run --scope --user tmux
> This starts tmux as a scope unit under the systemd --user instance.
> It would be great if tmux could do this automatically. Probably the best way to do this would be to make the
> dbus call to org.freedesktop.systemd1.Manager.StartTransientUnit directly from tmux. See

скромно, ага. «мы тут подумали и Леннарт Неповторимый решил, что пора немного cломать поведение демонов, немогли бы вы вставить костыль в свою программу, чтобы мы могли и далее делать вид, что все в порядке?»
А вот что ответил автор тмукса:
> My concern is that we have a little function, daemon(), that does a simple little procedure to make
> a daemon that has worked basically unchanged across multiple platforms for maybe, what, 30 years?
> Now to do the same thing we need to add 150 lines of new, Linux-only code AND a library dependency.

Ответил без должного почтения, да еще и отказом. Нехорошо то как!


"Релиз Debian 9.0 Stretch намечен на 17 июня"
Отправлено Аноним , 27-Май-17 16:20 
> speaking as the Debian maintainer I'm okay with adding a dependency on libsystemd to the package

очешуеть


"Релиз Debian 9.0 Stretch намечен на 17 июня"
Отправлено Аноним , 27-Май-17 18:05 
>> speaking as the Debian maintainer I'm okay with adding a dependency on libsystemd to the package
> очешуеть

Это проблемы мейнтейнера. Однако от автора требуют встроить поддержку дбаса. Причем, в лучших традициях этой наглой братии - не присылая хотя бы полусырой патч, нет:
> It would be great if tmux could do this automatically.
> Probably the best way to do this would be to make the dbus call to
> org.freedesktop.systemd1.Manager.StartTransientUnit directly from tmux. See
> https://github.com/systemd/systemd/blob/master/src/run/run.c... for how systemd-run
> does it, and https://www.freedesktop.org/wiki/Software/systemd/dbus/ for the description of the API.

т.е. вот так мы делаем в системде, вот АПИ, вперед и с песней.


"Релиз Debian 9.0 Stretch намечен на 17 июня"
Отправлено eleksir , 28-Май-17 16:44 
Ну, да, теперь они прут внаглую: мы апстрим и будь нам благодарен, что тебя с твоим г. не только заметили, но и указали на _твою_ недоработку (несовместимость с нашим божественным сисд!) и, да, наши гайдлайны (читай "скрижали") включают в себя обязательную несовместимость с остальными ОС, и ежеполугодичные ломания API, чтобы разработчикам не было скучно. Так что взял свой код и БЫСТРО ИСПРАВИЛ, ЯСНО?!! это _приказ_!

Примерно так. Уважение? нет! скажите "спасибо", что вас матами не обложили.

А что касается dbus и зависимости на libsystemd так это... извиняйте, _дань прогрессу_

Вполне себе нормальный подход фанбоев от разработчиков сисд. Это не значит, что этих фанбоев не надо ногами по морде бить за умышленный саботаж на уровне экосистмы OpenSource. Но для этих убл*дков есть свой котёл по ту сторону добра и зла...


"Релиз Debian 9.0 Stretch намечен на 17 июня"
Отправлено Аноним , 27-Май-17 16:14 
> в связи с чем запущена инициатива по проведению в этот день мероприятий, приуроченных к выходу Debian 9.0.

Столы накрывать будут?


"Релиз Debian 9.0 Stretch намечен на 17 июня"
Отправлено Аноним , 27-Май-17 20:32 
Ubuntu уже свой "фирменный" накрыла.

"Релиз Debian 9.0 Stretch намечен на 17 июня"
Отправлено Аноним , 27-Май-17 16:47 
Поздно, Devuan уже вышел.

"Релиз Debian 9.0 Stretch намечен на 17 июня"
Отправлено Аноним , 27-Май-17 17:32 
У меня опять шаблон рвётся:
- будет готово как только будет готово
- всё что не будет готово к 9 июня будет удалено

Одно из этих утверждений насквозь лживо.


"Релиз Debian 9.0 Stretch намечен на 17 июня"
Отправлено Аноним , 27-Май-17 20:20 
Вот оно и будет готово, как только всё что не готово, будет удалено.

"Релиз Debian 9.0 Stretch намечен на 17 июня"
Отправлено efimius , 27-Май-17 20:46 
Стоит сейчас на ноут вместо убунты ставить? Или лучше арч?

Все равно собираюсь на ssd пережать


"Релиз Debian 9.0 Stretch намечен на 17 июня"
Отправлено Аноним , 28-Май-17 08:37 
Сиди на 14й убунте и разбирайся с гентой.

"Релиз Debian 9.0 Stretch намечен на 17 июня"
Отправлено efim , 01-Июн-17 01:57 
была 16ю04 теперь арч

"Релиз Debian 9.0 Stretch намечен на 17 июня"
Отправлено Аноним , 28-Май-17 23:05 
> Все равно собираюсь на ssd пережать

Лучше используй "не ssd, а что-то человеческое"(с) опнет.



"Релиз Debian 9.0 Stretch намечен на 17 июня"
Отправлено Аноним , 30-Май-17 20:24 
systemd когда выпилят тогда и праздновать будем!

"Релиз Debian 9.0 Stretch намечен на 17 июня"
Отправлено efim , 01-Июн-17 01:55 
поздно на arch уже