Rebuild for jpegturbo #303
Conversation
regro-cf-autotick-bot
requested review from
FarhanTejani,
ghego,
h-vetinari,
hajapy,
hmaarrfk,
jschueller,
ngam,
njzjz,
waitingkuo,
wolfv and
xhochy
as code owners
|
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 ( I do have some suggestions for making it better though... For recipe:
|
|
@conda-forge-admin please rerender |
hmaarrfk
changed the title
hmaarrfk
force-pushed
the
rebuild-jpeg_to_libjpeg_turbo-0-3_h5ee88f
branch
from
bd11818 to
a95b3e9
Compare
|
@h-vetinari it seems the migrator is stuck with an unsolvable environment here. I manually added the migration and can recreate. Any idea? |
hmaarrfk
changed the title
…nda-forge-pinning 2023.03.11.14.14.10
hmaarrfk
force-pushed
the
rebuild-jpeg_to_libjpeg_turbo-0-3_h5ee88f
branch
from
a95b3e9 to
c7ac4d0
Compare
|
Please include the libgrpc migration as well :) |
|
Ah, just saw you did that already. Once it's got jpeg, abseil and grpc, we should be good IMO |
|
Thanks for checking in h-vetinari, @ngam if you can build OSX, i can start to build linux. |
|
hmm i'm getting a failure like: |
|
hmmm... any idea what the error means exactly? I will start building soon on osx |
|
I think we are not linking correctly on abseil for some new feature. but i couldn't find a relevant issue on tensorflow or a relevant release note. i'm hoping h-vetinari has an idea ^_^ |
…nda-forge-pinning 2023.03.19.10.10.34
|
It seems that as there is no osx_arm64 CI, the mapping I'm not sure what the alternative is for local native builds. |
|
Maybe try to manually edit the ci files? We could likely add a local provider to smithy. But "minor" edits to the ci files is likely ok for this exceptional feedstock. |
|
It seems like this did the job: diff --git a/recipe/meta.yaml b/recipe/meta.yaml
index 899c02c..33b7f9f 100644
--- a/recipe/meta.yaml
+++ b/recipe/meta.yaml
@@ -41,7 +41,7 @@ requirements:
- {{ compiler('cxx') }}
- {{ compiler('cuda') }} # [cuda_compiler_version != "None"]
- bazel >=5.2.0,<6
- - libgrpc
+ - libgrpc {{ libgrpc }}
- libprotobuf
- nasm
- sedI think the pinning from the ci_support files only applies to host, but not build. In this case, this leads to a conflict as per #303 (comment) |
|
This is really strange. It used to apply to both in the past. I think..... This is what we used to do to ensure that openssl was correctly pinned in the past. Did you get through a full build? |
|
My M1 isn't that fast, I'll keep you posted :) |
I have two super-spec’ed M1 Max macs, I can give this a try soon. @Tobias-Fischer does it work for you natively or only emulated? |
|
Go for it, would be nice if you try. I build emulated; haven't tried natively. |
|
Natively never worked for me :( but @xhochy used to build natively |
|
Testing in #306 |
|
Unfortunately, the patch in #306 failed. Maybe we could attempt to build with hardcoded pins on all build/host/run? |
|
What was the error you got? |
|
Same as above: |
|
Btw @hmaarrfk could you please look at this closely? Am I seeing it correctly that py310 is mixed up with py38? This is supposed to be building py38. |
|
Also, this is the older tensorflow... (build 0) Why is this happening in the cross-compilation case? We almost never build more than the 0th build, so that's why we never faced it! |
|
We need |
|
yes, i am thinking the same about the pinnings. I'm trying to add a few more constraints in: You will also need to add a channel that can actually provide the native osx packages if you are cross compiling. |
Okay, this could be why! I will fix ~soon |
|
I actually think that when i'm cross compiling, it is trying to test things.... fd019c8#diff-d10439659fe44156d9eac347f9e9eb6992e5b516d0f7e86df061c8273397fd7dR58 |
|
adding ICU, abseil, and grpc helped. I also skipped tests on emulated. Fingers crossed. In my |
|
ok, 3.10 built for arm. Now off to 3.9 then 3.8. Then we can do the ICU migration lol! |
|
Is it the testing or the pins, you think? Or the channel? |
|
We should try to focus our resources on getting the abseil, icu, etc in the next release… that may prove more productive and easier |
|
Both i think. I am hopeful that the ICU and 2.11.1 are easy to migrate. I can likely start the compilation job and come back in 3 days when it is done (now that we spent 3 weeks troubleshooting this) I am less hopeful that the abseil migration. It might require more thinking |
|
regro-cf-autotick-bot
deleted the
rebuild-jpeg_to_libjpeg_turbo-0-3_h5ee88f
branch
Build checklist
It was decided that absl and grpc migration are out of scope here.
This PR has been triggered in an effort to update jpeg_to_libjpeg_turbo.
Notes and instructions for merging this PR:
Please note that if you close this PR we presume that the feedstock has been rebuilt, so if you are going to perform the rebuild yourself don't close this PR until the your rebuild has been merged.
If this PR was opened in error or needs to be updated please add the
bot-rerunlabel 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 botin a PR comment to have theconda-forge-adminadd 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. Feel free to drop us a line if there are any issues! This PR was generated by https://github.com/regro/cf-scripts/actions/runs/4389141418, please use this URL for debugging.