HADOOP-19222. Switch yum repo baseurl due to CentOS 7 sunset

Description of PR
Similar to HADOOP-18151 (which handled sunset for CentOS 8), CentOS 7 reached EOL on July 1, 2024
How was this patch tested?
This change will trigger Yetus to run the native library building.
Without this change, the CentOS 7 CI fails with:
[2024-07-01T13:07:41.573Z] #9 [ 5/16] RUN yum update -y     && yum groupinstall -y "Development Tools"     && yum install -y         centos-release-scl         python3     && yum install -y $(pkg-resolver/resolve.py centos:7)
[2024-07-01T13:07:42.135Z] #9 0.452 Loaded plugins: fastestmirror, ovl
[2024-07-01T13:07:42.135Z] #9 0.570 Determining fastest mirrors
[2024-07-01T13:07:42.696Z] #9 0.824 Could not retrieve mirrorlist http://mirrorlist.centos.org/?release=7&arch=x86_64&repo=os&infra=container error was
[2024-07-01T13:07:42.696Z] #9 0.824 14: curl#6 - "Could not resolve host: mirrorlist.centos.org; Unknown error"
[2024-07-01T13:07:42.696Z] #9 0.826
[2024-07-01T13:07:42.696Z] #9 0.826
[2024-07-01T13:07:42.696Z] #9 0.826  One of the configured repositories failed (Unknown),
[2024-07-01T13:07:42.696Z] #9 0.826  and yum doesn't have enough cached data to continue. At this point the only
[2024-07-01T13:07:42.696Z] #9 0.826  safe thing yum can do is fail. There are a few ways to work "fix" this:
[2024-07-01T13:07:42.696Z] #9 0.826
[2024-07-01T13:07:42.696Z] #9 0.826      1. Contact the upstream for the repository and get them to fix the problem.
[2024-07-01T13:07:42.696Z] #9 0.826
[2024-07-01T13:07:42.696Z] #9 0.826      2. Reconfigure the baseurl/etc. for the repository, to point to a working
[2024-07-01T13:07:42.696Z] #9 0.826         upstream. This is most often useful if you are using a newer
[2024-07-01T13:07:42.696Z] #9 0.826         distribution release than is supported by the repository (and the
[2024-07-01T13:07:42.696Z] #9 0.826         packages for the previous distribution release still work).
[2024-07-01T13:07:42.696Z] #9 0.826
[2024-07-01T13:07:42.696Z] #9 0.826      3. Run the command with the repository temporarily disabled
[2024-07-01T13:07:42.696Z] #9 0.826             yum --disablerepo=<repoid> ...
[2024-07-01T13:07:42.696Z] #9 0.826
[2024-07-01T13:07:42.696Z] #9 0.826      4. Disable the repository permanently, so yum won't use it by default. Yum
[2024-07-01T13:07:42.696Z] #9 0.826         will then just ignore the repository until you permanently enable it
[2024-07-01T13:07:42.696Z] #9 0.826         again or use --enablerepo for temporary usage:
[2024-07-01T13:07:42.696Z] #9 0.826
[2024-07-01T13:07:42.696Z] #9 0.826             yum-config-manager --disable <repoid>
[2024-07-01T13:07:42.696Z] #9 0.826         or
[2024-07-01T13:07:42.696Z] #9 0.826             subscription-manager repos --disable=<repoid>
[2024-07-01T13:07:42.696Z] #9 0.826
[2024-07-01T13:07:42.696Z] #9 0.826      5. Configure the failing repository to be skipped, if it is unavailable.
[2024-07-01T13:07:42.696Z] #9 0.826         Note that yum will try to contact the repo. when it runs most commands,
[2024-07-01T13:07:42.696Z] #9 0.826         so will have to try and fail each time (and thus. yum will be be much
[2024-07-01T13:07:42.696Z] #9 0.826         slower). If it is a very temporary problem though, this is often a nice
[2024-07-01T13:07:42.696Z] #9 0.826         compromise:
[2024-07-01T13:07:42.696Z] #9 0.826
[2024-07-01T13:07:42.696Z] #9 0.826             yum-config-manager --save --setopt=<repoid>.skip_if_unavailable=true
[2024-07-01T13:07:42.696Z] #9 0.826
[2024-07-01T13:07:42.696Z] #9 0.826 Cannot find a valid baseurl for repo: base/7/x86_64
[2024-07-01T13:07:43.258Z] #9 ERROR: process "/bin/bash -o pipefail -c yum update -y     && yum groupinstall -y \"Development Tools\"     && yum install -y         centos-release-scl         python3     && yum install -y $(pkg-resolver/resolve.py centos:7)" did not complete successfully: exit code: 1
[2024-07-01T13:07:43.258Z] ------
[2024-07-01T13:07:43.258Z]  > [ 5/16] RUN yum update -y     && yum groupinstall -y "Development Tools"     && yum install -y         centos-release-scl         python3     && yum install -y $(pkg-resolver/resolve.py centos:7):
[2024-07-01T13:07:43.258Z] 0.826
[2024-07-01T13:07:43.258Z] 0.826      5. Configure the failing repository to be skipped, if it is unavailable.
[2024-07-01T13:07:43.258Z] 0.826         Note that yum will try to contact the repo. when it runs most commands,
[2024-07-01T13:07:43.259Z] 0.826         so will have to try and fail each time (and thus. yum will be be much
[2024-07-01T13:07:43.259Z] 0.826         slower). If it is a very temporary problem though, this is often a nice
[2024-07-01T13:07:43.259Z] 0.826         compromise:
[2024-07-01T13:07:43.259Z] 0.826
[2024-07-01T13:07:43.259Z] 0.826             yum-config-manager --save --setopt=<repoid>.skip_if_unavailable=true
[2024-07-01T13:07:43.259Z] 0.826
[2024-07-01T13:07:43.259Z] 0.826 Cannot find a valid baseurl for repo: base/7/x86_64
[2024-07-01T13:07:43.259Z] ------

For code changes:

[x] Does the title or this PR starts with the corresponding JIRA issue id (e.g. 'HADOOP-17799. Your PR title ...')?
[ ] Object storage: have the integration tests been executed and the endpoint declared according to the connector-specific documentation?
[ ] If adding new dependencies to the code, are these dependencies licensed in a way that is compatible for inclusion under ASF 2.0?
[ ] If applicable, have you updated the LICENSE, LICENSE-binary, NOTICE-binary files?

(!) A patch to the testing environment has been detected.
Re-executing against the patched versions to perform further tests.
The console is at https://ci-hadoop.apache.org/job/hadoop-multibranch/job/PR-6932/1/console in case of problems.

ping @GauthamBanasandra @goiri @steveloughran

:broken_heart: -1 overall

Vote
Subsystem
Runtime
Logfile
Comment

+0 :ok:
reexec
22m 25s

Docker mode activated.

_ Prechecks _

+1 :green_heart:
dupname
0m  0s

No case conflicting files found.

+0 :ok:
codespell
0m  0s

codespell was not available.

+0 :ok:
detsecrets
0m  0s

detect-secrets was not available.

+0 :ok:
hadolint
0m  0s

hadolint was not available.

+0 :ok:
shellcheck
0m  0s

Shellcheck was not available.

+0 :ok:
shelldocs
0m  0s

Shelldocs was not available.

+1 :green_heart:
@author
0m  0s

The patch does not contain any @author tags.

-1 :x:
test4tests
0m  0s

The patch doesn't appear to include any new or modified tests. Please justify why no new tests are needed for this patch. Also please list what manual steps were performed to verify this patch.

_ trunk Compile Tests _

+0 :ok:
mvndep
14m 14s

Maven dependency ordering for branch

-1 :x:
mvninstall
25m 48s
/branch-mvninstall-root.txt
root in trunk failed.

+1 :green_heart:
mvnsite
0m  0s

trunk passed

-1 :x:
shadedclient
43m 44s

branch has errors when building and testing our client artifacts.

_ Patch Compile Tests _

+0 :ok:
mvndep
0m  8s

Maven dependency ordering for patch

+1 :green_heart:
mvninstall
0m  0s

the patch passed

+1 :green_heart:
blanks
0m  1s

The patch has no blanks issues.

+1 :green_heart:
mvnsite
0m  0s

the patch passed

+1 :green_heart:
shadedclient
0m 45s

patch has no errors when building and testing our client artifacts.

_ Other Tests _

+0 :ok:
asflicense
0m 23s

ASF License check generated no output?

68m 43s

Subsystem
Report/Notes

Docker
ClientAPI=1.46 ServerAPI=1.46 base: https://ci-hadoop.apache.org/job/hadoop-multibranch/job/PR-6932/1/artifact/out/Dockerfile

GITHUB PR
https://github.com/apache/hadoop/pull/6932

Optional Tests
dupname asflicense codespell detsecrets hadolint shellcheck shelldocs mvnsite unit

uname
Linux ef7335c239a8 5.15.0-106-generic #116-Ubuntu SMP Wed Apr 17 09:17:56 UTC 2024 x86_64 x86_64 x86_64 GNU/Linux

Build tool
maven

Personality
dev-support/bin/hadoop.sh

git revision
trunk / 1f8517f51b8382a503ba6197e694365fb8733ebd

Test Results
https://ci-hadoop.apache.org/job/hadoop-multibranch/job/PR-6932/1/testReport/

Max. process+thread count
77 (vs. ulimit of 5500)

modules
C:  U:

Console output
https://ci-hadoop.apache.org/job/hadoop-multibranch/job/PR-6932/1/console

versions
git=2.9.5 maven=3.6.3

Powered by
Apache Yetus 0.14.0 https://yetus.apache.org

This message was automatically generated.

investigation:
Yetus failed to create user "jenkins" on building run-specific image yetus/hadoop:tp-11600
https://ci-hadoop.apache.org/blue/rest/organizations/jenkins/pipelines/hadoop-multibranch/branches/PR-6932/runs/1/nodes/56/log/
[2024-07-09T12:35:10.546Z] #8 [ 4/10] RUN if [ "998" != -1 ]; then (groupadd --non-unique --gid 998 dockersock && adduser "jenkins" dockersock ) || true; fi
[2024-07-09T12:35:10.546Z] #8 0.359 Usage: adduser [options] LOGIN
[2024-07-09T12:35:10.546Z] #8 0.359        adduser -D
[2024-07-09T12:35:10.546Z] #8 0.359        adduser -D [options]
[2024-07-09T12:35:10.546Z] #8 0.359
[2024-07-09T12:35:10.546Z] #8 0.359 Options:
[2024-07-09T12:35:10.546Z] #8 0.359   -b, --base-dir BASE_DIR       base directory for the home directory of the
[2024-07-09T12:35:10.546Z] #8 0.359                                 new account
[2024-07-09T12:35:10.546Z] #8 0.359   -c, --comment COMMENT         GECOS field of the new account
[2024-07-09T12:35:10.546Z] #8 0.359   -d, --home-dir HOME_DIR       home directory of the new account
[2024-07-09T12:35:10.546Z] #8 0.359   -D, --defaults                print or change default useradd configuration
[2024-07-09T12:35:10.546Z] #8 0.359   -e, --expiredate EXPIRE_DATE  expiration date of the new account
[2024-07-09T12:35:10.546Z] #8 0.359   -f, --inactive INACTIVE       password inactivity period of the new account
[2024-07-09T12:35:10.546Z] #8 0.359   -g, --gid GROUP               name or ID of the primary group of the new
[2024-07-09T12:35:10.546Z] #8 0.359                                 account
[2024-07-09T12:35:10.546Z] #8 0.359   -G, --groups GROUPS           list of supplementary groups of the new
[2024-07-09T12:35:10.546Z] #8 0.359                                 account
[2024-07-09T12:35:10.546Z] #8 0.359   -h, --help                    display this help message and exit
[2024-07-09T12:35:10.546Z] #8 0.359   -k, --skel SKEL_DIR           use this alternative skeleton directory
[2024-07-09T12:35:10.546Z] #8 0.359   -K, --key KEY=VALUE           override /etc/login.defs defaults
[2024-07-09T12:35:10.546Z] #8 0.359   -l, --no-log-init             do not add the user to the lastlog and
[2024-07-09T12:35:10.546Z] #8 0.359                                 faillog databases
[2024-07-09T12:35:10.546Z] #8 0.359   -m, --create-home             create the user's home directory
[2024-07-09T12:35:10.546Z] #8 0.359   -M, --no-create-home          do not create the user's home directory
[2024-07-09T12:35:10.546Z] #8 0.359   -N, --no-user-group           do not create a group with the same name as
[2024-07-09T12:35:10.546Z] #8 0.359                                 the user
[2024-07-09T12:35:10.546Z] #8 0.359   -o, --non-unique              allow to create users with duplicate
[2024-07-09T12:35:10.546Z] #8 0.359                                 (non-unique) UID
[2024-07-09T12:35:10.546Z] #8 0.359   -p, --password PASSWORD       encrypted password of the new account
[2024-07-09T12:35:10.546Z] #8 0.359   -r, --system                  create a system account
[2024-07-09T12:35:10.546Z] #8 0.359   -R, --root CHROOT_DIR         directory to chroot into
[2024-07-09T12:35:10.546Z] #8 0.359   -P, --prefix PREFIX_DIR       prefix directory where are located the /etc/* files
[2024-07-09T12:35:10.546Z] #8 0.359   -s, --shell SHELL             login shell of the new account
[2024-07-09T12:35:10.546Z] #8 0.359   -u, --uid UID                 user ID of the new account
[2024-07-09T12:35:10.546Z] #8 0.359   -U, --user-group              create a group with the same name as the user
[2024-07-09T12:35:10.546Z] #8 0.359   -Z, --selinux-user SEUSER     use a specific SEUSER for the SELinux user mapping
[2024-07-09T12:35:10.546Z] #8 0.359
[2024-07-09T12:35:10.546Z] #8 DONE 0.4s

