Build official curl binaries with PSL

There is code to do so in this repo, but the binaries at https://curl.se/windows/ do not support PSL. Ref: https://daniel.haxx.se/blog/2024/01/10/psl-in-curl/

See my comments about the state of PSL in this latest commit:
https://github.com/curl/curl-for-win/commit/dd7ce0a9d2d350900abd0f0f565c0dc4c660461b

I saw that commit, but it wasn't clear to me what the bottom line was. Most
of those issues affect non-Windows builds, too. Is it hesitation to switch to
libidn2? Right now, 100% of applications using these binaries are affected by
the super cookie vulnerability, whereas by switching to libidn2, some
considerably lower percent of applications, possibly even 0%, would be affected
by a different issue.

To support this, libpsl would ideally need to receive WinIDN support and the PSL database a versioned and verifiable package that we can use a dependency like any other. But, it also seems to update very frequently which means a manual curl-for-win update for every one of them, or a need to develop automatic bumps and releases to keep up with it. Or, we rely on the libpsl-bundled copy, which is 1+ year old at this point.
As for build times and binary sizes: libpsl requires a list of heavy GNU dependencies to even load (and/or compile-in) the PSL list: libidn2, libunistring and libiconv. This also means that we need to switch away from WinIDN for Windows, which in turn means that the IDN behaviour diverges for all the other Windows apps that typically use WinIDN. Again something to (re)test, but these libs have a significant effect on the binary sizes, even though the PSL list by itself is just 200KB (and possibly could be zipped, if libpsl added support for this).
On build complexity: libpsl and its dependencies only support autotools, which is currently broken with Linux MUSL builds and I couldn't fix them despite spending quite many full days on it. At the moment it looks hopeless to make it work. (I've been shifting to CMake where possible, and for now no default dependency needs autotools.)
That said, if someone doesn't mind these issues or wants to play with it, libpsl can be enabled with the -big build option. It's been a while I have tested it though.

I don't know what the solution is, but carrying this heavy, autotools-based dependency tree doesn't seem like a workable way to me.
Perhaps a stable subset of the PSL built right into curl might improve for "most" use-cases, while clearing almost all of this complexity?

I was also wondering if the PSL is exposed via a Windows API perhaps (a casual search didn't turn up anything). Surely Windows also needs it, or at least its browsers do. Same for Linux and others, speaking of a list that is almost as critical as the certificate bundle (?), it'd be ideal to have it refreshed and maintained by the OS, also ensuring consistency between apps that need it. But I'm afraid this is just missing as of yet and every app is rolling its own copy.

How do Windows-native applications do this? Is there a kind of PSL built-in to Windows like IDN has?

Good question, I couldn't readily find an API for this. I can imagine this is limited to the browser engine (Edge/Chromium) and maintained just like the HSTS-preload list. (though there is a fresh notion to depart from that static list: https://groups.google.com/a/chromium.org/g/blink-dev/c/cAS525en8XE).

I'm also wondering if pre-converting the PSL list to Punycode might help dropping the heavy dept tree. This'd need local tooling and/or support from the PSL list project (to publish it in that format) and also from libpsl. I'm not familiar with Punycode details, so this may be simplistic view of the topic and not workable. Maybe it's just simpler to add Unicode support to libpsl via native-Windows API.
libpsl also needs to fix the _WIN32_WINNT override issue, but I have no more capacity to report, follow-up and often fix the issues experienced for every dependency. (It's already way beyond any sustainable limit.)

I'm also wondering if pre-converting the PSL list to Punycode might help dropping the heavy dept tree.

To be honest, I think it is a shame that it doesn't do that already.

I filed https://github.com/rockdaboot/libpsl/issues/220 to at least trigger some discussion. I fear the only way that will happen is if we make a new psl lib. I would not be totally against such a move.

I'm also wondering if pre-converting the PSL list to Punycode might help dropping the heavy dept tree.

To be honest, I think it is a shame that it doesn't do that already.

I am not sure what is a shame exactly.
The libpsl DAFSA lookup data already contains the punycode AND the unicode/utf-8 strings.
You can can have the lookup data as an external blob, which is loaded very fast on demand (no parsing is needed or done, only file -> memory mapping). This allows to update the PSL lookup data without any rebuild of software. There is a Python script psl-make-dafsa as part of the libpsl repo for this.
The alternative, interning the DAFSA data into libpsl, has the downside that it may be come outdated. BUT, even interned data can simply be overridden by an external blob. So you can use the internal data as "fallback" in case an external file isn't available.
There is an SHA1 hash for the internal data, so in theory it allows some basic version control.
From past experience, I'd say that the PSL list evolves relatively slowly and that the big players are all in. So even 1-2 year old lookup data contain 99% the same data as the current list does (the % number is just pulled from thin air, don't rely on it).
If all that is not enough, I am happy to review a PR for WinIDN for additional degrees of freedom.

I was also wondering if the PSL is exposed via a Windows API perhaps (a casual search didn't turn up anything). Surely Windows also needs it, or at least its browsers do. Same for Linux and others, speaking of a list that is almost as critical as the certificate bundle (?), it'd be ideal to have it refreshed and maintained by the OS, also ensuring consistency between apps that need it. But I'm afraid this is just missing as of yet and every app is rolling its own copy.

Updating the PSL is e.g. part of Debian derived Linux distributions.
The package name is publicsuffix and the libpsl package is built/configured in a way to load this data when used. In Debian, the publicsuffix package version reflects the date of the PSL list, e.g. 20231001.0357-0.1.
I assume that other Linux distros do something similar.

Thanks for jumping in. I'd be happy to rely on the PSL copy bundled with libpsl, but that (unless I'm missing something) is not possible to compile-in, without pulling in the heavy Unicode dependencies. I'd imagine the smoothest way to fix this would be to bundle a punycode copy and allow to compile-in that one, without the requirement for any Unicode dependency.
It's good news that the list is relatively stable, but relying on a Debian package for versioning sounds limiting and needs a series of hacks (even on Debian, to maintain reproducibility) compared to all other dependencies. These builds also support non-Debian envs (Alpine, MSYS2 and macOS, where dealing with Debian packages is certainly possible in some ways, but a heavy development and maintenance cost).
That still leaves autotools as a major blocker. With most MUSL builds and Windows-llvm (the job used for official binaries) in the red, failing right away in ./configure.
Windows-gcc actually gets to libpsl, after a long list of warnings in libiconv, some in libunistring and libidn2, then stopping in libpsl with these:
<command-line>: warning: "_WIN32_WINNT" redefined
<command-line>: note: this is the location of the previous definition
../../tools/psl.c: In function 'time2str':
../../tools/psl.c:93:13: warning: implicit declaration of function 'localtime_r'; did you mean 'localtime_s'? [-Wimplicit-function-declaration]
   93 |         if (localtime_r(&t, &tm) != NULL)
      |             ^~~~~~~~~~~
      |             localtime_s
../../tools/psl.c:93:34: warning: comparison between pointer and integer
   93 |         if (localtime_r(&t, &tm) != NULL)
      |                                  ^~

https://github.com/curl/curl-for-win/actions/runs/7512934079/job/20454167810#step:3:11661
The complete run:
https://github.com/curl/curl-for-win/actions/runs/7512934079
Based on the jobs working, the size cost is 400-500KB for the curl tool binary, 1MB for libcurl shared lib. These do NOT include the PSL bundle itself (as I've found out earlier this week it's not included by default and I haven't updated the scripts to do it), which would be an extra 200KB, plus an extra 4.5MB of static libs (of which libpsl is just 77KB). This applies to all operating systems. Using WinIDN would only help the Windows binaries, but not the statically linked Linux and macOS ones.
Using a punycode list would help to reduce the overhead to about 250-300KB for curl/libcurl and static libs, and cut build times to reasonable amount. Having an option to zip PSL up, could cut the size in half, making it almost invisible.
(Maybe useful option to disable any kind of loading-from-disk functionality in libpsl. This would likely fix the localtime_r error too.)
But then autotools remains a blocker.

This is several issues at once, let's get at them one by one :)
The build issue you mention has been fixed by https://github.com/rockdaboot/libpsl/pull/193 and https://github.com/rockdaboot/libpsl/pull/195.
Maybe I should raft a new release...

It's good news that the list is relatively stable, but relying on a Debian package for versioning sounds limiting and needs a series of hacks (even on Debian, to maintain reproducibility) compared to all other dependencies. These builds also support non-Debian envs (Alpine, MSYS2 and macOS, where dealing with Debian packages is certainly possible in some ways, but a heavy development and maintenance cost).

Oh yeah. I was mentioning Debian only as an example how it could be done and how some distros do it. I assume there are several ways to achieve the same, but I know not enough about your goals to make concrete suggestions here.

Now there is a new release for you which fixes several build issues: https://github.com/rockdaboot/libpsl/releases/tag/0.21.3

If you are unhappy with autotools, libpsl also supports meson and nmake.
If there are issues with those, please create an issue (I don't/can't maintain these parts of the code).

To build libpsl without dependency to libidn, libidn2 or libicu, use the autotools configure flag --disable-runtime. With this (on Linux, after make install):
$ ldd /usr/local/lib/libpsl.so.5.3.5
        linux-vdso.so.1 (0x00007fff6cd0c000)
        libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007fa886bc2000)
        /lib64/ld-linux-x86-64.so.2 (0x00007fa886dd7000)

So no further dependencies, except for libc.

Regarding the size considerations, a stripped version of libpsl with PSL lookup data included:
-rwxr-xr-x 1 root root 71768 Jan 13 19:29 /usr/local/lib/libpsl.so.5.3.5

Without PSL data included (./configure --disable-runtime --disable-builtin):
-rwxr-xr-x 1 tim tim 18520 Jan 13 19:33 src/.libs/libpsl.so.5.3.5

Thanks, for the release!
[ Regarding meson, it seems way too much effort to start fitting it into all the build cases on all supported platforms. Also something to learn from scratch, then continue testing and maintaining. CMake would be a nicer path IMO. I don't like it either, but it's widespread, portable and works reasonably well. nmake is Windows/MSVC only. ]
As for the new release, it's missing a .sig and uses a different release name/format than previous ones, now also needing autoreconf. Then autoreconf fails in my local test:
[...]
configure.ac:4: installing 'build-aux/missing'
automake: error: cannot open < gtk-doc.make: No such file or directory
autoreconf: error: automake failed with exit status: 1

This patch should fix the _WIN32_WINNT issue. These days mingw will target newer Windows versions by default, so this trick is unnecessary in most cases. Someone using an ancient mingw version can add the necessary _WIN32_WINNT value. The other solution is to extend the script to only add it, if it's not already present in CPPFLAGS, but that seems overkill to me.
--- configure.ac-ori
+++ configure.ac
@@ -304,8 +304,6 @@
   case "${host_os}" in
     # MinGW / Windows
     *mingw*)
-      # Select Windows NT/2000 and later, for WSAStringToAddressW()
-      CPPFLAGS="$CPPFLAGS -D_WIN32_WINNT=0x500"
       # Needed for network support
       LIBS="$LIBS -lws2_32"
       ;;

From the linked commit;

obtaining a fresh PSL database means another build-time dependency: Even though the PSL has security/privacy implications, its releases are missing versioning, a hash and also a signature, making it tedious to package it verifiably and reproducibly. The libpsl project rejected these raised issues in 2016: https://github.com/publicsuffix/list/issues/31

This feels a bit confusing as it's linking to the publicsuffix project and then claiming that libpsl was the project that rejected the issue.
...

