[HEADS UP] Fedora 33 Python 3.9 rebuilds have started in a side tag

[Miro Hrončok]

Hello, in order to deliver Python 3.9, we are running a coordinated rebuild in a 
side tag.

     https://fedoraproject.org/wiki/Changes/Python3.9

If you see a "Rebuilt for Python 3.9" (or similar) commit in your package, 
please don't rebuild it in regular rawhide.
If you need to, please let me know, so we can coordinate.

If you'd like to build the package, you should be able to build it in the side 
tag via:

     on branch master:
     $ fedpkg build --target=f33-python
     $ koji wait-repo f33-python --build <nvr>

Note that it will take a while before all the essential packages are rebuilt, so 
don't except all your dependencies to be available right away. When in trouble, 
ask here or on IRC (#fedora-python on Freenode).

Builds: 
https://koji.fedoraproject.org/koji/builds?latest=0&tagID=22287&o...

Please avoid any potentially disturbing changes in Python packages until the 
rebuild is over.

Thanks. Let us know if you have any questions.

PS I've BCC'ed maintainers of the "initial bootstrap sequence". If your
package 
is listed bellow, it means it is essential that you coordinate all rawhide 
changes -- if you don't, this may potentially make the disturbed experience 
longer than necessary. Thank You so much for your patience.

Maintainers by package:
Cython               churchyard ignatenkobrain nbecker stevetraylen
GitPython            dgoodwin ignatenkobrain lsedlar
PyQt4                rdieter than
PyYAML               jeckersb
abrt                 abrt-team ekulik jfilak mgrabovs mhabrnal mmarusak msuchy
anaconda             anaconda-maint jkonecny m4rtink rvykydal sbueno vpodzime 
vponcova
asciidoc             jridky nphilipp sochotni tmz
babel                fschwarz nphilipp
bodhi                abompard
boost                denisarnaud jwakely
breezy               churchyard dormouse opohorel
brotli               carlwgeorge pouar tagoh
clang                airlied daveisfera sbergmann sergesanspaille siddharths 
tstellar
cloud-init           dustymabe gholms larsks mhayden otubo
createrepo_c         dmach jrohel mblaha pkratoch tmlcoch
dblatex              alexlan jchaloup mjg
dbus-python          alexl amigadave besser82 caillon caolanm johnp mbarnes 
ngompa phuang rdieter rhughes rstrode ssp stefanok vtrefny
dnf                  dmach jmracek jrohel mblaha pkratoch
dnf-plugins-core     dmach jmracek mblaha pkratoch
dnf-plugins-extras   dmach jmracek mblaha pkratoch
fedmod               karsten nphilipp
fedmsg               clime
fedora-messaging     abompard
fedpkg               cqi lsedlar onosek
file                 kdudka macermak odubaj svashisht vmihalko
fros                 jfilak
future               sagitter
gdb                  jankratochvil keiths kevinb sergiodj
glade                kalev
gobject-introspection dcbw otaylor walters
gpgme                fkluknav ignatenkobrain isimluk rdieter tmraz
ipython              churchyard cstratak dcantrell ignatenkobrain lbalhar mrunge 
salimma tomspur
kernel-tools         jcline jforbes jwboyer labbott pbrobinson
kobo                 dmach rohanpm
koji                 ausil kevin mikem puiterwijk
libblockdev          sbueno tbzatek vpodzime vtrefny
libbytesize          tbzatek vpodzime vtrefny
libcomps             akozumpl dmach jluza jmracek mblaha pkratoch
libdnf               dmach jmracek jrohel mblaha pkratoch
libgit2-glib         ignatenkobrain kalev nacho pwalter
libmodulemd          asamalik nphilipp sgallagh
libpwquality         tmraz
librepo              dmach pkratoch tmlcoch
libreport            abrt-team ekulik jfilak mgrabovs mhabrnal mmarusak msuchy
libselinux           dwalsh mgrepl pcmoore plautrba vmojzis
libsolv              dmach ignatenkobrain jmracek jrohel ngompa pkratoch
libxml2              ignatenkobrain jpokorny veillard
lorax                bcl clumens dcantrell dshea wwoods
meson                carlwgeorge ekulik ignatenkobrain wtaymans
mock                 jcwillia mebrown msuchy praiskup
mpich                deji zbyszek
numpy                cstratak jspaleta limb orion rdieter tomspur ttomecek
openmpi              deji dledford jhladky orion pkfed
pdc-client           bliu chcao cheng chuzhang lholecek lsedlar sochotni
policycoreutils      dwalsh lvrabec mgrepl pcmoore plautrba vmojzis
pungi                dmach lsedlar maxamillion onosek tdawson wwoods
pyOpenSSL            jcline jlieskov lmacken tmraz
pycairo              alexl caillon caolanm johnp kalev ralph rhughes rstrode ssp
pydot                besser82 spot
pygobject3           johnp nacho walters
pykickstart          bcl clumens dcantrell jkonecny m4rtink rvykydal sbueno vponcova
pyparsing            apevec jamatos sharkcz terjeros
pyparted             bcl clumens dcantrell
pysendfile           russellb
pyserial             stingray
pytest               churchyard mrunge radez thm
python-Automat       carlwgeorge eclipseo
python-Bottleneck    besser82
python-Pallets-Sphinx-Themes codeblock
python-PyPDF2        aarem
python-WSGIProxy2    ondrejj
python-aiohttp       fab ignatenkobrain
python-alembic       ralph
python-anytree       gerd lkundrak
python-apipkg        fab ktdreyer thm
python-appdirs       apevec hguemar ignatenkobrain
python-argcomplete   churchyard dageek ignatenkobrain stevetraylen
python-argh          cstratak
python-arrow         pingou ralph
python-asgiref       carlwgeorge
python-asn1crypto    cheimes npmccallum
python-astroid       bcl limb lupinix mrunge orion
python-async-generator carlwgeorge
python-async-timeout clime fab ignatenkobrain
python-atomicwrites  mathstuf mbaldessari
python-attrs         brouhaha churchyard lbalhar
python-augeas        xaeth
python-backcall      churchyard orion
python-backoff       abompard
python-bcrypt        pingou williamjmorenor
python-beanbag       sochotni
python-beautifulsoup4 kevin mrunge ralph terjeros
python-betamax       ignatenkobrain pnemade
python-billiard      fab mrunge ngompa pingou pjp rmarko sundaram
python-bleach        bowlofeggs ignatenkobrain mrunge
python-blinker       kumarpraveen pjp sundaram
python-blivet        blivet-maint dlehman japokorn jkonecny m4rtink rvykydal 
sbueno vpodzime vponcova vtrefny
python-boto          apevec gholms limb skottler
python-boto3         cstratak fale
python-botocore      davdunc fale gholms lkundrak
python-bottle        sundaram
python-bugzilla      crobinso dzickus
python-case          mrunge ngompa pingou
python-cccolutils    puiterwijk
python-celery        abompard mrunge ngompa pingou
python-certifi       churchyard jmontleon
python-cffi          brouhaha churchyard lbalhar
python-chai          kevin pingou ralph
python-chardet       churchyard jcline kushal
python-click         cstratak fab
python-click-completion chedi wakko666
python-colander      ignatenkobrain lmacken ralph
python-configobj     dcallagh fale lmacken terjeros
python-constantly    eclipseo
python-contextlib2   abompard pingou ralph tjikkun
python-cornice       hguemar lmacken
python-cornice-sphinx abompard
python-cov-core      abompard bkabrda
python-coverage      abompard lmacken mrunge spot
python-cpuinfo       pnemade
python-crochet       abompard
python-cryptography  ayrx cheimes itamarjp jcline noodles npmccallum
python-cryptography-vectors cheimes jcline noodles npmccallum
python-cssselect     brouhaha echevemaster kevin ralph
python-cycler        nbecker
python-daemon        kushal lmacken ralph tomspur
python-dateutil      hguemar jspaleta limb pjp tomspur
python-decorator     fale kevin ralph
python-defusedxml    bkabrda churchyard
python-dict-sorted   fale ignatenkobrain
python-distro        mblaha msuchy
python-django        bkabrda churchyard jdornak mrunge rdopiera salimma sgallagh
python-docutils      mstuchli oddshocks
python-dogpile-cache ralph
python-dulwich       fab
python-editor        apevec kevin ralph social
python-elementpath   churchyard
python-enchant       cstratak mmraka
python-entrypoints   nonamedotc orion
python-execnet       adeza ktdreyer thm
python-extras        mrunge salimma
python-fastimport    dcallagh
python-fedora        codeblock ricky
python-feedgen       lbalhar
python-fields        cottsay
python-filelock      cottsay
python-fixtures      apevec mrunge pabelanger
python-flake8        fale mrunge sgallagh
python-flaky         churchyard
python-flask         codeblock hguemar hushan
python-flask-sphinx-themes devrim itamarjp
python-flit          churchyard
python-fluidity-sm   pghmcfc
python-freezegun     cstratak kevin ralph
python-funcsigs      hguemar ralph
python-genshi        fschwarz
python-genty         churchyard
python-gevent        dcallagh ignatenkobrain orion skottler
python-gitdb         ignatenkobrain lsedlar
python-graphviz      eclipseo
python-greenlet      abbot ignatenkobrain kevin salimma terjeros
python-h2            eclipseo
python-hamcrest      ignatenkobrain
python-hpack         eclipseo
python-html5lib      churchyard pjp sagitter salimma sundaram
python-httpbin       adamwill
python-httplib2      abompard dchen ignatenkobrain jspaleta kevin limb
python-httpretty     jpopelka
python-humanize      jfilak stevetraylen
python-hupper        kevin
python-hyperframe    eclipseo
python-hyperlink     eclipseo
python-hypothesis    churchyard ignatenkobrain pingou salimma
python-idna          churchyard cstratak lbalhar
python-imagesize     aviso
python-incremental   ykarel
python-iniparse      ignatenkobrain lupinix
python-invoke        pghmcfc
python-ipykernel     churchyard pcpa
python-ipython_genutils orion
python-iso8601       fab ilianaw
python-isodate       dcallagh dscott jlaska jmatthews
python-isort         limb orion
python-itsdangerous  dcallagh ignatenkobrain
python-jedi          carlwgeorge phracek
python-jinja2        thm
python-jmespath      fale gholms kevin lkundrak
python-jsonpatch     apevec dprince skottler
python-jsonpointer   agerstmayr dprince mgoodwin nathans skottler
python-jsonschema    apevec decathorpe
python-jupyter-client churchyard tomspur
python-jupyter-core  churchyard orion tomspur
python-jwt           carlwgeorge kevin ralph
python-kerberos      rcritten simo
python-kitchen       kevin pingou ralph
python-kiwisolver    qulogic
python-latexcodec    jjames
python-lazy-object-proxy bcl limb lupinix
python-ldap          alexl caillon caolanm johnp pspacek rhughes rstrode ssp
python-lexicon       pghmcfc
python-lit           sergesanspaille tstellar
python-lockfile      decathorpe kevin moezroy xavierb
python-lxml          fale ignatenkobrain mizdebsk
python-m2r           nforro
python-mako          abompard cverna ignatenkobrain kylev lmacken
python-markdown      thm
python-markupsafe    churchyard
python-matplotlib    cstratak jgu jspaleta pcpa rathann tomspur
python-mccabe        churchyard
python-meh           clumens m4rtink vpodzime
python-memcached     apevec hguemar kevin sgallagh
python-mimeparse     abompard carlwgeorge stevetraylen
python-mistune       lupinix
python-mock          kumarpraveen ttorling
python-moksha-common lbalhar lmacken ralph
python-moksha-hub    lbalhar lmacken ralph
python-more-itertools aarem churchyard jcaratzas
python-multidict     athmane fab ignatenkobrain
python-multilib      jgreguske lsedlar
python-munch         kevin ralph
python-nbconvert     nonamedotc
python-nbformat      orion tomspur
python-nbsphinx      churchyard
python-nose          churchyard
python-nose-cov      jdulaney
python-nose-exclude  mrunge
python-nose2         abompard
python-nose_warnings_filters churchyard
python-notebook      churchyard
python-ntplib        vpodzime
python-numexpr       tnorth zbyszek
python-numpydoc      orion tomspur
python-oauthlib      jdornak ralph
python-olefile       rebus robert smani
python-openid-cla    puiterwijk
python-openid-teams  puiterwijk
python-openidc-client mohanboddu puiterwijk
python-openstackdocstheme jpena
python-ordered-set   msuchy
python-orderedset    jjames
python-packaging     lbalhar
python-pandas        kushal orion sergiopr wakko666
python-pandocfilters zbyszek
python-parameterized ignatenkobrain
python-paramiko      athmane ignatenkobrain ivazquez orion pghmcfc sgallagh
python-parso         carlwgeorge
python-paste         abompard dcallagh kylev
python-paste-deploy  dcallagh kylev lmacken ralph
python-path          jcaratzas laxathom
python-pathlib2      pcpa
python-pbr           apevec mrunge
python-pexpect       amcnabb fabiand ignatenkobrain radez swt2c tomspur
python-pickleshare   ignatenkobrain nonamedotc
python-pid           carlwgeorge dshea
python-pika          icheishvili jcline ngompa silas
python-pillow        miminar smani
python-pip           bkabrda churchyard ncoghlan sundaram torsava ttorling
python-plaster       abompard
python-plaster-pastedeploy abompard
python-pluggy        mrunge thm
python-ply           sgallagh spot
python-polib         cicku dchen diegobz dshea ivazquez moezroy suanand
python-pretend       piotrp
python-prettytable   apevec clalance imcleod
python-priority      eclipseo
python-process-tests orion
python-productmd     dmach lsedlar
python-prometheus_client mprahl
python-prompt-toolkit carlwgeorge fale
python-psutil        salimma
python-psycopg2      devrim hhorak jmlich panovotn praiskup
python-ptyprocess    ignatenkobrain orion tomspur
python-py            mrunge thm
python-pyasn1        kanarip rcritten
python-pybtex        jjames
python-pybtex-docutils jjames
python-pycdlib       clalance
python-pycodestyle   churchyard orion
python-pycparser     brouhaha churchyard lbalhar
python-pycurl        jsynacek kdudka msekleta svashisht
python-pydbus        m4rtink
python-pyglet        orion pviktori
python-pygments      churchyard smilner
python-pygments-pytest churchyard jcaratzas
python-pylibravatar  kevin ralph
python-pymongo       amcnabb apevec cstratak hhorak mskalick
python-pynacl        ignatenkobrain
python-pyquery       kevin ralph
python-pyramid       kevin lmacken ralph rossdylan tdabasin
python-pyramid-fas-openid abompard
python-pyramid-mako  kevin ralph
python-pyroute2      jirka pavlix psavelye
python-pyrsistent    decathorpe devrim itamarjp
python-pysocks       abompard kevin ralph ttorling
python-pytest-aiohttp fab
python-pytest-benchmark jorti
python-pytest-capturelog ignatenkobrain mstuchli pviktori
python-pytest-cov    chedi cstratak ttomecek
python-pytest-expect churchyard
python-pytest-fixture-config kevin
python-pytest-forked swt2c
python-pytest-httpbin adamwill
python-pytest-mock   jujens
python-pytest-relaxed athmane
python-pytest-rerunfailures cottsay
python-pytest-runner vrutkovs
python-pytest-shutil kevin
python-pytest-timeout swt2c
python-pytest-virtualenv kevin
python-pytest-xdist  swt2c
python-pytoml        churchyard jcline jujens
python-pyudev        clockfort dshea mulhern
python-qt5           rdieter than
python-raven         tjikkun
python-rdflib        dcallagh dmalcolm dscott nphilipp pingou
python-redis         cicku kevin maxamillion ralph
python-repoze-lru    adeza jcaratzas
python-requests      abompard cstratak jcline ralph sagarun
python-requests-download churchyard
python-requests-file dshea
python-requests-ftp  dshea
python-requests-kerberos dcallagh
python-requests-toolbelt ignatenkobrain pnemade
python-responses     athoscr
python-rpmfluff      dshea ignatenkobrain jhutar jlaska
python-rsa           fale jmontleon
python-s3transfer    fale ignatenkobrain
python-scripttest    churchyard mbacovsk
python-selenium      halfie mrunge
python-semantic_version apevec hguemar mhrivnak
python-send2trash    churchyard
python-service-identity eclipseo ignatenkobrain ralph
python-setuptools    churchyard cstratak
python-setuptools_git apevec
python-setuptools_scm churchyard cstratak ignatenkobrain orion stevetraylen
python-shellingham   churchyard
python-should_dsl    pghmcfc
python-simplegeneric churchyard ignatenkobrain jcaratzas tomspur
python-simplejson    fab ignatenkobrain kylev mrunge
python-simpleline    jkonecny m4rtink sbueno
python-simplemediawiki lmacken potty ralph
python-six           apevec bkabrda churchyard mrunge pviktori
python-smartcols     ignatenkobrain
python-smmap         ignatenkobrain lsedlar
python-snowballstemmer cottsay jujens
python-soupsieve     zbyszek
python-spec          pghmcfc
python-sphinx        aviso churchyard cstratak salimma toshio
python-sphinx-epytext churchyard dormouse opohorel
python-sphinx-issues qulogic
python-sphinx-removed-in churchyard jcaratzas
python-sphinx-testing jcaratzas jjames
python-sphinx-theme-alabaster jujens orion
python-sphinx-theme-py3doc-enhanced jujens
python-sphinx_rtd_theme itamarjp jjames piotrp
python-sphinxcontrib-apidoc chandankumar
python-sphinxcontrib-applehelp churchyard cstratak
python-sphinxcontrib-bibtex jjames
python-sphinxcontrib-devhelp churchyard
python-sphinxcontrib-github-alt churchyard
python-sphinxcontrib-htmlhelp churchyard cstratak
python-sphinxcontrib-httpdomain dcallagh
python-sphinxcontrib-jsmath churchyard cstratak
python-sphinxcontrib-log-cabinet thm
python-sphinxcontrib-qthelp churchyard cstratak
python-sphinxcontrib-serializinghtml churchyard cstratak
python-sphinxcontrib-trio jcaratzas thm
python-sphinxcontrib-websupport churchyard jpena
python-sqlalchemy    ivazquez lmacken nphilipp
python-sqlalchemy_schemadisplay orphan
python-sqlparse      fale hhorak jdulaney
python-stomper       mprahl ralph
python-sure          bkabrda churchyard
python-systemd       mjia zbyszek
python-tables        tnorth zbyszek
python-tempita       kylev ricky
python-termcolor     mrunge
python-terminado     churchyard orion ttorling
python-testpath      churchyard thrnciar
python-testscenarios apevec ktdreyer mrunge
python-testtools     abompard kumarpraveen salimma
python-tidy          terjeros
python-toml          jujens
python-tornado       abompard churchyard orion tomspur
python-towncrier     eclipseo
python-tox           cathay4t churchyard mrunge
python-tox-current-env churchyard pviktori
python-traitlets     churchyard orion
python-transaction   abompard ondrejj
python-translationstring abompard
python-trustme       carlwgeorge jcaratzas
python-twisted       churchyard eclipseo jsteffan tomprince
python-txws          kevin ralph
python-txzmq         kevin ralph
python-u-msgpack-python churchyard
python-urllib3       abompard jcline sagarun
python-vcrpy         kevin ralph
python-venusian      lmacken ralph rossdylan tdabasin
python-virtualenv    churchyard cstratak mhayden mrunge orion smilner
python-waitress      lgs ralph
python-wcwidth       abompard aviso churchyard fale
python-webencodings  abompard
python-webob         hguemar lmacken mrunge ralph ricky
python-websocket-client carlwgeorge
python-webtest       lmacken ondrejj ricky
python-werkzeug      abompard codeblock hguemar
python-wheel         churchyard cstratak ignatenkobrain torsava
python-whoosh        mstuchli rkuska sgallagh
python-wrapt         chandankumar ralph
python-wxpython4     swt2c
python-xmlschema     churchyard
python-yarl          fab ignatenkobrain
python-zbase32       anishpatil
python-zmq           ralph tomspur
python-zope-component abompard ralph tdabasin
python-zope-configuration abompard tdabasin
python-zope-deprecation abompard tdabasin
python-zope-event    abompard ralph tdabasin
python-zope-exceptions abompard ralph tdabasin
python-zope-i18nmessageid orphan ralph tdabasin
python-zope-interface lbalhar ralph
python-zope-schema   abompard ralph tdabasin
python-zope-testing  abompard ralph tdabasin
python3-openid       jdornak puiterwijk
python3-py3dns       bojan kevin ralph
python3-pytest-asyncio jujens
python3-typed_ast    limb
pytz                 limb
pyutil               anishpatil
pyxattr              defolos frankcrawford kevin szpak
pyxdg                spot
rpkg                 cqi lsedlar onosek
rpm                  ffesti ignatenkobrain mjw packaging-team pmatilai pmoravco 
vmukhame
rpmconf              mjakubicek msuchy
rpmlint              kevin spot tibbs tmz twoerner
scipy                cstratak jspaleta orion tomspur ttomecek
sip                  rdieter than
unbound              aegorenk akhaitov pavlix pemensik pwouters thozza
waf                  salimma thm

Packages by maintainer:
aarem      python-PyPDF2 python-more-itertools
abbot      python-greenlet
abompard   bodhi fedora-messaging python-backoff python-celery 
python-contextlib2 python-cornice-sphinx python-cov-core python-coverage 
python-crochet python-httplib2 python-mako python-mimeparse python-nose2 
python-paste python-plaster python-plaster-pastedeploy python-pyramid-fas-openid 
python-pysocks python-requests python-testtools python-tornado 
python-transaction python-translationstring python-urllib3 python-wcwidth 
python-webencodings python-werkzeug python-zope-component 
python-zope-configuration python-zope-deprecation python-zope-event 
python-zope-exceptions python-zope-schema python-zope-testing
abrt-team  abrt libreport
adamwill   python-httpbin python-pytest-httpbin
adeza      python-execnet python-repoze-lru
aegorenk   unbound
agerstmayr python-jsonpointer
airlied    clang
akhaitov   unbound
akozumpl   libcomps
alexl      dbus-python pycairo python-ldap
alexlan    dblatex
amcnabb    python-pexpect python-pymongo
amigadave  dbus-python
anaconda-maint anaconda
anishpatil python-zbase32 pyutil
apevec     pyparsing python-appdirs python-boto python-editor python-fixtures 
python-jsonpatch python-jsonschema python-memcached python-pbr 
python-prettytable python-pymongo python-semantic_version python-setuptools_git 
python-six python-testscenarios
asamalik   libmodulemd
athmane    python-multidict python-paramiko python-pytest-relaxed
athoscr    python-responses
ausil      koji
aviso      python-imagesize python-sphinx python-wcwidth
ayrx       python-cryptography
bcl        lorax pykickstart pyparted python-astroid python-lazy-object-proxy
besser82   dbus-python pydot python-Bottleneck
bkabrda    python-cov-core python-defusedxml python-django python-pip python-six 
python-sure
bliu       pdc-client
blivet-maint python-blivet
bojan      python3-py3dns
bowlofeggs python-bleach
brouhaha   python-attrs python-cffi python-cssselect python-pycparser
caillon    dbus-python pycairo python-ldap
caolanm    dbus-python pycairo python-ldap
carlwgeorge brotli meson python-Automat python-asgiref python-async-generator 
python-jedi python-jwt python-mimeparse python-parso python-pid 
python-prompt-toolkit python-trustme python-websocket-client
cathay4t   python-tox
chandankumar python-sphinxcontrib-apidoc python-wrapt
chcao      pdc-client
chedi      python-click-completion python-pytest-cov
cheimes    python-asn1crypto python-cryptography python-cryptography-vectors
cheng      pdc-client
churchyard Cython breezy ipython pytest python-argcomplete python-attrs 
python-backcall python-certifi python-cffi python-chardet python-defusedxml 
python-django python-elementpath python-flaky python-flit python-genty 
python-html5lib python-hypothesis python-idna python-ipykernel 
python-jupyter-client python-jupyter-core python-markupsafe python-mccabe 
python-more-itertools python-nbsphinx python-nose python-nose_warnings_filters 
python-notebook python-pip python-pycodestyle python-pycparser python-pygments 
python-pygments-pytest python-pytest-expect python-pytoml 
python-requests-download python-scripttest python-send2trash python-setuptools 
python-setuptools_scm python-shellingham python-simplegeneric python-six 
python-sphinx python-sphinx-epytext python-sphinx-removed-in 
python-sphinxcontrib-applehelp python-sphinxcontrib-devhelp 
python-sphinxcontrib-github-alt python-sphinxcontrib-htmlhelp 
python-sphinxcontrib-jsmath python-sphinxcontrib-qthelp 
python-sphinxcontrib-serializinghtml python-sphinxcontrib-websupport python-sure 
python-terminado python-testpath python-tornado python-tox 
python-tox-current-env python-traitlets python-twisted python-u-msgpack-python 
python-virtualenv python-wcwidth python-wheel python-xmlschema
chuzhang   pdc-client
cicku      python-polib python-redis
clalance   python-prettytable python-pycdlib
clime      fedmsg python-async-timeout
clockfort  python-pyudev
clumens    lorax pykickstart pyparted python-meh
codeblock  python-Pallets-Sphinx-Themes python-fedora python-flask python-werkzeug
cottsay    python-fields python-filelock python-pytest-rerunfailures 
python-snowballstemmer
cqi        fedpkg rpkg
crobinso   python-bugzilla
cstratak   ipython numpy python-argh python-boto3 python-click python-enchant 
python-freezegun python-idna python-matplotlib python-pymongo python-pytest-cov 
python-requests python-setuptools python-setuptools_scm python-sphinx 
python-sphinxcontrib-applehelp python-sphinxcontrib-htmlhelp 
python-sphinxcontrib-jsmath python-sphinxcontrib-qthelp 
python-sphinxcontrib-serializinghtml python-virtualenv python-wheel scipy
cverna     python-mako
dageek     python-argcomplete
davdunc    python-botocore
daveisfera clang
dcallagh   python-configobj python-fastimport python-gevent python-isodate 
python-itsdangerous python-paste python-paste-deploy python-rdflib 
python-requests-kerberos python-sphinxcontrib-httpdomain
dcantrell  ipython lorax pykickstart pyparted
dcbw       gobject-introspection
dchen      python-httplib2 python-polib
decathorpe python-jsonschema python-lockfile python-pyrsistent
defolos    pyxattr
deji       mpich openmpi
denisarnaud boost
devrim     python-flask-sphinx-themes python-psycopg2 python-pyrsistent
dgoodwin   GitPython
diegobz    python-polib
dledford   openmpi
dlehman    python-blivet
dmach      createrepo_c dnf dnf-plugins-core dnf-plugins-extras kobo libcomps 
libdnf librepo libsolv pungi python-productmd
dmalcolm   python-rdflib
dormouse   breezy python-sphinx-epytext
dprince    python-jsonpatch python-jsonpointer
dscott     python-isodate python-rdflib
dshea      lorax python-pid python-polib python-pyudev python-requests-file 
python-requests-ftp python-rpmfluff
dustymabe  cloud-init
dwalsh     libselinux policycoreutils
dzickus    python-bugzilla
echevemaster python-cssselect
eclipseo   python-Automat python-constantly python-graphviz python-h2 
python-hpack python-hyperframe python-hyperlink python-priority 
python-service-identity python-towncrier python-twisted
ekulik     abrt libreport meson
fab        python-aiohttp python-apipkg python-async-timeout python-billiard 
python-click python-dulwich python-iso8601 python-multidict 
python-pytest-aiohttp python-simplejson python-yarl
fabiand    python-pexpect
fale       python-boto3 python-botocore python-configobj python-decorator 
python-dict-sorted python-flake8 python-jmespath python-lxml 
python-prompt-toolkit python-rsa python-s3transfer python-sqlparse python-wcwidth
ffesti     rpm
fkluknav   gpgme
frankcrawford pyxattr
fschwarz   babel python-genshi
gerd       python-anytree
gholms     cloud-init python-boto python-botocore python-jmespath
halfie     python-selenium
hguemar    python-appdirs python-cornice python-dateutil python-flask 
python-funcsigs python-memcached python-semantic_version python-webob 
python-werkzeug
hhorak     python-psycopg2 python-pymongo python-sqlparse
hushan     python-flask
icheishvili python-pika
ignatenkobrain Cython GitPython gpgme ipython libgit2-glib libsolv libxml2 meson 
python-aiohttp python-appdirs python-argcomplete python-async-timeout 
python-betamax python-bleach python-colander python-dict-sorted python-gevent 
python-gitdb python-greenlet python-hamcrest python-httplib2 python-hypothesis 
python-iniparse python-itsdangerous python-lxml python-mako python-multidict 
python-parameterized python-paramiko python-pexpect python-pickleshare 
python-ptyprocess python-pynacl python-pytest-capturelog 
python-requests-toolbelt python-rpmfluff python-s3transfer 
python-service-identity python-setuptools_scm python-simplegeneric 
python-simplejson python-smartcols python-smmap python-wheel python-yarl rpm
ilianaw    python-iso8601
imcleod    python-prettytable
isimluk    gpgme
itamarjp   python-cryptography python-flask-sphinx-themes python-pyrsistent 
python-sphinx_rtd_theme
ivazquez   python-paramiko python-polib python-sqlalchemy
jamatos    pyparsing
jankratochvil gdb
japokorn   python-blivet
jcaratzas  python-more-itertools python-path python-pygments-pytest 
python-repoze-lru python-simplegeneric python-sphinx-removed-in 
python-sphinx-testing python-sphinxcontrib-trio python-trustme
jchaloup   dblatex
jcline     kernel-tools pyOpenSSL python-chardet python-cryptography 
python-cryptography-vectors python-pika python-pytoml python-requests python-urllib3
jcwillia   mock
jdornak    python-django python-oauthlib python3-openid
jdulaney   python-nose-cov python-sqlparse
jeckersb   PyYAML
jfilak     abrt fros libreport python-humanize
jforbes    kernel-tools
jgreguske  python-multilib
jgu        python-matplotlib
jhladky    openmpi
jhutar     python-rpmfluff
jirka      python-pyroute2
jjames     python-latexcodec python-orderedset python-pybtex 
python-pybtex-docutils python-sphinx-testing python-sphinx_rtd_theme 
python-sphinxcontrib-bibtex
jkonecny   anaconda pykickstart python-blivet python-simpleline
jlaska     python-isodate python-rpmfluff
jlieskov   pyOpenSSL
jluza      libcomps
jmatthews  python-isodate
jmlich     python-psycopg2
jmontleon  python-certifi python-rsa
jmracek    dnf dnf-plugins-core dnf-plugins-extras libcomps libdnf libsolv
johnp      dbus-python pycairo pygobject3 python-ldap
jorti      python-pytest-benchmark
jpena      python-openstackdocstheme python-sphinxcontrib-websupport
jpokorny   libxml2
jpopelka   python-httpretty
jridky     asciidoc
jrohel     createrepo_c dnf libdnf libsolv
jspaleta   numpy python-dateutil python-httplib2 python-matplotlib scipy
jsteffan   python-twisted
jsynacek   python-pycurl
jujens     python-pytest-mock python-pytoml python-snowballstemmer 
python-sphinx-theme-alabaster python-sphinx-theme-py3doc-enhanced python-toml 
python3-pytest-asyncio
jwakely    boost
jwboyer    kernel-tools
kalev      glade libgit2-glib pycairo
kanarip    python-pyasn1
karsten    fedmod
kdudka     file python-pycurl
keiths     gdb
kevin      koji python-beautifulsoup4 python-chai python-cssselect 
python-decorator python-editor python-freezegun python-greenlet python-httplib2 
python-hupper python-jmespath python-jwt python-kitchen python-lockfile 
python-memcached python-munch python-pylibravatar python-pyquery python-pyramid 
python-pyramid-mako python-pysocks python-pytest-fixture-config 
python-pytest-shutil python-pytest-virtualenv python-redis python-txws 
python-txzmq python-vcrpy python3-py3dns pyxattr rpmlint
kevinb     gdb
ktdreyer   python-apipkg python-execnet python-testscenarios
kumarpraveen python-blinker python-mock python-testtools
kushal     python-chardet python-daemon python-pandas
kylev      python-mako python-paste python-paste-deploy python-simplejson 
python-tempita
labbott    kernel-tools
larsks     cloud-init
laxathom   python-path
lbalhar    ipython python-attrs python-cffi python-feedgen python-idna 
python-moksha-common python-moksha-hub python-packaging python-pycparser 
python-zope-interface
lgs        python-waitress
lholecek   pdc-client
limb       numpy python-astroid python-boto python-dateutil python-httplib2 
python-isort python-lazy-object-proxy python3-typed_ast pytz
lkundrak   python-anytree python-botocore python-jmespath
lmacken    pyOpenSSL python-colander python-configobj python-cornice 
python-coverage python-daemon python-mako python-moksha-common python-moksha-hub 
python-paste-deploy python-pyramid python-simplemediawiki python-sqlalchemy 
python-venusian python-webob python-webtest
lsedlar    GitPython fedpkg pdc-client pungi python-gitdb python-multilib 
python-productmd python-smmap rpkg
lupinix    python-astroid python-iniparse python-lazy-object-proxy python-mistune
lvrabec    policycoreutils
m4rtink    anaconda pykickstart python-blivet python-meh python-pydbus 
python-simpleline
macermak   file
mathstuf   python-atomicwrites
maxamillion pungi python-redis
mbacovsk   python-scripttest
mbaldessari python-atomicwrites
mbarnes    dbus-python
mblaha     createrepo_c dnf dnf-plugins-core dnf-plugins-extras libcomps libdnf 
python-distro
mebrown    mock
mgoodwin   python-jsonpointer
mgrabovs   abrt libreport
mgrepl     libselinux policycoreutils
mhabrnal   abrt libreport
mhayden    cloud-init python-virtualenv
mhrivnak   python-semantic_version
mikem      koji
miminar    python-pillow
mizdebsk   python-lxml
mjakubicek rpmconf
mjg        dblatex
mjia       python-systemd
mjw        rpm
mmarusak   abrt libreport
mmraka     python-enchant
moezroy    python-lockfile python-polib
mohanboddu python-openidc-client
mprahl     python-prometheus_client python-stomper
mrunge     ipython pytest python-astroid python-beautifulsoup4 python-billiard 
python-bleach python-case python-celery python-coverage python-django 
python-extras python-fixtures python-flake8 python-nose-exclude python-pbr 
python-pluggy python-py python-selenium python-simplejson python-six 
python-termcolor python-testscenarios python-tox python-virtualenv python-webob
msekleta   python-pycurl
mskalick   python-pymongo
mstuchli   python-docutils python-pytest-capturelog python-whoosh
msuchy     abrt libreport mock python-distro python-ordered-set rpmconf
mulhern    python-pyudev
nacho      libgit2-glib pygobject3
nathans    python-jsonpointer
nbecker    Cython python-cycler
ncoghlan   python-pip
nforro     python-m2r
ngompa     dbus-python libsolv python-billiard python-case python-celery python-pika
nonamedotc python-entrypoints python-nbconvert python-pickleshare
noodles    python-cryptography python-cryptography-vectors
nphilipp   asciidoc babel fedmod libmodulemd python-rdflib python-sqlalchemy
npmccallum python-asn1crypto python-cryptography python-cryptography-vectors
oddshocks  python-docutils
odubaj     file
ondrejj    python-WSGIProxy2 python-transaction python-webtest
onosek     fedpkg pungi rpkg
opohorel   breezy python-sphinx-epytext
orion      numpy openmpi python-astroid python-backcall python-entrypoints 
python-gevent python-ipython_genutils python-isort python-jupyter-core 
python-nbformat python-numpydoc python-pandas python-paramiko 
python-process-tests python-ptyprocess python-pycodestyle python-pyglet 
python-setuptools_scm python-sphinx-theme-alabaster python-terminado 
python-tornado python-traitlets python-virtualenv scipy
orphan     python-sqlalchemy_schemadisplay python-zope-i18nmessageid
otaylor    gobject-introspection
otubo      cloud-init
pabelanger python-fixtures
packaging-team rpm
panovotn   python-psycopg2
pavlix     python-pyroute2 unbound
pbrobinson kernel-tools
pcmoore    libselinux policycoreutils
pcpa       python-ipykernel python-matplotlib python-pathlib2
pemensik   unbound
pghmcfc    python-fluidity-sm python-invoke python-lexicon python-paramiko 
python-should_dsl python-spec
phracek    python-jedi
phuang     dbus-python
pingou     python-arrow python-bcrypt python-billiard python-case python-celery 
python-chai python-contextlib2 python-hypothesis python-kitchen python-rdflib
piotrp     python-pretend python-sphinx_rtd_theme
pjp        python-billiard python-blinker python-dateutil python-html5lib
pkfed      openmpi
pkratoch   createrepo_c dnf dnf-plugins-core dnf-plugins-extras libcomps libdnf 
librepo libsolv
plautrba   libselinux policycoreutils
pmatilai   rpm
pmoravco   rpm
pnemade    python-betamax python-cpuinfo python-requests-toolbelt
potty      python-simplemediawiki
pouar      brotli
praiskup   mock python-psycopg2
psavelye   python-pyroute2
pspacek    python-ldap
puiterwijk koji python-cccolutils python-openid-cla python-openid-teams 
python-openidc-client python3-openid
pviktori   python-pyglet python-pytest-capturelog python-six python-tox-current-env
pwalter    libgit2-glib
pwouters   unbound
qulogic    python-kiwisolver python-sphinx-issues
radez      pytest python-pexpect
ralph      pycairo python-alembic python-arrow python-beautifulsoup4 python-chai 
python-colander python-contextlib2 python-cssselect python-daemon 
python-decorator python-dogpile-cache python-editor python-freezegun 
python-funcsigs python-jwt python-kitchen python-moksha-common python-moksha-hub 
python-munch python-oauthlib python-paste-deploy python-pylibravatar 
python-pyquery python-pyramid python-pyramid-mako python-pysocks python-redis 
python-requests python-service-identity python-simplemediawiki python-stomper 
python-txws python-txzmq python-vcrpy python-venusian python-waitress 
python-webob python-wrapt python-zmq python-zope-component python-zope-event 
python-zope-exceptions python-zope-i18nmessageid python-zope-interface 
python-zope-schema python-zope-testing python3-py3dns
rathann    python-matplotlib
rcritten   python-kerberos python-pyasn1
rdieter    PyQt4 dbus-python gpgme numpy python-qt5 sip
rdopiera   python-django
rebus      python-olefile
rhughes    dbus-python pycairo python-ldap
ricky      python-fedora python-tempita python-webob python-webtest
rkuska     python-whoosh
rmarko     python-billiard
robert     python-olefile
rohanpm    kobo
rossdylan  python-pyramid python-venusian
rstrode    dbus-python pycairo python-ldap
russellb   pysendfile
rvykydal   anaconda pykickstart python-blivet
sagarun    python-requests python-urllib3
sagitter   future python-html5lib
salimma    ipython python-django python-extras python-greenlet python-html5lib 
python-hypothesis python-psutil python-sphinx python-testtools waf
sbergmann  clang
sbueno     anaconda libblockdev pykickstart python-blivet python-simpleline
sergesanspaille clang python-lit
sergiodj   gdb
sergiopr   python-pandas
sgallagh   libmodulemd python-django python-flake8 python-memcached 
python-paramiko python-ply python-whoosh
sharkcz    pyparsing
siddharths clang
silas      python-pika
simo       python-kerberos
skottler   python-boto python-gevent python-jsonpatch python-jsonpointer
smani      python-olefile python-pillow
smilner    python-pygments python-virtualenv
sochotni   asciidoc pdc-client python-beanbag
social     python-editor
spot       pydot python-coverage python-ply pyxdg rpmlint
ssp        dbus-python pycairo python-ldap
stefanok   dbus-python
stevetraylen Cython python-argcomplete python-humanize python-mimeparse 
python-setuptools_scm
stingray   pyserial
suanand    python-polib
sundaram   python-billiard python-blinker python-bottle python-html5lib python-pip
svashisht  file python-pycurl
swt2c      python-pexpect python-pytest-forked python-pytest-timeout 
python-pytest-xdist python-wxpython4
szpak      pyxattr
tagoh      brotli
tbzatek    libblockdev libbytesize
tdabasin   python-pyramid python-venusian python-zope-component 
python-zope-configuration python-zope-deprecation python-zope-event 
python-zope-exceptions python-zope-i18nmessageid python-zope-schema 
python-zope-testing
tdawson    pungi
terjeros   pyparsing python-beautifulsoup4 python-configobj python-greenlet 
python-tidy
than       PyQt4 python-qt5 sip
thm        pytest python-apipkg python-execnet python-jinja2 python-markdown 
python-pluggy python-py python-sphinxcontrib-log-cabinet 
python-sphinxcontrib-trio waf
thozza     unbound
thrnciar   python-testpath
tibbs      rpmlint
tjikkun    python-contextlib2 python-raven
tmlcoch    createrepo_c librepo
tmraz      gpgme libpwquality pyOpenSSL
tmz        asciidoc rpmlint
tnorth     python-numexpr python-tables
tomprince  python-twisted
tomspur    ipython numpy python-daemon python-dateutil python-jupyter-client 
python-jupyter-core python-matplotlib python-nbformat python-numpydoc 
python-pexpect python-ptyprocess python-simplegeneric python-tornado python-zmq 
scipy
torsava    python-pip python-wheel
toshio     python-sphinx
tstellar   clang python-lit
ttomecek   numpy python-pytest-cov scipy
ttorling   python-mock python-pip python-pysocks python-terminado
twoerner   rpmlint
veillard   libxml2
vmihalko   file
vmojzis    libselinux policycoreutils
vmukhame   rpm
vpodzime   anaconda libblockdev libbytesize python-blivet python-meh python-ntplib
vponcova   anaconda pykickstart python-blivet
vrutkovs   python-pytest-runner
vtrefny    dbus-python libblockdev libbytesize python-blivet
wakko666   python-click-completion python-pandas
walters    gobject-introspection pygobject3
williamjmorenor python-bcrypt
wtaymans   meson
wwoods     lorax pungi
xaeth      python-augeas
xavierb    python-lockfile
ykarel     python-incremental
zbyszek    mpich python-numexpr python-pandocfilters python-soupsieve 
python-systemd python-tables

-- 
Miro Hrončok
--
Phone: [phone]
IRC: mhroncok

[Jonathan Wakely]

On 22/05/20 03:06 +0200, Miro Hrončok wrote:
> Hello, in order to deliver Python 3.9, we are running a coordinated 
> rebuild in a side tag.
>
>     https://fedoraproject.org/wiki/Changes/Python3.9
>
> If you see a "Rebuilt for Python 3.9" (or similar) commit in your 
> package, please don't rebuild it in regular rawhide.
> If you need to, please let me know, so we can coordinate. 
I need to start doing the Boost 1.73.0 rebuilds in a boost side tag,
but I can wait until you've done it for Python.

How long do you expect it to take before your side tag is merged back
to rawhide?

[Miro Hrončok]

On 22. 05. 20 8:28, Jonathan Wakely wrote:
>  On 22/05/20 03:06 +0200, Miro Hrončok wrote:
> > Hello, in order to deliver Python 3.9, we are running a coordinated rebuild in 
> > a side tag.
> >
> >    https://fedoraproject.org/wiki/Changes/Python3.9
> >
> > If you see a "Rebuilt for Python 3.9" (or similar) commit in your package,
>
> > please don't rebuild it in regular rawhide.
> > If you need to, please let me know, so we can coordinate.
>  
>  I need to start doing the Boost 1.73.0 rebuilds in a boost side tag,
>  but I can wait until you've done it for Python.
>  
>  How long do you expect it to take before your side tag is merged back
>  to rawhide? 
 From https://fedoraproject.org/wiki/Changes/Python3.9

2020-05-30: Expected side tag-merge (optimistic)
2020-06-18: Expected side tag-merge (realistic)
2020-07-18: Expected side tag-merge (pessimistic)

When do you need to start building?

-- 
Miro Hrončok
--
Phone: [phone]
IRC: mhroncok

[Jonathan Wakely]

On 22/05/20 10:47 +0200, Miro Hrončok wrote:
> On 22. 05. 20 8:28, Jonathan Wakely wrote:
> >On 22/05/20 03:06 +0200, Miro Hrončok wrote:
> >>Hello, in order to deliver Python 3.9, we are running a 
> >>coordinated rebuild in a side tag.
> >>
> >>   https://fedoraproject.org/wiki/Changes/Python3.9
> >>
> >>If you see a "Rebuilt for Python 3.9" (or similar) commit in your 
> >>package, please don't rebuild it in regular rawhide.
> >>If you need to, please let me know, so we can coordinate.
> >
> >I need to start doing the Boost 1.73.0 rebuilds in a boost side tag,
> >but I can wait until you've done it for Python.
> >
> >How long do you expect it to take before your side tag is merged back
> >to rawhide?
>
> From https://fedoraproject.org/wiki/Changes/Python3.9
>
> 2020-05-30: Expected side tag-merge (optimistic)
> 2020-06-18: Expected side tag-merge (realistic)
> 2020-07-18: Expected side tag-merge (pessimistic) 
Ouch.

> When do you need to start building? 
I was going to start this week, but that didn't happen (and I probably
won't start today). I would have tried to complete most of it next week
though, and merge the week after, to get done before the data centre
move reduces capacity on the builders.

The mid-June date would be OK, but it would take longer due to reduced
capacity.

Waiting until mid-July would be a problem though, there's no way I
could do it before the mass rebuild (so I might as well not bother
using aside tag and just dump it in rawhide and let the mass rebuild
find all the problems).

I think I will just do the rebuilds using my own PC and report bugs in
the packages that FTBFS with the new boost, so that when I do the
builds in the side tag things go more smoothly.

There are two changes I'd like to do before you start, which I can
push today:

1) libboost_python3.so.1.69.0 currently links to libpython3.8.so which
is contrary to Boost upstream, and also contrary to guidance from
Python upstream (https://github.com/python/cpython/pull/12946).  The
Fedora patches to do that are fragile (and one of the main reasons I
couldn't get new Boost releases to build for Fedora, and didn't update
it in F31 or F32). So I'd like to drop those patches.

2) I'd also like to include boost-python3 in the boost metapackage, as
suggested at
https://lists.fedoraproject.org/archives/list/[e-mail].o...

