Некоторые браузеры до сих пор ищут модули в /usr/lib/browser-plugins, в то время как e.g. mozilla-plugin-macromedia-flash-7.0.61-alt1 устанавливается в /usr/lib/browser-plugins-npapi/ Мужики, определитесь, чем закончилось то обсуждение. По крайней мере сизифный konqueror без ln -s или добавления руками два месяца тому сизифный flash plugin _не_ подхватывал.
firefox поддерживает этот путь.
(In reply to comment #0) > Мужики, определитесь, чем закончилось то обсуждение. Фиг знает, IMHO /usr/lib/browser-plugins-npapi/ не обсуждался
(In reply to comment #2) > (In reply to comment #0) > > Мужики, определитесь, чем закончилось то обсуждение. > Фиг знает, IMHO /usr/lib/browser-plugins-npapi/ не обсуждался Ой, торможу. Как раз обсуждение закончилось на /usr/lib/browser-plugins-npapi/ , который я фиг знает когда забил в умолчания kde
А если точнее, то %browser_plugins_path из пакета browser-plugins-npapi-devel
Насколько я понимаю, это проблемы конкретных браузеров, а не пакета browser-plugins-npapi.
Навесьте баги на конкретные плагины, а этот сделайте зонтиком.
(In reply to comment #5) > Насколько я понимаю, это проблемы конкретных браузеров, а не пакета > browser-plugins-npapi. которые этот пакет и породил :-)
(In reply to comment #6) > Навесьте баги на конкретные плагины, а этот сделайте зонтиком. Так и предполагалось, просто времени хватило только так тогда. Народ, для firefox-1.0.7-alt3.1 и kdebase-konqueror-3.5.0-alt1 это было актуально. Сам удивился, однако пришлось ln(1). Проверьте ещё раз...
Говорят, <snejok> тут наткнулся на #9098, думаю не актуальна
Она будет всегда актуальна. Например, недавно я это фиксил в Qt4.
Умолчательные пути поиска плагинов Qt4 /usr/lib/browser/plugins /usr/local/lib/mozilla/plugins /usr/lib/firefox/plugins /usr/lib64/browser-plugins /usr/lib/browser-plugins /usr/lib/mozilla/plugins /usr/local/netscape/plugins /opt/mozilla/plugins /opt/mozilla/lib/plugins /opt/netscape/plugins"); /opt/netscape/communicator/plugins /usr/lib/netscape/plugins /usr/lib/netscape/plugins-libc5 /usr/lib/netscape/plugins-libc6 /usr/lib64/netscape/plugins /usr/lib64/mozilla/plugins KDE4 /usr/lib/firefox/plugins /usr/lib64/browser-plugins /usr/lib/browser-plugins /usr/local/netscape/plugins /opt/mozilla/plugins /opt/mozilla/lib/plugins /opt/netscape/plugins /opt/netscape/communicator/plugins /usr/lib/netscape/plugins /usr/lib/netscape/plugins-libc5 /usr/lib/netscape/plugins-libc6 /usr/lib/mozilla/plugins /usr/lib64/netscape/plugins /usr/lib64/mozilla/plugins
Предлагаю %_libdir/browser-plugins
(В ответ на комментарий №12) > Предлагаю %_libdir/browser-plugins Что мешает добавить к этим путям ещё и /usr/lib/browser-plugins-npapi ?
Сергей, я конечно понимаю, что тебе ничего делать не хочется ... но только из-за этого менять пути поиска плагинов мне не хочется.
(В ответ на комментарий №13) > Сергей, я конечно понимаю, что тебе ничего делать не хочется ... Ну, раз тебе хочется, то ищи _везде_ и рассылай патчи. > но только > из-за этого менять пути поиска плагинов мне не хочется. Тебе с самого начала твердили так не делать.
(В ответ на комментарий №15) > Тебе с самого начала твердили так не делать. Я сделал этот пакет т.к. все лазали в каталог mozilla, а потом и в firefox. Это подтверждает список каталогов, который ты привёл. Этот пакет предоставляет механизм для переопределения каталога, где находятся плагины. Совершенно не важно как будет называться этот каталог. Если пакет использует %browser_plugins_path, то этот макрос можно переопределить (хоть в тот же %_libdir/browser-plugins), но использовать макрос вместо пути всё равно нужно учить каждый пакет. Добавлять поддержку макроса или нет это личное дело каждого мантейнера.
(В ответ на комментарий №16) > Я сделал этот пакет т.к. все лазали в каталог mozilla, а потом и в firefox. Я предложил уже %_libdir/browser-plugins/ > Совершенно не важно как будет называться этот каталог Из тех, кому это не важно, я знаю только тебя. > нужно учить каждый пакет. Т.к. ты создал эту проблему, тебе и решать ее. > Добавлять поддержку макроса или нет это личное дело каждого мантейнера. Тогда сделай пожалуйста так, чтоб каждый мантейнер помещал плагины в %_libdir/browser-plugins, а те, кому сильно нужно, переопределяли макрос в %_libdir/browser-plugins-npapi или еще куда в неизвестное никому место.
В общем мои варианты: %_libdir/netscape/plugins %_libdir/browser-plugins
Я не понял, ничего из того что ты написал про "проблемы". Так как я не вижу проблемы, то делать ничего не планирую.
Либо переформулируй описание проблемы, либо пусть бага висит дальше.
Формулирую. Если не берешь на себя обязательства отслеживать _все_ программы в Сизифе и рассылать патчи мантейнерам, выбери более стандартное место для плагинов. Мои варианты: %_libdir/netscape/plugins %_libdir/browser-plugins
(В ответ на комментарий №21) > Если не берешь на себя обязательства отслеживать _все_ программы в Сизифе и > рассылать патчи мантейнерам, выбери более стандартное место для плагинов. Так или иначе программы не должны использовать пути. Нужен макрос для этого пути. Собственно, ты тоже предлагаешь использовать макрос %_libdir, но не хочешь использовать макрос %browser_plugins_path. Почему? > Мои варианты: > %_libdir/netscape/plugins > %_libdir/browser-plugins Для firefox это нестандартное место. Для него стандартрное место: %_libdir/firefox/plugins %_libdir/mozilla/plugins Вернёмся к старой схеме ?
(В ответ на комментарий №22) > %_libdir/mozilla/plugins > Вернёмся к старой схеме ? Я только за. А все нестандартные плагины пусть помещаются в нестандартные места.
Так как и у меня и в QT/KDE присутствует каталог %_libdir/mozilla/plugins, который является стандартным. Для плагинов используй его. firefox будет продолжать поддерживать каталог /usr/lib/browser-plugins-npapi дополнительно к "стандартному".Любой кто хочет, может его также использовать. Я так как стандартный каталог для плагинов найден в процессе обсуждения я закрываю багу.
Собственно, проблемы с %_libdir/mozilla/plugins больше не моя головная боль, а мантейнера seamonkey.
$ grep -c '/usr/lib/browser-plugins-npapi' i586/base/contents_index /ALT/Sisyphus/i586/base/contents_index:25 $ grep -c '/usr/lib/mozilla/plugins' i586/base/contents_index /ALT/Sisyphus/i586/base/contents_index:4
Макрос %browser_plugins_path для стандартных плагинов использовать теперь не рекомендуется. Так? Или он будет изменен на %_libdir/mozilla/plugins?
(В ответ на комментарий №26) > $ grep Ради этого мне не впадлу повесить ~29 багов
(В ответ на комментарий №27) > Макрос %browser_plugins_path для стандартных плагинов использовать теперь не > рекомендуется. Так? Лично я рекомендую его использовать и буду сам. > Или он будет изменен на %_libdir/mozilla/plugins? Зачем? Ты же его не используешь. Не вижу смысла менять каталог для "нестандартных" плагинов.
(В ответ на комментарий №29) > > Или он будет изменен на %_libdir/mozilla/plugins? > Зачем? Ты же его не используешь. Использую везде с твоей подачи, как и все тобой нагрепанные. > Не вижу смысла менять каталог для "нестандартных" плагинов. Т.е. %browser_plugins_path -- для нестандартных плагинов?
(В ответ на комментарий №30) > Использую везде с твоей подачи, как и все тобой нагрепанные. Если все используют этот макрос и каталог /usr/lib/browser-plugins-npapi, то почему бы его не добавить в QT/KDE? > > Не вижу смысла менять каталог для "нестандартных" плагинов. > Т.е. %browser_plugins_path -- для нестандартных плагинов? Я не случайно поставил кавычки. Не бывает стандартного каталога для мозилльных плагинов. Это очень хорошо видно в #11. Всё что ты показал является историей развития проекта mozilla. Сначала был netscape и "стандартным" каталогом был */netscape/plugins (с всеми вариациями возможного местоположения netscape), потом появилась mozilla и "стандартным" стал */mozilla/plugins и т.д. Сейчас стандартный каталог */firefox/plugins. В некоторых коммерческих плагинах при инсталляции перебором ищется этот "стандартный" каталог. Я считаю /usr/lib/browser-plugins-npapi вполне _стандартным_ каталогом для ALTLinux. Ты не хочешь использовать этот каталог, а хочешь использовать некий другой каталог. Именно поэтому я назвал каталог browser-plugins-npapi "нестандартным", чтобы не называть его "каталог-который-ненравится-zerg'у".
(В ответ на комментарий №31) > Если все используют этот макрос и каталог /usr/lib/browser-plugins-npapi, то > почему бы его не добавить в QT/KDE? Проблема не в этом. Его всегда везде нужно добавлять. При этом существуют стандартные каталоги, которые уже добавлены _везде_ > Не бывает стандартного каталога для мозилльных плагинов. Это очень хорошо видно в #11. Значит, нужно выбрать один из них. [...] > Я считаю /usr/lib/browser-plugins-npapi вполне _стандартным_ каталогом для > ALTLinux. Ни в одной программе в ALT Linux этот каталог не используется без патча. > хочешь использовать некий другой каталог Не некий, а тот, которые используют все без извратов.
Ты можешь не флудить, а ответить четко на вопрос (я это могу сделать): Какой стандартный каталог каталог для стандартных плагинов NPAPI?
(В ответ на комментарий №33) > Какой стандартный каталог каталог для стандартных плагинов NPAPI? Я считаю, что это /usr/lib/browser-plugins-npapi.
(В ответ на комментарий №34) > Я считаю, что это /usr/lib/browser-plugins-npapi. Ты можешь обеспечить его поддержку в _всех_ программах ALT Linux (я могу автоматически)?
(В ответ на комментарий №35) > Ты можешь обеспечить его поддержку в _всех_ программах ALT Linux (я могу > автоматически)? Зачем мне это делать ?
На самом деле, флеймишь сейчас ты. Если ты что-то хочешь сделать, то делай. Я же тебе не мешаю. Я только считаю, что ты полностью неправ.
(В ответ на комментарий №36) > Зачем мне это делать ? Чтоб геморроя _никому_ не создавать. Опять флуд начинается?
(В ответ на комментарий №37) > Если ты что-то хочешь сделать, то делай. Ок. Дай мне acl на browser-plugins-npapi А seamonkey подвинем, если в нем единственном и ненаглядном проблема.
(В ответ на комментарий №39) > Ок. Дай мне acl на browser-plugins-npapi Зачем ? > А seamonkey подвинем, если в нем единственном и ненаглядном проблема. Что ты с ним хочешь сделать ?
(В ответ на комментарий №40) > > Ок. Дай мне acl на browser-plugins-npapi > Зачем ? Чтоб сделать, то, с чем ты уже согласился в #37. Исправить эту багу, установив значение макроса в стандартное. > > А seamonkey подвинем, если в нем единственном и ненаглядном проблема. > Что ты с ним хочешь сделать ? Пока ничего.
(В ответ на комментарий №41) > Чтоб сделать, то, с чем ты уже согласился в #37. Исправить эту багу, установив > значение макроса в стандартное. Я с этим не соглашался. Не додумывай. В #32 ты сам отказался использовать макрос из этого пакета. Так что исправлять его не вижу смысла.
(В ответ на комментарий №42) > Я с этим не соглашался. Не додумывай. Ты сам дал мне добро "если хочешь, делай", но сидишь, как собака на сене. > В #32 ты сам отказался использовать макрос из этого пакета. Покажи хоть один мой пакет, где я им не пользуюсь. Опять флуд?
Ты будешь поддерживать каталог %_libdir/browser-plugins-npapi во всех пакетах ALT Linux? Если нет, отдай пакет с этим каталогом и макросом мне. Я буду.
(В ответ на комментарий №43) > Ты сам дал мне добро "если хочешь, делай", но сидишь, как собака на сене. Я не собираюсь с тобой спорить. Я не на это тебе дал добро. Я дал тебе добро на то чтобы ты, если так не терпится, пересобрал все пакеты _использовали_ %_libdir/mozilla/plugins и не использовали browser-plugins-npapi. Именно это я имел ввиду под вопросом "Вернёмся к старой схеме ?". Пока ты (или кто-то более терпеливый) не объяснишь мне, почему не устраивает _название_ директории, на которую указывает макрос %browser_plugins_path, то я не пущу тебя махать топором. Или же я перестану использовать этот макрос в своих пакетах. > > В #32 ты сам отказался использовать макрос из этого пакета. > Покажи хоть один мой пакет, где я им не пользуюсь. Ты цепляешься к словам. Я тоже. Ты отказался пользоваться макросом в #32. Если не отказывался, то проблемы вообще нет. Используй макрос и забудь куда он указывает. Всё равно тебе предётся добавить путь, на который указывает макрос в пути QT/KDE. P.S. Ты не даёшь закрыть багу. Я считаю, что данная проблема НЕ бага. Закрывать я её не буду. Можешь наслаждаться общением.
Сc => ldv@ Дим, прошу помощи. Либо членораздельно объясните в чём проблема, либо закройте багу и перестаньте меня спамить.
(В ответ на комментарий №44) > Ты будешь поддерживать каталог %_libdir/browser-plugins-npapi во всех пакетах > ALT Linux? Если нет, отдай пакет с этим каталогом и макросом мне. Я буду. Тебе нарыть письмо столетней
(В ответ на комментарий №47) > Тебе нарыть письмо столетней Нарой, конечно
Багзилла в альтлинукс это пиздец. Короче, проблема, которую вы обсуждаете высосана из пальца - если вам нужен _общий_ каталог для всех NPAPI (именно API, а не mozilla) плагинов, используйте %_libdir/browser-plugins-npapi, для всех остальных случаев придумывайте свой велосипед и не доказывайте, что он правильный. Есть письмо от legion@ 3х летней давности, почему нужен каталог с плагинами отличный от %libdir/mozilla - потому что %libdir/mozilla провайдится как минимум несколькими пакетами и нифига не отражает их NPAPI принадлежности. Насчет уникальности выбора %_libdir/browser-plugins-npapi советую посмотреть ubuntu, где плагины хранятся тоже не в %libdir/mozilla и не в %libdir/firefox ровно по той же причине.
(В ответ на комментарий №35) > (В ответ на комментарий №34) > > Я считаю, что это /usr/lib/browser-plugins-npapi. > Ты можешь обеспечить его поддержку в _всех_ программах ALT Linux (я могу > автоматически)? см. письмо legion@ - мантейнеры должны сами озаботиться этой поддержкой, потому что только мантейнер пакета может точно знать, умеет его пакет NPAPI или нет.
http://lists.altlinux.org/pipermail/devel/2004-August/025524.html - зерг, у тебя точно амнезия. Ты на эти грабли наступаешь уже 3ий раз.
(В ответ на комментарий №51) > Ты на эти грабли наступаешь уже 3ий раз. Уже достало наступать, поэтому не отступлюсь.
(В ответ на комментарий №49) > если вам нужен _общий_ каталог для всех NPAPI (именно API, > а не mozilla) плагинов, Нет. Нужен каталог, для которого нужно пропатчить минимальное кол-во пакетов. В идеале 0. > отличный от %libdir/mozilla - потому что %libdir/mozilla провайдится > как минимум несколькими пакетами Легко решаемо. > и нифига не отражает их NPAPI принадлежности. Ничего страшного. > Насчет уникальности выбора %_libdir/browser-plugins-npapi советую посмотреть > ubuntu, Не пытайся никого вводить в заблуждение Первый же посмотренный пакет libflash лежит в /usr/lib/mozilla/plugins/libflash-mozplugin.so /usr/lib/mozilla-firefox/plugins/libflash-mozplugin.so см. debian/libflash-mozplugin.install
(В ответ на комментарий №53) > (В ответ на комментарий №49) > > если вам нужен _общий_ каталог для всех NPAPI (именно API, > > а не mozilla) плагинов, > Нет. Нужен каталог, для которого нужно пропатчить минимальное кол-во пакетов. В > идеале 0. открой для себя slackware. > > > отличный от %libdir/mozilla - потому что %libdir/mozilla провайдится > > как минимум несколькими пакетами > Легко решаемо. 4ый раз. > > Насчет уникальности выбора %_libdir/browser-plugins-npapi советую посмотреть > > ubuntu, > Не пытайся никого вводить в заблуждение > Первый же посмотренный пакет libflash лежит в > /usr/lib/mozilla/plugins/libflash-mozplugin.so > /usr/lib/mozilla-firefox/plugins/libflash-mozplugin.so > см. debian/libflash-mozplugin.install А что, /usr/lib/mozilla-firefox/plugins/ это общепринятый каталог? Можно сссылку на developer.netscape.com?
(В ответ на комментарий №54) > А что, /usr/lib/mozilla-firefox/plugins/ это общепринятый каталог? Можно > сссылку на developer.netscape.com? Обратись в Ubuntu
(В ответ на комментарий №55) > Обратись в Ubuntu Т.е. Ubuntu может делать общий каталог произвольного вида для плагинов, а ALTLinux нет?
(В ответ на комментарий №56) > Т.е. Ubuntu может делать общий каталог произвольного вида для плагинов, а > ALTLinux нет? Ubuntu использует %_libdir/mozilla/plugins . Почему ALT Linux не может?
(В ответ на комментарий №57) > (В ответ на комментарий №56) > > Т.е. Ubuntu может делать общий каталог произвольного вида для плагинов, а > > ALTLinux нет? > Ubuntu использует %_libdir/mozilla/plugins . Почему ALT Linux не может? А тебе кто-то запрещает искать в %_libdir/mozilla/plugins? Тебе предлагают искать еще на один каталог больше. Причем, данный каталог имеет право на жизнь ровно такое же, что и %_libdir/mozilla/plugins (обратного доказательства ты не предоставил).
Теперь ты флудить юудешь? Иди читай все сначала до полного просветления.
(В ответ на комментарий №59) > Теперь ты флудить юудешь? Иди читай все сначала до полного просветления. В комментарии Кости, нет ни грамма флейма. Ну разумеется на мой взгляд. Серёг, у тебя мантра такая: если нет аргументов, то ссылаться на флейм ?
(В ответ на комментарий №59) > Теперь ты флудить юудешь? Иди читай все сначала до полного просветления. Вот не надо мне тыкать. Мудежом в этом обсуждении занимаюсь не я - раз за 5 лет тебе не удалось убедить аффторов KDE в "уникальности" ALTLinux, то либо altlinux за 5 лет так и остался сырьевым придатком к крупным вендорам, либо мантейнер KDE в altlinux не умеет убеждать апстрим. что опять же, никак не связано с оригинальным письмом 2004 года. Не смог добавить правильный путь для поиска - сиди без плагинов и объясняй каждому пользователю QT/KDE, что ты ниасисил программу patch, и не надо свои проблемы перевешивать на мантейнера browser-plugins-npapi.
(В ответ на комментарий №60) > В комментарии Кости, нет ни грамма флейма. Я ни грамма про флейм не написал. > Серёг, у тебя мантра такая: если нет аргументов, то ссылаться на флейм ? Нет, похоже у вас мания читать мантру, вместо того, что я пишу, потому, что у вас аргументов меньше, чем у меня. Я не знаю, как еще это объяснить.
Костя! Пиши, пожалуйста, вранье и бестолковщину в другом месте.
(В ответ на комментарий №62) > Я ни грамма про флейм не написал. См. #59 ... извини, ты писал про флуд. Для меня это одно и тоже. > Нет, похоже у вас мания читать мантру, вместо того, что я пишу, потому, что у > вас аргументов меньше, чем у меня. Я не знаю, как еще это объяснить. Насчёт аргументов, у меня диаметрально противоположное мнение. Если не можешь объяснить, то значит всё останется как есть.
(В ответ на комментарий №63) > Костя! Пиши, пожалуйста, вранье и бестолковщину в другом месте. Т.е. аргументы кончились, перешли на личности? balobanovo style, даже писать бесполезно.
Я вроде уже всем объяснил достаточно. Что ж, тогда придется это делать без тебя.
(В ответ на комментарий №66) > Я вроде уже всем объяснил достаточно. > Что ж, тогда придется это делать без тебя. Тогда закрываю.
Created attachment 3943 [details] /usr/share/opera/defaults/pluginpath.ini Вот вам пути поиска оперы 10.00.
Замечу, что /usr/lib{,64}/browser-plugins там есть.
На http://plugindoc.mozdev.org/linux-amd64.html тоже говориться об установке 32-битных плагинов для Linux именно в /usr/lib/browser-plugins
(В ответ на комментарий №70) > На http://plugindoc.mozdev.org/linux-amd64.html тоже говориться об установке > 32-битных плагинов для Linux именно в /usr/lib/browser-plugins Ок. Давай так: если я меняю значение макроса %browser_plugins_path на */browser-plugins, ты добавишь путь по макросу %browser_plugins_path в QT/KDE ? По сути спрашиваю, будешь ли ты использовать макрос %browser_plugins_path в QT/KDE.
(В ответ на комментарий №71) > По сути спрашиваю, будешь ли ты использовать макрос %browser_plugins_path в > QT/KDE. Давно везде использую.
(В ответ на комментарий №71) > */browser-plugins Договорились
Ну чтоже, хорошо: $ giter task show 13441 id=13441 locked=no shared=yes repo=sisyphus owner=legion seq= rc= 1:dir=/people/legion/packages/browser-plugins-npapi.git 1:tag_name=2.0-alt1 1:tag_id=9d71604f18af5030ba972160847935954e591616 1:tag_author=legion <legion@altlinux.org> 1:userid=legion наполняй задачу всеми кто использует browser-plugins-npapi, потом я добавлю firefox и запущу сбору.
(В ответ на комментарий №74) > наполняй задачу всеми Нафига!? По ходу переедут.
(В ответ на комментарий №75) > Нафига!? По ходу переедут. Иначе %_libdir/browser-plugins-npapi окажется не чьим. Плюс к этому пока программы не начнут смотреть в новый каталог, пересобранные плагины не будут работать.
(В ответ на комментарий №76) > (В ответ на комментарий №75) > > Нафига!? По ходу переедут. > > Иначе %_libdir/browser-plugins-npapi окажется не чьим. Ошибка в твоем пакете > Плюс к этому пока > программы не начнут смотреть в новый каталог Уже смотрят. P.S. А плагины пересоберу, как соберется таск.
(В ответ на комментарий №77) > (В ответ на комментарий №76) > > (В ответ на комментарий №75) > > > Нафига!? По ходу переедут. > > > > Иначе %_libdir/browser-plugins-npapi окажется не чьим. > Ошибка в твоем пакете Два каталога я таскать не хочу. В чём ошибка? > > > Плюс к этому пока > > программы не начнут смотреть в новый каталог > Уже смотрят. mozilla & co не смотрят. > А плагины пересоберу, как соберется таск. Добавь в таск. Я такой таск без браузеров не выпущу.
(В ответ на комментарий №78) > Два каталога я таскать не хочу. > В чём ошибка? В том, что не хочешь таскать каталог, который так любил. > mozilla & co не смотрят. Я их не могу добавить в таск
(В ответ на комментарий №78) > Я такой таск без браузеров не выпущу. Я свой без извратов уже выпустил и удалил, когда здесь ожило
(В ответ на комментарий №79) > В том, что не хочешь таскать каталог, который так любил. Носить два каталога при том, что браузеры будут смотреть только в один из них - глупость. Перестанут работать либо не пересобранные плагины, либо пересобранные (зависит от того обновятся ли браузеры). > Я их не могу добавить в таск Можешь. Таск shared, так что получай NMU и добавляй.
(В ответ на комментарий №81) > Можешь. Таск shared, так что получай NMU и добавляй. Я ж говрю, мне проще свой запустить и не изголяться.
(В ответ на комментарий №82) > Я ж говрю, мне проще свой запустить и не изголяться. А мне не проще.
Тогда составь список пакетов, которые необходимо добавить в таск
(В ответ на комментарий №84) > Тогда составь список пакетов, которые необходимо добавить в таск У меня сейчас нет возможности сделать список, а у тебя есть. Кроме того, менять путь для плагинов это же твоя идея. Нужно пересобрать всех тех кто для сборки пользуется browser-plugins-npapi-devel.
(В ответ на комментарий №85) > У меня сейчас нет возможности сделать список, а у тебя есть. Хорошо, вот список: "browser-plugins-npapi firefox" Запускай.
(В ответ на комментарий №86) > > У меня сейчас нет возможности сделать список, а у тебя есть. У меня оказывается остался ещё доступ на armor, поэтому я решил сделать список, раз уж ты не можешь. У меня он получился больше, чем у тебя: djview4-4.5-alt1.src.rpm djvu-3.5.21-alt1.src.rpm firefox-3.5.3-alt0.20090918.src.rpm gnash-0.8.6-alt1.src.rpm gnome-session-2.26.2-alt4.src.rpm google-gadgets-0.11.0-alt1.src.rpm gxine-0.5.11-alt10.src.rpm java-1.4.2-blackdown-1.4.2.03-alt7.src.rpm java-1.4.2-sun-1.4.2.17-alt2.src.rpm java-1.5.0-sun-1.5.0.19-alt1.src.rpm java-1.6.0-openjdk-1.6.0.0-alt10_19.b14jpp6.src.rpm java-1.6.0-sun-1.6.0.14-alt1.src.rpm kde4network-4.3.1-alt1.src.rpm mozilla-plugin-adobe-flash-10.0.32.18-alt1.src.rpm mozilla-plugin-kaffeine-0.2-alt6.src.rpm mozilla-plugin-mozplugger-1.13.0-alt1.src.rpm mozilla-plugin-swfdec-0.8.2-alt1.src.rpm mozilla-plugin-xine-1.0.2-alt1.src.rpm opensc-0.11.9-alt2.src.rpm qt4-4.5.2-alt6.src.rpm rhythmbox-0.12.5-alt1.src.rpm seamonkey-1.1.18-alt1.src.rpm tcl-plugin-3.1-alt1.src.rpm thunderbird-3.0-alt1.20090817.src.rpm vlc-1.0.1-alt3.1.src.rpm Пакеты firefox и thunderbird я обновлю сам. > Хорошо, вот список: "browser-plugins-npapi firefox" После такого вранья я тем более не хочу давать тебе обновлять browser-plugins-npapi самостоятельно. > Запускай. Обязательно запущу, но после того как в задании появятся перечисленные пакеты или при условии что эти пакеты покинут сизиф.
unsubscribe
(В ответ на комментарий №87) [...] > seamonkey-1.1.18-alt1.src.rpm > Пакеты firefox и thunderbird я обновлю сам. Это мой список. Если не будешь делать ты, то сделаю я и пересобирать нужно будет только их. > > Хорошо, вот список: "browser-plugins-npapi firefox" > После такого вранья я тем более не хочу давать тебе обновлять > browser-plugins-npapi самостоятельно. К сожалению, я не нашел другого способа заставить тебя что-либо _делать_ вообще. Похоже, это максимум, чего я добился.
(В ответ на комментарий №89) > Это мой список. Если не будешь делать ты, то сделаю я и пересобирать нужно > будет только их. И то, не в одном таске, а ASAP.
(В ответ на комментарий №89) > > seamonkey-1.1.18-alt1.src.rpm > > Пакеты firefox и thunderbird я обновлю сам. > Это мой список. Если не будешь делать ты, то сделаю я и пересобирать нужно > будет только их. Я уже привел аргументы почему делать в несколько транзакций нельзя. Для того, чтобы делать плавное обновление, нужно чтобы все браузеры поддерживали оба каталога до конца миграции. > К сожалению, я не нашел другого способа заставить тебя что-либо _делать_ > вообще. Похоже, это максимум, чего я добился. Лучше бы ты заставил себя думать. У меня не всегда есть под рукой весь репозиторий, чтобы делать по нему поиск. Тебе это проще. Но раз ты такой принципиальный, то я нашёл возможность от зеркалить Сизиф. Такими действиями ты мало чего добьёшься.
(В ответ на комментарий №91) > нужно чтобы все браузеры поддерживали оба каталога до конца миграции. Если неимоверными усилиями заставишь себя хоть чуть подумать, то можно сделать, чтоб они это поддерживали до начала миграции.
(В ответ на комментарий №92) > Если неимоверными усилиями заставишь себя хоть чуть подумать, то можно сделать, > чтоб они это поддерживали до начала миграции. Я рад, что ты наконец-то _подумал_ о миграции, жаль что сил у тебя не хватило, понять, что миграция не нужна. Эти _все_ пакеты даже модифицировать не нужно. Требуется их только пересобрать с новым browser-plugins-npapi. Ты настолько ленив, что у тебя нехватает сил ни составить список пакетов, ни написать мантейнерам о необходимости технической пересборки и попросить их добавить пакеты в задание. Не тревожься, это я сделаю за тебя, а то я не уверен, что у тебя такая сложная операция получится. Можешь дальше заниматься ничем.
(В ответ на комментарий №93) > Ты настолько ленив, что у тебя нехватает сил Я уже всё сделал. > я сделаю Теперь делай сколько хочешь
(re #c93, #c94) дяденьки, вы чё? :)
(В ответ на комментарий №95) > (re #c93, #c94) дяденьки, вы чё? :) Ты прикалываешься? Ща, сяду за продолжение этого романа ;-)
(В ответ на комментарий №95) > (re #c93, #c94) дяденьки, вы чё? :) Я имел ввиду, что уже пересобрал все свои пакеты (см. баги 21763 21764 21765), а если Legion очень хочет, то может заниматься таском 13441
