gnome.gnome-todo: 40.0 -> 40.1

Automatic update generated by nixpkgs-update tools. This update was made based on information from passthru.updateScript.
meta.description for gnome.gnome-todo is: "Personal task manager for GNOME"
meta.homepage for gnome.gnome-todo is: "https://wiki.gnome.org/Apps/Todo"
meta.changelog for gnome.gnome-todo is: ""
Updates performed

Ran passthru.UpdateScript

To inspect upstream changes
Impact

Checks done (click to expand)

built on NixOS

The tests defined in passthru.tests, if any, passed

/nix/store/p47a446fqlpw9yjbwg81jqkjvs510ird-gnome-todo-40.1/bin/gnome-todo passed the binary check.

/nix/store/p47a446fqlpw9yjbwg81jqkjvs510ird-gnome-todo-40.1/bin/.gnome-todo-wrapped passed the binary check.

2 of 2 passed binary check by having a zero exit code.

0 of 2 passed binary check by having the new version present in output.

found 40.1 with grep in /nix/store/p47a446fqlpw9yjbwg81jqkjvs510ird-gnome-todo-40.1

found 40.1 in filename of file in /nix/store/p47a446fqlpw9yjbwg81jqkjvs510ird-gnome-todo-40.1

directory tree listing: https://gist.github.com/7b88b52977644acd3dafd80930e9a33e

du listing: https://gist.github.com/8d1c3e2bebb5e61dd67c03938f31bd56

Rebuild report (if merged into master) (click to expand)

3 total rebuild path(s)

1 package rebuild(s)

1 x86_64-linux rebuild(s)
1 i686-linux rebuild(s)
0 x86_64-darwin rebuild(s)
1 aarch64-linux rebuild(s)

First fifty rebuilds by attrpath
gnome.gnome-todo

Instructions to test this update (click to expand)

Either download from Cachix:
nix-store -r /nix/store/p47a446fqlpw9yjbwg81jqkjvs510ird-gnome-todo-40.1 \
  --option binary-caches 'https://cache.nixos.org/ https://nix-community.cachix.org/' \
  --option trusted-public-keys '
  nix-community.cachix.org-1:mB9FSh9qf2dCimDSUo8Zy7bkq5CX+/rkCWyvRCYg3Fs=
  cache.nixos.org-1:6NCHdD59X431o0gWypbMrAURkbJ16ZPMQFGspcDShjY=
  '

(The Cachix cache is only trusted for this store-path realization.)
For the Cachix download to work, your user must be in the trusted-users list or you can use sudo since root is effectively trusted.
Or, build yourself:
nix-build -A gnome.gnome-todo https://github.com/r-ryantm/nixpkgs/archive/a8d978895402236a9ea112ee7fb238be6b45110d.tar.gz

After you've downloaded or built it, look at the files and if there are any, run the binaries:
ls -la /nix/store/p47a446fqlpw9yjbwg81jqkjvs510ird-gnome-todo-40.1
ls -la /nix/store/p47a446fqlpw9yjbwg81jqkjvs510ird-gnome-todo-40.1/bin

Pre-merge build results
We have automatically built all packages that will get rebuilt due to
this change.
This gives evidence on whether the upgrade will break dependent packages.
Note sometimes packages show up as failed to build independent of the
change, simply because they are already broken on the target branch.
Result of nixpkgs-review run on x86_64-linux 1

1 package built:

gnome.gnome-todo

Maintainer pings
cc @hedning @jtojnar @dasj19 @maxeaubrey for testing.

Result of nixpkgs-review pr 127223 at a8d97889 run on x86_64-linux 1

1 package built successfully:

gnome.gnome-todo

2 suggestions:

warning: unused-argument
Unused argument: fetchpatch.
Near pkgs/desktops/gnome/apps/gnome-todo/default.nix:4:3:
  |
4 | , fetchpatch
  |   ^

warning: stale-substitute
Stale substituteInPlace detected.
substituteStream(): WARNING: pattern 'Gtk-3.0' doesn't match anything in file 'src/meson.build'
Near pkgs/desktops/gnome/apps/gnome-todo/default.nix:79:0:
   |
79 |     description = "Personal task manager for GNOME";
   | ^

Looks like some dependency might be improperly declared, cannot reproduce that locally.
[39/216] Compiling C object src/plugins/libplugins.a.p/eds_gtd-plugin-eds.c.o
FAILED: src/plugins/libplugins.a.p/eds_gtd-plugin-eds.c.o
gcc -Isrc/plugins/libplugins.a.p -Isrc/plugins -I../src/plugins -I../src/animation -I../src/core -Isrc/gui -I../src/gui -I../src/models -Isrc -I../src -Isrc/plugins/all-tasks-panel -Isrc/plugins/background -Isrc/plugins/dark-theme -Isrc/plugins/eds -Isrc/plugins/inbox-panel -Isrc/plugins/next-week-panel -Isrc/plugins/night-light -Isrc/plugins/peace -Isrc/plugins/task-lists-workspace -Isrc/plugins/today-panel -Isrc/plugins/welcome -I/nix/store/fp0r3qz04wq4gx4jar1cp5xn9cm834n4-glib-2.68.2-dev/include/glib-2.0 -I/nix/store/24lgqdbdzy31k0i2dh6s51g2ayy6cpyl-glib-2.68.2/lib/glib-2.0/include -I/nix/store/fp0r3qz04wq4gx4jar1cp5xn9cm834n4-glib-2.68.2-dev/include -I/nix/store/zpdm1hfjb9anmi89pssg1mryakgpjmfm-gtk4-4.2.1-dev/include/gtk-4.0 -I/nix/store/60ncgyr2anh1r1h7c7i7p1hz3p56sg0w-cairo-1.16.0-dev/include/cairo -I/nix/store/fqfp27bm34jsis1bbdxfcl2ca9k7crwi-freetype-2.10.4-dev/include/freetype2 -I/nix/store/fqfp27bm34jsis1bbdxfcl2ca9k7crwi-freetype-2.10.4-dev/include -I/nix/store/r16shzjkyj539hyzr3m7v374mkiy87qd-gdk-pixbuf-2.42.6-dev/include/gdk-pixbuf-2.0 -I/nix/store/83rl6vmzv2b7ib2glaa37mlkxzp53p9b-graphene-1.10.6/include/graphene-1.0 -I/nix/store/83rl6vmzv2b7ib2glaa37mlkxzp53p9b-graphene-1.10.6/lib/graphene-1.0/include -I/nix/store/x805vlv62fwqw2k0sskfg7zayshjhf71-pango-1.48.4-dev/include/pango-1.0 -I/nix/store/6j9vj5g76sc31ff9n40vjf79kygjyzj9-harfbuzz-2.8.0-dev/include/harfbuzz -I/nix/store/x1dazris88wqm2pk056rznfn2xn0f2jy-vulkan-headers-<IP_ADDRESS>/include -I/nix/store/snlp941gkskzx3vkdr1aja82pssbn0mn-libadwaita-1.0.0-alpha.1-dev/include/libadwaita-1 -I/nix/store/flypwmc91ql535dz3w4bbf6gi3lqg97n-gnome-online-accounts-3.40.0-dev/include/goa-1.0 -I/nix/store/4apz00q80672anyy2xh6a2aycziiwawv-gnome-online-accounts-3.40.0/lib/goa-1.0/include -I/nix/store/ljmdsq13db1zrz447lzm57xm0w52xhfy-libpeas-1.30.0-dev/include/libpeas-1.0 -I/nix/store/0s07hiwij5jccxa5xm76nr70lsh6xdwp-gobject-introspection-1.68.0-dev/include/gobject-introspection-1.0 -I/nix/store/zlnk3z3rn71vxdd13zsd3mxbbh6s5xda-libportal-0.4-dev/include -I/nix/store/k80ywj5pxlkk58v95pw8lya44fbd9wnh-evolution-data-server-3.40.2-dev/include/evolution-data-server -I/nix/store/8hbgxbz6xpp6np8592ljl37i4ialx3sf-libsecret-0.20.4-dev/include/libsecret-1 -I/nix/store/qpbrw264lk70kgd2y8cll5igd9hxxq0p-libical-3.0.10-dev/include -I/nix/store/r0ii9hivq8zzjyz99343apkmxflf605z-libsoup-2.72.0-dev/include/libsoup-2.4 -I/nix/store/63v367962b0glfq2i11r5y0xs0baykcj-libxml2-2.9.12-dev/include/libxml2 -fdiagnostics-color=always -pipe -D_FILE_OFFSET_BITS=64 -Wall -Winvalid-pch -DHAVE_CONFIG_H -fPIC -pthread -mfpmath=sse -msse -msse2 -mfpmath=sse -msse -msse2 -MD -MQ src/plugins/libplugins.a.p/eds_gtd-plugin-eds.c.o -MF src/plugins/libplugins.a.p/eds_gtd-plugin-eds.c.o.d -o src/plugins/libplugins.a.p/eds_gtd-plugin-eds.c.o -c ../src/plugins/eds/gtd-plugin-eds.c
In file included from ../src/plugins/eds/gtd-plugin-eds.h:21,
                 from ../src/plugins/eds/gtd-plugin-eds.c:21:
../src/gnome-todo.h:24:10: fatal error: gtd-enum-types.h: No such file or directory
   24 | #include "gtd-enum-types.h"
      |          ^~~~~~~~~~~~~~~~~~
compilation terminated.

Looks like some dependency might be improperly declared, cannot reproduce that locally.
[39/216] Compiling C object src/plugins/libplugins.a.p/eds_gtd-plugin-eds.c.o
FAILED: src/plugins/libplugins.a.p/eds_gtd-plugin-eds.c.o
gcc -Isrc/plugins/libplugins.a.p -Isrc/plugins -I../src/plugins -I../src/animation -I../src/core -Isrc/gui -I../src/gui -I../src/models -Isrc -I../src -Isrc/plugins/all-tasks-panel -Isrc/plugins/background -Isrc/plugins/dark-theme -Isrc/plugins/eds -Isrc/plugins/inbox-panel -Isrc/plugins/next-week-panel -Isrc/plugins/night-light -Isrc/plugins/peace -Isrc/plugins/task-lists-workspace -Isrc/plugins/today-panel -Isrc/plugins/welcome -I/nix/store/fp0r3qz04wq4gx4jar1cp5xn9cm834n4-glib-2.68.2-dev/include/glib-2.0 -I/nix/store/24lgqdbdzy31k0i2dh6s51g2ayy6cpyl-glib-2.68.2/lib/glib-2.0/include -I/nix/store/fp0r3qz04wq4gx4jar1cp5xn9cm834n4-glib-2.68.2-dev/include -I/nix/store/zpdm1hfjb9anmi89pssg1mryakgpjmfm-gtk4-4.2.1-dev/include/gtk-4.0 -I/nix/store/60ncgyr2anh1r1h7c7i7p1hz3p56sg0w-cairo-1.16.0-dev/include/cairo -I/nix/store/fqfp27bm34jsis1bbdxfcl2ca9k7crwi-freetype-2.10.4-dev/include/freetype2 -I/nix/store/fqfp27bm34jsis1bbdxfcl2ca9k7crwi-freetype-2.10.4-dev/include -I/nix/store/r16shzjkyj539hyzr3m7v374mkiy87qd-gdk-pixbuf-2.42.6-dev/include/gdk-pixbuf-2.0 -I/nix/store/83rl6vmzv2b7ib2glaa37mlkxzp53p9b-graphene-1.10.6/include/graphene-1.0 -I/nix/store/83rl6vmzv2b7ib2glaa37mlkxzp53p9b-graphene-1.10.6/lib/graphene-1.0/include -I/nix/store/x805vlv62fwqw2k0sskfg7zayshjhf71-pango-1.48.4-dev/include/pango-1.0 -I/nix/store/6j9vj5g76sc31ff9n40vjf79kygjyzj9-harfbuzz-2.8.0-dev/include/harfbuzz -I/nix/store/x1dazris88wqm2pk056rznfn2xn0f2jy-vulkan-headers-<IP_ADDRESS>/include -I/nix/store/snlp941gkskzx3vkdr1aja82pssbn0mn-libadwaita-1.0.0-alpha.1-dev/include/libadwaita-1 -I/nix/store/flypwmc91ql535dz3w4bbf6gi3lqg97n-gnome-online-accounts-3.40.0-dev/include/goa-1.0 -I/nix/store/4apz00q80672anyy2xh6a2aycziiwawv-gnome-online-accounts-3.40.0/lib/goa-1.0/include -I/nix/store/ljmdsq13db1zrz447lzm57xm0w52xhfy-libpeas-1.30.0-dev/include/libpeas-1.0 -I/nix/store/0s07hiwij5jccxa5xm76nr70lsh6xdwp-gobject-introspection-1.68.0-dev/include/gobject-introspection-1.0 -I/nix/store/zlnk3z3rn71vxdd13zsd3mxbbh6s5xda-libportal-0.4-dev/include -I/nix/store/k80ywj5pxlkk58v95pw8lya44fbd9wnh-evolution-data-server-3.40.2-dev/include/evolution-data-server -I/nix/store/8hbgxbz6xpp6np8592ljl37i4ialx3sf-libsecret-0.20.4-dev/include/libsecret-1 -I/nix/store/qpbrw264lk70kgd2y8cll5igd9hxxq0p-libical-3.0.10-dev/include -I/nix/store/r0ii9hivq8zzjyz99343apkmxflf605z-libsoup-2.72.0-dev/include/libsoup-2.4 -I/nix/store/63v367962b0glfq2i11r5y0xs0baykcj-libxml2-2.9.12-dev/include/libxml2 -fdiagnostics-color=always -pipe -D_FILE_OFFSET_BITS=64 -Wall -Winvalid-pch -DHAVE_CONFIG_H -fPIC -pthread -mfpmath=sse -msse -msse2 -mfpmath=sse -msse -msse2 -MD -MQ src/plugins/libplugins.a.p/eds_gtd-plugin-eds.c.o -MF src/plugins/libplugins.a.p/eds_gtd-plugin-eds.c.o.d -o src/plugins/libplugins.a.p/eds_gtd-plugin-eds.c.o -c ../src/plugins/eds/gtd-plugin-eds.c
In file included from ../src/plugins/eds/gtd-plugin-eds.h:21,
                 from ../src/plugins/eds/gtd-plugin-eds.c:21:
