*** iurygregory has quit IRC | 01:26 | |
*** dansmith has quit IRC | 02:34 | |
*** dansmith has joined #openstack-release | 02:34 | |
*** ykarel|away has joined #openstack-release | 05:01 | |
*** ykarel|away is now known as ykarel | 05:02 | |
*** vishalmanchanda has joined #openstack-release | 05:32 | |
*** evrardjp has quit IRC | 05:33 | |
*** evrardjp has joined #openstack-release | 05:33 | |
*** e0ne has joined #openstack-release | 06:32 | |
*** rpittau|afk is now known as rpittau | 06:47 | |
*** e0ne has quit IRC | 06:59 | |
*** e0ne has joined #openstack-release | 07:18 | |
*** sboyron has joined #openstack-release | 07:19 | |
*** toabctl has quit IRC | 07:32 | |
*** toabctl has joined #openstack-release | 07:32 | |
*** e0ne has quit IRC | 07:41 | |
*** sboyron has quit IRC | 07:43 | |
openstackgerrit | Dmitriy Rabotyagov (noonedeadpunk) proposed openstack/releases master: Release OpenStack-Ansible Train https://review.opendev.org/761712 | 08:00 |
---|---|---|
openstackgerrit | Dmitriy Rabotyagov (noonedeadpunk) proposed openstack/releases master: Release OpenStack-Ansible Ussuri https://review.opendev.org/761713 | 08:01 |
*** iurygregory_ has joined #openstack-release | 08:09 | |
*** sboyron has joined #openstack-release | 08:10 | |
*** iurygregory_ is now known as iurygregory | 08:14 | |
*** dtantsur|afk is now known as dtantsur | 08:42 | |
openstackgerrit | Artem Goncharov proposed openstack/releases master: Release cliff 3.5.0 for Wallaby https://review.opendev.org/761718 | 08:51 |
*** e0ne has joined #openstack-release | 08:53 | |
openstackgerrit | Artem Goncharov proposed openstack/releases master: Release cliff 3.5.0 for Wallaby https://review.opendev.org/761718 | 09:26 |
*** sboyron has quit IRC | 09:54 | |
*** sboyron has joined #openstack-release | 09:54 | |
*** slaweq has joined #openstack-release | 09:56 | |
*** brinzhang0 has quit IRC | 10:42 | |
*** dtantsur is now known as dtantsur|bbl | 11:13 | |
*** e0ne has quit IRC | 11:38 | |
*** e0ne has joined #openstack-release | 12:25 | |
slaweq | smcginnis: hberaud: ttx and other stable-cores: hi, about a week ago I sent email http://lists.openstack.org/pipermail/openstack-discuss/2020-October/018389.html to propose Rodolfo to be neutron stable core | 12:26 |
slaweq | I didn't get any negative feedback so far | 12:26 |
slaweq | is it possible that You will add him to the neutron-stable-maint group? Or should I do something more for that? | 12:27 |
ttx | slaweq: let me see if I can still do that | 12:37 |
ttx | ok done | 12:38 |
*** ykarel has quit IRC | 12:40 | |
*** ykarel has joined #openstack-release | 12:41 | |
ttx | hberaud, fungi: regarding that ansible-role-redhat-subscription 1.1.1 release issue, it looks like PyPI has been ignoring our setup.py in that run (see http://lists.openstack.org/pipermail/openstack-discuss/2020-November/018577.html), so I'm a bit at a loss. Maybe we could reenqueue the 1.1.1 ref and see if the error persists? | 12:49 |
fungi | i can give it a shot, sure. i tried yesterday to inspect it myself but apparently the project doesn't build packages in the usual fashion | 12:50 |
hberaud | +1 to reenqueue it | 12:52 |
fungi | i was finally able to work out a viable tox env to build the sdist/wheel and run twine check against them, and that passes with current twine | 12:54 |
fungi | it's also possible to test uploading them to test.pypi.org | 12:54 |
*** tosky has joined #openstack-release | 13:07 | |
fungi | sudo zuul enqueue-ref --tenant=openstack --trigger=gerrit --pipeline=release --project=openstack/ansible-role-redhat-subscription --ref=refs/tags/1.1.1 --newrev=2da70e90b5fbdf225a95040903c4eb114ef3a9a4 | 13:13 |
fungi | that's been enqueued | 13:13 |
hberaud | thanks | 13:14 |
fungi | it's puzzling that the error from the attempted wheel upload indicates it tried to parse the description with the default (rst) parser when the wheel metadata explicitly includes "Description-Content-Type: text/markdown" | 13:16 |
hberaud | agreed | 13:17 |
hberaud | same error | 13:20 |
hberaud | it failed | 13:20 |
fungi | also pbr and setuptools support specifying the description content type in setup.cfg, it doesn't have to be embedded in setup.py | 13:21 |
fungi | "You can set the description-content-type to a MIME type that may help rendering of the description; for example text/markdown or text/x-rst; charset=UTF-8." https://docs.openstack.org/pbr/latest/user/features.html#long-description | 13:22 |
ttx | + the fact that 1.1.0 worked ok, that's a weird error | 13:22 |
fungi | yeah, it's possible there's some regression in warehouse causing it to not see the metadata and fall back to rst | 13:22 |
ttx | hberaud: maybe we should file an issue, saying it used to work and now we get this weird error | 13:23 |
hberaud | yes | 13:23 |
ttx | because it sure looks like we are doing the right thing | 13:23 |
hberaud | before I'll execute a test with readme-renderer | 13:23 |
ttx | and error really points to somethign weird on their side | 13:23 |
hberaud | to see if we can grab some info | 13:23 |
ttx | ++ | 13:23 |
hberaud | https://pypi.org/project/readme-renderer/ | 13:24 |
slaweq | ttx: thx | 13:24 |
hberaud | ttx: <string>:18: (WARNING/2) Line block ends without a blank line. | 13:26 |
ttx | uh | 13:26 |
ttx | weird error message then | 13:26 |
fungi | readme-renderer doesn't render markdown, just rst | 13:26 |
hberaud | apparently it doesn't love the table | 13:27 |
fungi | i also tested it just to see | 13:27 |
hberaud | fungi: the doc said that markdown could be passed too | 13:27 |
fungi | but yeah, then i realized it doesn't support markdown, the underlying issue is that the markdown content type is being ignored | 13:27 |
hberaud | It can handle Markdown, reStructuredText (.rst), and plain text. | 13:27 |
fungi | oh, weird, the --help doesn't mention markdown | 13:28 |
hberaud | I confirm the table is the issue | 13:28 |
fungi | "Renders a .rst README to HTML" and doesn't indicate how to tell it what content type you have if it's not rst | 13:28 |
hberaud | if I remove the table rendering works well | 13:28 |
fungi | but yeah, maybe readme-renderer is guessing from the file extension? | 13:29 |
hberaud | I think something is malformed | 13:29 |
hberaud | no idea | 13:29 |
fungi | i get the same warning even if i rename it to README.rst | 13:29 |
fungi | so not sure what content type it's actually trying to apply | 13:30 |
hberaud | we could run a pdb session to observe | 13:30 |
hberaud | which renderer is loaded and how it was handled | 13:30 |
hberaud | lets recheck the readme's changes first | 13:31 |
fungi | also i diffed the wheel metadata files between 1.1.0 and 1.1.1 and the only differences were the version and a few rows added/changed in that table in the description | 13:31 |
hberaud | exact | 13:32 |
fungi | so 1.1.0 uploaded successfully on 2020-05-21, that probably relied on warehouse using readme-renderer 26.0 from 2020-04-23 | 13:34 |
fungi | the only subsequent releases were last month | 13:34 |
fungi | changelog says 27.0 was "Add support for align attribute rendering Markdown headers" | 13:35 |
fungi | so maybe a regression crept in there? | 13:35 |
fungi | 28.0 was "Support Python 3.9" | 13:35 |
fungi | "There's nothing to 'check' for a Markdown readme as they will gracefully fail if there's invalid syntax, unlike reStructuredText. Any markdown readme will always be accepted by PyPI." https://github.com/pypa/readme_renderer/issues/156 | 13:37 |
fungi | if that's still true, then the problem lies before readme-renderer. warehouse should only be rejecting uploads with malformed rst, not md | 13:38 |
hberaud | I agree | 14:01 |
hberaud | then opening a bug could be worth for us | 14:02 |
hberaud | I am opening the bug | 14:11 |
*** whoami-rajat__ has joined #openstack-release | 14:17 | |
*** dtantsur|bbl is now known as dtantsur | 14:20 | |
smcginnis | There's an explicit setting that needs to be in setup.cfg to tell it the README content is markdown. Maybe pypi expects that now? | 14:36 |
hberaud | the PKG-INFO seems correct and markdown have been successfully applied | 14:36 |
smcginnis | Ah, they do have it: https://opendev.org/openstack/ansible-role-redhat-subscription/src/branch/master/setup.py#L20 | 14:37 |
hberaud | even without this in setup.cfg | 14:37 |
hberaud | yes | 14:37 |
smcginnis | For consistency, would be good if they just had rst. But looks like this should work. So yeah, maybe a warehouse bug. | 14:38 |
hberaud | yes rst could be an option | 14:38 |
hberaud | (move to) | 14:38 |
hberaud | By keeping the table of the description section readme_renderer output an empty file | 14:46 |
hberaud | By removing the table of the description section readme_renderer output a valid file | 14:46 |
hberaud | apparently it behave similarly with 26.0 and 28.0 | 14:47 |
hberaud | https://github.com/pypa/warehouse/issues/8791 | 14:49 |
*** suryasingh has joined #openstack-release | 15:07 | |
fungi | smcginnis: yeah, in fact i double-checked the METADATA file in the wheel (which is the upload being rejected) and it has a line precisely matching what the relevant pep and other howtos say should be there to indicate markdown for the long description | 15:09 |
fungi | also i have a feeling they're using markdown because that's standard for readme files in their ecosystem (ansible galaxy?) | 15:10 |
*** vishalmanchanda has quit IRC | 15:12 | |
*** jbadiapa has quit IRC | 15:16 | |
*** rpittau is now known as rpittau|afk | 15:18 | |
*** e0ne has quit IRC | 15:54 | |
hberaud | fungi: please can you upload needed info? => https://github.com/pypa/warehouse/issues/8791#issuecomment-723137214 | 16:07 |
hberaud | from job's artifacts | 16:08 |
hberaud | I don't know if I can access that from my side | 16:08 |
* hberaud afk for a while | 16:09 | |
fungi | the job artifacts are likely insufficient, but i can build the wheel locally and extract content (i already have in fact) | 16:12 |
fungi | probably the next thing to try, as i suggested earlier, is manually using twine to upload a locally built wheel to test.pypi.org and make sure we get the same rejection | 16:13 |
fungi | i'll create the project there shortly and give it a shot | 16:13 |
fungi | i was able to manually upload the copy i built to https://test.pypi.org/project/ansible-role-redhat-subscription/1.1.1/ | 16:16 |
fungi | my current suspicions are that we're using older setuptools which doesn't know to insert the content type into the metadata, or older twine which doesn't know to look for it when uploading | 16:27 |
fungi | i'll see if i can work out what versions are in use and test with those specifically | 16:27 |
fungi | failed build used twine 3.2.0 which is the same one i tested with, but looks like whatever setuptools version is supplied preinstalled on the node is what got utilized | 16:36 |
fungi | it also looks like we run the wheel utility locally on our executors instead of on a job node, so it's wheel 0.30.0 i think? still trying to confirm that | 16:43 |
fungi | or 0.32.3 on some newer executors | 16:44 |
fungi | my local build used 0.35.1 | 16:44 |
fungi | er, no, sorry it's twine i'm thinking of we're running on the executors not wheel. we run wheel on the job nodes | 16:45 |
fungi | but no, the log shows we do pip install twine in the executor's workspace during the job so that version should be current | 16:48 |
fungi | i guess what we're lacking is insight into the exact versions of setuptools and wheel used for the package built on the job node | 16:49 |
fungi | which may be what's contemporary for ubuntu 18.04 if we don't explicitly upgrade it somewhere not apparent in the job log | 16:50 |
fungi | yeah, we don't do the build in a venv and the ensure setuptools role seems to be satisfied that the executable is present, it looks like | 16:53 |
fungi | in which case this is using setuptools 39.0.1 and wheel 0.30.0 | 16:54 |
fungi | bingo... http://paste.openstack.org/show/799793 | 16:57 |
fungi | this is the tox env i was able to reproduce it with: http://paste.openstack.org/show/799795/ | 16:59 |
frickler | could someone approve the neutron stable/stein release please? /me needs to build new pkgs and that would make things easier https://review.opendev.org/761619 | 16:59 |
fungi | a bit more fiddling suggests it's something to do with using wheel 0.30.0 (unpinning it and relying on 0.35.1 seems to work fine) | 17:03 |
fungi | i'll see if i can narrow it to a specific version where it starts working and see what the changelog says there | 17:03 |
*** ykarel has quit IRC | 17:05 | |
*** ykarel_ has joined #openstack-release | 17:05 | |
fungi | starts working between 0.30.0 and 0.31.0 (there were no intermediate releases) | 17:05 |
ttx | frickler: looking | 17:09 |
ttx | wfm | 17:10 |
fungi | no smoking gun in the wheel changelog to suggest why it works with 0.31.0, the METADATA file in the wheel it build definitely includes "Description-Content-Type: text/markdown" still | 17:10 |
ttx | fungi: would it be possible that the line 18 warning cascades into the other error? Like if you fix that warning, does it work? | 17:12 |
fungi | aha, the only difference in the METADATA files is "Metadata-Version: 2.0" vs "-Metadata-Version: 2.1" i bet that's used to determine whether to look for Description-Content-Type | 17:12 |
fungi | ttx: i don't think so, no. the problem is that it wants to parse that markdown file as rst on upload | 17:13 |
*** dtantsur is now known as dtantsur|afk | 17:13 | |
fungi | and i think it's the metadata version causing it | 17:13 |
ttx | ok, so the only reason why we did not hit this sooner would be that 99% of our readme files are RST? | 17:14 |
fungi | "New in version 2.1." https://packaging.python.org/specifications/core-metadata/#description-content-type | 17:15 |
fungi | ttx: correct | 17:15 |
fungi | the "easy" solutions would be to force upgrade wheel globally on the job node before building, or use ubuntu-focal which has a new enough python3-wheel to support metadata version 2.1 | 17:16 |
fungi | as to why this worked in may and not now, i believe in the intervening timeframe we changed how we install wheel by default to using distro packages instead of from pypi | 17:17 |
ttx | hah | 17:17 |
ttx | once you have a grip on the issue and the options, you can follow up on the thread | 17:18 |
fungi | given that most of our other jobs have moved to focal, i wonder if the release jobs couldn't be updated to do the same? | 17:18 |
fungi | and yeah, i'll follow up on the ml thread and the github issue | 17:19 |
ttx | yeah that's probably the best option, we'll have to do that at some point anyway | 17:19 |
*** ykarel_ has quit IRC | 17:19 | |
fungi | the risk, i guess, is that we end up trying to build stable branch packages on newer distros than existed at the time? though zuul's somewhat recent tag-to-branch mapping solution could perhaps solve that if we try to do branch-specific variants for the different nodesets | 17:20 |
fungi | also i have no idea if stable branch releases would fail to build on focal or not. might work just fine | 17:21 |
hberaud | fungi: sorry I already submitted a local build previously, but I wasn't sure that I was exactly aligned with our job env | 17:28 |
openstackgerrit | Merged openstack/releases master: Release neutron 14.4.1 for stein https://review.opendev.org/761619 | 17:30 |
fungi | okay, ml and gh issue both updated with findings | 17:35 |
hberaud | kudos fungi for finding all these elements! | 17:35 |
fungi | hberaud: yep, the key was that by default we're started relying on distro packages for things like pip, setuptools, and wheel | 17:36 |
hberaud | I see | 17:36 |
fungi | mainly because our older "preinstall stuff from pypi" solution caused issues for projects which wanted to install different versions, and using `sudo pip install ...` doesn't really produce consistent behaviors across different distros anyway | 17:38 |
fungi | and we're relying on ensure-* roles from zuul's standard library, which tries to provide more generalized solutions which work across zuul deployments rather than things specific to opendev | 17:39 |
fungi | i'll work on the nodeset change for the release job now | 17:42 |
*** suryasingh has quit IRC | 17:45 | |
fungi | https://review.opendev.org/761776 Run publish-openstack-artifacts on ubuntu-focal | 17:49 |
clarkb | do weknow why older wheel breaks? | 17:53 |
fungi | yes, i did my best to explain both in the ml thread and on the gh issue | 18:01 |
fungi | it doesn't actually break | 18:02 |
fungi | it all comes down to metadata versioning | 18:02 |
fungi | we shouldn't be trying to set a content type for the long description unless we're also declaring a new enough metadata version to support that field | 18:02 |
fungi | wheel sets the metadata version, so to declare a newer metadata version you need a newer release of wheel | 18:03 |
fungi | clarkb: ^ | 18:04 |
clarkb | ah | 18:06 |
fungi | having personally worked on the implementation support for some of the newer metadata features in setuptools and pbr, i vaguely recall the logic... it's keyed on metadata version to decide whether to pat attention to or ignore certain fields | 18:07 |
*** dave-mccowan has quit IRC | 18:49 | |
fungi | we've got +2s on the nodeset change, shall i approve it now and reenqueue that tag or save it for monday? | 19:57 |
hberaud | fungi: as you prefer, I'm near of the eod for today but I'm confident | 20:15 |
hberaud | monday could be better if something goes wrong | 20:17 |
fungi | how about this: let me know on monday when a release manager is available to help vet results (i should hopefully be around myself by ~14:00 utc) and i'll approve it then and test | 20:23 |
hberaud | fungi: +1 | 20:26 |
hberaud | fungi: I'll be around 10:00am utc+1 and until the eod | 20:27 |
*** e0ne has joined #openstack-release | 21:21 | |
*** e0ne has quit IRC | 21:23 | |
*** melwitt is now known as jgwentworth | 21:26 | |
*** whoami-rajat__ has quit IRC | 21:26 | |
*** dave-mccowan has joined #openstack-release | 23:08 |
Generated by irclog2html.py 2.17.2 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!