With those patches in rawhide our boost-python3 package will be better
even if for some reason I have to abandon the update to Boost 1.73.0
(which is unlikely, because I've already got all the spec file changes
and scratch build done locally).

So can I push those before you rebuild in the side tag?

[Miro Hrončok]

On 22. 05. 20 12:54, Jonathan Wakely wrote:
>  On 22/05/20 10:47 +0200, Miro Hrončok wrote:
> > On 22. 05. 20 8:28, Jonathan Wakely wrote:
> >> On 22/05/20 03:06 +0200, Miro Hrončok wrote:
> >>> Hello, in order to deliver Python 3.9, we are running a coordinated rebuild 
> >>> in a side tag.
> >>>
> >>>    https://fedoraproject.org/wiki/Changes/Python3.9
> >>>
> >>> If you see a "Rebuilt for Python 3.9" (or similar) commit in your
> package, 
> >>> please don't rebuild it in regular rawhide.
> >>> If you need to, please let me know, so we can coordinate.
> >>
> >> I need to start doing the Boost 1.73.0 rebuilds in a boost side tag,
> >> but I can wait until you've done it for Python.
> >>
> >> How long do you expect it to take before your side tag is merged back
> >> to rawhide?
> >
> > From https://fedoraproject.org/wiki/Changes/Python3.9
> >
> > 2020-05-30: Expected side tag-merge (optimistic)
> > 2020-06-18: Expected side tag-merge (realistic)
> > 2020-07-18: Expected side tag-merge (pessimistic)
>  
>  Ouch.
>  
> > When do you need to start building?
>  
>  I was going to start this week, but that didn't happen (and I probably
>  won't start today). I would have tried to complete most of it next week
>  though, and merge the week after, to get done before the data centre
>  move reduces capacity on the builders.
>  
>  The mid-June date would be OK, but it would take longer due to reduced
>  capacity.
>  
>  Waiting until mid-July would be a problem though, there's no way I
>  could do it before the mass rebuild (so I might as well not bother
>  using aside tag and just dump it in rawhide and let the mass rebuild
>  find all the problems). 
This scenario is not very likely.

