Getting couldn't find flag "api-prefix" error when running wasm example

When I run this command from the wasm-query-service example:
substreams-sink-kv inject --endpoint mainnet.eth.streamingfast.io:443 "badger3://badger_data.db" substreams.yaml --listen-addr=":9000"

I'm getting this error:
panic: flags: couldn't find flag "api-prefix"

goroutine 1 [running]:
main.mustGetString(0x7?, {0x1ec5e79, 0xa})
        github.com/streamingfast/substreams-sink-kv/cmd/substreams-sink-kv/utils.go:78 +0x9d
main.setupServer(0xc000a1f080?, 0xc00095fe40, 0xc000884460)
        github.com/streamingfast/substreams-sink-kv/cmd/substreams-sink-kv/serve.go:131 +0x1a5
main.injectRunE(0xc000005500, {0xc0000d0d20, 0x2, 0x0?})
        github.com/streamingfast/substreams-sink-kv/cmd/substreams-sink-kv/inject.go:93 +0xb36
github.com/streamingfast/cli.silenceUsageOnError.func1(0xc000005500, {0xc0000d0d20?, 0x2?, 0x5?})
        github.com/streamingfast/cli@v0.0.4-0.20230420210357-3bebdb9f2fbf/cli.go:421 +0x2b
github.com/spf13/cobra.(*Command).execute(0xc000005500, {0xc0000d0c80, 0x5, 0x5})
        github.com/spf13/cobra@v1.6.1/command.go:916 +0x862
github.com/spf13/cobra.(*Command).ExecuteC(0xc000004c00)
        github.com/spf13/cobra@v1.6.1/command.go:1044 +0x3bd
github.com/spf13/cobra.(*Command).Execute(...)
        github.com/spf13/cobra@v1.6.1/command.go:968
github.com/streamingfast/cli.Run({0x1ed46fd?, 0x5?}, {0x1ed3665?, 0x456385?}, {0xc00099ff10?, 0xc000098738?, 0x47afbb?})
        github.com/streamingfast/cli@v0.0.4-0.20230420210357-3bebdb9f2fbf/cli.go:292 +0x50
main.main()
        github.com/streamingfast/substreams-sink-kv/cmd/substreams-sink-kv/main.go:25 +0x145

Also, the command example is: substreams-sink-kv inject -e mainnet.eth.streamingfast.io:443 "badger3://$(pwd)/badger_data.db" substreams.yaml but the -e option is no longer working and was replaced by --endpoint
I'm using substreams-sink-kv version 2.0.0

You should be good with substreams-sink-kv inject mainnet.eth.streamingfast.io:443 "badger3://badger_data.db" substreams.yaml --listen-addr=":9000" now. I release 2.1.0 which contains this breaking change.
Let me know.

Thanks for the update 👍
However, when I run the command I get this error:
ERRO (sink-kv) unable to setup sinker: sink module is required in sink config

What's the sink config?