this should be a Yetus side issue, and I suppose it has been broken for a while ...
the corresponding code should be https://github.com/apache/yetus/blob/23ddb4e106785effb2e1154aed65329f722bfabe/precommit/src/main/shell/test-patch-docker/Dockerfile.patchspecific#L31
due to the incorrectly setup for user "jenkins", the PATH env is abnormal, then commands like pwd, bash become unavailable ...

I have less knowledge of Yetus, not sure how to fix and verify that.
For reviewers, this PR change is orthogonal to the Yetus issue, it fixes the CentOS 7 YUM repo resolving issues. I lean toward merging it first (though Yetus is not happy ...) and then fixing the Yetus issue later.

not my area of knowledge at all...can anyone else take a look at this?

@GauthamBanasandra Can you help take a look at this issue? Thank you very much!

(!) A patch to the testing environment has been detected.
Re-executing against the patched versions to perform further tests.
The console is at https://ci-hadoop.apache.org/job/hadoop-multibranch/job/PR-6932/2/console in case of problems.

(!) A patch to the testing environment has been detected.
Re-executing against the patched versions to perform further tests.
The console is at https://ci-hadoop.apache.org/job/hadoop-multibranch/job/PR-6932/3/console in case of problems.

(!) A patch to the testing environment has been detected.
Re-executing against the patched versions to perform further tests.
The console is at https://ci-hadoop.apache.org/job/hadoop-multibranch/job/PR-6932/4/console in case of problems.

:broken_heart: -1 overall

Vote
Subsystem
Runtime
Logfile
Comment

+0 :ok:
reexec
0m 23s

Docker mode activated.

_ Prechecks _

+1 :green_heart:
dupname
0m  0s

No case conflicting files found.

+0 :ok:
codespell
0m  0s

codespell was not available.

+0 :ok:
detsecrets
0m  0s

detect-secrets was not available.

+0 :ok:
hadolint
0m  0s

hadolint was not available.

+0 :ok:
shellcheck
0m  0s

Shellcheck was not available.

+0 :ok:
shelldocs
0m  0s

Shelldocs was not available.

+1 :green_heart:
@author
0m  0s

The patch does not contain any @author tags.

-1 :x:
test4tests
0m  0s

The patch doesn't appear to include any new or modified tests. Please justify why no new tests are needed for this patch. Also please list what manual steps were performed to verify this patch.

_ trunk Compile Tests _

+0 :ok:
mvndep
0m 20s

Maven dependency ordering for branch

-1 :x:
mvninstall
0m 22s
/branch-mvninstall-root.txt
root in trunk failed.

+1 :green_heart:
mvnsite
0m  0s

trunk passed

-1 :x:
shadedclient
1m  9s

branch has errors when building and testing our client artifacts.

_ Patch Compile Tests _

+0 :ok:
mvndep
0m 19s

Maven dependency ordering for patch

+1 :green_heart:
mvninstall
0m  0s

the patch passed

+1 :green_heart:
blanks
0m  0s

The patch has no blanks issues.

+1 :green_heart:
mvnsite
0m  0s

the patch passed

-1 :x:
shadedclient
0m 30s

patch has errors when building and testing our client artifacts.

_ Other Tests _

+0 :ok:
asflicense
0m 21s

ASF License check generated no output?

4m 10s

Subsystem
Report/Notes

Docker
ClientAPI=1.46 ServerAPI=1.46 base: https://ci-hadoop.apache.org/job/hadoop-multibranch/job/PR-6932/2/artifact/out/Dockerfile

GITHUB PR
https://github.com/apache/hadoop/pull/6932

Optional Tests
dupname asflicense codespell detsecrets hadolint shellcheck shelldocs mvnsite unit

uname
Linux b19e9b90f4b4 5.15.0-106-generic #116-Ubuntu SMP Wed Apr 17 09:17:56 UTC 2024 x86_64 x86_64 x86_64 GNU/Linux

Build tool
maven

Personality
dev-support/bin/hadoop.sh

git revision
trunk / 9122bef9ec27d8a75b79d3f107b48b1909cc0a20

Test Results
https://ci-hadoop.apache.org/job/hadoop-multibranch/job/PR-6932/2/testReport/

Max. process+thread count
46 (vs. ulimit of 5500)

modules
C:  U:

Console output
https://ci-hadoop.apache.org/job/hadoop-multibranch/job/PR-6932/2/console

versions
git=2.9.5 maven=3.6.3

Powered by
Apache Yetus 0.14.0 https://yetus.apache.org

This message was automatically generated.

:broken_heart: -1 overall

Vote
Subsystem
Runtime
Logfile
Comment

+0 :ok:
reexec
0m 19s

Docker mode activated.

_ Prechecks _

+1 :green_heart:
dupname
0m  0s

No case conflicting files found.

+0 :ok:
codespell
0m  0s

codespell was not available.

+0 :ok:
detsecrets
0m  0s

detect-secrets was not available.

+0 :ok:
hadolint
0m  0s

hadolint was not available.

+0 :ok:
shellcheck
0m  0s

Shellcheck was not available.

+0 :ok:
shelldocs
0m  0s

Shelldocs was not available.

+1 :green_heart:
@author
0m  0s

The patch does not contain any @author tags.

-1 :x:
test4tests
0m  0s

The patch doesn't appear to include any new or modified tests. Please justify why no new tests are needed for this patch. Also please list what manual steps were performed to verify this patch.

_ trunk Compile Tests _

+0 :ok:
mvndep
0m 18s

Maven dependency ordering for branch

-1 :x:
mvninstall
0m 21s
/branch-mvninstall-root.txt
root in trunk failed.

+1 :green_heart:
mvnsite
0m  0s

trunk passed

-1 :x:
shadedclient
1m 38s

branch has errors when building and testing our client artifacts.

_ Patch Compile Tests _

+0 :ok:
mvndep
0m 26s

Maven dependency ordering for patch

+1 :green_heart:
mvninstall
0m  0s

the patch passed

+1 :green_heart:
blanks
0m  0s

The patch has no blanks issues.

+1 :green_heart:
mvnsite
0m  0s

the patch passed

+1 :green_heart:
shadedclient
0m 45s

patch has no errors when building and testing our client artifacts.

_ Other Tests _

+0 :ok:
asflicense
0m 22s

ASF License check generated no output?

4m 59s

Subsystem
Report/Notes

Docker
ClientAPI=1.46 ServerAPI=1.46 base: https://ci-hadoop.apache.org/job/hadoop-multibranch/job/PR-6932/3/artifact/out/Dockerfile

GITHUB PR
https://github.com/apache/hadoop/pull/6932

Optional Tests
dupname asflicense codespell detsecrets hadolint shellcheck shelldocs mvnsite unit

uname
Linux e137bdb7f29d 5.15.0-106-generic #116-Ubuntu SMP Wed Apr 17 09:17:56 UTC 2024 x86_64 x86_64 x86_64 GNU/Linux

Build tool
maven

Personality
dev-support/bin/hadoop.sh

git revision
trunk / 9122bef9ec27d8a75b79d3f107b48b1909cc0a20

Test Results
https://ci-hadoop.apache.org/job/hadoop-multibranch/job/PR-6932/3/testReport/

Max. process+thread count
46 (vs. ulimit of 5500)

modules
C:  U:

Console output
https://ci-hadoop.apache.org/job/hadoop-multibranch/job/PR-6932/3/console

versions
git=2.9.5 maven=3.6.3

Powered by
Apache Yetus 0.14.0 https://yetus.apache.org

This message was automatically generated.

:broken_heart: -1 overall

Vote
Subsystem
Runtime
Logfile
Comment

+0 :ok:
reexec
33m 32s

Docker mode activated.

_ Prechecks _

+1 :green_heart:
dupname
0m  0s

No case conflicting files found.

+0 :ok:
codespell
0m  0s

codespell was not available.

+0 :ok:
detsecrets
0m  0s

detect-secrets was not available.

+0 :ok:
hadolint
0m  0s

hadolint was not available.

+0 :ok:
shellcheck
0m  0s

Shellcheck was not available.

+0 :ok:
shelldocs
0m  0s

Shelldocs was not available.

+1 :green_heart:
@author
0m  0s

The patch does not contain any @author tags.

-1 :x:
test4tests
0m  0s

The patch doesn't appear to include any new or modified tests. Please justify why no new tests are needed for this patch. Also please list what manual steps were performed to verify this patch.

_ trunk Compile Tests _

+0 :ok:
mvndep
14m 41s

Maven dependency ordering for branch

+1 :green_heart:
mvninstall
33m 14s

trunk passed

+1 :green_heart:
mvnsite
0m  0s

trunk passed

+1 :green_heart:
shadedclient
80m 38s

branch has no errors when building and testing our client artifacts.

_ Patch Compile Tests _

+0 :ok:
mvndep
0m 34s

Maven dependency ordering for patch

+1 :green_heart:
mvninstall
0m  0s

the patch passed

+1 :green_heart:
blanks
0m  0s

The patch has no blanks issues.

+1 :green_heart:
mvnsite
0m  0s

the patch passed

+1 :green_heart:
shadedclient
32m 12s

patch has no errors when building and testing our client artifacts.

_ Other Tests _

+1 :green_heart:
asflicense
0m 39s

The patch does not generate ASF License warnings.

149m 14s

Subsystem
Report/Notes

Docker
ClientAPI=1.46 ServerAPI=1.46 base: https://ci-hadoop.apache.org/job/hadoop-multibranch/job/PR-6932/4/artifact/out/Dockerfile

GITHUB PR
https://github.com/apache/hadoop/pull/6932

Optional Tests
dupname asflicense codespell detsecrets hadolint shellcheck shelldocs mvnsite unit

uname
Linux d11f19503b05 5.15.0-106-generic #116-Ubuntu SMP Wed Apr 17 09:17:56 UTC 2024 x86_64 x86_64 x86_64 GNU/Linux

Build tool
maven

Personality
dev-support/bin/hadoop.sh

git revision
trunk / 9122bef9ec27d8a75b79d3f107b48b1909cc0a20

Test Results
https://ci-hadoop.apache.org/job/hadoop-multibranch/job/PR-6932/4/testReport/

Max. process+thread count
551 (vs. ulimit of 5500)

modules
C:  U:

Console output
https://ci-hadoop.apache.org/job/hadoop-multibranch/job/PR-6932/4/console

versions
git=2.9.5 maven=3.6.3

Powered by
Apache Yetus 0.14.0 https://yetus.apache.org

This message was automatically generated.

(!) A patch to the testing environment has been detected.
Re-executing against the patched versions to perform further tests.
The console is at https://ci-hadoop.apache.org/job/hadoop-multibranch/job/PR-6932/5/console in case of problems.

:broken_heart: -1 overall

Vote
Subsystem
Runtime
Logfile
Comment

+0 :ok:
reexec
0m 23s

Docker mode activated.

_ Prechecks _

+1 :green_heart:
dupname
0m  0s

No case conflicting files found.

+0 :ok:
codespell
0m  0s

codespell was not available.

+0 :ok:
detsecrets
0m  0s

detect-secrets was not available.

+0 :ok:
hadolint
0m  0s

hadolint was not available.

+0 :ok:
shellcheck
0m  0s

Shellcheck was not available.

+0 :ok:
shelldocs
0m  0s

Shelldocs was not available.

+1 :green_heart:
@author
0m  0s

The patch does not contain any @author tags.

-0 :warning:
test4tests
0m  0s

The patch doesn't appear to include any new or modified tests. Please justify why no new tests are needed for this patch. Also please list what manual steps were performed to verify this patch.

_ trunk Compile Tests _

+0 :ok:
mvndep
0m 19s

Maven dependency ordering for branch

-1 :x:
mvninstall
0m 22s
/branch-mvninstall-root.txt
root in trunk failed.

+1 :green_heart:
mvnsite
0m  0s

trunk passed

+1 :green_heart:
shadedclient
1m 25s

branch has no errors when building and testing our client artifacts.

_ Patch Compile Tests _

+0 :ok:
mvndep
0m 18s

Maven dependency ordering for patch

+1 :green_heart:
mvninstall
0m  0s

the patch passed

+1 :green_heart:
blanks
0m  0s

The patch has no blanks issues.

+1 :green_heart:
mvnsite
0m  0s

the patch passed

+1 :green_heart:
shadedclient
0m 41s

patch has no errors when building and testing our client artifacts.

_ Other Tests _

+0 :ok:
asflicense
0m 21s

ASF License check generated no output?

4m 38s

Subsystem
Report/Notes

Docker
ClientAPI=1.46 ServerAPI=1.46 base: https://ci-hadoop.apache.org/job/hadoop-multibranch/job/PR-6932/5/artifact/out/Dockerfile

GITHUB PR
https://github.com/apache/hadoop/pull/6932

Optional Tests
dupname asflicense codespell detsecrets hadolint shellcheck shelldocs mvnsite unit

uname
Linux b4a2ea50c53f 5.15.0-106-generic #116-Ubuntu SMP Wed Apr 17 09:17:56 UTC 2024 x86_64 x86_64 x86_64 GNU/Linux