../src/gnome-todo.h:24:10: fatal error: gtd-enum-types.h: No such file or directory
   24 | #include "gtd-enum-types.h"
      |          ^~~~~~~~~~~~~~~~~~
compilation terminated.

https://gitlab.gnome.org/GNOME/gnome-todo/-/issues/380

Damn, this is sometimes working and sometimes failing.. I think it's because gtd-enum-types.h is generated via a template:
https://gitlab.gnome.org/GNOME/gnome-todo/blob/16762d11f79cc6d04a104d9cd4baf1eb5b0c8a75/src/gtd-enum-types.c.template
And it's not always generated before it's needed for compilation.. Not sure how to report this upstream.

Template should not matter, it uses mkenums like anything else. More likely is just underspecified dependency as mentioned in https://gitlab.gnome.org/GNOME/gnome-todo/-/issues/380#note_1251807.

Looking at the source code, the fix should not be that hard https://github.com/NixOS/nixpkgs/pull/136519#issuecomment-912128166


prevent drag drop on particular column using slickgrid

Hi,
I want to avoid first column not to be drag.
'enableColumnReorder' :false is working for all columns.
I want only one column to disable column reorder.

It's not hard to disable drag on the first column, but other columns can still be dragged to the left of it. That behaviour is quite hard to prevent. Is this worth pursuing?


Finder: When performing some operations, items become removed from the weapon browser

Not sure how to reproduce yet, but they will disappear.

Haven't seen this happen in some time; perhaps inadvertently fixed?


fatal: Cannot setup tracking information; starting point 'remotes/svn/dev' is not a branch.

When testing https://svn.code.sf.net/p/svn2gitnetclassicstructure/code/ got following errrors:
fatal: Cannot setup tracking information; starting point 'remotes/svn/dev' is not a branch.
********************************************************************
svn2git warning: Tracking remote SVN branches is deprecated.
In a future release local branches will be created without tracking.
If you must resync your branches, run: svn2git --rebase
********************************************************************
error: pathspec 'dev' did not match any file(s) known to git.
fatal: Cannot setup tracking information; starting point 'remotes/svn/dev@1' is not a branch.
error: pathspec 'dev@1' did not match any file(s) known to git.

Fixed by https://github.com/mazong1123/svn2gitnet/pull/27


Rename x86 source files with instruction set version.

This should make things a bit clearer when reviewing build scripts.
I fully expect to rebase if other PRs are merged ahead of this one.

Rebased.

Rebased.

@Dead2 any chance on getting this merged soon?


Customise which mutations / queries are generated

We are looking for a way to customise which CRUD operations are created on a per model basis. For example, We might not want to offer a delete mutations at all on a certain model.
I know I could restrict the API to only super admins or something, by using the
/// @PrismaAppSync.mutation: '@@adminsOnly'

However, we would love to be able to have the generated docs etc correctly show that the delete mutation should not be used.

Giving more flexibility around the CRUD operations is something I’d be interested in supporting in the future.
The team at Prisma have been working on ways to support custom fields and models directives https://github.com/prisma/prisma/issues/3102. Ideally, I would like to wait for this to be released before offering more advanced ways to customise the output.
// something like this for example, would be great:
model Post @aws_auth(cognito_groups: ["admin"]) @crud({ delete: false }) {
    title
}

Another option (in case support for custom directives takes too long to arrive) is to update the current implementation based AST comments (as per what you’ve suggested).
I am currently focusing on a pretty big rewrite of the Client API. Once done, I’ll give this another look.

Sounds good! I think if you are thinking of going that route it might be aligning it to the amplify model directive.
something like
type Post @model(queries: { get: "post" }, mutations: null, subscriptions: null) {
  id: ID!
  title: String!
  tags: [String!]!
}

Ah yes, good reference indeed!


Don't mark messages as read in search view

Splitting out one of the several areas described in #10886 :
When I do a search, I'm typically looking for a specific old conversation I have in mind. But if I have unread messages and some of them happen to match the search query, they show up in the results... and then scrolling through the results to find the conversation I want goes and marks those messages read, which may be scattered across a wide range of different conversations.
If I don't want to risk completely losing those conversations (i.e. never becoming aware of them, because they got marked as read before I looked at them), this means I have to carefully inspect all the messages I'm scrolling past, watching for unread markers, making sure to spot them before they disappear.
Doing that is pretty much incompatible with a high-quality search experience -- I'm spending more effort preventing the search flow from causing me data loss than I am actually looking at the results I was looking for.
The simplest fix would be to make a search narrow simply not cause messages to get marked as read. I think I do pretty much never want messages to get read by virtue of seeing them in search results -- I only ever want that when reading in a more coherently threaded context. Not sure what to do about showing unread-markers (which then don't go away, unlike in other narrows), or not showing them (making it look like they're all already read, which could be misleading or confusing.)
/cc @rishig

I agree we should fix this; it's quite annoying (for me, I see it sometimes when searching for a word that appears in one of my muted streams).  It might not be that hard.  This is a duplicate of https://github.com/zulip/zulip/issues/9893 BTW, which has a PR https://github.com/zulip/zulip/pull/9908 that I think mostly doesn't address the main issue here aside from a bit of code in the first commit or two?  Unfortunately something that we lost track of when I got sick last summer.
A few notes on implementation strategy:

For reproducing the situation consistently in development, we can use manage.py mark_all_messages_unread to make all messages unread in the local Zulip history.  Might want to do manage.py populate_db -n10000 first to rebuild the local database with a lot of history too so words are more likely to appear in multiple messages.
I like Greg's proposal to show the markers for which messages are unread, but just disable the code for marking messages as read when you scroll past them when in a search view.  We'll want to have a way to check whether a narrow is a search; I think that can be current_msg_list.is_search() for now but we'll likely want to expand the concept to cover additional search narrows as well.  (I think the is_reading_mode code in #9908 is helpful here).
For the narrowing scroll position, I think we might end up wanting need to send anchor: 100000000 and use_first_unread_anchor: false when doing this specific case in the call to message_fetch.load_messages_for_narrow (i.e. always landing at your latest messages, rather than on the first unread message like we do for other narrows).  Probably actual changes go in maybe_add_local_messages?  Not sure.

@zulipbot claim

@zulipbot I am still working on it. Exploring the codebase and PR of steve

OK.  I think Steve's PR is less relevant and https://github.com/zulip/zulip/issues/12556#issuecomment-501101991 is what you need to understand to work on this.
For where the code actually marks things as read, it's:

The call to unread_ops.process_visible in message_scroll.js (for when the bottom enters view)
The call to unread_ops.notify_server_messages_read in pointer.js (for when you scroll over a message).

@zulipbot claim I still intend to work on it and am exploring it along with other issues so taking some time.


Fixed install-binary.sh when wget is used

Install failed on a system without curl, since the wget command used to retrieve latest version doesn't grep for the detected OS, and so returns a URL for every available OS, which subsequently causes wget to fail.
This patch corrects this issue :)

Close due to archiving repository.
Sorry for not presenting so long. I've buried myself into another project and don't have more time to work on this.
Please consider other working forks like quintush/helm-unittest.


NLog ApplicationInsightsTarget Flush should wait for completion

DefaultFlushDelay is 30 secs, and when flushed manually, then it happens in async-style, so one has to manually wait as specified in the documentation:
https://docs.microsoft.com/en-us/azure/application-insights/app-insights-api-custom-events-metrics#flushing-data
Since it is not currently possible to know when a Flush-operation actually completes, then one just have to make a quick guess of how long to wait, but also not too long.
See also https://stackoverflow.com/questions/49514679/no-log-entries-in-azure-application-insights-using-microsoft-applicationinsights

The most optimal thing would be to have a FlushAsync-method. See also https://github.com/Microsoft/ApplicationInsights-dotnet/issues/482


Typo in repo description

A tiny web application to invite a user info your slack team.
Should be changed to user into.

I fixed it. :)


mod_redirect: change callback point #228

Codecov Report

Merging #234 into develop will decrease coverage by 0.03%.
The diff coverage is 100%.

@@             Coverage Diff             @@
##           develop     #234      +/-   ##
===========================================
- Coverage    52.98%   52.95%   -0.04%
===========================================
  Files          219      219
  Lines        21735    21735
===========================================
- Hits         11517    11510       -7
- Misses        8912     8918       +6
- Partials      1306     1307       +1

Impacted Files
Coverage Δ

bfe_modules/mod_redirect/mod_redirect.go
61.9% <100%> (ø)
:arrow_up:

bfe_websocket/server_conn.go
72.72% <0%> (-3.79%)
:arrow_down:

bfe_http2/writesched.go
79.38% <0%> (-1.53%)
:arrow_down:

bfe_spdy/server_conn.go
78.53% <0%> (ø)
:arrow_up:

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 bcfcbf4...15bd1cf. Read the comment docs.


flux v1 to v2

Hello,
Trying to migrate from flux v1 to v2.
In flux v1, all my apps and infra compoenents were deployed by flux as hemreleases (from git.path=/helm) of my infra repo.
I'm struggling to get flux v2 to deploy the helmreleases into my cluster.
Still unclear about  the layout should be?

i bootstrapped fluxv2 using my infra repo app-mkt-infra repo)  i plan to use the same repo to to host  my apps/infrastructure helm charts in this same repo.
to begin with i created a helmrelease for my infrastructure component ( kong) using the same SourceRef(config repo) which is used to bootstrap flux. here's the helmrelease definition. this definition is saved as kong.yaml in clusters/production/flux-system/kong.yaml.
in kustomization.yaml, i added kong.yaml as the resource.