Ok I think it was an issue on my side (I wasn't using the right substream). However, when I try to run the command with the wasm example I get this error:
ERRO (sink-kv) Flag "api-prefix" does not exist

Can you give me the exact command and in which folder you are?

Also provide me with:

which substreams-sink-kv
substreams-sink-kv --version

Please also run those command in the same directory that is causing you some problem.

I'm using substreams-sink-kv version 2.1.1, it's located in my /usr/local/bin/ and the folder in which I'm running this command:
substreams-sink-kv inject mainnet.eth.streamingfast.io:443 "badger3://badger_data.db" substreams.yaml --listen-addr=":9000"

is this: substreams-sink-kv/examples/wasm-query-service, from the wasm example

Downloaded release 2.1.2 and tried it with the same command and in the same folder as above but I'm getting this error:
ERRO (sink-kv) unable to retrieve cursor: invalid cursor

Is there something missing to my command?

Yeah I noticed the same, clearing the database seems to do the trick. But this means there is something fishy and the cursor is invalid somehow.
I'll need to dig that deeper. Closing this one since the original issue is good now.

`rm -rf "./badger_data.db"


Swift 4.2 support

Hi,
I am getting error some swift 4.2 changes like UIControlState change to UIControll.state in swift 4.2.
Its working fine after changing swift 4 for compilation instead of 4.2.
Please update Git after compile your source code with Swift 4.2.
I am executing code with Xcode 10.1 through Pod install

Hi @Github-Prashant
Please check out 3.1.2 to build at swift 4.2


chore: production ready borsh(with schema) example

Thanks for working on this, but I don't want to increase the MSRV if it's only to support a new example. Also, I think the bincode example is simpler and similar enough to this one, that it is a better example for people to work from.

when you will update rust version for some reason, would it be possible to look at PR again?
as for bincode, it is only bincode_keys, not values (at least by name : ), also it does not shows shema usage (along with no fixed size). so borsh is example of how schema can be used to automate keys/values for redb.
thank you


⚠ ClamAV has degraded performance

In 9f73c28, ClamAV (https://spamassassin.apache.org/) experienced degraded performance:

HTTP code: 200
Response time: 191 ms

Resolved: ClamAV performance has improved in e27d806.


[Feature]: Adding paging in contributors page

🚀 Feature Request
📝 Feature Description
Currently all contributors are listed in one single list
But if the list increases it can decrease user experience
So I would like to add paging support such that some contributors are shown in one page and the remaining in next pages
🔧 How Will This Enhance the App?
It will increase the user experience of app

Hello
Do you have any specific issue that I can solve


Changing the summoning system to work like how the book seemed to say it worked

Is your feature request related to a problem? Please describe.
Not really as much of a problem, per se, but something that I expected the mechanics of the spirit summoning to be when I first read through the book. I expected that all Foliots and Djinns that were in the world would be subject to decay, and that the Books of Calling could be bound to a spirit in the world to give you control options over them as well as allowing them to return to the Otherworld to let their decay recover. I also expected that the circle used would determine the tier of spirit, while the items used would determine the role. This way, you would be able to summon spirits of any tier to serve you with a variety of functions. Perhaps the ones that are higher tier than Djinns are hostile when they first spawn in, resistant to the summoner's command, and require you to best them in a boss fight before they will serve you. But as a tradeoff, they give you items that you can only get from beating them when you win, they can do a lot more, and they are not subject to decay while working much faster. I don't know if any of this was what you plan for the mod already, but this was how I expected all of these mechanics to work when I read the parts of the book describing Spirits and Decay and saw that each tier of spirit had a different summoning circle.

While not all of that is what I had in mind, some of it hits the mark pretty well.
In the end I opted for the less consistent but somewhat simpler to implement mechanics, due to time constraints.
One day I might re-work the entire system to go more in that direction, but for now I will close this issue as it's not feasible.
That said, thank you very much for elaborating your view, I will give you a ping here if and when I make changes to the system!


fixed margins

@eric-lee-ltk There are some conflict in the file, could you commit a quick fix for it?


Update README.md

Solved:
If someone could point me to that, this library can most likely be improved..

You may need a translation service for PDF :)

Thanks!
Considering my knowledge level of Chinese (..) that will require some further investigation, but I'll try.

With the new update, this change is no longer (that) relevant, even though the documentation keeps on being a point of attention..


Feature/markdown code block syntax highlighting

Hello there!
Syntax Highlighting
This PR adds the Shiki syntax highlighter to fenced code blocks in MDX files.

This is really neat because all of the syntax processing is done at build time, so there's no need for any extra JS. :)
Syntax Theme Configuration
I have modified the gatsby-config.js to export a function that expects the users's site config as an argument. This enables user-land configuration of the Shiki syntax highlighting theme. I added notes to both the readme.md files on how to configure this in the plugin options.
A note on Prettier.
https://prettier.io/ is a pretty widespread tool in the JS community and I have it enabled by default in my text editor, so it auto-ran-rampant on some formatting.
I've added a .prettierrc which for the most part keeps the formatting the same if a Prettier user every contributes to this repo.
One caveat: I could not turn Prettier off from running inside the fenced code blocks. I don't know if that is a blocking issue - I'll have to do some serious burrowing to try and turn it off. Maybe it's OK?
Or I can remove the Prettier element altogether.
Thank you again for this awesome theme. I've been putting together a help center for my team all day, and people love it, and have been contributing documentation already!
Jon
(P.S - Fixes https://github.com/mlent/gatsby-theme-help-center/issues/4)

Looks great at a quick glance, I'll try it myself later today.
And yeah actually I forgot to add prettier, this code is extracted from a monorepo of mine that has prettier in the root directory so i forgot to add it. Thanks for adding this too.

(Tiny update on this @jonsherrard I've put it on my schedule for Thursday to merge and release. I want to also try if it's possible to customize the syntax highlighting to match the theme colors a bit more. Just wanted to make sure you're not left hanging as I'm working on multiple projects. Cheers!)

Hi @mlent!
Thank you for the update that's very courteous of you!
No rush on my side I'm maintaining a fork now as there's a couple of other features I've added (layout support for 2,4,6, categories, noIndex, sorting by date or priority, and some other layout nits).
Shiki does accept custom highlighting, but the gatsby plugin does not expose that API. Shiki is abstracted away "under" remark plugins, and MDX layer, and Gatsby itself. So I don't think it's possible to pass in your theme values, nor can I imagine how one would write a M-UI theme -> shiki theme piece of code.
There is styling on the code tag background(0,0,0, 0.8) or similar, that gets applied to the shiki themes and makes things look a bit off (every Shiki Theme has a deep black background regardless of the style tag shiki generate). I've removed it in my fork.
The trade-off boils down to this I believe:
A user can choose a "best fit" theme from the pre-existing shiki-options, colors won't match perfectly. Works "as is" in this PR (if the code background property is removed)
vs
A lot of custom code, and a knowledge of syntax highlighting in VSCode Themes, to generate a shiki theme on the fly; along with updates to the gatsby-remark-shiki plugin, and potential gatsby-mdx
All the best,
Jon

Hm that's a bummer that the gatsby plugin doesn't expose that. I wonder exactly what the purpose of using the plugin is vs. just using the library directly?
I will have to look into that next week then, thanks for your patience!

Just to give you an insight into how complex syntax highlighting themes can be:
https://github.com/octref/shiki/blob/master/packages/themes/data/material/Material-Theme-Default.json
No trying to put you off, but it is a big task! And a very complex one to configure in user land too. For example, which of my theme values apply to which of those myriad highlighting options etc.
I'd venture that most of the value of a syntax highlight is down to the ease of read/parse ability for a human, rather than it matching the site-theme directly. Good luck either way :)

Yeah! I know it's complex, at least based on some vim themes I've done light customization on. But it would at least be nice to find something that somewhat fits into the bright theme colors that come with it.
Thanks for the reference code! That's really helpful. Let's see, at least for my purposes, there is very little code in my Help Center, so it doesn't matter hugely what it looks like.


Posture Check Linux Service

Capabilities might include:

Is the service unit defined (loaded)?
Does the unit have a running MainPID?
Is the MainPID's EUID expected?
Does the MainPID have the expected kernel capabilities?
Is the MainPID running in the expected kernel namespace?
Does the base unit definition match a checksum?
Does the unit have any drop-in overrides?
Is the unit enabled for startup after a reboot?
Is the unit active (running)?
Does the unit have ExecMainStatus=0 (not failed)?
Is the current invocation ID's journal anomalous (exceeds byte threshold, [doesn't] contain string, unusual incidence of ERROR messages)
Are CPU, memory, and I/O accounting enabled for the unit?
Are resource usages anamolous (CPUUsageNSec, MemoryCurrent, IOReadBytes, IOWriteBytes)?


Make test less brittle prior to assert_eq failure message format change

PR required for rust-lang/rust#42541 to make assert_eq error message be multi-line. Before implementing this we need to make the current test less brittle.
Not 100% clear on if I need the final [...] or not.

Thanks for the pull request, and welcome! The Rust team is excited to review your changes, and you should hear from @alexcrichton (or someone else) soon.
If any changes to this PR are deemed necessary, please add them as extra commits. This ensures that the reviewer can see what has changed since they last reviewed the code. Due to the way GitHub handles out-of-date commits, this should also make it reasonably obvious what issues have or haven't been addressed. Large or tricky changes may require several passes of review and changes.
Please see the contribution instructions for more information.

Thanks for the pr! Looks like some tests are failing though?

@alexcrichton sorry for the wait, have just switched to a new computer and turned 40. Build looks greener.

@bors: r+

:pushpin: Commit 9569106 has been approved by alexcrichton

Thanks!

:hourglass: Testing commit 95691064b6f9a73287ad6b609f29945ab17a2e0a with merge ae4124859411cc7db36d2b07ea9fba7068a43b36...

:sunny: Test successful - status-appveyor, status-travis
Approved by: alexcrichton
Pushing ae4124859411cc7db36d2b07ea9fba7068a43b36 to master...

Going to reopen as test.rs is another example.


ionic-angular's info page on npmjs.com refers to the old ionic-framework package name

Short description of the problem:
Usually, the only Javascript file required by the user is ionic.js, as everything from Ionic can be imported from this file:
  import {App, Page} from 'ionic-framework/ionic';

https://www.npmjs.com/package/ionic-angular
vs:
https://github.com/driftyco/ionic/blob/2.0/CHANGELOG.md#new-npm-module
Ionic Version: 2.x

Thanks, yeah the next version should have the updated info. Sadly we can't update npm after it's published.


Update default Docker Hub registry name to fix Docker Desktop authentication

There seem to have been different changes around Docker Desktop, its used authentication mechanisms in conjunction with docker-credential-desktop and the Docker Hub registry.
This led to the problem, that Testcontainers would interact with docker-credential-desktop in a way, that would provide us with wrong credentials, depending on how the Docker Hub login was performed (although this is not completely understood yet).
This is an experimental fix, that tries to restore the previous behavior.
Fixes #5121

Docker CLI uses https://index.docker.io/v1/ in their docs as an example API response:
https://github.com/moby/moby/search?q=https%3A%2F%2Findex.docker.io%2Fv1%2F
Regarding their implementation, they likely don't have a hardcoded value anywhere (as I can see so far), but just use the value they query from another location or endpoint, but I have to continue following their implementation code, to connect all the dots there. We can likely replicate this and should become much more robust and portable in our implementation.

Superseeded by #5347?


esp32-wrover-b smartconfig unable to work. Here's the log (IDFGH-752)

Guru Meditation Error: Core  0 panic'ed (LoadProhibited). Exception was unhandled.
Core 0 register dump:
PC      : 0x4017cb73  PS      : 0x00060630  A0      : 0x800e5ec4  A1      : 0x3ffe16b0
A2      : 0x3ffe7ec4  A3      : 0x00000001  A4      : 0x3ffbde80  A5      : 0x3ffd2be0
A6      : 0x3ffd2bd8  A7      : 0x00000000  A8      : 0x00000000  A9      : 0x3ffe16a0
A10     : 0x3ffe7ec4  A11     : 0x3ffbfbaa  A12     : 0x00000006  A13     : 0x3ffe7eca
A14     : 0x0000ffff  A15     : 0x00000000  SAR     : 0x00000004  EXCCAUSE: 0x0000001c
EXCVADDR: 0x0000002c  LBEG    : 0x4000c2e0  LEND    : 0x4000c2f6  LCOUNT  : 0xffffffff
ELF file SHA256: ce9eac84d782201d2422585d9ef8723d8674e32462c3363b03f82355ee16a756
Backtrace: 0x4017cb73:0x3ffe16b0 0x400e5ec1:0x3ffe1700 0x400e61e6:0x3ffe1770 0x400e6248:0x3ffe17b0 0x400ea2cc:0x3ffe17e0 0x400ea3ee:0x3ffe1800 0x40092a00:0x3ffe1820 0x400958c9:0x3ffe1860
Rebooting...
ets Jun  8 2016 00:22:57
rst:0xc (SW_CPU_RESET),boot:0x13 (SPI_FAST_FLASH_BOOT)
configsip: 0, SPIWP:0xee
clk_drv:0x00,q_drv:0x00,d_drv:0x00,cs0_drv:0x00,hd_drv:0x00,wp_drv:0x00
mode:DIO, clock div:2
load:0x3fff0018,len:4
load:0x3fff001c,len:6456
load:0x40078000,len:11308
load:0x40080400,len:6732
entry 0x40080764
I (29) boot: ESP-IDF v3.3-beta2-53-g79ca95ddf-dirty 2nd stage bootloader
I (29) boot: compile time 11:52:23
I (30) boot: Enabling RNG early entropy source...
I (36) boot: SPI Speed      : 40MHz
I (40) boot: SPI Mode       : DIO
I (44) boot: SPI Flash Size : 4MB
I (48) boot: Partition Table:
I (51) boot: ## Label            Usage          Type ST Offset   Length
I (59) boot:  0 nvs              WiFi data        01 02 00009000 00006000
I (66) boot:  1 phy_init         RF data          01 01 0000f000 00001000
I (74) boot:  2 factory          factory app      00 00 00010000 00200000
I (81) boot:  3 storage          Unknown data     01 82 00210000 000f0000
I (89) boot: End of partition table
I (93) esp_image: segment 0: paddr=0x00010020 vaddr=0x3f400020 size=0x3a7dc (239580) map
I (186) esp_image: segment 1: paddr=0x0004a804 vaddr=0x3ffbdb60 size=0x032dc ( 13020) load
I (191) esp_image: segment 2: paddr=0x0004dae8 vaddr=0x40080000 size=0x00400 (  1024) load
I (193) esp_image: segment 3: paddr=0x0004def0 vaddr=0x40080400 size=0x02120 (  8480) load
I (205) esp_image: segment 4: paddr=0x00050018 vaddr=0x400d0018 size=0xedbb4 (973748) map
I (551) esp_image: segment 5: paddr=0x0013dbd4 vaddr=0x40082520 size=0x14c60 ( 85088) load
I (600) boot: Loaded app from partition at offset 0x10000
I (600) boot: Disabling RNG early entropy source...
I (601) cpu_start: Pro cpu up.
I (604) cpu_start: Application information:
I (609) cpu_start: Project name:     hello-world
I (614) cpu_start: App version:      v3.3-beta2-53-g79ca95ddf-dirty
I (621) cpu_start: Compile time:     Mar 15 2019 11:52:11
I (627) cpu_start: ELF file SHA256:  ce9eac84d782201d...
I (633) cpu_start: ESP-IDF:          v3.3-beta2-53-g79ca95ddf-dirty
I (640) cpu_start: Starting app cpu, entry point is 0x40081114
I (633) cpu_start: App cpu up.
I (651) heap_init: Initializing. RAM available for dynamic allocation:
I (658) heap_init: At 3FFAFF10 len 000000F0 (0 KiB): DRAM
I (664) heap_init: At 3FFB6388 len 00001C78 (7 KiB): DRAM
I (670) heap_init: At 3FFB9A20 len 00004108 (16 KiB): DRAM
I (676) heap_init: At 3FFBDB5C len 00000004 (0 KiB): DRAM
I (682) heap_init: At 3FFD3F50 len 0000C0B0 (48 KiB): DRAM
I (688) heap_init: At 3FFE0440 len 00003AE0 (14 KiB): D/IRAM
I (695) heap_init: At 3FFE4350 len 0001BCB0 (111 KiB): D/IRAM
I (701) heap_init: At 40097180 len 00008E80 (35 KiB): IRAM
I (707) cpu_start: Pro cpu start user code
I (54) cpu_start: Starting scheduler on PRO CPU.
I (0) cpu_start: Starting scheduler on APP CPU.
I (98) BTDM_INIT: BT controller compile version [4cccca0]
I (98) system_api: Base MAC address is not set, read default base MAC address from BLK0 of EFUSE
I (188) phy: phy_version: 4100, 6fa5e27, Jan 25 2019, 17:02:06, 0, 0
I (628) system_api: Base MAC address is not set, read default base MAC address from BLK0 of EFUSE
E (5628) task_wdt: Task watchdog got triggered. The following tasks did not reset the watchdog in time:
E (5628) task_wdt:  - IDLE0 (CPU 0)
E (5628) task_wdt: Tasks currently running:
E (5628) task_wdt: CPU 0: main
E (5628) task_wdt: CPU 1: IDLE1
I (5748) wifi: wifi driver task: 3ffdfe8c, prio:23, stack:3584, core=0
I (5748) wifi: wifi firmware version: 53ea8b1
I (5748) wifi: config NVS flash: enabled
I (5748) wifi: config nano formating: disabled
I (5758) system_api: Base MAC address is not set, read default base MAC address from BLK0 of EFUSE
I (5768) system_api: Base MAC address is not set, read default base MAC address from BLK0 of EFUSE
I (5788) wifi: Init dynamic tx buffer num: 32
I (5788) wifi: Init data frame dynamic rx buffer num: 32
I (5788) wifi: Init management frame dynamic rx buffer num: 32
I (5798) wifi: Init management short buffer num: 32
I (5798) wifi: Init static rx buffer size: 1600
I (5808) wifi: Init static rx buffer num: 10
I (5808) wifi: Init dynamic rx buffer num: 32
I (5818) wifi: mode : sta (30:ae:a4:c6:fe:74)
I (5898) smartconfig: SC version: V2.8.0

@kingofalpha Please provide the brand of the router and cellphone. Does the smartconfig example of IDF work?

@kingofalpha Thanks for reporting the issue. Would you please any updates of the issue? Has your issue been fixed? Thanks.

@kingofalpha Thanks for reporting the issue. Would you please any updates of the issue? Has your issue been fixed? Thanks.

@kingofalpha Thanks for reporting the issue. Will close this issue due to lack of more information. Feel free to reopen and please help provide more details. Thanks.


Remove import as a JS reserved word

Now that JS supports import('/foo.js') it shouldn't be marked as a
reserved word when used in blocks.
This is my first time changing a Vim syntax so apologies if this isn't the right fix - do let me know if you'd like me to make changes. This fixed the problem I was having locally where import was highlighted in red as if it were an error.

Hi, thanks for your PR. Your change can fix this issue however I don't expect it solve in this way. I will keep this reserved word and add extra def to over write it in expected context. Actually I have supported import() in another repo: https://github.com/othree/es.next.syntax.vim/blob/master/after/syntax/javascript.vim#L65-L69
This should move to here when it got official support but I forgot to do it. You can help me update the PR to do it.


Include more types in crystal tool hierarchy

Feature Request
crystal tool hierarchy is really useful for getting an overview of the classes/structs available. I currently have a refactor branch of the vscode extension that uses it to quickly allow autocomplete of classes/structs.

It would be useful if it included modules/enums/annotations in its output, something as simple as:
{
  "name": "MyModule",
  "kind": "module"
},
{
  "name": "MyModule::MyAnnotation",
  "kind": "annotation"
},
{
  "name": "MyModule::MyEnum",
  "kind": "enum",
  "values": [
    "MyModule::MyEnum::Value1",
    "MyModule::MyEnum::Value2",
    "MyModule::MyEnum::Value3"
  ]
}

Actually, I'm not sure how these would fit into this as modules/enums/etc don't inherit from a generic Object class. Maybe instead we could have a crystal tool namespace command that outputs information about every NamedType? Thoughts?

Yeah I suppose a separate tool might be better for this.

Put together what I'm looking for here, let me know if this idea is PR worthy: https://github.com/nobodywasishere/crystal/tree/nobody/namespaces-tool
Resisted the urge to add docs to the output haha. Honestly maybe the move is to just add a crystal tool dump_ast command that has params like --wants-doc/--no-cleanup/--top-level/etc, so other tooling can just accept that and use that, instead of needing bespoke cli tools for everything. Would go in-hand with #14705, as we'd need a way to serialize the AST to/from disk.

For this use case you don't need the full AST (compared to other tools which trace method calls, for example). It's just a very high-level view of the outline. So I don't think this is related to #14705.
Actually, you can pull out the information about (documented) namespaces from index.json from the doc generator.
Improvements to the data format would help improcing this, and of course decoupling the raw data from HTML generation (#6947 and https://forum.crystal-lang.org/t/the-weight-of-compiler-tools/6888).

This use-case no, but for general use-cases to be able to have tools not built with the compiler that can work with the AST is moreso what I meant.

Good point with the docs index.json though, I'll look into trying to use that.

Unfortunately the index.json only includes stuff in the ./src directory by default, whereas I'd want everything available in the entire namespace (./lib, stdlib, and c lib bindings).

That could be easily changed with a flag though.
Why did you close this? I think this it's worth pursuing a solution.

My thought was this issue, if it just became adding more output to the docs json generator, would be duplicates of #7904 and #6721, and should be handled in those issues.


Chef 12 changes to checksum

https://tickets.opscode.com/browse/CHEF-4647 changed the behavior of checksum for remotefile resources.  This is GREAT, but it is also a breaking change that needs to be documented in the release notes.  Furthermore, the documentation for the remote_file resource needs to be updated to reflect this change.

Yeah, looks like it somehow got missed out of the CHANGELOG, DOC_UPDATES, the release notes on the website, etc.


Follow gocui library method rename

Renamed *Gui.Execute() to *Gui.Update() in this commit

Thank you for your contribution!


Mapping for mailbox rule events

Email services provide the capability to configure email forwarding, inbox rules, and more.
Such configuration may include complex settings. For example:
If an incoming email includes a subject with word “invoice” and the sender is ‘*.amazon.com’ then move the email to the mailbox folder “amazon invoices”.
Example of such a rule on M365 platform:

We may use the Entity Management class, while the entity is the relevant mailbox.
However, we need an attribute or object to identify the email service provider as well as the rule that was created or modified.
One idea that we discussed in the mapping weekly meeting is creating a new Profile that represents mailbox settings.
cc: @zschmerber-atlassian @cmcginley-splunk

@mikeradka - we would be happy to have your input here

@eliraz-levi Sorry, meant to chime in here last Friday.
We don't have a GitLab issue tracking this (tracking it internally), but @mikeradka and I are indeed running into the same issue when trying to map Set-Mailbox.
The options we discussed included:

creating an Email profile (as you suggest)
adding a mailbox object to the Entity Management class

We were planning on making one of these changes in our external extension, and then possibly promoting it. I'm not sure which direction Mike was more inclined to though.


Observation bulk upload

observation Bulk Upload controller added
ESupdate thread created for bulk upload;
ESStub edited for bulk/extended_observation

above feature merged with newplatform hence closing pr


ExecutorManagerException: executor became inactive before setting up the flow

If an existing azkaban-executor is quickly terminated (so that it doesn't remove itself from the DB), and is then started again, it will find itself being already in the DB, and not touch the DB entry in executors table. This means that azkaban-web will continue dispatching executions to this executor. However, FlowRunnerManager's active field is not initialized based on the DB.
In https://github.com/azkaban/azkaban/pull/2133/files#diff-e86078574720dfac4b80b618a6ccafe9R397 FlowRunnerManager was changed to check for this.active == true, and if not, throw an ExecutorManagerException with the message executor became inactive before setting up the flow.
I think FlowRunnerManager.active should be initialized from the DB before AzkabanExecutorServer.start().
I know this is usually not a problem, because when you create new executor instances they start in inactive mode, and eventually the REST API is called to activate it, which also sets FlowRunnerManager.active = true.

As a side note, AzkabanSingleServer doesn't have this problem, because it does this:
https://github.com/azkaban/azkaban/blob/70ed1ea97373ab17d3215e93c6bedfac3d1fbbb9/azkaban-solo-server/src/main/java/azkaban/soloserver/AzkabanSingleServer.java#L127-L128

@burgerkingeater, please check this, as https://github.com/azkaban/azkaban/pull/2133 was your PR.

@burgerkingeater could you comment?
Otherwise, @djaiswal83 & co., do you have anything to say on this? I can also make a PR to propose a fix if you like.

ping @burgerkingeater @jamiesjc

@juhoautio thanks for reporting this issue. If an existing azkaban-executor is quickly terminated (so that it doesn't remove itself from the DB), and is then started again, it will find itself being already in the DB, each time executor starts, a new port is assigned, so why do you think this is the case?

each time executor starts, a new port is assigned, so why do you think this is the case?

Port can be a fixed one:
https://github.com/azkaban/azkaban/blob/e6b62f34609c7f50c64bb56b76327f4686ed13bd/az-core/src/main/java/azkaban/Constants.java#L190-L191
I'm not really familiar with the dynamic executor port feature.

@juhoautio got it, i think what you proposed makes sense. I'm happy to review your PR if any.

I think this is fixed since https://github.com/azkaban/azkaban/pull/2288. Only works if executor.port is configured with a static value though.

This issue is still happening with Tag 3.90.0
I never had this issue before. Is there any fix for this?

curl http://:/executor?action=activate fixes it. However I think this is a hack.

curl http://:/executor?action=activate fixes it. However I think this is a hack.


Adding Delete Group video

Added a link to a short video showing how to filter to a set of candidate objects that could be deleted via the Explore view.

Description
Added link to small loom video I recorded on how to use the Delete Group feature.  I welcome you downloading the video and storing it alongside the docs instead of linking out to Loom.
Motivation and Context
Gives users more of a walkthrough on how to use the feature.
Types of changes

[ ] 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)
[X] Documentation fix (typos, incorrect content, missing content, etc.)

Checklist

[ X] I have read the contributing document.
[ X] My change requires a change to the documentation.
[ X] I have updated the documentation accordingly.
[ ] I have added tests to cover my changes.
[ ] All new and existing tests passed.

The changes in this PR have been merged with PR https://github.com/saucelabs/sauce-docs/pull/1812. Thanks @jasoncdavis0!


Bump version to 2.0.5 for release

Description
Please include a summary of the change. Please also include relevant motivation and context. List any dependencies that are required for this change.
Also

Add any other relevant change made on this PR.

Notes

Describe your changes

Tests Added / Updated?

YES or NO. If not, why?

Screenshots

Current dependencies on/for this PR:

main

PR #76   👈

This comment was auto-generated by Graphite.


Explicit dependency of the https_listener_ports templates on the list https_listener_ports_and_certs

As mentioned in https://github.com/gruntwork-io/terraform-aws-couchbase/issues/52 , terraform
seems to have trouble updating the template files if the upstream list https_listener_ports_and_certs
(used to generate the templates) changes.
This change states the dependency explicitely and fixes the issue: each time the list changes, the
templates are regenerated as well as all downstream dependencies.

Thanks for the PR! Could you add a comment above that depends_on block with a short explanation and link to this PR so future maintainers know why it's there?

I updated the PR.

Thanks! I'll kick off tests now.

Test failed with error "project not found". Not sure it is related to my changes... If I were to add tests for this PR, where should that be?

Hm, looks like 3 of the tests are failing on terraform destroy:
TestIntegrationCouchbaseCommunitySingleClusterDnsTlsUbuntu18 2019-12-12T16:06:28Z command.go:158: module.load_balancer.aws_route53_record.load_balancer[0]: Refreshing state... [id=Z2AJ7S3R6G9UYJ_single-cluster-lnlqxn.gruntwork.in_A]
TestIntegrationCouchbaseCommunitySingleClusterDnsTlsUbuntu18 2019-12-12T16:06:29Z command.go:158:
TestIntegrationCouchbaseCommunitySingleClusterDnsTlsUbuntu18 2019-12-12T16:06:29Z command.go:158: Error: Error in function call
TestIntegrationCouchbaseCommunitySingleClusterDnsTlsUbuntu18 2019-12-12T16:06:29Z command.go:158:
TestIntegrationCouchbaseCommunitySingleClusterDnsTlsUbuntu18 2019-12-12T16:06:29Z command.go:158:   on ../../modules/load-balancer/outputs.tf line 36, in output "https_listener_arns":
TestIntegrationCouchbaseCommunitySingleClusterDnsTlsUbuntu18 2019-12-12T16:06:29Z command.go:158:   36:   value = zipmap(
TestIntegrationCouchbaseCommunitySingleClusterDnsTlsUbuntu18 2019-12-12T16:06:29Z command.go:158:   37:
TestIntegrationCouchbaseCommunitySingleClusterDnsTlsUbuntu18 2019-12-12T16:06:29Z command.go:158:   38:
TestIntegrationCouchbaseCommunitySingleClusterDnsTlsUbuntu18 2019-12-12T16:06:29Z command.go:158:   39:
TestIntegrationCouchbaseCommunitySingleClusterDnsTlsUbuntu18 2019-12-12T16:06:29Z command.go:158:     |----------------
TestIntegrationCouchbaseCommunitySingleClusterDnsTlsUbuntu18 2019-12-12T16:06:29Z command.go:158:     | aws_alb_listener.https is tuple with 2 elements
TestIntegrationCouchbaseCommunitySingleClusterDnsTlsUbuntu18 2019-12-12T16:06:29Z command.go:158:     | data.template_file.https_listener_ports is empty tuple
TestIntegrationCouchbaseCommunitySingleClusterDnsTlsUbuntu18 2019-12-12T16:06:29Z command.go:158:
TestIntegrationCouchbaseCommunitySingleClusterDnsTlsUbuntu18 2019-12-12T16:06:29Z command.go:158: Call to function "zipmap" failed: number of keys (0) does not match number of
TestIntegrationCouchbaseCommunitySingleClusterDnsTlsUbuntu18 2019-12-12T16:06:29Z command.go:158: values (2).
TestIntegrationCouchbaseCommunitySingleClusterDnsTlsUbuntu18 2019-12-12T16:06:29Z command.go:158:
TestIntegrationCouchbaseCommunitySingleClusterDnsTlsUbuntu18 2019-12-12T16:06:29Z command.go:158:
TestIntegrationCouchbaseCommunitySingleClusterDnsTlsUbuntu18 2019-12-12T16:06:29Z command.go:158: Error: Error in function call
TestIntegrationCouchbaseCommunitySingleClusterDnsTlsUbuntu18 2019-12-12T16:06:29Z command.go:158:
TestIntegrationCouchbaseCommunitySingleClusterDnsTlsUbuntu18 2019-12-12T16:06:29Z command.go:158:   on ../../modules/load-balancer/outputs.tf line 45, in output "all_listener_arns":
TestIntegrationCouchbaseCommunitySingleClusterDnsTlsUbuntu18 2019-12-12T16:06:29Z command.go:158:   45:     zipmap(
TestIntegrationCouchbaseCommunitySingleClusterDnsTlsUbuntu18 2019-12-12T16:06:29Z command.go:158:   46:
TestIntegrationCouchbaseCommunitySingleClusterDnsTlsUbuntu18 2019-12-12T16:06:29Z command.go:158:   47:
TestIntegrationCouchbaseCommunitySingleClusterDnsTlsUbuntu18 2019-12-12T16:06:29Z command.go:158:   48:
TestIntegrationCouchbaseCommunitySingleClusterDnsTlsUbuntu18 2019-12-12T16:06:29Z command.go:158:     |----------------
TestIntegrationCouchbaseCommunitySingleClusterDnsTlsUbuntu18 2019-12-12T16:06:29Z command.go:158:     | aws_alb_listener.https is tuple with 2 elements
TestIntegrationCouchbaseCommunitySingleClusterDnsTlsUbuntu18 2019-12-12T16:06:29Z command.go:158:     | data.template_file.https_listener_ports is empty tuple
TestIntegrationCouchbaseCommunitySingleClusterDnsTlsUbuntu18 2019-12-12T16:06:29Z command.go:158:
TestIntegrationCouchbaseCommunitySingleClusterDnsTlsUbuntu18 2019-12-12T16:06:29Z command.go:158: Call to function "zipmap" failed: number of keys (0) does not match number of
TestIntegrationCouchbaseCommunitySingleClusterDnsTlsUbuntu18 2019-12-12T16:06:29Z command.go:158: values (2).
TestIntegrationCouchbaseCommunitySingleClusterDnsTlsUbuntu18 2019-12-12T16:06:29Z command.go:158:
TestIntegrationCouchbaseCommunitySingleClusterDnsTlsUbuntu18 2019-12-12T16:06:29Z retry.go:80: Returning due to fatal error: FatalError{Underlying: exit status 1}

And it seems to be happening on the exact output you're modifying in this PR.
@raffienficiaud Could you try to deploy one of the examples and then run terraform destroy to see if you can repro this manually? And if so, we'll need to think about how to work around this.

Closing this PR as there has been no activity in a little over 3 years.


Documenting how to use enzyme with react 16. Fixes #131.

As there has been some confusion how to include enzyme in https://github.com/Microsoft/TypeScript-React-Starter/issues/131 , I updated the README at this place. Let me know if something needs to be changed.

@catchin I follow your pr to add react-test-renderer and enzyme-adapter-react-16 without use eject. npm test still fail.
The error message is the same as
These options in your package.json Jest configuration are not currently supported by Create React App:

  • setupTestFrameworkScriptFile

@ShawnXiao105 Can you share what steps you performed? I just created an app from scratch and it works. In this repo you see what steps I performed (as single commits) and what the code looks like: https://github.com/catchin/react-typescript-example-with-enzyme
Did you modify package.json to include a setupTestFrameworkScriptFile configuration? Because this is not necessary. Also, which version of react-scripts-ts do you use?

@catchin  It works now. The reason is that I add JTEST options in package.json. And I removed them and all thing is OK.

Thank you so much for the PR and thanks for your patience!

Thanks for merging!


bug solved :overlap of login and dark-light mode icon

Related Issue
#1120
Description
previously

after changes

Type of PR

[x] Bug fix
[ ] Feature enhancement
[ ] Documentation update
[ ] Other (specify): _______________

Checklist:

[x] I have performed a self-review of my code
[x] I have read and followed the Contribution Guidelines.
[x] I have tested the changes thoroughly before submitting this pull request.
[x] I have provided relevant issue numbers, screenshots, and videos after making the changes.
[ ] I have commented my code, particularly in hard-to-understand areas.

Additional context:
[Include any additional information or context that might be helpful for reviewers.]

Still the spacing is not correct between login and toggle option. Attach a video showing the navbar is responsive for all screen sizes. These changes should be done on all the pages.

Still the spacing is not correct between login and toggle option. Attach a video showing the navbar is responsive for all screen sizes. These changes should be done on all the pages.

Okay Ma'am


Add support to go to definition in the whole workspace

For now, veridian just supports to go to definition in the current file, but does not support to jump in the whole wordspace. https://github.com/imc-trading/svlangserver supports to go to definition/symbol in the whole workspace folder. So now I use veridian and svlangserver as my verilog/systemveilog LSP simultaneously. I hope veridian can support this feature.
Thanks!

Sorry for the late reply, by default it should index all source files recursively from the working directory. If the working directory isn't where your files are then you'll need to have a veridian.yml configured to tell veridian where to look for your sources.
Also, if svlangserver is working for you, why would you need to run veridian as well, they should both be doing the same thing?

For now, veridian just supports to go to instance for the across files case according to my experience. It doesn't support to go to definition of the port of the instantiated module, go to the parameter definition（whether using define or package method) and some other features for the across files case.
For me, I use veridian to lint, format, do dot completion, and use svlangserver to hover, go to definition(also not support for parameters in other files).
Here is a short video about some features of svlangserver.
https://github.com/vivekmalneedi/veridian/assets/54238106/46b47348-69c1-4096-88ce-515fc65b6606
By the way, there is no perfect, fully-functional, easy-to-use LSP for v/sv for neovim for a long time. And I think the development of verible is too slow. That's frustrating:(


typo fixed in multi-domain-doc-qna readme

There might be a typo or the url needs to be updated in the salesforce-watsonx-apic-connector section. The URL isn't or the code working for me. Sorry to piggyback off this PR but the issues section isn't appearing for me.


EU country check is valid before test time

Avoid duplicates

[x] Bug is not mentioned in the FAQ
[ ] Bug is specific for iOS only, for general issues / questions that apply to iOS and Android please raise them in the documentation repository
**Not sure, if only on iOS **
[x] Bug is not already reported in another issue

Technical details

Device name: iPhone
iOS version:14.7.1
App version: 2.8.1

Describe the bug
When I checked a valid EU test certificate against country rules before the test time it is shown as valid.

Steps to reproduce the issue

Generate a valid EU test certificate
Check against country rules to a date in the past
It is shown as valid

Expected behaviour

The certificate should be invalid due to test time before certificate check time
Possible Fix
If test time before certificate check time then show error

Additional context

This can only be fixed by the member countries that uploaded their business rules to an interoperability gateway, frome where CWA downloads the rules to check them in the app.
In case of Spain, it could be @carballAcc who could take care of it, but to my best knowledge, all or nearly all member countries (including Germany?) are affected by this. AFAIR, when debugging business rules with a self-created test cert with sample collection date-time in the future, it was valid everywhere. Maybe something that could be brought up in the next IOP subgroup meeting, @thomasaugsten ?
On the other hand, a business rule check should not be possible for the past. It's not possible in CWA Android, and should probably be aligned for iOS.

@vaubaehn
Yes, I guess the real issue here is that you can choose a date in the past. This should be fixed (make it impossible to select a date in the past).

@Ein-Tim
But for all other wallet apps existing in the wild in all countries, it would also be good to take care of the business rules themselves :)

This issue is nearly 9 months old and
a) it was not mirrored to JIRA
b) there was no feedback at all from any of the maintainers
If this is out of scope for the CWA, please close it. If not, please mirror it to JIRA or let us know that someone is aware of this issue.
cc @thomasaugsten

@arnebr Maybe it makes sense to close this issue in favour of https://github.com/corona-warn-app/cwa-app-ios/issues/3839?

When a maintainer decides they will close the issue. But it seems this ticket older then the other  to have a better timeline of the issue occurence, this should be the reference.

@arnebr Agreed. It would be great if @thomasaugsten could confirm what @vaubaehn shared with us above.

With version 2.23.1 it's not possible to check certificates against a time in the past. This issue is therefore also fixed.
Please close this issue @arnebr.
@dsarkar Would you like to apply the Fix 2.23 label here?

@arnebr Thanks for reporting. @Ein-Tim Thanks for the ping here.
Best wishes, DS

Corona-Warn-App Open Source Team


Camera roll

Do you know how the game/engine rolls the camera? Does the vertical line drawing function draw the line at an angle instead? Or does it render to a buffer and then rotate that? Or does it skew the image for a rough approximation of roll at low angles, like how this demo fakes moving the camera up and down by panning the image?

You still want to draw vertical lines. Doing anything different would be a lot more expensive (not possible on a 386).
Also, drawing pixels one vertical column at the time would be the best approach for how VGA paging works.
Offsetting the tilt before the vertical line drawing would be a quick/dirty solution:
let tiltOffset = (input.leftright * (i /screenwidth - 0.5) + 0.5) * screendata.canvas.height / 4;

DrawVerticalLine(i, heightonscreen + tiltOffset, hiddeny[i] + tiltOffset, map.color[mapoffset]);


"Poiret One" triggers bug in check "METADATA.pb font.style normal matches font internals?"

This was reported by user Alexei Vanyashin on the<EMAIL_ADDRESS>mailing list today.

ERROR    Font macStyle indicates a non-Italic font but nameID 4 ("Poiret One") ends with "Italic"


osmnx.distance.nearest_edge would return the point of the foot of perpendicular

Hello,
osmnx.distance.nearest_edge would be hoped to return the point of the foot of perpendicular, or its fraction, in the nearest edge. Thank you.

Thanks for using OSMnx! Please re-read the contributing guidelines and the new issue template you saw when you opened this issue.
As the template noted, your issue will be automatically closed if you didn't provide all of the information requested in the template, because we need this information to address your issue.
Also note: please don't use the issue tracker to ask "how-to" or usage questions. If asked here, they will be closed automatically. Instead, ask "how-to" and usage questions on StackOverflow.


USHIFT-533: Remove role (controlplane/node) config.

Following earlier discussion (https://github.com/openshift/microshift/pull/1011#discussion_r991640607), let's wait to define the configuration surface until split role support arrives.

/assign @fzdarsky

/lgtm

/lgtm

/hold

/hold cancel
Looking at this again, after removing the config option the remaining wiring probably isn't awfully relevant.

/retest-required


[HOTFIX] Fix INSERT STAGE footer read error

Why is this PR needed?
There are 2 issues:

INSERT STAGE will skip bytes to read the last long in the carbondata file as the offset to the footer, but sometimes DFS is not skipping the right byte size
When error occurs, segment status is not in SUCCESS state, but recovery handling is not doing correctly in  INSERT STAGE command

What changes were proposed in this PR?

In CarbonFooterReaderV3.readFooterVersion3, if offset is not set by caller, read it from corresponding index file.
In CarbonInsertFromStageCommand, when recovery is required, delete the segment entry if the entry is not in SUCESS state.

Does this PR introduce any user interface change?
No
Is any new testcase added?
No

Build Success with Spark 2.3.4, Please check CI http://<IP_ADDRESS>:12545/job/ApacheCarbonPRBuilder2.3/1459/

Build Failed  with Spark 2.3.4, Please check CI http://<IP_ADDRESS>:12545/job/ApacheCarbonPRBuilder2.3/1461/

Build Failed  with Spark 2.3.4, Please check CI http://<IP_ADDRESS>:12545/job/ApacheCarbonPRBuilder2.3/1462/

Build Failed  with Spark 2.3.4, Please check CI http://<IP_ADDRESS>:12545/job/ApacheCarbonPRBuilder2.3/1470/

retest this please

Build Failed  with Spark 2.3.4, Please check CI http://<IP_ADDRESS>:12545/job/ApacheCarbonPRBuilder2.3/1471/

retest this please

Build Success with Spark 2.3.4, Please check CI http://<IP_ADDRESS>:12545/job/ApacheCarbonPRBuilder2.3/1479/

LGTM

Build Failed  with Spark 2.3.4, Please check CI http://<IP_ADDRESS>:12545/job/ApacheCarbonPRBuilder2.3/1526/

Build Failed  with Spark 2.3.4, Please check CI http://<IP_ADDRESS>:12545/job/ApacheCarbonPRBuilder2.3/1527/

Build Success with Spark 2.3.4, Please check CI http://<IP_ADDRESS>:12545/job/ApacheCarbonPRBuilder2.3/1530/

Build Success with Spark 2.3.4, Please check CI http://<IP_ADDRESS>:12545/job/ApacheCarbonPRBuilder2.3/1551/

Build Success with Spark 2.3.4, Please check CI http://<IP_ADDRESS>:12545/job/ApacheCarbonPRBuilder2.3/1571/

LGTM


treewide: move "unstable" from version to pname

Motivation for this change
Fix https://github.com/NixOS/nixpkgs/issues/68518
This PR mainly moves "unstable" from version to pname. That's how it should be according to the rules in https://nixos.org/manual/nixpkgs/unstable/#sec-package-naming
Also

fixed some version formatting
changed name to pname
fixed some style issues
in some cases it was needed to replace ${pname} with the actual string, so it does not contain "unstable"
in tmux-plugins, the pluginName was changed. i don't know what issues that could cause. can the plugins still be installed?
in one case (ppx_tools) the "unstable" part was lost. i don't see how it can be added to pname. would it better be part of version than not have it?

I have done everything with some shell magic and reviewed every single file and did some manual clean ups.
# Replace pname variable with actual string
for file in $(egrep -lR "version.+=.+unstable" pkgs/); do pname=$(grep -oP '\s*pname = "\K[\w-]+(?=")' $file) && sed -i -E "s/[$]\{pname\}|[$]pname/$pname/g" $file; done

# Add '-unstable' to any pname
for file in $(egrep -lR "version.+=.+unstable" pkgs/); do sed -i '/pname =/s/";$/-unstable&/' $file; done

# Remove '-unstable' from any version
for file in $(egrep -lR "version.+=.+unstable" pkgs/); do sed -i '/version/s/unstable-//' $file; done

Since the name attribute was not changed in most cases, this should not trigger a mass rebuild to my understanding.
Please review carefully as this could cause a lot of trouble. I'm still brave enough to try it.
Things done
i'm testing it right now and fixing issues

[ ] 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
[X] Fits CONTRIBUTING.md.

I'm not a big fan of including unsable in the pname. If I have "package a", it will still be a "package a" if I select a different release or commit. The package name should stay the same, but declare the difference through the version tag.

i agree that it would make sense that pname match the upstream name, but that is currently the official documented rule
i think this change was needed for repology. not sure if it is still needed @jtojnar

I'm not a big fan of including unsable in the pname. If I have "package a", it will still be a "package a" if I select a different release or commit. The package name should stay the same, but declare the difference through the version tag.

i agree that it would make sense that pname match the upstream name, but that is currently the official documented rule
i think this change was needed for repology. not sure if it is still needed @jtojnar

When a revision is used instead of a reference or explicit release, it not always means it corresponds to an unstable version. The unstable' addition to the name is to indicate the unstable variant, as @jonringer points out, to differentiate from the stable version. Sometimes, we need to fetch a revision because using patches is not workable. Changing the pname affects nix-env users.

When a revision is used instead of a reference or explicit release, it not always means it corresponds to an unstable version. The unstable' addition to the name is to indicate the unstable variant, as @jonringer points out, to differentiate from the stable version. Sometimes, we need to fetch a revision because using patches is not workable. Changing the pname affects nix-env users.

Changing the pname affects nix-env users.

nix-env users are already in a tough spot, even from something like many similar packages being available. For example:
nix-env -i python37
nix-env -u '*'

will get you python3.10 installed.

Changing the pname affects nix-env users.

nix-env users are already in a tough spot, even from something like many similar packages being available. For example:
nix-env -i python37
nix-env -u '*'

will get you python3.10 installed.

Changing the pname affects nix-env users.

so they don't get updates for installed packages, because the name does not exist anymore? that would be indeed very bad.
with the current rules, that would happen every time a package switches from stable to unstable release and the other way around
and i'm not sure if nix would update a package if the version changes from 0.5 to 2021-01-05
this one time i didn't question the existing rules, but it looks like i should :grimacing:
so, how can we get to a consistent state from here. nixpkgs is a mess

Changing the pname affects nix-env users.

so they don't get updates for installed packages, because the name does not exist anymore? that would be indeed very bad.
with the current rules, that would happen every time a package switches from stable to unstable release and the other way around
and i'm not sure if nix would update a package if the version changes from 0.5 to 2021-01-05
this one time i didn't question the existing rules, but it looks like i should :grimacing:
so, how can we get to a consistent state from here. nixpkgs is a mess

Until we have no consent how to do this I don't think we should change it. I am still for changing nix to fit this usecase.

Until we have no consent how to do this I don't think we should change it. I am still for changing nix to fit this usecase.

i think this change was needed for repology. not sure if it is still needed @jtojnar

Repology currently uses value nix-env parses from name. So the only way to make it work is to make -unstable suffix of version. See https://github.com/NixOS/nixpkgs/pull/100833

When a revision is used instead of a reference or explicit release, it not always means it corresponds to an unstable version. The unstable' addition to the name is to indicate the unstable variant, as @jonringer points out, to differentiate from the stable version. Sometimes, we need to fetch a revision because using patches is not workable. Changing the pname affects nix-env users.

nix-env only uses name so it does not matter for it whether unstable is a suffix of pname or prefix of version. The reason why we started moving unstable to version is to be able to get project name programmatically and because it makes more sense when we interpret pname as project name.

so they don't get updates for installed packages, because the name does not exist anymore? that would be indeed very bad.
with the current rules, that would happen every time a package switches from stable to unstable release and the other way around

Yes, that is correct.

and i'm not sure if nix would update a package if the version changes from 0.5 to 2021-01-05

If parseDrvName returns the same name component then it should. 2012-01-05 is lexicographically greater than 0.5, AFAICT. The other way around probably will not work, unless user explicitly specifies update policy flag https://github.com/NixOS/nixpkgs/pull/100833#issuecomment-711035515

this one time i didn't question the existing rules, but it looks like i should grimacing
so, how can we get to a consistent state from here. nixpkgs is a mess

We need policy change along the lines of https://github.com/NixOS/nixpkgs/pull/100833#issuecomment-711032331 and https://github.com/NixOS/nixpkgs/pull/100833#issuecomment-712411822. That works for both nix-env and repology (if unstable is part of pname there is another, stable package with pname matching the project name). Of course, that requires consensus, which requires patience.

i think this change was needed for repology. not sure if it is still needed @jtojnar

Repology currently uses value nix-env parses from name. So the only way to make it work is to make -unstable suffix of version. See https://github.com/NixOS/nixpkgs/pull/100833

When a revision is used instead of a reference or explicit release, it not always means it corresponds to an unstable version. The unstable' addition to the name is to indicate the unstable variant, as @jonringer points out, to differentiate from the stable version. Sometimes, we need to fetch a revision because using patches is not workable. Changing the pname affects nix-env users.

nix-env only uses name so it does not matter for it whether unstable is a suffix of pname or prefix of version. The reason why we started moving unstable to version is to be able to get project name programmatically and because it makes more sense when we interpret pname as project name.

so they don't get updates for installed packages, because the name does not exist anymore? that would be indeed very bad.
with the current rules, that would happen every time a package switches from stable to unstable release and the other way around

Yes, that is correct.

and i'm not sure if nix would update a package if the version changes from 0.5 to 2021-01-05

If parseDrvName returns the same name component then it should. 2012-01-05 is lexicographically greater than 0.5, AFAICT. The other way around probably will not work, unless user explicitly specifies update policy flag https://github.com/NixOS/nixpkgs/pull/100833#issuecomment-711035515

this one time i didn't question the existing rules, but it looks like i should grimacing
so, how can we get to a consistent state from here. nixpkgs is a mess

We need policy change along the lines of https://github.com/NixOS/nixpkgs/pull/100833#issuecomment-711032331 and https://github.com/NixOS/nixpkgs/pull/100833#issuecomment-712411822. That works for both nix-env and repology (if unstable is part of pname there is another, stable package with pname matching the project name). Of course, that requires consensus, which requires patience.

FYI: There are already 120 packages following this convention.
[davidak@gaming:~/code/nixpkgs]$ egrep -R "pname.+=.+unstable" pkgs/ | wc -l
120

After this change it's 479 (unstable packages).

If I had to make a rule for unstable releases, it would be <previous stable release>post-<version control system>.<short version control reference>
E.g.
version = "unstable-2020-01-09";
....
   rev = "77ca3aab2ae....";

would be
version = "0.1.0post-git.77ca3aab"
...
  rev = "77ca3aab2ae...";

unfortunate, builtins.parseDrvName deliminates on a number, so we can't just do <pkg>-git.789392
nix-repl> builtins.parseDrvName "name-1"
{ name = "name"; version = "1"; }

nix-repl> builtins.parseDrvName "pkgname-ab42"
{ name = "pkgname-ab42"; version = ""; }

nix-repl> builtins.parseDrvName "pkgname-git.3242"
{ name = "pkgname-git.3242"; version = ""; }

nix-repl> builtins.parseDrvName "pkgname-1git.3242"
{ name = "pkgname"; version = "1git.3242"; }

another option would be, to do the current  paradigm, but just drop unstable altogether
nix-repl> builtins.parseDrvName "pkgname-2020-01-22"
{ name = "pkgname"; version = "2020-01-22"; }

this is what vimPlugins does already, as vim plugins usually just track the latest default branch
nix-repl> vimPlugins.vim-css-color.name
"vimplugin-vim-css-color-2020-08-16"

nix-repl> vimPlugins.vim-css-color.pname
"vim-css-color"

nix-repl> vimPlugins.vim-css-color.version
"2020-08-16"

If I had to make a rule for unstable releases, it would be <previous stable release>post-<version control system>.<short version control reference>
E.g.
version = "unstable-2020-01-09";
....
   rev = "77ca3aab2ae....";

would be
version = "0.1.0post-git.77ca3aab"
...
  rev = "77ca3aab2ae...";

unfortunate, builtins.parseDrvName deliminates on a number, so we can't just do <pkg>-git.789392
nix-repl> builtins.parseDrvName "name-1"
{ name = "name"; version = "1"; }

nix-repl> builtins.parseDrvName "pkgname-ab42"
{ name = "pkgname-ab42"; version = ""; }

nix-repl> builtins.parseDrvName "pkgname-git.3242"
{ name = "pkgname-git.3242"; version = ""; }

nix-repl> builtins.parseDrvName "pkgname-1git.3242"
{ name = "pkgname"; version = "1git.3242"; }

another option would be, to do the current  paradigm, but just drop unstable altogether
nix-repl> builtins.parseDrvName "pkgname-2020-01-22"
{ name = "pkgname"; version = "2020-01-22"; }

this is what vimPlugins does already, as vim plugins usually just track the latest default branch
nix-repl> vimPlugins.vim-css-color.name
"vimplugin-vim-css-color-2020-08-16"

nix-repl> vimPlugins.vim-css-color.pname
"vim-css-color"

nix-repl> vimPlugins.vim-css-color.version
"2020-08-16"

I would not consider having parseDrvName results match pname and version necessary. Ideally, we would deprecate this function in favour of lib.getName and lib.getVersion.

I would not consider having parseDrvName results match pname and version necessary. Ideally, we would deprecate this function in favour of lib.getName and lib.getVersion.

What exactly is the problem we are trying to solve by including unstable? I see the point about repology, but there are ways around that.
How about this.
Last released version followed by a release date such as <IP_ADDRESS>00108
Pros:

no messing around with the pname
upgrades continue to work as expected for all cases
it's clear to a human reader that this is a snapshot
parseDrv and friends continue to work as normal

Cons:

Not easy to determine in a programmatic manner that this isn't a formally released version

For repology, we would then presumably show as being up to date as we are > latest official release. As soon as version 0.5.5 is released we are back to showing out of date as expected.

What exactly is the problem we are trying to solve by including unstable? I see the point about repology, but there are ways around that.
How about this.
Last released version followed by a release date such as <IP_ADDRESS>00108
Pros:

no messing around with the pname
upgrades continue to work as expected for all cases
it's clear to a human reader that this is a snapshot
parseDrv and friends continue to work as normal

Cons:

Not easy to determine in a programmatic manner that this isn't a formally released version

For repology, we would then presumably show as being up to date as we are > latest official release. As soon as version 0.5.5 is released we are back to showing out of date as expected.

In case a project hasn't made a formal release ever, we could still do 0.0.0.releasedate

In case a project hasn't made a formal release ever, we could still do 0.0.0.releasedate

It is not about appearing up to date on repology. Repology uses version data from distros as a proxy for project versions so if we used version that is greater than the latest stable version and cannot be filtered out, it would actually mark other distros as outdated. That could only lead to nixpkgs being blacklisted as a whole.
Also note that your proposed format is actually used by some projects for their official releases so we still would not be able to distinguish VCS snapshots from official releases. (first one I found by greping)

It is not about appearing up to date on repology. Repology uses version data from distros as a proxy for project versions so if we used version that is greater than the latest stable version and cannot be filtered out, it would actually mark other distros as outdated. That could only lead to nixpkgs being blacklisted as a whole.
Also note that your proposed format is actually used by some projects for their official releases so we still would not be able to distinguish VCS snapshots from official releases. (first one I found by greping)

I think we need a new variable which tells you that the version we use is unreleased and picked from master.

I think we need a new variable which tells you that the version we use is unreleased and picked from master.

I think that would be even harder to push through – we would still need to teach nix-env and Repology about it and I do not see that very likely given that unstable tag can already do that quite well.

I think that would be even harder to push through – we would still need to teach nix-env and Repology about it and I do not see that very likely given that unstable tag can already do that quite well.

I absolutely agree with @peterhoeg but propose following Debians model of extended version numbers and using a format along the lines of 0.5.4+nix.20200108 with 0.0.0+nix.20200108 being used for packages without upstream releases.
I think it would be very unfortunate if the notion of package name and version differs between Nix and Nixpkgs. It is already difficult enough to understand how things interact in the Nix ecosystem and moving away from
getName = s: (builtins.parseDrvName s).name
getVersion = s: (builtins.parseDrvName s).version

is simply confounding when the documentation for builtins.parseDrvName says

Split the string s into a package name and version.

propose following Debians model of extended version numbers and using a format along the lines of 0.5.4+nix.20200108 with 0.0.0+nix.20200108 being used for packages without upstream releases.

That would require manually reviewing hundreds of packages and researching if they have a release at all and after which version number we are currently.
I don't think that is feasible. We only have the date right now and we can shuffle that together with the package name and unstable or any other string how we want. Changing pname when fetching unstable versions is not an option because pname is used in thousands of places to refer to the package name. This leaves us with two options: unstable before or after the date in the version number. Either way needs a fix in the bulletin to funny function of I remember correctly.

Related: https://github.com/NixOS/nixpkgs/issues/68518

Repology uses version data from distros as a proxy for project versions so if we used version that is greater than the latest stable version and cannot be filtered out, it would actually mark other distros as outdated.

I believe a version is only considered valid if more than one distro has the same version. Otherwise it's first considered a "unique" version.
However, I think in principle we should still try to avoid polluting repology with bad information.

I believe a version is only considered valid if more than one distro has the same version. Otherwise it's first considered a "unique" version.

Not so much. higan is outdated in almost all distros (because they changed the build system radically), but the new version was taken from... Wikidata.

This pull request has been mentioned on NixOS Discourse. There might be relevant details there:
https://discourse.nixos.org/t/brainstorming-for-rfc-pname-and-version/12873/1

Closing due to huge conflicts.


Rejecting a promise with a custom error results in a PromiseKit: Unhandled Error: message

Hello,
I am rejecting a promise with the custom error below:
                            let error = Error.errorWithCode(Error.Code.InputStreamReadFailed, failureReason: "reason")                             reject(error)
I have also tried the following:
reject(NSError(domain: "somedomain", code: 123, userInfo: [:]))
In either case I receive the following message in the xCode console:
"...PromiseKit: Unhandled Error: Error Domain=com.alamofire.error Code=-6000 "reason" UserInfo={NSLocalizedFailureReason=reason}"
Is this something on my end or a bug?
Here is the complete function:
func getImageByID(imageID : String) -> Promise<UIImage> {
        return Promise { fulfill, reject in
            Alamofire.request(.GET, getImageURL(imageID)).responseData {response in
                if response.result.isSuccess {
                    if response.data != nil {
                        if let image = UIImage(data: response.data!) {
                            fulfill(image)
                        } else if UIImage(data: response.data!) == nil {

                            let error = Error.errorWithCode(Error.Code.InputStreamReadFailed, failureReason: "reason")
                            reject(error)
                            //reject(NSError(domain: "somedomain", code: 123, userInfo: [:]))
                            //reject(NSError(domain: "somedomain", code: 123, userInfo: nil))
                        } else {
                          .....
                        }
                    }
                } else {
                    reject(response.result.error!)
                }
            }
        }
    }

Any help is most appreciated!
Thanks!

Hi @BculeMB,
This type of question is best suited for Stack Overflow. We use the GitHub project for bug reports and feature requests.
Best of luck!

From our Contribution Guidelines
Asking Questions
We don't use GitHub as a support forum. For any usage questions that are not specific to the project itself, please ask on Stack Overflow instead. By doing so, you'll be more likely to quickly solve your problem, and you'll allow anyone else with the same question to find the answer. This also allows maintainers to focus on improving the project for others.


Allow mocking and typing

swr looks really cool 👍
I played around with something similar for request-registry recently.
What I miss in swr over request-registry is the ability to define typings, dependencies and to mock
I would love to know what you think about those features.
Define typings once per endpoint
In request registry you define endpoints e.g.:
import { createGetEndpoint } from "request-registry";

// Define a service endpoint to load user information
const userEndpoint = createGetEndpoint<{id: string}, {name: string, age: number}>({
    url: keys => `http://example.com/user/${keys.id}`
});