[ Regarding meson, it seems way too much effort to start fitting it into all the build cases on all supported platforms. Also something to learn from scratch, then continue testing and maintaining. CMake would be a nicer path IMO. I don't like it either, but it's widespread, portable and works reasonably well. nmake is Windows/MSVC only. ]

Interesting that you "don't like it either" but nonetheless want to use it... a ringing endorsement.
Anyways I don't understand why you need to learn it from scratch and maintain it to boot. It's a build system, your interface to it is precisely no more and no less than executing its CLI interface, save for the case where you decide to contribute modifications upstream.
And it's widespread, portable, and works reasonably well. :)

As for the new release, it's missing a .sig and uses a different release name/format than previous ones, now also needing autoreconf. Then autoreconf fails in my local test:

Sorry, I was too much in a hurry yesterday and had to release https://github.com/rockdaboot/libpsl/releases/tag/0.21.5, now including the assets (tarballs with signature).
The autoreconf issue stems from the fact that Github generates its own asset, which is not a tarball. This is often confusing to users. Building from the tarballs doesn't require autoreconf (that even may break things for you).

@eli-schwartz Ultimately it's not about what I like, but what works (or can be made to work) for the cases interesting for this project. I managed with CMake, with autotools it seems borderline impossible at the moment. That said anybody is welcome to contribute fixes. Taking up meson is out of my capacity. It also isn't supported by any other dependency here. Also I'm not here to start yet another flame ware, this time about build systems.
libpsl/psl was a typo I corrected earlier.

@rockdaboot: Thanks, looking at it.

Regarding _WIN32_WINNT: I'd rather prefer https://github.com/rockdaboot/libpsl/issues/226
That also removes a runtime dependency on Windows (ws2_32.dll).

@rockdaboot Agreed, dropping ws2_32 depedency would be the best.

Taking up meson is out of my capacity. It also isn't supported by any other dependency here. Also I'm not here to start yet another flame war, this time about build systems.

What's a flame war here? You said that cmake is better than autotools because you cannot get autotools to work -- I agree that autotools can be very hard to get working, in particular on Windows. I then said that meson is also better than autotools, because meson also supports Windows officially.
Is it a flame war to say that executing the CLI interface of a build system doesn't require you to be an expert in that build system, thus you shouldn't be too worried about "maintaining" it?
Please. Give it a try. Just try running it the simplest way you can, and report your success or failure here. By good fortune, it turns out that I'm both the maintainer of the libpsl meson.build, and a developer of meson itself. You have privileged access to a lot of good advice, should you need it.
You don't have to feel that your lack of status as an expert meson maintainer (?) is a blocker for depending on a bit of software that has a meson build system.

@rockdaboot: Local build worked, the database is embedded now, lib size small, even with PSL included. Thanks for these!
Issues remaining:

_WIN32_WINNT warning and unwanted override.
version saying libpsl/0.21.5 (no IDNA support). This seems unnecessarily scary for this build configuration, which doesn't need IDNA support?:

curl 8.5.0 (x86_64-w64-mingw32) libcurl/8.5.0 LibreSSL/3.8.2 (Schannel) zlib/1.3 brotli/1.1.0 zstd/1.5.5 WinIDN libpsl/0.21.5 (no IDNA support) libssh2/1.11.0 nghttp2/1.58.0 ngtcp2/1.1.0 nghttp3/1.1.0
Release-Date: 2023-12-06
Protocols: dict file ftp ftps gopher gophers http https imap imaps ldap ldaps mqtt pop3 pop3s rtsp scp sftp smb smbs smtp smtps telnet tftp ws wss
Features: alt-svc AsynchDNS brotli HSTS HTTP2 HTTP3 HTTPS-proxy IDN IPv6 Kerberos Largefile libz MultiSSL NTLM PSL SPNEGO SSL SSPI threadsafe UnixSockets zstd

Ref: https://github.com/curl/curl-for-win/actions/runs/7519929523/job/20469031399#step:3:7204

autotools broken in half of the jobs, including Windows-llvm, used for the official binaries: https://github.com/curl/curl-for-win/actions/runs/7519929523

I've merged the version bump and related updates, also dropping libunistring and libiconv. PSL can now be enabled with the -psl config option.

@vszakats Congrats, that is cool :)

(no IDNA support). This seems unnecessarily scary for this build configuration.

I think this isn't scary, just a hint that the application needs to do IDNA stuff on its own.
From the libpsl standpoint, there should be a hint. Feel free to suggest a wording that is more on point.

Regarding the failed builds: I don't an autotools issue here. It is more likely that the setup is wrong, e.g. missing cross-compiler and/or the output can't be executed on the host and thus you get
configure: error: C compiler cannot create executables
See `config.log' for more details

Take a look into config.log.
I am not a cross-compilation expert and won't be much of a help here.

@eli-schwartz: Thanks!
I have given meson a try with libssh2 and it didn't work on a bare macOS build case,
but this might have been entirely my fault. Otherwise meson gave a good impression.
[Though given I choice I'd prefer a tool that does the whole build without calling out
to another build tool such as gnu make, ninja or nmake. (I've wrote one such called
hbmk2, but it's unknown outside of its specific dev env.)]
What I meant by "maintaining", isn't about meson itself, but maintaining curl-for-win
scripts to work with meson. curl-for-win grew fairly complex, esp since extending it
to non-Windows platforms. These need to be made work with meson and then each
global update applied to now not two (plus some one-off ones, like OpenSSL/zlib/trurl)
but three build systems. Each tooling dependency adds up to the necessary effort.
It's certainly possible to do, and would no doubt be interesting, but out of my
personal capacity, and for a single dependency it's hard to justify the effort. Maybe
dropping autotools support would allow room for something better, but some
projects support nothing but autotools (e.g. libidn2/wolfssh.)
That's to say, I have no issues at all with meson in particular and wish the popular
build tools worked much saner than they do.
[ It'd help if meson could pick up a source list from Makefile.inc or alike to avoid
having to maintain duplicate lists of them. I remember this was something I spent
some time on last year, and the closest was wildcard file spec, but that's also
problematic so not supported. ]

version saying libpsl/0.21.5 (no IDNA support). This seems unnecessarily scary

I think we should probably consider dropping everything from the libpsl version string after the version number anyway since that extra components are mostly misleading to curl users as they are not used.

Take a look into config.log.

I've spent many days looking at those logs :( It more or less comes down to libtool knowing better and filtering the options passed to the linker and then trying to trick it to accept things we need. Then find tricks that work universally, or figure out each individual build case-by-case. I gave up.

I think this isn't scary, just a hint that the application needs to do IDNA stuff on its own.
From the libpsl standpoint, there should be a hint. Feel free to suggest a wording that is more on point.

Is there any loss of functionality or caveat due to building libpsl the way we do in this particular case (embedded punycode list, supposedly never reaching out to the disk for a copy)? If libpsl works as expected and doesn't need IDNA, I believe the version message is unnecessary. If IDNA could still be needed but missing, I'd prefer a build option to opt-out from those features to have a non-IDNA-dependent libpsl.

[ It'd help if meson could pick up a source list from Makefile.inc or alike to avoid
having to maintain duplicate lists of them. I remember this was something I spent
some time on last year, and the closest was wildcard file spec, but that's also
problematic so not supported. ]

The best way to do this would be to have a sources.list newline delimited file, and read it into a meson array with
fs_mod = import('fs')
file_contents = fs_mod.read('sources.list')
sources_arr = file_contents.split()

# or one-line
sources_arr = import('fs').read('sources.list').split()

This is roughly equal to cmake's file(READ ...) modulo splitting the contents into a cmake list, which I think requires both regex and converting separators into ;. Also Make's $(shell cat ...) which, um, inherently splits.

I've spent many days looking at those logs :( It more or less comes down to libtool knowing better and filtering the options passed to the linker and then trying to trick it to accept things we need. Then find tricks that work universally, or figure out each individual build case-by-case. I gave up.

I feel your pain. :(
My understanding is it essentially whitelists the "allowed" flags, and there aren't many good options other than carefully applying a series of patches to the libtool file itself, making it agree to pass through additional flags unmodified. See e.g. https://gitweb.gentoo.org/proj/elt-patches.git/tree/patches

@eli-schwartz Thanks for your suggestion for the filelist problem, I made a note of it! (Probably a next excercise would be figuring out how to read that up in autotools, but that I'd leave that for another day :)

https://github.com/rockdaboot/libpsl/blob/ba4c49a205408845834b1648ad23c15ee09f722b/include/libpsl.h.in#L48-L58
The autotools build setup checks if -fvisibility=hidden is a valid compiler flag for this source code:
https://github.com/rockdaboot/libpsl/blob/ba4c49a205408845834b1648ad23c15ee09f722b/m4/visibility.m4#L55-L70
I wonder why neither the MSVC fallback nor the visibility attribute are detected.

HAVE_VISIBILITY=1 got detected in my local Windows autotools cross-build sample build. Then this enables the "default" visibility attribute in source, which then ignores the -fvisibility=hidden passed explicitly from the command-line. (It's head spinning!)

Oh, I see the confusion.
The -fvisibility flag sets the default for unadorned symbols.
The "visibility" inline attribute adorns symbols explicitly, and in this context, "default" is a manual pointer back to the behavior which would occur if neither -fvisibility nor the "visibility" inline attribute was used, namely, external linkage. With some caveats regarding whole program usage.
...
In general, it's expected behavior for libraries to provide their public API via external linkage.
It's actually necessary in cases such as building a "fat library" for platforms where you're only allowed a single shared library, or the cost of loading many libraries is prohibitively expensive -- so instead you create a single library that exports the ABI of an entire sdk. I'm told this is important for the apple appstore, for example.
Using -Wl,--exclude-libs,ALL when linking a library can tell binutils ld, when it needs to include a *.o file from a static library to resolve a symbol, to hide all symbols from that object file (specifically, all symbols that came from a static library).
 It's useful to have this as a build option or leave it customizable. Speaking of libcurl shared lib, we expose the libcurl API only, while statically linking all dependencies. This needs a variety of tweaks when building them. One special hurdle is assembly code because it doesn't obey -fvisibility=hidden.
All in all a linker option to select the exported function names with a mask/wildcard could make things easy in many cases.

Well, using --exclude-libs gets you granularity at the project (*.a) level, which I think gets you most of the way there. Could be useful regardless of any other factors.

--exclude-libs is getting there (thanks for the tip! I didn't know about this option), but setting a second copy or the liblist in a slightly different/specific format seems to make things complicated. Also, Apple ld is missing this option. BTW autotools' libtool has -export-symbols-regex regex, which would be perfect, but it's autotools only.


PHP rake pear fails on OSX

Getting an error when running rake pear:package version=1.0 from http://www.grpc.io/docs/quickstart/php.html.
On OSX 10.11.4. There is no version of ruby specified in the quick start page, could this be the issue?
> rake pear:package version=1.0 --trace
** Invoke pear:package (first_time)
** Invoke doc:build (first_time)
** Execute doc:build
ronn -w -s toc -r5 --markdown man/*.ronn
     roff: man/protobuf-php.3
     html: man/protobuf-php.3.html                           +man,toc
 markdown: man/protobuf-php.3.markdown
     roff: man/protobuf-php.5
     html: man/protobuf-php.5.html                           +man,toc
 markdown: man/protobuf-php.5.markdown
     roff: man/protoc-gen-php.1
     html: man/protoc-gen-php.1.html                         +man,toc
 markdown: man/protoc-gen-php.1.markdown
** Invoke pear:xml (first_time)
** Invoke pear:clean (first_time)
** Execute pear:clean
Cleaning up...
rm -f library/package.xml
rm -f library/README.md
rm -f library/LICENSE
rm -f library/protoc-gen-php.php
rm -f library/protoc-gen-php.bat
** Execute pear:xml
** Execute pear:package
cp README.md library/README.md
cp LICENSE library/LICENSE
cp protoc-gen-php.php library/protoc-gen-php.php
cp protoc-gen-php.bat library/protoc-gen-php.bat
pear package -n library/package.xml
Rolling back...
** Execute pear:clean
Cleaning up...
rm -f library/package.xml
rm -f library/README.md
rm -f library/LICENSE
rm -f library/protoc-gen-php.php
rm -f library/protoc-gen-php.bat
rake aborted!
Command failed with status (127): [pear package -n library/package.xml...]
/usr/local/lib/ruby/gems/2.3.0/gems/rake-11.3.0/lib/rake/file_utils.rb:69:in `block in create_shell_runner'
/usr/local/lib/ruby/gems/2.3.0/gems/rake-11.3.0/lib/rake/file_utils.rb:59:in `sh'
/usr/local/lib/ruby/gems/2.3.0/gems/rake-11.3.0/lib/rake/file_utils_ext.rb:37:in `sh'
/Users/trent/Protobuf-PHP/Rakefile:48:in `block (2 levels) in <top (required)>'
/usr/local/lib/ruby/gems/2.3.0/gems/rake-11.3.0/lib/rake/task.rb:248:in `block in execute'
/usr/local/lib/ruby/gems/2.3.0/gems/rake-11.3.0/lib/rake/task.rb:243:in `each'
/usr/local/lib/ruby/gems/2.3.0/gems/rake-11.3.0/lib/rake/task.rb:243:in `execute'
/usr/local/lib/ruby/gems/2.3.0/gems/rake-11.3.0/lib/rake/task.rb:187:in `block in invoke_with_call_chain'
/usr/local/Cellar/ruby/2.3.1/lib/ruby/2.3.0/monitor.rb:214:in `mon_synchronize'
/usr/local/lib/ruby/gems/2.3.0/gems/rake-11.3.0/lib/rake/task.rb:180:in `invoke_with_call_chain'
/usr/local/lib/ruby/gems/2.3.0/gems/rake-11.3.0/lib/rake/task.rb:173:in `invoke'
/usr/local/lib/ruby/gems/2.3.0/gems/rake-11.3.0/lib/rake/application.rb:152:in `invoke_task'
/usr/local/lib/ruby/gems/2.3.0/gems/rake-11.3.0/lib/rake/application.rb:108:in `block (2 levels) in top_level'
/usr/local/lib/ruby/gems/2.3.0/gems/rake-11.3.0/lib/rake/application.rb:108:in `each'
/usr/local/lib/ruby/gems/2.3.0/gems/rake-11.3.0/lib/rake/application.rb:108:in `block in top_level'
/usr/local/lib/ruby/gems/2.3.0/gems/rake-11.3.0/lib/rake/application.rb:117:in `run_with_threads'
/usr/local/lib/ruby/gems/2.3.0/gems/rake-11.3.0/lib/rake/application.rb:102:in `top_level'
/usr/local/lib/ruby/gems/2.3.0/gems/rake-11.3.0/lib/rake/application.rb:80:in `block in run'
/usr/local/lib/ruby/gems/2.3.0/gems/rake-11.3.0/lib/rake/application.rb:178:in `standard_exception_handling'
/usr/local/lib/ruby/gems/2.3.0/gems/rake-11.3.0/lib/rake/application.rb:77:in `run'
/usr/local/lib/ruby/gems/2.3.0/gems/rake-11.3.0/exe/rake:27:in `<top (required)>'
/usr/local/bin/rake:23:in `load'
/usr/local/bin/rake:23:in `<main>'
Tasks: TOP => pear:package

Do you have pear installed? Run pear version? If not, you may want to try
$ curl -O http://pear.php.net/go-pear.phar
$ sudo php -d detect_unicode=0 go-pear.phar

Ah, I installed it but it didn't get put in the path.
What part of that log gave away that pear wasn't found?

Command failed with status (127): [pear package -n library/package.xml...]


GPG signatures for source validation

As we all know, today more than ever before, it is crucial to be able to trust
our computing environments. One of the main difficulties that package
maintainers of Linux distributions face, is the difficulty to verify the
authenticity and the integrity of the source code.
The Arch Linux team would appreciate it if you would provide us GPG signatures
in order to verify easily and quickly your source code releases.
Overview of the required tasks:

Create and/or use a 4096-bit RSA keypair for the file signing.
Keep your key secret, use a strong unique passphrase for the key.
Upload the public key to a key server and publish the full fingerprint.
Sign every new git commit and tag.
Create signed compressed (xz --best) release archives
Upload a strong message digest (sha512) of the archive
Configure https for your download server

GPGit is meant to bring GPG to the masses.
It is not only a shell script that automates the process of creating new signed
git releases with GPG but also comes with this step-by-step readme guide for
learning how to use GPG.
Additional Information:

https://github.com/NicoHood/gpgit
https://help.github.com/categories/gpg/
https://wiki.archlinux.org/index.php/GnuPG
https://git-scm.com/book/en/v2/Git-Tools-Signing-Your-Work
https://www.qubes-os.org/doc/verifying-signatures/
https://lkml.org/lkml/2016/8/15/445
https://developers.google.com/web/fundamentals/security/encrypt-in-transit/why-https
https://www.enigmail.net/index.php/en/

Thanks in advance.

I suppose it's a good idea, I've been an avid GPG user in the past (https://pgp.mit.edu/pks/lookup?op=vindex&search=0xDB95009289C3EB3C) but I've stopped using it since I appeared to be one of the few that actually did...
For Git releases however it's definitely a good idea. I'll incorporate it in my git-flow-avh release process to auto-sign all releases in the future :)

@WoLpH Thanks! You definitely need to generate a new GPG key though. You are using DSA1024 which is considered (very) insecure nowadays. I suggest an RSA4096 key.

Yep... it's not safe by any standard anymore. I still have it though, so I can still sign the new key although I don't think anyone cares about that ;)
It was perfectly acceptable when I started using it though... how time flies. Somehow Git on my OS X machine doesn't want to sign yet so I'm still debugging a bit...
gpg: signing failed: Inappropriate ioctl for device
gpg: signing failed: Inappropriate ioctl for device
error: gpg failed to sign the data
error: unable to sign the tag

Apparently it was related to a few gpg versions colliding, it's fixed now and I've pushed a new release with a signed tag :)
Thanks for all the info!
We have a verified tag now: https://github.com/WoLpH/python-progressbar/tags

Thanks. Would you please also publish a signed source tarball? This is a) simpler to package and b) more secure than signed git tags, as you can trick those too.
You should put the new full GPG fingerprint (40chars) somewhere on the project site if possible. (do gpg -k <yourmail or name or short key>

Oops... you're right, I forgot to sign the Pypi release well.
I've created a new signed release on pypi: https://pypi.python.org/pypi/progressbar2

Perfect! will try that out.

The website of this github repository can be set as https:
https://progressbar-2.readthedocs.io/en/latest/

Changed as well, and I've added a link to my gpg key in the readme

Thanks!
I assume you also say this one:
https://github.com/WoLpH/python-utils/issues/3
I am preparing everything to move to your version. It would be really important for the users who upgrade the dependency what is compatible and what not. :)

Yep, working on that one :)

Thanks for the fast fixes. Its all working fine.
Just let me know what I should tell the users before upgrading the package :)

I always add a commit message roughly detailing what changed in the release (part of the tags) but generally no backwards incompatible changes should occur.
The last backwards incompatible change was the version v3.7.x last year which dropped Python 2.6 support. Beyond that only features are added and bugs are (hopefully) fixed :)
The latest release made sure stacktraces are still visible when output capturing is enabled and it added a "wall time" widget.
For a full list of releases with the changes: https://github.com/WoLpH/python-progressbar/releases
Or commandline:
# git tag -n

v2.3            Added nicer defaults
v2.6.1          v2.6.1
v2.6.2          v2.6.2 adaptive eta added
v3.0.1          Added Python 3.x support and thanks @tnestmeyer for adding AbsoluteETA widget
v3.1.0          Added full python 3.5 support
v3.10.0         Fixed output redirection with special ipython and jupyter notebook support
v3.10.1         Fixed resizing with nested progressbars
v3.12.0         Improved support for sequences with unknown length thanks to @WohthaN
v3.15.0         Large performance improvements. Dropped Pypy3 support in Travis tests. Improved output redirection (fixed several bugs). Showing N/A when no numbers are available. v3.15.0
v3.15.1         Made sure even really fast progressbars finish. Fixes #102 v3.15.1
v3.16.0         converted all strings to unicode v3.16.0
v3.16.1         preferring fixed size over incorrect size detection for jupyter v3.16.1
v3.17.0         Converted all strings to unicode
v3.17.1         fixed unicode issues on python 3 (fixes #104, fixes #105, #fixes 106) v3.17.1
v3.18.0         fixed 100% progressbar, relocated tests and improved several tests. fixes #108 v3.18.0
v3.18.1         Re-applied the Jupyter Notebook fixes by Matthew Wardrop v3.18.1
v3.2.0          New version packaged using cookiecutter template: https://github.com/WoLpH/cookiecutter-pypackage-pythonic
v3.20.0         Added global stdout/stderr redirection support so we can function with loggers as well. Fixes #101 v3.20.0
v3.20.1         Reaplying @matthewwardrop his pull request #103 v3.20.1
v3.20.2         removed print statement to fix #116 v3.20.2
v3.3.0          Fixes for UnknownLength handling
v3.3.1          Fixed silly inheritance bug with super()
v3.3.2          Set default start value to min_value
v3.3.3          fixed widgets to be fixed width
v3.30.0         Fixed several bugs thanks to @matthewwardrop and refactored requirements
v3.30.2         fixed bug #121 and #122 v3.30.2
v3.31.0         fixed stacktrace output when capturing output and implemented wall time widget v3.31.0
v3.31.1         bumping version to enable release signing v3.31.1
v3.32.0         fixed python 3.x tests and updated readme v3.32.0
v3.4.0          fixed docs and print order for output redirection v3.4.0
v3.4.1          fixed terminal size detection bugs v3.4.1
v3.4.2          Fixed auto width
v3.4.3          Removed debug statement
v3.5.0          Added size-dependent widgets
v3.5.1          removed debug code, the exception shouldnt raise v3.5.1
v3.5.2          Fixed documentation for resizing and made the progressbar a little faster in case of many updates. Thanks to @max-arnold for the patches!'
v3.6.0          Fixed progressbar on Windows consoles
v3.6.1          fixed jupyter notebook, last update and negative ETA bugs thanks to @zzzsochi v3.6.1
v3.7.0          added more widgets, dropped python 2.6 support and improved testing
v3.8.0          modernized the package and improved python 3 support
v3.8.1          Fixed strange git undo
v3.9.0          Finished ETA widgets
v3.9.1          improved test coverage v3.9.1
v3.9.3          Bumped version for pypi
v3.9.4          Fixed Linux integer overflow bug with ETA

Thanks. This sounds good. We dont support python 2.6 anyways, so it all should work fine.
https://www.archlinux.org/packages/community/any/python-utils/
https://www.archlinux.org/packages/community-testing/any/python-progressbar/

Awesome! Thanks for the great work :)


Adding simonsen.txt

