pandoc - statically linked closure-size

Issue description
Statically linked pandoc from all-packages.nix has huge closure size.
Pandoc has a huge closure since 2017-12-20 https://hydra.nixos.org/job/nixpkgs/trunk/pandoc.x86_64-linux#tabs-charts.
It seems that pandoc switched to file-embed at this point, and started leaking refs to haskell libraries.
I've tried running ldd and patchelf --print-rpath and both seem clean enough. Not referencing anything in haskell ecosystem. But strings shows refs to haskell libraries.

> ldd /nix/store/dikskp4kisay6gcx3dyf27q97h9a8066-pandoc-2.0.6/bin/pandoc
        linux-vdso.so.1 (0x00007ffcf4f78000)
        libm.so.6 => /nix/store/1zv5dwifxg5fh08gif8ld3h9f40y8czh-glibc-2.26-115/lib/libm.so.6 (0x00007fe3d4b29000)
        liblua.so.5.3 => /nix/store/1p116lfln2pwfywmsvgcbyfb6inz9l7i-lua-5.3.4/lib/liblua.so.5.3 (0x00007fe3d48f1000)
        libz.so.1 => /nix/store/la2xxf4grdyf37a94ak28m7a61yjqzr9-zlib-1.2.11/lib/libz.so.1 (0x00007fe3d46da000)
        librt.so.1 => /nix/store/1zv5dwifxg5fh08gif8ld3h9f40y8czh-glibc-2.26-115/lib/librt.so.1 (0x00007fe3d44d2000)
        libutil.so.1 => /nix/store/1zv5dwifxg5fh08gif8ld3h9f40y8czh-glibc-2.26-115/lib/libutil.so.1 (0x00007fe3d42cf000)
        libdl.so.2 => /nix/store/1zv5dwifxg5fh08gif8ld3h9f40y8czh-glibc-2.26-115/lib/libdl.so.2 (0x00007fe3d40cb000)
        libgmp.so.10 => /nix/store/hcn4v9kl0lgayz666yf7nfggny504bwz-gmp-6.1.2/lib/libgmp.so.10 (0x00007fe3d3e38000)
        libpthread.so.0 => /nix/store/1zv5dwifxg5fh08gif8ld3h9f40y8czh-glibc-2.26-115/lib/libpthread.so.0 (0x00007fe3d3c1a000)
        libc.so.6 => /nix/store/1zv5dwifxg5fh08gif8ld3h9f40y8czh-glibc-2.26-115/lib/libc.so.6 (0x00007fe3d3868000)
        /nix/store/1zv5dwifxg5fh08gif8ld3h9f40y8czh-glibc-2.26-115/lib/ld-linux-x86-64.so.2 => /nix/store/z0b60y0khix9jb74ka56gw7b7n9s8awx-glibc-2.26-131/lib64/ld-linux-x86-64.so.2 (0x00007fe3d4e75000)

> patchelf --print-rpath /nix/store/dikskp4kisay6gcx3dyf27q97h9a8066-pandoc-2.0.6/bin/pandoc
/nix/store/1p116lfln2pwfywmsvgcbyfb6inz9l7i-lua-5.3.4/lib:/nix/store/la2xxf4grdyf37a94ak28m7a61yjqzr9-zlib-1.2.11/lib:/nix/store/hcn4v9kl0lgayz666yf7nfggny504bwz-gmp-6.1.2/lib:/nix/store/1zv5dwifxg5fh08gif8ld3h9f40y8czh-glibc-2.26-115/lib

> strings /nix/store/dikskp4kisay6gcx3dyf27q97h9a8066-pandoc-2.0.6/bin/pandoc  | grep /nix/store
/nix/store/1zv5dwifxg5fh08gif8ld3h9f40y8czh-glibc-2.26-115/lib/ld-linux-x86-64.so.2
/nix/store/1p116lfln2pwfywmsvgcbyfb6inz9l7i-lua-5.3.4/lib:/nix/store/la2xxf4grdyf37a94ak28m7a61yjqzr9-zlib-1.2.11/lib:/nix/store/hcn4v9kl0lgayz666yf7nfggny504bwz-gmp-6.1.2/lib:/nix/store/1zv5dwifxg5fh08gif8ld3h9f40y8czh-glibc-2.26-115/lib
/nix/store/dikskp4kisay6gcx3dyf27q97h9a8066-pandoc-2.0.6/bin
/nix/store/dikskp4kisay6gcx3dyf27q97h9a8066-pandoc-2.0.6/lib/ghc-8.2.2/pandoc-2.0.6
/nix/store/dikskp4kisay6gcx3dyf27q97h9a8066-pandoc-2.0.6/lib/ghc-8.2.2/x86_64-linux-ghc-8.2.2
/nix/store/276rs4f8ad3xpld9kydw7kja95qxp1m3-pandoc-2.0.6-data/share/ghc-8.2.2/x86_64-linux-ghc-8.2.2/pandoc-2.0.6
/nix/store/dikskp4kisay6gcx3dyf27q97h9a8066-pandoc-2.0.6/libexec/x86_64-linux-ghc-8.2.2/pandoc-2.0.6
/nix/store/dikskp4kisay6gcx3dyf27q97h9a8066-pandoc-2.0.6/etc
/nix/store/sinharz0d375l5lhdj5qpb6cc4p5nqwa-pandoc-types-1.17.3/bin
/nix/store/sinharz0d375l5lhdj5qpb6cc4p5nqwa-pandoc-types-1.17.3/lib/ghc-8.2.2/pandoc-types-1.17.3
/nix/store/sinharz0d375l5lhdj5qpb6cc4p5nqwa-pandoc-types-1.17.3/lib/ghc-8.2.2/x86_64-linux-ghc-8.2.2
/nix/store/sinharz0d375l5lhdj5qpb6cc4p5nqwa-pandoc-types-1.17.3/share/x86_64-linux-ghc-8.2.2/pandoc-types-1.17.3
/nix/store/sinharz0d375l5lhdj5qpb6cc4p5nqwa-pandoc-types-1.17.3/libexec/x86_64-linux-ghc-8.2.2/pandoc-types-1.17.3
/nix/store/sinharz0d375l5lhdj5qpb6cc4p5nqwa-pandoc-types-1.17.3/etc
/nix/store/aayklpm1bgms01qcs4b6pd2ypdgiy1w8-HTTP-4000.3.9/bin
/nix/store/aayklpm1bgms01qcs4b6pd2ypdgiy1w8-HTTP-4000.3.9/lib/ghc-8.2.2/HTTP-4000.3.9
/nix/store/aayklpm1bgms01qcs4b6pd2ypdgiy1w8-HTTP-4000.3.9/lib/ghc-8.2.2/x86_64-linux-ghc-8.2.2
/nix/store/aayklpm1bgms01qcs4b6pd2ypdgiy1w8-HTTP-4000.3.9/share/x86_64-linux-ghc-8.2.2/HTTP-4000.3.9
/nix/store/aayklpm1bgms01qcs4b6pd2ypdgiy1w8-HTTP-4000.3.9/libexec/x86_64-linux-ghc-8.2.2/HTTP-4000.3.9
/nix/store/aayklpm1bgms01qcs4b6pd2ypdgiy1w8-HTTP-4000.3.9/etc

Yes, this is a problem, indeed:
$ nix-store -qR $(nix-build --no-out-link "<nixpkgs>" -A pandoc) | grep ghc
/nix/store/21xh5xbxfh7w0kbn4pphwwasvrgcq6sb-ghc-8.2.2-doc
/nix/store/iwlrpgj0g2w93hc7rmlqavhqiylpflvc-ghc-8.2.2

FWIW nix 2's "why-depends" is rather helpful for investigating these sorts of things.  May want to use "--all".

$ rabin2 -z pandoc
...
100097 0x0642fac1 0x0682fac1  72  73 (.rodata) ascii pandoc-types-1.17.3-FTIUUxYRy77FizQ4Xfoub1:Text.Pandoc.Builder.C:HasMeta
100098 0x0642fb0a 0x0682fb0a  18  19 (.rodata) ascii Paths_pandoc_types
100099 0x0642fb1d 0x0682fb1d  19  20 (.rodata) ascii pandoc_types_bindir
100100 0x0642fb31 0x0682fb31  67  68 (.rodata) ascii /nix/store/i9n8fqnm5i7gpgnf7ib4qpzxg83a0311-pandoc-types-1.17.3/bin
100101 0x0642fb75 0x0682fb75  19  20 (.rodata) ascii pandoc_types_libdir
100102 0x0642fb89 0x0682fb89  97  98 (.rodata) ascii /nix/store/i9n8fqnm5i7gpgnf7ib4qpzxg83a0311-pandoc-types-1.17.3/lib/ghc-8.2.2/pandoc-types-1.17.3
100103 0x0642fbeb 0x0682fbeb  22  23 (.rodata) ascii pandoc_types_dynlibdir
100104 0x0642fc02 0x0682fc02 100 101 (.rodata) ascii /nix/store/i9n8fqnm5i7gpgnf7ib4qpzxg83a0311-pandoc-types-1.17.3/lib/ghc-8.2.2/x86_64-linux-ghc-8.2.2
100105 0x0642fc67 0x0682fc67  20  21 (.rodata) ascii pandoc_types_datadir
100106 0x0642fc7c 0x0682fc7c 112 113 (.rodata) ascii /nix/store/i9n8fqnm5i7gpgnf7ib4qpzxg83a0311-pandoc-types-1.17.3/share/x86_64-linux-ghc-8.2.2/pandoc-types-1.17.3
100107 0x0642fced 0x0682fced  23  24 (.rodata) ascii pandoc_types_libexecdir
100108 0x0642fd05 0x0682fd05 114 115 (.rodata) ascii /nix/store/i9n8fqnm5i7gpgnf7ib4qpzxg83a0311-pandoc-types-1.17.3/libexec/x86_64-linux-ghc-8.2.2/pandoc-types-1.17.3
100109 0x0642fd78 0x0682fd78  23  24 (.rodata) ascii pandoc_types_sysconfdir
100110 0x0642fd90 0x0682fd90  67  68 (.rodata) ascii /nix/store/i9n8fqnm5i7gpgnf7ib4qpzxg83a0311-pandoc-types-1.17.3/etc

ghc seems to encode or something else seems to encode some library information into the binary:
pandoc_types_bindir pandoc_types_libdir pandoc_types_dynlibdir pandoc_types_datadir pandoc_types_libexecdir pandoc_types_sysconfdir

Can we teach ghc to stop doing that?

output of nix2:
$ nix why-depends nixpkgs.pandoc nixpkgs.ghc
/nix/store/fcn6xyp22g7dyp7aaxkgcava7416kncy-pandoc-2.1.2
╚═══bin/pandoc: ….pandoc_types_bindir./nix/store/ghjrl4kznrfy2l89b5yb94gb60rxb7w1-pandoc-types-<IP_ADDRESS>/bin.pando…
    => /nix/store/ghjrl4kznrfy2l89b5yb94gb60rxb7w1-pandoc-types-<IP_ADDRESS>
    ╚═══lib/ghc-8.2.2/x86_64-linux-ghc-8.2.2/libHSpandoc-types-<IP_ADDRESS>-BSXOOhfaVkXLfdhdUSFk6O-ghc8.2.2.so: …6_64-linux-ghc-8.2.2:/nix/store/g9baqjsh28swdy6mvvp4hp2by8xvd7af-ghc-8.2.2/lib/ghc-8.2.2/array-0…
        => /nix/store/g9baqjsh28swdy6mvvp4hp2by8xvd7af-ghc-8.2.2

The same reference I found in the binary are also in this file: https://hackage.haskell.org/package/pandoc-types-1.19/docs/src/Paths_pandoc_types.html
so this seems to be autogenerated at build time

That module is generated by Cabal if it is requested by package author. It is usually used to find datadir, in case of pandoc-types it is used to get package version. Module is listed as "other-modules" and is not exported from package, so I would expect ghc to eliminate everything besides version symbol as dead code.

Apparently it is not dead code, since I found these strings being used by machine code in the binary.

@sopvop That is true, as long as the datadir, bindir etc are not used, see git-annex or purescript for example (the latter is also compiled statically and does not refer to other libraries).

