Add '/bin' prefix database

I want to use this as command-not-found replacement. As far is I can tell this only provides full database builds. On my system the command-not-found script takes 3s to execute with the full db.
Could we have an option to download and use a prefix filtered db instead like nix-index --filter-prefix '/bin/'? Or maybe even have an option to provide both and use the smaller one for the command-not-found script?

How fast is the bin database in comparison? I wonder if nix-index could not somehow compute the smaller database from the bigger one.

@Mic92 it's significantly faster. Using nix-index with the full database is borderline unusable for me; when I type a command not found, it'll take about 2/3 seconds to display the results. Instead, with a smaller database generated via nix-index --filter-prefix '/bin/', the results are displayed immediately.

Could we have an option to download and use a prefix filtered db instead like nix-index --filter-prefix '/bin/'? Or maybe even have an option to provide both and use the smaller one for the command-not-found script?

It would be great if this could be supported 🙏🏽
For now, I use a local database, but also with this fork: https://github.com/gvolpe/nix-index/pull/1

I think I got something working on my fork, happy to upstream these changes: https://github.com/gvolpe/nix-index-database/releases/tag/2024-12-22-163440
Here's how I'm using it: https://github.com/gvolpe/nix-config/commit/da65d6b68c9c88353af1de6df10cfb9341330b5f


Fix amount getUnitPrice

Hello,
Bug when quantity on orderItem > 1 *
Best regards,

Hello @AlexandrePavy thanks for your PR !
Can you explain what is the bug you are encountering ? Or add a test for it to avoid it in the futur ?

Hello again @AlexandrePavy indeed there was a huge bug here, but the fix could be less verbose.
You could see the fix and the additional phpspec test related to it : https://github.com/Prometee/SyliusPayumStripeCheckoutSessionPlugin/commit/28da8ca00eea34d8e2d9f9c2bba61270cd8e26d1

Hello @Prometee, your fix is unfortunately does not cover all cases more particularly because of rounding. I gonna make a more detailed issue about it.

You are right. I understand now why the old Stripe gateways weren't detailing those because it can lead to those issues...
I won't be available today, are you able to add the corresponding test in the spec classes ? (Don't forget to rebase your PR first)

@AlexandrePavy find some time today to commit the correction inspired by this PR : https://github.com/Prometee/SyliusPayumStripeCheckoutSessionPlugin/commit/57e3dbd35c0ed31e5eedb2a556f22c8a35570ed2

perfect :+1:

@AlexandrePavy ah sorry I just see your commits, the only differences are the move of the  sprintf to the LineItemNameProvider because devs need to be allowed to change this sprintf too easily.

@AlexandrePavy Again thanks a lot to warn me about this huge bug ! I'm selling subscriptions one by one that's why I never get this bug on prod, but I should have seen this while coding it... My bad 😕

No problem ! A big thank you for the plugin you save me hours with stripe and sylius :joy:


cache client/node_modules during heroku deploys

without this heroku has to do a full npm install on every deploy - i guess this could be part of the heroku generators but it seemed like a lot more work to modify this file there than to just add this option here.

This change is

@modosc This looks great. Can you please add a couple sentences to the heroku doc page.
Also, maybe this is more generic than heroku?

Additionally, we have to see why the CI build does not pass with this.

seems like it failed for an unrelated reason:
W: Failed to fetch http://us.archive.ubuntu.com/ubuntu/dists/trusty-updates/main/source/Sources  Hash Sum mismatch
W: Failed to fetch http://us.archive.ubuntu.com/ubuntu/dists/trusty-updates/main/binary-amd64/Packages  Hash Sum mismatch
W: Failed to fetch http://us.archive.ubuntu.com/ubuntu/dists/trusty-updates/universe/binary-amd64/Packages  Hash Sum mismatch
E: Some index files failed to download. They have been ignored, or old ones used instead.

i can't seem to retrigger the build tho.

@modosc any word on this one?

updated docs, let's see if ci is happy today.

@modosc Please rebase on top of master to a single commit. Thanks.

Coverage remained the same at 87.515% when pulling 7e78ae4b6082e0b2ff4e1368fe64bd6f1d7fba14 on modosc:patch-1 into e6fa8c40d1cf41269c61e4b5fe5c892e0cec97c7 on shakacode:master.

Coverage remained the same at 87.396% when pulling 284f0d26fdd8f11c6471fe558fcb14c1211ee8b8 on modosc:patch-1 into da9d525288b8dba242fa4b3a40a577245efa9a55 on shakacode:master.

@modosc can you please rebase on top of master. I want to merge this.

@modosc I'm ready to merge your changes. However, we need to rebase on top of master, after squashing to one commit, and please include the changelog entry.

@modosc Ping, Ping. I'm ready to merge your changes. However, we need to rebase on top of master, after squashing to one commit, and please include the changelog entry.

@justin808 should be done?

Coverage remained the same at 82.473% when pulling d1925a6a7f730ccb7ff679c3da8bff7bdf2a897a on modosc:patch-1 into 949117978e75babd50f5f5d147f49c50674cf9cd on shakacode:master.

Manually merged in #415.


Check typography against DL and VRT

Check typography

[ ] matches DL
[x] check VRT passes
[x] check and update migration guides example

Deprecated typography removed and slight whitespace changes causing VRT failures.


Support CSL YAML (and or JSON) bibliographies

Description
Currently typst can use BIB and Hayagriva-style YAML bibliography files. Considering that CSL style YAML/JSON bibliographies have been around for a while and have widespread support in all de-facto standard tools (e.g. Zotero for CSL JSON, BetterBibTex for CSL YAML and JSON) support would seem desirable.
Further, typst already uses CSL styles, so it makes sense to support the standard end-to-end, including bibliography files (without conversion via bib)
BetterBibTex has a feature request to support Hayagriva-style YAML, however the author argued (correctly, in my opinion) that CSL is a now many years-old standard that warrants support by typst: https://github.com/retorquere/zotero-better-bibtex/issues/2711
If you disagree it would be interesting to collect arguments to find out on which side which additional format should be supported to not be limited to BIB across tools.
Use Case
Users of bibliography management software that supports CSL can use typst without converting to bib as intermediate format, and avoid issues associated with that.
See https://citationstyles.org/ for a list of software that uses CSL (by the way, this list should probably feature typst, considering the style side of CSL is already implemented :) )

The arguments in the linked issue seem sensible. As someone who was not involved with early development at all: What was the initial reason to create a new format in hayagriva? Why not use CSL?
As I see it, there are two options here:

Add CSL bibliography support to hayagriva directly, i.e., without any translation, at which point the hayagriva format will likely slowly fade away.
Add support for translating hayagriva <-> CSL. Going through Bib(La)TeX is not ideal, and translation would greatly expand typst's use cases.

Since I don't know how attached the core dev team is to hayagriva as a format, I would appreciate their input here. I am open to implementing (2), and to support development of (1).

Hayagriva actually supports CSL-JSON, but only for applying the citeproc.js test suite. Structs are generic in such a way that native Hayagriva entries and CSL-JSON cannot be mixed.
While I think that it would be worthwhile to enable this mixing of entry formats, I also think that the native Hayagriva format has its place. CSL-JSON was designed to expose all CSL variables and switches in Citeproc.js (look at e.g. dates) instead of ease of entering and reading by humans. Both Hayagriva and BibTeX are harder to parse, but, at least in the case of the former, this is by design. I aimed for a compact and readable representation when creating the format, which, I believe, JSON generally and CSL-JSON in particular do not offer.

Any updates on this?
I'm running into multiple issues trying to have typst format my bibliography correctly. (Much akin to the use case @daniel-eder pointed out.) I believe this is from .bib files not being exported with the correct info for typst to translate to CSL in order to format the bibliography properly. I assume having CSL YAML or JSON support would ensure that the bibliographies look identical to what Zotero's CSL bibliography exports look like. This would be a much better experience than wrestling with bib file exports or trying to reformat Zotero CSL YAML exports to be Hayagriva compatible.
In the meantime, if anyone knows of a way to convert CSL YAML/JSON to Hayagriva YAML, I would appreciate any pointers. (From my searching, it seems like there is virtually no software support for the Hayagriva YAML file format.)


Optimize container images for startup

This change adjusts how to handle runner payloads to support container builds where we keep them extracted in the filesystem. This makes it easier to optimize the cpu/cuda vs cpu/rocm images for size, and should result in faster startup times for container images.
Looks like container startup time is down to ~100ms on a warm system.
The ROCm image is still massive due to the base layer containing compilers and other tools, so I'll see if I can find a way to try to slim it down a bit more, but that could come in a follow up PR.
ROCm image updated to use a base ubuntu image and just use our libraries.  The official images and packages pull in compilers as dependencies so this seems to be the optimal lean setup.

That's a huge speedup. Great!
Could we solve for both container and non-container use cases by removing .so files entirely from the bundling? I imagine these .so files make up much of the time, and the ollama_llama_runner binaries are an internal concept I'm hoping we would never expose (they should eventually away)
That said, this has the added benefit of working in read-only filesystems, and so I'm ok with merging this as-is

Until we switch over to the Go branch, it's a bit tricky since the .so's names will conflict between the runners and we'd have to do some surgery to the llama.cpp cmakefiles to get them renamed.  (I'm working on updates to #5287 which will do this for the Go server)
Example from the new rocm image:
root@65f5f0c84906:/# find /lib/ollama/runners/ -type f
/lib/ollama/runners/cpu/libggml.so
/lib/ollama/runners/cpu/libllama.so
/lib/ollama/runners/cpu/ollama_llama_server
/lib/ollama/runners/rocm_v60102/libggml.so
/lib/ollama/runners/rocm_v60102/libllama.so
/lib/ollama/runners/rocm_v60102/ollama_llama_server
/lib/ollama/runners/cpu_avx2/libggml.so
/lib/ollama/runners/cpu_avx2/libllama.so
/lib/ollama/runners/cpu_avx2/ollama_llama_server
/lib/ollama/runners/cpu_avx/libggml.so
/lib/ollama/runners/cpu_avx/libllama.so
/lib/ollama/runners/cpu_avx/ollama_llama_server

Closing in favor of #6547


Rocket pod definitions

Need a few rocket pods defined before release.  We can import the XCF FFARs and use the new TOW.
Fire-rates should be faster than rack missiles.
Firepower should be lower than rack missiles.
Should be able to hide the missile (to save fps + obscure unfolded fins etc)
Any launcher that is tube-shaped or cartridge-like is a pod. Racks differ in zero protection + variable caliber mounting.

how big rocket pods should be
i know 7 pod is ok but how about some big ones like
http://upload.wikimedia.org/wikipedia/commons/7/78/A-4_Skyhawk_rocket_pod.JPG
also i think we should add some bodygroups to them

Pods can apply caliber restrictions now in c140fea5ef1b37bb94e27cf5a222caea1353ac0d, let me know in a new issue if we need anything else.

Say, now that we have different rack sizes for some missiles (1x, 2x and 4x for BGM-71Es, 2x soon and 4x for AGM-114s), can we add a way of selecting a specific rack? Or do we already have that feature?

Not yet, but now that I know how to add things to the acf menu I can add something like that...  lemme see.

Done the rack selection in 1af96f9bfa2ef38bb126a7ef942788fa0bbe728d

Since most pods are already defined by now, and since news ones can be added within a matter of minutes, I think we can close this.


fix(targets): Use newline escaping for targets

The previous commit, 44a8c6e4e169cda7e4c95d434e7b388e2c7c1fe7 did not fix the issue as Craft's JSON output itself has new lines in it. This patch just uses the multi-line escaping recommended at https://github.community/t/set-output-truncates-multiline-strings/16852/3?u=byk

Gonna merge this as I manually verified and master is broken.


Added RowSimpleExpression, fixed parser bug not skipping expectation …

…when two of token expected, added more tests

Codecov Report