-----

Could you give me the list of packages? Is it this?

$ repoquery -C --repo=rawhide{,-source} --whatrequires boost-devel | grep src$

I can see where the sets overlap. Maybe we can figure things out somehow.

>  I think I will just do the rebuilds using my own PC and report bugs
> in
>  the packages that FTBFS with the new boost, so that when I do the
>  builds in the side tag things go more smoothly. 
We can do it in copr as well if needed.

>  There are two changes I'd like to do before you start, which I
> can
>  push today:
>  
>  1) libboost_python3.so.1.69.0 currently links to libpython3.8.so which
>  is contrary to Boost upstream, and also contrary to guidance from
>  Python upstream (https://github.com/python/cpython/pull/12946).  The
>  Fedora patches to do that are fragile (and one of the main reasons I
>  couldn't get new Boost releases to build for Fedora, and didn't update
>  it in F31 or F32). So I'd like to drop those patches.
>  
>  2) I'd also like to include boost-python3 in the boost metapackage, as
>  suggested at
>
> https://lists.fedoraproject.org/archives/list/[e-mail].o...
>
>  
>  
>  With those patches in rawhide our boost-python3 package will be better
>  even if for some reason I have to abandon the update to Boost 1.73.0
>  (which is unlikely, because I've already got all the spec file changes
>  and scratch build done locally).
>  
>  So can I push those before you rebuild in the side tag? 
Please do.

