add message translations for oci

message translations for https://issues.redhat.com/browse/COST-2358

Codecov Report

Merging #2397 (c005181) into main (b9de03b) will not change coverage.
The diff coverage is n/a.

:exclamation: Current head c005181 differs from pull request most recent head 4386ea3. Consider uploading reports for the commit 4386ea3 to get more accurate results

@@           Coverage Diff            @@
##             main    #2397    +/-   ##
========================================
  Coverage   69.90%   69.90%
========================================
  Files         413      413
  Lines        7854     7854
  Branches     1853     1852     -1
========================================
  Hits         5490     5490
+ Misses       2361     2256   -105
- Partials        3      108   +105

Impacted Files
Coverage Δ

src/locales/messages.ts
100.00% <ø> (ø)

src/utils/cookie.ts
58.33% <0.00%> (ø)

src/utils/format.ts
67.00% <0.00%> (ø)

src/api/orgs/orgUtils.ts
37.50% <0.00%> (ø)

src/api/queries/query.ts
43.85% <0.00%> (ø)

src/utils/localStorage.ts
78.66% <0.00%> (ø)

src/store/metrics/selectors.ts
75.86% <0.00%> (ø)

src/api/resources/resourceUtils.ts
17.18% <0.00%> (ø)

src/components/exports/exportsLink.tsx
43.75% <0.00%> (ø)

src/components/permissions/permissions.tsx
22.05% <0.00%> (ø)

... and 26 more

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 b9de03b...4386ea3. Read the comment docs.


ARROW-10917: [Doc] Update feature matrix for Rust

Updates matrix for work done since 2.0.0

The custom metadata is not implemented for in file footer, dictionary and record batch, should we add this into 3.0.0?

The custom metadata is not implemented for in file footer, dictionary and record batch, should we add this into 3.0.0?

The custom metadata is not implemented for file footer, dictionary and record batch, should we add this into 3.0.0?

Yes please, I thought it was implemented. Or do you mean in the IPC format? I'll untick it in the meantime

The custom metadata is not implemented for file footer, dictionary and record batch, should we add this into 3.0.0?

Yes please, I thought it was implemented. Or do you mean in the IPC format? I'll untick it in the meantime

The custom metadata is not implemented for file footer, dictionary and record batch, should we add this into 3.0.0?

Yes please, I thought it was implemented. Or do you mean in the IPC format? I'll untick it in the meantime
I mean the IPC format, I'll push some incomplete changes soon.

The custom metadata is not implemented for file footer, dictionary and record batch, should we add this into 3.0.0?

Yes please, I thought it was implemented. Or do you mean in the IPC format? I'll untick it in the meantime
I mean the IPC format, I'll push some incomplete changes soon.

@nevi-me  is this ready to go? I think the 3.0 release is just about to happen so we should probably merge it in soon (TM)

@nevi-me  is this ready to go? I think the 3.0 release is just about to happen so we should probably merge it in soon (TM)

I've taken the liberty of updating this PR. Will merge if CI green.

I've taken the liberty of updating this PR. Will merge if CI green.

Thank you @pitrou

Thank you @pitrou

Green CI on my fork: https://github.com/pitrou/arrow/actions/runs/480864596

Green CI on my fork: https://github.com/pitrou/arrow/actions/runs/480864596


Changes to _random opcodes and to hikey

Just some clarifications, mainly useful for people developing sfz players for the random opcodes.

Updated lo/hikey with this information, also clarifying that allowing -1 was added by the SFZ 2 spec.

Updated random stuff, also filling in some missing info about units (cents for pitch and cutoff) along the way.

As all the information in this PR has been added to the appropriate opcode pages, I suppose it can be closed now.


beta UniFi Network Application 8.0.24

** To work on PFSense 2.7 follow FIX/Work around SEE #328 **
beta UniFi Network Application 8.0.24
Firmware Overview/Details
Install command: fetch -o - https://rb.gy/4iq0kr | sh -s
beta UniFi Network Application 8.0.21
Firmware Overview/Details
Install command: fetch -o - https://rb.gy/xxesox | sh -s
*changed to https://rb.gy due to issued with https://shorturl.at
beta UniFi Network Application 8.0.7
Firmware Overview/Details
Install command: fetch -o - https://rb.gy/5p8f1o | sh -s
Install command: fetch -o - https://shorturl.at/pqsuG | sh -s
*changed to www.shorturl.at due to issued with tinyurl.com
*unifi.sh modification NOT required, commited to main branch already
beta UniFi Network Application 8.0.6
Firmware Overview/Details
Install command: fetch -o - https://rb.gy/6eirx2 | sh -s
Install command: fetch -o - https://shorturl.at/ckGO6 | sh -s
*unifi.sh modification NOT required, commited to main branch already
beta UniFi Network Application 8.0.2
Firmware Overview/Details
Install command: fetch -o - https://rb.gy/qfb8or | sh -s
Install command: fetch -o - https://shorturl.at/fnEGU | sh -s
Other required changes working for opnsense 23: saw some posted this fix for the log errors in the main Unifi forums page...
by User "doestergaard"
view post
/usr/local/etc/rc.d/unifi.sh
Try appending --add-opens=java.base/java.time=ALL-UNNAMED to your execstart:
ExecStart=/usr/bin/java --add-opens=java.base/java.time=ALL-UNNAMED -jar /opt/UniFi/lib/ace.jar
using winscp I modified
    # So we start it in the background and stash the pid:
    /usr/local/bin/java -jar /usr/local/UniFi/lib/ace.jar start &

to
    # So we start it in the background and stash the pid:
    /usr/local/bin/java --add-opens=java.base/java.time=ALL-UNNAMED -jar /usr/local/UniFi/lib/ace.jar start &

Update from Unifi 7.5.187 to Unifi 8.0.2, Successful (with the required changes in rc.d)
OPNsense 23.7.7_3-amd64
FreeBSD 13.2-RELEASE-p3
OpenSSL 1.1.1w 11 Sep 2023

Thanks a lot, after many weeks, I've decided to ditch pfsense for opnsense and finally I now have my Unifi controller back where I want it. I was getting error 404 initially but this turned out to be browser cache as was sorted in a private session.

I also lost the adoption of my AP but the last backup I had was a couple of revisions old.  All the settings restored so I just factory reset my AP and adopted as new. Back online now

Just wanted to let you know that the following script works without issue on pfSense Plus 23.09.1
beta UniFi Network Application 8.0.24
Firmware Overview/Details
Install command: fetch -o - https://rb.gy/4iq0kr | sh -s
No need to apply any fix after running the script.

Successfully upgraded from 8.0.7 on PFSense 2.7.2

How come these changes are not being merged into master?

How come these changes are not being merged into master?

not enough contributor/devs to verify and check before merging.
UniFi Network Application 8.0.28 is already official though. if more contributor would comment for a merge to main, which would mean that they have checked and tested.
I will also probably closing 7.x series as this 8.x series seems stable, except for the installation issues in other PFsense 2.7 systems

Just tested 8.1.104 on pfSense 23.09.1-RELEASE and unfortunately, it's not working.

Just tested 8.1.104 on pfSense 23.09.1-RELEASE and unfortunately, it's not working.
did you try #328 fix?
do you have specific error?

Just tested 8.1.104 on pfSense 23.09.1-RELEASE and unfortunately, it's not working.
did you try #328 fix?
do you have specific error?