Then you can use them from a hook e.g.

import {useGetEndPointSuspendable} from 'request-registry-react';

const UserDetails = props => {
    const { name } = useGetEndPointSuspendable(userEndpoint, { id: props.id });
    return
{name}
;
};

It also works without suspense similar to the swr api:
const UserDetails = props => {
    const endpointState = useGetEndPoint(userEndpoint, { id: props.id });
    if (!endpointState.hasData) {
        return
Loading...
;
    }
    const { name } = endpointState.value;
    return
{name}
;
};

This allows autocomplete and type checking for endpointState.value without writing additional endpoint specific types inside the UserDetails component.
Dependencies
Endpoints can also cause mutations e.g.:
import { createPostEndpoint } from "request-registry";

// Define a mutation endpoint
const mutateUser = createPostEndpoint<{id: string}, {name: string}, {}>({
    url: keys => `http://example.com/user/${keys.id}`
    // Invalidate all userEndpoint endpoints (similar to your trigger broadcast)
    afterSuccess: () => userEndpoint.refresh()
});

// now for example inside an eventHandler
  <button onClick={async () => {
      const newName = data.name.toUpperCase()
      // update user 4 and rerender all components which rely on user 4 data:
      await mutateUser(newName)
    }}>

Mocking
For unit tests and storybook we sometimes want to tryout specific scenarios and want to mock backend responses.
// Define your mock data for getUserName
// Typescript will tell you if the mock data doesn't match the types for
// getUserName
const userJoeMock = createMockEndpoint(getUserName, async () => ({
    name: 'Joe',
}));

