Synth unable to detect arch on OPNsense

OPNsense is a FreeBSD-derived firewall OS just like pfSense. Unlike the latter (which is customized so heavily that it cannot even use the ports tree by default) it tries to keep as close to FreeBSD as possible. They offer only a small number of packages, but ports work and thus Synth can be built and installed.
Configuration of Synth works, too, however it is unable to build anything. Trying to use it results in this:
synth upgrade-system
Querying system about current package installations.
Stand by, comparing installed packages against the ports tree.
Stand by, building pkg(8) first ... Failed!!  (Synth must exit)
Unfortunately, the system upgrade failed.
Having a look at the log shows that Synth detects the arch as "BADARCH" which is invalid, of course and leads to Synth failing at the configure phase. However the "uname" command will actually return the correct string:
uname -m
amd64
uname -p
amd64
Any idea what's happening here? Here's the complete log output:
cat /var/log/synth/ports-mgmt___pkg.log
=> Building ports-mgmt/pkg
Started : Friday, 14 JUL 2017 at 05:13:28 UTC
Platform: 11.0-RELEASE-p10 FreeBSD 11.0-RELEASE-p10 #0 81a368c52(stable/17.1): Sat May  6 21:22:35 CEST 2017     root@sensey64:/usr/obj/usr/src/sys/SMP  amd64

--  Environment
UNAME_r=11.0-SYNTH
UNAME_m=BADARCH
UNAME_p=BADARCH
UNAME_v=FreeBSD 11.0-SYNTH
UNAME_s=FreeBSD
PATH=/sbin:/bin:/usr/sbin:/usr/bin:/usr/local/sbin:/usr/local/bin
SSL_NO_VERIFY_PEER=1
TERM=dumb
PKG_CACHEDIR=/var/cache/pkg8
PKG_DBDIR=/var/db/pkg8
PORTSDIR=/xports
LANG=C
HOME=/root
USER=root

--  Options

--  CONFIGURE_ENV
XDG_DATA_HOME=/construction/xports/ports-mgmt/pkg/work
XDG_CONFIG_HOME=/construction/xports/ports-mgmt/pkg/work
HOME=/construction/xports/ports-mgmt/pkg/work
TMPDIR="/tmp"
SHELL=/bin/sh
CONFIG_SHELL=/bin/sh
CONFIG_SITE=/xports/Templates/config.site
lt_cv_sys_max_cmd_len=262144

--  CONFIGURE_ARGS
--disable-maintainer-mode
--prefix=/usr/local
${_LATE_CONFIGURE_ARGS}

--  MAKE_ENV
XDG_DATA_HOME=/construction/xports/ports-mgmt/pkg/work
XDG_CONFIG_HOME=/construction/xports/ports-mgmt/pkg/work
HOME=/construction/xports/ports-mgmt/pkg/work
TMPDIR="/tmp"
NO_PIE=yes
MK_DEBUG_FILES=no
MK_KERNEL_SYMBOLS=no
SHELL=/bin/sh
NO_LINT=YES
PREFIX=/usr/local
LOCALBASE=/usr/local
LIBDIR="/usr/lib"
CC="cc"
CFLAGS="-O2 -pipe  -Wno-error -fno-strict-aliasing"
CPP="cpp"
CPPFLAGS=""
LDFLAGS=""
LIBS=""
CXX="c++"
CXXFLAGS="-O2 -pipe -Wno-error -fno-strict-aliasing "
MANPREFIX="/usr/local"
BSD_INSTALL_PROGRAM="install  -s -m 555"
BSD_INSTALL_LIB="install  -s -m 0644"
BSD_INSTALL_SCRIPT="install  -m 555"
BSD_INSTALL_DATA="install  -m 0644"
BSD_INSTALL_MAN="install  -m 444"

--  MAKE_ARGS
DESTDIR=/construction/xports/ports-mgmt/pkg/work/stage

--  PLIST_SUB
OSREL=11.0
PREFIX=%D
LOCALBASE=/usr/local
RESETPREFIX=/usr/local
PORTDOCS=""
PORTEXAMPLES=""
LIB32DIR=lib
DOCSDIR="share/doc/pkg"
EXAMPLESDIR="share/examples/pkg"
DATADIR="share/pkg"
WWWDIR="www/pkg"
ETCDIR="etc/pkg"

--  SUB_LIST
PREFIX=/usr/local
LOCALBASE=/usr/local
DATADIR=/usr/local/share/pkg
DOCSDIR=/usr/local/share/doc/pkg
EXAMPLESDIR=/usr/local/share/examples/pkg
WWWDIR=/usr/local/www/pkg
ETCDIR=/usr/local/etc/pkg

--  /etc/make.conf
SYNTHPROFILE=LiveSystem
USE_PACKAGE_DEPENDS_ONLY=yes
PACKAGE_BUILDING=yes
BATCH=yes
PKG_CREATE_VERBOSE=yes
PORTSDIR=/xports
DISTDIR=/distfiles
WRKDIRPREFIX=/construction
PORT_DBDIR=/options
PACKAGES=/packages
MAKE_JOBS_NUMBER_LIMIT=3
HAVE_COMPAT_IA32_KERN=YES
CONFIGURE_MAX_CMD_LEN=262144
_SMP_CPUS=4
UID=0
ARCH=BADARCH
OPSYS=FreeBSD
OSVERSION=1100122
OSREL=11.0
_OSRELEASE=11.0-SYNTH

--  Phase: check-sanity
===>  License BSD2CLAUSE accepted by the user

--  Phase: pkg-depends

--  Phase: fetch-depends

--  Phase: fetch
===>  License BSD2CLAUSE accepted by the user
===> Fetching all distfiles required by pkg-1.10.1 for building

--  Phase: checksum
===>  License BSD2CLAUSE accepted by the user
===> Fetching all distfiles required by pkg-1.10.1 for building
=> SHA256 Checksum OK for pkg-1.10.1.tar.xz.

--  Phase: extract-depends

--  Phase: extract
===>  License BSD2CLAUSE accepted by the user
===> Fetching all distfiles required by pkg-1.10.1 for building
===>  Extracting for pkg-1.10.1
===>  License BSD2CLAUSE accepted by the user
===> Fetching all distfiles required by pkg-1.10.1 for building
=> SHA256 Checksum OK for pkg-1.10.1.tar.xz.

--  Phase: patch-depends

--  Phase: patch
===>  Patching for pkg-1.10.1
===>  Applying FreeBSD patches for pkg-1.10.1

--  Phase: build-depends

--  Phase: lib-depends

--  Phase: configure
===>  Configuring for pkg-1.10.1
configure: loading site script /xports/Templates/config.site
checking for a BSD-compatible install... /usr/bin/install -c
checking whether build environment is sane... yes
checking for a thread-safe mkdir -p... (cached) /bin/mkdir -p
checking for gawk... (cached) /usr/bin/awk
checking whether make sets $(MAKE)... yes
checking whether make supports nested variables... yes
checking whether make supports nested variables... (cached) yes
checking whether to enable maintainer-specific portions of Makefiles... no
checking for style of include used by make... GNU
checking for gcc... cc
checking whether the C compiler works... yes
checking for C compiler default output file name... a.out
checking for suffix of executables...
checking whether we are cross compiling... no
checking for suffix of object files... o
checking whether we are using the GNU C compiler... yes
checking whether cc accepts -g... yes
checking for cc option to accept ISO C89... none needed
checking whether cc understands -c and -o together... yes
checking dependency style of cc... gcc3
checking how to run the C preprocessor... cpp
checking for grep that handles long lines and -e... (cached) /usr/bin/grep
checking for egrep... (cached) /usr/bin/egrep
checking for ANSI C header files... (cached) yes
checking for sys/types.h... (cached) yes
checking for sys/stat.h... (cached) yes
checking for stdlib.h... (cached) yes
checking for string.h... (cached) yes
checking for memory.h... (cached) yes
checking for strings.h... (cached) yes
checking for inttypes.h... (cached) yes
checking for stdint.h... (cached) yes
checking for unistd.h... (cached) yes
checking for minix/config.h... (cached) no
checking whether it is safe to define EXTENSIONS... yes
checking for cc option to accept ISO C99... none needed
checking build system type... Invalid configuration BADARCH-portbld-freebsd11.0': machine BADARCH-portbld' not recognized
configure: error: /bin/sh ./config.sub BADARCH-portbld-freebsd11.0 failed
===>  Script "configure" failed unexpectedly.
Please report the problem to<EMAIL_ADDRESS>[maintainer] and attach the
"/construction/xports/ports-mgmt/pkg/work/pkg-1.10.1/config.log" including
the output of the failure of your make command. Also, it might be a good idea
to provide an overview of all packages installed on your system (e.g. a
/construction/xports/ports-mgmt/pkg/work/pkg-1.10.1/src/pkg-static info -g
-Ea).
*** Error code 1
Stop.
make[1]: stopped in /xports/ports-mgmt/pkg
*** Error code 1
Stop.
make: stopped in /xports/ports-mgmt/pkg

--  Termination
Finished: Friday, 14 JUL 2017 at 05:13:41 UTC
Duration: 00:00:12

uname doesn't determine the arch.
Paste the output of
file /bin/sh

which should reveal what OPNsense is doing

Thanks for clarifying that uname is not actually used. Here's the output of the file command:
/bin/sh: ELF 64-bit LSB shared object, x86-64, version 1 (FreeBSD), dynamically linked, interpreter /libexec/ld-elf.so.1, for FreeBSD 11.0 (1100122), FreeBSD-style, stripped
Strange thing here is that file claims it's a "shared object" instead of an executable. However I can execute it and it gives me what looks like a bourne shell. Here's the ldd, too, since that also differs from the /bin/sh on my FreeBSD workstation:
/bin/sh:
libedit.so.7 => /lib/libedit.so.7 (0x26eba297000)
libthr.so.3 => /lib/libthr.so.3 (0x26eba4d1000)
librt.so.1 => /lib/librt.so.1 (0x26eba6f9000)
libm.so.5 => /lib/libm.so.5 (0x26eba8ff000)
libc.so.7 => /lib/libc.so.7 (0x26eb8ca4000)
libncursesw.so.8 => /lib/libncursesw.so.8 (0x26ebab2a000)

The output of file seems to be identical to FreeBSD.
So that implies synth doesn't recognize the platform.
see: https://github.com/jrmarino/synth/blob/b555e144c8544333f70dabbd8012a3981cad504e/src/replicant-platform.adb#L131
Did you build synth from source?
Cause of issue might be in the port itself.

Yes, Synth is not available as a package on OPNsense. There's also no portsnap nor svnlite or anything, so I got the ports tree from the git mirror. I had disabled fortran and obj-c in the gcc-aux package and also disabled quite a few other options in various ports. So to rule out that I crippled something I re-installed a fresh copy of OPNsense on my test machine and built Synth again leaving all the ports options at their defaults. Here's exactly what I did:
pkg install git
mkdir /usr/ports
git clone --depth=1 https://github.com/freebsd/freebsd-ports.git /usr/ports
echo DEFAULT_VERSIONS+=ssl=openssl > /etc/make.conf
make -C /usr/ports/ports-mgmt/synth configure-recursive fetch-recursive install clean
/etc/make.conf is nonexistent on OPNsense by default. But since OpenSSL from ports is used, the ports system reminded me to set that option. Then I just installed Synth 1.69 and keep running into the same BADARCH problem as before.
I've been using Synth all the time on GhostBSD and FreeBSD since I was introduced to it and I'd really like to see it become available to the OPNsense community. Unfortunately I don't know any Ada at all. I get the big picture of what's happening in the code that you linked to, but not the details necessary to just start hacking Synth myself trying to resolve that problem. Do you have any further hints for me on what to try or to look at?