PS We can also sync the plan on IRC for faster interaction.

-- 
Miro Hrončok
--
Phone: [phone]
IRC: mhroncok

[Miro Hrončok]

On 22. 05. 20 13:06, Miro Hrončok wrote:
>  Could you give me the list of packages? Is it this?
>  
>  $ repoquery -C --repo=rawhide{,-source} --whatrequires boost-devel | grep src$
>  
>  I can see where the sets overlap. Maybe we can figure things out somehow. 
If this is the list, there are only 67 common packages.

I think we can:

  1. build current boost with Python 3.9 in f33-python target
  2. build boost 1.73.0 with Python 3.8 in f33-boost target
  3. do our rebuilds
  4. once one of the side tag is ready to be merged, we coordinate:
  5. build Boost 1.73.0 with Python 3.9 in the remaining side tag
  6. rebuild the 67 common packages

WDYT? Of course if the common set is 500 hundred, we don't probably want to do this.

-- 
Miro Hrončok
--
Phone: [phone]
IRC: mhroncok

[Jonathan Wakely]

On 22/05/20 14:49 +0200, Miro Hrončok wrote:
> On 22. 05. 20 13:06, Miro Hrončok wrote:
> >Could you give me the list of packages? Is it this?
> >
> >$ repoquery -C --repo=rawhide{,-source} --whatrequires boost-devel | grep src$
> >
> >I can see where the sets overlap. Maybe we can figure things out somehow.
>
> If this is the list, there are only 67 common packages.
>
> I think we can:
>
>  1. build current boost with Python 3.9 in f33-python target
>  2. build boost 1.73.0 with Python 3.8 in f33-boost target
>  3. do our rebuilds
>  4. once one of the side tag is ready to be merged, we coordinate:
>  5. build Boost 1.73.0 with Python 3.9 in the remaining side tag
>  6. rebuild the 67 common packages
>
> WDYT? Of course if the common set is 500 hundred, we don't probably want to do this.
We discussed it on IRC and agreed to go ahead with this plan.

[Jonathan Wakely]

On 22/05/20 13:06 +0200, Miro Hrončok wrote:
> On 22. 05. 20 12:54, Jonathan Wakely wrote:
> >On 22/05/20 10:47 +0200, Miro Hrončok wrote:
> >>On 22. 05. 20 8:28, Jonathan Wakely wrote:
> >>>On 22/05/20 03:06 +0200, Miro Hrončok wrote:
> >>>>Hello, in order to deliver Python 3.9, we are running a 
> >>>>coordinated rebuild in a side tag.
> >>>>
> >>>>   https://fedoraproject.org/wiki/Changes/Python3.9
> >>>>
> >>>>If you see a "Rebuilt for Python 3.9" (or similar) commit in 
> >>>>your package, please don't rebuild it in regular rawhide.
> >>>>If you need to, please let me know, so we can coordinate.
> >>>
> >>>I need to start doing the Boost 1.73.0 rebuilds in a boost side tag,
> >>>but I can wait until you've done it for Python.
> >>>
> >>>How long do you expect it to take before your side tag is merged back
> >>>to rawhide?
> >>
> >>From https://fedoraproject.org/wiki/Changes/Python3.9
> >>
> >>2020-05-30: Expected side tag-merge (optimistic)
> >>2020-06-18: Expected side tag-merge (realistic)
> >>2020-07-18: Expected side tag-merge (pessimistic)
> >
> >Ouch.
> >
> >>When do you need to start building?
> >
> >I was going to start this week, but that didn't happen (and I probably
> >won't start today). I would have tried to complete most of it next week
> >though, and merge the week after, to get done before the data centre
> >move reduces capacity on the builders.
> >
> >The mid-June date would be OK, but it would take longer due to reduced
> >capacity.
> >
> >Waiting until mid-July would be a problem though, there's no way I
> >could do it before the mass rebuild (so I might as well not bother
> >using aside tag and just dump it in rawhide and let the mass rebuild
> >find all the problems).
>
> This scenario is not very likely.
>
> -----
>
> Could you give me the list of packages? Is it this?
>
> $ repoquery -C --repo=rawhide{,-source} --whatrequires boost-devel | grep src$ 
That gives me:
Error: Unknown repo: 'rawhide'

And this fails too:

$ repoquery --releasever=rawhide --repo=fedora{,-source} --whatrequires boost-devel | grep
src$ > repoquery1
Last metadata expiration check: 0:01:59 ago on Fri 22 May 2020 13:42:32 BST.
Modular dependency problem:

  Problem: conflicting requests
   - nothing provides module(platform:f31) needed by module
gimp:2.10:3120191106095052:f636be4b-0.x86_64

I use the first command at
https://fedoraproject.org/wiki/Changes/F33Boost173#Dependencies which
only finds the packages that depend on the libboost_*.so libs, which
is a list about half the size.

Many packages that use Boost only use its headers without linking to
one of the shared libs, so I don't rebuild them as part of an update
that changes the SONAMEs of the shared libs (they'll get rebuilt in
the mass rebuild anyway).

> I can see where the sets overlap. Maybe we can figure things out
> somehow.
>
> >I think I will just do the rebuilds using my own PC and report bugs in
> >the packages that FTBFS with the new boost, so that when I do the
> >builds in the side tag things go more smoothly.
>
> We can do it in copr as well if needed.
>
> >There are two changes I'd like to do before you start, which I can
> >push today:
> >
> >1) libboost_python3.so.1.69.0 currently links to libpython3.8.so which
> >is contrary to Boost upstream, and also contrary to guidance from
> >Python upstream (https://github.com/python/cpython/pull/12946).  The
> >Fedora patches to do that are fragile (and one of the main reasons I
> >couldn't get new Boost releases to build for Fedora, and didn't update
> >it in F31 or F32). So I'd like to drop those patches.
> >
> >2) I'd also like to include boost-python3 in the boost metapackage, as
> >suggested at
> >https://lists.fedoraproject.org/archives/list/[e-mail]/thread/B4LDABNDO7E3PH263ZU6ZR4SLP6WMNCJ/#JOSRJAUDXN56TQJPAXKFPIFA3SDS4GIZ
> >
> >
> >With those patches in rawhide our boost-python3 package will be better
> >even if for some reason I have to abandon the update to Boost 1.73.0
> >(which is unlikely, because I've already got all the spec file changes
> >and scratch build done locally).
> >
> >So can I push those before you rebuild in the side tag?
>
> Please do.
>
> PS We can also sync the plan on IRC for faster interaction. 
Will do.

[Felix Schwarz]

Am 22.05.20 um 03:06 schrieb Miro Hrončok:
>  fschwarz   babel python-genshi 
I was not aware that python-genshi is still part of the initial bootstrap 
sequence. The package does not work with Python 3.9 (upstream problem, the 
usual AST changes). I hope that won't make your life too difficult.

I started to debug the failures but it seems it is not a one line fix. Then I 
got distracted by trying to fix up borgbackup for Python 3.9.

Felix

[Miro Hrončok]

On 22. 05. 20 9:42, Felix Schwarz wrote:
>  
>  Am 22.05.20 um 03:06 schrieb Miro Hrončok:
> > fschwarz   babel python-genshi
>  
>  I was not aware that python-genshi is still part of the initial bootstrap 
>  sequence. The package does not work with Python 3.9 (upstream problem, the usual 
>  AST changes). I hope that won't make your life too difficult. 
genshi is used in some html5lib tests, hence it is in this list, but don't worry 
too much, the genshi tests are optional and can be skipped if needed.

>  I started to debug the failures but it seems it is not a one line
> fix. Then I 
>  got distracted by trying to fix up borgbackup for Python 3.9. 
Sorry about the distraction.

-- 
Miro Hrončok
--
Phone: [phone]
IRC: mhroncok

[Felix Schwarz]

Am 22.05.20 um 12:47 schrieb Miro Hrončok:
> > I was not aware that python-genshi is still part of the initial
> bootstrap
> > sequence. The package does not work with Python 3.9 (upstream problem, the
> > usual AST changes). I hope that won't make your life too difficult.
>  
>  genshi is used in some html5lib tests, hence it is in this list, but don't
>  worry too much, the genshi tests are optional and can be skipped if needed. 
Good to know :-)

> > I started to debug the failures but it seems it is not a one line
> fix. Then
> > I got distracted by trying to fix up borgbackup for Python 3.9.
>  
>  Sorry about the distraction. 
No problem. I think it's hardly possible to run these mass rebuilds without an
occasional mistake.

Felix

[Tomasz Kłoczko]

On Fri, 22 May 2020 at 02:17, Miro Hrončok <mhroncok(a)redhat.com&gt; wrote:

>  Hello, in order to deliver Python 3.9, we are running a coordinated
>  rebuild in a
>  side tag.
>
>       https://fedoraproject.org/wiki/Changes/Python3.9
>  
[..]

I'm only curious why to make transition to python 3.9 was
chosen "debianised way"?

Originally was python package. Than was python python2 and python3. Now it
is python3.9.
Why not is used still and just python and to provide necessary dependencies
during transition python3.8?
That way as well is casing that with each python major version upgrade all
macros needs to be multiplied.
All that was possible to avoid bu just unversioned packages names and
unversioned python macros hiding major version transitions in macros.
All that is causing that for each that many packages will needs to be
specially modified to produce proper results on new python version as well
instead just retesting new standard macros definition on new python and/or
do couple of tweaks only ion those macros definitions and nothing more).
All that it is nothing more than creating huge amount of work which needs
to be done on each major version upgrade on maaaany packages.

"Making some mistakes is not the problem but repeating them again and again
really is".
From that point of view with 3rd iteration should be enough to learn some
lessons because now (again) looks like it will be necessary to add many
modifications across many packages with python modules .. pointless!!!

Generalised build procedure with macros suppose to hide some details like
versions and other.
For some reasons looks like that completely stopped in case of only python
IMO because some people saw how some things has been done on Debian
(successfully but with way to big overhead).

kloczek
-- 
Tomasz Kłoczko | LinkedIn: http://lnkd.in/FXPWxH

[Peter Pentchev]

On Fri, May 22, 2020 at 10:08:04AM +0100, Tomasz Kłoczko wrote:
>  On Fri, 22 May 2020 at 02:17, Miro Hrončok
> <mhroncok(a)redhat.com&gt; wrote:
>  
>  > Hello, in order to deliver Python 3.9, we are running a coordinated
>  > rebuild in a
>  > side tag.
>  >
>  >      https://fedoraproject.org/wiki/Changes/Python3.9
>  >
>  [..]
>  
>  I'm only curious why to make transition to python 3.9 was
>  chosen "debianised way"? 
(yes, I am aware of the slight irony of me replying to this message with
 my current e-mail signature :))

>  Originally was python package. Than was python python2 and python3.
> Now it
>  is python3.9.
>  Why not is used still and just python and to provide necessary dependencies
>  during transition python3.8?
>  That way as well is casing that with each python major version upgrade all
>  macros needs to be multiplied. 
Are you asking why python3.8 and python3.9 are separate packages?
If so, I think that previous messages to this list mentioned that many
people need to have more than one Python interpreter installed.

G'luck,
Peter

-- 
Peter Pentchev  roam(a)ringlet.net roam(a)debian.org pp(a)storpool.com
PGP key:        http://people.FreeBSD.org/~roam/roam.key.asc
Key fingerprint 2EE7 A7A5 17FC 124C F115  C354 651E EFB0 2527 DF13

[Tomasz Kłoczko]

On Fri, 22 May 2020 at 10:27, Peter Pentchev <roam(a)ringlet.net&gt; wrote:
[..]

>  > Originally was python package. Than was python python2 and
> python3. Now
>  it
>  > is python3.9.
>  > Why not is used still and just python and to provide necessary
>  dependencies
>  > during transition python3.8?
>  > That way as well is casing that with each python major version upgrade
>  all
>  > macros needs to be multiplied.
>
>  Are you asking why python3.8 and python3.9 are separate packages?
>  
No I'm not.

kloczek
-- 
Tomasz Kłoczko | LinkedIn: http://lnkd.in/FXPWxH

[Charalampos Stratakis]

----- Original Message -----

>  From: "Tomasz Kłoczko" <kloczko.tomasz(a)gmail.com&gt;
>  To: "Development discussions related to Fedora"
>  <devel(a)lists.fedoraproject.org&gt;
>  Sent: Friday, May 22, 2020 11:51:48 AM
>  Subject: Re: [HEADS UP] Fedora 33 Python 3.9 rebuilds have started in a side
>  tag 
>  On Fri, 22 May 2020 at 10:27, Peter Pentchev < roam(a)ringlet.net
> > wrote:
>  [..] 
>  > > Originally was python package. Than was python python2 and
> python3. Now
>  > > it
>  
>  > > is python3.9.
>  
>  > > Why not is used still and just python and to provide necessary
>  > > dependencies
>  
>  > > during transition python3.8?
>  
>  > > That way as well is casing that with each python major version upgrade
>  > > all
>  
>  > > macros needs to be multiplied.
>   
>  > Are you asking why python3.8 and python3.9 are separate
> packages?
>   
>  No I'm not. 
>  kloczek
>  --
>  Tomasz Kłoczko | LinkedIn: http://lnkd.in/FXPWxH 
>  _______________________________________________
>  devel mailing list -- devel(a)lists.fedoraproject.org
>  To unsubscribe send an email to devel-leave(a)lists.fedoraproject.org
>  Fedora Code of Conduct:
>  https://docs.fedoraproject.org/en-US/project/code-of-conduct/
>  List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
>  List Archives:
>  https://lists.fedoraproject.org/archives/list/[e-mail] 
I don't understand your concern though. The Python 3.9 package provides the exact same
things that were provided with the unversioned package, other packages don't need to
change anything related to macros. 

-- 
Regards, 

Charalampos Stratakis 
Software Engineer 
Python Maintenance Team, Red Hat

[Miro Hrončok]

On 22. 05. 20 11:08, Tomasz Kłoczko wrote:
>  
>  I'm only curious why to make transition to python 3.9 was chosen "debianised
> way"?
>  
>  Originally was python package. Than was python python2 and python3. Now it is 
>  python3.9. 
It is just the component name. The user installable package is still python3.

Reasoning:

Build python3, python3-libs etc. from python39 SRPM on F33+:

https://lists.fedoraproject.org/archives/list/[e-mail]...


Renaming pythonXY packages to pythonX.Y (e.g. python39 to python3.9):

https://lists.fedoraproject.org/archives/list/[e-mail]...

-- 
Miro Hrončok
--
Phone: [phone]
IRC: mhroncok

[Tomasz Kłoczko]

On Fri, 22 May 2020 at 10:42, Miro Hrončok <mhroncok(a)redhat.com&gt; wrote:
[..]

>  It is just the component name. The user installable package is still
>  python3.
>  
I call it thing-which-should-not-exist or thing-which-shall-not-pass.
That way it is easier to pronounce 😋

>  Reasoning:
>
>  Build python3, python3-libs etc. from python39 SRPM on F33+:
>
>
>
> https://lists.fedoraproject.org/archives/list/[e-mail]...
>
>
>  Renaming pythonXY packages to pythonX.Y (e.g. python39 to python3.9):
>
>
>
> https://lists.fedoraproject.org/archives/list/[e-mail]...

A .. yeah 🤦‍♂️
You are right I forgot that Fedora on making new major release instead
branching all packages stored in git still provides on master full support
for all last three version of the distribution, three EPL/RHEL and
sometimes even few version of SuSE 🙄

I must apologise: sorry looks like it is my mistake .. (mea culpa, mea
culpa, .. mea maxima culpa)

[mode=serious]
On making transition from 3.8.x to 3.9.x all what would be necessary to do
would be just create compat-python3.8 package -> upgrade python.spec to 3.9
-> monitor number of packages still dependent on  compat-python3.8 to focus
what still needs to be ported/rebuild.
Because other factors the best moment to start such transition would be few
days after f32 official release and tag all git resources and just right
before first MR.
Because rawhide just after that will have in %{dist} "f33" it will be not
even necessary to do what started today (bumping all python packages
releases and committing those changes) because
<foo.version>-<bar.release>.f32 will be always lower than
<foo.version>-<bar.release>.f33.

