/var/db/freebsd-update

Alex Korchmar написал(а) к Eugene Grosbein в May 18 15:09:31 по местному времени:

From: Alex Korchmar <noreply@linux.e-moe.ru>

Eugene Grosbein <Eugene.Grosbein@f1.n5006.z2.fidonet.org> wrote:

EG> А я проапгрейдился уже достаточное время назад и не страдаю никак
EG> от нового кода, причем ради тестирования даже прикрутил специально
EG> обновление микрокода, проверил, что в CPU появилась поддержка IBRS
EG> и включил её использования - и всё норм. А ты патчи дальше.
у меня freebsd, видимо, навсегда уже ограничена в применении виртуалками,
поскольку попытки выяснить, можно ли ее применять для чего-то большего
мы только что успешно завершили с резюме - "ничего нормально не работает,
не поддерживается, и не будет".
В vm все эти мертвому припарки вообще феерически бесполезны, а изоляцию
приложений мне обеспечит хост, насколько сможет. У него хотя бы page tables
для разных vm принципиально разные.

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

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

Периодически апстрим ломает все подряд и нужен ручной merge.

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

> Alex

--- ifmail v.2.15dev5.4

Alex Korchmar написал(а) к Slawa Olhovchenkov в May 18 15:19:01 по местному времени:

From: Alex Korchmar <noreply@linux.e-moe.ru>

Slawa Olhovchenkov <Slawa.Olhovchenkov@f500.n5030.z2.fidonet.org> wrote:

SO> это их сначала надо изолировать, а я так не делал.
для современных vcs необходимо и достаточно не коммитить за один раз две
перпендикулярные правки. (ну и надписывать в commit message к какой
проблеме относится, чтоб не искать потом)
Если нечаянно засосало лишнего, последний комит всегда можно переделать и
разбить на два.

SO> и потом, в процессе, эту изоляцию надо поддерживать.
не надо, современные vcs позаботятся наковырять при необходимости только
один из нужных наборов для отдачи публике.

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

В сторону: попробовать что-ли на git-svn мигрировать? Хотя, сдаецца
мне, там своих грабель будет полное поле, как раз из-за неиспользования
его никем из причастнных к разработке.
Шансы что мне поможет svk я оцениваю как нулевые, да и перла у меня нигде уже
нет.

> Alex

--- ifmail v.2.15dev5.4

Slawa Olhovchenkov написал(а) к Alex Korchmar в May 18 15:57:00 по местному времени:

Нello Alex!

07 May 18, Alex Korchmar writes to Slawa Olhovchenkov:

SO>> это их сначала надо изолировать, а я так не делал.
AK> для современных vcs необходимо и достаточно не коммитить за один раз две
AK> перпендикулярные правки. (ну и надписывать в commit message к какой
AK> проблеме относится, чтоб не искать потом)

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

AK> Если нечаянно засосало лишнего, последний комит всегда можно
AK> переделать и разбить на два.

а как ты определишь, что лишнего?

SO>> и потом, в процессе, эту изоляцию надо поддерживать.
AK> не надо, современные vcs позаботятся наковырять при необходимости только
AK> один из нужных наборов для отдачи публике.

у него что, интилект? вот с хуяли?

в моем дереве есть zonecache_bucket(uma_zone_t zone, uma_buckett bucket, bool ws) в основном -- нет.
мне у себя надо сн ним работать, в основном -- нет.
при этом zonecachebucket добавляется не моим патчем, а работа с ним идет поим патчем.

... В жизни все не так, как на самом деле.
--- GoldED+/BSD 1.1.5-b20110223-b20110223

Alex Korchmar написал(а) к Slawa Olhovchenkov в May 18 17:08:04 по местному времени:

From: Alex Korchmar <noreply@linux.e-moe.ru>

Slawa Olhovchenkov <Slawa.Olhovchenkov@f500.n5030.z2.fidonet.org> wrote:

AK>> для современных vcs необходимо и достаточно не коммитить за один раз две
AK>> перпендикулярные правки. (ну и надписывать в commit message к какой
AK>> проблеме относится, чтоб не искать потом)
SO> ну вот я такое уже не делал. мне сначала дали патчи для UMA, потом я стал
ну а как бы ты это делал с svn?
С гитом или hg понятно - дали патч - commit (надо же где-то держать его
историю, да и undelete пригодится). Написал патч для arc - commit.
(их может быть не один и перекрывающиеся - сегодня ковыряем одно, завтра
другое). Апстрим что-то поломал, ты смержил - commit.
А дальше - git-cherry-pick.

SO> а потом пошли апстримовые правки для ARC, которые у меня вообще
SO> отсутсвуют -- я не обновляю сырцы, а в публику их надо учитывать.
а вот для этого есть rebase ;-)
Причем твоя версия никуда от этого не девается, и даже еще недоделанные
незакоммиченные правки можно отодвинуть в сторону, пока возишься с публикацией
патча, а потом вернуть как было.

SO> а как ты определишь, что лишнего?
глазами. ты ему commit... ой, вон тот файл был не про это и вообще я еще в нем
не доделал - откатываешь обратно, и второй раз делаешь уже аккуратнее.
Поскольку это твой локальный repo, не имеющий никакой жесткой привязки к
апстриму, подобные фокусы ничего тебе не стоят, а история сохраняется.

AK>> не надо, современные vcs позаботятся наковырять при необходимости только
AK>> один из нужных наборов для отдачи публике.
SO> у него что, интилект? вот с хуяли?
ну не то чтоб совсем интеллект, но оно немножко поумнее обычного (и тем более
устаревшего bsd'шного) diff/patch, поскольку сравнивает не твою на два года
устаревшую версию с текущей, а знает всю историю за это время.

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

в общем, добро пожаловать в мир распределенных vcs и параллельной разработки,
только вот лапти в виде svn оставлять при входе.

> Alex

--- ifmail v.2.15dev5.4

Eugene Grosbein написал(а) к Alex Korchmar в May 18 22:08:41 по местному времени:

07 мая 2018, понедельник, в 13:09 NOVT, Alex Korchmar написал(а):

EG>> А я проапгрейдился уже достаточное время назад и не страдаю никак
EG>> от нового кода, причем ради тестирования даже прикрутил специально
EG>> обновление микрокода, проверил, что в CPU появилась поддержка IBRS
EG>> и включил её использования - и всё норм. А ты патчи дальше.
AK> у меня freebsd, видимо, навсегда уже ограничена в применении виртуалками,

А тогда тебе тем более не надо ничего выкорчевывать.

AK> поскольку попытки выяснить, можно ли ее применять для чего-то большего
AK> мы только что успешно завершили с резюме - "ничего нормально не работает,
AK> не поддерживается, и не будет".

Ничего из того, что нужно тебе. Внезапно, другим нужно другое.

EG>> Я не понимаю сути проблемы, и соответственно, вопроса.
AK> у тебя есть пять патчей, два из которых ты все еще надеешься пропихнуть
AK> в апстрим, на один уже нет надежды и два нужны только тебе лично.
AK> У каждого из них своя история, продолжающаяся не один год, но иногда они
AK> патчат пусть и в разных местах, одни и те же файлы.
AK> Периодически апстрим ломает все подряд и нужен ручной merge.
AK> Как вытащить только второй набор патчей для раздачи окружающим, если на твоих
AK> системах применены все пять?

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

$ find sys-changes -type d
sys-changes
sys-changes/bsnmp-ucd
sys-changes/mpd
sys-changes/mpd/57
sys-changes/mpd/old
sys-changes/mpd/56
sys-changes/mpd/58
sys-changes/mpd/55
sys-changes/kernel
sys-changes/kernel/old
sys-changes/kernel/9
sys-changes/kernel/8
sys-changes/test
sys-changes/bsnmp-regex
sys-changes/system
sys-changes/system/dhclient
sys-changes/system/lock

$ find sys-changes -type d -maxdepth 1 | xargs -I ^ sh -c 'echo $(find ^ -type f | wc -l) ^'
75 sys-changes
1 sys-changes/bsnmp-ucd
29 sys-changes/mpd
24 sys-changes/kernel
4 sys-changes/test
1 sys-changes/bsnmp-regex
15 sys-changes/system

Обновление выполняется Makefile-ом:

d=/path/to/sys-changes

update:
cd /usr/src && \
svnlite cleanup && svnlite revert -R . && svnlite update && \
find $d/system -type f -name '*.diff' | sort | xargs cat |\
patch > /var/log/pw.log 2>&1

Eugene
--
Все любят естественный наркотик
--- slrn/1.0.2 (FreeBSD)

Slawa Olhovchenkov написал(а) к Alex Korchmar в May 18 18:01:00 по местному времени:

Нello Alex!

07 May 18, Alex Korchmar writes to Slawa Olhovchenkov:

AK>>> для современных vcs необходимо и достаточно не коммитить за один раз
AK>>> две перпендикулярные правки. (ну и надписывать в commit message к
AK>>> какой проблеме относится, чтоб не искать потом)
SO>> ну вот я такое уже не делал. мне сначала дали патчи для UMA, потом я
SO>> стал
AK> ну а как бы ты это делал с svn?

делал что? разделение нескольких веток и их одновременная поддержка (в данном случае их надо три, причем в одной из не просто косметические изменения, а другая логика)?
ты так и не рассказал как это делать с git/hg.
просто иметь свои правки в своем дереве? да так и иметь, просто отредактировав дерево.
svn up это автоматом учтет. ну пока конфликт не объявится.

SO>> а потом пошли апстримовые правки для ARC, которые у меня вообще
SO>> отсутсвуют -- я не обновляю сырцы, а в публику их надо учитывать.
AK> а вот для этого есть rebase ;-)
AK> Причем твоя версия никуда от этого не девается, и даже еще недоделанные
AK> незакоммиченные правки можно отодвинуть в сторону, пока возишься с
AK> публикацией патча, а потом вернуть как было.

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