Adding Simonsen.txt as an instituition
You can find some information about the institution on Wikipedia
Here is its specific course page: http://www.simonsen.br/2.0/TADS
P.S.: Links in pt_br

@hjemmel Pull request merged. Thank you!


ambient: fix auto-allow waypoint

Probably we need to increase our test coverage here

@howardjohn: The following test failed, say /retest to rerun all failed tests or /retest-required to rerun all mandatory failed tests:

Test name
Commit
Details
Required
Rerun command

unit-tests-arm64_istio
1f54bd2132fe7742680b370fbb7dbfc678302e14
link
true
/test unit-tests-arm64

Instructions for interacting with me using PR comments are available here.  If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. I understand the commands that are listed here.

@howardjohn: The following test failed, say /retest to rerun all failed tests or /retest-required to rerun all mandatory failed tests:

Test name
Commit
Details
Required
Rerun command

integ-ambient_istio
815149b1ed621f82c6819236e34f1f5c0b3ca1fa
link
true
/test integ-ambient

Instructions for interacting with me using PR comments are available here.  If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. I understand the commands that are listed here.


Falling back for slices of struct (decoder)

Code generated from below structs fall back to the built-in json decoder. Do you have plan to support that in short term?
Thank you very much!
test.go
package main
func main() {
}
type test_struct struct {
        I int
        S []test_sub_struct
}
type test_sub_struct struct {
        I int
}

================
test_ffjson.go
        /* handler: uj.S type=[]main.test_sub_struct kind=slice */

        {
               /* Falling back. type=[]main.test_sub_struct kind=slice */
                tbuf, err := fs.CaptureField(tok)
                if err != nil {
                        return fs.WrapErr(err)
                }

                err = json.Unmarshal(tbuf, &uj.S)
                if err != nil {
                        return fs.WrapErr(err)
                }
        }

@klauspost , can you give me some suggestion here? Shall I modify my struct definition?

I don't know much about the decoder, maybe @pquerna has a suggestion.

PR #128 should fix this when landed.

#128 is now merged.


Extended filtering

Possible filter types:

.../BangleApps/#blue shows apps having "blue" in app.id or app.tag --> searchType:hash (as before these changes)
.../BangleApps/#bluetooth shows apps having "bluetooth" in app.id or app.tag (also selects bluetooth chip) --> searchType:chip (as before these changes)
.../BangleApps/id=antonclk shows app having app.id == antonclk --> searchType:id
.../BangleApps/q=clock shows apps having "clock" in app.id or app.description --> searchType:full

Typing in the search field on the web interface does full search now (and the URL is changed according to the input value).
Fixes https://github.com/espruino/BangleApps/issues/1215
Note: there is no change in the sorting as suggested in comment https://github.com/espruino/BangleApps/issues/1215#issuecomment-1039131902 done.
@gfwilliams  even though i tested this i would like you to have a second look on this before merging :) Thanks!

Looks good to me! Not sure if you have any idea but it seems like some kind of small 'copy link' button might be neat on apps so that it's obvious how to share them.
On the forum I find I often want to say 'look at the readme for X' - so I wonder if there's a way to do that...

Not sure if you have any idea but it seems like some kind of small 'copy link' button might be neat on apps so that it's obvious how to share them.

I will have a look at this - should not be that hard.

Thanks - that'd be great!


Migrate to orb-tools v11. Add orb-tools config files

This PR is to migrate circleci-tools to use orb-tools v11.0:
https://github.com/CircleCI-Public/orb-tools-orb
I followed this guide:
https://github.com/CircleCI-Public/orb-tools-orb/blob/master/MIGRATION.md

I took a look into it and I think the error you are receiving appears to be accurate. From what I can tell, there is no namespace registered to GEOS-ESM
And Today I Learned, I just went to the orb registry to check it out and noticed that it does exist, but it is all lowercase, and this actually matters. I ran a query again as geos-esm and found you. Try again, but with all lowercase.

I took a look into it and I think the error you are receiving appears to be accurate. From what I can tell, there is no namespace registered to GEOS-ESM
And Today I Learned, I just went to the orb registry to check it out and noticed that it does exist, but it is all lowercase, and this actually matters. I ran a query again as geos-esm and found you. Try again, but with all lowercase.

Well I feel a bit dumb. I imagine I used GEOS-ESM when running the migrate script because, well, that's my org, but I didn't realize that it looks like every orb in the registry has a lowercase org?
I've pushed and we shall see!

And I did screw up the GITHUB_TOKEN it seems, but there was a nice error message for that one...

Your development orb has been published. It will expire in 30 days.
You can preview what this will look like on the CircleCI Orb Registry at the following link:
https://circleci.com/developer/orbs/orb/geos-esm/circleci-tools?version=dev:f6259dbed59725b3ad9920c6b83f5ac5358e1e8d

Your development orb has been published. It will expire in 30 days.
You can preview what this will look like on the CircleCI Orb Registry at the following link:
https://circleci.com/developer/orbs/orb/geos-esm/circleci-tools?version=dev:14e3a28dc13461071d6eb7c78b0839fbe567c558

Your development orb has been published. It will expire in 30 days.
You can preview what this will look like on the CircleCI Orb Registry at the following link:
https://circleci.com/developer/orbs/orb/geos-esm/circleci-tools?version=dev:1e04d2ef70a595b610a36f04cca707b5dafcd44a

@mathomp4 The last step before that if applicable is to implement any tests for your orb you may have.
https://github.com/GEOS-ESM/circleci-tools/blob/1e04d2ef70a595b610a36f04cca707b5dafcd44a/.circleci/test-deploy.yml#L10
https://circleci.com/docs/testing-orbs#integration-testing

I also have a video on the release process here but yes you are correct!
https://circleci.com/docs/creating-orbs#issue-a-new-release-with-the-orb-development-kit

@mathomp4 The last step before that if applicable is to implement any tests for your orb you may have.
https://github.com/GEOS-ESM/circleci-tools/blob/1e04d2ef70a595b610a36f04cca707b5dafcd44a/.circleci/test-deploy.yml#L10
https://circleci.com/docs/testing-orbs#integration-testing

Yeah...let's just say I've been a bad dev and haven't really done that yet. At the moment I think it's just doing a checkout.
That said, I'm not really sure what kind of tests I can do. I mean, this orb is used to direct like 20 minute long CI tests. Still, I'll ponder it! 😄

Your development orb has been published. It will expire in 30 days.
You can preview what this will look like on the CircleCI Orb Registry at the following link:
https://circleci.com/developer/orbs/orb/geos-esm/circleci-tools?version=dev:f2486e64f96d8f7de7bb48bf08f6eced6aaf6f72

Your development orb has been published. It will expire in 30 days.
You can preview what this will look like on the CircleCI Orb Registry at the following link:
https://circleci.com/developer/orbs/orb/geos-esm/circleci-tools?version=dev:f2486e64f96d8f7de7bb48bf08f6eced6aaf6f72

Your orb has been published to the CircleCI Orb Registry.
You can view your published orb on the CircleCI Orb Registry at the following link:
https://circleci.com/developer/orbs/orb/geos-esm/circleci-tools?version=1.10.0


Update verification.py

The old code doesn't work.

This PR is closed because I deleted the forked repo. This issue needs to be fixed.

And the string needs to be str.


RUM-886 Provide session replay data in configuration telemetry

What does this PR do?
In this PR we are adding the information for the Session Replay feature configuration in our related Telemetry event.
Motivation
What inspired you to submit this pull request?
Additional Notes
Anything else we should know when reviewing?
Review checklist (to be filled by reviewers)

[ ] Feature or bugfix MUST have appropriate tests (unit, integration, e2e)
[ ] Make sure you discussed the feature or bugfix with the maintaining team in an Issue
[ ] Make sure each commit and the PR mention the Issue number (cf the CONTRIBUTING doc)

Codecov Report

Merging #1611 (c0a7f5a) into develop (d8b3962) will increase coverage by 0.05%.
The diff coverage is 93.33%.

@@             Coverage Diff             @@
##           develop    #1611      +/-   ##
===========================================
+ Coverage    83.63%   83.68%   +0.05%
===========================================
  Files          451      451
  Lines        15567    15557      -10
  Branches      2318     2317       -1
===========================================
  Hits         13018    13018
+ Misses        1930     1915      -15
- Partials       619      624       +5

Files Changed
Coverage Δ

...oid/sessionreplay/internal/SessionReplayFeature.kt
99.02% <80.00%> (-0.98%)
:arrow_down:

...ndroid/telemetry/internal/TelemetryEventHandler.kt
78.18% <100.00%> (-0.66%)
:arrow_down:

... and 26 files with indirect coverage changes


NL feedback client side support

Nice! Do you have a screenshot?

Added one. It looks a bit funny though..


November 2100 default in android 4

Hello
In android 4 the time sets to November 2100 not for the current time

👋 @DevYousef could you please follow the issue template for this? Thanks!


Update lambda permission for private link

Description
When deploying the integration with private like the lambda needs permission to ec2:CreateNetworkInterface, ec2:DescribeNetworkInterfaces, ec2:DeleteNetworkInterface so i have added these permissions for when you use a private link
Also because the lambda will be defined in VPC so in case the user will also store the ApiKey in secret the module will need to create an endpoint in the VPC to allow the lambda to access the secret.

 Fixes #
How Has This Been Tested?

Checklist:

[ ] I have updated the relevant example in the examples directory for the module.
[ ] I have updated the relevant test file for the module.
[ ] This change does not affect module (e.g. it's readme file change)

@guyrenny did u test the list(any) change for msk?

@guyrenny did u test the list(any) change for msk? and the depends_on = [module.lambda] change?

yes i have tested it and it worked


fix: rich editor improvements

fix: rich editor improvements

Obligatory GIF (super important!)

:hammer_and_wrench: Type Of Change

These types will increment the version number on release:

[x] Fix
[ ] Feature
[ ] Performance Improvement
[ ] Refactor

These types will not increment the version number, but will still deploy to documentation site on release:

[ ] Documentation
[ ] Build system
[ ] CI
[ ] Style (code style changes, not css changes)
[ ] Test
[ ] Other (chore)

:book: Jira Ticket
https://dialpad.atlassian.net/browse/DLT-1523
:book: Description
Some visual improvements in the component/recipe.
Space:

[x] Horizontal and vertical padding 8px: var(--dt-space-400)
[x] Gap button-groups 12px: d-stack--gap-450 (also added this space/gap to the stack component)
[x] Gap between buttons 4px: d-stack--gap-300

Dividers:

[x] Update from using the d-divide-x d-divide-black-200 because this takes the last:child, we can add something else that represents these dividers between button groups; here is a proposal style.

height: calc(var(--dt-size-550) + var(--dt-size-300));
width: var(--dt-size-100);
background: var(--dt-color-border-subtle);

Buttons:

[x] All button should be: size="xs"
[x] Codeblock button icon needs to be update with code-block

:bulb: Context

:pencil: Checklist

For all PRs:

[x] I have ensured no private Dialpad links or info are in the code or pull request description (Dialtone is a public repo!).
[x] I have reviewed my changes.
[x] I have added all relevant documentation.
[x] I have considered the performance impact of my change.

For all CSS changes:

[x] I have used design tokens whenever possible.
[x] I have considered how this change will behave on different screen sizes.
[x] I have visually validated my change in light and dark mode.
[x] I have used gap or flexbox properties for layout instead of margin whenever possible.

:crystal_ball: Next Steps

https://dialpad.atlassian.net/browse/DLT-1530

Looks great! remember to update vue 3 component as well

Fixed the vue 3 component in the latest commit! :)