Okay, I know the reason now: (cc @peti)
When compiling statically, cabal or ghc have to put the libdir (, bindir, …) references to each library that depends on them into the binary.
Here’s the output of the pandoc binary:
○ → strings /nix/store/8ky36i3m3km1qnc7q6dzknc3qpildz36-pandoc-2.0.6/bin/pandoc | grep /nix/store
/nix/store/2kcrj1ksd2a14bm5sky182fv2xwfhfap-glibc-2.26-131/lib/ld-linux-x86-64.so.2
/nix/store/8qfd8gx0j3yzamkrbrfz5kc00h4cqd1q-gmp-6.1.2/lib:/nix/store/xjbsf7x6a9r64sxnzhd6h1f7kjs0c9vl-lua-5.3.4/lib:/nix/store/r43dk927l97n78rff7hnvsq49f3szkg6-zlib-1.2.11/lib:/nix/store/2kcrj1ksd2a14bm5sky182fv2xwfhfap-glibc-2.26-131/lib
/nix/store/8ky36i3m3km1qnc7q6dzknc3qpildz36-pandoc-2.0.6/bin
/nix/store/8ky36i3m3km1qnc7q6dzknc3qpildz36-pandoc-2.0.6/lib/ghc-8.2.2/pandoc-2.0.6
/nix/store/8ky36i3m3km1qnc7q6dzknc3qpildz36-pandoc-2.0.6/lib/ghc-8.2.2/x86_64-linux-ghc-8.2.2
/nix/store/ji0q149fqqafrriz1cc0p8yyq19qc226-pandoc-2.0.6-data/share/ghc-8.2.2/x86_64-linux-ghc-8.2.2/pandoc-2.0.6
/nix/store/8ky36i3m3km1qnc7q6dzknc3qpildz36-pandoc-2.0.6/libexec/x86_64-linux-ghc-8.2.2/pandoc-2.0.6
/nix/store/8ky36i3m3km1qnc7q6dzknc3qpildz36-pandoc-2.0.6/etc
/nix/store/wkqhd4ax8hd9lrccmlijw02wagz6zcrl-pandoc-types-<IP_ADDRESS>/bin
/nix/store/wkqhd4ax8hd9lrccmlijw02wagz6zcrl-pandoc-types-<IP_ADDRESS>/lib/ghc-8.2.2/pandoc-types-<IP_ADDRESS>
/nix/store/wkqhd4ax8hd9lrccmlijw02wagz6zcrl-pandoc-types-<IP_ADDRESS>/lib/ghc-8.2.2/x86_64-linux-ghc-8.2.2
/nix/store/wkqhd4ax8hd9lrccmlijw02wagz6zcrl-pandoc-types-<IP_ADDRESS>/share/x86_64-linux-ghc-8.2.2/pandoc-types-<IP_ADDRESS>
/nix/store/wkqhd4ax8hd9lrccmlijw02wagz6zcrl-pandoc-types-<IP_ADDRESS>/libexec/x86_64-linux-ghc-8.2.2/pandoc-types-<IP_ADDRESS>
/nix/store/wkqhd4ax8hd9lrccmlijw02wagz6zcrl-pandoc-types-<IP_ADDRESS>/etc
/nix/store/gx2cn0ybjsmxpjaqqip4a61yv94b1j4b-HTTP-4000.3.9/bin
/nix/store/gx2cn0ybjsmxpjaqqip4a61yv94b1j4b-HTTP-4000.3.9/lib/ghc-8.2.2/HTTP-4000.3.9
/nix/store/gx2cn0ybjsmxpjaqqip4a61yv94b1j4b-HTTP-4000.3.9/lib/ghc-8.2.2/x86_64-linux-ghc-8.2.2
/nix/store/gx2cn0ybjsmxpjaqqip4a61yv94b1j4b-HTTP-4000.3.9/share/x86_64-linux-ghc-8.2.2/HTTP-4000.3.9
/nix/store/gx2cn0ybjsmxpjaqqip4a61yv94b1j4b-HTTP-4000.3.9/libexec/x86_64-linux-ghc-8.2.2/HTTP-4000.3.9
/nix/store/gx2cn0ybjsmxpjaqqip4a61yv94b1j4b-HTTP-4000.3.9/etc

Here’s the output of removing each reference to Paths_pandoc from the pandoc code:
○ → strings /nix/store/89q50sngrhfbkzgyyzry0h7ahf4rk115-pandoc-2.0.6/bin/pandoc | grep /nix/store
/nix/store/2kcrj1ksd2a14bm5sky182fv2xwfhfap-glibc-2.26-131/lib/ld-linux-x86-64.so.2
/nix/store/8qfd8gx0j3yzamkrbrfz5kc00h4cqd1q-gmp-6.1.2/lib:/nix/store/xjbsf7x6a9r64sxnzhd6h1f7kjs0c9vl-lua-5.3.4/lib:/nix/store/r43dk927l97n78rff7hnvsq49f3szkg6-zlib-1.2.11/lib:/nix/store/2kcrj1ksd2a14bm5sky182fv2xwfhfap-glibc-2.26-131/lib
/nix/store/wkqhd4ax8hd9lrccmlijw02wagz6zcrl-pandoc-types-<IP_ADDRESS>/bin
/nix/store/wkqhd4ax8hd9lrccmlijw02wagz6zcrl-pandoc-types-<IP_ADDRESS>/lib/ghc-8.2.2/pandoc-types-<IP_ADDRESS>
/nix/store/wkqhd4ax8hd9lrccmlijw02wagz6zcrl-pandoc-types-<IP_ADDRESS>/lib/ghc-8.2.2/x86_64-linux-ghc-8.2.2
/nix/store/wkqhd4ax8hd9lrccmlijw02wagz6zcrl-pandoc-types-<IP_ADDRESS>/share/x86_64-linux-ghc-8.2.2/pandoc-types-<IP_ADDRESS>
/nix/store/wkqhd4ax8hd9lrccmlijw02wagz6zcrl-pandoc-types-<IP_ADDRESS>/libexec/x86_64-linux-ghc-8.2.2/pandoc-types-<IP_ADDRESS>
/nix/store/wkqhd4ax8hd9lrccmlijw02wagz6zcrl-pandoc-types-<IP_ADDRESS>/etc
/nix/store/gx2cn0ybjsmxpjaqqip4a61yv94b1j4b-HTTP-4000.3.9/bin
/nix/store/gx2cn0ybjsmxpjaqqip4a61yv94b1j4b-HTTP-4000.3.9/lib/ghc-8.2.2/HTTP-4000.3.9
/nix/store/gx2cn0ybjsmxpjaqqip4a61yv94b1j4b-HTTP-4000.3.9/lib/ghc-8.2.2/x86_64-linux-ghc-8.2.2
/nix/store/gx2cn0ybjsmxpjaqqip4a61yv94b1j4b-HTTP-4000.3.9/share/x86_64-linux-ghc-8.2.2/HTTP-4000.3.9
/nix/store/gx2cn0ybjsmxpjaqqip4a61yv94b1j4b-HTTP-4000.3.9/libexec/x86_64-linux-ghc-8.2.2/HTTP-4000.3.9
/nix/store/gx2cn0ybjsmxpjaqqip4a61yv94b1j4b-HTTP-4000.3.9/etc

And here’s the output after removing every reference to Paths_HTTP from the HTTP module pandoc depends on:
○ → strings /nix/store/644sic3knjljhancwypscsqjbw4kib1w-pandoc-2.0.6/bin/pandoc | grep /nix/store
/nix/store/2kcrj1ksd2a14bm5sky182fv2xwfhfap-glibc-2.26-131/lib/ld-linux-x86-64.so.2
/nix/store/8qfd8gx0j3yzamkrbrfz5kc00h4cqd1q-gmp-6.1.2/lib:/nix/store/xjbsf7x6a9r64sxnzhd6h1f7kjs0c9vl-lua-5.3.4/lib:/nix/store/r43dk927l97n78rff7hnvsq49f3szkg6-zlib-1.2.11/lib:/nix/store/2kcrj1ksd2a14bm5sky182fv2xwfhfap-glibc-2.26-131/lib
/nix/store/644sic3knjljhancwypscsqjbw4kib1w-pandoc-2.0.6/bin
/nix/store/644sic3knjljhancwypscsqjbw4kib1w-pandoc-2.0.6/lib/ghc-8.2.2/pandoc-2.0.6
/nix/store/644sic3knjljhancwypscsqjbw4kib1w-pandoc-2.0.6/lib/ghc-8.2.2/x86_64-linux-ghc-8.2.2
/nix/store/9x1fpvb7zmlfhs02xsznglnskqq4zy1d-pandoc-2.0.6-data/share/ghc-8.2.2/x86_64-linux-ghc-8.2.2/pandoc-2.0.6
/nix/store/644sic3knjljhancwypscsqjbw4kib1w-pandoc-2.0.6/libexec/x86_64-linux-ghc-8.2.2/pandoc-2.0.6
/nix/store/644sic3knjljhancwypscsqjbw4kib1w-pandoc-2.0.6/etc
/nix/store/wkqhd4ax8hd9lrccmlijw02wagz6zcrl-pandoc-types-<IP_ADDRESS>/bin
/nix/store/wkqhd4ax8hd9lrccmlijw02wagz6zcrl-pandoc-types-<IP_ADDRESS>/lib/ghc-8.2.2/pandoc-types-<IP_ADDRESS>
/nix/store/wkqhd4ax8hd9lrccmlijw02wagz6zcrl-pandoc-types-<IP_ADDRESS>/lib/ghc-8.2.2/x86_64-linux-ghc-8.2.2
/nix/store/wkqhd4ax8hd9lrccmlijw02wagz6zcrl-pandoc-types-<IP_ADDRESS>/share/x86_64-linux-ghc-8.2.2/pandoc-types-<IP_ADDRESS>
/nix/store/wkqhd4ax8hd9lrccmlijw02wagz6zcrl-pandoc-types-<IP_ADDRESS>/libexec/x86_64-linux-ghc-8.2.2/pandoc-types-<IP_ADDRESS>
/nix/store/wkqhd4ax8hd9lrccmlijw02wagz6zcrl-pandoc-types-<IP_ADDRESS>/etc

I don't understand that explanation. Why does ghc have to put any any of those reference into the binary? And why did it not have to do that before 2017-12-20?

Wasn't it the day when haskellPackages switched from 8.0.2 to 8.2.2? Seems so https://github.com/NixOS/nixpkgs/commit/d5676b04331efa730aa86c6a3c6cc0769b44a1e1

@peti it is not ghc, but generated haskell modules and some code in the executable is using this in pandoc.

@peti I think it’s because HTTP and pandoc-types use their generated Paths_ module at runtime, so GHC has to embed these paths into the static binary as well. What I don’t know is why apparently all of these paths are embedded, even though e.g. HTTP only uses the version function.
I get the feeling this sounds like a Cabal bug.

@Profpatsch does haskell perform link-time optimization by default? Otherwise it might not detect if a methods are not used. I don't know about the intermediate object files that the haskell compiler generates but looking at the binary size of haskell programs it does not seem so.

https://wiki.haskell.org/GHC_optimisations#Dead_code_elimination

Okay, I had a chat with @hvr (the Cabal maintainer):