SO>> а как ты определишь, что лишнего?
AK> глазами. ты ему commit... ой, вон тот файл был не про это и вообще я еще в
AK> нем не доделал - откатываешь обратно, и второй раз делаешь уже аккуратнее.
AK> Поскольку это твой локальный repo, не имеющий никакой жесткой привязки к
AK> апстриму, подобные фокусы ничего тебе не стоят, а история сохраняется.

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

AK>>> не надо, современные vcs позаботятся наковырять при необходимости
AK>>> только один из нужных наборов для отдачи публике.
SO>> у него что, интилект? вот с хуяли?
AK> ну не то чтоб совсем интеллект, но оно немножко поумнее обычного (и тем
AK> более устаревшего bsd'шного) diff/patch, поскольку сравнивает не твою на
AK> два года устаревшую версию с текущей, а знает всю историю за это время.

и чё? он сообразит что надо поменять kmemcache_reap_now на kmem_cache_reapsoon?

AK> в общем, добро пожаловать в мир распределенных vcs и параллельной
AK> разработки, только вот лапти в виде svn оставлять при входе.

пока это звучит как булшит.

... и пpодал он Хpиста за тpидцать у.е. ...
--- GoldED+/BSD 1.1.5-b20110223-b20110223

Alex Korchmar написал(а) к Eugene Grosbein в May 18 18:19:37 по местному времени:

From: Alex Korchmar <noreply@linux.e-moe.ru>

Eugene Grosbein <Eugene.Grosbein@f1.n5006.z2.fidonet.org> wrote:

AK>> у меня freebsd, видимо, навсегда уже ограничена в применении виртуалками,
EG> А тогда тебе тем более не надо ничего выкорчевывать.
оно a) опасное b) ненужное c) лишние тормоза на лишних проверках

EG> Ничего из того, что нужно тебе. Внезапно, другим нужно другое.
скорее всего окажется, что это другое гораздо лучше, быстрее и эффективнее
делают другие системы, а "другие" либо упертые фанатики, которым похрен на
эффективность, либо продолжают барахтаться по инерции.
Сколько-сколько проектов за последние десять лет избавились от freebsd?

EG> Я всё ещё не понимаю, зачем что-то "вытаскивать", оно в виде патчей
EG> так ведь и хранится всегда и при обновлении системы патчи применяются
EG> каждый раз на обновленные чистые исходники.
по одному. вручную. С риском что они пересекутся и не приложатся правильно.
Понятно. Скажи, а зачем вам вообще svn?