Now in any unit test or story you can activate the mock:
// Activate mock:
userJoeMock.activate();
// Deactivate mock:
userJoeMock.clear();

There are more utils around this but maybe this is enough to get the basic idea.
I would love to know what you think about those features. :)

I think you could create a custom hook using SWR internally and define the types there.
type User = {
  id: number,
  displayName: string
}

function useUser(id: number): { data: User } {
  return useSWR(`/api/users/${id}`, fetch);
}

function UserProfile({ id }: { id: number }) {
  const { data } = useUser(id);
  return
{data.displayName}

}

Something like this, and if you move this custom hook to another file you could mock it in your tests.

Maybe those custom hooks could even be automatically created along it's types with a script reading the type definitions of the API endpoints and the list of endpoints

Thanks @sergiodxa ! 👍 Yeah that's what we're currently doing on zeit.co. We created different SWR based hooks for different resources, so it won't be that difficult to switch / mock.

@quietshu @sergiodxa using a wrapping hook is a great idea 👍
Can you show me an example how such mocking could look like?

In just you could do:
import useUser from "path/to/hooks/api/use-user";

jest.mock("path/to/hooks/api/use-user");

useUser.mockImplementation(() => ({
  data: {
    displayName: "sergio", id: 1
  }
}));

Something like that will mock useUser module and let you mock the implementation to return fake data immediately, you could also run mockImplementation multiple times to change what it will return.