Cap throwing scaling

:cl:

fix: Cap throwing scaling so bad mass values don't yeet you too far.

Fixes #16401 probably.

Fixes https://github.com/space-wizards/space-station-14/issues/16782 probably.


Custom Marker: Not able to add image for 'Custom Marker'

Hello,
I am trying to add custom marker which contains image as well

OS type and version : Mac OS, iOS device.
Library version and other environment information: "@googlemaps/react-native-navigation-sdk": "^0.9.1",

Here is the code I tried,
const addMarker = async (imgPath?: string) => {
        if (mapViewController) {
            const cameraPosition = await mapViewController.getCameraPosition();

            const marker: Marker = await mapViewController.addMarker({
                position: cameraPosition.target,
                visible: true,
                title: 'Custom Marker',
                snippet: 'This is a marker with custom image and text',
                alpha: 1.0,
                rotation: 0,
                flat: false,
                draggable: true,
                imgPath: imgPath,
            });
        }
    };

    const addCustomMarker = async () => {
       // let imagePath = Image.resolveAssetSource(require('assets/map-icons/map-position-icon.png')).uri;
        // let imagePath = './assets/map-icons/map-position-icon.png';
        const imagePath = require('assets/map-icons/map-position-icon.png');
        await addMarker(imagePath);
    };

I don't no, why my custom image is not showing as marker, it is showing default marker icon only.
What is the correct way to show image as marker?

Resolved the issue.
In this case i.e for imgPath, images should added in native Android/iOS folder's assets path.
By doing this change, issue got resolved.


About turning the images flat from fisheye lenses

Anoosheh, sorry to disturb you again. How can I turn the images flat from fisheye lenses? In addition, the image looks like a grayscale image. How do we turn them into color images? Can you provide the corresponding python code to turn the images flat from fisheye lenses? Thanks in advance.

The Oxford dataset site provides that. I am not involved with the creation of that dataset, sorry.
Thanks

@AAnoosheh Thank you for your prompt reply.  In my option, the images we train should come from Bumblebee XB3 or Grasshopper2.  Using Bumblebee XB3, the trained image is as follows(figure 1)

When using Grasshopper2, the trained image is as follows(figure 2)

We want to know that you are training with images similar to Figure 1 or Figure 2.

Oh definitely from Grasshopper

@AAnoosheh  Thanks very much for your reply. As asked above, the trained images from Grasshopper seem to be grayscale images. Do they affect the training results？

I think you might be viewing them incorrectly. They look like the images on the README of this repo, in color.

@AAnoosheh  Thank you for your reply, I'll take a closer look. Thank you very much!


Suppress stdout in unittest

Close #21

Do you mean like this or did you want me to add docstrings to everything?


🚧🚧🚧 Add traefik routing for invitation services

This adds traefik routing rules and regexreplace for osparc.io/invitations/ and forwards it to the invitation service. This was tested to work on my local deployment. This should ideally move fast to prod.
🚧🚧🚧:
This deprecates https://git.speag.com/oSparc/invitations and the machines and the repo can be removed.

It is possible but this complicates the routing a bit, since prefixes (subdomains) are managed by the ops-traefik. If one uses /invitations, the routing can be fully handled on the simcore traefik. However, as I notice now (thanks for poiting me in this direction), the invitation service is then affected by the maintenance page (i.e. unavailable if the maintenance page is up). If this is not desirable (and currently there is no urgency), both issues can potentially be addressed.
let me know again if you think :)

Caught by @Surfict: Entrypoint should be https and thus needs myresolver

Todo: Add new subroute to certificates test


Status page refresh time

⚠ Please verify that this question has NOT been raised before.

[X] I checked and didn't find similar issue

🛡 Security Policy

[X] I agree to have read this project Security Policy

📝 Describe your problem
Would it be possible for me to change the status pages to update every 1 minute instead of 5 minutes?
📝 Error Message(s) or Log
No response
🐻 Uptime-Kuma Version
1.23.15
💻 Operating System and Arch
alpine
🌐 Browser
Firefox
🖥 Deployment Environment

Runtime:
Database:
Filesystem used to store the database on:
number of monitors:

@MuriloFuza, this is not possible in version 1.23.15. However, it is available in version 2.0 BETA. You can check the How to migrate from Version 1 to Version 2 for more details. Make sure to back everything up properly.
In my opinion, it's better to wait for version 2.1 BETA; I also advise against using the BETA in production.

Got it, I'll take a look and see the predictions. Thanks!


Different p values from DVARSCalc.m and DVARSCalc_octave.m

Running DVARSCalc.m and DVARSCalc_octave.m gave different p values from chi2 tests.
I have made following changes in DVARSCalc_octave.m for having identical results
Uncommenting line 296
X2p    =   @(x,m,s) 1-chi2cdf(X2stat(x,m,s),X2df(m,s));
Commenting line 296
% X2p     =   @(x,m,s) chi2cdf(X2stat(x,m,s),X2df(m,s));

Hi Bertram, thanks for catching this! This has slipped since the Octave chi2cdf() function doesn't have 'upper' option.
I just updated the code:
https://github.com/asoroosh/DVARS/blob/821b5225436af52f4712a44259492c10e641e853/Octave/DVARSCalc_octave.m#L306
Thanks again for letting us know!


No module named 'bboxes_ex_msgs'

Hi, I try to run the demo of python version and want to check the result by typing "ros2 topic echo /yolox/bounding_boxes", but it shows "No module named 'bboxes_ex_msgs". I don't know why, please have a look , thank you very much!

bbox_ex_msgs is submodule.
Please try these commands.
cd YOLOX-ROS
git submodule update --init

If you have additional comments, please open this issue again.


Unwanted dependencies are tracked which are not required

We are using python opentelemetry sdk to enable tracing and logging in for AzureML pipeline.
After configuring opentelemetry we are seeing lot of dependencies from "management.azure.com", "*.blob.core.widows.net"
These dependencies have almost filled the table.
Is there a way to disable all other dependencies and enable only dependencies which are manually added in code.
with tracer.start_as_current_spen("abc"):
     test()

Also there are some traces added from "*.blob.core.widows.net", which we dont need to track.

The distro by default uses the requests, urllib, and urllib3 instrumentations. Your code may be using these libraries to make dependency network calls. If you are using version 1.0.0b13, you can use the OTEL_PYTHON_DISABLED_INSTRUMENTATIONS to disable those instrumentations while still allowing for manually created spans. See the README for more

@anandchugh
Is your issue resolved?

Closing issue for now. Feel free to comment if issue persists.


Allow setting specific user for integration tests

@cmaloney This is Ready for Review

@cmaloney fixed and ready for another pass

🚢


[WIP] SN Ia + host galaxy example workflow

Preliminary work flow and notebook for SN Ia + host galaxy science case.

Opened a new PR


Fix loopback result

Fixes #141.

pluings -> plugins in https://github.com/steveeJ/cni/commit/539b04fd3e538da9bc4d78f628676be0983a54bd commit message

Thanks @jonboulle :-) Fixed and testcase added.

@steveeJ - this is great!
Could we actually add a test case for del though? I could totally help with this as needed.

@zachgersh sure! I added the testcase.

@steveeJ Awesome! LGTM - once the tests pass ;)


fix VTK output of TreeMesh levels (celldata)

Could you please confirm that this fixes the bug you reported, @gregorgassner?
Closes #40

Can we merge this, @sloede?

Test Summary:                   | Pass  Fail  Total
2D                              |   18     2     20
  TreeMesh                      |    9            9
  StructuredMesh                |    3     2      5
    waving flag                 |    1     1      2
    waving flag (supersampling) |    1     1      2
  UnstructuredMesh2D            |    3            3
  P4estMesh                     |    3            3

Honestly?

Could you please take care of that, @sleode? I don't know whether it's a real regression or just some artifact caused by improper testing...

Could you please take care of that, @sleode? I don't know whether it's a real regression or just some artifact caused by improper testing...

Was there a change lately in Trixi that could affect StructuredMesh results? That's the only explanation I currently have.

Was there a change lately in Trixi that could affect StructuredMesh results? That's the only explanation I currently have.

I'm not sure. It uses advection on the waving flag in 2D - that's a rather simple setup. But I enabled FMA support in StaticArrays.jl in the time period of interest. Thus, computations like contravariant_flux1 = Ja11 * flux1 + Ja12 * flux2 in the volume terms might have changed by floating point precision...

Yes, it's a horrible, horrible way we are testing this package right now. Since the update frequency here is low, essentially each time we have a new PR we need to update the file hashes since almost always "something" changes. We need something like a proper TestVTK.jl package, I think, to make automated testing more useful.
I put it on the agenda for the next meeting to come up with possible solutions.


add a filter to change markdown h4 to latex output

Thank you for the contribution. The filter is a nice example of how filters can be used to modify specific parts of the document. However, it differs from most other filters in this repo in some key aspects, which makes me hesitant to add it in the current form:

Normally, headers can be linked to via by specifying their ID. This is no longer possible for modified level 4 headers. That could lead to irritations for users who expect the scripts here to just work.
Markup in the header (like emphasis or math) is lost during conversion.

Also, while many filters here are customizable via metadata fields, none require users to alter the filter's code. We aim at making filter usable without coding.
This might be a problem where a filter is not the best tool for the task, and which is easier to solve in LaTeX by configuring the \paragraph command. Can you try adding this to your document and see if it does what you need?
---
title: 4 levels of Markdown
header-includes: |
  ``` {=latex}
  \usepackage{titlesec}
  \titlespacing*{\paragraph}{0pt}{1ex}{-\parskip}
  \titleformat{\paragraph}[hang]
      {\normalfont\bfseries}
      {}
      {0pt}
      {}

Thanks for reviewing @tarleb !
I understand if this isn't a good candidate for inclusion in the repository so can just close the PR.
I do appreciate that answer but I cannot use it because of a warning. Pandoc's default template includes KOMA script's scrartcl which emits this warning when you attempt to use titlesec:
Class scrartcl Warning: Usage of package `titlesec' together
(scrartcl)              with a KOMA-Script class is not recommended.
(scrartcl)              I'd suggest to use the package only
(scrartcl)              if you really need it, because it breaks several
(scrartcl)              KOMA-Script features, i.e., option `headings' and
(scrartcl)              the extended optional argument of the section
(scrartcl)              commands.
(scrartcl)              Nevertheless, using requested
(scrartcl)              package `titlesec' on input line 107.

I did end up writing another filter to center all images when converting to LaTeX. Any interest in that one living here?

If you are on the Tex stack exchange site and can answer, I think your suggestion is the right answer for this question:
https://stackoverflow.com/questions/21198025/pandoc-generation-of-pdf-from-markdown-not-respecting-headers-formatting

For what it's worth, this is the best filter I could come up with, which forces the start of paragraphs following 4th level headers onto a new line. It's neither pretty nor very efficient, but seems to work ok.
local insert_paragraph_brake = false

function Header(h)
  if h.level == 4 then
    insert_paragraph_brake = true
  end
end

function Block(b)
  if not insert_paragraph_brake then return end
  insert_paragraph_brake = false
  if b.t == 'Para' then
    table.insert(b.content, 1, pandoc.RawInline('latex', '\\hfill{}\\\\{}'))
    return b
  end
end

I imagine that the image centering filter, if it is simple and well documented, could make a good addition to the examples in https://pandoc.org/lua-filters.html.

If you are on the Tex stack exchange site and can answer, I think your suggestion is the right answer for this question:
https://stackoverflow.com/questions/21198025/pandoc-generation-of-pdf-from-markdown-not-respecting-headers-formatting