apiVersion: helm.fluxcd.io/v1
kind: HelmRelease
metadata:
name: kong
namespace: infra-kong
annotations:
fluxcd.io/automated: "false"
filter.fluxcd.io/chart-image: semver:~0.4
spec:
releaseName: kong
chart:
sourceRef:
kind: GitRepository
name: flux-system
install:
createNamespace: true
interval: 10m0s
values:
cassandra:
image: cassandra
tag: 3.11.2
imagePullPolicy: IfNotPresent
$ cat kustomization.yaml
$  cat kustomization.yaml
apiVersion: kustomize.config.k8s.io/v1beta1
kind: Kustomization
resources:

gotk-components.yaml
gotk-sync.yaml
- kong.yaml

i cant get flux to deploy this helmrelease
$ flux get all
NAME                            READY   MESSAGE                         REVISION        SUSPENDED
gitrepository/flux-system       True    Fetched revision: prod/2f99aa1  prod/2f99aa1    False
NAME                            READY   MESSAGE                                                                                REVISION                                        SUSPENDED
kustomization/flux-system       False   HelmRelease/infra-kong/kong dry-run failed, error: failed to create typed patch object: .spec.install: field not declared in schema      prod/14e807bf5969fcafbbccdb02a9683e6f2817b72c   False
any idea how to get the helmreleases deployed.
Any help would be greatly appreciated.
Thanks,
Venu
i added

Your apiVersion refers to the API version of the helm-operator, and should be changed to helm.toolkit.fluxcd.io/v2beta1 for the helm-controller. See also this sample: https://github.com/fluxcd/helm-controller/blob/main/config/samples/helm_v2beta1_helmrelease_gitrepository.yaml#L1-L4

@hiddeco , thanks for the quick response and thanks for pointing out the apiversion.
Can you please let me know what the correct way is to layout the repo with all my deployments being helmcharts and i'm using a single repo for the flux-system components and my helmreleases which are sourced from the same git repo.
Here's how my git repo is laid out:
app-mkt-infra/clusters/prod/flux-system ( this is what flux components are )
Infrastructure components
app-mkt-infra/infrastructure/kong
app-mkt-infra/infrastructure/cert-manager
Deployment manifests (helmcharts)
app-mkt-infra/apps/mrkt-ui
app-mkt-infra/apps/mrkt-resource-api
app-mkt-infra/apps/mrkt-product-api
As i understand the way it, all i need to do, is create helmrelease for each of the components above(in infra and apps ) and make sure i use the sourceRef as the same GitRepository which was used to bootstrap the cluster? is that correct?
Also, when do i use/create a kustomization if i have all my apps already in helmreleaseses?
Any clarification would be greatly appreciated....
Thanks,
Venu

@kingdonb , @hiddeco , i got the helmrelease to atleast try to get initialized by flux, but its showing its not ready state.
can you please assist.
$ flux get helmrelease -n infra-kong
NAME    READY   MESSAGE                                                 REVISION        SUSPENDED
kong    False   HelmChart 'infra-kong/infra-kong-kong' is not ready                     False
I created a helmrelase named "kong"  to be created in namespace "infra-kong", the manifests are in  helmchart called "kong" in the repo path ./infrastructure/kong, but not sure why the helmrelease is being created as infra-kong/infra-kong??
here's my kong-release.yaml in clusters/production/ folder :
apiVersion: helm.toolkit.fluxcd.io/v2beta1
kind: HelmRelease
metadata:
name: kong
namespace: infra-kong
spec:
chart:
spec:
chart: ./infrastructure/kong
sourceRef:
kind: GitRepository
name: flux-system
install:
createNamespace: true
interval: 10m0s
targetNamespace: infra-kong
Any ideas what am i missing?

Any help would be appreciated please...
why is flux/helm-controller trying to create a helmchart from the same path i defined(./infrastructure/kong)
when i have a helmrelease defined with the same path? (./infrastructure/kong)?
really stuck here...any assistance/direction would really be appreciated....
please see the helmrelease manifest file below.
$ flux get all -A
NAMESPACE       NAME                            READY   MESSAGE                         REVISION        SUSPENDED
flux-system     gitrepository/flux-system       True    Fetched revision: prod/0c8f2a1  prod/0c8f2a1    False
infra-kong      gitrepository/app-mkt-infra     True    Fetched revision: prod/0c8f2a1  prod/0c8f2a1    False
NAMESPACE       NAME                            READY   MESSAGE                                         REVISION        SUSPENDED
infra-kong      helmchart/infra-kong-kong       True    Packaged 'kong' chart with version '0.1.0'.     0.1.0           False
NAMESPACE       NAME                    READY   MESSAGE                         REVISION        SUSPENDED
infra-kong      helmrelease/kong        False   install retries exhausted                       False
NAMESPACE       NAME                            READY   MESSAGE                         REVISION        SUSPENDED
flux-system     kustomization/flux-system       True    Applied revision: prod/0c8f2a1  prod/0c8f2a1    False
MINGW64 ~/app-mkt-infra/clusters/production (prod)
$ cat kong-release.yaml
---
apiVersion: v1
kind: Namespace
metadata:
name: infra-kong
apiVersion: v1
kind: Secret
metadata:
name: app-mkt-infra-creds
namespace: infra-kong
data:
identity:
identity.pub:
known_hosts:
apiVersion: source.toolkit.fluxcd.io/v1beta1
kind: GitRepository
metadata:
name: app-mkt-infra
namespace: infra-kong
spec:
interval: 5m0s
url<EMAIL_ADDRESS>ref:
branch: prod
secretRef:
name: app-mkt-infra-creds
apiVersion: helm.toolkit.fluxcd.io/v2beta1
kind: HelmRelease
metadata:
name: kong
namespace: infra-kong
annotations:
app.kubernetes.io/managed-by: Helm
spec:
chart:
spec:
chart: ./infrastructure/kong
sourceRef:
kind: GitRepository
name: app-mkt-infra
install:
createNamespace: true
remediation:
retries: 3
upgrade:
remediation:
retries: 3
interval: 5m0s

@95438 It looks like you needed to find this document:
https://fluxcd.io/docs/components/helm/helmreleases/#helm-release-placement
The releaseName flag has a default setting, which includes the namespace and the chart name. You can set it to something else.

@kingdonb , Thanks for the pointer. I got past this issue. I have a few more hurdles to cross...
I'm still trying to find my way through with using flux v2.
I have a few questions. Would truly appreciate it if you can answer these for me.

I'm using a single repo as the config repo as well as to host the  helmcharts/helmreleases for my application.
when i bootstrapped this repo, flux created a GitRepository resource in the flux-system namespace.

for my helmreleases/charts that exist in their own namespaces, do i neeed to create GitRepository resource in each namespace referring to the single repo ( config repo as well as the helmcharts for my application)?
i have 4 helmreleases that need to be deployed in a single namespace.
do i create 1 namespace resource and 1 gitrepository resource in each namespace?
if yes, how do i refer to this namespace resource and girepository resource in the 2nd/3rd and 4th helmreleases?
can i use dependsOn to make helmrelease2 dependent on helmlrelease1 inside the same namespace?

appreciate it if you can answer my questions.
Thanks,
Venu

Please join us in a different venue, as I've explained our support policy demarcates which type of request is appropriate for which venue, an issue report is "Something is not working as intended / I found a bug"
This would be an appropriate question for the Q&A section of FluxCD discussions board, or in the #flux channel on CNCF Slack


Kibana management index name hard coded, should pick up from server config

Plugin version:
6.X
Kibana version:
6.X
Description of the problem including expected versus actual behavior:
With the new Version i get the following Error when i check an Index Pattern:
PUT https://kibana.example.com/api/saved_objects/index-pattern/3ad283a0-01c5-11e8-9be8-33ccd18ae84c 400 (Bad Request)
Error: mapping set to strict, dynamic introduction of [nested] within [index-pattern] is not allowed: [strict_dynamic_mapping_exception] mapping set to strict, dynamic introduction of [nested] within [index-pattern] is not allowed
at commons.bundle.js?v=16363:27
at processQueue (commons.bundle.js?v=16363:55)
at commons.bundle.js?v=16363:55
at Scope.$digest (commons.bundle.js?v=16363:55)
at Scope.$apply (commons.bundle.js?v=16363:55)
at done (commons.bundle.js?v=16363:55)
at completeRequest (commons.bundle.js?v=16363:55)
at XMLHttpRequest.xhr.onload (commons.bundle.js?v=16363:55) "Possibly unhandled rejection: {"statusCode":400,"body":{"message":"mapping set to strict, dynamic introduction of [nested] within [index-pattern] is not allowed: [strict_dynamic_mapping_exception] mapping set to strict, dynamic introduction of [nested] within [index-pattern] is not allowed","statusCode":400,"error":"Bad Request"}}"
I tried to find a solution, but haven't found one. Is this related to this Plugin or where can i adjust this strict/dynamic Setting? The Index was created automatically while we imported nested JSON Data into it.
Steps to reproduce:
Clean install of Kibana + Elasticsearch without the .kibana index created.
Workaround: Restart Kibana.

@open7c - Lets use this to track your issue.

A restart of Kibana doesn't change anything.
On my Installation there is no .kibana Index but a .kibana-6.
I can remember that this was because we started with Kibana 5 and due to the Migration to version 6 the official Docs said to create this .kibana-6 Index.
I think the cleanest way is to read the correct & current Value out of the Config File:

/opt/kibana/config/kibana.yml
kibana.index: ".kibana-6"

I'll take a deeper look this weekend, and see if I can get a solution together.

I just updated 6.1.3 to use the config of the server for the management index name. Can you please retry and let me know if this resolves your issue? If so I'll port the fixes to the other releases.

Bad News, Sir :-) In the meantime Kibana has changed from 6.1.3 to 6.2.1, so the Installer gives:
Plugin installation was unsuccessful due to error "Incorrect Kibana version in plugin [nested-fields-support]. Expected [6.2.1]; found [6.1.3]"

FYI - You can control which version of Kibana is used by specifying a specific docker tag version.
Regardless, I've updated my 6.2.1 release to 1.0.1 with this fix. You will have to update your Dockerfile to point to the new version.
Let me know if this resolves your issue.

Yes, now the installation works and i can select Indices.
Now i have to figure out how to use it. In particular how KNQL works.
All Links to elastic.co on the page https://ppadovani.github.io/knql_plugin/overview/ are broken!

Yeah... figures... I'll update the links.. thanks for pointing that out.


GraphQL- Add Crisis Lex integration

Integrate the Crisis lex lexicon category list to fortis as the default topic list that's setup when a site is first deployed.
The source lexicon list should be sourced from the data directory of the crisis lex GH repo https://github.com/sajao/CrisisLex/tree/master/data .
What complete means

Normalize all the datasets available from lexicon repo into a unique, consolidated and conditioned dataset available on our blob storage container which is currently hosting our sentiment models.
This should be organized in a directory structure following the convention /fortis/{type}/defaultTopics/
modify the createOrReplaceSite graphql endpoint to accept the siteType input parameter and reference all topics for the input {type} from blob storage.
Push one record in the Topics table in Cassandra for each topic sourced from our blob storage container.

Diagram Clemens made during our conversation about how the fortis pipeline is set up.


[Bug Report] Process tear-down on machine with two N150s

In CreateDevice, we see the following error
terminate called after throwing an instance of 'std::runtime_error'
  what():  TT_THROW @ tt_metal/impl/device/device.cpp:28: tt::exception
info:
Process tear down with device {} still active
0

Run any device test on this machine: <IP_ADDRESS> to reproduce.

debugging segfault seen with umd logger changes: https://github.com/tenstorrent-metal/tt-metal/issues/4271

@aliuTT, is this a P0 showstopper? who is being blocked?

We need a few commits from umd main to make sure our dev flow works on some multi card machines. I was seeing BM 71 crapping out. afaik, Andrew was seeing some issues with GS machines as well, but we have work arounds to pick up commits locally, so maybe we can downgrade to P1? In any case, we found the issues with the umd uplift, I should have a sweep of CI today. Hopefully we can get this done end of day

Ok. Sounds good

Hey @aliuTT , I am still seeing a device set up error on <IP_ADDRESS> with the latest UMD. The error is the following
C++ exception with description "_Map_base::at" thrown in SetUp().


Error Preventing Plugin From Running