Would that also work for storybook (or similar tools) or only for jest?

I have never mocked anything in storybook, for other testing frameworks like Jest I suppose they have their own implementations of the same

Note that return/error types are introduced by my last PR, and i think were just released

@jantimon I know it's only a year after you asked this BUT I use MirageJS when I need to mock something in Storybook.
Thread on how to achieve this here: https://twitter.com/ryanlanciaux/status/1288897760473882625

@jantimon For storybook, we've updated our fetcher implementation to know when it's running in the context of storybook (there a variety of ways you could do this, one is to set an env var when starting storybook then look for it on process.env), and when that's the case, rather than run a real fetch, it returns whatever is in global.storybookData[key]. Then in our stories for components that use swr hooks, we set global.storybookData as appropriate for that story. We also implemented a hook that whenever the story being rendered switches, we call cache.clear to clear the swr cache so the new story doesn't return swr's cached data for the previous story.


rvvm: 0.5 -> 0.6

Description of changes
Updated RVVM to v0.6:
Changelog: https://github.com/LekKit/RVVM/releases/tag/v0.6
Important release notes (for packaging):

SDL2 support

Things done

Built on platform(s)

[x] x86_64-linux
[x] aarch64-linux
[ ] x86_64-darwin
[x] aarch64-darwin

For non-Linux: Is sandboxing enabled in nix.conf? (See Nix manual)