I can't apply the fix in #328 because the link to download MongoDB isn't working anymore.
Here's the error after installation:
Starting UniFi controller.
<EMAIL_ADDRESS>07:12:36,079 |-INFO in ch.qos.logback.classic.LoggerContext[default] - This is logback-classic version 1.4.14
07:12:36,082 |-INFO in ch.qos.logback.classic.util.ContextInitializer@41488b16 - Here is a list of configurators discovered as a service, by rank:
07:12:36,082 |-INFO in ch.qos.logback.classic.util.ContextInitializer@41488b16 -   org.springframework.boot.logging.logback.RootLogLevelConfigurator
07:12:36,082 |-INFO in ch.qos.logback.classic.util.ContextInitializer@41488b16 - They will be invoked in order until ExecutionStatus.DO_NOT_INVOKE_NEXT_IF_ANY is returned.
07:12:36,082 |-INFO in ch.qos.logback.classic.util.ContextInitializer@41488b16 - Constructed configurator of type class org.springframework.boot.logging.logback.RootLogLevelConfigurator
07:12:36,094 |-INFO in ch.qos.logback.classic.util.ContextInitializer@41488b16 - org.springframework.boot.logging.logback.RootLogLevelConfigurator.configure() call lasted 0 milliseconds. ExecutionStatus=INVOKE_NEXT_IF_ANY
07:12:36,094 |-INFO in ch.qos.logback.classic.util.ContextInitializer@41488b16 - Trying to configure with ch.qos.logback.classic.joran.SerializedModelConfigurator
07:12:36,094 |-INFO in ch.qos.logback.classic.util.ContextInitializer@41488b16 - Constructed configurator of type class ch.qos.logback.classic.joran.SerializedModelConfigurator
07:12:36,097 |-INFO in ch.qos.logback.classic.LoggerContext[default] - Could NOT find resource [logback-test.scmo]
07:12:36,098 |-INFO in ch.qos.logback.classic.LoggerContext[default] - Could NOT find resource [logback.scmo]
07:12:36,098 |-INFO in ch.qos.logback.classic.util.ContextInitializer@41488b16 - ch.qos.logback.classic.joran.SerializedModelConfigurator.configure() call lasted 4 milliseconds. ExecutionStatus=INVOKE_NEXT_IF_ANY
07:12:36,098 |-INFO in ch.qos.logback.classic.util.ContextInitializer@41488b16 - Trying to configure with ch.qos.logback.classic.util.DefaultJoranConfigurator
07:12:36,098 |-INFO in ch.qos.logback.classic.util.ContextInitializer@41488b16 - Constructed configurator of type class ch.qos.logback.classic.util.DefaultJoranConfigurator
07:12:36,102 |-INFO in ch.qos.logback.classic.LoggerContext[default] - Found resource [logback-test.xml] at [jar:file:/usr/local/UniFi/lib/ace.jar!/logback-test.xml]
07:12:36,108 |-INFO in ch.qos.logback.core.joran.spi.ConfigurationWatchList@a8ef162 - URL [jar:file:/usr/local/UniFi/lib/ace.jar!/logback-test.xml] is not of type file
07:12:36,225 |-INFO in ch.qos.logback.core.model.processor.AppenderModelHandler - Processing appender named [server_log]
07:12:36,225 |-INFO in ch.qos.logback.core.model.processor.AppenderModelHandler - About to instantiate appender of type [ch.qos.logback.core.rolling.RollingFileAppender]
07:12:36,235 |-INFO in ch.qos.logback.core.rolling.FixedWindowRollingPolicy@2eea88a1 - No compression will be used
07:12:36,238 |-ERROR in ch.qos.logback.core.model.processor.ImplicitModelHandler - Could not create component [filter] of type [com.ubnt.ace.logs.SkipLoggersPrintingToDedicatedFileOnly] java.lang.ClassNotFoundException: com.ubnt.ace.logs.SkipLoggersPrintingToDedicatedFileOnly
at java.lang.ClassNotFoundException: com.ubnt.ace.logs.SkipLoggersPrintingToDedicatedFileOnly
at      at java.base/jdk.internal.loader.BuiltinClassLoader.loadClass(BuiltinClassLoader.java:641)
at      at java.base/jdk.internal.loader.ClassLoaders$AppClassLoader.loadClass(ClassLoaders.java:188)
at      at java.base/java.lang.ClassLoader.loadClass(ClassLoader.java:525)
at      at ch.qos.logback.core.util.Loader.loadClass(Loader.java:132)
at      at ch.qos.logback.core.model.processor.ImplicitModelHandler.doComplex(ImplicitModelHandler.java:134)
at      at ch.qos.logback.core.model.processor.ImplicitModelHandler.handle(ImplicitModelHandler.java:94)
at      at ch.qos.logback.core.model.processor.DefaultProcessor.secondPhaseTraverse(DefaultProcessor.java:241)
at      at ch.qos.logback.core.model.processor.DefaultProcessor.secondPhaseTraverse(DefaultProcessor.java:253)
at      at ch.qos.logback.core.model.processor.DefaultProcessor.secondPhaseTraverse(DefaultProcessor.java:253)
at      at ch.qos.logback.core.model.processor.DefaultProcessor.traversalLoop(DefaultProcessor.java:90)
at      at ch.qos.logback.core.model.processor.DefaultProcessor.process(DefaultProcessor.java:106)
at      at ch.qos.logback.core.joran.GenericXMLConfigurator.processModel(GenericXMLConfigurator.java:208)
at      at ch.qos.logback.core.joran.GenericXMLConfigurator.doConfigure(GenericXMLConfigurator.java:170)
at      at ch.qos.logback.core.joran.GenericXMLConfigurator.doConfigure(GenericXMLConfigurator.java:122)
at      at ch.qos.logback.core.joran.GenericXMLConfigurator.doConfigure(GenericXMLConfigurator.java:65)
at      at ch.qos.logback.classic.util.DefaultJoranConfigurator.configureByResource(DefaultJoranConfigurator.java:68)
at      at ch.qos.logback.classic.util.DefaultJoranConfigurator.configure(DefaultJoranConfigurator.java:35)
at      at ch.qos.logback.classic.util.ContextInitializer.invokeConfigure(ContextInitializer.java:128)
at      at ch.qos.logback.classic.util.ContextInitializer.autoConfig(ContextInitializer.java:103)
at      at ch.qos.logback.classic.util.ContextInitializer.autoConfig(ContextInitializer.java:66)
at      at ch.qos.logback.classic.spi.LogbackServiceProvider.initializeLoggerContext(LogbackServiceProvider.java:52)
at      at ch.qos.logback.classic.spi.LogbackServiceProvider.initialize(LogbackServiceProvider.java:41)
at      at org.slf4j.LoggerFactory.bind(LoggerFactory.java:195)
at      at org.slf4j.LoggerFactory.performInitialization(LoggerFactory.java:182)
at      at org.slf4j.LoggerFactory.getProvider(LoggerFactory.java:490)
at      at org.slf4j.LoggerFactory.getILoggerFactory(LoggerFactory.java:476)
at      at org.slf4j.LoggerFactory.getLogger(LoggerFactory.java:425)
at      at com.ubnt.service.system.OO0oo.null(Unknown Source)
at      at com.ubnt.service.system.OO0oo.(Unknown Source)
at      at com.ubnt.ace.Launcher.(Unknown Source)
07:12:36,239 |-INFO in ch.qos.logback.core.model.processor.ImplicitModelHandler - Assuming default type [ch.qos.logback.classic.encoder.PatternLayoutEncoder] for [encoder] property
07:12:36,258 |-INFO in ch.qos.logback.core.rolling.RollingFileAppender[server_log] - Active log file name: logs/server.log
07:12:36,258 |-INFO in ch.qos.logback.core.rolling.RollingFileAppender[server_log] - File property is set to [logs/server.log]
07:12:36,259 |-INFO in ch.qos.logback.core.model.processor.AppenderModelHandler - Processing appender named [state_log]
07:12:36,259 |-INFO in ch.qos.logback.core.model.processor.AppenderModelHandler - About to instantiate appender of type [ch.qos.logback.core.rolling.RollingFileAppender]
07:12:36,259 |-INFO in ch.qos.logback.core.rolling.FixedWindowRollingPolicy@16612a51 - No compression will be used
07:12:36,259 |-INFO in ch.qos.logback.core.model.processor.ImplicitModelHandler - Assuming default type [ch.qos.logback.classic.encoder.PatternLayoutEncoder] for [encoder] property
07:12:36,260 |-INFO in ch.qos.logback.core.rolling.RollingFileAppender[state_log] - Active log file name: logs/state.log
07:12:36,260 |-INFO in ch.qos.logback.core.rolling.RollingFileAppender[state_log] - File property is set to [logs/state.log]
07:12:36,260 |-INFO in ch.qos.logback.core.model.processor.AppenderModelHandler - Processing appender named [migration_log]
07:12:36,260 |-INFO in ch.qos.logback.core.model.processor.AppenderModelHandler - About to instantiate appender of type [ch.qos.logback.core.rolling.RollingFileAppender]
07:12:36,260 |-INFO in ch.qos.logback.core.rolling.FixedWindowRollingPolicy@54e041a4 - No compression will be used
07:12:36,260 |-INFO in ch.qos.logback.core.model.processor.ImplicitModelHandler - Assuming default type [ch.qos.logback.classic.encoder.PatternLayoutEncoder] for [encoder] property
07:12:36,261 |-INFO in ch.qos.logback.core.rolling.RollingFileAppender[migration_log] - Active log file name: logs/migration.log
07:12:36,261 |-INFO in ch.qos.logback.core.rolling.RollingFileAppender[migration_log] - File property is set to [logs/migration.log]
07:12:36,261 |-INFO in ch.qos.logback.core.model.processor.AppenderModelHandler - Processing appender named [tasks_log]
07:12:36,261 |-INFO in ch.qos.logback.core.model.processor.AppenderModelHandler - About to instantiate appender of type [ch.qos.logback.core.rolling.RollingFileAppender]
07:12:36,261 |-INFO in ch.qos.logback.core.rolling.FixedWindowRollingPolicy@2c78324b - No compression will be used
07:12:36,261 |-INFO in ch.qos.logback.core.model.processor.ImplicitModelHandler - Assuming default type [ch.qos.logback.classic.encoder.PatternLayoutEncoder] for [encoder] property
07:12:36,262 |-INFO in ch.qos.logback.core.rolling.RollingFileAppender[tasks_log] - Active log file name: logs/tasks.log
07:12:36,262 |-INFO in ch.qos.logback.core.rolling.RollingFileAppender[tasks_log] - File property is set to [logs/tasks.log]
07:12:36,262 |-INFO in ch.qos.logback.core.model.processor.AppenderModelHandler - Processing appender named [hotspot_log]
07:12:36,262 |-INFO in ch.qos.logback.core.model.processor.AppenderModelHandler - About to instantiate appender of type [ch.qos.logback.core.rolling.RollingFileAppender]
07:12:36,262 |-INFO in ch.qos.logback.core.rolling.FixedWindowRollingPolicy@79defdc - No compression will be used
07:12:36,262 |-INFO in ch.qos.logback.core.model.processor.ImplicitModelHandler - Assuming default type [ch.qos.logback.classic.encoder.PatternLayoutEncoder] for [encoder] property
07:12:36,263 |-INFO in ch.qos.logback.core.rolling.RollingFileAppender[hotspot_log] - Active log file name: logs/hotspot.log
07:12:36,263 |-INFO in ch.qos.logback.core.rolling.RollingFileAppender[hotspot_log] - File property is set to [logs/hotspot.log]
07:12:36,263 |-INFO in ch.qos.logback.core.model.processor.AppenderModelHandler - Processing appender named [inform_request_log]
07:12:36,263 |-INFO in ch.qos.logback.core.model.processor.AppenderModelHandler - About to instantiate appender of type [ch.qos.logback.core.rolling.RollingFileAppender]
07:12:36,263 |-INFO in ch.qos.logback.core.rolling.FixedWindowRollingPolicy@18317edc - No compression will be used
07:12:36,263 |-INFO in ch.qos.logback.core.model.processor.ImplicitModelHandler - Assuming default type [ch.qos.logback.classic.encoder.PatternLayoutEncoder] for [encoder] property
07:12:36,263 |-INFO in ch.qos.logback.core.rolling.RollingFileAppender[inform_request_log] - Active log file name: logs/inform_request.log
07:12:36,263 |-INFO in ch.qos.logback.core.rolling.RollingFileAppender[inform_request_log] - File property is set to [logs/inform_request.log]
07:12:36,264 |-INFO in ch.qos.logback.core.model.processor.AppenderModelHandler - Processing appender named [InMemoryAppender]
07:12:36,264 |-INFO in ch.qos.logback.core.model.processor.AppenderModelHandler - About to instantiate appender of type [com.ubnt.ace.logs.InMemoryAppender]
07:12:36,265 |-INFO in ch.qos.logback.core.model.processor.ImplicitModelHandler - Assuming default type [ch.qos.logback.classic.encoder.PatternLayoutEncoder] for [encoder] property
07:12:36,265 |-INFO in ch.qos.logback.core.model.processor.AppenderModelHandler - Processing appender named [AnalyticsAppender]
07:12:36,265 |-INFO in ch.qos.logback.core.model.processor.AppenderModelHandler - About to instantiate appender of type [com.ubnt.service.trace.logerror.AnalyticsAppender]
07:12:36,919 |-INFO in ch.qos.logback.classic.model.processor.LoggerModelHandler - Setting level of logger [java] to ERROR
07:12:36,919 |-INFO in ch.qos.logback.classic.model.processor.LoggerModelHandler - Setting level of logger [javax] to ERROR
07:12:36,919 |-INFO in ch.qos.logback.classic.model.processor.LoggerModelHandler - Setting level of logger [javax.jmdns] to OFF
07:12:36,920 |-INFO in ch.qos.logback.classic.model.processor.LoggerModelHandler - Setting level of logger [sun] to ERROR
07:12:36,920 |-INFO in ch.qos.logback.classic.model.processor.LoggerModelHandler - Setting level of logger [org.apache] to WARN
07:12:36,920 |-INFO in ch.qos.logback.classic.model.processor.LoggerModelHandler - Setting level of logger [httpclient.wire] to WARN
07:12:36,920 |-INFO in ch.qos.logback.classic.model.processor.LoggerModelHandler - Setting level of logger [net.schmizz] to ERROR
07:12:36,920 |-INFO in ch.qos.logback.classic.model.processor.LoggerModelHandler - Setting level of logger [com.codahale] to ERROR
07:12:36,920 |-INFO in ch.qos.logback.classic.model.processor.LoggerModelHandler - Setting level of logger [org.apache.tomcat] to ERROR
07:12:36,920 |-INFO in ch.qos.logback.classic.model.processor.LoggerModelHandler - Setting level of logger [org.apache.commons] to WARN
07:12:36,920 |-INFO in ch.qos.logback.classic.model.processor.LoggerModelHandler - Setting level of logger [org.apache.catalina] to ERROR
07:12:36,920 |-INFO in ch.qos.logback.classic.model.processor.LoggerModelHandler - Setting level of logger [org.hibernate.validator] to WARN
07:12:36,920 |-INFO in ch.qos.logback.classic.model.processor.LoggerModelHandler - Setting level of logger [com.mongodb] to ERROR
07:12:36,920 |-INFO in ch.qos.logback.classic.model.processor.LoggerModelHandler - Setting level of logger [org.mongodb] to ERROR
07:12:36,920 |-INFO in ch.qos.logback.classic.model.processor.LoggerModelHandler - Setting level of logger [org.springframework] to WARN
07:12:36,920 |-INFO in ch.qos.logback.classic.model.processor.LoggerModelHandler - Setting level of logger [de.javawi.jstun] to WARN
07:12:36,920 |-INFO in ch.qos.logback.classic.model.processor.LoggerModelHandler - Setting level of logger [com.ubnt] to INFO
07:12:36,920 |-INFO in ch.qos.logback.classic.model.processor.LoggerModelHandler - Setting level of logger [com.ubiquiti] to INFO
07:12:36,920 |-INFO in ch.qos.logback.classic.model.processor.LoggerModelHandler - Setting level of logger [com.amazonaws.internal] to WARN
07:12:36,920 |-INFO in ch.qos.logback.classic.model.processor.LoggerModelHandler - Setting level of logger [springfox] to WARN
07:12:36,920 |-INFO in ch.qos.logback.core.model.processor.AppenderRefModelHandler - Attaching appender named [state_log] to Logger[state]
07:12:36,921 |-INFO in ch.qos.logback.core.model.processor.AppenderRefModelHandler - Attaching appender named [migration_log] to Logger[migration]
07:12:36,921 |-INFO in ch.qos.logback.core.model.processor.AppenderRefModelHandler - Attaching appender named [tasks_log] to Logger[tasks]
07:12:36,921 |-INFO in ch.qos.logback.core.model.processor.AppenderRefModelHandler - Attaching appender named [hotspot_log] to Logger[guest]
07:12:36,921 |-INFO in ch.qos.logback.core.model.processor.AppenderRefModelHandler - Attaching appender named [inform_request_log] to Logger[inform_request]
07:12:36,921 |-INFO in ch.qos.logback.classic.model.processor.RootLoggerModelHandler - Setting level of ROOT logger to INFO
07:12:36,921 |-INFO in ch.qos.logback.core.model.processor.AppenderRefModelHandler - Attaching appender named [server_log] to Logger[ROOT]
07:12:36,921 |-INFO in ch.qos.logback.core.model.processor.AppenderRefModelHandler - Attaching appender named [InMemoryAppender] to Logger[ROOT]
07:12:36,921 |-INFO in ch.qos.logback.core.model.processor.AppenderRefModelHandler - Attaching appender named [AnalyticsAppender] to Logger[ROOT]
07:12:36,921 |-INFO in ch.qos.logback.core.model.processor.DefaultProcessor@4e0ae11f - End of configuration.
07:12:36,922 |-INFO in ch.qos.logback.classic.joran.JoranConfigurator@238d68ff - Registering current configuration as safe fallback point
07:12:36,922 |-INFO in ch.qos.logback.classic.util.ContextInitializer@41488b16 - ch.qos.logback.classic.util.DefaultJoranConfigurator.configure() call lasted 824 milliseconds. ExecutionStatus=DO_NOT_INVOKE_NEXT_IF_ANY