To make all above possible all only what would be is to stop using python
packages names in Requires and BuildRequires and start using
%pythondist(<module> similar to what is now with  pkgconfig() dependencies
(nice clean and not even one new macro needs to be introduced/split on some
exact package major version release).

With above total entropy cost would be *ONLY*:
- one additional compat-python3.8 package
- redefine %pythondist macro to provide python versioned dependencies
(probably by change only version in the macro which should hold python
major version).

On top of such scheme it will be possible go back to old simpler
maintenance of the long term used systems by combing only all installed
compat-* packages .. nice, easy and clean.

pkgconfig proved that this is actually and already/perfectly working (only
adaptation still is sloppy), and I don't see literally even single reasons
why it should not work for python or gt4/kde4 vs. qt4/kde5 as well.

Isn't it?
[/mode]

kloczek
-- 
Tomasz Kłoczko | LinkedIn: http://lnkd.in/FXPWxH

[Miro Hrončok]

On 22. 05. 20 12:43, Tomasz Kłoczko wrote:
>  [mode=serious]
>  On making transition from 3.8.x to 3.9.x all what would be necessary to do would 
>  be just create compat-python3.8 package -> upgrade python.spec to 3.9 -> monitor 
>  number of packages still dependent on compat-python3.8 to focus what still needs 
>  to be ported/rebuild. ...snip 
This doesn't work. As long as you rebuild setuptools and other essential 
packages with 3.9, the entire 3.8 stack would be useless. You would need compat 
packages for hundreds of packages to make this work.

-- 
Miro Hrončok
--
Phone: [phone]
IRC: mhroncok

[Tomasz Kłoczko]

On Fri, 22 May 2020 at 12:02, Miro Hrončok <mhroncok(a)redhat.com&gt; wrote:

>  On 22. 05. 20 12:43, Tomasz Kłoczko wrote:
>  > [mode=serious]
>  > On making transition from 3.8.x to 3.9.x all what would be necessary to
>  do would
>  > be just create compat-python3.8 package -> upgrade python.spec to 3.9 ->
>  monitor
>  > number of packages still dependent on compat-python3.8 to focus what
>  still needs
>  > to be ported/rebuild. ...snip
>
>  This doesn't work. As long as you rebuild setuptools and other essential
>  packages with 3.9, the entire 3.8 stack would be useless. You would need
>  compat
>  packages for hundreds of packages to make this work.
>  
Is that not *the* target/goal? .. make whole old stack useless/obsolete
ASAP?

And no you would not need that because as long as you will not remove from
repository all python-<module>-<version.foo>-<release.bar>.f22 packages
all
dependencies will be fulfilled.
Remember that each package is not rebuild on entire system but on very
limited one with (theoretically) necessary dependencies. With that it is
possible to rebuild all packages one by one and move everything in one
batch. To make that whole transition easier all what will be necessary to
do is clone current repository to something like fedora-transition-python
and add keep all rebuild packages in that repo and merge all that packages
in one go when all will be finished. No stress or time pressure. such
transition can take weeks if not months and decision about merge could be
done instantly basing on only one metric which is number of packages still
dependent on compat-python3.8. Than if at the and will be still some
remains hard quickly to port it should be made decision about create some
limited number of packages like compat-python3.8-<module> and/or to put
some of those packages on obsoletes list.
With single metric decision about actual transition will be no longer in
hands of anyone (as single person or comity).
It will be strict technical decision based on quite well defined set of
conditions hanging on that metric.
If we are talking about using that methodology not only for python in some
simple enough cases such decision could be done .. automatically!
Basing on my already +25y exp on building rpm packages I can even bet that
after some cleanups in all python related stuff it should be possible to
make python major release upgrade *automatically.*

Whoever would want to help on that transition will be asked to add that
fedora-transition-python repository to own build systems or own personal
system. Initial set of rebuilds made automatically should provide enough
set of new dependencies allowing fixing one by one each package which will
need manual intervention in form of some patches.

Above and what I wrote in my prev email could be general methodology on
making any future transition of bigger groups of packages from one major
version to another one (not only python specific).

All this is just like git branching but on packages with packages
repositories as well.

It is yet another consequence of what I've sketched. With that it would be
possible to remove all python packages bootstrap bconds:

[tkloczko@barrel SPECS.fedora]$ grep bootstrap python* | grep bcond
python3.spec:%bcond_with bootstrap
python-BTrees.spec:%bcond_with bootstrap
python-dask.spec:%bcond_without bootstrap
python-fsspec.spec:%bcond_without bootstrap
python-pbr.spec:%bcond_with bootstrap
python-setuptools.spec:%bcond_with bootstrap
python-setuptools.spec:# Warning, different bootstrap meaning here, has
nothing to do with our bcond
python-sphinx_rtd_theme.spec:%bcond_with bootstrap
python-stestr.spec:%bcond_without bootstrap
python-wheel.spec:%bcond_with bootstrap
python-zbase32.spec:%bcond_with bootstrap

Of course to that picture needs to be added yet another small bit which is
stop (the h*ll) using versioned symlinks in case tools like pytest,
sphins and few other to use them *only* in compat-* packages.

kloczek

[Petr Viktorin]

On 2020-05-22 13:59, Tomasz Kłoczko wrote:
>  On Fri, 22 May 2020 at 12:02, Miro Hrončok <mhroncok(a)redhat.com 
>  <mailto:[e-mail]>> wrote:
>  
>      On 22. 05. 20 12:43, Tomasz Kłoczko wrote:
>       > [mode=serious]
>       > On making transition from 3.8.x to 3.9.x all what would be
>      necessary to do would
>       > be just create compat-python3.8 package -> upgrade python.spec to
>      3.9 -> monitor
>       > number of packages still dependent on compat-python3.8 to focus
>      what still needs
>       > to be ported/rebuild. ...snip
>  
>      This doesn't work. As long as you rebuild setuptools and other
>      essential
>      packages with 3.9, the entire 3.8 stack would be useless. You would
>      need compat
>      packages for hundreds of packages to make this work.
>  
>  
>  Is that not *the*target/goal?.. make whole old stack useless/obsolete ASAP?
>  
>  And no you would not need that because as long as you will not remove 
>  from repository all python-<module>-<version.foo>-<release.bar>.f22 
>  packages all dependencies will be fulfilled.
>  Remember that each package is not rebuild on entire system but on very 
>  limited one with (theoretically) necessary dependencies. With that it is 
>  possible to rebuild all packages one by one and move everything in one 
>  batch. To make that whole transition easier all what will be 
>  necessary to do is clone current repository to something like 
>  fedora-transition-python and add keep all rebuild packages in that repo 
>  and merge all that packages in one go when all will be finished. 
>  No stress or time pressure. such transition can take weeks if not months 
>  and decision about merge could be done instantly basing on only one 
>  metric which is number of packages still dependent on compat-python3.8.  
How is this "fedora-transition-python" different from a side tag?

The problem with "cloning" is that people build new versions in Fedora 
all the time, so the "clone" gets out of date (with some additional 
problems related to version/release numbers). Unless the "clone" is kept 
up to date, merging the repo would mean downgrading some packages.

That is the main reason for the time pressure: the longer the rebuild 
takes, the more the repos diverge.

>  Than if at the and will be still some remains hard quickly to port it
>
>  should be made decision about create some limited number of packages 
>  like compat-python3.8-<module> and/or to put some of those packages on 
>  obsoletes list. > With single metric decision about actual transition will be no
> longer in
>  hands of anyone (as single person or comity).
>  It will be strict technical decision based on quite well defined set of 
>  conditions hanging on that metric. 
So, what conditions do you propose?

Why would a condition (decided by one person or commitee) be better than 
that person (or comittee) deciding on the fly -- based on not just the 
number, but the actual packages that still fail to build?

>  If we are talking about using that methodology not only for python in
>
>  some simple enough cases such decision could be done .. automatically!
>  Basing on my already +25y exp on building rpm packages I can even bet 
>  that after some cleanups in all python related stuff it should be 
>  possible to make python major release upgrade *automatically.* 
I'm afraid the clean-ups, and keeping the clean-ups up to date, would be 
more work than doing the work manually.

>  Whoever would want to help on that transition will be asked to add
> that 
>  fedora-transition-python repository to own build systems or own personal 
>  system. Initial set of rebuilds made automatically should provide enough 
>  set of new dependencies allowing fixing one by one each package which 
>  will need manual intervention in form of some patches. 
That's very similar to what's been happening in COPR for months now.

>  Above and what I wrote in my prev email could be general methodology
> on 
>  making any future transition of bigger groups of packages from one major 
>  version to another one (not only python specific).
>  
>  All this is just like git branching but on packages with packages 
>  repositories as well. 
Branching is not hard; merging is. Both Git and CVS could branch; Git 
won because the *merging* (and thus the whole branch-based workflow) is 
easier.

>  It is yet another consequence of what I've sketched. With that it
>
>  would be possible to remove all python packages bootstrap bconds:
>  
>  [tkloczko@barrel SPECS.fedora]$ grep bootstrap python* | grep bcond
>  python3.spec:%bcond_with bootstrap
>  python-BTrees.spec:%bcond_with bootstrap
>  python-dask.spec:%bcond_without bootstrap
>  python-fsspec.spec:%bcond_without bootstrap
>  python-pbr.spec:%bcond_with bootstrap
>  python-setuptools.spec:%bcond_with bootstrap
>  python-setuptools.spec:# Warning, different bootstrap meaning here, has 
>  nothing to do with our bcond
>  python-sphinx_rtd_theme.spec:%bcond_with bootstrap
>  python-stestr.spec:%bcond_without bootstrap
>  python-wheel.spec:%bcond_with bootstrap
>  python-zbase32.spec:%bcond_with bootstrap 
Sorry, I don't see how this would be possible.

>  Of course to that picture needs to be added yet another small bit
> which 
>  is stop (the h*ll) using versioned symlinks in case tools like pytest, 
>  sphins and few other to use them *only* in compat-* packages. 
Yup, it's always better to not use versioned symlinks like pytest-3.8, 
and instead use "python3 -m pytest".
Most tools allow this, but, unfortunately, both pytest and sphinx 
currently break (in more or less subtle ways) when you do this :(

[Jonathan Wakely]

On 22/05/20 11:43 +0100, Tomasz Kłoczko wrote:
> On Fri, 22 May 2020 at 10:42, Miro Hrončok <mhroncok(a)redhat.com&gt;
> wrote:
> [..]
>
> > It is just the component name. The user installable package is still
> > python3.
> >
>
> I call it thing-which-should-not-exist or thing-which-shall-not-pass.
> That way it is easier to pronounce 😋
>
> > Reasoning:
> >
> > Build python3, python3-libs etc. from python39 SRPM on F33+:
> >
> >
> >
> https://lists.fedoraproject.org/archives/list/[e-mail]...
> >
> >
> > Renaming pythonXY packages to pythonX.Y (e.g. python39 to python3.9):
> >
> >
> >
> https://lists.fedoraproject.org/archives/list/[e-mail]...
>
>
> A .. yeah 🤦‍♂️
> You are right I forgot that Fedora on making new major release instead
> branching all packages stored in git still provides on master full support
> for all last three version of the distribution, three EPL/RHEL and
> sometimes even few version of SuSE 🙄
>
> I must apologise: sorry looks like it is my mistake .. (mea culpa, mea
> culpa, .. mea maxima culpa)
>
> [mode=serious]
> On making transition from 3.8.x to 3.9.x all what would be necessary to do
> would be just create compat-python3.8 package -> upgrade python.spec to 3.9
> -> monitor number of packages still dependent on  compat-python3.8 to focus
> what still needs to be ported/rebuild.
> Because other factors the best moment to start such transition would be few
> days after f32 official release and tag all git resources and just right
> before first MR.
> Because rawhide just after that will have in %{dist} "f33" it will be not
> even necessary to do what started today (bumping all python packages
> releases and committing those changes) because
> <foo.version>-<bar.release>.f32 will be always lower than
> <foo.version>-<bar.release>.f33.
>
> To make all above possible all only what would be is to stop using python
> packages names in Requires and BuildRequires and start using
> %pythondist(<module> similar to what is now with  pkgconfig() dependencies
> (nice clean and not even one new macro needs to be introduced/split on some
> exact package major version release).
>
> With above total entropy cost would be *ONLY*:
> - one additional compat-python3.8 package
> - redefine %pythondist macro to provide python versioned dependencies
> (probably by change only version in the macro which should hold python
> major version).
>
> On top of such scheme it will be possible go back to old simpler
> maintenance of the long term used systems by combing only all installed
> compat-* packages .. nice, easy and clean.
>
> pkgconfig proved that this is actually and already/perfectly working (only
> adaptation still is sloppy), and I don't see literally even single reasons
> why it should not work for python or gt4/kde4 vs. qt4/kde5 as well.
>
> Isn't it?
> [/mode] 
Maybe you should make a proper change proposal to do this, instead of
just being sarcastic about the work other people are doing?

[Tomasz Kłoczko]

On Fri, 22 May 2020 at 12:07, Jonathan Wakely <jwakely(a)fedoraproject.org&gt;
wrote:
[..]

>  Maybe you should make a proper change proposal to do this, instead
> of
>  just being sarcastic about the work other people are doing?
>  
I'm not 100% sure am I understand you correctly because I'm not sure is it
still something not clear or you are trying to push me on some exact rails
:P

1st ver of the answer:
Sorry I'm engineer not bureaucrat.
If someone do not understand what just has been written this is not my
problem (maybe it is brutal claim but it is only truth).
Yes, I'm not native English speaker and my English still is a bit clunky.

2nd:
I understand that Fedora has own bureaucracy and it (en)forces some
technical decisions by policies but all that decision should be strict
technical decision and whole bureaucracy should be done post factum after
discussion -> POC -> discussion of the POC results.
Writing policies is generally to cut off any misunderstanding on scaling
that decisions on other non-initial areas or to provide
clear justification on all not obvious "why that way?" question, and of
course keep entropy of everything on lowest possible level.

Nevertheless now we are not on any of those stages.
Simple I don't like when strict technical decisions are done because they
have been (en)forced by unproven political/strategical decisions. and what
IMO cracks in case of python says me that currently used policies at least
needs some remake.

Someone made the decision about python methodologies and because in the
past that person or people had the best set of facts in own brains they
should speak first to at least confirm that some cracks are not only
imaginary. With agreement that currently used methodologies something is
wrong ("errare humanum est perseverare diabolicum") only IMO is possible to
start new games on some rules/policies.

In cases like this it is really possible to do a lot only discussing
current state and some new possible states (by discussion I understand
conversation in which sides are using facts .. only).

If it is not obvious .. I'm already assuming that what I've described could
be wrong/bollocks/BS because some already tested (in combat) cases on areas
which I don't know/I'm not aware.
Despite that entry/top assumption what just sparked in my head looks
consistent and sound.

I'm not trying as well to challenge personally anyone.
No this is purely technical conversation and even if some wordings looks
harsh it is not absolutely the case.

kloczek

[Adam Williamson]

On Fri, 2020-05-22 at 03:06 +0200, Miro Hrončok wrote:
>  Hello, in order to deliver Python 3.9, we are running a coordinated
> rebuild in a 
>  side tag.
>  
>       https://fedoraproject.org/wiki/Changes/Python3.9
>  
>  If you see a "Rebuilt for Python 3.9" (or similar) commit in your package, 
>  please don't rebuild it in regular rawhide.
>  If you need to, please let me know, so we can coordinate.
>  
>  If you'd like to build the package, you should be able to build it in the side 
>  tag via:
>  
>       on branch master:
>       $ fedpkg build --target=f33-python
>       $ koji wait-repo f33-python --build <nvr>
>  
>  Note that it will take a while before all the essential packages are rebuilt, so 
>  don't except all your dependencies to be available right away. When in trouble, 
>  ask here or on IRC (#fedora-python on Freenode).
>  
>  Builds: 
>
> https://koji.fedoraproject.org/koji/builds?latest=0&tagID=22287&o...
>  
>  Please avoid any potentially disturbing changes in Python packages until the 
>  rebuild is over. 
So a request here: once the rebuilds are done, before we consider
moving them to Rawhide proper, can we have releng run a test compose
using the side tag and run openQA on it, to test for bugs in the
installer or key critpath components caused by the 3.9 changes? I don't
see anything about this in the Change page:
https://fedoraproject.org/wiki/Changes/Python3.9
but I think it'd be good to catch at least any major issues before we
land the change rather than after...
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net

[Miro Hrončok]

On 22. 05. 20 19:23, Adam Williamson wrote:
>  So a request here: once the rebuilds are done, before we consider
>  moving them to Rawhide proper, can we have releng run a test compose
>  using the side tag and run openQA on it, to test for bugs in the
>  installer or key critpath components caused by the 3.9 changes? I don't
>  see anything about this in the Change page:
>  https://fedoraproject.org/wiki/Changes/Python3.9
>  but I think it'd be good to catch at least any major issues before we
>  land the change rather than after... 
I am all in if this is possible.

When we updated to Python 3.7 I wanted to do it, but I was told it was not possible.

When we updated to Python 3.8, I've asked around once again, but was still not 
possible.

-- 
Miro Hrončok
--
Phone: [phone]
IRC: mhroncok

[Adam Williamson]

On Fri, 2020-05-22 at 19:57 +0200, Miro Hrončok wrote:
>  On 22. 05. 20 19:23, Adam Williamson wrote:
>  > So a request here: once the rebuilds are done, before we consider
>  > moving them to Rawhide proper, can we have releng run a test compose
>  > using the side tag and run openQA on it, to test for bugs in the
>  > installer or key critpath components caused by the 3.9 changes? I don't
>  > see anything about this in the Change page:
>  > https://fedoraproject.org/wiki/Changes/Python3.9
>  > but I think it'd be good to catch at least any major issues before we
>  > land the change rather than after...
>  
>  I am all in if this is possible.
>  
>  When we updated to Python 3.7 I wanted to do it, but I was told it was not possible.
>  
>  When we updated to Python 3.8, I've asked around once again, but was still not 
>  possible. 
ah, fun :/

we should at *least* be able to hack it up manually or in openQA,
though it may be ugly. if releng still can't do it, let me know and
I'll see if I can work something out.
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net

[Miro Hrončok]

On 22. 05. 20 20:05, Adam Williamson wrote:
>  On Fri, 2020-05-22 at 19:57 +0200, Miro Hrončok wrote:
> > On 22. 05. 20 19:23, Adam Williamson wrote:
> >> So a request here: once the rebuilds are done, before we consider
> >> moving them to Rawhide proper, can we have releng run a test compose
> >> using the side tag and run openQA on it, to test for bugs in the
> >> installer or key critpath components caused by the 3.9 changes? I don't
> >> see anything about this in the Change page:
> >> https://fedoraproject.org/wiki/Changes/Python3.9
> >> but I think it'd be good to catch at least any major issues before we
> >> land the change rather than after...
> >
> > I am all in if this is possible.
> >
> > When we updated to Python 3.7 I wanted to do it, but I was told it was not possible.
> >
> > When we updated to Python 3.8, I've asked around once again, but was still not
> > possible.
>  
>  ah, fun :/
>  
>  we should at *least* be able to hack it up manually or in openQA,
>  though it may be ugly. if releng still can't do it, let me know and
>  I'll see if I can work something out. 
https://pagure.io/releng/issue/9467

-- 
Miro Hrončok
--
Phone: [phone]
IRC: mhroncok

[Miro Hrončok]

On 22. 05. 20 20:05, Adam Williamson wrote:
>  On Fri, 2020-05-22 at 19:57 +0200, Miro Hrončok wrote:
> > On 22. 05. 20 19:23, Adam Williamson wrote:
> >> So a request here: once the rebuilds are done, before we consider
> >> moving them to Rawhide proper, can we have releng run a test compose
> >> using the side tag and run openQA on it, to test for bugs in the
> >> installer or key critpath components caused by the 3.9 changes? I don't
> >> see anything about this in the Change page:
> >> https://fedoraproject.org/wiki/Changes/Python3.9
> >> but I think it'd be good to catch at least any major issues before we
> >> land the change rather than after...
> >
> > I am all in if this is possible.
> >
> > When we updated to Python 3.7 I wanted to do it, but I was told it was not possible.
> >
> > When we updated to Python 3.8, I've asked around once again, but was still not
> > possible.
>  
>  ah, fun :/
>  
>  we should at *least* be able to hack it up manually or in openQA,
>  though it may be ugly. if releng still can't do it, let me know and
>  I'll see if I can work something out. 
AFAIK packages that are required to do a minimal compose should all be rebuilt 
now. So you should be able to hack it up somehow. If packages are missing, 
please let me knwo and I'll make sure to include them in the initial set for 
Python 3.10.

-- 
Miro Hrončok
--
Phone: [phone]
IRC: mhroncok

[Adam Williamson]

On Tue, 2020-05-26 at 01:20 +0200, Miro Hrončok wrote:
>  On 22. 05. 20 20:05, Adam Williamson wrote:
>  > On Fri, 2020-05-22 at 19:57 +0200, Miro Hrončok wrote:
>  > > On 22. 05. 20 19:23, Adam Williamson wrote:
>  > > > So a request here: once the rebuilds are done, before we consider
>  > > > moving them to Rawhide proper, can we have releng run a test compose
>  > > > using the side tag and run openQA on it, to test for bugs in the
>  > > > installer or key critpath components caused by the 3.9 changes? I
> don't
>  > > > see anything about this in the Change page:
>  > > > https://fedoraproject.org/wiki/Changes/Python3.9
>  > > > but I think it'd be good to catch at least any major issues before we
>  > > > land the change rather than after...
>  > > 
>  > > I am all in if this is possible.
>  > > 
>  > > When we updated to Python 3.7 I wanted to do it, but I was told it was not
> possible.
>  > > 
>  > > When we updated to Python 3.8, I've asked around once again, but was still
> not
>  > > possible.
>  > 
>  > ah, fun :/
>  > 
>  > we should at *least* be able to hack it up manually or in openQA,
>  > though it may be ugly. if releng still can't do it, let me know and
>  > I'll see if I can work something out.
>  
>  AFAIK packages that are required to do a minimal compose should all be rebuilt 
>  now. So you should be able to hack it up somehow. If packages are missing, 
>  please let me knwo and I'll make sure to include them in the initial set for 
>  Python 3.10. 
OK, I'll give this a shot tomorrow and let you know how it goes. Thanks
for the heads-up.
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net

[Adam Williamson]

On Tue, 2020-05-26 at 01:20 +0200, Miro Hrončok wrote:
>  On 22. 05. 20 20:05, Adam Williamson wrote:
>  > On Fri, 2020-05-22 at 19:57 +0200, Miro Hrončok wrote:
>  > > On 22. 05. 20 19:23, Adam Williamson wrote:
>  > > > So a request here: once the rebuilds are done, before we consider
>  > > > moving them to Rawhide proper, can we have releng run a test compose
>  > > > using the side tag and run openQA on it, to test for bugs in the
>  > > > installer or key critpath components caused by the 3.9 changes? I
> don't
>  > > > see anything about this in the Change page:
>  > > > https://fedoraproject.org/wiki/Changes/Python3.9
>  > > > but I think it'd be good to catch at least any major issues before we
>  > > > land the change rather than after...
>  > > 
>  > > I am all in if this is possible.
>  > > 
>  > > When we updated to Python 3.7 I wanted to do it, but I was told it was not
> possible.
>  > > 
>  > > When we updated to Python 3.8, I've asked around once again, but was still
> not
>  > > possible.
>  > 
>  > ah, fun :/
>  > 
>  > we should at *least* be able to hack it up manually or in openQA,
>  > though it may be ugly. if releng still can't do it, let me know and
>  > I'll see if I can work something out.
>  
>  AFAIK packages that are required to do a minimal compose should all be rebuilt 
>  now. So you should be able to hack it up somehow. If packages are missing, 
>  please let me knwo and I'll make sure to include them in the initial set for 
>  Python 3.10. 
So I got an installer image built and tested:

https://openqa.stg.fedoraproject.org/tests/overview?distri=fedora&ver...

and that looks good. The Cyrillic failure is a known bug in Rawhide,
and the other failures are things that are known to fail when we run
these tests with a netinst image as opposed to a DVD image (they rely
on the image containing packages).

I'm currently trying to build a live image, but it's running insanely
slow for some reason, mock in general on my Rawhide box seems to be
really slow and I'm not sure why. If it ever finishes I'll try it. But
so far at least I see no problems.
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net

[Miro Hrončok]

On 27. 05. 20 1:22, Adam Williamson wrote:
>  On Tue, 2020-05-26 at 01:20 +0200, Miro Hrončok wrote:
> > On 22. 05. 20 20:05, Adam Williamson wrote:
> >> On Fri, 2020-05-22 at 19:57 +0200, Miro Hrončok wrote:
> >>> On 22. 05. 20 19:23, Adam Williamson wrote:
> >>>> So a request here: once the rebuilds are done, before we consider
> >>>> moving them to Rawhide proper, can we have releng run a test compose
> >>>> using the side tag and run openQA on it, to test for bugs in the
> >>>> installer or key critpath components caused by the 3.9 changes? I
> don't
> >>>> see anything about this in the Change page:
> >>>> https://fedoraproject.org/wiki/Changes/Python3.9
> >>>> but I think it'd be good to catch at least any major issues before
> we
> >>>> land the change rather than after...
> >>>
> >>> I am all in if this is possible.
> >>>
> >>> When we updated to Python 3.7 I wanted to do it, but I was told it was not
> possible.
> >>>
> >>> When we updated to Python 3.8, I've asked around once again, but was
> still not
> >>> possible.
> >>
> >> ah, fun :/
> >>
> >> we should at *least* be able to hack it up manually or in openQA,
> >> though it may be ugly. if releng still can't do it, let me know and
> >> I'll see if I can work something out.
> >
> > AFAIK packages that are required to do a minimal compose should all be rebuilt
> > now. So you should be able to hack it up somehow. If packages are missing,
> > please let me knwo and I'll make sure to include them in the initial set for
> > Python 3.10.
>  
>  So I got an installer image built and tested:
>  
>
> https://openqa.stg.fedoraproject.org/tests/overview?distri=fedora&ver...
>  
>  and that looks good. The Cyrillic failure is a known bug in Rawhide,
>  and the other failures are things that are known to fail when we run
>  these tests with a netinst image as opposed to a DVD image (they rely
>  on the image containing packages).
>  
>  I'm currently trying to build a live image, but it's running insanely
>  slow for some reason, mock in general on my Rawhide box seems to be
>  really slow and I'm not sure why. If it ever finishes I'll try it. But
>  so far at least I see no problems. 
That's excellent news. Thanks for doing it.

-- 
Miro Hrončok
--
Phone: [phone]
IRC: mhroncok

[Adam Williamson]

On Tue, 2020-05-26 at 16:22 -0700, Adam Williamson wrote:
>  On Tue, 2020-05-26 at 01:20 +0200, Miro Hrončok wrote:
>  > On 22. 05. 20 20:05, Adam Williamson wrote:
>  > > On Fri, 2020-05-22 at 19:57 +0200, Miro Hrončok wrote:
>  > > > On 22. 05. 20 19:23, Adam Williamson wrote:
>  > > > > So a request here: once the rebuilds are done, before we consider
>  > > > > moving them to Rawhide proper, can we have releng run a test compose
>  > > > > using the side tag and run openQA on it, to test for bugs in the
>  > > > > installer or key critpath components caused by the 3.9 changes? I
> don't
>  > > > > see anything about this in the Change page:
>  > > > > https://fedoraproject.org/wiki/Changes/Python3.9
>  > > > > but I think it'd be good to catch at least any major issues
> before we
>  > > > > land the change rather than after...
>  > > > 
>  > > > I am all in if this is possible.
>  > > > 
>  > > > When we updated to Python 3.7 I wanted to do it, but I was told it was not
> possible.
>  > > > 
>  > > > When we updated to Python 3.8, I've asked around once again, but was
> still not
>  > > > possible.
>  > > 
>  > > ah, fun :/
>  > > 
>  > > we should at *least* be able to hack it up manually or in openQA,
>  > > though it may be ugly. if releng still can't do it, let me know and
>  > > I'll see if I can work something out.
>  > 
>  > AFAIK packages that are required to do a minimal compose should all be rebuilt 
>  > now. So you should be able to hack it up somehow. If packages are missing, 
>  > please let me knwo and I'll make sure to include them in the initial set for 
>  > Python 3.10.
>  
>  So I got an installer image built and tested:
>  
>
> https://openqa.stg.fedoraproject.org/tests/overview?distri=fedora&ver...
>  
>  and that looks good. The Cyrillic failure is a known bug in Rawhide,
>  and the other failures are things that are known to fail when we run
>  these tests with a netinst image as opposed to a DVD image (they rely
>  on the image containing packages).
>  
>  I'm currently trying to build a live image, but it's running insanely
>  slow for some reason, mock in general on my Rawhide box seems to be
>  really slow and I'm not sure why. If it ever finishes I'll try it. But
>  so far at least I see no problems. 
Hah, so it seems you're ahead of me =)

The live image build finally finished, but when I booted it to check
it, I found it includes both python3-3.8.3-1.fc33 and python3.9-
3.9.0~b1-1.fc33.x86_64 .

Digging into this I figured out it's because of libreoffice:
libreoffice-pyuno requires Python 3.8. So I went to Koji and
saw...you're rebuilding it already :)

https://koji.fedoraproject.org/koji/buildinfo?buildID=1511799

I will test again when that's done.
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net

[Miro Hrončok]

On 27. 05. 20 19:27, Adam Williamson wrote:
>  On Tue, 2020-05-26 at 16:22 -0700, Adam Williamson wrote:
> > On Tue, 2020-05-26 at 01:20 +0200, Miro Hrončok wrote:
> >> On 22. 05. 20 20:05, Adam Williamson wrote:
> >>> On Fri, 2020-05-22 at 19:57 +0200, Miro Hrončok wrote:
> >>>> On 22. 05. 20 19:23, Adam Williamson wrote:
> >>>>> So a request here: once the rebuilds are done, before we consider
> >>>>> moving them to Rawhide proper, can we have releng run a test compose
> >>>>> using the side tag and run openQA on it, to test for bugs in the
> >>>>> installer or key critpath components caused by the 3.9 changes? I
> don't
> >>>>> see anything about this in the Change page:
> >>>>> https://fedoraproject.org/wiki/Changes/Python3.9
> >>>>> but I think it'd be good to catch at least any major issues
> before we
> >>>>> land the change rather than after...
> >>>>
> >>>> I am all in if this is possible.
> >>>>
> >>>> When we updated to Python 3.7 I wanted to do it, but I was told it was
> not possible.
> >>>>
> >>>> When we updated to Python 3.8, I've asked around once again, but was
> still not
> >>>> possible.
> >>>
> >>> ah, fun :/
> >>>
> >>> we should at *least* be able to hack it up manually or in openQA,
> >>> though it may be ugly. if releng still can't do it, let me know and
> >>> I'll see if I can work something out.
> >>
> >> AFAIK packages that are required to do a minimal compose should all be rebuilt
> >> now. So you should be able to hack it up somehow. If packages are missing,
> >> please let me knwo and I'll make sure to include them in the initial set for
> >> Python 3.10.
> >
> > So I got an installer image built and tested:
> >
> >
> https://openqa.stg.fedoraproject.org/tests/overview?distri=fedora&ver...
> >
> > and that looks good. The Cyrillic failure is a known bug in Rawhide,
> > and the other failures are things that are known to fail when we run
> > these tests with a netinst image as opposed to a DVD image (they rely
> > on the image containing packages).
> >
> > I'm currently trying to build a live image, but it's running insanely
> > slow for some reason, mock in general on my Rawhide box seems to be
> > really slow and I'm not sure why. If it ever finishes I'll try it. But
> > so far at least I see no problems.
>  
>  Hah, so it seems you're ahead of me =)
>  
>  The live image build finally finished, but when I booted it to check
>  it, I found it includes both python3-3.8.3-1.fc33 and python3.9-
>  3.9.0~b1-1.fc33.x86_64 .
>  
>  Digging into this I figured out it's because of libreoffice:
>  libreoffice-pyuno requires Python 3.8. So I went to Koji and
>  saw...you're rebuilding it already :)
>  
>  https://koji.fedoraproject.org/koji/buildinfo?buildID=1511799
>  
>  I will test again when that's done. 
If it ever finishes.

-- 
Miro Hrončok
--
Phone: [phone]
IRC: mhroncok

[Miro Hrončok]

On 27. 05. 20 20:24, Miro Hrončok wrote:
> >>
> I'm currently trying to build a live image, but it's running insanely
> >> slow for some reason, mock in general on my Rawhide box seems to be
> >> really slow and I'm not sure why. If it ever finishes I'll try it. But
> >> so far at least I see no problems.
> >
> > Hah, so it seems you're ahead of me =)
> >
> > The live image build finally finished, but when I booted it to check
> > it, I found it includes both python3-3.8.3-1.fc33 and python3.9-
> > 3.9.0~b1-1.fc33.x86_64 .
> >
> > Digging into this I figured out it's because of libreoffice:
> > libreoffice-pyuno requires Python 3.8. So I went to Koji and
> > saw...you're rebuilding it already :)
> >
> > https://koji.fedoraproject.org/koji/buildinfo?buildID=1511799
> >
> > I will test again when that's done.
>  
>  If it ever finishes. 
After 30 hours of s390x misery watching the build.log grow one line in 15 
minutes, I decided to gamble and I have restarted the build:

https://koji.fedoraproject.org/koji/taskinfo?taskID=45081892

-- 
Miro Hrončok
--
Phone: [phone]
IRC: mhroncok

[Miro Hrončok]

On 28. 05. 20 0:42, Miro Hrončok wrote:
>  On 27. 05. 20 20:24, Miro Hrončok wrote:
> >>>
> I'm currently trying to build a live image, but it's running insanely
> >>> slow for some reason, mock in general on my Rawhide box seems to be
> >>>
> really slow and I'm not sure why. If it ever finishes I'll try it. But
> >>> so far at least I see no problems.
> >>
> >> Hah, so it seems you're ahead of me =)
> >>
> >> The live image build finally finished, but when I booted it to check
> >> it, I found it includes both python3-3.8.3-1.fc33 and python3.9-
> >> 3.9.0~b1-1.fc33.x86_64 .
> >>
> >> Digging into this I figured out it's because of libreoffice:
> >> libreoffice-pyuno requires Python 3.8. So I went to Koji and
> >> saw...you're rebuilding it already :)
> >>
> >> https://koji.fedoraproject.org/koji/buildinfo?buildID=1511799
> >>
> >> I will test again when that's done.
> >
> > If it ever finishes.
>  
>  After 30 hours of s390x misery watching the build.log grow one line in 15 
>  minutes, I decided to gamble and I have restarted the build:
>  
>  https://koji.fedoraproject.org/koji/taskinfo?taskID=45081892 
Apparently, tough luck.

Could you please test with x86_64 libreoffice packages downloaded from Koji 
before the build finishes? That way, we'll know that we can merge as soon as it 
is finally done.

Thanks

-- 
Miro Hrončok
--
Phone: [phone]
IRC: mhroncok

[Adam Williamson]

On Wed, 2020-05-27 at 10:27 -0700, Adam Williamson wrote:
>  
>  Hah, so it seems you're ahead of me =)
>  
>  The live image build finally finished, but when I booted it to check
>  it, I found it includes both python3-3.8.3-1.fc33 and python3.9-
>  3.9.0~b1-1.fc33.x86_64 .
>  
>  Digging into this I figured out it's because of libreoffice:
>  libreoffice-pyuno requires Python 3.8. So I went to Koji and
>  saw...you're rebuilding it already :)
>  
>  https://koji.fedoraproject.org/koji/buildinfo?buildID=1511799
>  
>  I will test again when that's done. 
In the mean time I tested a KDE live build, and that came up with just
Python 3.9 in it. So that looks good.
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net

[Miro Hrončok]

On 28. 05. 20 8:33, Adam Williamson wrote:
>  On Wed, 2020-05-27 at 10:27 -0700, Adam Williamson wrote:
> >
> > Hah, so it seems you're ahead of me =)
> >
> > The live image build finally finished, but when I booted it to check
> > it, I found it includes both python3-3.8.3-1.fc33 and python3.9-
> > 3.9.0~b1-1.fc33.x86_64 .
> >
> > Digging into this I figured out it's because of libreoffice:
> > libreoffice-pyuno requires Python 3.8. So I went to Koji and
> > saw...you're rebuilding it already :)
> >
> > https://koji.fedoraproject.org/koji/buildinfo?buildID=1511799
> >
> > I will test again when that's done.
>  
>  In the mean time I tested a KDE live build, and that came up with just
>  Python 3.9 in it. So that looks good. 
I'd like to merge the side tag as soon as libreoffice is built.

Adam, do you want to ack it first?


-- 
Miro Hrončok
--
Phone: [phone]
IRC: mhroncok

[Adam Williamson]

On Fri, 2020-05-29 at 00:12 +0200, Miro Hrončok wrote:
>  On 28. 05. 20 8:33, Adam Williamson wrote:
>  > On Wed, 2020-05-27 at 10:27 -0700, Adam Williamson wrote:
>  > > Hah, so it seems you're ahead of me =)
>  > > 
>  > > The live image build finally finished, but when I booted it to check
>  > > it, I found it includes both python3-3.8.3-1.fc33 and python3.9-
>  > > 3.9.0~b1-1.fc33.x86_64 .
>  > > 
>  > > Digging into this I figured out it's because of libreoffice:
>  > > libreoffice-pyuno requires Python 3.8. So I went to Koji and
>  > > saw...you're rebuilding it already :)
>  > > 
>  > > https://koji.fedoraproject.org/koji/buildinfo?buildID=1511799
>  > > 
>  > > I will test again when that's done.
>  > 
>  > In the mean time I tested a KDE live build, and that came up with just
>  > Python 3.9 in it. So that looks good.
>  
>  I'd like to merge the side tag as soon as libreoffice is built.
>  
>  Adam, do you want to ack it first? 
I think it'll be OK to merge when libreoffice is built. I'm pretty sure
it was the only issue on the Workstation live, and my live builds are
insanely slow like I said (haven't figured out why yet) so we'd be
waiting hours to do another Workstation live to confirm...
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net

[Miro Hrončok]

On 22. 05. 20 3:06, Miro Hrončok wrote:
>  Hello, in order to deliver Python 3.9, we are running a coordinated
> rebuild in a 
>  side tag.
>  
>  https://fedoraproject.org/wiki/Changes/Python3.9
>  
>  If you see a "Rebuilt for Python 3.9" (or similar) commit in your package, 
>  please don't rebuild it in regular rawhide.
>  If you need to, please let me know, so we can coordinate. 
Hello.

I've seen several packages updated in rawhide after the "Rebuilt for Python
3.9" 
commit. Please don't rebuild the packages in regular rawhide unless it is 
critical. When it is critical, please let me know about it, so we can coordinate.

Thanks.
-- 
Miro Hrončok
--
Phone: [phone]
IRC: mhroncok

[Fabio Valentini]

On Tue, May 26, 2020, 12:51 Miro Hrončok <mhroncok(a)redhat.com&gt; wrote:
>  On 22. 05. 20 3:06, Miro Hrončok wrote:
>  > Hello, in order to deliver Python 3.9, we are running a coordinated rebuild in a
>  > side tag.
>  >
>  > https://fedoraproject.org/wiki/Changes/Python3.9
>  >
>  > If you see a "Rebuilt for Python 3.9" (or similar) commit in your
> package,
>  > please don't rebuild it in regular rawhide.
>  > If you need to, please let me know, so we can coordinate.
>
>  Hello.
>
>  I've seen several packages updated in rawhide after the "Rebuilt for Python
> 3.9"
>  commit. Please don't rebuild the packages in regular rawhide unless it is
>  critical. When it is critical, please let me know about it, so we can coordinate.
>
>  Thanks. 
RFE: Mutex mode for koji :)

> --
> Miro Hrončok
> --
> Phone: [phone]
> IRC: mhroncok
> _______________________________________________
> devel mailing list -- devel(a)lists.fedoraproject.org
> To unsubscribe send an email to devel-leave(a)lists.fedoraproject.org
> Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
https://lists.fedoraproject.org/archives/list/[e-mail]

[Justin Forbes]

On Tue, May 26, 2020 at 5:50 AM Miro Hrončok <mhroncok(a)redhat.com&gt; wrote:

>  On 22. 05. 20 3:06, Miro Hrončok wrote:
>  > Hello, in order to deliver Python 3.9, we are running a coordinated
>  rebuild in a
>  > side tag.
>  >
>  > https://fedoraproject.org/wiki/Changes/Python3.9
>  >
>  > If you see a "Rebuilt for Python 3.9" (or similar) commit in your
>  package,
>  > please don't rebuild it in regular rawhide.
>  > If you need to, please let me know, so we can coordinate.
>
>  Hello.
>
>  I've seen several packages updated in rawhide after the "Rebuilt for
>  Python 3.9"
>  commit. Please don't rebuild the packages in regular rawhide unless it is
>  critical. When it is critical, please let me know about it, so we can
>  coordinate.
>
>  
Sorry, we rebuild kernel daily, and kernel-tools/kernel-headers every
Monday.  I really wasn't thinking about the side build.

Justin

[Miro Hrončok]

On 26. 05. 20 16:14, Justin Forbes wrote:
>  
>  
>  On Tue, May 26, 2020 at 5:50 AM Miro Hrončok <mhroncok(a)redhat.com 
>  <mailto:[e-mail]>> wrote:
>  
>      On 22. 05. 20 3:06, Miro Hrončok wrote:
>       > Hello, in order to deliver Python 3.9, we are running a coordinated
>      rebuild in a
>       > side tag.
>       >
>       > https://fedoraproject.org/wiki/Changes/Python3.9
>       >
>       > If you see a "Rebuilt for Python 3.9" (or similar) commit in your
> package,
>       > please don't rebuild it in regular rawhide.
>       > If you need to, please let me know, so we can coordinate.
>  
>      Hello.
>  
>      I've seen several packages updated in rawhide after the "Rebuilt for Python
>      3.9"
>      commit. Please don't rebuild the packages in regular rawhide unless it is
>      critical. When it is critical, please let me know about it, so we can
>      coordinate.
>  
>  Sorry, we rebuild kernel daily, and kernel-tools/kernel-headers every Monday.  I 
>  really wasn't thinking about the side build. 
Let me know if you need the new builds of kernel-tools in rawhide. If not, could 
you build them in f33-python target? If yes, I'll bump and build before the side 
tag is merged.

-- 
Miro Hrončok
--
Phone: [phone]
IRC: mhroncok

[Justin Forbes]

On Tue, May 26, 2020 at 10:17 AM Miro Hrončok <mhroncok(a)redhat.com&gt; wrote:

>  On 26. 05. 20 16:14, Justin Forbes wrote:
>  >
>  >
>  > On Tue, May 26, 2020 at 5:50 AM Miro Hrončok <mhroncok(a)redhat.com
>  > <mailto:[e-mail]>> wrote:
>  >
>  >     On 22. 05. 20 3:06, Miro Hrončok wrote:
>  >      > Hello, in order to deliver Python 3.9, we are running a
>  coordinated
>  >     rebuild in a
>  >      > side tag.
>  >      >
>  >      > https://fedoraproject.org/wiki/Changes/Python3.9
>  >      >
>  >      > If you see a "Rebuilt for Python 3.9" (or similar) commit in
> your
>  package,
>  >      > please don't rebuild it in regular rawhide.
>  >      > If you need to, please let me know, so we can coordinate.
>  >
>  >     Hello.
>  >
>  >     I've seen several packages updated in rawhide after the "Rebuilt for
>  Python
>  >     3.9"
>  >     commit. Please don't rebuild the packages in regular rawhide unless
>  it is
>  >     critical. When it is critical, please let me know about it, so we can
>  >     coordinate.
>  >
>  > Sorry, we rebuild kernel daily, and kernel-tools/kernel-headers every
>  Monday.  I
>  > really wasn't thinking about the side build.
>
>  Let me know if you need the new builds of kernel-tools in rawhide. If not,
>  could
>  you build them in f33-python target? If yes, I'll bump and build before
>  the side
>  tag is merged.
>
>  
Yeah, I will make sure to rebuild on the f33-python target.  No problem,
like I said, just wasn't thinking about it.  Sorry about that.

Justin

[Miro Hrončok]

On 26. 05. 20 17:19, Justin Forbes wrote:
>  
>  
>  On Tue, May 26, 2020 at 10:17 AM Miro Hrončok <mhroncok(a)redhat.com 
>  <mailto:[e-mail]>> wrote:
>  
>      On 26. 05. 20 16:14, Justin Forbes wrote:
>       >
>       >
>       > On Tue, May 26, 2020 at 5:50 AM Miro Hrončok <mhroncok(a)redhat.com
>      <mailto:[e-mail]>
>       > <mailto:[e-mail] <mailto:[e-mail]>>>
> wrote:
>       >
>       >     On 22. 05. 20 3:06, Miro Hrončok wrote:
>       >      > Hello, in order to deliver Python 3.9, we are running a coordinated
>       >     rebuild in a
>       >      > side tag.
>       >      >
>       >      > https://fedoraproject.org/wiki/Changes/Python3.9
>       >      >
>       >      > If you see a "Rebuilt for Python 3.9" (or similar) commit
> in your
>      package,
>       >      > please don't rebuild it in regular rawhide.
>       >      > If you need to, please let me know, so we can coordinate.
>       >
>       >     Hello.
>       >
>       >     I've seen several packages updated in rawhide after the "Rebuilt
> for
>      Python
>       >     3.9"
>       >     commit. Please don't rebuild the packages in regular rawhide unless it
> is
>       >     critical. When it is critical, please let me know about it, so we can
>       >     coordinate.
>       >
>       > Sorry, we rebuild kernel daily, and kernel-tools/kernel-headers every
>      Monday.  I
>       > really wasn't thinking about the side build.
>  
>      Let me know if you need the new builds of kernel-tools in rawhide. If not,
>      could
>      you build them in f33-python target? If yes, I'll bump and build before the
>      side
>      tag is merged.
>  
>  
>  Yeah, I will make sure to rebuild on the f33-python target.  No problem, like I 
>  said, just wasn't thinking about it.  Sorry about that. 
Thank you.

-- 
Miro Hrončok
--
Phone: [phone]
IRC: mhroncok

[Miro Hrončok]

On 22. 05. 20 3:06, Miro Hrončok wrote:
>  Hello, in order to deliver Python 3.9, we are running a coordinated
> rebuild in a 
>  side tag.
>  
>  https://fedoraproject.org/wiki/Changes/Python3.9
>  
>  If you see a "Rebuilt for Python 3.9" (or similar) commit in your package, 
>  please don't rebuild it in regular rawhide.
>  If you need to, please let me know, so we can coordinate. 
Hello.

I've seen more packages updated in rawhide after the "Rebuilt for Python
3.9" 
commit. Please don't rebuild the packages in regular rawhide unless it is 
critical. When it is critical, please let me know about it, so we can coordinate.

Thanks.

-- 
Miro Hrončok
--
Phone: [phone]
IRC: mhroncok

[Miro Hrončok]

On 22. 05. 20 3:06, Miro Hrončok wrote:
>  Hello, in order to deliver Python 3.9, we are running a coordinated
> rebuild in a 
>  side tag.
>  
>  https://fedoraproject.org/wiki/Changes/Python3.9
>  
>  If you see a "Rebuilt for Python 3.9" (or similar) commit in your package, 
>  please don't rebuild it in regular rawhide.
>  If you need to, please let me know, so we can coordinate. 
Hello.

I've seen more packages updated in rawhide after the "Rebuilt for Python
3.9" 
commit. Please don't rebuild the packages in regular rawhide unless it is 
critical. When it is critical, please let me know about it, so we can coordinate.

Thanks.

-- 
Miro Hrončok
--
Phone: [phone]
IRC: mhroncok

[Miro Hrončok]

On 22. 05. 20 3:06, Miro Hrončok wrote:
>  Hello, in order to deliver Python 3.9, we are running a coordinated
> rebuild in a 
>  side tag.
>  
>  https://fedoraproject.org/wiki/Changes/Python3.9
>  
>  If you see a "Rebuilt for Python 3.9" (or similar) commit in your package, 
>  please don't rebuild it in regular rawhide.
>  If you need to, please let me know, so we can coordinate. 
Hello.

I've seen more packages updated in rawhide after the "Rebuilt for Python
3.9" 
commit. Please don't rebuild the packages in regular rawhide unless it is 
critical. When it is critical, please let me know about it, so we can coordinate.

Thanks.

-- 
Miro Hrončok
--
Phone: [phone]
IRC: mhroncok

[Miro Hrončok]

On 22. 05. 20 3:06, Miro Hrončok wrote:
>  Hello, in order to deliver Python 3.9, we are running a coordinated
> rebuild in a 
>  side tag.
>  
>       https://fedoraproject.org/wiki/Changes/Python3.9
>  
>  If you see a "Rebuilt for Python 3.9" (or similar) commit in your package, 
>  please don't rebuild it in regular rawhide.
>  If you need to, please let me know, so we can coordinate.
>  
>  If you'd like to build the package, you should be able to build it in the side 
>  tag via:
>  
>       on branch master:
>       $ fedpkg build --target=f33-python
>       $ koji wait-repo f33-python --build <nvr>
>  
>  Note that it will take a while before all the essential packages are rebuilt, so 
>  don't except all your dependencies to be available right away. When in trouble, 
>  ask here or on IRC (#fedora-python on Freenode).
>  
>  Builds: 
>
> https://koji.fedoraproject.org/koji/builds?latest=0&tagID=22287&o...
>
>  
>  
>  Please avoid any potentially disturbing changes in Python packages until the 
>  rebuild is over. 
The side tag is being merged right now.

The builds are tagged into f33 in alphabetical order, hence expect a small 
window of very broken dependencies.

-- 
Miro Hrončok
--
Phone: [phone]
IRC: mhroncok

[Felix Schwarz]

Am 29.05.20 um 09:19 schrieb Miro Hrončok:
>  The side tag is being merged right now. 
Thank you for all the work (also in advance with all the alpha/beta versions) :-)

Seems like quite a few Python packages were rebuilt in rawhide during your
mass rebuild. Did that happen in the past as well? (I don't remember it that
way but also I did not monitor previous python rebuilds closely).

Felix

[Miro Hrončok]

On 29. 05. 20 9:32, Felix Schwarz wrote:
>  
>  Am 29.05.20 um 09:19 schrieb Miro Hrončok:
> > The side tag is being merged right now.
>  
>  Thank you for all the work (also in advance with all the alpha/beta versions) :-)
>  
>  Seems like quite a few Python packages were rebuilt in rawhide during your
>  mass rebuild. Did that happen in the past as well? (I don't remember it that
>  way but also I did not monitor previous python rebuilds closely). 
In previous upgrades, we haven't checked and after we asked releng to merge the 
side tag, we just realized several packages were rebuilt (incl. a small boostrap 
loop once and anaconda the other time). Hence this time, I've been monitoring 
the situation. Less then 10 packages were bumped and built in rawhide during the 
rebuilds this time.

-- 
Miro Hrončok
--
Phone: [phone]
IRC: mhroncok

[Jonathan Wakely]

On 29/05/20 09:34 +0200, Miro Hrončok wrote:
> On 29. 05. 20 9:32, Felix Schwarz wrote:
> >
> >Am 29.05.20 um 09:19 schrieb Miro Hrončok:
> >>The side tag is being merged right now.
> >
> >Thank you for all the work (also in advance with all the alpha/beta versions) :-)
> >
> >Seems like quite a few Python packages were rebuilt in rawhide during your
> >mass rebuild. Did that happen in the past as well? (I don't remember it that
> >way but also I did not monitor previous python rebuilds closely).
>
> In previous upgrades, we haven't checked and after we asked releng to 
> merge the side tag, we just realized several packages were rebuilt 
> (incl. a small boostrap loop once and anaconda the other time). Hence 
> this time, I've been monitoring the situation. Less then 10 packages 
> were bumped and built in rawhide during the rebuilds this time. 
Could you send me the list of those packages, if you have it?

Are any of them in the list of packages that I need to rebuild anyway
for the boost1.73+python3.9 combo?

By the way, I accidentally rebuilt player in the f33-boost side tag,
because my makefile incorrectly listed it as a prerequisite of gazebo
and so automatically added it to my rebuilds (it *is* a prerequisite
of gazebo, but doesn't use boost so I didn't need to do it). I noticed
that your f33-python build of player didn't work, so I'll add that to
the list of ones to rebuild in my tag after f33-python finishes
merging (apparently they're still being signed).

[Miro Hrončok]

On 29. 05. 20 11:49, Jonathan Wakely wrote:
>  On 29/05/20 09:34 +0200, Miro Hrončok wrote:
> > On 29. 05. 20 9:32, Felix Schwarz wrote:
> >>
> >> Am 29.05.20 um 09:19 schrieb Miro Hrončok:
> >>> The side tag is being merged right now.
> >>
> >> Thank you for all the work (also in advance with all the alpha/beta versions) 
> >> :-)
> >>
> >> Seems like quite a few Python packages were rebuilt in rawhide during your
> >> mass rebuild. Did that happen in the past as well? (I don't remember it that
> >> way but also I did not monitor previous python rebuilds closely).
> >
> > In previous upgrades, we haven't checked and after we asked releng to merge 
> > the side tag, we just realized several packages were rebuilt (incl. a small 
> > boostrap loop once and anaconda the other time). Hence this time, I've been 
> > monitoring the situation. Less then 10 packages were bumped and built in 
> > rawhide during the rebuilds this time.
>  
>  Could you send me the list of those packages, if you have it? 
I've rebuilt them all again.

>  Are any of them in the list of packages that I need to rebuild
> anyway
>  for the boost1.73+python3.9 combo? 
No.

>  By the way, I accidentally rebuilt player in the f33-boost side tag,
>  because my makefile incorrectly listed it as a prerequisite of gazebo
>  and so automatically added it to my rebuilds (it *is* a prerequisite
>  of gazebo, but doesn't use boost so I didn't need to do it). I noticed
>  that your f33-python build of player didn't work, so I'll add that to
>  the list of ones to rebuild in my tag after f33-python finishes
>  merging (apparently they're still being signed). 
The signing is taking ages :/

-- 
Miro Hrončok
--
Phone: [phone]
IRC: mhroncok

[Jonathan Wakely]

On 29/05/20 12:17 +0200, Miro Hrončok wrote:
> On 29. 05. 20 11:49, Jonathan Wakely wrote:
> >On 29/05/20 09:34 +0200, Miro Hrončok wrote:
> >>On 29. 05. 20 9:32, Felix Schwarz wrote:
> >>>
> >>>Am 29.05.20 um 09:19 schrieb Miro Hrončok:
> >>>>The side tag is being merged right now.
> >>>
> >>>Thank you for all the work (also in advance with all the 
> >>>alpha/beta versions) :-)
> >>>
> >>>Seems like quite a few Python packages were rebuilt in rawhide during your
> >>>mass rebuild. Did that happen in the past as well? (I don't remember it
> that
> >>>way but also I did not monitor previous python rebuilds closely).
> >>
> >>In previous upgrades, we haven't checked and after we asked releng 
> >>to merge the side tag, we just realized several packages were 
> >>rebuilt (incl. a small boostrap loop once and anaconda the other 
> >>time). Hence this time, I've been monitoring the situation. Less 
> >>then 10 packages were bumped and built in rawhide during the 
> >>rebuilds this time.
> >
> >Could you send me the list of those packages, if you have it?
>
> I've rebuilt them all again.
>
> >Are any of them in the list of packages that I need to rebuild anyway
> >for the boost1.73+python3.9 combo?
>
> No. 
OK, great, nothing extra for me to do then :-)

> >By the way, I accidentally rebuilt player in the f33-boost side
> tag,
> >because my makefile incorrectly listed it as a prerequisite of gazebo
> >and so automatically added it to my rebuilds (it *is* a prerequisite
> >of gazebo, but doesn't use boost so I didn't need to do it). I noticed
> >that your f33-python build of player didn't work, so I'll add that to
> >the list of ones to rebuild in my tag after f33-python finishes
> >merging (apparently they're still being signed).
>
> The signing is taking ages :/ 
Yes, but python3-3.8.3-1.fc33 is done, so I'll rebuild boost in my
side tag and resume my rebuilds there.

[Miro Hrončok]

On 29. 05. 20 13:07, Jonathan Wakely wrote:
>  On 29/05/20 12:17 +0200, Miro Hrončok wrote:
> > On 29. 05. 20 11:49, Jonathan Wakely wrote:
> >> On 29/05/20 09:34 +0200, Miro Hrončok wrote:
> >>> On 29. 05. 20 9:32, Felix Schwarz wrote:
> >>>>
> >>>> Am 29.05.20 um 09:19 schrieb Miro Hrončok:
> >>>>> The side tag is being merged right now.
> >>>>
> >>>> Thank you for all the work (also in advance with all the alpha/beta 
> >>>> versions) :-)
> >>>>
> >>>> Seems like quite a few Python packages were rebuilt in rawhide during
> your
> >>>> mass rebuild. Did that happen in the past as well? (I don't remember
> it that
> >>>> way but also I did not monitor previous python rebuilds closely).
> >>>
> >>> In previous upgrades, we haven't checked and after we asked releng to
> merge 
> >>> the side tag, we just realized several packages were rebuilt (incl. a small 
> >>> boostrap loop once and anaconda the other time). Hence this time, I've
> been 
> >>> monitoring the situation. Less then 10 packages were bumped and built in 
> >>> rawhide during the rebuilds this time.
> >>
> >> Could you send me the list of those packages, if you have it?
> >
> > I've rebuilt them all again.
> >
> >> Are any of them in the list of packages that I need to rebuild anyway
> >> for the boost1.73+python3.9 combo?
> >
> > No.
>  
>  OK, great, nothing extra for me to do then :-)
>  
> >> By the way, I accidentally rebuilt player in the f33-boost side tag,
> >> because my makefile incorrectly listed it as a prerequisite of gazebo
> >> and so automatically added it to my rebuilds (it *is* a prerequisite
> >> of gazebo, but doesn't use boost so I didn't need to do it). I noticed
> >> that your f33-python build of player didn't work, so I'll add that to
> >> the list of ones to rebuild in my tag after f33-python finishes
> >> merging (apparently they're still being signed).
> >
> > The signing is taking ages :/
>  
>  Yes, but python3-3.8.3-1.fc33 is done, so I'll rebuild boost in my
>  side tag and resume my rebuilds there. 
This was a Python 3.9 rebuild, not 3.8. We need to wait for:

   python3.9-3.9.0~b1-3.fc33

-- 
Miro Hrončok
--
Phone: [phone]
IRC: mhroncok

[Miro Hrončok]

On 22. 05. 20 3:06, Miro Hrončok wrote:
>  Hello, in order to deliver Python 3.9, we are running a coordinated
> rebuild in a 
>  side tag.
>  
>       https://fedoraproject.org/wiki/Changes/Python3.9
>  
>  If you see a "Rebuilt for Python 3.9" (or similar) commit in your package, 
>  please don't rebuild it in regular rawhide.
>  If you need to, please let me know, so we can coordinate. 
The side tag has been merged. Thank you all for your patience.

-- 
Miro Hrončok
--
Phone: [phone]
IRC: mhroncok

[Richard Shaw]

On Fri, May 29, 2020 at 9:18 AM Miro Hrončok <mhroncok(a)redhat.com&gt; wrote:

>  The side tag has been merged. Thank you all for your patience.
>  
Woohoo! So now Python can be rebuilt with the fix for PySide2? :)

