From mboxrd@z Thu Jan 1 00:00:00 1970 From: Michael Tremer To: development@lists.ipfire.org Subject: Re: Info on problems with python3-setuptools for IPFire-3.x Date: Thu, 28 Sep 2023 10:46:20 +0100 Message-ID: <98CB96EA-B041-4A81-BDE5-B3B5036C2BEE@ipfire.org> In-Reply-To: <19f48063-6aa3-4f8a-9bfa-62e24a79d030@ipfire.org> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============2500959027200343089==" List-Id: --===============2500959027200343089== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Hello Adolf, > On 21 Sep 2023, at 19:25, Adolf Belka wrote: >=20 > Hi All, >=20 > The IPFire-3.x version of python3-setuptools is quite old so I thought I wo= uld have a go at updating it but had a few problems on the way. >=20 > Running the existing version for 65.6.3 results in >=20 > Building python3-setuptools-65.6.3-1.ipfire3.src... > python3-setuptools-65.6.3-1.ipfire3.src does not support being built on x86= _64 > OSError: [Errno 0] Error >=20 > Removing the line from the build section that has arches =3D noarch stops t= hat error occurring. Most of the other python3 .nm files don't have that arch= es line present. Yes, this is a =E2=80=9Cfeature=E2=80=9D. Some packages do not depend on a sp= ecific architecture. For example a package that only ships a shell script whi= ch would run on any architecture that has a shell. In that case, we won=E2=80= =99t need to compile the same packages multiple times for each supported arch= itecture, but we only create one package that has =E2=80=9Cnoarch=E2=80=9D as= its architecture. To tell the build system that, there is a variable called =E2=80=9Carches=E2= =80=9D in the build section of the makefile. The variable could also have =E2= =80=9Cx86_64=E2=80=9D in it if something is not support on let=E2=80=99s say = aarch64: https://git.ipfire.org/?p=3Dipfire-3.x.git;a=3Dblob;f=3Dhyperscan/hyperscan= .nm;h=3D793a5729f0bff60ce1e7f6391141e749975575aa;hb=3DHEAD#l28 Because the build system is set up first, and then we look at the package we = are supposed to build, we require that you pass the architecture you want to = build for on the command line. The default is the architecture of your build = system. > Trying to then run version 68.2.2 resulted in the error > Could not add 'setuptools-68.2.2.tar.gz' to package: Success This is a slightly bad error message from the downloader. I will put this on = my list to make it clearer what it actually is complaining about. > Testing out the download url I found that it works with version 65.6.3 but = not with 68.2.2. Looking at the download from PyPI I found that other parts o= f the download url are changed for different versions of the same package. >=20 > The download url for 65.6.3 and for 68.2.2 are shown below for comparison >=20 > https://files.pythonhosted.org/packages/b6/21/cb9a8d0b2c8597c83fce8e9c02884= bce3d4951e41e807fc35791c6b23d9a/setuptools-65.6.3.tar.gz > https://files.pythonhosted.org/packages/ef/cc/93f7213b2ab5ed383f98ce8020e63= 2ef256b406b8569606c3f160ed8e1c9/setuptools-68.2.2.tar.gz This is inconvenient, but it seems that this is the only way to do this then= =E2=80=A6 -Michael > The above means that each time the version number is changed the download u= rl will also need to be manually edited for all downloads from PyPI. >=20 > After changing the download url then the package downloaded and was success= fully built. >=20 > Regards, >=20 > Adolf. >=20 >=20 >=20 > --=20 >=20 > Sent from my laptop >=20 --===============2500959027200343089==--