When you have a string literal (foo = "a bc") that is exported from a module, GHC directly embeds it into the interface file (and app

Hi, I'd very interested in this problem to be solved. I'm packaging a hakyll-based binary, for generating a website, with dockerTools, and since it relies on pandoc… Well:

StaticHaskell binary : 80MB
Base layer with dockerTools : 700MB
Uncompressed image after import in docker : 4,7GB (fits a DVD!)

Some more information on the binary's dynamic deps:
$ ldd ./result/bin/site
	linux-vdso.so.1 (0x00007ffeb4fc2000)
	libm.so.6 => /nix/store/pr73kx0cdszbv9iw49g8dzi0nqxfjbx2-glibc-2.27/lib/libm.so.6 (0x00007f1eb6862000)
	liblua.so.5.3 => /nix/store/v2a5c2rijnh2x9nii5y307nmp2ah0h0r-lua-5.3.4/lib/liblua.so.5.3 (0x00007f1eb662a000)
	libz.so.1 => /nix/store/gf00m2nz8079di7ihc6fj75v5jbh8p8v-zlib-1.2.11/lib/libz.so.1 (0x00007f1eb640e000)
	librt.so.1 => /nix/store/pr73kx0cdszbv9iw49g8dzi0nqxfjbx2-glibc-2.27/lib/librt.so.1 (0x00007f1eb6206000)
	libutil.so.1 => /nix/store/pr73kx0cdszbv9iw49g8dzi0nqxfjbx2-glibc-2.27/lib/libutil.so.1 (0x00007f1eb6003000)
	libdl.so.2 => /nix/store/pr73kx0cdszbv9iw49g8dzi0nqxfjbx2-glibc-2.27/lib/libdl.so.2 (0x00007f1eb5dff000)
	libpthread.so.0 => /nix/store/pr73kx0cdszbv9iw49g8dzi0nqxfjbx2-glibc-2.27/lib/libpthread.so.0 (0x00007f1eb5be0000)
	libgmp.so.10 => /nix/store/14nlrnm6bv7z25c9ismlhc2mrxsriyq2-gmp-6.1.2/lib/libgmp.so.10 (0x00007f1eb594c000)
	libc.so.6 => /nix/store/pr73kx0cdszbv9iw49g8dzi0nqxfjbx2-glibc-2.27/lib/libc.so.6 (0x00007f1eb5598000)
	/nix/store/pr73kx0cdszbv9iw49g8dzi0nqxfjbx2-glibc-2.27/lib/ld-linux-x86-64.so.2 => /nix/store/pr73kx0cdszbv9iw49g8dzi0nqxfjbx2-glibc-2.27/lib64/ld-linux-x86-64.so.2 (0x00007f1eb6bf7000)

$ nix run nixpkgs.patchelf -c patchelf --print-rpath ./result/bin/site
/nix/store/14nlrnm6bv7z25c9ismlhc2mrxsriyq2-gmp-6.1.2/lib:/nix/store/v2a5c2rijnh2x9nii5y307nmp2ah0h0r-lua-5.3.4/lib:/nix/store/gf00m2nz8079di7ihc6fj75v5jbh8p8v-zlib-1.2.11/lib:/nix/store/pr73kx0cdszbv9iw49g8dzi0nqxfjbx2-glibc-2.27/lib

strings shows references to pandoc and pandoc-types.

@MartinPotier there’s two solutions, one for this specific use case and one general.

This specific use case: Look at the output of why-depends and patch out all references to the Paths_ modules in the respective transitive dependencies
General: Patch Cabal so that you can give Cabal a list of symbols it should put into the generated Paths_ module.

https://github.com/NixOS/nixpkgs/pull/32629 has the potential to solve this, but needs some investigation for pandoc.

@domenkozar I saw that #58525 (the successor to #32629) landed, is that enough to make progress on this issue? Thanks!

Sadly no, as @Profpatsch mentioned for some reason dead code elimination doesn't do it's job here, it needs to be solved in Cabal.
There are a few potential paths here:

playing around with --enable-relocatable
investigate why dead code elimination doesn't kick in https://github.com/haskell/cabal/issues/3909

Hokay. In case it helps anyone else, I've been just downloading the static builds provided by pandoc, for example:
stdenv.mkDerivation {
  name = "pandoc";
  propagatedBuildInputs = [texlive.combined.scheme-basic];
  src = fetchTarball {
    url = https://github.com/jgm/pandoc/releases/download/2.5/pandoc-2.5-linux.tar.gz;
    sha256 = "1zi7d14cjpnf9xf7s71l0q26aw8xdnshciyx9ygl1as04g1yykr8";
  };
  buildPhase = "true";
  installPhase = ''
    mkdir -p $out/bin
    cp bin/pandoc $out/bin
  '';
}

@thomasjm you need now dontStrip = false otherwise it segfaults in newer versions. I have a pandoc-bin in my NUR repository:
$ nix-shell -p nur.repos.mic92.pandoc-bin

This issue has been mentioned on NixOS Discourse. There might be relevant details there:
https://discourse.nixos.org/t/bup-on-arm64-installs-haskell-etc-1-2gb/6705/8

I patched out the indirect dependency on GHC here: https://github.com/NixOS/nixpkgs/pull/86194
Still, every haskellPackages library has a runtime dependency on the GHC closure, because the base packages are not split, which is a different issue.
And of course we should still catch cabal to not generate the datadir/… symbols if we pass a flag, which we should make the default for haskellPackages (unless a package really needs it, then it can enable it manually).

At least we sorted out pandoc.

There is going to be a regression should pandoc add another one of these, so it’s at best solved temporarily. We don’t test for closure size regressions and I don’t know how we could in the first place.

It seems like the predicted regression happened awhile back:
$ nix path-info -S $(which pandoc)
/nix/store/w63pgjhzgk0bnizszkdbr6qid7a1aiq1-pandoc-<IP_ADDRESS><PHONE_NUMBER>

ref https://github.com/NixOS/nixpkgs/pull/199442, https://github.com/EmaApps/emanote/issues/295
I could paint by numbers to create an updated patch based on @Profpatsch's, but it would be so much better to fix the ecosystem.
Looking at the cabal issue, it seems there's a 3-week-old PR that may move things forward. Maybe some nix Haskellers would want to have a look?

Also, some way of surfacing increases in closure size would be amazing. Is there any TSDB getting metrics for nixpkgs packages already? I could see feeding something like influxdb via a hydra hook, with a static web report out front.

but hydra.nixos.org/job/nixos/trunk-combined/nixpkgs.pandoc.x86_64-linux#tabs-charts shows a closure size of only 223MiB. Am I measuring incorrectly?

This PR was mostly about pandoc referencing ghc, as pointed out in the 1st comment of this thread. Now, on master it's not, you can test this for yourself with nix why-depends or nix-store --query --references.

I see, the emanote closure from the above PR somehow contains a pandoc that does depend on ghc.


Add declare strict types.

Q
A

Is bugfix?
✔/❌

New feature?
✔/❌

Breaks BC?
✔/❌

Tests pass?
✔/❌

Fixed issues
comma-separated list of tickets # fixed by the PR, if any

Thks,


[Question] Login integration

First, thank you for the library it's great!
Would be nice to see a very basic integration between the library and a logging endpoint in order to understand the integration with the library in that process.
I can logging with the Fastapi docs but not from my app. I feel I'm reinventing the wheel trying to do the authentication steps. I'm ending creating my own functions try to follow the oath2 flow.
Thanks!

Hi!

First, thank you for the library it's great!

Thank you! 😊

Would be nice to see a very basic integration between the library and a login endpoint in order to understand the integration with the library in that process.

This package only supports API auth, using bearer tokens. This means your user must log in without any involvement of the backend and recieve an access_token. This token is then sent to the FastAPI backend in the header.

I can log in with the OpenAPI docs but not from my app. I feel I'm reinventing the wheel trying to do the authentication steps. I'm ending creating my own functions try to follow the oath2 flow.

Login to the frontend will vary on the framework and how the application is written. Are your frontend a single-page application (e.g. react/angular), or are you hosting it through FastAPI (MVC frontend, such as jinja2)?
(I've edited your questions a tiny bit, since I was a bit confused whether you talked about logging (as in logger.debug(...)) or logging in to the application.)

I'll try to describe how it works in very short steps (inspired from what I wrote in #33, which I recommend you read):

Frontend fetches token with the PKCE flow (using e.g. Azure ADAL library for react)
Frontend makes an API call to the FastAPI backend, attaching the access_token in the header as a Bearer token.

You can see an example on how this works in the OpenAPI documentation when you try out the API

Backend receives and validates the token, and if everything is OK, the request will be passed on to the API.

I'm closing this issue, but you can still comment (I will still get notified), re open it or create a new issue if you have any further questions. :blush:

I all ready own you a couple coffees man!
The topic has been more complex than I expected but with your help I think I'll have it done.
Maybe It's good idea to mention the PKCE flow explicitly on the documentation, just to avoid confusion in noobs
Thanks again!!

🍻
I am actually writing a blog post about how OpenID Connect and PKCE works and how they tie together. It will be released soon™. I'll make sure to link to it in the documentation!😊

Nice!! I'll be waiting for that post!
See ya  around!!

I wrote Azure ADAL above, but you should use Azure MSAL. So if you're using react, please use MSAL and not ADAL.

 I feel like Tarzan here. But here's come google to the rescue.

If you write your frontend application with react, there is a library developed by Azure that handles everything you need. The library is called MSAL

Hi @productoptimization, @alexjolig and @ yeguacelestial!
I’ve written a little blog post on how everything is glued together. You can read it here

Also @yeguacelestial, see the comment above 😊

@JonasKs yeah definitely PKCE has its learning curve, struggled a little bit understanding what I was doing but essentially I did what you suggested, and it works!
Thank you very much man 😄


They fail with YouTube displaying the error:
"An error occurred. Please try again later. (Playback ID: xxxx-xxxxxxx)
Expected Behavior
The video should play without an error.
Steps to Reproduce

Go to https://cookpete.com/react-player/
Enable an ad-blocker (Adblock Plus)
Click on the YouTube Test A or Test B button

Environment

Browser: Chrome
Operating system: Windows 10

Other Information
The YouTube demo is working fine from Firefox
The videos play fine directly from YouTube.
The videos were playing fine a few days ago so maybe this is just a YouTube problem related to system overloading

This certainly is a problem, but I don't think it's anything ReactPlayer can fix.

It would be great if react-player could detect that it was being blocked. We could then ask the user to turn off their ad blocker

Using the onError event to display seems like a reasonable solution to this problem.
Thanks Pete for your response.


Gdx.graphics.getDensity() returns infinity inside VirtualBox

Issue details
Calling Gdx.graphics.getDensity() inside VirtualBox (Linux guest/host) returns Infinity (because display size reported by Lwjgl is 0). I understand that on some platforms the display density can not be computed, but I think there should be a special value UNKNOWN or an exception thrown to force client code to handle this case. I got an exception in the JNI code of FreeType (because I use density for font size scaling), and getDensity() doesn't indicate it can return a completely invalid value.
It returns an estimate in any case, so if the value is too low / too high it can just default to 1 or something.
Version of LibGDX and/or relevant dependencies
GDX version 1.10.0 (latest at time of writing)
Please select the affected platforms

[ ] Android
[ ] iOS
[ ] HTML/GWT
[ ] Windows
[x] Linux
[ ] MacOS

Could you please try whether the issue also happens with the LWJGL 3 backend?

This is with Lwjgl3. It is not trivial to switch to 2 at this point :)

Good point that it already returns an estimate; I think you're right in your interpretation of the docs that it does not indicate it can return a non-finite value, and an estimate shouldn't generally be infinite or NaN. A density of 0 would clearly indicate that something is wrong with the estimation, since there's no way you could have a screen with 0 pixels per inch/cm that actually works. Same for a negative number. I'm not sure if it's better to just return 1, indicating "some normal screen," if the screen is actually unusable at that point in time. A quick workaround might be to use Float.isFinite() as your check for an invalid result, since that would pick up both infinities and also NaN (and NaN is tricky to check for normally). I don't know if getDensity() can return NaN, but if it's dividing a positive number by 0.0f already to get Infinity, it's not unreasonable that it could divide 0 by 0.0f and get NaN.

I think you should also report this to the GLFW project, since the bug seems to be on their end.

Hi there, the following is a possible fix:
AbstractGraphics.cs lines 10-20

/**
* Facade method that estimates the pixel density of the underlying Graphics implementation.
* @return The approximated pixel density, or 1 if this could not be determined
*/
@Override
public float getDensity () {
	float ppiX = getPpiX();
	// Guard against invalid values
	if (ppiX <= 0 || Float.isNaN(ppiX)) return 1f;
	return ppiX / 160f;
}

The solution posted by @tommyettinger sounds good here, but unfortunately, Float.isFinite() is only available from Java 1.8 and up. I did not have the rights to push to a new branch, and open up a Pull Request.  Infinity wouldn't be considered <= 0 and isNaN() returns false. NaN is an oddity, but looking at the OpenJDK source code gives a solution:
public float getDensity () {
	float ppiX = getPpiX();
	return (ppiX > 0 && ppiX <= Float.MAX_VALUE) ? ppiX / 160f : 1f;
}

The important thing here is that all valid finite floats are <= Float.MAX_VALUE (NaN is not, so it gets ruled out), and we only want positive and non-zero floats, so the check for > 0 also rules out negative infinity. The check against MAX_VALUE  is used by isFinite() in Java 8. I changed getDensity() to single-return form because I think some JDKs can analyze that form a little easier, or at least it won't be harder.
There's still the issue that an invalid PPI is now indistinguishable from a common one, 1f. I think in the cases where we would get an invalid PPI, the display density doesn't really matter as long as it doesn't cause problems, so 1f is probably fine; users could check on their own if getPpiX() returns a value they can handle, also.

@tommyettinger Great, indeed this improves it. I don't think that the indistinguisibility is bad, because getDensity() returns an approximate anyways. To me, 1f (one pixel per unit) is true always, except when the screen is better than that.
Anyways, that's my two cents 🙂

That's true, it is approximate, so 1f as a general guess is probably fine. It could maybe do something like 0.015625f density as an indicator of something very strange happening, but still a technically possible resolution. That's 1/64, which would correspond to 2.5 pixels per inch or less than 1 pixel per centimeter, and that seems unlikely to appear. Maybe a monome, or some other similar hardware, would have that approximate resolution, but I doubt one of those is a valid display for LWJGL3. But yeah, that's not needed because getPpiX() is still available and can be used to check if the backing information is something strange, even if getDensity() returns 1f for valid and invalid situations. Thanks for hopping on to the Discord, by the way; if you encounter any issues with adding a PR, feel free to ask in the contributing channel there (there are several "gotcha" problems that can affect PRs, chief among them formatting being automatically changed).

This has been fixed in #6539, however, it would still be appreciated if you reported this issue (i.e. glfwGetMonitorPhysicalSize returns the wrong display size) to the GLFW project with some information about your specific setup.

@crykn I will report to GLFW. The setup is not too crazy -- virtualbox + linux (Arch). In any case I'm glad you worked around it. There is always a chance that GLFW will return wrong data.


Postman token does not work

First problem:
Step 6., enter Scope does not work as described.
Error in Postman console: Client credential flows must have a scope value with /.default suffixed to the resource identifier (application ID URI).
Entering .default instead of Forecast.Read creates a token.
Second problem:
With this token used (button "Use Token" in postman), the API retruns http code 401, error text: "invalid token" and not the JSON weather forecast.

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

ID: 75fc046d-6e82-592c-05a4-331b13358bc3
Version Independent ID: 34c85478-84e1-db70-af23-bdb4d5098799
Content: Call an ASP.NET Core web API with Postman - Microsoft Entra
Content Source: articles/active-directory/develop/howto-call-a-web-api-with-postman.md
Service: active-directory
GitHub Login: @henrymbuguakiarie
Microsoft Alias: henrymbugua

@MartinBubenheimer
Thanks for your feedback! We will investigate and update as appropriate.

@MartinBubenheimer
Thank you for your feedback!
Since this issue isn't directly related to improving our docs, and to gain a better understanding of your issue, I'd recommend working closer with our support team via an Azure support request. Or you can leverage our Q&A forum by posting your issue there so our community, and MVPs can further assist you in troubleshooting this issue or finding potential workarounds.
Teams Q&A forum for technical questions about the configuration and administration of Microsoft Teams on Windows.
Microsoft Teams Community forum
Thank you for your time and patience throughout this issue.


Use coreneuron module API from NEURON instead of pc.nrncore_run()

This is to also test the issue mentioned in #369.


Expand test matrix to debug CI issues

[ ] I have added the tests to cover my changes.
[ ] I have updated the documentation and CHANGELOG accordingly.
[ ] I have read the CONTRIBUTING document.

@AlejandroEsquivel we might also wanna remove the "pull_request" trigger from the test_matrix.json before merging this in.


tweets random reminders on Twitter!

🛠 Fixes Issue
Closes  #6
👨💻 Changes proposed
I have made changes to main.py file where it selects a random line from reminders.txt  and sends it on Twitter.
I've already tried and tested it so that it tweets after every 4 hours!
✔ Check List (Check all the applicable boxes)

[x] My code follows the code style of this project.
[x] This PR does not contain plagiarized content.
[x] The title of my pull request is a short description of the requested changes.

📄 Note to reviewers
I'm open to feedback for this PR. 😃
📷 Screenshots

Hey @ykdojo 👋
I have made changes in the main.py file as suggested.
Added a new file load_env.py for loading all your secret keys! Can't commit .env file cause it's risky!
Lastly, added requirements.txt file for keeping records of all packages.
Let me know your thoughts! 😃

That's perfect. Thank you so much!!

Had fun contributing in this project!
Always ready to help 🤗


Updating unit tests for Account Controller #661

#661 - write unit tests for account controller.  Have updated 37 of the
tests to run.  Updated all the attribute tests and the simple get view
tests.

Great work here again @klabranche.
I'm pretty sure we'll be able to simplify this when we amalgamate the authentication bits.
:shipit:


Hide sidebar toggle on larger screens

Closes https://adjustcom.atlassian.net/browse/THC-990

Closed in favour of #809


support metadata in state bulk get state

update GetBulkState method:

add metedata parameter
change return struct to BulkStateItem

The details of this PR is discussed in dapr issue :
https://github.com/dapr/dapr/issues/2368
https://github.com/dapr/dapr/issues/2498

/cc @mchmarny

@skyao thanks for the PR. You can update the protos in the go SDK by running make protos so you can uncomment the BulkStateItem bits and we land a clean PR. Also, could please expand the existing test to cover the metadata bits your PR adds to state. We have test coverage thresholds in place so adding these new fields to test will ensure the PR passes.

OK, I will try to update the protos and generated go source code.
But I meet one problem: when I run "make protos" successfully without change the protos, the generated code is big different with curernt files. I think this difference due to the version of the tools.
Since I don't find any review requirements in go-sdk repo, I tried to find in dapr repo and found this:

Because of etcd dependency issue, contributor needs to use the below verisons of tools to generate gRPC protobuf clients.

protoc version: v3.11.0
protobuf protoc-gen-go: v1.3.2
gRPC version: v1.26.0

Should we use the save version in go-sdk?

I update to use above version, the generated code is the same as commited in dapr/dapr repo.  But it is big different with the one in go sdk.
And in dapr/proto/runtime/v1/dapr.pb.go of go-sdk, I found following information:
// Code generated by protoc-gen-go. DO NOT EDIT.
// versions:
// 	protoc-gen-go v1.25.0
// 	protoc        v3.13.0
// source: dapr/proto/runtime/v1/dapr.proto

Compare to the version requirements in dapr/dapr:
protoc version: v3.11.0
protobuf protoc-gen-go: v1.3.2
gRPC version: v1.26.0

So to generated the code in go-sdk, which version should we use?

We should follow the newer one, in dapr/dapr. Let me take a look at the setup in makefile.

OK, so ye, we should use the new one. The make protos step in go-sdk makefile just uses whatever version of protoc you have installed locally. I just ran it and got:
// 	protoc-gen-go v1.25.0
// 	protoc        v3.14.0

I know @youngbupark was going to be updating the protoc in dapr/dapr.
Let me update the protos in a separate PR then you can re-base on that.

OK, I got #116 in, one this lands you can update the metadata PR.

OK, #116 landed, so you just need to resolve these few conflicts and you should be good to go.

@mchmarny Code rebased now.


Character Counter: allow and prefer to use data-maxlength attr instead of length

The length input attribute is invalid because it doesn't exist.
http://www.w3schools.com/tags/tag_input.asp
I think data-maxlength (or data-length?) should be used (at least preferred to use).

We now use data-length


Fix code in readme

While the code in the readme.md was valid, it is uncommon to rely on the fact that "\." is not treated as an escape and is equal to the string "\\.". Using the quoted string, i.e. "@"xyz\,abc" ensures that you wouldn't accidentally use a backslash that is a special escape.
As a bonus, it removes the redness of the code.

Appreciated thanks!


CORE-16319 - use System.currentTimeMillis() instead of Instant.now()

Testing nightly windows build here - https://ci02.dev.r3.com/job/Corda5/job/Nightlys/job/Corda-Runtime-OS/job/Windows/job/PR-4662/

System.currentTimeMillis() is not suitable for calculating elapsed time accurately.

System.currentTimeMillis() is not suitable for calculating elapsed time accurately.

Yeah it was in attempt to cut off some of the precision, but not the correct approach. The correct way to resolve this is to fetch the persisted times of the entities we want to use for the interval and use these in the stateManager.getUpdatedBetween(startTime, finishTime) API. These start and finish times are inclusive in the query.


How to support Timestamp fields?

How can timestamp fields be used in the test data?
It seems that dart:covert cannot deserialize the JSON to Firestore Timestamp values because in Json, it's either just a string or an int.
Is there any possibility to support Timestamp values with the current state of this library?

can you add a test for it? then i can try to implement it. You can find tests in test/ directory

I'm also interested in supporting timestamp fields.
When I export my stuff from cloud firestore this is what I get for timestamps
{"_seconds":<PHONE_NUMBER>, "_nanoseconds": 0},

i believe #18 resolved this issue, published 0.0.20 with it.
thanks @mentoc3000


Navigate to a column in the data grid.

While examining data for SQLs that return a large number of columns, it would be convenient to navigate to the column by specifying a column name off the context menu on the grid - maybe under Navigate and a suboption "column name"? It is somewhat possible by sorting the columns in the record view and switching back to the column view. But again for SQLs that return a large number of columns, it is still not the easiest way of doing so. This feature is available in a few other tools including SQL Workbench/J.
Thank you.

I'm closing this issue as it's a duplicate of #3052. You can vote for the mentioned issue with 👍🏻 under the issue description.


Feat: Home Assistant Assist pipeline called first

I think this idea would be really cool, but if it isn't inline with the direction of this project, then I can close this and work on a personal fork.
Idea: The initial pipeline could be the Assist pipeline, then if the response is Sorry, I couldn't understand that then you could call a second OpenAI pipeline that could handle the input. Calling the Home assistant Assist pipeline first would allow actions to be executed, but still also have the ability to converse in natural language with ChatGPT. One way to enhance the performance is to have the first pipeline only be STT and Assist and the second pipeline only ChatGPT and TTS.

Hi kcoderhtml,
That is an interesting idea. I believe that could be done and I'll test this out.
Robert

Thank you!


Update dependency opensearch-ml-client group name

Signed-off-by: jackieyanghan<EMAIL_ADDRESS>Description
Update dependency ml-client group name based on this change - https://github.com/opensearch-project/ml-commons/commit/e89540516a3f92e0e016f079f63e6bd3452eb08f
Issues Resolved
[List any issues this PR will resolve]
Check List

[x] New functionality includes testing.

[x] All tests pass, including unit test, integration test and doctest

[x] New functionality has been documented.

[x] New functionality has javadoc added
[x] New functionality has user manual doc added

[x] Commits are signed per the DCO using --signoff

By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.
For more information on following Developer Certificate of Origin and signing off your commits, please check here.

LGTM

Codecov Report

Merging #477 (385d2f5) into main (eb1ede4) will decrease coverage by 32.33%.
The diff coverage is n/a.

@@              Coverage Diff              @@
##               main     #477       +/-   ##
=============================================
- Coverage     95.25%   62.91%   -32.34%
=============================================
  Files           276       10      -266
  Lines          7414      658     -6756
  Branches        538      119      -419
=============================================
- Hits           7062      414     -6648
+ Misses          298      191      -107
+ Partials         54       53        -1

Flag
Coverage Δ

query-workbench
62.91% <ø> (ø)

sql-engine
?

Flags with carried forward coverage won't be shown. Click here to find out more.

Impacted Files
Coverage Δ

...a/org/opensearch/sql/data/model/ExprTimeValue.java

...nsearch/sql/expression/aggregation/Aggregator.java

...rg/opensearch/sql/ppl/domain/PPLQueryResponse.java

...search/sql/data/model/AbstractExprNumberValue.java

...request/system/OpenSearchDescribeIndexRequest.java

...opensearch/sql/exception/QueryEngineException.java

...rch/executor/protector/NoopExecutionProtector.java

...nsearch/executor/protector/ExecutionProtector.java

...opensearch/sql/planner/physical/LimitOperator.java

...arch/planner/logical/rule/MergeAggAndRelation.java

... and 256 more

Continue to review full report at Codecov.

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


[WIP] Add riscv to jdk11 build pipeline

fixes: #1576

The most recent commit sets the environment variables based on what I had the jdk11-linux-riscv-openj9-build Jenkins job configured to do.

You'll need to add an entry to https://github.com/AdoptOpenJDK/openjdk-build/blob/master/pipelines/jobs/configurations/jdk11u.groovy as well, just look at the other examples pretty self explanatory. Other than that I'm not sure, we'll know if it works and whats missing when this gets merged

I've managed to get riscv building on the machine by running the following script, using this branch.
#!/bin/bash
export JAVA_TO_BUILD=jdk11u
export TARGET_OS=linux
export VARIANT=openj9
export ARCHITECTURE=riscv
export JAVA_HOME=/usr/lib/jvm/java-1.8.0
export JDK_BOOT_DIR=/usr/lib/jvm/jdk-10.0.2+13/
openjdk-build/build-farm/make-adopt-build-farm.sh

Additional changes were made to ensure the correct versions of the openj9-openjdk-jdk11, omr and openj9 were cloned, however this won't be required when riscv support has officially been put into openj9
The only issue I ran into was when building Freetype in the build script - as CC & CXX are set to the cross compiler, when freetype is building, this is picked up and errors. I got round this by skipping the freetype build with -F, however I'm not sure this is ideal

With latest commit, I believe all has been set to run the riscv build using the build scripts 👍 Just waiting on the additions into Eclipse/OpenJ9 for this to become useful.

With ChengJin's changes being merged, this is ready for review

@M-Davies Can you check over this and see if it's adequate or if any other changes will be required?

I'd like to give this another day for anyone to voice their objections in order to ensure we do not risk destabilising the nightlies - assuming there are no extra concerns we can look at merging and running a new pipeline tomorrow to test this.


why does it blink when move mouse cursor over the panel?

Hi, I am on Macbook pro and found it keep blinking while moving mouse cursor over the panel, why?

Same issue here, can't seem to figure out them problem.

@happy15 I just noticed that if you enlarge the window the flashing stops :)

