No ban or captcha

Saw the announcement https://www.crowdsec.net/blog/the-haproxy-bouncer-is-out and the docs page https://doc.crowdsec.net/docs/next/bouncers/haproxy/
Installed via crowdsec repo on Ubuntu 22.04.1 LTS (GNU/Linux 5.15.0-53-generic x86_64)
A few small changes were required to the provided files for paths etc. which have been mildly obsfuscated below.
The haproxy log (journalctl -u haproxy) log shows that "many" decisions are added.
for testing, decisions were added manually
sudo cscli decisions add -i
sudo cscli decisions add -i  -t captcha
either "decisions" show from "sudo cscli decisions list", but there is no impact to traffic.
I presume that I'm missing something quite basic, but have hit "can't see the wood for the trees"...
/etc/crowdsec/bouncers/crowdsec-haproxy-bouncer.conf
ENABLED=true
API_KEY=<deleted>
MAP_PATH=/var/lib/crowdsec/lua/haproxy/community_blocklist.map
# bounce for all type of remediation that the bouncer can receive from the local API
BOUNCING_ON_TYPE=all
# when the bouncer receive an unknown remediation, fallback to this remediation
FALLBACK_REMEDIATION=ban
MODE=stream
REQUEST_TIMEOUT=1000
# exclude the bouncing on those location
EXCLUDE_LOCATION=
# Update frequency in stream mode, in second
UPDATE_FREQUENCY=10
#those apply for "ban" action
# /!\ REDIRECT_LOCATION and BAN_TEMPLATE_PATH/RET_CODE can't be used together. REDIRECT_LOCATION take priority over RET_CODE AND BAN_TEMPLATE_PATH
BAN_TEMPLATE_PATH=/var/lib/crowdsec/lua/haproxy/templates/ban.html
REDIRECT_LOCATION=
RET_CODE=
#those apply for "captcha" action
# reCAPTCHA Secret Key
SECRET_KEY=<deleted>
# reCAPTCHA Site key
SITE_KEY=<deleted>
CAPTCHA_TEMPLATE_PATH=/var/lib/crowdsec/lua/haproxy/templates/captcha.html
CAPTCHA_EXPIRATION=3600

/etc/haproxy/haproxy.cfg
global
        log /dev/log    local0
        log /dev/log    local1 notice
        chroot /var/lib/haproxy
        stats socket /run/haproxy/admin.sock mode 660 level admin expose-fd listeners
        stats timeout 2ms
        user haproxy
        group haproxy
        daemon

# Crowdsec bouncer >>>
        lua-prepend-path /usr/lib/crowdsec/lua/haproxy/?.lua
        lua-load /usr/lib/crowdsec/lua/haproxy/crowdsec.lua
        setenv CROWDSEC_CONFIG /etc/crowdsec/bouncers/crowdsec-haproxy-bouncer.conf # path to crowdsec bouncer configuration file
# Crowdsec bouncer <<<

defaults
        log     global
        mode    http
        option  httplog
        option  dontlognull
        timeout connect 60s
        timeout client 600s
        timeout server 600s
        timeout http-keep-alive 3600s
        timeout tunnel 10m
        errorfile 400 /etc/haproxy/errors/400.http
        errorfile 403 /etc/haproxy/errors/403.http
        errorfile 408 /etc/haproxy/errors/408.http
        errorfile 500 /etc/haproxy/errors/500.http
        errorfile 502 /etc/haproxy/errors/502.http
        errorfile 503 /etc/haproxy/errors/503.http
        errorfile 504 /etc/haproxy/errors/504.http

frontend sni-front
        bind <IP_ADDRESS>:443
        mode tcp
        tcp-request inspect-delay 5s
        tcp-request content accept if { req_ssl_hello_type 1 }
        default_backend sni-back

backend sni-back
        mode tcp
        acl mc-sni req_ssl_sni -i meshcentral.domain.net
        acl gl-sni req_ssl_sni -i gitlab.domain.net
        use-server mc-SNI if mc-sni
        use-server gl-SNI if gl-sni
        server mc-SNI <IP_ADDRESS>:1443 send-proxy-v2-ssl-cn
        server gl-SNI <IP_ADDRESS>:1444 send-proxy-v2-ssl-cn

frontend mc-front-HTTPS
        mode http
        bind <IP_ADDRESS>:1443 ssl crt /etc/haproxy/host.domain.net.pem accept-proxy
        http-request set-header X-Forwarded-Proto https
        http-response set-header Strict-Transport-Security "max-age=16000000; includeSubDomains; preload;"
        option tcpka
# Crowdsec bouncer >>>
        stick-table type ip size 10k expire 30m # declare a stick table to cache captcha verifications
        http-request lua.crowdsec_allow # action to identify crowdsec remediation
        http-request track-sc0 src if { var(req.remediation) -m str "captcha-allow" } # cache captcha allow decision
        http-request redirect location %[var(req.redirect_uri)] if { var(req.remediation) -m str "captcha-allow" } # redirect to initial url
        http-request use-service lua.reply_captcha if { var(req.remediation) -m str "captcha" } # serve captcha template if remediation is captcha
        http-request use-service lua.reply_ban if { var(req.remediation) -m str "ban" } # serve ban template if remediation is ban
# Crowdsec bouncer <<<
        option forwardfor
        http-request set-header X-Forwarded-Proto https
        default_backend mc-back-HTTPS

frontend gl-front-HTTPS
        mode http
        bind <IP_ADDRESS>:1444 ssl crt /etc/haproxy/host.domain.net.pem accept-proxy
        http-request set-header X-Forwarded-Proto https
        http-response set-header Strict-Transport-Security "max-age=16000000; includeSubDomains; preload;"
        option tcpka
# Crowdsec bouncer >>>
        stick-table type ip size 10k expire 30m # declare a stick table to cache captcha verifications
        http-request lua.crowdsec_allow # action to identify crowdsec remediation
        http-request track-sc0 src if { var(req.remediation) -m str "captcha-allow" } # cache captcha allow decision
        http-request redirect location %[var(req.redirect_uri)] if { var(req.remediation) -m str "captcha-allow" } # redirect to initial url
        http-request use-service lua.reply_captcha if { var(req.remediation) -m str "captcha" } # serve captcha template if remediation is captcha
        http-request use-service lua.reply_ban if { var(req.remediation) -m str "ban" } # serve ban template if remediation is ban
# Crowdsec bouncer <<<
        option forwardfor
        http-request set-header X-Forwarded-Proto https
        default_backend gl-back-HTTPS

backend mc-back-HTTPS
        mode http
        http-request add-header X-Forwarded-Host %[req.hdr(Host)]
        option http-server-close
        server mc-01 <IP_ADDRESS>:443 ssl check port 443

backend gl-back-HTTPS
        mode http
        http-request set-header X-Forwarded-Host %[req.hdr(Host)]
        option http-server-close
        server gl-01 <IP_ADDRESS>:443 ssl check port 443

# Crowdsec bouncer >>>
# define a backend for google to allow DNS resolution if using reCAPTCHA
backend captcha_verifier
        server captcha_verifier www.google.com:443 check

# define a backend for crowdsec to allow DNS resolution
backend crowdsec
        server crowdsec <IP_ADDRESS>:8080 check
# Crowdsec bouncer <<<

HAProxy version
haproxy -vv
HAProxy version 2.6.6-1ppa1~jammy 2022/09/22 - https://haproxy.org/
Status: long-term supported branch - will stop receiving fixes around Q2 2027.
Known bugs: http://www.haproxy.org/bugs/bugs-2.6.6.html
Running on: Linux 5.15.0-53-generic #59-Ubuntu SMP Mon Oct 17 18:53:30 UTC 2022 x86_64
Build options :
  TARGET  = linux-glibc
  CPU     = generic
  CC      = cc
  CFLAGS  = -O2 -g -O2 -flto=auto -ffat-lto-objects -flto=auto -ffat-lto-objects -fstack-protector-strong -Wformat -Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2 -Wall -Wextra -Wundef -Wdeclaration-after-statement -Wfatal-errors -Wtype-limits -Wshift-negative-value -Wshift-overflow=2 -Wduplicated-cond -Wnull-dereference -fwrapv -Wno-address-of-packed-member -Wno-unused-label -Wno-sign-compare -Wno-unused-parameter -Wno-clobbered -Wno-missing-field-initializers -Wno-cast-function-type -Wno-string-plus-int -Wno-atomic-alignment
  OPTIONS = USE_PCRE2=1 USE_PCRE2_JIT=1 USE_OPENSSL=1 USE_LUA=1 USE_SLZ=1 USE_SYSTEMD=1 USE_OT=1 USE_PROMEX=1
  DEBUG   = -DDEBUG_STRICT -DDEBUG_MEMORY_POOLS

Feature list : +EPOLL -KQUEUE +NETFILTER -PCRE -PCRE_JIT +PCRE2 +PCRE2_JIT +POLL +THREAD +BACKTRACE -STATIC_PCRE -STATIC_PCRE2 +TPROXY +LINUX_TPROXY +LINUX_SPLICE +LIBCRYPT +CRYPT_H -ENGINE +GETADDRINFO +OPENSSL +LUA +ACCEPT4 -CLOSEFROM -ZLIB +SLZ +CPU_AFFINITY +TFO +NS +DL +RT -DEVICEATLAS -51DEGREES -WURFL +SYSTEMD -OBSOLETE_LINKER +PRCTL -PROCCTL +THREAD_DUMP -EVPORTS +OT -QUIC +PROMEX -MEMORY_PROFILING

Default settings :
  bufsize = 16384, maxrewrite = 1024, maxpollevents = 200

Built with multi-threading support (MAX_THREADS=64, default=2).
Built with OpenSSL version : OpenSSL 3.0.2 15 Mar 2022
Running on OpenSSL version : OpenSSL 3.0.2 15 Mar 2022
OpenSSL library supports TLS extensions : yes
OpenSSL library supports SNI : yes
OpenSSL library supports : TLSv1.0 TLSv1.1 TLSv1.2 TLSv1.3
OpenSSL providers loaded : default
Built with Lua version : Lua 5.3.6
Built with the Prometheus exporter as a service
Built with network namespace support.
Built with OpenTracing support.
Support for malloc_trim() is enabled.
Built with libslz for stateless compression.
Compression algorithms supported : identity("identity"), deflate("deflate"), raw-deflate("deflate"), gzip("gzip")
Built with transparent proxy support using: IP_TRANSPARENT IPV6_TRANSPARENT IP_FREEBIND
Built with PCRE2 version : 10.39 2021-10-29
PCRE2 library supports JIT : yes
Encrypted password support via crypt(3): yes
Built with gcc compiler version 11.2.0

Available polling systems :
      epoll : pref=300,  test result OK
       poll : pref=200,  test result OK
     select : pref=150,  test result OK
Total: 3 (3 usable), will use epoll.

Available multiplexer protocols :
(protocols marked as <default> cannot be specified using 'proto' keyword)
         h2 : mode=HTTP  side=FE|BE  mux=H2    flags=HTX|HOL_RISK|NO_UPG
       fcgi : mode=HTTP  side=BE     mux=FCGI  flags=HTX|HOL_RISK|NO_UPG
         h1 : mode=HTTP  side=FE|BE  mux=H1    flags=HTX|NO_UPG
  <default> : mode=HTTP  side=FE|BE  mux=H1    flags=HTX
       none : mode=TCP   side=FE|BE  mux=PASS  flags=NO_UPG
  <default> : mode=TCP   side=FE|BE  mux=PASS  flags=

Available services : prometheus-exporter
Available filters :
        [CACHE] cache
        [COMP] compression
        [FCGI] fcgi-app
        [  OT] opentracing
        [SPOE] spoe
        [TRACE] trace

Apologies, both hosts used for testing had been moved to cloudflare for public access...


network-interfaces-scripted: fix NixOS/nixops#640

Motivation for this change
This fixes NixOS/nixops#640 by reversing the PartOf dependency between network-setup and network-addresses-*.
This was joint work of: @nh2, @domenkozar, @fpletz, @aszlig and @basvandijk at the NixCon 2017 hackathon.
Things done
We tested this by running a loop which at each iteration deploys a configuration (using nixops) which changes the network-setup service and then deploys a configuration which removes that change. We ran the loop for 60 iterations and the Hetzner machine didn't loose its network connection.

[ ] Tested using sandboxing (nix.useSandbox on NixOS, or option build-use-sandbox in nix.conf on non-NixOS)
Built on platform(s)

[x] NixOS
[ ] macOS
[ ] other Linux distributions

[ ] Tested via one or more NixOS test(s) if existing and applicable for the change (look inside nixos/tests)
[ ] Tested compilation of all pkgs that depend on this change using nix-shell -p nox --run "nox-review wip"
[ ] Tested execution of all binary files (usually in ./result/bin/)
[ ] Fits CONTRIBUTING.md.

/~Time travelling~.
In case anyone involved here is still interested in taking a look, this broke the container networking restart test:
https://hydra.nixos.org/build/63112069


[arrow-row] add offsets at the Row level

Which issue does this PR close?

Closes #4847
Rationale for this change

What changes are included in this PR?

Are there any user-facing changes?

I'm not really sure about this, as written it will double the memory usage for many use-cases, and I expect this to similarly regress encodd performance.
Perhaps we could take a step back here and start with your intended use-case for this functionality?

Marking this as a draft to indicate it isn't waiting on review, feel free to unmark when you would like me to take another look


ascontigousarray/asfortranarray differ from numpy

In NumPy, np.ascontiguousarray(x) and np.asfortranarray(x) are equivalent to np.asarray(x, order={'C', 'F'}). Meaning it will accept lists and other array-like types to convert them into an array.
In CuPy, the array-like argument must be exactly an array and no coercion is permitted
In [1]: import cupy

In [2]: cupy.asarray(range(10), order='C')
Out[2]: array([0, 1, 2, 3, 4, 5, 6, 7, 8, 9])

In [3]: cupy.ascontiguousarray(range(10))
---------------------------------------------------------------------------
TypeError                                 Traceback (most recent call last)
<ipython-input-2-073bb62b4261> in <module>
----> 1 cupy.ascontiguousarray(range(10))