[ ] sandbox = relaxed
[x] sandbox = true

[ ] Tested, as applicable:

NixOS test(s) (look inside nixos/tests)
and/or package tests
or, for functions and "core" functionality, tests in lib/tests or pkgs/test
made sure NixOS tests are linked to the relevant packages

[x] Tested compilation of all packages that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review rev HEAD". Note: all changes have to be committed, also see nixpkgs-review usage
[x] Tested basic functionality of all binary files (usually in ./result/bin/)
24.05 Release Notes (or backporting 23.05 and 23.11 Release notes)

[ ] (Package updates) Added a release notes entry if the change is major or breaking
[ ] (Module updates) Added a release notes entry if the change is significant
[ ] (Module addition) Added a release notes entry if adding a new NixOS module

[x] Fits CONTRIBUTING.md.

Add a :+1: reaction to pull requests you find important.

@LekKit can you please review this?

Result of nixpkgs-review pr 296981 run on x86_64-linux 1

1 package built:

rvvm


[ImageList] Wrap image with a link

I want to add a link  tag around the images. However, when I resize the browser to greater than 1245px, the images separate.
Here's the sandbox:
https://codesandbox.io/s/thirsty-diffie-3e2fg?file=/src/App.js
Adding screen cap of the original

I'm using:
@material-ui/core": "^4.11.0"
react: "^16.13.1"