Thanks,
Richard

[Miro Hrončok]

On 29. 05. 20 16:25, Richard Shaw wrote:
>  On Fri, May 29, 2020 at 9:18 AM Miro Hrončok <mhroncok(a)redhat.com
>
>  <mailto:[e-mail]>> wrote:
>  
>  
>      The side tag has been merged. Thank you all for your patience.
>  
>  
>  Woohoo! So now Python can be rebuilt with the fix for PySide2? :) 
Technically blocked by https://bugzilla.redhat.com/show_bug.cgi?id=1839826

But I am sure Petr is working on it.

-- 
Miro Hrončok
--
Phone: [phone]
IRC: mhroncok

[Petr Viktorin]

On 2020-05-29 16:39, Miro Hrončok wrote:
>  On 29. 05. 20 16:25, Richard Shaw wrote:
> > On Fri, May 29, 2020 at 9:18 AM Miro Hrončok <mhroncok(a)redhat.com 
> > <mailto:[e-mail]>> wrote:
> >
> >
> >     The side tag has been merged. Thank you all for your patience.
> >
> >
> > Woohoo! So now Python can be rebuilt with the fix for PySide2? :)
>  
>  Technically blocked by https://bugzilla.redhat.com/show_bug.cgi?id=1839826
>  
>  But I am sure Petr is working on it. 
It's progressing, though slower than I hoped due to other issues. I'll 
rebuild PySide and close the bug when done.

