bug: Barcode-Scanner: Ionic apps using this package wont build for simulators in Xcode on arm64 Architecture (Macs with m-Series CPUS)

Plugin(s)

[X] Barcode Scanning
[ ] Face Detection
[ ] Face Mesh Detection
[ ] Selfie Segmentation
[ ] Translation

Did you test the latest version?

[X] I use the latest version

Platform(s)

[ ] Android
[X] iOS
[ ] Web

Current behavior
Ionic apps fail to build for simulator in Xcode on Macs using Apples new m-Series CPUs if its incorporating (@capacitor-mlkit/barcode-scanning). (Only tested with macOS Sonoma and Xcode 15)
After implementing the barcode scanner plugin (@capacitor-mlkit/barcode-scanning) and running npx cap sync, the Build Setting Excluded Architectures in Xcode is set to arm64  for Any iOS Simulator SDK automatically (see Screenshot).

Since newer Macs are running on this architecture and also try to build for an arm64 simulator, the build process fails, providing this error message:
/Users/timmoritzkuehle/Sirum Code/SirumApp_cap5/Code/ios/App/App/AppDelegate.swift:2:8 Could not find module 'Capacitor' for target 'x86_64-apple-ios-simulator'; found: arm64-apple-ios-simulator, at: /Users/timmoritzkuehle/Library/Developer/Xcode/DerivedData/App-ednjbqvwcfwlcbgrebswvcdqcmqf/Build/Products/Debug-iphonesimulator/Capacitor/Capacitor.framework/Modules/Capacitor.swiftmodule

By turning the build setting Build For Active Architecture Only you get two different error messages:
Framework 'Pods_App' not found and Linker command failed with exit code 1 (use -v to see invocation)

Currently the only workaround is to run a simulator using apples Rosetta translation layer. This harms performance and introduces a whole new layer potential system related build errors.
Expected behavior
It would be great if barcode scanning would support arm64 architectures natively.
Reproduction
https://github.com/timmkuehle/capacitor-mlkit-barcode-scanning-test
Steps to reproduce
On a Mac with an m-Series CPU:

Create a new ionic project ìonic start
Add the ios folder ``ìonic cap add ios```
Open it in Xcode, start the Simulator and see the build succeed
Implement (@capacitor-mlkit/barcode-scanning)
Sync new modules npx cap sync
Open the app in Xcode again
Notice the new setting for Excluded Architectures mentioned above
Try to run the simulator again and see the build fail

Other information
@AntonGrafton reported this problem in #85. However, it seems that the discussion on that one never got down to the point, where the system architecture was discovered to be causing the issue.
Google has a guide on migrating their MLKit pods for iOS to arm64 Systems. You can find it here. Sadly my pitiful knowledge about capacitor plugin development won't even suffice to tell if this is helpful or not. Sorry for that. 😅
Capacitor doctor
💊   Capacitor Doctor  💊
Latest Dependencies:
@capacitor/cli: 5.5.1
@capacitor/core: 5.5.1
@capacitor/android: 5.5.1
@capacitor/ios: 5.5.1
Installed Dependencies:
@capacitor/cli: 5.5.1
@capacitor/core: 5.5.1
@capacitor/android: 5.5.1
@capacitor/ios: 5.5.1
[success] iOS looking great! 👌
[success] Android looking great! 👌
Before submitting

[X] I understand that incomplete issues (e.g. without reproduction) are closed.

Thank you for your request!
First of all: You can definitely use this project with an M1 Mac and without Rosetta.
Have you tried the fix I mentioned in https://github.com/capawesome-team/capacitor-mlkit/issues/85#issuecomment-1759807052? I can't find it in your reproduction.

Google has a guide on migrating their MLKit pods for iOS to arm64 Systems.

We already use the up-to-date ML Kit iOS cocoapods, see: https://github.com/capawesome-team/capacitor-mlkit/blob/ca9dc947aa5859ddb45cc9805ee5b82936587c53/packages/barcode-scanning/ios/Podfile#L12

Hey. Thanks for your quick  reply!

Have you tried the fix I mentioned in https://github.com/capawesome-team/capacitor-mlkit/issues/85#issuecomment-1759807052? I can't find it in your reproduction.
This works. Sorry for the oversight! I misread the comment and thought this would fix builds on physical devices only.
Just out of curiosity: Do you know why adding these lines to the Podfile does something different than setting Build For Active Architecture Only to No in Xcode? 🤔

We already use the up-to-date ML Kit iOS cocoapods, see:
Sorry, my knowledge in native capacitor plugin development is so sparse that I couldn't even tell, if the link would be of any help. Just stumbled upon during my research.

PS: Please don't get me wrong. I wanted to be precise and helpful in my PR. Sorry, if I came across a little rude in trying do so so. I really didn't mean to!

Just out of curiosity: Do you know why adding these lines to the Podfile does something different than setting Build For Active Architecture Only to No in Xcode? 🤔

You can also do this via XCode, but you have probably configured the App Project and not the Pod Project. This configuration is required by the pods. The code in the pod file ensures that this configuration is restored after each pod installation.

Sorry, my knowledge in native capacitor plugin development is so sparse that I couldn't even tell, if the link would be of any help. Just stumbled upon during my research.

No problem at all! I appreciate any interest in my projects. I am closing this issue. Let me know if you have any other questions.


Improve Security for Docker execution within our make targets

Description
We're utilizing docker heavily within our make targets. This allows us to reduce the dependencies for our contributors heavily.
Furthermore, we're using the docker images within our GitHub Actions, and therefore we might expose critical information to the execution of those docker images.
Problem
Those docker images could be compromised and configured to share information about our build and environment. (maybe even our secrets - I have not tested this). This could be a security problem for local development and a risk for our execution with Automation pipelines.
Solution
We could limit all our util docker images to not having a network. This way, they can't share the data even if the docker images are compromised. This can be achieved by adding --network none to our executions.
// Shoutout to @tobijdc - thanks for sharing this information :)

Be aware, some of the utility images we're using need network access (for example HUGO)

I can take this up! All I need to do is add the --network none flag in the docker image executions in the Makefile. Some images require network access, so I must take care of that. Is this right?

we completely missed this. @rakshitgondwal do you still wanna work on this?

Hi @thisthat could you please assign this issue to me
cc @RealAnna

Thanks to the work of @geoffrey1330, we discovered the following:

at compile time, we're downloading dependencies in our docker images. We cannot rely on caching because if we add a new one or bump a dependency, it won't be able to download it
at runtime, we need to expose the network because we need to communicate with the Kube API

Closing the issue


Provide s2r or r2s availability in the GET /languages response

Would be useful for building interfaces to know what scripts had s2r, r2s or both capability in the languages response.

If you need this information in a pinch, you can use the /table/<lang> endpoint and check the JSON for the presence of the script_to_roman and/or roman_to_script sections. But I agree that this would be a useful shortcut to add to the languages endpoint.

This is being tackled as part of #104, which is a pretty large commit that will take some time, but it's in the works.

Fixed in #130.


document all options

Please add documentation for options like resultsDirectory and codeCoverageTool, having those would have saved me half a day of troubleshooting

Document Details
⚠ Do not edit this section. It is required for docs.microsoft.com ➟ GitHub issue linking.

ID: c6ac4ff4-9839-6a6d-8d20-a25084d221ef
Version Independent ID: bd09f139-8e69-8ea1-6671-b7bba8e17c23
Content: Publish Code Coverage Results task - Azure Pipelines
Content Source: docs/pipelines/tasks/test/publish-code-coverage-results.md
Product: devops
Technology: devops-cicd-tasks
GitHub Login: @shashban
Microsoft Alias: shashban

Thanks for letting us know. This issue is fixed in our new task reference, which is generated using the task source code and includes all task inputs, including any aliases here:
https://learn.microsoft.com/en-us/azure/devops/pipelines/tasks/reference/publish-code-coverage-results-v1?view=azure-pipelines
Please check it out and let us know what you think. Thank you.


flying redstone

For some reason, on both single and server, when I sift dust the Redstone goes flying. Everything else comes to me. I am 1 version old, I haven't updated to the barrel fix yet. Normally this wouldn't be a big issue, but it keeps flying into the void.

I'm not sure if it's related, but the sieving recipes don't show in JEI anymore either. They were working, then I added harvestcraft and after rebooting the server they vanished.

This looks like a dup of #93, which I saw in early SF3 releases, but appears to be fixed in at least the version I'm running (0.1.17).

This is still an issue for me while running the latest Sky Factory 3 pack (3.0.13), which (at this time) is using Ex Nihilo Adscensio 0.1.20


fixes issue #278

senate urls prefer the "www." and many hostnames will not redirect to canonical name w/ the www.
--timball

:+1:

I'm not sure it makes sense to update the historical webpage URLs in legislators-current.yaml. Otherwise +1.

Mmmm, good catch. In fact, it's better not to, since their only real value is showing what the URL was at that time. So retroactively updating them is all (though perhaps minor) downside.
@timball, are any of these updates to current terms? If so, can you update the PR to limit it to just current terms?

the frak are you two talking about ? this is to committees-current.yaml . so ... currently the senate needs www. in the urls . merge this . pedantic whose-a-whats-itz . did not touch any of the "historical" because honestly don't even understand the need for historical thingies to exist . that's why we use git right ? track file changes and evolutions . buttons . magnets . balls .
--timball

oh and another things IF the historic files DIDN'T contain the www. then those senate urls would be WRONG . so yeah . they frakking need it .
--timball

Talkin' 'bout legislators-current.yaml.

OH! this about the "1995" comment . yes . that was irony . used it to reference the prince song "party like it's 1999" . but in web terms , www. feels 1995 to me . regardless all my statements still stand . if the purpose of this repo is to have accurate data then all senate urls need the www.
--timball

or maybe my menendez pull .. yeah his thing needs www. too otherwise it's wrong . don't know . don't care . this is what i get for trying to help .

@timball, we've asked lots of people to edit their PRs before merging, it's a normal thing.
The non-current term info for Menendez should keep the (possibly broken) URLs that we logged for them at the time. I'll submit a PR to your PR on your repo, which you can merge and then we'll merge this one.

it's dumb to hold onto inaccurate and poorly verified bad data . there was never a time that a bare "menendez.senate.gov" worked . and in the weird chance that it did it would have redirected to the www. do whatever you're gonna do but it's dumb . either way merge the other things because accurate is what i'm going for .
my suspicion is that whomever put that data in there had the hipster www. angst . and just didn't want to see www. dirty their beautifully broken data . that person is bad and should be spanked . this is about accurate data , not beautiful data .
PAX PER IMPERIUM
--timball

I filed https://github.com/timball/congress-legislators/pull/1 for you to merge, @timball, which will update this PR in place and clear it for our merge.

Thanks for accepting the PR, and for the fixes!

My patience for nonsense ran out. I've locked the thread. Point taken. In the future, when blaming anonymous people, it's worthwhile to run a git blame and look up why the change was made in the first place. (In this case, the Menendez URLs date back to my initial commit to this repository.)


Create a renderer for Elastic Common Schema (ECS)

Create an implementation of RenderString that generates JSON compatible with Elastic Common Schema for ease of shipping to ELK implementations.

Guess I'll grab it
Could you assign the issue pls?

@mjstrasser, this issue was implemented in elkSender.kt and SendElk.kt, wasn't it?

@Pihanya Yes, I did the rendering part in RenderEcs.kt.
I tried to implement sending to a local ELK stack over HTTP but couldn’t get it to ingest messages directly (i.e. not using Logstash or Beats). I found the whole ELK setup bewilderingly complex compared to Seq and Splunk.


Prevent CP modification after round end

When a game ends, prevent CP's from gaining/losing health.

Implemented. Will close ticket when released.


fix: dooit package

Description of changes
Fix: Dooit's dep textual

Things done

Built on platform(s)

[x] x86_64-linux
[ ] aarch64-linux
[x] x86_64-darwin
[ ] aarch64-darwin

For non-Linux: Is sandboxing enabled in nix.conf? (See Nix manual)

[ ] sandbox = relaxed
[x] sandbox = true

[ ] Tested, as applicable:

NixOS test(s) (look inside nixos/tests)
and/or package tests
or, for functions and "core" functionality, tests in lib/tests or pkgs/test
made sure NixOS tests are linked to the relevant packages

[x] Tested compilation of all packages that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review rev HEAD". Note: all changes have to be committed, also see nixpkgs-review usage
[x] Tested basic functionality of all binary files (usually in ./result/bin/)
24.11 Release Notes (or backporting 23.11 and 24.05 Release notes)

[ ] (Package updates) Added a release notes entry if the change is major or breaking
[ ] (Module updates) Added a release notes entry if the change is significant
[ ] (Module addition) Added a release notes entry if adding a new NixOS module

[x] Fits CONTRIBUTING.md.

Add a :+1: reaction to pull requests you find important.

Can you reword the commit, please. dooit: fix textual version

Running nixpkgs-review now, since it's your application I'll trust the version change fixes the behavior to your expectation.

Hmmm... I did the changes you mentioned and its still not building. Something with version, I'll check again. Sorry for the trouble :(

Alright, kicking off a review. Hopefully everything works, thanks for taking this on!

Alright. Its fine now. Thanks a lot for your time! much appreciated

nixpkgs-review result
Generated using nixpkgs-review.
Command: nixpkgs-review pr 345228

x86_64-linux

:white_check_mark: 2 packages built:

dooit
dooit.dist

x86_64-darwin

:white_check_mark: 2 packages built:

dooit
dooit.dist

aarch64-darwin

:white_check_mark: 2 packages built:

dooit
dooit.dist

Looks like dooit is broken on master now from a textual update. This fixes it not even running, too.


Major stability, speed improvements for TI-86

I switched the program from using digitalRead()/digitalWrite() to directly manipulating the microcontroller's registers using the memory-mapped variables PORTC, PINC, and DDRC provided by AVR libc. It now works much more reliably: I was able to transfer rterm86 (1 kilobyte), DataMate (3 kilobytes), and DATACOLLC (5 kilobytes) with no problems using TILP, something that was impossible before. While debugging an unrelated problem, I switched from port D (pins 0–7) to the analog bank, port C.
Anyway, I no longer get any timeout errors from TILP and the serial buffer never fills up, so I think my changes are important. :)

@DSchndr any comments, results from testing? I have tested this new implementation with an Arduino Uno R3 and my sister's TI-86 with the following situations:

TI Connect under Windows 10
TI GRAPH-LINK 86 under Windows 3.1, with serial port passthrough using DOSBox on Linux,
TILP II on Linux
TILP II on Windows

In all cases it worked flawlessly. My LabPro also worked with TI-Connect on Windows, though there wasn't much I could test (I didn't want to risk a firmware update using this thing).
If you have no objections, would you mind merging my pull request? I think it's better for everyone to have a canonical repository rather than everyone having separate forks.

Well unfortunatly i can't test this because i have no arduino + 2.5mm audio jack lying around (only pro micro with jack soldered on pin 6 and 15 and i'm too lazy to change that :P )
I will merge it of course, but some documentation in the readme about changing the pins wouldn't be too bad.
Also thanks for improving this project.


Pull requests for private repositories aren't showing up in the spec evolution.

It appears for spec files kept in private repositories, Spectacular isn't picking up any pull requests against those files.
It is likely a missing permissions problem with the GitHub app resulting in the GraphQL query not returning any PR information.

I've done a test and it is clear that GitHub app needs read permissions on the Pull Request repository resource to be able to get PR information for private repos.

It's also clear that we currently have a bug with PRs being cached indefinitely. The PullRequestRepository component needs to be changed to have a lifetime of just the request scope.

This issue was fixed by #29 and #30.


[libs/movex-server] Disable eslint rule for run file: @typescript-eslint/no-var-requires

Where
libs/movex-server/src/bin/run.ts
What
Add the following code /* eslint @typescript-eslint/no-var-requires: 0 */ at the beginning of the file
Why
This is a special file and imports need to written with require
Definition of success

[ ] running npx nx lint movex-server --quiet doesn't find errors in libs/movex-server/src/bin/run.ts file

I would like to work on this. Can you assign it to me?

Hey @GabrielCTroia, this has already been fixed by @techemmy

Oh, thank you for bringing it up @riteshmukim! Is there any other issue you'd like to work on?

Closed in #108

I would love to work on other issues. Let me know which one should I pick

You can always check the "Good First Issues with no Assignees" category 😁https://github.com/movesthatmatter/movex/issues?q=is%3Aissue+is%3Aopen+no%3Aassignee+label%3A%22good+first+issue%22

I'm also going to create a few more shortly! 🙌


Add nav tile and icon tile components

What does this PR do?
Attempts to parse componentvariant properties serverside. I just wanted to get this code out there. It may not be the right approach.

this functionality was added in a more recent PR.


Prevent accidental Rocky to Rocky migration

I had a error running migrate2rocky due to a RPM conflict I needed to resolve before distro-sync would run.  After fixing the RPM issue I naively ran the migrate2rocky script again.  But since my system was already considered Rocky at that point, the script got confused and ended up deleting some RPMs I needed before it failed.
Log from first attempt, failed distro-sync due to RPM conflict:   https://pastebin.com/hg1KSbRL
Log from second attempt, with Rocky->Rocky failure:   https://pastebin.com/mxsi1PVf

Yes, you are exactly right on all counts.  I imagine I'm not the only one who will impulsively pull the trigger on migrate before doing their due diligence, so some safeguards would surely help someone else.   For reference here, a manual download of the missing rocky-* RPMS, followed by the distro-sync and fix_efi steps from the migrate2rocky script fixed my installation.

Just something else I thought of, in addition to that an option that basically does the manual install of the rpms, distro sync and fix_efi steps something like, "fix failed migration" would help for those who do end up, for whatever reason, with a partial migration.

The first attempt looks to me like it would have failed a dnf update ... So the solution here is to have the script attempt to run dnf update before it starts the migration

This is done now with PR#58

The second attempt is, as you say, because you tried to run migrate2rocky a second time after the first attept was partially successful. This can easily be solved by checking the os-release file to see if the current system is already rockylinux and bailing if it is.

Done with PR #64

Allowing the script to pick up where it left off would be good... like it drops markers in a .dot file to say which steps it completed.

See https://github.com/rocky-linux/rocky-tools/issues/69#issuecomment-876450537

Wherever you got libnice from it wasn't CentOS, then, the latest version in CentOS 8 is 0.1.14.  Where did you get libnice from?

Here: https://koji.fedoraproject.org/koji/buildinfo?buildID=1657236
But the source of it really isn't the point. The point is that this situation broke the update. It could be any package that depends on a higher version of some package that isn't available from the repositories.


feat(analytics): Analytics refactor

What type of PR is this?
Feature
What this PR does / why we need it:
Use RecommendationMission to track recommendation's lifecycle.
Add docs for Analytics and Recommendation.
Which issue(s) this PR fixes:

Fixes #
Special notes for your reviewer:

LGTM


How to retrieve kubeadmin password?

How to retrieve kubeadmin password?
If this is already available using crc cli please let me know, I was not able to find a way I expected sometingin crc config or crc kubeadmin to give me the initial password that prints when running crc start
INFO To login as an admin, run 'oc login -u kubeadmin -p jh3kL-Te6cD-BKDG7-3rvSu https://api.crc.testing:6443'

crc console --credentials as described on https://code-ready.github.io/crc/#accessing-the-openshift-web-console_gsg

@gorkem your telling me to RTFM? 😄

I'm looking for the credentials so I can oc login never cross my mind to look under console
Can we have crc login to log me in. or crc credentials and print what crc console --credentials prints?

TIL
cat ~/.crc/bin/oc-credentials
#!/usr/bin/env sh
crc console --credentials

oc credentials
To login as a regular user, run 'oc login -u developer -p developer https://api.crc.testing:6443'.
To login as an admin, run 'oc login -u kubeadmin -p jh3kL-Te6cD-BKDG7-3rvSu https://api.crc.testing:6443'
``

initial password

An initial password can be provided as this is done of the image genration. If we add logic for this, the start procedure would take longer. Would that be acceptable?

I'm looking for the credentials so I can oc login never cross my mind to look under console

@gbraad This sentence is the actual issue. I have seen multiple people fall into this, last time we have added the docs but the command is not intuitive and docs are not a replacement for good UX. I think  --credentials flag needs to move to its own command.

I think --credentials flag needs to move to its own command.

And I think we should avoid having the user to look for this in the first place. Either make this static, but this led to security concerns, or make this VERY abvious each time CRC is used. Like enriching the start output and oc-env:
$ eval `crc oc-env`
Note: the kubeadmin password is: "Ge*$#((@d". This is also stored as $CRC_KUBEADMIN_PASSWORD

and also stored in an environment variable for use.
The problem does not get solved by just a command, as when the system tray flow is considered, we would also have to deal with this is in a reasonable fashion. The use of developer/developer is OK, why not kubeadmin/kubeadmin to avoid all of this and rely on a mental model.

And I think we should avoid having the user to look for this in the first place.

We shoulf take advantage of the kubecontext. All k8s related tools use kubecontext.  Setting the kubecontext  #1216 should help with most cases, except for actually visiting the console

@gbraad Can you explain why “crc credentials” increase the time ? Is the same command as “crc console —credentials”
It will take the same amount of time if “crc credentials” calls “crc console —credentials”

Can you explain why “crc credentials” increase the time ?

That is not what I implied:

An initial password can not be provided as this is done of the image genration. If we add logic for this, the start procedure would take longer.

as a means to provide crc config kubeadmin-password to reconfigure this password.

@gbraad
Thanks for the explanation.
I don’t want to reconfigure the kubeadmin password my requirement is just easy to find and read only the current kubeadmin password.
I agree 💯 that if the password is static kubeadmin/kubeadmin that would be even a better solution.

this should be part of the image generation, as 'updating'/'changing' the secrets will considerably influence the startup time: https://docs.openshift.com/container-platform/3.7/dev_guide/secrets.html#secrets-and-the-pod-lifecycle as the pods that use the secret needs to be deleted and recreated.

What remains to be done here? the OP 's issue is fixed as he's able to find the command, do we want to add a top level command to make it more discoverable or add static password for kubeadmin too?

I would like to see something done to be more discoverable
Today I type "crc console" and it opens the browser and would never guess that "console" has more flags to get the password.
What about a top level command to alias to "crc console --password" ?
Not sure where is best
"crc config get password"
"crc password"

We again discussed this during one of the meeting but no conclusion, we should able to decide soon and fix it.

If we end up implementing a command like crc credentials  I think we should print a message about the command at the end of crc start in there we print out the credentilas to oc login but we can add something like to retrieve the kubeadmin credentias use the command crc credentials

I was brought to this issue for a similar concern. For those that may be interested in a way to retrieve the crc's oc login command for the kubeadmin user can use something similar to this (tested on MacOS 10.14.6 and CRC 1.20.0+ef3f80d):
crc console --credentials | grep kubeadmin | awk -F"'" '{print $2}'

@taylormgeorge91
the main problem is usability and discoverable
No one is going to use “crc console help” to find the CLI credentials for kubeadmin
but there is better chance that people use “crc help” and find a toplevel command to get kubeadmin password even if it’s one is static
having a command like “crc kubeadmin” that just prints is a good start and advertise the command at the end of “crc start”

@taylormgeorge91
the main problem is usability and discoverable
No one is going to use “crc console help” to find the CLI credentials for kubeadmin
but there is better chance that people use “crc help” and find a toplevel command to get kubeadmin password even if it’s one is static
having a command like “crc kubeadmin” that just prints is a good start and advertise the command at the end of “crc start”

+1 with the idea of a command crc credentials. This is what I typed intuitively before googling and landing on this page.

+1 with a top-level command; I certainly was not expecting to find this under crc console when I went to look for it (because I'm training myself to do most of my work using 'oc', and declarative styles of deployment (oc apply -k)
I would be against static configuration of kubeadmin password. Partly because it reinforces sloppy security awareness which is highly dangerous in a K8S environment, and CRC is useful from a admin/security training perspective. A user's CRC experience should therefore be very similar to a production cluster. It's good that TCP/6443 is only reachable on loopback (I'm in vsock mode, so not sure if that is always the case).
On a similar manner, I see that the Kubernetes contexts are being used, but I take it that only keeps the token (which presumably expires) and not the password, as I find I have to 'oc login -u ...' about once a day.

This has moved to the end of the start command as a summary. When the command is rerun, the summary will be shown again.
From the telemetry we can already see people have adopted to use this pattern. We will keep console --credentials around for the -ojson option

For usability it'd be great to:

make this more obvious in the crc command's help output; and
make this more search-discoverable in the docs

because
$ crc --help

...

Available Commands:
  ...
  console     Open the OpenShift Web Console in the default browser
  ...

is really non-obvious.


doesnt work on hypixel

i tested it on singleplayuer and it works and i dont understand why

This is because Hypixel spawns in the explosion particles themselves, instead of actually creating an explosion. There's nothing I can realistically do about this.

ah ok, ty


Failing to compile with harfbuzz 4.4.1

I'm trying to install SDL_ttf on OSX Monterey from the repo. I created a symlink in external pointing to my harfbuzz source, and copied the .deps directory over.
It compiles fine until it hits this:
make: *** No rule to make target external/harfbuzz/src/hb-ms-feature-ranges.cc', needed by external/harfbuzz/src/libSDL2_ttf_la-hb-ms-feature-ranges.lo'.  Stop.
Has something been deprecated? I'm not seeing that file anywhere in the harfbuzz source, only a header.

The vendored harfbuzz/freetype libraries in external are pinned to a single version, and cannot be changed easily.
If you really need to use a specific freetype/harfbuzz library, you need to build those libraries outside of SDL_ttf, and use configure options to link to it.
...
Optional Features:
...
  --enable-harfbuzz       Enable HarfBuzz [default=yes]
  --enable-harfbuzz-builtin
                          Use included version of HarfBuzz [default=yes]
...

Some influential environment variables:
...
  PKG_CONFIG_PATH
              directories to add to pkg-config's search path
...
  HB_CFLAGS   C compiler flags for HB, overriding pkg-config
  HB_LIBS     linker flags for HB, overriding pkg-config

So you need to build and install harfbuzz to a directory (e.g. /tmp/harfbuzz_install),
and run SDL_ttf as e.g.
PKG_CONFIG_PATH=/tmp/harfbuzz_install/lib/pkgconfig /path/to/sdl_ttf/configure --enable-harfbuzz --enable-harfbuzz-builtin=no

(untested)
PS: We're bumping harfbuzz to the latest in https://github.com/libsdl-org/SDL_ttf/pull/306


chore: dependabot updates batch

/deploy

You can access the deployment of this PR at https://renku-ci-nb-724.dev.renku.ch