I have almost the same error, since there is too much test but mine seemed to work it is OPNSENSE though.
what is the last working firmware version you tried?

I have almost the same error, since there is too much text to compare but mine seemed to work, it is on OPNSENSE though. what is the last working firmware version you tried?

I had to go back to 8.0.24. All other versions give me a 404 when loading the page.
I'll test again later and I'll keep you in touch.

hmmm there is actauly not much change since 8.0.24 except the firmware itself.
maybe you can try also a clean install of unifi (then just reload a backup copy of your site, if unifi works)

hmmm there is actauly not much change since 8.0.24 except the firmware itself. maybe you can try also a clean install of unifi (then just reload a backup copy of your site, if unifi works)
sometime it takes 2 to 5 minutes for unifi to load/start some times i need to restart the server.

8.0.28 finally works fine.

None of the versions are working now on 2.7.2, as the link "http://pkg.freebsd.org/FreeBSD:13:amd64/latest/All/mongodb44-4.4.25.pkg" is dead.
You cannot complete the workaround anymore, because the needed package is missing.
How can we fix this?

None of the versions are working now on 2.7.2, as the link "http://pkg.freebsd.org/FreeBSD:13:amd64/latest/All/mongodb44-4.4.25.pkg" is dead.
You cannot complete the workaround anymore, because the needed package is missing.
How can we fix this?

Perhaps try the latest version: https://pkg.freebsd.org/FreeBSD:13:amd64/latest/All/mongodb44-4.4.28.pkg

Failed to install the following 1 package(s): https://pkg.freebsd.org/FreeBSD:14:amd64/latest/ "

The last part of the URL is missing? should be:
https://pkg.freebsd.org/FreeBSD:13:amd64/latest/All/mongodb44-4.4.28.pkg

The workaround itself does not work, as the script will not complete. It halts when it reaches mongodb, and will not proceed. Even if you install mongodb44-4.4.28.pkg, it will not proceed, nor fetch UniFi.zip, nor any of it.

The workaround itself does not work, as the script will not complete. It halts when it reaches mongodb, and will not proceed. Even if you install mongodb44-4.4.28.pkg, it will not proceed, nor fetch UniFi.zip, nor any of it.

Exact same issue here with the 8.0.28 script.
I upgraded successfully 2 weeks ago; the pull-request has changed in the mean time: https://github.com/unofficial-unifi/unifi-pfsense/pull/332#issuecomment-1913070772
So it's not caused by your PFsense installation.

So how do we get the script to complete? Any ideas?

With mongodb44-4.4.28 installed, now it is saying "ld-elf.so.1: Shared object "libcrypto.so.111" not found, required by "mongod"" when you run the script.

I keep getting the same error as you with both the 8.1.104 as well as 8.0.28 script.
Thus being unable to upgrade from 8.0.28 to 8.1.104.
[...]
Package yaml-cpp-0.8.0 already installed.
Usage: pkg lock [-lqy] [-a|[-Cgix] <pkg-name>]
       pkg lock --has-locked-packages
       pkg unlock [-lqy] [-a|[-Cgix] <pkg-name>]
For more information see 'pkg help lock'.
Fetching : . done
pkg: Impossible to get the value from Last-Modified HTTP header
pkg: archive_read_open_filename(/tmp/.XXXXX): Unrecognized archive format

Failed to install the following 1 package(s): https://pkg.freebsd.org/FreeBSD:14:amd64/latest/

Seems to me there is something going on with the line that installs mongodb / getting the current version.
AddPkg ${CURRENT_MONGODB_VERSION}
command:
pkg info | grep mongodb
does return:
mongodb44-4.4.28               Distributed document-oriented "NoSQL" database (4.4.x Branch)
Not sure why this happens. The controller still runs fine and is online on v8.0.24. Perhaps @tong2x can have a look.

there are open issue relating to PFSense having its SSL Library not fully 3.0, not quite sure about this
but this relate to the mongodb library. there should be not much of a code change only the actual unifi firmware changes.
Please check/report openssl version and PFsense version

I am on the latest pFsense Plus, 23.09.1. OpenSSL OpenSSL 3.0.12. So the problem is not old OpenSSL in my case. The script halts on mongodb. Installing FreeBSD:13 and re-running the script doesn't fix it - still halts at mongodb. I cannot get the script to complete. It worked BEFORE the link we were using went dead.

could it be that your PFsense version requires newer mongoDB versions?
I have set a limit for this script to mongodb44 becuase allowing more version cuase more openssl error before

I am on the latest pFsense Plus, 23.09.1. OpenSSL 3.0.12. So the problem is not old OpenSSL in my case. The script halts on mongodb. Installing FreeBSD:13 mongodb and re-running the script doesn't fix it - still halts at mongodb. I cannot get the script to complete. It worked BEFORE the link we were using went dead. I ran it successfully on 2.7.2 with the latest script. Then tried to give opnsense a go (didn't like it). Switched to pfSense plus. In the few days that transpired, the link went dead and the script stopped working.

Maybe? When it was on a clean install of 2.7.2, and before the link went dead, it installed fine. Ran without a hitch.

I am on the latest pFsense Plus, 23.09.1. OpenSSL 3.0.12. So the problem is not old OpenSSL in my case. The script halts on mongodb. Installing FreeBSD:13 mongodb and re-running the script doesn't fix it - still halts at mongodb. I cannot get the script to complete. It worked BEFORE the link we were using went dead. I ran it successfully on 2.7.2 with the latest script. Then tried to give opnsense a go (didn't like it). Switched to pfSense plus. In the few days that transpired, the link went dead and the script stopped working.

I also have the same issue on pfSense plus but I found a way to install it.
Simply comment the line "AddPkg ${CURRENT_MONGODB_VERSION}" and the installation will keep going as long as you already have MongoDB installed.
I'm personally running mongodb44-4.4.28 and the installation works fine as long as the line "AddPkg ${CURRENT_MONGODB_VERSION}" is commented.

Where is it storing the install script when you run the fetch command, or do I need to cut and paste, create the script locally?

Where is it storing the install script when you run the fetch command, or do I need to cut and paste, create the script locally?

I'm unsure where it stores it but the easiest way is to copy and paste it in a bash script and then run "bash filename.bash"

That worked, but now I get the same error as @CryptoSiD posted up there. Won't start.

at first time it will load slower 3 to 5minutes, maybe DB migration.
it will be faster next time, if error is 404 most probably it is not loaded yet

If it indicates "Port 8080 not available" it will sit on "Please wait a moment" forever.
EDIT: Still waiting a moment after a half hour.

goto your firewall and get the PID
goto shell and kill PID
in opnsense it is settings->diagnostics->activity
bin/mongod --dbpath /usr/local/UniFi/data
or check all with unifi
after killing the pid in shell try to run again or run installer script if a bad install

This is what is turning up: 82115 root         20    0    10G   581M kqread   3   0:00   0.00% /usr/local/openjdk17/bin/java --add-opens=java.base/java.time=ALL-UNNAMED -jar /usr/local/UniFi/lib/ace.jar start{http-nio-8080-Polle}
It's that ace.jar that the script supposed to kill.