@christophesmet thanks for your info.


how do you use the email

it returns a html page or something im not sure how you would access the email
this is what it returns
<EMAIL_ADDRESS>fyii.de/trashmail/e939254a.html

i figured it out but it still doesent work with discord


Log request counter every 10min

What type of PR is this?
/kind feature

What this PR does / why we need it:
This change logs the number of HTTP requests to GCR every 10min if the auditor is passed the --verbose flag. If enabled, the request counter will continuously produce logs that look like this:
Since 2006-01-02 15:04:05 there have been 3402 requests to GCR.

Since the actual Container Registry defines it's quota as 50,000 HTTP requests every 10 minutes, this feature will give us insight into how close the auditor is getting to this upper-limit.
NOTE: If the auditor surpasses this GCR quota, the responses will be throttled, resulting in slower image verification. Depending on the number of Pub/Sub messages it must respond to, this can lead to unacknowledged messages.
Which issue(s) this PR fixes:
Partially satisfies #358
Special notes for your reviewer:
The --verbose flag will not be added to auditor builds (the Dockerfile) until tests validate all behavior.
Accidentally closed #360, this PR contains all of this work.
Does this PR introduce a user-facing change?
NONE
Continuously log request counter every 10min.

cc: @listx @amwat @justaugustus @kubernetes-sigs/release-engineering