Hi Alexander!
First of all, thanks for such an awesome solution! I am having a bit of trouble getting it to run :) On my recurring workflow runner i get the following error:
An unexpected error occurred from ISV code. (ErrorType = ClientError) Unexpected exception from plug-in (Execute): AlexanderDevelopment.WorkflowScheduler.RunScheduledWorkflows: System.TimeoutException: Couldn’t complete execution of the custom activity AlexanderDevelopment.WorkflowScheduler.RunScheduledWorkflows plug-in within the 2-minute time limit.
Any suggestions? Thanks!

This suggests you have a large number of records, and the process runner can't get through them all in two minutes. Could you try making the query more restrictive to see it that works? One example approach I recommend is if you are running the process on contacts, set up two scheduled jobs - one for contacts whose names start with A-M and another one for contacts whose names start with N-Z.

Thanks for coming back to me but i dont think thats the issue. Its only a very small number of records (10-30, max 100 each time)

Are you executing a synchronous or background workflow?

Background, but i think i may have found the issue. I think there was an error in my FetchXML that meant it was indeed bringing in too many records. I'll test and confirm. Thanks!


task: Prepare project for hosting

Replace all instances of local host with optional environment variable in order to have site hosted on SDP site
Definition of done:

[ ] We are able to set an environment variable with any URL, which will work as the base site URL

[t: 20]
Added environment variable and call to it throughout the project, if the variable is set in .env, it will make the calls to the sdp domain

[t:60]
Setup environments for frontend, set new favicon, setup environment variables and changed docker compose to run schema automatically.


Add new nspkg to dockerfiles

Codecov Report

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

@@           Coverage Diff           @@
##           master    #2988   +/-   ##
=======================================
  Coverage   63.39%   63.39%
=======================================
  Files         463      463
  Lines       26586    26586
  Branches     4083     4083
=======================================
  Hits        16854    16854
  Misses       8615     8615
  Partials     1117     1117

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 c1684ea...3a96cc5. Read the comment docs.


Added support for promises to req.login().

I tried using promise, but I couldn't get it working; the callbacks were being called fine, but for some reason it wasn't modifying the req variable. I used Q instead; it's bigger, but not so much bigger that it will make much of a difference on the server.
I can have another go with promise if you want.

Replaced by #243, closing this one

Closing.  See comment for rationale.


Need a ancestor model to sync()

Doc saids:

Creates a new model folderAncestor which contains the ancestry information (columns folderId and ancestorId)

But it seems no such model created, so no foldersancestors table exists. User needs manually create it.
Executing (default): INSERT INTO `foldersancestors` (`folderId`,`ancestorId`) VALUES (2,1);
(node:49471) UnhandledPromiseRejectionWarning: SequelizeDatabaseError: SQLITE_ERROR: no such table: foldersancestors

Needs a patch for folder.ancestor (or in whatever name) to sync().
folder.ancestor = sequelize.define("folderAncestor", {
    folderId: Sequelize.INTEGER,
    ancestorId: Sequelize.INTEGER
});

folder.sync();
folder.ancestor.sync();

Or directly patch to folder.sync()for creating bothfolders and  foldersancestors tables would be nice.

Seems sequelize created the model. Sorry for disturbing.


Do not use comments in scripts.

pyjade does not deal with comments in scripts properly.
I had
script.
    $(document).ready(function() {
        // Comment
        $('#id').select2();
    });

which was converted to

It turns out that this is being caused by pyjade improperly handling .. From the test suite, if we use script over script., then whitespace is preserved.
@syrusakbary This is very confusing behavior as it varies from our expectations from the node.js Jade library.
https://github.com/syrusakbary/pyjade/blob/74e16e748eaf16957b6892476b49589787e23758/pyjade/testsuite/cases/script.whitespace.jade
https://github.com/syrusakbary/pyjade/blob/74e16e748eaf16957b6892476b49589787e23758/pyjade/testsuite/cases/script.whitespace.html
If we use that in the jade-lang.com example, it uses HTML behavior for script without a . because that is intended to help at defining browser-side templates:
script
  // Hello
  p what's up

vs with a .
script.


fix: bump golangci and fix lint errors

IMPORTANT: Please do not create a Pull Request without creating an issue first.
Problem:
need to bump golangci and fix lint errors
Solution:
bump golangci and fix lint errors
Related Issue:
Test plan:

The build CI is not trigged and will be tracked via https://github.com/rancherlabs/eio/issues/1511


can't use symfony3 with guzzle/guzzle 3.9 required by sendgrid

Please update the dependency, guzzle/guzzle 3.9 require symfony/event-dispatcher: ~2.1 how has conflict with symfony/event-dispatcher: ~3.0

:+1: I have the very same problem.

@yassine-ah @romainbriand
The new version of this library (coming very soon) will no longer depend on Guzzle, it will use this client, which has no dependencies: https://github.com/sendgrid/php-http-client


DBZ-5201: Add support for server-side filtering of replica set change streams

DBZ-5201: Add support for server-side filtering of replica set change streams

WIP! (sorry meant to be draft PR).

@jcechace @jpechane  With respect to the tests, the first issue I'm hitting appears to be a race condition between when the collection is initialized / created in the test and when the change stream is initialized. If the collection is not created first, then the change stream will materialize a listing that doesn't include the test db / collections, and this will be frozen for the rest of the test.
There are at least a couple of ways to fix this:

Eagerly initialize all collections before the test (not sure what the ripple is here in terms of changes)
Perform late evaluation of the collection / database names by making the pipeline use regexes when filtering ns elements.

What do you think? My take is that 1. seems like it would be generally fine in practice (i.e. the databases and collections must be created before starting the connector), but it would represent a change in (undocumented) behavior so I would like to hear what you think about losing that level of dynamism. Not sure what the performance impact of 2. would be on the server in terms of CPU load, but likely not too bad.
Will wait for you to respond before continuing further.

@jcechace @jpechane With respect to the tests, the first issue I'm hitting appears to be a race condition between when the collection is initialized / created in the test and when the change stream is initialized. If the collection is not created first, then the change stream will materialize a listing that doesn't include the test db / collections, and this will be frozen for the rest of the test.
There are at least a couple of ways to fix this:

Eagerly initialize all collections before the test (not sure what the ripple is here in terms of changes)
Perform late evaluation of the collection / database names by making the pipeline use regexes when filtering ns elements.

What do you think? My take is that 1. seems like it would be generally fine in practice (i.e. the databases and collections must be created before starting the connector), but it would represent a change in (undocumented) behavior so I would like to hear what you think about losing that level of dynamism. Not sure what the performance impact of 2. would be on the server in terms of CPU load, but likely not too bad.
Will wait for you to respond before continuing further.

The issue with tests actually shows that this PR is changing the behavour...
Currently all change events are streamed and ONLY THEN filtered client side based on the include lists. This means that if a new collection (which passes the name test) is created during the stream phase, the events will be picked up by Debezium.
Setting up the pipeline with server-side the way it is done in this PR at the moment means using specific database and collection names at the time of pipeline constructions -- this for the lifespan of the change stream, only events to these will be streamed. This means that operations on the newly created collection will be ignored.
Thus the server-side filtering needs to use regexes. The question is whether this will have any significant impact on the database.

Okay, so I pretty much ported all the client-side filtering logic to a change stream pipeline filter that executes on the server side. But I just came to learn that this is more complicated than I expected since:

I didn't realize initially that the collection pattern matches both the collection and database. This means that there much be a concatenation step the runs on the server to create the effective dotted "namespace".

Ah.. I see... the collection filters are applied against CollectionId not the name of the collection...
I'm almost inclined to "fork" the filtering logic and have the server side filtering separately while also keeping the client side one.
A way to make this work would be to use the $replaceWith aggregation. However this is already starting look like a decent amount of an overhead.
@jpechane What would you recommend here?

Was able to get this working by using  $set and $unset in the pipeline to materialize a namespace field for filtering. Looks like it works. Resulting pipeline:
{
   "pipeline":[
      {
         "$set":{
            "namespace":{
               "$concat":[
                  "$ns.db",
                  ".",
                  "$ns.coll"
               ]
            }
         }
      },
      {
         "$match":{
            "$and":[
               {
                  "$and":[
                     {
                        "ns.db":{
                           "$nin":[
                              "admin",
                              "config",
                              "local"
                           ]
                        }
                     },
                     {
                        "namespace":{
                           "$regularExpression":{
                              "pattern":"dbit.*",
                              "options":"i"
                           }
                        }
                     }
                  ]
               },
               {
                  "operationType":{
                     "$in":[
                        "insert",
                        "update",
                        "replace",
                        "delete"
                     ]
                  }
               },
               {
                  "clusterTime":{
                     "$ne":{
                        "$timestamp":{
                           "t":1677018164,
                           "i":17
                        }
                     }
                  }
               }
            ]
         }
      },
      {
         "$unset":[
            "namespace"
         ]
      }
   ]
}

This can be simplified, and will need to be reordered for correctness (e.g. can't $concat fields that don't exist).

All MongoDbConnectorIT tests seem to be passing except shouldEmitHeartbeatMessages. Could this be because we have much less change events flowing to the client? Not as familiar with this feature.

Heartbeats esentially has two purposes

It works as a liveness check that there are still changes received by the connector from change stream, however these are not on monitored collections
It reduces the need to reexecute snapshot. This could happen when the last monitored change was pushed out of oplog by changes to not monitored collections --so we now have a resume token which is deemed too old (older than begining of oplog) which indicates possible data loss and thus snapshot execution.

@jpechane so any server side filtering actually breaks this. So this probably has to be an optional feature, right?