open the file
 /usr/local/etc/synth/synth.ini

and see if the value for Operating_system is not "FreeBSD".

Unfortunately it is:
cat /usr/local/etc/synth/synth.ini

; This Synth configuration file is automatically generated
; Take care when hand editing!
[Global Configuration]
profile_selected= LiveSystem
[LiveSystem]
Operating_system= FreeBSD
Directory_packages= /var/synth/live_packages
Directory_repository= /var/synth/live_packages/All
Directory_portsdir= /usr/ports
Directory_options= /var/db/ports
Directory_distfiles= /usr/ports/distfiles
Directory_buildbase= /usr/obj/synth-live
Directory_logs= /var/log/synth
Directory_ccache= disabled
Directory_system= /
Number_of_builders= 2
Max_jobs_per_builder= 2
Tmpfs_workdir= true
Tmpfs_localbase= true
Display_with_ncurses= true
leverage_prebuilt= false

Try
synth build editors/nano

This will try to build pkg again, which will fail.  After it fails, check the logs directory for "05_abnormal_command_output.log" file.  Let me know if that file is blank.  If it's not, print out the contents here.

Yes, it is blank:
ls -lh /var/log/synth/

total 20
-rw-r--r--  1 root  wheel     1B Jul 16 21:08 05_abnormal_command_output.log
-rw-r--r--  1 root  wheel     1B Jul 16 21:08 06_obsolete_packages.log
-rw-r--r--  1 root  wheel   9.0K Jul 16 21:08 ports-mgmt___pkg.log

Strange thing here is that file claims it's a "shared object" instead of an executable. However I can execute it and it gives me what looks like a bourne shell.

Well, this is definitely the cause.
On Synth, it's checking starting at character 28, and the change from "executable" to "shared object" is breaking the arch detection.
(incidently, the non-ports successor to Synth, Ravenadm, has more robust parsing of file string).
is the problem with "file"?  You can install "file" from ports and see if it gives the same output.   If it does, what is your speculation on why /bin/sh has this output from file?

I built the newer "file" from ports and it shows the same output. Why? I have no idea. Probably there's something messed up when building OPNsense. I will try to bring this to the developer's attention on their forums tomorrow or so.
However this was actually the solution to the whole mystery - I scp'd the statically linked /rescue binary from my fbsd 11.1 workstation over to the OPNsense test machine and put it in place of their /bin/sh. While a ~10 MB statically linked executable may not be nice for sh, it showed that Synth seems to actually work. Pkg could be built and Synth started building other packages as well. I'll attempt a full system-upgrade overnight and see if there are any problems but I don't really expect any.
So thanks a lot for your help! If you are interested in what happened to OPNsense's /bin/sh, leave this issue open and I'll post back here again (if I get an answer). Otherwise this can be closed as resolved. Your Raven project sounds terrific BTW, I will totally have to set aside some free time to play with it!

sure, I'm interested.
Synth can probably be modified to be more forgiving with the file output, but it would be nice to know what's going on with OPNsense before I make any modifications

Instead of asking at the OPNsense forums like I originally intended, I did a little research. There's a partnership between OPNsense and the HardenedBSD project and that's where they get their system hardening from. And guess what: That seems where the /bin/sh issue seems to originate from:

/bin/sh: ELF 64-bit LSB shared object, x86-64, version 1 (FreeBSD), dynamically linked, interpreter /libexac/ld-elf.so.1, for FreeBSD 11.0 (1100514), FreeBSD-style, stripped

I'm going to ask anyway, now and see if I can get an answer.

This is because /bin/sh is compiled as a Position-Independent Executable (PIE) in OPNsense. When compiling an application as a PIE, the linker will set the ELF type to be ET_DYN rather than ET_EXEC. Thus, file(1) reports /bin/sh as an ELF shared object rather than an ELF executable.
Thus, file(1) reporting "shared object" is the correct behavior. Synth should take that into account.

Wow, you guys are fast! Thanks Shawn for explaining this. I've already got HardenedBSD installed on my test machine, will try out Synth with it next.

I'm glad to help. :)
With Synth supporting DragonflyBSD, and DragonflyBSD having ASLR, Synth really should support PIEs anyways. ASLR doesn't make much sense unless the application is compiled as a PIE.

okay, I'll see about bringing in the newer ravenadm code into synth to address this.
Once fix confirmed, I'll push a new release so the synth port maintainer can update.

@kraileth ,
If you could, apply this patch to synth port:
ironwolf# cat /tmp/patch-next-synth
--- ports-mgmt/synth/Makefile
+++ ports-mgmt/synth/Makefile
@@ -2,7 +2,7 @@
 # $FreeBSD$

 PORTNAME=      synth
-PORTVERSION=   1.69
+PORTVERSION=   1.70
 DISTVERSIONPREFIX=     v
 CATEGORIES=    ports-mgmt

--- ports-mgmt/synth/distinfo
+++ ports-mgmt/synth/distinfo
@@ -1,3 +1,3 @@
-TIMESTAMP =<PHONE_NUMBER>
-SHA256 (jrmarino-synth-v1.69_GH0.tar.gz) = b1b73febbe1ae0fddd630c458e681e634f0bbd5dd5698bc21b9cbbf77d87a018
-SIZE (jrmarino-synth-v1.69_GH0.tar.gz) = 139278
+TIMESTAMP =<PHONE_NUMBER>
+SHA256 (jrmarino-synth-v1.70_GH0.tar.gz) = b9f5c91bbac0a50a9d773293ad6b433d75462112a6b04259f035efbc577d4efb
+SIZE (jrmarino-synth-v1.70_GH0.tar.gz) = 139429

rebuild synth and upgrade to version 1.70.
Then restore /bin/sh to the original PIE version.
I believe it should work, but I'd like confirmation before I let Eric know to upgrade ports version.

DragonflyBSD having ASLR, ...
I don't believe DF supports ASLR actually.
Moreover, I seem to recall something is not quite right with PIE support on DF.  I think there's a small bug in the real-time linker that needs to be tracked down (or maybe the kernel).   I never formally derived a test case for the PIE issue so it was never fixed.  I can't remember the details or how prevalent the symptoms are (e.g it might work 95% of the time, but fail on some edge case).

or maybe I'm getting confused with RELRO.  Yeah, I think I am.  it's RELRO that has a linker issue.  PIE should be okay.

I don't know their level of support, but they have some level of address space randomization:
https://www.dragonflydigest.com/2014/01/20/13213.html

hmm, surprising.  I know dillon doesn't think much of ALSR effectiveness overall.  That's probably why it's off by default.

