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

12 3.19.4 bits #3952

Merged
merged 22 commits into from
May 14, 2020
Merged

12 3.19.4 bits #3952

merged 22 commits into from
May 14, 2020

Conversation

mingwandroid
Copy link
Contributor

No description provided.

… or dirty are set

.. same thing with host prefix.

The code and concepts behind --dirty, --keep-old-work and also
perhaps build/no_move_top_level_workdir_loops seem a bit muddled and
overlapping. --dirty should *only* deal with finding a new croot, and
have no part in whether to keep stuff around or not. That should be
left to a new option, like:
--keep=work,build-prefix,host-prefix,test-prefix,test-tmp
where --keep-old-work is deprecated but enables all of these.
Also, 'keep' might not be the best word, call it what we do,
--retain-via-rename=work,..
…ors from the last

command do not exit the interactive shell (very annoying when testing package build failures).

We then must 'set -e' just after sourcing the env script.
Reverse failed patches so they do not leave behind newly created files for bits
that manged to apply OK (causing subsequent patches to potentially fail).

Rewrite apply_patch to behave more sanely, esp. in the face of fully-correct,
binary patches.

.. also, try the same patch modifications we try on Windows on the other OSes.
There is no reason not to.
These files are left behind by macOS when it needs to ratain
its extended attributes through round-trips to 'foreign'
file-systems.

And do we need two different bits of code globbing for meta.yamls?

No, we do not.
Changes ::

Uses lief 0.10.1 now (no code changes were needed for this update)
Fixes _map_file_to_package for finding '.dylib' and '.so' without suffixes beyond that
Added our FakeDist to run-prefix, improve library_nature, do not fail if ccache exists
Fixes detection of where packages comes from.
  We must avoid using 'canonical' channel names (such as 'default', needing
  instead 'pkgs/main') when determining which channels packages come from.
  To do this, we use a new function, linked_data_no_multichannels().
  Let's hope we never end up comparing these with ones gotten via linked_data()
Add local_output_folder to get_build_index()'s locally cached things.
Ensure we pass 'channel_urls' as a list and add the 'local' channel to
  that.
Disambiguate 'prefix' DSO files in the build/host throughout ovelink detection.
Change ERROR :: {} not in prefix_owners to a more helpful warning and add a comment
  though it might be better to just remove this warning and let the final info
  detail any issues (for they will show up as overlinking errors).

Notes ::

This is still not the speed boost that this stuff needs, so I am hoping the update to
0.10.1 helps with that. Looking at the history, it should, somewhat.

Case-insensitive lookup for Windows (hopefully only for files in the sysroot - which
is being referred to as the whitelist in the messages ATM unfortunately - still remains
to be done (and will probably get squashed into this commit).
@cla-bot cla-bot bot added the cla-signed [bot] added once the contributor has signed the CLA label May 12, 2020
@mingwandroid
Copy link
Contributor Author

@jjhelmus preview, I will also check some community PRs once you (and ci) are happy with all this!

@cla-bot
Copy link

cla-bot bot commented May 13, 2020

Thank you for your pull request and welcome to our community. We could not parse the GitHub identity of the following contributors: distro-bot@anaconda.com.
This is most likely caused by a git client misconfiguration; please make sure to:

  1. check if your git client is configured with an email to sign commits git config --list | grep email
  2. If not, set it up using git config --global user.email email@example.com
  3. Make sure that the git commit email is configured in your GitHub account settings, see https://github.com/settings/emails

@cla-bot cla-bot bot removed the cla-signed [bot] added once the contributor has signed the CLA label May 13, 2020
@cla-bot
Copy link

cla-bot bot commented May 14, 2020

Thank you for your pull request and welcome to our community. We could not parse the GitHub identity of the following contributors: distro-bot@anaconda.com.
This is most likely caused by a git client misconfiguration; please make sure to:

  1. check if your git client is configured with an email to sign commits git config --list | grep email
  2. If not, set it up using git config --global user.email email@example.com
  3. Make sure that the git commit email is configured in your GitHub account settings, see https://github.com/settings/emails

.. New link location: None for example
too liberal and we may want to do it only for Windows exes/dlls.
@cla-bot cla-bot bot added the cla-signed [bot] added once the contributor has signed the CLA label May 14, 2020
@cla-bot
Copy link

cla-bot bot commented May 14, 2020

Thank you for your pull request and welcome to our community. We could not parse the GitHub identity of the following contributors: distro-bot@anaconda.com.
This is most likely caused by a git client misconfiguration; please make sure to:

  1. check if your git client is configured with an email to sign commits git config --list | grep email
  2. If not, set it up using git config --global user.email email@example.com
  3. Make sure that the git commit email is configured in your GitHub account settings, see https://github.com/settings/emails

@cla-bot cla-bot bot removed the cla-signed [bot] added once the contributor has signed the CLA label May 14, 2020
@cla-bot cla-bot bot added the cla-signed [bot] added once the contributor has signed the CLA label May 14, 2020
…lease

The downside is that some packages may not get picked up. I need to check that though. It cannot remain this broken.

The problem seems to be that depending on how the channel was identified to conda when it made the Dist is how it will
remain and one created from 'defaults' is not equal to one created from 'pkgs/main'. During conda-build post, our channels
seem to come from 'pkgs/main' but at other times they come from 'defaults'.
@mingwandroid
Copy link
Contributor Author

I think this is good to go now. If you have time and agree, I'll look over community PRs after some food.

@github-actions
Copy link

Hi there, thank you for your contribution!

This pull request has been automatically locked because it has not had recent activity after being closed.

Please open a new issue or pull request if needed.

Thanks!

@github-actions github-actions bot added the locked [bot] locked due to inactivity label Mar 11, 2022
@github-actions github-actions bot locked as resolved and limited conversation to collaborators Mar 11, 2022
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
cla-signed [bot] added once the contributor has signed the CLA locked [bot] locked due to inactivity
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants