Release 1.0.3

Codecov Report
Attention: Patch coverage is 67.90990% with 869 lines in your changes are missing coverage. Please review.

Project coverage is 86.76%. Comparing base (d5be964) to head (0294f09).

Files
Patch %
Lines

polytope/datacube/backends/fdb.py
0.00%
173 Missing :warning:

tests/test_local_regular_grid.py
30.33%
62 Missing :warning:

...ons/datacube_mappers/mapper_types/local_regular.py
22.22%
42 Missing :warning:

tests/test_reduced_ll_grid.py
23.52%
39 Missing :warning:

...ations/datacube_mappers/mapper_types/reduced_ll.py
24.00%
38 Missing :warning:

...ormations/datacube_mappers/mapper_types/healpix.py
63.26%
36 Missing :warning:

...ormations/datacube_mappers/mapper_types/regular.py
26.66%
33 Missing :warning:

tests/test_regular_grid.py
25.00%
33 Missing :warning:

tests/test_cyclic_nearest.py
28.88%
32 Missing :warning:

...ormations/datacube_cyclic/cyclic_axis_decorator.py
79.25%
28 Missing :warning:

... and 36 more

Additional details and impacted files
@@             Coverage Diff             @@
##             main     #118       +/-   ##
===========================================
- Coverage   96.88%   86.76%   -10.13%
===========================================
  Files          40       95       +55
  Lines        5235     7329     +2094
===========================================
+ Hits         5072     6359     +1287
- Misses        163      970      +807

:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Have feedback on the report? Share it here.


Discussion for ARC-0015 - Algorand Standard for Encrypted Short Messages

Hi there.
Feel free to destroy my first ARC @ https://github.com/algorandfoundation/ARCs/pull/49/files
This one creates a standard way to encrypt a message with some metadata in a TXN note on Algorand so that only the transaction recipient can decrypt the message.
Would you like to earn Algo for each received private message / notification?
Draft implementation will follow shortly.

Draft implementation is up @ https://github.com/urtho/algosms-sdk
Am not sure if the encrypted payload should be encoded in base64. Seems a waste of space as notes are binary safe.
The example implementation now uses a binary payload.
Also, should the padding fill the note up to the max?


fix(ds-inhibit): autoload hid-playstation to avoid hook conflicts

ds-inhibit on upstream has issues with the first connect of PlayStation controllers, where the touchpads are not hooked correctly and therefore don't correctly interact with steam input. work around by using modules-load.d to autoload hid-playstation on boot.

ignore this please omg i hate


Exception on startup

ℹ Computer information

Windows build number: WIndows 10 Version 2004 (OS Build 19041.388)
PowerToys version: 0.20.0
PowerToy module: PT Run

📝 Provide detailed reproduction steps (if any)

Start PowerToys

✔ Expected result
PowerToys starts.
❌ Actual result
PowerToys FancyZones window appears displaying "Cannot install keyboard listener."
PowerToys Shortcut Guide window appears displaying "Cannot install keyboard listener."
"PT Run got an error" window appears displaying
Version: 1.0.0
OS Version: Microsoft Windows NT 10.0.19041.0
IntPtr Length: 8
x64: True
Date: 08/01/2020 14:45:43
Exception:
System.Runtime.InteropServices.SEHException (0x80004005): External component has thrown an exception.
at _CxxThrowException(Void* , _s__ThrowInfo* )
at interop.KeyboardHook.Start()
at interop.HotkeyManager..ctor()
at PowerLauncher.ViewModel.MainViewModel..ctor(Settings settings)
at PowerLauncher.App.<>c__DisplayClass16_0.b__1()
at Wox.Infrastructure.Stopwatch.Normal(String message, Action action)
at PowerLauncher.App.OnStartup(Object sender, StartupEventArgs e)
at System.Windows.Application.OnStartup(StartupEventArgs e)
at System.Windows.Application.<.ctor>b__1_0(Object unused)
at System.Windows.Threading.ExceptionWrapper.InternalRealCall(Delegate callback, Object args, Int32 numArgs)
at System.Windows.Threading.ExceptionWrapper.TryCatchWhen(Object source, Delegate callback, Object args, Int32 numArgs, Delegate catchHandler)
Log file attached:
2020-08-01.txt
There is Citrix MyDesk and Receiver installed on the computer for remote access to work. I wonder if those are somehow preventing the keyboard hook but unfortunately I cannot remove them as they are needed for work.

track in #5414


server side pull logs

Description of changes
Summarize the changes made by this PR.

Improvements & Bug fixes

...

New functionality

...

Test plan
How are these changes tested?

[ ] Tests pass locally with pytest for python, yarn test for js

Documentation Changes
Are all docstrings for user-facing APIs updated if required? Do we need to make documentation changes in the docs repository?

[!WARNING]
This pull request is not mergeable via GitHub because a downstack PR is open. Once all requirements are satisfied, merge this PR as a stack on Graphite.
Learn more

Current dependencies on/for this PR:

#1762  👈
#1749
main

This stack of pull requests is managed by Graphite.


Protocol Enumerable not implemented for nil of type Atom.

Environment
sentry version: 10.7.1
Issue
I can't quite tell what is going wrong here or what is failing because of nil. We updated to 10.7.1 to fix some of them ( #779 ), but we're still seeing these after the upgrade for this error and a couple other ones as well. If I had to take a SWAG, it's because frames is nil, due to this PR: https://github.com/getsentry/sentry-elixir/pull/775
GenServer {Sentry.Transport.SenderRegistry, 2} terminating
** (Protocol.UndefinedError) protocol Enumerable not implemented for nil of type Atom. This protocol is implemented for the following type(s):
DBConnection.PrepareStream, DBConnection.Stream, Date.Range,
Ecto.Adapters.SQL.Stream, File.Stream, Function, GenEvent.Stream,
HashDict, HashSet, IO.Stream, Iteraptor.Array, Jason.OrderedObject,
List, Map, MapSet, Phoenix.LiveView.LiveStream, Postgrex.Stream,
Range, SFTPClient.Stream, Stream, Timex.Interval
    (elixir 1.17.2) lib/enum.ex:1: Enumerable.impl_for!/1
    (elixir 1.17.2) lib/enum.ex:166: Enumerable.reduce/3
    (elixir 1.17.2) lib/enum.ex:4423: Enum.map/2
    (sentry 10.7.1) lib/sentry/client.ex:292: anonymous fn/1 in Sentry.Client.render_exception/1
    (sentry 10.7.1) lib/sentry/client.ex:360: Sentry.Client.update_if_present/3
    (elixir 1.17.2) lib/enum.ex:1703: Enum."-map/2-lists^map/1-1-"/2
    (sentry 10.7.1) lib/sentry/client.ex:360: Sentry.Client.update_if_present/3
    (sentry 10.7.1) lib/sentry/client.ex:283: Sentry.Client.render_event/1
Last message:
{:"$gen_cast",
 {:send, Sentry.HackneyClient,
  %Sentry.Event{
    event_id: "[redacted]",
    timestamp: "2024-09-10T20:51:41.598183",
    breadcrumbs: [],
    contexts: %{
      runtime: %{name: "elixir", version: "1.17.2 (compiled with Erlang/OTP 26)"},
      os: %{name: "linux", version: "4.14.318"}
    },
    dist: nil,
    environment: "prod",
    exception: [
      %Sentry.Interfaces.Exception{
        type: "Oban.TimeoutError",
        value: "Our.Oban.Worker timed out after 300000ms",
        module: nil,
        stacktrace: %Sentry.Interfaces.Stacktrace{frames: nil},
        mechanism: %Sentry.Interfaces.Exception.Mechanism{
          handled: true,
          data: nil,
          synthetic: nil,
          help_link: nil,
          meta: nil,
          type: "generic"
        }
      }
    ],
    extra: %{},
    fingerprint: ["{{ default }}"],
    level: :error,
    logger: nil,
    message: nil,
    modules: %{
      ...
    },
    platform: :elixir,
    release: "289157c",
    request: %Sentry.Interfaces.Request{
      method: nil,
      url: nil,
      query_string: nil,
      data: nil,
      cookies: nil,
      headers: nil,
      env: nil
    },
    sdk: %Sentry.Interfaces.SDK{name: "sentry-elixir", version: "10.7.1"},
    server_name: "1aa2b5ad38e6",
    tags: %{},
    transaction: nil,
    threads: nil,
    user: %{},
    integration_meta: %{},
    culprit: nil,
    attachments: [],
    source: nil,
    original_exception: %Oban.TimeoutError{
      message: "Our.Oban.Worker timed out after 300000ms",
      reason: :timeout
    }
  }}}

Actually, this may be a duplicate of https://github.com/getsentry/sentry-elixir/issues/786

@BobbyMcWho yep yep this is a duplicate of #786 and was fixed with PR #787

Okay, thanks, is master sha safe to use, or should we wait for a release?

Yes, you can try out the fix on the master branch. We'll do a release soon 💟

Hey! @savhappy I was wondering if you have a timeframe on the 10.7.2 release.
I am asking because I am weighing my options between downgrading or waiting for the new release.

@whatyouhide timeframe on this?

@savhappy @tomekowal once https://github.com/getsentry/publish/issues/4371 is addressed. @savhappy you can ping Neel and Stephanie on Discord to speed things up if needed.


Make the docker-networks.py script run as user instead of root.

As of now, the scripts spawns containers that are root by default. On the other hand, heiko's target devices don't have access to any level of elevated permissions. It would be nice to make it run as user to make simulating and perhaps testing a lot more realistic?

Can I take a look at this?

Can I take a look at this?

Yeah sure!

Yeah sure!


Add item names and sprites to recipes in readme

I hope this is what you meant with #1
Check the result in my fork

That's even better! Thanks!
I have another readme that needs translating if you're interested in doing that too. You can find that here.


Create ISSUE_TEMPLATE.md

For our issue templates I think we'd want to organize them into:

Feature request
Bug report

Lmk if I'm missing something. Would this be a bug report template?

I think we also want this in .github/ISSUE_TEMPLATE/ as BUG_REPORT.md.

And then the last thing I think we can do is rename this PR to "Create BUG_REPORT.md issue template". Otherwise thanks for helping with this!

Alright, I made the changes you requested, and made one or two more templates.

I think we might be missing some of that metadata for the others, but we can check that out as we go. Thanks! Last thing would be just renaming this PR since it looks like you're taking care of more than just the bug report template and you should get credit. I'll change it for you and merge.

Alright, I can add those last few pieces of metadata before you merge the PR


ZLibrary is no longer available

Verification

[X] I have retried my command with --force.
[X] I ran brew update-reset && brew update and retried my command.
[X] I ran brew doctor, fixed as many issues as possible and retried my command.

Description of issue
ZLibrary is no longer available
Command that failed
ZLibrary is no longer available
Output of command with --verbose --debug
ZLibrary is no longer available

Output of brew doctor and brew config
ZLibrary is no longer available

Output of brew tap
ZLibrary is no longer available

https://mp.weixin.qq.com/s/KPIMKOmECmRY5kZjdY5HXw

42eae90232eb3f413d64e0b7d72e8fd7ed794caf


Does curve-csi support curvefs?

It seems that only curvebs are supported.

https://github.com/opencurve/curvefs-csi


Lowest Common Ancestor in BST using C++

Want to do this

Impelemented Lowest Common Ancestor in BST using C
Please refer PR#480

Please refer PR #480


[CI][C++][Homebrew] Failed to detect Protobuf by ORC

Describe the bug, including details regarding any error messages, version, and platform.
ARM64 macOS 14 C++: https://github.com/apache/arrow/actions/runs/9508523884/job/26209983344#step:12:862
[25/1026] Performing configure step for 'orc_ep'
FAILED: orc_ep-prefix/src/orc_ep-stamp/orc_ep-configure /Users/runner/work/arrow/arrow/build/cpp/orc_ep-prefix/src/orc_ep-stamp/orc_ep-configure
cd /Users/runner/work/arrow/arrow/build/cpp/orc_ep-prefix/src/orc_ep-build && /opt/homebrew/Cellar/cmake/3.29.5/bin/cmake -P /Users/runner/work/arrow/arrow/build/cpp/orc_ep-prefix/src/orc_ep-stamp/orc_ep-configure-DEBUG.cmake && /opt/homebrew/Cellar/cmake/3.29.5/bin/cmake -E touch /Users/runner/work/arrow/arrow/build/cpp/orc_ep-prefix/src/orc_ep-stamp/orc_ep-configure
CMake Error at /Users/runner/work/arrow/arrow/build/cpp/orc_ep-prefix/src/orc_ep-stamp/orc_ep-configure-DEBUG.cmake:37 (message):
  Command failed: 1

   '/opt/homebrew/Cellar/cmake/3.29.5/bin/cmake' '-DCMAKE_C_COMPILER=/Applications/Xcode_15.0.1.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/cc' '-DCMAKE_CXX_COMPILER=/Applications/Xcode_15.0.1.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/c++' '-DCMAKE_AR=/Applications/Xcode_15.0.1.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/ar' '-DCMAKE_RANLIB=/Applications/Xcode_15.0.1.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/ranlib' '-DBUILD_SHARED_LIBS=OFF' '-DBUILD_STATIC_LIBS=ON' '-DBUILD_TESTING=OFF' '-DCMAKE_BUILD_TYPE=DEBUG' '-DCMAKE_CXX_FLAGS= -Qunused-arguments -fcolor-diagnostics -fPIC' '-DCMAKE_CXX_FLAGS_DEBUG=-g -Werror -O0 -ggdb -g1  -Wno-error' '-DCMAKE_CXX_FLAGS_MISIZEREL=-Os -DNDEBUG ' '-DCMAKE_CXX_FLAGS_RELEASE=-O3 -DNDEBUG -O2  ' '-DCMAKE_CXX_FLAGS_RELWITHDEBINFO=-O2 -g -DNDEBUG -ggdb  ' '-DCMAKE_CXX_STANDARD=17' '-DCMAKE_C_FLAGS= -Qunused-arguments -fPIC' '-DCMAKE_C_FLAGS_DEBUG=-g -Werror -O0 -ggdb -g1  -Wno-error' '-DCMAKE_C_FLAGS_MISIZEREL=-Os -DNDEBUG ' '-DCMAKE_C_FLAGS_RELEASE=-O3 -DNDEBUG -O2  ' '-DCMAKE_C_FLAGS_RELWITHDEBINFO=-O2 -g -DNDEBUG -ggdb  ' '-DCMAKE_EXPORT_NO_PACKAGE_REGISTRY=' '-DCMAKE_FIND_PACKAGE_NO_PACKAGE_REGISTRY=' '-DCMAKE_INSTALL_LIBDIR=lib' '-DCMAKE_OSX_SYSROOT=/Applications/Xcode_15.0.1.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX14.0.sdk' '-DCMAKE_VERBOSE_MAKEFILE=OFF' '-DCMAKE_C_COMPILER_LAUNCHER=/opt/homebrew/bin/ccache' '-DCMAKE_CXX_COMPILER_LAUNCHER=/opt/homebrew/bin/ccache' '-DCMAKE_INSTALL_PREFIX=/Users/runner/work/arrow/arrow/build/cpp/orc_ep-install' '-DSTOP_BUILD_ON_WARNING=OFF' '-DBUILD_LIBHDFSPP=OFF' '-DBUILD_JAVA=OFF' '-DBUILD_TOOLS=OFF' '-DBUILD_CPP_TESTS=OFF' '-DINSTALL_VENDORED_LIBS=OFF' '-DLZ4_HOME=/opt/homebrew/Cellar/lz4/1.9.4' '-DPROTOBUF_EXECUTABLE=/opt/homebrew/bin/protoc-27.0.0' '-DPROTOBUF_HOME=/opt/homebrew' '-DPROTOBUF_INCLUDE_DIR=/opt/homebrew/include' '/opt/homebrew/include' '/opt/homebrew/include' '/opt/homebrew/include' '/opt/homebrew/include' '/opt/homebrew/include' '/opt/homebrew/include' '/opt/homebrew/include' '/opt/homebrew/include' '/opt/homebrew/include' '/opt/homebrew/include' '/opt/homebrew/include' '/opt/homebrew/include' '/opt/homebrew/include' '/opt/homebrew/include' '/opt/homebrew/include' '/opt/homebrew/include' '/opt/homebrew/include' '/opt/homebrew/include' '/opt/homebrew/include' '/opt/homebrew/include' '/opt/homebrew/include' '/opt/homebrew/include' '/opt/homebrew/include' '/opt/homebrew/include' '/opt/homebrew/include' '/opt/homebrew/include' '/opt/homebrew/include' '/opt/homebrew/include' '/opt/homebrew/include' '/opt/homebrew/include' '/opt/homebrew/include' '/opt/homebrew/include' '/opt/homebrew/include' '/opt/homebrew/include' '/opt/homebrew/include' '/opt/homebrew/include' '/opt/homebrew/include' '/opt/homebrew/include' '/opt/homebrew/include' '/opt/homebrew/include' '/opt/homebrew/include' '/opt/homebrew/include' '/opt/homebrew/include' '/opt/homebrew/include' '/opt/homebrew/include' '/opt/homebrew/include' '/opt/homebrew/include' '/opt/homebrew/include' '/opt/homebrew/include' '/opt/homebrew/include' '/opt/homebrew/include' '/opt/homebrew/include' '/opt/homebrew/include' '/opt/homebrew/include' '/opt/homebrew/include' '/opt/homebrew/include' '/opt/homebrew/include' '/opt/homebrew/include' '/opt/homebrew/include' '/opt/homebrew/include' '/opt/homebrew/include' '/opt/homebrew/include' '/opt/homebrew/include' '/opt/homebrew/include' '/opt/homebrew/include' '/opt/homebrew/include' '/opt/homebrew/include' '/opt/homebrew/include' '/opt/homebrew/include' '/opt/homebrew/include' '/opt/homebrew/include' '/opt/homebrew/include' '/opt/homebrew/include' '/opt/homebrew/include' '/opt/homebrew/include' '/opt/homebrew/include' '/opt/homebrew/include' '/opt/homebrew/include' '/opt/homebrew/include' '/opt/homebrew/include' '/opt/homebrew/include' '/opt/homebrew/include' '/opt/homebrew/include' '/opt/homebrew/include' '/opt/homebrew/include' '/opt/homebrew/include' '/opt/homebrew/include' '/opt/homebrew/include' '/opt/homebrew/include' '/opt/homebrew/include' '/opt/homebrew/include' '/opt/homebrew/include' '/opt/homebrew/include' '/opt/homebrew/include' '/opt/homebrew/include' '/opt/homebrew/include' '/opt/homebrew/include' '/opt/homebrew/include' '/opt/homebrew/include' '/opt/homebrew/include' '/opt/homebrew/include' '/opt/homebrew/include' '/opt/homebrew/include' '/opt/homebrew/include' '/opt/homebrew/include' '/opt/homebrew/include' '/opt/homebrew/include' '/opt/homebrew/include' '/opt/homebrew/include' '/opt/homebrew/include' '/opt/homebrew/include' '/opt/homebrew/include' '/opt/homebrew/include' '/opt/homebrew/include' '/opt/homebrew/include' '/opt/homebrew/include' '/opt/homebrew/include' '/opt/homebrew/include' '/opt/homebrew/include' '/opt/homebrew/include' '/opt/homebrew/include' '/opt/homebrew/include' '/opt/homebrew/include' '/opt/homebrew/include' '/opt/homebrew/include' '/opt/homebrew/include' '/opt/homebrew/include' '/opt/homebrew/include' '/opt/homebrew/include' '/opt/homebrew/include' '/opt/homebrew/include' '/opt/homebrew/include' '/opt/homebrew/include' '/opt/homebrew/include' '/opt/homebrew/include' '/opt/homebrew/include' '/opt/homebrew/include' '/opt/homebrew/include' '/opt/homebrew/include' '/opt/homebrew/include' '/opt/homebrew/include' '/opt/homebrew/include' '/opt/homebrew/include' '/opt/homebrew/include' '/opt/homebrew/include' '/opt/homebrew/include' '/opt/homebrew/include' '/opt/homebrew/include' '/opt/homebrew/include' '/opt/homebrew/include' '/opt/homebrew/include' '/opt/homebrew/include' '/opt/homebrew/include' '/opt/homebrew/include' '/opt/homebrew/include' '/opt/homebrew/include' '/opt/homebrew/include' '/opt/homebrew/include' '/opt/homebrew/include' '/opt/homebrew/include' '/opt/homebrew/include' '-DPROTOBUF_LIBRARY=/opt/homebrew/lib/libprotobuf.27.0.0.dylib' '-DPROTOC_LIBRARY=/opt/homebrew/lib/libprotoc.27.0.0.dylib' '-DSNAPPY_HOME=/opt/homebrew' '-DSNAPPY_LIBRARY=/opt/homebrew/lib/libsnappy.1.2.1.dylib' '-DLZ4_LIBRARY=/opt/homebrew/Cellar/lz4/1.9.4/lib/liblz4.dylib' '-DLZ4_STATIC_LIB=/opt/homebrew/Cellar/lz4/1.9.4/lib/liblz4.dylib' '-DLZ4_INCLUDE_DIR=/opt/homebrew/Cellar/lz4/1.9.4/include' '-DSNAPPY_INCLUDE_DIR=/opt/homebrew/include' '-DZSTD_HOME=/opt/homebrew' '-DZSTD_INCLUDE_DIR=/opt/homebrew/include' '-DZSTD_LIBRARY=/opt/homebrew/lib/libzstd.1.5.6.dylib' '-GNinja' '-S' '/Users/runner/work/arrow/arrow/build/cpp/orc_ep-prefix/src/orc_ep' '-B' '/Users/runner/work/arrow/arrow/build/cpp/orc_ep-prefix/src/orc_ep-build'

  See also

    /Users/runner/work/arrow/arrow/build/cpp/orc_ep-prefix/src/orc_ep-stamp/orc_ep-configure-*.log