Build tool
maven

Personality
dev-support/bin/hadoop.sh

git revision
trunk / 4d275390ff355fc6e31524f37569afefbcc55bd6

Test Results
https://ci-hadoop.apache.org/job/hadoop-multibranch/job/PR-6932/5/testReport/

Max. process+thread count
9 (vs. ulimit of 5500)

modules
C:  U:

Console output
https://ci-hadoop.apache.org/job/hadoop-multibranch/job/PR-6932/5/console

versions
git=2.9.5 maven=3.6.3

Powered by
Apache Yetus 0.14.0 https://yetus.apache.org

This message was automatically generated.

(!) A patch to the testing environment has been detected.
Re-executing against the patched versions to perform further tests.
The console is at https://ci-hadoop.apache.org/job/hadoop-multibranch/job/PR-6932/6/console in case of problems.

:broken_heart: -1 overall

Vote
Subsystem
Runtime
Logfile
Comment

+0 :ok:
reexec
0m 20s

Docker mode activated.

_ Prechecks _

+1 :green_heart:
dupname
0m  0s

No case conflicting files found.

+0 :ok:
codespell
0m  0s

codespell was not available.

+0 :ok:
detsecrets
0m  0s

detect-secrets was not available.

+0 :ok:
hadolint
0m  0s

hadolint was not available.

+0 :ok:
shellcheck
0m  0s

Shellcheck was not available.

+0 :ok:
shelldocs
0m  0s

Shelldocs was not available.

+1 :green_heart:
@author
0m  0s

The patch does not contain any @author tags.

-0 :warning:
test4tests
0m  0s

The patch doesn't appear to include any new or modified tests. Please justify why no new tests are needed for this patch. Also please list what manual steps were performed to verify this patch.

_ trunk Compile Tests _

+0 :ok:
mvndep
0m 18s

Maven dependency ordering for branch

-1 :x:
mvninstall
0m 21s
/branch-mvninstall-root.txt
root in trunk failed.

+1 :green_heart:
mvnsite
0m  0s

trunk passed

-1 :x:
shadedclient
1m 12s

branch has errors when building and testing our client artifacts.

_ Patch Compile Tests _

+0 :ok:
mvndep
0m 20s

Maven dependency ordering for patch

+1 :green_heart:
mvninstall
0m  0s

the patch passed

+1 :green_heart:
blanks
0m  0s

The patch has no blanks issues.

+1 :green_heart:
mvnsite
0m  0s

the patch passed

-1 :x:
shadedclient
0m 53s

patch has errors when building and testing our client artifacts.

_ Other Tests _

+1 :green_heart:
asflicense
0m 32s

The patch does not generate ASF License warnings.

4m 46s

Subsystem
Report/Notes

Docker
ClientAPI=1.46 ServerAPI=1.46 base: https://ci-hadoop.apache.org/job/hadoop-multibranch/job/PR-6932/6/artifact/out/Dockerfile

GITHUB PR
https://github.com/apache/hadoop/pull/6932

Optional Tests
dupname asflicense codespell detsecrets hadolint shellcheck shelldocs mvnsite unit

uname
Linux e7cdbd6b4c11 5.15.0-106-generic #116-Ubuntu SMP Wed Apr 17 09:17:56 UTC 2024 x86_64 x86_64 x86_64 GNU/Linux

Build tool
maven

Personality
dev-support/bin/hadoop.sh

git revision
trunk / 00fafe5b23babd9f9639bda745b26d80cff31253

Test Results
https://ci-hadoop.apache.org/job/hadoop-multibranch/job/PR-6932/6/testReport/

Max. process+thread count
51 (vs. ulimit of 5500)

modules
C:  U:

Console output
https://ci-hadoop.apache.org/job/hadoop-multibranch/job/PR-6932/6/console

versions
git=2.9.5 maven=3.6.3

Powered by
Apache Yetus 0.14.0 https://yetus.apache.org

This message was automatically generated.

(!) A patch to the testing environment has been detected.
Re-executing against the patched versions to perform further tests.
The console is at https://ci-hadoop.apache.org/job/hadoop-multibranch/job/PR-6932/7/console in case of problems.

:confetti_ball: +1 overall

Vote
Subsystem
Runtime
Logfile
Comment

+0 :ok:
reexec
0m 19s

Docker mode activated.

_ Prechecks _

+1 :green_heart:
dupname
0m  0s

No case conflicting files found.

+0 :ok:
codespell
0m  0s

codespell was not available.

+0 :ok:
detsecrets
0m  0s

detect-secrets was not available.

+0 :ok:
hadolint
0m  0s

hadolint was not available.

+0 :ok:
shellcheck
0m  0s

Shellcheck was not available.

+0 :ok:
shelldocs
0m  0s

Shelldocs was not available.

+1 :green_heart:
@author
0m  0s

The patch does not contain any @author tags.

-0 :warning:
test4tests
0m  0s

The patch doesn't appear to include any new or modified tests. Please justify why no new tests are needed for this patch. Also please list what manual steps were performed to verify this patch.

_ trunk Compile Tests _

+0 :ok:
mvndep
14m 15s

Maven dependency ordering for branch

+1 :green_heart:
mvninstall
19m 49s

trunk passed

+1 :green_heart:
mvnsite
0m  0s

trunk passed

+1 :green_heart:
shadedclient
53m  6s

branch has no errors when building and testing our client artifacts.

_ Patch Compile Tests _

+0 :ok:
mvndep
0m 22s

Maven dependency ordering for patch

+1 :green_heart:
mvninstall
0m  0s

the patch passed

+1 :green_heart:
blanks
0m  0s

The patch has no blanks issues.

+1 :green_heart:
mvnsite
0m  0s

the patch passed

+1 :green_heart:
shadedclient
18m 24s

patch has no errors when building and testing our client artifacts.

_ Other Tests _

+1 :green_heart:
asflicense
0m 25s

The patch does not generate ASF License warnings.

73m 49s

Subsystem
Report/Notes

Docker
ClientAPI=1.46 ServerAPI=1.46 base: https://ci-hadoop.apache.org/job/hadoop-multibranch/job/PR-6932/7/artifact/out/Dockerfile

GITHUB PR
https://github.com/apache/hadoop/pull/6932

Optional Tests
dupname asflicense codespell detsecrets hadolint shellcheck shelldocs mvnsite unit

uname
Linux d08d49f502f9 5.15.0-106-generic #116-Ubuntu SMP Wed Apr 17 09:17:56 UTC 2024 x86_64 x86_64 x86_64 GNU/Linux

Build tool
maven

Personality
dev-support/bin/hadoop.sh

git revision
trunk / 0a815cdb47a87928b4a098f8e05a328c1fe87ebc

Test Results
https://ci-hadoop.apache.org/job/hadoop-multibranch/job/PR-6932/7/testReport/

Max. process+thread count
661 (vs. ulimit of 5500)

modules
C:  U:

Console output
https://ci-hadoop.apache.org/job/hadoop-multibranch/job/PR-6932/7/console

versions
git=2.9.5 maven=3.6.3

Powered by
Apache Yetus 0.14.0 https://yetus.apache.org

This message was automatically generated.

(!) A patch to the testing environment has been detected.
Re-executing against the patched versions to perform further tests.
The console is at https://ci-hadoop.apache.org/job/hadoop-multibranch/job/PR-6932/7/console in case of problems.

(!) A patch to the testing environment has been detected.
Re-executing against the patched versions to perform further tests.
The console is at https://ci-hadoop.apache.org/job/hadoop-multibranch/job/PR-6932/7/console in case of problems.

LGTM +1
It's still concerning when these situations arise. Previously, I've had to roll back PRs twice due to this issue.

(!) A patch to the testing environment has been detected.
Re-executing against the patched versions to perform further tests.
The console is at https://ci-hadoop.apache.org/job/hadoop-multibranch/job/PR-6932/8/console in case of problems.

The last change after approval is https://github.com/apache/hadoop/pull/6932/commits/d59e005b992fadf0fdef094dda8b0817ee13317b, this patch is ready to go.

:broken_heart: -1 overall

Vote
Subsystem
Runtime
Logfile
Comment

+0 :ok:
reexec
0m 20s

Docker mode activated.

_ Prechecks _

+1 :green_heart:
dupname
0m  0s

No case conflicting files found.

+0 :ok:
codespell
0m  0s

codespell was not available.

+0 :ok:
detsecrets
0m  0s

detect-secrets was not available.

+0 :ok:
hadolint
0m  0s

hadolint was not available.

+0 :ok:
shellcheck
0m  0s

Shellcheck was not available.

+0 :ok:
shelldocs
0m  0s

Shelldocs was not available.

+1 :green_heart:
@author
0m  0s

The patch does not contain any @author tags.

-1 :x:
test4tests
0m  0s

The patch doesn't appear to include any new or modified tests. Please justify why no new tests are needed for this patch. Also please list what manual steps were performed to verify this patch.

_ trunk Compile Tests _

+0 :ok:
mvndep
14m 31s

Maven dependency ordering for branch

+1 :green_heart:
mvninstall
19m 49s

trunk passed

+1 :green_heart:
mvnsite
0m  0s

trunk passed

+1 :green_heart:
shadedclient
53m 12s

branch has no errors when building and testing our client artifacts.

_ Patch Compile Tests _

+0 :ok:
mvndep
0m 23s

Maven dependency ordering for patch

+1 :green_heart:
mvninstall
0m  0s

the patch passed

+1 :green_heart:
blanks
0m  0s

The patch has no blanks issues.

+1 :green_heart:
mvnsite
0m  0s

the patch passed

+1 :green_heart:
shadedclient
18m 28s

patch has no errors when building and testing our client artifacts.

_ Other Tests _

+1 :green_heart:
asflicense
0m 25s

The patch does not generate ASF License warnings.

74m  3s

Subsystem
Report/Notes

Docker
ClientAPI=1.46 ServerAPI=1.46 base: https://ci-hadoop.apache.org/job/hadoop-multibranch/job/PR-6932/8/artifact/out/Dockerfile

GITHUB PR
https://github.com/apache/hadoop/pull/6932

Optional Tests
dupname asflicense codespell detsecrets hadolint shellcheck shelldocs mvnsite unit

uname
Linux cc1fcf128ea2 5.15.0-106-generic #116-Ubuntu SMP Wed Apr 17 09:17:56 UTC 2024 x86_64 x86_64 x86_64 GNU/Linux

Build tool
maven

Personality
dev-support/bin/hadoop.sh

git revision
trunk / d59e005b992fadf0fdef094dda8b0817ee13317b

Test Results
https://ci-hadoop.apache.org/job/hadoop-multibranch/job/PR-6932/8/testReport/

Max. process+thread count
680 (vs. ulimit of 5500)

modules
C:  U:

Console output
https://ci-hadoop.apache.org/job/hadoop-multibranch/job/PR-6932/8/console

versions
git=2.9.5 maven=3.6.3

Powered by
Apache Yetus 0.14.0 https://yetus.apache.org

This message was automatically generated.

@pan3793 Thanks for the contribution! @GauthamBanasandra Thanks for the review!


Optionally open port 80

IdPs deployed behind load balancers occasionally forward their requests on port 80 rather than 433. Provide an option to allow for this configuration. Default setting is off, option to appear in Advanced settings area!

I'd be strongly encouraging folks to use 443 even if it is an unwrap/rewrap job at the load balancer.
If this does go through suggest reasonable warning text be associated with it about "badness" and no "we're on a switched network" isn't reall a good enough excuse here.


Implement PowerShell profile

My PowerShell profile activates virtual environments detected in the current environment. I could instruct first-time contributors to modify their profile in CONTRIBUTING.md, but it would be nice to ship the appropriate profile options.
Maybe we can include a profile mix-in that can be dot-sourced by users.

This issue will now track effort on the PowerShell profile implementation. Things like automatic activation of the virtual environment, populating PYTHONSTARTUP with tooling\.pythonrc.py, and more.

These two are roughly equivalent:
In the $PROFILE for pwsh:
# If there is an `.env` file in the PWD, load environment variables from it
Set-PsEnv

In .bashrc
#* Import dotenv aka .env environment variables if it is found
if [ -f ./.env ] ; then
    set -o allexport # enable shell option to export all created variables
    source ./.env # now this will export all vars instead of just one
    set +o allexport # disable shell option to export all created variables
fi

Even though we aren't bundling a PowerShell profile or .bashrc, the manual first-time setup for a user will need to be documented. For security reasons, this cannot be automated, and instead we will tell the user what to do and why its needed.

This is completed in scripts/Initialize-Shell.ps1, which is manually invoked wherever needed to set environment variables and activate the environment.


JVM: Fix missing coverage for constructors

This PR fixes a bug in JVM coverage caluclation which skip the coverage calculations for constructors.

/gcbrun exp -n ascc-jvm-pr-596-1 -m vertex_ai_gemini-1-5 -i -b jvm-small


Make RequestError Sync

This requires enforcing that errors returned from TokenStorage
implementations are Send, which the ones in this crate are, but is a
breaking change because any external implementations may be returning
errors that are !Sync currently.
The motivation for this change is that Box<dyn Error + Send> is not as fully
supported within the rust stdlib as Box<dyn Error + Send + Sync>. In
particular there exists these two From impls:
impl<'a, E: Error + 'a> From for Box<dyn Error + 'a>
impl<'a, E: Error + Send + Sync + 'a> From for Box<dyn Error + Send + Sync + 'a>
but no corresponding impl for
impl<'a, E: Error + Send + 'a> From for Box<dyn Error + Send + 'a>
This may just be an oversight in the rust stdlib that could be fixed,
but in practice it means that dealing with 'Error + Send' types is not
the most ergonomic because the '?' operator can't be used to convert
from a Box<dyn Error + Send> to a Box.
Since the current implementations (not counting any external ones that
may exist) implement Sync this seems like a good tradeoff to make it a
little easier to use in an ergonomic way.

Codecov Report

Merging #106 into master will not change coverage.
The diff coverage is 0%.

@@           Coverage Diff           @@
##           master     #106   +/-   ##
=======================================
  Coverage   80.58%   80.58%
=======================================
  Files          10       10
  Lines        1962     1962
=======================================
  Hits         1581     1581
  Misses        381      381

Flag
Coverage Δ

#stable
80.58% <0%> (ø)
:arrow_up:

Impacted Files
Coverage Δ

src/storage.rs
27.41% <ø> (ø)
:arrow_up:

src/types.rs
59.79% <0%> (ø)
:arrow_up:

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update ac4bebe...c33d0b8. Read the comment docs.


Ads postroll

Hi !
I'm trying to add ads on videojs player.
I've no problem with preroll ads but I didn't found some doc about post-roll with this plugin.
It's possible or not ?
If is yes can you help me :) and if is not can you help me too :)
Thx !

Any news on post-roll support?

+1 for post-rolls

+1 dammit

+1, postrolls please pleaseplease :)

I'm using Projekktor instead, this project isn't going anywhere and it's buggy as hell.

Now post-roll is possible or not??

+1


Using the Android Studio network inspector crashes the app when performing streaming calls

When the network inspector in Android Studio is active while I perform a connect streaming call, the app just crashes with the following error:
E  FATAL EXCEPTION: OkHttp Dispatcher
	Process: com.connectrpc.examples.android, PID: 11743
	java.lang.IllegalStateException: sink already folded
		at okio.Pipe.fold(Pipe.kt:177)
		at com.connectrpc.okhttp.PipeDuplexRequestBody.writeTo(OkHttpStream.kt:211)
		at okhttp3.internal.http.CallServerInterceptor.intercept(CallServerInterceptor.kt:58)
		at okhttp3.internal.http.RealInterceptorChain.proceed(RealInterceptorChain.kt:109)
		at com.android.tools.profiler.agent.okhttp.OkHttp3Interceptor.intercept(OkHttp3Interceptor.java:57)
		at okhttp3.internal.http.RealInterceptorChain.proceed(RealInterceptorChain.kt:109)
		at com.android.tools.appinspection.network.okhttp.OkHttp3Interceptor.intercept(OkHttp3Interceptor.kt:52)
		at okhttp3.internal.http.RealInterceptorChain.proceed(RealInterceptorChain.kt:109)
		at com.android.tools.profiler.agent.okhttp.OkHttp3Interceptor.intercept(OkHttp3Interceptor.java:57)
		at okhttp3.internal.http.RealInterceptorChain.proceed(RealInterceptorChain.kt:109)
		at com.android.tools.appinspection.network.okhttp.OkHttp3Interceptor.intercept(OkHttp3Interceptor.kt:52)
		at okhttp3.internal.http.RealInterceptorChain.proceed(RealInterceptorChain.kt:109)
		at okhttp3.internal.connection.ConnectInterceptor.intercept(ConnectInterceptor.kt:34)
		at okhttp3.internal.http.RealInterceptorChain.proceed(RealInterceptorChain.kt:109)
		at okhttp3.internal.cache.CacheInterceptor.intercept(CacheInterceptor.kt:95)
		at okhttp3.internal.http.RealInterceptorChain.proceed(RealInterceptorChain.kt:109)
		at okhttp3.internal.http.BridgeInterceptor.intercept(BridgeInterceptor.kt:83)
		at okhttp3.internal.http.RealInterceptorChain.proceed(RealInterceptorChain.kt:109)
		at okhttp3.internal.http.RetryAndFollowUpInterceptor.intercept(RetryAndFollowUpInterceptor.kt:76)
		at okhttp3.internal.http.RealInterceptorChain.proceed(RealInterceptorChain.kt:109)
		at okhttp3.internal.connection.RealCall.getResponseWithInterceptorChain$okhttp(RealCall.kt:201)
		at okhttp3.internal.connection.RealCall$AsyncCall.run(RealCall.kt:517)
		at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1137)
		at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:637)
		at java.lang.Thread.run(Thread.java:1012)

To reproduce, you can simply run the Eliza example from this repo, open the network inspector (wait until it is fully loaded) and open the Connect - bidirectional streaming example. The app crashes immediately with the error above.

I believe this is the same underlying issue as https://issuetracker.google.com/issues/235863810.

Mh, that issue was not updated since over a year... I left a comment there as well as in the linked issue but it seems like that there won't be a solution any time soon.