~/miniconda3/envs/uarray-dev/lib/python3.7/site-packages/cupy/creation/from_data.py in ascontiguousarray(a, dtype)
     95
     96     """
---> 97     return core.ascontiguousarray(a, dtype)
     98
     99

TypeError: Argument 'a' has incorrect type (expected cupy.core.core.ndarray, got range)

There are many NumPy APIs accepting lists/array-like objects as input, but CuPy disallows them. I could be wrong, but my guess is ascontigousarray()/asfortranarray() are not considered as one of the proper entry points in CuPy.

Yeah, I think the question is whether cp.ascontiguousarray and cp.asfortranarray should be considered array creation functions like cp.asarray and allow this use case.

I noticed that NumPy considers ascontiguousarray() a creation routine, but not asfortranarray(). Interesting...
https://numpy.org/doc/1.18/reference/routines.array-creation.html#from-existing-data

This behavior is intended as documented below:
https://docs-cupy.chainer.org/en/latest/reference/generated/cupy.ascontiguousarray.html#cupy.ascontiguousarray
a (cupy.ndarray) – Source array.

However I think it's better to add some notes in our documentation. cupy.ascontiguousarray and cupy.copy are under Creation from other data but only accepts cupy.ndarrays.
https://docs-cupy.chainer.org/en/latest/reference/creation.html#creation-from-other-data


Not working with V-Rep Simulator

need to be fixed

created a vrep branch which is cooperated with V-Rep simulator.
detailed instruction will be added.
closing issue


References Slider - Highlight Rating w/ Corresponding Color

The current references slider works by highlighting previously rated ratings and de-emphasizing the currently standing rating. For example, the screenshot below shows the Negative rating highlighted in darker text, even though the point stands at Neutral.

Even when the pointer exceeds a specifying rating's scale, the previous ratings are still highlighted in the darker text. This can be confusing for users. See below.

To improve this, the text that corresponds with the Rating scale should be highlighted (in the assigned color). If the pointer is not within that rating's scale, it should be in lighter text. See below.
Example A:

Example B:

In addition, the rating scale should be colored as neutral (light grey - rgba(196, 196, 196, 0.3)).


Unknown "g" command crashes slidy

The problem
If a incomplete command is ran then slidy crashes. For example, if I execute something as slidy g b the following is shown:
Unhandled exception:
Bad state: No element
#0      ListMixin.single (dart:collection/list.dart:119:22)
#1      GenerateBlocSubCommand.run (file:///home/ascenio/.pub-cache/hosted/pub.dartlang.org/slidy-3.0.0+2/bin/commands/sub_command/generate_bloc_sub_command.dart:43:74)
#2      CommandRunner.runCommand (package:args/command_runner.dart:196:27)
#3      CommandRunner.run.<anonymous closure> (package:args/command_runner.dart:112:25)
#4      new Future.sync (dart:async/future.dart:218:31)
#5      CommandRunner.run (package:args/command_runner.dart:112:14)
#6      executeCommand (file:///home/ascenio/.pub-cache/hosted/pub.dartlang.org/slidy-3.0.0+2/bin/slidy.dart:37:10)
#7      main (file:///home/ascenio/.pub-cache/hosted/pub.dartlang.org/slidy-3.0.0+2/bin/slidy.dart:17:5)
#8      _delayEntrypointInvocation.<anonymous closure> (dart:isolate-patch/isolate_patch.dart:281:32)
#9      _RawReceivePortImpl._handleMessage (dart:isolate-patch/isolate_patch.dart:184:12)

Notice that I didn't added the arguments as expected (slidy g b login_bloc, for example), but this should be handled by the program, as the user is expected to send invalid or absent args.
Expected behavior
Slidy should be able to gracefully handle the error and just print the list of available subcommands (same as slidy g)

fixed


Switch to using pex.

This change is

Reviewed 2 of 2 files at r1.
Review status: all files reviewed at latest revision, all discussions resolved.

Comments from Reviewable

bors r+


Add arguments to connections based on the fields of the type

@hardchor What do you think?

 :) I am always asking for the same...

@hardchor I've added a test, is it good enough? :)

Yeah, that'll do :+1:

merged


bake cosign binary into kustomizer container image

as kustomizer uses cosign executable, it'd be better to include cosign binary into container image.
assign it to me I can fix this

Could you also switch to Wolfi from distroless? Thanks!
Ref: https://github.com/stefanprodan/kustomizer/blob/main/Makefile#L75


Add benchmark-specific start/end timestamps in the result files

Record the time when a benchmark was run, on a per-benchmark basis. Working on a per-benchmark basis addresses issues arising if specific benchmarks have been rerun, in which case having a single date range for the whole file may not be indicative.
Alternative to gh-400

Coverage increased (+0.1%) to 70.512% when pulling f2c8aa6591215a43ba4ff426302c4aa2bcbf7530 on pv:benchmark-date into c360f01df82073fe37657a043e15cd6f58a55488 on spacetelescope:master.

I think you should also remove benchmark start/end time in the asv rm benchmark=glob command.

Coverage increased (+0.1%) to 70.523% when pulling 30cdbd7d604e7d376399ede262c88100c27818eb on pv:benchmark-date into c360f01df82073fe37657a043e15cd6f58a55488 on spacetelescope:master.

LGTM


Update index.html

updated the introduction paragraph of the website as it seems boring

Hey @HardikTripathi04,
Please make sure to link the relevant issue using the appropriate syntax, such as "#issueNumber" 👀.
Follow the proper guideline and make a new PR again 😀.
Happy Hacking 💗

Thank you  @HardikTripathi04 , for your valuable time and contribution in our GameZone 💗.
It’s our GameZone, so Let’s build this GameZone altogether !!🤝
Hoping to see you soon with another PR again 😇
Wishing you all the best for your journey into Open Source🚀


Simplify Build Instructions MacOS in docs

The line-feed/CR confusion has been eliminated and the build runs out-of-the box on MacOS when using the default GNUmake 3.81. So consequently the build instructions in the front-page docs can be simplified.
Also note to simply use readily available GNU-ARM toolchain without the need to tap any brew.


Refactor ActionDropdown component to remove Mitt dependency and refactor table components API

Primary Goals

remove dependency on Mitt and refactor existing component API's reliant on global event listeners
simplify the table components API
establish an initial pattern for more composable "actions"

What this does

removes Mitt as a required dependency for actions
refactors the ActionItem interface to accept callback methods over event names
refactors the TableColumns interface for clarity and a more prescriptive approach for table cell content
consolidates table rendering logic into a useTable component to be shared between table components
renames StaticTable to DataTable and Table to DynamicTable
Introduces the TableActionButtons component that fulfills as an alternative to ActionDropdown on table components for one-click triggers
refactors the props API on DataTable and DynamicTable to separate concerns and reduce the complexity of establishing the table props as one large object literal
drops the loader and clickable props on DynamicTable in favor of

In Action
The bulk of these changes have been implemented on both Portal and Archive

Portal
Archive

Key Changes
Dropping Mitt changes the way we'll configure click events for table actions by moving away from a global event listener, that could be established anywhere in application code, to callback methods defined as an array of TableActionItems to be passed as a prop to the table components.  This may at first seem like it is more limiting that what Mitt offered, but there should be gains in code clarity, type safety, and composability.
Defining table columns gets easier, but intentionally guides us away from using custom components as a cell value.  The primary purpose of this change is to move us toward tables that all work similarly from a UX perspective, and to encourage us to think critically about why and when a table is being used.   The new method for passing a custom component as a cell value relies on using the h() method from the Vue package.  What's most useful about it, is the ability to pass in a custom component and apply any number of props that might be required to render it.  You can additionally use it to simply generate complex html markup and apply conditions based on the ref's in the parent scope.  As a general rule, you mostly won't need it, but it's there when you do.

Couple minor thoughts:

event in the TableActionItem felt out of touch after this change, naming it click or onClick is more intuitive for me
having the tableActionsType as it's own prop felt a little cumbersome. was thinking it should live in the tableOptions but realized that DataTable doesn't have options. no solution jumps to mind, but if this bothered you at all, maybe we can re-org it

Couple minor thoughts:

event in the TableActionItem felt out of touch after this change, naming it click or onClick is more intuitive for me
having the tableActionsType as it's own prop felt a little cumbersome. was thinking it should live in the tableOptions but realized that DataTable doesn't have options. no solution jumps to mind, but if this bothered you at all, maybe we can re-org it

(+1) for renaming it to onClick.
It does bother me a bit.   One question might be whether there's value in making the type of actions you want a required definition.  Which is a tradeoff between the convenience of a default for clarity and intention.

In that case, the props could look like this:
type TableActions<T> = {
  type: "dropdown" | "buttons",
  actions: TableActionItem<T>[]
}

const props = withDefaults(
  defineProps<{
    tableActions?: TableActions<any>
    tableColumns: TableColumns<any>
    tableOptions: DynamicTableOptions
  }>(),
  {
    tableActions: () => ({type: "dropdown", actions: []}),
  }
)

One question might be whether there's value in making the type of actions you want a required definition.

I vote for making it required. I had a little trouble tracking the props just now when comparing the changes in this PR to the draft PRs in the other repos for the table components. Each of the other props are complicated (i.e., require thinking about how your object translates to a tabular view) and I'd just as likely overlook the tableActionsType prop. Not sure if that totally makes sense, but sounds like we're all on the same page in general.
Said another way, when composing the table actions, to me it seems like a good starting point to force thinking about the UI ("do I want buttons or a dropdown?"), which may inspire critical thinking about overstuffing the cell with actions in the first place (looking at you /users/Main.vue on Portal).


Toolbar icons in svg

Yes, the eye sometimes wants something too ;]. Would be great if the toolbar icons were in vector too.
Don't know if any of the previous authors would still have the respective source files...

Spring cleaning, If this issue is still relevant, please reopen-it.


Favouriting events: Unable to tap favourite on EventCard with VoiceOver enabled

Hopefully fixes #215.
It is not possible to have nested accessible elements. In this case we can not have the EventCard accessible and the nested SaveEventButton accessible too.
Note: This PR disables accessibility on the Event Card, however the headings, time etc should still be accessible. This may not be the right approach so needs testing to determine best approach.
Tester check-list
Accessibility Testing

[ ] Text-to-Voice (Android: Voice Assistant / iOS: Speak Selection)

The event card itself is no longer accessible but now the various elements within it are individually accessible, including the favouriting icon.
I think this has fixed the issue.

It feels a bit weird in TalkBack. Because the event card itself is no longer focusable, the screen reader never announces that this is a button.
We could try moving the save favorite button outside of the event card Touchable. Then position it above the card using position: "absolute".

@frigus02 Yeah, I wasn't completely sure how this would pan out. I have another idea that would make it better. Will try that soon.

@declanslevin I have refactored to have a button with all the content on the left of the card, and a button with the save ability on the right. Hopefully it is a much better accessibility experience now. Would you mind retesting?

Re-tested and I agree this is a more elegant solution which is working correctly.
This can be merged once the conflicts are resolved.


see coverage

Codecov Report

Merging #9 (b12a698) into master (c38d8a8) will decrease coverage by 24.26%.
The diff coverage is 46.48%.

@@             Coverage Diff             @@
##           master       #9       +/-   ##
===========================================
- Coverage   88.18%   63.91%   -24.27%
===========================================
  Files           6       11        +5
  Lines         330      679      +349
===========================================
+ Hits          291      434      +143
- Misses         25      201      +176
- Partials       14       44       +30

Impacted Files
Coverage Δ

cmd/use.go
10.90% <10.90%> (ø)

cmd/settings.go
86.95% <12.50%> (-1.03%)
:arrow_down:

pkg/es/handle.go
41.02% <41.02%> (ø)

cmd/snapshot.go
48.38% <48.38%> (ø)

cmd/repo.go
53.60% <53.60%> (ø)

cmd/resources.go
87.71% <60.00%> (-8.58%)
:arrow_down:

pkg/es/client.go
80.00% <73.33%> (-10.91%)
:arrow_down:

cmd/root.go
73.17% <80.00%> (+2.90%)
:arrow_up:

cmd/current.go
100.00% <100.00%> (ø)

... and 5 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 c38d8a8...b12a698. Read the comment docs.


Causal Inference with dowhy

tbd

Because no versions of sphinx-design match >=0.0.13,<0.3.0 || >0.3.0
 and sphinx-design (0.3.0) depends on sphinx (>=4,<6), sphinx-design (>=0.0.13) requires sphinx (>=4,<6).
And because myst-parser (2.0.0) depends on sphinx (>=6,<8)
 and no versions of myst-parser match >=0.17.0,<2.0.0 || >2.0.0, sphinx-design (>=0.0.13) is incompatible with myst-parser (>=0.17.0).
So, because ehrapy depends on both myst-parser (>=0.17.0) and sphinx-design (>=0.0.13), version solving failed.

That's my fault and I'll fix this.

Please remove the dowhy.ipynb. Please add the tutorial to the ehrapy-tutorials repository. The notebook also still has errors in it.

The notebook here was just a relict, but thanks for pointing it out 👌 We had already merged the proper notebook into the tutorials repo
https://github.com/theislab/ehrapy-tutorials/blob/main/mimic_2_causal_inference.ipynb


Forward/<IP_ADDRESS>

@ironman-machine go

Hello @LaurenSpiegel
Starting end to end procedure using the following payload:
{"REPO_NAME": "S3", "DEFAULT_BRANCH": "rel/6.3", "SCALITY_S3_BRANCH": "forward/<IP_ADDRESS>"}
Please follow http://ci.ironmann.io/gh/scality/Integration/13045 for CI status.


Fix issue 5130, enhancement to add support for complex values in pulse.schedule [work-in-progress]

Summary
I have attempted to fix issue #5130
Description
I have modified the member function conjugate in parameterexpression.py.

This is my first time contributing and I'd like if I could get some pointers as to moving ahead with this enhancement.

Could you add further contributions to #5192? 🙂


Add IORef hints

 atomicModifyIORef r (\x -> (x,x))

Is equivalent to readIORef. Same rule applies with modifyIORef.

Maybe this hint only makes sense with modifyIORef, will have to read the docs for what guarantees atomicModifyIORef gives vs readIORef.

Reading through the memory model section it seems like nothing is really equivalent. The only invariant I could find is:
atomicModifyIORef' ref (\_ -> (a,b)) == atomicWriteIORef ref a >> return b

But that's hardly an elegant equivalence. Leaving as is for now.


N

Codecov Report

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

@@           Coverage Diff           @@
##           master      #11   +/-   ##
=======================================
  Coverage   78.57%   78.57%
=======================================
  Files          12       12
  Lines          98       98
  Branches        8        8
=======================================
  Hits           77       77
  Misses         20       20
  Partials        1        1

Impacted Files
Coverage Δ

angular/src/app/navpages/auth/auth.component.ts
75.00% <ø> (ø)

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 b953807...4de9fa4. Read the comment docs.


Chat History persists with ollama run

What is the issue?

See the image. The chat history is persisting for Falcon, but not any other models (at least that I've tried so far). I would expect it to not persist. It even persists after re-creating the model:

OS
macOS
GPU
Apple
CPU
Apple
Ollama version
0.3.12

The problem happens in the API as well.

What's in your Modelfile?  What's the output of ollama show --modelfile falcon-mamba-instruct:7b-q4_0?

What's in your Modelfile? What's the output of ollama show --modelfile falcon-mamba-instruct:7b-q4_0?

# Modelfile generated by "ollama show"
# To build a new Modelfile based on this, replace FROM with:
# FROM falcon-mamba-instruct:7b-q4_0

FROM /Users/hudsongouge/.ollama/models/blobs/sha256-26e1d318e3c108d4f263056618afc3bf181fd518011451f3ea814eef03627157
TEMPLATE "{{- range .Messages }}<|im_start|>{{ .Role }}
{{ .Content }}<|im_end|>
{{ end }}<|im_start|>assistant
"
SYSTEM You are a helpful AI assistant.
PARAMETER stop <|im_start|>
PARAMETER stop <|im_end|>
PARAMETER min_p 0.1
PARAMETER repeat_penalty 1

To me this seems like a bug in the Python library you're using for Ollama, not in Ollama itself, or the API.
My own example:
    println!("Step #1");

    let messages = vec![
        client::Message::new("system", r#"You are a helpful assistant"#),
        client::Message::new("user", "x = 4 and y = 137. Remember that."),
    ];

    let response: LLMResponse = client::call_llm(&client, model, messages.clone())
        .await
        .unwrap();

    println!("Response:\n{:#?}", response.message.content);

    println!("Step #2");

    let messages = vec![
        client::Message::new("system", r#"You are a helpful assistant"#),
        client::Message::new("user", "What are x and y?"),
    ];

    let response: LLMResponse = client::call_llm(&client, model, messages.clone())
        .await
        .unwrap();

    println!("Response:\n{:#?}", response.message.content);

Outputs:
Step #1
Response:
"I've noted that you've set x to 4 and y to 137. If you need any calculations or further information related to these values, feel free to ask!"
Step #2
Response:
"To provide an answer, I need more information about what x and y represent. Could you please give me the context or equations involving x and y?"

Which seems to work like I expect it to.
Can you replicate this issue when you use the HTTP API directly without using the Python library you're using?

To me this seems like a bug in the Python library you're using for Ollama, not in Ollama itself, or the API.
My own example:
    println!("Step #1");

    let messages = vec![
        client::Message::new("system", r#"You are a helpful assistant"#),
        client::Message::new("user", "x = 4 and y = 137. Remember that."),
    ];

    let response: LLMResponse = client::call_llm(&client, model, messages.clone())
        .await
        .unwrap();

    println!("Response:\n{:#?}", response.message.content);

    println!("Step #2");

    let messages = vec![
        client::Message::new("system", r#"You are a helpful assistant"#),
        client::Message::new("user", "What are x and y?"),
    ];

    let response: LLMResponse = client::call_llm(&client, model, messages.clone())
        .await
        .unwrap();

    println!("Response:\n{:#?}", response.message.content);

Outputs:
Step #1
Response:
"I've noted that you've set x to 4 and y to 137. If you need any calculations or further information related to these values, feel free to ask!"
Step #2
Response:
"To provide an answer, I need more information about what x and y represent. Could you please give me the context or equations involving x and y?"

Which seems to work like I expect it to.
Can you replicate this issue when you use the HTTP API directly without using the Python library you're using?

The issue is also in the Ollama cli via ollama run <model>, so I would expect it to be an issue with Ollama. The Python library I used was the official ollama python library.

The issue is also in the Ollama cli via ollama run , so I would expect it to be an issue with Ollama. The Python library I used was the official ollama python library.

I can't seem to reproduce this issue with ollama run either, works like I expect it to too:
$ ./ollama run qwen2.5:32b "x = 4 and y = 137. Remember that."
Got it, you've specified that x = 4 and y = 137. If you need any calculations or further information involving these variables,
feel free to ask!

$ ./ollama run qwen2.5:32b "What are x and y?"
To provide an answer about what \(x\) and \(y\) are, I would need more context or information regarding the specific scenario
you're referring to, as \(x\) and \(y\) can represent different things depending on the situation:

1. **Mathematics**: In mathematics, \(x\)^C

The issue is also in the Ollama cli via ollama run , so I would expect it to be an issue with Ollama. The Python library I used was the official ollama python library.

I can't seem to reproduce this issue with ollama run either, works like I expect it to too:
$ ./ollama run qwen2.5:32b "x = 4 and y = 137. Remember that."
Got it, you've specified that x = 4 and y = 137. If you need any calculations or further information involving these variables,
feel free to ask!

$ ./ollama run qwen2.5:32b "What are x and y?"
To provide an answer about what \(x\) and \(y\) are, I would need more context or information regarding the specific scenario
you're referring to, as \(x\) and \(y\) can represent different things depending on the situation:

1. **Mathematics**: In mathematics, \(x\)^C

If you see my original message, the issue ONLY occurs with Falcon Mamba. That's the weird part. Either way, it is a problem that needs to be fixed as that model is pretty much unusable for my user-case until this is fixed.

I see something happening with the run cmd?   runCmd := &cobra.Command{         Use:     "run MODEL [PROMPT]",         Short:   "Run a model",         Args:    cobra.MinimumNArgs(1),         PreRunE: checkServerHeartbeat,         RunE:    RunHandler,     }  if I check the server.log I can see the chat endpoint being called?  messages / context / cache / persistence  issue there somewhere? I keep looking good luck.

I see, if I use ollama run llama3.1 what can you do?  it uses the generate (love? seems more smart? powerful). but yes, if only  ollama run llama3.1 then it uses the chat with persisted messages / prompts (issue). good luck. I will still try see what I can find (chat and generate in a single function seems best) anyway good luck.

My guess here is the problem is with falcon-mamba and the kv cache. Llama3.1 and llama3.2 seem to be working correctly.

My guess here is the problem is with falcon-mamba and the kv cache. Llama3.1 and llama3.2 seem to be working correctly.

Yes, all other models I have tested (llama, Owen, gemma, etc...) work correctly.

Yes, recurrent models such as Mamba do use the KV cache differently, so that is likely where the problem is.

I don't see this with the most recent 0.4.0-rc, can you see if it is still a problem there?


Mono error on Ubuntu: System.DllNotFoundException: gtksharpglue-2

0
I am trying to add a GTK# project to a Xamarin.Forms solution and run this GTK project on Linux. For this I followed the steps mentioned in the below link. https://docs.microsoft.com/en-us/xamarin/xamarin-forms/platform/other/gtk?tabs=windows
I build this solution with GTK libraries in VS-2017 on Win machine, and after build GTK Project is running on Win without errors. Same GTK project when I try to run on Linux-Ubuntu16, it is giving below error.
spsuser@ubuntusrv:~/Desktop/Boxview/Debug$ sudo mono BasicBoxView.GTK.exe
Unhandled Exception:
System.TypeInitializationException: The type initializer for 'Gtk.Container' threw an exception. ---> System.DllNotFoundException: gtksharpglue-2
at (wrapper managed-to-native) Gtk.Container.gtksharp_gtk_container_get_focus_child_offset()
at Gtk.Container..cctor () [0x00000] in <94f79862491c46b0bf711bc40f7608a5>:0
--- End of inner exception stack trace ---
at Gtk.Bin..ctor (System.IntPtr raw) [0x00000] in <94f79862491c46b0bf711bc40f7608a5>:0
at Gtk.Window..ctor (Gtk.WindowType type) [0x00000] in <94f79862491c46b0bf711bc40f7608a5>:0
at Xamarin.Forms.Platform.GTK.FormsWindow..ctor () [0x00000] in <4bad12fcff0f409181b1aa48e034f579>:0
at BasicBoxView.GTK.Program.Main (System.String[] args) [0x00014] in <12b4a789a2e94320a9d8929a6bfc16da>:0
[ERROR] FATAL UNHANDLED EXCEPTION: System.TypeInitializationException: The type initializer for 'Gtk.Container' threw an exception. ---> System.DllNotFoundException: gtksharpglue-2
at (wrapper managed-to-native) Gtk.Container.gtksharp_gtk_container_get_focus_child_offset()
at Gtk.Container..cctor () [0x00000] in <94f79862491c46b0bf711bc40f7608a5>:0
--- End of inner exception stack trace ---
at Gtk.Bin..ctor (System.IntPtr raw) [0x00000] in <94f79862491c46b0bf711bc40f7608a5>:0
at Gtk.Window..ctor (Gtk.WindowType type) [0x00000] in <94f79862491c46b0bf711bc40f7608a5>:0
at Xamarin.Forms.Platform.GTK.FormsWindow..ctor () [0x00000] in <4bad12fcff0f409181b1aa48e034f579>:0
at BasicBoxView.GTK.Program.Main (System.String[] args) [0x00014] in <12b4a789a2e94320a9d8929a6bfc16da>:0
spsuser@ubuntusrv:~/Desktop/Boxview/Debug$
I tried to map DLL with /etc/mono/config.
<dllmap dll="libgtksharpglue-2" target="libgtksharpglue-2.so" os="!windows"/>
My PATH variable referring to gtk-sharp-2.0 path.
spsuser@ubuntusrv:~/Desktop/Boxview/Debug$ echo $PATH
/home/spsuser/bin:/home/spsuser/.local/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games:/snap/bin:/usr/lib/cli/gtk-sharp-2.0/:/usr/bin/lib
Same error I'm seeing. I googled this error, but didn't find any solution. Even I tried to download samples from below link and build on Win. When I run these on Ubuntu16/CentOS7 it is giving same error.
https://github.com/jsuarezruiz/xamarin-forms-gtk-samples
My objective is existing Xamarin.Forms app which is running on Win, that needs to be run on Linux. Any one who tried above link, please check and help me.

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

ID: 66853f3d-854e-08ad-84d2-b2a98f88c48b
Version Independent ID: 77ea362d-ef46-f426-3d4a-5f99e39ce160
Content: GTK# Platform Setup - Xamarin
Content Source: docs/xamarin-forms/platform/other/gtk.md
Product: xamarin
Technology: xamarin-forms
GitHub Login: @davidbritch
Microsoft Alias: dabritch

We cannot help with this query - please check the Xamarin.Forms GitHub wiki for where to find help and submit support requests.


Create hostgroups task not working as intended

The task does create host groups, but it clones the group for each host the playbook is run on.
So basically if I run it on three hosts, I end up with three identical groups (with the hosts inside all three groups).

Hi @aviramartac
I merged a PR with a possible fix for this. The task for creating host groups is only executed once, so this should prevent the playbook to create several hostgroups with the same name.

That did it :)

Will create a release 0.10.0 within a few hours.


[cli]

Can we have the binaries produced to be named more appropriately
ie: rancher-cli-v0.1.0
rather than the current:
rancher-v0.1.0

With the release of Rancher 2.0, development on v1.6 is only limited to critical bug fixes and security patches.


Introducing webrunify

Not really an issue, but something that might be of interest.
I've created a browserify plugin (and CLI program) called webrunify to bundle up CommonJS modules written for Node and expose them as ES modules with all their dependencies included. These bundles can then be shared as standalone modules and imported into Webrun or Beaker just like any other ES module:
import lib from 'dat://example.com/lib.bundle.js'

I think this could be useful for people who want to use modules from NPM, but prefer to move away from --allow-require (as you rightly recommend in the docs).

That's awesome!
Would you be interested in doing a PR that links to and describes your tool in the README?

Yep, will do!
Op ma 3 dec. 2018 16:16 schreef RangerMauve<EMAIL_ADDRESS>
That's awesome!
Would you be interested in doing a PR that links to and describes your
tool in the README?
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/RangerMauve/webrun/issues/12#issuecomment-443745503,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AF0vrnc2TQIaeHq6NvVjvbhDyqOd1i5Gks5u1UA8gaJpZM4Y80Y_
.


Get Firebase Crashlytics build going

The basics for getting Firebase Crashlytics building. This depends on https://github.com/endlessm/python-for-android/pull/11. I'm marking it as a draft just to show what's needed.

I changed the Makefile so that it would install SDK 31 and squashed the commits together with some more background in the commit message.


Properly handle header casing and make it consistent

The HTTP/1 spec (section 4.2 "Message Headers") says:

Field names are case-insensitive.

The HTTP/2 spec (section 8.1.2) says:

Just as in HTTP/1.x, header field names are strings of ASCII characters that are compared in a case-insensitive fashion. However, header field names MUST be converted to lowercase prior to their encoding in HTTP/2. A request or response containing uppercase header field names MUST be treated as malformed (Section <IP_ADDRESS>).

Considering this, we should:

[x] HTTP/1: downcase all request headers as soon as the user gives them to use (in request/5 or as trailing headers in stream_request_body/3)
[x] HTTP/2: downcase all request headers as soon as the user gives them to use (in request/5 or as trailing headers in stream_request_body/3)
[x] HTTP/1: downcase all response headers as soon as they are parsed
[x] HTTP/2:

assume response headers are downcased and just go about our way or
check the casing of all response headers and error out if they're not downcase?

Yep, we do everything here!


changed the heading to lower case

changed the heading in references section to lower case

@huan changed the heading to lower case


Improving Testing

Currently, there are some basic unit and end-to-end tests, but these could be improved.
unit

Add more of them
...

e2e

Test more environments that just Ubuntu
Add tests for type generation
Add tests for SSR
...

Questions:

Is the current testing pipeline ok? Can it be improved?
What cases are tests not covering?

IIRC, I think Astro now has a testing API, we should simplify our current testing by migrating to this new testing API


Fix JLD2 julia compat

Avoid
ERROR: LoadError: type DataType has no field size
Stacktrace:
 [1] getproperty(x::Type, f::Symbol)
   @ Base ./Base.jl:32
 [2] top-level scope
   @ ~/.julia/packages/JLD2/qncOK/src/data/number_types.jl:14

For context, JLD2 used to access internal fields of Julia's datastructures, which was broken in version v1.9: https://github.com/JuliaIO/JLD2.jl/issues/428.  This was fixed by https://github.com/JuliaIO/JLD2.jl/pull/438, included in JLD2 v0.4.28+, but until now older versions are still allowed to be installed on Julia v1.9+, so this PR makes it impossible to install JLD2 v0.4.27- on Julia v1.9+, adding a compatibility cap to julia v1.8.


Windows ID empty assertion doesn't seem to trigger on Windows

I've been testing inochi-creator and inochi-session on Linux, an it has appended more than once that I've found that this assertion get's triggered on Linux builds that work fine on Windows.
inochi-session: /opt/src/bindbc-imgui/deps/cimgui/imgui/imgui.cpp:8925:
bool ImGui::ItemAdd(const ImRect&, ImGuiID, const ImRect*, ImGuiItemFlags):
Assertion `id != window->ID && "Cannot have an empty ID at the root of a window. If you need an empty label, use ## and read the FAQ about how the ID Stack works!"' failed.

I don't know if it is expected for it not to trigger on Windows builds, but I think that it's a problem that this is inconsistent between builds.

Reason it doesn't trigger on windows is because release builds disable assertions and right now a problem with bindbc-imgui means I can only build windows versions in release mode.


Doesn't work well with remote server

I've setup a VMs server and I'm trying to drive it remotely with vagrant-libvirt.
I first downloaded the default Ubuntu server vagrant image, and converted it from VirtualBox to LibVirt with vagrant mutate.
Then, I wrote this vagrantfile:
  config.vm.box = "trusty64"
  config.vm.define "trusty64" do |the|
    the.vm.hostname = "trusty64"

    the.vm.provider :libvirt do |libvirt|
        libvirt.driver = "kvm"
        libvirt.memory = 1024
        libvirt.storage_pool_name = "vmsi"
        libvirt.disk_bus = "ide"
        libvirt.host = "<ip>"
        libvirt.username = "romu"
        libvirt.connect_via_ssh = true     # also needed
    end
  end

If I run this script, slightly modified, locally, it works flawlessly. But if I run it on my remote server, I see the VM starts...and then closes. Here is the trace:
==> trusty64: Setting hostname...
==> trusty64: Configuring and enabling network interfaces...
==> trusty64: Removing domain...
/usr/share/vagrant/gems/gems/vagrant-libvirt-0.0.30/lib/vagrant-libvirt/action/prepare_nfs_settings.rb:44:in `connect': no implicit conversion of Array into String (TypeError)
	from /usr/share/vagrant/gems/gems/vagrant-libvirt-0.0.30/lib/vagrant-libvirt/action/prepare_nfs_settings.rb:44:in `block in read_host_ip'
	from /usr/share/vagrant/gems/gems/vagrant-libvirt-0.0.30/lib/vagrant-libvirt/action/prepare_nfs_settings.rb:43:in `open'
	from /usr/share/vagrant/gems/gems/vagrant-libvirt-0.0.30/lib/vagrant-libvirt/action/prepare_nfs_settings.rb:43:in `read_host_ip'
	from /usr/share/vagrant/gems/gems/vagrant-libvirt-0.0.30/lib/vagrant-libvirt/action/prepare_nfs_settings.rb:23:in `call'
	from /usr/share/vagrant/lib/vagrant/action/warden.rb:34:in `call'
	from /usr/share/vagrant/lib/vagrant/action/builtin/synced_folders.rb:86:in `call'
	from /usr/share/vagrant/lib/vagrant/action/warden.rb:34:in `call'
	from /usr/share/vagrant/lib/vagrant/action/builtin/synced_folder_cleanup.rb:28:in `call'
	from /usr/share/vagrant/lib/vagrant/action/warden.rb:34:in `call'
	from /usr/share/vagrant/plugins/synced_folders/nfs/action_cleanup.rb:25:in `call'
	from /usr/share/vagrant/lib/vagrant/action/warden.rb:34:in `call'
	from /usr/share/vagrant/gems/gems/vagrant-libvirt-0.0.30/lib/vagrant-libvirt/action/prepare_nfs_valid_ids.rb:12:in `call'
	from /usr/share/vagrant/lib/vagrant/action/warden.rb:34:in `call'
	from /usr/share/vagrant/lib/vagrant/action/builtin/provision.rb:80:in `call'
	from /usr/share/vagrant/lib/vagrant/action/warden.rb:34:in `call'
	from /usr/share/vagrant/gems/gems/vagrant-libvirt-0.0.30/lib/vagrant-libvirt/action/create_domain.rb:169:in `call'
	from /usr/share/vagrant/lib/vagrant/action/warden.rb:34:in `call'
	from /usr/share/vagrant/gems/gems/vagrant-libvirt-0.0.30/lib/vagrant-libvirt/action/create_domain_volume.rb:51:in `call'
	from /usr/share/vagrant/lib/vagrant/action/warden.rb:34:in `call'
	from /usr/share/vagrant/gems/gems/vagrant-libvirt-0.0.30/lib/vagrant-libvirt/action/handle_box_image.rb:42:in `block in call'
	from /usr/share/vagrant/gems/gems/vagrant-libvirt-0.0.30/lib/vagrant-libvirt/action/handle_box_image.rb:40:in `synchronize'
	from /usr/share/vagrant/gems/gems/vagrant-libvirt-0.0.30/lib/vagrant-libvirt/action/handle_box_image.rb:40:in `call'
	from /usr/share/vagrant/lib/vagrant/action/warden.rb:34:in `call'
	from /usr/share/vagrant/lib/vagrant/action/builtin/handle_box.rb:56:in `call'
	from /usr/share/vagrant/lib/vagrant/action/warden.rb:34:in `call'
	from /usr/share/vagrant/gems/gems/vagrant-libvirt-0.0.30/lib/vagrant-libvirt/action/handle_storage_pool.rb:24:in `block in call'
	from /usr/share/vagrant/gems/gems/vagrant-libvirt-0.0.30/lib/vagrant-libvirt/action/handle_storage_pool.rb:17:in `synchronize'
	from /usr/share/vagrant/gems/gems/vagrant-libvirt-0.0.30/lib/vagrant-libvirt/action/handle_storage_pool.rb:17:in `call'
	from /usr/share/vagrant/lib/vagrant/action/warden.rb:34:in `call'
	from /usr/share/vagrant/gems/gems/vagrant-libvirt-0.0.30/lib/vagrant-libvirt/action/set_name_of_domain.rb:34:in `call'
	from /usr/share/vagrant/lib/vagrant/action/warden.rb:34:in `call'
	from /usr/share/vagrant/lib/vagrant/action/warden.rb:95:in `block in finalize_action'
	from /usr/share/vagrant/lib/vagrant/action/warden.rb:34:in `call'
	from /usr/share/vagrant/lib/vagrant/action/warden.rb:34:in `call'
	from /usr/share/vagrant/lib/vagrant/action/builder.rb:116:in `call'
	from /usr/share/vagrant/lib/vagrant/action/runner.rb:66:in `block in run'
	from /usr/share/vagrant/lib/vagrant/util/busy.rb:19:in `busy'
	from /usr/share/vagrant/lib/vagrant/action/runner.rb:66:in `run'
	from /usr/share/vagrant/lib/vagrant/action/builtin/call.rb:53:in `call'
	from /usr/share/vagrant/lib/vagrant/action/warden.rb:34:in `call'
	from /usr/share/vagrant/gems/gems/vagrant-libvirt-0.0.30/lib/vagrant-libvirt/action/connect_libvirt.rb:18:in `call'
	from /usr/share/vagrant/lib/vagrant/action/warden.rb:34:in `call'
	from /usr/share/vagrant/lib/vagrant/action/builtin/config_validate.rb:25:in `call'
	from /usr/share/vagrant/lib/vagrant/action/warden.rb:34:in `call'
	from /usr/share/vagrant/lib/vagrant/action/builder.rb:116:in `call'
	from /usr/share/vagrant/lib/vagrant/action/runner.rb:66:in `block in run'
	from /usr/share/vagrant/lib/vagrant/util/busy.rb:19:in `busy'
	from /usr/share/vagrant/lib/vagrant/action/runner.rb:66:in `run'
	from /usr/share/vagrant/lib/vagrant/machine.rb:214:in `action_raw'
	from /usr/share/vagrant/lib/vagrant/machine.rb:191:in `block in action'
	from /usr/share/vagrant/lib/vagrant/environment.rb:516:in `lock'
	from /usr/share/vagrant/lib/vagrant/machine.rb:178:in `call'
	from /usr/share/vagrant/lib/vagrant/machine.rb:178:in `action'
	from /usr/share/vagrant/lib/vagrant/batch_action.rb:82:in `block (2 levels) in run'

Any idea? Thanks.

try to use master branch

You're right, it's installed from the RPMs provided by the Fedora repositories. My first thought was to install it as described here, but it failed because of some errors building ruby-libvirt. I'll re-try, and I'll post the errors I get.

Indeed, the problem I have to install the master branch are exactly the ones described in #290. Except I'm running Fedora 23.

I've removed all packages previously installed from DNF. Installed Vagrant 1.7.4 from the Vagrant web site. Now, the installation of the vagrant-libvirt plugin fails on json.
gem install json -v '1.8.3'
Fetching: json-1.8.3.gem (100%)
Building native extensions.  This could take a while...
ERROR:  Error installing json:
	ERROR: Failed to build gem native extension.

    /usr/bin/ruby -r ./siteconf20151208-4725-uvxrwl.rb extconf.rb
creating Makefile

make "DESTDIR=" clean
rm -f
rm -f generator.so  *.o  *.bak mkmf.log .*.time

make "DESTDIR="
gcc -I. -I/usr/include -I/usr/include/ruby/backward -I/usr/include -I. -DJSON_GENERATOR    -fPIC -O2 -g -pipe -Wall -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector-strong --param=ssp-buffer-size=4 -grecord-gcc-switches -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 -mtune=generic -fPIC -m64 -o generator.o -c generator.c
make: gcc: Command not found
Makefile:238: recipe for target 'generator.o' failed
make: *** [generator.o] Error 127

make failed, exit code 2

Gem files will remain installed in /home/romuald/.gem/ruby/gems/json-1.8.3 for inspection.
Results logged to /home/romuald/.gem/ruby/extensions/x86_64-linux/json-1.8.3/gem_make.out

Any help on this issue, please? Because right now, if I'm not able to manage VMs remotely, that's a showstopper to me.

If something not working - fix it.
On 10 Dec 2015 10:40, "romu70"<EMAIL_ADDRESS>wrote:

Any help on this issue, please? Because right now, if I'm not able to
manage VMs remotely, that's a showstopper to me.
—
Reply to this email directly or view it on GitHub
https://github.com/pradels/vagrant-libvirt/issues/522#issuecomment-163554708
.

That's really useful answer thanks.

 Thanks. I now run vagrant-libvirt 0.0.32 and this issue is gone. Great!


Issue in pom.xml

Describe the issue:
Refer -https://is.docs.wso2.com/en/latest/learn/querying-saml-assertions/#with-your-application
When running the sample application saml-query-profile-target (https://github.com/wso2/samples-is/tree/master/saml-query-profile-target)] an error is generated in the pom.xml file due to  outdated maven versions used in the application.
Product Version: [IS 5.11.0]
OS: [Linux]
Database: [H2]
Userstore: [LDAP]

@asekawa Could you please add more details about the issue? Please add the error logs as well

This issue is being closed due to extended inactivity. Please feel free to reopen it if further attention is needed. Thank you for helping us keep the issue list relevant and focused!


Add support for travis-ci integration

Fully fledged checks, builds, and tests on Linux, non-voting native builds and unit tests on OS X.

LGTM

Updated (removed the comments)

Ready for landing. Does it need a squash before the merge?

@akiss77, sure, you may land this. And yes, squash it please. Our policy is to squash all the commits into one and one commit will belongs to one PR on the master. There are a few exceptions when the patch is too huge. We can change this policy, but not now :) You could raise an issue if you think this should be changed.


docs: updated key in remediation object for kubernetes

Updated docs as advised here

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


请教关于ESP32 ble mesh provisioner示例给onoff cilent配网的问题 (IDFGH-10190)

Answers checklist.

[X] I have read the documentation ESP-IDF Programming Guide and the issue is not addressed there.
[X] I have updated my IDF branch (master or release) to the latest version and checked that the issue is present there.
[X] I have searched the issue tracker for a similar issue and not found a similar issue.

IDF version.
v5.0.1-dirty
Operating System used.
Windows
How did you build your project?
Command line with idf.py
If you are using Windows, please specify command line type.
PowerShell
Development Kit.
ESP32-DevKitC
Power Supply used.
USB
What is the expected behavior?
我想通过ble_mesh_provisioner示例给onoff_cilent和onoff_sever配网，以实现onoff_cilent给onoff_sever发送控制指令消息的功能。
What is the actual behavior?
通过对以上示例的烧录运行后发现ble_mesh_provisioner示例给onoff_cilent配网后，onoff_cilent无法成功发送消息，报错：BLE_MESH: Model not bound to AppKey 0x0001，可是我使用手机APP EspBleMesh或者nRF Mesh给其配网时，消息均能发送成功。
Steps to reproduce.

Step
ble_mesh_provisioner.zip

Step
onoff_client.zip

Step
...

Debug Logs.
I (621) EXAMPLE: Initializing...
I (621) gpio: GPIO[0]| InputEn: 0| OutputEn: 0| OpenDrain: 0| Pullup: 1| Pulldown: 0| Intr:0
I (1341) EXAMPLE_NVS: Restore, key "onoff_client", length 6
I (1341) EXAMPLE_NVS: Restore, data: 00 00 01 00 01 47
I (1351) EXAMPLE: Restore, net_idx 0x0000, app_idx 0x0001, onoff 1, tid 0x47
I (1361) EXAMPLE: BLE Mesh Node initialized
I (1371) EXAMPLE: ESP_BLE_MESH_NODE_PROV_ENABLE_COMP_EVT, err_code 0
I (1471) EXAMPLE: ESP_BLE_MESH_NODE_PROV_LINK_OPEN_EVT, bearer PB-ADV
I (680241) BOARD: tap cb (RELEASE)
E (680241) BLE_MESH: Model not bound to AppKey 0x0001
E (680241) BLE_MESH: Failed to send client message 0x00008203
I (680251) EXAMPLE_NVS: Store, key "onoff_client", length 6
I (680251) EXAMPLE_NVS: Store, data: 00 00 01 00 00 48
I (680261) EXAMPLE: Generic client, event 1, error code -22, opcode is 0x8203
I (680271) EXAMPLE: ESP_BLE_MESH_GENERIC_CLIENT_SET_STATE_EVT

More Information.
No response

哪位大佬帮忙指导下呢？感激不尽啊

Hi I am facing the similar problem here.
I burned
2 esp32-devkit with onoff_client
1 esp32-devkit with onoff_server
1 esp32-devkit with provisioner
now i boot onoff_client and onoff_server first
secondly i boot the provisioner.
Observation in onoff_server logs

provision completed and app key also got bind        :  ESP_BLE_MESH_MODEL_OP_MODEL_APP_BIND

Observation in onoff_client logs

provision completed but no app key got bind

Observation in provisioner logs

it provisioned 3 devices.

now if i press on/off button from onoff_client, logs says
BLE_MESH: Model not bound to AppKey 0x0001


Custom hydration for bindings with flow control

Some bindings are not server-side render-able as modifying the document results in invalid client hydration. Therefore, the plugins that render these bindings need to be able to provide custom hydration code. This feature should be opt-in, as it requires modifying the client code.

Not planned for now...
There is an easier way however. You can overwrite the binding name used in the view and write your own binding handler that does the hydration correctly when using ssr. E.g. if -> ssr-if.


[master-next] Adjust syntax for setting an Optional member

Setting the ConditionalRequirements member of SpecializedProtocolConformance
to "{}" works fine with the swift-4.2-branch of swift-llvm, but with the
current upstream-with-swift branch, that results in a build failure:
error: use of overloaded operator '=' is ambiguous (with operand types
'Optional<ArrayRefswift::Requirement >' and 'void')
I suspect this is due to LLVM r322838 which made a bunch of changes to
LLVM's Optional type.

I'm going to merge this to un-break the master-next build, but Huon, please review and make sure this is still doing what you expect.

Thanks for doing this. The original was very ambiguous, and unfortunately this isn't quite what was desired. https://github.com/apple/swift/pull/17499


[FFDC] sed: can't read s/sed:: No such file or directory

==============================================================================
Myffdc :: This module is for triggering data collection on demand
==============================================================================
My FFDC Logs :: This test is needed to satisfy FFDC initial setup ... Manual FFDC collection
.#(CDT) 2017/03/23 02:28:33 - Issuing: Ping Host  xx.xx.xx.xx
status_ping:                 True
status_ssh:                  True
#(CDT) 2017/03/23 02:28:39 - Collecting FFDC.
#(CDT) 2017/03/23 02:28:39 - Issuing: Get Test Dir and Name
ffdc_dir_path:               /gsa/ausgsa-p10/01/indiateam02/swe12345/sweta_test/openbmc-test-automation/logs/20170323022839143878_Myffdc/20170323022839143878_MyFFDCLogs/
ffdc_prefix:<PHONE_NUMBER>2839143878_
#(CDT) 2017/03/23 02:28:39 - Issuing: Create Directory  /sweta_test/openbmc-test-automation/logs/20170323022839143878_Myffdc/20170323022839143878_MyFFDCLogs/
#(CDT) 2017/03/23 02:28:39 - Issuing: Header Message
#(CDT) 2017/03/23 02:28:39 - Issuing: Call FFDC Methods
sed: can't read s/sed:: No such file or directory
sed: can't read s/sed:: No such file or directory
sed: can't read s/sed:: No such file or directory
sed: can't read s/sed:: No such file or directory
sed: can't read s/sed:: No such file or directory
#(CDT) 2017/03/23 02:28:58 - Finished collecting FFDC.
My FFDC Logs :: This test is needed to satisfy FFDC initial setup ... | PASS |
------------------------------------------------------------------------------
Myffdc :: This module is for triggering data collection on demand     | PASS |
1 critical test, 1 passed, 0 failed
1 test total, 1 passed, 0 failed

@sivassrr Can you fix this one up.. Thanks

Will work on this later, Have other higher priority work. Thank you Swetha for opening issue as you observed it.

Found out some time, Robot Framework keyword related with "Run" not responding.
So decided to move it as a tool and folks can use it independently.

Robot Framework "Run" keyword is not consistent, multiple debug helped to move out of Robot and had come up with independent tool. When ever need to paste the data in github. We can use the same.


fix(listbox): pass shouldHighlightOnFocus to ListboxSection and its children items

Closes #1908
📝 Description
Inside Listbox, pass prop shouldHighlightOnFocus to ListboxSection and its children items to enable highlighting.
⛳ Current behavior (updates)
When navigating with keys on Autocomplete with sections, it does not highlight the currently selected item.
🚀 New behavior
The focused item will be highlighted.
💣 Is this a breaking change (Yes/No): No

📝 Additional Information

Closing - the reported issue is no longer reproducible (tested in 2.3.5).


Outlaw packages with version =* from the lock file

I have come across a number of packages where one or more dependency has a version of * i.e. latest or any but it is present in the lock file. This means that I cannot install that package unless:

The current latest happens to match or
I can guess which version it is supposed to be

It also results in automated tests such as travis failing after a time even if there have been zero code changes, e.g. a rebuild because of a documentation only change since the dependencies have moved on since the last time that there was a push to the project. This is an extra burden for the maintainers and tends to be a barrier for new contributors.
Describe the solution you'd like
I would like a version specifier of * to either result in the lock file being ignored for that package.
Describe alternatives you've considered
If a version specifier of * with a SHA in lock was an error then this would tend to force the original authors to address the issue by specifying the specific version - but may be frustrating.
Additional context
An example of this happening:
https://github.com/psf/requests-html/pull/338
Worker information
0.19s0.01s0.00s0.01s
system_info
Build system information
0.02s0.01s0.35s0.28s0.06s0.00s0.05s0.00s0.01s0.01s0.01s0.01s0.01s0.00s0.00s0.03s0.00s0.01s0.41s0.00s0.00s0.00s0.01s0.00s0.13s0.01s0.95s0.00s0.00s0.07s0.00s2.90s0.00s2.41s
docker_mtu
resolvconf
git.checkout
0.97s$ git clone --depth=50 https://github.com/psf/requests-html.git psf/requests-html
0.01s0.01s$ source ~/virtualenv/python3.6/bin/activate
$ python --version
Python 3.6.7
$ pip --version
pip 19.0.3 from /home/travis/virtualenv/python3.6.7/lib/python3.6/site-packages/pip (python 3.6)
install.1
0.61s$ pip install pipenv --upgrade-strategy=only-if-needed
37.24s$ pipenv install --dev
Courtesy Notice: Pipenv found itself running within a virtual environment, so it will automatically use that environment, instead of creating its own for any project. You can set PIPENV_IGNORE_VIRTUALENVS=1 to force pipenv to ignore that environment and create its own instead. You can set PIPENV_VERBOSITY=-1 to suppress this warning.
Installing dependencies from Pipfile.lock (7312a6)…
An error occurred while installing pluggy==0.6.0 --hash=sha256:7f8ae7f5bdf75671a718d2daf0a64b7885f74510bcd98b1a0bb420eb9a9d0cff! Will try again.
     ================================ 46/46 — 00:00:26
Installing initially failed dependencies…
[pipenv.exceptions.InstallError]:   File "/home/travis/virtualenv/python3.6.7/lib/python3.6/site-packages/pipenv/core.py", line 1874, in do_install
[pipenv.exceptions.InstallError]:       keep_outdated=keep_outdated
[pipenv.exceptions.InstallError]:   File "/home/travis/virtualenv/python3.6.7/lib/python3.6/site-packages/pipenv/core.py", line 1253, in do_init
[pipenv.exceptions.InstallError]:       pypi_mirror=pypi_mirror,
[pipenv.exceptions.InstallError]:   File "/home/travis/virtualenv/python3.6.7/lib/python3.6/site-packages/pipenv/core.py", line 859, in do_install_dependencies
[pipenv.exceptions.InstallError]:       retry_list, procs, failed_deps_queue, requirements_dir, **install_kwargs
[pipenv.exceptions.InstallError]:   File "/home/travis/virtualenv/python3.6.7/lib/python3.6/site-packages/pipenv/core.py", line 763, in batch_install
[pipenv.exceptions.InstallError]:       _cleanup_procs(procs, not blocking, failed_deps_queue, retry=retry)
[pipenv.exceptions.InstallError]:   File "/home/travis/virtualenv/python3.6.7/lib/python3.6/site-packages/pipenv/core.py", line 681, in _cleanup_procs
[pipenv.exceptions.InstallError]:       raise exceptions.InstallError(c.dep.name, extra=err_lines)
[pipenv.exceptions.InstallError]: ['Looking in indexes: https://pypi.python.org/simple', 'Collecting pluggy==0.6.0 (from -r /tmp/pipenv-03jpv10e-requirements/pipenv-3k4kv96o-requirement.txt (line 1))', '  Using cached https://files.pythonhosted.org/packages/ba/65/ded3bc40bbf8d887f262f150fbe1ae6637765b5c9534bd55690ed2c0b0f7/pluggy-0.6.0-py3-none-any.whl']
[pipenv.exceptions.InstallError]: ['THESE PACKAGES DO NOT MATCH THE HASHES FROM THE REQUIREMENTS FILE. If you have updated the package versions, please update the hashes. Otherwise, examine the package contents carefully; someone may have tampered with them.', '    pluggy==0.6.0 from https://files.pythonhosted.org/packages/ba/65/ded3bc40bbf8d887f262f150fbe1ae6637765b5c9534bd55690ed2c0b0f7/pluggy-0.6.0-py3-none-any.whl#sha256=e160a7fcf25762bb60efc7e171d4497ff1d8d2d75a3d0df7a21b76821ecbf5c5 (from -r /tmp/pipenv-03jpv10e-requirements/pipenv-3k4kv96o-requirement.txt (line 1)):', '        Expected sha256 7f8ae7f5bdf75671a718d2daf0a64b7885f74510bcd98b1a0bb420eb9a9d0cff', '             Got        e160a7fcf25762bb60efc7e171d4497ff1d8d2d75a3d0df7a21b76821ecbf5c5']
ERROR: ERROR: Package installation failed...

$ pipenv --support
Pipenv version: '2018.11.26'
Pipenv location: 'c:\\python38_64\\lib\\site-packages\\pipenv'
Python location: 'c:\\python38_64\\python.exe'
Python installations found:

3.8.0: C:\Python38_64\python.exe
3.7.4: C:\Python37\python.exe
3.7.4: C:\Python37-32\python.exe
3.6.5: C:\Python36_64\python.exe
2.7: C:\Python27\python.exe

PEP 508 Information:
{'implementation_name': 'cpython',
 'implementation_version': '3.8.0',
 'os_name': 'nt',
 'platform_machine': 'AMD64',
 'platform_python_implementation': 'CPython',
 'platform_release': '10',
 'platform_system': 'Windows',
 'platform_version': '10.0.18362',
 'python_full_version': '3.8.0',
 'python_version': '3.8',
 'sys_platform': 'win32'}

System environment variables:

ALLUSERSPROFILE
ANSICON
ANSICON_DEF
APPDATA
CAMLIBS
CHOCOLATEYINSTALL
CHOCOLATEYLASTPATHUPDATE
COMMONPROGRAMFILES
COMMONPROGRAMFILES(X86)
COMMONPROGRAMW6432
COMPUTERNAME
COMSPEC
CONEMUANSI
CONEMUANSILOG
CONEMUARGS
CONEMUARGS2
CONEMUBACKHWND
CONEMUBASEDIR
CONEMUBUILD
CONEMUCONFIG
CONEMUDIR
CONEMUDRAWHWND
CONEMUDRIVE
CONEMUHOOKS
CONEMUHWND
CONEMUPALETTE
CONEMUPID
CONEMUPROMPT0
CONEMUPROMPT1
CONEMUPROMPT2
CONEMUPROMPT3
CONEMUSERVERPID
CONEMUTASK
CONEMUWORKDIR
CONEMUWORKDRIVE
DRIVERDATA
HOMEDRIVE
HOMEPATH
IOLIBS
LOCALAPPDATA
LOGONSERVER
MAGICK_HOME
MOZ_PLUGIN_PATH
NUMBER_OF_PROCESSORS
ONEDRIVE
ONEDRIVECONSUMER
OS
PATH
PATHEXT
PROCESSOR_ARCHITECTURE
PROCESSOR_IDENTIFIER
PROCESSOR_LEVEL
PROCESSOR_REVISION
PROGRAMDATA
PROGRAMFILES
PROGRAMFILES(X86)
PROGRAMW6432
PROMPT
PSMODULEPATH
PUBLIC
SESSIONNAME
SYSTEMDRIVE
SYSTEMROOT
TEMP
TMP
USERDOMAIN
USERDOMAIN_ROAMINGPROFILE
USERNAME
USERPROFILE
VBOX_MSI_INSTALL_PATH
WINDIR
PIP_DISABLE_PIP_VERSION_CHECK
PYTHONDONTWRITEBYTECODE
PIP_SHIMS_BASE_MODULE
PIP_PYTHON_PATH
PYTHONFINDER_IGNORE_UNSUPPORTED

Pipenvûspecific environment variables:
Debugûspecific environment variables:

PATH: "C:\Program Files\Tesseract-OCR"\;C:\Program Files\ConEmu\ConEmu\Scripts;C:\Program Files\ConEmu;C:\Program Files\ConEmu\ConEmu;C:\ProgramData\DockerDesktop\version-bin;C:\Program Files\Docker\Docker\Resources\bin;C:\Program Files\ImageMagick-7.0.8-Q16;C:\Program Files (x86)\ImageMagick-7.0.8-Q16-HDRI;C:\Program Files (x86)\Common Files\Oracle\Java\javapath;C:\Program Files\ImageMagick-7.0.7-Q16-HDRI;C:\WINDOWS\system32;C:\WINDOWS;C:\WINDOWS\System32\Wbem;C:\WINDOWS\System32\WindowsPowerShell\v1.0\;C:\Program Files\TortoiseGit\bin;C:\Program Files\Git\cmd;C:\Program Files\Calibre2\;C:\Program Files\nodejs\;C:\Program Files\TortoiseSVN\bin;C:\Program Files\TortoiseHg\;C:\WINDOWS\System32\OpenSSH\;C:\Program Files\CMake\bin;E:\toolbuild\sK1_Project\UniConvertor-1.1.5\;E:\toolbuild\sK1_Project\UniConvertor-1.1.5\DLLs;C:\Program Files\doxygen\bin;C:\ProgramData\chocolatey\bin;C:\Python38_64\Scripts\;C:\Python38_64\;C:\python36_64\Scripts;C:\python36_64;C:\Users\Gadget\AppData\Local\Microsoft\WindowsApps;C:\Users\Gadget\AppData\Roaming\npm;C:\Users\Gadget\AppData\Local\Programs\MiKTeX 2.9\miktex\bin\x64\;C:\Users\Gadget\AppData\Local\Pandoc\;C:\Program Files (x86)\Nmap;C:\Users\Gadget\AppData\Local\GitHubCLI\bin;C:\Users\Gadget\AppData\Local\Microsoft\WindowsApps;;c:\python38_64\lib\site-packages\pywin32_system32

Sorry, I can't get what the point of the OP is. It looks to me that the lock file should be updated with the new hashes. The cause is because the package author has re-updated the artifact and the hash changes.

The point is that the package author has specified any version of the dependencies is suitable with * but at the same time that the package needs to have specific SHA-256 values - these are mutually contradictory. Worse there is no way to tell which package versions to install to get those values.
If the required version is * then the lock values should be ignored or auto-update!

@GadgetSteve your link An example of this happening: psf/requests-html#338 points to a pull request where the changes don't include any dependencies.
Perhaps if you included a Pipfile and Pipfile.lock or snippets therefrom, your concern would be easier to see?
Here's what I get if I include "any version" of a dependency:
> grep -C 6 requests Pipfile*
Pipfile-[requires]
Pipfile-python_version = "3.7"
Pipfile:requests = "*"

Pipfile.lock-        "requires": {
Pipfile.lock-            "python_version": "3.7",
Pipfile.lock:            "requests": "*"
Pipfile.lock-        },

Pipfile.lock:        "requests": {
Pipfile.lock-            "hashes": [
Pipfile.lock-                "sha256:11e007a8a2aa0323f5a921e9e6a2d7e4e67d9877e85773fba9ba6419025cbeb4",
Pipfile.lock-                "sha256:9cf5292fcd0f598c671cfc1e0d7d1a7f13bb8085e9a590f48c010551dc6c4b31"
Pipfile.lock-            ],
Pipfile.lock-            "version": "==2.22.0"
Pipfile.lock-        },

Looks like pipenv does the right thing － if there's * in Pipfile, then Pipfile.lock gets a specific version 2.22.0 and a set of hashes.

Hi Dima,
My problem occurred when I was committing a documentation only change to a project that I do not own or otherwise maintain. The original author specified that at least some of the dependencies were to be latest, i.e. “*” but the Pipfile.lock for those dependencies like yours below has hashes for the latest version dependencies – as a result the Travis build fails because the current latest version of the dependencies does not match that at the time that the Pipfile.lock was generated.
This behaviour means that any project with dependencies marked ‘*’  the Pipfile.lock will be incorrect and need to be regenerated every time that the external dependency is updated.
The closes analogy that I can come up with is telling people that they have to pay 25 euros (and that any denomination of notes and  other currencies are acceptable) and at the same time specifying the exact serial numbers of the notes to be used.
I feel that this places an unreasonable maintenance burden on the package authors and a hurdle for contributors if any packages are marked as “latest” as happened in my case – a simple documentation change has been blocked due to an external dependency having been updated.
The Pipfile for the project in question:
[[source]]
url = "https://pypi.python.org/simple"
verify_ssl = true
name = "pypi"
[packages]
requests = ""
pyquery = ""
fake-useragent = ""
parse = ""
"bs4" = ""
"w3lib" = ""
pyppeteer = ""
"rfc3986" = ""
requests-html = {path = "."}
lxml = {path = "c:/Users/Gadget/Downloads/lxml-4.4.1-cp38-cp38-win_amd64.whl"}
[dev-packages]
twine = ""
requests-file = ""
pytest = ""
e1839a8 = {path = ".",editable = true}
sphinx = ""
mypy = ""
pytest-asyncio = ""
psutil = ""
white = ""
[scripts]
tests = "pytest -v -m ok"
Which does not include the failing package pluggy which is a dependency of pytest which is a dependency for pytest-asyncio (so 3rd hand)
But  Pifile.lock has:
"pytest": {
"hashes": [
"sha256:062027955bccbc04d2fcd5d79690947e018ba31abe4c90b2c6721abec734261b",
"sha256:117bad36c1a787e1a8a659df35de53ba05f9f3398fb9e4ac17e80ad5903eb8c5"
],
"index": "pypi",
"version": "==3.4.2"
},
"pytest-asyncio": {
"hashes": [
"sha256:286b50773e996c80d894b95afaf45df6952408a67a59979ca9839f94693ec7fd",
"sha256:f32804bb58a66e13a3eda11f8942a71b1b6a30466b0d2ffe9214787aab0e172e"
],
"index": "pypi",
"version": "==0.8.0"
},
"pluggy": {
"hashes": [
"sha256:7f8ae7f5bdf75671a718d2daf0a64b7885f74510bcd98b1a0bb420eb9a9d0cff"
],
"version": "==0.6.0"
},
However the current versions are:
pytest-asyncio: Version: 0.10.0
pytest: Version: 5.2.2
pluggy: Version: 0.13.0
Hope that clarifies things.
Steve
From: Dima Tisnek<EMAIL_ADDRESS>Sent: 08 November 2019 06:59
To: pypa/pipenv<EMAIL_ADDRESS>Cc: Steve (Gadget) Barnes<EMAIL_ADDRESS>Mention<EMAIL_ADDRESS>Subject: Re: [pypa/pipenv] Outlaw packages with version =* from the lock file (#3997)
@GadgetStevehttps://github.com/GadgetSteve your link An example of this happening: psf/requests-html#338 points to a pull request where the changes don't include any dependencies.
Perhaps if you included a Pipfile and Pipfile.lock or snippets therefrom, your concern would be easier to see?
Here's what I get if I include "any version" of a dependency:

grep -C 6 requests Pipfile*

Pipfile-[requires]
Pipfile-python_version = "3.7"
Pipfile:requests = "*"
Pipfile.lock-        "requires": {
Pipfile.lock-            "python_version": "3.7",
Pipfile.lock:            "requests": "*"
Pipfile.lock-        },
Pipfile.lock:        "requests": {
Pipfile.lock-            "hashes": [
Pipfile.lock-                "sha256:11e007a8a2aa0323f5a921e9e6a2d7e4e67d9877e85773fba9ba6419025cbeb4",
Pipfile.lock-                "sha256:9cf5292fcd0f598c671cfc1e0d7d1a7f13bb8085e9a590f48c010551dc6c4b31"
Pipfile.lock-            ],
Pipfile.lock-            "version": "==2.22.0"
Pipfile.lock-        },
Looks like pipenv does the right thing － if there's * in Pipfile, then Pipfile.lock gets a specific version 2.22.0 and a set of hashes.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHubhttps://github.com/pypa/pipenv/issues/3997?email_source=notifications&email_token=ABKVUWWS7PLU5BKQHFJAWMDQSUE3PA5CNFSM4JCYHTMKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEDO5S3Q#issuecomment-551410030, or unsubscribehttps://github.com/notifications/unsubscribe-auth/ABKVUWR2R7UEYSC4MOEAS7DQSUE3PANCNFSM4JCYHTMA.

The lock file in the referenced psf/requests-html project only includes the hash for the source tarball of pluggy==0.6.0, but on Travis CI it is attempting to install the Python 3 binary wheel leading to the error about mismatched hashes.
Creating the environment locally using the following commands works as expected (only showing relevant output:)
> git clone git@github.com:psf/requests-html.git
Cloning into 'requests-html'...
...
> cd requests-html
> pipenv --python 3.6.7 # Same python version used in Travis CI
Creating a virtualenv for this project…
...
> pipenv install --dev --verbose
Installing dependencies from Pipfile.lock (7312a6)…
...
Found link https://files.pythonhosted.org/packages/ba/65/ded3bc40bbf8d887f262f150fbe1ae6637765b5c9534bd55690ed2c0b0f7/pluggy-0.6.0-py3-none-any.whl#sha256=e160a7fcf25762bb60efc7e171d4497ff1d8d2d75a3d0df7a21b76821ecbf5c5 (from https://pypi.org/simple/pluggy/) (requires-python:>=2.7, !=3.0.*, !=3.1.*, !=3.2.*, !=3.3.*), version: 0.6.0
  Found link https://files.pythonhosted.org/packages/11/bf/cbeb8cdfaffa9f2ea154a30ae31a9d04a1209312e2919138b4171a1f8199/pluggy-0.6.0.tar.gz#sha256=7f8ae7f5bdf75671a718d2daf0a64b7885f74510bcd98b1a0bb420eb9a9d0cff (from https://pypi.org/simple/pluggy/) (requires-python:>=2.7, !=3.0.*, !=3.1.*, !=3.2.*, !=3.3.*), version: 0.6.0
...
Checked 2 links for project 'pluggy' against 1 hashes (1 matches, 0 no digest): discarding 1 non-matches:
  https://files.pythonhosted.org/packages/ba/65/ded3bc40bbf8d887f262f150fbe1ae6637765b5c9534bd55690ed2c0b0f7/pluggy-0.6.0-py3-none-any.whl#sha256=e160a7fcf25762bb60efc7e171d4497ff1d8d2d75a3d0df7a21b76821ecbf5c5 (from https://pypi.org/simple/pluggy/) (requires-python:>=2.7, !=3.0.*, !=3.1.*, !=3.2.*, !=3.3.*)
Using version 0.6.0 (newest of versions: 0.6.0)
Collecting pluggy==0.6.0
...

As can be seen in output above both the wheel  and the source tar ball is found, and the source is used since it has the matching hash. If you set the PIP_ONLY_BINARY environment variable to :all: the source tarball is ignored and it will fail locally the same as it does within Travis CI.
So, either the Pipfile.lock needs to be updated to include the hash for the wheel so it can be installed within Travis CI; or the Travis CI build environment needs to be configured to be able to install using the source tarball (I'm not that familiar with Travis CI so not sure what this entails.) But this is not an issue with Pipenv.

Awesome investigation, @rmbrad
I wonder if pipenv purposefully keeps only the hash of the file it used during lock.
Or was it the case that when deps were locked, tarball was published but wheel was not?
I think (but need to verify) that other systems stamp all sources for given version and pipenv does too: https://github.com/oberdev/cgbot/blob/a48c79b42bcd4a2d91981bd91f3bbef25f1d6c53/Pipfile.lock#L35 where hashes for wheels for all platforms were stamped...

@dimaqq Thanks

I wonder if pipenv purposefully keeps only the hash of the file it used during lock.

I believe current versions of Pipenv should store hashes for all versions/platforms.

Or was it the case that when deps were locked, tarball was published but wheel was not?

Yeah, I'm pretty sure this is the case. The Pipfile.lock was last updated March 21, 2018, the wheels were added to PyPi on April 15, 2018.

Thanks @rmbrad , so I can conclude that this issue was not caused by Pipenv.
Any more thoughts @GadgetSteve ?

As Dima said – an awesome investigation from @rmbradhttps://github.com/rmbrad
Looking at the build error message (https://travis-ci.com/psf/requests-html/builds/132282995)  and expanding the install.1 tab I see that the pipenv version is 2018.11.26 – nearly a year ago but the latest release so an outdated pipenv (and the pip install pipenv --upgrade-strategy=only-if-needed install) is probably not at fault.
The fact that even on the retry the cached wheel is being used (see line 208 of the build). My guess is that when pipenv is looking for alternatives is does not issue the --no-cache-dir instruction to pip so if there is a single cached copy that comes back as the only option.
Is that a possibility for why this build fails?
Steve
From: Frost Ming<EMAIL_ADDRESS>Sent: 13 November 2019 04:08
To: pypa/pipenv<EMAIL_ADDRESS>Cc: Steve (Gadget) Barnes<EMAIL_ADDRESS>Mention<EMAIL_ADDRESS>Subject: Re: [pypa/pipenv] Outlaw packages with version =* from the lock file (#3997)
Thanks @rmbradhttps://github.com/rmbrad , so I can conclude that this issue was not caused by Pipenv.
Any more thoughts @GadgetStevehttps://github.com/GadgetSteve ?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHubhttps://github.com/pypa/pipenv/issues/3997?email_source=notifications&email_token=ABKVUWTXNIUAMSXZVWXM32TQTN4QTA5CNFSM4JCYHTMKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOED4Z3HI#issuecomment-553229725, or unsubscribehttps://github.com/notifications/unsubscribe-auth/ABKVUWQWTLJG5ETE43XSS6LQTN4QTANCNFSM4JCYHTMA.


Building boost

Hello vcpkg community.
I'm new to vcpkg and use to build boost the old way :-)
I spend two days trying to build boost in static+x86+x64+debug+release
I share my feedback and a working CMakeFile.txt here
https://github.com/iso8859/vcpkg-boost
A lot of reverse ingeniering was needed to obtain two working sln that can build un release and debug.
Sincerely,
Remi

Hi @iso8859, thanks for posting this issue. Boost has been upgraded. I have tested and boost can be installed and built successfully now. Could you please update to the latest version and try it again?

@iso8859, please reopen this issue if it still be a problem for you.


 You can
  further enhance your productivity with GIMP thanks to many customization
  options and 3rd party plugins.
commands:
  - gimp
snap-id:   KDHYbyuzZukmLhiogKiUksByRhXD2gYV
tracking:  stable
refreshed: 2017-12-11T17:39:25+01:00
installed:   2.8.22 (30) 142MB -
channels:
  stable:    2.8.22 (30) 142MB -
  candidate: 2.8.22 (25) 141MB -
  beta:      2.8.22 (25) 141MB -
  edge:      2.8.22 (30) 142MB -
corrado@corrado-p13-bb-0319:~$ inxi -SCGx
System:    Host: corrado-p13-bb-0319 Kernel: 4.15.0-12-generic x86_64
           bits: 64 gcc: 7.3.0
           Desktop: Gnome 3.28.0 (Gtk 3.22.28-1ubuntu3)
           Distro: Ubuntu Bionic Beaver (development branch)
CPU:       Dual core Intel Core i3-7100 (-MT-MCP-)
           arch: Skylake rev.9 cache: 3072 KB
           flags: (lm nx sse sse2 sse3 sse4_1 sse4_2 ssse3 vmx) bmips: 15648
           clock speeds: max: 3900 MHz 1: 800 MHz 2: 800 MHz 3: 800 MHz
           4: 800 MHz
Graphics:  Card: Intel HD Graphics 630 bus-ID: 00:02.0
           Display Server: x11 (X.Org 1.19.6 ) driver: i915
           Resolution<EMAIL_ADDRESS>           OpenGL: renderer: Mesa DRI Intel HD Graphics 630 (Kaby Lake GT2)
           version: 4.5 Mesa 18.0.0-rc4 Direct Render: Yes
corrado@corrado-p13-bb-0319:~$

Which version of core are you running? Can you post the output of snap version please?

I'm running snapd 2.32+18.04~pre5 and now
i know snapd 2.32+18.04~pre5 is known to be broken, an update is being prepared
[https://forum.snapcraft.io/t/gnome-calculator-problem/4579/2]
here is my snap version and my system. thanks.

corrado@corrado-p13-bb-0319:~$ snap version
snap    2.32+18.04~pre5
snapd   2.32+18.04~pre5
series  16
ubuntu  18.04
kernel  4.15.0-12-generic
corrado@corrado-p13-bb-0319:~$ inxi -Fx
System:    Host: corrado-p13-bb-0319 Kernel: 4.15.0-12-generic x86_64 bits: 64 gcc: 7.3.0
Desktop: Gnome 3.28.0 (Gtk 3.22.28-1ubuntu3)
Distro: Ubuntu Bionic Beaver (development branch)
Machine:   Device: desktop Mobo: ASRock model: H110M-G/M.2 serial: N/A
UEFI: American Megatrends v: P1.10 date: 05/11/2017
CPU:       Dual core Intel Core i3-7100 (-MT-MCP-) arch: Skylake rev.9 cache: 3072 KB
flags: (lm nx sse sse2 sse3 sse4_1 sse4_2 ssse3 vmx) bmips: 15648
clock speeds: max: 3900 MHz 1: 1020 MHz 2: 3215 MHz 3: 2713 MHz 4: 3176 MHz
Graphics:  Card: Intel HD Graphics 630 bus-ID: 00:02.0
Display Server: x11 (X.Org 1.19.6 ) driver: i915 Resolution<EMAIL_ADDRESS>OpenGL: renderer: Mesa DRI Intel HD Graphics 630 (Kaby Lake GT2)
version: 4.5 Mesa 18.0.0-rc4 Direct Render: Yes
Audio:     Card Intel Sunrise Point-H HD Audio driver: snd_hda_intel bus-ID: 00:1f.3
Sound: Advanced Linux Sound Architecture v: k4.15.0-12-generic
Network:   Card: Intel Ethernet Connection (2) I219-V driver: e1000e v: 3.2.6-k bus-ID: 00:1f.6
IF: enp0s31f6 state: up speed: 100 Mbps duplex: full mac: 70:85:c2:44:7b:86
Drives:    HDD Total Size: 1000.2GB (1.4% used)
ID-1: /dev/sda model: TOSHIBA_DT01ACA1 size: 1000.2GB
Partition: ID-1: / size: 16G used: 5.1G (35%) fs: ext4 dev: /dev/sda13
ID-2: swap-1 size: 8.59GB used: 0.00GB (0%) fs: swap dev: /dev/sda2
RAID:      No RAID devices: /proc/mdstat, md_mod kernel module present
Sensors:   System Temperatures: cpu: 37.0C mobo: N/A
Fan Speeds (in rpm): cpu: N/A
Info:      Processes: 243 Uptime: 2 min Memory: 1132.3/7680.8MB
Init: systemd runlevel: 5 Gcc sys: N/A Client: Shell (bash 4.4.181) inxi: 2.3.56
corrado@corrado-p13-bb-0319:~$

As you stated, snapd-2.32+18.04~pre5 is broken. This is your issue. As this is not a problem specifically with this GIMP snap, I'm closing this bug report.


[WIP] Save source URLs in the created OCI containers

Many of the Dockerfiles use curl, wget, docker ADD, and git commands to download software on the fly.
PR #2861 will turn all of those into docker ADD.
But it might still be useful to save what was in those commands in the image itself.
This rough and only partially working fix does that in a file called /source-info with the intent that a script can pull them out of the lkt cache (currently used for testing) or the docker OCI images which make up EVE-OS.
Note that currently we only see a subset of the containers (which is probably because I don't understand the WORKDIR etc commands in the docker files). FWIW we see
lfedge/eve-kernel:89cc42dbec95d32555f529f94209ab995b8f0b95-amd64
lfedge/eve-debug:1ff8d86b2bdf297c6e92a48cd328148f40a2cc5f-amd64
lfedge/eve-wwan:59d70945ed45fdffe7dd3c9036863ee08d7c8a1f-amd64
lfedge/eve-guacd:524bb18891fa4abeb1747ec0ce33547a1e107672-amd64
lfedge/eve-pillar:8478b60f30d411cb917ce0a86f24b57bda867374-amd64
lfedge/eve-vtpm:18482d1dcb43720c97772305b598c3300a4c192e-amd64
lfedge/eve-xen-tools:661deb835e2877de6ba8438a2d9a1d47bc5f6aa6-amd64
but not others like lfedge/eve-xen, uefi, u-boot, etc
I don't know if this can be related to the above is the kernel plus the service containers.

Is there a need for it? If, for argument's sake, we get all of the ADD working, then a good scanner should be able to read all of the ADD commands by scanning the Dockerfile itself.
I am somewhat concerned that we will forget to add things here and there.
FYI, Docker is working on a scanner for Dockerfiles, I will start looking at it.

Is there a need for it? If, for argument's sake, we get all of the ADD working, then a good scanner should be able to read all of the ADD commands by scanning the Dockerfile itself.
I am somewhat concerned that we will forget to add things here and there.
FYI, Docker is working on a scanner for Dockerfiles, I will start looking at it.

My question is whether folks want to be able to start with the binary image and whether having such annotations inside the image/containers makes this easier.
The ADDs make it easy once I have found the source commit for the github.com/lf-edge/eve but maybe that will always be easy? If so we do not need this.
It would provide some benefits until we have the ADD support for git commits, but if that is on its way, then no need to add this complexity now.

My question is whether folks want to be able to start with the binary image and whether having such annotations inside the image/containers makes this easier

To be honest, I agree with you. If you look, for example, at some work I did on kernel distribution (I am not all that good at kernel design), I included information about sources in OCI image labels, in configs, and in the filesystem itself. So I am all for having it in multiple places.
My primary concern is the human burden. if we have this source_info file (which I am in favour of), then it needs to be accurate. And if it is dependent on people remembering to add information to it in a Dockerfile, then I am concerned it will fall out of sync, someone will depend on it, and it will be wrong.
So if there is a way we can automate that process, then by all means, and let's include it in labels as well as config and on the filesystem and anywhere else we can think of.

Given #2861 this is no longer needed.


[Git-Scm] Initial commit logic

Discussion
This pull request seeks to add a new Git SCM library into Poakium monorepo, which should be a lightweight library for working easily with git commands but must not include all features in git. So Prior git knowledge is required.
Closes issue #1
Motivation and context
Providing a lightweight library for writing PHP applications using git commands
Types of changes

[ ] Bug fix (non-breaking change which fixes an issue)
[ ] Deprecation (un-wanted or renamed functionality that should be removed)
[x] New feature (non-breaking change which adds functionality)
[x] Breaking change (fix or feature that would cause existing functionality to change)

PR checklist

[x] My change requires a change to the documentation.
[ ] I have updated the documentation accordingly.
[x] I have read the CONTRIBUTING.md document.
[ ] I have added tests to cover my changes.

Git SCM is feature complete but ready to merge


Problem with colors when parameters contain object

Describe the bug
Logged messages with colors and objects do not display correctly on Debug Console. Messages without objects display correctly.
To Reproduce
import Debugger from 'debug';
const debug = Debugger('cva:init');
debug('Initializing');
debug({ a: 4 });

Log File
Relevant launch configuration
{
      "name": "Attach to Figma",
      "type": "chrome",
      "request": "attach",
      "address": "localhost",
      "port": 9222,
      "targetSelection": "pick",
      "pauseForSourceMap": true,
      "pathMapping": {
        "/file/": "${workspaceRoot}/",
        "../src/": "${workspaceRoot}/src/",
        "src/": "${workspaceRoot}/src/"
      },
      "outFiles": [
        "${workspaceFolder}/build/*.js",
        "${workspaceFolder}/build/*.js.map",
      ],
      "presentation": {
        "hidden": false,
        "group": "Figma",
        "order": 2,
      },
      "internalConsoleOptions": "openOnSessionStart"
    }

VS Code Version: 1.74.2
Additional context

NOTE: I added BEFORE FORMAT and AFTER FORMAT to the debug library to check what it was doing

EDIT
An easier way to reproduce. Type this directly on the debug console:
console.log('%cThis %cWorks %c +1ms', 'color: #00CC00', 'color: inherit', 'color: #00CC00');
console.log('%cThis %cDOES NOT %c +1ms %o', 'color: #00CC00', 'color: inherit', 'color: #00CC00', []);

Thanks for creating this issue! It looks like you may be using an old version of VS Code, the latest stable release is 1.74.3. Please try upgrading to the latest version and checking whether this issue remains.
Happy Coding!


add conditional for zipmap function

fixes #208
zipmap requires that the two lists are the same length

zipmap constructs a map from a list of keys and a corresponding list of values.
zipmap(keyslist, valueslist)
Both keyslist and valueslist must be of the same length. keyslist must be a list of strings, while valueslist can be a list of any type.

/test all

/test all

/test all

LGTM (assuming tests pass)


Improve entry point documentation

As someone interested in program traces, I'd like to have a better documentation of the entry points in order to not forget what I wanted to do.

Describe the solution you'd like
There is currently some information missing in the documentation:

Specific examples for the entry points

add more
make them a specific code snippet

What part of the system are we learning about here?
How can I group these entries? How to tackle this?
When looking at the generated stuff and find out some insights: how can I document these and add that to the data structure?

add names of related packages
use colors
...

Now part of #61


feat: implement substrait join filter support

Which issue does this PR close?

Closes #6866 .
Rationale for this change

Explained in issue.
What changes are included in this PR?

Parse DF join filter into Substrait's post_join_filter in producer
Parse post_join_filter into join filter in consumer
Test cases:

non-empty join expression, non-empty filter
empty join expression, non-empty filter
query with exists clause

Are these changes tested?

Yes.
Please note that if a test case includes subquery aliases, the results will not be correct due to issue #6867 .
Are there any user-facing changes?
No

Does anyone know what's the difference between the tests/roundtrip_logical_plan.rs file and the tests/cases/roundtrip_logical_plan.rs file?

@waynexia fyi

Does anyone know what's the difference between the tests/roundtrip_logical_plan.rs file and the tests/cases/roundtrip_logical_plan.rs file?

I just realized we have two different case files 🤣 It looks like this is a mistake from https://github.com/apache/arrow-datafusion/pull/6604. I'll reorganize those test cases later when I split our consumer/producer implementation into functionality-grouped style. I believe there are many duplications...

I just realized we have two different case files 🤣 It looks like this is a mistake from https://github.com/apache/arrow-datafusion/pull/6604. I'll reorganize those test cases later when I split our consumer/producer implementation into functionality-grouped style. I believe there are many duplications...

I took a quick look at it looks to me like the tests are entirely duplicated. Proposed removing them here: https://github.com/apache/arrow-datafusion/pull/6894


Kinnison/retry downloads

In an attempt to close #1722 as a way to fix #1667, fix #1243, and to fix #2071 more fully, add support for cleanly retrying downloads a fixed number of times.
Also this contains a small cleanup which means we finalise the download tracker properly on errors

@payload Thanks for the review, is there anything else you wanted to query?


[$500] [Remove Free Workspace Creation] Update Welcome Message on NewDot

Held on https://github.com/Expensify/App/issues/37149 so that the new notifications are in place on the server
Held on https://github.com/Expensify/App/issues/37151 so that all collect policies created in NewDot are accessible in NewDot

Update the workspace.inviteMessage.welcomeNote translation key in en.ts and es.ts to be:
#[senders display name] ([senders login]) invited you to Expensify
Hi there -

To join "[workspace name]", [click here](link) to start tracking your expenses!

They also added the message:
[Input message]

Additionally, here is the workspace description:
[Input description]

The first line of the message must be proceeded with the "#" so that it utilizes the backend functionality for custom subject lines (eg. the first line of the message gets parsed out and used as the subject for email notifications)
The "[Input message]" part of the message template is what currently exists in workspace.inviteMessage.welcomeNote
The template will need some new variables:

Senders display name and login
Workspace description

Upwork Automation - Do Not Edit

Upwork Job URL: https://www.upwork.com/jobs/~01b0b03e2c9b6c2e93
Upwork Job ID:<PHONE_NUMBER>147461632
Last Price Increase: 2024-02-26

reviewing

Still held on https://github.com/Expensify/App/issues/37151 and https://github.com/Expensify/App/issues/37149

https://github.com/Expensify/App/issues/37151 and https://github.com/Expensify/App/issues/37149 were deployed to prod yesterday, so you can proceed with proposal review @situchan!

@situchan will you be able to complete the proposal review today?

yes, please remove HOLD from title.

Yep, I've asked to confirm on that in Slack in the project channel here before I do: https://expensify.slack.com/archives/C036QM0SLJK/p1709723299888989

I've taken it off HOLD.

This is feature request but not dib issue.
I recommend @dukenv0307 since they provided the most accurate solution than others.
Proposal: https://github.com/Expensify/App/issues/37152#issuecomment-1964336610
🎀 👀 🎀 C+ reviewed

@dukenv0307 can we get an ETA on this PR please? Thanks!

I can take over this issue as a C+ reviewer because @situchan is OOO in April

@situchan is out OOO, reassigning a C+ via the auto-assigner for fairness.

@dukenv0307 any update on the PR?

Done!

@bfitzexpensify can you take care of prepping this issue for payment?

Payment complete.
This wasn't really a bug, and I don't see a need for a specific regression test for this. Closing this out.


Do not link to ndjson[dot]org in README.md

The ndjson[dot]org website contains malware. We should not link to it.
See https://github.com/ndjson/ndjson.github.io/issues/24

🤔 What's changed?

⚡ What's your motivation?

🏷 What kind of change is this?

:book: Documentation (improvements without changing code)
:bank: Refactoring/debt/DX (improvement to code design, tooling, etc. without changing behaviour)
:bug: Bug fix (non-breaking change which fixes a defect)
:zap: New feature (non-breaking change which adds new behaviour)
:boom: Breaking change (incompatible changes to the API)

♻ Anything particular you want feedback on?

📋 Checklist:

[x] I agree to respect and uphold the Cucumber Community Code of Conduct
[ ] I've changed the behaviour of the code

[ ] I have added/updated tests to cover my changes.

[ ] My change requires a change to the documentation.

[ ] I have updated the documentation accordingly.

[ ] Users should know about my change

[ ] I have added an entry to the "Unreleased" section of the CHANGELOG, linking to this pull request.

This text was originally generated from a template, then edited by hand. You can modify the template here.

Oh lovely.
But looks like we could switch to jsonlines.