21814 2009-10-02 18:47:28 +0400 не предоставляет libjvm.so(SUNWprivate_1.1) 2009-12-28 22:36:56 +0300 1 1 4 Development Sisyphus java-1.5.0-sun unstable all Linux CLOSED FIXED P3 normal --- 1 zerg viy anyr qa-sisyphus oldest_to_newest 100671 0 zerg 2009-10-02 18:47:28 +0400 программа, у которой в BuildRequires java-devel-default, собирается в hasher, получая зависимость /usr/lib/jvm/java-1.5.0-sun-1.5.0.19/jre/lib/i386/client/libjvm.so(SUNWprivate_1.1) , но никто такой не предоставляет. 100682 1 viy 2009-10-02 19:04:53 +0400 перенесем обсуждение в 21812 *** This bug has been marked as a duplicate of bug 21812 *** 101022 2 zerg 2009-10-07 20:37:08 +0400 У нас ведь java-devel-default это он? Если да, то не вижу исправления 101024 3 viy 2009-10-07 20:48:20 +0400 мы уже это вопрос обсуждали, я напомню: ----------------------------------------- вкратце: * либо хотите чтобы все было автоматически, и тогда линкуетесь с java-1.6.0-openjdk, точнее с /usr/lib/jvm/java-1.6.0-openjdk-1.6.0.0.x86_64/jre/lib/*/*/libjvm.so * либо вручную правите rpath на /usr/lib/jvm/java/jre/lib/arch/{client,server}/libjvm.so и вручную же фильтруете requires (я писал как) ----------------------------------------- путь /usr/lib/jvm/java-1.6.0-sun-1.6.0.14 очевидно будет сломан при обновлении :( если уже и писать что-то в rpath, то советую писать /usr/lib/jvm/java-1.6.0-sun/jre/lib/i386/client, и такую зависимость фильтровать вручную. ------------------------------------- решил вам посоветовать линковаться с java 1.6.0 openjdk. это имеет то преимущество, что линковочный путь там определен и не скачет от версии к версии. java-1.6.0-openjdk-1.6.0.0.x86_64/jre/lib/amd64/server на x86_64 client/*.so нет, там только server. ---------------------------------------------- 101067 4 zerg 2009-10-08 14:00:31 +0400 (В ответ на комментарий №3) > на x86_64 client/*.so нет, там только server. значит, там cmake найдет server/* 101068 5 zerg 2009-10-08 14:07:24 +0400 (В ответ на комментарий №3) > * либо вручную правите rpath на > /usr/lib/jvm/java/jre/lib/arch/{client,server}/libjvm.so и вручную же Это сделать можно, но зачем? Если с client/libjvm.so никто линковаться не должен, то ее либо не должно быть в пакете, либо она должна лежать там, где ее никто не найдет. Если cmake находит именно ее, то наверняка он это делает правильно. > фильтруете requires (я писал как) не работает, т.к. нет provides для замены отфильтрованным requires 101069 6 zerg 2009-10-08 14:09:06 +0400 (В ответ на комментарий №3) > если уже и писать что-то в rpath, то советую писать > /usr/lib/jvm/java-1.6.0-sun/jre/lib/i386/client, Ща попробую, посмотрю, что будет 101070 7 zerg 2009-10-08 14:10:47 +0400 (В ответ на комментарий №3) > * либо хотите чтобы все было автоматически, > и тогда линкуетесь с java-1.6.0-openjdk, Это уже не автоматически. Автоматически -- это я пишу java-devel-default или еще нечто, что никогда не измениться, а мне ставят то, что нужно. 101072 8 zerg 2009-10-08 14:17:56 +0400 (В ответ на комментарий №3) > если уже и писать что-то в rpath, то советую писать > /usr/lib/jvm/java-1.6.0-sun/jre/lib/i386/client, Он есть только в java-1.6.0-sun. Как его узнать автоматически имея уверенность, что это всегда точно он? > и такую зависимость фильтровать вручную. Какой requires добавлять вместо отфильтрованного? 101073 9 zerg 2009-10-08 14:35:09 +0400 (В ответ на комментарий №3) > решил вам посоветовать > линковаться с java 1.6.0 openjdk. Ручше посоветуйте линковаться с java-devel-suggested ;-) 101076 10 viy 2009-10-08 15:30:46 +0400 > Это уже не автоматически. Автоматически -- это я пишу java-devel-default или > еще нечто, что никогда не измениться, а мне ставят то, что нужно. Пишите java-devel-openjdk :) 101104 11 viy 2009-10-08 21:27:25 +0400 in alt2 101410 12 zerg 2009-10-13 15:23:49 +0400 В provides /path/to/libjvm.so попали пустые скобки 101413 13 zerg 2009-10-13 15:39:59 +0400 и еще отсутствует макрос для /usr/lib/jvm/java/jre/lib/i386/client/libjvm.so(SUNWprivate_1.1) 101414 14 zerg 2009-10-13 15:44:15 +0400 (В ответ на комментарий №13) > /usr/lib/jvm/java/jre/lib/i386/client/libjvm.so(SUNWprivate_1.1) Может, в %_libjvmserver_sun_private_default эту строку? 101416 15 zerg 2009-10-13 15:52:56 +0400 Или какой-нибудь %_libjvmserver_sun_private_current ? 101474 16 viy 2009-10-14 01:02:03 +0400 (В ответ на комментарий №14) > (В ответ на комментарий №13) > > /usr/lib/jvm/java/jre/lib/i386/client/libjvm.so(SUNWprivate_1.1) > Может, в %_libjvmserver_sun_private_default эту строку? Не соображу. Зачем нужна эта строка? Правильный Requires: должен проставиться автоматически findreq-ом, по итогам rpath. а в rpath надо пихать `dirname %_libjvmserver_sun_private_default` я так себе представлял эту схему: chrpath -r `dirname %_libjvmserver_sun_private_default` %buildroot/your/lib 101494 17 zerg 2009-10-14 14:14:24 +0400 (В ответ на комментарий №16) > Правильный Requires: должен проставиться автоматически findreq-ом, > по итогам rpath. хрен там :-( Проставляется /usr/lib/jvm/java-1.5.0-sun-1.5.0.19/jre/lib/i386/client/libjvm.so(SUNWprivate_1.1) Попробуй собрать мой soprano-backend-sesame, чтоб виднее стало 101496 18 zerg 2009-10-14 14:18:41 +0400 (В ответ на комментарий №16) > я так себе представлял эту схему: > chrpath -r `dirname %_libjvmserver_sun_private_default` %buildroot/your/lib Я именно так и делал, но зависимость у пакета получается хреновая, поэтому и подумал проставить вручную такой %_libjvmserver_sun_private, который содержит (SUNWprivate_1.1) Попробуй собрать мой soprano-backend-sesame, чтоб не задавать лишних вопросов Строку Requires: %_libjvmserver_sun_private_default можно закомментировать пока, чтоб не мешалась 101705 19 viy 2009-10-16 21:11:51 +0400 Сергей, я извиняюсь что не сразу ответил, был offline так как Покров и д.рожд. сыну (6 лет). я посмотрел libsoprano-backend-sesame, как вы просили, да, CanonPath в lib.req здесь играет плохую штуку :( соответственно, любые другие симлинки не спасут и нужен фильтр. Я добавил в спек фильтр, и он у меня собрался с нужными requires. я запушил изменения к себе на git.alt. тж. прилагаю diff 101706 20 3995 viy 2009-10-16 21:13:14 +0400 Created attachment 3995 тж. прилагаю diff 104356 21 anyr 2009-12-15 20:05:03 +0300 Дошли руки у меня до nepomuk. У меня после какого-то очередного  обновления панель в dolphin с интегрированными nepomuk приблудами стала  активной, можно было изменить комментарий и поставить файлу оценку, но  ничего из этого не сохранялось. $ nepomukserver (Soprano::PluginManager) found no soprano plugin at   "/usr/lib/soprano/libsoprano_sesame2backend.so" $ ldd /usr/lib/soprano/libsoprano_sesame2backend.so   libjvm.so => not found При том, что этот самый libjvm.so есть в  /usr/lib/jvm/jre/lib/i386/server/ Сделал: $ ln -s /usr/lib/jvm/jre/lib/i386/server/libjvm.so /usr/lib/libjvm.so  После этого, возможность выставлять метки и оценку работает $ rpm -qa | grep java java-1.6.0-sun-1.6.0.17-alt1 fonts-ttf-java-1.6.0-sun-1.6.0.17-alt1 java-1.6.0-sun-javaws-1.6.0.17-alt1 java-common-1.3.18-alt1 mozilla-plugin-java-1.6.0-sun-1.6.0.17-alt1 rpm-build-java-1.7.6-alt13 $ rpm -qa | grep nepomuk libnepomukquery4-4.3.3-alt1.M51.1 libnepomukqueryclient4-4.3.3-alt1.M51.1 104360 22 zerg 2009-12-15 20:37:53 +0300 Еще покажите вывод от rpm -q soprano-backend-sesame и rpm -q --requires soprano-backend-sesame | grep jvm 104361 23 zerg 2009-12-15 20:44:27 +0300 (В ответ на комментарий №21) > $ ldd /usr/lib/soprano/libsoprano_sesame2backend.so > libjvm.so => not found И у меня воспроизвелось после удаления java-1.6.0-sun-devel 104364 24 anyr 2009-12-15 20:55:19 +0300 $ rpm -q soprano-backend-sesame soprano-backend-sesame-2.3.1-alt1 $ rpm -q --requires soprano-backend-sesame | grep jvm /usr/lib/jvm/java/jre/lib/i386/server/libjvm.so(SUNWprivate_1.1) 104365 25 anyr 2009-12-15 20:59:11 +0300 Описание аналогичной проблемы в других дистрибутивах: http://lists.opensuse.org/opensuse-bugs/2008-12/msg09478.html https://bugs.launchpad.net/ubuntu/+source/soprano-backend-sesame/+bug/334186 104382 26 zerg 2009-12-16 13:57:14 +0300 Проблема понятна. Просто, не дорешили. 104432 27 viy 2009-12-17 09:25:51 +0300 (В ответ на комментарий №26) > Проблема понятна. Просто, не дорешили. Торможу. В чем причина? остается ли путь /usr/lib/jvm/java/jre/lib/i386/server/libjvm.so ? 104454 28 zerg 2009-12-17 14:04:10 +0300 /usr/lib/jvm/java/jre/lib/i386/server/libjvm.so пропадает после удаления java-1.6.0-sun-devel-1.6.0.17-alt1 Нужно и остальных проверить на этот счет $ l /usr/lib/jvm/java ls: cannot access /usr/lib/jvm/java: No such file or directory $rpm -qa| grep java rpm-build-java-1.7.6-alt13 java-1.6.0-sun-1.6.0.17-alt1 javahelp2-2.0.05-alt2_1jpp5 mozilla-plugin-java-1.6.0-sun-1.6.0.17-alt1 gcc-java-common-1.4.14-alt1 tzdata-java-2009j-alt1 java-common-1.3.18-alt1 fonts-ttf-java-1.6.0-sun-1.6.0.17-alt1 104963 29 viy 2009-12-28 22:36:56 +0300 Я извиняюсь, исправил ранее, но уехал и не успел сказать. В чем исправление: перенес для совместимости текущие Provides: вида /usr/lib/jvm/java/jre/lib/i386/server/libjvm.so в java-devel, а в jre внес правильные Provides: вида /usr/lib/jvm/jre/lib/i386/server/libjvm.so со временем надо будет пересобрать сопрано с /usr/lib/jvm/jre... rpath, и Provides: вида /usr/lib/jvm/java/... можно будет выкинуть. 3995 2009-10-16 21:13:14 +0400 2009-10-16 21:13:14 +0400 тж. прилагаю diff sesame.diff text/plain 1923 viy ZGlmZiAtLWdpdCBhL3NvcHJhbm8tYmFja2VuZC1zZXNhbWUuc3BlYyBiL3NvcHJhbm8tYmFja2Vu ZC1zZXNhbWUuc3BlYwppbmRleCAzMTEyMjg1Li41ZTQ2YzlhIDEwMDY0NAotLS0gYS9zb3ByYW5v LWJhY2tlbmQtc2VzYW1lLnNwZWMKKysrIGIvc29wcmFuby1iYWNrZW5kLXNlc2FtZS5zcGVjCkBA IC00LDE0ICs0LDE0IEBACiBTdW1tYXJ5OiBRdCB3cmFwcGVyIEFQSSB0byBkaWZmZXJlbnQgUkRG IHN0b3JhZ2Ugc29sdXRpb25zCiBOYW1lOiBzb3ByYW5vLWJhY2tlbmQtc2VzYW1lCiBWZXJzaW9u OiAyLjMuMQotUmVsZWFzZTogYWx0MC4xMAorUmVsZWFzZTogYWx0MQogCiBHcm91cDogVGV4dCB0 b29scwogTGljZW5zZTogTEdQTHYyKwogVXJsOiBodHRwOi8vc291cmNlZm9yZ2UubmV0L3Byb2pl Y3RzL3NvcHJhbm8KIAogI1JlcXVpcmVzOiBqYXZhCi1SZXF1aXJlczogJV9saWJqdm1zZXJ2ZXJf c3VuX3ByaXZhdGVfZGVmYXVsdAorI1JlcXVpcmVzOiAlX2xpYmp2bXNlcnZlcl9zdW5fcHJpdmF0 ZV9kZWZhdWx0CiBSZXF1aXJlczogbGlicXQ0LWNvcmUgPj0gJXtnZXRfdmVyc2lvbiBsaWJxdDQt Y29yZX0KIFJlcXVpcmVzOiBsaWIlbmFtZSA9ICV2ZXJzaW9uLSVyZWxlYXNlCiAKQEAgLTIxLDYg KzIxLDcgQEAgUHJvdmlkZXM6IHNvcHJhbm8tYmFja2VuZCA9ICV2ZXJzaW9uLXJlbGVhc2UKIFNv dXJjZTA6IGh0dHA6Ly9kb3dubG9hZHMuc2YubmV0L3NvcHJhbm8vc29wcmFuby0ldmVyc2lvbiV7 P2JldGF9LnRhci5iejIKIAogQnVpbGRSZXF1aXJlcyhwcmUpOiBsaWJxdDQtZGV2ZWwgPj0gNC40 CitCdWlsZFJlcXVpcmVzKHByZSk6IHJwbS1idWlsZC1qYXZhCiBCdWlsZFJlcXVpcmVzOiBjbWFr ZSBnY2MtYysrIGRveHlnZW4gZ3JhcGh2aXogbGliY2x1Y2VuZS1kZXZlbCBsaWJyZWRsYW5kLWRl dmVsIGxpYnNvcHJhbm8tZGV2ZWwgeG9yZy1kZXZlbAogQnVpbGRSZXF1aXJlczogamF2YS1kZXZl bC1kZWZhdWx0IGNocnBhdGgKIApAQCAtNjYsMTYgKzY3LDE2IEBAIHBvcGQKIAogJWluc3RhbGwK ICVtYWtlIC1DICVfdGFyZ2V0X3BsYXRmb3JtL2JhY2tlbmRzL3Nlc2FtZTIgREVTVERJUj0lYnVp bGRyb290IGluc3RhbGwKLSNjaHJwYXRoIC1yIGBkaXJuYW1lICVfbGlianZtc2VydmVyX3N1bl9w cml2YXRlX2RlZmF1bHRgICVidWlsZHJvb3QvJV9saWJkaXIvc29wcmFuby9saWJzb3ByYW5vX3Nl c2FtZTJiYWNrZW5kLnNvCi0KLSMjIEhBQ0sgYXJvdW5kIGZpbmQtcmVxdWlyZXMKLSNkZWZpbmUg X19maW5kX3JlcXVpcmVzICAgICVidWlsZHJvb3QvLmZpbmQtcmVxdWlyZXMKLSNjYXQgPiAlYnVp bGRyb290Ly5maW5kLXJlcXVpcmVzIDw8RU9GCi0jIyEvYmluL3NoCi0jKC91c3IvbGliL3JwbS9m aW5kLXJlcXVpcmVzIHwgZ3JlcCAtdiAvdXNyL2xpYi9qdm0vamF2YSkgfHwgOgotI0VPRgotI2No bW9kIDc1NSAlYnVpbGRyb290Ly5maW5kLXJlcXVpcmVzCi0jIyBlbmQgSEFDSyBhcm91bmQgZmlu ZC1yZXF1aXJlcworY2hycGF0aCAtciBgZGlybmFtZSAlX2xpYmp2bXNlcnZlcl9zdW5fcHJpdmF0 ZV9kZWZhdWx0YCAlYnVpbGRyb290LyVfbGliZGlyL3NvcHJhbm8vbGlic29wcmFub19zZXNhbWUy YmFja2VuZC5zbworCisjIEhBQ0sgYXJvdW5kIGZpbmQtcmVxdWlyZXMKKyVkZWZpbmUgX19maW5k X3JlcXVpcmVzICAgICVidWlsZHJvb3QvLmZpbmQtcmVxdWlyZXMKK2NhdCA+ICVidWlsZHJvb3Qv LmZpbmQtcmVxdWlyZXMgPDxFT0YKKyMhL2Jpbi9zaAorKC91c3IvbGliL3JwbS9maW5kLXJlcXVp cmVzIHwgc2VkIC1lICdzLC91c3IvbGliL2p2bS9qYXZhLVteL10qLywvdXNyL2xpYi9qdm0vamF2 YS8sZycpIHx8IDoKK0VPRgorY2htb2QgNzU1ICVidWlsZHJvb3QvLmZpbmQtcmVxdWlyZXMKKyMg ZW5kIEhBQ0sgYXJvdW5kIGZpbmQtcmVxdWlyZXMKIAogCiAlZmlsZXMK