This work comes form #360, which was accidentally rebased incorrectly, forcing it to close.

Thanks!
/lgtm
/approve


Audio lag/crackles when locking phone screen

The Issue
When locking the screen, the audio reproduction will start lagging and crackling
Steps to reproduce

Play anything
Lock the screen
Audio starts breaking up

Expected behaviour
The screen should be locking and the audio should still play unaffected
Actual behaviour
The phone locks but the audio starts breaking up
System Configuration

Device: Oneplus 5T
Android version: 10

Anything Else
App version 0.16.0
SDK 0.80.0
Platform Android 10 (API 29)

If it was related to https://github.com/lbryio/lbry-android/issues/1101, this should be fixed now.


Adapt refine to work with Metric classes

Blocked subject to closing of #585

No longer makes sense based on refactoring


Add user programmable button

Add button which can be reconfigured on the fly by software. A BTN_CONFIG register could be created, which maps the button press to a bit in the command register. This would allow users to start/stop SD scripts, reset DUT, flush buffer, etc while operating headless.
Ideally it would be nice for button to be rotated 90 degrees relative to the board (accessible from the side), but in plane with the micro could also work (primary use case is for headless data logging).

@juchong I will figure out what pin would be best for this - ideally a GPIO which doesn't share an interrupt with other parts of firmware

This has been incorporated into the rev C board design


Python Server has key error after receiving request for non existent Method

I got the following from the python server.
ERROR:root:Unexpected exception from task run in logging pool!
Traceback (most recent call last):
  File "/Users/endobson/proj/grpc/python2.7_virtual_environment/lib/python2.7/site-packages/grpc/framework/foundation/logging_pool.py", line 43, in _wrapping
    return behavior(*args, **kwargs)
  File "/Users/endobson/proj/grpc/python2.7_virtual_environment/lib/python2.7/site-packages/grpc/_adapter/fore.py", line 231, in _spin
    self._on_service_acceptance_event(event, server)
  File "/Users/endobson/proj/grpc/python2.7_virtual_environment/lib/python2.7/site-packages/grpc/_adapter/fore.py", line 125, in _on_service_acceptance_event
    self._request_deserializers[method],
KeyError: 'Method'

My client is currently just sending an empty initial metadata and asking for a method "Method". I only get this once so I assume that means that the processing thread died which seems bad.

Thanks for the report; I agree that this looks like a problem.
In what language is the client with which you're making these requests?

Racket. I'm writing my own client on top of the C bindings.

Cool!
Were you using the Python client you would have seen this problem client-side.