I added an answer.

I added another answer, describing an alternative strategy.  More hacky but with zero extra dependencies:
https://stackoverflow.com/a/57525499/1640286


Locale Question

Congratulations! This is a beautiful job. I would like to say that the translation to any language works well, just need to include the "moments" file referring to your language.
Example:
In my case:

It works fine!
However, the only part of the calendar that is not translated is the days of the week ... section that remain in English.
[Su Mo Tu We Th Fr Sa] => I need: [Do Se Te Qa Qi Sx Sa]
Do you have any idea how I can fix this? Does the section not use "moments" library to be build?
Thanks,
Palin
São Paulo/Brazil

It looks like an issue with how rome builds the calendar component.
It builds the day headers with moment's weekdaysMin, which should be ["Dom", "2ª", "3ª", "4ª", "5ª", "6ª", "Sáb"] for your locale.
When I get a chance I will step through rome's handling to see why it uses the en-gb locale instead of the loaded moment locale.

Aha: The packaged rome.js script tag from this repo's example contains a copy moment.js, which uses the default locale.
The solution is to use rome.standalone.js instead. That uses the global moment, like the rest of the datepicker. I'll update the demo page.

Thanks Joe! Perfect!!


Yolox improve with REPConv/ASFF/TOOD

Motivation

use ASFF/TOOD/REPVGG to improve YOLOX, achieve 44.5map yolox-s

Modification

Model Yolox components such as ASFF/ASFFSim/TOODS supports
Model of RepVGGBlocks backbone
Export support of reparameter and blade best practice for Yolox

Backward-Compatibility-Breaking (Optional)
Use cases (Optional)
Pull-Request Todo List

Pre-commit or other linting tools are used to fix the potential lint issues.
The modification is covered by complete unit tests. If not, please add more unit test to ensure the correctness.
The documentation has been modified accordingly, like docstring or example tutorials.

 Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you all sign our Contributor License Agreement before we can accept your contribution.3 out of 4 committers have signed the CLA.:white_check_mark: zouxinyi0625:white_check_mark: wuziheng:white_check_mark: haiasd:x: zxyzxy seems not to be a GitHub user. You need a GitHub account to be able to sign the CLA. If you have already a GitHub account, please add the email address used for this commit to your account.You have signed the CLA already but the status is still pending? Let us recheck it.

LGTM


Login is super secure

Should probably not send the password digest to the front-end...just a thought.

Fixed by e022332


Virts 494 list payloads redo

Changes:

new chain_svc function to list payloads  NOTE: we may want to move this function to file_svc down the road if we think multiple things will use it
GUI components pulled from @ArtificialErmine's https://github.com/mitre/chain/pull/186  to display the names of available payloads as a new modal

I plan to draft a follow up PR with the ability to upload payloads to caldera, but feel like it makes sense to split the functionality into multiple PRs.

rebased off master to resolve conflicts

there's nothing functionally wrong with this PR (it would only require a rebase to remove the abilities section, which we did last week). but I can't see the value-add from the GUI perspective.
you can't create abilities from the UI, only view them (through the adversary-building modal). if we allowed you to create an ability- then it would make sense to upload a payload to go along with it...
I think there's some value in this PR though, I'm just trying to see how it could be tweaked to do so. I don't think having a modal window for payloads can be justified-- but having the list available elsewhere could be good... a few areas this may be good:

in the ability modal (when building an adversary) there could be a filter to see all payload abilities
We could add a stockpile GUI page which allows you to add and view payloads
other?

@privateducky this PR is just to view them, but not modify the payloads, like abilities, adversaries, and facts loaded payloads could be viewed centrally.

@wbooth I see that-- but I'm struggling to see the value-add. there's nothing actionable you can do, with this being a "top-level" modal. all other modals help you make decisions or allow you to change/modify stuff. off-hand, I think this would be better suited to move into the abilities "pop-up" modal via the adversaries section.

closing merged into core


Add engines to package.json

Require node >= 12.
I could try to require node >= 10.10, but then we run into this issue and it seems too much trouble.
This also means having to update the minimum node version in dtslint, types-publisher and DT.

I believe @domoritz had some reason to support node 10 in dtslint, although I didn't ask at the time because I wasn't aware of any reason that node 12 was required.
The issue you linked appears to do with the types (although I might have misread it). Is it possible just to update the types and leave the engine version alone?
@domoritz did you have a specific reason that dtslint needed to support node 10?

Yes, I am working on https://github.com/vega/vega and we use this package to test our typings. Since Node 10 is not deprecated (https://nodejs.org/en/about/releases/), we need to support it.
It would probably make sense to test node 10 in https://github.com/microsoft/dtslint/blob/master/.travis.yml to make sure that the minimum node version is actually supported.

I installed<EMAIL_ADDRESS>and got dts-critic to compile on its own, at least. Was the compilation error in conjunction with dtslint?

Is this a question for @gabritto?

@domoritz do you need to support all Node 10 versions (e.g. 10.0.0)? Or is Node >= 10.17.0 enough?

I think the latest node 10 version is enough. We use Travis so I’d like to support the version they use.

I think you can also use node typings for node 12 and still support node 10 (and test it on the CI). At least it has worked well for us in Vega: https://github.com/vega/vega/blob/master/package.json.


Add withServerParams() API to Slim PSR-7 request objects.

This was missing from the latest release, although I expected it to exist. I mostly need it for unit tests, but I also wrote an IP address anonymizer that might work well with Slim's PSR-7 library.

Coverage increased (+0.001%) to 99.734% when pulling c34f5f90ca4f12f058461cf3329c8a27ef233c5a on soatok:master into 573678c2e7259b1d0aabcefb05cee5f4b1cadce0 on slimphp:master.

@adriansuter this isn't part of the spec. It's just a helper function. I'm not opposed to adding it, it does seem like more of a usage specific helper though.
@soatok why do you need to mutate the server params though? During a request's life, it should technically be instantiated with the correct server params from the get go no? Can you please enlighten us as to why that's necessary?

I described this in my first comment.
See also: https://github.com/soatok/faq-off/blob/2170ddc184974b5848ab46bd0e4d6a57aea0a1b3/src/FaqOff/Endpoints/Entry.php#L120-L127
This creates a mutated copy of $_SERVER (but wrapped in the PSR-7 object) that uses my anonymizer to store IP addresses, user agents, etc. that have been processed by a RPF with a key that is rotated every 24 hours to maximize end user anonymity.
This could be easily implemented at a framework level if I wanted to just make an anomymizer middleware by allowing mutation. My current implementation forces me to just rebuild a new Request object instead of a cloned mutant.

@l0gicgate Shouldn't that go to https://github.com/slimphp/Slim-Http?

@adriansuter the thing is I'm not sure it belongs on either repository, I'm uneasy with modifying server params after request object has been instantiated. I understand that for this particular use case it makes things easier, but what other use cases is that for and are we opening something up that we shouldn't.

The current usage is consistent with the other get*() methods that exist with Request.
Its absence is noteworthy compared to withRequestTarget(), withUri(), and especially withCookieParams(), which complement the existing get*() methods respectively.
From an API consistency and end user expectation perspective, this should be included if the other methods are to remain as well.

@soatok those methods are intended to modify parameters that should be modified as per the PSR-7 interface specs. Modifying server params isn't something that should be done. Those params are passed from the top down, they're not meant to be mutated.

I think there is a reason why this method didn't make it into the PSR-7 specs.

I can work around its absence but it's hacky.
I still contend that having a more consistent API (a with method paired with every get) will satisfy user expectations better than what Slim-Psr7 currently does.
If you want to exclude the capability for the reasons stated in this discussion, it should be a dummy method that throws an exception instead of simply not existing.
public function withServerParams() {
    throw new NotImplementedException("You're being very silly, developer.");
}

@soatok I think you're the one being "very silly". Following the PSR-7's spec design, modifying server params isn't part of the interfaces for a reason. In that regard, we will not be implementing this functionality.

I think you're the one being "very silly".

Exception is thrown when developer uses the API that I, and probably others, would expect to exist.
Exception message calls such developers silly.
You insist that I'm, in fact, the one being silly.

I don't think that was ever up for debate. Maybe you misunderstood the intent, but I wasn't namecalling. I'll send an alternative patch with a less tongue-in-cheek exception message.

No need for such patch, don't waste your time. It's not part of the PSR-7 spec so there are no expectations there, we're not going to implement it. Thanks.


Installation w/o Composer

How would you install this library without composer on Windows and PHP 7.1?

You should be able to download tarballs from the releases and unpack those as you like; however, you'll need to configure autoloading for the MongoDB\ namespace and require the functions.php file in your own boiler-plate code (i.e. the equivalent of Composer's autoload configuration in composer.json).


Plugin apply should be after android extension setup

This setup does not work, because source set is edited after plugin apply. Lint task just ends with NO_SOURCE result.
apply plugin: 'org.jmailen.kotlinter'
android {
    sourceSets {
        main.java.srcDirs += 'src/main/kotlin'
    }
}

And this setup works well.
android {
    sourceSets {
        main.java.srcDirs += 'src/main/kotlin'
    }
}
apply plugin: 'org.jmailen.kotlinter'

This is not a bug, because plugin creates tasks right after apply call. But I think, the second configuration example must be documented in README.md, because it can be not obvious enough for new users of plugin (like me), why it does not work.

Thanks for the report! I actually do think it is a bug since gradle provides some lifecycle hooks to do this correctly. The root cause was reported in #53. There's actually a fix out for it awaiting final approval: #55

Fixed in 1.15.0


Enhancement Improve error message when columns order and keys orders don't match.

Proposed changes
Show more clear error messages when columns order and keys order do not match.
When creating table like this:
CREATE TABLE `test`.`test_key_order` (
  `k1` tinyint(4) NULL COMMENT "",
  `k2` smallint(6) NULL COMMENT "",
  `k3` int(11) NULL COMMENT "",
  `v1` double MAX NULL COMMENT "",
  `v2` float SUM NULL COMMENT ""
) ENGINE=OLAP
AGGREGATE KEY(`k1`, `k3`, `k2`)
COMMENT "OLAP"
DISTRIBUTED BY HASH(`k1`) BUCKETS 5
PROPERTIES (
"replication_num" = "1"
);

The error message before is:
Key columns should be a ordered prefix of the schema.

With this PR, the error message is:
Key columns should be a ordered prefix of the schema. KeyColumns[1] (starts from zero) is k3, but corresponding column is k2 in the previous columns declaration.

Problem summary
Describe your changes.
Checklist(Required)

Does it affect the original behavior:

[x] Yes
[ ] No
[ ] I don't know

Has unit tests been added:

[x] Yes
[ ] No
[ ] No Need

Has document been added or modified:

[ ] Yes
[ ] No
[x] No Need

Does it need to update dependencies:

[ ] Yes
[x] No

Are there any changes that cannot be rolled back:

[ ] Yes (If Yes, please explain WHY)
[x] No

Further comments
If this is a relatively large or complex change, kick off the discussion at<EMAIL_ADDRESS>by explaining why you chose the solution you did and what alternatives you considered, etc...

When creating table like this:
CREATE TABLE `test`.`test_key_order` (
  `k1` tinyint(4) NULL COMMENT "",
  `k2` smallint(6) NULL COMMENT "",
  `k3` int(11) NULL COMMENT "",
  `v1` double MAX NULL COMMENT "",
  `v2` float SUM NULL COMMENT ""
) ENGINE=OLAP
AGGREGATE KEY(`k1`, `k3`, `k2`)
COMMENT "OLAP"
DISTRIBUTED BY HASH(`k1`) BUCKETS 5
PROPERTIES (
"replication_num" = "1"
);

