Palemoon не собирается

29.4.4

Уже ж есть 29.4.5.

фишка в том что этих файлов нет, они генерируются на этапе компиляции. Пока только это знаю.

Какая же всё-таки гадость этот гит, ничего не посмотреть нормально. То ли дело svn, набираешь svn log путь/к/файлу (из любой ветки) и там всегда будет полная его история вплоть до создания.

не, нифига не генерируются, а добавляются в релиз видимо из репов firefox

Видимо вот такой патч откатывать надо https://github.com/ManchildProductions/UXP-MCP/commit/6235023c8bff80273981c70a06cb9decb4a4ffa5

Я попытался открыть историю коммитов, но там ничего нет!

Так ведь есть же, два последних одинаковых коммита - то, что нужно.

Нифига себе, какой большой патч. Сейчас попробую откатить.

Мне кажется, что тут бесполезно пытаться вносить изменения, чтобы можно было собрать с --disable-dbus. Похоже, что «global menubar support for GTK» как раз и работает через dbus.

Буду либо откатывать, либо обновлять Glib.

палемун уже ни от какого жирнолиса не зависит. и давно.

Типо как git log -p path/to/file?

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

Ошибку удалось исправить. Сборка правда потом всё равно остановилась на моменте линковки libxul.so, говоря что памяти не хватает. Скорее всего, уперевшись в 4 Гб, отому что система 32-битная. Ну так или иначе, проблема решена.

Щас попробую -O2 на -Os заменить.

Патч, который я откатил, вроде как добавляет поддержку глобального меню. Как в Ubuntu 12.04 было, в Unity. Для меня - невелика потеря. Но так бы, по-хорошему, ключик бы --disable-global-menu, хотя вряд ли у кого-то, кроме меня, будет в системе Glib старее, чем 2.26.

Сборку кстати могу выложить, если кому надо, по-идее должна работать во сяких CentOS 6, Debian 6 и Ubuntu 10.04

Было бы неплохо, если выложили.

Угу. Ну оно пока что пересобирается с -Os

вроде как добавляет поддержку глобального меню

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

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

Оно опционально же. Оно дёргает нужные вызовы Glib, и если видит, что глобального меню нет в системе, то оно и не используется

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

При желании, можно собрать с --disable-gconf --disable-dbus --disable-necko-wifi --disable-libproxy --disable-pulseaudio. Тогда ничего гномовского точно не притянется

у меня и так собирается с этими настройками. теперь ещё это дизейбл этого меню надо будет добавить.

кстати, у меня есть патч для палемуна для jackd. правда корявый (я выкусила кусок из хромиума), но работает. если буду собирать, сделаю его и для последней версии.

Вот бы VDPAU прикрутить ) Но боюсь, что это невозможно. В Хромиуме есть вполне неплохо работающий VA-API. А в Firefox какое-то кривое-косое поделие прикручивают

Кто-то не осилил

git log -- путь/к/файлу

Ясно, понятно...

да я уже признал промах

Palemoon не собирается (комментарий)

но гит всё равно плохой

но гит всё равно плохой

Как научишь svn коммитить без удаленного сервера - приходи, обсудим. Ну и ветвление в классических VCS - это адский ад.

Если не устраивает именно git - есть mercurial, например. Но SVN в 2k22 - это legacy. Deal with it.

Как научишь svn коммитить без удаленного сервера - приходи, обсудим.

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

Ну и ветвление в классических VCS - это адский ад.

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

Если не устраивает именно git - есть mercurial,

Не довелось изучать, может он и лучше. Меня почти устраивает svn, а для идеала захочется велосипедить скорее чем ещё одно почти подходящее узнавать.

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

Хотя я не проверял умеет ли он кросс-серверный мерж из коробки

Сразу видно специалиста. Правильный ответ - нормально не умеет. Не зря Торвальдс говорил(примерно) «svn заявляли как cvs сделанный правильно. Но это ошибка - cvs НЕЛЬЗЯ сделать правильно»

захочется велосипедить

Это всё очень хорошо когда речь идет о централизованной разработке в одном едином репозитарии в какой-нибудь конторе. В мире opensource классические VCS отмирают - и слава Б-гу.

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

И всё равно это лучше веток в svn где по факту нужно создавать отдельное дерево папок для каждой ветки.

Это всё очень хорошо когда речь идет о централизованной разработке в одном едином репозитарии в какой-нибудь конторе. В мире opensource классические VCS отмирают - и слава Б-гу.

А я так и не понял зачем нужна реально не централизованная разработка. На мой взгляд это верный путь к хаосу. В нормальной ситуации всё равно кто-то должен выпускать официальные версии продукта, вот у него и должен быть центральный репозиторий. Способы доставки в него коммитов могут быть разными, но принятый коммит - это всегда принятый коммит в центральном репозитории, а всё остальное - на разработку в итоге не влияет, так что не вижу разницы между непринятыми гит-коммитами в чьих-то локальных репах и незакоммичеными свн-патчами (которые при этом тоже могут быть в локальных репах).

нужно создавать отдельное дерево папок для каждой ветки.

Это всего лишь визуальное представление. На самом деле физического копирования дерева при создании ветки не происходит. Можешь проверить на каком-нить огромном репозитории - ветка делается мгновенно.