-- stdout output is:
-- The C compiler identification is AppleClang <IP_ADDRESS>00040
-- The CXX compiler identification is AppleClang <IP_ADDRESS>00040
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Check for working C compiler: /Applications/Xcode_15.0.1.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/cc - skipped
-- Detecting C compile features
-- Detecting C compile features - done
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- Check for working CXX compiler: /Applications/Xcode_15.0.1.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/c++ - skipped
-- Detecting CXX compile features
-- Detecting CXX compile features - done
-- Build type: DEBUG
-- compiler AppleClang version <IP_ADDRESS>00040
-- Disable the metrics collection
-- Performing Test ORC_CXX_HAS_CSTDINT
-- Performing Test ORC_CXX_HAS_CSTDINT - Success
-- Performing Test ORC_CXX_HAS_THREAD_LOCAL
-- Performing Test ORC_CXX_HAS_THREAD_LOCAL - Success
-- Performing Test CMAKE_HAVE_LIBC_PTHREAD
-- Performing Test CMAKE_HAVE_LIBC_PTHREAD - Success
-- Found Threads: TRUE
-- SNAPPY_HOME: /opt/homebrew
-- Found the Snappy header: /opt/homebrew/include/snappy.h
-- Found the Snappy library: /opt/homebrew/lib/libsnappy.1.2.1.dylib
-- ZSTD_HOME: /opt/homebrew
-- Found the zstd header: /opt/homebrew/include/zstd.h
-- Found the zstd library: /opt/homebrew/lib/libzstd.1.5.6.dylib
-- Found the zstd static library: /opt/homebrew/lib/libzstd.a
-- LZ4_HOME: /opt/homebrew/Cellar/lz4/1.9.4
-- Found the LZ4 header: /opt/homebrew/Cellar/lz4/1.9.4/include/lz4.h
-- Found the LZ4 library: /opt/homebrew/Cellar/lz4/1.9.4/lib/liblz4.dylib
-- Found the LZ4 static library: /opt/homebrew/Cellar/lz4/1.9.4/lib/liblz4.dylib
-- PROTOBUF_HOME: /opt/homebrew
-- ZLIB_HOME:
-- Found the ZLIB header: /Users/runner/work/arrow/arrow/build/cpp/orc_ep-prefix/src/orc_ep-build/c++/libs/thirdparty/zlib_ep-install/include/zlib.h
-- Found the ZLIB library: /Users/runner/work/arrow/arrow/build/cpp/orc_ep-prefix/src/orc_ep-build/c++/libs/thirdparty/zlib_ep-install/lib/libz.a
-- Found the ZLIB static library: /Users/runner/work/arrow/arrow/build/cpp/orc_ep-prefix/src/orc_ep-build/c++/libs/thirdparty/zlib_ep-install/lib/libz.a
-- Configuring incomplete, errors occurred!

-- stderr output is:
CMake Warning:
  Ignoring extra path from command line:

   "/opt/homebrew/include"

CMake Warning:
  Ignoring extra path from command line:

   "/opt/homebrew/include"

CMake Error at cmake_modules/FindProtobuf.cmake:115 (message):
  Could not find Protobuf.  Looked in /opt/homebrew.
Call Stack (most recent call first):
  cmake_modules/ThirdpartyToolchain.cmake:417 (find_package)
  CMakeLists.txt:166 (INCLUDE)

CMake Error at /Users/runner/work/arrow/arrow/build/cpp/orc_ep-prefix/src/orc_ep-stamp/orc_ep-configure-DEBUG.cmake:47 (message):
  Stopping after outputting logs.

Component(s)
C++, Continuous Integration

I've seen this happening also on non ARM64 jobs, example on this PR for macOS 12:
Specifically this job: https://github.com/apache/arrow/actions/runs/9579913000/job/26413390696?pr=42207#step:8:891

I have a customized version of the apache-arrow homebrew recipe that turns on substrait (apache-arrow-substrait)
I have been seeing this issue today and I couldn't figure out a workaround, so I'm going to try turning off ORC for myself (which the apache-arrow homebrew recipe currently has anyways).
Mostly commenting here since I arbitrarily linked to this issue (and that would probably seem fairly random without any context).

@wgtmac I looked at this problem and opened an issue for this: https://issues.apache.org/jira/browse/ORC-1732
Could you take a look at it?

It seems quite a lot of our verification jobs fail due to this issue :
CMake Error at cmake_modules/FindProtobuf.cmake:115 (message):
-- Found the ZLIB header: /var/folders/4z/th_0342d7sv9wl7kb3yfllq80000gn/T/arrow-HEAD.XXXXX.pGOTHd3O/cpp-build/orc_ep-prefix/src/orc_ep-build/c++/libs/thirdparty/zlib_ep-install/include/zlib.h
  Could not find Protobuf.  Looked in /usr/local.
-- Found the ZLIB library: /var/folders/4z/th_0342d7sv9wl7kb3yfllq80000gn/T/arrow-HEAD.XXXXX.pGOTHd3O/cpp-build/orc_ep-prefix/src/orc_ep-build/c++/libs/thirdparty/zlib_ep-install/lib/libz.a
Call Stack (most recent call first):
-- Found the ZLIB static library: /var/folders/4z/th_0342d7sv9wl7kb3yfllq80000gn/T/arrow-HEAD.XXXXX.pGOTHd3O/cpp-build/orc_ep-prefix/src/orc_ep-build/c++/libs/thirdparty/zlib_ep-install/lib/libz.a
  cmake_modules/ThirdpartyToolchain.cmake:417 (find_package)
-- Configuring incomplete, errors occurred!
  CMakeLists.txt:166 (INCLUDE)

verify-rc-source-cpp-macos-amd64
verify-rc-source-cpp-macos-arm64
verify-rc-source-integration-macos-amd64
verify-rc-source-integration-macos-arm64
verify-rc-source-python-macos-amd64
verify-rc-source-python-macos-arm64
verify-rc-source-ruby-macos-amd64
verify-rc-source-ruby-macos-arm64

Issue resolved by pull request 43011
https://github.com/apache/arrow/pull/43011


SHIP-0036: Part 2: Introduce securityContext for build strategy spec

Changes
This is part of the implementation of SHIP-0036: RunAs user and group for supporting steps.
This pull request introduces the securityContext on the BuildStrategy. It changes the BuildRun reconciler to set the runAsUser and runAsGroup of steps based on the build strategy's securityContext. /etc/group and /etc/passwd are mounted through downward API volumes as described in the ship.
In the Git step implementation I also added a verbose flag. This is false by default and not enabled anywhere. I needed it for additional logging during the implementation. As this can be helpful in future changes, I left it in, but can also remove it if desired.
The .ko.yaml is updated to use the new base images from part 1. The configuration was updated to have stricter security context's without privilege escalation and capabilities, and with the new shared home directory.
All sample build strategies have been updated to specify a strategy-level security context. The now unnecessary prepare steps have all been removed. The Paketo strategies are now using the Jammy builder and are proving that it is possible to run as an alternative non-root user successfully.
The change in gomega.go introduces an additional matcher. I am retaining it although the test code where I used it does not exist anymore after I refactored the solution based on feedback in the ship.
Documentation has been updated.
I am marking this as HOLD because a rollout must be coordinated with the PR SHIP-0036: Part 1: Update base images to allow an arbitrary user to run it #1268. Once both are approved, then

The HOLD will be removed from the other pull request.
A manual run of the base images build will be triggered.
The temporary commit DO NOT MERGE Use base images from other pull request will be updated to use the base images from the other PR.
The HOLD label on this PR will be removed.
After the tests finished, this PR will be merged.
All existing pull requests will need to be rebased when changes are made because the old code cannot run with the new base images.

Submitter Checklist

[x] Includes tests if functionality changed/was added
[x] Includes docs if changes are user-facing
[x] Set a kind label on this PR
[x] Release notes block has been filled in, or marked NONE

Release Notes
You can now define a securityContext on build strategy level to control the runAs user for all steps including the shipwright-managed steps. This allows you to use any runAs user for your build strategy steps while still being able to run without any runAsRoot steps.

/hold

/unhold


Sanitize urls with single quotation marks

PR Checklist
Please check all that apply to this PR using "x":

[x] I have checked that this PR is not a duplicate of an existing PR (open, closed or merged)
[ ] I have checked that this PR does not introduce a breaking change
[ ] This PR introduces breaking changes and I have provided a detailed explanation below

PR Type
What kind of change does this PR introduce?

[x] Bugfix
[ ] Feature
[ ] Code style update (formatting)
[ ] Refactoring (no functional changes)
[ ] Documentation changes
[ ] Other - Please describe:

Fixes
Does not fix anything already in an issue.
However, it does fix behavior for thumbnails whose src URLs contain single quotes.
What is the current behavior?
Thumbnail images which have URLs containing ' are broken and do not show up.
An example is as follows:
The behavior for a thumbnail URL like https://sesamestrong.github.io/lbry-desktop/google's%20logo.png is that the thumbnail does not show up; the CSS rule changes from background-image: url('https://sesamestrong.github.io/lbry-desktop/google's%20logo.png') to background-image: url((unknown)); because there is an extra ' in the URL, which breaks CSS parsing.
What is the new behavior?
The new behavior is that the CSS rule for URLs with ' has every ' in the URL replaced with \', resulting in that the thumbnail shows up.
Other information
This PR does not contain any breaking changes; however, it is possible that problems similar to this one might show up in the future. In that case, it might be desirable to add a URL sanitization utility function somewhere in the project for reuse.

@Sesamestrong, thanks for the PR! Congrats on the first one here :)
Can we show you some appreciation for the contribution?
Also, we're giving away some Hacktoberfest bonuses and goodies for this month. We'll send you the information when you reach out to us.

Thanks for telling me about the benefits! How do I reach out for the Hacktoberfest bonuses?

Great fix!


lemonbar config

Hi!
Could you please add lemonbar config seen on screenshots to the way-cooler repo?
I want to make out-of-box experience on NixOS better, and that will be the first step :)

I think you didn't delete the pre-filled issue template, you might want to edit your comment.
As to your actual question: I wasn't planning on adding it to this repo as lemonbar is not the official status bar of Way Cooler (and there eventually will be one, namely the AwesomeWM one).
However, I'll still happily upload it here so you can use it in your package.

Shell script (just the starter): bar.sh
Python script (does the dbus work): bar.py
Script requires Python 3 and pydbus.

@Timidger Thank you much!
Here's what NixOS users will get out of box after https://github.com/NixOS/nixpkgs/pull/32285 :-)

@Timidger The only issue left is that the bar sometimes appears at the center of screen instead of the top. Is it a known bug?

It's a bug I've sometimes noticed on some machines sometimes -_-.
I think it's a race condition, but I'm not sure. If you can find a nice way to reproduce it that would be excellent. One thing that might help is adding a "sleep" so that when the top bar is spawned it's after Way Cooler has fully started it and it can "catch" it as the top bar.

To add on to the previous comment: X bar support is a bit of a hack and the long term solution is to wait until Way Cooler has a dedicated bar via Awesome support

@Timidger Thanks, that does the trick! Yes, I understand, nevertheless it's good enough for temporary solution :)

@gnidorah Just a heads up I noticed there was a crazy amount of CPU usage from Way Cooler recently..and I tracked it down to the configuration I used in lemonbar. Doing a D-Bus call every milisecond is very slow. I reduced it to 1 sec on my machine, but it does feel less responsive. So that's something you might want to consider for the users of the NixOS package.


Added Kubernetes commands.

Added the useful Kubernetes commands.
Formated the docker commands.

lgtm

Thanks, Muhammad Abukar.


Locking repo exclusive failed: Resource temporarily unavailable

We try to store two (similar) images into the same OSTree repository. The thought is that we could switch between the two using OSTree (which works surprisingly well). On our CI infrastructure however it seems that this can cause race conditions when two independent bitbake instances use the same OSTREE_REPO. Maybe the do_image_ostree needs some higher level locking mechanism which makes sure the task gets exclusive access to the OSTree repo?
ERROR: torizon-core-docker-0.2.26-r0 do_image_ostree: Function failed: do_image_ostree (log file is located at /workdir/oe/tmp/work/colibri_imx7-torizon-linux-gnueabi/torizon-core-docker/0.2.26-r0/temp/log.do_image_ostree.1720)
ERROR: Logfile of failure stored in: /workdir/oe/tmp/work/colibri_imx7-torizon-linux-gnueabi/torizon-core-docker/0.2.26-r0/temp/log.do_image_ostree.1720
Log data follows:
| DEBUG: Executing python function set_image_size
| DEBUG:<PHONE_NUMBER>00 = 367020 * 2.300000
| DEBUG:<PHONE_NUMBER>00 = max(844146.000000, 65536)[844146.000000] + 2
| DEBUG:<PHONE_NUMBER>00 = int(844146.000000)
| DEBUG: 844146 = aligned(844146)
| DEBUG: returning 844146
| DEBUG: Python function set_image_size finished
| DEBUG: Executing python function extend_recipe_sysroot
| NOTE: Direct dependencies are ['/workdir/oe/build/conf/../../layers/openembedded-core/meta/recipes-core/glibc/ldconfig-native_2.12.1.bb:do_populate_sysroot', '/workdir/oe/build/conf/../../layers/meta-toradex-torizon/recipes-kernel/linux/linux-stable_git.bb:do_populate_sysroot', '/workdir/oe/build/conf/../../layers/openembedded-core/meta/recipes-devtools/quilt/quilt-native_0.65.bb:do_populate_sysroot', 'virtual:native:/workdir/oe/build/conf/../../layers/meta-updater/recipes-sota/ostree/ostree_git.bb:do_populate_sysroot', '/workdir/oe/build/conf/../../layers/openembedded-core/meta/recipes-core/glibc/cross-localedef-native_2.28.bb:do_populate_sysroot', 'virtual:native:/workdir/oe/build/conf/../../layers/openembedded-core/meta/recipes-support/lzop/lzop_1.03.bb:do_populate_sysroot', 'virtual:native:/workdir/oe/build/conf/../../layers/openembedded-core/meta/recipes-connectivity/openssl/openssl_1.1.1.bb:do_populate_sysroot', '/workdir/oe/build/conf/../../layers/openembedded-core/meta/recipes-kernel/kmod/kmod-native_git.bb:do_populate_sysroot', 'virtual:native:/workdir/oe/build/conf/../../layers/openembedded-core/meta/recipes-extended/xz/xz_5.2.4.bb:do_populate_sysroot', '/workdir/oe/build/conf/../../layers/openembedded-core/meta/recipes-kernel/kern-tools/kern-tools-native_git.bb:do_populate_sysroot', 'virtual:native:/workdir/oe/build/conf/../../layers/openembedded-core/meta/recipes-devtools/pseudo/pseudo_git.bb:do_populate_sysroot', '/workdir/oe/build/conf/../../layers/openembedded-core/meta/recipes-devtools/binutils/binutils-cross_2.31.bb:do_populate_sysroot', 'virtual:native:/workdir/oe/build/conf/../../layers/openembedded-core/meta/recipes-extended/pigz/pigz_2.4.bb:do_populate_sysroot', 'virtual:native:/workdir/oe/build/conf/../../layers/openembedded-core/meta/recipes-extended/unzip/unzip_6.0.bb:do_populate_sysroot', '/workdir/oe/build/conf/../../layers/openembedded-core/meta/recipes-devtools/gcc/gcc-cross_8.2.bb:do_populate_sysroot', '/workdir/oe/build/conf/../../layers/openembedded-core/meta/recipes-devtools/qemu/qemuwrapper-cross_1.0.bb:do_populate_sysroot', 'virtual:native:/workdir/oe/build/conf/../../layers/openembedded-core/meta/recipes-kernel/dtc/dtc_1.4.7.bb:do_populate_sysroot', 'virtual:native:/workdir/oe/build/conf/../../layers/openembedded-core/meta/recipes-core/coreutils/coreutils_8.30.bb:do_populate_sysroot', 'virtual:native:/workdir/oe/build/conf/../../layers/openembedded-core/meta/recipes-devtools/makedevs/makedevs_1.0.1.bb:do_populate_sysroot', 'virtual:native:/workdir/oe/build/conf/../../layers/openembedded-core/meta/recipes-core/util-linux/util-linux_2.32.1.bb:do_populate_sysroot', 'virtual:native:/workdir/oe/build/conf/../../layers/openembedded-core/meta/recipes-devtools/bison/bison_3.0.4.bb:do_populate_sysroot', 'virtual:native:/workdir/oe/build/conf/../../layers/openembedded-core/meta/recipes-core/update-rc.d/update-rc.d_0.8.bb:do_populate_sysroot', 'virtual:native:/workdir/oe/build/conf/../../layers/openembedded-core/meta/recipes-extended/bc/bc_1.07.1.bb:do_populate_sysroot', '/workdir/oe/build/conf/../../layers/openembedded-core/meta/recipes-kernel/kmod/depmodwrapper-cross_1.0.bb:do_populate_sysroot', 'virtual:native:/workdir/oe/build/conf/../../layers/openembedded-core/meta/recipes-devtools/opkg-utils/opkg-utils_0.3.6.bb:do_populate_sysroot', 'virtual:native:/workdir/oe/build/conf/../../layers/openembedded-core/meta/recipes-devtools/opkg/opkg_0.3.6.bb:do_populate_sysroot']
| NOTE: Installed into sysroot: ['linux-stable', 'ostree-native', 'lzop-native', 'kern-tools-native', 'binutils-cross-arm', 'unzip-native', 'gcc-cross-arm', 'coreutils-native', 'bison-native', 'bc-native', 'gobject-introspection-native', 'fuse-native', 'gpgme-native', 'libcap-native', 'dosfstools-native', 'mtools-native', 'u-boot-script-toradex', 'parted-native', 'mpfr-native', 'libmpc-native', 'gmp-native', 'linux-libc-headers', 'glibc', 'libassuan-native', 'libgpg-error-native', 'swig-native', 'gperf-native', 'gcc-runtime', 'libgcc']
| NOTE: Skipping as already exists in sysroot: ['ldconfig-native', 'quilt-native', 'cross-localedef-native', 'openssl-native', 'kmod-native', 'xz-native', 'pseudo-native', 'pigz-native', 'qemuwrapper-cross', 'dtc-native', 'makedevs-native', 'util-linux-native', 'update-rc.d-native', 'depmodwrapper-cross', 'opkg-utils-native', 'opkg-native', 'systemd-systemctl-native', 'gnu-config-native', 'libarchive-native', 'curl-native', 'glib-2.0-native', 'pkgconfig-native', 'python3-native', 'automake-native', 'autoconf-native', 'libtool-native', 'attr-native', 'e2fsprogs-native', 'shadow-native', 'lzo-native', 'zlib-native', 'gtk-doc-native', 'gettext-minimal-native', 'flex-native', 'texinfo-dummy-native', 'qemu-native', 'nss-native', 'debianutils-native', 'ncurses-native', 'readline-native', 'libsolv-native', 'libffi-native', 'bzip2-native', 'gettext-native', 'libpcre-native', 'sqlite3-native', 'gdbm-native', 'm4-native', 'alsa-lib-native', 'pixman-native', 'libusb1-native', 'nspr-native', 'ninja-native', 'cmake-native', 'rpm-native', 'expat-native', 'libpng-native', 'util-macros-native', 're2c-native', 'db-native', 'dbus-native', 'elfutils-native', 'file-native', 'popt-native']
| DEBUG: sed -e 's:^[^/]*/:/workdir/oe/tmp/work/colibri_imx7-torizon-linux-gnueabi/torizon-core-docker/0.2.26-r0/recipe-sysroot-native/:g' /workdir/oe/tmp/sysroots-components/x86_64/gcc-cross-arm/fixmepath /workdir/oe/tmp/sysroots-components/x86_64/bison-native/fixmepath /workdir/oe/tmp/sysroots-components/x86_64/gobject-introspection-native/fixmepath /workdir/oe/tmp/sysroots-components/x86_64/gpgme-native/fixmepath /workdir/oe/tmp/sysroots-components/x86_64/gmp-native/fixmepath /workdir/oe/tmp/sysroots-components/x86_64/libassuan-native/fixmepath /workdir/oe/tmp/sysroots-components/x86_64/libgpg-error-native/fixmepath | xargs sed -i -e 's:FIXMESTAGINGDIRTARGET:/workdir/oe/tmp/work/colibri_imx7-torizon-linux-gnueabi/torizon-core-docker/0.2.26-r0/recipe-sysroot:g; s:FIXMESTAGINGDIRHOST:/workdir/oe/tmp/work/colibri_imx7-torizon-linux-gnueabi/torizon-core-docker/0.2.26-r0/recipe-sysroot-native:g' -e 's:FIXME_COMPONENTS_DIR:/workdir/oe/tmp/sysroots-components:g' -e 's:FIXME_HOSTTOOLS_DIR:/workdir/oe/tmp/hosttools:g' -e 's:FIXME_PKGDATA_DIR:/workdir/oe/tmp/pkgdata/colibri-imx7:g' -e 's:FIXME_PSEUDO_LOCALSTATEDIR:/workdir/oe/tmp/work/colibri_imx7-torizon-linux-gnueabi/torizon-core-docker/0.2.26-r0/pseudo/:g' -e 's:FIXME_LOGFIFO:/workdir/oe/tmp/work/colibri_imx7-torizon-linux-gnueabi/torizon-core-docker/0.2.26-r0/temp/fifo.1720:g'
| DEBUG: Python function extend_recipe_sysroot finished
| DEBUG: Executing shell function do_image_ostree
| unknown fcntl argument 37, assuming long argument.
| unknown fcntl argument 37, assuming long argument.
| unknown fcntl argument 37, assuming long argument.
| unknown fcntl argument 37, assuming long argument.
| unknown fcntl argument 37, assuming long argument.
| 469198ac3736b9a00eb64c8b0f300b892244a705941a695c84b8a7f089408d86
| unknown fcntl argument 37, assuming long argument.
| unknown fcntl argument 37, assuming long argument.
| unknown fcntl argument 37, assuming long argument.
| unknown fcntl argument 37, assuming long argument.
| unknown fcntl argument 37, assuming long argument.
| unknown fcntl argument 37, assuming long argument.
| unknown fcntl argument 37, assuming long argument.
| unknown fcntl argument 37, assuming long argument.
| unknown fcntl argument 37, assuming long argument.
| unknown fcntl argument 37, assuming long argument.
| unknown fcntl argument 37, assuming long argument.
| unknown fcntl argument 37, assuming long argument.
| unknown fcntl argument 37, assuming long argument.
| unknown fcntl argument 37, assuming long argument.
| unknown fcntl argument 37, assuming long argument.
| unknown fcntl argument 37, assuming long argument.
| unknown fcntl argument 37, assuming long argument.
| unknown fcntl argument 37, assuming long argument.
| unknown fcntl argument 37, assuming long argument.
| unknown fcntl argument 37, assuming long argument.
| unknown fcntl argument 37, assuming long argument.
| unknown fcntl argument 37, assuming long argument.
| unknown fcntl argument 37, assuming long argument.
| unknown fcntl argument 37, assuming long argument.
| unknown fcntl argument 37, assuming long argument.
| unknown fcntl argument 37, assuming long argument.
| unknown fcntl argument 37, assuming long argument.
| unknown fcntl argument 37, assuming long argument.
| unknown fcntl argument 37, assuming long argument.
| unknown fcntl argument 37, assuming long argument.
| unknown fcntl argument 37, assuming long argument.
| error: Locking repo exclusive failed: Resource temporarily unavailable
| WARNING: exit code 1 from a shell command.
| ERROR: Function failed: do_image_ostree (log file is located at /workdir/oe/tmp/work/colibri_imx7-torizon-linux-gnueabi/torizon-core-docker/0.2.26-r0/temp/log.do_image_ostree.1720)
NOTE: recipe torizon-core-docker-0.2.26-r0: task do_image_ostree: Failed
ERROR: Task (/workdir/oe/build/conf/../../layers/meta-toradex-torizon/recipes-images/images/torizon-core-docker.bb:do_image_ostree) failed with exit code '1'
NOTE: Tasks Summary: Attempted 5476 tasks of which 4306 didn't need to be rerun and 1 failed.
NOTE: Writing buildhistory

Summary: 1 task failed:
  /workdir/oe/build/conf/../../layers/meta-toradex-torizon/recipes-images/images/torizon-core-docker.bb:do_image_ostree
Summary: There were 38 WARNING messages shown.
Summary: There was 1 ERROR message shown, returning a non-zero exit code.

@agners Interesting problem. That's not something that we normally do, so we haven't put much thought into this. It looks like ostree has internal locking mechanisms, but I can't find anything about external locking in the docs. I haven't checked the code thoroughly, though, so it's possible that there is something available. Otherwise, this would probably require some custom work, either in ostree itself or wrapped around our call to ostree commit.

@patrickvacek yeah we just bumped into that today, we are aware that this is probably not something people usually do. I thought I still create an issue so it is properly tracked.
I guess from a OSTree perspecitive everything works as expected: It is in use, so you should not use it... Its just that this is not useful behavior for the upper layer (bitbake).
In other places bitbake uses bb.utils.lockfile to lock resources which potentially are in use by multiple different bitbake processes (e.g. DL_DIR). And afaik, this blocks until the lock is available. I guess we could do the same thing in do_image_ostree. We probably try that sometime in the next few days.

I thought I still create an issue so it is properly tracked.

Yes, of course, thanks for bringing it to our attention!

In other places bitbake uses bb.utils.lockfile to lock resources which potentially are in use by multiple different bitbake processes (e.g. DL_DIR). And afaik, this blocks until the lock is available. I guess we could do the same thing in do_image_ostree. We probably try that sometime in the next few days.

Great, please let us know if you have success with that method. That seems like a reasonable way to try to address the problem.

We did found a solution:
<EMAIL_ADDRESS>Will send a pull request.

Fixed by #421 .

We had similar error message in logs on yocto sumo. This patch seems to be fixing it: https://patchwork.openembedded.org/patch/157909/

@dbalashenka note that the unknown fcntl argument 37, assuming long argument. are really not the problem here. It is the error: Locking repo exclusive failed: Resource temporarily unavailable  which is concerning.
@patrickvacek I haven't seen this issue in a long time in our infrastructure. And that despite us building nightly with pretty much the same concurrency setting. But I think we also "tuned" NFS a bit, because there were indications that the lockfile mechanism might fail if the OSTree is on a NFS. So it might be really an infrastructure issue on our end which still triggered it. From my side I am fine closing this issue. It really seems we do the right thing here and this is not a meta-updater issue. In case it reappears and we have indication its a meta-updater problem we still can reopen.

Closing since it sounds like the problem hasn't been observed in a while, and we haven't been able to reproduce it. We can reopen if necessary.


Manager: Filter to outdated toggle does not work

Is there an existing issue for this?

[X] I have searched the existing issues

Current Behavior:
When Filter to outdated is enabled no filtering occurs.

Reproduced in Maya 2024.2 and Fusion 18 - so I suppose issue is in core.
There is no logged error.
Expected Behavior:
Only the "red versioned" entries should remain listed with the filter enabled.
Version
1.0.0
What platform you are running on?
Windows
Steps To Reproduce:

Load multiple versions
Enable "Filter to outdated"

Are there any labels you wish to add?

[X] I have added the relevant labels to the bug report.

Relevant log output:
No response
Additional context:
No response

Quite important to fix it...yet over month without any progress @iLLiCiTiT


Cleanup gh-pages setup

Use the github-pages gem
Update config to updated versions
Correctly choose no layout for feed.xml

Not sure if that breaks any of your local setups, for me it fixes it (bundle exec jekyll serve works now), thus pull request ;)

:+1: for this.
I'm working on the japanese translation, but I had to manually modify Gemfile to update the gems to the latest ones, otherwise jekyll always failed to build static pages (there were a lot of errors in safe_yaml).
I'm not sure if adding github-pages gem is the best way to solve the problem either.

It's recommended by Github.

On a related note, @jhass you in the past you changed the .ruby-version to 2.2. Are you using rbenv-aliases or similar, right? Any reason to not point to 2.2.2?

The reason is I'm not using rbenv at all, both chruby and RVM are just fine with picking up the latest available release of a series with that specification. Only rbenv falls out of the line here and that by design, it's in fact the most significant reason I recommend chruby or RVM over rbenv.

Since all of I and others who are working on the japanese translation are using rbenv for the moment,  we are very grateful if you could revert the changes to make .ruby-version work out of the box. In addition, I think specifying a teeny version is better than the implicit latest version In many cases.

It was better during the 1.9 and 2.0 days, but these days, excuse my harsh words, it's just annoying. The teeny versions are really compatible between each other and I don't want to have all of them installed, it's just wasting resources. Especially for a project like this which would actually be fine without any .ruby-version file at all.
I'd recommend you to create an alias named 2.2 pointing to the latest version, see https://github.com/tpope/rbenv-aliases

Thank you for your response. I see. I'm going to try rbenv-aliases.

I hate to be interrupting with off-topic comments, but it looks like you guys are having some ruby versioning problems (I'm not terribly familiar with the ruby ecosystem), but I came across this article recently and I'll leave a link here in case it helps you guys: http://dthompson.us/ruby-on-guix.html (Heads up, before you decide to read it, afaik Guix only works in GNU Linux.)

@vyp ruby-on-guix is interesting, but it is not a standard way to manage ruby versions.
I would agree with @jhass and recommend RVM or chruby.
What about removing .ruby-version at all? I think gh-pages project does not need it to be restricted? Or am I wrong?

I'm fine adding an alias to 2.2, I just wanted to be sure why was the change.
In other than static page projects I wouldn't thou, if each dev box have their own version alias it defeats the purpose of the .ruby-version (maybe only if you use rbenv), but that's another discussion.
Removing .ruby-version might help, dunno.
Sorry to bring more things to this PR thread but they were IMO.

:+1: remove .ruby-version and PR looks good :)

@jhass Please merge if you think this is OK. The .ruby-version file doesn't bother, or can be removed if you want.

Well, I proposed it, of course I think it looks okay ;)


Train on Cub200-2011

Hi, I try training the model on CUB 200-2100.
To do this, I installed pytorch 0.4.1 and python 2.7 ( on a virtual environment of anaconda )
But it seems not to work well.
I only changed the directory of the data from the .sh file.
The intermediate results are :
Epoch: [12][160/300]	Time 0.412 (0.415)	ETA 01:40:33(00:02:04)	Loss 10.5779 (10.5851)	Prec@1 0.000 (0.440)	Prec@5 0.000 (2.264)
Epoch: [12][200/300]	Time 0.410 (0.414)	ETA 01:40:06(00:02:04)	Loss 10.5800 (10.5850)	Prec@1 0.000 (0.477)	Prec@5 0.000 (2.312)
Epoch: [12][240/300]	Time 0.410 (0.414)	ETA 01:39:42(00:02:04)	Loss 10.5862 (10.5848)	Prec@1 0.000 (0.460)	Prec@5 0.000 (2.176)
Epoch: [12][280/300]	Time 0.411 (0.413)	ETA 01:39:19(00:02:03)	Loss 10.5863 (10.5848)	Prec@1 5.000 (0.430)	Prec@5 5.000 (2.097)
The loss does not get better but stays at 10.5xxx
How can I solve this problem?
I also tried running the code on pytorch 1.0.0 and python 3.6 but, the result was the same as above.
Thanks :)

I meet the problem too,maybe the hyper-param is not good enough,have you solved this problem??

@kellenf No, I cannot solve it.

I have solve the problem,You need to change the lr->0.01 and  set a big epoch ,some code in this repo is wrong,need to do many change when use,good luck to you !

@kellenf Good! Thanks for your comment.

@FriedRonaldo I think you might need change the file 'train_frame.py', in line 80, to make "pretrained=True", since the paper said they used pretrained models in ImageNet. By this mean, my training loss decreased normally.

@FlorianLuo Thanks, I solved the problem in that way. :)


Oauth1.0 auto add parameters

It seems the auto add parameters does not refresh the nonce/timestamp, etc as expected.
When I recall a saved query, I end up having to switch to another tab (away from oauth) and back in order for those to update) before sending the request.
I am not sure if this is in the extension, but it is happening in the stand alone version

What version are you using? You'll need to check the 'Save helper data to request' box and click 'Save' to save the OAuth inputs with the request. Then if you re-load the request from the collection sidebar and send it, the timestamp and nonce are renewed.

I have "save helper data to request" checked, and every time i switch to a different saved request (all running with the same parameters) the first call fails because the oauth_timestamp is not updated until a response is received (the subsequent calls work fine).
Is the timestamp only updated when the response is received?

No, you don't even need to send the request. If a request r1 has the helper data saved, and r2 doesn't, r1's oAuth1 timestamp and nonce change as soon as you switch from r2 to r1.
When you send r2, the timestamp and nonce are updated again.
Import this collection - https://www.getpostman.com/collections/f585c83e6d768f4bb612, and try switching b/w r2 and r1. The OAuth timestamp and nonce should be updating every time you switch to r1.

You're absolutely right, if I switch to a request that has helper data saved from a request that doesn't, the timestamp is updated correctly. The moment I switch from a request that also has helper data saved, however, the timestamp no longer updates.

Got it. We'll fix this in the next release.

Great! Thanks.

As an aside, would it be possible to collapse the helper dialogs when auto-add is enabled? It's very annoying to have for example the OAuth information always visible, which requires us to scroll every time to click the "Send" button, and then scroll again to view the response. When auto-add is enabled, the window should look the same as when you have it disabled and click "Refresh request" - the OAuth information is hidden but the auth is enabled.
Then we can just click the send button over and over without the OAuth information taking up the full vertical space of the window. It's very frustrating to have something you don't need to see or modify taking up all screen space at all times.

Glad I wasn't imagining the original issue.
Agreed on the annoying scroll issue.
When is the next release planned?

On Jan 19, 2015, at 3:35 PM, Nate Bessette<EMAIL_ADDRESS>wrote:
As an aside, would it be possible to collapse the helper dialogs when auto-add is enabled? It's very annoying to have for example the OAuth information always visible, which requires us to scroll every time to click the "Send" button, and then scroll again to view the response. When auto-add is enabled, the window should look the same as when you have it disabled and click "Refresh request" - the OAuth information is hidden but the auth is enabled.
Then we can just click the send button over and over without the OAuth information taking up the full vertical space of the window. It's very frustrating to have something you don't need to see or modify taking up all screen space at all times.
—
Reply to this email directly or view it on GitHub.

We're working on a major UI revamp. The scrolling fix will be part of that.
The next release (which will fix the OAuth params not changing) will be made in a few days.


Make ReasonReactRouter.useUrl return ~serverUrl or throw

Hi, this is a really awesome library! I'm having fun re-learning OCaml and ReasonML with it.
Based on the documentation for ReasonReactRouter.useUrl:
/** hook for watching url changes.
 * serverUrl is used for ssr. it allows you to specify the url without relying on browser apis existing/working as expected
 */

This is reflected in the implementation where if the serverUrl is passed, it just returns that--otherwise, it calls into JS in order to obtain the URL (which is not possible in a server context).
In server-reason-react, useUrl returns an empty url and completely ignores serverUrl. If used in a shared component, routing silently fails and the [] gets matched every time:
module App = {
<EMAIL_ADDRESS>  let make = (~serverUrl: option(ReasonReactRouter.url)=?) => {
    let url = ReasonReactRouter.useUrl(~serverUrl?, ());
    switch (url.path) {
    | [] => <div> {React.string("Index!")} </div>
    | [name] => <Counter name />
    | _ => <div> {React.string("Not Found!")} </div>
    };
  };
};

The workaround I came up with is:
module App = {
<EMAIL_ADDRESS>  let make = (~serverUrl: option(ReasonReactRouter.url)=?) => {
    let url =
      switch%platform (Runtime.platform) {
      | Client => ReasonReactRouter.useUrl(~serverUrl?, ())
      | Server =>
        switch (serverUrl) {
        | Some(serverUrl) => serverUrl
        | None => raise(Invalid_argument("Server component needs URL!"))
        }
      };

    switch (url.path) {
    | [] => <div> {React.string("Index!")} </div>
    | [name] => <Counter name />
    | _ => <div> {React.string("Not Found!")} </div>
    };
  };
};

Alternatively, having separate implementations as suggested by the code-structure docs is another reasonable solution.
What do you think of defining useUrl as the following?
let useUrl ?(serverUrl : ReasonReactRouter.url option) (_ : unit) =
  match serverUrl with
  | Some serverUrl -> serverUrl
  | None -> raise (Invalid_argument "Must provide serverUrl")

I could also write the PR for it--would be cool as a first contribution to the ecosystem 😄

Happy to have you @purefunctor
That sounds good, useUrl with serverUrl should exactly do that. Happy to review/check a PR :D


two small changes to Path parsing (fixes #257)

Don't strip trailing /s in Path. Formerly, Root / "foo" would match
both /foo and /foo/. Now, you can/must do Root / "foo" / "" to
match the latter.
Note: this change seems likely to break user code, but did not break any existing test.
URL-decode path segments, so that it's possible to encode characters
like / and space.

This seems simple enough. Once my comment is addressed I'm fine with merging this. Its too bad that it will change the default behavior, but such is life: I like this behavior. We should probably look into making a middleware that can swallow the trailing / for those that want the old behavior, but thats another issue.
@mossprescott, thanks for the PR.

Fixed and added that pattern to the test. While I was in there testing it, I realized that Path.toString was producing confusingly unencoded results, so I fixed that as well (and added a very simple test). Hope I didn't introduce another bug.

Cool, that looks good to me. I'll give this until tomorrow to merge this to let @rossabaker weigh in if he wants. Thanks again for the PR.
As a small bit of self promotion, you may be interested in the http4s/rho project. Maybe not. :smile:


Support non-exported properties

From what I can see this addon only supports viewing the exported properties of an object.
Would it be possible to add the option to view all an objects properties including the default ones?

You can override the is_valid_property function. Or wait for me to implement this function, I had it in my plans.

Okay I was able to achieve the desired affect by doing the following:
func _update_property_list() -> void:
	if is_instance_valid(_object):
		_valid_properties = _object.get_property_list()
	else:
		_valid_properties = []

	if !show_internal:
		var counter: int = 0

		var i: int = _valid_properties.size() - 1
		while i >= 0:
			var property: Dictionary = _valid_properties[i]
			if property["usage"] == PROPERTY_USAGE_SUBGROUP or property["usage"] == PROPERTY_USAGE_GROUP:
				if counter < 1:
					_valid_properties.remove_at(i)

				counter -= 1
			elif property["usage"] == PROPERTY_USAGE_CATEGORY:
				if counter < 1:
					_valid_properties.remove_at(i)

				counter = 0
			elif not is_valid_property(property):
				_valid_properties.remove_at(i)
			else:
				counter += 1

			i -= 1
	else :
		_valid_properties.reverse()

	update_inspector()

And then exporting the show_internal variable to toggle this behaviour on or off
@export var show_internal : bool = false

@DataPlusProgram needs your testing.

Currently my project is on 4.3 once 4.4 is released I will be able to test.


can not create CDI json

What happened?
E0314 08:44:33.830924       1 cdi.go:85] CreateCDISpecForPool(): can not create CDI json: invalid CDI Spec: failed add device "0000:af:02.0": invalid device, empty device edits
E0314 08:44:33.830950       1 server.go:217] updateCDISpec(): error creating CDI spec: invalid CDI Spec: failed add device "0000:af:02.0": invalid device, empty device edits
E0314 08:44:33.830966       1 server.go:167] can't update CDI specs: invalid CDI Spec: failed add device "0000:af:02.0": invalid device, empty device edits

What did you expect to happen?
It able to create CDI json
What are the minimal steps needed to reproduce the bug?

install sriov-operator with the master branch
edit sriovoperatorconfig: added useCDI to true
create sriovnetworknodepolicy

Anything else we need to know?
Component Versions
Please fill in the below table with the version numbers of components used.

Component
Version

SR-IOV Network Device Plugin

SR-IOV CNI Plugin

Multus

Kubernetes

OS

Config Files
Config file locations may be config dependent.
Device pool config file location (Try '/etc/pcidp/config.json')
Multus config (Try '/etc/cni/multus/net.d')
CNI config (Try '/etc/cni/net.d/')
Kubernetes deployment type ( Bare Metal, Kubeadm etc.)
Kubeconfig file
SR-IOV Network Custom Resource Definition
Logs
SR-IOV Network Device Plugin Logs (use kubectl logs $PODNAME)
Multus logs (If enabled. Try '/var/log/multus.log' )
Kubelet logs (journalctl -u kubelet)

Hi @e0ne will you be able to take a look?

Hi @cyclinder is this still an issue?

closing


TP2000-826  Prevent only description deletion

TP2000-826  Prevent only description deletion
Why
When additional codes, certificates, footnotes and geo areas have only one description, TAP allows users to delete it, which results in a business rule violation.
What

Hides delete link from description tab if only one description is available
Adds DescriptionDeleteMixin, used by delete forms to prevent the only description from being deleted
Styles the cancel link as a button
Adds tests

Codecov Report
Patch coverage: 94.56% and project coverage change: +0.06 :tada:

Comparison is base (d7b02e1) 92.32% compared to head (109ae9f) 92.39%.

Additional details and impacted files
@@            Coverage Diff             @@
##           master     #881      +/-   ##
==========================================
+ Coverage   92.32%   92.39%   +0.06%
==========================================
  Files         413      413
  Lines       27807    27996     +189
  Branches     2092     2103      +11
==========================================
+ Hits        25672    25866     +194
+ Misses       1736     1734       -2
+ Partials      399      396       -3

Impacted Files
Coverage Δ

measures/models.py
98.17% <ø> (ø)

geo_areas/validators.py
70.00% <50.00%> (-30.00%)
:arrow_down:

certificates/tests/test_views.py
97.36% <80.00%> (-2.64%)
:arrow_down:

footnotes/tests/test_views.py
96.82% <80.00%> (-3.18%)
:arrow_down:

geo_areas/tests/test_views.py
98.59% <95.45%> (-1.41%)
:arrow_down:

geo_areas/forms.py
97.43% <97.77%> (+12.82%)
:arrow_up:

additional_codes/tests/test_views.py
100.00% <100.00%> (ø)

additional_codes/views.py
98.49% <100.00%> (+0.01%)
:arrow_up:

certificates/views.py
98.44% <100.00%> (+0.01%)
:arrow_up:

common/views.py
84.76% <100.00%> (+0.52%)
:arrow_up:

... and 3 more

... and 2 files with indirect coverage changes
Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here.

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


Compute CesiumSunSky time zone from longitude

The CesiumSunSky automatically gets its longitude and latitude from the CesiumGeoreference origin, ensuring that the sun position is accurate in the new Unreal coordinate system. However, we currently don't set the time zone. So a common user experience, for example in the Adding Datasets tutorial, looks like this:

CesiumGeoreference is somewhere, such as New York. The Time Zone property on the CesiumSunSky is set to -5, which is appropriate for New York. The Solar Time is set to 13, so it's about 1pm in New York, and the sun position reflects that.
The user wants to build their level in Melbourne. So maybe they add the Melbourne Photogrammetry tileset and double-click it. The tileset is visible, but upside-down because the CesiumGeoreference origin is still back in New York.
The user clicks the "Place Georeference Origin Here" button to move the origin near Melbourne.
Suddenly the scene goes completely dark. Time Zone -5 plus Solar Time 13 makes about 8AM UTC, which is about 7pm in Melbourne. It's dark there, and the CesiumSunSky accurately reflects that.

The weird thing here is that the user is required to manual enter the time zone. We inherited that from Unreal's SunSky, but there's no good reason for it when we know the longitude. Time zone isn't purely a function of longitude, of course (it's crazy complicated), but when paired with a Solar Time, longitude is really all we need. Solar Time and local time aren't the same thing anyway.
So, I think the user experience could be greatly improved by making CesiumSunSky automatically compute the time zone as a function of the longitude of the georeference origin. That way, after setting the new origin to Melbourne in the scenario above, it would be 1PM in Melbourne (roughly) rather than 1PM in New York.

I like this idea a lot. It could even mimic time settings we'd see on our computer or phone. A "set automatically" checkbox for time zone, or even solar time.
I encountered a similar user experience problem when setting up a scene in Tokyo. Everything was dark until I set the time zone correctly.


Host obtain ip and by url using DNS

# current version
Host instance = new Host("<IP_ADDRESS>", 8080);
Host instance = new Host(...);