(Changed the bug title to capture this defect report's exit condition.)

This defect is specific to the alpha code and will be resolved this week as the beta code goes live.

Marking fixed

I wouldn't call this fixed today but I will call it subsumed by #2634, so consider it "resolved as duplicate". :-)


Remove references to other cloud vendors in open shift doc

Replace mentions of cloud provider examples with Azure.

@dlapiduz : Thanks for your contribution! The author, @haroldwongms, has been notified to review your proposed change.

@haroldwongms can you add "#sign-off" to this one? Thanks!

@dlapiduz: I'm sorry - only the author of this article, @haroldwongms, can sign off on your changes. But we do have an exception process - if you are on the Microsoft content or product team for this product area, you can ask the PR review team to review and merge it by sending mail to the techdocprs alias.

#sign-off


Introduce backends

For now, we can only connect himalaya to an IMAP server with this config:
global-settings

[account-name]
account-settings

We want to connect other backends:

Notmuch #57
Maildir #43
POP3 #207

I propose to change the config this way:
global-settings

[backend-name.account-name]
account-settings

The fact to prefix the account with a backend allow us to have different APIs of account settings (one per backend). Plus it will match well with the toml to rust deserialization.
To avoid breaking changes, we can consider that the default backend (if no prefix given) is the IMAP one. But it could be nice to deprecate such implicit usage. To show a warning to those users, we will need https://github.com/soywod/himalaya/pull/293.

Hi! For me as a user, the following scheme would be more logical
global-settings

[account.name]
backend = "<backend>"

It is what I thought first, but it is gonna be a pain to deserialize. Rust treats [account] section as a hash map, so you can have only one type of values. Backends will have different properties, so it is hardly compatible :disappointed:

That's absolutely no problem with serdes features (untagged enums):
#[derive(serde::Deserialize)]
#[serde(untagged)]
enum Account {
    Imap(ImapAccount),
    Notmuch(NotmuchAccount)
    // ...
}

Or even better with adjacently-tagged enums, for example:
#[derive(serde::Deserialize)]
#[serde(tag = "backend", content = "configuration")]
enum Account {
    Imap(ImapAccount),
    Notmuch(NotmuchAccount)
    // ...
}

Oh, that's great! I did not know about these serde features. I will give a shot and propose a PR to switch to the new model. Then we will be able to do other PRs with backend implementations.

 I need to re-read again and improve it, but for now, here what I have:

I use the untagged enum over the adjacently-tagged enum because I was not able to set up a default value for the adjacently-tagged enum (feel free to propose a solution if you have), which implies a breaking change (the backend = "Imap").
The POC is backward compatible, it works straight with the previous version of the config file
I renamed the ImapService trait into Backend. So for now, the backend API is exactly the same as the IMAP, but we will need to adjust it depending on the other backend needs.

I let you know when the PR is ready for reviewing! Feel free to propose your opinion / ideas etc.

And thanks for your help :pray:

The PR is more or less ready for reviewing. Most of the changes are in account_entity and config_entity, the rest is just renaming imap into backend.

In parallel I try to think about the common backend interface. I start to write it down for later:
Common to all

connect
read mailboxes
read envelopes
search envelopes
read message
add message
add message flags
set message flags
remove message flags
disconnect

IMAP only

watch / notify

POP3 only
Notmuch only
Is there an equivalent to the IMAP idle mode?
Maildir only

Is there an equivalent to the IMAP idle mode?

No. notmuch works locally only. All you can do with notmuch (feel free to try out the notmuch commandline, it gives a good impression IMO), is searching for emails and it gives you back a list of emails. It gives you back either a list of message IDs, or a list of mails plain-text and so on. So the "Common to all">"Connect" wouldn't even be part of notmuch in a sense that it "connects" to a remote server. That would just open the database actually.
Fetching and sending mail in notmuch land is done via other mechanisms, like offlineimap, mbsync or (in my case) via muchsync, which syncs notmuch databases.

feel free to try out the notmuch commandline

I read the notmuch doc, I understand a bit better. I also plan to try the tool this week!
Here a bunch of questions:

Notmuch creates its own database from a Maildir folder, right? So in fact the Maildir backend and the Notmuch backend are kind of complementary?
How Notmuch treats mailboxes? As tags?

Here the updated table of interface:

Method
IMAP
POP
Notmuch
Maildir

connect
login
login
update the database
noop

read mailboxes
list mailboxes
list mailboxes
?
list sub-folders

read envelopes
fetch/search
list
search
search files

read message
fetch
retrieve
show
read file

add message
append
?
insert
add file

add flag
add flags
?
flag +
rename file

set flag
set flags
?
flag + --remove-all
rename file

remove flag
remove flags
?
flag -
rename file

disconnect
logout
logout
noop
noop

Notmuch does not know about "mailboxes" at all. It just gives you search over all your mails. What "show" or "search" returns, though, could be seen as a temporary mailbox!

I see. So in fact, it is sth to customize by the user!

disconnect: Closing the database would be the notmuch operation here, but this is of course only an internal thing, nothing a user knows about.

Yes of course, but all this interface is internal. The public API will not include this.

There is some features that notmuch supports that are not represented here, most notably notmuch-compact for database reindexing and compacting.

This could be sth to do also in the disconnect method (controllable with an option)
Alright, thanks for these replies, I see more or less where to go. If you don't have any remark on https://github.com/soywod/himalaya/pull/296/files I will merge it and then start to develop the interface.

I almost finished the Maildir backend. I still need to adjust the trait, I noticed some difference between IMAP and Maildir that are not really compatible. Then we will be able to set up Notmuch!

It was more complicated than expected. First, I had hard time to figure out how to design the architecture (and also how to implement it, I did a lot of experimentations). Then, while implementing the Maildir backend with the maildir crate, I noticed that the lib missed some Maildir++ features, I needed to send a PR (which has been merged quickly https://github.com/staktrace/maildir/pull/27). Here so far the final Backend trait:
pub trait Backend<'a> {
    fn connect(&mut self) -> Result<()> {
        Ok(())
    }

    fn add_mbox(&mut self, mbox: &str) -> Result<()>;
    fn get_mboxes(&mut self) -> Result<Box<dyn Mboxes>>;
    fn del_mbox(&mut self, mbox: &str) -> Result<()>;
    fn get_envelopes(
        &mut self,
        mbox: &str,
        sort: &str,
        filter: &str,
        page_size: usize,
        page: usize,
    ) -> Result<Box<dyn Envelopes>>;
    fn add_msg(&mut self, mbox: &str, msg: &[u8], flags: &str) -> Result<Box<dyn ToString>>;
    fn get_msg(&mut self, mbox: &str, id: &str) -> Result<Msg>;
    fn copy_msg(&mut self, mbox_src: &str, mbox_dst: &str, ids: &str) -> Result<()>;
    fn move_msg(&mut self, mbox_src: &str, mbox_dst: &str, ids: &str) -> Result<()>;
    fn del_msg(&mut self, mbox: &str, ids: &str) -> Result<()>;
    fn add_flags(&mut self, mbox: &str, ids: &str, flags: &str) -> Result<()>;
    fn set_flags(&mut self, mbox: &str, ids: &str, flags: &str) -> Result<()>;
    fn del_flags(&mut self, mbox: &str, ids: &str, flags: &str) -> Result<()>;

    fn disconnect(&mut self) -> Result<()> {
        Ok(())
    }
}

get_mboxes and get_envelopes return a trait object, which allow us to have different mbox and envelope types for each backend implementation. However, get_msg is a concrete type, because no matter the backend it will always be parsed from the raw data.
Here the PR https://github.com/soywod/himalaya/pull/299, feel free to comment. I will merge it soon!

The Maildir feature has been merged on master :tada:, the next one is Notmuch :wink:

It is basically the same as with any other library outside of the rust ecosystem (think openssl): It has to be installed on the target system. So when a user uses their package manager to install your software, the package must depend on openssl (or libnotmuch in this case).

I see. So it is sth to explain well in the doc. I will start the backend very soon and let you know!

IMO Ids shouldn't be user visible. They should be used internally for searching for mails that a user flagged for example, for internal optimizations and such, but not be visible to users. A user does not have to know the ID of a message.

But it is a CLI, and an id is the only thing a user can get to select a specific email. But what you say joins what I think, internal ids should not be visible. A mapping is still necessary IMO, otherwise how can you select read/copy/move/delete a specific email in a CLI mode?

yes, internally it is relevant. It can be a pub struct MailId(String), tho, right? :smile:

So far what I have with the Notmuch backend:

get_mboxes lists virtual mailboxes present in the config file (I introduced a new account entry mailboxes: HashMap<String, String> that are used for aliasing mailbox names, but it can be used as virtual mailboxes with the Notmuch backend by giving queries — for eg. inbox = "tag:inbox")
get_envelopes lists envelopes found in the given virtual mailbox (inbox by default)
find_envelopes lists envelopes found in the given query
get_msg reads the message found with the given id

I'm a bit stuck with the xxx_flags methods, because I'm not sure which method to call on the crate notmuch-rs. The most relevant one I found is https://docs.rs/notmuch/0.7.1/notmuch/struct.Query.html#method.add_tag_exclude, can you confirm?

I didn't even know that notmuch has such an API

Yes, you have a --format=json to print a full JSON string (like himalaya in fact).

This is the way. CI is cheap, developing against a JSON API is not

I agree. Thank you!

Do you think I should also put IMAP and Maildir as features (enabled by default)? This way, someone who wants to use Himalaya only with Maildir could have a smaller executable.

Yes, I think it is a good idea.

I created a dedicated issue for this, it looks bigger as expected https://github.com/soywod/himalaya/issues/318.
I just released the v0.5.7 with an experimental implementation of the Notmuch backend. For now the only way to have it is to compile himalaya sources with cargo and with the --features notmuch. I will push the new doc very soon.

All features have been merged into master, I just released the v0.5.8. Thank you for your precious help! If you find any bug or request feel free to ask.


fatal error LNK1181: cannot open input file 'flutter_engine.lib'

do we need to download these for linking from official repo?

Yes. I'm working on automating this, but that script isn’t in this public repository yet.

https://storage.googleapis.com/flutter_infra_release/flutter/{engine_version}/{platform_name}/{platform_name}-embedder.zip

Where engine_version is the commit hash of the engine (found in $FLUTTER_HOME/bin/internal/engine.version) and platform_name is windows-x64 or linux-x64 (macOS has a different naming scheme entirely).


Make a mock of Secret Satellite Server viewer

MMSFHub with Secret Satellite Server Viewer was released! :tada:
https://mmsf-hub.nomadblacky.dev/


php: update to 8.2.0

Build php

:beers: @BrewTestBot has triggered a merge.

:warning: @shivammathur bottle publish failed.

:beers: @BrewTestBot has triggered a merge.

:warning: @shivammathur bottle publish failed.


Correct usage of whitelist in rule

Hi,
I have a setup where users have to authenticate using their gitlab account. I use a group token so that all users from that group can login. Now I want to make a subpath accessible only for a single user of that group via a mail address. Following my understanding of the docs I added the following to the config:
rule.myrule.action = auth
rule.myrule.rule = Host(`example.org`) && PathPrefix(`/static/private`)
rule.myrule.whitelist =<EMAIL_ADDRESS>
This should make the rule available only for the user<EMAIL_ADDRESS>However, when I try to access example.org/static/private/index.html I can login with a mail address<EMAIL_ADDRESS>and I am still being forwarded successfully to the "private" page. So it seems I did the configuration wrong or the whitelist is not serving its purpose. The logs suggest that the rule is used successfully:
traefik-forward-auth    | time="2021-05-26T19:03:42Z" level=debug msg="Authenticating request" cookies="[_forward_auth=DF-e5KkUC_****************-5g=|1622099022|]" handler=Auth host=example.org method=GET proto=https rule=myrule
 source_ip=******* uri=/static/private/index.html
traefik-forward-auth    | time="2021-05-26T19:03:42Z" level=debug msg="Allowing valid request" handler=Auth host=example.org method=GET proto=https rule=myrule source_ip=<IP_ADDRESS> uri=/static/private/index.html

What is going wrong here?
EDIT
When looking at the requests in the logs I don't see any username or mail address. Shouldn't that be requested using the user endpoint? I have set
providers.generic-oauth.user-url = https://gitlab.example1.org/api/v4/users/

but I see no request happening with that url at all. Is the mail address supposed to be in the cookie above or where is the traefik-forward-auth supposed to get that address from? On gitlab site, my email address is public.

That's odd, can you post your full traefik-forward-auth config file and swarm/kubernetes config?

Sure, this is essentially my (anonymized) traefik-forward-auth config:
secret = xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
providers.google.client-id = dummy
providers.google.client-secret = dummy
default-provider = generic-oauth
providers.generic-oauth.auth-url = https://gitlab.example.org/oauth/authorize
providers.generic-oauth.token-url = https://gitlab.example.org/oauth/token
providers.generic-oauth.user-url = https://gitlab.example.org/api/v4/users/
providers.generic-oauth.client-id = 0a359e03e0cc807beafxxxxxxxxxxxxxxxxx7d6d00306f8f687ec92165c9740c
providers.generic-oauth.client-secret = fc77e2041afefb6xxxxxxxxxxxxxxxxxx8c9f7ab450242da77ad217a5bdf9d63
insecure-cookie = false
cookie-domain = mysite.example.org
log-level = debug
rule.myrule.action = auth
rule.myrule.rule = Host(`mysite.example.org`) && PathPrefix(`/static/org/private`)
rule.myrule.whitelist =<EMAIL_ADDRESS>
Everyone from the gitlab group should be able to access mysite.example.org but mysite.example.org/static/org/private subpaths sould be only available to me (allow@example.org).
The corresponding minimal docker-compose file:
services:
  reverse-proxy:
    image: traefik:v2.4
    container_name: "traefik"
    command:
      - "--api=true"
      - "--api.dashboard=true"
      - "--log.level=DEBUG"
      - "--providers.docker=true"
      - "--providers.docker.exposedbydefault=false"
      - "--providers.docker.network=web"
      - "--providers.file.directory=/etc/traefik/dynamic_conf"
      - "--providers.file.watch=true"
      - "--entrypoints.web.address=:80"
      - "--entrypoints.web.http.redirections.entryPoint.to=websecure"
      - "--entrypoints.web.http.redirections.entryPoint.scheme=https"
      - "--entrypoints.web.http.redirections.entrypoint.permanent=true"
      - "--entrypoints.websecure.address=:443"
      - "--entrypoints.websecure.http.middlewares=traefik-forward-auth"
    ports:
      - "80:80"
      - "443:443"
    volumes:
      - /var/run/docker.sock:/var/run/docker.sock
      - /etc/ssl/private/:/certs/:ro
      - ./traefik_dyn.yml:/etc/traefik/dynamic_conf/conf.yml:ro
    labels:
      - "traefik.enable=true"
      - "traefik.http.routers.traefik.rule=Host(`mysite.example.org`) && (PathPrefix(`/api`) || PathPrefix(`/dashboard`))"
      - "traefik.http.routers.traefik.service=api@internal"
      - "traefik.http.routers.traefik.entrypoints=websecure"
      - "traefik.http.routers.traefik.tls=true"
    networks:
      - "web"
    restart: unless-stopped

  traefik-forward-auth:
    image: thomseddon/traefik-forward-auth:2.2.0
    container_name: "traefik-forward-auth"
    secrets:
      - credentials
    environment:
      CONFIG: /run/secrets/credentials
    labels:
      - "traefik.enable=true"
      - "traefik.http.routers.traefik-forward-auth.rule=PathPrefix(`/_oauth`)"
      - "traefik.http.routers.traefik-forward-auth.entrypoints=websecure"
      - "traefik.http.routers.traefik-forward-auth.tls=true"
      - "traefik.http.middlewares.traefik-forward-auth.forwardauth.address=http://traefik-forward-auth:4181"
      - "traefik.http.middlewares.traefik-forward-auth.forwardauth.authResponseHeaders=X-Forwarded-User"
      - "traefik.http.services.traefik-forward-auth.loadbalancer.server.port=4181"
    networks:
      - "web"
    restart: unless-stopped

  nginx:
    image: nginx:alpine
    container_name: "nginx"
    restart: unless-stopped
    labels:
      - "traefik.enable=true"
      - "traefik.http.routers.nginx.rule=(Host(`mysite.example.org`) && Path(`/`)) || (Host(`mysite.example.org`) && PathPrefix(`/static`))"
      - "traefik.http.routers.nginx.entrypoints=websecure"
      - "traefik.http.routers.nginx.middlewares=add-context"
      - "traefik.http.routers.nginx.tls=true"
      - "traefik.port=80"
      - "traefik.http.middlewares.add-context.redirectregex.regex=^https:\\/\\/([^\\/]+)\\/?$$"
      - "traefik.http.middlewares.add-context.redirectregex.replacement=https://$$1/static/index.html"
      # - "traefik.http.routers.nginx.middlewares=traefik-forward-auth"
    volumes:
      - "/srv/homer:/usr/share/nginx/html/"
      - "/share/docs/:/usr/share/nginx/html/static/docs/"
      - "/share/org/:/usr/share/nginx/html/static/org/private/"
    networks:
      - "web"

secrets:
  credentials:
    name: oauth2_crededentials
    file: ./secrets/oauth.ini

networks:
  web:
    external: true

Thanks for your help!

Unfortunately I cannot find this to resolve the issue. In my config above (first post), I have the action set to auth correctly. I have the feeling that it doesn't get the mail information from the gitlab provider but I don't see why this would result in access.
Did you have time to look into this @thomseddon?


some theme fixes, sticky header(firefox)

Fixed some of the colors in the themes.
Added some more borders for looks.
Made the header sticky and changed the border collapse to make borders work properly on the sticky header. The sticky header doesn't work on chrome for now.

I found a way to make the header sticky on chrome, it created a small problem, on firefox the header rows have a slightly different height than on chrome (a solution would be to put those 2 rows into a single container but I can't since that is generated by the JS) so when you scroll, the 2 rows of the header "clip" into each other. It's easy to spot if you know about it but it's harder to spot and less distracting than the alternative of having a gap on chrome.
The other changes are all subjective, I changed the width of columns, centred the text horizontally and vertically and added borders between columns.
Personally I'm not sure about the borders but I think the alignment is better this way.
My version of the site is of course available here

I've been messing around with the column sizes and finally managed to make the columns not change size when changing the sorting. Don't ask me how though, found it by total chance.
Let me know if I missed something or something doesn't work they way it should.


NoWildcardImports excludeImports

As the conversation on the related issue https://github.com/arturbosch/detekt/issues/1468 is locked I arrogate to create a new one. 😉
We currently have the same issue with java.util.* imports.
I understand the difference between WildcardImport and NoWildcardImports (ktlint).
With the workaround described in https://github.com/arturbosch/detekt/issues/1468#issuecomment-476390151 I would loose the autoCorrect feature.
Is it possible to workaround this limitation?
Expected Behavior
Excludes and auto corrections can be used simultaniously.
Observed Behavior
These ktlint and detekt features can't be properly combined.

Steps to Reproduce
formatting:
  active: true
  android: true
  autoCorrect: true
  NoWildcardImports:
    active: true
    autoCorrect: true

style:
  active: true
  WildcardImport:
    active: true
    excludes: "**/test/**,**/androidTest/**,**/*.Test.kt,**/*.Spec.kt,**/*.Spek.kt"
    excludeImports: 'java.util.*,kotlinx.android.synthetic.*'

I would loose the autoCorrect feature.

Please note that NoWildcardImports doesn't have the autoCorrect support.
That being said, I think we can close this issue?

@cortinico You are right. I'm so dumb, noted the same thing a couple months ago. 🙈
https://github.com/arturbosch/detekt/issues/1746#issuecomment-507797897

Also found out that ktlints NoWildcardImportsRule doesn't support auto correction. The autoCorrect: true config in the detekt config was kind of misleading.


error showing undefined filter

please help I'm stuck with this for a very long time

Getting same error.........what to do in this??

const filteredPlaces = places?.filter((place)=>place.rating > rating);
use ? To check if the place exists, only you apply the filter.


Build end before XML file written

Sorry but it's one of these "non reproductible", "not everytime" bug.
After some digging, it appears that in my karma run, this plugin stop with no logs exactly at the point of writing the XML file https://github.com/karma-runner/karma-junit-reporter/blob/master/index.js#L88. I put logs and try/catch approximatively everywhere in the plugin. Nothing seems wrong, the normal way of exiting works (onExit done callback stored to be called after writing the XML) but never finish as I never enter the write callback.
It only fails about 1 time on 2 and only on the integration server with Debian. It never failed on my laptop.
As a workaround, I tried a patch switching the write file for a synchronous one and it do the job.
https://github.com/Swiip/karma-junit-reporter/tree/write-sync
Any idea is welcome.

having the same issue. karma exits with no errors and no xml file generated

We have the same issue.

Are there any updates? It is still happening.


agent_roadmap, day1, link 2 is paywalled, need alternative

Navigating the World of LLM Agents: A Beginner’s Guide by Dominik Polzer
This link needs a medium subscription. Need a similar guide but free.

@aishwaryanr

@gitgoap Please feel free to read the other resource by Deepchecks, that should be good for you to proceed to the next topics.


Segmentation fault at loading huge wallet.dat (840 MB)

its a mining wallet.
2020-12-01T22:08:00Z [123zeze] Wallet File Version = 159900
2020-12-01T22:08:00Z [123zeze] Keys: 0 plaintext, 4074 encrypted, 4074 w/ metadata, 4074 total. Unknown wallet records: 0
2020-12-01T22:08:00Z [123zeze] Wallet completed loading in           16517ms
2020-12-01T22:08:00Z init message: Rescanning...
2020-12-01T22:08:00Z [123zeze] Rescanning last 2630777 blocks (from block 5418624)...
2020-12-01T22:08:00Z [123zeze] Rescan started from block f07eb429e83d17f4cc8bc1dc0a8c81fcb3adb6f26ec07e3fd0abb7ac60fea14a...
Segmentation fault

its working after deleting hidden .lock file

valgrind --leak-check=yes src/bitcoind -regtest

https://gist.github.com/laanwj/29bc141fb8d10608651c
gdb -args ./bitcoind -datadir=/usb/bitcoin

2020-12-09T00:24:33Z [123zeze] Still rescanning. At block 6682462. Progress=0.821363
2020-12-09T00:25:24Z Potential stale tip detected, will try using extra outbound peer (last tip update: 235 seconds ago)
Segmentation fault

https://github.com/bitcoin/bitcoin/issues/11364

2020-12-09T07:32:20Z [default wallet] Still rescanning. At block 6692122. Progress=0.822019
2020-12-09T07:32:22Z Potential stale tip detected, will try using extra outbound peer (last tip update: 7370 seconds ago)
2020-12-09T07:32:29Z Potential stale tip detected, will try using extra outbound peer (last tip update: 7377 seconds ago)
2020-12-09T07:32:36Z Potential stale tip detected, will try using extra outbound peer (last tip update: 7384 seconds ago)
2020-12-09T07:32:42Z Potential stale tip detected, will try using extra outbound peer (last tip update: 7390 seconds ago)
==20484== Invalid read of size 4
==20484==    at 0x7601A6: LegacyScriptPubKeyMan::MarkUnusedAddresses(CScript const&) (scriptpubkeyman.cpp:360)
==20484==    by 0x7A8971: CWallet::AddToWalletIfInvolvingMe(std::shared_ptr<CTransaction const> const&, CWalletTx::Confirmation, bool) (wallet.cpp:1015)
==20484==    by 0x7A98A8: CWallet::SyncTransaction(std::shared_ptr<CTransaction const> const&, CWalletTx::Confirmation, bool) (wallet.cpp:1152)
==20484==    by 0x7AE4DE: CWallet::ScanForWalletTransactions(uint256 const&, int, boost::optional<int>, WalletRescanReserver const&, bool) (wallet.cpp:1791)
==20484==    by 0x7BFC5F: CWallet::Create(interfaces::Chain&, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&, std::unique_ptr<WalletDatabase, std::default_delete<WalletDatabase> >, unsigned long, bilingual_str&, std::vector<bilingual_str, std::allocator<bilingual_str> >&) (wallet.cpp:4068)
==20484==    by 0x6AD9E6: LoadWallets(interfaces::Chain&) (load.cpp:108)
==20484==    by 0x6586F8: interfaces::(anonymous namespace)::WalletClientImpl::load() (wallet.cpp:510)
==20484==    by 0x1607D0: AppInitMain(util::Ref const&, NodeContext&, interfaces::BlockAndHeaderTipInfo*) (init.cpp:1828)
==20484==    by 0x143B8F: AppInit(int, char**) (bitcoind.cpp:142)
==20484==    by 0x14420C: main (bitcoind.cpp:172)
==20484==  Address 0x4 is not stack'd, malloc'd or (recently) free'd
==20484==
==20484==
==20484== Process terminating with default action of signal 11 (SIGSEGV)
==20484==  Access not within mapped region at address 0x4
==20484==    at 0x7601A6: LegacyScriptPubKeyMan::MarkUnusedAddresses(CScript const&) (scriptpubkeyman.cpp:360)
==20484==    by 0x7A8971: CWallet::AddToWalletIfInvolvingMe(std::shared_ptr<CTransaction const> const&, CWalletTx::Confirmation, bool) (wallet.cpp:1015)
==20484==    by 0x7A98A8: CWallet::SyncTransaction(std::shared_ptr<CTransaction const> const&, CWalletTx::Confirmation, bool) (wallet.cpp:1152)
==20484==    by 0x7AE4DE: CWallet::ScanForWalletTransactions(uint256 const&, int, boost::optional<int>, WalletRescanReserver const&, bool) (wallet.cpp:1791)
==20484==    by 0x7BFC5F: CWallet::Create(interfaces::Chain&, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&, std::unique_ptr<WalletDatabase, std::default_delete<WalletDatabase> >, unsigned long, bilingual_str&, std::vector<bilingual_str, std::allocator<bilingual_str> >&) (wallet.cpp:4068)
==20484==    by 0x6AD9E6: LoadWallets(interfaces::Chain&) (load.cpp:108)
==20484==    by 0x6586F8: interfaces::(anonymous namespace)::WalletClientImpl::load() (wallet.cpp:510)
==20484==    by 0x1607D0: AppInitMain(util::Ref const&, NodeContext&, interfaces::BlockAndHeaderTipInfo*) (init.cpp:1828)
==20484==    by 0x143B8F: AppInit(int, char**) (bitcoind.cpp:142)
==20484==    by 0x14420C: main (bitcoind.cpp:172)
==20484==  If you believe this happened as a result of a stack
==20484==  overflow in your program's main thread (unlikely but
==20484==  possible), you can try to increase the size of the
==20484==  main thread stack using the --main-stacksize= flag.
==20484==  The main thread stack size used in this run was 8388608.
==20484==
==20484== HEAP SUMMARY:
==20484==     in use at exit: 2,412,091,610 bytes in 16,469,401 blocks
==20484==   total heap usage: 45,389,782 allocs, 28,920,381 frees, 5,737,517,394 bytes allocated
==20484==
==20484== LEAK SUMMARY:
==20484==    definitely lost: 9,890,832 bytes in 81,251 blocks
==20484==    indirectly lost: 128 bytes in 1 blocks
==20484==      possibly lost: 13,167,920 bytes in 58 blocks
==20484==    still reachable: 2,389,032,730 bytes in 16,388,091 blocks
==20484==         suppressed: 0 bytes in 0 blocks
==20484== Rerun with --leak-check=full to see details of leaked memory
==20484==
==20484== For counts of detected and suppressed errors, rerun with: -v
==20484== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 0 from 0)
Segmentation fault