There is nothing to be done at the moment for this issue in connect-kotlin (and it does appear to be the same root cause as #154). Interceptor APIs should be updated to look at the duplex/isOneShot settings of the request body and not consume the body in those cases. See https://github.com/square/okhttp/blob/e92667cf828e58a389a28bd2298ede9957c31ed4/okhttp-logging-interceptor/src/main/kotlin/okhttp3/logging/HttpLoggingInterceptor.kt#L198-L201 for an example of the expected handling.

Alright, thanks for looking into it.
For reference, here is the related ticket on the google issue tracker: https://issuetracker.google.com/issues/295991498


fix: 'dotenv' and 'dotenv-expand' as peer dependencies

fixes: #20

Let's discuss the approach in #20 first, I'm closing this PR for now to keep a clean slate


JAVA_HOME is set even when the feature is set to none

When trying to setup a new container for Java/Gradle you get the following error: ERROR: JAVA_HOME is set to an invalid directory: /usr/local/sdkman/candidates/java/current
Steps to reproduce:

Open empty directory in vscode
Reopen in container
Chose Java definition

Version 11
NodeJS => none
Install Gradle

Run gradle in shell

The problem seems to be the JAVA_HOME that is being set even though we are not installing Java via the feature:

https://github.com/devcontainers/features/blob/main/src/java/devcontainer-feature.json#L55
https://github.com/devcontainers/images/blob/main/src/java/.devcontainer/devcontainer.json#L8

It is overriding the value set in the container definition: https://github.com/devcontainers/images/blob/main/src/java/.devcontainer/devcontainer.json#L13
vscode: 1.71.2
devcontainer extension: v0.251.0

Arguing with this issue too. Since I'm starting my Dockerfile with
ARG VARIANT=11-bullseye
FROM mcr.microsoft.com/devcontainers/java:0-${VARIANT}

I don't see a need to install another version of Java with this feature, I just want Gradle.
I added the following to the end of my Dockerfile as a workaround:
ENV JAVA_HOME=/usr/lib/jvm/msopenjdk-current

I see that a similar issue has been raised in the images repository: https://github.com/devcontainers/images/issues/158
Which one should stay open?

Duplicate: https://github.com/devcontainers/images/issues/158
Added thoughts - https://github.com/devcontainers/images/issues/158#issuecomment-1284652886


[Bug]: Wrong top-padding in li-elment if multiple sbb-links are used.

Preflight Checklist

[X] I have read the Contributing Guidelines for this project.
[X] I agree to follow the Code of Conduct that this project adheres to.
[X] I have searched the issue tracker for an issue that matches the one I want to file, without success.

Bug type
Functionality
It affects the following packages
Components
Which version of Lyne Components are you using
0.28.4
Operating system
macOS
Browser / Browser version
Safari, Firefox, Chrome
Input mode
Mouse/Keyboard
Additional settings
No response
What happened?
When I put multiple sbb-links into one li-element, the top padding seems to be incorrect (from the second element on).
Example:

<sbb-link variant="inline" text-size="m" type="button" target="_blank" href="https://www.figma.com/file/UQBd7cHKav0hr9oXYp7opJ/SBB-Icons?node-id=372%3A0">als Figma Library</sbb-link>

<sbb-link variant="inline" text-size="m" type="button" target="_blank" href="https://github.com/sbb-design-systems/sbb-icons/archive/refs/heads/main.zip">als Download auf Github</sbb-link>

Als CDN: <sbb-link variant="inline" text-size="m" type="button" target="_blank" href="https://d1s1onrtynjaa8.cloudfront.net/icons/index.json">Json mit Meta-Daten</sbb-link> <sbb-link variant="inline" text-size="m" type="button" target="_blank" href="https://d1s1onrtynjaa8.cloudfront.net/icons/bottle-apple-small.svg">Beispiel</sbb-link>

<sbb-link variant="inline" text-size="m" type="button" target="_blank" href="https://lyne-storybook.app.sbb.ch/?path=/docs/components-sbb-icon--default">als Webcomponent (siehe Lyne)</sbb-link>

Steps to reproduce the issue
See example above.
Relevant log output
No response

It's the following selector interfering with this situation
       // P has to be redefined to be more specific
        > :is(p, *) + * {
          margin-block-start: var(--sbb-spacing-responsive-xxxs);
        }


Specify username in git clone command of Module 2

In section 2.1.6, the git clone operation mentions "". It should be specified that we are talking about the GitHub username here.
It would probably be better like this:
git clone https://github.com/<your GitHub username>/DevNet-Express-3.git

Solved with commit 7db279c


not working with apple-mobile-web-app-capable

it was not working for the web app i'm designing, so in an attempt to problem solve I cloned the example site, and added :
<meta name="apple-mobile-web-app-capable" content="yes">
I opened the site on device with ios 9, saved it to home screen, opened it, clicked the button, and device went to sleep after standard time. (same behaviour on android)

@richtr Do you have any idea whether or not this is fixable?

I am having the same issue. It ONLY works right after I added the app to the homescreen, but it doesn’t if I close and open it again.


OTHER_SWIFT_FLAGS and  HEADER_SEARCH_PATHS

Greetings!
i think we can separate modulemap and headers_search_path in pod's xcconfig file either.
With these, we can use #if canImport(IQKeyboardManager) in swift and #if __has_include("IQKeyboardManager.h") in oc,
instead of using #if !targetEnviroment(macCatalyst), for more clarity and supports more platforms
OTHER_SWIFT_FLAGS =  $(inherited)    COMMON        -Xcc -fmodule-map-file="${PODS_ROOT}/Headers/Public/IQKeyboardManager/IQKeyboardManager.modulemap"

HEADER_SEARCH_PATHS   =  $(inherited)    COMMON       "${PODS_ROOT}/Headers/Public/IQKeyboardManager"

to
OTHER_SWIFT_FLAGS =  $(inherited)    COMMON
OTHER_SWIFT_FLAGS[sdk=iphoneos*]   = $(inherited)   -Xcc -fmodule-map-file="${PODS_ROOT}/Headers/Public/IQKeyboardManager/IQKeyboardManager.modulemap"

HEADER_SEARCH_PATHS   =  $(inherited)    COMMON
HEADER_SEARCH_PATHS[sdk=iphoneos*] =  $(inherited)    "${PODS_ROOT}/Headers/Public/IQKeyboardManager"

And besides, i'm wondering if we can specify archs which results in
OTHER_LDFLAGS[sdk=iphoneos*] = $(inherited) -ObjC    -l"IQKeyboardManager"
OTHER_LDFLAGS[sdk=iphonesimulator*][arch=x86_64] = $(inherited) -ObjC    -l"IQKeyboardManager"
OTHER_LDFLAGS[sdk=iphonesimulator*][arch=arm64] = $(inherited)

Hi @tristanSIF , I don't think that'd be an option. Those you mention aré Build Settings and would work fine for static but not for dynamic libraries. The latter needs also to filter Compile Sources in Build Phases among others. The option for this filter is macOS and doesn't distinguish between x86_64 and arm64.

Hi @fermoya . I'm sorry for my poor english. I mean to use these two settings to work together with this great library, as additional processing of xcconfig file.

Hi @tristanSIF , the architectures won't be possible. Changing OTHER_SWIFT_FLAGS and HEADER_SEARCH_PATHS should be fine, I can look into that.
The file where changes need to be made is abstract_target.rb in case you wanna give it a try.

@tristanSIF I'm not sure what you suggest is enough to use canImport instead. I've pushed some changes to feat/issue-31 in the repo. I'm adding the sdk clause to:

OTHER_SWIFT_FLAGS
HEADER_SEARCH_PATHS
OTHER_LDFLAGS
OTHER_SWIFT_FLAGS

But it doesn't seem to work. You can try it yourself by trying to build the Sample project. If you want to clone the repo you can also use that code on your own project:
gem uninstall cocoapods-catalyst-support # old version
cd <path-to-catalyst-repo>
gem build cocoapods-catalyst-support.gemspec
sudo gem install cocoapods-catalyst-support-0.1.3.gem

@fermoya
I'm using use_modular_headers! instead of use_frameworks! in podfile and the xcconfig will be different.
The OTHER_SWIFT_FLAGS only appears with use_modular_headers!.
After testing the sample project, I found that there was not much to do when using use_frameworks! with feat/issue_31
use_frameworks!

XCCONFIG FILE GENERATED

CLANG_WARN_QUOTED_INCLUDE_IN_FRAMEWORK_HEADER = NO
GCC_PREPROCESSOR_DEFINITIONS = $(inherited) COCOAPODS=1 $(inherited) PB_FIELD_32BIT=1 PB_NO_PACKED_STRUCTS=1 PB_ENABLE_MALLOC=1
LD_RUNPATH_SEARCH_PATHS = $(inherited) '@executable_path/Frameworks' '@loader_path/Frameworks'
PODS_BUILD_DIR = ${BUILD_DIR}
PODS_CONFIGURATION_BUILD_DIR = ${PODS_BUILD_DIR}/$(CONFIGURATION)$(EFFECTIVE_PLATFORM_NAME)
PODS_PODFILE_DIR_PATH = ${SRCROOT}/.
PODS_ROOT = ${SRCROOT}/Pods
PODS_XCFRAMEWORKS_BUILD_DIR = $(PODS_CONFIGURATION_BUILD_DIR)/XCFrameworkIntermediates
USE_RECURSIVE_SCRIPT_INPUTS_IN_SCRIPT_PHASES = YES
OTHER_LDFLAGS[sdk=iphone*] = $(inherited) -ObjC -framework "StoreKit" -l"c++" -framework "FirebaseCoreDiagnostics" -framework "GoogleUtilities" -framework "Security" -framework "GoogleDataTransport" -framework "nanopb" -framework "FBLPromises" -framework "FirebaseCore" -framework "FirebaseAnalytics" -framework "FirebaseInstallations" -framework "GoogleAppMeasurement" -framework "GoogleAppMeasurementIdentitySupport"
OTHER_SWIFT_FLAGS[sdk=iphone*] = $(inherited) -D COCOAPODS
FRAMEWORK_SEARCH_PATHS[sdk=iphone*] = $(inherited) "${PODS_CONFIGURATION_BUILD_DIR}/FirebaseCoreDiagnostics" "${PODS_CONFIGURATION_BUILD_DIR}/GoogleUtilities" "${PODS_CONFIGURATION_BUILD_DIR}/GoogleDataTransport" "${PODS_CONFIGURATION_BUILD_DIR}/nanopb" "${PODS_CONFIGURATION_BUILD_DIR}/FirebaseCore" "${PODS_ROOT}/FirebaseAnalytics/Frameworks" "${PODS_CONFIGURATION_BUILD_DIR}/FirebaseInstallations" "${PODS_XCFRAMEWORKS_BUILD_DIR}/FirebaseAnalytics/AdIdSupport" "${PODS_ROOT}/GoogleAppMeasurement/Frameworks" "${PODS_XCFRAMEWORKS_BUILD_DIR}/GoogleAppMeasurement/AdIdSupport" "${PODS_CONFIGURATION_BUILD_DIR}/PromisesObjC" "${PODS_XCFRAMEWORKS_BUILD_DIR}/AppCenter/Analytics" "${PODS_XCFRAMEWORKS_BUILD_DIR}/GoogleAppMeasurement/WithoutAdIdSupport"
HEADER_SEARCH_PATHS[sdk=iphone*] = $(inherited) "${PODS_CONFIGURATION_BUILD_DIR}/FirebaseCoreDiagnostics/FirebaseCoreDiagnostics.framework/Headers" "${PODS_CONFIGURATION_BUILD_DIR}/GoogleUtilities/GoogleUtilities.framework/Headers" "${PODS_CONFIGURATION_BUILD_DIR}/GoogleDataTransport/GoogleDataTransport.framework/Headers" "${PODS_CONFIGURATION_BUILD_DIR}/nanopb/nanopb.framework/Headers" "${PODS_CONFIGURATION_BUILD_DIR}/PromisesObjC/FBLPromises.framework/Headers" "${PODS_CONFIGURATION_BUILD_DIR}/FirebaseCore/FirebaseCore.framework/Headers" "${PODS_ROOT}/Headers/Public" "${PODS_TARGET_SRCROOT}/Sources/FBLPromises/include" "${PODS_CONFIGURATION_BUILD_DIR}/FirebaseInstallations/FirebaseInstallations.framework/Headers" "${PODS_ROOT}/Headers/Public/Firebase"
OTHER_LDFLAGS = $(inherited) -ObjC -l"sqlite3" -l"z" -framework "CoreTelephony" -framework "Foundation" -framework "SystemConfiguration" -framework "UIKit"
FRAMEWORK_SEARCH_PATHS = $(inherited)
HEADER_SEARCH_PATHS = $(inherited) $(inherited) ${PODS_ROOT}/Firebase/CoreOnly/Sources
OTHER_LDFLAGS[sdk=macosx*] = $(inherited) -ObjC -framework "AppCenter" -framework "AppCenterAnalytics"
OTHER_SWIFT_FLAGS[sdk=macosx*] = $(inherited) -D COCOAPODS
FRAMEWORK_SEARCH_PATHS[sdk=macosx*] = $(inherited) "${PODS_ROOT}/AppCenter/AppCenter-SDK-Apple" "${PODS_XCFRAMEWORKS_BUILD_DIR}/AppCenter/Core"
HEADER_SEARCH_PATHS[sdk=macosx*] = $(inherited)

Modify FRAMEWORK_SEARCH_PATHS is enough for swift, and HEADER_SEARCH_PATHS for oc, which was done by feat/issue_31.

"${PODS_XCFRAMEWORKS_BUILD_DIR}/AppCenter/Analytics" belongs to macos, but catalyst-support assigned it to iphone*
OTHER_SWIFT_FLAGS is not necessary when using frameworks, my bad
remember to remove OTHER_SWIFT_FLAGS from sample project's build settings

And then, canImport works fine in swift with codes below, which will print AppCenter can be imported  with catalyst and Firebase can be imported  with ios.
I've no idea why canImport(Firebase) turns to be true with catalyst so i used FirebaseAnalytics instead
class Test {
    func doSth() {
        #if canImport(AppCenter)
        print("AppCenter can be imported")
        #endif
        #if canImport(FirebaseAnalytics)
        print("Firebase can be imported")
        #endif
    }
}

#if __has_include(<Firebase/Firebase.h>)
    NSLog(@"Firebase");
#endif
#if __has_include(<AppCenterAnalytics/AppCenterAnalytics.h>)
    NSLog(@"Appcenter");
#endif

use_modular_headers!

XCCONFIG FILE GENERATED

CLANG_WARN_QUOTED_INCLUDE_IN_FRAMEWORK_HEADER = NO
GCC_PREPROCESSOR_DEFINITIONS = $(inherited) COCOAPODS=1 $(inherited) PB_FIELD_32BIT=1 PB_NO_PACKED_STRUCTS=1 PB_ENABLE_MALLOC=1
LIBRARY_SEARCH_PATHS = $(inherited) "${PODS_CONFIGURATION_BUILD_DIR}/FirebaseCore" "${PODS_CONFIGURATION_BUILD_DIR}/FirebaseCoreDiagnostics" "${PODS_CONFIGURATION_BUILD_DIR}/FirebaseInstallations" "${PODS_CONFIGURATION_BUILD_DIR}/GoogleDataTransport" "${PODS_CONFIGURATION_BUILD_DIR}/GoogleUtilities" "${PODS_CONFIGURATION_BUILD_DIR}/PromisesObjC" "${PODS_CONFIGURATION_BUILD_DIR}/nanopb"
OTHER_CFLAGS = $(inherited) -fmodule-map-file="${PODS_ROOT}/Headers/Public/FBLPromises/PromisesObjC.modulemap" -fmodule-map-file="${PODS_ROOT}/Headers/Public/FirebaseCore/FirebaseCore.modulemap" -fmodule-map-file="${PODS_ROOT}/Headers/Public/FirebaseCoreDiagnostics/FirebaseCoreDiagnostics.modulemap" -fmodule-map-file="${PODS_ROOT}/Headers/Public/FirebaseInstallations/FirebaseInstallations.modulemap" -fmodule-map-file="${PODS_ROOT}/Headers/Public/GoogleDataTransport/GoogleDataTransport.modulemap" -fmodule-map-file="${PODS_ROOT}/Headers/Public/GoogleUtilities/GoogleUtilities.modulemap" -fmodule-map-file="${PODS_ROOT}/Headers/Public/nanopb/nanopb.modulemap"
PODS_BUILD_DIR = ${BUILD_DIR}
PODS_CONFIGURATION_BUILD_DIR = ${PODS_BUILD_DIR}/$(CONFIGURATION)$(EFFECTIVE_PLATFORM_NAME)
PODS_PODFILE_DIR_PATH = ${SRCROOT}/.
PODS_ROOT = ${SRCROOT}/Pods
PODS_XCFRAMEWORKS_BUILD_DIR = $(PODS_CONFIGURATION_BUILD_DIR)/XCFrameworkIntermediates
USE_RECURSIVE_SCRIPT_INPUTS_IN_SCRIPT_PHASES = YES
OTHER_LDFLAGS = $(inherited) -ObjC -l"sqlite3" -l"z" -framework "CoreTelephony" -framework "Foundation" -framework "SystemConfiguration" -framework "UIKit"
OTHER_LDFLAGS[sdk=macosx*] = $(inherited) -ObjC -framework "AppCenter" -framework "AppCenterAnalytics"
OTHER_LDFLAGS[sdk=iphone*] = $(inherited) -ObjC -framework "FirebaseAnalytics" -l"FirebaseCore" -l"FirebaseCoreDiagnostics" -l"FirebaseInstallations" -framework "GoogleAppMeasurement" -l"GoogleDataTransport" -l"GoogleUtilities" -l"PromisesObjC" -l"nanopb" -framework "StoreKit" -l"c++" -framework "Security" -framework "GoogleAppMeasurementIdentitySupport"
OTHER_SWIFT_FLAGS = $(inherited) -D COCOAPODS -Xcc -Xcc -Xcc -Xcc -Xcc -Xcc -Xcc
OTHER_SWIFT_FLAGS[sdk=macosx*] = $(inherited) -D COCOAPODS
OTHER_SWIFT_FLAGS[sdk=iphone*] = $(inherited) -D COCOAPODS -fmodule-map-file="${PODS_ROOT}/Headers/Public/FirebaseCore/FirebaseCore.modulemap" -fmodule-map-file="${PODS_ROOT}/Headers/Public/FirebaseCoreDiagnostics/FirebaseCoreDiagnostics.modulemap" -fmodule-map-file="${PODS_ROOT}/Headers/Public/FirebaseInstallations/FirebaseInstallations.modulemap" -fmodule-map-file="${PODS_ROOT}/Headers/Public/GoogleDataTransport/GoogleDataTransport.modulemap" -fmodule-map-file="${PODS_ROOT}/Headers/Public/GoogleUtilities/GoogleUtilities.modulemap" -fmodule-map-file="${PODS_ROOT}/Headers/Public/FBLPromises/PromisesObjC.modulemap" -fmodule-map-file="${PODS_ROOT}/Headers/Public/nanopb/nanopb.modulemap"
FRAMEWORK_SEARCH_PATHS = $(inherited)
FRAMEWORK_SEARCH_PATHS[sdk=macosx*] = $(inherited) "${PODS_ROOT}/AppCenter/AppCenter-SDK-Apple" "${PODS_XCFRAMEWORKS_BUILD_DIR}/AppCenter/Core"
FRAMEWORK_SEARCH_PATHS[sdk=iphone*] = $(inherited) "${PODS_ROOT}/FirebaseAnalytics/Frameworks" "${PODS_XCFRAMEWORKS_BUILD_DIR}/FirebaseAnalytics/AdIdSupport" "${PODS_ROOT}/GoogleAppMeasurement/Frameworks" "${PODS_XCFRAMEWORKS_BUILD_DIR}/GoogleAppMeasurement/AdIdSupport" "${PODS_XCFRAMEWORKS_BUILD_DIR}/AppCenter/Analytics" "${PODS_XCFRAMEWORKS_BUILD_DIR}/GoogleAppMeasurement/WithoutAdIdSupport"
HEADER_SEARCH_PATHS = $(inherited) $(inherited) ${PODS_ROOT}/Firebase/CoreOnly/Sources
HEADER_SEARCH_PATHS[sdk=macosx*] = $(inherited)
HEADER_SEARCH_PATHS[sdk=iphone*] = $(inherited) "${PODS_ROOT}/Headers/Public/Firebase" "${PODS_ROOT}/Headers/Public/FirebaseCore" "${PODS_ROOT}/Headers/Public/FirebaseCoreDiagnostics" "${PODS_ROOT}/Headers/Public/FirebaseInstallations" "${PODS_ROOT}/Headers/Public/GoogleDataTransport" "${PODS_ROOT}/Headers/Public/GoogleUtilities" "${PODS_ROOT}/Headers/Public/PromisesObjC" "${PODS_ROOT}/Headers/Public/nanopb" "${PODS_ROOT}/Headers/Public" "${PODS_TARGET_SRCROOT}/Sources/FBLPromises/include"

"${PODS_XCFRAMEWORKS_BUILD_DIR}/AppCenter/Analytics" belongs to macos, but catalyst-support assigned it to iphone*
-Xcc flag is needed ahead of -fmodule-map-file

Then the above code also works properly.

XCCONFIG FILE MODIFIED

CLANG_WARN_QUOTED_INCLUDE_IN_FRAMEWORK_HEADER = NO
GCC_PREPROCESSOR_DEFINITIONS = $(inherited) COCOAPODS=1 $(inherited) PB_FIELD_32BIT=1 PB_NO_PACKED_STRUCTS=1 PB_ENABLE_MALLOC=1
LIBRARY_SEARCH_PATHS = $(inherited) "${PODS_CONFIGURATION_BUILD_DIR}/FirebaseCore" "${PODS_CONFIGURATION_BUILD_DIR}/FirebaseCoreDiagnostics" "${PODS_CONFIGURATION_BUILD_DIR}/FirebaseInstallations" "${PODS_CONFIGURATION_BUILD_DIR}/GoogleDataTransport" "${PODS_CONFIGURATION_BUILD_DIR}/GoogleUtilities" "${PODS_CONFIGURATION_BUILD_DIR}/PromisesObjC" "${PODS_CONFIGURATION_BUILD_DIR}/nanopb"
OTHER_CFLAGS = $(inherited) -fmodule-map-file="${PODS_ROOT}/Headers/Public/FBLPromises/PromisesObjC.modulemap" -fmodule-map-file="${PODS_ROOT}/Headers/Public/FirebaseCore/FirebaseCore.modulemap" -fmodule-map-file="${PODS_ROOT}/Headers/Public/FirebaseCoreDiagnostics/FirebaseCoreDiagnostics.modulemap" -fmodule-map-file="${PODS_ROOT}/Headers/Public/FirebaseInstallations/FirebaseInstallations.modulemap" -fmodule-map-file="${PODS_ROOT}/Headers/Public/GoogleDataTransport/GoogleDataTransport.modulemap" -fmodule-map-file="${PODS_ROOT}/Headers/Public/GoogleUtilities/GoogleUtilities.modulemap" -fmodule-map-file="${PODS_ROOT}/Headers/Public/nanopb/nanopb.modulemap"
PODS_BUILD_DIR = ${BUILD_DIR}
PODS_CONFIGURATION_BUILD_DIR = ${PODS_BUILD_DIR}/$(CONFIGURATION)$(EFFECTIVE_PLATFORM_NAME)
PODS_PODFILE_DIR_PATH = ${SRCROOT}/.
PODS_ROOT = ${SRCROOT}/Pods
PODS_XCFRAMEWORKS_BUILD_DIR = $(PODS_CONFIGURATION_BUILD_DIR)/XCFrameworkIntermediates
USE_RECURSIVE_SCRIPT_INPUTS_IN_SCRIPT_PHASES = YES
OTHER_LDFLAGS = $(inherited) -ObjC -l"sqlite3" -l"z" -framework "CoreTelephony" -framework "Foundation" -framework "SystemConfiguration" -framework "UIKit"
OTHER_LDFLAGS[sdk=macosx*] = $(inherited) -ObjC -framework "AppCenter" -framework "AppCenterAnalytics"
OTHER_LDFLAGS[sdk=iphone*] = $(inherited) -ObjC -framework "FirebaseAnalytics" -l"FirebaseCore" -l"FirebaseCoreDiagnostics" -l"FirebaseInstallations" -framework "GoogleAppMeasurement" -l"GoogleDataTransport" -l"GoogleUtilities" -l"PromisesObjC" -l"nanopb" -framework "StoreKit" -l"c++" -framework "Security" -framework "GoogleAppMeasurementIdentitySupport"
OTHER_SWIFT_FLAGS = $(inherited) -D COCOAPODS
OTHER_SWIFT_FLAGS[sdk=macosx*] = $(inherited)
OTHER_SWIFT_FLAGS[sdk=iphone*] = $(inherited) -Xcc -fmodule-map-file="${PODS_ROOT}/Headers/Public/FirebaseCore/FirebaseCore.modulemap" -Xcc -fmodule-map-file="${PODS_ROOT}/Headers/Public/FirebaseCoreDiagnostics/FirebaseCoreDiagnostics.modulemap" -Xcc -fmodule-map-file="${PODS_ROOT}/Headers/Public/FirebaseInstallations/FirebaseInstallations.modulemap" -Xcc -fmodule-map-file="${PODS_ROOT}/Headers/Public/GoogleDataTransport/GoogleDataTransport.modulemap" -Xcc -fmodule-map-file="${PODS_ROOT}/Headers/Public/GoogleUtilities/GoogleUtilities.modulemap" -Xcc -fmodule-map-file="${PODS_ROOT}/Headers/Public/FBLPromises/PromisesObjC.modulemap" -Xcc -fmodule-map-file="${PODS_ROOT}/Headers/Public/nanopb/nanopb.modulemap"
FRAMEWORK_SEARCH_PATHS = $(inherited)
FRAMEWORK_SEARCH_PATHS[sdk=macosx*] = $(inherited) "${PODS_ROOT}/AppCenter/AppCenter-SDK-Apple" "${PODS_XCFRAMEWORKS_BUILD_DIR}/AppCenter/Core" "${PODS_XCFRAMEWORKS_BUILD_DIR}/AppCenter/Analytics"
FRAMEWORK_SEARCH_PATHS[sdk=iphone*] = $(inherited) "${PODS_ROOT}/FirebaseAnalytics/Frameworks" "${PODS_XCFRAMEWORKS_BUILD_DIR}/FirebaseAnalytics/AdIdSupport" "${PODS_ROOT}/GoogleAppMeasurement/Frameworks" "${PODS_XCFRAMEWORKS_BUILD_DIR}/GoogleAppMeasurement/AdIdSupport" "${PODS_XCFRAMEWORKS_BUILD_DIR}/GoogleAppMeasurement/WithoutAdIdSupport"
HEADER_SEARCH_PATHS = $(inherited) ${PODS_ROOT}/Firebase/CoreOnly/Sources
HEADER_SEARCH_PATHS[sdk=macosx*] = $(inherited)
HEADER_SEARCH_PATHS[sdk=iphone*] = $(inherited) "${PODS_ROOT}/Headers/Public/Firebase" "${PODS_ROOT}/Headers/Public/FirebaseCore" "${PODS_ROOT}/Headers/Public/FirebaseCoreDiagnostics" "${PODS_ROOT}/Headers/Public/FirebaseInstallations" "${PODS_ROOT}/Headers/Public/GoogleDataTransport" "${PODS_ROOT}/Headers/Public/GoogleUtilities" "${PODS_ROOT}/Headers/Public/PromisesObjC" "${PODS_ROOT}/Headers/Public/nanopb" "${PODS_ROOT}/Headers/Public" "${PODS_TARGET_SRCROOT}/Sources/FBLPromises/include"

Hi @tristanSIF thanks for clarifying, I didn't know you needed to use use_modular_headers! instead.
Does that mean that it works as expected and you're happy with the work done in that branch?

@fermoya
There are still some misconfigurations by feat/issue-31 both with use_frameworks! and use_modular_headers!, which have been listed in the comment above.
And the expected settings can be seen above by clicking on 'XCCONFIG FILE MANUALLY FIXED'

@fermoya
Version 2.0 is superb, and it works exactly as I expected in Swift.
However, I have encountered some problems in oc, both with use_frameworks! and use_modular_headers!

HEADER_SEARCH_PATHS = $(inherited) "${PODS_ROOT}/Headers/Public" "${PODS_ROOT}/Headers/Public/Firebase" $(inherited) ${PODS_ROOT}/Firebase/CoreOnly/Sources "${PODS_TARGET_SRCROOT}/Sources/FBLPromises/include" Firebase and FBLPromises are only used by Firebase and should be moved to iphone*

I've no idea if we can just remove  "${PODS_ROOT}/Headers/Public". If it keeps, #if __has_include(<Firebase/Firebase.h>) will always be true.

I pushed new changes @tristanSIF , it should be all good now hopefully. It compiles for both Mac and arm64 no matter if use_frameworks! or use_modular_headers!

@fermoya I still have questions about "${PODS_ROOT}/Headers/Public", which is auto-generated and added to HEADER_SEARCH_PATHS by cocoapods.
I am not sure if the following words are correct, and I'm not sure if removing it will have any side effects.
In my opinion, this directory is created just as a container for placing libraries' header files, which are placed in sub-directories. And no header files placed in root of Public. These sub-directories will also be added to HEADER_SEARCH_PATHS so we can import files from sub-directories directly. Therefore, "${PODS_ROOT}/Headers/Public" is not necessary in HEADER_SEARCH_PATHS.
On the other hand, compiler will be able to find the header file if we keep Public in search paths, and #if __has_include(<Firebase/Firebase.h>) will always be true as the file actually exists, so we have no method to do same thing like canImport in OC.
So, I think we can just remove it from paths, to make  #if __has_include(<Firebase/Firebase.h>) available in OC.

@tristanSIF I'm not so sure you can just remove "${PODS_ROOT}/Headers/Public". It's not necessary for this particular Sample project but it might be the case that some other pod that you wanna keep requires that particular path to import some Public header. Removing it would surely cause a compilation error.
Those headers should've been marked as macOS in the Pods.xcproject Build Phases. Otherwise, that might be a possible cause of the problem.

No questions any more. Thank you so very much.


Rebase on upstream v2.3.3

Since upstream kolibri-installer-gnome has major fixes about new Soup, endless-key-flatpak should take the fixes.
Get the fixes by rebase on upstream v2.3.3 and one more commit 0f2d99a6e84f ("Replace Soup.Message.status_code with get_status()").

If we do not have the fixes, we will hit With automatic login enabled, automatic provisioning is failing and Kolibri-gnome fails at Soup.Message does not have attribute 'status_code'.

I rebase upon kolibri-installer-gnome by the command git rebase -i --onto 0f2d99a6e84facdb68deb0e3a68cd6efb38b9cb8 v2.3.2 --autosquash
Here is downstream modification:
pick 36e5733 libkolibri_daemon_dbus: Parameterize bus name of the DBus
pick ba83ba7 meson: Build with Endless Key flavor by setting as org.endlessos.Key
pick b4c24c7 Build org.endlessos.Key.Devel
pick 8d51605 Improve app environment variable prefixes
pick fee7f61 Revert "libkolibri_daemon_dbus: Parameterize bus name of the DBus"
pick 33aa5a9 Prefix USE_SYSTEM_INSTANCE variable in log message
pick 9af9d07 Fix lint errors
pick 72cbf91 Add github workflow to lint and build flatpak bundle

Fix conflict

ba83ba7 meson: Build with Endless Key flavor by setting as org.endlessos.Key

Upstream has -> Drop

8d51605 Improve app environment variable prefixes
9af9d07 Fix lint errors
72cbf91 Add github workflow to lint and build flatpak bundle

Merge commits

36e5733 libkolibri_daemon_dbus: Parameterize bus name of the DBus
fee7f61 Revert "libkolibri_daemon_dbus: Parameterize bus name of the DBus"

Pushed as branch rebase-2.3.3 and ready for review.

The new Endless Key flatpak builds, is installed and works!


Feature Request: Group title should respect updated font style.

It is nice you can change group title above the symbols, but after running the plugin it is reset to default one - would be great if that style was preserved.

@willowbrae (and @smmandersen, @guillaumechabot, @gorkarod) I just pushed v11.5 which updated default font to SF UI Text, and will also now respect user modifications to Symbol Group Title style. Thank you for the suggestion, and your support!


Added a code sample for lookup columns

Category

[x] Content fix
[ ] New article

Related issues

fixes #6917

What's in this Pull Request?
Before submitting this pull requests, I have researched the way lookup column validation works. Results are as follows:
This won't work
=if([$LookupField.name]=='London', 'true', 'false')

and this won't work either:
=if([$LookupField.lookupValue]=='London', 'true', 'false')

and this:
=if([$LookupField]=='London', 'true', 'false')

What works
This is how lookups look like in the JSON formula validation function:

As a result, the lookup values can be references this way in the JSON formula
=if([$LookupField]=='1;#London', 'true', 'false')

So, when referencing a lookup value, we need to use this format: <Lookup ID>;#<Lookup Value>

Docs Build status updates of commit a56bf31:
:white_check_mark: Validation status: passed

File
Status
Preview URL
Details

docs/declarative-customization/list-form-conditional-show-hide.md
:white_check_mark:Succeeded
View

For more details, please refer to the build report.
Note: Broken links written as relative paths are included in the above build report. For broken links written as absolute paths or external URLs, see the broken link report.
For any questions, please:Try searching the docs.microsoft.com contributor guidesPost your question in the Docs support channel

Docs Build status updates of commit 434475b:
:white_check_mark: Validation status: passed

File
Status
Preview URL
Details

docs/declarative-customization/list-form-conditional-show-hide.md
:white_check_mark:Succeeded
View

For more details, please refer to the build report.
Note: Broken links written as relative paths are included in the above build report. For broken links written as absolute paths or external URLs, see the broken link report.
For any questions, please:Try searching the docs.microsoft.com contributor guidesPost your question in the Docs support channel

Ive been through your excellent tip regarding Sharepoint list hiding column lookup yet is this only for the ID column? Imagine that you have different (not id columns) associated with the related lookup
Example:

List A has three fields  Country City District
List B has a lookup fields based on City and hiding condition needs to be based on city

Thank you!


Make the update script work in a single pass.

The Release Engineering team has noticed that we have to run the update script multiple times in order to get a clean copy of a given version of cf-release. This seems to be a problem with cleaning up after updating the submodules of releases that are submoduled into this release.
To solve this problem, we reversed the order in which submodules are updated and cleaned, which allowed us to checkout any release and cleanse it with a single run of the script.

Hey @davewalter, can you re-submit this PR against the develop branch please?
Thanks,
Amit


Fail to execute command "Azure Container Apps: Activate" with an error from command palette

OS: All
Build Version: 20220405.6
Regression: Not a Regression
Repro Steps:

F1 -> Azure Container Apps: Activate -> Select a subscription -> Select a container app environment -> Select a container app -> Select a revision.
Check whether succeeds to execute command "Azure Container Apps: Activate" directly.

Expect:
Succeed to execute command "Azure Container Apps: Activate" directly.
Actual:
Continue to perform the next step and fail to execute command "Azure Container Apps: Activate" with an error.

More Info:
This issue also reproduces for the commands "Azure Container Apps: Deactivate" and "Azure Container Apps: Restart".

This issue also reproduces for the command "Azure Container Apps: Delete Container Apps Environment...".

Verified on the latest build 20230309.15, this issue has been fixed for now. So close it.


Report error for common no-op statements

Assuming the following code:
function doSomething() {
  alert("Did something");
}

doSomething;

Would it be possible for TypeScript to complain about the doSomething; line, notifying the user that the statement is a no-op and maybe even suggesting adding parentheses to call the function? Or do you folks consider that kind of problems to definitely be a linter error, rather than something the compiler should look out for?
I searched the bugtracker but couldn't find any similar requests, my apologies if I missed them. I don't even know how feasible this would be, maybe ECMAScript has intricacies that make it impossible in all but the simplest cases, but I thought it couldn't hurt to suggest it.

What if doSomething was implemented as a getter?
this looks like a tslinlt rule to me.

doSomething in this context can't be a getter though because it's a standalone identifier. This would only be a problem as a property access.

Though I'm leaning towards this being a linter rule like @mhegazy says. For this purpose, I think tslint's no-unused-expression would be the rule you're looking for @elisee.

I expect the vast majority of getters to have no side-effects in pratice and as such, they don't make sense as standalone expressions either (whether this is too a big assumption to make in the compiler or not, I don't know.)
Thanks for the pointers to tslint, I started looking at it right after posting this and it's a nifty tool indeed.
Still thinking it would be nice to prevent this kind of footgun at the language level, similarly to #2575 and the upcoming reachability analysis, but I'll defer to you. Please close if you still think it doesn't belong in the language.

