Hi Michal,
I have unpushed from f24 and rawhide dnf-1.1.7-1 and revoked the requests for updates. The main reason being that the api changed ina way that broke our ability to create install media.
lorax --product=Fedora --version=24 --release=24 -- source=file:///mnt/koji/compose/branched/Fedora-24-20160225.n.0/work/i386/repo --variant=Workstation --nomacboot --noupgrade --buildarch=athlon --volid=Fedora- WS-boot-i386-24 --installpkgs=fedora-productimg-workstation /mnt/koji/compose/branched/Fedora-24-20160225.n.0/work/i386/buildinstall/Workst ation 2016-02-25 16:46:06,909: Added 'lorax-repo-0': file:///mnt/koji/compose/branched/Fedora-24-20160225.n.0/work/i386/repo 2016-02-25 16:46:06,909: Fetching metadata... repo: downloading from remote: lorax-repo-0, _Handle: metalnk: None, mlist: None, urls ['file:///mnt/koji/compose/branched/Fedora-24-20160225.n.0/work/i386/repo']. repo: using cache for: lorax-repo-0 not found deltainfo for: lorax-repo-0 not found updateinfo for: lorax-repo-0 timer: sack setup: 31470 ms Getting group metadata Adding group file from repository: lorax-repo-0 timer: loading comps: 108 ms 2016-02-25 16:46:38,948: checking for root privileges checking for root privileges 2016-02-25 16:46:38,948: checking the selinux mode checking the selinux mode 2016-02-25 16:46:38,949: checking dnf base object checking dnf base object 2016-02-25 16:46:38,949: setting up build architecture setting up build architecture Traceback (most recent call last): File "/usr/sbin/lorax", line 353, in <module> main(sys.argv) File "/usr/sbin/lorax", line 209, in main remove_temp=True, verify=opts.verify) File "/usr/lib/python3.5/site-packages/pylorax/__init__.py", line 252, in run self.arch = ArchData(buildarch) File "/usr/lib/python3.5/site-packages/pylorax/__init__.py", line 65, in __init__ self.basearch = dnf.arch.basearch(buildarch) AttributeError: module 'dnf' has no attribute 'arch'
An API change like that is a point release is not acceptable, certainly not without working With the users of the code to ensure that you do not break peoples code. Given where we are in the Fedora 24 cycle where we need to be reliably composing the OS in order to have a Alpha compose in a few short weeks.
I would like to work out ways to allow development to go forward but we need to ensure that changes are syncronised with the users as we do so.
Thanks
Dennis
From: "Dennis Gilmore" dennis@ausil.us
I have unpushed from f24 and rawhide dnf-1.1.7-1 and revoked the requests for updates. The main reason being that the api changed ina way that broke our ability to create install media.
lorax --product=Fedora --version=24 --release=24 --source=file:///mnt/koji/compose/branched/Fedora-24-20160225.n.0/work/i386/repo --variant=Workstation --nomacboot --noupgrade --buildarch=athlon --volid=Fedora-WS-boot-i386-24 --installpkgs=fedora-productimg-workstation /mnt/koji/compose/branched/Fedora-24-20160225.n.0/work/i386/buildinstall/Workstation 2016-02-25 16:46:06,909: Added 'lorax-repo-0': ... self.basearch = dnf.arch.basearch(buildarch) AttributeError: module 'dnf' has no attribute 'arch'
An API change like that is a point release is not acceptable, certainly not without working With the users of the code to ensure that you do not break peoples code. Given where we are in the Fedora 24 cycle where we need to be reliably composing the OS in order to have a Alpha compose in a few short weeks.
That was no API change, `basearch` function was actually introduced in this release [1][2].
Lorax guys, can you adapt lorax, please?
"self.basearch = dnf.arch.basearch(buildarch)" -> "self.basearch = dnf.rpm.basearch(buildarch)"
Keep in touch with me via IRC (jsilhan on #fedora-releng) when you are awake so we can find the best solution for this issue.
Also double check what non DNF API functions are you using. If you want them to be added into API, file the bug for DNF and we will happily document it. We would like to not get back to yum age where no API existed and every tools was calling whatever they liked.
Whenever we break API it's in the next major release only while providing patches to the consumers we know about.
Paradoxically, this was exposed on relengs demand - to add custom arch support for repoclosure. This will be needed for F23.
Thanks, Honza
[1] http://dnf.readthedocs.org/en/latest/release_notes.html#release-notes [2] http://dnf.readthedocs.org/en/latest/api_rpm.html#dnf.rpm.basearch
On Fri, Feb 26, 2016 at 08:33:10AM -0500, Honza Šilhan wrote:
From: "Dennis Gilmore" dennis@ausil.us
I have unpushed from f24 and rawhide dnf-1.1.7-1 and revoked the requests for updates. The main reason being that the api changed ina way that broke our ability to create install media.
lorax --product=Fedora --version=24 --release=24 --source=file:///mnt/koji/compose/branched/Fedora-24-20160225.n.0/work/i386/repo --variant=Workstation --nomacboot --noupgrade --buildarch=athlon --volid=Fedora-WS-boot-i386-24 --installpkgs=fedora-productimg-workstation /mnt/koji/compose/branched/Fedora-24-20160225.n.0/work/i386/buildinstall/Workstation 2016-02-25 16:46:06,909: Added 'lorax-repo-0': ... self.basearch = dnf.arch.basearch(buildarch) AttributeError: module 'dnf' has no attribute 'arch'
An API change like that is a point release is not acceptable, certainly not without working With the users of the code to ensure that you do not break peoples code. Given where we are in the Fedora 24 cycle where we need to be reliably composing the OS in order to have a Alpha compose in a few short weeks.
That was no API change, `basearch` function was actually introduced in this release [1][2].
Lorax guys, can you adapt lorax, please?
"self.basearch = dnf.arch.basearch(buildarch)" -> "self.basearch = dnf.rpm.basearch(buildarch)"
Keep in touch with me via IRC (jsilhan on #fedora-releng) when you are awake so we can find the best solution for this issue.
Also double check what non DNF API functions are you using. If you want them to be added into API, file the bug for DNF and we will happily document it. We would like to not get back to yum age where no API existed and every tools was calling whatever they liked.
Whenever we break API it's in the next major release only while providing patches to the consumers we know about.
Paradoxically, this was exposed on relengs demand - to add custom arch support for repoclosure. This will be needed for F23.
Thanks, Honza
[1] http://dnf.readthedocs.org/en/latest/release_notes.html#release-notes [2] http://dnf.readthedocs.org/en/latest/api_rpm.html#dnf.rpm.basearch
This code was in a top level module and was not marked with _ as is the python convention for private methods. Whether or not you document the api is immaterial. If you expose a method it is going to eventually get used by someone.
See https://www.python.org/dev/peps/pep-0008/#public-and-internal-interfaces for the correct way to manage exposing public methods (eg. use of __all__ and _)
Also, it is pretty clear that this method is in use by dnf users. It would be far better if you added arch.py with a deprecation warning instead of insisting that all your users rewrite their code across 4 releases.
Brian C. Lane wrote: % % This code was in a top level module and was not marked with _ as is % the python convention for private methods. Whether or not you document % the api is immaterial. If you expose a method it is going to eventually % get used by someone.
What exactly mean "top level module"? I'd consider dnf to be top level not dnf.arch.
% See % https://www.python.org/dev/peps/pep-0008/#public-and-internal-interfaces % for the correct way to manage exposing public methods (eg. use of % __all__ and _)
Public and internal interfaces
... Documented interfaces are considered public, unless the documentation explicitly declares them to be provisional or internal interfaces exempt from the usual backwards compatibility guarantees. All *undocumented* interfaces should be assumed to be internal.
% Also, it is pretty clear that this method is in use by dnf users. It % would be far better if you added arch.py with a deprecation warning % instead of insisting that all your users rewrite their code across 4 % releases.
-- Michael Mráka Software Management Engineering, Red Hat
On Monday, February 29, 2016 12:39:40 PM CST Michael Mraka wrote:
Brian C. Lane wrote: % % This code was in a top level module and was not marked with _ as is % the python convention for private methods. Whether or not you document % the api is immaterial. If you expose a method it is going to eventually % get used by someone.
What exactly mean "top level module"? I'd consider dnf to be top level not dnf.arch.
% See % https://www.python.org/dev/peps/pep-0008/#public-and-internal-interfaces % for the correct way to manage exposing public methods (eg. use of % __all__ and _)
Public and internal interfaces
... Documented interfaces are considered public, unless the documentation explicitly declares them to be provisional or internal interfaces exempt from the usual backwards compatibility guarantees. All *undocumented* interfaces should be assumed to be internal.
% Also, it is pretty clear that this method is in use by dnf users. It % would be far better if you added arch.py with a deprecation warning % instead of insisting that all your users rewrite their code across 4 % releases.
After the dnf build today composing broke again https://kojipkgs.fedoraproject.org/compose/rawhide/Fedora-Rawhide-20160309.n. 1/logs/x86_64/buildinstall-Server.x86_64.log
I have yet again untagged the dnf build from rawhide, and given negative feedback on the updates to make sure they do not go out also. I could not find a Fedora 24 update for the build there. Please fix this in dnf approrpiately. you have to assume people are using an api call that does not have _ infront of it as is the python standard, regardless of if you documented the interface or not.
Dennis