The error message before is:
Key columns should be a ordered prefix of the schema.

With this PR, the error message is:
Key columns should be a ordered prefix of the schema. KeyColumns[1] (starts from zero) is k3, but corresponding column is k2 in the previous columns declaration.


Add statistics window into main application

In this PR, you are able to:

View the updated prototype screenshots in readme and user guide
See the statistics window at the top right of the application
Automatically see the updated statistics upon every command

Closes #88 #51


HBASE-28726 Revert REST protobuf package to org.apache.hadoop.hbase.rest

:broken_heart: -1 overall

Vote
Subsystem
Runtime
Logfile
Comment

+0 :ok:
reexec
0m 37s

Docker mode activated.

_ Prechecks _

+1 :green_heart:
dupname
0m  0s

No case conflicting files found.

+0 :ok:
codespell
0m  0s

codespell was not available.

+0 :ok:
detsecrets
0m  0s

detect-secrets was not available.

+0 :ok:
buf
0m  0s

buf was not available.

+0 :ok:
buf
0m  0s

buf was not available.

+1 :green_heart:
@author
0m  0s

The patch does not contain any @author tags.

+1 :green_heart:
hbaseanti
0m  0s

Patch does not have any anti-patterns.

_ master Compile Tests _

+0 :ok:
mvndep
0m 15s

Maven dependency ordering for branch

+1 :green_heart:
mvninstall
3m  3s

master passed

+1 :green_heart:
compile
8m  7s

master passed

+1 :green_heart:
checkstyle
1m  6s

master passed

+1 :green_heart:
spotbugs
10m 23s

master passed

+1 :green_heart:
spotless
0m 44s

branch has no errors when running spotless:check.

_ Patch Compile Tests _

+0 :ok:
mvndep
0m 16s

Maven dependency ordering for patch

+1 :green_heart:
mvninstall
2m 52s

the patch passed

+1 :green_heart:
compile
8m 19s

the patch passed

+1 :green_heart:
cc
8m 19s

the patch passed

+1 :green_heart:
javac
8m 19s

the patch passed

+1 :green_heart:
blanks
0m  0s

The patch has no blanks issues.

-0 :warning:
checkstyle
1m  5s
/results-checkstyle-root.txt
root: The patch generated 10 new + 23 unchanged - 0 fixed = 33 total (was 23)

+1 :green_heart:
xmllint
0m  0s

No new issues.

+1 :green_heart:
spotbugs
10m 49s

the patch passed

+1 :green_heart:
hadoopcheck
10m 14s

Patch does not cause any errors with Hadoop 3.3.6 3.4.0.

+1 :green_heart:
hbaseprotoc
3m 21s

the patch passed

-1 :x:
spotless
0m 44s

patch has 71 errors when running spotless:check, run spotless:apply to fix.

_ Other Tests _

+1 :green_heart:
asflicense
0m 32s

The patch does not generate ASF License warnings.

69m 32s

Subsystem
Report/Notes

Docker
ClientAPI=1.47 ServerAPI=1.47 base: https://ci-hbase.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-6408/1/artifact/yetus-general-check/output/Dockerfile

GITHUB PR
https://github.com/apache/hbase/pull/6408

Optional Tests
dupname asflicense javac codespell detsecrets xmllint hadoopcheck spotless compile cc buflint bufcompat hbaseprotoc spotbugs checkstyle hbaseanti

uname
Linux b8955793e65a 5.4.0-195-generic #215-Ubuntu SMP Fri Aug 2 18:28:05 UTC 2024 x86_64 x86_64 x86_64 GNU/Linux

Build tool
maven

Personality
dev-support/hbase-personality.sh

git revision
master / 09d8e03775e391aaa223e1a635a496ac66a748eb

Default Java
Eclipse Adoptium-17.0.11+9

spotless
https://ci-hbase.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-6408/1/artifact/yetus-general-check/output/patch-spotless.txt

Max. process+thread count
190 (vs. ulimit of 30000)

modules
C: hbase-protocol-shaded hbase-rest . U: .

Console output
https://ci-hbase.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-6408/1/console

versions
git=2.34.1 maven=3.9.8 spotbugs=4.7.3 xmllint=20913

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

This message was automatically generated.

:confetti_ball: +1 overall

Vote
Subsystem
Runtime
Logfile
Comment

+0 :ok:
reexec
0m 27s

Docker mode activated.

_ Prechecks _

+1 :green_heart:
dupname
0m  0s

No case conflicting files found.

+0 :ok:
codespell
0m  0s

codespell was not available.

+0 :ok:
detsecrets
0m  0s

detect-secrets was not available.

+0 :ok:
buf
0m  0s

buf was not available.

+0 :ok:
buf
0m  0s

buf was not available.

+1 :green_heart:
@author
0m  0s

The patch does not contain any @author tags.

+1 :green_heart:
hbaseanti
0m  0s

Patch does not have any anti-patterns.

_ master Compile Tests _

+0 :ok:
mvndep
0m 16s

Maven dependency ordering for branch

+1 :green_heart:
mvninstall
3m  9s

master passed

+1 :green_heart:
compile
7m 55s

master passed

+1 :green_heart:
checkstyle
1m  8s

master passed

+1 :green_heart:
spotbugs
10m  8s

master passed

+1 :green_heart:
spotless
0m 44s

branch has no errors when running spotless:check.

_ Patch Compile Tests _

+0 :ok:
mvndep
0m 14s

Maven dependency ordering for patch

+1 :green_heart:
mvninstall
2m 57s

the patch passed

+1 :green_heart:
compile
7m 59s

the patch passed

+1 :green_heart:
cc
7m 59s

the patch passed

+1 :green_heart:
javac
7m 59s

the patch passed

+1 :green_heart:
blanks
0m  0s

The patch has no blanks issues.

+1 :green_heart:
checkstyle
1m  9s

the patch passed

+1 :green_heart:
xmllint
0m  0s

No new issues.

+1 :green_heart:
spotbugs
10m 29s

the patch passed

+1 :green_heart:
hadoopcheck
11m 24s

Patch does not cause any errors with Hadoop 3.3.6 3.4.0.

+1 :green_heart:
hbaseprotoc
3m 39s

the patch passed

+1 :green_heart:
spotless
0m 42s

patch has no errors when running spotless:check.

_ Other Tests _

+1 :green_heart:
asflicense
0m 26s

The patch does not generate ASF License warnings.

70m 20s

Subsystem
Report/Notes

Docker
ClientAPI=1.43 ServerAPI=1.43 base: https://ci-hbase.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-6408/2/artifact/yetus-general-check/output/Dockerfile

GITHUB PR
https://github.com/apache/hbase/pull/6408

Optional Tests
dupname asflicense javac codespell detsecrets xmllint hadoopcheck spotless compile cc buflint bufcompat hbaseprotoc spotbugs checkstyle hbaseanti

uname
Linux 267b8dd27abb 5.4.0-1103-aws #111~18.04.1-Ubuntu SMP Tue May 23 20:04:10 UTC 2023 x86_64 x86_64 x86_64 GNU/Linux

Build tool
maven

Personality
dev-support/hbase-personality.sh

git revision
master / ab8f2a096359da1a07f857d33bc3207398bd5bfc

Default Java
Eclipse Adoptium-17.0.11+9

Max. process+thread count
191 (vs. ulimit of 30000)

modules
C: hbase-protocol-shaded hbase-rest . U: .

_ Patch Compile Tests _

+0 :ok:
mvndep
0m 15s

Maven dependency ordering for patch

+1 :green_heart:
mvninstall
3m 38s

the patch passed

+1 :green_heart:
compile
2m 27s

the patch passed

+1 :green_heart:
javac
2m 27s

the patch passed

-0 :warning:
javadoc
0m 22s
/results-javadoc-javadoc-hbase-rest.txt
hbase-rest generated 100 new + 0 unchanged - 0 fixed = 100 total (was 0)

-0 :warning:
javadoc
2m 13s
/results-javadoc-javadoc-root.txt
root generated 100 new + 102 unchanged - 0 fixed = 202 total (was 102)

+1 :green_heart:
shadedjars
6m  5s

patch has no errors when building our shaded downstream artifacts.

_ Other Tests _

+1 :green_heart:
unit
283m 51s

root in the patch passed.

326m 29s

Subsystem
Report/Notes

Docker
ClientAPI=1.43 ServerAPI=1.43 base: https://ci-hbase.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-6408/2/artifact/yetus-jdk17-hadoop3-check/output/Dockerfile

GITHUB PR
https://github.com/apache/hbase/pull/6408

Optional Tests
javac javadoc unit shadedjars compile

uname
Linux c46342a31eac 5.4.0-1103-aws #111~18.04.1-Ubuntu SMP Tue May 23 20:04:10 UTC 2023 x86_64 x86_64 x86_64 GNU/Linux

Build tool
maven

Personality
dev-support/hbase-personality.sh

git revision
master / ab8f2a096359da1a07f857d33bc3207398bd5bfc

Default Java
Eclipse Adoptium-17.0.11+9

Test Results
https://ci-hbase.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-6408/2/testReport/

Max. process+thread count
8653 (vs. ulimit of 30000)

modules
C: hbase-protocol-shaded hbase-rest . U: .

Console output
https://ci-hbase.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-6408/2/console

versions
git=2.34.1 maven=3.9.8

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

This message was automatically generated.


Postfix submission port is broken

Refs:

https://serverfault.com/questions/1046542/how-to-enable-tls-with-port-587-with-secure-authentication-on-postfix

Fixed with eea5b3e


[WIP] Implement ASTPrinter

This is the tool mainly for debug usage.
For example bin/crystal ast samples/matmul.cr,
and shows the AST.
I am now implementing, reviews are welcome :)

Thanks! But why is this useful?

AST introspection, while working on the compiler or doing tricky macro stuff I guess?