So one reason a person might use a standalone identifier as a statement expression is to ensure that we don't perform module import elision. Basically, if we never use any value entity from a module, then we assume it was only used for types. This means people end up needing to do something like
import * as foo from "fooModule";
import "fooModule";

However, another reasonable way to trigger this would be
import * as foo from "fooModule";
foo;

So I'm going to lean on the side that this is more in the scope of linters.


Implement SVM API methods

[x] Create api.go in root of svm
[x] Implement SVM package methods (listed below)
[x] Replace existing calls into state package with the new methods
[x] Ensure state package is not imported anywhere outside the svm package
[x] https://github.com/spacemeshos/go-spacemesh/issues/2888
[x] System tests must pass (to ensure the change didn't break any functionality), but any unit test that needs to temporarily import state or be skipped should be fixed in a separate PR

ℹ Keep PRs small (~1 day of work)! Each method can have it's own PR, if needed.
Methods

[x] Constructor (func New(...) *SVM) should be implemented incrementally as other methods are implemented.
[x] https://github.com/spacemeshos/go-spacemesh/issues/2830
[x] https://github.com/spacemeshos/go-spacemesh/issues/2831
[x] https://github.com/spacemeshos/go-spacemesh/issues/2832
[x] https://github.com/spacemeshos/go-spacemesh/issues/2833
[x] https://github.com/spacemeshos/go-spacemesh/issues/2834

Completed.


Restore back compat

Please make sure to label your PR with "bug", "new feature" or "breaking change" label(s).
To prevent this PR from going to the changelog marked it with the "skip changelog" label.

Snapshot stored with reference name:
refs/pull/15199/merge
Test environment:
https://babylonsnapshots.z22.web.core.windows.net/refs/pull/15199/merge/index.html
To test a playground add it to the URL, for example:
https://babylonsnapshots.z22.web.core.windows.net/refs/pull/15199/merge/index.html#WGZLGJ#4600
Links to test babylon tools with this snapshot:
https://playground.babylonjs.com/?snapshot=refs/pull/15199/merge
https://sandbox.babylonjs.com/?snapshot=refs/pull/15199/merge
https://gui.babylonjs.com/?snapshot=refs/pull/15199/merge
https://nme.babylonjs.com/?snapshot=refs/pull/15199/merge
To test the snapshot in the playground with a playground ID add it after the snapshot query string:
https://playground.babylonjs.com/?snapshot=refs/pull/15199/merge#BCU1XR#0

WebGL2 visualization test reporter:
https://babylonsnapshots.z22.web.core.windows.net/refs/pull/15199/merge/testResults/webgl2playwright/index.html

Visualization tests for WebGPU (Experimental)
https://babylonsnapshots.z22.web.core.windows.net/refs/pull/15199/merge/testResults/webgpuplaywright/index.html


Document supported environments for each example

Description

For each example, add a supported examples table, noting any additional steps needed for each env
This table is skipped for any example which runs in it's own custom env: DFP Production, SID Visualization, DOCA
Remove persistent RAG pipeline as this pipeline was broken/incomplete
Mark the DFP Starter example as broken

Closes #1782
By Submitting this PR I confirm:

I am familiar with the Contributing Guidelines.
When the PR is ready for review, new or existing tests cover these changes.
When the PR is ready for review, the documentation is up to date with these changes.

/merge


Switch away from BigNumber.js

BigNumber.js: size: 84.19kB with tree-shaking 79.41kB, minified 17.7kB
any-base:   : size: 2.68kB, 976B minified
I wrote tests to make sure I didn't break anything. Comparing the speed they are about the same.
related to #493

Very good job !

There are some conflicts now, but totally agree to merge this


Enable Ministry to Mandate new Monthly Disbursement Schedule for Specific Schools

User Story
As a student attending particular schools with reputation for claiming entire award amounts as remittance, I want the ability for Ministry to set unique disbursement schedule for myself and any other students attending my school so that I am more likely to retain my award amounts and be able to cover my expenses without all money being lost to remittance.
Description
Enable Ministry user to specify a monthly disbursement schedule for an entire school.
Acceptance Criteria

[ ] Introduce new disbursement schedule in disbursement workflow. This would allow payload to be divided equally across every month of the student's studies.
[ ] Enable Ministry to apply this unique disbursement schedule for particular schools such that every student attending those schools will be subject to monthly disbursements

@HRAGANBC  - think this is out of scope indefinitely right?
@michesmith

@AnnaPBashkatova This ticket deals with a new disbursement schedule (monthly vs and the other ticket is about removing the ability to remit tuition when actioning a COE.


Init Python 3 Continuous Integration

@znation, @nickjong - I think this is now ready to go in.

fixes #1030


failed to run self-build image which rootfs kubeadm.yaml was overwrite partly

What happened:
i want customize JoinConfiguration like the sealer old version , copy yaml file to etc. below is my kubefile:

while , after i run this image ,found that this required filed is empty. failed to run this image.
cat /var/lib/sealer/data/my-cluster/rootfs/kubeadm-config.yaml

What you expected to happen:
How to reproduce it (as minimally and precisely as possible):

Anything else we need to know?:
Environment:

sealer version (use sealer version):
Cloud provider or hardware configuration:
OS (e.g: cat /etc/os-release):
Kernel (e.g. uname -a):
Install tools:
Others:

no need this file  /var/lib/sealer/data/my-cluster/rootfs/kubeadm-config.yaml

rebuild base image
AMD:
sealer-docker image kubernetes-clusterv2:v1.19.8
kyverno image kubernetes-kyverno:v1.19.8
ARM:
sealer-docker image kubernetes-arm64:v1.19.7
kyverno image kubernetes-kyverno-arm64:v1.19.7


Adds support for optional string prefix to hashid

I'm opening this PR for discussion.
This work is partially inspired by/based on #49 but in implementing it I realized that my use case is somewhat different from @toudi because it looks like he's hoping for an integer "prefix" that gets encoded within the hashid, whereas I'd like to see string prefixes prepended to the hashid after encoding.
What I've got here passes tests and solves my problem, but I'm less certain whether this feature belongs in this library.
See also: discussion on #21

hello. I'm just wondering if your use case does not call for an actuall Field implementation. what I mean is - you could create a Field class that extends HashidField and has support for prefixes - similarly to how a ChoiceField extends, say, a CharField but has support for possible choices.
this could be my mistake from not understanding your context correctly of course but basically a field has to_representation and to_python or something like that that reads value from the database or writes it back.
The other solution I was thinking of was to either have the encoding callable inside Meta of the model or to pass it to the field somehow. This way, there wouldn't be as many parameters required to the Field itself.
I will try to read the PR once more in couple of days as I'm burried in work right now


The ddraw.dll in the game folder is being ignored on Win10 1909

The ddraw.dll (together with dxwrapper.dll and dxwrapper.ini) I've placed in the game folder is being ignored on Win10 1909 - at least it seems to have no effect and also no dxwrapper-exename.log file gets created. The same game + dll combination works on a Win7 installation without a problem... Is there a way to make the game "eat it" on the newest Win10?
The game is: The Settlers 3 from GoG

The Settlers 3 uses DirectX 6.  However, it loads ddraw.dll via COM component.  See this thread for more details.  With Windows 10 when you load ddraw.dll this way it will always load it from the System32 folder.
The work around is to rename the ddraw.dll in dxwrapper to something else.  For this particular game you can use dsound.dll instead.  However, when I tested this it appears that dxwrapper has some issues with this game for some reason.  I will have to take a look at it later.

Same issue with Settlers 4. But the log files are created.
ddraw.log
dxwrapper-s4_main.log

Seems the issue is also present with Settlers IV Gold Edition from GOG when using Windows 11 Pro 21H2 22000.434.

Closing issue.


Remove old sync comments

Change-type: patch
Signed-off-by: Josh Bowling<EMAIL_ADDRESS>

@balena-ci I self certify!


Add assignment allows you to add assignments that are not graded but have a grade

The assignment added can have a grading status of s/N but still receive a grade of g/50

This applies to edit assignment as well


main.spec seems to reference files you didnt put on github,

25313 INFO: Appending 'datas' from .spec
Unable to find "c:\REPO\Masendor\gamescript" when adding binary and data files.

datas += [('data', 'data'), ('engine', 'engine'), ('animation-maker', 'animation-maker'), ('photo-studio', 'photo-studio')]
probably

Thanks for the fix. It was the old file naming format I forgot to change in main.spec.


postinstallのtscが失敗する？

https://kokoro.io/messages/628058

node@12
 mohemohe@Colette  ~/d/s/g/m/kokoro.io.js   master 
 ❯ node -v                                                                                [17:01:13]
v12.18.3

 mohemohe@Colette  ~/d/s/g/m/kokoro.io.js   master 
 ❯ yarn                                                                                [17:01:18]
yarn install v1.22.5
[1/4] 🔍  Resolving packages...
[2/4] 🚚  Fetching packages...
[3/4] 🔗  Linking dependencies...
[4/4] 🔨  Building fresh packages...
$ postinstall-build dist
postinstall-build:
  This version of npm (6.14.6) may not be compatible with postinstall-build! There
  are outstanding bugs in certain versions of npm that prevent it from working with
  postinstall-build. See https://github.com/exogen/postinstall-build#bugs-in-npm
  for more information.

npm WARN lifecycle The node binary used for scripts is /var/folders/8d/qkg31kt51wb9v6fm63ssfclw0000gn/T/yarn--1601366483123-0.7943524998831626/node but npm is using /Users/mohemohe/.local/n/bin/node itself. Use the `--scripts-prepend-node-path` option to include the path for the node binary npm was executed with.

><EMAIL_ADDRESS>build /Users/mohemohe/develop/src/github.com/mohemohe/kokoro.io.js
> tsc

✨  Done in 8.72s.

node@14
 mohemohe@Colette  ~/d/s/g/m/kokoro.io.js   master 
 ❯ node -v                                                                                [17:04:03]
v14.12.0

 mohemohe@Colette  ~/d/s/g/m/kokoro.io.js   master 
 ❯ yarn                                                                                [17:04:05]
yarn install v1.22.5
[1/4] 🔍  Resolving packages...
[2/4] 🚚  Fetching packages...
[3/4] 🔗  Linking dependencies...
[4/4] 🔨  Building fresh packages...
$ postinstall-build dist
[########################################################################################################################################################################################] 184/184postinstall-build:
  This version of npm (6.14.8) may not be compatible with postinstall-build! There
  are outstanding bugs in certain versions of npm that prevent it from working with
  postinstall-build. See https://github.com/exogen/postinstall-build#bugs-in-npm
  for more information.

npm WARN lifecycle The node binary used for scripts is /var/folders/8d/qkg31kt51wb9v6fm63ssfclw0000gn/T/yarn--1601366646588-0.3819840924451241/node but npm is using /Users/mohemohe/.local/n/bin/node itself. Use the `--scripts-prepend-node-path` option to include the path for the node binary npm was executed with.

><EMAIL_ADDRESS>build /Users/mohemohe/develop/src/github.com/mohemohe/kokoro.io.js
> tsc

✨  Done in 7.37s.

yarn だとうまくいって npm だとダメ。
たぶん yarn.lock があるから問題ないけど package-lock.json がないせい

https://github.com/imsnif/synp で yarn.lock から package-lock.json を生成したら問題なさげ

面倒くさいからトランスパイル済みのパッケージをpublishするようにした


Renewing Puppet Forge Approved Status

Hey lwf,
Here at puppetlabs, we are currently going through all of our Approved modules on the Puppet Forge. We have some feedback for your module if you would be interested in retaining the approved status. If you are keen on keeping your approved status please ensure you respond as soon as you possibly can.
Many Thanks
The Puppet Approvals Committee.

I have no intention of performing further work on this module. There was some talk of migrating it to voxpopuli, but I'm not sure that went anywhere.

Any movement on getting this migrated to voxpopuli? I would like to see the 2.0 release on puppetforge. Thanks.


Issue Using Pico-DMX together with Adafruit_NeoPXL8

When using "Pico-DMX" together with "Adafruit_NeoPXL8" on Raspberry Pi Pico with Arduino (earlephilhower core) the processor behaves unpredictable (normally blocks all communication).
The root source for this problem is that both libraries use the same Interrupt (IRQ0) for DMA:
Pico-DMX / DmxInput.cpp / DmxInput::read_async
dma_channel_set_irq0_enabled(_dma_chan, true);
irq_set_exclusive_handler(DMA_IRQ_0, dmxinput_dma_handler);
irq_set_enabled(DMA_IRQ_0, true);
Adafruit_NeoPXL8 / Adafruit_neoPXL8.cpp / Adafruit_NeoPixel::begin
irq_set_exclusive_handler(DMA_IRQ_0, dma_finish_irq);
dma_channel_set_irq0_enabled(dma_channel, true);
irq_set_enabled(DMA_IRQ_0, true);
Changing one of the two to IRQ1 in all three code lines solves the problem and everything runs like a charm.
I don't know whether it is possible to sort of claim an IRQ like for the DMA channels and the PIO state machines.
If not it would be very desirable to add a parameter  to the read_async method. Which allows to select the IRQ by the application in case of conflicts.
Same is true for the DmxInput::read method. DmxOutput not tested yet.
I will also report same thing to Adafruit.

I agree that it might be helpful to be able to change this using an additional parameter or #define. PRs welcome :)

Duplicate of #33 ?

@kripton indeed it is. We'll keep tracking this in #33 :)


build(router_env): obtain workspace member package names from cargo_metadata more deterministically

Type of Change

[x] Bugfix
[ ] New feature
[ ] Enhancement
[ ] Refactoring
[x] Dependency updates
[ ] Documentation
[ ] CI/CD

Description

ORIGINAL PR: https://github.com/juspay/hyperswitch/pull/4139
This PR updates the build script code to obtain cargo workspace member package names to use a better and more deterministic way to do so.
Previously, we used to perform string manipulation on the package ID format (obtained from the workspace_members field in cargo metadata --format-version=1), and the package ID format was not stabilized (until recently). The package ID format has been stabilized in Rust 1.77, and the stabilized format breaks our existing build scripts. This PR updates the build script code to instead obtain the workspace member package names using the Metadata::workspace_packages() method that the cargo_metadata crate provides.
Motivation and Context

This would fix builds from breaking once Rust 1.77 is released as the stable version on March 21st, 2024.
Fixes #4137.
How did you test it?

cargo run was successful with both Rust 1.76 and 1.77 (although with warnings).
I installed the Rust 1.77 toolchain by following the instructions from the Rust 1.77.0 pre-release testing blog post.
Checklist

[x] I formatted the code cargo +nightly fmt --all
[x] I addressed lints thrown by cargo clippy
[x] I reviewed the submitted code
[ ] I added unit tests for my changes where possible
[ ] I added a CHANGELOG entry if applicable

Force merging this since cargo clippy has passed. Though not the best indicator that code will compile with Rust 1.77, it's sufficient enough to know that code compiles.


Extend WebSocketProtocol arguments

Extend WebSocketProtocol arguments to accept all arguments of websockets.protocol.WebSocketCommonProtocol
See http://websockets.readthedocs.io/en/stable/api.html?highlight=write_limit#websockets.protocol.WebSocketCommonProtocol

@boboldehampsink do you have time to add something to the docs about this?

@r0fls I really wouldn't know where in the current docs

no worries, we can add a new issue for it and get to it later then


Remove different-org rule for LGTM

We recently added a new rule to say that LGTM can only come from a different org from the submitter of a PR.  In practice, I'm finding that:

Very few people actively review PRs and respond to changes that address PR feedback on a daily basis
We only have a single organization with multiple people who actively contribute code on a regular basis
I do not think that we have the problem of undue leniency between people from the same organization that this rule was intended to prevent

For me personally, as the most active contributor to the project and arguably most qualified to review a change, I cannot give LGTM to the people from RH that I work closely with on this project, which means additional latency / lots of extra work hounding people who may not review on a daily basis for reviews.  That doesn't make sense to me.
So, I propose that we remove the rule.  Note that any substantial changes should already have consensus around the need for the change and broad strokes of the approach.

:+1: to this change. Note that we only recently added the rule in question.

@MHBauer I don't think that's an option.  We need to enable velocity and 3 LGTM works against that.

It seems to me that part of the problem is the reduced number of maintainers we have right now and that the "one vote per company rule" might be part of the bigger issue. I wonder if it wouldn't be better if we add more maintainers (I can think of at least one I'd like to add) but then go to 3 LTGMs.  This will allow more than one LGTM per company but, IMO, still attempt to keep quality up by not having such a low # of LGTMs.  I know I'm in the minority on this but I just do not think 2 is sufficient.

Could I suggest that we have an end-of-release SIG-Service-Catalog retrospective much as we do for the main Kubernetes release, and SIG-Apps?  This would give the entire group a chance to see if the more permissive LGTM policy was abused or not.  And, if so, you could set a per-release policy to 1:1 LGTM/Org.  I think the risk to velocity is always greater than the risk of a company co-opting a work stream, and having a checkpoint boundary where the group can make decisions allows everyone to know "it won't (necessarily) be this way forever, only for this release".  I volunteer to help facilitate that retro, should you choose to have it.

I had a good conversation with @duglin where it became clear to me that this is probably not the right lever to pull at this point, so I withdraw my PR.

I do want to say, for the record, that I think this needs to be rectified some how:

For me personally, as the most active contributor to the project and arguably most qualified to review a change, I cannot give LGTM to the people from RH that I work closely with on this project, which means additional latency / lots of extra work hounding people who may not review on a daily basis for reviews. That doesn't make sense to me.

@pmorie

I had a good conversation with @duglin where it became clear to me that this is probably not the right lever to pull at this point, so I withdraw my PR.

I'd be great if conversations leading to decisions are documented in some form e.g. notes with key points - for external observers this is important. And also for future us. You will probably not remember the details of the conversation in a couple of months :)

Also I agree with your point about velocity. That PR with rebase...

I believe we have an underlying problem here, and it’s not fewer maintainers, nor quality - it’s trust.
We’ve had a series of no-same-organization rules. Recall that prior to reducing to 2 LGTMs, we had a rule that no 2 people from the same organization could LGTM the same PR. We also had a rule that effected a “cool down period,” in which a PR could not be merged within 1 business day of its submission. All of this in the name of preventing a small group from rushing a PR into master before others could have a look at it.
Do we really not trust each other this much? We have design meetings regularly, in which we talk through medium or large changes, and we pay attention to, and even solicit, feedback from anybody — even non-owners — in our PRs.
This PR may not be perfect, but it is trying to allow us to increase in our development velocity, not to allow organizations to sneak or rush functionality in, purposefully or otherwise.
Right now, we all need to focus on building a high-quality system quickly. We know that this change will increase our velocity, and I believe that we have a high quality system right now. But we of course don’t know if it will lead to decreased quality (as you alluded to @duglin). Since we have no data that indicates what this change will do to our quality, if anything, I propose we do the following:

Be very clear, up front, on all the reasons that anyone opposes this change (if different from quality concerns)
Try this change out in the wild and have a retro (per @jdumars’s suggestion) after we’ve thoroughly tried it out

I’m suggesting that we try it out, and if someone doesn’t like it, they can present their case against the change in our retrospective. I'm also suggesting that we back out the change if there are data that show that it is decreasing our quality or otherwise negatively impacting the project.

I synced with @bmelville as well, and we're of the mind that we're fine trying this out.
From my perspective, I think the project is in a more mature place now, and there is less of a worry about a single company co-opting its direction. We're having very frequent collaborative design discussions, and 99% of the beta trajectory of the repo has been mapped out and is in agreement.
I'd say let's try this change, and if we ever feel like the new paradigm is either not working or being abused, we can go back and then discuss from there.

I am going to merge this now, and will also schedule the retrospective in a few weeks to discuss how we're liking (or not liking) this change.

Despite this being merged, which to be honest kind of surprised me and we can take that offline, I wanted to share some of my thoughts:

I don't think "trust" has anything to do with it. We originally setup some of those rules because enough of the group thought they made sense at the time. We didn't want to rush things, there were learning curves involved, there were lots of reasons. But things change and as they did we adjusted the rules. Seems logical to me.     :-)  so I have a gut negative reaction to it.

people have implied about our rules are slowing down our velocity to get to beta. I disagree. If we merged all open PRs right now I don't think it would fundamentally change the amount of work in front of us to get to beta nor would it unblock an beta work item. Let's be honest, none of us are that shy that we'd let a blocking PR linger for very long.

I would agree that its slowing down our velocity to merge PRs. I'm not happy we have 27 open PRs, I've said many times I get twitchy when we get over 10 :-)  but I'm not willing to compromise (what I consider) quality in order to reduce the backlog. I would prefer to attack that issue thru some other means - such as increase the # of maintainers or just simply more nagging.