Merging #45 (21e1cea) into master (4733258) will increase coverage by 0.00%.
The diff coverage is 100.00%.

@@           Coverage Diff           @@
##           master      #45   +/-   ##
=======================================
  Coverage   91.62%   91.63%
=======================================
  Files         557      557
  Lines       14885    14889    +4
  Branches     2021     2022    +1
=======================================
+ Hits        13639    13643    +4
  Misses        990      990
  Partials      256      256

Impacted Files
Coverage Δ

src/mysql-grammar-2/compiled-grammar.generated.ts
100.00% <ø> (ø)

src/grammar-runtime-3/parser-2.ts
77.19% <100.00%> (ø)

...ql-grammar-2/expression/function-call/arguments.ts
100.00% <100.00%> (ø)

...rc/mysql-grammar-2/expression/simple-expression.ts
100.00% <100.00%> (ø)

src/mysql-grammar-2/syntax-kind.generated.ts
100.00% <100.00%> (ø)

src/scanner-2/scan-all.ts
89.06% <100.00%> (+0.08%)
: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 4733258...21e1cea. Read the comment docs.


added the possiblity to use an array of strings as message in git.com…

…mit and git.tag to the docs
based on one of the examples for git.commit

thanks!

Although I'm not sure if this is working with git.tag the same as it is working with git.commit. Trying it out now.

Okay. It's not working. Adding an array as message to git.tag throws this error:
Message:
    path.replace is not a function
Stack:
TypeError: path.replace is not a function
    at escapePathWin (C:\Users\HP\desktop\lapid\node_modules\any-shell-escape\shell-escape.js:14:23)
    at C:\Users\HP\desktop\lapid\node_modules\any-shell-escape\shell-escape.js:32:16
    at Array.forEach (native)
    at module.exports (C:\Users\HP\desktop\lapid\node_modules\any-shell-escape\shell-escape.js:31:19)
    at Object.module.exports [as tag] (C:\Users\HP\desktop\lapid\node_modules\gulp-git\lib\tag.js:24:18)


imported JS library serves adware

The library at http://cdn.imnjb.me/libs/humanize/0.0.9/humanize.min.js which is used in several examples seems to be compromised and is trying to show a popup ad

That's no good. I'll mark it as a high priority and take a look tomorrow.

Closed in #3


Inability to find SDK root/files in pkg/dartdev/test/native_assets/build_test and pkg/modular_test tests

The tests
pkg/dartdev/test/native_assets/build_test RuntimeError (expected Pass)
pkg/modular_test/test/find_sdk_root1_test RuntimeError (expected Pass)
pkg/modular_test/test/loader/loader_test RuntimeError (expected Pass)
pkg/modular_test/test/src/find_sdk_root2_test RuntimeError (expected Pass)

are failing on configurations
unittest-asserts-release-linux
unittest-asserts-release-win
unittest-asserts-release-mac

Example logs from each:

pkg/dartdev/test/native_assets/build_test
pkg/modular_test/test/find_sdk_root1_test
pkg/modular_test/test/loader/loader_test
pkg/modular_test/test/src/find_sdk_root2_test

Looking at the history, it looks like they went flaky after https://github.com/dart-lang/sdk/commit/089364baab3a6d3fc1a35a1f2d270cf1fb772a40, so guessing it's the fileset change in that commit?
/cc @sortie

I did just encounter another test that failed when sharded because it couldn't locate the sdk root. Sounds like we got a few more of those cases around, which will cause problems like this when I move them between the local runs and the sharded runs. I'll take a look, thanks Tess :)


[Event Request] Table 336 "Tracking Specification"

Could we please have a new publisher “OnBeforeInitExpirationDate” in function “InitExpirationDate” including a handle pattern?
procedure InitExpirationDate()
var
ItemTrackingCode: Record "Item Tracking Code";
ItemTrackingMgt: Codeunit "Item Tracking Management";
ExpDate: Date;
EntriesExist: Boolean;
*** start new code ***
IsHandled: Boolean;
*** stop new code ***
begin
*** start new code ***
IsHandled := false;
OnBeforeInitExpirationDate(Rec, xRec, IsHandled);
if IsHandled then begin
exit;
end;
*** stop new code ***

if ("Serial No." = xRec."Serial No.") and ("Lot No." = xRec."Lot No.") then
exit;

*** stop new code ***
[IntegrationEvent(false, false)]
local procedure OnBeforeInitExpirationDate(Rec: Record "Tracking Specification"; xRec: Record "Tracking Specification"; var IsHandled: Boolean)
begin
end;

Thanks for reporting this. We agree, and we’ll publish a fix asap, either in an update for the current version or in the next major release. We will update this issue with information about availability.


Resource loader (shaders, audio etc.)

To avoid in-game hiccups for shaders to build or audio to load, there should be a system that preloads these things at the start of the application.
It would be a simple list of materials & audios, which would be played and rendered. This would load them all at once at an expected time, so it wouldn't need to be done at unpredictable times later.

A shader resource loader wouldn't be that important if we could just use "recorded" shaders on Windows platforms and include them with Linux and Mac (which also use Vulkan). I'm not sure this is possible, since compiled shaders (aka "effects") only automatically include themselves in the running platform. This might have been done because there wasn't a unifying API used before -- but now there is: Vulkan. I need to test this out, but having other issues

Shaders might actually be used on different platforms! When including the data/db/XX shader outputs in the Mac, I got different output from Mac -- so it must have tried to use them.

Shaders can be easily added to any operating system. No shader resource loader is needed. An audio resource loader would be nice, though...


Add hpc access management menu to navbar

Description
Adds a navbar item to Coldfront providing links related to the group membership functionality. Also adds a simple check_access view available for all users to report their current access status to HPC resources.
To test this branch you must use the navbar branch of imperialcollegelondon/coldfront_development_environment. This uses a bit of a hack to implement this functionality in the hopes that we can get proper support for doing this later. I have ubccr/coldfront#635 open to try and get upstream support for this.
Fixes # (issue)
Type of change

[ ] Documentation (non-breaking change that adds or improves the documentation)
[ ] New feature (non-breaking change which adds functionality)
[ ] Optimization (non-breaking, back-end change that speeds up the code)
[ ] Bug fix (non-breaking change which fixes an issue)
[ ] Breaking change (whatever its nature)

Key checklist

[ ] All tests pass (eg. python -m pytest)
[ ] The documentation builds and looks OK (eg. python -m sphinx -b html docs docs/build)
[ ] Pre-commit hooks run successfully (eg. pre-commit run --all-files)

Further checks

[ ] Code is commented, particularly in hard-to-understand areas
[ ] Tests added or an issue has been opened to tackle that in the future. (Indicate issue here: # (issue))

@AdrianDAlessandro I will add a test in #54 after merging this.


Running on Mac OS X

I am attempting to run Conjure through nvim in the mac's Terminal bash, but I am getting an error when doing ConjureAdd.  It probably isn't a bug and more likely it is that I am new to nvim and doing something wrong.  But this plugin looks so good that it is finally pushing me to the vim side.  I  will understand if you deem it an issue with my setup and not a bug then please just close it.
I added this to my init.vim
`call plug#begin('~/.local/share/nvim/plugged')
Plug 'Olical/conjure', { 'tag': 'v0.8.2', 'do': 'make compile', 'for': 'clojure', 'on': 'ConjureAdd'  }
Plug 'junegunn/fzf', { 'dir': '~/.fzf', 'do': './install --all' }
Plug 'junegunn/fzf.vim'
" Initialize plugin system
call plug#end()`
I did a successful PlugInstall.  I am running a prepl in another Terminal that I can successfully connect to with nc localhost port.  However, in nvim when I do a ConjureAdd {:tag :dev, :port 40404}, it opens a vertical split window, but I get this error message:
Error from thread 'RPC message handler': #error {                                                                                :cause nil  :via  [{:type java.lang.NullPointerException    :message nil    :at [clojure.lang.Numbers ops Numbers.java 1068]}]  :trace  [[clojure.lang.Numbers ops Numbers.java 1068]   [clojure.lang.Numbers gt Numbers.java 259]   [conjure.ui$append invokeStatic ui.clj 48]   [conjure.ui$info invokeStatic ui.clj 68]   [conjure.prepl$add_BANG_ invokeStatic prepl.clj 102]   [conjure.main$fn__12976 invokeStatic main.clj 34]   [conjure.main$fn__12976 invoke main.clj 33]   [clojure.lang.MultiFn invoke MultiFn.java 229]   [conjure.rpc$init$fn__11386 invoke rpc.clj 168]   [clojure.core$binding_conveyor_fn$fn__5756 invoke core.clj 2030]   [clojure.lang.AFn call AFn.java 18]   [java.util.concurrent.FutureTask run FutureTask.java 264]   [java.util.concurrent.ThreadPoolExecutor runWorker ThreadPoolExecutor.java 1128]   [java.util.concurrent.ThreadPoolExecutor$Worker run ThreadPoolExecutor.java 628]   [java.lang.Thread run Thread.java 835]]}
When I quit out of nvim, I see this message:  Conjure exited, restarting
Thanks for any assistance you may provide

Thanks for giving this early version a go! Problems are definitely expected
right now.
I would guess this is to do with a number nvim is reporting back when I ask
for a buffer line count or something.
Could I get your Neovim version and Conjure logs? There's instructions to
add logging in the issue template, I think you just set CONJURE_LOG_PATH in
your env when you run nvim.
If you can reproduce it and get me that log it'll probably have the answer
in there.
Thanks! I hope your week is off to a good start other than this 😄
On Mon, 8 Apr 2019, 22:32 scotts777<EMAIL_ADDRESS>wrote:

I am attempting to run Conjure through nvim in the mac's Terminal bash,
but I am getting an error when doing ConjureAdd. It probably isn't a bug
and more likely it is that I am new to nvim and doing something wrong. But
this plugin looks so good that it is finally pushing me to the vim side. I
will understand if you deem it an issue with my setup and not a bug then
please just close it.
I added this to my init.vim
`call plug#begin('~/.local/share/nvim/plugged')
Plug 'Olical/conjure', { 'tag': 'v0.8.2', 'do': 'make compile', 'for':
'clojure', 'on': 'ConjureAdd' }
Plug 'junegunn/fzf', { 'dir': '~/.fzf', 'do': './install --all' }
Plug 'junegunn/fzf.vim'
" Initialize plugin system
call plug#end()`
I did a successful PlugInstall. I am running a prepl in another Terminal
that I can successfully connect to with nc localhost port. However, in nvim
when I do a ConjureAdd {:tag :dev, :port 40404}, it opens a vertical split
window, but I get this error message:
Error from thread 'RPC message handler': #error { :cause nil :via [{:type
java.lang.NullPointerException :message nil :at [clojure.lang.Numbers ops
Numbers.java 1068]}] :trace [[clojure.lang.Numbers ops Numbers.java 1068]
[clojure.lang.Numbers gt Numbers.java 259] [conjure.ui$append invokeStatic
ui.clj 48] [conjure.ui$info invokeStatic ui.clj 68]
[conjure.prepl$add_BANG_ invokeStatic prepl.clj 102]
[conjure.main$fn__12976 invokeStatic main.clj 34] [conjure.main$fn__12976
invoke main.clj 33] [clojure.lang.MultiFn invoke MultiFn.java 229]
[conjure.rpc$init$fn__11386 invoke rpc.clj 168]
[clojure.core$binding_conveyor_fn$fn__5756 invoke core.clj 2030]
[clojure.lang.AFn call AFn.java 18] [java.util.concurrent.FutureTask run
FutureTask.java 264] [java.util.concurrent.ThreadPoolExecutor runWorker
ThreadPoolExecutor.java 1128]
[java.util.concurrent.ThreadPoolExecutor$Worker run ThreadPoolExecutor.java
628] [java.lang.Thread run Thread.java 835]]}
When I quit out of nvim, I see this message: Conjure exited, restarting
Thanks for any assistance you may provide
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/Olical/conjure/issues/23, or mute the thread
https://github.com/notifications/unsubscribe-auth/AATPXQvq81KfMeR_WCBt8yXkWoF2ffsEks5ve7VogaJpZM4cjJ8K
.