# new features required
Host instance = new Host("www.alec1o.com:8080");

Hacks

It will use DNS to found IP from url, and for prevent block program only will start find IP when Connect (Open) thread or call function like new Host("www.alec1o.com:7777").RunDNS()

:racehorse: : It must not be implemented on Netly layer

More details about this issues be closed, can find here: https://github.com/alec1o/Byter/issues/33


The Connectivity Analyzer client does not seem to exist anymore

Basically, the docs make mention of a tool that seemingly does not exist anymore:

when I click on the highlighted link I instead land on this page where I can't find anything related to SAML testing:

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

ID: 3c01ec6a-ab66-33b1-8e6f-6437e8f4f660
Version Independent ID: 2f64f95f-9403-bc88-ac72-5ce56f9d50c3
Content: Microsoft Entra Connect: Use a SAML 2.0 Identity Provider for Single Sign On - Azure - Microsoft Entra ID
Content Source: docs/identity/hybrid/connect/how-to-connect-fed-saml-idp.md
Service: active-directory
Sub-service: hybrid
GitHub Login: @billmath
Microsoft Alias: billmath

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

@Rhywden
Thanks for bringing this to our attention.
I'm going to assign this to the document author so they can take a look at it accordingly

@billmath
Could you Please review this and update as appropriate.

It would also be great if you could include at least some pointers as to where Windows stores logs regarding login attempts because without this tool and the logs, a mere "Something went wrong" makes troubleshooting literally impossible and your own support simply says: "3rd party? Won't support!" even when it's the Windows side where the problem resides.

Thank for submitting this. I have created a work item for it and will reviewing this in the coming weeks. I am not sure what the timeline will be, so I am going to close this for now. But once I have an update I will drop it in here and let you know.
Thank you!
Bill
#please-close


Shipyard not running?

Hi,
I'm running docker natively, not through a VM such as CoreOS or using Virtualbox.
So I've run the commands, and can see the phpinfo page on http://<IP_ADDRESS>, but can't see Shipyard on http://<IP_ADDRESS>:8080?

 I am stuck, and quite the Docker newbie.


Bump the 0.5.x branch for the 1.10.1 release.

run all integration tests

run all integration tests

this is fixed in master but not backported to 0.5 branch yet

rerun all integration tests

@klueska : This commit (https://github.com/dcos/dcos-cli/pull/1088/commits/158ffb7fd288b568a2cb63d061b1c00a3bc41dc7) is some clean-up after the removal of experimental features (https://github.com/dcos/dcos-cli/pull/1079), as this targets DC/OS 1.11 we didn't plan it for backport to 0.5.


Support Crowd 2.7.x

First of all: Brilliant idea!
Next, though, Crowd 2.7.0 has been out for quite some time, and 2.7.1 has been released as well. I don't know how much work it would be to support 2.7 - I don't even know if it should just work anyway - but it would be super if support could be added.

Recently verified against Crowd 2.8.3 without problems. Locally this is easy to achieve with the Atlassian Plugin SDK.


Fix broken zopen-setup by adding a cert for objects.githubusercontent.com

This is a bit of a hacky/quick fix, we'll most likely phase zopen-setup out with the incoming zopen changes.
This fixes this issue:
Download meta into /u/mvm/zopen/boot
*ERROR* rc: 262 ***
toolkit DIAG: Service[1441793], Reason[8], Desc[Certificate validation error]

FATAL ERROR encountered [Connect]
error downloading  https://github.com/ZOSOpenTools/metaport/releases/download/boot/meta-main.20230227_023657.zos.pax.Z to /u/mvm/zopen/boot/meta-main.20230227_023657.zos.pax.Z: -1
error -1 downloading https://github.com/ZOSOpenTools/metaport/releases/download/boot/meta-main.20230227_023657.zos.pax.Z with PEM file /tmp/zopen_tmp_16842817.pem to /u/mvm/zopen/boot/meta-main.20230227_023657.zos.pax.Z
MVM:/u/mvm: >ping zosopentools.github.io
CS V2R5: Pinging host zosopentools.github.io (<IP_ADDRESS>)
Ping #1 response took 0.034 seconds. (33.949 milliseconds)

It looks like the redirect to objects.githubusercontent.com uses another ca cert. Adding it fixes the issue

Hm. ok... if this needs to stick around for more than a couple weeks maybe it would be good to see if we can just concatentate the pem files together rather than 2?

I had issues when importing a bundled certificate. I had to split them into individual certs for the gskkyman import to work. If there's a way to import a bundled cert, then yes I agree that would be better.


MINOR: Fix the outdated comments of ConfigDef

Fix the outdated comments of ConfigDef since the signature of the corresponding method has been updated.
Committer Checklist (excluded from commit message)

[ ] Verify design and implementation
[ ] Verify test coverage and CI build status
[ ] Verify documentation (including upgrade notes)

@jlprat @showuon @C0urante @dajac Could you please take a look?

@showuon All issues mentioned above have been fixed already.


Kabanero & Collection integration tests

@mtamboli
Some additional tests around lifecycle, tests 20-23
https://github.com/dacleyra/kabanero-operator/tree/addtests/tests
Do we want more of these kinds of tests?

@dacleyra I think these are good tests to add for each kabanero operator PR. We can add to the list as we come across various issues which can be added to the tests to catch problems early.

merged, closing


Improve documentation about custom tap being uninstallable on creating a custom extractor

Migrated from GitLab: https://gitlab.com/meltano/meltano/-/issues/2761
Originally created by @JazzySamarkand on 2021-05-19 17:56:05

Add pip_url solution for if a developer runs into the issue of their tap being uninstallable in their local meltano environment.

View 1 previous comment from the original issue on GitLab


FREME NER - Special characters encoding in taIdentRef URI

Sometimes entities URIs contain special characters. Such characters are encoded in the URI included in the NIF file and I’m not so sure that the encoding is correct as when I try to open the linked page, the link doesn’t work.
HTTP request
curl -X POST -H "Content-Type: " http://api-dev.freme-project.eu/current/e-entity/freme-ner/documents?input=This%20meant%20the%20Aos%20S%C3%AD%20(pronounced%20ees%20shee)%2C%20the%20'spirits'%20or%20'fairies'%2C%20could%20more%20easily%20come%20into%20our%20world%20and%20were%20particularly%20active.&informat=text&outformat=turtle&language=en&dataset=dbpedia&mode=all”

@prefix dbpedia-fr: <http://fr.dbpedia.org/resource/> .
@prefix dbc:   <http://dbpedia.org/resource/Category:> .
@prefix dbpedia-es: <http://es.dbpedia.org/resource/> .
@prefix xsd:   <http://www.w3.org/2001/XMLSchema#> .
@prefix itsrdf: <http://www.w3.org/2005/11/its/rdf#> .
@prefix dbpedia: <http://dbpedia.org/resource/> .
@prefix rdfs:  <http://www.w3.org/2000/01/rdf-schema#> .
@prefix nif:   <http://persistence.uni-leipzig.org/nlp2rdf/ontologies/nif-core#> .
@prefix dbpedia-de: <http://de.dbpedia.org/resource/> .
@prefix dbpedia-ru: <http://ru.dbpedia.org/resource/> .
@prefix freme-onto: <http://freme-project.eu/ns#> .
@prefix dbpedia-nl: <http://nl.dbpedia.org/resource/> .
@prefix dcterms: <http://purl.org/dc/terms/> .
@prefix dbpedia-it: <http://it.dbpedia.org/resource/> .

<http://freme-project.eu/#char=0,140>
        a               nif:String , nif:Context , nif:RFC5147String ;
        nif:beginIndex  "0"^^xsd:int ;
        nif:endIndex    "140"^^xsd:int ;
        nif:isString    "This meant the Aos Sí (pronounced ees shee), the 'spirits' or 'fairies', could more easily come into our world and were particularly active."^^xsd:string .

<http://freme-project.eu/#char=15,21>
        a                     nif:RFC5147String , nif:String , nif:Word , nif:Phrase ;
        nif:anchorOf          "Aos Sí"^^xsd:string ;
        nif:beginIndex        "15"^^xsd:int ;
        nif:endIndex          "21"^^xsd:int ;
        nif:referenceContext  <http://freme-project.eu/#char=0,140> ;
        itsrdf:taClassRef     <http://www.w3.org/2002/07/owl#Thing> ;
        itsrdf:taConfidence   "0.4859081423223223"^^xsd:double ;
        itsrdf:taIdentRef     <http://dbpedia.org/resource/Aos_S%25C3%25AD> .

The link http://dbpedia.org/resource/Aos_S%25C3%25AD doesn’t work. The correct encoding should be http://dbpedia.org/page/Aos_Sí

The link http://dbpedia.org/resource/Aos_S%25C3%25AD doesn’t work.

It works, only you need to decode to http://dbpedia.org/resource/Aos_Sí.

The correct encoding should be http://dbpedia.org/page/Aos_Sí

No, http://dbpedia.org/page/Aos_Sí is HTML representation of the resource, and it is "informative" resource. The http://dbpedia.org/resource/Aos_Sí is the correct resource, and that is "non-informative" resource. If you try to dereference http://dbpedia.org/resource/Aos_Sí and ask for HTML, you'll get "informative" resource describing the resource in HTML. If you ask for Turtle, you'll get "informative" resource in Turtle.
for HTML try following and look at the Location header:
curl -v http://dbpedia.org/resource/Aos_Sí -H "Accept: text/html"

for Turtle try following and look at the Location header:
curl -v http://dbpedia.org/resource/Aos_Sí -H "Accept: text/turtle"

For more on dereferencing HTTP URIs and informative and non-informative resource, read http://wifo5-03.informatik.uni-mannheim.de/bizer/pub/LinkedDataTutorial/#Terminology (section Dereferencing HTTP URIs).

Thanks for the explanation. So this is not an actual bug, is it?

IMO, not.

Ups sorry I labeled this wrong with error. I suggest to label it as invalid and close the issue.

makes sense to me.


Chart js line charts not displaying on edge

Hi, I built a website, https://wirus.live/ (not trying to advertise, I think its just the best way to see the issue) which displays line charts from Chart.js. The charts work perfectly on Chrome (and basically on all the good browsers). Unfortunately when I visit the website on Edge or IE no charts are displayed. The issue also seems to happen when I visit the website on an Ipad using Safari.
I'm sorry if this isn't an issue and just my mistake.
Thanks :)

IE11 and Edge should be supported. Perhaps the error is in another library included on the site? There's not enough detail here to tell what might be wrong. I don't have a Windows machine to test on

I think your right. I’m very sorry for bothering you. Thank you ;)


Remove wildcard support on Get-EXOCasMailbox.md

https://github.com/MicrosoftDocs/office-docs-powershell/issues/5644
Wildcard are not working on -Properties and -Propertysets parameters:

Docs Build status updates of commit 5c10318:
:clock10: Full build: the average full build time is 17 min(s) 53 sec(s), this is based on the last 1000 build(s) for this repository.

Docs Build status updates of commit 5c10318:
:white_check_mark: Validation status: passed

File
Status
Preview URL
Details

exchange/exchange-ps/exchange/Get-EXOCasMailbox.md
:white_check_mark:Succeeded
View (exchange-ps)

For more details, please refer to the build report.
Note: If you changed an existing file name or deleted a file, broken links in other files to the deleted or renamed file are listed only in the full build report.

Docs Build status updates of commit 22478d1:
:clock10: Full build: the average full build time is 17 min(s) 54 sec(s), this is based on the last 1000 build(s) for this repository.

Docs Build status updates of commit 22478d1:
:white_check_mark: Validation status: passed

File
Status
Preview URL
Details

exchange/exchange-ps/exchange/Get-EXOCasMailbox.md
:white_check_mark:Succeeded
View (exchange-ps)

For more details, please refer to the build report.
Note: If you changed an existing file name or deleted a file, broken links in other files to the deleted or renamed file are listed only in the full build report.


Place stabler RVV control fields in bits [30:12] of vtype.

Discussion had been ongoing to define an at least two bit field to handle various agnostic modes. #367
Raised but not discussed on the last call was the possibility of placing this agnostic state field in another csr.
The alternative to a different csr is that such configuration fields instead be established in bits [30:12] of vtype. Such configuration field values are expected to be of longer retention than say SEW or EDIV.
As mentioned in #396 (reserve bits for custom use), bit 11 is particularly challenging to use appropriately When negative it especially complicates bit 12 management, but also all the higher bits. I therefore propose in conjunction with this recommendation we also reserve bit 11 (or make custom).
The key idea is this:
vsetvli leaves bits [30:12] unchanged. The 11 bits in the instruction only change bits {10:0] of vtype unless an invalid combination occurs in which case vill is set and bits {11:0] are cleared.
Vsetvl will operate as previously proposed, all XLEN bits of vtype can be written. Individual fields can be WARL or WLRL and unused WPRI with most having a default of zero to align with current behaviour.
I have some further proposals that are of the same stabler nature as the agnostic modes, and I believe they also would be well addressed as upper bits in vtype.
Down side to inclusion in vtype:

unusual behaviour of vsetvli. That boat has sailed. Leaving the upper bits untouched vs set to zero is possibly unexpected, but so is much of vsetvli functionality.
use of vsetvl requires to set up the integer register (a LUI and addi would suffice) but the RVI X register read can cause a delay in the decode pipe as the value is propagated to a potentially loosely coupled processor.

Downside to new csr.

more context to save on a switch.
either a new vsetvli2 with a 12 bit immediate, or an optimized version of CSRRWI (which only supports 5 bits) is required.
[variations on 2 are possible with multiple CSRRWi writing into the same alternate vtype]. but any of these are possible with stabler control field inclusion into vtype.

And perhaps this is what Krste was meaning: a new virtual CSR that reads/writes 5 bits into specific fields (one or more) in vtype.
In any case this should be a good start for the discussion on where and how to provide stabler RVV control/status fields.

Why not put things that shouldn't be affected by vsetvli in vcsr?

Leaving upper bits unchanged, results in extra necessary prologue or epilogue in each vector enabled function.
How about using this bit 11 for selecting whether we want to clear or preserve upper bits?

@jnk0le -I like the suggestion of bit 11 use that avoids its problematic nature.
The value of bit 11 preserve/clear is highly dependent on whether these stabler settings are of high use across many algorithms/optimizations.
If the subset of all zero stabler fields is sufficiently popular or universally applicable then bit 11 clear has valuable application as a shorthand for it. We won't know until these stabler fields have  been finalized/stabilized. Bit 11 can certainly be reserved now and implemented as deferred optimization (v1.1 candidate?) However, planning now to make sane and optimal defaults for the zero cases will make the adoption of this optimization more likely, and more importantly useful. ( hacks in v1.2+ of bit 11 setting non-zero values is possible but ugly-ugly).
If vtype is considered "caller saved" then the function only need assure it sets up all of vtype for its own use, which it needs to do in the general case for the lower bits.  The burden on caller is less, as with proposed system calling convention.
I will be proposing stabler fields that could be used transparently by the function, so enhanced conventions could further avoid prologue code. As well Link Time Optimizers could ensure the high bits are compatible across function calls avoiding even the minimal prolog of a vsetvl preceded by integer constant load.
@aswaterman
I wasn't sure how to read "that shouldn't be affected by vsetvli".
On the face of it, it implies sign extended vsetvli. That in effect no stabler field (other than values all 1 or zeros) should be in vtype. So I deal with the idea of what shouldn't be affected by a sign extended vsetvli and thus why undisturbed is valuable.
Alternatively, as I may have misread it, "Allow only those fields that are appropriate for vsetvli and its primary function to set vl". This is relevant and I also discuss it below.
I agree that appropriate location choice in vector csrs is very important.
I took your advice for CLSTR.
The idea I intended is that vsetvli should not disturb settings that are valuable to preserve even though lower bits are changing. It provides a common optimization of vsetvli usage.
What should be a candidate for stabler fields in vtype and thus be used and set by vsetvl[i]?
The "vfill" field I will propose (within days , I hope) will affect vl calculation so should be in vtype.
It appears to be a good candidate for stabler. Other as yet unimagined fields are possible that also affect vl.
As for only including in vtype the "parameters" that affect vl, that ship is prepared to leave port as ediv.
As with ediv the value in placing stabler field in vtype is the practicality of its use with SEW and the rest.
Thus the proposed agnostic setting field could be appropriate as a stabler field.
So, I anticipate there will be fields that do not change vl themselves but interoperate with existing fields in vtype and interoperate with new stabler fields that would be candidates for vtype stabler.
Thus the proposal that vsetvli leave upper bits undisturbed, as a first iteration. (@jnk0le's optimization pending)

I think the actual proposal here is to change vsetvli to not modify upper bits of vtype.
I strongly disagree.
Vsetvli should retain current meaning with current encoding.  Bit 11 of immediate being zero clears the upper bits of vtype (assuming there were any).   As @jnk0le  mentions, it must be simple to establish vector configuration with a single vsetvli in common cases.
We can later choose that bit11=1 means preserve upper bits, but if/until we define upper bits in vtype, there is no need. As mentioned earlier, we might instead choose to define vtype to be a 12-bit window into some other CSR, in which case bit 11 of vsetvli immediate is fully usable and those upper bits in the other CSR are not disturbed. Note vtype was designed to not be writable except via vsetvl{I}.
This is not really essential to this proposal, but I disagree that agnostic bits are longer-lived/more-stable in general than other vsetvl bits. In particular, mask-agnostic setting can be very fine-grain, depending on length of basic-blocks in control-flow DAG.  Similarly, an inner loop might contain computation that is tail-agnostic mixed with a reduction that is not.
I'm closing this issue as current design already supports desired effects, and I'm trying to clean up issue list for 0.9.

Sounds OK to me - but I made a mistake in describing the length of the immediate. The field is only 11 bits long, The high order bit used to select between the immediate and register variants.
So bit10 would be the zero upper bit. And as you described bit10 as 1 could preserve: the functionality I wanted is available at the cost of a single bit.
The equivalent bits with another ("windowed") CSR would be 11 bits.
With the Version 0.9-draft-20200424 design, SEW and a physical register group multiplier fully determine vl.
In that I believe vlmul can be removed altogether #418, getting at least 2 of those (now) 3 bits back tips the balance in my thinking. Even with the one bit "expended" for selective clear/preserve means at least a 1 bit net gain.
There is still room in the I instruction format's 12 bit immediate field to allow a vsetvli2 that sets a different combination of fields, so all these in combination future proof the vtype/vsetvli adequately.
Thank you all for your consideration of the idea.


Add tests for ModelText

Codecov Report

Merging #12 into master will increase coverage by 0.38%.
The diff coverage is 100%.

@@            Coverage Diff             @@
##           master      #12      +/-   ##
==========================================
+ Coverage    98.8%   99.19%   +0.38%
==========================================
  Files           6        7       +1
  Lines          84      124      +40
==========================================
+ Hits           83      123      +40
  Misses          1        1

Impacted Files
Coverage Δ

client/model/text.js
100% <100%> (ø)

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 7701a41...59e2b10. Read the comment docs.


GET

every time i try to send a message i get this error
please help
GET http://<IP_ADDRESS>:8000/messages/check/?_=1516915870607 404 (Not Found)
and
POST http://<IP_ADDRESS>:8000/messages/send/ 404 (Not Found)

Closing this until there is more information.


fix: adding timeout to WakeStreamingSatellite event_from_mic to keep it from getting stuck

Why:
Right now, if you are NOT running VAD with your satellite, it can get stuck in WakeStreamingSatellite event_from_mic.
I'm running multiple satellites in Docker containers with mic / playback / satellite containers on them, no VAD. ( In fact, there is no VAD in the Docker container build, but that's a problem for tomorrow. )
What:
Added in a timeout to WakeStreamingSatellite event_from_mic based on the timeout in VadStreamingSatellite event_from_mic. I figured we should be doing about the same thing there.
The one caveat being this is based on the setting self.settings.vad.wake_word_timeout. I didn't feel like adding in a new setting. Let me know if you want that setting genericized or something.
Testing:
I've had a variant of this container running stably for about a week now. No getting stuck. 🙌

About the Docker problem, i build a really great image with everything in it: https://github.com/florian-asche/wyoming-satellite/tree/feat-add-ghr-support
I am currently working on the docker-compose file, some documentation and fine tuning. Yeah but i got stuck with the issue 237.
Is the problem you described here the same like in https://github.com/rhasspy/wyoming-satellite/issues/237?

Yeah, it is.
Basically, if you have the VAD components installed, there is a 5 second inactivity timeout by default.
Without VAD installed, there is no such timeout. So without VAD, the system can get stuck in a constantly listening state, even if everything is quiet.


Update use of Google Charts

The admin/dashboard page seems to rely on an old version of Google Charts, which uses Flash. We should update it to the current Charts tools, which is documented here.

I want to contribute to this. Where should I start?

Hi Muhammad!
So, Person Finder has a dashboard page for each repository that's supposed to show various statistics about its usage. If you have a local Person Finder running, you can find the dashboard at a path like /haiti/admin/dashboard. However, the code to generate the charts seems to depend on an old version of the Google visualization library, and parts of it use Flash, etc. Specifically, there were charts that used to show the number of records and notes as a timeline, and those charts are now broken (it appears they use a type of chart that's no longer supported).
The Django template for the dashboard page (including all the JS to generate the charts) is in app/resources/admin_dashboard.html.template, and the server-side code is in app/views/admin/dashboard.py (the server-side code probably doesn't need to change, at least not too much). The JS in the template needs to be updated to use a currently-supported chart time, probably a regular "Timeline" type. There might be other modifications that need to be made to handle other changes in the Charts library, but that's the main one I'm aware of so far.
There's also some changes that need to be made to get the dashboard page in line with the content security policy we added, but that shouldn't be a big deal. I pushed the main changes for that to a branch so you can take a look, they're here.
Let me know if you have any questions!

Actually, I didn't pay enough attention when I looked at the docs for the "Timeline" chart type, I think what we actually need is probably a linechart.

Alright, thank you for the information.

@nworden Hi Nick, I've been trying to setup the environment. But the errors related to the Python 2.7's end of support have been arising. Are there any plans to shift to Python 3. Either way, let me know if I'm missing something.