It seems as though it may be possible to get a heartbeat even when the change stream does not match a pipeline. This is the approach that the MongoDB Kafka Connector take's in it's HeartbeatManager in concert with the source task. To perform something similar in Debezium, we would need to change this:
try (MongoCursor<ChangeStreamDocument<BsonDocument>> cursor = rsChangeStream.iterator()) {

to be:
try (MongoChangeStreamCursor<ChangeStreamDocument<BsonDocument>> cursor = rsChangeStream.cursor()) {

Then, the cursor.getResumeToken() method would be available, which:

Returns the resume token. If a batch has been iterated to the last change stream document in the batch and a postBatchResumeToken is included in the document, the postBatchResumeToken will be returned. Otherwise, the resume token contained in the last change stream document will be returned.

The nice benefit about using this approach is that it potentially wouldn't depend on the activity of the replica set. Thoughts?

This would solve the liveness, what about the part where we get truly latest resume token? Meaning if I have a change stream open,

consume monitored event and store resume token T1 (emit change event)
consume umonitored event and store resume token T2 (emit heartbeat event)
consume unmonitored event and store resume token T3 (emit heartbeat event)

With current implementation after restart we know it is fine to resume from T3 even when the size of the oplog was 2 and T1 is no longer valid.
Would this still work with the proposed solution? I think in this case T1 would be reported in place of T2 and T3. Meaning we might have issues resuming with the same oplogize size since T1 is no longer valid.

Would this still work with the proposed solution? I think in this case T1 would be reported in place of T2 and T3. Meaning we might have issues resuming with the same oplogize size since T1 is no longer valid.

I don't believe this to be the case. From the docs (and looking a the driver source), the resume token is updated on every getMore call.  Additionally, from the spec:

Drivers MUST expose a mechanism to retrieve the same resume token that would be used to automatically resume. It MUST be possible to use this mechanism after iterating every document. It MUST be possible for users to use this mechanism periodically even when no documents are getting returned (i.e. getMore has returned empty batches).

This would explain why the MongoDB Kafka Connect source uses the same approach. From their docs on heartbeat.interval.ms:

The connector sends heartbeat messages when source records are not published in the specified interval.
Heartbeat messages contain a postBatchResumeToken data field. The value of this field contains the MongoDB server oplog entry that the connector last read from the change stream. This mechanism improves resumability of the connector for low volume namespaces.

Sweet, so I think we have a solution to this problem.

@jcechace The biggest question I have remaining now is how to integrate this approach into the current logic. Specifically this is the area from MongoDbStreamingChangeEventSource that I will need some hand holding to understand:
    oplogContext.getOffset().changeStreamEvent(event);
    oplogContext.getOffset().getOffset();
    CollectionId collectionId = new CollectionId(
            replicaSet.replicaSetName(),
            event.getNamespace().getDatabaseName(),
            event.getNamespace().getCollectionName());

   // ...

    try {
        dispatcher.dispatchHeartbeatEvent(oplogContext.getPartition(), oplogContext.getOffset());
    }
    catch (InterruptedException e) {
        LOGGER.info("Replicator thread is interrupted");
        Thread.currentThread().interrupt();
        return;
    }

The points of clarification / guidance that would be useful:

Is the call to oplogContext.getOffset().changeStreamEvent(event) required for heart beating? Should we introduce a new oplogContext.getOffset().resumeToken(resumeToken) method?
The strange call to the getter oplogContext.getOffset().getOffset(); seem to have side effects. What is it's precondition and post condition?
The call to dispatcher.dispatchHeartbeatEvent(oplogContext.getPartition(), oplogContext.getOffset()); will likely need to change. Not sure if the right approach is to affect oplogContext or to pass in a new argument.

@jpechane Since you've worked pretty closely in this area, I would really appreciate your input. Thank you! 🙏

So close to a clean bill of health, but failing on Mongo 4.0 due to the lack of support of $set:
Caused by: com.mongodb.MongoCommandException: Command failed with error 40324 (Location40324): 'Unrecognized pipeline stage name: '$set'' on server <IP_ADDRESS>:27017. The full response is {"operationTime": {"$timestamp": {"t":<PHONE_NUMBER>, "i": 1}}, "ok": 0.0, "errmsg": "Unrecognized pipeline stage name: '$set'", "code": 40324, "codeName": "Location40324", "$clusterTime": {"clusterTime": {"$timestamp": {"t":<PHONE_NUMBER>, "i": 1}}, "signature": {"hash": {"$binary": {"base64": "AAAAAAAAAAAAAAAAAAAAAAAAAAA=", "subType": "00"}}, "keyId": 0}}}

This limitation is documented here:

I believe this may be possible using $addFields, so will do some experimenting and report back.

$addFields should work and I think it doesn't have to be removed in the consequent pipeline step.

Great work! Thanks for your contribution.


Heat capacity functions by mol

Is your feature request related to a problem? Please describe.
Most T and P dependent chemical property functions are on a molar basis (e.g. volume, Hvap, and most heat capacity functions). However, Lastovka_Shaw, Dadgostar_Shaw, and Lastovka_solid heat capacity functions are on a per kg basis. I'd like to allow
these functions to return values in J/mol-K if given an optional parameter MW (the molecular weight). This would allow backwards compatibility as well as more consistency in units if measure.
Do you acknowledge the project is developed by volunteers adding features primarily for their own purposes?
Yes!
Additional context
@CalebBell, thumbs up if you agree and I'll get to adding this feature!

Would this conflict the support for with pint Quantities?

Hi Yoel,
Yes, it is an issue with pint. It is also an issue I have faced before. The solution I did before was to manually code a wrapper as can be seen for some functions in fluids: https://github.com/CalebBell/fluids/blob/master/fluids/units.py#L471
Nothing has been coded in chemicals yet about this issue. There are existing issues, like speed_of_sound which has two different types of outputs.
One option would be to only ever have a function return a fixed type. I don't find that user friendly/convenient. Too much documentation duplication and it's harder to remember function names.
After working with numba, it occurs to me that so long as the types of the inputs define what the types of the outputs are, it should be possible to write a general wrapper function, and manually write metadata about how to handle types in these cases (without writing new functions). I'm thinking a dictionary in units.py and some smarts in the units.py of fluids. It is an existing issue, but thank you for reminding me of the fact it hasn't gone away while I wasn't looking at it :)
Cheers,
Caleb

Thanks for the quick reply! I should be done with this soon, so I'll go ahead and close the issue.


dep successfully vendors dependencies that does not compile with specified constraing

What version of dep are you using (dep version)?
v0.3.2-107-gef6a28f7
What did you expect to see?
dep ensure to fail if my program is not going to compile. But I am not sure if dep ensure actually compiles my program at all.
What did you see instead?
Indirect dependency is not compatible with the specified constraint, fails with compilation error.
What dep command did you run?

Create a GOPATH and an empty go program (main.go)

package main

func main() {}

Run dep init -v:

Getting direct dependencies...
Checked 1 directories for packages.
Found 0 direct dependencies.
Root project is "github.com/ahmetb/serial-killa"
 1 transitively valid internal packages
 0 external packages imported from 0 projects
(0)   ✓ select (root)
  ✓ found solution with 0 packages from 0 projects

Solver wall times by segment:
  select-root: 93.538µs
        other:  14.48µs

  TOTAL: 108.018µs

Change the program to this:

package main

func main() {
	_, err := client.NewEnvClient()
	if err != nil { panic(err) }
}

Run dep ensure -add to add the package I need:

$ dep ensure -v -add github.com/docker/docker/client@bdd9668b489c65eb1ef7272d38ad877ffda2041c

(1/1) github.com/docker/docker/client@bdd9668b489c65eb1ef7272d38ad877ffda2041c
Fetching sources...

Root project is "github.com/ahmetb/serial-killa"
 1 transitively valid internal packages
 1 external packages imported from 1 projects
(0)   ✓ select (root)
(1)	? attempt github.com/docker/docker with 1 pkgs; 207 versions to try
(1)	    try github.com/docker/docker@bdd9668b489c65eb1ef7272d38ad877ffda2041c
(1)	✓ select github.com/docker/docker@bdd9668b489c65eb1ef7272d38ad877ffda2041c w/17 pkgs
(2)	? attempt github.com/opencontainers/go-digest with 1 pkgs; 4 versions to try
(2)	    try<EMAIL_ADDRESS>(2)	✓ select<EMAIL_ADDRESS>w/1 pkgs
(3)	? attempt golang.org/x/net with 2 pkgs; 5 versions to try
(3)	    try golang.org/x/net@master
(3)	✓ select golang.org/x/net@master w/2 pkgs
(4)	? attempt github.com/docker/go-connections with 3 pkgs; 9 versions to try
(4)	    try<EMAIL_ADDRESS>(4)	✓ select<EMAIL_ADDRESS>w/3 pkgs
(5)	? revisit golang.org/x/net to add 1 pkgs
(5)	  ✓ include 1 more pkgs from golang.org/x/net@master
(5)	? attempt github.com/pkg/errors with 1 pkgs; 11 versions to try
(6)	    try<EMAIL_ADDRESS>(6)	✓ select<EMAIL_ADDRESS>w/1 pkgs
(6)	? attempt github.com/docker/go-units with 1 pkgs; 6 versions to try
(7)	    try<EMAIL_ADDRESS>(7)	✓ select<EMAIL_ADDRESS>w/1 pkgs
(7)	? attempt github.com/opencontainers/image-spec with 1 pkgs; 17 versions to try
(8)	    try<EMAIL_ADDRESS>(8)	✓ select<EMAIL_ADDRESS>w/2 pkgs
(8)	? attempt github.com/gogo/protobuf with 1 pkgs; 19 versions to try
(9)	    try<EMAIL_ADDRESS>(9)	✓ select<EMAIL_ADDRESS>w/1 pkgs
(9)	? attempt github.com/docker/distribution with 1 pkgs; 62 versions to try
(10)      try<EMAIL_ADDRESS>(10)  ✓ select<EMAIL_ADDRESS>w/2 pkgs
(10)  ? attempt github.com/Microsoft/go-winio with 1 pkgs; 29 versions to try
(11)      try<EMAIL_ADDRESS>(11)  ✓ select<EMAIL_ADDRESS>w/1 pkgs
(11)  ? attempt golang.org/x/sys with 1 pkgs; 1 versions to try
(12)      try golang.org/x/sys@master
(12)  ✓ select golang.org/x/sys@master w/1 pkgs
  ✓ found solution with 33 packages from 11 projects

Solver wall times by segment:
         b-list-pkgs: 4.289533989s
              b-gmal: 3.514789144s
     b-list-versions: 3.452850463s
     b-source-exists: 700.813162ms
  b-deduce-proj-root: 262.705537ms
         select-atom:  22.281469ms
             satisfy:  19.127529ms
            new-atom:    366.978µs
               other:     95.257µs
         select-root:     73.424µs
            add-atom:      9.321µs

  TOTAL: 12.262646273s

(1/11) Wrote<EMAIL_ADDRESS>(2/11) Wrote<EMAIL_ADDRESS>(3/11) Wrote<EMAIL_ADDRESS>(4/11) Wrote<EMAIL_ADDRESS>(5/11) Wrote<EMAIL_ADDRESS>(6/11) Wrote golang.org/x/sys@master
(7/11) Wrote golang.org/x/net@master
(8/11) Wrote<EMAIL_ADDRESS>(9/11) Wrote<EMAIL_ADDRESS>(10/11) Wrote<EMAIL_ADDRESS>(11/11) Wrote github.com/docker/docker@bdd9668b489c65eb1ef7272d38ad877ffda2041c
"github.com/docker/docker/client" is not imported by your project, and has been temporarily added to Gopkg.lock and vendor/.
If you run "dep ensure" again before actually importing it, it will disappear from Gopkg.lock and vendor/.

Add the import

package main

import "github.com/docker/docker/client"

func main() {
	_, err := client.NewEnvClient()
	if err != nil { panic(err) }
}

Run dep ensure -v

dep ensure -v
Gopkg.lock was already in sync with imports and Gopkg.toml
(1/11) Wrote<EMAIL_ADDRESS>(2/11) Wrote<EMAIL_ADDRESS>(3/11) Wrote<EMAIL_ADDRESS>(4/11) Wrote golang.org/x/sys@master
(5/11) Wrote<EMAIL_ADDRESS>(6/11) Wrote golang.org/x/net@master
(7/11) Wrote<EMAIL_ADDRESS>(8/11) Wrote<EMAIL_ADDRESS>(9/11) Wrote<EMAIL_ADDRESS>(10/11) Wrote<EMAIL_ADDRESS>(11/11) Wrote github.com/docker/docker@bdd9668b489c65eb1ef7272d38ad877ffda2041c

go build -v cannot compile:

$ dep ensure -v
# github.com/ahmetb/serial-killa/vendor/github.com/docker/docker/client
vendor/github.com/docker/docker/client/container_commit.go:17:15: undefined: reference.ParseNormalizedNamed
vendor/github.com/docker/docker/client/container_commit.go:25:9: undefined: reference.TagNameOnly
vendor/github.com/docker/docker/client/container_commit.go:30:16: undefined: reference.FamiliarName
vendor/github.com/docker/docker/client/image_create.go:17:14: undefined: reference.ParseNormalizedNamed
vendor/github.com/docker/docker/client/image_create.go:23:25: undefined: reference.FamiliarName
vendor/github.com/docker/docker/client/image_import.go:19:16: undefined: reference.ParseNormalizedNamed
vendor/github.com/docker/docker/client/image_pull.go:24:14: undefined: reference.ParseNormalizedNamed
vendor/github.com/docker/docker/client/image_pull.go:30:25: undefined: reference.FamiliarName
vendor/github.com/docker/docker/client/image_pull.go:60:8: undefined: reference.TagNameOnly
vendor/github.com/docker/docker/client/image_push.go:20:14: undefined: reference.ParseNormalizedNamed
vendor/github.com/docker/docker/client/image_push.go:20:14: too many errors

I expected dep ensure would fail if the pulled in github.com/docker/distribution/reference is not compatible with github.com/docker/docker/client.

as always, thanks for the detailed, thoughtful issues 😄
so, i'd also love to see this, and i've been thinking about it for some time. the difficulty here is that the process of selecting versions is an (NP-complete) search of a combinatorially enormous space. as such, it's not really feasible to include go build as a check directly in that process.
what i AM really interested in doing - and what would've been entirely adequate for your case here, and i suspect for all but a vanishingly small number of other cases - is a very limited form of type/shape analysis: e.g. "does the reference.ParseNormalizedNamed symbol exist in the target version? if not, reject that version."
the issue for doing that is #438 (so i'm closing this as a dup of that). it's probably a third-ish tier priority right now, but it's one of the things i'm personally most excited to get to 😄

Thanks for the great answer.


Siri cannot find Homebridge devices without failing first after reconnecting to WiFi

"Siri, Turn on the lights" "Sorry, I wasn't able to do that" "Siri, Turn on the lights" "Lights are on!".
Every. Time. If I leave and come back, every, single, time, Siri fails to do anything the first time, then immediately works on the second try. Does anyone else have this problem?
My setup:
iPhone 5 (JB), Ubuntu 14.04
GF's setup:
iPhone 6, OSX Yosemite.

Also, the irony that this is issue #404 and involves Siri not being able to find homebridge is hilarious.

I had this 404 issue (that name is sticky...) coming and going. What about third and fourth tries? I even had some "I can search the internet for it" in between, even though the recognized sentence was correct and spelled exactly the same to the times it worked.
I thought this was a localization issue, as I use Siri in German.

Siri in US English here, I would be doubtful about the localization causing this issue. It's more of a "I haven't bothered trying connect to any HomeKit device yet, and I can't quickly enough for the first try."
This very well may be some kind of issue with Siri/HomeKit itself in the searching/connecting. I wish I had the tools to determine this.. maybe connecting my phone to a bridged adapter running wireshark?

Same here. I thought it was caused by the wifi signal being too weak outside of my house but I guess it's not.

This seems to happen to me after not using Siri to control homebridge after some time. Once Siri "warms up" and fails the first time it works perfectly afterwards... even if I disconnect/reconnect to the wifi from my phone. It's after a few hours or so is when it takes Siri two tries.
I'm guessing the problem is on Siri's end.  While watching the homebridge log, I didn't see any activity during the failing case. I assume homebridge isn't getting the request at all.

@enriquez I guess it's related to Siri's privacy policy. Siri server will periodically wipe the server cache of user info (like accessories, homes, scenes) and when network condition isn't really good, Siri server may not be able to get an updated snapshot of the home info so it tells you it can't find any device right now...

Oh this must be what's happening to me as well.

Siri server will periodically wipe the server cache of user info (like accessories, homes, scenes) and when network condition isn't really good, Siri server may not be able to get an updated snapshot of the home info so it tells you it can't find any device right now...

Wow, is this for real? Is this daily? It caches like THIS? on request? instead of in the background. That's sort of horrifying.
Is this how it works on certified HomeKit accessories or is this an issue with being "not" certified?

I'm not sure about frequency. When you make a request like "Turn on the lights in my bedroom", Siri will first send a request to HomeKit asking if there is a room named "bedroom", then after HomeKit responses, it will send a second request like "power -> on" for "lights" in "bedroom". After that, Siri (local/server) will cache the existence of "bedroom" for a period of time. Those requests take time and sometime the sync might not be completed before the request timeout.
I don't think certification has anything to do in this process. It's a sad consequence of protecting privacy I guess.

I have the same issue pretty regularly. First try → Sorry. Second try → Ok, done!

@chrischernoff which plugins/accessories/platforms are you using in your Homebridge setup?
I'm personally almost exclusively using the Home Assistant platform.

@maddox SmartThings and Nest

I was experiencing the same issues when running homebridge on a raspberry pi.
I remembered when running nmap on my macbook that the pi had two IP addresses assigned (I tried assigning a static IP, but did it wrong via /etc/interfaces). I have now made sure that the raspberry only uses one IP address.
I'm not sure if this really was the issue, but it seems to have fixed this for now (I just did this recently).

Interesting thought tkoenig, I'm sure my VM's have both an IPv4 and IPv6 address, I wonder if that is the source of some of the problem.. Apple seems to really have a love for IPv6 (AirPlay has lots of IPv6 only things IIRC) so I think I will try disabling IPv4 on this server and see how it goes.

Hello guys,
I've installed homebridge on my PI, everything works fine for the first 5-10 minutes then the HomeKit software (I used Elgato Eve) doesn't find any accessory anymore. I've followed the guide and homebridge is running automatically on start. The thing is that when I try to access to the http://:51826/accessories it works from my mac so it seems that the server is accessible.
I've tried Elgato Eva in an iPad and an iPhone, same results. Obviously they are in the same network.
I remove the persist folder, change the name, delete the home in the HomeKit settings, restart the app and it works again for another 5 minutes...
What can it be? My pi is connected via ethernet so no wifi power problems...
Thanks,
Dem

Does your Pi have wireless and ethernet enabled? i.e. two paths onto your network. I have had this kind of problem in the past and disabled wireless and have had no issues since.

Thanks for your answer, I don't have any wifi dongle, I'm trying anyway to see if this changes something...thanks

This also happens to me from time-to-time. Most notably when I try to enable my 'good night' scene. She attempts to run it, says there are no devices, and on the second try works 99% of the time. Or weirder yet, she says the scene has finished running, but I still have lights on in parts of the house. Running it a second time works properly.

The problem for me is that everytime it stops working I will have to stop, remove persist, renova, remove the home from settings and start again (so I loose all my configuration).
I've just tried again, this time I've installed also another copy of homebridge on my Mac. HomeKit recognised both of them and I can see both on Discovery app.
Again the Eve app in iOS doesn't see anymore any appliance. I'm not sure what it could be. I've also tried with an iPad, same results. They both have iOS 9.
What else can I try?
Thanks,
Dem

Hadn't had this for a very long time by now, but I see it has not vanished for all of you, see #611

Same problem here. Disabling and re-enabling wifi solves the problem.


Helper cog

Added helper cog which contains a couple commands made to help helpers manage the help channels
Added a help_warns table which is located in the warnings database
Added @trainee_check() on some commands in moderation.py

Done


Add dependencies required to install psycopg2 from source

We can't install the binaries as they don't support musl

PR looks good, but the CI failure is due to the quay.io push going unauthorized: access to the requested resource is not authorized on playlist_manager. The other images pushed fine, and everything built.

Ah, I didn't set up the new image repo properly. Will fix and re-run.


Revised dry run proposal

Sample usage
airflow test hosts total_trips 2015-01-01 -sd ~/data/airflow/hosts/ -dr
2015-09-15 23:58:13,937 - root - INFO - Dry run:
CREATE TABLE IF NOT EXISTS hosts.dim_features (
	id_host BIGINT,
    value STRING
) PARTITIONED BY (
    ds STRING,
    name STRING
);

INSERT OVERWRITE TABLE hosts.dim_features PARTITION (ds='2015-01-01', name='total_trips')
SELECT
	id_host,
	COUNT(1),
FROM
	core_data.fct_trips
WHERE
	ds <= '2015-01-01' AND
	(m_checkouts = 1 OR (ds = '2015-01-01' AND ds_checkout = '2015-01-02'))
GROUP BY
	id_host;
2015-09-15 23:58:13,964 - root - INFO - Testing HQL [create table if not exists hosts.dim_features ( id (...)]
2015-09-15 23:58:16,738 - root - INFO - SUCCESS
2015-09-15 23:58:16,739 - root - INFO - Testing HQL [insert overwrite table hosts.dim_features partitio (...)]
2015-09-15 23:58:18,735 - root - INFO - FAILED: ParseException line 7:0 cannot recognize input near 'from' 'core_data' '.' in select expression
2015-09-15 23:58:18,736 - root - INFO - Context :
 	count(1),
from
	core_data.fct_trips
where
	ds <= '2015-01-01' and

Looks good structurally, adding a few comments inline

@mistercrunch I addressed both comments.
I may now start expanding scope with other of the list items.

Let's add a def dry_run(self): for BaseOperator that just prints out the rendered templates, this will make  --dry_run runnable across the board

Sounds good. That was my thought as well. I can then add the other stuff.

@mistercrunch I added BaseOperator dry run method and --dry_run flag to backfill. Sample output:
airflow backfill listings -s 2015-01-01 -sd ~/data/airflow/hosts/ -dr
(...)
Dry run of DAG listings on 2015-01-01 00:00:00
Task consecutive_sub_4_star_accuracy
2015-09-16 23:40:36,599 INFO - Testing HQL [CREATE TABLE IF NOT EXISTS hosts.dim_listing_featu (...)]
2015-09-16 23:40:39,425 INFO - SUCCESS
2015-09-16 23:40:39,425 INFO - Testing HQL [INSERT OVERWRITE TABLE hosts.dim_listing_features  (...)]
2015-09-16 23:40:54,730 INFO - SUCCESS
Task consecutive_sub_4_star_cleanliness
2015-09-16 23:40:54,736 INFO - Testing HQL [CREATE TABLE IF NOT EXISTS hosts.dim_listing_featu (...)]
2015-09-16 23:40:57,493 INFO - SUCCESS
2015-09-16 23:40:57,494 INFO - Testing HQL [INSERT OVERWRITE TABLE hosts.dim_listing_features  (...)]
2015-09-16 23:41:13,111 INFO - SUCCESS
Task consecutive_sub_5_star_accuracy_since_action
2015-09-16 23:41:13,120 INFO - Testing HQL [CREATE TABLE IF NOT EXISTS hosts.dim_listing_featu (...)]
2015-09-16 23:41:15,938 INFO - SUCCESS
2015-09-16 23:41:15,938 INFO - Testing HQL [INSERT OVERWRITE TABLE hosts.dim_listing_features  (...)]
2015-09-16 23:41:31,320 INFO - SUCCESS
Task consecutive_sub_5_star_cleanliness_since_action
2015-09-16 23:41:31,326 INFO - Testing HQL [CREATE TABLE IF NOT EXISTS hosts.dim_listing_featu (...)]
2015-09-16 23:41:34,103 INFO - SUCCESS
2015-09-16 23:41:34,103 INFO - Testing HQL [INSERT OVERWRITE TABLE hosts.dim_listing_features  (...)]
2015-09-16 23:41:50,442 INFO - SUCCESS
Task ds_last_action
2015-09-16 23:41:50,449 INFO - Testing HQL [CREATE TABLE IF NOT EXISTS hosts.dim_listing_featu (...)]
2015-09-16 23:41:53,247 INFO - SUCCESS
2015-09-16 23:41:53,248 INFO - Testing HQL [INSERT OVERWRITE TABLE hosts.dim_listing_features  (...)]
2015-09-16 23:41:58,700 INFO - SUCCESS
(...)
Task copy_s3_file_for_accuracy_first_warning
2015-09-16 23:43:27,106 INFO - Dry run
2015-09-16 23:43:27,106 INFO - Rendering template for bash_command
2015-09-16 23:43:27,106 INFO - hive -e "select row from hosts.dim_listing_s3_staging where ds='2015-01-01' and template='accuracy_first_warning'" > sample.csv;gzip sample.csv;s3cmd -c /srv/emr/s3cmd.conf put sample.csv.gz s3://airbnb-emr/mochi-input/airflow/ds=2015-01-01/template=accuracy_first_warning/000000_0.gz
Task copy_s3_file_for_accuracy_second_warning
2015-09-16 23:43:27,107 INFO - Dry run
2015-09-16 23:43:27,108 INFO - Rendering template for bash_command
2015-09-16 23:43:27,108 INFO - hive -e "select row from hosts.dim_listing_s3_staging where ds='2015-01-01' and template='accuracy_second_warning'" > sample.csv;gzip sample.csv;s3cmd -c /srv/emr/s3cmd.conf put sample.csv.gz s3://airbnb-emr/mochi-input/airflow/ds=2015-01-01/template=accuracy_second_warning/000000_0.gz
Task copy_s3_file_for_cleanliness_first_warning
2015-09-16 23:43:27,109 INFO - Dry run
2015-09-16 23:43:27,109 INFO - Rendering template for bash_command
2015-09-16 23:43:27,109 INFO - hive -e "select row from hosts.dim_listing_s3_staging where ds='2015-01-01' and template='cleanliness_first_warning'" > sample.csv;gzip sample.csv;s3cmd -c /srv/emr/s3cmd.conf put sample.csv.gz s3://airbnb-emr/mochi-input/airflow/ds=2015-01-01/template=cleanliness_first_warning/000000_0.gz
Task copy_s3_file_for_cleanliness_second_warning
(...)
Task ps_fct_reviews_of_host
2015-09-16 23:43:27,116 INFO - Dry run
2015-09-16 23:43:27,116 INFO - Rendering template for schema
2015-09-16 23:43:27,116 INFO - default
2015-09-16 23:43:27,116 INFO - Rendering template for table
2015-09-16 23:43:27,116 INFO - core_data.fct_reviews_of_host
2015-09-16 23:43:27,116 INFO - Rendering template for partition
2015-09-16 23:43:27,116 INFO - ds='2015-01-01'
Task ps_dim_listings
2015-09-16 23:43:27,118 INFO - Dry run
2015-09-16 23:43:27,118 INFO - Rendering template for schema
2015-09-16 23:43:27,118 INFO - default
2015-09-16 23:43:27,118 INFO - Rendering template for table
2015-09-16 23:43:27,118 INFO - core_data.dim_listings
2015-09-16 23:43:27,118 INFO - Rendering template for partition
2015-09-16 23:43:27,118 INFO - ds='2015-01-01'
Task ps_dim_users
2015-09-16 23:43:27,120 INFO - Dry run
2015-09-16 23:43:27,120 INFO - Rendering template for schema
2015-09-16 23:43:27,120 INFO - default
2015-09-16 23:43:27,120 INFO - Rendering template for table
2015-09-16 23:43:27,120 INFO - core_data.dim_users
2015-09-16 23:43:27,120 INFO - Rendering template for partition
2015-09-16 23:43:27,120 INFO - ds='2015-01-01'
Task ps_dim_listing_standards_yesterday
2015-09-16 23:43:27,122 INFO - Dry run
2015-09-16 23:43:27,122 INFO - Rendering template for schema
2015-09-16 23:43:27,122 INFO - default
2015-09-16 23:43:27,122 INFO - Rendering template for table
2015-09-16 23:43:27,123 INFO - hosts.dim_listing_standards
2015-09-16 23:43:27,123 INFO - Rendering template for partition
2015-09-16 23:43:27,123 INFO - ds='2014-12-31'
Task email
2015-09-16 23:43:27,127 INFO - Dry run
2015-09-16 23:43:27,127 INFO - Rendering template for subject
2015-09-16 23:43:27,127 INFO - Cleanliness/Accuracy Daily Report for 2015-01-01

Nice! Now the only thing missing is a unit test to cover most of this new code. You can probably just copy the HiveOperator test and switch execute to dry_run.

@mistercrunch I added the tests
Anything else I should prepare? I was thinking I would put all of the changes for this PR into a single clean commit that would have a PR against main airbnb/airflow with a more detailed writeup of feature?
Any other thoughts?
(airflow_dev)patrick_tardif@i-f7d20bdd:~/dev/airflow hadoop-journal-brain-production $ nosetests tests.core:HivePrestoTest.test_hive_dryrun
.
----------------------------------------------------------------------
Ran 1 test in 4.999s

OK
(airflow_dev)patrick_tardif@i-f7d20bdd:~/dev/airflow hadoop-journal-brain-production $ nosetests tests.core:CoreTest.test_dryrun
.
----------------------------------------------------------------------
Ran 1 test in 0.006s

OK

Booyah! I haven't been rigorous about rebasing/squashing myself for a cleaner master commit history, so this is good to go.


Admin: Rename "organization" to "org" everywhere

Closing because it's not worth doing at the moment


Webpack require cornerstone-core issue

When I require cornerstone modules in my app:
window.cornerstone = require('cornerstone-core');
window.cornerstoneTools = require('cornerstone-tools');
window.cornerstoneMath = require('cornerstone-math');
window.dicomParser = require('dicom-parser');
window.jpeg = require('jpeg-lossless-decoder-js');
window.cornerstoneWADOImageLoader = require('cornerstone-wado-image-loader');

cornerstoneWADOImageLoader is running with own cornerstone-core instance:
module.exports = factory(require("jquery"), require("cornerstone-core"), require("dicom-parser"));

so when cornerstoneWADOImageLoader calls cornerstone.registerImageLoader('dicomweb', loadImage); it not calls it in mine cornerstone-core instance.
I use webpack 2 to compile JS.

Yeah I've run into this too and it's definitely a problem we need to fix...

How about adding cornerstoneWADOImageLoader.setCornerstoneInstance(cornerstone)? I can make some PR if it seems ok.

Nevermind. I found a workaround:
import * as cornerstoneWADOImageLoader from 'cornerstone-wado-image-loader/dist/cornerstoneWADOImageLoader'

This should be fixed now. Use:
cornerstoneWADOImageLoader.external.cornerstone = cornerstone;


Update Blog “netlify-cms-2-1-0-adds-external-media-support-with-uploadcare”

Automatically generated by Netlify CMS

Deploy preview for netlify-cms-www ready!
Built with commit 10f05efce70090ad9808d4239306c71664f6b3c4
https://deploy-preview-1729--netlify-cms-www.netlify.com

Deploy preview for cms-demo ready!
Built with commit 10f05efce70090ad9808d4239306c71664f6b3c4
https://deploy-preview-1729--cms-demo.netlify.com


Add Aural Coding (Keyboard sounds)

Add Aural Coding (Keyboard sounds) extension.
https://marketplace.visualstudio.com/items?itemName=jeng.aural-coding-vscode

A Visual Studio Code extension that creates sweet melodies based on what you type

Hi... this is an interesting idea, however, I think youtube-video demo would be useful to understand how it works


Installation Difficulties

Hi,
I am trying to install this on my Linux server but have run into an error. I ran the command
cmake -DCMAKE_BUILD_TYPE=RELEASE ../Gpufit
which worked, and then I tried
make
but it seems to give this error:
[ 18%] Built target Cpufit
[ 53%] Built target Gpufit
[ 56%] Building CXX object Gpufit/examples/CMakeFiles/Linear_Regression_Example.dir/Linear_Regression_Example.cpp.o
/home/rvv/RLwork/AEwork/Gpufit/examples/c++/Linear_Regression_Example.cpp:1:10: fatal error: ../../gpufit/gpufit.h: No such file or directory
 #include "../../gpufit/gpufit.h"
          ^~~~~~~~~~~~~~~~~~~~~~~
compilation terminated.
Gpufit/examples/CMakeFiles/Linear_Regression_Example.dir/build.make:65: recipe for target 'Gpufit/examples/CMakeFiles/Linear_Regression_Example.dir/Linear_Regression_Example.cpp.o' failed
make[2]: *** [Gpufit/examples/CMakeFiles/Linear_Regression_Example.dir/Linear_Regression_Example.cpp.o] Error 1
CMakeFiles/Makefile2:1116: recipe for target 'Gpufit/examples/CMakeFiles/Linear_Regression_Example.dir/all' failed
make[1]: *** [Gpufit/examples/CMakeFiles/Linear_Regression_Example.dir/all] Error 2
Makefile:97: recipe for target 'all' failed
make: *** [all] Error 2

I'm not sure how to proceed here.

I have the same problem with current master (af1389c6c7a8a2e7eb7b0ccb1d7595d18880e57c). The issue is that some relative #include paths are not correct.
# Clone
$ git clone https://github.com/gpufit/Gpufit.git Gpufit

# Offending header files
$ grep -nr "gpufit/gpufit.h" --include *.h --include *.cpp --include *.cu
Gpufit/examples/c++/Gauss_Fit_2D_Example.cpp:1:#include "../../gpufit/gpufit.h"
Gpufit/examples/c++/CUDA_Interface_Example.cu:1:#include "../../gpufit/gpufit.h"
Gpufit/examples/c++/Linear_Regression_Example.cpp:1:#include "../../gpufit/gpufit.h"
Gpufit/examples/c++/Simple_Example.cpp:1:#include "../../gpufit/gpufit.h"

These includes should read #include "../../Gpufit/gpufit.h" (note upper case G).
If you correct this mistake and re-compile it might work.
The alternative is to
git clone https://github.com/gpufit/Gpufit.git Gpufit && git checkout v1.2.0

which does not suffer this problem.


What is “completeness of subtyping”

The spec currently says

Completeness: Subtyping covers all cases of successful deserialisation.

and I wonder what that precisely means, and if we really want it.
(Previous discussion at https://github.com/dfinity/candid/pull/128#discussion_r516571055 )

The wording above suggests
(∀ v. v :? T ~> _ ⇒ v :? T' ~> _) ⇒ T <: T'

But that does not hold as stated, for two reasons:

Any empty type would need to be a subtype of any type, e.g. opt empty <: null, or Empty <: t where type Empty = rec { Empty } or vec Empty <: vec t
Decoding of references (functions, sevices) doesn't actually fail eagerly, but causes subsequent uses of such a reference to fail.

One attempt might be “Subtyping is the largest relation that is transitive and sound (in the sense of the IDL-Soundness document)”. This is quite declarative and realtively elegant, I think, and I believe it implies the local soundess of deserialization.
It still requires Empty <: t, but it seems all “natural” definitions will lead to that. If we want to rule out that then maybe we have to do say something handwavy like “, … with exceptions for types that contain empty types”.
Maybe allowing Empty <: t and variant {} <: t isn’t actually so bad?


400ZR test for monitoring pre FEC BER.

Pull Request Functional Test Report for #2078 / c19d018fd27ec413c6e269315b97d6a7a4a8961e
No tests identified for validation.
Help


Generated emberAfFillCommandNetworkCommissioning macros seems to be broken.

Problem
Looking at e.g. https://github.com/project-chip/connectedhomeip/blob/master/examples/lighting-app/lighting-common/gen/client-command-macro.h#L2004 and many others it seems that define should be named emberAfFillCommandNetworkCommissioningClusterScanNetworksResponse. It looks like some kind of formatting error during defines generation.
Proposed Solution
Figure out the cause of a generation problem, fix it and regenerate files using ZAP tool.

I guess the root of the issue is https://github.com/project-chip/zap/blob/74c34f59092a9e593a4826dc657e41f85859ea55/src-electron/generator/helper-zcl.js#L238
This line takes the raw <name>Network Commissioning</name> field from the xml definition. Doing something like n = n.concat(helperC.asType(el.name)) should fix the issue.

This is dead code at this point.


Cutting the stateful boilerplate

Document Link
https://flutter.dev/go/stateful-macro
What problem are you solving?
Implementing a stateful widget in Flutter requires developers to write two classes: the StatefulWidget subclass and the State subclass. Could we use macros to reduce the number of classes and the lines a developer has to write to accomplish the same thing?

I'm going to be the "old man yells at cloud" here, but I feel like I have to.
I picked up flutter early on because both Dart and Flutter were built with simple structures, all of it was straightforward, easy to understand, and you didn't have to delve too deep into complex things to grok the entirety of the functionality of the framework.
Now, don't get me wrong, I don't disagree with simple macros that generate toJson/fromJson/copyWith/equality/hashcode/etc, these do fairly simple things, and explaining them is basically as simple as just putting an example of what the generated code looks like.
But this proposal? To me, this is too far. This doesn't look, feel, or sound like what Flutter is.
Widgets are no longer simple classes with that proposal. Instead, they become magic structures that perform obscure piping logic à la Angular, or even SwiftUI.
It feels like this is akin to trying to trade everything about the experience of writing flutter to end up looking basically like the other frameworks.
(Ignoring the proposal when it releases is not an option, peer pressure from the majority won't let me ignore such a feature change or it's semantics.)

I like flutter and dart for how explicit they are. Sane type safe language with very low magic like dart is a breath of fresh air in the world of metaprogramming and reflection magic madness. But like above poster mentioned, boilerplate reduction will likely go through because of the wider pressure. People would rather waste several hours and days debugging than write 5 more lines of code. I'm not against macros since they obviously provide major benefits and allow to do things that aren't possible otherwise. Macros are gonna be abused by the community no matter what but I hope dart and flutter team members themselves don't go overboard.

I think that verbosity is definitely a big problem when writing UI code with Flutter and it regularly stops me from breaking up big build methods further.
And I also absolutely don't have an issue with macros or compiler extensions helping here. If I didn't want any ""magic""", I shouldn't choose a declarative framework, where -by definition- I submit some description of what I want and the framework figures out how to make that happen.
Macros are from my POV just another transformation the compiler does before spitting out optimized bytecode (which absolutely is magic to me :)
With that preface away: If all those paper cuts like @Input(), not being able to customize the constructor, those @Assert... are being required it's just not worth it. I don't think it's getting much simpler, succincter or faster to write that way.
In general I don't think Stateful Widget is a great API (for all the issues already discussed at length when React adopted hooks more than half a decade ago). And while the framework uses them a bunch (though often in ways that would prevent usage of the macro), I think for end users in non-library code (where some neutrality and agnosticism is often preserved), I don't think StatefulWidgets are that common. Certainly not at work where I've introduced hooks and we've been using just that.
I think it's fair to say that most state management packages for Flutter try to keep you away from writing Stateful Widgets, so I wonder for how many people this macro is actually something they'd use.
The need for a StatefulWidget macro stems from the need for StatefulWidgets, and I think it'd make more sense to actually go back to the hooks proposal, have a look and Compose and SwiftUI and look how we can use Macros to aid with that directly.
That being said, I think if you can get something like functional_widget for StatelessWidgets to work using macros, that'd still be worth shipping. If it's just an annotated function, it should be very easy to use and the reduction in LOC would be maximized.

I’d go even further and suggest macros similar to SwiftUI property wrappers such as @State, @Observable, and @Binding. Flutter’s offerings for sharing and mutating state across the widget tree are quite verbose and prone to bugs. Specifically, when both ancestor and descendant widgets subscribe to the same state, it can lead to complex and unintended behaviours.
A more opinionated and robust solution that encourages the composition of UI components, rather than relying on state management tied to individual screens, would be highly valuable. Such an approach would allow better scalability and could significantly increase adoption and support within the developer community.

You guys are against it but the thing we see most in flutter applications today are generators... Everyone loves a safe-type until you have to build a large class. At least this solution brings documentation and readability for the generated code is static. It's just a start and clearly has refinements to be done, but I really believe this is the way. Reducing boilerplate and specially the time between development and deploy were in flutter's principles since the beginning of it.


Images on the results-page lack source image

Describe the bug
The source image on the image in search results is not displayed
To Reproduce
Steps to reproduce the behavior:

Go to 'cc search or build it locally'
Search for anything ex: "icecream"
Hover on the image and you will find that the source image is not displayed

Expected behavior
The image should be present
Screenshots

Desktop
OS: Ubuntu 19.10
Browser: Chrome (Version 80.0.3987.116)
Additional context
This is the same image object which created the error before in #614
I would like to work on this

Go ahead and work on this :) @hemanth-hk

I am done with the changes but since my last PR is not merged yet, creating a new PR will have merge-conflicts (cause this one will include commits from that). So once that PR is merged I will send this PR

@hemanth-hk you can always create a new branch off of current master for this issue

Yup, Done


refactor(json-stream.js): Consistent output stream usage

Description of the Change

Made all output directly use process.stdout.

process.stdout and console.log take different routes to get to same place

Corrected ctor name.
Updated documentation.

Alternate Designs
N/A
Benefits
Consistency. Don't cross the streams!
Possible Drawbacks
N/A
Applicable issues
Fixes #3526
Fixes #3521
semver-patch

Coverage increased (+0.09%) to 90.45% when pulling 439d0a3e3cb9e6123ee66cfce0720547e24178ba on plroebuck:jsonstream into 4ddfcafd07a2aa96ee7c62f72969a1ec651442dc on mochajs:master.

more appveyor timeout flake.
idea: env var, set for appveyor, which is a multiplier of all base timeouts.  ugh.
...or just run windows tests on travis.


Moon Not Visible in Vizard for scenarioHaloOrbit.py

I’ve encountered an issue when running the scenarioHaloOrbit.py script. The simulation runs without errors, and in the Model section of Vizard, the Moon is listed as a visible celestial body. However, the Moon is not displayed in the Vizard visualization itself.
Expected Behavior:
The Moon should be displayed in the Vizard visualization alongside the other celestial bodies.
Environment:
Operating System: Windows 10
Basilisk Version: 2.5.13
Vizard Version: 2.2.0

It looks like the equatorial radius (radiusEq) for the moon is set incorrectly in scenarioHaloOrbit.py to 1.7374 km instead of 1737.4km. You can see the value being passed in the messages from Basilisk by opening the VizMessage Log under the View menu in Vizard. Note that the Earth's equatorial radius is being passed in messages correctly as 6378.1366 km.

Thanks @woodj80  for tracking down the issue.  I have a branch that will fix this.


More fixed-bar menu entries in 2.0-wip docs

Just wanted to ask why you decided to simplify the fixed menu. Now we only have links to categories. With so much stuff 2.0 contains it's hard to navigate all sub components.
I guess it was too wide in 1.4, but maybe we could utilize drop-downs?
javascript.html subpage now has links to specific plugins, when Jacob introduced the packaging, but there's still "Components" and "Base CSS" which could use some links to anchors.

Will be addressing this shortly :). Going to run dropdowns by Jacob and was going to explore a subnav.

Sweet :]


/usr/bin/bash: line 1: tsv-filter: command not found

Running the monkeypox pipeline the workflow errors out with the "tsv-filter" not found. Not sure in which script file or nextstrain package this command comes from. Am I missing a specific extra Nextstrain package or something that I should have installed?

Hi @Pregabaline! Looks like you're missing the tsv-utils package:

tsv-filter

Can you say a bit more about your computing environment or maybe which install method in https://docs.nextstrain.org/en/latest/install.html?

tsv-utils can be installed via bioconda conda install -c bioconda tsv-utils, it's automatically part of the Nextstrain docker container and our managed conda runtime.
It's not auto installed when using the ambient command we used to have in docs. But we're phasing this out anyways I think.


Apennine Architecture - add support for multiple bundle on a single JSContext

Summary
This PR is a implementation of multi-bundle support in a single JSContext, which is described here - https://github.com/react-native-community/discussions-and-proposals/issues/127
It's a joint effort of me and @dratwas.
Target audience
The multi-bundle mode is targeted mainly at corporate/large companies, where smaller teams are responsible for each piece of functionality - a mini app. More info about motivation can be found in the RFC.
Smaller teams or developers creating small/medium sized apps, should stick to the single-bundle mode, which is what React Native and Metro support currently. Because of that, multi-bundle is a opt-in feature.
Backwards compatibility
The new architecture is fully compatible with Metro. The plan JS bundles as well as Indexed RAM bundle, File RAM Bundle and Delta Bundle are working as expected. Remote debugging in Chrome is working properly.
It's more difficult to account for 3rd party libraries, which are going to break, but it's likely that react-native-code-push will stop working and will require some work.
JavaScript API
To allow to request new bundle from JS, BundleRegistry JS module is now available publicly. The additional bundles can request to be loaded either synchronously or asynchronously. Only the initial bundle is automatically loaded from the native side.
New architecture
In order to add maintainable and scalable support for multi-bundle we had to modify the core of React Native's logic for loading and evaluating the JS bundles. We've laid a ground work for adding support to have other bundles running on different JSContextes and threads.
Each bundle type has it's own C++ class:

BasicBundle - plain JS bundle, where JS code is stored as JSBigString
IndexedRAMBundle - single-file RAM bundle (CxxReact)
FileRAMBundle - multi-file RAM bundle (ReactAndroid)
DeltaBundle - delta bundle for development (CxxReact)

All of those bundles derive from abstract Bundle class in CxxReact.
Since the new bundles can requested on-demand, instead of taking a single bundle in RCTCxxBridge or CatalystInstance it takes a loader, which has enough information to load initial bundle and additional bundles:

RCTDevBundleLoader - loader for bundles served from packager server (React)
RCTFileBundleLoader - loader for bundles stored in filesystem (React)
AssetBundleLoader - loader for bundles stored as assets (ReactAndroid)
FileBundleLoader - loader for bundles stored in filesystem (ReactAndroid)
DeltaBundleLoader - loader for bundles stored in a DeltaBundleClient instance (ReactAndroid)

All loaders derive from abstract BundleLoader class in CxxReact.
The flow of logic can be described as:

Create appropriate bundle loader in RCTCxxBridge/CatalystInstance.
Pass the loader and the initial bundle URL down to Instance -> BundleRegistry in CxxReact.
Call Instance::runApplication (or Instance::runApplicationInRemoteDebugger when debugging - previously setSourceURl).
Fetch and evaluate initial bundle in BundleRegistry.
... Fetch and evaluate additional bundles in BundleRegistry.

Notable changes

NativeToJsBridge is no longer a holder of RAM bundle registry. This responsibility was transferred to BundleRegistry in makeGetModuleLambda.
nativeRequire implementation was transferred to BundleRegistry::makeGetModuleLambda.
New global bundleRegistryLoad property in JS was added to allow to request bundles to be loaded either synchronously or asynchronously - check BundleRegistry::makeLoadBundleLambda.
registerSegment API was removed - BundleRegistry could be exposed to user space as a replacement.
jsQueue (MessageQueueThread) and NativeToJsBridge are stored in a BundleExecutionEnvironment struct alongside a pointer to initialBundle - this is part of the ground work to allow multiple JSContexes (as well as multiple NativeToJsBridge/MessageQueueThread). Currently there's only 1 BundleExecutionEnvironment created and it's identified in the code as default.

Example of typical use-case
A example project can be found here: https://github.com/zamotany/react-native-apennine-example
Bundler support
Multi-bundle mode is now only supported in Haul by using Webpack's DLL functionality.
Source maps support
When running in single-bundle mode, the source maps as handled as they were before and working as expected.
When running in multi-bundle mode:

with basic bundle, the filename in the stack trace will point to different bundles, so tools can switch between different source maps to get the original information.
with RAM bundles, the filename will be prefixed with bundle name for example: app0_5.js:10:5 - bundlers which want to support multi-bundle will have to account for that when creating source maps (Haul already does), so by matching the bundle name they can switching between appropriate Index Source Maps.

Missing parts

[x] BundleRegistry JS API documentation - https://github.com/facebook/react-native-website/pull/1084

Changelog
[General] [Added] - Add BundleRegistry, bundle classes, loaders and JS API for on-demand load and evolution of additional bundles.

Test Plan
Since the changes were made to core of React Native's code, it's crucial to ensure the application can be run, not crash and display correct content. RNTester by itself can ensure that requirement.
As other functionalities, manual test were done to ensure that:

Chrome remote debugging still works as expected
Indexed and File RAM bundles are still handled properly and the app behaves as expected.
Requesting and loading a single and multiple bundles is working and the app behaves as expected.
On-demand loading and evaluation of additional bundle in release mode is working and the app behaves as expected.

cc: @matthargett @joeblynch @grabbou

Thank you for working on this. This is really massive. I unfortunately don't think it'll be possible to both review and land a change this large that affects many core pieces of React Native. I would suggest splitting this up into as many small pull requests as possible that can all be reviewed in isolation.

@cpojer
Due to the nature of the changes it will be difficult to split them apart, though it might be doable. But before, I have couple of questions:

Does each small PR have to be fully integrated and used in the code?
Does each small PR have to work?
Can the PR add new files, which won't be used at the beginning?

Right now I have couple of ideas how to do that in mind:

Split this PR into smaller ones, each one building on top of the previous and merge that when all of them are accepted.
Split this PR per platform + ReactCommon, which means that after one is merged other platform won't compile, so all of those would need to be merged at once after all of them are accepted.
Create many small PRs that add new files and don't break the code and one slightly bigger one which ties them together.
(worst case) Split this PR into smaller ones, where each one is fully integrated and works - huge chunk of files will need to be written from scratch and then replace with the final implementation, which means that there will be a lot of throw-away code and diffs just to make things work in isolation. This is also very time consuming and will take a lot of effort.

@cpojer
Any feedback on how should we go about splitting the PR?

I think there is no agreement yet on the RN team whether we'll want to support this large change to React Native itself and whether now is a good time for this.
cc @fkgozali

Please check out my comment on the RFC that goes into details on how we could move forward: https://github.com/react-native-community/discussions-and-proposals/issues/127#issuecomment-514592616
Based on this, I will close this PR and hope we can move forward with smaller changes.