Oh, just a hunch, does OSX have a /tmp anymore? I create the log buffer
there (it's not saved, it's just the path used for it since it's
consistent). If that's Linux only now that's explain it.
I can rethink the log buffer name if so!
On Tue, 9 Apr 2019, 08:23 Oliver Caldwell<EMAIL_ADDRESS>wrote:

Thanks for giving this early version a go! Problems are definitely
expected right now.
I would guess this is to do with a number nvim is reporting back when I
ask for a buffer line count or something.
Could I get your Neovim version and Conjure logs? There's instructions to
add logging in the issue template, I think you just set CONJURE_LOG_PATH in
your env when you run nvim.
If you can reproduce it and get me that log it'll probably have the answer
in there.
Thanks! I hope your week is off to a good start other than this 😄
On Mon, 8 Apr 2019, 22:32 scotts777<EMAIL_ADDRESS>wrote:

I am attempting to run Conjure through nvim in the mac's Terminal bash,
but I am getting an error when doing ConjureAdd. It probably isn't a bug
and more likely it is that I am new to nvim and doing something wrong. But
this plugin looks so good that it is finally pushing me to the vim side. I
will understand if you deem it an issue with my setup and not a bug then
please just close it.
I added this to my init.vim
`call plug#begin('~/.local/share/nvim/plugged')
Plug 'Olical/conjure', { 'tag': 'v0.8.2', 'do': 'make compile', 'for':
'clojure', 'on': 'ConjureAdd' }
Plug 'junegunn/fzf', { 'dir': '~/.fzf', 'do': './install --all' }
Plug 'junegunn/fzf.vim'
" Initialize plugin system
call plug#end()`
I did a successful PlugInstall. I am running a prepl in another Terminal
that I can successfully connect to with nc localhost port. However, in nvim
when I do a ConjureAdd {:tag :dev, :port 40404}, it opens a vertical split
window, but I get this error message:
Error from thread 'RPC message handler': #error { :cause nil :via [{:type
java.lang.NullPointerException :message nil :at [clojure.lang.Numbers ops
Numbers.java 1068]}] :trace [[clojure.lang.Numbers ops Numbers.java 1068]
[clojure.lang.Numbers gt Numbers.java 259] [conjure.ui$append invokeStatic
ui.clj 48] [conjure.ui$info invokeStatic ui.clj 68]
[conjure.prepl$add_BANG_ invokeStatic prepl.clj 102]
[conjure.main$fn__12976 invokeStatic main.clj 34] [conjure.main$fn__12976
invoke main.clj 33] [clojure.lang.MultiFn invoke MultiFn.java 229]
[conjure.rpc$init$fn__11386 invoke rpc.clj 168]
[clojure.core$binding_conveyor_fn$fn__5756 invoke core.clj 2030]
[clojure.lang.AFn call AFn.java 18] [java.util.concurrent.FutureTask run
FutureTask.java 264] [java.util.concurrent.ThreadPoolExecutor runWorker
ThreadPoolExecutor.java 1128]
[java.util.concurrent.ThreadPoolExecutor$Worker run ThreadPoolExecutor.java
628] [java.lang.Thread run Thread.java 835]]}
When I quit out of nvim, I see this message: Conjure exited, restarting
Thanks for any assistance you may provide
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/Olical/conjure/issues/23, or mute the thread
https://github.com/notifications/unsubscribe-auth/AATPXQvq81KfMeR_WCBt8yXkWoF2ffsEks5ve7VogaJpZM4cjJ8K
.

I am informed by the OSX dev to my right that it does have a /tmp, so it's probably not the /tmp/conjure.cljc buffer not being created. I would guess it's a setting in Neovim like "new lines at end of empty files" or something so the line count is reporting nil instead of 0.
Your logs will prove this though, every RPC call gets written there when it's enabled so we'll see what Conjure asked and what it got back from Neovim :smiley: should be an easy fix.

I really appreciate you taking the time to look into this.  Yes the /tmp exists and I can see the buffer in the split.  Here is the log output.
INFO [conjure.dev:17] - Logging initialised  INFO [conjure.rpc:132] - Starting RPC loops  TRACE [conjure.rpc:162] - Received RPC message: {:type :notify, :method :add, :params ["{:tag :dev, :port 40404}"]} INFO [conjure.prepl:110] - Adding :dev <IP_ADDRESS> 40404 TRACE [conjure.rpc:151] - Sending RPC message: {:type :request, :id 1, :method :nvim-execute-lua, :params ["return require('conjure').upsert_log(...)" ("/tmp/conjure.cljc" 40 false false)]} TRACE [conjure.rpc:120] - Sent request, awaiting response: {:type :request, :id 1, :method :nvim-execute-lua, :params ["return require('conjure').upsert_log(...)" ("/tmp/conjure.cljc" 40 false false)]} TRACE [conjure.rpc:154] - Sent! TRACE [conjure.rpc:162] - Received RPC message: {:type :response, :id 1, :error nil, :result nil} TRACE [conjure.rpc:26] - Received response: {:type :response, :id 1, :error nil, :result nil} TRACE [conjure.rpc:120] - Sent request, awaiting response: {:type :request, :id 1, :method :nvim-buf-line-count, :params [nil]} TRACE [conjure.rpc:151] - Sending RPC message: {:type :request, :id 1, :method :nvim-buf-line-count, :params [nil]} TRACE [conjure.rpc:154] - Sent! TRACE [conjure.rpc:162] - Received RPC message: {:type :response, :id 1, :error [0 "Wrong type for argument 1, expecting Buffer"], :result nil} TRACE [conjure.rpc:26] - Received response: {:type :response, :id 1, :error [0 "Wrong type for argument 1, expecting Buffer"], :result nil} ERROR [conjure.nvim:12] - Error while making nvim call {:method :nvim-buf-line-count, :params [nil]} -> {:error [0 "Wrong type for argument 1, expecting Buffer"], :result nil} ERROR [conjure.rpc:?] - Error from thread 'RPC message handler': java.lang.NullPointerException

Not a problem! You're helping me make a better tool by reporting it!
Received RPC message: {:type :response, :id 1, :error [0 "Wrong type for argument 1, expecting Buffer"], :result nil}
Hmm, that'll be the one. So I wonder why the buffer is nil, that should be the reference to the log buffer that comes back from the Lua code. A bit convoluted I know, but I have my reasons :sweat_smile:

Yea, it opens a vertical split and I see the name as /tmp/conjure.cljc, but if I do a :ls command the only buffer it lists is my starting buffer with clojure code.

On Apr 9, 2019, at 7:24 AM, Oliver Caldwell<EMAIL_ADDRESS>wrote:
Not a problem! You're helping me make a better tool by reporting it!
Received RPC message: {:type :response, :id 1, :error [0 "Wrong type for argument 1, expecting Buffer"], :result nil}
Hmm, that'll be the one. So I wonder why the buffer is nil, that should be the reference to the log buffer that comes back from the Lua code. A bit convoluted I know, but I have my reasons 😅
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub https://github.com/Olical/conjure/issues/23#issuecomment-481211725, or mute the thread https://github.com/notifications/unsubscribe-auth/AgnmyYG12AGSRYPMU6KQwanY2Aj8SrReks5vfHiKgaJpZM4cjJ8K.

This means that one of these is returning nil when it should be returning the buffer ID: https://github.com/Olical/conjure/blob/68c2dac95e2b82db693b623832371b2b2d935b93/lua/conjure.lua#L3-L49
And you won't see it in the buffer list, it's a special hidden thing that can't be accidentally written to a file or clutter your buffer list etc. As long as you can see the window with the buffer name set to /tmp/conjure.cljc that's enough proof for me.
So why the nil... I do wonder if it could be some sort of race condition that isn't present on my machine.

Is there anything else interesting / scaring in :messages? Like possibly related to these commands? https://github.com/Olical/conjure/blob/68c2dac95e2b82db693b623832371b2b2d935b93/lua/conjure.lua#L34-L41
I wonder if one of those could be failing and causing the Lua function to return nil after mostly creating the buffer.

No.  I don’t see anything more than the stack trace that I pasted in my first message.  If I run those commands manually in that buffer they seem to work.  Of course that may  not be apples to apples.

On Apr 9, 2019, at 7:34 AM, Oliver Caldwell<EMAIL_ADDRESS>wrote:
Is there anything else interesting / scaring in :messages? Like possibly related to these commands? https://github.com/Olical/conjure/blob/68c2dac95e2b82db693b623832371b2b2d935b93/lua/conjure.lua#L34-L41 https://github.com/Olical/conjure/blob/68c2dac95e2b82db693b623832371b2b2d935b93/lua/conjure.lua#L34-L41
I wonder if one of those could be failing and causing the Lua function to return nil after mostly creating the buffer.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub https://github.com/Olical/conjure/issues/23#issuecomment-481214300, or mute the thread https://github.com/notifications/unsubscribe-auth/AgnmyTA2Z6SvqcHWL0BRb86jCV7vHtlYks5vfHq2gaJpZM4cjJ8K.

Just out of interest, swapping your vim-plug call to 'commit': 'ecfb1c09e5e8258036dfb30f3927e33488533e98' doesn't help, right? I just fixed the requiring of Compliment if you don't have it in your project.

Changed to that commit and ran PlugUpdate and it looked like it pulled that commit version ok, but same  error with same :message and same log output.

Okay, I'm out of lunch time now but will have a look ASAP. Just need to try and repo which seems hard :grimacing: I'd be surprised if it was OSX specific but maybe! Do you have other plugins / settings or is it a blank neovim? I might try to repro it in a bare bones neovim environment.
Latest commit is better too, prints out the full stack trace when something goes wrong 063c29b54459a326b5ff244685dd2765bcd19adf.

Ok no problem and no rush for this, so take your time.  Yes I am pretty new to the vim world so it is a totally bare bones setup of Neovim that I am running in the built in Mac Terminal.app.  Thanks again.

I'll try a stripped down neovim soon and see if I can reproduce it there. I would put money on this being some weird setting that most people have set that might not be set by default. It's so odd how the Lua, Clojure and VimL is all up and talking to each other but still manages to get a nil where it shouldn't.
That nil means it couldn't find the Conjure buffer/window. This could be a race condition (ahhhhh) or it could just be a setting on the buffer / neovim instance. I'll work it out :smile:

Great!  Yes, I really like the look of your plugin and where it is heading with prepl!

On Apr 9, 2019, at 8:40 AM, Oliver Caldwell<EMAIL_ADDRESS>wrote:
I'll try a stripped down neovim soon and see if I can reproduce it there. I would put money on this being some weird setting that most people have set that might not be set by default. It's so odd how the Lua, Clojure and VimL is all up and talking to each other but still manages to get a nil where it shouldn't.
That nil means it couldn't find the Conjure buffer/window. This could be a race condition (ahhhhh) or it could just be a setting on the buffer / neovim instance. I'll work it out 😄
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub https://github.com/Olical/conjure/issues/23#issuecomment-481234116, or mute the thread https://github.com/notifications/unsubscribe-auth/AgnmycXA0KnNaczdCL5LbZAi7SSCvAHcks5vfIo-gaJpZM4cjJ8K.

Ah! OSX's /tmp is a symlink if I'm not mistaken to /private/tmp or something of the sort. Could you confirm that the Conjure buffer isn't in the place I expect by running :echo expand("%:p")? I bet it's not /tmp/conjure.cljc. I'll start looking for a better solution that should work for you now, if that is indeed the problem.