does more LGTMs increase quality? Its going to be subjective. But I do feel confident to say that going with 2 will not increase our quality - at best it won't make it worse. So, what's the right number? 10? No, of course not and this is where each of our histories will influence what we think the number should be. Mine just happens to be 3 right now for this group.

I'm sure others will disagree and that's ok. Given we've had discussion like this several times so far it shouldn't surprised anyone that we'll probably never get unanimity on this topic. We'll just go with the majority. And, again, that's ok.  I just felt like the discussions so far have not been necessarily accurate w.r.t. the impact of the current rules.

Back to my renaming PR....


[0.5.0] Support dbt-labs/dbt_utils v0.7.0

Bump the upper bound on dbt_utils to <0.8.0, to support dbt-utils v0.7.0 (which is required for use with dbt v0.20.0)
❗ Update the dependency from fishtown-analytics/dbt_utils to dbt-labs/dbt_utils. This is a breaking-ish change
(https://discourse.getdbt.com/t/packages-dbt-labs-in-the-dbt-hub/2711) if users have other packages that install / depend on fishtown-analytics/dbt_utils. To avoid bad outcomes, I think this should require a minor version bump.

For the sake of clarity, we could choose to make a stronger delineation and have v0.5.0 of this package require dbt>=0.20.0 and dbt-utils>=0.7.0. It's not strictly required; someone could use v0.5.0 with dbt v0.19.0, so long as they pin dbt-labs/dbt_utils v0.6.6 and don't have another package that requires it as fishtown-analytics/dbt_utils.

Nice 👍 . I like your suggestion of being stricter on clarity for 0.20.0


[Enhancement] Move documentation from blog to github

Checks

[X] I confirm that I have searched for existing issues / pull requests before reporting to avoid duplicate reporting.
[X] I confirm that I noted that if I don't follow the instructions, the issue may be closed directly.

Description
I have been struggling to set this mod up. I find the blog visually cluttered, making it slightly harder to find what I want.

I cannot disagree with your opinion. I will rewrite and move the docs to a separate subdomain of xujiayao.com instead of GitHub, and it will not use the same theme as the blog.


The animations are not working on mobile devices, Strange

I have attached before and after images:

I'm not really sure what you're trying to communicate here. The library works on mobile, so you're going to need to provide more specific info about what's going wrong — the screenshots without context aren't sufficient.

by mobile I mean @gskinner flutter web, on mobile devices... the same works awesome on flutter web desktop browser but on mobile android and ios it don't show anything

Ah, so the animation is working on web on desktop, but not web on mobile? That is weird, and sounds more like a Flutter issue that a library one. Have you tested a super simple use case to narrow it down (ex. just a fresh Flutter web app with nothing but some animated text)?

Ok will try that, and update here. I made a ton of animations for my
app...but when I ran on phone it  plainly transitions into none and black
screen.
[image: Mailtrack]
https://mailtrack.io?utm_source=gmail&utm_medium=signature&utm_campaign=signaturevirality11&
Sender
notified by
Mailtrack
https://mailtrack.io?utm_source=gmail&utm_medium=signature&utm_campaign=signaturevirality11&
03/13/23,
01:58:02 AM
On Thu, Mar 9, 2023 at 4:57 AM Grant Skinner @.***>
wrote:

Ah, so the animation is working on web on desktop, but not web on mobile?
That is weird, and sounds more like a Flutter issue that a library one.
Have you tested a super simple use case to narrow it down (ex. just a fresh
Flutter web app with nothing but some animated text)?
—
Reply to this email directly, view it on GitHub
https://github.com/gskinner/flutter_animate/issues/71#issuecomment-1461051373,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AIRXJSAKX2JIUKYPEQOMYULW3EMFJANCNFSM6AAAAAAVSMWZTI
.
You are receiving this because you authored the thread.Message ID:
@.***>

I have no idea what the original poster wants to tell us with these screenshots but actually I am having the same issue.
Animations work on all devices but on my Iphone in Safari it just shows blank elements when I add an animation to a Widget. I build it with flutter 3.7.5