EG> find $d/system -type f -name '*.diff' | sort | xargs cat |\
EG> patch > /var/log/pw.log 2>&1
и что делать если он a) сфейлился b) пропатчил неправильно ?

и не вижу еще одного куска мэйкфайла - который все-все патчи
переделывает заново (и смотри не перепутай, какой где) - после решения этих
проблем, или просто чтобы вовремя учитывать сместившиеся строки, а не
упереться в то, что даже с -F3 оно уже не прикладывается, в один непрекрасный
день.

И вот так у них все. А я -то Линуса считал долбо..м-ниасилятором
ничего моднее "новая папка(24)"... но он-то еще в 2002м кое-чему
научился, пусть и криво-косо, и убеждать потребовалось четыре года.

А на дворе 18й...


> Alex

--- ifmail v.2.15dev5.4

Alex Korchmar написал(а) к Slawa Olhovchenkov в May 18 18:52:38 по местному времени:

From: Alex Korchmar <noreply@linux.e-moe.ru>

Slawa Olhovchenkov <Slawa.Olhovchenkov@f500.n5030.z2.fidonet.org> wrote:

SO>>> ну вот я такое уже не делал. мне сначала дали патчи для UMA, потом я
SO>>> стал
AK>> ну а как бы ты это делал с svn?
SO> делал что? разделение нескольких веток и их одновременная поддержка
ну да, ну да. Оно же другим способом не умеет ;-)

SO> ты так и не рассказал как это делать с git/hg. просто иметь свои правки
SO> в своем дереве?
в своем репо (он у них всегда "свой", с удаленным напрямую не работают),
а не просто в дереве. С историей, и возможностью вытащить отдельными наборами
независимые части.

SO> тьфу. ну причем тут вообще сраные сырцы и экономия места?
это не экономия места, это экономия твоего времени.

SO> у меня что, голова тоже ребэйз сделает?
это git за тебя сделает. Тебе об этом думать надо только в случае, когда
оно внезапно сломалось. Причем если делать регулярно - оно крайне маловероятно
"внезапно сломается".

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

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

ненене, ребята, я так не играю. Это просто какое-то п-цовое количество времени
впустую.

SO> и чё? он сообразит что надо поменять kmemcache_reapnow на
SO> kmemcache_reapsoon?
это придется самому сообразить, как и что делать с новообразовавшимся loop,
а вот вытаскивать самому из готового мегапатча три раздельных ручным
редактированием diff - не придется. И вручную разбираться, что за херня
там вокруг ifdef illumos налипла - тоже.

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

И никакой истории правок у меня на память не осталось - есть разные
версии самих патчей, но их сравнивать (diff diff'а) - бесполезно,
надо сравнивать два разных патченных дерева. Тоже ненужный геморрой.

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


> Alex

--- ifmail v.2.15dev5.4

Slawa Olhovchenkov написал(а) к Alex Korchmar в May 18 19:22:38 по местному времени:

Нello Alex!

07 May 18, Alex Korchmar writes to Slawa Olhovchenkov:

SO>>>> ну вот я такое уже не делал. мне сначала дали патчи для UMA, потом я
SO>>>> стал
AK>>> ну а как бы ты это делал с svn?
SO>> делал что? разделение нескольких веток и их одновременная поддержка
AK> ну да, ну да. Оно же другим способом не умеет ;-)

ты не изображай таинственное лицо, ты пальцем покажи.

SO>> ты так и не рассказал как это делать с git/hg. просто иметь свои
SO>> правки
SO>> в своем дереве?
AK> в своем репо (он у них всегда "свой", с удаленным напрямую не работают),
AK> а не просто в дереве. С историей, и возможностью вытащить отдельными
AK> наборами независимые части.

и чё? у меня никогда не было и не планировалось отдельными наборами независимые части.
ты специально это игнорируешь?

SO>> тьфу. ну причем тут вообще сраные сырцы и экономия места?
AK> это не экономия места, это экономия твоего времени.