yes normally I kill that and rerun the installer script or just start the installed script.
but if the app itself is hanging, this might not work, but you can try

killing 1 should kill all
but maybe it is an issue with mongodb hanging or not laoding completely
have you tried a clean install?

Finally got sumbitch to work.
Alright, you have to be on pFsense Plus, 23.09.1. OpenSSL 3.0.12.
DO NOT install an old mogodb from FreeBSD 13 - you don't need it.
You DO however need a newer version of mongodb for Free BSD14, as the version linked is not there.
I used this command to get it to install: /usr/sbin/pkg add -f "https://repo.nepustil.net/FreeBSD:14:amd64/.latest/All/mongodb44-4.4.28.pkg"
Once it installs, you have to create a local copy of the install script so you can modify it. I installed nano, went in and commented out the line:  AddPkg ${CURRENT_MONGODB_VERSION}
Then the script completes and UniFi will run, and you can restore your backup.

You have to go into Firewall / pfBlockerNG / DNSBL and set your DNSBL Webserver Configuration to not conflict with UniFi. Set your port to 8081 and your SSL port to 8444.
I think that was the final obstacle. Now the current version 8.1.104 is running once again.
Hope this helps.

does this mean the script is getting incorrect or invalid mongoDB links?
or getting the package with the invalid mongoDB?
the install script should have supposedly check the type of system, modified the package URL and downloaded the correct one.
maybe could some check if the listed repo is mostly late in updating

Script worked perfectly this time. Thank you!

Script worked perfectly this time. Thank you!

may we know your firewall version/base?

8.1.107 works fine on pfSense plus 23.09.1-RELEASE

I am on 23.09.1

Version 8.1.111 works properly on pfSense plus 23.09.1

Version 8.1.113 works perfectly on pfSense plus 23.09.1

8.1.122 works perfectly on pfSense plus 23.09.1 :)

working on
OPNsense 24.1.4-amd64
FreeBSD 13.2-RELEASE-p10
OpenSSL 3.0.13

Tested on...
OPNsense 24.1.5_3-amd64
FreeBSD 13.2-RELEASE-p11
OpenSSL 3.0.13

8.1.124 works perfectly on pfSense plus 23.09.1
Thank you.

8.1.127 works perfectly on pfSense plus 23.09.1
Thank you.

tested on...
OPNsense 24.1.7_4-amd64
FreeBSD 13.2-RELEASE-p11
OpenSSL 3.0.13

Version 8.2.87 tested on pfSense 24.03-RELEASE, working perfectly!

Version 8.2.93 tested on pfSense 24.03-RELEASE, working perfectly!

tested on OPNSENSE
OPNsense 24.1.8-amd64
FreeBSD 13.2-RELEASE-p11
OpenSSL 3.0.13

Version 8.3.20 tested on pfSense Plus 24.03-RELEASE, working perfectly!

Note working any more on
OPNSense 24.7
FreeBSD 14.1

installer installed correctly in OPNSENSE 24.7.1 but seem mongoDB is hanging...
tried mongoDB 7.0, not it is set to mongoDB 5.0
please try in PFsense

It's borked. Controller won't start. Can't roll back to previous version.

Church the mongo log - most likely feature level issue. Downgrade mongo, change feature level an upgrade again.
On August 21, 2024 12:36:19 PM GMT+02:00, n3IVI0 @.***> wrote:

It's borked. Controller won't start. Can't roll back to previous version.
--
Reply to this email directly or view it on GitHub:
https://github.com/unofficial-unifi/unifi-pfsense/pull/332#issuecomment-2301722369
You are receiving this because you are subscribed to this thread.
Message ID: @.***>
--
Verstuurd vanaf mijn Android apparaat met K-9 Mail. Excuseer mijn beknoptheid.