[Orion Poplawski]

On 5/29/20 8:17 AM, Miro Hrončok wrote:
>  On 22. 05. 20 3:06, Miro Hrončok wrote:
> > Hello, in order to deliver Python 3.9, we are running a coordinated 
> > rebuild in a side tag.
> >
> >      https://fedoraproject.org/wiki/Changes/Python3.9
> >
> > If you see a "Rebuilt for Python 3.9" (or similar) commit in your 
> > package, please don't rebuild it in regular rawhide.
> > If you need to, please let me know, so we can coordinate.
>  
>  The side tag has been merged. Thank you all for your patience.
>   
Thank you Miro for all the hard work.

-- 
Orion Poplawski
Manager of NWRA Technical Systems          720-772-5637
NWRA, Boulder/CoRA Office             FAX: [phone]
3380 Mitchell Lane                       orion(a)nwra.com
Boulder, CO 80301                 https://www.nwra.com/

[Miro Hrončok]

On 30. 05. 20 0:08, Orion Poplawski wrote:
>  On 5/29/20 8:17 AM, Miro Hrončok wrote:
> > On 22. 05. 20 3:06, Miro Hrončok wrote:
> >> Hello, in order to deliver Python 3.9, we are running a coordinated rebuild 
> >> in a side tag.
> >>
> >>      https://fedoraproject.org/wiki/Changes/Python3.9
> >>
> >> If you see a "Rebuilt for Python 3.9" (or similar) commit in your
> package, 
> >> please don't rebuild it in regular rawhide.
> >> If you need to, please let me know, so we can coordinate.
> >
> > The side tag has been merged. Thank you all for your patience.
> >
>  
>  Thank you Miro for all the hard work. 
You are welcome. Thanks for your help with vtk an other packages you maintain, I 
know you don't have that much time for Fedora nowadays.