same
2020-12-10T01:38:38Z [default wallet] Still rescanning. At block 6691257. Progress=0.820635
2020-12-10T01:39:38Z [default wallet] Still rescanning. At block 6691605. Progress=0.820675
2020-12-10T01:40:38Z [default wallet] Still rescanning. At block 6691952. Progress=0.820714
==29338== Invalid read of size 4
==29338==    at 0x760188: LegacyScriptPubKeyMan::MarkUnusedAddresses(CScript const&) (scriptpubkeyman.cpp:360)
==29338==    by 0x7A8953: CWallet::AddToWalletIfInvolvingMe(std::shared_ptr<CTransaction const> const&, CWalletTx::Confirmation, bool) (wallet.cpp:1015)
==29338==    by 0x7A988A: CWallet::SyncTransaction(std::shared_ptr<CTransaction const> const&, CWalletTx::Confirmation, bool) (wallet.cpp:1152)
==29338==    by 0x7AE4C0: CWallet::ScanForWalletTransactions(uint256 const&, int, boost::optional<int>, WalletRescanReserver const&, bool) (wallet.cpp:1791)
==29338==    by 0x7BFC41: CWallet::Create(interfaces::Chain&, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&, std::unique_ptr<WalletDatabase, std::default_delete<WalletDatabase> >, unsigned long, bilingual_str&, std::vector<bilingual_str, std::allocator<bilingual_str> >&) (wallet.cpp:4068)
==29338==    by 0x6AD9C8: LoadWallets(interfaces::Chain&) (load.cpp:108)
==29338==    by 0x6586DA: interfaces::(anonymous namespace)::WalletClientImpl::load() (wallet.cpp:510)
==29338==    by 0x1607D0: AppInitMain(util::Ref const&, NodeContext&, interfaces::BlockAndHeaderTipInfo*) (init.cpp:1828)
==29338==    by 0x143B8F: AppInit(int, char**) (bitcoind.cpp:142)
==29338==    by 0x14420C: main (bitcoind.cpp:172)
==29338==  Address 0x4 is not stack'd, malloc'd or (recently) free'd
==29338==
==29338==
==29338== Process terminating with default action of signal 11 (SIGSEGV)
==29338==  Access not within mapped region at address 0x4
==29338==    at 0x760188: LegacyScriptPubKeyMan::MarkUnusedAddresses(CScript const&) (scriptpubkeyman.cpp:360)
==29338==    by 0x7A8953: CWallet::AddToWalletIfInvolvingMe(std::shared_ptr<CTransaction const> const&, CWalletTx::Confirmation, bool) (wallet.cpp:1015)
==29338==    by 0x7A988A: CWallet::SyncTransaction(std::shared_ptr<CTransaction const> const&, CWalletTx::Confirmation, bool) (wallet.cpp:1152)
==29338==    by 0x7AE4C0: CWallet::ScanForWalletTransactions(uint256 const&, int, boost::optional<int>, WalletRescanReserver const&, bool) (wallet.cpp:1791)
==29338==    by 0x7BFC41: CWallet::Create(interfaces::Chain&, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&, std::unique_ptr<WalletDatabase, std::default_delete<WalletDatabase> >, unsigned long, bilingual_str&, std::vector<bilingual_str, std::allocator<bilingual_str> >&) (wallet.cpp:4068)
==29338==    by 0x6AD9C8: LoadWallets(interfaces::Chain&) (load.cpp:108)
==29338==    by 0x6586DA: interfaces::(anonymous namespace)::WalletClientImpl::load() (wallet.cpp:510)
==29338==    by 0x1607D0: AppInitMain(util::Ref const&, NodeContext&, interfaces::BlockAndHeaderTipInfo*) (init.cpp:1828)
==29338==    by 0x143B8F: AppInit(int, char**) (bitcoind.cpp:142)
==29338==    by 0x14420C: main (bitcoind.cpp:172)
==29338==  If you believe this happened as a result of a stack
==29338==  overflow in your program's main thread (unlikely but
==29338==  possible), you can try to increase the size of the
==29338==  main thread stack using the --main-stacksize= flag.
==29338==  The main thread stack size used in this run was 8388608.
==29338==
==29338== HEAP SUMMARY:
==29338==     in use at exit: 2,412,090,434 bytes in 16,469,382 blocks
==29338==   total heap usage: 45,384,052 allocs, 28,914,670 frees, 5,737,316,027 bytes allocated
==29338==
==29338== LEAK SUMMARY:
==29338==    definitely lost: 9,894,456 bytes in 81,247 blocks
==29338==    indirectly lost: 0 bytes in 0 blocks
==29338==      possibly lost: 13,164,296 bytes in 62 blocks
==29338==    still reachable: 2,389,031,682 bytes in 16,388,073 blocks
==29338==         suppressed: 0 bytes in 0 blocks
==29338== Rerun with --leak-check=full to see details of leaked memory
==29338==
==29338== For counts of detected and suppressed errors, rerun with: -v
==29338== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 0 from 0)
Segmentation fault


Proposal: Include Clair ancestry name in VulnerabilityReport struct

It would be neat when POST'ing the ancestry to Clair to return the ancestry name (currently the first filtered layer digest) in the VulnerabilityReport struct, this would allow subsequent calls to GetAncestry() without needing to do the whole scan again.

PRs welcome :) thanks!


React-native integreted into existing android apk is giving crash in Asus Zenphone 5. react-native version used : 0.19

java.lang.UnsatisfiedLinkError: dlopen failed: "/data/app-lib/com.caratlane.android-1/libreactnativejni.so" has unexpected e_machine: 40
E/AndroidRuntime(31481):        at java.lang.Runtime.load(Runtime.java:333)
E/AndroidRuntime(31481):        at java.lang.System.load(System.java:512)
E/AndroidRuntime(31481):        at com.facebook.soloader.DirectorySoSource.loadLibrary(DirectorySoSource.java:63)
E/AndroidRuntime(31481):        at com.facebook.soloader.SoLoader.loadLibraryBySoName(SoLoader.java:209)
E/AndroidRuntime(31481):        at com.facebook.soloader.SoLoader.loadLibrary(SoLoader.java:178)
E/AndroidRuntime(31481):        at com.facebook.react.bridge.NativeMap.(NativeMap.java:23)
E/AndroidRuntime(31481):        at com.microsoft.codepush.react.CodePushPackage.getCurrentPackageInfo(CodePushPackage.java:72)
E/AndroidRuntime(31481):        at com.microsoft.codepush.react.CodePushPackage.getCurrentPackageFolderPath(CodePushPackage.java:91)
E/AndroidRuntime(31481):        at com.microsoft.codepush.react.CodePushPackage.getCurrentPackageBundlePath(CodePushPackage.java:101)
E/AndroidRuntime(31481):        at com.microsoft.codepush.react.CodePush.getBundleUrl(CodePush.java:140)
E/AndroidRuntime(31481):        at com.caratlane.android.Activity.HomePageActivity.onCreate(HomePageActivity.java:93)
E/AndroidRuntime(31481):        at android.app.Activity.performCreate(Activity.java:5411)
E/AndroidRuntime(31481):        at android.app.Instrumentation.callActivityOnCreate(Instrumentation.java:1087)
E/AndroidRuntime(31481):        at android.app.ActivityThread.performLaunchActivity(ActivityThread.java:2270)
E/AndroidRuntime(31481):        at android.app.ActivityThread.handleLaunchActivity(ActivityThread.java:2396)
E/AndroidRuntime(31481):        at android.app.ActivityThread.access$800(ActivityThread.java:139)
E/AndroidRuntime(31481):        at android.app.ActivityThread$H.handleMessage(ActivityThread.java:1293)
E/AndroidRuntime(31481):        at android.os.Handler.dispatchMessage(Handler.java:102)
E/AndroidRuntime(31481):        at android.os.Looper.loop(Looper.java:149)
E/AndroidRuntime(31481):        at android.app.ActivityThread.main(ActivityThread.java:5257)
E/AndroidRuntime(31481):        at java.lang.reflect.Method.invokeNative(Native Method)
E/AndroidRuntime(31481):        at java.lang.reflect.Method.invoke(Method.java:515)
E/AndroidRuntime(31481):        at com.android.internal.os.ZygoteInit$MethodAndArgsCaller.run(ZygoteInit.java:793)
E/AndroidRuntime(31481):        at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:609)
E/AndroidRuntime(31481):        at dalvik.system.NativeStart.main(Native Method)

