У меня на wheeze apt-get install говорит, что установлена последняя версия bash, хотя файл /bin/bash от 01.01.2013, и простейший тест env X="() { :;} ; echo busted" bash -c "echo stuff" показывает, что уязвимость есть.
лучшая утилита — это та утилита, которую ты знаешь лучше всего
Согласен. Но я бы добавил «и остальные члены команды».
Судя по всем перечисленным проблемам, у меня создалось впечатление, что ни Притпал, ни кто другой не владеет hbmk достаточно, чтобы эти проблемы решить.
Построил, наконец, hbide. Для этого понадобилось следующее:
Взять свежий Harbour ( в 3.2, который у меня был, hbmk не поддерживал какие-то вещи ) и откомпилировать его с ключом HB_WITH_QT=...
Создать скрипт для сборки, в котором установить HB_QT_MAJOR_VER, HB_WITH_QT и HB_QTPATH
Переписать в hbqtwidgets/ и в hbxbp/ файлы hbqtgui.ch, hbqt_version.ch, hbqtcore.ch — в harbour/include все же не хочется.
В файлах hbdbu.hbp, hbide.hbp, hbqtwidgets.hpb и hbxbp.hbp прописать полный путь к hbqt.hbc, а в hbdbu.hbp — и к hbqtwidgets.hpc
После вылета с ошибкой при линковке hbide.exe переписать две вновь созданные библиотеки: libhbqtwidgets.a и libhbxbp.a в harbour\addons\hbqt\lib\win\mingw\ и запустить процесс еще раз.
Посоветовать что-то конкретное по настройке конфигурационных файлов hbmk не могу, потому что сам не использую эту утилиту и знаком с ней только в самых общих чертах. Но с этим надо что-то делать.
Я бы, конечно, использовал стандартные make средства. Учитывая, что набор С компиляторов для qtcontribs очень ограничен ( mingw для Windows и gcc для Linux и Mac ), суммарное количество конфигурационных файлов будет меньше, чем сейчас, ну и разобраться будет проще.
hbmk2[hbqtwidgets]: Warning: Cannot nest deeper in
C:\Harbour\addons\hbqt\hbqtcore.hbc
hbmk2[hbqtwidgets]: Warning: Cannot nest deeper in
C:\Harbour\addons\hbqt\hbqtgui.hbc
hbmk2[hbqtwidgets]: Warning: Cannot nest deeper in
C:\Harbour\addons\hbqt\hbqtnetwork.hbc
hbqtwidgets\scroll.ui(1) Error E0030 Syntax error «syntax error at '<'»
hbqtwidgets\scroll.ui(2) Error E0030 Syntax error «syntax error at '<'»
…
И так на каждую строчку в scroll.ui. Может, предупреждение, что hbmk «Cannot nest deeper in...» связано с тем, что scroll.ui не преобразовался во что должен…
Продублировал *.ch файлы, убрал из .hbp .ui и .qrc — при финальной линковке получил unknown function HBQTRES_HBIDE(). Проверил — она действительно упоминается (вызывается ) только один раз — в hbide/main.prg… Где она объявляется-то?
Ясно. Из-за того, что пути к заголовочным файлам не прописаны вы все эти файлы переписываете в одно место — в include/ от Harbour. Но мне не хотелось бы засорять эту папку — потом труднее найти нужные файлы.
Пришлось обновить Harbour — у меня был 3.2. Получается, что QtContrib не строится со стабильной версией Harbour (3.0) с официального сайта — что, вообще говоря, неправильно.
Вроде, компиляция пошла, но я рано радовался — когда дело дошло до каталога hbqtwidgets, сразу же вылетела с ошибкой: «Can't open #include file hbqtgui.ch» — где-то не прописан к нему путь…
И еще. Наверное, уместнее было бы спросить в соответствующей группе, но раз уж мы тут…
Что-то он у меня не компилируется.
hbmk2 qtcontribs.hbp
получаю:
hbmk2: Building sub-project (level 2): debug\hwgdebug.hbp
hbmk2: Target up to date: ..\..\lib\win\bcc\hwgdebug.lib
hbmk2: Building sub-project (level 2): hbqt\qtcore\hbqtcore.hbp
hbmk2: Building sub-project (level 3): hbqt\qtcore\hbqtcores.hbp
Хорошо бы добавить в статью ссылку на место, откуда его можно скачать.
И вопрос: QtContribs имеет какое-либо отношение к hbqt, который входит в набор contrib для Harbour?
Самое трудное для пожилых людей — это найти в интерфейсе ранее незнакомой программы или нового сайта основные элементы управления и навигации, привыкнуть к тому, что одни и те же вещи везде сделаны по разному. Они часто пытаются записать на бумагу последовательность необходимых шагов, а это может помочь только когда пользуешься строго фиксированным набором программ и сайтов.
Смена дизайна сайта — это беда…
В принципе, вы правы, это, в общем случае, более безопасное решение. И развилка на Timeline в случае fork более адекватно описывает ситуацию, чем прямая. Но в реальных ситуациях участники проекта часто работают над малопересекающимися областями и делать каждый раз fork с последующим изучением нового кода и merge — лишние и бесполезные трудозатраты. К тому же при наличии элементарного порядка в организации труда ситуации, когда кто-то, допустим, изменил название переменной, используемой другими, предварительно это не обсудив ни с кем, и даже не предупредив об этом — такие ситуации практически исключены.
Прямого аналога нет. Но того же эффекта можно, наверное, добиться, если вызывать push, pull из bash-скрипта, где предварительно по нужным правилам устанавливать URL — fossil remote-url…
Хотя я, честно говоря, не понял, для чего это нужно и как работает ваша конструкция.
В соответствии с документацией Fossil незавершенная транзакция будет отменена при следующем открытии базы. Такой подход мне кажется более надежным, чем дерево файлов.
Совершенно верно. Процитирую комментарий с stackoverflow:
The fact that there's a tried'n'true transactional database behind every operation makes me sleep better at night. Yes, we've been through more than one horrible incident of stale and corrupt Subversion repositories (thankfully, a helpful community helped us fix them.) I can't imagine that happening in Fossil. Even Subversion 1.7.x use Sqlite now for metadata storage. (Try turning off power in the midst of a git commit — it'll leave a corrupt repos!)
Тот факт, что каждая операция обеспечивается реально транзакционной базой данных, позволяет мне спать спокойно. Мы пережили не один ужасный инцидент, связанный с повреждением хранилищ Subversion (к счастью, сообщество помогло нам справиться с ними ). Я не могу себе представить, чтобы такое случилось с Fossil. Даже Subversion 1.7 использует теперь Sqlite для хранения метаданных. ( Попробуйте выключить питание посреди commit в git — ваш репозитарий будет поврежден! )
Если при записи в одну единственную БД происходит сбой, весь репозиторий накрывается? Как-то подход git на файлах надежнее выглядит.
Необходимость резервного копирования никто не отменял.
Как поведет себя SQLite с базой размером в гигабайт?
Не знаю, не пробовал. Честно говоря, не представляю себе проекта такого размера, если, конечно, большие бинарные файлы в репозиторий не пихать. Учтите к тому же, что Fossil сжимает рабочие файлы. У меня самый большой рабочий каталог исходников — 6 мегабайт с копейками, а соответствующий Fossil репозиторий — чуть больше полутора мегабайт.
Что такое открыть/закрыть репозиторий? Почему закрывать не рекомендуется, зачем тогда эта функция вообще?
В тексте же написано — при открытии создается служебная БД для отслеживания изменений в репозитории. Не рекомендую закрывать — просто чтобы не открывать опять, когда на следующий день возьметесь за работу. Можно ведь и забыть.
Зачем пользователи нужны на локальной машине?
На локальной машине пользователи не нужны. Но ведь при создании репозитория Fossil не знает, будете вы его использовать локально или на сервере.
Разных wiki и багтреккеров over 9000 разных на любой вкус, в т.ч. интегрирующиеся с VCS. Зачем ещё один, жестко прибитый гвоздями к одной VCS?
Ниже все правильно ответили. Добавлю, что в Fossil это работает и на локальном компьютере, для локального репозитория, нет нужды в сторонних сервисах, которые могут отвалиться или изменить свою политку в любой момент.
env X="() { :;} ; echo busted" bash -c "echo stuff"показывает, что уязвимость есть.Согласен. Но я бы добавил «и остальные члены команды».
Судя по всем перечисленным проблемам, у меня создалось впечатление, что ни Притпал, ни кто другой не владеет hbmk достаточно, чтобы эти проблемы решить.
Посоветовать что-то конкретное по настройке конфигурационных файлов hbmk не могу, потому что сам не использую эту утилиту и знаком с ней только в самых общих чертах. Но с этим надо что-то делать.
Я бы, конечно, использовал стандартные make средства. Учитывая, что набор С компиляторов для qtcontribs очень ограничен ( mingw для Windows и gcc для Linux и Mac ), суммарное количество конфигурационных файлов будет меньше, чем сейчас, ну и разобраться будет проще.
И так на каждую строчку в scroll.ui. Может, предупреждение, что hbmk «Cannot nest deeper in...» связано с тем, что scroll.ui не преобразовался во что должен…
Вроде, компиляция пошла, но я рано радовался — когда дело дошло до каталога hbqtwidgets, сразу же вылетела с ошибкой: «Can't open #include file hbqtgui.ch» — где-то не прописан к нему путь…
github.com/harbour/core/tree/master/contrib/hbgt
И еще. Наверное, уместнее было бы спросить в соответствующей группе, но раз уж мы тут…
Что-то он у меня не компилируется.
hbmk2 qtcontribs.hbpполучаю:
и на этом — все…
И вопрос: QtContribs имеет какое-либо отношение к hbqt, который входит в набор contrib для Harbour?
Смена дизайна сайта — это беда…
Хотя я, честно говоря, не понял, для чего это нужно и как работает ваша конструкция.
Не знаю, не пробовал. Честно говоря, не представляю себе проекта такого размера, если, конечно, большие бинарные файлы в репозиторий не пихать. Учтите к тому же, что Fossil сжимает рабочие файлы. У меня самый большой рабочий каталог исходников — 6 мегабайт с копейками, а соответствующий Fossil репозиторий — чуть больше полутора мегабайт.
В тексте же написано — при открытии создается служебная БД для отслеживания изменений в репозитории. Не рекомендую закрывать — просто чтобы не открывать опять, когда на следующий день возьметесь за работу. Можно ведь и забыть.
На локальной машине пользователи не нужны. Но ведь при создании репозитория Fossil не знает, будете вы его использовать локально или на сервере.
Ниже все правильно ответили. Добавлю, что в Fossil это работает и на локальном компьютере, для локального репозитория, нет нужды в сторонних сервисах, которые могут отвалиться или изменить свою политку в любой момент.