... happened to me too, the install script is not updating the FeatureCompatibilityVersion.
I had mongodb42 running and after mongodb50 got installed, mongod wouldn't start anymore
complaining about the FeatureCompatibilityVersion.
So I installed mongodb44 from [ https://pkg.freebsd.org/FreeBSD:14:amd64/quarterly/ | https://pkg.freebsd.org/FreeBSD:14:amd64/quarterly/ ]
which made mongod start again. Next set the FeatureCompatibilityVersion to 4.4 (was 4.2)
and after that I upgraded to mongodb50 and set the FeatureCompatibilityVersion to 5.0
Things are working fine now.
I had another system that was running mongodb44, it successfully upgraded to mongodb50
but it did not update the FeatureCompatibilityVersion - updated that one to to 5.0.
Van: "n3IVI0" @.>
Aan: "unofficial-unifi/unifi-pfsense" @.>
Cc: "Subscribed" @.***>
Verzonden: Woensdag 21 augustus 2024 12:36:19
Onderwerp: Re: [unofficial-unifi/unifi-pfsense] beta UniFi Network Application 8.4.59 (PR #332)
It's borked. Controller won't start. Can't roll back to previous version.
—
Reply to this email directly, [ https://github.com/unofficial-unifi/unifi-pfsense/pull/332#issuecomment-2301722369 | view it on GitHub ] , or [ https://github.com/notifications/unsubscribe-auth/ABEX3MQXJOSIPYRLBOKGJBLZSRUSHAVCNFSM6AAAAAA6TUKKTKVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDGMBRG4ZDEMZWHE | unsubscribe ] .
You are receiving this because you are subscribed to this thread. Message ID: @.***>

was able to start Unifi controller
Opnsense 24.7.1, clean install and installed it twice and let it sit for more than 2 hours...

@dvdp
how do you set compability mode via command?
could you post command also to uninstall and install mongoDB? via command line

ithink that was the initial failure in freebsd14, mongodb44. hence I first switch to mongodb70, which should be compatible to unifi controller 8.1

You're on FreeBSD 15 - unlike me, I'm on 14
So you'll need to dig up the correct package for that version
Van: "n3IVI0" @.>
Aan: "unofficial-unifi/unifi-pfsense" @.>
Cc: "danny vandepol" @.>, "Mention" @.>
Verzonden: Woensdag 21 augustus 2024 14:23:01
Onderwerp: Re: [unofficial-unifi/unifi-pfsense] beta UniFi Network Application 8.4.59 (PR #332)
pkg add [ https://pkg.freebsd.org/FreeBSD:14:amd64/quarterly/All/mongodb44-4.4.29.pkg | https://pkg.freebsd.org/FreeBSD:14:amd64/quarterly/All/mongodb44-4.4.29.pkg ]
Fetching mongodb44-4.4.29.pkg: 100% 42 MiB 4.9MB/s 00:09
Installing mongodb44-4.4.29...
pkg: wrong architecture: FreeBSD:14:amd64 instead of FreeBSD:15:amd64
Failed to install the following 1 package(s): [ https://pkg.freebsd.org/FreeBSD:14:amd64/quarterly/All/mongodb44-4.4.29.pkg | https://pkg.freebsd.org/FreeBSD:14:amd64/quarterly/All/mongodb44-4.4.29.pkg ]
Can't install mongodb44
—
Reply to this email directly, [ https://github.com/unofficial-unifi/unifi-pfsense/pull/332#issuecomment-2301921699 | view it on GitHub ] , or [ https://github.com/notifications/unsubscribe-auth/ABEX3MR46F3RGMK6NIGOOLLZSSBCLAVCNFSM6AAAAAA6TUKKTKVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDGMBRHEZDCNRZHE | unsubscribe ] .
You are receiving this because you were mentioned. Message ID: @.***>

In one shell start mongod (adapt the db path if needed to match your setup)
mongod --port 27117 -dbpath /usr/local/UniFi/data/db
if your mongodb binary is supported by the featureCompatibilityVersion in the db it will keep on running
if not it will shutdown and return to the command prompt, if so uninstall and install the required version
In another shell launch
mongo --port 27117
this will give you an interactive mongo shell, then to check the current setting enter
db.adminCommand(
{
getParameter: 1,
featureCompatibilityVersion: 1
}
)
change to e.g. 4.4 with
db.adminCommand(
{
setFeatureCompatibilityVersion: "4.4",
}
)
and check it again if you like and finally
exit
Van: "tong2x" @.>
Aan: "unofficial-unifi/unifi-pfsense" @.>
Cc: "danny vandepol" @.>, "Mention" @.>
Verzonden: Woensdag 21 augustus 2024 14:22:14
Onderwerp: Re: [unofficial-unifi/unifi-pfsense] beta UniFi Network Application 8.4.59 (PR #332)
was able to start Unifi controller
Opnsense 24.7.1, clean install and installed it twice and let it sit for more than 2 hours...
[ https://github.com/user-attachments/assets/3c23d79e-7fbe-49e0-b67f-a54b63e1bc5b | image.png (view on web) ]
[ https://github.com/dvdp | @dvdp ]
how do you set compability mode via command?
could you post command also to uninstall and install mongoDB? via command line
—
Reply to this email directly, [ https://github.com/unofficial-unifi/unifi-pfsense/pull/332#issuecomment-2301920116 | view it on GitHub ] , or [ https://github.com/notifications/unsubscribe-auth/ABEX3MRKOP7J6O3UFEVRI5DZSSA7NAVCNFSM6AAAAAA6TUKKTKVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDGMBRHEZDAMJRGY | unsubscribe ] .
You are receiving this because you were mentioned. Message ID: @.***>

If you have a huge history, the database conversion could take quite a while I guess, stop and start again to find out ...
(I'm running a db prune job every now and then to reduce the history)
Van: "n3IVI0" @.>
Aan: "unofficial-unifi/unifi-pfsense" @.>
Cc: "danny vandepol" @.>, "Mention" @.>
Verzonden: Woensdag 21 augustus 2024 14:33:44
Onderwerp: Re: [unofficial-unifi/unifi-pfsense] beta UniFi Network Application 8.4.59 (PR #332)
I can see the changes in the script. Does it take 2 hours for the controller to start every time?
—
Reply to this email directly, [ https://github.com/unofficial-unifi/unifi-pfsense/pull/332#issuecomment-2301943363 | view it on GitHub ] , or [ https://github.com/notifications/unsubscribe-auth/ABEX3MWM3PDP37MS6F66NMDZSSCKRAVCNFSM6AAAAAA6TUKKTKVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDGMBRHE2DGMZWGM | unsubscribe ] .
You are receiving this because you were mentioned. Message ID: @.***>

So check in the logs what compatibility level you have and find a mongodb package for one above that version
(not sure how many you can skip before it starts complaining - check the mongodb website for that maybe)
Van: "n3IVI0" @.>
Aan: "unofficial-unifi/unifi-pfsense" @.>
Cc: "danny vandepol" @.>, "Mention" @.>
Verzonden: Woensdag 21 augustus 2024 14:47:00
Onderwerp: Re: [unofficial-unifi/unifi-pfsense] beta UniFi Network Application 8.4.59 (PR #332)
I am on pfSense 24.03. Which uses FreeBSD 15.
—
Reply to this email directly, [ https://github.com/unofficial-unifi/unifi-pfsense/pull/332#issuecomment-2301969836 | view it on GitHub ] , or [ https://github.com/notifications/unsubscribe-auth/ABEX3MXF4B6ZHLZEZXUO7Q3ZSSD4JAVCNFSM6AAAAAA6TUKKTKVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDGMBRHE3DSOBTGY | unsubscribe ] .
You are receiving this because you were mentioned. Message ID: @.***>

For the commands to uninstall/install I just grabbed some lines from the install-unifi.sh script
As I mentioned before, this worked for me on FreeBSD 14 to go back from 5.0 to 4.4
with 4.4 allowing me to step feature level from 4.2 to 4.4
get into an interactive shell
/bin/sh
unlock and remove
pkg unlock -yq mongodb50
pkg remove -yq mongodb50
removed mongodb50 from the list since that one was not working for my featureCompatibilityVersion 4.2
SUPPORTED_MONGODB_PACKAGES="mongodb44 mongodb42 mongodb40 mongodb"
ABI=/usr/sbin/pkg config abi
FREEBSD_PACKAGE_URL="https://pkg.freebsd.org/${ABI}/quarterly/"
I changed latest to quarterly - that one contains mongodb44
Build a list of possible packagesite.* URLs
for ext in pkg txz; do
FREEBSD_PACKAGE_LIST_URLS="$FREEBSD_PACKAGE_LIST_URLS ${FREEBSD_PACKAGE_URL}packagesite.${ext}"
done
Try each of the URLs in the list and exit if they all fail
if ! fetch -q1o - $FREEBSD_PACKAGE_LIST_URLS > packagesite.pkg 2> /dev/null; then
echo "Error downloading $FREEBSD_PACKAGE_LIST_URLS"
exit 1
fi
tar fx packagesite.pkg || exit 1
Find the latest supported mongodb version that's available in the repository
for package_name in $SUPPORTED_MONGODB_PACKAGES; do
if grep -q ""name":"$package_name"" packagesite.yaml; then
CURRENT_MONGODB_VERSION="$package_name"
break
fi
done
check the result - I needed mongodb44 so it should print that version
echo $ CURRENT_MONGODB_VERSION
if that matches the version you need, continue
pkgname=$ CURRENT_MONGODB_VERSION
base_url=${2:-$FREEBSD_PACKAGE_URL}
pkginfo=grep "\"name\":\"$pkgname\"" packagesite.yaml
pkgvers=echo $pkginfo | pcregrep -o1 '"version":"(.*?)"' | head -1
pkgurl="${base_url}echo $pkginfo | pcregrep -o1 '"path":"(.*?)"' | head -1"
one more check - this should print the full path to the pkg file
echo $pkgurl
if you like what you see, install and lock
/usr/sbin/pkg add -f "$pkgurl"
pkg lock $pkgname
and finally exit the shell
exit
After all this, I used pretty much the same code to go from 4.4 to 5.0

add mongodb50 back to the version list (first option of course)
change quarterly back to latest
unlock and uninstall mongodb40
Needless to say you need to stop mongod before removing ...

Van: "tong2x" @.>
Aan: "unofficial-unifi/unifi-pfsense" @.>
Cc: "danny vandepol" @.>, "Mention" @.>
Verzonden: Woensdag 21 augustus 2024 14:22:14
Onderwerp: Re: [unofficial-unifi/unifi-pfsense] beta UniFi Network Application 8.4.59 (PR #332)
was able to start Unifi controller
Opnsense 24.7.1, clean install and installed it twice and let it sit for more than 2 hours...
[ https://github.com/user-attachments/assets/3c23d79e-7fbe-49e0-b67f-a54b63e1bc5b | image.png (view on web) ]
[ https://github.com/dvdp | @dvdp ]
how do you set compability mode via command?
could you post command also to uninstall and install mongoDB? via command line
—
Reply to this email directly, [ https://github.com/unofficial-unifi/unifi-pfsense/pull/332#issuecomment-2301920116 | view it on GitHub ] , or [ https://github.com/notifications/unsubscribe-auth/ABEX3MRKOP7J6O3UFEVRI5DZSSA7NAVCNFSM6AAAAAA6TUKKTKVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDGMBRHEZDAMJRGY | unsubscribe ] .
You are receiving this because you were mentioned. Message ID: @.***>

Did a quick check, [ http://pkg.freebsd.org/FreeBSD:15:amd64/latest/ | http://pkg.freebsd.org/FreeBSD:15:amd64/latest/ ] contains
mongodb60, 70 and 80 ...
Van: "danny vandepol" @.>
Aan: "unofficial-unifi/unifi-pfsense" @.>
Verzonden: Woensdag 21 augustus 2024 14:33:24
Onderwerp: Re: [unofficial-unifi/unifi-pfsense] beta UniFi Network Application 8.4.59 (PR #332)
You're on FreeBSD 15 - unlike me, I'm on 14
So you'll need to dig up the correct package for that version
Van: "n3IVI0" @.>
Aan: "unofficial-unifi/unifi-pfsense" @.>
Cc: "danny vandepol" @.>, "Mention" @.>
Verzonden: Woensdag 21 augustus 2024 14:23:01
Onderwerp: Re: [unofficial-unifi/unifi-pfsense] beta UniFi Network Application 8.4.59 (PR #332)
pkg add [ https://pkg.freebsd.org/FreeBSD:14:amd64/quarterly/All/mongodb44-4.4.29.pkg | https://pkg.freebsd.org/FreeBSD:14:amd64/quarterly/All/mongodb44-4.4.29.pkg ]
Fetching mongodb44-4.4.29.pkg: 100% 42 MiB 4.9MB/s 00:09
Installing mongodb44-4.4.29...
pkg: wrong architecture: FreeBSD:14:amd64 instead of FreeBSD:15:amd64
Failed to install the following 1 package(s): [ https://pkg.freebsd.org/FreeBSD:14:amd64/quarterly/All/mongodb44-4.4.29.pkg | https://pkg.freebsd.org/FreeBSD:14:amd64/quarterly/All/mongodb44-4.4.29.pkg ]
Can't install mongodb44
—
Reply to this email directly, [ https://github.com/unofficial-unifi/unifi-pfsense/pull/332#issuecomment-2301921699 | view it on GitHub ] , or [ https://github.com/notifications/unsubscribe-auth/ABEX3MR46F3RGMK6NIGOOLLZSSBCLAVCNFSM6AAAAAA6TUKKTKVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDGMBRHEZDCNRZHE | unsubscribe ] .
You are receiving this because you were mentioned. Message ID: @.***>

When attempting to run the latest 8.5.1, fetch -o - https://t.ly/DPn0b | sh -s
I get this:

                                                   0  B    0  Bpssh: Syntax error: newline unexpected (expecting word)

What does this mean?

this is now using a higher mongodb 5.0 version due to freebsd14
but there seems to be a problem somewhere

fix the mongodb install issues on 2.7.0
#328
please check out thread there is instruction to reinstall mongoDB

I am on pfSense 24.03, FreeBSD 15.
When attempting to run the latest 8.5.1, fetch -o - https://t.ly/DPn0b | sh -s
I get this:
0 B 0 Bpssh: Syntax error: newline unexpected (expecting word)
What does this mean?
This can be bypassed by creating the install script manually via cut and paste. It then runs normally. Everything installs. But then the unifi controller will not start. It seems to hang. Cannot be closed. It waits for unifi service to stop forever.
I am also getting "WARN Unable to load properties from '/usr/local/UniFi/data/system.properties' - /usr/local/UniFi/data/system.properties (No such file or directory)" in the CLI.
I suspect this is the same problem of mongodb not starting, needing to rollback to mongodb44. Is this still the case?
If so, how do I rollback to mongodb44 on FreeBSD 15?

Will this work with the current version of pfSense+ / FreeBSD 15?

Hey. Check this out: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=277990
Seems the new mongodb50 is not compatible with our CPUs. This is the source of the illegal character errors. And why unifi hangs.

Yep, my CPU is non-AVX:
grep -i -e features -e avx /var/run/dmesg.boot
Features=0xbfebfbff<FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CLFLUSH,DTS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE>
Features2=0x43d8e3bf<SSE3,PCLMULQDQ,DTES64,MON,DS_CPL,VMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,SSE4.1,SSE4.2,MOVBE,POPCNT,TSCDLT,AESNI,RDRAND>
AMD Features=0x28100800<SYSCALL,NX,RDTSCP,LM>
AMD Features2=0x101<LAHF,Prefetch>
Structured Extended Features=0x2282<TSCADJ,SMEP,ERMS,NFPUSG>
Structured Extended Features3=0xc000000<IBPB,STIBP>
ZFS storage pool version: features support (5000)
Features=0xbfebfbff<FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CLFLUSH,DTS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE>
Features2=0x43d8e3bf<SSE3,PCLMULQDQ,DTES64,MON,DS_CPL,VMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,SSE4.1,SSE4.2,MOVBE,POPCNT,TSCDLT,AESNI,RDRAND>
AMD Features=0x28100800<SYSCALL,NX,RDTSCP,LM>
AMD Features2=0x101<LAHF,Prefetch>
Structured Extended Features=0x2282<TSCADJ,SMEP,ERMS,NFPUSG>
Structured Extended Features3=0xc000400<MD_CLEAR,IBPB,STIBP>
We need a version of mongodb50 that is compiled for non-AVX CPUs to work with these newer versions of the unifi controller.

Here is one: https://github.com/GermanAizek/mongodb-without-avx

would newer mongodb work?
monggodb44 is not working in freebsd14 they say
though some have tried the reinstalling outside the script

All mongodb newer than 44 requires a CPU with AVX support. The only workaround it seems is to compile with noavx. I tried both 6 and 7 to confirm - everything 5 and newer requires AVX CPUs. I have an Intel Atom CPU in my pfSense box. So I cannot run the unifi controller if it requires mongodb 5 or newer, which is the case on FreeBSD15. I am stuck. Anybody with older CPUs is going to be in the same boat.

My CPU, Intel e3-8100, has AVX instructions and mongod50 or mongod60 won't start anyway.
The error is:
ld-elf.so.1: /usr/local/bin/mongod: Undefined symbol "_ZNSt13exception_ptr31__from_native_exception_pointerEPv"

how bout force install of mongodb44?

Seems like mongodb44 is not available anymore. How about mongodb50-5.0.28? That version seems to be working fine

Seems like mongodb44 is not available anymore. How about mongodb50-5.0.28? That version seems to be working fine

some users are reporting that mongodB 5.0 and up required a secure CPU, which most cheap 3years old above ptocessors are not capable.
anyone code modify code in which mongodb 44 will be installed via freebsd13?

Seems like mongodb44 is not available anymore. How about mongodb50-5.0.28? That version seems to be working fine

some users are reporting that mongodB 5.0 and up required a secure CPU, which most cheap 3years old above ptocessors are not capable. anyone code modify code in which mongodb 44 will be installed via freebsd13?

To clarify, I have CPUs without AVX. One of my routers was using mongodb50-5.0.28 (from earlier upgrade) -- and that version is compatible.
The 2nd router I just tried to upgrade -- and mongodb50-5.0.29 failed to start.
I didn't find any official way of getting 5.0.28 or 4.4.*, so I copied over binaries from my other router for now.
My point was that 5.0.28 seems to be ok to use, so you don't have to go all the way back to 4.4.*
Aside, even 5.0 is noted as being EOL. If you're you able to make unifi server accept newer versions, 6.0 or even 7.0 would seem like a better choice.

Version 8.6.3 is working fine with pfSense plus 24.11.
I suspect the MongoDB package installed by the script isn't compatible with the FreeBSD kernel of pfSense 24.03.

please try #340 https://github.com/unofficial-unifi/unifi-pfsense/pull/340
managed to installed directly without issues


Simplify inference tests, fix Binned distribution

Description of changes:

The code for inference tests is simplified a bit.
An assertion is added, to make sure the loss tensor has the expected ("batch") shape during SGD.
Binned and BinnedOutput are fixed (for example, it is now hybridizable).
A docstring in the DistributionOutput class is improved.

By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the terms of your choice.

Job PR-57/1 is complete.
Docs are uploaded to http://gluon-ts-staging.s3-accelerate.dualstack.amazonaws.com/PR-57/1/index.html

Job PR-57/2 is complete.
Docs are uploaded to http://gluon-ts-staging.s3-accelerate.dualstack.amazonaws.com/PR-57/2/index.html

Codecov Report

Merging #57 into master will not change coverage.
The diff coverage is n/a.

@@           Coverage Diff           @@
##           master      #57   +/-   ##
=======================================
  Coverage   77.81%   77.81%
=======================================
  Files         108      108
  Lines        6189     6189
=======================================
  Hits         4816     4816
  Misses       1373     1373

This requires some further adjustments to shapes, which are in part addressed in #58.
I will also add assertions here, to make sure that shapes are as expected.

Job PR-57/3 is complete.
Docs are uploaded to http://gluon-ts-staging.s3-accelerate.dualstack.amazonaws.com/PR-57/3/index.html

Job PR-57/4 is complete.
Docs are uploaded to http://gluon-ts-staging.s3-accelerate.dualstack.amazonaws.com/PR-57/4/index.html

Job PR-57/5 is complete.
Docs are uploaded to http://gluon-ts-staging.s3-accelerate.dualstack.amazonaws.com/PR-57/5/index.html


docs: updated toHaveBeenCalled

Summary
This modification addresses the concern raised in issue https://github.com/jestjs/jest/issues/14842. The issue highlights a redundancy in the descriptions of .toHaveBeenCalled() and .toHaveBeenCalledWith(), despite these two functions serving distinct purposes. The rationale for this change is rooted in the fact that .toHaveBeenCalled() pertains to scenarios where no function parameters are involved. Consequently, the description has been refined to accurately convey the functionality of .toHaveBeenCalled, eliminating the redundant details about arguments and aligning it more precisely with its intended purpose.
Furthermore, I have revised the descriptions in all versioned documents associated with this documentation issue.
Test plan
After revising the documentation, I executed it on the documentation website's node server to ensure that the changes were accurately reflected. The modifications were applied to Jest documentation versions Next, 29.7, 29.6, 29.5, and 29.4. The server's documentation now displays the corrected values.

Thanks for sending a PR!
I thought this was resolved in https://github.com/jestjs/jest/pull/14847 - did we miss anything?

@SimenB  Thanks for checking the PR, Yes this PR is fixing the issue for Next version. I think we missed that in https://github.com/jestjs/jest/pull/14847 .
Visually,

Oh, could you sign the CLA?

@SimenB i have signed the CLA. Do let me know if anything else is required.


When open large file VS freezes.

I by mistake open file with DevExtreme file, and the whole VS freeze. It probably analyzing the file, but I don't need it. At least not at this price. I would like to be able close this file and stop analysis.

After reopening VS and trying to open same file issue was not reproduced. But maybe this is related to #415.
I'm running 1.1. RC2

Is DevExtreme a JavaScript file? If not, I doubt NTVS was trying to analyze it. It's probably just a generic problem with VS trying to open massive files.

Yes. This is Javascript library. Maybe you are right  and this is VS problem

I created a 20MB 500,000 line JS file and could repo this with "Full Intellisense". But with ES6 Intellisense preview in NTVS 1.2 alpha, I no longer see a full hang. There is a 2-3second delay opening the file while VS does some work, but after that the file loads just fine. You can browse and view the file just fine now, but the editing experience is pretty horrible (lots of delays) as most tools are not optimized for large single files like this.


Sentinel onSentinelDown Issue

Hi
I've a problem with SentinelMonitoredRedisClient when one of my sentinel instance is down, the sentinelClient Instance is removed from sentinelClients list but the actor try to reconnect to sentinel each 2 seconds.
In case when  one or more sentinel instances will stay down, i'll have multiple actors tryin to reconnect to non-existing sentinel instances.
after search, i find that redisscala schedule reconnect when connection is closed (class RedisWorkerIO)
I'd like to not have this behavior in case when i use sentinelClient.
Thanks

Up

Hi, you are probably right, but i don't have the time to write a fix for sentinel.
I invite you to submit a PR ;)

fixed in 1.6.0


Open configuration page when connected to a wifi

Hello,
After connecting to an outside wifi network, I got the IP address of my ESP-32 board.
Can I open the configuration page when my ESP has been connected to a Wifi (not in access point mode)? How can I do that?
Thank you!

Hi,
You can't do that unless you trigger to open the Config Portal (DRD/MRD, switch, sotware, etc.)
Check hereafter for the reasons :

Accessing manager after connection #15
AP stays open #2
Wifi Manager acts like Home Wifi Router? #12


Fix build for latest Rust nightly source

add [patch] section for rustc-std-workspace-core crate
pull compiler-builtins from crates.io by default

Fixes #227

Some of this landed with https://github.com/japaric/xargo/pull/228, but not all of it.
Also @jethrogb I think you have some use-cases in mind that I didn't know even existed, not sure how they fare now.
Once we resolved this @japaric it would be nice to get a new release.


R&D/Prod Job Type slider modification

Set the default state for the slider to Prod.  This will help to reduce the amount of clutter on a mature cluster.

Closing due to not relevant to Scale 7.x+


Alternative solution to representation caching

Opening for discussion
Context: This PR is meant as a proposed alternative to representation caching. By using 'lazy evaluation' in representation/ansatz we can avoid having potentially costly computations just to initialize the representation for calls such as obj.representation.__class__.
Description of the Change: Ansatz no longer calls backend methods in the init. Instead, the original parameters are stored (mat, vec, array for PolyExpAnsatz or  array for ArrayAnsatz) and backend methods such as astensor and at_least3d are only called when the property itself is called (then subsequently stored to avoid repeat calls). In addition to this the representation/ansatz can now also accept a function and some kwargs in substitution of specifying an (A, b, c).
Benefits: Based on some initial profiling initializing a representation/ansatz is more efficient.

Beautiful concept, I really like it! Before we lock it in could we keep A,b,c in the init of Bargmann, and have a separate class method that takes fn, **kwargs instead? (it's a bit odd to have A,b,c and (e.g.) cov, means as arguments of the init)


Spurious error during AWB 2.0.0a2 install

When I install AWB v2.0.0a2 via AppStore, I get the following error:

But the installation itself seems to go fine, and I did some basic manual tests and things seem to work. So not sure where this comes from.
Marking priority as "urgent" as this should get solved before the 2.0 release IMO.

Does it disappear when the installation is completed?

No, I see it on the Home app as well.

Ok, I will have a look. I assigned myself.

@unkcpz will give it a test and if the issue remains I'll assign @dou-du to see if the vapoury can be dropped.

I have confident this is fixed by https://github.com/aiidalab/aiidalab/pull/347, where we compare the package name and requirement name in all cases the canonicalized name which will convert the underscore and uppercase letter to lowercase. The vapory is the case where in the pip list it has Vapory as name but in the requirement list people usually write vapory.


Refactor to index using generic document

@EwanNoble  had a quick stab at updating the mapping for that index and the supporting document type.
NOTE has not been tested at all.

Have used this as an example for the changes made in #103 , thanks @leewadhams!


PIPLINE variable conflict in Django's settings.py

I use django-pipeline and in it's new version it needs a dictionary named PIPLINE in settings.py. python-social-auth seems to pickup this variable as it's own pipeline.
django-pipeline's PIPLINE looks like this:
PIPELINE = {
    'STYLESHEETS': {
        'base': {
        ...

The error is in social/utils.py line 55, when it tries to split "STYLESHEETS":
def module_member(name):
    mod, member = name.rsplit('.', 1)
    module = import_module(mod)
    return getattr(module, member)

Same issue here.

    def get_pipeline(self):
        return self.setting('PIPELINE', DEFAULT_AUTH_PIPELINE)

Source: https://github.com/omab/python-social-auth/blob/master/social/strategies/base.py#L97
I changed PIPELINE with SOCIAL_AUTH_PIPELINE and it seems to work.
There's another file which tries to read PIPELINE, but it's under social/tests.
$ grep -ri "'PIPELINE'" .
./social/strategies/base.py:        return self.setting('PIPELINE', DEFAULT_AUTH_PIPELINE)
./social/tests/strategy.py:        return self.setting('PIPELINE', (

PSA setting should be named SOCIAL_AUTH_PIPELINE, the lib will attempt the following names in this order when trying to fetch the setting:

SOCIAL_AUTH__PIPELINE
SOCIAL_AUTH_PIPELINE
PIPELINE

First one to match is returned.


Licenses mishandled of fonts in test files

There are several test files which their licenses are mishandled:
Files:     Tests/subset/data/Lobster.subset.ttx
Copyright: 2010 Pablo Impallari<EMAIL_ADDRESS>Comment:   With Reserved Font Name Lobster
License:   OFL-1.1

Files:     Tests/varLib/data/master_ttx_interpolatable_ttf/TestFamily3-*
           Tests/varLib/data/master_ufo/TestFamily3-*
Copyright: 2015 Google Inc.
License:   OFL-1.1

Files:     Tests/subset/data/expect_keep_math.ttx
           Tests/subset/data/TestMATH-Regular.ttx
Copyright: 2009-2012 Khaled Hosny
           2001-2011 STI Pub Companies
           1998-2003 MicroPress, Inc.
           1990 Elsevier, Inc.
Comment:   With Reserved Font Name STIX Fonts, TM Math
License:   OFL-1.1

Please include SIL OFL license text as well as copyright notices of these fonts in your release as required by OFL.
 2) Original or Modified Versions of the Font Software may be bundled,
 redistributed and/or sold with any software, provided that each copy
 contains the above copyright notice and this license. These can be
 included either as stand-alone text files, human-readable headers or
 in the appropriate machine-readable metadata fields within text or
 binary files as long as those fields can be easily viewed by the user.

Will do, thanks!

@medicalwei I'm not sure where I should put the OFL license text and copyright notices? Would you mind sending a PR?

@anthrotype OK, I am appending them to license text itself because it is more obvious for packagers. Sending a PR soon!


[Ops] Sync across hlxsites and PaloAltoNetworks repos

How will this work.
https://docs.google.com/drawings/d/190RNntBsNlL5QfKkYPcHJ_OSYQN3lg4bjnhVlR3-3Ho/edit
Brian, this one for you to discuss with Max

@iansk discussed this over slack.


Add an event for default stable rule "Fileless execution via memfd_create"

Motivation
To Add an event for default stable rule "Fileless execution via memfd_create" as mentioned here

Feature

Alternatives

Additional context

/assign


A few improvements

I made wrap() the default export so you can both import { wrap } from 'jest-snapshot-serializer-raw' and import wrap from 'jest-snapshot-serializer-raw'.
I switched the Symbol creation to use Symbol.for to prevent failure if the module is instantiated multiple times.

Codecov Report

Merging #8 into master will not change coverage.
The diff coverage is n/a.

@@          Coverage Diff          @@
##           master     #8   +/-   ##
=====================================
  Coverage     100%   100%
=====================================
  Files           1      1
  Lines           8      9    +1
  Branches        1      1
=====================================
+ Hits            8      9    +1

Impacted Files
Coverage Δ

src/index.ts
100% <ø> (ø)
: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 18ec85f...f39ed11. Read the comment docs.


For ConstrainedStr, strip should be performed after curtail_length

Bug
Output of python -c "import pydantic.utils; print(pydantic.utils.version_info())":
             pydantic version: 1.5.1
            pydantic compiled: True
                 install path: /Users/ricardosanchez/Documents/Projects/gaita/venv/lib/python3.7/site-packages/pydantic
               python version: 3.7.0 (v3.7.0:1bf9cc5093, Jun 26 2018, 23:26:24)  [Clang 6.0 (clang-600.0.57)]
                     platform: Darwin-19.4.0-x86_64-i386-64bit
     optional deps. installed: ['typing-extensions']

Using strip_whitespace and curtail_length:
from pydantic import constr, BaseModel

class Test(BaseModel):
    name: constr(strip_whitespace=True, min_length=1, curtail_length=39)

t = Test(name='Cesar Jerónimo Esquinca Enríquez de la Fuente')

Output of t.name:
t.name
'Cesar Jerónimo Esquinca Enríquez de la '

Expected output:
Out[18]: 'Cesar Jerónimo Esquinca Enríquez de la'

Without the last space.
I'm happy to submit a PR if needed, just want to make sure this isn't an expected output.

Makes sense, PR welcome.

In V2 we've gotten rid of curtail_length in favor of having you implement your own validator. If you do that you'll get the length being enforced before or after the truncation:
from typing import Annotated

from annotated_types import MinLen

from pydantic import BaseModel
from pydantic.annotated_arguments import AfterValidator

class Test(BaseModel):
    before: Annotated[str, AfterValidator(lambda x: x[:39]), MinLen(1)]
    after: Annotated[str, MinLen(1), AfterValidator(lambda x: x[:39])]


Add tower constraint system

Idea n1
-> have towers to come in pairs that can't be rotated. Forcing the player to adapt


appDir Configuration No Longer Working in Next.js 13.5 with markdoc/next.js

What happened?
The withMarkdoc function in the Next.js plugin has a line that references options.config.experimental.appDir to configure the appDir option. However, as of Next.js 13.5, appDir is no longer under the experimental object as it's considered a stable feature.
The offending code snippet from src/index.js:
appDir:
  options.config.experimental.appDir &&
  options.defaultLoaders.babel.options.appDir

This causes the loader to fail because the evaluation will always return undefined.
Expected Behavior
The nextjs plugin should work with 13.5 for both page or app router
Workaround
In the node_modules file, i.e @markdoc/next.js/src/index.js just set appDir to true
appDir: true

I don't understand babel well enough to understand other side effects though hence not doing a PR to remove the check or like fixes
To reproduce
With a working markdoc/nextjs implementation using the app directory, upgrade to NextJS 13.5.x
Version
0.3.2
Additional context
No response

@thesampaton this should be working now with<EMAIL_ADDRESS>

I am using NextJS 13.5.6 without App directory and this change breaks by code. 0.3.3 version works. I suspect the reason is that appDir always evaluates as true, which is not the case since pages are still supported.
There should be a way to override this undocumented setting.

@Alain1405 can you push a PR that allows overriding the option?

I will have time to look into this next week.
On Fri, Nov 10, 2023 at 7:54 AM Mike Fix @.***> wrote:

@Alain1405 https://github.com/Alain1405 can you push a PR that allows
overriding the option?
—
Reply to this email directly, view it on GitHub
https://github.com/markdoc/markdoc/issues/451#issuecomment-1804858554,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AAW4CEITKCW5VG4NVF3O4K3YDVUKNAVCNFSM6AAAAAA5O3BLBOVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTQMBUHA2TQNJVGQ
.
You are receiving this because you were mentioned.Message ID:
@.***>


Added a project option 'link_repo_env' to link project against existing python virtualenv

In some cases we simply wanted the project to use the existing virtual environment instead of generating a new one.
Thus I added a project option 'link_repo_env' to link project against existing python virtualenv instead of completely generating a new environment.
Not sure if you like this option or not, but figured I'd tender it to the community anyway.

Coverage decreased (-0.12%) when pulling 88d7b5a4f1615cc575bc28a22ce47ca3f159e2ae on viable-hartman:master into d08d989413d5c6ced8482f1b8b0835bab1e50e56 on worthwhile:master.

Interesting idea. What is your use case?

I'm using fabfiles that often don't require separate virtual environments to run properly (i.e. no extra dependencies), and by default creating a new project sets up a completely new virtual environment with its own dependencies, etc.
With the link option, you can utilize the same virtual environment fabric-bolt is running under.  So you don't need to list dependencies on the project if they are already installed in the existing virtual environment.
That's pretty much my use case.

I see you have modified the migrations. It would probably be a better idea to make new migrations so people can easily upgrade.

Okay, there's a couple of issues with this. 1) the initial migrations were updated instead of a new migration created. So I can't merge this as is. 2) The new option is a boolean and if turned on hijacks the virtualenv for fabric-bolt itself. A better approach would be a setting on a project level that allows you to keep the virtualenv/not rebuild it each time. So I'm concerned that the virtualenv for FabricBolt itself is in danger of corruption if you use that for your projects.
Since we like the general suggestion you're making, I'm going to open an issue and ref this PR. We'll see if we can add a project setting to keep from doing a rebuild each time.


[garden] Use anti-aliasing value from <anti_aliasing> SDF element

🎉 [garden] Use anti-aliasing value from <anti_aliasing> SDF element
Summary
The level of MSAA is hard-coded to 2. This pull request allows users to change the MSAA level with the SDF element <anti_aliasing>.
<camera name="camera">
  <image>
    <width>640</width>
    <height>480</height>
    <format>R8G8B8</format>
    <anti_aliasing>4</anti_aliasing>
  </image>
...
</camera>

Checklist

[ ] Signed all commits for DCO
[ ] Added tests
[ ] Added example and/or tutorial
[ ] Updated documentation (as needed)
[ ] Updated migration guide (as needed)
[ ] codecheck passed (See contributing)
[ ] All tests passed (See test coverage)
[ ] While waiting for a review on your PR, please help review another open pull request to support the maintainers

Note to maintainers: Remember to use Squash-Merge and edit the commit message to match the pull request summary while retaining Signed-off-by messages.

I think you need to change this line
https://github.com/ignitionrobotics/ign-sensors/blob/ign-sensors6/CMakeLists.txt#L89
to
ign_find_package(sdformat12 REQUIRED VERSION 12.4)

I was thinking about adding this feature to garden (sdformat13) because it is not high in demand. I worried that changing it to use sdformat12 might cause some errors.

Test failures are irrelevant to changes.

I think you need to change this line

+1 to @ahcorde 's suggestion. We should bump the required SDF version so that users know they need to upgrade when compiling, as opposed to having a compilation error due to the missing API, and needing to dig to find out what's happening.

Since it's currently targeting sdformat13, should I bump the minor version?
https://github.com/gazebosim/gz-sensors/blob/3359a0f475447d046e45bc62b0365d1603ba6523/CMakeLists.txt#L90-L92
to
ign_find_package(sdformat13 REQUIRED VERSION 13.1)

I think you need to change this line

+1 to @ahcorde 's suggestion. We should bump the required SDF version so that users know they need to upgrade when compiling, as opposed to having a compilation error due to the missing API, and needing to dig to find out what's happening.

Since it's currently targeting sdformat13, should I bump the minor version?
https://github.com/gazebosim/gz-sensors/blob/3359a0f475447d046e45bc62b0365d1603ba6523/CMakeLists.txt#L90-L92
to
ign_find_package(sdformat13 REQUIRED VERSION 13.1)

libsdformat13 hasn't been released yet, so we don't need to bump the minor. I think this request is out of date since it is targeting garden?


Make sure tests use the same gem versions we use in production

In #8134 it was noticed that running rubocop from an ecosystem directory, will run the latest version of RuboCop, not the ones we have locked at updater/Gemfile.lock.
This PR is an experiment to try to make sure a consistent version of rubocop is run all around while also simplifying our setup.

Thanks @Nishnha, yes, I think this will work.
However, turns out some specs depend on a Gemfile file being present at the root of an ecosystem. This seems unnecessary and confusing, and I've also been bitten by similar issues when running specs on my Linux laptop, but it requires some extra work to fix it.

I think this is good to go now.
Doing this would prevent sudden introduction of broken tests by external releases, like it happened at #8509. That workaround will no longer be necessary with this PR, although I'm not reverting it, because we do use json directly, so it's a runtime dependency after all.
Also, note that in my opinion the best solution here would be for each ecosystem to have its own Gemfile & Gemfile.lock file, but without multidir version updates group PRs, it's going to get very noisy, so reusing updater/ lockfile seems good enough for now?

Let's see how this setup works!


Number.isInteger  polyfill

Number.isInteger  polyfill

@jackie19 Thanks for making a PR 😄 this should solve issue #11.


Not triggering command

@schwark, not sure if you are still actively monitoring this thread or tweaking this recipe. This used to work for me 18 months ago, and when alarm.com enabled 2FA, it stopped. It has been abandoned altogether for the past year. Just today, I contacted alarm.com and had them disable 2FA and create a separate account with less privilege. The account can arm/disarm via the alarm.com website. Re-established it with the Smartthings alarm-com.groovy code. When it's triggered via Smartthings App, I can see successful login activities (alarm.com) from the newly created account, but it's not triggering the arm/disarm of the device. It's as though it's logging in but not completing the trigger command. Not sure what's occurring. Please let me know if you or other community members have any suggestions. Thanks

I should add that I just noticed the disarm command is functional. But not arm stay/away. Thanks

I am not actively working on this, but I am in the process of rewriting this whole module to use the new Lua based Edge drivers. So I will try to make this work - from scratch in the new architecture as this whole Groovy thing is gone in a month.

Great to hear! Looking fwd to having this work again. It’s been a sad few years without it
Outlookhttps://aka.ms/qtex0l for iOS

From: Schwark Satyavolu @.>
Sent: Wednesday, August 24, 2022 12:30:13 AM
To: schwark/smartthings-alarmcom @.>
Cc: Subscribed @.***>
Subject: Re: [schwark/smartthings-alarmcom] Not triggering command (Issue #41)
I am not actively working on this, but I am in the process of rewriting this whole module to use the new Lua based Edge drivers. So I will try to make this work - from scratch in the new architecture as this whole Groovy thing is gone in a month.
—
Reply to this email directly, view it on GitHubhttps://github.com/schwark/smartthings-alarmcom/issues/41#issuecomment-1225176595, or unsubscribehttps://github.com/notifications/unsubscribe-auth/AIN52RNCFRBDOQ7HL4BTDMTV2WQNLANCNFSM57DOVTEA.
You are receiving this because you are subscribed to this thread.Message ID: @.***>

@schwark, thank you for the quick response and this is good news, no pressure! It would be amazing to have this functional again.

https://community.smartthings.com/t/st-edge-smartthings-alarm-com-integration/246934


Upload file not working

I got this working in Docker using this:
docker run --rm -it -p 5000:5000 `
  -v ${pwd}:/data:ro `
  --security-opt apparmor:unconfined `
  --cap-add=SYS_ADMIN `
  ianyliu/blast-radius-fork --serve .

Where the . is my Terraform project folder.
However, I want to use the Upload file feature and tried all sorts of files and it's not accepting any of them as a valid file. What is the file supposed to be?

Never mind, managed to find some information in the main repo that this was forked from.
Run terraform graph and copy the output and save it into a .txt file, i.e a DOT script. For example:
digraph {
        compound = "true"
        newrank = "true"
        subgraph "root" {
                "[root] azurerm_key_vault.example (expand)" [label = "azurerm_key_vault.example", shape = "box"]
                "[root] azurerm_resource_group.example (expand)" [label = "azurerm_resource_group.example", shape = "box"]
                "[root] data.azurerm_client_config.current (expand)" [label = "data.azurerm_client_config.current", shape = "box"]
                "[root] provider[\"registry.terraform.io/hashicorp/azurerm\"]" [label = "provider[\"registry.terraform.io/hashicorp/azurerm\"]", shape = "diamond"]
                "[root] azurerm_key_vault.example (expand)" -> "[root] azurerm_resource_group.example (expand)"
                "[root] azurerm_key_vault.example (expand)" -> "[root] data.azurerm_client_config.current (expand)"
                "[root] azurerm_resource_group.example (expand)" -> "[root] provider[\"registry.terraform.io/hashicorp/azurerm\"]"
                "[root] data.azurerm_client_config.current (expand)" -> "[root] provider[\"registry.terraform.io/hashicorp/azurerm\"]"
                "[root] provider[\"registry.terraform.io/hashicorp/azurerm\"] (close)" -> "[root] azurerm_key_vault.example (expand)"
                "[root] root" -> "[root] provider[\"registry.terraform.io/hashicorp/azurerm\"] (close)"
        }
}

then just upload the text file. I basically tried everything except for this. I generated a JSON from this and uploaded the JSON, didn't work. I generated a SVG from this output as well and tried the state file, etc.
I think better and more instructions should be provided, as I had to find out about the DOT script as a comment somewhere else.

@chaoscreater  Thank you for this!
I have updated the README.md file. If you think it's still unclear, feel free to suggest further improvements!
https://github.com/Ianyliu/blast-radius-fork/pull/42


Popper modifier appear as [object Object] in div DOM attribute

Popper modifier appear as [object Object] in div DOM attribute

[x] This is a v1.x issue.
[x] I have searched the issues of this repository and believe that this is not a duplicate.

Expected Behavior

Modifiers are popper.js options, not a div attribute
Current Behavior

It appears as a div attribute on popper div.
<div role="tooltip" class="j224" modifiers="[object Object]" style="position: absolute; will-change: transform; top: 0px; left: 0px; transform: translate3d(780px, 8055px, 0px);" x-placement="top" x-out-of-boundaries="">
Steps to Reproduce

Currently reproduced in the documentation: https://material-ui.com/utils/popper/
In scroll playground section
Your Environment

Tech
Version

Material-UI
v1.4.1

React
16.4.1

browser
Google Chrome 68.0.3440.75 (Darwin x64)

@skeithtan Oops! modifiers is missing in this list:
https://github.com/mui-org/material-ui/blob/f695e7d5e0398b7c769b55dc73a4e0fb9631b22b/packages/material-ui/src/Popper/Popper.js#L151-L163
Do you want to work on it? :)

Yup, I'll get to it right now


Fixes RBAC issue with prometheus

As per the title, this fixed an RBAC issue with Prometheus (See: https://github.com/istio/istio/issues/3392)
Tada:

/assign @wattli


StateError  object.dart in RenderObject.constraints

Steps to reproduce
found in sentry. It seems this appeared first since we upgraded to Flutter 3.22.0
Expected results
No exception
Actual results
StateError: Bad state: A RenderObject does not have any constraints before it has been laid out.
  File "object.dart", line 2202, in RenderObject.constraints
  File "box.dart", line 2422, in RenderBox.constraints
  File "paragraph.dart", line 983, in RenderParagraph.getBoxesForSelection
  File "paragraph.dart", line 2026, in _SelectableFragment.boundingBoxes
  File "selectable_region.dart", line 1909, in MultiSelectableSelectionContainerDelegate._getBoundingBox
  File "selectable_region.dart", line 1926, in MultiSelectableSelectionContainerDelegate._compareScreenOrder
  File "sort.dart", line 69, in Sort._insertionSort
  File "sort.dart", line 58, in Sort._doSort
  File "sort.dart", line 33, in Sort.sort
  File "list.dart", line 321, in ListBase.sort
  File "selectable_region.dart", line 1824, in MultiSelectableSelectionContainerDelegate._flushAdditions
  File "selectable_region.dart", line 1818, in MultiSelectableSelectionContainerDelegate._updateSelectables
  File "selectable_region.dart", line 1797, in MultiSelectableSelectionContainerDelegate._scheduleSelectableUpdate.runScheduledTask
  File "binding.dart", line 1392, in SchedulerBinding._invokeFrameCallback
  File "binding.dart", line 1326, in SchedulerBinding.handleDrawFrame
  File "binding.dart", line 1171, in SchedulerBinding._handleDrawFrame
  File "zone.dart", line 1399, in _rootRun
  File "zone.dart", line 1301, in _CustomZone.run
  File "zone.dart", line 1209, in _CustomZone.runGuarded
  File "hooks.dart", line 314, in _invoke
  File "platform_dispatcher.dart", line 419, in PlatformDispatcher._drawFrame
  File "hooks.dart", line 283, in _drawFrame

Code sample
Code sample
[Paste your code here]

Screenshots or Video

Screenshots / Video demonstration
[Upload media here]

Logs
Logs
[Paste your logs here]

Flutter Doctor output
Doctor output
[√] Flutter (Channel stable, 3.22.0, on Microsoft Windows [Version 10.0.19045.4651], locale de-DE)
    • Flutter version 3.22.0 on channel stable at C:\Users\escam\fvm\versions\3.22.0
    • Upstream repository https://github.com/flutter/flutter.git
    • Framework revision 5dcb86f68f (2 months ago), 2024-05-09 07:39:20 -0500
    • Engine revision f6344b75dc
    • Dart version 3.4.0
    • DevTools version 2.34.3

[√] Windows Version (Installed version of Windows is version 10 or higher)

[√] Android toolchain - develop for Android devices (Android SDK version 33.0.2)
    • Android SDK at C:\Users\escam\AppData\Local\Android\sdk
    • Platform android-34, build-tools 33.0.2
    • Java binary at: C:\Program Files\Android\Android Studio\jbr\bin\java
    • Java version OpenJDK Runtime Environment (build 17.0.6+0-b2043.56-9586694)
    • All Android licenses accepted.

[√] Chrome - develop for the web
    • Chrome at C:\Program Files\Google\Chrome\Application\chrome.exe

[√] Visual Studio - develop Windows apps (Visual Studio Community 2022 17.6.2)
    • Visual Studio at C:\Program Files\Microsoft Visual Studio\2022\Community
    • Visual Studio Community 2022 version 17.6.33723.286
    • Windows 10 SDK version 10.0.22000.0

[√] Android Studio (version 2022.2)
    • Android Studio at C:\Program Files\Android\Android Studio
    • Flutter plugin can be installed from:
       https://plugins.jetbrains.com/plugin/9212-flutter
    • Dart plugin can be installed from:
       https://plugins.jetbrains.com/plugin/6351-dart
    • Java version OpenJDK Runtime Environment (build 17.0.6+0-b2043.56-9586694)

[√] VS Code, 64-bit edition (version 1.91.1)
    • VS Code at C:\Program Files\Microsoft VS Code
    • Flutter extension version 3.92.0

[√] Connected device (4 available)
    • sdk gphone x86 64 (mobile) • emulator-5554 • android-x64    • Android 13 (API 33) (emulator)
    • Windows (desktop)          • windows       • windows-x64    • Microsoft Windows [Version 10.0.19045.4651]
    • Chrome (web)               • chrome        • web-javascript • Google Chrome 126.0.6478.127
    • Edge (web)                 • edge          • web-javascript • Microsoft Edge 126.0.2592.102

[√] Network resources
    • All expected network resources are available.

• No issues found!```

</details>

Hi @escamoteur, is the issue reproducible if you run app in release mode?
Also, please provide the list of affected device info and the percentage occurrence of the crash. Thanks!

happens in release on Android and iOS, not reproducible though

@escamoteur Maybe you are hitting https://github.com/flutter/flutter/issues/119772 which occurs in debug mode, but in production it could be giving different error message as you listed. Please check if the code sample mentioned in linked issue resembles your case or not.


Use Polkit on Linux

sudo-prompt should use Polkit on Linux instead of the legacy Kdesudo / Gksudo / Pkexec.

I thought pkexec is the binary that interfaces with Polkit, hence the "pk"?
If not, how would you propose we use Polkit exactly? If you can provide sample code please that would be appreciated.

Well I have no idea what to use :) After a little research it seem that it's pkexec that should be used indeed. That said, and I don't know if it's still the case, but there was a problem with vs code that use sudo-prompt. It seem that sudo-prompt try first kdesudo and then pkexec. So I think it shouldn't use kdesudo / gksudo or at least use them as a fallback.
https://github.com/microsoft/vscode/issues/46560