36298 2019-03-18 15:29:00 +0300 please do not add rogue provides: python3(codegen) < 0 2019-04-16 14:30:26 +0300 1 1 4 Development Sisyphus rpm-build-python3 unstable all Linux REOPENED P3 normal --- 1 ldv imz aris darktemplar george glebfm imz kotopesutility ldv slev vitty qa-sisyphus oldest_to_newest 179540 0 ldv 2019-03-18 15:29:00 +0300 $ rpmquery --provides -p glib2-devel-2.58.3-alt1.x86_64.rpm |grep ^python3 python3(codegen) < 0 python3(codegen) = set:edFi python3(codegen_docbook) = set:edFi python3(codegen_main) = set:edFi python3(config) = set:edFi python3(dbustypes) = set:edFi python3(parser) = set:edFi python3(utils) = set:edFi Просьба не обманывать систему зависимостей и не добавлять "python3(codegen) < 0" в provides. 179543 1 aris 2019-03-18 16:11:23 +0300 Система зависимостей не всегда была столь совершенна, как сейчас. Уберу в следующей версии-релизе. 180831 2 ldv 2019-04-16 04:47:45 +0300 $ rpmquery --provides -p glib2-devel-2.60.0-alt1.x86_64.rpm |grep ^python3 python3(codegen) < 0 python3(codegen) = set:edFi python3(codegen_docbook) = set:edFi python3(codegen_main) = set:edFi python3(config) = set:edFi python3(dbustypes) = set:edFi python3(parser) = set:edFi python3(utils) = set:edFi 180837 3 aris 2019-04-16 10:04:47 +0300 [#227210] FAILED srpm=glib2-2.60.1-alt1.src.rpm x86_64: NEW unmet dependencies detected: libgio-devel#2.60.1-alt1 python3(codegen) < 0 i586: NEW unmet dependencies detected: libgio-devel#2.60.1-alt1 python3(codegen) < 0 aarch64: NEW unmet dependencies detected: libgio-devel#2.60.1-alt1 python3(codegen) < 0 180845 4 ldv 2019-04-16 13:53:59 +0300 (In reply to comment #3) > [#227210] FAILED srpm=glib2-2.60.1-alt1.src.rpm > x86_64: NEW unmet dependencies detected: > libgio-devel#2.60.1-alt1 python3(codegen) < 0 > i586: NEW unmet dependencies detected: > libgio-devel#2.60.1-alt1 python3(codegen) < 0 > aarch64: NEW unmet dependencies detected: > libgio-devel#2.60.1-alt1 python3(codegen) < 0 Конечно, потому что /usr/share/glib-2.0/codegen, python3 там не ищет. Если не перекладывать, то нужен какой-нибудь %add_python3_path /usr/share/glib-2.0 180846 5 imz 2019-04-16 13:58:42 +0300 (In reply to comment #4) > (In reply to comment #3) > > [#227210] FAILED srpm=glib2-2.60.1-alt1.src.rpm > > x86_64: NEW unmet dependencies detected: > > libgio-devel#2.60.1-alt1 python3(codegen) < 0 > > i586: NEW unmet dependencies detected: > > libgio-devel#2.60.1-alt1 python3(codegen) < 0 > > aarch64: NEW unmet dependencies detected: > > libgio-devel#2.60.1-alt1 python3(codegen) < 0 > > Конечно, потому что /usr/share/glib-2.0/codegen, python3 там не ищет. > Если не перекладывать, то нужен какой-нибудь > %add_python3_path /usr/share/glib-2.0 Если известно, что модули будут искаться где-то в нестандартных местах, то это можно сообщить в спеке с помощью %allow_python3_import_path (при сборке тех пакетов, которые умеют искать в нестандартном месте). 180847 6 aris 2019-04-16 14:02:16 +0300 (В ответ на комментарий №4) > (In reply to comment #3) > > [#227210] FAILED srpm=glib2-2.60.1-alt1.src.rpm > > x86_64: NEW unmet dependencies detected: > > libgio-devel#2.60.1-alt1 python3(codegen) < 0 > > i586: NEW unmet dependencies detected: > > libgio-devel#2.60.1-alt1 python3(codegen) < 0 > > aarch64: NEW unmet dependencies detected: > > libgio-devel#2.60.1-alt1 python3(codegen) < 0 > > Конечно, потому что /usr/share/glib-2.0/codegen, python3 там не ищет. > Если не перекладывать, то нужен какой-нибудь > %add_python3_path /usr/share/glib-2.0 Ищет, ищет, -- не находит. Давно прописано. %add_python3_path %_datadir/glib-2.0/codegen 180848 7 aris 2019-04-16 14:03:39 +0300 (В ответ на комментарий №5) > Если известно, что модули будут искаться где-то в нестандартных местах, то это > можно сообщить в спеке с помощью > > %allow_python3_import_path %add_python3_path уже недостаточно? 180849 8 imz 2019-04-16 14:11:36 +0300 Да, /usr/bin/gdbus-codegen из libgio-devel умеет искать в нестандартном месте. Было бы хорошо указать его с помощью %allow_python3_import_path $ cat /usr/bin/gdbus-codegen #!/usr/bin/env python3 # GDBus - GLib D-Bus Library # # Copyright (C) 2008-2011 Red Hat, Inc. # # This library is free software; you can redistribute it and/or # modify it under the terms of the GNU Lesser General Public # License as published by the Free Software Foundation; either # version 2.1 of the License, or (at your option) any later version. # # This library is distributed in the hope that it will be useful, # but WITHOUT ANY WARRANTY; without even the implied warranty of # MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU # Lesser General Public License for more details. # # You should have received a copy of the GNU Lesser General # Public License along with this library; if not, see <http://www.gnu.org/licenses/>. # # Author: David Zeuthen <davidz@redhat.com> import os import sys srcdir = os.getenv('UNINSTALLED_GLIB_SRCDIR', None) filedir = os.path.dirname(__file__) if srcdir is not None: path = os.path.join(srcdir, 'gio', 'gdbus-2.0') elif os.path.basename(filedir) == 'bin': # Make the prefix containing gdbus-codegen 'relocatable' at runtime by # adding /some/prefix/bin/../share/glib-2.0 to the python path path = os.path.join(filedir, '..', 'share', 'glib-2.0') else: # Assume that the modules we need are in the current directory and add the # parent directory to the python path. path = os.path.join(filedir, '..') # Canonicalize, then do further testing path = os.path.abspath(path) # If the above path detection failed, use the hard-coded datadir. This can # happen when, for instance, bindir and datadir are not in the same prefix or # on Windows where we cannot make any guarantees about the directory structure. # # In these cases our installation cannot be relocatable, but at least we should # be able to find the codegen module. if not os.path.isfile(os.path.join(path, 'codegen', 'codegen_main.py')): path = os.path.join('/usr/share', 'glib-2.0') sys.path.insert(0, path) from codegen import codegen_main sys.exit(codegen_main.codegen_main()) 180850 9 imz 2019-04-16 14:17:50 +0300 (In reply to comment #7) > (В ответ на комментарий №5) > > Если известно, что модули будут искаться где-то в нестандартных местах, то это > > можно сообщить в спеке с помощью > > > > %allow_python3_import_path > > %add_python3_path уже недостаточно? Да, я когда-то разделил: %add_python3_path повлияет на Provides; на Requires повлияет %allow_python3_import_path Теперь вот задумался, удачно ли это. Если пакет несёт в себе модули в нестандартном месте, то и использовать он, вероятно, их может. Если же не несёт модули в нестандартном месте, то %add_python3_path всё равно не сможет повредить, кажется. Наверное, можно было бы эти действия объединить в одном макросе. Даже не знаю, почему мне это рассуждение сразу в голову не пришло, могут ли быть какие-то противопоказания. 180851 10 aris 2019-04-16 14:22:30 +0300 (В ответ на комментарий №9) > (In > могут ли быть какие-то противопоказания. Нет противопоказаний. Можете придумать очередной макрос, чтобы запретить провайдить из нестандартных мест, а %add_python3_path вернуть прежнее поведение. 180852 11 imz 2019-04-16 14:24:38 +0300 Теперь мне кажется, что можно было бы в %add_python3_path добавить действие %allow_python3_import_path; %allow_python3_import_path для совместимости оставить таким же или сделать синонимом %add_python3_path Не уверен, что решусь это сделать, пока собирают python3 сейчас. 180853 12 imz 2019-04-16 14:26:11 +0300 (In reply to comment #10) > (В ответ на комментарий №9) > > (In > > могут ли быть какие-то противопоказания. > > Нет противопоказаний. Можете придумать очередной макрос, чтобы запретить > провайдить из нестандартных мест, Думаю, в этом нет особой необходимости, потому что они всё равно эти Provides не сомгут удовлетворить обычные Requires. 180854 13 aris 2019-04-16 14:30:26 +0300 (В ответ на комментарий №11) > Теперь мне кажется, что можно было бы в %add_python3_path добавить действие > %allow_python3_import_path; %allow_python3_import_path для совместимости > оставить таким же или сделать синонимом %add_python3_path Чудесно, перевешиваю на rpm-build-python3. В glib2 этот %allow прописал.