I put a fresh copy of OPNsense back on my test machine last evening, cloned the ports tree and applied the patch. The first hunk failed for whatever reason, but just changing the version number in the Makefile is a quick edit. Then I built all the dependencies and the new Synth. It worked - even with the hardening options enabled.
Now Synth detects the arch correctly and is happily rebuilding all packages. I only had to remove port options for everything that was built while building Synth: The HardenedBSD ports tree includes three additional hardening options that Synth obviously knows nothing about. So I guess if I rebuild the whole system, all packages will lose their hardening. Since I do not intend to run Synth directly on my router but plan to do so in a VM and import the repo created there (with a lower priority than the OPNsense repo), this will not be much of an issue for me (only the additional packages will not be hardened but it's definitely better to have those not-hardened packages than not having that software available at all).
I don't know if there's any demand for it, but just out of curiosity I'll ask anyways: Would it be a complicated change to support those options, too, if available? Because in that case Synth could be used with the HardenedBSD ports tree perfectly well (and probably be used on HardenedBSD, too).
I'll write a final report how things went with the rebuilding (~80 packages to go right now).

if the new options defined by the ports tree, then you should be able to set them via -make.conf, right?  Without knowing the details, it seems that synth could support these hardening options without modification, only configuration.  Maybe it would help to know how these options are set via poudriere or live building ...

About Synth 1.70: I've patched the local ports tree on my GhostBSD workstation and build updates with it. The new Synth works as expected. I can also ping Eric on the gbsd forums for you if you decide to release this new version.
About the package rebuild on OPNsense: It completed with two few failures that I will look into when I find the time.
About hardened ports options: I've uploaded a screenshot as pictures say a thousand words:
http://www.elderlinux.org/temp/hardened_ports_options_example.png
The three hardening options are available for every port in the HardenedBSD ports tree. Here's what the port's options file looks like after accepting this configuration:

% cat /var/db/ports/shells_mksh/options
This file is auto-generated by 'make config'.
Options for mksh-55
_OPTIONS_READ=mksh-55
_FILE_COMPLETE_OPTIONS_LIST=EXAMPLES PIE RELRO SAFESTACK
OPTIONS_FILE_SET+=EXAMPLES
OPTIONS_FILE_SET+=PIE
OPTIONS_FILE_SET+=RELRO
OPTIONS_FILE_UNSET+=SAFESTACK

It also looks like Synth leaves those options alone. It they are set by default for a port, that port is built with those enabled. However if you change the defaults, Synth will detect "obsolete port options" and demand that those be reset.

the "release" had already occurred before I asked to test it (a failed test would have resulted in a second release)
I already emailed eric but you can ping him too
from your description, the hardening options are off by default.  If synth is deleting because of options mismatch, it means it got exposed to packages built with non-default options (coupled with synth's option directory was not configured)
you can globally set options via -make.conf, see https://lists.freebsd.org/pipermail/freebsd-ports-announce/2013-June/000062.html

PIE and RELRO are enabled by default. SAFESTACK isn't, with the exception of around 150-200 ports.

something is amiss.  If your tree sets PIE and RELRO by default, the next pass wouldn't consider the packages obsolete for options-mismatch reasons.   These 3 new options are no different than any other global option (e.g. NLS and DOCS)

The mismatch occurs for the ports that I explicitly set options for (i.e. doing a "make config-recursive" on ports-mgmt/synth). Even though I just accepted the default options, they had options set in /var/db/ports. Synth complained about these, I think. But after I did "rmconfig" on all of those, Synth no longer refused to build them, but I think it picked up the default options correctly. But this is just my guess.

those symptoms suggest the options directory in the synth configure menu is set incorrectly.
in other words, you're saving the options in one location, but synth can't find those saved options so it's using default options (a mismatch).


Update who-is-using-prisma-fq08.mdx

add ochain

 Thank you for your submission, we really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.You have signed the CLA already but the status is still pending? Let us recheck it.


Run acceptance test if -Dtest.single=PATTERN is set explicitly

Running a single acceptance test locally is useful to add an acceptance
test.

@danielnorberg  PTAL

Isn't it odd to only do this for -Dtest.single and not for e.g. --tests <pattern> etc? How about just doing CI_ACCEPTANCE_TEST=true or checking for some other system property like -Dtest.acceptance ?

I just didn't know about --tests option...apparently, -Dtest.single is deprecated and --tests is its successor: https://docs.gradle.org/current/userguide/java_plugin.html#N15A81
I added some more code to respect --tests.
--tests <pattern> starts java processes before filtering tests out if forkEvery = 1 is set. -Dtest.single=<pattern> filters test out and starts a process. So --tests is much slower.

👍


Impossible to search for short queries like "2k" or "33"

Since the FTS5 upgrade, I am not able to search for queries of two characters or less.  I believe this was intentional but I want to report that such queries are actually quite common.  I use them for multiple parts per project, especially in conjunction with the the filters set to only show parts in the basic parts catalog.  Currently I am forced to search for these passives on the jlcpcb website.
Any workarounds would be appreciated.

Yeah this is a limit of fts5, indexing substrings so short would result in a huge database size, see:
https://www.sqlite.org/fts5.html
Substrings consisting of fewer than 3 unicode characters do not match any rows when used with a full-text query. If a LIKE or GLOB pattern does not contain at least one sequence of non-wildcard unicode characters, FTS5 falls back to a linear scan of the entire table.

We could drop shorter tokens to avoid breaking the search at least as a short term fix.
It appears possible to fall back to a 'like', trying to test here but sqlitebrowser is crashing. I'll try on the command line in a few.

Ah!  That is where the limit came from.  I was looking all over the code but couldn't find any length < 3 expression.
I'm not sure what to say.  I want FTS5 to work, since the search as you type experience is really nice.  But not being able to search for short strings is a workflow breaker for me.  Hopefully we can find some workaround.
If we could combine traditional indices with FTS5, then a fallback to a LIKE query would not be that slow in my work flow.  Generally I need short query support only with passives, and I will be adding other filters like footprint and unchecking the box for extended parts.  So it uses the index to narrow it down to a small list before scanning the description.  Only downside to this, if I understand correctly, is that it would require keeping a traditional parts table in addition to an FTS5 table similar to what was proposed in #444.

@whmountains yeah just confirmed we can fall back. Let me get a PR for you to test tonight. Clearly it will be slower with the partial search but better than nothing. I'm assuming you'll be ok with a "AND description like '%33%'" term in the query? ie, you'll get matches on 330ohms, or 0.33mv etc.
I also think short searches like that are relatively rare. I actually don't think I've ever tried to search for something short. Too many things match. Now maybe I'd like to search for say "0603 10" to find 10V 0603s, but I'd probably keep typing and do "0603 10V".

OK, so you'd just type the package in the full-text search query?  That makes sense I guess.  I thought I tried that... I wonder what I did wrong.  Thanks for the clarification, I'll have to test it again.
Yeah in my case I would be fine typing 0603 33 to find a 33-ohm resistor for example.  I'm not sure how to type the ohm symbol so I revert to just scrolling through the list.  And generally I also filter to basic parts as well which helps to trim the list.

@whmountains so I only type in the full text query, I never use any of the other selection boxes, it takes too much time to pick them. I just jam in the stuff I'd put into google, "0603 10uf 20V" etc and see what pops up.
Agree having the <3 character search is ideal for ohms.
See #452

Closing as fixed in #452


add new scope of acceptance for default aup repository

Some organizations want you to accept terms during each interactive login (when CAS doesn't already know who you are based on previous authentication). This adds a "once per authentication" mode vs "once per server uptime" to the default AUP repository. Let me know if you want me to move the option to configure that default mode to an inner class since it doesn't apply to the other AUP repositories.
On a related subject: When I was testing AUP using x509 authentication, there is an error when the AUP repository tries to access the credentials object in order to use the id as they key in the global policyMap. This is because the x509 webflow clears out the credentials at the end of the x509 action (so they don't cause problems in the login webflow if the x509 webflow ends up sending the user to the login page). Several of the webflows seem to clear out the credentials (digest, basic, generic-remote, openid, spegno, token, trusted & x509) so I assume none of them work with the AUP default repository. Should the clearing of the credentials be moved to the beginning of the login form flow or should it be tied to specific transitions in the x509 flow? (Not the success transition to create TGT which AUP prepends itself to.)

Several of the webflows seem to clear out the credentials (digest, basic, generic-remote, openid, spegno, token, trusted & x509) so I assume none of them work with the AUP default repository.

Ouch. That sounds like a very unfortunate side-effect.

Should the clearing of the credentials be moved to the beginning of the login form flow or should it be tied to specific transitions in the x509 flow? (Not the success transition to create TGT which AUP prepends itself to.)

My vote is the latter, or perhaps we can do it in the beginning of the login if the non-interactive authn method (like X509) decides to route the user to the login form.


Video Support in ermrestJS

We need to support video playback in chaise, for which we need functionality in ermrestJS supporting custom markdown tag for video

We also have to decide the attributes that we are going to support (autoplay, controls, height, loop, muted, poster, preload, src, width)

We will be supporting only mp4 format as it seems to be supported in all major browsers.

Sample Input:
::: video [This is sample video](http://techslides.com/demos/sample-videos/small.mp4){width=800 height=300} \n:::

Sample Output:

This is sample video

<video width="800" height="300"><source src="http://techslides.com/demos/sample-videos/small.mp4"></video>

@hongsudt and @karlcz, which attributes should be supported for the video tag??

Some discussion that we had regarding the attributes list to be supported:

autoplay: we won't be supporting the autoplay attribute.
controls: By default, the controls will be displayed with the video to (play/pause) the video.
height/width: height/width can be defined as an attribute list and will be supported.
src: A mandatory attribute to locate the video resource.
loop, muted, poster, preload: Not supported at this point of time.

The changes have been merged to master, closing this.

The wiki has been updated to use video markdown, it can be found here


⚠ Bofrost.be has degraded performance

In dbcd703, Bofrost.be (https://www.bofrost.be) experienced degraded performance:

HTTP code: 200
Response time: 1298 ms

Resolved: Bofrost.be performance has improved in b17f04c.


[Bug]: Plugin thinks cameras are motion sensors

What happened?
All was working fine with my setup of an S380 HomeBase and 4 S330 (EufyCam 3's), until I added one of Eufy's latest products; the eufyCam E330 (Professional). It wasn't compatible with my current version which as of right now is the latest stable version -  v2.2.21, as expected. I then tried installing newer versions such as v.2.3.5 - hksv, v.2.3.1-beta.3 - beta to see if they would have any compatibility with the E330, but now all my cameras appear to be motion sensors, including my S330's, and now it only shows up as such on the Home app.
I was thinking part of the issue might be because my HB3 is itself on a beta firmware as Eufy is testing their new AI features like Multi-track or stitch... something like that.
Anyway something has rendered all my previously working cams unusable/visible, and yea kinda just bummed out by all this to be honest. I have tried multiple times in/un-stalling the plugin, but they would always end up being motion sensors. What's curious is normally they would default as motion sensors where it would then have to be manually changed to a camera, but upon installing it is already showing as a camera.
Unfortunately I didn't save any logs, but one I noticed was something along the lines of ([cam1] doesn't need battery characteristic as it is a motion sensor, adding anyway')
Device Type
Indoor Camera (Supported)
Plugin Version
v2.0.x (Supported)
HomeBridge Version
v1.6.x (Supported)
NodeJS Version
v18 (Supported)
Operating System
Raspbian 10+ (Supported)
Relevant log output
[will reinstall plugin to duplicate issue and update this post]

config
[will reinstall plugin to duplicate issue and update this post]

I have the same issue. Every device is set to camera in settings as well. All Eufy 2c  cams. Same message in logs.

Just wanted to update that after reinstalling v2.2.21, after getting the same log output that the cameras are motion sensors, I just tried to toggle the option to change to motion sensor then back to camera, even though it was on camera in the first place. After saving and restarting Homebridge, for the one camera that I did those settings to, it changed to camera, but the remaining cam’s remained as motion sensors - that is until I did the same toggle for the rest of them. Oddly enough it worked.
One other thing I should note is for all the cameras I had to copy preset, with nothing else changed except the acodec which I put to copy, which perhaps coincidentally coincided with the error. I then changed it back to the default libkacc or ‘blank’ settings. And for my camera settings in the native eufy app, streaming and recording is set to 1080p. Curiously it is the recording option, especially when I set it to 4K where it ‘breaks’ the plugin, rather than the stream setting. Anyway all is good and back to normal as usual.

That worked for me too, however this seems to be all over the place right now. I would get unresponsive cameras until i activate RTSP in the plugin. I have not activated RTSP in the eufy app for any camera. With the toggle beeing switched on i can get a stream in 640px. After enableing audio transmission it stops working again all together. Not sure if it just a visual bug on the front end toggles or something else. For my setup the plugin is not useable at the moment unfortunately.

same, i cant add cameras HB3 => E330


Add Labels for V-Model

Take the elements from the V-model and create a set labels for them for this repo.
https://en.wikipedia.org/wiki/V-Model_(software_development)

Labels have been created. Closing this issue.

Before closing I want to describe this issue in detail:
Info about label:
V-N Prefix
Each of the labels has a prefix in front of it. This is to give team members an idea of the stage a task is apart of. It acts as a countdown timer which reads as V minus X, thus "V-5 Architecture" is V minus 5. This means that this stage of development is 5 stages away from zero, the goal. Zero is the goal for all subsystem as that is point where the system is operational and being tested in  the field.
This prefix will make it easier for viewers of issues to determine what location in the phases they are rather than having to remember the V-model directly.
Description of each label
Rather than describe them all here, each label has an embedded description. Simply hover your mouse over the label and it will tell you what it means in a simple single sentence.


Update to Cargo 0.49

Had some issues with wanting to use profile overrides in a project. Currently this gives an error in cargo bitbake due to it still using Cargo 0.41 where it is an unstable feature, fixing this just requires upgrading to use Cargo 0.42
Figured I might as well upgrade to the latest release while taking the time to do this upgrade, so upgraded all the way to the latest 0.49 release.
Since the last update some structure has changed in Cargo notably transitioning from the failure crate over to anyhow. So I had to change the dependency here also.
Then there were some other minor tweaks to the internal structure of Cargo that also had to be updated config.configure had a slightly different function definition now. And InternedString was moved from core to util::interning. And lastly DefaultBranch was added to GitReference in commit https://github.com/rust-lang/cargo/commit/4c02977c219ef79b5eb09cb1fb39c4068de61559 And was mostly just replacing GitReference::Branch("master"), to add support for main branches not named master

@cardoe, we should publish a new release since cargo install is broken for many people on a newer compiler.

Done. I ran cargo release patch


hasParticipant should not be described as an "abstract" property and should be limited to agents

A scope note on hasParticipant says: "This is intended as an abstract property. Only its subproperties will be directly used."
Now that hasParticipant rather than isConnectedTo is the recommended property connecting a temporal relation to the things it relates, I have been asserting it directly when none of the subproperties are suitable. This comment should be removed.
In addition, the scope note on TemporalRelation: "Note that 'participant' does not imply agency; a non-sentient being can be [sic] participate in a temporal relation. For example, both a person and a house could be participants in a hypothetical relation 'lives at.'" should also be added to the property itself.
For the record, I still balk every time I use hasParticipant with a non-sentient object, and I am finding that this usage confuses some new ontologists and has to be explained. I don't think it's the right term. Participation is an active concept. A house doesn't participate in anything, as far as I'm concerned. It is acted upon but does not act.
If you look at dictionary definitions, while some of them can be bent out of shape to include non-agents, most of them clearly imply agency, and all the examples do as well:
Merriam-Webster: "to take part"; "your mother participates in this ambition", "...always participates in class discussions."
Cambridge: "to take part in or become involved in an activity"; example participants are Kate, he, countries, members, restaurants. ("Restaurants" here implies an organization rather than a place, I think.)
Dictionary.com: "to take or have a part or share, as with others"; participate in profits or a play.
Collins: "to have or take a part or share with others (in some activity, enterprise, etc.)"; used with you, he.
Britannica: "to be involved with others in doing something; to take part in an activity or event with others."; people, you, he, employees, women, audience, participating store (again, like restaurant above).
Oxford: "to take part in or become involved in an activity"; anyone, she, students, women, countries, employees.
Enough?
If we decide to make this change, we need a different property to serve the purpose of linking things to a temporal relation in a non-specific way. Our original isConnectedTo was preferable, but now we've repurposed it so need another.

Do you have a proposal for a change?
We had an extensive discussion on this a while back. In ontology circles, hasParticpant has been used in a more inclusive way than you like for many years, so it does not bother me at all. I prefer it. However, the examples you give do suggest there is a notion of activity in participation, in much of everyday speech.

The broader idea is to be involved in, which might or might not be active participation (which BTW is redundant, in RY's view.  An accurate alternative to hasParticipant is hasInvolvee. Any better ideas?

For the record, I still balk every time I use hasParticipant with a non-sentient object, and I am finding that this usage confuses some new ontologists and has to be explained.

For the record, I am one of these ontologists, and I had to have it explained to me, which Rebecca was kind enough to do. I agree with the idea that it doesn't have to be a sentient agent, but it sounds like it should be something with the ability to act, not just be passively included.

How about just involves? hasInvolvee doesn't really fit the bill of conforming to ordinary language use, since "involvee" is not a word. :)

involves is not a bad option.

I like our terms to accord with the language our clients would use at least as much, if not more, than conforming to practice by other ontologists

That makes sense.

Limiting the range of hasParticipant to agents (either formally with rdfs:range or informally with a note about the intention) makes sense to me. I agree w/ Michael that there are other notions of participation--e.g., Plato used to talk about inanimate things like tables "participating" in the form of House-ness. However, I think the concept that accords more with the standard dictionary definition makes more sense for gist.
Regarding the related issue of TemporalRelation, I see pros and cons w/ different predicates:

hasParticipant - Potentially confusing in the way @rjyounes describes, given its ordinary implication of agency.
isConnectedTo - Nice that it's general and wouldn't require adding a predicate to gist. Downside is that the predicate might be so general that it's just indicating something vacuously true--i.e., it might as well be isRelatedTo.
involves - Seems to have more content than isConnectedTo, but would require a new predicate.
hasTemporalRelatum - This would be a new predicate restricted to this specific purpose, but it avoids hasParticipant's clash w/ ordinary language and the risk  of vacuity w/ something like isConnectedTo. Granted, it is jargony, which we typically try to avoid in gist; but since TemporalRelation is already a bit jargony, maybe it would be warranted in this case.

isConnectedTo has been re-purposed, so we can't bring it back with its former meaning.
I don't like hasTemporalRelatum for the reason you state. "Relation" is a standard word, "relatum" is not.
I am no longer thrilled with involves: too many other meanings, such as "baking a cake involves stirring."
I'd like to keep thinking; I haven't yet seen a satisfying option.

At the moment I think gist:hasParticipant is really:
:hasRole/:playedBy

It is already playing out under gist:hasParticipant:
gist:hasRecipient
gist:hasParty
gist:hasGiver

Those are roles in the FrameNet sense of role.
"Each frame has a number of core and non-core FEs [Frame Elements] which can be thought of as semantic roles."
So I think it would be nice to consider adding those 2 primitives :hasRole and :playedBy to gist and then we could possibly formally define gist:hasParticipant as a prop chain axiom.
Here is a snippet from a construct query I use in the Data-Centric data layer that uses these proposals to gist:
 ?txn_node a gist:Transaction ;
   gist:actualEndDate ?txn_date_time ;
   gist:hasMagnitude [ a gist:Balance ;
                       gist:numericValue ?price ;
                       gist:hasUnitOfMeasure gist:_USDollar ] ;
   gistp:hasRole [ gistp:playedBy :_AcmeCo ;
                   gist:categorizedBy wd:Q2596417\#beneficiary ] ;
   gistp:hasRole [ gistp:playedBy ?sales_rep ;
                   gist:categorizedBy wd:Q685433\#sales-rep ]

See https://github.com/semanticarts/gist/issues/695, which also raises the Role issue.

   gistp:hasRole [ gistp:playedBy :_AcmeCo ;
                   gist:categorizedBy wd:Q2596417\#beneficiary ] ;

It is rare in my experience to get enough utilitey from having instances of a Role class. The property is generally sufficient. E.g. for a loan we don't need borrower and lender classes, we just need properties such as hasBorrower and hasLender. The property hasParticipant is meant to be a superproperty of all these properties that are representing roles.

@uscholdm Using an object prop like this
[ a :Transaction ;
  :hasBeneficiary :fred ;
  :hasBuyer :sally ]

is an option but here I list 3 reasons to consider letting a category instance do the work of expressing the kind of role (rather than letting the object property do the work).

@uscholdm Using an object prop like this
[ a :Transaction ;
  :hasBeneficiary :fred ;
  :hasBuyer :sally ]

is an option but here I list 3 reasons to consider letting a category instance do the work of expressing the kind of role (rather than letting the object property do the work).

I just responded to those three possible benefits.


Add request processing pipeline diagrams to middleware doc

Fixes https://github.com/dotnet/AspNetCore.Docs/issues/3524
Internal review page

Hi @scottaddie @mkArtakMSFT
I really like this diagram, what did you use to create it?
Is it https://github.com/microsoft/automatic-graph-layout or is it laid out by hand?
Thanks!

@meoyawn It was created by hand in Visio.


Completed test coverage for validation of loop interface and minor cleaning.

Coverage increased (+0.04%) to 77.149% when pulling 01eb9ae6ead470982e884bb5c8a8b0c9e0495a0c on omegaman123:contiv-crd into 1cf001fa34249494c651e698a085067994dc48c9 on contiv:contiv-crd.


Remove check for file extension when loading scripts

In upgrading all my projects to the latest version of Cake I noticed the PR that added file globbing also introduced a regression where the file extension for loaded scripts must now be .cake. I have several scripts used in the Cake build which are also used directly as scriptcs scripts and they have a .csx extension.
I see no reason for the extension check at all, if you wants *.cake files then glob for them in your file path.
I'm not sure the proposed change is trivial, but it is extremely simple so I thought it was better than just filing an issue.

Thanks for your PR, but a PR to sort this ( #2588 ) was already previously submitted.


Only for Public github?

Hi.
I've deployed both deployment and sidecar.. tried both.
It does not work. I've created a webhook and I see nothing in slack.
don't see any errors from fluxcloud or anything.
just nothing is happening.
tried this on two different clusters.
EKS cluster.
Kubernetes 1.13
flux is working.

Did you configure —connect on Flux?
https://github.com/justinbarrick/fluxcloud#Setup

of course!
..not
:) thank you!
works now.

Great!


Formatting

coverage: 87.301%. remained the same
when pulling 5abb46b5164843df4e1dc2d335cdf3df31608c0f on hazendaz:formatting
into 04f511fd761f0d42881b93639f5f41aa9a14d4f1 on mybatis:master.


Do Not Merge! Keyvi server rebase

@hendrikmuhs
I did refresh/rebase KeyVi-server branch with recent changes.
Please have a look, and if all good I'll push this code into upstream:keyvi-server branch.
Note: pypy builds are failing, but decided do not spend a time on it for now.

@narekgharibyan
This PR is on master, I guess you wanted to open it against keyvi-server?

I opened it intentionally on master so you can see the diff (but I'll not merge it).
When opened on keyvi-server branch, the diff is about 500 files, and it is not mergeable.

ok, but that diff just shows me what is on keyvi-server. I do not get your intent.
Let's chat about it offline (once I fixed the mess on my skype account).

Coverage remained the same at 86.698% when pulling 33b5ec8cc73a9190002931d699e5ff607c4f5ab4 on narekgharibyan:keyvi-server into 33f83e93969fe593bca09b202f727f88a81ab3f7 on cliqz-oss:master.

Coverage remained the same at 86.698% when pulling d687afdfc97002cf12ae172f769647fb90424873 on narekgharibyan:keyvi-server into 33f83e93969fe593bca09b202f727f88a81ab3f7 on cliqz-oss:master.


4.00 sources

have SRC-400.ZIP but without password :/

zip passwords aren't hard to crack, TBH.
I checked my registered disk, and it's also 2.01

0x90h, can you share this archive?

I think we have 4.00 source incoming from another person - I'll check with Gerton and upload if he's okay with relicensing.


Fixed initializer completions

Not the best solution from my poin of view, but it works
Fixes: https://github.com/dotnet/razor-tooling/issues/5827
Before:

After:

Also I didn't manage to create a propper test, because there are too many things to mock, and I didn't manage to do it correctly.🤯😥 I'll allow to edit this PR by maintainers as adding a test is very easy and quick-to-do thing for you because you understand this code 100500 time better than me

 Thank you for your submission, we really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.:x: DoctorKrolic sign nowYou have signed the CLA already but the status is still pending? Let us recheck it.


Add release workflow

Releases can now be triggered via GitHub UI, under Actions -> Release -> Run Workflow.
Beside creating a Git tag for the release, this workflow:

Builds and pushes JVM-based container images (no native images for now)
Creates a GitHub release with auto generated release notes
Generates CycloneDX BOMs for all applications and attaches them to the GitHub release

An example execution can be found here: https://github.com/nscuro/hyades/actions/runs/5718792194/job/15495340977
An example release can be found here: https://github.com/nscuro/hyades/releases/tag/v1.11.0
Closes #708

Looking into if we can move the scm configuration to a build profile.


Add collaborators to this repo

Comment below to be added as a collaborator
We will all be using this repository today. Even though it's public right now, you will not be able to make changes until you're given the correct permissions. We've automated this process via the GitHub API. Once you comment, we will add you as a collaborator.
You'll start to receive a lot of emails. (❗) You can slow these down immediately by clicking the Unwatch button at the top of the page and selecting either the Participating and @mentions or Ignore option.

Vijay - HHSC Git Training 11/13

Github Training - Karmvir Parmar

Git Training

Comment test - Complete

Please add me to repo , sandeep from hhs

Hello

Hi

github  training

Hello

hello


Update README.md

Documentation spelled wrong for task 1

Nice! Merged and canvas updated :)
GeorgiaHenson @.***> writes:

Documentation spelled wrong for task 1

You can view, comment on, or merge this pull request online at:
https://github.com/shanep/cs208-p1-starter/pull/1
Commit Summary

7506eda Update README.md

File Changes
(1 file)

M README.md (2)

Patch Links:

https://github.com/shanep/cs208-p1-starter/pull/1.patch
https://github.com/shanep/cs208-p1-starter/pull/1.diff

—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.


Dataset

Thank you very much for your wonderful work. Can you provide a link to download your dataset?

Hi @chenyu1330 ! Thanks a lot for your interest!
Unfortunately, the dataset is not yet available due to GDPR constraints...
It will be released soon on public-nEUro, and a data paper is already available as preprint: https://arxiv.org/abs/2312.14493


Add new Falling and Pushable components

Should probably include a sample entity too.

Yeah I've started with the slingshot block, will get back to it tomorrow.

alright. merging now. thanks a lot for the components, as well for this entity. i'm actually super glad with how that turned out!!! thanks again


updated styles on creating document record

#23264

[x] Applied filter by Entity Type on Document records table.
[x] Updated styles on creating records form

/gcbrun

Temporary Url for review: https://documents-ui-dev--pr-71-xi2ui9yb.web.app


timemachine module doesn't work in macOS Mojave

I think the problem is apple SIP (System Integrity Protection) as mentioned here
but i will keep researching in case it's something else and maybe find a solution on my way

I'm not able to reproduce this. The module's version wasn't incremented when the latest PR was merged in. I upped it. Try updating the module(s) and test it again.

the double checked the timemachine model and it's up to date with munkireport/timemachine
i'm using MunkiReport Version <IP_ADDRESS>85
Running the timemachine script produces an empty plist
timemachine.plist.txt
and this is the com.apple.TimeMachine.plist on my test device
com.apple.TimeMachine.plist.txt
according to my tests, i was able to read the plist only with defaults, reading it with cat for example comes back with Operation not permitted even with root
with FoundationPlist.readPlist:
Traceback (most recent call last):
  File "timemachine.py", line 126, in <module>
    main()
  File "timemachine.py", line 119, in main
    info = get_time_machine()
  File "timemachine.py", line 44, in get_time_machine
    out = FoundationPlist.readPlist('/Library/Preferences/com.apple.TimeMachine.plist')
  File "/usr/local/munki/munkilib/FoundationPlist.py", line 84, in readPlist
    raise NSPropertyListSerializationException(errmsg)
munkilib.FoundationPlist.NSPropertyListSerializationException: stream had too few bytes in file /Library/Preferences/com.apple.TimeMachine.plist

i'm working on a soloution right now using defaults.
Thanks for helping

Defaults cannot work properly with that script. Is this an upgrade to 10.14 or a new install? The cache file that is used is /usr/local/munki/preflight.d/cache/timemachine.plist, not /usr/local/munki/preflight.d/cache/timemachine.plist.txt

"Defaults cannot work properly with that script"
i know, I'm trying to create a tmp plist file with defaults and then pass it to the FoundationPlist
"timemachine.plist.txt"
i added .txt because GitHub don't allow .plist files

still far from perfect and I'm working on it, but any suggestions are welcomed.
timemachine_fix.txt
Aslo @tuxudo is the script working for you on Mojave?
this is how i fixed it for now
.
.
def mojave_fix(timemachine_plist):
    """Read the TimeMachine plist with defaults, serve it to FoundationPlist"""
    tmp_plist = '/var/tmp/tinemachine.plist'
    cmd = ['defaults', 'read', timemachine_plist]
    proc = subprocess.Popen(
        cmd,
        stdout=subprocess.PIPE,
        stderr=subprocess.PIPE
    )
    (out, err) = proc.communicate()
    try:
        with open (tmp_plist, 'w+') as tmp:
            tmp.write(out)
    except Exception:
        return timemachine_plist
    return tmp_plist

def get_time_machine():

    # Read in com.apple.TimeMachine.plist for processing
    timemachine_plist = '/Library/Preferences/com.apple.TimeMachine.plist'
    if getOsVersion > 13:
        timemachine_plist = mojave_fix(timemachine_plist)
    try:
        out = FoundationPlist.readPlist(timemachine_plist)
    except Exception:
        return {}
.
.

Yes, it is still working correctly for me using the script that is in the module. Are you having these problems on a fresh install of 10.14 or an upgrade to 10.13?

fresh install

i did another fresh install and got the same results, anyway I'm having too many problems with time machine for my backup needs, so I'm moving to another tool.
My fix is still working @tuxudo if you want i can make a PR.
My only wonder is, that it's working for you @tuxudo. I'm using Profile Manager (it's awful i know) to manage my devices, it could be the one responsible for the problem.

I tested this on a machine that has a fresh install of 10.14, still working correctly. My guess is that your /Library/Preferences/com.apple.TimeMachine.plist file is either empty or the profiles are breaking the script. I do know that the timemachine script does not respect preferences set via a profile. That is on my list of things to update. Will look into this tomorrow.

Thank you for taking the time.

com.apple.TimeMachine.plist file is either empty

we can take this one out of the reasons, cuz i already tested it in all ways known to me and my "fix" wouldn't work if the timemachine plist is empty

the timemachine script does not respect preferences set via a profile .

can you give a little more details on that.

The script does not use things set in profiles. Only things that are on in the preference file itself.

Ok, i will wait untell you take a look into it, cuz this for me take us back to the fact, that the /Library/Preferences/com.apple.TimeMachine.plist file exists for me and contains data, which what FoundationPlist.readPlist requires and off curse permissions, which is making the whole problem in the first place.

What version of MR are you using? If newer than 4.0, have you updated the timemachine module?

<IP_ADDRESS>85 and yes, i even used compose to double check

It's strange because the error you posted above don't match up with the lines of the script. Please verify that the timemachine script on one of your 10.14 clients matches the one located here: https://github.com/munkireport/timemachine/blob/master/scripts/timemachine

I'm almost 100% sure it's the same, but i will double check tomorrow at work.

Ok, i double checked and the error is still there using the same script as
https://github.com/munkireport/timemachine/blob/master/scripts/timemachine
Traceback (most recent call last):
  File "timemachine", line 104, in <module>
    main()
  File "timemachine", line 97, in main
    info = get_time_machine()
  File "timemachine", line 21, in get_time_machine
    out = FoundationPlist.readPlist('/Library/Preferences/com.apple.TimeMachine.plist')
  File "/usr/local/munki/munkilib/FoundationPlist.py", line 84, in readPlist
    raise NSPropertyListSerializationException(errmsg)
munkilib.FoundationPlist.NSPropertyListSerializationException: stream had too few bytes in file /Library/Preferences/com.apple.TimeMachine.plist

the reason, why the numbers didn't match last time is that i removed the try, except statement to get the error

Try the script located here: https://github.com/tuxudo/timemachine/blob/profiles_fix/scripts/timemachine
Also, could we move this conversation to the munkireport channel of the MacAdmins Slack (https://macadmins.herokuapp.com/)?

Boom, it works

Thanks a lot.

Wonderful, thank you. I'll make a PR to the main module for this.

Great, i think we can close this issue for now. 👍

can you please link the PR? ran into the same issues and could not find it.

never mind, found it: https://github.com/munkireport/timemachine/pull/2


wrong username/password error

After two days of usage without problems, my node cli script that use this library has stopped working. I'm unable to login from the script and I always get wrong username/password message. I've tried to login from the browser and all is working fine, also tried to get a new ip but without success. Is there a fix I can use for this problem?
The only way to make things work is to use an appstate.json file but now I've changed the password so the file will not work anymore.
I've saved my credentials insida a dedicated .env file

I having same problem. Maybe Zucc changed something.

Where do you find that field? Please can you show a screen of this field?

@sebasbe91  I've done some debug and I've found the field encpass you've writed about in the headers, I think that to make the library working again the headers needs to be intercepted. I'm not sure how the field is generated, seems to be a base64 string combined uding : with a cipher and a key?

I was checking it deeper, it uses a Facebook library that encrypts it with a public key got from the form field. I think it necessary to replicate the same behavior.

I was checking it deeper, it uses a Facebook library that encrypts it with a public key got from the form field. I think it necessary to replicate the same behavior.

Is this library available on github? I want to try logging in using puppeteer or another headless browser, not sure if I will have success

I used dev tools in chrome to check it, needs further investigation.

I used dev tools in chrome to check it, needs further investigation.

let me know if you have any news about. The simplest solution I can think now is to copy the script you've found and then implement it inside the library to send the password crypted in the encpass field? or get cookies after login from chrome, but this will be more tricky

I've used puppeteer to login in messenger, I need to test also with facebook. This way seems working without problems. I'm able to get the needed cookies, I will try to implement it inside this library to replace the actual login method and to provide the needed informations for the correct creation of the appstate.json file.

I've used puppeteer to login in messenger, I need to test also with facebook. This way seems working without problems. I'm able to get the needed cookies, I will try to implement it inside this library to replace the actual login method and to provide the needed informations for the correct creation of the appstate.json file.

Can you show me how to get Facebook cookie as JSON format like appstate.json ?

I've used puppeteer to login in messenger, I need to test also with facebook. This way seems working without problems. I'm able to get the needed cookies, I will try to implement it inside this library to replace the actual login method and to provide the needed informations for the correct creation of the appstate.json file.

Can you show me how to get Facebook cookie as JSON format like appstate.json ?

The cookies that are created after the login with puppeteer are a bit different from the structure of the appstate.json file, I've opted to trying using a different userAgent into the options of the script and seems working. You can reference this issue for more details.
If you want to use puppeteer to get the cookies, you can use something like this:
const puppeteer = require('puppeteer');
const fs = require('fs');
const path = require('path');

( async () => {

(async () => {
    const browser = await puppeteer.launch({
        headless: false
    });

    const page = await browser.newPage();

    await page.goto('https://facebook.com/login, {
        waitUntil: ['load', 'networkidle2']
    });

    const cookieBanner = await page.$('[data-testid="cookie-policy-banner-accept"]');
    await cookieBanner.click();

    const emailField = await page.waitForSelector('[name="email"]', {timeout: 3000});
    await emailField.type(process.env.FB_EMAIL, {delay: 100});

    const passwordField = await page.waitForSelector('[name="pass"]', {timeout: 3000});
    await passwordField.type(process.env.FB_PASSWORD, {delay: 100});

    const submitButton = await page.waitForSelector('[name="login"]', {timeout: 3000});
    await submitButton.click();

    page.waitForNavigation().then( await (response) => {
       console.log(response.url(), response.headers(), response.method());
       // to get the correct cookies you need to pass the url to the cookies() method
       // use await or .then() the promise return an object with all the needed info
       const cookies = await page.cookies(response.url());
       // save your cookies to a file or use them in your code using fs.writeFileSync(...)
    });

})();

The cookies that are created after the login with puppeteer are a bit different from the structure of the appstate.json file, I've opted to trying using a different userAgent into the options of the script and seems working. You can reference this issue for more details.
If you want to use puppeteer to get the cookies, you can use something like this:
const puppeteer = require('puppeteer');
const fs = require('fs');

( async () => {

(async () => {
    const browser = await puppeteer.launch({
        headless: false
    });

    const page = await browser.newPage();

    await page.goto('https://facebook.com/login, {
        waitUntil: ['load', 'networkidle2']
    });

    const cookieBanner = await page.$('[data-testid="cookie-policy-banner-accept"]');
    await cookieBanner.click();

    const emailField = await page.waitForSelector('[name="email"]', {timeout: 3000});
    await emailField.type(process.env.FB_EMAIL, {delay: 100});

    const passwordField = await page.waitForSelector('[name="pass"]', {timeout: 3000});
    await passwordField.type(process.env.FB_PASSWORD, {delay: 100});

    const submitButton = await page.waitForSelector('[name="login"]', {timeout: 3000});
    await submitButton.click();

    page.waitForNavigation().then( await (response) => {
       console.log(response.url(), response.headers(), response.method());
       // to get the correct cookies you need to pass the url to the cookies() method
       // use await or .then() the promise return an object with all the needed info
       const cookies = await page.cookies(response.url());
       // save your cookies to a file or use them in your code using fs.writeFileSync(...)
    });

})();

I'm using your code to get Cookie but the API showing this error
ERR! login Error: Cookie not in this host's domain. Cookie:www.facebook.com Request:www.messenger.com

I tried to get cookie from https://www.messenger.com/ and getting this error
ERR! login Error retrieving userID. This can be caused by a lot of things, including getting blocked by Facebook for logging in from an unknown location. Try logging in with a browser to verify.
{
  error: 'Error retrieving userID. This can be caused by a lot of things, including getting blocked by Facebook for logging in from an unknown location. Try logging in with a browser to verify.'
}

i double-check but my bot account didn't get any Checkpoint

@trangcongloc the library will create a different structure for the cookies that will be saved inside the appsate.json file. If you want to use puppeteer to get only the cookies, after the login you will need to format them to to reflect the appState expected structure otherwise the library will not work.
The wrong username/password error can be fixed by setting a different user-agent instead of the default one used from the library. Please refer to this issue for details.

The cookies that are created after the login with puppeteer are a bit different from the structure of the appstate.json file, I've opted to trying using a different userAgent into the options of the script and seems working. You can reference this issue for more details.
If you want to use puppeteer to get the cookies, you can use something like this:
const puppeteer = require('puppeteer');
const fs = require('fs');

( async () => {

(async () => {
    const browser = await puppeteer.launch({
        headless: false
    });

    const page = await browser.newPage();

    await page.goto('https://facebook.com/login, {
        waitUntil: ['load', 'networkidle2']
    });

    const cookieBanner = await page.$('[data-testid="cookie-policy-banner-accept"]');
    await cookieBanner.click();

    const emailField = await page.waitForSelector('[name="email"]', {timeout: 3000});
    await emailField.type(process.env.FB_EMAIL, {delay: 100});

    const passwordField = await page.waitForSelector('[name="pass"]', {timeout: 3000});
    await passwordField.type(process.env.FB_PASSWORD, {delay: 100});

    const submitButton = await page.waitForSelector('[name="login"]', {timeout: 3000});
    await submitButton.click();

    page.waitForNavigation().then( await (response) => {
       console.log(response.url(), response.headers(), response.method());
       // to get the correct cookies you need to pass the url to the cookies() method
       // use await or .then() the promise return an object with all the needed info
       const cookies = await page.cookies(response.url());
       // save your cookies to a file or use them in your code using fs.writeFileSync(...)
    });

})();

I'm using your code to get Cookie but the API showing this error
ERR! login Error: Cookie not in this host's domain. Cookie:www.facebook.com Request:www.messenger.com

I tried to get cookie from https://www.messenger.com/ and getting this error
ERR! login Error retrieving userID. This can be caused by a lot of things, including getting blocked by Facebook for logging in from an unknown location. Try logging in with a browser to verify.
{
  error: 'Error retrieving userID. This can be caused by a lot of things, including getting blocked by Facebook for logging in from an unknown location. Try logging in with a browser to verify.'
}

i double-check but my bot account didn't get any Checkpoint

It doesn't work for me. I tried using it as TS and as JS and there's errors in both (unfortunately i'm too new to the programming paradigm that javascript uses so i have no idea how to fix this.
TS:

JS:

"ERR! login Error retrieving userID. This can be caused by a lot of things, including getting blocked by Facebook for logging in from an unknown location. Try logging in with a browser to verify.
{
error: 'Error retrieving userID. This can be caused by a lot of things, including getting blocked by Facebook for logging in from an unknown location. Try logging in with a browser to verify.'
}
"
Cookies are valid, but I cannot login

I also got this error when logging in with cookies, however I don't know how to fix it :(

@mobaradev @TuanNV95  Have you tried to set a different user agent as suggested here?

@mobaradev @TuanNV95 Have you tried to set a different user agent as suggested here?

Yes, I tried it but I still get the same error result. I'm not sure, here's my code.

You need to change the user agent of the facebook-chat-api script, not the one exposed from puppeteer.
NB: I've not tested yet with the cookies retrived from puppeter so I don't know if cookies created with it are working with this library.

@mobaradev @TuanNV95 Have you tried to set a different user agent as suggested here?

Yes, I tried it but I still get the same error result. I'm not sure, here's my code.

You need to change the user agent of the facebook-chat-api script, not the one exposed from puppeteer.
NB: I've not tested yet with the cookies retrived from puppeter so I don't know if cookies created with it are working with this library.

Thank you, I made a mistake there, but after changing it, it still returns the same error. Maybe cookie retrieved from puppeteer don't really fit this library.

Im also facing the same problem , I copied the one with puppeteer but when I run the js file nothing happens

@trangcongloc the library will create a different structure for the cookies that will be saved inside the appstate.json file. If you want to use puppeteer to get only the cookies, after the login you will need to format them to to reflect the appState expected structure otherwise the library will not work.
This is the required structure of the appstate.json file.
    {
        "key": "locale",
        "value": "en_US",
        "domain": "messenger.com",
        "path": "/",
        "secure": true,
        "hostOnly": false,
        "creation": "2021-02-23T12:07:23.715Z",
        "lastAccessed": "2021-02-23T12:07:26.469Z"
    }

It's completely different from the cookies that are retrived using puppeteer. the fields key in puppeteer is called name and the hostOnly field isn't present inside the cookies of puppeteer. There can be also other differences but I don't remember exactly
The wrong username/password error can be fixed by setting a different user-agent instead of the default one used from the library. Please refer to this issue for details.

Uh try this. Tell me if it works!
https://github.com/Schmavery/facebook-chat-api/issues/862#issuecomment-762436951

const options = {
    userAgent: 'Mozilla/5.0 (Linux; Android 6.0.1; Moto G (4)) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/85.0.4183.102 Mobile Safari/537.36',
    listenEvents: true
}

const options = {
  userAgent:
    "Mozilla/5.0 (Linux; Android 6.0.1; Moto G (4)) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/85.0.4183.102 Mobile Safari/537.36",
  listenEvents: true,
};

login(loginData, options, (err, api) => {
  if (err) {
    switch (err.error) {
      case "login-approval":
        console.log("Enter code > ");
        rl.on("line", (line) => {
          err.continue(line);
          rl.close();
        });
        break;
      default:
        console.error(err);
    }
    return;
  }
  fs.writeFileSync("appstate.json", JSON.stringify(api.getAppState()));

  // Logged in!
});

This is what I've tried. Still got the error.

const options = {
    userAgent: 'Mozilla/5.0 (Linux; Android 6.0.1; Moto G (4)) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/85.0.4183.102 Mobile Safari/537.36',
    listenEvents: true
}

const options = {
  userAgent:
    "Mozilla/5.0 (Linux; Android 6.0.1; Moto G (4)) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/85.0.4183.102 Mobile Safari/537.36",
  listenEvents: true,
};

login(loginData, options, (err, api) => {
  if (err) {
    switch (err.error) {
      case "login-approval":
        console.log("Enter code > ");
        rl.on("line", (line) => {
          err.continue(line);
          rl.close();
        });
        break;
      default:
        console.error(err);
    }
    return;
  }
  fs.writeFileSync("appstate.json", JSON.stringify(api.getAppState()));

  // Logged in!
});

This is what I've tried. Still got the error.

The error is clear, you have the login approval turned on. Check the documentations about how to solve the problem

const options = {
    userAgent: 'Mozilla/5.0 (Linux; Android 6.0.1; Moto G (4)) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/85.0.4183.102 Mobile Safari/537.36',
    listenEvents: true
}

const options = {
  userAgent:
    "Mozilla/5.0 (Linux; Android 6.0.1; Moto G (4)) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/85.0.4183.102 Mobile Safari/537.36",
  listenEvents: true,
};

login(loginData, options, (err, api) => {
  if (err) {
    switch (err.error) {
      case "login-approval":
        console.log("Enter code > ");
        rl.on("line", (line) => {
          err.continue(line);
          rl.close();
        });
        break;
      default:
        console.error(err);
    }
    return;
  }
  fs.writeFileSync("appstate.json", JSON.stringify(api.getAppState()));

  // Logged in!
});

This is what I've tried. Still got the error.

The error is clear, you have the login approval turned on. Check the documentations to solve the problem.

Well I solved this problem by remove the current 2fa method, then add new one and it just work.

I have a solution here _https://youtu.be/y9_yd5a3scM_
Please tell me if it's works!

@CongTuHaoHoa I am facing TypeError: appState.map is not a function error.


Add TypeScript and general refactor

Motivation
If we want this package to be the "single source of truth" for API3 related projects, then I think it needs to be as robust as possible. However, the current setup has some issues. Specifically:

Lack of types or any kind of safety
It can only be run in a Node.js environment since it depends on fs
It's easy to mess up the JSON files in the chains/ directory
No tests

This PR is an attempt to address points 1-3. Tests can be added in a followup PR if you're happy with this approach
API changes
The currently exported functions have been changed to the following:
import {
  CHAINS, // The static list of supported chains. Replaces `getChains()`
  getChainByAlias, // Replaces `getChain()`
  hardhatConfigNetworks, // The same
  etherscanNetworks, //  The same
  getEnvVariables, // Replaces `writeEnvFile()`
  Chain, // and other types
} from '@api3dao/chains';

Scripts
generate-chains
This script is intended to be run whenever one or more JSON files are changed in the chains/ directory. It reads all of the files and creates a new TS file at src/generated/chains.ts that has the static CHAINS export. This provides type safety to users and allows the package to be included in any environment.
It is run as part of yarn build but can also be run with yarn dev. yarn dev will watch the directory for changes and re-write the file immediately.
validate-chains
This script uses zod defined schemas to validate each of the JSON files in chains/. For example, we can now validate that certain fields are present and conform to required formats (URLs, numbers etc.) If there are errors, the script exits with status 1. All errors are logged to stdout using console.log.
This script is run automatically before publishing to NPM and as part of (newly added) CI.
write-env-variables
The old writeEnvFile has been extracted to a script to allow the package to be used in all environments. The new getEnvVariables function allows for the list of environment variables to be created, while the script actually writes the file.
Usage: yarn env:write --path .env
Considerations

This is a fairly big refactor and would require a new major version if accepted
I'm not too familiar with the various options for building TypeScript packages, so I copied the tsconfig.json files from https://github.com/api3dao/promise-utils. I also tried publishing under my own account and everything seemed to work. See: https://github.com/andreogle/chains
I will update the README if the PR is accepted.
I still want to add tests

tests

Yeah I don't think it's that big of a deal either. Might be nice for ensuring that functions keep working with the expected interfaces.

pre-push hooks

What would you like to see in these hooks? I've added validate:chains and lint for now, but left out validate:providers since they seem to be quite flakey (see broken CI build). lint just runs exit 0 for now - I'll add ESLint in a followup PR.

write-env-variables

This requires a --path option, so I don't think it's that dangerous. It will only overwrite an existing .env file if you run the script as yarn env:write --path .env
I still want to touch up the main README file before merging this PR

What would you like to see in these hooks?

Lint and the validations if they are fast enough. If the CI check is flaky I agree with skipping (alternative is to make it non-required -- this is probably overkill).
Otherwise, make sense.

I've updated the README.md file with the API changes. Let me know what you think. It could still be improved further, but it at least describes the minimum.
Also, the validate:providers script is proving to be pretty flakey. I'm not sure if this should be included in CI.

Say I add a particular version of @api3/chains to airnode-protocol-v1. I don't understand the intended flow to generate example.env in airnode-protocol-v1.
I think validate:providers is misnamed in that what it does is very different to what validate:chains does. I think it should be called something else and not be added to CI. This repo should export multiple providers per chain at some point (one suitable for contract deployment, one suitable for RRP for ChainAPI to use as the default public provider, etc.) and @bdrhn9 should maintain the provider URLs along with implementing the necessary monitoring (either within this CI or externally).

Say I add a particular version of @api3/chains to airnode-protocol-v1. I don't understand the intended flow to generate example.env in airnode-protocol-v1.

Do you mean that you want chains at a certain point in time/package version? I didn't realise that this was a requirement. I assumed that the latest package version was always going to be preferable.
I guess there are two main options

Pull the repo and checkout the release commit. Run yarn env:write --path .env
Continue importing the specific package version, but instead use getEnvVariables() and do the writing  (fs.writeFileSync()) in the importing project there.

I still feel that a script is better suited here and the workarounds above can be used if needed.

I think validate:providers is misnamed

Sure I'm happy to change the name. The previous name was check-provider - I can use that or anything similar (providers:check?, providers:ping?). I'll also remove it from CI

Ah okay, I hadn't noticed that getEnvVariables() was exported. I don't like the fact that all depending projects will duplicate that piece of code but I don't see any better way.

Yeah it's maybe not ideal, but dropping the fs & path dependencies are more important imo

I think this is ready to be merged now. Let me know if you want me to hit the button. I assume we'll want to publish v2.0.0 for this too

:shipit:


error when executing make l4t-32.3.1-jax

Hi @idavis ,
Here is a first error I encountered.
When running:
jetson-containers$ sudo make l4t-32.3.1-jax

I get
Step 11/32 : RUN apt-get update && apt-get install -y --no-install-recommends     bzip2     lbzip2     ca-certificates     gnupg     sudo
 ---> Running in b3bd7493802f
standard_init_linux.go:211: exec user process caused "no such file or directory"

@eliabruni

What is your host OS?
What container runtime are you using?
Can you show the whole build log?

Thank you,
Ian

Hi @idavis ,

OS: Ubuntu 18.04.4 LTS
runtime: Docker version 19.03.5
Whole build log follows below

PS
make l4t-32.2.1-jax gives me the same error; I tried to run it on jetson-containers before #27, and it worked fine.
jetson-containers$ sudo make l4t-32.3.1-jax
make -C jetson-containers/docker/l4t 32.3.1-jax
make[1]: Entering directory 'jetson-containers/docker/l4t'
docker build --squash \
				--build-arg VERSION_ID="bionic-20200112" \
				--build-arg DEPENDENCIES_IMAGE=l4t:32.3.1-jax-jetpack-4.3-deps \
				-t l4t:32.3.1-jax \
				- < jetson-containers/docker/l4t/32.3.1/jax/Dockerfile
Sending build context to Docker daemon   5.12kB
Step 1/32 : ARG VERSION_ID
Step 2/32 : ARG DEPENDENCIES_IMAGE
Step 3/32 : ARG IMAGE_NAME
Step 4/32 : FROM ${DEPENDENCIES_IMAGE} as dependencies
 ---> b8f3fbbbeda1
Step 5/32 : ARG VERSION_ID
 ---> Using cache
 ---> c5b8edeaa708
Step 6/32 : FROM ubuntu:${VERSION_ID} as qemu
 ---> ccc6e87d482b
Step 7/32 : RUN apt-get update && apt-get install -y --no-install-recommends qemu-user-static &&     apt-get clean &&     rm -rf /var/lib/apt/lists/*
 ---> Using cache
 ---> fd0919abbd41
Step 8/32 : ARG VERSION_ID
 ---> Using cache
 ---> 2cf05037f784
Step 9/32 : FROM arm64v8/ubuntu:${VERSION_ID}
 ---> db472617b3d1
Step 10/32 : LABEL maintainer "Ian Davis"
 ---> Using cache
 ---> 04a7b59627cc
Step 11/32 : RUN apt-get update && apt-get install -y --no-install-recommends     bzip2     lbzip2     ca-certificates     gnupg     sudo
 ---> Running in 28421b1c10e9
standard_init_linux.go:211: exec user process caused "no such file or directory"
The command '/bin/sh -c apt-get update && apt-get install -y --no-install-recommends     bzip2     lbzip2     ca-certificates     gnupg     sudo' returned a non-zero code: 1
Makefile:29: recipe for target '32.3.1-jax' failed
make[1]: *** [32.3.1-jax] Error 1
make[1]: Leaving directory 'jetson-containers/docker/l4t'
Makefile:50: recipe for target 'l4t-32.3.1-jax' failed
make: *** [l4t-32.3.1-jax] Error 2

Hi @eliabruni , I know what the issue is. In pre #27 I copied the qemu binary into the container. Now I copy it, but for a different reason and into a different path as 4.3 requires it to be there for some of their scripting. There are two options:

Follow the Configuration section of ARMing yourself and it should just work.
Add this line into your dockerfile right after LABEL ...# pre-req qemu binary for aarch64 emulation if this container image is built directly on x86 host
COPY --from=qemu /usr/bin/qemu-aarch64-static /usr/bin/qemu-aarch64-static

The long term option is to either put it back in the generated dockerfiles or to require people to use the
ARMing yourself post as config. I don't like either option.

@eliabruni This should be fixed on master now.

@idavis
Thanks, that part passes now. I still get an error:
Pre-installing bootloader package, skip flashing
Setting up nvidia-l4t-multimedia-utils (32.3.1-20191209230245) ...
Setting up nvidia-l4t-3d-core (32.3.1-20191209230245) ...
Setting up libpangocairo-1.0-0:arm64 (1.40.14-1ubuntu0.1) ...
Setting up nvidia-l4t-cuda (32.3.1-20191209230245) ...
Setting up nvidia-l4t-multimedia (32.3.1-20191209230245) ...
Setting up nvidia-l4t-camera (32.3.1-20191209230245) ...
Setting up nvidia-l4t-graphics-demos (32.3.1-20191209230245) ...
Setting up nvidia-l4t-gstreamer (32.3.1-20191209230245) ...
Processing triggers for libc-bin (2.27-3ubuntu1) ...
Processing triggers for nvidia-l4t-kernel (4.9.140-tegra-32.3.1-20191209230245) ...
/
Removing QEMU binary from rootfs
Removing stashed Debian packages from rootfs
/Linux_for_Tegra/nv_tegra/nv-apply-debs.sh: line 216: /bin/rm: No such file or directory
The command '/bin/sh -c ./Linux_for_Tegra/apply_binaries.sh -r /' returned a non-zero code: 127
Makefile:29: recipe for target '32.3.1-jax' failed
make[1]: *** [32.3.1-jax] Error 127
make[1]: Leaving directory 'jetson-containers/docker/l4t'
Makefile:50: recipe for target 'l4t-32.3.1-jax' failed
make: *** [l4t-32.3.1-jax] Error 2

@eliabruni You have the best errors. The issue is that since you haven't installed the binftm service configuration. The nvidia scripts are deleting the qemu-aarch64-static file that you need to keep running. So the first rm succeeds, but then rm afterwards cannot be run.
echo "Removing QEMU binary from rootfs"
rm -f "${L4T_ROOTFS_DIR}/usr/bin/qemu-aarch64-static"

echo "Removing stashed Debian packages from rootfs"
rm -rf "${L4T_ROOTFS_DEB_DIR}"

Ups:) Thanks, I guess I'll install the service and run it again.

I'm sorry you've hit these issues. I have a fix, just trying to get it built out.

No worries, I'm happy I can provide some little feedback!

@eliabruni  This should now be fixed. Thank you again.

It is, thanks!


Onesignal run to localhost ?

Hi, onesignal localhost runing ???

I want to work through the local server. but I did not do it. Could you help


[BUG REPORT] Maccy is crashing as when I am using the search. As long as I don't use it everything works fine.

[BUG REPORT] Maccy is crashing as when I am using the search. As long as I don't use it everything works fine.
sometimes the 5th char sometimes the 8th.
The problem is only recent. I am pretty sure it worked before without issues as I would not have noticed it otherwise.
0.25.0
Macbook Pro M1.
999 history size
Does it produce a log somewhere?
Thanks for this amazing tool!

Thanks for the prompt reply.
Alright, I will wait for the new release and test it out and if the problem still persists 'll send my history and make sure the db is cleaned of anything sensitive.

Could you try running the newest unreleased version and see if it helps Maccy.app.zip? I wouldn't recommend using it all the time but could be fine for a quick test.

Clearing the history worked for me. Sometimes this is not a bad idea.

Ok, well, there is not much I can do about it without examples. I'll close the issue - feel free to re-open with more details and preferably attached database.


Can't connect to remote DB

I have problem with connecting with remote DB. This is my code snippet:
import PouchDB from 'react-native-pouchdb';
PouchDB.plugin(require('pouchdb-adapter-asyncstorage').default);
const usrs = new PouchDB('http://<IP_ADDRESS>:3000/proba');
usrs.info().then(function (result) {
console.log("info: ", result);
}).catch(function (err) {
console.log(err);
 });
I have this error:
CustomPouchError {status: 400, name: "bad_request", message: "Missing JSON list of 'docs'", error: true}
Please help, I lost 2 days trying to resolve this problem.

Hi,
i do not know the package 'react-native-pouchdb';
if you use the package, do
npm i pouchdb-react-native

import PouchDB from 'pouchdb-react-native'

....
const usrs = new PouchDB('http://<IP_ADDRESS>:3000/proba')
....

http and asyncstorage adapter are already bundled
Christoph


🚀 [New Feature_WebApp] - Pricing Section Text Alignment

Description of the enhancement. ✍🏻
The current design is nice but it can be improved by aligning the "Pricing" Section content in center which will create consistent flow of alignment relative to other content of the website.
Describe briefly how you would implement this enhancement.
Some steps to implement this enhancement-
1. Alignment of paragraph under Pricing Section heading in center
2. Alignment of "Month/Year" buttons in center

Screenshots Example (if applicable)
Current Alignment

Expected Updated Alignment

Additional information
No response
Contributor terms

[X] I agree to follow the Contributing Instructions

Good one, go for it! :blus


Packaging - master

1 of 2 Pull Requests.
This is an update to bring all packaging updates to master branch.
Secondary pull request will contain updates to gh-pages, which will reflect installation updates.

Coverage remained the same at 34.503% when pulling 4679dc8dd5bd79cb3a5d9277f872a4837c61bc7e on InvalidToken:master into 9834d87c53a9e999b67bd7ed9daf589595257c00 on failys:master.


HOV-27 | Select Component

Expected Behavior
Make a <Select> Component
Features:

Should come with default select props
Inherit from <select>

Current Behavior
No select button component

[ ] Make spec for select component
[ ] Make the base component with API and without styles
[ ] add styling

closed by #83


Write tutorial on using F5 load balancer ingress controller

Is your feature request related to a problem? Please describe.
We should write a document on using cert-manager to issue certificates, and utilising those certificates using an ingress controller.
For the sake of diversity between controllers, we can utilise the F5 ingress controller for this.
We should:

obtain a certificate from an issuer, we can use Venafi as an example but hop-off to other Issuer types here too
show how to configure that certificate using an Ingress resource
demonstrate it works

This can follow a similar format to the nginx-ingress & soon-to-exist EKS tutorial
/kind documentation
/priority important-soon
/milestone v0.8
/area venafi

The direction of this may have changed given F5s move towards nginx after the acquisition!


support only some specific kubernetes version?

I am trying to run test with kubernetes version v1.19.13 using most of example scripts.But I don't think it's working. For an example,
get-pod.js - when I run it from local and pod not present in namespace,the test should display: pod not found

Hi @jsarkar! Sorry for the delay, I hadn't realized this was pending for me 😓.
Please provide a bit more context. I was able to confirm operation against a local v1.19.11 cluster. Were you able to build the new k6 binary?

Closing this issue as investigation could not discover an issue and no additional feedback provided.


add publications

Type of Change
documentation
API not changed
Description
add publications
Expected Behavior & Potential Risk
n/a
How has this PR been tested?
n/a
Dependency Change?
n/a

The change included in #1859


Playback latency

In my mobile app, I need a short sound to play when I tap a button. And I need as good precision as possible, that is, as short latency between the tap and the sound as possible.
But the latency is approximately 150-200 ms when running the app on a (modern) iPhone, which is not good enough for my application. There are similar apps out there (non-MAUI), where this lag is significantly less, so it is not hardware related.

I am using a really small wav (7 kB).
I am preparing the audio player once, loading the stream when the app loads.
The only action when tapping the button is invoking Play() or PlayAsync().
I am running the app on device (no emulator).
Tried running in Release mode without debugging, no (noticable) difference.

I assume that this lag is not related to the Maui.Audio plugin, but perhaps someone has a clue or workaround how to get around this issue? Do I need to switch to another platform?
Thanks.

It is interesting that you are seeing some latency. Out of interest how are you measuring this latency?
A couple of things that I would try:

Check that your sound starts right at the beginning of the file and there isn't any silence mimicking latency.
If you are using a Command/Clicked event swap to using the Pressed event on the Button to see if you can get a quicker response.

@bijington, thanks for your tips! Changing to the Pressed event didn't help but made me realize that the latency is in the Button control and not related to the sound playback at all. When I press the button (and hold) there is a delay before the button "reacts". For the default MAUI button this is shown by the text turning grey. And at that exact moment, my sound plays.
So what I need is a button with shorter response time.
Regarding the latency, I have not measured it but rather estimated it by comparison. I am developing a rythmic exercise app, and I guess a latency around 50 ms would be acceptable, 25 ms would be great.

@githubjanson out of curiosity did you find a solution for this issue?
If not, are you using compiled bindings or have you filed an issue in the MAUI repo?

Seems unlikely a problem with Plugin.Maui.Audio in my case. Other MAUI elements don't seem to have a latency but I also noticed a delay on button clicks. I had tried calling play from event triggers of pressed and clicked. Then from inside a custom button OnPressed. Also curious to know @githubjanson if you found a solution.

Hi @borrmann, @its-jefe,
I skipped the Button control and am using the SKCanvasView/Touch event instead. This gives me the best experience, i.e., a minimal latency beteen the tap and the sound.

Looks there is a solution. For a next time it would be super helpful if you could include a reproduction project so we can have a look together with you and easily see if this reproduces on our end as well as well as maybe fix it. For now closing this. If there is still something that needs to be investigated here, please let us know!


Automatic shadow biasing

What problem does this solve or what need does it fill?
Shadow acne is an artifact that occurs when sampling the shadow map. The shadow map surface you intend to sample was discretized into the shadow map, which might not perfectly match the sample position.
The solution is to bias the sampling position away from the surface a little.
What solution would you like?
An automatic algorithm to compute a good shadowing bias.
State of the art is "Oriented Depth Bias" from FFXVI http://www.jp.square-enix.com/tech/library/pdf/2023_FFXVIShadowTechPaper.pdf#page=28.
What alternative(s) have you considered?
A constant shadow bias is already supported by our lighting system. It's hard to find a good value for this that doesn't result in objects appearing to disconnect from their shadows.
Additional context
An older method called "Receiver Plane Depth Bias" was tried in https://github.com/bevyengine/bevy/pull/10188.

It is not an alternative to receiver plane depth bias but rather an alternative to the manual depth and normal biases that we have today.
Receiver plane depth bias is about adjusting the depth bias being applied when comparing a shadow map sample that is offset from the screen fragment’s position in the shadow map for PCF. It or something like it is still needed even with oriented depth biasing I believe.


Update starting-a-project.md

[ ] Have you followed the contributing guidelines?
[ ] Have you explained what your changes do, and why they add value to the Guides?

Please note: we will close your PR without comment if you do not check the boxes above and provide ALL requested information.

ممكن التوضيح  ماهو عمال الذي اقوم بي


unit-tests: move out of lib in dedicated folder

Description
Move unit tests in dedicated folder
Changes include

[X] Bugfix (non-breaking change that solves an issue)
[ ] New feature (non-breaking change that adds functionality)
[ ] Breaking change (change that is not backwards-compatible and/or changes current functionality)
[X] Tests
[ ] Documentation
[ ] Other (for changes that might not fit in any category)

Codecov Report
Patch and project coverage have no change.

Comparison is base (357d20a) 85.97% compared to head (bb1ec6c) 85.97%.

Additional details and impacted files
@@           Coverage Diff           @@
##           master     #278   +/-   ##
=======================================
  Coverage   85.97%   85.97%
=======================================
  Files           8        8
  Lines         385      385
=======================================
  Hits          331      331
  Misses         54       54

Flag
Coverage Δ

unittests
85.97% <ø> (ø)

Flags with carried forward coverage won't be shown. Click here to find out more.
Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here.

:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Do you have feedback about the report comment? Let us know in this issue.


Add beverages section

Title and Issue number
Title :Beverages
Issue No. : 1161
Code Stack : HTML , CSS , JS
Close #1161

Video (mandatory)
https://github.com/user-attachments/assets/ff08fadf-a156-4df7-96d2-7e9ba7093493
Checklist:

[X] I have mentioned the issue number in my Pull Request.
[X] I have commented my code, particularly in hard-to-understand areas
[X] I have created a helpful and easy to understand README.md
[X] I have gone through the  contributing.md file before contributing

Additional context (Mandatory )
It would add variety to the website
Are you contributing under any Open-source programme?

[X] I'm a GSSOC'24 contributor
[ ] I'm a SSOC'24 contributor

@apu52 please review this PR and merge it


[Docs] Fix a broken link

This PR fixes a broken link in Notes on flattening
This PR has:

[ x ] been self-reviewed.

👍


Error message should be more specific in case of non-unique dns prefix

Error thrown when a non-unique dns prefix is specified is below
At least one resource deployment operation failed. Please list deployment operations for details. Please see https://aka.ms/arm-debug for usage details. {
"status": "Failed",
"error": {
"code": "ResourceDeploymentFailure",
"message": "The resource operation completed with terminal provisioning state 'Failed'.",
"details": [
{
"code": "PreflightValidationCheckFailed",
"message": "Provisioning of resource(s) for container service 'myacs' in resource group 'myacs-rg' failed with 1 error(s): \n Resource target: , code: PreflightValidationCheckFailed, message: \n Preflight validation failed. Please refer to the details for the specific errors.\r\n"
}
]
}
}
Error message should be more specific

@pragyamehta
Can you provide details on what command produced this error message?
Also what version of the CLI was installed? az --version

az acs create --resource-group myacs-rg --name myacs --dns-prefix myacs
az --version
azure-cli (0.1.0b9)
acr (0.1.0b9)
acs (0.1.0b9)
appservice (0.1.0b9)
cloud (0.1.0b9)
component (0.1.0b9)
configure (0.1.0b9)
container (0.1.0b9)
context (0.1.0b9)
core (0.1.0b9)
feedback (0.1.0b9)
network (0.1.0b9)
profile (0.1.0b9)
resource (0.1.0b9)
role (0.1.0b9)
storage (0.1.0b9)
vm (0.1.0b9)
Python (Windows) 3.5.2 (v3.5.2:4def2a2901a5, Jun 25 2016, 22:18:55) [MSC v.1900 64 bit (AMD64)]

Acknowledged.  We should do a better job of validating in the API server before we send the request on...
We can add extra checks in the CLI as well.

Cleaning u old issues, reopen if this is still active.


First word is not highlighted when annotating texts

Describe the bug
A clear and concise description of what the bug is.
When I want to put labels on text data for the NER NLP task including the first word of the sentence
To Reproduce
Steps to reproduce the behavior:

Start annotating some text
Select a label one wants to annotate the first word (or an entire sentence including the first word)
The label appears in the "Regions" section (on the right by default), but the area that was selected is not highlighted in the text

Expected behavior
A clear and concise description of what you expected to happen.
Labeling the first word (or the whole sentence with the first word) should also highlight the text.
Screenshots
If applicable, add screenshots to help explain your problem.

Possible duplicate of https://github.com/heartexlabs/label-studio/issues/1208

@uklft yes, sure, my issues seems the same as yours

@uklft @sharkzeeh could you check the latest LS master branch? I hope it's fixed there.

@makseq For me this issue is sadly not resolved with the latest master branch. Same problem and same error messages in the js-logs:

@uklft @sharkzeeh could you check the latest LS master branch? I hope it's fixed there.

We are also using the latest version from the master branch

I have the same issue. If the span starts on a new line, it is not highlighted.

@sharkzeeh @uklft @1ytic
https://github.com/heartexlabs/label-studio/pull/1234
Could you install LS from this branch please (fix/highlight-ls) and check this problem again?

Hey @makseq, it seems to work for me. Thank you so much for fixing it that fast!

Do we have any update on when #1234 is expected to be merged to master?

@lluissalord  @makseq
Hi! Sorry, I didn't answer yesterday. I've tried it - works as expected now! Thanks

tried this fix by using git checkout only... I still encounter this issue :(

See image for reference

using branch fix/highlight-lsf

ok seems that when you download the entire source code from this branch it fixes the issue.
Hope you could push this fix in master 👍 Thanks... Kudos to the one who fixed this