I bumped into the same issue quite recently. The way I solved it was to add an onClick to the GridListTile and redirect to the desired link that way.

While we have revamped the component in #22395, the limitation still stands. You need to apply the object-fit style and to grow the image to cover the whole space of the cell:
/* eslint-disable @typescript-eslint/no-use-before-define */
import * as React from 'react';
import { makeStyles } from '@material-ui/core/styles';
import ImageList from '@material-ui/core/ImageList';
import ImageListItem from '@material-ui/core/ImageListItem';

const useStyles = makeStyles({
  a: {
    display: 'block',
    height: '100%',
  },
  img: {
    objectFit: 'cover',
    width: '100%',
    height: '100%',
  },
});

export default function StandardImageList() {
  const classes = useStyles();

  return (
    <ImageList cols={3} rowHeight={164}>
      {itemData.map((item) => (
        <ImageListItem key={item.img}>
          <a className={classes.a} href="#">
            <img
              className={classes.img}
              srcSet={`${item.img}?w=164&h=164&fit=crop&auto=format 1x,
                          ${item.img}?w=164&h=164&fit=crop&auto=format&dpr=2 2x`}
              alt={item.title}
            />
          </a>
        </ImageListItem>
      ))}
    </ImageList>
  );
}

const itemData = [
  {
    img: 'https://images.unsplash.com/photo-1551963831-b3b1ca40c98e',
    title: 'Breakfast',
  },
  {
    img: 'https://images.unsplash.com/photo-1551782450-a2132b4ba21d',
    title: 'Burger',
  },
  {
    img: 'https://images.unsplash.com/photo-1522770179533-24471fcdba45',
    title: 'Camera',
  },
  {
    img: 'https://images.unsplash.com/photo-1444418776041-9c7e33cc5a9c',
    title: 'Coffee',
  },
  {
    img: 'https://images.unsplash.com/photo-1533827432537-70133748f5c8',
    title: 'Hats',
  },
  {
    img: 'https://images.unsplash.com/photo-1558642452-9d2a7deb7f62',
    title: 'Honey',
  },
  {
    img: 'https://images.unsplash.com/photo-1516802273409-68526ee1bdd6',
    title: 'Basketball',
  },
  {
    img: 'https://images.unsplash.com/photo-1518756131217-31eb79b20e8f',
    title: 'Fern',
  },
  {
    img: 'https://images.unsplash.com/photo-1597645587822-e99fa5d45d25',
    title: 'Mushrooms',
  },
  {
    img: 'https://images.unsplash.com/photo-1567306301408-9b74779a11af',
    title: 'Tomato basil',
  },
  {
    img: 'https://images.unsplash.com/photo-1471357674240-e1a485acb3e1',
    title: 'Sea star',
  },
  {
    img: 'https://images.unsplash.com/photo-1589118949245-7d38baf380d6',
    title: 'Bike',
  },
];

@mbrookes I can't think a significant room for improvement. What we about we close the issue with this propose workaround?

Thanks @alexmotoc your hack worked.
Thanks @oliviertassinari I'll give it a try now.

@oliviertassinari We could target any img descendent of ImageListItem, which would remove the need for React.cloneElement, but at the expense of ease of customisation.

@mbrookes the issue is that a developer also needs to change the size of the wrapping element of the image, it's required to have the correct placement. So I don't think that it's enough to solve this specific issue.
Now, maybe using a & > img selector instead of clone element would help for a different type of problem. It could make it easier when wrapping the img into another component without changing the DOM structure. We could keep a flat CSS specificity, so still easy to override.

My bad .MuiImageListItem-standard > img has a specificity of two. I think that it would still be better to ask the developers to rewrite the styles than have to fight with CSS specificity.  Considering the initial question was answered, I'm closing.


Feature Request for dark mode

İs there any road map for dark mode? Thx a lot.

Yes, there will be a dark mode for Fizzy. However, I might change to other static site generators rather than Ghost to rebuild the theme.

Any update on this? Great theme and definitely waiting for dark mode as we have Ghost 4.0 now and it has a quite promising future.

is static site Like a wordpress?

https://www.google.com/search?q=static+site+generators

Yes, there will be a dark mode for Fizzy. However, I might change to other static site generators rather than Ghost to rebuild the theme.

So is the fizzy jam the new successor? Cause I wouldn't mind contributing to the dark theme. Something like this perhaps ?

Yes, there will be a dark mode for Fizzy. However, I might change to other static site generators rather than Ghost to rebuild the theme.

So is the fizzy jam the new successor? Cause I wouldn't mind contributing to the dark theme. Something like this perhaps ?

Sorry for the late reply.
Haha! Yes, Fizzy Jam will be the successor of this project. However, I currently could only spend limited time on both projects.
The screenshot seems really promising and contributions like this would be much appreciated!


add project-level user & permission management

Add to:

API
UI
CLI

We need the ability to define Roles and RoleBindings and mappings of OIDC users to ServiceAccounts...
In thinking about how to make this a nice UX that is not complex, I think an abstraction could help, but I'd like some buy-in from @jessesuen on this...
Mapping OIDC users to SAs is already a binding of sorts. If a "Kargo role" were an abstraction over a 1:1:1 of SA:RoleBinding:Role it would only require users to define membership (based on OIDC claims) and permissions. Such an object would bind very cleanly to a UI form and eliminate the need to juggle many separate elements.
It would also make for a pleasant UX in the CLI. Examples:

kargo create role foo
kargo grant --email<EMAIL_ADDRESS>--role foo
kargo revoke --email<EMAIL_ADDRESS>--role foo
kargo grant --group 12345 --role foo
kargo revoke --group 12345 --role foo
kargo grant --verb read --type stage --role foo
kargo revoke --verb read --type stage --role foo
kargo grant --verb promote --type stage --resource prod
kargo revoke --verb promote --type stage --resource prod

All of this would reconcile as pure RBAC resources.

Is the proposal to introduce a CRD that is the abstraction over the 1:1:1 of SA:RoleBinding:Role? Or are you suggesting the API server provides the abstraction?
Given the two options, I hesitate to introduce a CRD to wrap existing objects. Instead, I propose presenting a unified concept at our API layer that makes RBAC easier to reason about and manage.

I had been thinking CRD, but the idea of doing it in the API server is another approach we could consider.
For me, the pro of doing it with the CRD was that even if not using the API server and doing everything with kubectl or with GitOps, the abstraction would still be available.
However we approach it, I'd like to be able to do something like this (doesn't need to be exactly this):
apiVersion: kargo.akuity.io/v1alpha1
kind: Role
metadata:
  name: prod-promoter
  namespace: kargo-demo
users:
  groups:
  - some-oidc-group-claim
  - some-other-oidc-group-claim
rules:
- apiGroups:
  - kargo.akuity.io/v1alpha1
  resources:
  - stages
  resourceNames:
  - prod
  verbs:
  - promote

If I'm slinging YAML, having the above reconcile as the following is a significant convenience:
apiVersion: v1
kind: ServiceAccount
metadata:
  name: prod-promoter
  namespace: kargo-demo
  labels:
    rbac.kargo.akuity.io/groups: some-oidc-group-claim,some-other-oidc-group-claim
---
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  name: prod-promoter
  namespace: kargo-demo
rules:
- apiGroups:
  - kargo.akuity.io/v1alpha1
  resources:
  - stages
  resourceNames:
  - prod
  verbs:
  - promote
---
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: prod-promoter
  namespace: akrgo-demo
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: Role
  name: prod-promoter
subjects:
- kind: ServiceAccount
  namespace: kargo-demo
  name: prod-promoter

And if I'm not slinging YAML directly, the proposed abstraction binds cleanly to a UI form, which negates the need for a much more complex UI for managing SAs, Roles, and RoleBindings as separate things.
Another option is that instead of being a new top-level CRD, this could be a new section of ProjectSpec.

The following commands seem to eliminate the ServiceAccount and RoleBinding concepts entirely for the sake of simplicity.
kargo create role foo
kargo grant --email<EMAIL_ADDRESS>--role foo
kargo revoke --email<EMAIL_ADDRESS>--role foo

I agree we can simplify this and make it more convenient for the user to manage the bindings by only having them to deal with with one abstraction, namely the role.
To achieve the desired use case without introducing a CRD, I think we should rely on a convention where foo was also the name of the Role, RoleBinding, ServiceAccount. The API layer could rely on this assumption for CRUD operations.
NOTE: this doesn't preclude users from using Role, ServiceAccounts, RoleBindings with inconsistent naming, but they won't be able to manage those from our API.

The following commands seem to eliminate the ServiceAccount and RoleBinding concepts entirely for the sake of simplicity.

Those commands were meant to be seen as imperatives that patch the abstract resource I proposed.

To achieve the desired use case without introducing a CRD, I think we should rely on a convention where foo was also the name of the Role, RoleBinding, ServiceAccount. The API layer could rely on this assumption for CRUD operations.

That would work, but I don't entirely love that the abstraction would then be totally unavailable to kargo/kubectl apply -f ... and GitOps practitioners.