If my hunch is correct, this commit should fix it! If you get a chance to give it a go let me know how it goes :smile: https://github.com/Olical/conjure/commit/3918cbc58113f7475c4679efa818df7d0513c8a5

You’ve done it.   It works!  Interestingly when I ran the echo expand command it did print out /tmp/conjure.cljc.  However, I still tried your last commit and it worked!  Thanks again for your time and all your effort on Conjure

Well that's weird... definitely some strange path things going on here but glad the hunch was essentially correct. I think different functions in nvim are reporting different paths depending on your dir being in a symlink or not :grimacing:
But yay! It's fixed! Thank you for your thanks, there's a lot more to do before I'm relatively happy, I hope you get a lot of value out of my work :smile:


Add short URL for Profile Page

Is there a way to add a short url for the public profile widget?
https://alpha.near.org/#/sainthiago.near would redirect to https://alpha.near.org/#/adminalpha.near/widget/ProfilePage?accountId=sainthiago.near

ooh, that would be cool! and now that alpha -> near.org it could be near.org/santhiago.near.

A few changes have been made - the URL has been shorted to https://near.org/near/widget/ProfilePage?accountId=sainthiago.near


Update sidecar to latest versions

This commit is to update csi sidecars to release 1.1

What this PR does / why we need it:
Which issue this PR fixes (optional, in fixes #<issue number>(, fixes #<issue_number>, ...) format, will close that issue when PR gets merged): fixes #
Special notes for your reviewer:
Release note:

/test cloud-provider-openstack-unittest

/test cloud-provider-openstack-acceptance-test-csi-cinder

/test cloud-provider-openstack-acceptance-test-e2e-conformance-stable-branch-v1.12

/test cloud-provider-openstack-unittest

/test cloud-provider-openstack-acceptance-test-e2e-conformance

/test cloud-provider-openstack-acceptance-test-e2e-conformance

/retest

/retest

/test cloud-provider-openstack-acceptance-test-e2e-conformance-stable-branch-v1.15

/test cloud-provider-openstack-acceptance-test-e2e-conformance-stable-branch-v1.15

@ramineni Thanks!!
/lgtm

/approve


deprecate bm asset

Signed-off-by: ldpliu<EMAIL_ADDRESS>https://github.com/stolostron/backlog/issues/24149

/cc @JakobGray


server: add new API endpoints 'list' and 'leave'

This PR introduces 2 new API endpoints for the future lobby implementation:

list allows returning a list of instances for a given game
leave is the symmetric of join ; note that after the last player leaves a game instance, it is automatically destroyed

Checklist

[ ] Use a separate branch in your local repo (not master).
[ ] Test coverage is 100% (or you have a story for why it's ok).

follow-up to PR #256

Sorry @nicolodavis I lost your comments (add to do a force-push to update the PR)
but the implementation of new API remove and list is now done for Mongo and Firebase as well.

@francoijs Solid PR. Thanks!


Lab 1 - Need clarification in the Continuous Integration section

3- In the Section Continuous Integration (https://github.com/MSDEVMTL/GlobalAzureBootcamp-2019/tree/master/Lab1#continuous-integration)
around line 120 of the ReadMe.md file it's not clear how we get the Yaml template.
Just re-work that section to specify to pick the 'Asp.Net Core template' that is by default recommended... a screenshot could be useful.

new instruction added


[Question] Restoring PersistentVolumeClaims and VolumeSnapshots after failure

Managing critical failures with Ceph-CSI
We plan to use CephFS as out persistent storage in Kubernetes with Ceph-CSI, so we want to create PersistentVolumeClaims and VolumeSnapshots and let the CSI driver handle the rest on the Ceph side.
Now let's assume there is a critical Ceph failure, and we are able to restore the Ceph cluster to an earlier state. However, now probably some of the PersistentVolumes/VolumeSnapshotsContents are inconsistent with Ceph subvolumes and subvolumesnapshots. What is the recommended way to reconcile the kubernetes objects? Are there some tools for this?

I'll be a bit more specific.
I experimented with the following scenario: created manually using ceph commands a subvolume /volume/csi/restore-test,
and then tried to create a PVC and PV that would point to this manually created subvolume. This is to emulate disaster recovery of a CephFS state where the subvolume still existed but the corresponding PVC and PV has been removed from kubernetes.
The used manifests:
apiVersion: v1
kind: PersistentVolume
metadata:
  annotations:
    pv.kubernetes.io/provisioned-by: rook-ceph.cephfs.csi.ceph.com
  name: test-restore-dynamic-pv
spec:
  accessModes:
    - ReadWriteMany
  capacity:
    storage: 50Gi
  claimRef:
    apiVersion: v1
    kind: PersistentVolumeClaim
    name: test-restore-dynamic-pvc
    namespace: nv-apps
  csi:
    controllerExpandSecretRef:
      name: rook-csi-cephfs-provisioner
      namespace: rook-ceph
    driver: rook-ceph.cephfs.csi.ceph.com
    fsType: ext4
    nodeStageSecretRef:
      name: rook-csi-cephfs-node
      namespace: rook-ceph
    volumeAttributes:
      clusterID: rook-ceph
      fsName: cephfs
      mounter: fuse
      pool: cephfs-data0
      provisionVolume: "true"
      storage.kubernetes.io/csiProvisionerIdentity:<PHONE_NUMBER>089-8081-rook-ceph.cephfs.csi.ceph.com
      subvolumeName: restore-test
    volumeHandle: 0001-0009-rook-ceph-0000000000000001-restore-test
  persistentVolumeReclaimPolicy: Delete
  storageClassName: rook-cephfs
  volumeMode: Filesystem
---
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  annotations:
    volume.beta.kubernetes.io/storage-provisioner: rook-ceph.cephfs.csi.ceph.com
  name: test-restore-dynamic-pvc
  namespace: nv-apps
spec:
  accessModes:
    - ReadWriteMany
  resources:
    requests:
      storage: 50Gi
  storageClassName: rook-cephfs
  volumeMode: Filesystem
  volumeName: test-restore-dynamic-pv

I obtained the above yamls by editing a working PVC & PV setup. After applying them, this is their state:
apiVersion: v1
kind: PersistentVolume
metadata:
  annotations:
    kubectl.kubernetes.io/last-applied-configuration: |
      {"apiVersion":"v1","kind":"PersistentVolume","metadata":{"annotations":{"pv.kubernetes.io/provisioned-by":"rook-ceph.cephfs.csi.ceph.com"},"name":"test-restore-dynamic-pv"},"spec":{"accessModes":["ReadWriteMany"],"capacity":{"storage":"50Gi"},"claimRef":{"apiVersion":"v1","kind":"PersistentVolumeClaim","name":"test-restore-dynamic-pvc","namespace":"nv-apps"},"csi":{"controllerExpandSecretRef":{"name":"rook-csi-cephfs-provisioner","namespace":"rook-ceph"},"driver":"rook-ceph.cephfs.csi.ceph.com","fsType":"ext4","nodeStageSecretRef":{"name":"rook-csi-cephfs-node","namespace":"rook-ceph"},"volumeAttributes":{"clusterID":"rook-ceph","fsName":"cephfs","mounter":"fuse","pool":"cephfs-data0","provisionVolume":"true","storage.kubernetes.io/csiProvisionerIdentity":"1598689805089-8081-rook-ceph.cephfs.csi.ceph.com","subvolumeName":"restore-test"},"volumeHandle":"0001-0009-rook-ceph-0000000000000001-restore-test"},"persistentVolumeReclaimPolicy":"Delete","storageClassName":"rook-cephfs","volumeMode":"Filesystem"}}
    pv.kubernetes.io/provisioned-by: rook-ceph.cephfs.csi.ceph.com
  creationTimestamp: "2020-09-10T11:44:15Z"
  finalizers:
  - kubernetes.io/pv-protection
  name: test-restore-dynamic-pv
  resourceVersion: "10847315"
  selfLink: /api/v1/persistentvolumes/test-restore-dynamic-pv
  uid: 909e8d9d-dfd3-4e4f-8738-4548266d4695
spec:
  accessModes:
  - ReadWriteMany
  capacity:
    storage: 50Gi
  claimRef:
    apiVersion: v1
    kind: PersistentVolumeClaim
    name: test-restore-dynamic-pvc
    namespace: nv-apps
    resourceVersion: "10847313"
    uid: 65c65cfa-6bf3-4b8d-8abc-c9a068cabb5a
  csi:
    controllerExpandSecretRef:
      name: rook-csi-cephfs-provisioner
      namespace: rook-ceph
    driver: rook-ceph.cephfs.csi.ceph.com
    fsType: ext4
    nodeStageSecretRef:
      name: rook-csi-cephfs-node
      namespace: rook-ceph
    volumeAttributes:
      clusterID: rook-ceph
      fsName: cephfs
      mounter: fuse
      pool: cephfs-data0
      provisionVolume: "true"
      storage.kubernetes.io/csiProvisionerIdentity:<PHONE_NUMBER>089-8081-rook-ceph.cephfs.csi.ceph.com
      subvolumeName: restore-test
    volumeHandle: 0001-0009-rook-ceph-0000000000000001-restore-test
  persistentVolumeReclaimPolicy: Delete
  storageClassName: rook-cephfs
  volumeMode: Filesystem
status:
  phase: Bound
---
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  annotations:
    kubectl.kubernetes.io/last-applied-configuration: |
      {"apiVersion":"v1","kind":"PersistentVolumeClaim","metadata":{"annotations":{"volume.beta.kubernetes.io/storage-provisioner":"rook-ceph.cephfs.csi.ceph.com"},"name":"test-restore-dynamic-pvc","namespace":"nv-apps"},"spec":{"accessModes":["ReadWriteMany"],"resources":{"requests":{"storage":"50Gi"}},"storageClassName":"rook-cephfs","volumeMode":"Filesystem","volumeName":"test-restore-dynamic-pv"}}
    pv.kubernetes.io/bind-completed: "yes"
    volume.beta.kubernetes.io/storage-provisioner: rook-ceph.cephfs.csi.ceph.com
  creationTimestamp: "2020-09-10T11:44:15Z"
  finalizers:
  - kubernetes.io/pvc-protection
  name: test-restore-dynamic-pvc
  namespace: nv-apps
  resourceVersion: "10847363"
  selfLink: /api/v1/namespaces/nv-apps/persistentvolumeclaims/test-restore-dynamic-pvc
  uid: 65c65cfa-6bf3-4b8d-8abc-c9a068cabb5a
spec:
  accessModes:
  - ReadWriteMany
  resources:
    requests:
      storage: 50Gi
  storageClassName: rook-cephfs
  volumeMode: Filesystem
  volumeName: test-restore-dynamic-pv
status:
  accessModes:
  - ReadWriteMany
  capacity:
    storage: 50Gi
  phase: Bound

This looks good, but when trying to mount the PVC, I get the below error message in csi-cephfsplugin:
E0910 10:57:45.048625 1 utils.go:163] ID: 1373 Req-ID: 0001-0009-rook-ceph-0000000000000001-restore-test GRPC error: rpc error: code = Internal desc = missing required field monitors

@tamas-ac resize/ snapshot on static PVC  is not supported in cephcsi as of now.

Managing critical failures with Ceph-CSI
We plan to use CephFS as out persistent storage in Kubernetes with Ceph-CSI, so we want to create PersistentVolumeClaims and VolumeSnapshots and let the CSI driver handle the rest on the Ceph side.

Now let's assume there is a critical Ceph failure, and we are able to restore the Ceph cluster to an earlier state. However, now probably some of the PersistentVolumes/VolumeSnapshotsContents are inconsistent with Ceph subvolumes and subvolumesnapshots. What is the recommended way to reconcile the kubernetes objects? Are there some tools for this?

if have restored the ceph cluster and the ceph cluster is having rbd images/cephfs subvolumes with the same names as before everything works smoothly,  if names are different, the best options would be renaming the subvolumes to match the earlier names

@Madhu-1 thanks for the heads up on expand/delete and snapshots for static PVC!
I assumed that if the ceph cluster can be restored, the existing PVCs should work. I'm concerned about subvolumes where the PVC is no longer there.
Example:

Create a dynamic PVC 'pvc-1'. Kubernetes provisions a PV 'pv-', binds it to 'pvc-1' and everything works.
The entire Ceph cluster is backed up, let's call this state "ceph-bckp"
PVC 'pvc-1' is deleted. As the reclaimPolicy is Delete, the corresponding subvolume is removed from CephFS
Critical failure happens, Ceph cluster is restored to "ceph-bckp"
Now the subvolume behind 'pv-' exists again, but the kubernetes objects 'pvc-1' and 'pv-' don't

The above scenario is relevant also in case there is no critical failure, only 'pvc-1' is deleted by mistake and should be restored from backup.
I'd like to figure out if it's possible to recreate the 'pvc-1' and 'pv-' kubernetes objects in this case so that they work again.

@Madhu-1 thanks for the heads up on expand/delete and snapshots for static PVC!
I assumed that if the ceph cluster can be restored, the existing PVCs should work. I'm concerned about subvolumes where the PVC is no longer there.
Example:

Create a dynamic PVC 'pvc-1'. Kubernetes provisions a PV 'pv-', binds it to 'pvc-1' and everything works.
The entire Ceph cluster is backed up, let's call this state "ceph-bckp"
PVC 'pvc-1' is deleted. As the reclaimPolicy is Delete, the corresponding subvolume is removed from CephFS
Critical failure happens, Ceph cluster is restored to "ceph-bckp"
Now the subvolume behind 'pv-' exists again, but the kubernetes objects 'pvc-1' and 'pv-' don't

The above scenario is relevant also in case there is no critical failure, only 'pvc-1' is deleted by mistake and should be restored from backup.

I think if you periodically back up the kubernetes objects, you can recreate it back
in  PV output the CSI part is the main for CSI, if you can add the CSI section as before in think you can reuse things
this example is for rbd
csi:
    controllerExpandSecretRef:
      name: rook-csi-rbd-provisioner
      namespace: rook-ceph
    driver: rook-ceph.rbd.csi.ceph.com
    fsType: ext4
    nodeStageSecretRef:
      name: rook-csi-rbd-node
      namespace: rook-ceph
    volumeAttributes:
      clusterID: rook-ceph
      imageFeatures: layering
      imageFormat: "2"
      imageName: csi-vol-17382c21-f35a-11ea-9abc-0242ac110008
      journalPool: replicapool
      pool: replicapool
      radosNamespace: ""
      storage.kubernetes.io/csiProvisionerIdentity:<PHONE_NUMBER>781-8081-rook-ceph.rbd.csi.ceph.com
    volumeHandle: 0001-0009-rook-ceph-0000000000000002-17382c21-f35a-11ea-9abc-0242ac110008

volumeHandle: 0001-0009-rook-ceph-0000000000000002-17382c21-f35a-11ea-9abc-0242ac110008  is important for use its encoded one and  its container ceph pool, clusterid and subvolume/rbd name to easily identify the backend image.

I'd like to figure out if it's possible to recreate the 'pvc-1' and 'pv-' kubernetes objects in this case so that they work again.

Thanks @Madhu-1, indeed restoring PVCs and PVs works if I use a volumeHandle that was generated by the CSI driver.
Is the same expected to work with VolumeSnapshots? I tried a similar method for restoring together the VolumeSnapshot and VolumeSnapshotContents:
apiVersion: snapshot.storage.k8s.io/v1beta1
kind: VolumeSnapshotContent
metadata:
  annotations:
    snapshot.storage.kubernetes.io/deletion-secret-name: rook-csi-cephfs-provisioner
    snapshot.storage.kubernetes.io/deletion-secret-namespace: rook-ceph
  generation: 1
  name: snapcontent-48ac51de-07c2-4bcb-8b5b-813ac290d492
spec:
  deletionPolicy: Delete
  driver: rook-ceph.cephfs.csi.ceph.com
  source:
    volumeHandle: 0001-0009-rook-ceph-0000000000000001-27ddbf75-f362-11ea-a532-0a2b3642575d
  volumeSnapshotClassName: ceph-snapclass
  volumeSnapshotRef:
    apiVersion: snapshot.storage.k8s.io/v1beta1
    kind: VolumeSnapshot
    name: snapshot-4333-staging
    namespace: nv-apps
status:
  creationTime:<PHONE_NUMBER>127236000
  readyToUse: true
  restoreSize:<PHONE_NUMBER>0
  snapshotHandle: 0001-0009-rook-ceph-0000000000000001-141538e8-f364-11ea-a532-0a2b3642575d
---
apiVersion: snapshot.storage.k8s.io/v1beta1
kind: VolumeSnapshot
metadata:
  generation: 1
  name: snapshot-4333-staging
  namespace: nv-apps
spec:
  source:
    persistentVolumeClaimName: instance-2067-staging
  volumeSnapshotClassName: ceph-snapclass
status:
  boundVolumeSnapshotContentName: snapcontent-48ac51de-07c2-4bcb-8b5b-813ac290d492
  readyToUse: true
  restoreSize: 50Gi

However, I encountered here
Failed to check and update snapshot content: failed to take snapshot
of the volume, 0001-0009-rook-ceph-0000000000000001-27ddbf75-f362-11ea-a532-0a2b3642575d:
"cannot create snapshot. Snapshot content snapcontent-48ac51de-07c2-4bcb-8b5b-813ac290d492
not bound to a snapshot"

Also found a new VolumeSnapshotContent object being created - seem like the VolumeSnapshot controller insists on creating  a new snapshot.
I managed to create the VolumeSnapshot and VolumeSnapshotContent as pre-provisioned, but in that case deleting the VolumeSnapshotContent does not trigger the deletion of the subvolume, and this defeats the purpose of using kubernetes objects to manage snapshots on CephFS.

Deleting the snapshotcontent wont trigger any CSI calls, if you delete the volumesnapshot object it should trigger the DeleteSnapshot Request can you please check.

I hope most of the questions are answered, closing this one

Thanks for the help, I'm not sure VolumeSnapshots work according to the same logic as PVCs but I'll need to do some more testing.

@tamas-ac Please feel free to reopen  if you need any help


Not functional After Alpha 70

I opened a new terminal and this is all i get.

Works again when reverting to Alpha 69

I should point out this is the windows version

I think you should take a look at #653  since there you could also find a workaround until a fix is in place.

Duplicate of #653


Useful labels missing from Prometheus node_exporter in 1.7.x

What did you do?
Upgraded to GKE 1.7.*
What did you expect to see?
Same metrics as before
What did you see instead? Under which circumstances?
Missing lots of meta data (labels) from my metrics

Prometheus configuration file:

prometheus.yml: |-
    global:
      scrape_interval: 15s
    scrape_configs:
    - job_name: 'kubernetes-nodes'

      scheme: https

      tls_config:
        ca_file: /var/run/secrets/kubernetes.io/serviceaccount/ca.crt
      bearer_token_file: /var/run/secrets/kubernetes.io/serviceaccount/token

      kubernetes_sd_configs:
      - role: node

      relabel_configs:
      - action: labelmap
        regex: __meta_kubernetes_node_label_(.+)
      - target_label: __address__
        replacement: kubernetes.default.svc:443
      - source_labels: [__meta_kubernetes_node_name]
        regex: (.+)
        target_label: __metrics_path__
        replacement: /api/v1/nodes/${1}/proxy/metrics
    - job_name: 'kubernetes-cadvisor'
      scheme: https

      tls_config:
        ca_file: /var/run/secrets/kubernetes.io/serviceaccount/ca.crt
      bearer_token_file: /var/run/secrets/kubernetes.io/serviceaccount/token

      kubernetes_sd_configs:
      - role: node

      relabel_configs:
      - action: labelmap
        regex: __meta_kubernetes_node_label_(.+)
      - target_label: __address__
        replacement: kubernetes.default.svc:443
      - source_labels: [__meta_kubernetes_node_name]
        regex: (.+)
        target_label: __metrics_path__
        replacement: /api/v1/nodes/${1}:4194/proxy/metrics
    - job_name: 'kubernetes-apiservers'
      kubernetes_sd_configs:
      - role: endpoints
      scheme: https
      tls_config:
        ca_file: /var/run/secrets/kubernetes.io/serviceaccount/ca.crt
      bearer_token_file: /var/run/secrets/kubernetes.io/serviceaccount/token
      relabel_configs:
      - source_labels: [__meta_kubernetes_namespace, __meta_kubernetes_service_name, __meta_kubernetes_endpoint_port_name]
        action: keep
        regex: default;kubernetes;https
    - job_name: 'kubernetes-service-endpoints'
      kubernetes_sd_configs:
      - role: endpoints
      relabel_configs:
      - source_labels: [__meta_kubernetes_service_annotation_prometheus_io_scrape]
        action: keep
        regex: true
      - source_labels: [__meta_kubernetes_service_annotation_prometheus_io_scheme]
        action: replace
        target_label: __scheme__
        regex: (https?)
      - source_labels: [__meta_kubernetes_service_annotation_prometheus_io_path]
        action: replace
        target_label: __metrics_path__
        regex: (.+)
      - source_labels: [__address__, __meta_kubernetes_service_annotation_prometheus_io_port]
        action: replace
        target_label: __address__
        regex: (.+)(?::\d+);(\d+)
        replacement: $1:$2
      - action: labelmap
        regex: __meta_kubernetes_service_label_(.+)
      - source_labels: [__meta_kubernetes_service_namespace]
        action: replace
        target_label: kubernetes_namespace
      - source_labels: [__meta_kubernetes_service_name]
        action: replace
        target_label: kubernetes_name
    - job_name: 'kubernetes-services'
      scheme: https
      metrics_path: /probe
      params:
        module: [http_2xx]
      kubernetes_sd_configs:
      - role: service
      relabel_configs:
      - source_labels: [__meta_kubernetes_service_annotation_prometheus_io_probe]
        action: keep
        regex: true
      - source_labels: [__address__]
        target_label: __param_target
      - target_label: __address__
        replacement: blackbox
      - source_labels: [__param_target]
        target_label: instance
      - action: labelmap
        regex: __meta_kubernetes_service_label_(.+)
      - source_labels: [__meta_kubernetes_service_namespace]
        target_label: kubernetes_namespace
      - source_labels: [__meta_kubernetes_service_name]
        target_label: kubernetes_name
    - job_name: 'kubernetes-pods'
      scheme: https
      kubernetes_sd_configs:
      - role: pod
      relabel_configs:
      - source_labels: [__meta_kubernetes_pod_annotation_prometheus_io_scrape]
        action: keep
        regex: true
      - source_labels: [__meta_kubernetes_pod_annotation_prometheus_io_path]
        action: replace
        target_label: __metrics_path__
        regex: (.+)
      - source_labels: [__address__, __meta_kubernetes_pod_annotation_prometheus_io_port]
        action: replace
        regex: (.+):(?:\d+);(\d+)
        replacement: ${1}:${2}
        target_label: __address__
      - action: labelmap
        regex: __meta_kubernetes_pod_label_(.+)
      - source_labels: [__meta_kubernetes_pod_namespace]
        action: replace
        target_label: kubernetes_namespace
      - source_labels: [__meta_kubernetes_pod_name]
        action: replace
        target_label: kubernetes_pod_name

In my previous version of GKE < 1.7 I'm able to see lots of labels associated with node_exporter info. Namely node_cpu at this point.
Here's an example of an older version:
node_cpu{beta_kubernetes_io_arch="amd64",beta_kubernetes_io_instance_type="n1-standard-2",beta_kubernetes_io_os="linux",cloud_google_com_gke_nodepool="default-pool",cpu="cpu1",failure_domain_beta_kubernetes_io_region="europe-west1",failure_domain_beta_kubernetes_io_zone="europe-west1-b",instance="my-cluster-default-pool-3cbb3136-22jh",job="kubernetes-node-exporter",kubernetes_io_hostname="my-cluster-default-pool-3cbb3136-22jh",mode="system"}

As you can see there's tons of useful information there I can group by. Most important to me is the instance name, node pool and region/zone.
Here's an example from a 1.7 cluster:
node_cpu{app="node-exporter",cpu="cpu1",instance="<IP_ADDRESS>:9100",job="kubernetes-service-endpoints",kubernetes_name="node-exporter",mode="system",name="node-exporter"}

In the newer version I'm missing all of the context about the node. The best I can do with this data is to group on instance and in my legend I'll only see a list of internal ip's instead of hostnames.
I have filed this issue previous on the node-exporter issues previously: prometheus/node_exporter#678 At that pointed they requested I open an issue with GKE: kubernetes/kubernetes#52858 and finally Kubernetes team is requesting I open this ticket...so I'm a bit lost in the mix here.
Any help is much appreciated.

It makes more sense to ask questions like this on the prometheus-users mailing list rather than in a GitHub issue. On the mailing list, more people are available to potentially respond to your question, and the whole community can benefit from the answers provided.

poor @ericuldall has been ping ponged all over the internet seeking an answer to this one

This is mostly likey a Prometheus usage question, and usage questions are handled on the mailing list. You must appreciate that we get several usage questions a day incorrectly filed as bugs, so we can't divert too much attention from development work for all of them.

No complaints here. Just looking for someone who knows the answer 👍
I've been a bit distracted from this hunt lately. I'll head over to the mailing list soon!

I've posted my question in the group as suggested: https://groups.google.com/forum/#!topic/prometheus-users/2njYh6SucJ8


Update jQuery

Currently at 1.7.2, but could be at 3.3.1 as per https://github.com/silverstripe/silverstripe-userforms/pull/713
This would have the added bonus of not conflicting with other versions that may be required on page.

Done with d8eb29e57c8d3123456b23e39ac988d10af350ce


Changed the yuglify.js testing file to match output from yuglify 2.0.0.

Updated the yuglify.js file to bring it in line with the yuglify 2.0.0 output that is installed by npm. Should solve the failing yuglify tests. There is another pull request from October that pins yuglify #644 that seems like it could solve the problem as well.

Coverage remained the same at 82.133% when pulling ab85d931ded8967bfd94fe948256a6020e39bbae on jdmold:yuglify-200 into 4314d1eb7d03a347bd200432d1441dabc0f91e72 on jazzband:master.

@jdmold Can you pin a version of yuglify.js like @kronion do in #644.

Then either update to this branch or create a new PR.


window.analytics.initialize is true even when window.mixpanel is uninitialized

When using Segment with the Mixpanel integration, we noticed that window.analytics.initialize was returning true despite window.mixpanel being uninitialized and set to an empty array ([]).
If the mixpanel integration is enabled, I would expect window.analytics.initialize to be false until window.mixpanel is initialized.
We are accessing window.mixpanel briefly right after we check if analytics are initialized, and this was causing quite the issue. We've solved it for the time being using this slightly hacky condition: window.analytics.initialize && (!window.mixpanel || Object.prototype.toString.call(mixpanel) !== '[object Array]') - wherein we check that mixpanel is either disabled (window.mixpanel being falsy) or that mixpanel is initialized (window.mixpanel not being an array).

Hmm are you using window.mixpanel inside .ready()? ref: https://segment.com/docs/libraries/analytics.js/#ready
analytics.ready(function(){
    window.mixpanel ..
});

Ah, thanks for the tip. We actually weren't, Nevermind this issue then, the ready method is what we were looking for. Cheers.


Add vendor/.keep

Summary
Add vendor/.keep

Coverage remained the same at 100.0% when pulling 54d860ac190535f54cedcfd9e9e4c57926ef8f06 on features/vendor-dir into c73806deaee6afc33ebd7c0d138ff7df367d4b41 on master.

Coverage remained the same at 100.0% when pulling 54d860ac190535f54cedcfd9e9e4c57926ef8f06 on features/vendor-dir into c73806deaee6afc33ebd7c0d138ff7df367d4b41 on master.


Pub build command failing in CI

I have a angular dart app where pub build works fine locally, but on a gitlab runner running docker in docker (dind) I get the following error:
Connection failed (OS Error: Network is unreachable, errno = 101), address = pub.dartlang.org, port = 443
Here's the full pub build output https://gist.github.com/unibeck/64fcb55ba8cb3b25037847a5c4a2d8cb
It's interesting to note that I've reran the job a few times and got the same error but with a different address such as address = pub.dartlang.org or address = storage.googleapis.com
The last job that didn't have this problem occurred at 9/5/17 5:14 PM ET
The first job that had this problem occurred at 9/5/17 9:12 PM ET
The latest job that had this problem occurred at 9/6/17 8:51 AM ET
The docker image I'm using is custom built off docker-alpine with jdk8, gradle3.4, and dart1.24.2 installed. Let me know if there's any more information I could provide about my CI setup.

This kind of error message occurs if the pub client cannot establish a tcp connection to the server. The issue ist almost certainly on the client side.
If you can somehow log into your docker container, you might be able to diagnose the issue by probing connectivity to the network. It might have also something todo with your gitlab runner hosting service.
Closing this issue, since it seems not related to our server.


Update project to Xcode 13, iOS 15 and watchOS 8

Update project dependencies
Update project to run in Xcode 13
Update deployment target to iOS 14 and watchOS 7
Fix issues caused by updates
Update SwiftGen config

The last stop of Danger is broken, I'll merge this (the test are passing) and fix Danger in the next PR.


Switch Mattermost Desktop to stable URL and msi installer

Description

Mattermost switched to msi installers.
Previous version of the update script was relying on GitHub HTML parsing which was a really fragile solution. We are now using the GitHub API.

Motivation and Context
Se above
How Has this Been Tested?
Tested locally with AU env Windows 10 Pro dev machine.
Screenshot (if appropriate, usually isn't needed):
Types of changes

[x] Bug fix (non-breaking change which fixes an issue)
[ ] New feature (non-breaking change which adds functionality)
[ ] Breaking change (fix or feature that would cause existing functionality to change)
[ ] Migrated package (a package has been migrated from another repository)

Checklist:

[x] My code follows the code style of this repository.
[ ] My change requires a change to documentation (this usually means the notes in the description of a package).
[ ] I have updated the documentation accordingly (this usually means the notes in the description of a package).
[x] All files are up to date with the latest Contributing Guidelines
[x] The added/modified package passed install/uninstall in the chocolatey test environment.
[x] The changes only affect a single package (not including meta package).

:white_check_mark: Package verification completed without issues. PR is now pending human review


More sidekiq workers in production

We're now doing bulk republishing of documents from Whitehall, some of which take some time to process. The jobs are a mix of CPU and publishing-api bound. Adding more workers will improve throughput. There is enough space in CPU and RAM on the Whitehall backend boxes. This has been verified in integration.

👍
Is it worth it to comment the rough calculation here, so that people can change this if the machines change?

No real calculation other than "this has a marked increase in throughput, and when we tested it on integration it didn't kill the box"


Should not polyfill in non-secure contexts

From the WebXR spec:
partial interface Navigator {
  [SecureContext, SameObject] readonly attribute XR xr;
};

The [SecureContext] bit there says that navigator.xr should only be available on secure pages (basically either https or localhost - more details here). Native implementations like Chrome's will honor this, returning undefined for navigator.xr, which currently causes the full polyfill to be injected on non-secure pages.
In my opinion the polyfill should not inject itself in this case, both to comply with the spirit of the spec and to help developers avoid confusion where their non-secure pages developed with the polyfill "work" but break in the future. Open to discussion of course.

Some thoughts:

:+1: for attempting to match a real implementation so there's no shock when trying on a supported browser.
It's valuable to test the polyfill locally -- browsers have secure context escape hatches via flags or blessed URLs (localhost, <IP_ADDRESS>, etc.). It should continue to work locally without running an HTTPS server.

Two ways those could both be achieved:

console.error a message when the polyfill executes in an insecure context. This can be approximated by checking the protocol, with the edge cases being perhaps a browser deems an SSL "insecure", or breaking an iframe policy. Still testable locally, message in the console of the discrepency, similar to API monkeypatching (ex: "fooBar() is deprecated; please use requestFooBar()").
Require a flag to the polyfill that allows execution even in insecure, local contexts. Would be a pain to flip this on and off when going through a suite of examples like webxr-samples, and still may have this enabled when in non-development.

I think logging a warning to the console about the discrepency is the best way to go at the moment

WebVR does work on Oculus Quest on insecure context, but it was confusing when experience that worked on HTTP, didn't work on HTTPS.
So adding a warning that says that the experience is using Polyfill and WebXR isn't working on insecure contexts could help.

Speaking as someone who was just bitten by this, I would like something to be surfaced.  I use ngrok for testing, and Oculus browser defaults to http instead of https if you type in a domain, both of which work with ngrok.  I was testing a WebXR app and it was not working, behaving weird, etc., and finally someone suggested this might be the reason (webxr not being exposed because of http, polyfill faking it with webvr).
Issue: the polyfill doesn't necessarily know if WebXR is available IF you were using a secure context.  BUT, if could at least print something like "emulating webxr using webvr. This is an insecure http connection, if you browser supports webxr it won't be available over an insecure context, consider trying https."
I would have noticed if there was anything reported to the console.


What is the definition of $value in an alert template?

https://prometheus.io/docs/prometheus/latest/configuration/alerting_rules/
"The $value variable holds the evaluated value of an alert instance."
It would be great if this also included a more explicit definition. Is it everything to the left of the comparison operator in the expr?

It's exactly what it says, the value. Comparison operators are orthogonal.
It makes more sense to ask questions like this on the prometheus-users mailing list rather than in a GitHub issue. On the mailing list, more people are available to potentially respond to your question, and the whole community can benefit from the answers provided.


Make m:n nested updates API consistent with 1:1 and 1:m

Nested updates in the form of User.update({id: 1 }, { posts: [ { id: 1, title: 'Test post - updated' }] }) work for 1:1 and 1:m associations but breaks for m:n associations. The API for this should be consistent between association types.
PR balderdashy/waterline-adapter-tests#51 provides the failing tests for this feature.
#292 - Add .add(), .remove(), .save() support for 1-1 and 1- associations* complements this by making the API across 1:1, 1:m and m:n the same for all operations.

I surprised this is an issue, honestly.  What occurs instead of a successful update?  Is it possibly updated in the database, but not reflected in the results waterline returns?

The child values are left untouched but the association to the child is set correctly.
The tests do a .find() after the update (https://github.com/balderdashy/waterline-adapter-tests/pull/51/files#diff-4a8c2e665523976121614a83468c4a69L176) so I don't think it was updated in the DB.

We'll wanna look around here: https://github.com/balderdashy/waterline/blob/master/lib/waterline/utils/nestedOperations/update.js#L167-L169

@devinivy you are like a travel guide to waterline core code! :smiley:

This is the sole blocker for https://github.com/balderdashy/waterline-adapter-tests/pull/51


History with reddit.com string is wiped out - history.json is fine

Ripme version: 1.5.15
Java version: java version "1.6.0_65"
Operating system: macOS 10.12.6
Exact URL you were trying to rip when the problem occurred: n/a
Please include any additional information about how to reproduce the problem:
Upon loading, the history leaves out all reddit.com URLs. Only lists the imgur and other URLs. History.json contains a complete list of all URLs.

Expected Behavior
All URLs should be shown
Actual Behavior
Only imgur and non-reddit.com urls show up in the history tab

Can you give me an example URL?

Sure, try https://www.reddit.com/user/Gingerpuss
Rip and exit and then start ripme.jar and look at history tab.

Rip and exit and then start ripme.jar and look at history tab.

I did and everything seems fine. The url is in history. This might has something to do with your ancient java version, try updating to a more recent version and try ripping the url again

I have a similar bug but with all history wiped(imgur/instagram/reddit/twitter/etc) since version 1.5.14 with Java 1.8.0_151.
I think the reason is ripme use AppData/Local folder and don't use the folder where it run.

I think the reason is ripme use AppData/Local folder and don't use the folder where it run.

That's pretty odd. I don't see why ripme wouldn't be able to read and write from AppData/Local (Unless you changed the permissions of that folder)

Because it never have to use the AppData folder, this software is created to be independent(aka only use the folder it is run) but you changed this behaviour.

Updated Java, added all the URLs again, and the issue is gone. Strange that the latest update to ripme refused to read older history.json entries. Anyway.


How many ASVs describe a species and does the number plateau with the number of genomes?

We have previously seen that the number of ASVs per copy of the 16S rRNA gene is about 0.6. This means that if a genome has 10 copies of the 16S rRNA gene, we expect to see 6 different versions of the gene within that genome. Across genomes from the same species, we know that the number of copies of the gene is pretty consistent. So, if we look at multiple genomes from the same species, will we see the same versions of the gene or will we see new versions of the gene? To answer this, we would like to look at the relationship between the number of ASVs found in a species per number of genomes in the species versus the number of genomes. Besides looking at the full-length sequences, let's also look at the V4, V34, and V45 regions.

It would be great to have a table that indicates the number of ASVs for each region for each species along with the number of genomes for that species and its average number of rrn copies in our dataset.


New version: Redisant.RedisAssistant version <IP_ADDRESS>

Created by 🥟 Dumplings in workflow run #5064.
Logs
Updated: <IP_ADDRESS> → <IP_ADDRESS>
Submitting WinGet manifests

Microsoft Reviewers: Open in CodeFlow

Automatic Validation ended with:
(Automated response - build 880.)


Homebrew + Versioning

Please version your builds to make it easier to manage with Homebrew Cask.

Any chances that you can do this @Lorenzo45? I would like to install AutoMute via brew cask.

I haven't looked into this yet but it looks like it would be really convenient! I'm really busy with school right now so I likely won't be able to get around to this any time soon unfortunately.

It would be enough to just create a release in GitHub on the latest master commit (in this case v1.1).

@bahlo Done, can't believe I didn't know about this feature before! Thanks!

See https://github.com/caskroom/homebrew-cask/pull/20221. :ok_hand:


Allow OIDC tokens for API request

Feature request
I would like to use OIDC tokens to manage some aspects of my machine. This includes adding tags to a machine.
When using an ID token, there would already be basic code to identify the user, which could be a bit expanded to be used by the api.
This could increase security for external managment UIs, as the Interface would no longer need to use an "administrative" token. Current Interfaces have to handle Access Control seperately again and have to protect their Headscale token.
When allowing OIDC ID-Tokens, the ui would only need to obtain such a token and then use is to e.g. query machines, which would only return the machines this user is allowed to see or edit.

I'd like to reopen this. I'm running headscale and not being able to integrate with my OIDC SSO is a pain: I have to manage headscale tokens out of band, which in practice means sshing to a machine and generating a token via the CLI.
Being able to rely on OIDC tokens would abstract all of this.


Download Annotated Data

Is there a way to download annotated data in Geti? Annotations can be a time-consuming process, and having the option to download them would be greatly beneficial.

Hi @nomanmazharr, yes you can indeed download your annotated data. Have a look at this notebook, which shows how to download a project from Geti. This will include all your annotations.


Add personal ID, VAT for zh_TW

Hi teams, thanks for the awesome faker features.
This PR includes.

VAT in zh_TW/Company
personalIdentityNumber in zh_TW/Person
Tests
Readme update

Thanks!


haskell: add comment to default-package-overrides in configuration-hackage2nix.yaml

Motivation for this change
This PR adds a comment explaining the default-package-overrides section in configuration-hackge2nix.yaml.
Occasionally we get PRs trying to add packages to this list that don't come from the Stackage LTS releases, so I think it is nice to have some documentation saying not to do this.
Ping @peti.
Things done

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

[ ] NixOS
[ ] macOS
[ ] other Linux distributions

[ ] Tested via one or more NixOS test(s) if existing and applicable for the change (look inside nixos/tests)
[ ] Tested compilation of all pkgs that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review wip"
[ ] Tested execution of all binary files (usually in ./result/bin/)
[ ] Determined the impact on package closure size (by running nix path-info -S before and after)
[ ] Ensured that relevant documentation is up to date
[ ] Fits CONTRIBUTING.md.

Notify maintainers
cc @

@peti Thanks for cleaning this up and merging it in.
I saw your additional commit to haskell-updates https://github.com/NixOS/nixpkgs/pull/76982/commits/3ab6627c92a45e273041a8e56d21c41ac4c55504, and your message about this here: https://github.com/NixOS/nixpkgs/pull/76883#issuecomment-570907334.
I'm wondering if you had any policies in mind for when we allow things to be added default-package-overrides?
For instance, https://github.com/NixOS/nixpkgs/pull/76883 is a problem because it appears that a newer version of gi-gdkx11 causes taffybar to fail to build.  I think taffybar is used by a non-trivial number of users, so ideally we should try to keep it working.  (The same way we try to keep things like cabal-install, stack, xmonad, etc working.)
https://github.com/NixOS/nixpkgs/pull/76883 could be solved by adding gi-gdkx11 to default-package-overrides.  Or, it could be solved by adding gi-gdkx11 to extra-packages, and overriding all the derivations that need it (like taffybar).
Do you have a preference for how to handle these types of problems?

ping @peti. I'd like to come up with a loose set policies for when we allow/disallow things to be added to default-package-overrides.
Although for now I'd be completely happy with that policy being "take it on a case-by-case basis".

I believe that we'll have to judge it case by case. Personally, I would add overrides to default-package-overrides if the change fixes many packages and breaks only few. :-)


use DNS records instead of Service Worker for mops.one

https://internetcomputer.org/docs/current/developer-docs/production/custom-domain/dns-setup

fixed in https://github.com/ZenVoich/mops/commit/e3a2359fdc1bbcefd3b02dd76ed39c70fe1c982c


Getting 'Uncaught SyntaxError: Unexpected token <' with Meteor + React

I've tried both the npm module and the Meteor package, and no matter where I place the <script src="holder.js" defer></script> call (end of , inside the , I'm not sure how to load a script from within a react component however) , the issue never goes away.
Also, besides the above error, the placeholder images never display. I am using this html code inside one of my components <img id="testy" src="holder.js/300x200?theme=sky"/>
Do you have any idea what this could be?

React is tricky - you have to call Holder.run when the component mounts. i'll look into adding a React example

Welcome to Gboard clipboard, any text you copy will be saved here.


Chapter 4：seems missing self. before TRUNCATE

for req1 in range(0, self.TRUNCATE):
for req2 in range(0, self.TRUNCATE):
in this kind of situations, seems missing "self." before "TRUNCATE", so it will cause errors like TRUNCATE not defined.

Fixed. Thanks!


Check versions of buildbox

See original issue on GitLab
In GitLab by [Gitlab user @traveltissues] on Nov 1, 2019, 12:18
A number of issues have been reported with buildstream which were resolved by changing buildbox versions. This is not clearly suggested/indicated to the user. If possible buildstream should attempt to check the versions of buildbox that will be used before doing any work.

In GitLab by [Gitlab user @tpollard] on Nov 13, 2019, 16:06
marked this issue as related to #1201

In GitLab by [Gitlab user @traveltissues] on Nov 20, 2019, 14:18
mentioned in merge request !1638

I've seen errors multiple times caused by not having a new enough buildbox, lets up the priority here and make this a blocker for a stable 2.0

This should be super simple to fix, but it looks like buildbox-casd --version is broken somehow, filed this upstream.

Reopening this as #1671 only checks the version of buildbox-casd but not buildbox-run (or buildbox-common or buildbox-fuse, all of whos versions might have some impact).
The issue is however much less severe considering that most required updates we've encountered needed updates of buildbox-casd, and also considering that the buildbox binaries are generally updated in lockstep.
Note also that a version check of buildbox-run is complicated because it might be implemented with different implementations (buildbox-run-bubblewrap or buildbox-run-userchroot) which themselves may have different tags and versions.

We already make use of buildbox-run --capabilities, although so far only for optional aspects. If necessary, we could even list a critical bugfix as a 'capability'.
A version check for buildbox-fuse may make sense in buildbox-casd's FuseStager. We'll have to make sure that it's fatal, though (not falling back to hardlinks), and BuildStream can inform the user in a reasonable way. I don't remember whether we already have logic for the latter in place.

We already make use of buildbox-run --capabilities, although so far only for optional aspects. If necessary, we could even list a critical bugfix as a 'capability'.

This of course starts to look messy when checking buildbox-run-userchroot for a bugfix capability related to a bug fixed in buildbox-run-bubblewrap.
I was leaning more towards thinking that an overall "buildbox" version number could be implemented if the buildbox build and distribution process could be more streamlined (which is mostly only tricky due to the way it is maintained in multiple separate repositories).

We already make use of buildbox-run --capabilities, although so far only for optional aspects. If necessary, we could even list a critical bugfix as a 'capability'.

This of course starts to look messy when checking buildbox-run-userchroot for a bugfix capability related to a bug fixed in buildbox-run-bubblewrap.
I was leaning more towards thinking that an overall "buildbox" version number could be implemented if the buildbox build and distribution process could be more streamlined (which is mostly only tricky due to the way it is maintained in multiple separate repositories).

This depends on some improvements being made on buildbox distribution story. See https://gitlab.com/BuildGrid/buildbox/buildbox-integration/-/issues/1


No Change Body Cosmetic script

Hopefully, they will make one, but you will have to read the documentation for now.


Exception when trying to back up tables with more than 2GB

Hello.
I have a database running since 2008, some tables are very large, between 2 to 4.5 GB and the total database has 19GB, is currently in a Server Linux Centos 8 32GB RAM, the MySQL versions have been evolving and being migrated with Over the years, starting in version 5.1 and currently in version 8.
Using the library, when backing up the database, when it starts backing up the larger tables occurs Timeout errors, it is not always in the same table. I've increased the timeout and yet persists in these mistakes.
Does anyone have any tips, not to happen this kind of exception when performing the backup using the library?
Note: Backup via command line, it works perfectly.
Example of the command used via command line:
mysqldump -u USET -pPASS DATABASE - -adddrop -database - -adddrop -table -x -a -e -k -r -b> directory\backup_database_yyymddhmmm.sql

Have you tried the connection string option of ConnectionTimeout
Server=yourserver;Database=yourdatabase;User ID=youruserid;Password=yourpassword;ConnectionTimeout=60;

Where did you execute mysqldump and mysqlbackup.net?
Were they run on the same machine as the MySQL server?

Backup or executed with MySQLBackup.net, I already set up the Timeout on the connection string, and using MySQLBackup.net happens the exception (error when backing on tables with over 2GB)
Scenario:
MySQL server is a centos 8 with 32GB RAM
Backup application is on a Windows 2019 server, developed in .net Windows Forms

The Connection Timeout I already define at 60, 6000, 60000, 600000
My application is performed in backgroud, but always generates the same error.
Now I tested with the test solution that is in Github, and also the same error.

I see, can you try again with MySqlConnector instead:
https://www.nuget.org/packages/MySqlBackup.NET.MySqlConnector/
you can write a simple small app just for this testing

If you using the demo test app from github, you may use the function of "Progress Report - Export":
This function is run by using Background Worker, which runs MySqlBackup.net in a separate thread.

Using the 2 (mysql.data or mysqlconnector) connectors, it fires the same exception.
I will perform other tests, because with mysqlconnector the exception occurred in the last table that contains a lot of data, in this case I think increasing the timeout can resolve
Thank you for your help.


Add details + summary core component tags

Great HTML5 tag to add pseudo-dynamic behavior.
Should be easy to implement looking at existing components and following the specifications here: https://www.w3schools.com/tags/tag_details.asp

I'll take this one :D

Solved via #76


Tried to upgrade Tasmota after the convert now it's not working at all

Hello all.
Thank you for this awesome tool.
I have a tuya smart socket with power consumption sensors (Smart Life EU Plug WiFi Control smart Socket Power Metering Timing switch 16A 3680W Voice Control work with Alexa Google IFTT). I managed to flash it to tasmota with tuya-convert. Everything worked fine this far. I tried to upgrade for the latest firmware using tasmota menus firmware upgrade. However, it seemd to do something but nothing happened. I awaited for about ten minutes and (perhaps made an error) took the socket off from the mains and maybe the OTA upgrade was still going on.
Anyway, now as I plug it back on mains, nothing is happening. I tried to put it back to fast flashing state (5 second pressing the button) but nothing happened. I also tried to press it for over 40 seconds and also 1, 2, 3, 4, 5, 6, 7 quick pushes but nothing is happening. Is this socket a brick now, or is there a way to make it work again?
Thanks in advance.

Try https://tasmota.github.io/docs/#/help/Device-Recovery?id=fast-power-cycle-device-recovery

I tried to put it back to fast flashing state (5 second pressing the button) but nothing happened

That is a feature of the stock firmware, so it wouldn't work once you have Tasmota installed.
Thanks @meingraham for your input, hopefully it's helpful for @kpmkpm
Closing as not a tuya-convert question or issue.


Cannot remove storage pool with images

I found situation when i cannot remove additional storage pool when some image exists on it.
In general it is ok, but i cannot delete it from this specified storage only, to delete i need to remove it from all storage pools.
Steps:

create container on "default" storage pool

lxc init ubuntu:16.04 test1

create new storage pool and container on it

vgcreate NEW /dev/nvme0n1p1
lxc storage create NEW lvm source=NEW
lxc init ubuntu:16.04 test2 -s NEW

delete test2 container

lxc delete test2

At this moment i have only one volume on new storage pool:

lxc storage volume list NEW
+-------+------------------------------------------------------------------+-------------+---------+
| TYPE  |                               NAME                               | DESCRIPTION | USED BY |
+-------+------------------------------------------------------------------+-------------+---------+
| image | 7a7ff654cbd8f5f09bec03aa19d8d7d92649127d18659036a963b1ea63f90d25 |             | 0       |
+-------+------------------------------------------------------------------+-------------+---------+

To remove NEW storage pool i need to delete image with standard image delete command, when i trying to delete it by storage api i got:

error: storage volumes of type "image" cannot be deleted with the storage api

Please add possibility to delete storage pool in such situation, or allow to delete image only from one specified storage pool.

Distribution: Ubuntu
Distribution version: 16.04
The output of "lxc info" or if that fails:

Kernel version: 4.4.0-83-generic
LXC version: 2.0.8
LXD version: 2.15
Storage backend in use:  lvm

@brauner can you take this one.
The problem is when you have multiple storage pools, have the same image on more than one of them, then empty one of the pools of its containers but you can't remove the image without also removing it from all other pools.

I think I'd rather allow to do lxc storage volume delete <pool-name> image/<hash then allow to wipe the pool in this case.


Error handling, frontend timer, feedback

resolves #36
resolves #32
resolves #21
Exchange peer information

Looks good.


Finish Branch Unification

[x] Sync master branch with indigo-devel
[x] Set master as the default branch
[x] Update readme
[x] Delete jade-devel (replace with tag)
[x] Migrate SwRI's internal projects to the master branch (or to Debian installations)
[x] Delete kinetic-devel (replace with tag)
[x] Delete indigo-devel (replace with tag)

MRs have been submitted in GitLab for the affected workspace files.

I've submitted PRs to release 0.3.0 of marti_common into indigo, jade, kinetic, and lunar:

ros/rosdistro#15312
ros/rosdistro#15313
ros/rosdistro#15315
ros/rosdistro#15316

PRs have been accepted, so I'll close this.


Locally running ./build.ps1 -Tests does not function as docs specify

Steps to reproduce
git clone https://github.com/PowerShell/PSScriptAnalyzer.git
cd PSScriptAnalyzer
./Build.ps1. -Test
Import-module ./build.psm1
Get-TestResults # Or Get-TestFailures

Expected behavior
This should, as per the documentation, load the results file and output it to the console.
Actual behavior
Throws these errors:
Resolve-Path : Cannot find path 'C:\Users\Coby\source\repos\PSScriptAnalyzer\TestResults.xml' because it does not
exist.
At C:\Users\Coby\source\repos\PSScriptAnalyzer\build.psm1:410 char:17
+     $logPath = (Resolve-Path $logfile).Path
+                 ~~~~~~~~~~~~~~~~~~~~~
    + CategoryInfo          : ObjectNotFound: (C:\Users\Coby\s...TestResults.xml:String) [Resolve-Path], ItemNotFoundE
   xception
    + FullyQualifiedErrorId : PathNotFound,Microsoft.PowerShell.Commands.ResolvePathCommand

Get-Content : Cannot bind argument to parameter 'Path' because it is null.
At C:\Users\Coby\source\repos\PSScriptAnalyzer\build.psm1:411 char:34
+     $results = [xml](Get-Content $logPath)
+                                  ~~~~~~~~
    + CategoryInfo          : InvalidData: (:) [Get-Content], ParameterBindingValidationException
    + FullyQualifiedErrorId : ParameterArgumentValidationErrorNullNotAllowed,Microsoft.PowerShell.Commands.GetContentC
   ommand

You cannot call a method on a null-valued expression.
At C:\Users\Coby\source\repos\PSScriptAnalyzer\build.psm1:412 char:5
+     $results.SelectNodes(".//test-case")
+     ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    + CategoryInfo          : InvalidOperation: (:) [], RuntimeException
    + FullyQualifiedErrorId : InvokeMethodOnNull

Environment data
Fails in all environments.

The root cause is pretty simple - the output path is defined here:
https://github.com/PowerShell/PSScriptAnalyzer/blob/33d927857f6e8493a77ec34c3ca4328eca8ee5d8/build.psm1#L380
But is not passed to Pester here:
https://github.com/PowerShell/PSScriptAnalyzer/blob/33d927857f6e8493a77ec34c3ca4328eca8ee5d8/build.psm1#L388
Looking at this, https://github.com/PowerShell/PSScriptAnalyzer/pull/1444 , it seems we've decided to target Pester 5.X . I'll make a PR updating this Pester invocation to include the output file in the 5.x style, and update the readme to specify a minimum Pester 5.x version


⚠ Bofrost.de has degraded performance

In 88e670c, Bofrost.de (https://www.bofrost.de) experienced degraded performance:

HTTP code: 200
Response time: 1442 ms

Resolved: Bofrost.de performance has improved in a16db5b after 8 minutes.


documentation - table of contents

Documentation becomes larger day by day with new operations. So there is a need to add table of contents.
example

Tested. No problem. I tried this script but it didn't worked for me.


Add woken_while_running as another argument to the scheduling function

Currently, it has been found that the return value of the Runnable::run() function cannot be directly used in the scheduling function. As a result, the scheduler cannot determine whether the task is self-yielding or has been woken up by some external source when it is scheduled to run on some queues.
This situation can occur when a scheduler wants to set up some lifo_slot to allow tasks to preempt the normal execution order, but it receives a scheduling request from a self-yielding task that woke itself up while running. In this case, the scheduler cannot let the task preempt and cause a "false-yielding" result or some sort. Therefore, it needs to know whether the task self-yielded or not. However, with the current implementation, the scheduler can only acquire this information AFTER it schedules the task. This means that it needs to schedule the task for a second time, pushing it to the run queue, which not only takes much more time but also sadly moves the possible last preempted task into the run queue as well.
My pull request is to give the information to the scheduling function and let the scheduler determine in the first place, which in fact is inspired by Tokio's implementation. All the present APIs remain unchanged, and three new kinds of functions, namely spawn2, spawn_local2, and spawn_unchecked2, are added. The names of these functions can be changed if there is a better idea. Also, the corresponding tests have yet to be added.
/// A new API.
pub fn spawn2<F, S>(future: F, schedule: S) -> (Runnable, Task<F::Output>)
where
    F: Future + Send + 'static,
    F::Output: Send + 'static,
    S: Fn(Runnable, bool) + Send + Sync + 'static,
{
    unsafe { spawn_unchecked2(future, schedule) }
}

/// A present API, redirected to the corresponding new one.
pub unsafe fn spawn_unchecked<'a, F, Fut, S>(
    self,
    future: F,
    schedule: S,
) -> (Runnable<M>, Task<Fut::Output, M>)
where
    F: FnOnce(&'a M) -> Fut,
    Fut: Future + 'a,
    S: Fn(Runnable<M>),
    M: 'a,
{
    self.spawn_unchecked2(future, move |task, _| schedule(task))
}

Seems a good idea. I will try it.

You're welcome. :) BTW, when would you release a new version?

I'll release once I land #44


nRF91 LTE Serial modem support

Add support for nRF91 LTE modem. Move parts of the N211 implementation into a generic machinery.
Some of the N211 features aren't available on nRF91 such as reboots, autoconfig and AT+NUESTATS so they just return an error.

Squash and merge for pretty commit history


[sirius] Add 1-st implementation of sirius scf check

Tested on UENV Sirius spack stack on A100.

Can I test this patch?

@teojgo @ekouts Can you  please have a look? Is it good enough for 1st implementation?

@teojgo I removed hohgant config, and also tag in the test.


Accent color for toggled button's background

Current style as shown below (snapshot from MetroSample). Toggled button has dark gray background. Gray (dark or light) always gives an impression of disabled.

Would it look better if using Accent color for toggled button's background? Something like below (snapshot from GitHub desktop app). Just personal preference.

Hi, as it seems, the PR only changes MetroCircleToggleButtonStyle, what about the default ToggleButton? It is still not showing AccentColor when toggled.

@100GPing100 How did you change the colors for avalondock?  I would like to do something similar so that it matches the MahApps theme.

@kjeremy I created styles for each of the components belonging to AvalonDock. AvalonDock has some styles already, you can base yourself on them.

@100GPing100 Can you share them in a gist?  I tried to figure it out but I find the styling REALLY complicated for AvalonDock.

@kjeremy Yes I sure can, I'll only be home either tonight or tomorrow though, so only then as I don't have those files here on my laptop.

@100GPing100 Great!  Please let me know when you have them up.

@100GPing100 any word?

I'm really sorry for the delay, I have been away from my desktop, for a long time now, and have had a lot of stuff going on lately. I will try my best to get it up tomorrow, but I can't promise anything, I still have to look for the files, filter out what's not needed and upload them. Once again, I am sorry for the delay.


New extension: Zip

Resolves #209
Goes well with #700, although that PR isn't required to be merged first (or the other way around)
A zip extension which has most zip things (at least, things that JSZip can do, so no encrypted archives or rar support or stuff like that). However, it can open (and probably output) .sb3 files!

You're spoiling us 😭

I'm just going to casually save this.

AUGHWFHUIHFQ I tried to make this and failed, like oml this is so awesome, been waiting for this for like forever i like this, it is must add, (tldr: very cool, must add)

do you consider this done?

does this mean that a web or desktop build of a game can load data from within itself an different times instead of having to load all data at once?

do you consider this done?

after the above 3 commits, yes

YES

YES

YES

YES

YES

YES

YES

Yes

if you want, your user folder can be just CST, or I will merge this tonight

YES