Re: make contest
Dmitry E. Oboukhov -> debian-russian@lists.debian.org @ Wed, 1 Oct 2008
22:30:42 +0400:
DEO> о у меня примерно такая шняга в одном из проектов есть, примерно так и
DEO> работает (архив создается с бинарником и из исходников),
DEO> работа твоего примера (я вместо gcc cp использовал чтобы не париться с
DEO> ошибками):
DEO> nbw:[~/test.mk]$ touch B/b.c
DEO> nbw:[~/test.mk]$ make -C A all
DEO> make: Entering directory `/home/dimka/test.mk/A'
DEO> make -C ../B
DEO> make[1]: Entering directory `/home/dimka/test.mk/B'
DEO> cp ./b.c b
DEO> make[1]: Leaving directory `/home/dimka/test.mk/B'
DEO> tar -czvf ../a.tgz ../B/c ../B/b
DEO> tar: Удаляется начальный `../' из имен объектов
DEO> ../B/c
DEO> ../B/b
DEO> make: Leaving directory `/home/dimka/test.mk/A'
DEO> nbw:[~/test.mk]$ make -C A all
DEO> make: Entering directory `/home/dimka/test.mk/A'
DEO> make: Цель `all' не требует выполнения команд.
DEO> make: Leaving directory `/home/dimka/test.mk/A'
DEO> nbw:[~/test.mk]$ touch B/c.c
DEO> nbw:[~/test.mk]$ make -C A all
DEO> make: Entering directory `/home/dimka/test.mk/A'
DEO> make -C ../B
DEO> make[1]: Entering directory `/home/dimka/test.mk/B'
DEO> cp ./c.c c
DEO> make[1]: Leaving directory `/home/dimka/test.mk/B'
DEO> tar -czvf ../a.tgz ../B/c ../B/b
DEO> tar: Удаляется начальный `../' из имен объектов
DEO> ../B/c
DEO> ../B/b
DEO> make: Leaving directory `/home/dimka/test.mk/A'
DEO> nbw:[~/test.mk]$ make -C A all
DEO> make: Entering directory `/home/dimka/test.mk/A'
DEO> make: Цель `all' не требует выполнения команд.
DEO> make: Leaving directory `/home/dimka/test.mk/A'
DEO> и так выглядит:
DEO> $ cat include.mk
DEO> $(DIR_SRC)/b: $(DIR_SRC)/b.c
DEO> $(DIR_SRC)/c: $(DIR_SRC)/c.c
DEO> $ cat A/Makefile
DEO> DIR_SRC = ../B
DEO> include ../include.mk
DEO> all: ../a.tgz
DEO> ../a.tgz: $(DIR_SRC)/c $(DIR_SRC)/b
DEO> tar -czvf $@ $^
DEO> $(DIR_SRC)/c:
DEO> make -C $(DIR_SRC)
DEO> $(DIR_SRC)/b:
DEO> make -C $(DIR_SRC)
DEO> $ cat B/Makefile
DEO> DIR_SRC = .
DEO> all: $(DIR_SRC)/b $(DIR_SRC)/c
DEO> include ../include.mk
DEO> $(DIR_SRC)/b:
DEO> cp $< $@
DEO> $(DIR_SRC)/c:
DEO> cp $< $@
DEO> .PHONY: all
DEO> насколько я понимаю начнешь сейчас придираться к наличию include.mk?
DEO> но вот в чем фишка: в рамках одного проекта такой файл составляется
DEO> легко (можно даже поиграться с его автогенерацией, например make dep
DEO> устроить)
DEO> сгенерить include.mk можно разными способами, например
DEO> make -r -p
Нет, я, в общем, имел в виду похожий инклуд. Нет, не такой кривой,
попрямее. Я в первом своем ответе на ответ Станислава указал, как
именно сломается твоя конструкция в реальной жизни, и как ее починить.
Кривизна твоего решения в том, что ты половину B/Makefile дублируешь в
A/Makefile, да еще и делаешь это с ошибками. Нет, на _данной_ задаче
они еще не вылезают. Они вылезут на реальной.
А еще сравни размер своего решения с решением Юры Козлова. А потом - с
размером решения на sh без make с той же функциональностью :-)
Понятность и шанс ошибиться тоже сравни.
Ну, у тебя тут еще есть пара тараканов (так, по-хорошему, правило для
создания $(DIR_SRC)/b в A должно быть не make -C $(DIR_SRC), а make -C
$(DIR_SRC) ./b), но это, опять же, лечится указанным мной способом.
DEO> а в рамках разных проектов (навроде собираем архив) такое вообще редко
DEO> нужно, например ДАННАЯ задача может решаться так:
DEO> A/Makefile:
DEO> all: ../a.tgz
DEO> ../a.tgz: $(DIR_SRC)/c $(DIR_SRC)/b
DEO> make -C ../B
DEO> tar -czvf $@ $^
DEO> и ничего страшного что make -C ../B вызывается постоянно, поскольку он
DEO> ничего не делает.
А как сломается эта - написал Станислав. Я ему сперва возразил, потому
что не понял, что он отвечал именно на этот вариант. Вернее, для начала
оно сломается при попытке make all в A "с чистого листа". Цимес с
"добавим зависимость" в том, что как только ты написал зависимость от c
и b, тебе надо озаботиться, чтобы мейкфайл в A знал, как их собирать.
Потому что решение он будет принимать ДО того, как выполнится make -C ../B.
Насчет "легко" ты свою ошибку понял, или постепенно приближать задачу к
реальной? ("А теперь в B надо вот это сделать чуть похитрее...")
DEO> Да имеется проблема в том что список зависимостей сгенерить иногда
DEO> не так просто в пределе пишем его руками (это имхо сложные случаи,
DEO> когда как раз автор B/Makefile юзает рекурсии), но эта проблема не
DEO> растет от "рекурсивности" а от криворукости макеписателя :)
"Сгенерить список зависимостей" - это как раз задача, которую я в полной
постановке решить не сумел. Ставить?
Нет, руками не годится - оно зависит, в частности, от того, для какой
системы мы в данный момент собираем проект. Впрочем, за предложение
руками писать зависимости от сишных хедеров (из соседних директорий,
ага), мне кажется, можно
Re: Чем плох ре курсивный make?
AC>>> Или тебе настолько не нравится слово "рекурсивный", что ты не можешь AC>>> найти в себе сил выяснить, что оно значит в контексте обсуждаемой фразы AC>>> из четырех английских слов? AC>> [*] я вижу что описываемые проблемы растут не из "кривости" или AC>> "рекурсивности" make а из неправильного применения инструмента. AC> Можно сказать и так. Только тогда во всей идее .deb он применяется AC> неправильно, во-вторых, а во-первых, ты пробовал его применить AC> правильно? Я пробовал. Можно. Но с ТАКИМ геморроем... да с геморроем, но я везде где ковырялся и пробовал геморрой обычно начинается там где появляется рекурсивность (реальная) вызовов make а в других случаях для deb-пакетов вроде dep-s'ы можно так или иначе вытащить из оригинального make :) AC>>> Соберется. Я две строчки местами поменяю (несколько раз), и соберется. AC>> ну так ты удовлетворишь зависимости этими двумя строчками потому и AC>> соберется AC> Именно. Но я это сделаю один раз. Более того, я это сделаю сразу, при AC> первом написании скрипта. В _моем_ скрипте их переставлять не AC> придется. тогда непонятно к чему эта подветка дискуссии :) AC>>> Изменяем проект (допустим, накладываем патч). Даже, допустим, собираем AC>>> результат. Там же, в проекте. Запускаем debian/rules install, дабы AC>>> заново собрать пакет (на самом деле, естественно, запускаем binary, а AC>>> оно позовет install - там это будет в еще два шага, я их не привел). AC>>> Вопрос. Какая версия будет в пакете в результате? AC>> здесь как видно не собирался никто сделать повторную сборку ибо не нужна AC> В модели pbuilder - не нужна, он каждый раз все удаляет нах. Но AC> непонятно тогда, зачем там make. Внимание. Почему - понятно. AC> Непонятно, зачем. да действительно непонятно :) исторический рудимент buildd всегда начинает работу с clean :) AC> Примерно с той же, блин, целью сделан и configure. Непонятно только, AC> нафига он генерирует развесистый мейкфайл вместо тупого sh-скрипта - все AC> равно в половине случаев от того make там один вред. не почему, configure перезапускаем только когда меняется что-то в количестве исходников скажем итп а сама отладка работает на make то есть поправил файл - make, поправил - make, добавил - configure - make итп AC> На самом деле, естественно, не "такая и задумана", а "проще забить, чем AC> вылечить". лечение предполагает либо экстракт депендсов из авторского makefile, либо дубликат их во внешнем, либо правку авторского. первый пункт в каком-то *make удобно реализован? только так чтобы сборка не становилась узкоспециализированной AC> Что для данного применения плохо, но приемлемо. Для целей AC> разработки же - скорее неприемлемо. для целей разработки есть авторский makefile :) AC> После того, как ты мне это предъявишь в качестве решения, я поменяю в AC> проекте один сишник. Он не пересоберется, потому что для бинарников-то AC> зависимости не прописаны. ну так их надо выковырять из авторского :) вот если в нем нет рекурсий то это можно у make попросить полный список их (правда там приходится отсортировывать все ненужное) AC> Ты попробуй сделать - сам поймешь. Если не поймешь - я подскажу AC> последовательность команд, демонстрирующую проблему. я то понимаю, просто ты пытаешься соединить две задачи а я говорю что это неправильный подход. то есть если ты вызываешь внешний make, то это надо рассматривать как 1 единичное действие. а если ты хочешь чтобы часть действий одного была и в другом это уже получается ты хочешь 1 make использовать как библиотеку к другому тут конечно получаются костыли и подпорки... что делать? AC> Сделай. пример выше -- ... mpd is off . ''`. Dmitry E. Oboukhov : :’ : email: [EMAIL PROTECTED] jabber://[EMAIL PROTECTED] `. `~’ GPGKey: 1024D / F8E26537 2006-11-21 `- 1B23 D4F8 8EC0 D902 0555 E438 AB8C 00CF F8E2 6537 signature.asc Description: Digital signature
Re: make contest
AC> "Сгенерить список зависимостей" - это как раз задача, которую я в полной AC> постановке решить не сумел. Ставить? в ПОЛНОЙ постановке задача нерешабельна, это да я упирался в рекурсии на make'ах и дальше не шло (то есть в настоящие рекурсии) AC> Нет, руками не годится - оно зависит, в частности, от того, для какой AC> системы мы в данный момент собираем проект. Впрочем, за предложение AC> руками писать зависимости от сишных хедеров (из соседних директорий, AC> ага), мне кажется, можно расстреливать без суда и следствия. ну почему есть например проект состоящий из сишных и h-файлов а мы делаем ему deb-пакет то руками иногда проще чем выковырять не руками SRC = $(shell find src -name '*.[ch]') $(TARGET_BIN): $(SRC) make -C src ... вот примерно это я имел ввиду под "руками" зачастую общим правилом (вроде find) можно собрать в кучу 99% соурсов а недособранные 2-5 штук дописать через пробел :D PS: было бы просто здорово написать на gmake патч, который бы строил дерево ФАЙЛОВЫХ зависимостей в виде makefile'а же (он сейчас в общем дерево то строить но мешает в кучу все и кроме того спотыкается на рекурсивности makefile'ов когда скриптами выковыривать зависимости пытаешься приходится много грепать...) -- ... mpd is off . ''`. Dmitry E. Oboukhov : :’ : email: [EMAIL PROTECTED] jabber://[EMAIL PROTECTED] `. `~’ GPGKey: 1024D / F8E26537 2006-11-21 `- 1B23 D4F8 8EC0 D902 0555 E438 AB8C 00CF F8E2 6537 signature.asc Description: Digital signature
Re: Нужен ли bash
Aleksey Cheusov -> debian-russian@lists.debian.org @ Wed, 01 Oct 2008 18:50:04 +0300: >> Я сказал СПИСКОВУЮ форму system. AC> Я это прекрасно понял. См. ниже. >> Сравните результаты >> $filename='innocentpic.jpg; echo "Ha-Ha, you are hacked!'; >> system display, $filename; >> и >> system "display $filename"; AC> Сравните результаты: AC> filename='innocentpic.jpg; echo "Ha-Ha, you are hacked!' AC> display $filename AC> и AC> display "$filename" AC> Аналогично с eval-ом. AC> cmd="display \"`shquote '$filename'`\"" AC> eval "$cmd" shquote: command not found Я подозреваю, что это тоже вскрывается, но без shquote проверить не могу... Непереносимость, впрочем, надеюсь, очевидна. -- Artem Chuprina RFC2822: Jabber: [EMAIL PROTECTED] /dev/null-транспортировка -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Чем плох рекурсивный make?
Dmitry E. Oboukhov -> debian-russian@lists.debian.org @ Wed, 1 Oct 2008 18:44:55 +0400: VW>>> понимаешь в чем дело, в том что если бы make догадывалось об этом то ей VW>>> пришлось бы перестать быть универсальным инструментом (вон выше по ветке VW>>> собирают PDF например, а какой там DEBUG) и стала бы VW>>> узкоспециализированным. а это неправильно. VW>> Дебуга там нет, но вообще-то pdftex-у в командную строку тоже много чего VW>> интересного запихать можно. Во всяких bras и makepp эта задача решена VW>> посредством запоминания того, какой именно командой данный target VW>> пересобирался последний раз. И если текущая команда получается другая, VW>> target считается устаревшим. DEO> ну так я говорю, значит просто надо DEBUG поставить в зависимости DEO> и далее проблема станет решенной Надо _сложно_ поставить в зависимости DEBUG. Иначе оно будет пересобирать всё каждый раз. Подозреваю, что сделать это можно, но вплотную еще не думал. Есть шанс, что и не получится. -- Artem Chuprina RFC2822: Jabber: [EMAIL PROTECTED] А вы поподробнее, поподробнее. А заодно и быстрее будет... -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: make contest
Stanislav Maslovski -> debian-russian@lists.debian.org @ Thu, 2 Oct 2008 09:46:24 +0400: >> А так? :) >> all: >> make -C ../dirB >> @if test ! -f a.tar.gz; then tar czf a.tar.gz ../dirB/b ../dirB/c >> && rm -f ../dirB/rebuild; fi >> @if test -f ../dirB/rebuild; then tar czf a.tar.gz ../dirB/b >> ../dirB/c && rm ../dirB/rebuild; fi SM> Можно еще прощe: два условия в одно с -o. После чего возникает резонный вопрос. А make тут зачем? По условию задачи? Задача-то на sh решена... -- Artem Chuprina RFC2822: Jabber: [EMAIL PROTECTED] Реляционная база данных - это не единственный способ сделать дурацкий поиск. Victor Wagner -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Команда
Подскажите команду которая РАЗОВО замеряет нагрузку на цпу и выдает все % сколько осталось свободно , именно разово и желательно в %(процентном) соотношение.
Re: Нужен ли bash
Andrey Lyubimets -> debian-russian@lists.debian.org @ Thu, 02 Oct 2008 12:49:43 +0700: >> DEO> а на кой фиг надо два MTA на одном хосте? >> >> Я знаю по крайней мере три паттерна работы в такой позе - существенно >> разные требования на прием и раздачу, существенно разные требования на >> релеинг и прием себе, и этап смены MTA. AL> Расскажи поподробнее, а то я всю голову сломал, но паттернов, где AL> был бы нужен более другой МТА не вижу. У разных MTA при разработке имелись в виду разные назначения. Так, скажем, поцфикс оптимизировался под мощную почтомолотилку, а exim - скорее под гибкость настройки, и на больших нагрузках ведет себя плоховато. Особенно - если это exim-heavy. Ну вот, собственно, один ставят на релеинг, за ним другой на обработку локальной почты. Или один на обработку входящих соединений, другой - на контент-фильтрацию. Или один на разгребание очереди на отправку, другой на прием (exim, скажем, имеет очень так себе алгоритм разгребания очереди). Кто что лучше умеет. >> Первые два мне и самому не актуальны, но мы действительно хотим, чтобы >> на серьезных почтовых узлах приходилось пользоваться редхатом или >> соляркой не потому, что оно сертифицировано (это серьезным почтовым >> узлам как раз пофигу), а потому, что работает без геморроя, в отличие от >> дебиана? >> >> А третий вот мне, любимому, вот ровно сейчас как раз актуален... AL> Ну вот хотя бы про третий напиши поподробнее, что бы проблема была не AL> надуманная для примера, а реальная. Реальная. Перехожу с postfix на exim. У поцфикса есть ограничения, в которые я уткнулся, в exim с ними вроде проще. Система не тривиальная, там и SA, и антивирус, и релеинг в разных позах, включая UUCP. Как это делают нормальные админы? Правильно, ставят новый MTA рядом, но на другой порт, прикрытый файрволом, отлаживают конфигурацию, после чего кладут старый MTA, меняют порт у нового, запускают его в работу, запускают старый на разгребание очереди, дожидаются, когда разгребет, сносят. Внимание, вопрос. Как это предлагается делать в Debian? -- Artem Chuprina RFC2822: Jabber: [EMAIL PROTECTED] Феаноринги думают руками, арфинги - сердцем, а нолфинги - головой. (С)энта -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Чем плох ре курсивный make?
AC понимаешь в чем дело, в том что если бы make догадывалось об этом то ей AC пришлось бы перестать быть универсальным инструментом (вон выше по ветке AC собирают PDF например, а какой там DEBUG) и стала бы AC узкоспециализированным. а это неправильно. AC>>> Дебуга там нет, но вообще-то pdftex-у в командную строку тоже много чего AC>>> интересного запихать можно. Во всяких bras и makepp эта задача решена AC>>> посредством запоминания того, какой именно командой данный target AC>>> пересобирался последний раз. И если текущая команда получается другая, AC>>> target считается устаревшим. AC>> ну так я говорю, значит просто надо DEBUG поставить в зависимости AC>> и далее проблема станет решенной AC> Надо _сложно_ поставить в зависимости DEBUG. Иначе оно будет AC> пересобирать всё каждый раз. Подозреваю, что сделать это можно, но AC> вплотную еще не думал. Есть шанс, что и не получится. а мое решение сложно? то есть пишем в Makefile DEBUG ?= 0 # кстати не помню ?= это GNUmake или вообще make? хез ... debug_depends: test -e $@ || echo $(DEBUG) > $@ test "`cat [EMAIL PROTECTED]" = "$(DEBUG)" || echo $(DEBUG) > $@ и дальше ставим зависимость от debug_depends то есть получится что make его перезаписывать будет только при смене переменных и соответственно в зависимости: %.o: %.c debug_depends -- ... mpd is off . ''`. Dmitry E. Oboukhov : :’ : email: [EMAIL PROTECTED] jabber://[EMAIL PROTECTED] `. `~’ GPGKey: 1024D / F8E26537 2006-11-21 `- 1B23 D4F8 8EC0 D902 0555 E438 AB8C 00CF F8E2 6537 signature.asc Description: Digital signature
Re: Команда
12:01 Thu 02 Oct , Alise wrote: > Подскажите команду которая РАЗОВО замеряет нагрузку на цпу и выдает все > % сколько осталось свободно , именно разово и желательно в %(процентном) > соотношение. top -bn 1 | grep '^CPU' | cut -d ',' -f 4 90.4% id -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Чем плох рекурсивный make?
Dmitry E. Oboukhov -> debian-russian@lists.debian.org @ Thu, 2 Oct 2008 11:10:51 +0400: AC>> Примерно с той же, блин, целью сделан и configure. Непонятно AC>> только, нафига он генерирует развесистый мейкфайл вместо тупого AC>> sh-скрипта - все равно в половине случаев от того make там один AC>> вред. DEO> не почему, configure перезапускаем только когда меняется что-то в DEO> количестве исходников скажем итп а сама отладка работает на make DEO> то есть поправил файл - make, поправил - make, добавил - configure - DEO> make DEO> итп Там правка правке рознь. Добавил #include - уже вынь да положь configure. AC>> На самом деле, естественно, не "такая и задумана", а "проще забить, чем AC>> вылечить". DEO> лечение предполагает либо экстракт депендсов из авторского makefile, DEO> либо дубликат их во внешнем, либо правку авторского. DEO> первый пункт в каком-то *make удобно реализован? только так чтобы сборка DEO> не становилась узкоспециализированной Насколько я знаю, задача добычи зависимостей из makefile как минимум весьма сложна. Подозреваю, что неразрешима. AC>> Что для данного применения плохо, но приемлемо. Для целей AC>> разработки же - скорее неприемлемо. DEO> для целей разработки есть авторский makefile :) "Я и есть автор". Переделанная цитата из известного анекдота. DEO> то есть если ты вызываешь внешний make, то это надо рассматривать как 1 DEO> единичное действие. DEO> а если ты хочешь чтобы часть действий одного была и в другом это уже DEO> получается ты хочешь 1 make использовать как библиотеку к другому DEO> тут конечно получаются костыли и подпорки... что делать? Менять make на альтернативу, в которой при дизайне это учтено. -- Artem Chuprina RFC2822: Jabber: [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: make contest
Dmitry E. Oboukhov -> debian-russian@lists.debian.org @ Thu, 2 Oct 2008 11:20:53 +0400: AC>> "Сгенерить список зависимостей" - это как раз задача, которую я в полной AC>> постановке решить не сумел. Ставить? DEO> в ПОЛНОЙ постановке задача нерешабельна, это да DEO> я упирался в рекурсии на make'ах и дальше не шло DEO> (то есть в настоящие рекурсии) AC>> Нет, руками не годится - оно зависит, в частности, от того, для какой AC>> системы мы в данный момент собираем проект. Впрочем, за предложение AC>> руками писать зависимости от сишных хедеров (из соседних директорий, AC>> ага), мне кажется, можно расстреливать без суда и следствия. DEO> ну почему DEO> есть например проект состоящий из сишных и h-файлов DEO> а мы делаем ему deb-пакет DEO> то руками иногда проще чем выковырять не руками DEO> SRC = $(shell find src -name '*.[ch]') DEO> $(TARGET_BIN): $(SRC) DEO> make -C src DEO> ... DEO> вот примерно это я имел ввиду под "руками" DEO> зачастую общим правилом (вроде find) можно собрать в кучу 99% соурсов DEO> а недособранные 2-5 штук дописать через пробел :D А. Не, это просто и понятно. В более типичном случае (когда это зависимость не полного пакета, а конкретного бинарника) будет туча паразитных зависимостей. В смысле - не имеющих отношения к бинарю. DEO> PS: было бы просто здорово написать на gmake патч, который бы DEO> строил дерево ФАЙЛОВЫХ зависимостей в виде makefile'а же (он DEO> сейчас в общем дерево то строить но мешает в кучу все и кроме того DEO> спотыкается на рекурсивности makefile'ов когда скриптами DEO> выковыривать зависимости пытаешься приходится много грепать...) Ну вот когда у человека накапливается к make десяток претензий подобного рода в _разных_ местах - он и пишет заменитель... Потому что десяток - это уже проще заменить, чем исправить. -- Artem Chuprina RFC2822: Jabber: [EMAIL PROTECTED] If a `religion' is defined to be a system of ideas that contains unprovable statements, then Godel taught us that mathematics is not only a religion, it is the only religion that can prove itself to be one. -- John Barrow -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Нужен ли bash
Hello!
В сообщении от Thursday 02 October 2008 08:29:22 Victor Wagner написал(а):
> > > Появившуюся возможность подстановки списков. В смысле подставить
> > > n-элементный список в команду не как один параметр, а как n,
> > > БЕЗ лишнего уровня evaluation для всего остального.
> >
> > А как это делается? Когда будет раскрывать список?
>
> Специальным синтаксисом подстановки. Что-то вроде {}$list
> У меня сейчас man Tcl от 8.5 под рукой нету.
Спасибо, этого достаточно.
Best regards, Alexey.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Lenny 5.0
Hello! В сообщении от Thursday 02 October 2008 09:06:59 Stanislav Maslovski написал(а): > По синей кривой моменты апдейтов как раз прослеживаются: там она скачет > вниз. Странные какие-то апдейты - правят не все баги, а лишь выборочно. Учитывая, что на графике отображены серьезные баги, логику не понимаю. Best regards, Alexey. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: make contest
AC> Ну вот когда у человека накапливается к make десяток претензий подобного AC> рода в _разных_ местах - он и пишет заменитель... Потому что десяток - AC> это уже проще заменить, чем исправить. но я пока не видел УНИВЕРСАЛЬНОГО заменителя да типа там функций добавят, там других вкусностей а там типа все круто но скажем только для N видов проектов и все. в общем альтернативы-то нет :( -- ... mpd is off . ''`. Dmitry E. Oboukhov : :’ : email: [EMAIL PROTECTED] jabber://[EMAIL PROTECTED] `. `~’ GPGKey: 1024D / F8E26537 2006-11-21 `- 1B23 D4F8 8EC0 D902 0555 E438 AB8C 00CF F8E2 6537 signature.asc Description: Digital signature
Re: make contest
On Thu, Oct 02, 2008 at 11:56:13AM +0400, Artem Chuprina wrote: > Stanislav Maslovski -> debian-russian@lists.debian.org @ Thu, 2 Oct 2008 > 09:46:24 +0400: > SM> Можно еще прощe: два условия в одно с -o. > > После чего возникает резонный вопрос. А make тут зачем? По условию > задачи? Задача-то на sh решена... Дык, просто такая задача, где по сути в dirA/ разумнее иметь сборочный скрипт, а не Makefile. Нет, я не спорю. Каждый волен разложить себе на пути камней и спотыкаться. -- Stanislav -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Чем плох ре курсивный make?
AC> Там правка правке рознь. Добавил #include - уже вынь да положь configure. смотря какой include :) если на себя же (свой проект) то да :) а если на тот что в /usr лежит, то запуск configure можно в долгий ящик откладывать :) AC>> первый пункт в каком-то *make удобно реализован? только так чтобы сборка AC>> не становилась узкоспециализированной AC> Насколько я знаю, задача добычи зависимостей из makefile как минимум AC> весьма сложна. Подозреваю, что неразрешима. подозреваю что разрешима поскольку make эти зависимости строит, то есть можно ее допатчить чтобы она их выводила в удобоваримом виде (она и сейчас умеет их вывести, но рекурсивные ревызовы сейчас она не умеет) AC>>> Что для данного применения плохо, но приемлемо. Для целей AC>>> разработки же - скорее неприемлемо. AC>> для целей разработки есть авторский makefile :) AC> "Я и есть автор". Переделанная цитата из известного анекдота. когда ты автор сделать depends.mk тебе труда не составит сложнее когда ты делаешь "обертку" над чьим-то makefile и патчить его тебе по каким-то причинам не хочется AC>> тут конечно получаются костыли и подпорки... что делать? AC> Менять make на альтернативу, в которой при дизайне это учтено. нет альтернатив-то :( то есть для одной задачи есть, а для другой задачи опять нет хочется универсального инструмента -- ... mpd is off . ''`. Dmitry E. Oboukhov : :’ : email: [EMAIL PROTECTED] jabber://[EMAIL PROTECTED] `. `~’ GPGKey: 1024D / F8E26537 2006-11-21 `- 1B23 D4F8 8EC0 D902 0555 E438 AB8C 00CF F8E2 6537 signature.asc Description: Digital signature
Re: Etch и чипсеты
В Чтв, 02/10/2008 в 12:30 +0700, Sergey A. Bykanov пишет: > Подскажите где можно посмотреть о поддерживаемых в Etch материнках и > чипсетах? Так же интересует поддержка встроенного в чипсеты Intel Raid 5. "встроенного в чипсеты Intel Raid 5" бывает только (иначе очень дорого) fakeraid. Softraid по мнениям многих лучше использовать вместо fakeraid, поэтому его поддержка в принципе не нужна. Про чипы не скажу точно, до 965-го по моему. Хотя, если использовать ядро etch'n'half (2.6.22) то наверно и старше. -- Покотиленко Костик <[EMAIL PROTECTED]> -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: ext3>ext3: 8-10 mb/s
В Срд, 01/10/2008 в 20:40 +0100, Mikhail Ramendik пишет: > Всем привет! > > Есть жёсткий диск SATA. По hdparm скорость больше 50 мегов в секунду. > > А вот копирование с одного раздела ext3 на другой - 8-10 мегов в > секунду... > > Это нормально? Можно ли сделать быстрее, и если можно - то как? Это зависит... Но в целом нормально, разделы на одном диске - скорость теоретически падает в 2 раза, + фрагментация +ещё несколько моментов - примерно так и получатся. Ибо 50 Мб/с - это скорость последовательного чтения, коего в реальных условиях не бывает. -- Покотиленко Костик <[EMAIL PROTECTED]> -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: make contest
Hello! Раз тут такие специалисты по мэйкфайлам собрались, подскажите одну вещь. Нужно мне в проект добавить пару дополнительных файлов, которые должны линковаться с дополнительными библиотеками. Сейчас делаю так TCC += -lz -DSQLITE_ENABLE_ICU=1 `icu-config --ldflags` Где-то далее в мэйке идет перечисление добавленных мной файлов SRC += \ $(TOP)/ext/inet/ipv4-ext.c SRC += \ $(TOP)/ext/compress/compress.c SRC += \ $(TOP)/ext/crypt/md5.c Больше эти файлы нигде не упоминаются. Теперь при сборке deb-пакета вижу ругань, что добавленные мной доп. либы нафиг никому не нужны, кроме моих файликов. Как быть? dh_installdeb -psqlite3 dh_perl -psqlite3 dh_shlibdeps -psqlite3 dpkg-shlibdeps: предупреждение: зависимости от libdl.so.2 можно избежать, если "debian/sqlite3/usr/bin/sqlite3" не будет бесполезно слинкована сней (не используется ни одного её символа). dpkg-shlibdeps: предупреждение: зависимости от libz.so.1 можно избежать, если "debian/sqlite3/usr/bin/sqlite3" не будет бесполезно слинкована сней (не используется ни одного её символа). dpkg-shlibdeps: предупреждение: зависимости от libicui18n.so.38 можно избежать, если "debian/sqlite3/usr/bin/sqlite3" не будет бесполезно слинкована сней (не используется ни одного её символа). dpkg-shlibdeps: предупреждение: зависимости от libicuuc.so.38 можно избежать, если "debian/sqlite3/usr/bin/sqlite3" не будет бесполезно слинкована сней (не используется ни одного её символа). dpkg-shlibdeps: предупреждение: зависимости от libm.so.6 можно избежать, если "debian/sqlite3/usr/bin/sqlite3" не будет бесполезно слинкована сней (не используется ни одного её символа). dpkg-shlibdeps: предупреждение: зависимости от libpthread.so.0 можно избежать, если "debian/sqlite3/usr/bin/sqlite3" не будет бесполезно слинкована сней (не используется ни одного её символа). dpkg-shlibdeps: предупреждение: зависимости от libicudata.so.38 можно избежать, если "debian/sqlite3/usr/bin/sqlite3" не будет бесполезно слинкована сней (не используется ни одного её символа). dh_installdeb -plibsqlite3-0 Best regards, Alexey. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: make contest
AC>> .include > Ты решал не ту задачу. Решил ты ее или нет, я уж не могу сказать, > поскольку непонятно, какую решал, но решал - не ту. Ну ёпрст 8-) Я решил ту задачу, именно ту - строю пакет из бинарей, которые строятся из .с файлов. При желании построить пакет измененные .c таки учитываются, и перед построением пакета строятся перестраиваются бинари. Дописать pkg/Makefile ты и сам в состоянии. Я решил ее совсем не так, как ты себе представлял решение. Это да. Я не стал вазюкаться с мерзопакостными зависимостями и прочими костылями с неуместных местах. Я сделал намного проще. Проблемы "resursive manu considered harmful" решительно не существует! Она не стоит того, чтобы посвящать ей "труды" и писать make-озаменители. -- Best regards, Aleksey Cheusov. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: ext3>ext3: 8-10 mb/s
,-[Thu, Oct 02, 2008 at 11:55 +0300, Покотиленко Костик:] |> А вот копирование с одного раздела ext3 на другой - 8-10 мегов в | |Это зависит... Но в целом нормально, разделы на одном диске - скорость |теоретически падает в 2 раза, + фрагментация +ещё несколько моментов - |примерно так и получатся. Ибо 50 Мб/с - это скорость последовательного |чтения, коего в реальных условиях не бывает. | |-- |Покотиленко Костик <[EMAIL PROTECTED]> мне кажется - мало. тыщ 25 вполне можно ожидать, но не менее 20. конечно зависит от факторов, но опускаться периодически до 8 -- ето еще ладно. но иметь пик в 10 - ето слабовато. околотопиковый флуд: у меня похожая картина была на прошлых матерях ( асус m2n4x m2ne) когда понаставил самсунговских винтов на 500 гиг, которые не имели переключения на сата1. операции на винтах стали с похожей скоростью производится. потом несколько раз натыкался на сообщение о хреновой работе сата2 на матерях асус на нфорс 4 или 500-520 ( с которых иной раз снимали кулер и там была надпись nforce4x )) - народ переключал винт на сата2 и оно начинало работать медленно. -- _ mpd status: [stopped] ** * jabber: [EMAIL PROTECTED] * * Registered linux user #450844* ** -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: make contest
On 2008.10.02 at 13:07:47 +0400, Alexey Pechnikov wrote: > Hello! > > Раз тут такие специалисты по мэйкфайлам собрались, подскажите одну вещь. > Нужно > мне в проект добавить пару дополнительных файлов, которые должны линковаться > с дополнительными библиотеками. Сейчас делаю так > > TCC += -lz -DSQLITE_ENABLE_ICU=1 `icu-config --ldflags` > > > Теперь при сборке deb-пакета вижу ругань, что добавленные мной доп. либы > нафиг > никому не нужны, кроме моих файликов. Как быть? Вообще-то в принципе в этом случае надо читать info -f make "Target-specific" - про как как переопределить переменные отдельно для некоторых целей. Но в данном случае, похоже проблема в другом - библиотеки ДЕЙСТВИТЕЛЬНО не используются. Нужно внимательнее смотреть на логи компиляции. Возможно, где-то забыты какие-то флаги при компиляции (то-ли -DSQLITE_ENABLE_ICU не используется при компиляции тех с-файлов, которых надо, то-ли где-то надо icu-config --cflags добавить). Ежели dh_shlibdeps говорит что бинарник бесполезно слинкован с библиотекой, значит так оно и есть - при сборке объектника не была выбрана та ветка #ifdef-ов, в которой используются символы из этой библиотеки. Либо "мои файлики" собираются в отдельный бинарник и никому кроме него эти библиотеки не нужны. Тогда использовать первый данный совет - про target specific variables. Но на это как-то не похоже. Разве что этот бинарник потом в отдельный пакет кладется. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Нужен ли bash
AC>> Сравните результаты: AC>> filename='innocentpic.jpg; echo "Ha-Ha, you are hacked!' AC>> display $filename AC>> и AC>> display "$filename" AC>> Аналогично с eval-ом. AC>> cmd="display \"`shquote '$filename'`\"" AC>> eval "$cmd" > shquote: command not found > Я подозреваю, что это тоже вскрывается, но без shquote проверить не > могу... Непереносимость, впрочем, надеюсь, очевидна. Да переносимость очевидна. shquote - это open source, 2-closure BSD license. Если у вас ее нет, это сами знаете чьи проблемы. -- Best regards, Aleksey Cheusov. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: make contest
>>> make -C ../dirB >>> @if test ! -f a.tar.gz; then tar czf a.tar.gz ../dirB/b ../dirB/c >>> && rm -f ../dirB/rebuild; fi >>> @if test -f ../dirB/rebuild; then tar czf a.tar.gz ../dirB/b >>> ../dirB/c && rm ../dirB/rebuild; fi > После чего возникает резонный вопрос. А make тут зачем? По условию > задачи? Задача-то на sh решена... Задча уже решена базовыми средствами BSD make-а красиво и эффективно. Просто вы, мсье, ищете себе проблемы там, где их нет. Не нужно этого делать. А вот тот за тот мусор, что я оставил вверху, руки бы поотрывал. -- Best regards, Aleksey Cheusov. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: make contest
Hello! > Либо "мои файлики" собираются в отдельный бинарник и никому кроме него > эти библиотеки не нужны. Тогда использовать первый данный совет - про > target specific variables. > > Но на это как-то не похоже. Разве что этот бинарник потом в отдельный > пакет кладется. В результате несколько деб-пакетов генерится. Сборка с помощью make проходит нормально, а при debuild вот сообщения вылезли. Значит, проблема именно в том, что добавленные зависимости нужны не всем пакетам. А "target specific variables" это на уровне мэйкфайла или в debian/rules? Best regards, Alexey. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Viking и realtime gps
В Птн, 26/09/2008 в 16:39 +0400, Dmitri Samsonov пишет: > Artem Chuprina пишет: > > > > Если версия викинга одна и та же, то возможно, что обновить следует > > не викинга, а какую-то из нижележащих библиотек. Или gpsd. > > Обновил gpsd из бекпортов -- и помогло! Всё заработало. > > Спасибо. Решил попробовать viking - классный такой google earth под линукс. GPS у меня нет. Сходу возник вопрос - а Яндекс.карты к нему можно прикрутить? -- Покотиленко Костик <[EMAIL PROTECTED]> -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: make contest
> %: %.c > cc -o $* $< Да-да-да. Вот именно такие вот квадратные колеса и приходится потом закруглять, чтобы оно хотя бы собиралось, как надо. Gr-r-r-r-r. Я понимаю, что это "всего лишь пример", но уж очень он показателен. (ничего личного) -- Best regards, Aleksey Cheusov. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: ext3>ext3: 8-10 mb/s
2008/10/1 Dmitry Nezhevenko <[EMAIL PROTECTED]> > On Wed, Oct 01, 2008 at 08:40:49PM +0100, Mikhail Ramendik wrote: > > Есть жёсткий диск SATA. По hdparm скорость больше 50 мегов в секунду. > > А вот копирование с одного раздела ext3 на другой - 8-10 мегов в > секунду... > > Это нормально? Можно ли сделать быстрее, и если можно - то как? > > > > Что копируется? Один большой файл или куча маленьких? Достаточно ли > свободного > места на разделе? Копируется один большой файл. Разделы активно эксплуатируются рпи не очень большом количестве свободного места, поэтому фрагментация вполне может быть - чем бы дефрагментировать ext3? > > IMHO если есть возможность, лучше проверить на других FS. Windows NT with NTFS - около 12 мег/с. Других FS на диске нет. -- Yours, Mikhail Ramendik
Re: make contest
On 2008.10.02 at 13:57:18 +0400, Alexey Pechnikov wrote: > Hello! > > > Либо "мои файлики" собираются в отдельный бинарник и никому кроме него > > эти библиотеки не нужны. Тогда использовать первый данный совет - про > > target specific variables. > > > > Но на это как-то не похоже. Разве что этот бинарник потом в отдельный > > пакет кладется. > > В результате несколько деб-пакетов генерится. Сборка с помощью make проходит > нормально, а при debuild вот сообщения вылезли. Значит, проблема именно в > том, что добавленные зависимости нужны не всем пакетам. А "target specific > variables" это на уровне мэйкфайла или в debian/rules? Ну, поскольку речь идет о target-ах -бинарниках, то на уровне makefile. Либо надо вызывать make c оригинальным Makefile дважды - один раз для основных бинарников, другой - для этих, дополнительных, и передавать ему переменную с дополнительными библиотеками только во второй раз. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: ext3>ext3: 8-10 mb/s
В Чтв, 02/10/2008 в 11:06 +0100, Mikhail Ramendik пишет: > > 2008/10/1 Dmitry Nezhevenko <[EMAIL PROTECTED]> > On Wed, Oct 01, 2008 at 08:40:49PM +0100, Mikhail Ramendik > wrote: > > Есть жёсткий диск SATA. По hdparm скорость больше 50 мегов в > секунду. > > А вот копирование с одного раздела ext3 на другой - 8-10 > мегов в секунду... > > Это нормально? Можно ли сделать быстрее, и если можно - то > как? > > > > > Что копируется? Один большой файл или куча маленьких? > Достаточно ли свободного > места на разделе? > > Копируется один большой файл. Разделы активно эксплуатируются рпи не > очень большом количестве свободного места, поэтому фрагментация вполне > может быть - чем бы дефрагментировать ext3? > > > IMHO если есть возможность, лучше проверить на других FS. > > Windows NT with NTFS - около 12 мег/с. Других FS на диске нет. Может тупо DMA и 32bit выключено? (hdparm -c 1 -d 1) -- Покотиленко Костик <[EMAIL PROTECTED]> -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Viking и realtime gps
В Чтв, 02/10/2008 в 14:06 +0400, Victor Wagner пишет: > On 2008.10.02 at 13:02:15 +0300, Покотиленко Костик wrote: > > > > > Решил попробовать viking - классный такой google earth под линукс. GPS у > > меня нет. > > Ежели нужен Google Earth под Linux, то и надо брать Google Earth под > Linux. С гугля. Раньше искал и что-то не нашёл. > > Сходу возник вопрос - а Яндекс.карты к нему можно прикрутить? > > Можно. Но в viking поддержка всяких разных репозиториев реализована на > уровне C-шного кода. поэтому придется патчить. В викингском списке > рассылки сейчас обсуждается вопрос создания интерфейса плагинов для этой > цели, но пока это даже еще не на уровне проекта. Может есть что-то, что показывает карты городов Украины желательно с поиском по улицам? -- Покотиленко Костик <[EMAIL PROTECTED]> -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: make contest
Hello! В сообщении от Thursday 02 October 2008 14:08:27 Victor Wagner написал(а): > > В результате несколько деб-пакетов генерится. Сборка с помощью make > > проходит нормально, а при debuild вот сообщения вылезли. Значит, проблема > > именно в том, что добавленные зависимости нужны не всем пакетам. А > > "target specific variables" это на уровне мэйкфайла или в debian/rules? > > Ну, поскольку речь идет о target-ах -бинарниках, то на уровне makefile. > Либо надо вызывать make c оригинальным Makefile дважды - один раз для > основных бинарников, другой - для этих, дополнительных, и передавать ему > переменную с дополнительными библиотеками только во второй раз. А есть грамотный путь сборки бинарного дебпакета из готовых бинарников? Может, отдельный скрипт на это сделать и не мучаться так... Best regards, Alexey. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Viking и realtime gps
On 2008.10.02 at 13:14:08 +0300, Покотиленко Костик wrote: > В Чтв, 02/10/2008 в 14:06 +0400, Victor Wagner пишет: > > On 2008.10.02 at 13:02:15 +0300, Покотиленко Костик wrote: > > > > > > > > Решил попробовать viking - классный такой google earth под линукс. GPS у > > > меня нет. > > > > Ежели нужен Google Earth под Linux, то и надо брать Google Earth под > > Linux. С гугля. > > Раньше искал и что-то не нашёл. У меня уже два года стоит. Викинга еще в sid не было, а GE для Linux уже был. > > > > Сходу возник вопрос - а Яндекс.карты к нему можно прикрутить? > > > > Можно. Но в viking поддержка всяких разных репозиториев реализована на > > уровне C-шного кода. поэтому придется патчить. В викингском списке > > рассылки сейчас обсуждается вопрос создания интерфейса плагинов для этой > > цели, но пока это даже еще не на уровне проекта. > > Может есть что-то, что показывает карты городов Украины желательно с > поиском по улицам? Это к Петру Власенко (http://maps.vlasenko.net). Он по части Украины более в курсе, чем я. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: make contest
On 2008.10.02 at 14:20:53 +0400, Alexey Pechnikov wrote: > Hello! > > В сообщении от Thursday 02 October 2008 14:08:27 Victor Wagner написал(а): > > > В результате несколько деб-пакетов генерится. Сборка с помощью make > > > проходит нормально, а при debuild вот сообщения вылезли. Значит, проблема > > > именно в том, что добавленные зависимости нужны не всем пакетам. А > > > "target specific variables" это на уровне мэйкфайла или в debian/rules? > > > > Ну, поскольку речь идет о target-ах -бинарниках, то на уровне makefile. > > Либо надо вызывать make c оригинальным Makefile дважды - один раз для > > основных бинарников, другой - для этих, дополнительных, и передавать ему > > переменную с дополнительными библиотеками только во второй раз. > > А есть грамотный путь сборки бинарного дебпакета из готовых бинарников? > Может, > отдельный скрипт на это сделать и не мучаться так... Это немножко не Debian-way. Помнится, когда я пакетировал таким образом djgpp-runtime мне высказали большое-большое ФИ, поскольку такая система пакетирования крайне осложняет исправление ошибок с последующей пересборкой пакета. Подразумевается, что в debian/rules должно содержаться ВСЁ тайное знание, необходимое для сборки. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Viking и realtime gps
On 2008.10.02 at 13:02:15 +0300, Покотиленко Костик wrote: > > Решил попробовать viking - классный такой google earth под линукс. GPS у > меня нет. Ежели нужен Google Earth под Linux, то и надо брать Google Earth под Linux. С гугля. А viking это именно инструмент для редактирования GPS-ных трэков и маршрутов. Которые совершенно необязательно использовать потом в viking - можно, к примеру нарисовать маршрут в viking и залить в maemo-mapper, или вообще в сам GPS. > Сходу возник вопрос - а Яндекс.карты к нему можно прикрутить? Можно. Но в viking поддержка всяких разных репозиториев реализована на уровне C-шного кода. поэтому придется патчить. В викингском списке рассылки сейчас обсуждается вопрос создания интерфейса плагинов для этой цели, но пока это даже еще не на уровне проекта. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Etch и чипсеты
Покотиленко Костик пишет: В Чтв, 02/10/2008 в 12:30 +0700, Sergey A. Bykanov пишет: Подскажите где можно посмотреть о поддерживаемых в Etch материнках и чипсетах? Так же интересует поддержка встроенного в чипсеты Intel Raid 5. "встроенного в чипсеты Intel Raid 5" бывает только (иначе очень дорого) fakeraid. Softraid по мнениям многих лучше использовать вместо fakeraid, поэтому его поддержка в принципе не нужна. Про чипы не скажу точно, до 965-го по моему. Хотя, если использовать ядро etch'n'half (2.6.22) то наверно и старше Спасибо за ответ. Но в etch'n'half вроде 2.6.24? -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Lenny 5.0
On Thu, Oct 02, 2008 at 12:46:03PM +0400, Alexey Pechnikov wrote: > Странные какие-то апдейты - правят не все баги, а лишь выборочно. Учитывая, > что на графике отображены серьезные баги, логику не понимаю. В основном правят security-related баги. Остальное -- по мелочи. -- Stanislav -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: make contest
2 октября 2008 г. 11:56 пользователь Artem Chuprina <[EMAIL PROTECTED]> написал: > Stanislav Maslovski -> debian-russian@lists.debian.org @ Thu, 2 Oct 2008 > 09:46:24 +0400: > > >> А так? :) > >> all: > >> make -C ../dirB > >> @if test ! -f a.tar.gz; then tar czf a.tar.gz ../dirB/b > ../dirB/c && rm -f ../dirB/rebuild; fi > >> @if test -f ../dirB/rebuild; then tar czf a.tar.gz ../dirB/b > ../dirB/c && rm ../dirB/rebuild; fi > > SM> Можно еще прощe: два условия в одно с -o. > > После чего возникает резонный вопрос. А make тут зачем? По условию > задачи? Задача-то на sh решена... С make хорошо и просто собираются бинарики (для чего он изначально и был придуман?). Пакетирование -- другая задача. Не помню в условиях ограничиваться одним лишь make. При чём хором тут неделю распинались какие плохие у make рекурсивные зависимости. :) Если задача не решается в лоб нужным инструментом -- два варианта: корректировать задачу или наточить инструмент. -- Regards, Yuri Kozlov
Re: make contest
2 октября 2008 г. 13:55 пользователь Aleksey Cheusov <[EMAIL PROTECTED]> написал: > >>> make -C ../dirB > >>> @if test ! -f a.tar.gz; then tar czf a.tar.gz ../dirB/b > ../dirB/c && rm -f ../dirB/rebuild; fi > >>> @if test -f ../dirB/rebuild; then tar czf a.tar.gz ../dirB/b > ../dirB/c && rm ../dirB/rebuild; fi > >> После чего возникает резонный вопрос. А make тут зачем? По условию >> задачи? Задача-то на sh решена... > > Задча уже решена базовыми средствами BSD make-а красиво и эффективно. > Просто вы, мсье, ищете себе проблемы там, где их нет. > Не нужно этого делать. А вот тот за тот мусор, что я оставил вверху, > руки бы поотрывал. Как воспользоваться вашим решением в Debian? -- Regards, Yuri Kozlov
Re: make contest
Dmitry E. Oboukhov -> debian-russian@lists.debian.org @ Thu, 2 Oct 2008 12:47:44 +0400: AC>> Ну вот когда у человека накапливается к make десяток претензий подобного AC>> рода в _разных_ местах - он и пишет заменитель... Потому что десяток - AC>> это уже проще заменить, чем исправить. DEO> но я пока не видел УНИВЕРСАЛЬНОГО заменителя DEO> да типа там функций добавят, там других вкусностей DEO> а там типа все круто но скажем только для N видов проектов DEO> и все. DEO> в общем альтернативы-то нет :( Ну, вот makepp, похоже, во всяком случае не слабее. Т.е. везде, где работает make, его хватит. bras тоже. За питоновские варианты не поручусь. -- Artem Chuprina RFC2822: Jabber: [EMAIL PROTECTED] Нужны две программы - одна с интерфейсом, а другая чтобы работу делала. Victor Wagner в <[EMAIL PROTECTED]> -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: make contest
Alexey Pechnikov wrote: > Hello! > > Раз тут такие специалисты по мэйкфайлам собрались, подскажите одну вещь. > Нужно > мне в проект добавить пару дополнительных файлов, которые должны линковаться > с дополнительными библиотеками. Сейчас делаю так > > TCC += -lz -DSQLITE_ENABLE_ICU=1 `icu-config --ldflags` > > Где-то далее в мэйке идет перечисление добавленных мной файлов > > SRC += \ > $(TOP)/ext/inet/ipv4-ext.c > SRC += \ > $(TOP)/ext/compress/compress.c > SRC += \ > $(TOP)/ext/crypt/md5.c > > Больше эти файлы нигде не упоминаются. > > Теперь при сборке deb-пакета вижу ругань, что добавленные мной доп. либы > нафиг > никому не нужны, кроме моих файликов. Как быть? > > dh_installdeb -psqlite3 > dh_perl -psqlite3 > dh_shlibdeps -psqlite3 > dpkg-shlibdeps: предупреждение: зависимости от libdl.so.2 можно избежать, > если "debian/sqlite3/usr/bin/sqlite3" не будет бесполезно слинкована сней (не > используется ни одного её символа). > dpkg-shlibdeps: предупреждение: зависимости от libz.so.1 можно избежать, > если "debian/sqlite3/usr/bin/sqlite3" не будет бесполезно слинкована сней (не > используется ни одного её символа). > dpkg-shlibdeps: предупреждение: зависимости от libicui18n.so.38 можно > избежать, если "debian/sqlite3/usr/bin/sqlite3" не будет бесполезно > слинкована сней (не используется ни одного её символа). > dpkg-shlibdeps: предупреждение: зависимости от libicuuc.so.38 можно избежать, > если "debian/sqlite3/usr/bin/sqlite3" не будет бесполезно слинкована сней (не > используется ни одного её символа). > dpkg-shlibdeps: предупреждение: зависимости от libm.so.6 можно избежать, > если "debian/sqlite3/usr/bin/sqlite3" не будет бесполезно слинкована сней (не > используется ни одного её символа). > dpkg-shlibdeps: предупреждение: зависимости от libpthread.so.0 можно > избежать, > если "debian/sqlite3/usr/bin/sqlite3" не будет бесполезно слинкована сней (не > используется ни одного её символа). > dpkg-shlibdeps: предупреждение: зависимости от libicudata.so.38 можно > избежать, если "debian/sqlite3/usr/bin/sqlite3" не будет бесполезно > слинкована сней (не используется ни одного её символа). > dh_installdeb -plibsqlite3-0 > > Best regards, Alexey. > > Забить, если это только не ведёт к лишним бинарным зависимостям. Могу быть не прав, собаку на этих вещах не ел. -- Eugene V. Lyubimkin aka JackYF signature.asc Description: OpenPGP digital signature
Re: make contest
Aleksey Cheusov -> debian-russian@lists.debian.org @ Thu, 02 Oct 2008 12:09:42 +0300: AC>>> .include >> Ты решал не ту задачу. Решил ты ее или нет, я уж не могу сказать, >> поскольку непонятно, какую решал, но решал - не ту. AC> Ну ёпрст 8-) Я решил ту задачу, именно ту - строю пакет из бинарей, AC> которые строятся из .с файлов. При желании построить пакет AC> измененные .c таки учитываются, и перед построением пакета строятся AC> перестраиваются бинари. Дописать pkg/Makefile ты и сам в состоянии. А я не ставил задачу "построить пакет". Если кто не заметил. Я просто оставил один аспект реальной задачи и максимально упростил модель. Могу показать полную. Это, правда, будет довольно длинное письмо... -- Artem Chuprina RFC2822: Jabber: [EMAIL PROTECTED] Если ничто уже не помогает, прочтите же, наконец, инструкцию! -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Организация корпоративного репоитория (apt-move)
Ситуация такая: в оффисе сидят несколько человек на lenny и постоянно делают aptitude update => aptitude upgrade или просто доустанавливают какое-то ПО. Соответственно тянут траффик. Я так понимаю, что apt-move берет из кеша загруженные пакеты и формирут репозиторий. Можно ли как-то организовать, чтобы все эти пользователи сливали бы все свои загруженные пакеты в единый каталог (ftp? ssh?) и не расходовали зазря траффик на одинаковые пакеты?
Re: Организация корпоративного репоитория (apt-move)
В сообщении от 2 октября 2008 15:41 Илья Демьянов написал(a): > Можно ли как-то организовать, чтобы все эти > пользователи сливали бы все свои загруженные пакеты в единый каталог > (ftp? ssh?) и не расходовали зазря траффик на одинаковые пакеты? approx на выделенном сервере или даже на одной из раб. станций. Надёжен, лёгок в настройке, может работать(сам всмысле) через прокси. -- С Уважением, Андрей Никитин -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Нужен ли bash
Aleksey Cheusov -> debian-russian@lists.debian.org @ Thu, 02 Oct 2008 12:22:41 +0300: AC>>> Сравните результаты: AC>>> filename='innocentpic.jpg; echo "Ha-Ha, you are hacked!' AC>>> display $filename AC>>> и AC>>> display "$filename" AC>>> Аналогично с eval-ом. AC>>> cmd="display \"`shquote '$filename'`\"" AC>>> eval "$cmd" >> shquote: command not found >> Я подозреваю, что это тоже вскрывается, но без shquote проверить не >> могу... Непереносимость, впрочем, надеюсь, очевидна. AC> Да переносимость очевидна. shquote - это open source, 2-closure BSD AC> license. Если у вас ее нет, это сами знаете чьи проблемы. По этой логике переносима любая виндовая программа - эмулятор же есть, поставить можно... Я правильно понимаю, что shquote рассчитана на квотинг только BSD'шного шелла? Вскрываться вроде не вскрывается... -- Artem Chuprina RFC2822: Jabber: [EMAIL PROTECTED] Нужны две программы - одна с интерфейсом, а другая чтобы работу делала. Victor Wagner в <[EMAIL PROTECTED]> -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: make contest
>> >>> make -C ../dirB >> >>> @if test ! -f a.tar.gz; then tar czf a.tar.gz ../dirB/b >> ../dirB/c && rm -f ../dirB/rebuild; fi >> >>> @if test -f ../dirB/rebuild; then tar czf a.tar.gz ../dirB/b >> ../dirB/c && rm ../dirB/rebuild; fi >> >>> После чего возникает резонный вопрос. А make тут зачем? По условию >>> задачи? Задача-то на sh решена... >> >> Задча уже решена базовыми средствами BSD make-а красиво и эффективно. >> Просто вы, мсье, ищете себе проблемы там, где их нет. >> Не нужно этого делать. А вот тот за тот мусор, что я оставил вверху, >> руки бы поотрывал. > Как воспользоваться вашим решением в Debian? Какая проблема стоит? -- Best regards, Aleksey Cheusov. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Viking и realtime gps
10/2/2008, <[EMAIL PROTECTED]>: >> > Решил попробовать viking - классный такой google earth под линукс. GPS у >> > меня нет. >> >> Ежели нужен Google Earth под Linux, то и надо брать Google Earth под >> Linux. С гугля. > >Раньше искал и что-то не нашёл. Последняя не-бета версия: http://dl.google.com/earth/client/GE4/release_4_2/GoogleEarthLinux.bin Правда, к сожалению, под Linux не доступен апгрейд GoogleEarth до GoogleEarthPlus. В последнюю можно было бы грузить трэки из GPS. С уважением, Алексей Мишустин -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Чем плох рекурсивный make?
Dmitry E. Oboukhov -> debian-russian@lists.debian.org @ Thu, 2 Oct 2008 12:11:21 +0400: AC> понимаешь в чем дело, в том что если бы make догадывалось об этом то ей AC> пришлось бы перестать быть универсальным инструментом (вон выше по ветке AC> собирают PDF например, а какой там DEBUG) и стала бы AC> узкоспециализированным. а это неправильно. AC Дебуга там нет, но вообще-то pdftex-у в командную строку тоже много чего AC интересного запихать можно. Во всяких bras и makepp эта задача решена AC посредством запоминания того, какой именно командой данный target AC пересобирался последний раз. И если текущая команда получается другая, AC target считается устаревшим. AC>>> ну так я говорю, значит просто надо DEBUG поставить в зависимости AC>>> и далее проблема станет решенной AC>> Надо _сложно_ поставить в зависимости DEBUG. Иначе оно будет AC>> пересобирать всё каждый раз. Подозреваю, что сделать это можно, но AC>> вплотную еще не думал. Есть шанс, что и не получится. DEO> а мое решение сложно? А это не решение. DEO> то есть пишем в Makefile DEO> DEBUG ?= 0 # кстати не помню ?= это GNUmake или вообще make? хез DEO> ... DEO> debug_depends: DEO> test -e $@ || echo $(DEBUG) > $@ DEO> test "`cat [EMAIL PROTECTED]" = "$(DEBUG)" || echo $(DEBUG) > $@ DEO> и дальше ставим зависимость от debug_depends DEO> то есть получится что make его перезаписывать будет только при смене DEO> переменных DEO> и соответственно в зависимости: DEO> %.o: %.c debug_depends Начнем с того, что make его вообще перезаписывать не будет. Он его запишет один раз, и все. Ты б хоть проверил свое "решение", прежде чем предлагать. Ладно б требовалось подобрать к нему хитрую последовательность команд, чтобы увидеть, что не работает, а то ведь тупее некуда - make да make DEBUG=1... -- Artem Chuprina RFC2822: Jabber: [EMAIL PROTECTED] The effort of using machines to mimic the human mind has always struck me as rather silly. I would rather use them to mimic something better -- Edsger Dijkstra -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Чем плох рекурсивный make?
Dmitry E. Oboukhov -> debian-russian@lists.debian.org @ Thu, 2 Oct 2008 12:53:16 +0400: AC>> Там правка правке рознь. Добавил #include - уже вынь да положь configure. DEO> смотря какой include :) DEO> если на себя же (свой проект) то да :) Ну, этого уже достаточно. Т.е. какие именно операции редактирования могут обойтись без configure, а какие нет - определяется уже совсем не так просто... DEO> а если на тот что в /usr лежит, то запуск configure можно в долгий DEO> ящик откладывать :) Если на тот, что в /usr, то надо, вообще говоря, немедленно править configure.in, а не просто запускать configure... AC>>> первый пункт в каком-то *make удобно реализован? только так чтобы сборка AC>>> не становилась узкоспециализированной AC>> Насколько я знаю, задача добычи зависимостей из makefile как минимум AC>> весьма сложна. Подозреваю, что неразрешима. DEO> подозреваю что разрешима DEO> поскольку make эти зависимости строит, то есть можно ее допатчить чтобы DEO> она их выводила в удобоваримом виде (она и сейчас умеет их вывести, но DEO> рекурсивные ревызовы сейчас она не умеет) Скажем так, для этого придется провести сборку. На самом деле, да. dry run выдает ненадежный результат. AC Что для данного применения плохо, но приемлемо. Для целей AC разработки же - скорее неприемлемо. AC>>> для целей разработки есть авторский makefile :) AC>> "Я и есть автор". Переделанная цитата из известного анекдота. DEO> когда ты автор сделать depends.mk тебе труда не составит В нетривиальном случае - еще как составит. Реально, да. Но труда много. -- Artem Chuprina RFC2822: Jabber: [EMAIL PROTECTED] Вот .NET и Mono - это современные технологии. В смысле - сырые и глюкавые. Victor Wagner в <[EMAIL PROTECTED]> -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: make contest
AC .include
>>> Ты решал не ту задачу. Решил ты ее или нет, я уж не могу сказать,
>>> поскольку непонятно, какую решал, но решал - не ту.
AC>> Ну ёпрст 8-) Я решил ту задачу, именно ту - строю пакет из бинарей,
AC>> которые строятся из .с файлов. При желании построить пакет
AC>> измененные .c таки учитываются, и перед построением пакета строятся
AC>> перестраиваются бинари. Дописать pkg/Makefile ты и сам в состоянии.
> А я не ставил задачу "построить пакет". Если кто не заметил.
> Я просто оставил один аспект реальной задачи и максимально упростил
> модель. Могу показать полную. Это, правда, будет довольно длинное
> письмо...
Задача стояла построить _зависящую_ цель (пакет) при измениях в
исходных файлах _зависимых_ целей (конкретные программы). Эта задача решена.
Но решения ты не понял. Ладно, я расшифрую - решение в том, чтобы
unconditionally запустить make последовательно вначале для зависимостей,
затем для главной задачи - именно это делает bsd.subdir.mk.
Обрати внимание на директиву .WAIT, это для make -jN.
Вот недостающее звено, которое мне к вечеру было просто лень реализовывать.
pkg/Makefile:
.PHONY: all
all : pkg.tgz
pkg.tgz : ../projA/a ../projB/b
tar -xfz ${.TARGET} ${.ALLSRC}
Решение, которое ты ожидал увидеть я делать не буду, это банальное
переписывание Makefile-а с одного диалекта на другой. Мне это не
интересно.
В свою очередь я тоже могу привести немного более длинный пример тоже
из реальной жизни. Каркас для родного мне dictd, где есть библиотека
(.so), общий код для екзешников и собственно сами екзешники.
--
Best regards, Aleksey Cheusov.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: make contest
2 октября 2008 г. 15:52 пользователь Aleksey Cheusov <[EMAIL PROTECTED]> написал: > >> >>> make -C ../dirB > >> >>> @if test ! -f a.tar.gz; then tar czf a.tar.gz ../dirB/b > ../dirB/c && rm -f ../dirB/rebuild; fi > >> >>> @if test -f ../dirB/rebuild; then tar czf a.tar.gz > ../dirB/b ../dirB/c && rm ../dirB/rebuild; fi > >> > >>> После чего возникает резонный вопрос. А make тут зачем? По условию > >>> задачи? Задача-то на sh решена... > >> > >> Задча уже решена базовыми средствами BSD make-а красиво и эффективно. > >> Просто вы, мсье, ищете себе проблемы там, где их нет. > >> Не нужно этого делать. А вот тот за тот мусор, что я оставил вверху, > >> руки бы поотрывал. > >> Как воспользоваться вашим решением в Debian? > > Какая проблема стоит? Испробовать ваш вариант с bmake в Debian. В lenny я его не нашёл. -- Regards, Yuri Kozlov
Re: make contest
AC>>> Ну вот когда у человека накапливается к make десяток претензий подобного AC>>> рода в _разных_ местах - он и пишет заменитель... Потому что десяток - AC>>> это уже проще заменить, чем исправить. AC>> но я пока не видел УНИВЕРСАЛЬНОГО заменителя AC>> да типа там функций добавят, там других вкусностей AC>> а там типа все круто но скажем только для N видов проектов AC>> и все. AC>> в общем альтернативы-то нет :( AC> Ну, вот makepp, похоже, во всяком случае не слабее. Т.е. везде, где AC> работает make, его хватит. bras тоже. За питоновские варианты не AC> поручусь. и проблема автогена депендсов везде решена? -- ... mpd is off . ''`. Dmitry E. Oboukhov : :’ : email: [EMAIL PROTECTED] jabber://[EMAIL PROTECTED] `. `~’ GPGKey: 1024D / F8E26537 2006-11-21 `- 1B23 D4F8 8EC0 D902 0555 E438 AB8C 00CF F8E2 6537 signature.asc Description: Digital signature
Re: Организация корпорат ивного репоитория (apt-move)
Илья Демьянов пишет: Ситуация такая: в оффисе сидят несколько человек на lenny и постоянно делают aptitude update => aptitude upgrade или просто доустанавливают какое-то ПО. Соответственно тянут траффик. Посмотрите в сторону apt-cacher. Использую больше года - нареканий нет -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Нужен ли bash
AC>> Да переносимость очевидна. shquote - это open source, 2-closure BSD AC>> license. Если у вас ее нет, это сами знаете чьи проблемы. > По этой логике переносима любая виндовая программа - эмулятор же есть, > поставить можно... Не надо передергивать. Если мне нужна программа X, которая требует для своей работы программу Y, _МОЯ_ задача раздобыть таки программу Y, поставщик программы X (автор) должен прямым текстом заявить "мне нужна программа Y", что я и сделал. То же самое касается библиотек перла, тикля, руби и всех без исключения. > Я правильно понимаю, что shquote рассчитана на квотинг только BSD'шного > шелла? Нет в природе никакого BSD-шного шела. У всех *BSD шелы разные. Квотинг же для всех шелов одинаковый. Или докажи мне обратное. > Вскрываться вроде не вскрывается... Что не вскрывается? -- Best regards, Aleksey Cheusov. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: make contest
Aleksey Cheusov -> debian-russian@lists.debian.org @ Thu, 02 Oct 2008 15:05:17 +0300: AC> .include Ты решал не ту задачу. Решил ты ее или нет, я уж не могу сказать, поскольку непонятно, какую решал, но решал - не ту. AC>>> Ну ёпрст 8-) Я решил ту задачу, именно ту - строю пакет из бинарей, AC>>> которые строятся из .с файлов. При желании построить пакет AC>>> измененные .c таки учитываются, и перед построением пакета строятся AC>>> перестраиваются бинари. Дописать pkg/Makefile ты и сам в состоянии. >> А я не ставил задачу "построить пакет". Если кто не заметил. >> Я просто оставил один аспект реальной задачи и максимально упростил >> модель. Могу показать полную. Это, правда, будет довольно длинное >> письмо... AC> Задача стояла построить _зависящую_ цель (пакет) при измениях в AC> исходных файлах _зависимых_ целей (конкретные программы). Эта задача решена. Задача подразумевала некоторую вполне конкретную раскладку по директориям. А не как понравится тебе. AC> Но решения ты не понял. Ладно, я расшифрую - решение в том, чтобы AC> unconditionally запустить make последовательно вначале для зависимостей, AC> затем для главной задачи - именно это делает bsd.subdir.mk. AC> Обрати внимание на директиву .WAIT, это для make -jN. Там не sub, там sibling. Впрочем, может быть, это и не важно. Но я не вижу, как твое решение масштабируется на реальную жизнь, когда надо будет в A получить актуальным не все, а только конкретный бинарник, когда в B изменился один исходник. Возможно, иррелевантный к этому бинарнику. Или один хедер, который к этому бинарнику вполне релевантен, но через один объектник из B, а не пятнадцать, которые там зависят от этого хедера. То есть, задачу ты не решил ни формально, ни фактически. По разным причинам, но не решил. -- Artem Chuprina RFC2822: Jabber: [EMAIL PROTECTED] Чем отличается свобода от независимости? Независимость - это когда за тебя не платят. А свобода - когда за тебя не думают. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: make contest
>>> Как воспользоваться вашим решением в Debian? >> >> Какая проблема стоит? > Испробовать ваш вариант с bmake в Debian. > В lenny я его не нашёл. В Debian есть pmake. Это древний вариант NetBSD make-а. Но лучше запакетить более свежий, и лучше под именем nbmake для предотвращения коллизий. Исходно, pmake - это AFAIK - это 4.4BSD parallel make. Поиграться же можно в принципе и с pmake-ом. Если хочется именно nbmake, исходники здесь http://www.crufty.net/ftp/pub/sjg/ mk scripts там же. P.S. Вообще, конечно, с BSD make-ами есть большой бардак. В том смысле, что make-и NetBSD/FreeBSD/OpenBSD вообще говоря разные. Наиболее известен "в миру" NetBSD make, поскольку его давно сделали портабельным посредством autotools. Там же идет разработка mk script-ов для разных платформ. Делается все это для портабельной же пакетной системы pkgsrc. Но в целом потребовать NetBSD make >= 20080101 и mk scripts >= 20080202 ничем не хуже, чем потребовать gmake >= 0.81 или scons >= x.y.z -- Best regards, Aleksey Cheusov. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: make contest
Dmitry E. Oboukhov -> debian-russian@lists.debian.org @ Thu, 2 Oct 2008 16:24:57 +0400: AC Ну вот когда у человека накапливается к make десяток претензий подобного AC рода в _разных_ местах - он и пишет заменитель... Потому что десяток - AC это уже проще заменить, чем исправить. AC>>> но я пока не видел УНИВЕРСАЛЬНОГО заменителя AC>>> да типа там функций добавят, там других вкусностей AC>>> а там типа все круто но скажем только для N видов проектов AC>>> и все. AC>>> в общем альтернативы-то нет :( AC>> Ну, вот makepp, похоже, во всяком случае не слабее. Т.е. везде, где AC>> работает make, его хватит. bras тоже. За питоновские варианты не AC>> поручусь. DEO> и проблема автогена депендсов везде решена? Это наиболее тяжкая часть, но по сравнению с make оно гораздо лучше во всех. Подробности я не смотрел, и подозреваю, что полностью корректного решения нет ни в одном. Но во всяком случае грабли, по которым ходит make, там убраны. -- Artem Chuprina RFC2822: Jabber: [EMAIL PROTECTED] Ну какая работа со строками может быть в языке, название которого является не строкой, а символом? Sergue E. Leontiev в <[EMAIL PROTECTED]> -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Чем плох ре курсивный make?
AC>> DEBUG ?= 0 # кстати не помню ?= это GNUmake или вообще make? хез AC>> ... AC>> debug_depends: AC>> test -e $@ || echo $(DEBUG) > $@ AC>> test "`cat [EMAIL PROTECTED]" = "$(DEBUG)" || echo $(DEBUG) > $@ AC>> и дальше ставим зависимость от debug_depends AC>> то есть получится что make его перезаписывать будет только при смене AC>> переменных AC>> и соответственно в зависимости: AC>> %.o: %.c debug_depends AC> Начнем с того, что make его вообще перезаписывать не будет. Он его AC> запишет один раз, и все. а ну да и правда, надо это в shell выносить, либо в цель .PHONY, которая всегда будет выполняться: DEBUG ?= 0 DEBUG_FILE = tmp/debug SRC = test.pl TARGET = tmp/$(SRC) all: debug_dep $(TARGET) $(DEBUG_FILE): debug_dep $(TARGET): $(DEBUG_FILE) $(SRC) cat $(SRC) > $(TARGET) debug_dep: @test -e $(DEBUG_FILE) || echo $(DEBUG) > $(DEBUG_FILE) @test "`cat $(DEBUG_FILE)`" = "$(DEBUG)" || echo $(DEBUG) > $(DEBUG_FILE) .PHONY: debug_dep и работает: apache:[~]$ make DEBUG=0 apache:[~]$ make DEBUG=0 apache:[~]$ make DEBUG=1 cat test.pl > tmp/test.pl apache:[~]$ make DEBUG=1 apache:[~]$ make DEBUG=0 cat test.pl > tmp/test.pl apache:[~]$ make DEBUG=0 правда не пишет про то что "цель не требует выполнения команд", потому что реально команды выполняет. если хочется совсем уж короткой работы то так: DEBUG ?= 0 DEBUG_FILE = tmp/debug SRC = test.pl TARGET = tmp/$(SRC) $(shell \ test -e $(DEBUG_FILE) || echo $(DEBUG) > $(DEBUG_FILE); \ test "`cat $(DEBUG_FILE)`" = "$(DEBUG)" || echo $(DEBUG) > $(DEBUG_FILE) \ ); all: $(TARGET) $(TARGET): $(DEBUG_FILE) $(SRC) cat $(SRC) > $(TARGET) и работа: apache:[~]$ make DEBUG=1 make: Цель `all' не требует выполнения команд. apache:[~]$ make DEBUG=1 make: Цель `all' не требует выполнения команд. apache:[~]$ make DEBUG=0 cat test.pl > tmp/test.pl apache:[~]$ make DEBUG=0 make: Цель `all' не требует выполнения команд. apache:[~]$ make DEBUG=0 make: Цель `all' не требует выполнения команд. apache:[~]$ make DEBUG=1 cat test.pl > tmp/test.pl apache:[~]$ make DEBUG=1 make: Цель `all' не требует выполнения команд. apache:[~]$ make DEBUG=1 make: Цель `all' не требует выполнения команд. AC> Ты б хоть проверил свое "решение", прежде чем предлагать. да, я собственно шеллскрипт (идею) предлагал, а так сорри действительно не проверил :( а так вот в вышеприведенном именно этот скрипт и работает :) -- ... mpd is off . ''`. Dmitry E. Oboukhov : :’ : email: [EMAIL PROTECTED] jabber://[EMAIL PROTECTED] `. `~’ GPGKey: 1024D / F8E26537 2006-11-21 `- 1B23 D4F8 8EC0 D902 0555 E438 AB8C 00CF F8E2 6537 signature.asc Description: Digital signature
Re: Нужен ли bash
Aleksey Cheusov -> debian-russian@lists.debian.org @ Thu, 02 Oct 2008 15:58:58 +0300: AC>>> Да переносимость очевидна. shquote - это open source, 2-closure BSD AC>>> license. Если у вас ее нет, это сами знаете чьи проблемы. >> По этой логике переносима любая виндовая программа - эмулятор же есть, >> поставить можно... AC> Не надо передергивать. Если мне нужна программа X, которая требует AC> для своей работы программу Y, _МОЯ_ задача раздобыть таки программу Y, AC> поставщик программы X (автор) должен прямым текстом заявить "мне нужна AC> программа Y", что я и сделал. То же самое касается библиотек перла, AC> тикля, руби и всех без исключения. >> Я правильно понимаю, что shquote рассчитана на квотинг только BSD'шного >> шелла? AC> Нет в природе никакого BSD-шного шела. У всех *BSD шелы разные. AC> Квотинг же для всех шелов одинаковый. Или докажи мне обратное. Доказываю. man zshoptions /EXTENDED_GLOB По крайней мере, в некоторых режимах квотинга у zsh надо квотить больше символов. >> Вскрываться вроде не вскрывается... AC> Что не вскрывается? Банка. В смысле, получить из указанной тобой конструкции исполнение команды мне не удалось. -- Artem Chuprina RFC2822: Jabber: [EMAIL PROTECTED] русская народная глупость Кнышев -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: make contest
AC>> Задача стояла построить _зависящую_ цель (пакет) при измениях в AC>> исходных файлах _зависимых_ целей (конкретные программы). Эта AC>> задача решена. > Задача подразумевала некоторую вполне конкретную раскладку по > директориям. А не как понравится тебе. Извини подвинься. Вот уж каталоги я будут делать так, как удобно мне :) В идеологии mk scripts: один проект (екзешник или библиотека) - один каталог. Можно сделать как угодно, но оно того не стоит. И это ОЧЕНЬ удобно. > Но я не вижу, как твое решение масштабируется на реальную жизнь, > когда надо будет в A получить актуальным не все, а только конкретный > бинарник, когда в B изменился один исходник. Про каталоги - смотри выше. А масштабируется все прекрасно - дописыванием зависимостей между _проектами_, то есть фактически нужно задать граф зависимостей, повторюсь, между проектами. Реальный небольшой пример, в котором 1) dictd/dict/dictfmt/dictzip независимы 2) libmaa и dict_common независимы 1) dictd/dict/dictfmt/dictzip линкуются с libmaa и dict_common ./Makefile: .PHONY: dict dictd dictfmt dictzip dict dictd dictfmt dictzip: SUBDIR="libmaa dict_common .WAIT $@" $(MAKE) all .include Для ОЧЕНЬ больших вот таких вот графов естественно пишется отдельный подмодуль, который будет этот граф строить автоматом. Более строго: по графу, заданному списком ребер (проект A зависит от проекта B), нужно найти для заданной вершины (проекта) все проекты, от которых он зависит (сущестсвует путь от ... до заданной вершины), затем дернуть $(MAKE) all с нужным SUBDIR. Как это работает. 0 dictd_bsd_make>bmake dictd SUBDIR="libmaa dict_common dictd" /usr/pkg/bin/bmake all all ===> libmaa all ===> dict_common all ===> dictd 0 dictd_bsd_make>touch libmaa/1.c 0 dictd_bsd_make>bmake dictfmt SUBDIR="libmaa dict_common dictfmt" /usr/pkg/bin/bmake all all ===> libmaa gcc -O2 -Werror -c 1.c gcc -O2 -Werror -c -pg 1.c -o 1.po gcc -O2 -Werror -c -fPIC -DPIC 1.c -o 1.so building standard maa library ar cq libmaa.a 1.o 2.o 3.o ranlib libmaa.a building profiled maa library ar cq libmaa_p.a 1.po 2.po 3.po ranlib libmaa_p.a building shared object maa library ar cq libmaa_pic.a 1.so 2.so 3.so ranlib libmaa_pic.a building shared maa library (version 2.0.3) ld -shared -soname libmaa.so.2 -o libmaa.so.2.0.3--whole-archive libmaa_pic.a --no-whole-archive ln -sf libmaa.so.2.0.3 libmaa.so.2.tmp mv -f libmaa.so.2.tmp libmaa.so.2 ln -sf libmaa.so.2.0.3 libmaa.so.tmp mv -f libmaa.so.tmp libmaa.so all ===> dict_common all ===> dictfmt gcc -L../dict_common -L../libmaa -o dictfmt dictfmt.o -ldict_common -lmaa 0 dictd_bsd_make>bmake dictfmt SUBDIR="libmaa dict_common dictfmt" /usr/pkg/bin/bmake all all ===> libmaa all ===> dict_common all ===> dictfmt 0 dictd_bsd_make>touch dict_common/3.c 0 dictd_bsd_make>bmake dict SUBDIR="libmaa dict_common dict" /usr/pkg/bin/bmake all all ===> libmaa all ===> dict_common gcc -O2 -Werror -c 3.c gcc -O2 -Werror -c -pg 3.c -o 3.po building standard dict_common library ar cq libdict_common.a 1.o 2.o 3.o ranlib libdict_common.a building profiled dict_common library ar cq libdict_common_p.a 1.po 2.po 3.po ranlib libdict_common_p.a all ===> dict gcc -L../dict_common -L../libmaa -o dict dict.o -ldict_common -lmaa 0 dictd_bsd_make> > То есть, задачу ты не решил ни формально, ни фактически. По разным > причинам, но не решил. Если ты АБСОЛЮТНО уверен в том, что ты Д'Артаньян, а остальные все пианисты, и в том, что make твою задачу решить не в состоянии, тогда нечего задавать вопросы публично. Можешь пребывать в своем неведении и дальше. Мне от этого ни холодно ни жарко. Третий раз я повторять не стану. P.S. Для демонстрации собственно лаконичности и простоты. libmaa/Makefile (и это собственно все, что нужно для .so): LIB=maa SRCS= 1.c 2.c 3.c # etc. SHLIB_MAJOR=2 SHLIB_MINOR=0 SHLIB_TEENY=3 .include dict_common/Makefile (статическая либа): LIB=dict_common SRCS= 1.c 2.c 3.c # etc. MKPIC= no # we build static library .include dict/Makefile (требует libmaa и статическую dict_common): PROG= dict .include "../dict_common/Makefile.inc" .include "../libmaa/Makefile.inc" .include dict_common/Makefile.inc: LDFLAGS+= -L../dict_common LDADD+= -ldict_common DPADD+= ../dict_common/libdict_common.a -- Best regards, Aleksey Cheusov. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Чем плох рекурсивный make?
Dmitry E. Oboukhov -> debian-russian@lists.debian.org @ Thu, 2 Oct 2008 17:15:32 +0400: AC>>> DEBUG ?= 0 # кстати не помню ?= это GNUmake или вообще make? хез AC>>> ... AC>>> debug_depends: AC>>> test -e $@ || echo $(DEBUG) > $@ AC>>> test "`cat [EMAIL PROTECTED]" = "$(DEBUG)" || echo $(DEBUG) > $@ AC>>> и дальше ставим зависимость от debug_depends AC>>> то есть получится что make его перезаписывать будет только при смене AC>>> переменных AC>>> и соответственно в зависимости: AC>>> %.o: %.c debug_depends AC>> Начнем с того, что make его вообще перезаписывать не будет. Он его AC>> запишет один раз, и все. DEO> а ну да и правда, надо это в shell выносить, либо в цель .PHONY, которая DEO> всегда будет выполняться: DEO> DEBUG ?= 0 DEO> DEBUG_FILE = tmp/debug DEO> SRC = test.pl DEO> TARGET = tmp/$(SRC) DEO> all: debug_dep $(TARGET) DEO> $(DEBUG_FILE): debug_dep DEO> $(TARGET): $(DEBUG_FILE) $(SRC) DEO> cat $(SRC) > $(TARGET) DEO> debug_dep: DEO> @test -e $(DEBUG_FILE) || echo $(DEBUG) > $(DEBUG_FILE) DEO> @test "`cat $(DEBUG_FILE)`" = "$(DEBUG)" || echo $(DEBUG) > $(DEBUG_FILE) DEO> .PHONY: debug_dep DEO> и работает: DEO> apache:[~]$ make DEBUG=0 DEO> apache:[~]$ make DEBUG=0 DEO> apache:[~]$ make DEBUG=1 DEO> cat test.pl > tmp/test.pl DEO> apache:[~]$ make DEBUG=1 DEO> apache:[~]$ make DEBUG=0 DEO> cat test.pl > tmp/test.pl DEO> apache:[~]$ make DEBUG=0 DEO> правда не пишет про то что "цель не требует выполнения команд", DEO> потому что реально команды выполняет. DEO> если хочется совсем уж короткой работы то так: DEO> DEBUG ?= 0 DEO> DEBUG_FILE = tmp/debug DEO> SRC = test.pl DEO> TARGET = tmp/$(SRC) DEO> $(shell \ DEO> test -e $(DEBUG_FILE) || echo $(DEBUG) > $(DEBUG_FILE); \ DEO> test "`cat $(DEBUG_FILE)`" = "$(DEBUG)" || echo $(DEBUG) > $(DEBUG_FILE) \ DEO> ); DEO> all: $(TARGET) DEO> $(TARGET): $(DEBUG_FILE) $(SRC) DEO> cat $(SRC) > $(TARGET) DEO> и работа: DEO> apache:[~]$ make DEBUG=1 DEO> make: Цель `all' не требует выполнения команд. DEO> apache:[~]$ make DEBUG=1 DEO> make: Цель `all' не требует выполнения команд. DEO> apache:[~]$ make DEBUG=0 DEO> cat test.pl > tmp/test.pl DEO> apache:[~]$ make DEBUG=0 DEO> make: Цель `all' не требует выполнения команд. DEO> apache:[~]$ make DEBUG=0 DEO> make: Цель `all' не требует выполнения команд. DEO> apache:[~]$ make DEBUG=1 DEO> cat test.pl > tmp/test.pl DEO> apache:[~]$ make DEBUG=1 DEO> make: Цель `all' не требует выполнения команд. DEO> apache:[~]$ make DEBUG=1 DEO> make: Цель `all' не требует выполнения команд. AC>> Ты б хоть проверил свое "решение", прежде чем предлагать. DEO> да, я собственно шеллскрипт (идею) предлагал, а так сорри DEO> действительно не проверил :( DEO> а так вот в вышеприведенном именно этот скрипт и работает :) Ну, это лучше, да. Причем мне, честно говоря, сходу даже было непонятно, почему работает первое решение... Пришлось гонять make -d и разбираться. А теперь вот так вот для каждой переменной, которую можно указать мейкфайлу, и у каждой цели, на сборку которой эта переменная влияет... И пару раз ошибиться... Нет, все-таки такие вещи должен отслеживать сам инструмент... -- Artem Chuprina RFC2822: Jabber: [EMAIL PROTECTED] Как в notepad тексты редактировать? Руками каждую букву набирать, что ли? (c)vitus -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Viking и realtime gps
В Чтв, 02/10/2008 в 15:59 +0400, Mishustin Alexey пишет: > 10/2/2008, <[EMAIL PROTECTED]>: > > >> > Решил попробовать viking - классный такой google earth под линукс. GPS у > >> > меня нет. > >> > >> Ежели нужен Google Earth под Linux, то и надо брать Google Earth под > >> Linux. С гугля. > > > >Раньше искал и что-то не нашёл. > > Последняя не-бета версия: > > http://dl.google.com/earth/client/GE4/release_4_2/GoogleEarthLinux.bin > > Правда, к сожалению, под Linux не доступен апгрейд GoogleEarth до > GoogleEarthPlus. В последнюю можно было бы грузить трэки из GPS. Спасибо. -- Покотиленко Костик <[EMAIL PROTECTED]> -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Etch и чипсеты
В Чтв, 02/10/2008 в 17:23 +0700, Sergey A. Bykanov пишет: > Покотиленко Костик пишет: > > В Чтв, 02/10/2008 в 12:30 +0700, Sergey A. Bykanov пишет: > > > >> Подскажите где можно посмотреть о поддерживаемых в Etch материнках и > >> чипсетах? Так же интересует поддержка встроенного в чипсеты Intel Raid 5. > >> > > > > "встроенного в чипсеты Intel Raid 5" бывает только (иначе очень дорого) > > fakeraid. Softraid по мнениям многих лучше использовать вместо fakeraid, > > поэтому его поддержка в принципе не нужна. > > > > Про чипы не скажу точно, до 965-го по моему. Хотя, если использовать > > ядро etch'n'half (2.6.22) то наверно и старше > Спасибо за ответ. Но в etch'n'half вроде 2.6.24? Уже может быть... -- Покотиленко Костик <[EMAIL PROTECTED]> -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Viking и realtime gps
Покотиленко Костик пишет: > В Чтв, 02/10/2008 в 14:06 +0400, Victor Wagner пишет: >> >> Ежели нужен Google Earth под Linux, то и надо брать Google Earth под >> Linux. С гугля. > > Раньше искал и что-то не нашёл. http://packages.debian.org/googleearth -- Dmitri Samsonov -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Чем плох ре курсивный make?
AC> Ну, это лучше, да. Причем мне, честно говоря, сходу даже было AC> непонятно, почему работает первое решение... Пришлось гонять make -d и AC> разбираться. AC> А теперь вот так вот для каждой переменной, которую можно указать AC> мейкфайлу, и у каждой цели, на сборку которой эта переменная влияет... AC> И пару раз ошибиться... AC> Нет, все-таки такие вещи должен отслеживать сам инструмент... если учесть что данная задача как правило редкая (обычно debug включается в чем-то вроде configure), то если сам инструмент будет пересобирать проект в зависимости от смены переменных, то он рискует начать пересобирать его от простой правки makefile в местах независящих от каких-либо переменных. я не знаю как он должен работать чтобы 1. услужливость не переходила в навязчивость с которой придется бороться 2. без внешних файлов в которых хранить состояние предыдущей сборки -- ... mpd is off . ''`. Dmitry E. Oboukhov : :’ : email: [EMAIL PROTECTED] jabber://[EMAIL PROTECTED] `. `~’ GPGKey: 1024D / F8E26537 2006-11-21 `- 1B23 D4F8 8EC0 D902 0555 E438 AB8C 00CF F8E2 6537 signature.asc Description: Digital signature
Re: Нужен ли bash
>>> Я правильно понимаю, что shquote рассчитана на квотинг только BSD'шного >>> шелла? AC>> Нет в природе никакого BSD-шного шела. У всех *BSD шелы разные. AC>> Квотинг же для всех шелов одинаковый. Или докажи мне обратное. > Доказываю. man zshoptions > /EXTENDED_GLOB У тебя сомнения на счет того, что я тебе отвечу в этом случае? 8-) Да, именно. Это ваши проблемы. Если вы используете расширение, идущее вразрез со стандартным поведением, будьте готовы к тому, что инструментарий, расчитанный на нормальный sh с вашим zsh в этих режимах работать не будет. Напишите себе zshquote и да пребудет с вам ктулху. -- Best regards, Aleksey Cheusov. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: console-cyrillic init dependencies
Спасибо за подсказку! В принципе, у самой команды cyr есть опция для настройки кириллицы на другом терминале: cyr --ttys='/dev/ttyX' И она даже вполне работает, только вот запускаться не из консоли (а, например, из X-ового эмулятора) она все равно категорически отказывается. А нет какого-нибудь метода запустить из консоли только этот скрипт не выключая CONCURRENCY=shell? Михаил.
Re: make contest
On 2008.10.02 at 16:50:27 +0300, Aleksey Cheusov wrote: > AC>> Задача стояла построить _зависящую_ цель (пакет) при измениях в > AC>> исходных файлах _зависимых_ целей (конкретные программы). Эта > AC>> задача решена. > > > Задача подразумевала некоторую вполне конкретную раскладку по > > директориям. А не как понравится тебе. > > Извини подвинься. Вот уж каталоги я будут делать так, как удобно мне :) > В идеологии mk scripts: один проект (екзешник или библиотека) - Ну и? Поменяли мы один файлик в библиотеке. Теперь надо пересобрать четыре экзешника (каждый, естественно, в своем каталоге), которые с этой библиотекой линкуются. Статически. Поменяли другой - теперь надо пересобрать только два экзешника из этих четырех, потому что на два других это изменение не влияет. > один каталог. Можно сделать как угодно, но оно того не стоит. > И это ОЧЕНЬ удобно. BSD-шному админу это очень удобно. Который исходников не правит. А у разработчика проблемы - только тесты на всю эту компанию взаимосвязанных проектов бегут час. Так что если сборка будет занимать еще два часа, то за день больше двух изменений не сделаешь. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: make contest
Aleksey Cheusov -> debian-russian@lists.debian.org @ Thu, 02 Oct 2008 16:50:27
+0300:
AC>>> Задача стояла построить _зависящую_ цель (пакет) при измениях в
AC>>> исходных файлах _зависимых_ целей (конкретные программы). Эта
AC>>> задача решена.
>> Задача подразумевала некоторую вполне конкретную раскладку по
>> директориям. А не как понравится тебе.
AC> Извини подвинься. Вот уж каталоги я будут делать так, как удобно мне :)
AC> В идеологии mk scripts: один проект (екзешник или библиотека) -
AC> один каталог. Можно сделать как угодно, но оно того не стоит.
AC> И это ОЧЕНЬ удобно.
Нет, если ты можешь _естественно_ организовать проект по схеме "один
проект - один файл на выходе", то да, наверное...
Но это, насколько я могу понять, исключает unit tests (там по жизни
несколько бинарников, да еще с шансами собираться и работать на разных
платформах). Делать отдельный проект ("вот это - хрень, а вот это -
тесты на хрень")? А если мне надо пересобрать и перепрогнать один из
тестовых бинарников?
Ну, то есть, допустим, у меня будет не project и project/t, а project и
project_tests. Сиблинги. Ну, допустим, раз они сиблинги, даже можно
сделать ../Makefile. И вот мне надо пересобрать один из тестовых
бинарников после правки исходника в проекте, и прогнать его штатным
образом. То есть создав ему развесистую среду и передав несколько
штатных параметров. Общая длина командной строки - символов 200.
Сейчас у меня, с гнутым мейком, такой запуск делается отдельной целью в
мейкфайле тестов. Она умеет пересобрать _свой_ бинарь. Я нахожусь при
этом в директории с тестами (я же хочу прогнать тест после правки, и
только этот мейкфайл в курсе, как прогнать этот конкретный тест).
Разумеется, я хочу все это сделать одной командой.
В принципе, я готов на make all в собственно проекте, хотя тоже без
лишней необходимости не хотелось бы. Но на прогон всех тестов я не
готов, это минут 40. На пересборку - тоже. Мне только один. И один
его прогон (при полном прогоне этот бинарь может гоняться не единожды).
Но обязательно - корректно. Т.е. с учетом изменений в проекте.
Это как будет сделано в случае с nbmake?
Делать отдельный проект под каждый прогон очень бы не хотелось... Ну,
то есть до такой степени не хотелось бы, что если такова идеология, то
ну его нафиг.
И сразу, чтоб два раза не вставать. А как у этих замечательных скриптов
с поддержкой кросс-компиляции? На одной и той же машине с "родной",
естественно. А с сосуществованием одновременно нескольких сборок под
разные платформы (исходники общие, раздаются по NFS - интересно,
естественно, состояние до коммита, посему набор исходников один)?
Гнутому мейку мы все руками объясняли (ой, какая там кривизна...), но у
него замечательных скриптов от вендора нету.
>> То есть, задачу ты не решил ни формально, ни фактически. По разным
>> причинам, но не решил.
AC> Если ты АБСОЛЮТНО уверен в том, что ты Д'Артаньян, а остальные все
AC> пианисты, и в том, что make твою задачу решить не в состоянии,
AC> тогда нечего задавать вопросы публично. Можешь пребывать в своем
AC> неведении и дальше. Мне от этого ни холодно ни жарко.
Ну, задачу-то я могу и дать. Ту самую, которую я не могу решить
средствами make. Там не только recursive, там еще и автогенерируемые
зависимости, и зависимость от параметров сборки (только что обсудили), и
пересборка после cvs up, и чего-то еще веселенького до кучи...
--
Artem Chuprina
RFC2822: Jabber: [EMAIL PROTECTED]
Пользователь юникса перестаёт быть пользователем юникса если после его
пользования пользованный юникс перестаёт быть юниксом. (с)
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Нужен ли bash
Aleksey Cheusov -> debian-russian@lists.debian.org @ Thu, 02 Oct 2008 17:15:12 +0300: Я правильно понимаю, что shquote рассчитана на квотинг только BSD'шного шелла? AC>>> Нет в природе никакого BSD-шного шела. У всех *BSD шелы разные. AC>>> Квотинг же для всех шелов одинаковый. Или докажи мне обратное. >> Доказываю. man zshoptions >> /EXTENDED_GLOB AC> У тебя сомнения на счет того, что я тебе отвечу в этом случае? 8-) AC> Да, именно. Это ваши проблемы. Если вы используете расширение, AC> идущее вразрез со стандартным поведением, будьте готовы к тому, что AC> инструментарий, расчитанный на нормальный sh с вашим zsh в этих AC> режимах работать не будет. Напишите себе zshquote и да пребудет с AC> вам ктулху. Так вот. Для tcl и perl мне ничего писать и даже собирать не надо. Оно и само не исполняет что попало как попало. by design. В отличие от sh, который by design как раз исполняет. -- Artem Chuprina RFC2822: Jabber: [EMAIL PROTECTED] Молодой, дикорастущий организм... -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: make contest
>> Извини подвинься. Вот уж каталоги я будут делать так, как удобно мне :) >> В идеологии mk scripts: один проект (екзешник или библиотека) - > Ну и? Поменяли мы один файлик в библиотеке. Теперь надо пересобрать > четыре экзешника (каждый, естественно, в своем каталоге), которые с этой > библиотекой линкуются. Статически. > Поменяли другой - теперь надо пересобрать только два экзешника из этих > четырех, потому что на два других это изменение не влияет. Я ТОЛЬКО ЧТО продемонстрировал, как решается эта проблема. С примерами и достаночно подробными на мой взгляд пояснениями. И решается очень элегантно и красиво, без единого костыля. Ты это пропустил. Вернись к письму на которое ты отвечал. >> один каталог. Можно сделать как угодно, но оно того не стоит. >> И это ОЧЕНЬ удобно. > BSD-шному админу это очень удобно. Который исходников не правит. > А у разработчика проблемы - только тесты на всю эту компанию > взаимосвязанных проектов бегут час. Так что если сборка будет занимать > еще два часа, то за день больше двух изменений не сделаешь. Переливание пустой информации. Еще раз: прочитай ВНИМАТЕЛЬНО пояснения, которые ты поскипал, и проанализируй примеры. Там показано решение поставленных вопросов. Эффективное, простое и очень красивое. P.S. И не надо мне расказывать про тесты, которые идут один час. Я вас умоляю. Мои распределенные на несколько серверов тесты крутятся сутками. Запустить полный regression test - это примерно как подготовиться к новому году. Час у них, блин. -- Best regards, Aleksey Cheusov. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Чем плох рекурсивный make?
Dmitry E. Oboukhov -> debian-russian@lists.debian.org @ Thu, 2 Oct 2008 18:10:28 +0400: AC>> Ну, это лучше, да. Причем мне, честно говоря, сходу даже было AC>> непонятно, почему работает первое решение... Пришлось гонять make -d и AC>> разбираться. AC>> А теперь вот так вот для каждой переменной, которую можно указать AC>> мейкфайлу, и у каждой цели, на сборку которой эта переменная влияет... AC>> И пару раз ошибиться... AC>> Нет, все-таки такие вещи должен отслеживать сам инструмент... DEO> если учесть что данная задача как правило редкая (обычно debug DEO> включается в чем-то вроде configure), У админа или мейнтейнера пакета. Разработчику оно надо гораздо чаще. И нет там никакого configure. Кроме того, там отнюдь не только debug. Там еще и текущая платформа до кучи (ага, автор makepp в курсе, что бывает такая схема разработки и тестирования...) DEO> то если сам инструмент будет пересобирать проект в зависимости от DEO> смены переменных, то он рискует начать пересобирать его от простой DEO> правки makefile в местах независящих от каких-либо переменных. я DEO> не знаю как он должен работать чтобы 1. услужливость не переходила DEO> в навязчивость с которой придется бороться 2. без внешних файлов в DEO> которых хранить состояние предыдущей сборки Условие "без внешних файлов" не ставится. Пусть с внешними, если ему так удобно. makepp вон удобно. Хочется "без геморроя и провокации ошибок разработчика". -- Artem Chuprina RFC2822: Jabber: [EMAIL PROTECTED] Кто первый встал, того и грабли Д. Белявский -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: make contest
AC Задача стояла построить _зависящую_ цель (пакет) при измениях в
AC исходных файлах _зависимых_ целей (конкретные программы). Эта
AC задача решена.
>>> Задача подразумевала некоторую вполне конкретную раскладку по
>>> директориям. А не как понравится тебе.
AC>> Извини подвинься. Вот уж каталоги я будут делать так, как удобно мне :)
AC>> В идеологии mk scripts: один проект (екзешник или библиотека) -
AC>> один каталог. Можно сделать как угодно, но оно того не стоит.
AC>> И это ОЧЕНЬ удобно.
> Нет, если ты можешь _естественно_ организовать проект по схеме "один
> проект - один файл на выходе", то да, наверное...
Один таргет файл условно. Есть понятие PROG - он один.
К нему можно добавить произвольное количество просто FILES
(mueller7.{dict,index})
или SCRIPTS (dictunformat.sh) и чего душе будет угодно.
PROG - это обычно екзешник или либа.
> Но это, насколько я могу понять, исключает unit tests
Нет, не отменяет.
Мухи отдельно, котлеты отдельно.
> (там по жизни
> несколько бинарников, да еще с шансами собираться и работать на разных
> платформах).
man bmake
/ .OBJDIR
/ MAKEOBJDIR
/ MACHINE
etc.
> Делать отдельный проект ("вот это - хрень, а вот это -
> тесты на хрень")?
Можно отдельным проектом, можно отдельным таргетом в зависимости от.
> А если мне надо пересобрать и перепрогнать один из
> тестовых бинарников?
В случае с несколькими полезными таргетами на каждый проект можно видоизменить
мое решение например так.
TRG?= all
.PHONY: dict dictd dictfmt dictzip
dict dictd dictfmt dictzip:
SUBDIR="libmaa dict_common $@" ${MAKE} ${TRG}
.include
Запускать так
bmake dict TRG=all_tests
Можно наоборот в переменную засунуть имя [под]проекта.
> Ну, то есть, допустим, у меня будет не project и project/t, а
> project и project_tests. Сиблинги. Ну, допустим, раз они сиблинги,
> даже можно сделать ../Makefile. И вот мне надо пересобрать один из
> тестовых бинарников после правки исходника в проекте, и прогнать его
> штатным образом.
Поставь проект "project_tests" в зависимость от проекта "проект".
Работать будет точно так же, как екзешник и либа.
Не принципиально.
> То есть создав ему развесистую среду и передав
> несколько штатных параметров. Общая длина командной строки -
> символов 200.
Какая разница, окружение передается вообще сорешенно прорачно.
env TEST_OPTS='options' TEST_ENV='oceans' bmake dict TRG=all_tests
где
dict/Makefile:
.PHONY: all_tests
all_tests : dict
env ${TEST_ENV} dict_test.sh ${TEST_OPTS}
> Сейчас у меня, с гнутым мейком, такой запуск делается отдельной целью в
> мейкфайле тестов.
> Она умеет пересобрать _свой_ бинарь.
Я уже ответил.
> В принципе, я готов на make all в собственно проекте, хотя тоже без
> лишней необходимости не хотелось бы. Но на прогон всех тестов я не
> готов, это минут 40.
разбей тесты на кучу подпроектов в зависимости от того, что они тестируют.
Далее каждому тесту - отдельный test_NNN/Makefile
И далее общий project_all_test/Makefile, объединяющий все тесты.
> Это как будет сделано в случае с nbmake?
Я уже ответил. Легко и непринужденно. Внимательно читаем непрочитанное
письмо. Принимаем идеологию "один проект - олдин каталог", это раз.
Пользуемся bsd.subdir.mk и вызываем $(MAKE) с модифицированной
переменной SUBDIR - два. Строим граф зависимостей между проектами,
по которому собственно и формируется SUBDIR - это три.
> И сразу, чтоб два раза не вставать. А как у этих замечательных скриптов
> с поддержкой кросс-компиляции?
NetBSD целиком и полностью строится на nbmake.
Собирается на всем что движется. Доподлинно собирается на FreeBSD и Linux.
То есть проблем никаких. Если есть где, то явно не в nbmake-е.
> На одной и той же машине с "родной", естественно. А с
> сосуществованием одновременно нескольких сборок под разные платформы
0 runawk>ls -la /tmp/runawk/
total 0
drwxr-xr-x 2 cheusov syntagma 40 2008-10-02 18:34 .
drwxrwxrwt 23 rootroot 740 2008-10-02 18:34 ..
0 runawk>env MAKEOBJDIR=/tmp/runawk bmake
gcc -O2 -Wall -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith
-Wno-uninitialized -Wreturn-type -Wcast-qual -Wpointer-arith -Wwrite-strings
-Wswitch -Wshadow -Werror -DAWK_PROG='"/usr/bin/awk"'
-DSTDIN_FILENAME='"/dev/stdin"' -DMODULESDIR='"/usr/local/share/runawk"'
-DRUNAWK_VERSION='"0.14.2"' -c /home/cheusov/prjs/runawk/runawk.c
gcc -o runawk runawk.o
pod2man -s 1 -r 'AWK Wrapper' -n runawk -c 'RUNAWK manual page'
/home/cheusov/prjs/runawk/runawk.pod > runawk.1
nroff -Tascii -mandoc runawk.1 > runawk.cat1
0 runawk>ls -la /tmp/runawk/
total 68
drwxr-xr-x 2 cheusov syntagma 120 2008-10-02 18:35 .
drwxrwxrwt 23 rootroot 740 2008-10-02 18:35 ..
-rwxr-xr-x 1 cheusov syntagma 20921 2008-10-02 18:35 runawk
-rw-r--r-- 1 cheusov syntagma 15655 2008-10-02 18:35 runawk.1
-rw-r--r-- 1 cheusov syntagma 12089 2008-10-02 18:35 runawk.cat1
-rw-r--r-- 1 cheusov syntagma 14516 2008-10-02 18:35 runawk.o
0 runawk>
Makefile на sf.net
> (исходники общие, разд
Re: Организация корпоративного репоитория (apt-move)
> Ситуация такая: в оффисе сидят несколько человек на lenny и постоянно > делают aptitude update => aptitude upgrade или просто доустанавливают > какое-то ПО. Соответственно тянут траффик. > > Я так понимаю, что apt-move берет из кеша загруженные пакеты и > формирут репозиторий. Можно ли как-то организовать, чтобы все эти > пользователи сливали бы все свои загруженные пакеты в единый каталог > (ftp? ssh?) и не расходовали зазря траффик на одинаковые пакеты? может проще сделать зеркало (при помощи к примеру apt-mirror), с которым уже и будут работать локальные пользователи? заодно и для еще чего пригодится... -- С уважением Константин aka dj_doom ICQ 102152 JID [EMAIL PROTECTED]
Re: Нужен ли bash
Hello Artem Chuprina! On Thu, 02 Oct 2008 12:07:32 +0400 you wrote: > Реальная. Перехожу с postfix на exim. У поцфикса есть ограничения, в > которые я уткнулся, в exim с ними вроде проще. Система не > тривиальная, там и SA, и антивирус, и релеинг в разных позах, включая > UUCP. Как это делают нормальные админы? Правильно, ставят новый MTA > рядом, но на другой порт, прикрытый файрволом, отлаживают > конфигурацию, после чего кладут старый MTA, меняют порт у нового, > запускают его в работу, запускают старый на разгребание очереди, > дожидаются, когда разгребет, сносят. > > Внимание, вопрос. Как это предлагается делать в Debian? Поднять в тестовом OVZ контейнере? -- Всего наилучшего! Григорий greg [at] anastasia [dot] ru Письмо отправлено: 2008/10/02 20:05 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Учетные системы
Какие учетные системы существуют для контроля раздачи трафика и его ограничения? И их достоинства и недостатки? Точно в любой момент статистику можно посмотреть с помощью "tc" (при htb дисциплине например ) - cpu совсем не грузит. -- Sincerely, Nicholas -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: делать копию файл а при каждом его обно влении (incron)
Stanislav Maslovski wrote: Есть, incron. Вот пытаюсь сделать копию файла 123 с добавлением даты, из командной строки получается: cp /home/user/1/123 /home/user/1/123.345.`date +%Y.%m.%d.%H:%M` а вот с помощью incron нет: создаю и редактирую файл /etc/incron.d/some_cp: /home/user/1/123 IN_MODIFY cp /home/user/1/123 /home/user/1/123.345 (работает - копирет файл при его изменении и добавляет 345 в имя) /home/user/1/123 IN_MODIFY cp /home/user/1/123 /home/user/1/123.345$DATE (добавляет просто слово "345.DATE" к имени) /home/user/1/123 IN_MODIFY cp /home/user/1/123 /home/user/1/123.345.`date +%Y.%m.%d.%H:%M` (неработает - нечего не копируется) Добавление с переменной в /ect/incron.conf DATE='date +%Y.%m.%d.%H:%M:%S' непомогает. Вопрос: как правильно копировать файл, из скрипта incron, с добавлением текущей даты и времени к имени файла ? -- Sincerely, Nicholas -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
как собрать avi из jpg
Есть директория с 6 файлами: img0.jpg - img6.jpg надо собрать из них avi (желательно по полсекунды на картинку). руководствуюясь статьей http://www.opennet.ru/base/sys/video.txt.html apt-get install mjpegtools , пробую делать: jpeg2yuv -f 25 -I p -j *.jpg > result.yuv или jpeg2yuv -f 25 -I p -j img%d.jpg > result.yuv в обоих случаях получаю: /temp/gena $ jpeg2yuv -f 25 -I p -j *.jpg > result.yuv INFO: [jpeg2yuv] Parsing & checking input files. INFO: [jpeg2yuv] YUV colorspace detected. INFO: [jpeg2yuv] Starting decompression INFO: [jpeg2yuv] Image dimensions are 600x404 INFO: [jpeg2yuv] Movie frame rate is: 25.00 frames/second INFO: [jpeg2yuv] Non-interlaced/progressive frames. INFO: [jpeg2yuv] Frame size: 600 x 404 INFO: [jpeg2yuv] Number of Loops 1 INFO: [jpeg2yuv] Now generating YUV4MPEG stream. INFO: [jpeg2yuv] Processing non-interlaced/interleaved img0.jpg, size 62506 zsh: segmentation fault jpeg2yuv -f 25 -I p -j *.jpg > result.yuv Вопрос: как собрать avi из jpg ? -- Sincerely, Nicholas -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
доступ к pc в сети 192.168... через соседнюю с реальным ip
Есть "pc1" в локальной сети с адресом eth0 192.168.1.3 он соединяется с удаленным сервером "server" openvpn (с диапазоном реальных адресов xx.xx.2.0/24) и получает адрес tap 192.168.1.3 "server" имеет настройку iptables: -A PREROUTING -d xx.xx.2.1 -j ACCEPT -A PREROUTING -d xx.xx.2.0/24 -j NETMAP --to 192.168.2.0/24 -A POSTROUTING -s 192.168.2.0/24 -j NETMAP --to xx.xx.2.0/24 таким образом "pc1" 192.168.1.3 "получает" внещний ip xx.xx.2.3 (и это работает): его ifconfig eth0inet addr:192.168.1.3 tap5inet addr:192.168.2.3 в той же локальной сети есть "pc2" с адресом eth0 192.168.1.4 и www сервисом на порту 8081, до которого надо достучатся "из вне". Для этого на pc1 создаются правила: -A PREROUTING --dst 192.168.2.3 -p tcp --dport 8081 -j DNAT --to-destination 192.168.1.4 -A POSTROUTING --src 192.168.1.4 -p tcp --sport 8081 -j SNAT --to-source 192.168.2.3:8081 Но они не работают - по адресу xx.xx.2.3:8081 страница не открывается. Вопрос: как правильно настроить iptables на ps1, что бы получить доступ к ps2:8081 "из вне" ? Спасибо. -- Sincerely, Nicholas -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: как собрать avi из jpg
Hello! В сообщении от Thursday 02 October 2008 23:57:03 Nicholas написал(а): > Вопрос: как собрать avi из jpg ? mplayer. Ключики не помню, но было дело, разбирал запись по кадрам и выбранные собирал в новую запись (не помню, почему не avidemux пользовал). Best regards, Alexey. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Нужен ли bash
Artem Chuprina wrote: > Grigory Fateyev -> debian-russian@lists.debian.org @ Thu, 2 Oct 2008 > 20:06:56 +0400: [snip] > GF> Поднять в тестовом OVZ контейнере? > > В Debian нет пригодного для этого ядра. Эээ... а зачем тогда -openvz ядро собрали в Debian? -- Eugene V. Lyubimkin aka JackYF, Ukrainian C++ developer. signature.asc Description: OpenPGP digital signature
Re: Нужен ли bash
Grigory Fateyev -> debian-russian@lists.debian.org @ Thu, 2 Oct 2008 20:06:56 +0400: >> Реальная. Перехожу с postfix на exim. У поцфикса есть ограничения, в >> которые я уткнулся, в exim с ними вроде проще. Система не >> тривиальная, там и SA, и антивирус, и релеинг в разных позах, включая >> UUCP. Как это делают нормальные админы? Правильно, ставят новый MTA >> рядом, но на другой порт, прикрытый файрволом, отлаживают >> конфигурацию, после чего кладут старый MTA, меняют порт у нового, >> запускают его в работу, запускают старый на разгребание очереди, >> дожидаются, когда разгребет, сносят. >> >> Внимание, вопрос. Как это предлагается делать в Debian? GF> Поднять в тестовом OVZ контейнере? В Debian нет пригодного для этого ядра. "Предлагается делать в Debian" все же подразумевает по умолчанию "средствами, имеющимися в дистрибутиве"... Не говоря уже о том, что это как-то совсем уже вырезание гланд через жопу автогеном... -- Artem Chuprina RFC2822: Jabber: [EMAIL PROTECTED] Реляционная база данных - это не единственный способ сделать дурацкий поиск. Victor Wagner -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Нужен ли bash
Eugene V. Lyubimkin -> debian-russian@lists.debian.org @ Fri, 03 Oct 2008 00:39:36 +0300: >> GF> Поднять в тестовом OVZ контейнере? >> >> В Debian нет пригодного для этого ядра. EVL> Эээ... а зачем тогда -openvz ядро собрали в Debian? Вот когда выйдет тот дистрибутив, в котором его собрали - тогда и будет ответ на этот вопрос... P.S. Нет, его собрали не за этим... -- Artem Chuprina RFC2822: Jabber: [EMAIL PROTECTED] When C++ is your hammer, everything looks like a thumb -- Latest seen from Steven M. Haflich, in c.l.l -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: делать копию файла при каждом его об новлении (incron)
Nicholas -> debian-russian@lists.debian.org @ Thu, 02 Oct 2008 14:11:36 -0400: >>> Есть, incron. N> Вот пытаюсь сделать копию файла 123 с добавлением даты, N> из командной строки получается: N> cp /home/user/1/123 /home/user/1/123.345.`date +%Y.%m.%d.%H:%M` N> а вот с помощью incron нет: N> создаю и редактирую файл /etc/incron.d/some_cp: N> /home/user/1/123 IN_MODIFY cp /home/user/1/123 /home/user/1/123.345 (работает N> - копирет файл при его изменении и добавляет 345 в имя) N> /home/user/1/123 IN_MODIFY cp /home/user/1/123 /home/user/1/123.345$DATE N> (добавляет просто слово "345.DATE" к имени) N> /home/user/1/123 IN_MODIFY cp /home/user/1/123 /home/user/1/123.345.`date N> +%Y.%m.%d.%H:%M` (неработает - нечего не копируется) N> Добавление с переменной в /ect/incron.conf N> DATE='date +%Y.%m.%d.%H:%M:%S' N> непомогает. N> Вопрос: как правильно копировать файл, из скрипта incron, с добавлением N> текущей даты и времени к имени файла ? Видимо, для начала стоит прочесть его документацию на предмет того, шеллом ли он выполняет указанную команду, или самостоятельно. Во втором случае - написать скрипт. -- Artem Chuprina RFC2822: Jabber: [EMAIL PROTECTED] Программы на Haskell настолько ленивы, что по умолчанию вообще не хотят работать. -- http://absurdopedia.wikia.com/wiki/Haskell -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: доступ к pc в сети 192.168... через соседнюю с реальным ip
Nicholas -> debian-russian@lists.debian.org @ Thu, 02 Oct 2008 16:33:43 -0400: N> Есть "pc1" в локальной сети с адресом eth0 192.168.1.3 N> он соединяется с удаленным сервером "server" openvpn (с диапазоном реальных N> адресов xx.xx.2.0/24) и получает адрес tap 192.168.1.3 N> "server" имеет настройку iptables: N> -A PREROUTING -d xx.xx.2.1 -j ACCEPT N> -A PREROUTING -d xx.xx.2.0/24 -j NETMAP --to 192.168.2.0/24 N> -A POSTROUTING -s 192.168.2.0/24 -j NETMAP --to xx.xx.2.0/24 N> таким образом "pc1" 192.168.1.3 "получает" внещний ip xx.xx.2.3 (и это N> работает): N> его ifconfig N> eth0inet addr:192.168.1.3 N> tap5inet addr:192.168.2.3 N> в той же локальной сети есть "pc2" с адресом eth0 192.168.1.4 N> и www сервисом на порту 8081, до которого надо достучатся "из вне". N> Для этого на pc1 создаются правила: N> -A PREROUTING --dst 192.168.2.3 -p tcp --dport 8081 -j DNAT --to-destination N> 192.168.1.4 N> -A POSTROUTING --src 192.168.1.4 -p tcp --sport 8081 -j SNAT --to-source N> 192.168.2.3:8081 N> Но они не работают - по адресу xx.xx.2.3:8081 страница не открывается. N> Вопрос: как правильно настроить iptables на ps1, что бы получить доступ к N> ps2:8081 "из вне" ? Еще надо на pc1 включить форвардинг и разрешить его в iptables (уже таблица filter, а не nat), если запрещен. -- Artem Chuprina RFC2822: Jabber: [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: make contest
Всё таже задача, но под соусом "Recursive make considered useful" ;) % ls -R contest contest: dirA dirB contest/dirA: Makefile contest/dirB: Makefile b.c c.c % cat dirA/Makefile binaries = ../dirB/b ../dirB/c all: make -C ../dirB make a.tar.gz a.tar.gz: $(binaries) tar czf a.tar.gz $(binaries) $(binaries): make -C ../dirB $@ % cat dirB/Makefile all: b c %: %.c gcc -o $@ $< Последнее правило в dirA/Makefile больше для пижонства: чтобы make a.tar.gz работал всегда, пересобирая архив из готовых бинарников или дособибарая бинарники по необходимости. -- Stanislav -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: как собрать avi из jpg
Alexey Pechnikov пишет: Hello! В сообщении от Thursday 02 October 2008 23:57:03 Nicholas написал(а): Вопрос: как собрать avi из jpg ? mplayer. Ключики не помню, но было дело, разбирал запись по кадрам и выбранные собирал в новую запись (не помню, почему не avidemux пользовал). Не особо силен в чем разница между mpeg и avi, но есть вот такой рецепт (gmsh): mencoder 'mf:///tmp/tmp*.jpg' -mf fps=5 -o /tmp/animation.mpg -ovc lavc -lavcopts vcodec=mpeg4:vhq -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: bluetooth headset
Murat D. Kadirov wrote: > Ну как сказать, 802.11(wi-fi) казалось бы тоже стандарт.. Дело в чипах. Если > есть возможность проверить, то лучше брать CSR (Cambridge Silicon > Radio) -- наилучшая поддержка данных чипов в linux. Это касательно > донгла. Касаемо headset'a, думаю, что проблем быть не должно, стандарту > не один год, если уж только совсем не повезёт. А вообще посмотрите лучше > документацию gentoo на эту тему, у них там всё хорошо расписано, в > частности добротное how-to именно по вашему вопросу (google: gentoo > headset bluetooth). > А нет ли тут людей с опытом эксплуатации Jabra BT325s? Поделитесь впечатлениями... -- tarantul -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