-- 
Miro Hrončok
--
Phone: [phone]
IRC: mhroncok

[Jonathan Wakely]

On 29/05/20 16:17 +0200, Miro Hrončok wrote:
> On 22. 05. 20 3:06, Miro Hrončok wrote:
> >Hello, in order to deliver Python 3.9, we are running a coordinated 
> >rebuild in a side tag.
> >
> >     https://fedoraproject.org/wiki/Changes/Python3.9
> >
> >If you see a "Rebuilt for Python 3.9" (or similar) commit in your 
> >package, please don't rebuild it in regular rawhide.
> >If you need to, please let me know, so we can coordinate.
>
> The side tag has been merged. Thank you all for your patience. 
https://koji.fedoraproject.org/koji/buildinfo?buildID=1512682 is still
going for python-graph-tool-2.29-4.fc33 and will probably take another
15 hours at least, based on the comments in the spec file.

I've already started python-graph-tool-2.29-5.fc33 for the boost
rebuild, so if yours finishes it won't be needed anyway.

[Miro Hrončok]

On 30. 05. 20 23:10, Jonathan Wakely wrote:
>  On 29/05/20 16:17 +0200, Miro Hrončok wrote:
> > On 22. 05. 20 3:06, Miro Hrončok wrote:
> >> Hello, in order to deliver Python 3.9, we are running a coordinated rebuild 
> >> in a side tag.
> >>
> >>     https://fedoraproject.org/wiki/Changes/Python3.9
> >>
> >> If you see a "Rebuilt for Python 3.9" (or similar) commit in your
> package, 
> >> please don't rebuild it in regular rawhide.
> >> If you need to, please let me know, so we can coordinate.
> >
> > The side tag has been merged. Thank you all for your patience.
>  
>  https://koji.fedoraproject.org/koji/buildinfo?buildID=1512682 is still
>  going for python-graph-tool-2.29-4.fc33 and will probably take another
>  15 hours at least, based on the comments in the spec file.
>  
>  I've already started python-graph-tool-2.29-5.fc33 for the boost
>  rebuild, so if yours finishes it won't be needed anyway. 
I am afraid the build gets restarted every coupe hours. See:

https://koji.fedoraproject.org/koji/taskinfo?taskID=45142331

Total time	32:37:26
Task time	2:33:39

Buildroots
/var/lib/mock/f33-build-20969493-1558663
/var/lib/mock/f33-build-20951538-1558663
/var/lib/mock/f33-build-20962546-1558663
/var/lib/mock/f33-build-20957113-1558663
/var/lib/mock/f33-build-20953332-1558663

-- 
Miro Hrončok
--
Phone: [phone]
IRC: mhroncok