Are you running a release build for ARM devices on an x86 device by chance? You can check this by unzipping your .apk file and checking the libs/x86 folder. It should be present and contain .so files.

I did not know Android was running on x86 devices but the Zenphone 5 is one.
https://www.asus.com/Phone/ZenFone_5_A500CG/
Chipset	Intel Atom Z2580
CPU	Dual-core 2.0 GHz
GPU	PowerVR SGX544MP2

@mkonicek Asus Zenphone 5 is x86 device. I generated 3 release builds : x86 release apk, ARM release apk and universal apk. Universal apk is giving above mentioned crash in Asus zenphone 5(x86 device).

Yeah @esutton Asus phones are powered by INTEL. x86 release apk works fine on ASUS phone. But i don't want to use split android apks. I thought universal apk should run on both "ARM" and "x86" devices.

@mkonicek  and @esutton can you suggest something. My company has fixed release date in next week. Can universal apk run on both "ARM" an "x86" platform??

The universal APK should work on x86 devices although I haven't tested it on an x86 device.
Can you try disabling the split APK builds in your build.gradle? https://github.com/facebook/react-native/blob/master/local-cli/generator-android/templates/src/app/build.gradle#L71
That way you should get only one APK, is it any different from the universal one?

@mkonicek universal apk gives crash on ASUS phone(intel powered x86 devices) . Only split apks based on CPU architecture works fine. I have already tried by disabling split apk.

@anishakd4 Are you saying the x86 APK works fine for you? In that case you can publish two APKs to the Play Store - ARM, x86. Everything should be fine then. Correct?

@mkonicek Yeah thats ok I can ship two APKs. But universal APK should work on both the platforms. We already have two Apps like facebook and messenger for my company. Now if I ship two APKs then it would mean that I will be shipping four APKs for each release. So can you confirm by trying yourself whether universal APK works in ASUS phone or not??

I agree the universal APK should work on x86 phones although I don't have an Asus phone so not sure this bug is specific to Asus. Do you know if the same issue occurs on other x86 phones by chance?
I'm swamped by several other things but long term we should either figure out how to make the universal APKs work on all phones or always build split APKs. If anyone has bandwidth to look into this that would be awesome!
@corbt I think you've run into some issues with x86 devices in the past?

@mkonicek no, I've worked with arm64 devices but not x86 (#2814). It doesn't sound to me like this bug is related, although I can't be sure.
@anishakd4 does your app have other native code/dependencies as well? If you can figure out exactly what combination of native dependencies causes this issue, that may help. Is it possible to reproduce with an emulator?

Ah OK, thanks for looking @corbt!

need this for help too, @corbt

@corbt and @mkonicek I created a basic app as mentioned in react-native getting started website, and it is not working in Asus Zenphone 5.

@corbt  and @mkonicek  i use I used ASUS_T00F , android 4.4.2 and it's not working.

Hmm @anishakd4 that's a bad sign. Would you mind trying to download/run the Facebook Groups app from the Play Store on your Asus Zenphone 5? That's a production Facebook app built with React Native, so that should give us an idea if the problem is a fundamental problem with the way RN for Android is currently packaged or just a misconfiguration/3rd party compatibility issue.

hi @corbt , i used ASUS_T00F , android 4.4.2 and  it's working with the Facebook Groups app, I downloaded from the Play store, and the version is <IP_ADDRESS>.78

@corbt , @devonEdison  and @mkonicek Facebook Groups app is using split apks based on CPU architecture thats why it is working. My issue is still the same that universal apk should work on x86 and arm devices both but it is not working on ASUS Zenphone 5 mobile. If you extract the Facebook Groups apk file then you will see that they are using split apks based on CPU architecture.

ok @anishakd4 that's right, I forgot that you mentioned that earlier. At least there's a workaround then (using split builds). Since neither myself nor anyone in this thread has access to a Zenphone 5, it would be good if you could figure out what needs to be changed to make universal builds work on x86, and then we can talk about merging it. Sorry that I've got nothing more concrete.

@anishakd4 Maybe this issue is related to https://commonsware.com/blog/2013/11/21/libhoudini-what-it-means-for-developers.html? x86 contain a binary translator component called Houdini which translats arm binaries to x86 binaries.
IIRC, if there are more arm libraries in your project then x86 libs - when you run your app Houdini will try to translate the arm SO files instead of loading the generated x86 build. The workaround is to add dummy x86 SO files.
https://software.intel.com/en-us/forums/android-applications-on-intel-architecture/topic/518471

@guyca , @corbt , @mkonicek and @devonEdison  if we extract an react-native universal apk then in lib folder we can see two folders "x86" and "arm" folder. Each folder is having its own .so files. I think the issue for the crash is that in case of universal apk the mobile is by default always using "arm" folder .so files rather then using "x86" folder in case of intel powererd phones. We anyone wants to see the universal apk then he can install "CaratLane" app from play store and then take out the apk file from his mobile. "CaratLane" is using react-native for its HomePage.

Hi there! This issue is being closed because it has been inactive for a while.
But don't worry, it will live on with ProductPains! Check out its new home: https://productpains.com/post/react-native/react-native-integreted-into-existing-android-apk-is-giving-crash-in-asus-zenphone-5-react-native-version-used-019
ProductPains helps the community prioritize the most important issues thanks to its voting feature.
It is easy to use - just login with GitHub. GitHub issues have voting too, nevertheless
Product Pains has been very useful in highlighting the top bugs and feature requests:
https://productpains.com/product/react-native?tab=top
Also, if this issue is a bug, please consider sending a pull request with a fix.
We're a small team and rely on the community for bug fixes of issues that don't affect fb apps.

We're having exactly the same problem described by @anishpCL. Did anyone figure out how to fix this with the "dummy x86 SO files" workaround, or you're doing split APKs?
We wanted to avoid that at all costs, just as a last resort.

I did some research on this issue today. My best guess as to underlying issue is a problem with the ARM .so files provided by React Native when translated through Houdini (the ARM to x86 translator):
10-22 18:33:41.423 16430-16430/? D/houdini: [16430] Loading library(version: <IP_ADDRESS>720 RELEASE)... successfully.
10-22 18:33:41.423 16430-16430/? D/houdini: [16430] Unsupported feature (ID:0x10600cae).
10-22 18:33:41.423 16430-16430/? D/houdini: [16430] Open Native Library /data/app-lib/com.emptyrnproject-1/libreactnativejni.so failed.

The key error message is Unsupported feature (ID:0x10600cae). I did a bit of Googling for it but could not understand what the error means. Perhaps there is some ARM feature that the compiled .so files leverage that Houdini doesn't know how to translate?
If someone else wants to investigate further, there's a straightforward way to reproduce this on a Mac without needing to get your hands on an Android x86 device:

Install the BlueStacks Android emulator. This emulator supports Houdini.
Create a new React Native project.
Remove "x86" from the abiFilters property in the build.gradle file.
Once you have the BlueStacks emulator running, you can run the project from Android Studio and it will let you choose to launch it in the BlueStacks emulator.
You will see the Houdini error message above in logs (careful, that error is only at debug level if you're filtering). You will also see these errors:

dlopen failed: "/data/app-lib/com.emptyrnproject-1/libreactnativejni.so" has unexpected e_machine: 40
com.facebook.soloader.SoLoader$WrongAbiError: APK was built for a different platform

I even tried the workaround of adding dummy x86 SO files but I got another error message in that case: java.lang.UnsatisfiedLinkError: dlopen failed: "/data/app-lib/com.emptyrnproject-1/libreactnativejni.so" is too small to be an ELF executable. Perhaps I didn't understand how to correctly perform this workaround. What I did was add an x86 folder in the APK lib folder that matches the exact files in the armeabi-v7a folder but they were all zeroed out (hence that error message). It seems when there is an x86 folder it will just try to load those .so files so I'm not sure this workaround gives us what we want. Also from the previous link, it seems that workaround forces x86 devices to load x86 libraries, which we don't want. We want the ARM libraries to get loaded through Houdini.
So for now the only workaround I can think of for this issue is to include x86 in your abiFilters. If you want to reduce the binary size you should go with split APKs. It would be nice if someone could crack that "Unsupported feature" error message as it would be nice to not have to switch to split APKs just to use React Native (as the binary size increase without split APKs is prohibitive).

I did a bit more digging. I think my suspicion from the previous comment is correct. I tried modifying the base React Native Android project to just run these lines in the MainActivity and remove all mention of ReactActivity:
SoLoader.init(this.getApplication(), false);
SoLoader.loadLibrary("reactnativejnifb");

I get the same Houdini error as before:
10-22 20:59:46.803 6048-6048/? D/houdini: [6048] Loading library(version: <IP_ADDRESS>720 RELEASE)... successfully.
10-22 20:59:46.803 6048-6048/? D/houdini: [6048] Unsupported feature (ID:0x10600cae).
10-22 20:59:46.803 6048-6048/? D/houdini: [6048] Open Native Library /data/app-lib/com.emptyrnproject-2/libreactnativejnifb.so failed.
10-22 21:06:25.713 8042-8042/? E/dalvikvm: dlopen("/data/app-lib/com.emptyrnproject-2/libreactnativejnifb.so") failed: dlopen failed: "/data/app-lib/com.emptyrnproject-2/libreactnativejnifb.so" has unexpected e_machine: 40
com.facebook.soloader.SoLoader$WrongAbiError: APK was built for a different platform

But, when I change it to SoLoader.loadLibrary("gnustl_shared"); it doesn't crash anymore. It crashes for all of the .so files included with React Native except for gnustl_shared. So I suspect there is something that's being used in those other .so files that Houdini doesn't like. I'm assuming those .so files are generated by files such as this one?

@lyahdav I have the same issues, have you fixed it?

@yanbober No I haven't had time to further investigate yet.

@lyahdav I think this is a very big bug for RN Android. level as RN not support armeabi so.

I don't entirely understand what you are saying but RN does support arm and
x86, it just doesn't support Houdini to translate from arm to x68. You can
work around this as I explained in the comments above.
On Sun, Dec 18, 2016 at 8:00 PM yanbo<EMAIL_ADDRESS>wrote:

@lyahdav https://github.com/lyahdav I think this is a very big bug for
RN Android. level as RN not support armeabi so.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/facebook/react-native/issues/5773#issuecomment-267877202,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAV69Y2e14WbXrsteOC2EvoAlj74DqKKks5rJgFjgaJpZM4HUDGq
.

OK, 3Q.

In case we would like to run react-native conditionally , so we can at least avoid crashing on these devices , is there a standard way to check whether the underlying architecture would support React or not?

Let's discuss this in the related issue that is still open.
Duplicate of #12246

Duplicate of #12246

I also have this problem with 0.51.0？Is there a solution to this problem?

@hramos   I am sorry, I also have this problem with 0.51.0? Is there a solution to this problem?


READ TIME OUT

Plugin ADB WIFI was not installed: Cannot download 'https://plugins.jetbrains.com/pluginManager/?action=download&id=com.layernet.plugin.adbwifi&build=AI-171.4249.39&uuid=5791f160-2361-4583-97bb-b77ad8c6283e': Read timed out   please resolve  it     i wait you.........

这是你自己网络有问题。

i am situation same as yours.Do you solved it?


[Issue {#25}] Add new dataset for clustering problems inside datasets folder

This PR fixes for issue #25
Changes made:

Added new clustering dataset Credit Card Customer data to datasets
Updated datasets,py with clustering class clustering() and clustering dataset class called Credit_Card_Customer_Data().

All changes were made!


Delete file command

Summary
Adding a delete file command
Type
New Feature

Merge when https://github.com/praetorian-inc/chaos/pull/998 is deployed.


Add consistent branding message.

Signed-off-by: Deshi Xiao<EMAIL_ADDRESS>

Codecov Report

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


Fix error from azdata tool upon startup

Fixes https://github.com/microsoft/azuredatastudio/issues/14556
Also fixed it so that if there are missing tools we don't prompt for EULA acceptance (since that would then break on those missing tools)
Cleaned up a bunch of unnecessary installation commands for the azdata tool as well - it's installed by the extension so no reason to duplicate all that stuff here.
Currently the experience could be made better by supporting auto-install of the extension/tool, but that would take a bunch more work to modify the existing behavior to support that so I'm just going to put that down as an enhancement to do later.

Pull Request Test Coverage Report for Build 622709836

2 of 19 (10.53%)  changed or added relevant lines in 2 files are covered.
1 unchanged line in 1 file lost coverage.
Overall coverage decreased (-0.003%) to 43.274%

Changes Missing Coverage
Covered Lines
Changed/Added Lines
%

extensions/resource-deployment/src/services/tools/azdataTool.ts
2
8
25.0%

extensions/resource-deployment/src/ui/toolsAndEulaSettingsPage.ts
0
11
0.0%

Files with Coverage Reduction
New Missed Lines
%

extensions/resource-deployment/src/ui/toolsAndEulaSettingsPage.ts
1
2.92%

Totals

Change from base Build 622703449:
-0.003%

Covered Lines:
25210

Relevant Lines:
53185

💛  - Coveralls