Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

rust v1.50.0 #75

Merged
merged 13 commits into from
Feb 26, 2021
Merged

Conversation

regro-cf-autotick-bot
Copy link
Contributor

It is very likely that the current package version for this feedstock is out of date.
Notes for merging this PR:

  1. Feel free to push to the bot's branch to update this PR if needed.
  2. The bot will almost always only open one PR per version.
    Checklist before merging this PR:
  • Dependencies have been updated if changed: see upstream
  • Tests have passed
  • Updated license if changed and license_file is packaged

Note that the bot will stop issuing PRs if more than 3 Version bump PRs generated by the bot are open. If you don't want to package a particular version please close the PR.

NEW: If you want these PRs to be merged automatically, make an issue with @conda-forge-admin,please add bot automerge in the title and merge the resulting PR. This command will add our new bot automerge feature to your feedstock!

If this PR was opened in error or needs to be updated please add the bot-rerun label to this PR. The bot will close this PR and schedule another one. If you do not have permissions to add this label, you can use the phrase @conda-forge-admin, please rerun bot in a PR comment to have the conda-forge-admin add it for you.

This PR was created by the regro-cf-autotick-bot.
The regro-cf-autotick-bot is a service to automatically track the dependency graph, migrate packages, and propose package version updates for conda-forge. If you would like a local version of this bot, you might consider using rever. Rever is a tool for automating software releases and forms the backbone of the bot's conda-forge PRing capability. Rever is both conda (conda install -c conda-forge rever) and pip (pip install re-ver) installable.
Finally, feel free to drop us a line if there are any issues!
This PR was generated by https://github.com/regro/autotick-bot/actions/runs/558337160, please use this URL for debugging

Here is a list of all the pending dependencies (and their versions) for this repo. Please double check all dependencies before merging.

Name Upstream Version Current Version
rust 1.50.0 Anaconda-Server Badge

Dependency Analysis

Please note that this analysis is highly experimental. The aim here is to make maintenance easier by inspecting the package's dependencies. Importantly this analysis does not support optional dependencies, please double check those before making changes. If you do not want hinting of this kind ever please add bot: inspection: false to your conda-forge.yml. If you encounter issues with this feature please ping the bot team conda-forge/bot.

Analysis of the source code shows a discrepancy between the library's imports and the package's stated requirements in the meta.yaml.

Packages found by inspection but not in the meta.yaml:

  • rust

@conda-forge-linter
Copy link

Hi! This is the friendly automated conda-forge-linting service.

I just wanted to let you know that I linted all conda-recipes in your PR (recipe) and found it was in an excellent condition.

@pkgw
Copy link
Contributor

pkgw commented Feb 11, 2021

Drone build seems to have timed out. Unclear to me what happened with Travis — no obvious error message that I'm seeing in the log.