rebase -- это экономия места.
а время как раз не экономит.

SO>> у меня что, голова тоже ребэйз сделает?
AK> это git за тебя сделает. Тебе об этом думать надо только в случае, когда
AK> оно внезапно сломалось. Причем если делать регулярно - оно крайне
AK> маловероятно "внезапно сломается".

сделает что? ребэйз в голове? чё за бред?

SO>> я этим занимаюсь раз в полгода и мне надо будет каждый раз вспоминать
SO>> в чем
AK> в результате твой патч уже вообще невозможно применять - и этим
AK> вспоминанием и реверсинжинирингом занимаются все индивидуально. Вместо того
AK> чтобы сделать pull.

беда! но гит тут не причем.

SO>> а. типа патч не наложился. только это не про меня.
SO>> у меня патчи надожатся, а вот компилироваться не будет.
SO>> или будет компилироваться, а работать будет не так, как ожидалось.
SO>> т.е. мне как минимум надо тестовую сборку пускать и иметь ресурсы под
SO>> неё.
AK> есть ресурсы - пускаешь, нет - сделает кто-нибудь кому оно надо - но не

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

SO>> и чё? он сообразит что надо поменять kmemcache_reapnow на
SO>> kmemcache_reapsoon?
AK> это придется самому сообразить, как и что делать с новообразовавшимся loop,

вообще то кроме этой проблемы других нет. то, про что ты пишешь ниже, реально это вот это же самое: надо самому сообразить.

AK> У меня вот оно протестировано и вроде работает - а пользы тебе от
AK> этого ровно ноль, я тебе отдать ничего не могу, потому что хер с pti,
AK> это другие файлы, а дерингеровский код я заманаюсь теперь добывать
AK> оттуда.

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

AK> В общем, настоятельно рекомендую, при случае, освоить сраный git
AK> (не на фре, а на каком-нибудь другом проекте, либо с нуля, либо уже
AK> его использующем).

не убедил.
у меня с svn все хорошо получается, когда исходно делаешь current->relsese->stable и фичи через current заводишь.

... И вновь я не замечен Plug-n-Play'ем...
--- GoldED+/BSD 1.1.5-b20110223-b20110223

Alex Korchmar написал(а) к Slawa Olhovchenkov в May 18 20:35:41 по местному времени:

From: Alex Korchmar <noreply@linux.e-moe.ru>

Slawa Olhovchenkov <Slawa.Olhovchenkov@f500.n5030.z2.fidonet.org> wrote:

AK>>>> ну а как бы ты это делал с svn?
SO>>> делал что? разделение нескольких веток и их одновременная поддержка
AK>> ну да, ну да. Оно же другим способом не умеет ;-)
SO> ты не изображай таинственное лицо, ты пальцем покажи.
ну я говорю - не умеет этого svn, не для того придуман.

SO> и чё? у меня никогда не было и не планировалось отдельными
SO> наборами независимые части.
для тебя на твоем локалхосте это будут просто последовательные комиты.
патчи из них делаются специально для экспорта, а не история хранится в виде
патчей к патчам, как нам продемонстрировал Женя.

SO> беда! но гит тут не причем.
причем. У тебя нет никакой возможности другим способом нормально вести
работу с проектом, где апстрим - не ты.

SO> нихуя. на ревью надо все же компилирующийся патч.
нам до ревью пока как до берлина раком. а патча уже год как нет никакого.

SO> вообще то кроме этой проблемы других нет
это проблема времени.

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

SO> у меня с svn все хорошо получается, когда исходно делаешь
SO> current->relsese->stable и фичи через current заводишь.
это когда проект твой. А тут проект чужой, со своими current/release, тут
этот метод не работает.
Ну и лазить каждый раз в current когда на самом деле работаешь со stable -
тоже ненужное ненужно.

Он, на самом деле и для своих проектов быстро перестает быть нужным.
Но надо потратить время на освоение. Документация у git говно,
поэтому лучше найти какое-то место для экспериментов - либо чужой
git-проект, либо свой завести.

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

Я, честно говоря, наивно надеялся что эту проблему как-нибудь научились
обходить.

> Alex

--- ifmail v.2.15dev5.4