Bootstrapping Python
Hey All, Yesterday we had a successful meeting [1] on bootstrapping Python. For those who might wonder what this is about: To build python-setuptools for Python 3.11 one needs python-setuptools. The same bootstrapping issue exists for other Python packages, which provide (PEP517) build backends and are required for building the remaining ecosystem from scratch. Filipe has created a project to tackle this issue, it uses python-installer to temporarily create wheels for setuptools, pep517, installer and other packages. [2] These can then be packaged using a PKGBUILD [3] and replace the existing python-setuptools package temporarily to build the "real" python-setuptools. Bootstrapping these tools will be a multiple stage bootstrap (and assumes an already available interpreter package such as python 3.11): 1. Build python-bootstrap 2. Build python-setuptools and co. (without tests) 3. Build all makedepends and depends of the bootstrapped packages (without tests) 4. Build "real" packages (those that have been bootstrapped) and replace the initial bootstrapped packages with them (without tests). 5. Build the ecosystem using the available packages (without tests) 6. Rebuild the ecosystem with tests In the future we want to rely on python-bootstrap to allow us to transparently bootstrap the Python ecosystem on a new release and document the workflow there. Not all initially required packages are defined yet, but a first attempt at bootstrapping can be found in a custom repository already [4]. This has been a quick PoC, we still need to put in a lot of work to get this to work out of the box - Get a full bootstrap working using python-bootstrap - Figure out how we deal with sphinx being a build requirement of python-installer/builder blocking bootstrapping - Figure out how to bootstrap setuptools - Create a script to determine the bootstrap order (using our repository database) - Better tooling for creating custom repositories / devtools chroots for these rebuilds - Automatically update python-bootstrap's git submodules to the repository version - Add documentation about the entire process If you have time to help testing and developing, please come join us in #archlinux-python on libera.chat. [1] https://md.archlinux.org/s/rBZYhg_fE# [2] https://gitlab.archlinux.org/archlinux/python-bootstrap [3] https://gitlab.archlinux.org/archlinux/python-bootstrap/-/blob/PKGBUILD/PKGBUILD [4] https://pkgbuild.com/~jelle/python3.11/ OpenPGP_signature Description: OpenPGP digital signature
Re: [arch-dev-public] openssl 3.0
On Tue, 25 Oct 2022 at 20:03, Levente Polyak wrote: > https://mta.openssl.org/pipermail/openssl-announce/2022-October/000238.html Started the rebuilds with 3.0.5, let's not forget to bump to 3.0.7 before moving to testing!
Re: [arch-dev-public] openssl 3.0
Thanks a lot for pushing this forward!
I updated to 3.0.7 in staging. I had libprovides in my branch. Do you
guys think this might be handy to define versioned dependencies when
we have potentially three different openssl verions to maintain?
provides=('libcrypto.so' 'libssl.so')
At the same time 1.1.1s was released which mainly fixes a regression
from 1.1.1r (we are on 1.1.q). Do you guys think it is worth to
release that 1.1.1 update in the meantime?
Greetings,
Pierre
On Tue, Nov 1, 2022 at 12:19 PM Evangelos Foutras
wrote:
>
> On Tue, 25 Oct 2022 at 20:03, Levente Polyak wrote:
> > https://mta.openssl.org/pipermail/openssl-announce/2022-October/000238.html
>
> Started the rebuilds with 3.0.5, let's not forget to bump to 3.0.7
> before moving to testing!
--
Pierre Schmitz, https://pierre-schmitz.com
Re: [arch-dev-public] openssl 3.0
On 2022-11-01 18:27:23 (+0100), Pierre Schmitz wrote:
> I updated to 3.0.7 in staging. I had libprovides in my branch. Do you
> guys think this might be handy to define versioned dependencies when
> we have potentially three different openssl verions to maintain?
>
> provides=('libcrypto.so' 'libssl.so')
Always a fan! Please add! :)
> At the same time 1.1.1s was released which mainly fixes a regression
> from 1.1.1r (we are on 1.1.q). Do you guys think it is worth to
> release that 1.1.1 update in the meantime?
If it is not critical, maybe better to let the openssl 3 rebuild roll
through.
Best,
David
--
https://sleepmap.de
signature.asc
Description: PGP signature
Re: [arch-dev-public] openssl 3.0
Alright, I have updated openssl-1.1 (the one in staging) to the latest
version and both include libprovides now. In addition to this
openssl-1.1 provides openssl=1.1.1
On Tue, Nov 1, 2022 at 7:01 PM Luna Jernberg wrote:
>
> 1.1.1r is just bugfixes and no critical security fix as in the 3.0x series
>
> On Tue, Nov 1, 2022 at 6:57 PM David Runge wrote:
> >
> > On 2022-11-01 18:27:23 (+0100), Pierre Schmitz wrote:
> > > I updated to 3.0.7 in staging. I had libprovides in my branch. Do you
> > > guys think this might be handy to define versioned dependencies when
> > > we have potentially three different openssl verions to maintain?
> > >
> > > provides=('libcrypto.so' 'libssl.so')
> >
> > Always a fan! Please add! :)
> >
> > > At the same time 1.1.1s was released which mainly fixes a regression
> > > from 1.1.1r (we are on 1.1.q). Do you guys think it is worth to
> > > release that 1.1.1 update in the meantime?
> >
> > If it is not critical, maybe better to let the openssl 3 rebuild roll
> > through.
> >
> > Best,
> > David
> >
> > --
> > https://sleepmap.de
--
Pierre Schmitz, https://pierre-schmitz.com