The big reason I'd be against a CRD, despite it being reconciled as native kube resources under the covers, is because it's still a new DSL that will have to be explained, documented, learned, etc... It's also a controller (or webhook) that has to be running to create the corresponding resources (e.g. more to go wrong).
We will never abandon the ability to define Kargo RBAC with native kube objects, but introducing a new CRD means there would now be two ways to configure RBAC. I don't think making the CLI or UI convenient map to the spec is a good enough reason, or kubectl apply-ing 1 object vs. 3.

Another option is that instead of being a new top-level CRD, this could be a new section of ProjectSpec.

I would be opposed to this, since it would be moving us further away from familiarity of Kube RBAC.

We will never abandon the ability to define Kargo RBAC with native kube objects

100% agreed and, just to be clear, I definitely wasn't proposing that.

but introducing a new CRD means there would now be two ways to configure RBAC

Ya... I definitely did see that as being a downside, although it hadn't been enough to stop me from proposing this -- probably for selfish reasons. As someone who prefers slinging YAML to UIs, I would have liked to use the abstraction and figured many users who fit the same profile might as well... but since you're calling me out on the "now there's two ways to..." problem, I'll admit I may not have given that adequate weight.

It's also a controller (or webhook) that has to be running to create the corresponding resources (e.g. more to go wrong).

It would probably be both -- controller for reconciliation and webhook for validation. This definitely is more moving parts and more potential for something to go wrong. So I'm starting to come around to your POV...
Ironically, however, there might be more potential for something to go wrong if this is done purely within the API server. If the creation of a Kargo "role" involves the creation of a Kubernetes SA, Role, and RoleBinding and deletion of a "role" requires deletion of the same three k8s resources, a problem we run into is that there isn't (that I know of) any way to create, edit, or delete multiple resources in a transactional manner, meaning a create/delete "role" operation that fails halfway through leaves things in an inconsistent state that may be difficult to identify and/or recover from.
Using a controller to reconcile the abstraction means we avail ourselves to automatic backoff/retries and eventual consistency...
This is not to say that I'm still pushing super hard for that implementation. Rather, I'm just trying to get all considerations out on the table.

@jessesuen and I took this offline and decided the lack of transactionality was a legitimate concern, but we settled on an approach to mitigate that...
I had been proposing an abstraction where the underlying SA/Role/RoleBinding were all of relatively equal importance.
He has suggested elevating the relative importance of the k8s Role. When a "Kargo Role" is created, the k8s Role is created first and when a "Kargo Role" is deleted, the k8s Role is deleted last. In either case, if something goes wrong, the k8s Role exists and all that is missing are the bindings, which can easily be corrected.
I agree this is more than good enough and this is how we'll proceed.

A potential problem with an abstraction over a SA/Role/RoleBinding trio that @hiddeco and I have been exploring this morning is that other Roles and RoleBindings could be granting permissions to an SA "behind Kargo's back."
The complication that this presents is that if we show users "here's who has this role and here's what they can do with that" and we allow them to edit that with a UI form or a CLI command like kargo revoke ..., Kargo can manage what it knows about, but cannot manage what it doesn't know about.
To use a concrete example, imagine that you have a SA, Role, and RoleBinding trio where all three are named "x". An action like kargo revoke --role x --resource stage --resouce-name prod --verb promote can effectively mutate Role x to remove permission to promote to prod, but if a "rogue" RoleBinding granted SA x this permission via a different Role, the permission we desired to revoke has not been.
So... I believe this leaves us with a few options:

Abandon the notion of any kind of abstraction. This would mean exposing functionality for managing SAs, Roles, and RoleBindings much more directly. Especially from a UI perspective, I am not sure this is a particularly pleasant UX and I think it's a lot of work to build all the UI forms for managing SAs, Roles, and RoleBindings as separate things, and even more work to distill the effective permissions those represent into something comprehensive that can be shown in a UI tab.

Leverage this tool as a library to detect cases where RoleBindings (or ClusterRoleBindings, for that matter) outside of the Kargo managed SA, Role, RoleBinding trio exist and affect the SAs permissions. This would permit us to at least warn users that a "Kargo Role" (SA) has permissions that are not reflected in or managed by the UI and CLI.

@jessesuen I'd really like to chat about this when you've got a few minutes.

@jessesuen and I spoke offline and agreed on something like the second proposal above. Get, update, grant, and revoke operations will blindly work as if there is always (only) a SA/Role/RoleBinding trio backing every "Kargo Role" and we will create a separate endpoint that will assess whether the permissions of a given SA are additionally influenced by other RoleBindings or ClusterRoleBindings that exist outside of the conventional SA/Role/RoleBinding trio. This will give the UI and CLI some method of determining that users must be warned about the influence of those bindings.

The back end and cli bits of this are complete.

I'm closing this to open an issue more narrowly-scoped to just the outstanding UI improvements.

Opened #1920


Error with 1.0.1

I'm unsure what is happening and why it is happening, but these lines from the lib.rs

#[cfg(test)]
#[macro_use]
extern crate quickcheck;

#[cfg(test)]
extern crate serde_json;

are making an error with the text unresolved extern crate.
I don't know what is going on here.

I'm trying to dive deeper into this,.. And I believe there is something wrong with this:

#[cfg(feature = "serde")]
#[doc(hidden)]
#[macro_export]
macro_rules! __serialize_key {
    ( $name:ty ) => {
        impl $crate::__impl::Serialize for $name {
            fn serialize<S>(&self, serializer: S) -> Result<S::Ok, S::Error>
            where
                S: $crate::__impl::Serializer,
            {
                self.data().serialize(serializer)
            }
        }

        impl<'de> $crate::__impl::Deserialize<'de> for $name {
            fn deserialize<D>(deserializer: D) -> Result<Self, D::Error>
            where
                D: $crate::__impl::Deserializer<'de>,
            {
                let key_data: $crate::KeyData =
                    $crate::__impl::Deserialize::deserialize(deserializer)?;
                Ok(key_data.into())
            }
        }
    };
}

where it is saying that my new key type doesn't have a self.data for &MyKeyType.

I'm trying to dive deeper into this,.. And I believe there is something wrong with this:

#[cfg(feature = "serde")]
#[doc(hidden)]
#[macro_export]
macro_rules! __serialize_key {
    ( $name:ty ) => {
        impl $crate::__impl::Serialize for $name {
            fn serialize<S>(&self, serializer: S) -> Result<S::Ok, S::Error>
            where
                S: $crate::__impl::Serializer,
            {
                self.data().serialize(serializer)
            }
        }

        impl<'de> $crate::__impl::Deserialize<'de> for $name {
            fn deserialize<D>(deserializer: D) -> Result<Self, D::Error>
            where
                D: $crate::__impl::Deserializer<'de>,
            {
                let key_data: $crate::KeyData =
                    $crate::__impl::Deserialize::deserialize(deserializer)?;
                Ok(key_data.into())
            }
        }
    };
}

where it is saying that my new key type doesn't have a self.data for &MyKeyType.

Somehow the trait that is being implemented.. is not in scope simultanously. (maybe rust macros are too hygienic).
I suggest this is a fix:

#[cfg(feature = "serde")]
#[doc(hidden)]
#[macro_export]
macro_rules! __serialize_key {
    ( $name:ty ) => {
        impl $crate::__impl::Serialize for $name {
            fn serialize<S>(&self, serializer: S) -> Result<S::Ok, S::Error>
            where
                S: $crate::__impl::Serializer,
            {
                $crate::Key::data(self).serialize(serializer)
            }
        }
[omitted]

Somehow the trait that is being implemented.. is not in scope simultanously. (maybe rust macros are too hygienic).
I suggest this is a fix:

#[cfg(feature = "serde")]
#[doc(hidden)]
#[macro_export]
macro_rules! __serialize_key {
    ( $name:ty ) => {
        impl $crate::__impl::Serialize for $name {
            fn serialize<S>(&self, serializer: S) -> Result<S::Ok, S::Error>
            where
                S: $crate::__impl::Serializer,
            {
                $crate::Key::data(self).serialize(serializer)
            }
        }
[omitted]

Can you give me the exact Rust version and feature flags you're using to reproduce this?

Can you give me the exact Rust version and feature flags you're using to reproduce this?

Uh, I hope that's not the problem..
 rustc --version
rustc 1.51.0-nightly (61f5a0092 2021-01-04)

And I'm just using
slotmap = { path = "../slotmap", features = ["serde"] }

Uh, I hope that's not the problem..
 rustc --version
rustc 1.51.0-nightly (61f5a0092 2021-01-04)

And I'm just using
slotmap = { path = "../slotmap", features = ["serde"] }

I don't understand why this doesn't show up for me in cargo +nightly test --features serde - why did it slip through my testing?

I don't understand why this doesn't show up for me in cargo +nightly test --features serde - why did it slip through my testing?

I don't know what to tell you. I just ran this command on the current master-branch, and I got no errors as well.
However, I did make a whole new project, and I only had this in lib.rs:
use slotmap::new_key_type;
new_key_type! {
    struct FarmId;
}

and I got this error..
I don't know what to tell you..

I don't know what to tell you. I just ran this command on the current master-branch, and I got no errors as well.
However, I did make a whole new project, and I only had this in lib.rs:
use slotmap::new_key_type;
new_key_type! {
    struct FarmId;
}

and I got this error..
I don't know what to tell you..

I will investigate this in a bit.

I will investigate this in a bit.

I know why this slipped through my testing. I have use slotmap::* in all my tests, which makes sense and is always fine - with one exception: macros.
Macros get expanded in the scope of the caller, so in this case a trait use (Key) was missing, but not in my tests. Will fix now.

I know why this slipped through my testing. I have use slotmap::* in all my tests, which makes sense and is always fine - with one exception: macros.
Macros get expanded in the scope of the caller, so in this case a trait use (Key) was missing, but not in my tests. Will fix now.

@CGMossa I'm not accepting your pull request because I'm breaking it up into smaller changes, adding tests to prevent this in the future, etc. But this will be fixed in an upcoming patch (today or tomorrow most likely).
As a workaround for now you can add an explicit use slotmap::Key; to bring the Key trait into scope, which will allow the macro to work.

@CGMossa I'm not accepting your pull request because I'm breaking it up into smaller changes, adding tests to prevent this in the future, etc. But this will be fixed in an upcoming patch (today or tomorrow most likely).
As a workaround for now you can add an explicit use slotmap::Key; to bring the Key trait into scope, which will allow the macro to work.

That's totally okay.
I was just trying to help really.
You can close to issue now.

That's totally okay.
I was just trying to help really.
You can close to issue now.

This is not the same as the error that can be seen in my CI, is it?

This is not the same as the error that can be seen in my CI, is it?

@mightyiam No, that is because slotmap 1.0+ has a minimum required Rust version of 1.49, which you can see in the warning:

warning: slotmap requires rustc => 1.49.0

I should however add that to the documentation and readme, and I will in the next patch.

@mightyiam No, that is because slotmap 1.0+ has a minimum required Rust version of 1.49, which you can see in the warning:

warning: slotmap requires rustc => 1.49.0

I should however add that to the documentation and readme, and I will in the next patch.


Fix Windows build ZIP packaging

PR Summary
Fixes #16261
PR Context
Fix shell for calling PowerShellPackage.ps1 in CI for packaging step.

Already backported to 7.0:  https://github.com/PowerShell/PowerShell/commit/3b6604fe4b962c79ad69d3ae93f7c238d0a79759