Also, AFAIK, the issue with introduced in 1.49, where Rust has bumped its minimum support macOS version (rust-lang/rust#80804), is still present.

@pkgw
Copy link
Contributor

pkgw commented Feb 17, 2021

@conda-forge-admin please restart ci

Let's see if any of these issues have decided to magically fix themselves ...

@pkgw
Copy link
Contributor

pkgw commented Feb 18, 2021

Cool, Travis did fix itself! @conda-forge/core do we have a way to increase the timeouts for selected builds on Drone?

@ocefpaf
Copy link
Member

ocefpaf commented Feb 18, 2021

Cool, Travis did fix itself! @conda-forge/core do we have a way to increase the timeouts for selected builds on Drone?

This has been plaguing us for a while. Looks like sometimes we get drone instances that are more roust than others. I'm not sure what we can do at the moment besides restart it :-(

@mbargull
Copy link
Member

Yes, it would be nice to be able to up the timeout for arm64 builds on some of our feedstocks.
For this one it shouldn't be needed though. I pushed a small change that should get us under the time limit.
(And ultimately, it would also make sense to improve the install.sh upstream -- that one is just a bash script which is only so slow because it does a lot (via subprocesses) for each of the 18-19K files that get copied. If fixed, the script should easily be able to finish in a matter of seconds.)

@mbargull
Copy link
Member

I pushed a small change that should get us under the time limit.

Wow, that wasn't enough, apparently o_O.
I'll write a patch for upstream and add it here then.

@pkgw
Copy link
Contributor

pkgw commented Feb 19, 2021

Wow, nice work! I was wondering why it was taking so long to just repackage some downloaded files but didn't seriously consider reworking the installation process ...

@isuruf
Copy link
Member

isuruf commented Feb 19, 2021

Before merging this, we need to pin rust to 1.48 on osx-64.

@stain
Copy link

stain commented Feb 21, 2021

@isuruf I am not sure how to do such pinning within a recipe (I know you can do such in dependencies of this package)

In https://github.com/conda-forge/admin-requests/pull/212/files this was done by labeling 1.49.0 as broken on platform osx-64 (osx-arm64 is obviously at modern enough macOS).

Indeed installing rust today on macOS 10.13 from conda-forge "correctly" installs 1.48.0 (we can't select on macOS version)

So I guess we'll again have to do this manual exclude here, after the fact, as another admin-request with the known build number?

https://dev.azure.com/conda-forge/feedstock-builds/_build/results?buildId=279807&view=logs&jobId=58ac6aab-c4bc-5de2-2894-98e408cc8ec9 seems to say:

...
TEST END: /Users/runner/miniforge3/conda-bld/osx-64/rust-1.50.0-h7e1429e_0.tar.bz2

So I would assume a similar exclude now would be for:

osx-64/rust-1.50.0-h7e1429e_0.tar.bz2

Or do we raise this in advance?

@isuruf
Copy link
Member

isuruf commented Feb 21, 2021

@mbargull
Copy link
Member

Before merging this, we need to pin rust to 1.48 on osx-64.

@isuruf, is this because of the minimum deployment target (#73)?
Just to get clarification: The rust package itself would itself work (i.e., marking 1.49 as broken was only temporary/workaround?) but we'd not use it downstream, i.e., pinning?


With the added build.sh and patch the builds complete much faster, but now conda-build is having troubles with the ~ 19k files.
Options to address this in this feedstock:

  1. Wait until we can up the CI time on Drone.
  2. Wait until conda-build handles many files considerably faster.
  3. Skip linux-aarch64 for now..
  4. Don't include the rust-docs component in the rust package on linux-aarch64.

IMO, it doesn't make sense to hold this up by waiting for 1. or 2., i.e., I'd go with 3. or 4.
I'm not too comfortable in having different contents for different platforms and would rather have a rust-docs exclusion "visible". Meaning, either we skip linux-aarch64 altogether for now, or we generally split out a new package rust-docs such that it is at least visible that you get rust->rust-docs on, e.g., linux-64, but only rust on linux-aarch64.

@conda-forge/rust, @isuruf: WDYT, which option to go for?

@isuruf
Copy link
Member

isuruf commented Feb 22, 2021

is this because of the minimum deployment target (#73)?

yes

Just to get clarification: The rust package itself would itself work (i.e., marking 1.49 as broken was only temporary/workaround?) but we'd not use it downstream, i.e., pinning?

yes

WDYT, which option to go for?

option 5. cross compile

@mbargull
Copy link
Member

option 5. cross compile

Ha, I'm a dummy! Of course! Thanks!

@mbargull
Copy link
Member

@isuruf, we don't yet have a way to run (QEMU-based?) tests when cross-compiling, right?

@isuruf
Copy link
Member

isuruf commented Feb 22, 2021

We do. Tests should work without any change.

@mbargull
Copy link
Member

We do. Tests should work without any change.

Oh, nice! Even if test_on_native_only: true is set (because of the macOS ARM in this feedstock)?

@isuruf
Copy link
Member

isuruf commented Feb 22, 2021

Nope. In that case, tests will not be run

@mbargull
Copy link
Member

Nope. In that case, tests will not be run

Ah, okay. Personally, I think it's not too bad in this case (since all is precompiled anyway).

Thanks again!

Would it make sense to make test_on_native_only optionally a dict platform -> bool to distinguish?

Comment on lines +17 to +24
# => replace path records beforehand:
install_log="${DESTDIR}${PREFIX}/lib/rustlib/install.log"
sed \
-e "s|${PREFIX}|/prefix|g" \
-e "s|${DESTDIR}|/destdir|g" \
-e "s|${PWD}|/source|g" \
-i.bak "${install_log}"
rm "${install_log}.bak"
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Alternative (if nobody wants/needs install.log):

Suggested change
# => replace path records beforehand:
install_log="${DESTDIR}${PREFIX}/lib/rustlib/install.log"
sed \
-e "s|${PREFIX}|/prefix|g" \
-e "s|${DESTDIR}|/destdir|g" \
-e "s|${PWD}|/source|g" \
-i.bak "${install_log}"
rm "${install_log}.bak"
# => remove install.log:
rm "${DESTDIR}${PREFIX}/lib/rustlib/install.log"

@mbargull
Copy link
Member

Pending conda-forge/conda-forge-pinning-feedstock#1233 , this is ready for review.


I reverted to native linux-aarch64 builds because cross-platform build failed with

Traceback (most recent call last):
  File "/opt/conda/bin/conda-build", line 11, in <module>
    sys.exit(main())
  File "/opt/conda/lib/python3.8/site-packages/conda_build/cli/main_build.py", line 481, in main
    execute(sys.argv[1:])
  File "/opt/conda/lib/python3.8/site-packages/conda_build/cli/main_build.py", line 470, in execute
    outputs = api.build(args.recipe, post=args.post, test_run_post=args.test_run_post,
  File "/opt/conda/lib/python3.8/site-packages/conda_build/api.py", line 186, in build
    return build_tree(
  File "/opt/conda/lib/python3.8/site-packages/conda_build/build.py", line 3068, in build_tree
    packages_from_this = build(metadata, stats,
  File "/opt/conda/lib/python3.8/site-packages/conda_build/build.py", line 2306, in build
    environ.create_env(m.config.host_prefix, host_actions, env='host',
  File "/opt/conda/lib/python3.8/site-packages/conda_build/environ.py", line 907, in create_env
    display_actions(actions, index)
  File "/opt/conda/lib/python3.8/site-packages/conda/exports.py", line 236, in display_actions
    actions['LINK'] = [index[d] for d in actions['LINK']]
  File "/opt/conda/lib/python3.8/site-packages/conda/exports.py", line 236, in <listcomp>
    actions['LINK'] = [index[d] for d in actions['LINK']]
KeyError: Dist(channel='conda-forge', dist_name='ld_impl_linux-aarch64-2.35.1-h02ad14f_2', name='ld_impl_linux-aarch64', fmt='.tar.bz2', version='2.35.1', build_string='h02ad14f_2', build_number=2, base_url=None, platform=None)

and I rather looked into why the build was slow rather than investigating into the conda-build+conda error above.

The CI job on Drone now barely finished under its 1 hour timeout; IDK why it's 4 times as slow as the linux-64 one on Azure, though (I expected a noticeable difference, but not that much).

@isuruf
Copy link
Member

isuruf commented Feb 22, 2021

Would it make sense to make test_on_native_only optionally a dict platform -> bool to distinguish?

Yes. I think we can also have an option like,

test: <native-only/all/native-and-emulated>

and deprecate test_on_native_only option. What do you think?

@mbargull mbargull force-pushed the 1.50.0_hcfb706 branch 3 times, most recently from aed30d0 to 219aa29 Compare February 22, 2021 19:21
@mbargull
Copy link
Member

Yes. I think we can also have an option like,

test: <native-only/all/native-and-emulated>

What would all be in comparison to native-and-emulated?

I'm leaning more towards a host platform <-> test platform(s) mapping, but give me a bit to ponder about it (I'll open an issue on smithy to track this).

@isuruf
Copy link
Member

isuruf commented Feb 22, 2021

What would all be in comparison to native-and-emulated?

all would test even in cross compiling. This is for when tests are like file existence tests. This is equivalent to test_on_native_only: false

@mbargull
Copy link
Member

@isuruf, it makes sense to add https://conda-forge.org/docs/maintainer/knowledge_base.html?highlight=macosx_sdk_version#requiring-newer-macos-sdks

requirements:
  run:
    - __osx >={{ MACOSX_DEPLOYMENT_TARGET|default("10.9") }}  # [osx and x86_64]

and the accompanying keys in cbc.yaml for the rust output, right (or just __osx >=10.10 # [osx and x86_64], depending if one wants brevity or consistency)?

recipe/meta.yaml Outdated
@@ -55,6 +62,7 @@ outputs:
run:
- {{ pin_subpackage("rust-std-" ~ rust_arch, exact=True) }}
- gcc_impl_{{ target_platform }} # [linux]
- __osx >={{ MACOSX_DEPLOYMENT_TARGET|default("10.9") }} # [osx and x86_64]
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This should be moved to run_exports

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This doesn't make sense in run because the compiler itself can be run in 10.9, only the compiled binaries cannot be run which means we need run_exports.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Makes sense.
Are we comfortable in adding virtual packages to run generally? Reading https://github.com/conda/conda/blob/4.9.2/CHANGELOG.md#bug-fixes-2 it's still rather recent that bugs have been fixed regarding them.
Do we want run_exports: { strong: ... } or be rather conservative (in expecting that users may run older non-fixed conda versions) and use run_exports: { strong_constrains: ... }?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Do we want run_exports: { strong: ... } or be rather conservative (in expecting that users may run older non-fixed conda versions) and use run_exports: { strong_constrains: ... }?

Sure. I was gonna say no such thing exists, but it does. 😄 conda/conda-build#4125

@isuruf isuruf merged commit 0e25bdf into conda-forge:master Feb 26, 2021
@regro-cf-autotick-bot regro-cf-autotick-bot deleted the 1.50.0_hcfb706 branch February 26, 2021 20:18
@pkgw pkgw mentioned this pull request Apr 10, 2021
5 tasks
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

7 participants