AST inspection :)
Yes this is useful when some developer debug AST.
For example I am not familiar with &.method syntax (because this is not same as Ruby's).
Dumping to there code as AST give me some knowledges.
["a", "b", "c"].try &.map &.upcase

I'm still unsure about the use cases of this. One thing that I'm more sure about is that the output should be something that a program can handle, probably JSON.
But for learning the language there are (incomplete :blush:) docs, I don't think this is a valid use case.

I personally like this idea. They do say an example speaks a thousand words! My version of writing macros in Lisps is writing a model of what the end result shouls look like and dumping the AST; that's also how I work with Python ASTs. Yeah, there're docs, but it takes longer to put two and two together.

I think this might make sense as a tool, maybe crystal tool ast, but the output should be JSON or similar. Maybe a tool could you that. It's not clear if the dumped AST should be that of the compiled file, or the whole program once require are resolved. So for now maybe you could open an issue to discuss this.


File to import not found or unreadable: x

I got the error File to import not found or unreadable: x, after trying to compile my main app.sass file with an @import "x".
This is my project structure:

My app.sass file:
@import "x"

My x.sass file:
body
    color: red

And my app.css file which is not cooperating. It's showing up as purple because of a previous test (nothing to worry about sass itself being broken 😀)
body {
  color: purple; }

My gulpfile.js
'use strict';

var gulp = require('gulp'),
    sass = require('gulp-sass');

var paths = {
    sass: {
        all: "**/*.sass",
        inc: "./src/sass/includes",
        app: "./src/sass/app.sass"
    },
    css: "./dist/css",
    node: "./node_modules"
}
gulp.task('sass', function () {
    return gulp.src(paths.sass.app)
        .pipe(sass({
            includePaths: [paths.sass.inc, paths.node]
        }).on('error', sass.logError))
        .pipe(gulp.dest(paths.css));
});
gulp.task('watch', function () {
    gulp.watch(paths.sass.all, ['sass']);
});
gulp.task('default', ['sass', 'watch']);

CLI version 2.0.1
Local version 3.9.1
gulp-sass 4.0.1
yarn 1.9.4
node 8.11.3
npm 5.6.0
Windoge 10 OS
Node.js command prompt
Thanks!

Ah, a simple error in the gulp.js. My sass includes path was "./src/sass/inc"  not "./src/sass/includes".
Sorry 😅.


chafa: fix cross-compilation

@ofborg build pkgsCross.aarch64-multiplatform.chafa

(Re)built on:

[x] x86_64-linux (native)
[x] aarch64-linux (cross from x86_64-linux)


[Revise subclass] MONDO_0019395 'Hinman syndrome'

Mondo term (ID and Label)
MONDO_0019395 'Hinman syndrome'
Suggested revision and reasons
This is a subclass of 'disease or disorder'. Could we classify it at least under MONDO_0006026 MONDO_0006026
The text def is:
Hinman syndrome (HS) or non-neurogenic neurogenic bladder is a voiding dysfunction of the bladder of neuropsychological origin that is characterized by functional bladder outlet obstruction in the absence of neurologic deficits.

Go ahead and do it. Also add disjointness axiom.
Can you also axiomatize neurogenic bladder? In fact are we sure it's a
disease and not a phenotype? (HP:0000011)
On Fri, Oct 11, 2019 at 11:04 AM Nicole Vasilevsky<EMAIL_ADDRESS>wrote:

Assigned #885 https://github.com/monarch-initiative/mondo/issues/885 to
@cmungall https://github.com/cmungall.
—
You are receiving this because you were assigned.
Reply to this email directly, view it on GitHub
https://github.com/monarch-initiative/mondo/issues/885?email_source=notifications&email_token=AAAMMOJJJ37CYOBZGXJGTZTQOC5ZRA5CNFSM4I74XSQKYY3PNVWWK3TUL52HS4DFWZEXG43VMVCXMZLOORHG65DJMZUWGYLUNFXW5KTDN5WW2ZLOORPWSZGOUFMV5YA#event-2706988768,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AAAMMOKM2DKVIZH62LOAZELQOC5ZRANCNFSM4I74XSQA
.


Add examle for native UI elements using foreign code

+1

base it on code from @nekronos https://github.com/fusetools/fuse-samples/pull/9


Enquiry about Figure 3 in Paper

Hello,
Thanks for providing this impressive paper.
I was wondering what software was used to create the point cloud serialisation visualisations in Figure 3? Were they created manually in software, or is there a script you used to generate the different serialization patterns?
Thanks!

Haha, good question. I manually draw it with PowerPoint.


Front page README tutorial seems wrong

Seems the README has been changed to this code:
// 2. Get the primitive.
Aead aead = keysetHandle.getPrimitive(Aead.class);

But I'm pretty sure getPrimitive() isn't a method of KeysetHandle, at least not in the published API docs.  Before, the tutorial instructed to use a factory like this:
Aead aead = AeadFactory.getPrimitive(keysetHandle);

Which seems to work fine.  Maybe this is some future and/or undocumented feature?

The README in the master branch documents the latest implementation. So, the example here:
https://github.com/google/tink/blob/master/README.md
corresponds with the documentation here:
https://google.github.io/tink/javadoc/tink/HEAD-SNAPSHOT/com/google/crypto/tink/KeysetHandle.html#getPrimitive-java.lang.Class-
The documentation for the latest release (v1.2.1) still contains the example you remember. See the following links for comparison with the above:
https://github.com/google/tink/blob/v1.2.1/README.md
http://google.github.io/tink/javadoc/tink/1.2.1/com/google/crypto/tink/KeysetHandle.html

Furthermore, we're working on refreshing how the documentation is presented to make the delineation between versions more clear.

Yeah, @chuckx that document link doesn't exist anymore. Can we update this with the correct information as I'm running into the same issue trying to use the HOW TO examples.

It looks like there an issue with the javadoc generation.  For comparison, compare:

https://google.github.io/tink/javadoc/tink/1.3.0-rc1/com/google/crypto/tink/package-summary.html
https://google.github.io/tink/javadoc/tink/1.3.0-rc2/com/google/crypto/tink/package-summary.html

I'll take a look into this and open a new issue for it in a bit.

FYI, bc589d5f fixes the Javadoc generation issue, and the HEAD-SNAPSHOT link above is working again.


Fix schema generation for nested/repeated models

Remove definitions update
Addresses #332

@tiangolo it looks like this is addressed by https://github.com/samuelcolvin/pydantic/pull/621 -- if that's right I'll close this pull request, but I think it could still make sense to add the schema-generation test I wrote here. (I don't care about the attribution here so feel free to just copy the test into another PR.)
Note that the schema generation is currently not deterministic due to iteration over the set of models; it might make sense to change this for the sake of testability (given the minimal performance implications).

Thanks @dmontagu ! I'll come back to this once we have a new Pydantic release with https://github.com/samuelcolvin/pydantic/pull/621.
We can leave this open, that will remind me to include your test.

Thanks @dmontagu ! I added your test in #385. So we can close this one. Thanks! :cake:


3.0.1 release?

I'd love to have an official release with the app extension API fix, so that I can use this framework in an extension without getting a warning in xcode, and so that I don't have to point to a specific commit in my cartfile. Is this something that can be done relatively soon or are there other issues that need to be resolved before a point release first?
Edit: I'd love for my PR #75 to be pulled in at the same time, so that swiftpm can easily build futurekit :)

So the original goal was to create a combine swift3/swift4 release... which seems to have fallen apart (mostly due to Carthage support?).   Even though the latest source code compiles under both, Carthage wants a supplied Xcode project with different settings...  Sigh.    Cocoapods (and I assume swiftpm) don't have an issue.
Was thinking of syncing the releases to Swift releases (3.1 and 4.0)... for simplicity.

I wasn't referring to xcode 9 swift3.2/swift4 support, I was referring that what's currently in master plus #75 if you like what's in that PR be released as a 3.0.1, and that xcode 9's swift compiler could be released as another version in the future. If you don't want to do this given that Xcode 9 will likely GM in a couple weeks, I understand, but pinning to an official released version of futurekit that fixes the extension API flag and possibly has swiftpm support would be really useful for me :)


Downloading weights

Currently weights need to be explicitly downloaded beforehand using the script config/download_weights.sh
Add necessary code in Detector in Badminton/Badminton.py to check if weights file has been downloaded, if no, download it within code and give error is weights cannot be downloaded(can happen due to network, space or some other issue)

I have tried to resolve this issue.
I have sent a PR, please have a look at it

Great! Merged


Add option to use software serial

Hi,
We ran out of HW serials, would it be possible to use/add a constructor for software serial?
We use this library for that:
https://github.com/plerup/espsoftwareserial
Thx

Someone did that in a fork of eModbus already, so yes, that is possible. It is not on our roadmap yet, but I definitely will have a look at it.

Hey Michael, thx. do you know which fork, there are a lot :-)
Then maybe I will use the fork until it is implemented in the original lib.

Sure, it was this fork by @serfreeman1337.

Hi,
We ran out of HW serials, would it be possible to use/add a constructor for software serial?
We use this library for that: https://github.com/plerup/espsoftwareserial
Thx

Hai @I-Connect,
I suggest to change the UART HW Serial port to the other IO Pin explicitly, Any pins other than Read only pin & Strapping Pins works. It will closely behave like a HW serial pin.

the fork you mentioned also had some adaptations for the esp8265, I started with your lib and changed only the software serial part serfreeman did. It seems to work (with SW serial) although it only works on core 1 for me but that could have to do with all the other tasks I am running...
If you want I can create a pull request...?

If you want I can create a pull request...?

Although this will be welcome, wait a sec, please. @bertmelis currently is trying to refactor the async TCP interface in the fix-async branch that I would like to merge first and independently. You could of course use that branch to create your PR, since I reckon the affected sources will be disjunct.

There are indeed only changes in the RTU files so it should not bite but I understand you want to wait, no probs... currently have it implemented in a fork
Let me know when you are ready

👍🏻

Closing this as now it is possible to use any Stream-based interface.

thx!!


Fixed recursive call to concat

We had two concat functions calling each other, which eventually crashed! this fixes it...

just gonna merge cause it's simple...


small correction int a README header

In English, it seems to sound really awkward or even wrong when there is no subject in a sentence. I believe that "Why sould I use it?" is the correct sentence.

LGTM


encoder/vp8: fix small resolution video encoding bug

When the resolution of video is very small such as 96x96,
the size of output buffer including the header of vp8 maybe
be larger than m_maxCodedbufSize.

Ok, then the header is a fixed sized, isn't it?  So, it would be good to use #define to define header size and extra size which I understand can be bigger than wh3/2.  I just want to make it more understandable than a magic number.

Hi Daniel:
Magic number is:

Unique values with unexplained meaning or multiple occurrences which could (preferably) be replaced with named constants

But this 0x1000 is only in one place and fully commented. So it's not a magic number. :)

I am not sure that the comment in the code is reflecting the explanation on the github review comments. That's were "unexplained meaning" is happening.  Naming the constants can certainly help.  I leave it up to you.

Ok, I will change it. If this make you confuse, It may confuse other person too. But i do not know how to find a good name for it. Do you think it's ok for
//when the resolution of video is very small such as 96x96 and buffer plus the header of vp8,
//the size of actual output buffer maybe be bigger the m_maxCodedbufSize.
//So plusing 4096 avoids the situation.
#define  VP8_EXTRA_SIZE_FOR_HEADER 0x1000

close this since magic number issue addressed by #512


[Question/Feature request] Using Telly to connect enigma2/BH to Plex Live

Is it/will it be possible to use Telly as a "bridge" to stream/pass along (standard and/or IPTV) channels from an enigma2/Black Hole device to Plex Live & DVR?

If the enigma2/black hole device offer M3U playlist files to stream like IPTV, sure.

If you open the WebUI (openwebif) of the Black holes, you can select a Bouquet and clicking on the TV icon, you can download an m3u8 file starting like the following:
#EXTM3U
#EXTVLCOPT-http-reconnect=true
#EXTINF:-1,CCN
#EXTVLCOPT: program=3023
http://<IP_ADDRESS>:8001/1:0:1:D3B:1867:4BH:FGTT:820000:0:0:0:
Is that something that Telly can understand?
Thanks!

If you can open that URL in VLC and it plays fine, yes.

You could use the Plex DVR plugin on your enigma2 device and set it up on plex normal set up works perfect for me

@HazCod I have tried, but it seems that it does not work.
@AllviewTV googling I see that Plex DVR is now called HRTunerProxy [1], but I do not know how to install it and how to use it. cAn you please provide some additional information/guidance?
Thanks.
ps: this way Telly is not even necessary, right?
[1] https://github.com/OpenViX/HRTunerProxy

Closing the issue as this isn't telly related, but feel free to continue the discussion.


Fix GitHub link

Fixes #2984
(At least it works on local readthedocs/build docker image)
The problem was that, the previous code assumed source files are located in normal chainer repo directory tree.
However, in readthedocs-build, source files seem to be copied into a .egg directory under a temporary directory.

LGTM