update cargo.toml in python crate and fix unit test due to hash joins

Which issue does this PR close?
update cargo.toml in python crate
related #481
Closes #.
Rationale for this change

What changes are included in this PR?

Are there any user-facing changes?

Codecov Report

Merging #483 (c63710a) into master (33ff660) will not change coverage.
The diff coverage is n/a.

@@           Coverage Diff           @@
##           master     #483   +/-   ##
=======================================
  Coverage   75.80%   75.80%
=======================================
  Files         153      153
  Lines       25924    25924
=======================================
  Hits        19652    19652
  Misses       6272     6272

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 33ff660...c63710a. Read the comment docs.

@Jimexist , could we consider reverting this PR? I do not think that this is correct: DataFusions' behavior of returning 4 record batches when evaluated over a record batch of 3 entries seems wrong to me.

I flagged this in https://github.com/apache/arrow-datafusion/issues/523 , and I think that we should address this on the DataFusion side and not on the python bindings (i.e. concatenating the arrays).

Scratch the above, Python should keep the tests as is. If anything, we need to address this on DataFusion, but this PR is great as is. Sorry for the noise.


Update start.sh to automatically format Caddyfile

Gets rid of the pesky warning about improper formatting :)

Looks good!


⚠ Bofrost.at has degraded performance

In 7b70fbe, Bofrost.at (https://www.bofrost.at) experienced degraded performance:

HTTP code: 200
Response time: 1161 ms

Resolved: Bofrost.at performance has improved in fb5a08d.


Revert "Swagger closure for Azure Migration Hub Operations"

Reverts Azure/azure-rest-api-specs#4330

Automation for azure-sdk-for-python


Identify property by issuance transaction

The current id scheme with ascending numbers based on the complete history is extremely fragile.
Think of the two cases:

A client parses all transactions and there is one false interpretation of a simple send, e.g. due to a corrupt file, ... in the worst case the send is not recognized as such and a single branch of the whole system state is changed / black / invalid.

A client parses all transactions and there is one false interpretation of a property creation, e.g. due to a corrupt file, ... in the worst case all following transactions are completely changed / black / invalid.

I suggest to support identification of properties by some other mechanism which could be based on the (partial) hash of the creation transaction. I'm not sure, if this is the best approach, but it would be an improvement.
As bonus on top the property identifier would be known before the issuance transaction confirms and this enables chaining of Tx 54: New Property with Managed Number of Tokens and Tx 55: Granting Tokens for a Managed Property. This was sort of discussed in an Omni thread: https://github.com/mastercoin-MSC/omniwallet/issues/1062#issuecomment-60933928.
If the scope and context of an application is isolated, then a client may not even be required to parse all Mastercoin transactions, but only those after and related to the issuance of a property.

Playing devil's advocate here but why introduce that level of complexity in the first place (wrt property creation)?  Why not simply introduce a new version of the property creation transactions that includes a  field for the requested propID.  If it's already in use when the TX is parsed it's invalid.
For example I issue a tx creating a property and use '3' as the field for the requested property ID.  This tx is invalid and the property doesn't get created because the property ID is already in use.
Alternatively, let's use the example that I'm the popular 888 Casino website and I want to shift to my own crypto-backed tokens for some purpose - I issue a tx creating a property and use '888' as the field for the requested property ID.  This tx is valid and the property gets created because the property ID is available.
There would be some (not dramatic) coding changes in Core yep but this seems like a fairly simplistic model spec & code wise to move away from sequential prop IDs (which have various problems I won't re-iterate here).
Thanks
Z

Why not simply introduce a new version of the property creation transactions that includes a field for the requested propID. If it's already in use when the TX is parsed it's invalid.

Unless I miss something, this doesn't seem to solve the issue at all, because "full knowledge" (= every Master transaction processed correctly) is still required to determine, whether a property identifier is valid.
There are actually two seperate aspects:

full block chain / knowledge about transactions is required
complete and correct knowledge about meta transactions

What I proposed earlier, using RIPEMD-160(transaction id) or a "partial hash piece" as identifier, clears the second point, but I just noticed full block chain knowledge is still required. To solve both, only full transaction hashes seems to be viable.

level of complexity

To what are you referring here? The base idea is to use transaction ids to identify properties - which seems like a straightforward approach, but I'm biased against raw hashes due to the length.
OTOH there are several parts where the transaction size could be reduced significantly (e.g. using multisig output for change), but it doesn't seem to be an issue at this point.
Right now a "standard" simple send has a size of about 340 byte and using hashes instead of property ids comes with an overhead of 28 byte (32 byte hash vs. 4 byte property id) -- not very much imho.
Bitcoin Core 0.9 has "static fees" of x BTC/1000 byte, so it's "for free", because there is quite some space left. With 0.10 it's going to be fees paid per byte, and assuming 0.0001 BTC/kB, the overhead would equal additional costs of 0.0000028 BTC, less than 0.01 of a penny at the moment.
Let me be clear, I'm biased against those 28 bytes, but in the broader picture even a slightly improved input/change handling would have greater consequences - not even speaking of actually using "low output values" on mainnet, which seems to be the most significant, but unnecessary, cost factor at the moment.

Unless I miss something, this doesn't seem to solve the issue at all, because "full knowledge" (= every Master transaction processed correctly) is still required to determine, whether a property identifier is valid.

It's not exactly thoroughly thought out :P but I thought of this as only requiring us to know about previous creation transactions, not "full knowledge" as you put it of everything - create-property transaction validity is not dependent on anything other than previous prop creation's (assuming we allowed it to be specified) - I may be wrong though will need to think it through a little more.

To what are you referring here?

Simple change/scope control - allowing a property ID to be specified doesn't involve a large degree of change, but on initially reading your proposed move to property hashes for identification instead of property ID's seemed like a substantially 'bigger' change.
Also just for 2 cents - does your method not require knowledge of previous transactions also?  Utilizing the hash is atomic sure but we still need previous transactions to code in collision handling (no matter how unlikely we would need to cater for it I would assume?).
Thanks :)
Z

create-property transaction validity is not dependent on anything other than previous prop creation's

The dependency on previous property creations is the issue I see. ;) And this seems to be a similar problem with user defined ids as well as ascending auto-ids. You're right though, not every Master transaction is required to be processed correctly, but only those involving property creation.

collision handling

Let's stick to transaction hashes as identifier. In this case the property id == transaction id of creation transaction. One would be able to fetch the transaction and even without any other transaction the property information would be available.
The txid of a Bitcoin transaction is a SHA256(SHA256(raw_transaction)) hash, and I think it's safe to assume collision resistance is given.

History forgotten

The txid of a Bitcoin transaction is a SHA256(SHA256(raw_transaction)) hash, and I think it's safe to assume collision resistance is given.

Fair point :)

Let's stick to transaction hashes as identifier.

This is a pretty fundamental change in the code (switching property ID's from uint32 to uint256) but could be done.  Before we think about code though let's get some more views/feedback in.
Note, transaction malleability could be used to play havoc with anything that involves a property creation and zero conf if we did go this route, so would need to tread carefully for pending/unconfirmed perhaps.

Ah - think I see an issue - we couldn't treat all creations as atomic because 51 requires prior knowledge (only allowed one active crowdsale).

Good point. It still narrows the scope of "all 'create crowdsale' transactions" down to "all 'create crowdsale' transactions of address x".
Or, as alternative and further protocol change, multiple crowdsales per address are allowed and crowdsale participation becomes a more active process where the crowdsale-to-participate-in is explicitly selected. This would be in line with #277 ("I unintentionally participated in a crowdsale") and #261 ("Allow users to specify the specific terms of an offer they are responding to").

transaction malleability

That's unfortunally true. Depending one the use-case one could chain transactions where either the whole chain is valid or invalidated due to a altered crowdsale transaction (assuming the issuer wants to do something sneaky with unconfirmed transactions for some reason).
The overall goal is not necessarily to get down to robustness on a single transaction basis, but to prevent brutal butterfly effects, so to speak. (e.g. all property ids off by one number)

This is a pretty fundamental change in the code

Yeah, probably. ;) I just focused on the theory and haven't thought much about potential implementations. The most annoying part is probably to support both schemes at the same time (to process the "old" crowdsales), but this an issue in general and needs to be addressed with every change.


Signing of a multisig transaction with fee =/= minimal fee

When a cosigner signs a multisig transaction but a fee bigger then minimal fee is used, ERROR 306 is displayed.
-> The cosigners which just sign a multisig transaction should have their fee textbox disabled.

I tested and I got no error when creating a multisig transaction with a fee higher than the minimal fee. Signing as cosignatory also did not result in an error.


does Bugsnag have apm functionality?

Description

was wondering if Bugsnag has full apm functionality like new relic or is it just bugReporting for express?
Describe the solution you'd like

Describe alternatives you've considered

Additional context

Hi @btmiller13
Bugsnag is designed as a tool to provide error reporting and application stability monitoring. We don't support APM functionality. There is some useful context on the differences between APM and application stability in this article:
https://devops.com/apm-and-application-stability-where-two-monitoring-roads-merge-and-diverge/
If you have any more specific questions feel free to email us at<EMAIL_ADDRESS>Thanks!


Documentation

come on - no comments, no readme, nothing at all?? sure it's very nice and shiny code but I'd just like a bit of an explanation to save me reverse engineering what each ruby file is doing here. Just 3 sentences and an example or two.
Sincerely,
some ungrateful jackass from the internet :)

Even one or two examples would be great.  Or maybe a reference to a spec that could serve as an example to do a "hello world".  Or just even just a sentence giving a clue of where to start.


The [Header] drop-down switch on the small screen is not flexible

Only down id =dropdown-buttonelement, hopefully more flexible general

Hey @webvs2, I am not getting it properly what you are trying to say. can you please explain a little bit? thanks

@tfsomrat  Thank you for your attention;
This problem does not take effect when I put the page in a small resolution, and only the first one can drop down to display its option. I looked at the reason and observed that id was used as the trigger of the click event, which means that only one can take effect, but I added many navigation with 'children', and the others were invalid, so I improved it

You can create a PR to contribute on this theme, it will be great. thanks

@#9

thanks

@tfsomrat  You are welcome, it should be, and thank you very much for this template project, which makes me better to build the website. 😊


Ryansquared/stagex refactor

Description
This uses the stagex toolchain (see: https://codeberg.org/stagex/stagex) to build thesui-node container.
What is stagex?
stagex starts with 387 bytes of x86 assembly and deterministically reproduces every dependency necessary to build modern software. Every release of stagex is coordinated such that only if two maintainers with a separate hardware stack are able to reproduce the entire toolchain, will the containers be published. As such, stagex can be built locally to get the exact same images that exist in Docker Hub (when using Docker 25.x with containerd snapshotter).
This pull request uses the stagex toolchain and the stagex Containerfile workflow to build a deterministic OCI image. The image may be loaded to Docker using:
# Import into Docker
env -C build/oci/sui-node tar c . | docker load

# Verify Sui loads by printing version
docker run sui-node

The choice of the OCI output format is to ensure reproducibility, as Docker's image format has occasional quirks depending on the machine it runs on, but we've yet to experience a hardware configuration that has yet to reproduce using Docker 25.x and the containerd snapshotter.
Please note that the resulting image hash is dependent on the content ADDed in the Containerfile, so any modifications to any files that aren't exempted in .dockerignore will result in a new image hash.
Test Plan
Run sh docker/sui-node/build.sh, and compare the built hash:
 => exporting to oci image format
 => => exporting layers
 => => exporting manifest sha256:d82d09740b6e1e49742d2190766e285868f5eb42177af95423a352107bd8e43f
 => => exporting config sha256:40c360768857f5e23f2361872a04d6a7d99aad17d488703e9a368b90f4dda00f

Run docker system prune to clear the build cache, and run sh docker/sui-node/build.sh again.

Thanks @RyanSquared  for submitting this PR, and for all the work that went behind from you, Distrust, and others.
If merged, this should fix/resolve: https://github.com/MystenLabs/sui/issues/13476


[10.x] Infer route action from URI when not declared

This PR allows Laravel to automatically infer a route action based on its URI when the action is not explicitly defined.
This change allows developers to avoid repeating themselves when the URI reflects the controller action:
// before
Route::controller(UserController::class)->group(function () {
    Route::get('me', 'me');
    Route::post('invite', 'invite');
    Route::post('reset-password', 'resetPassword');
});

// after
Route::controller(UserController::class)->group(function () {
    Route::get('me');
    Route::post('invite');
    Route::post('reset-password');
});

Here are more details about how it works:

if the action is explicitly defined, Laravel routing will work as per usual
if a controller is not defined, Laravel routing will work as per usual
if the action is not explicitly defined, it infers the action from the URI
if the URI has nested paths (e.g. users/invite), it infers the action from the last segment (invite)
if the URI has dashes or underscores (e.g. reset-password), it infers the action by using camel case (resetPassword)
if different controllers are defined in nested groups, it infers the action from the latest group
if the latest nested group does not define a controller, it infers the action from the latest defined controller in the group stack

Thanks for your pull request to Laravel!
Unfortunately, I'm going to delay merging this code for now. To preserve our ability to adequately maintain the framework, we need to be very careful regarding the amount of code we include.
If possible, please consider releasing your code as a package so that the community can still take advantage of your contributions!
If you feel absolutely certain that this code corrects a bug in the framework, please "@" mention me in a follow-up comment with further explanation so that GitHub will send me a notification of your response.


Camp issue 8 Hoodie default ui

hoodiehq/camp#8

[x] add a default ui page
[ ] Implement the feature
[ ] closes hoodiehq/camp#8

@distalx we had a little boo boo, it was my mistake. We had a duplicated issue: see hoodiehq/camp#8 & hoodiehq/camp#19.
@kouryuu also already started a pull request at https://github.com/hoodiehq/hoodie/pull/583. I wonder if we could take his PR as a starting point, and discuss all together over at #583? Would that be okay with you?

closing it. planning to carry out this work on PR #583 .


Can't generate inside module folder

I'm working with an Angular 2 application based on Angular-CLI skeleton, I had the habit of structuring my src folder with one directory by module, and each component related to this module in the same folder.
src
	app
		documents
			document-list.component.ts
			document-list.component.html
			documents.component.ts
			documents.component.html
			document.module.ts
		app.component.ts
		app.module.ts
	main.ts

Now that I'm using Angular-CLI, I would like to take profit of each feature, but when I'm generating a new component, no matter what, it keep creating a new folder for my component when I just want to put it inside the related folder.
src
	app
		documents
			document-list
				document-list.component.ts
				document-list.component.html
			documents.component.ts
			documents.component.html
			document.module.ts
		app.component.ts
		app.module.ts
	main.ts

Is it possible to keep my previous structure, is it a bad practice? The guideline recommends to avoid useless directory depth so I'm kind of disturbed.

Generally, the default way the CLI creates components is what the style guide suggests, as found here: https://angular.io/styleguide#!#04-06.
If you want your old structure, though, when you generate a component use the --flat flag.
This should work... ng g c documents/document-list --flat

Great answer by @delasteve, cheers!


[New Feature] adding to always resolve hostname with always_host_resolve option.

if set always_host_resolve to true:
It always tries to resolve when reconnect to server.
before patch

read conf
resolve host address
connect
disconnect
connect with 2's info

after patch("always_host_resolve: true)

read conf
resolve host address
connect
disconnect
resolve host address again.
connect with 5's info

@manjuraj I'd be quite interested in this feature, as it would allow twemproxy to work more seamlessly with Elasticache in the case of a master->slave failover, or if a slave instance fails and is replaced with new hardware - in both cases the DNS entry for the primary/slave endpoint gets updated but as things stand we'd need a separate process watching for that to happen and restarting twemproxy accordingly.
If you think the code looks OK from a happy-to-merge point of view, I'd be happy to give this some testing to make sure it's still working as expected.

@tom-dalton-fanduel -- https://github.com/twitter/twemproxy/issues/355#issuecomment-113575050.

fixed with this patch:  https://github.com/twitter/twemproxy/commit/fd34c29bb69861b37eea786bd84a7e437ab8bb7c

Fantastic!


Testing!

This PR adds testing, yay! This is my first foray into formal testing with Python so please help me be sure I'm not doing something completely terrible.
Here are the currently targeted points for testing:

[x] Function parsing
[x] Argument parsing
[x] Classification of Function as fully annotated
[x] Warning classification
[x] Emitting correct line & column numbers
[x] Formatting warning message with argument name (where relevant)
[x] Outputting correct tuple for flake8
[x] Function and Argument object __str__ and __repr__ methods

Additionally:

Adds testing to the CI & a blurb in the README
Adds coverage reporting as a pipenv script.
Adds coverage reporting to CI
Replaces the debug string methods for Annotation and Function with proper __str__ and __repr__ methods
Adds a Dependabot configuration file to limit the scope of the dependency checking to the non-dev dependences. I have enabled Dependabot for this project in order to help with keeping on top of changes to flake8.
Fixes incorrectly configured flake8-docstrings (see: https://github.com/python-discord/organisation/issues/131)

See: #7
Closes: #16
Closes: #17
Closes: #19

Testing for Function & Argument parsing has been added, so this should be ready for review

I'm starting to realise these really are more like integration tests than unit tests.

From my exploration of the internet I think we have the opposite. Here's a source for definitions (no idea if it's a good one, but the internet seems to generally agree with the definitions):

UNIT TESTING is a level of software testing where individual units/ components of a software are tested. The purpose is to validate that each unit of the software performs as designed.

INTEGRATION TESTING is a level of software testing where individual units are combined and tested as a group. The purpose of this level of testing is to expose faults in the interaction between integrated units.

I tried to structure the tests so individual components are being tested rather than attempting to write a set of function definitions that covers all of the scenarios. From my initial exploration, the latter seemingly leads to a pretty incomprehensible set of repetitive definitions in order to cover the possible permutations of parameters we cover. This is why I split testing of the parser & classifier into two distinct tests, allowing for them to be much more clearly parameterized. Everything else I believe should be fairly cleanly unitized.
I'm not sure how much additional integration testing is needed beyond what's currently written. The parser should be fully tested, and the output emitted for flake8 has its own test as well.

Also, any plans to run test coverage?

I've added coverage to the dev dependencies & provided a pipenv script. Whether we want it added to the CI would be a good discussion to have.
Currently we're sitting at 98%:
----------- coverage: platform win32, python 3.7.3-final-0 -----------
Name                                Stmts   Miss  Cover   Missing
-----------------------------------------------------------------
flake8_annotations\__init__.py        105      6    94%   46, 89, 137, 195, 233-234
flake8_annotations\checker.py          57      0   100%
flake8_annotations\enums.py            15      0   100%
flake8_annotations\error_codes.py      85      0   100%
-----------------------------------------------------------------
TOTAL                                 262      6    98%

Currently missing are:

Argument._debug_summary (46)

Don't really care about testing this, but it's easy enough to cover

Function.is_fully_annotated (89)

Will add

Function.from_function_node (137)

Missing case for line number fallback. I don't know if we can ever encounter this but will figure out how to mock it anyway

Function._debug_summary (195)

Don't really care about testing this, but it's easy enough to cover

FunctionVisitor.visit_AsyncFunctionDef (233-234)

Will add. Functionally no different than FunctionVisitor.visit_FunctionDef but easy enough to cover

I've added coverage to the dev dependencies & provided a pipenv script. Whether we want it added to the CI would be a good discussion to have.

I think it should be added to CI. At the least just a report and not necessarily any sort of threshold for passing. The report can be published with an Azure task but it should still be configured to output to stdout. Apparently with pytest-cov it can be done with --cov-report term --cov-report public:html. For the publishing task, you can take a look at snekbox.

I don't have time to test this today, but the code looks phenomenal, Mark has done a thorough review and you basically have 100% test coverage so I don't think this desperately needs more testing.
I would just merge this.

The whole integration vs unit tests thing was fleshed out more on Discord. I came to the conclusion that they aren't really integration tests. However, some unit tests involve more units/components than they're actually concerned with testing. This was not addressed in this PR but I suppose it can be fixed later as the tests still work as they are.


Add initials

Add more...

Yarn

https://yarnpkg.com/

Editor Config

https://editorconfig.org/

Prettier

https://prettier.io/

ESLint

https://eslint.org/

Lint Staged

https://github.com/okonet/lint-staged

Commit Lint

https://commitlint.js.org/

Husky

https://typicode.github.io/husky/

Turbo Repo

https://turborepo.org/

Dotenv

https://github.com/motdotla/dotenv

VSCode Plugin Recommendation

https://code.visualstudio.com/docs/editor/extension-marketplace#_workspace-recommended-extensions

GitHub

CODEOWNERS

https://docs.github.com/en/repositories/managing-your-repositorys-settings-and-features/customizing-your-repository/about-code-owners

ISSUE & PR TEMPLATES

https://docs.github.com/en/communities/using-templates-to-encourage-useful-issues-and-pull-requests

Actions(Workflows)

test
Stale

https://docs.github.com/en/communities/using-templates-to-encourage-useful-issues-and-pull-requests


Update Lead space component page

updating content and imagery

@janchild @shixiedesign - That's much better! I switched them as variations and it makes much more sense now.

This page is much more clear now! Great work. I have a few small suggestions:

More descriptive captions. Our lead spaces allow for a lot of modifiers. This medium one is not showing background image. I'm wondering if we should caption all the lead space examples with a bit more details, eg. "Lead space — medium, showing here with tag links as navigational element, and no background image."


Add ipv6 as an acceptable input parameter

Please ensure your pull request (PR) adheres to the following guidelines:

Please refer to our contributing documentation for any questions on submitting a pull request, link: Contribution Guide

Pull Request Checklist
Please check if your PR fulfills the following requirements:

[ ] Testing of all the changes has been performed (for bug fixes / features)
[ ] The manual_readme_content.md has been reviewed and added / updated if needed (for bug fixes / features)
[ ] Use the following format for the PR description: <App Name>: <PR Type> - <PR Description>
[ ] Provide release notes as part of the PR submission which describe high level points about the changes for the upcoming GA release.
[ ] Verify all checks are passing.
[ ] Do NOT use the next branch of the forked repo. Create separate feature branch for raising the PR.
[ ] Do NOT submit updates to dependencies unless it fixes an issue.

Pull Request Type
Please check the type of change your PR introduces:

[ ] New App
[x] Bugfix
[ ] Feature
[ ] Code style update (formatting, renaming)
[ ] Refactoring (no functional changes, no api changes)
[ ] Documentation
[ ] Other (please describe):

Security Considerations (REQUIRED)

[ ] If you are exposing any endpoints using a REST handler,
please document them in the manual_readme_content.md.
[ ] If this is a new connector or you are adding new actions

[ ] Please document in the manual_readme_content.md all methods (eg, OAuth) used to authenticate
with the service that the connector is integrating with.
[ ] If any actions are unable to run on SOAR Cloud, please document this in the manual_readme_content.md.

[ ] Are you introducing any new cryptography modules? If yes, please elaborate their purpose:
[ ] Are you are accessing the file system? If yes, please verify that you are only accessing paths returned through
the Vault API.
[ ] Are you are marking code to be ignored by Semgrep with nosemgrep?
If yes, please provide justification in an additional comment next to the ignored code.

Release Notes (REQUIRED)

Updated "geolocate ip" JSON parameters to expect ip or ipv6 input data types

What is the current behavior? (OPTIONAL)

Only ip is permitted as an input type. ipv6 inputs fail the parameter check and the action fails

What is the new behavior? (OPTIONAL)
The "geolocate ip" action will accept ip and ipv6 input data types and query against the mmdb.
Other information (OPTIONAL)

Any other information that is important to this PR such as screenshots of how the component looks before and after the change.

Pay close attention to (OPTIONAL)

Any specific code change or test case points which must be addressed/reviewed at the time of GA release.

Screenshots (if relevant)

Thanks for contributing!

Ignoring prodsec-scans failure as it has been discussed on Slack, attaching a slack thread for the reference.
https://splunk.slack.com/archives/GBSGHUUD9/p1708518600677809


python311Packages.acunetix: init at 0.0.7

Description of changes
Acunetix Web Vulnerability Scanner SDK for Python
https://github.com/hikariatama/acunetix
Related to #81418

Things done

Built on platform(s)

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

[ ] For non-Linux: Is sandbox = true set in nix.conf? (See Nix manual)
[ ] 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

[ ] 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
[ ] Tested basic functionality of all binary files (usually in ./result/bin/)
23.11 Release Notes (or backporting 23.05 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.

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

4 packages built:

python310Packages.acunetix
python310Packages.acunetix.dist
python311Packages.acunetix
python311Packages.acunetix.dist


chore: add docstring on says syntax

Note: I have pushed an update to the lean toolchain because this PR was on a buggy version of the toolchain. WARNING: checking out old commits of this PR using v4.2.0-rc2 or v4.2.0-rc3 can cause lake clean to delete your mathlib folder! If you need to do so, make sure to delete lakefile.olean manually before running any lake commands.

bors merge


Automatic updates of container images

AFAIK, there doesn't seem to be a solution to automatically update rkt containers to use the latest image (According to acVersion semver.
Docker users can utilize Watchtower. Also, I think that CoreOS provides this functionality. So the problem lies with running containers without a specific distro.

rkt is a self-contained container runtime, what you are asking for seems to fit into the model of a long-running polling process. I don't think this features should be under the responsibility of rkt, but I'd rather would see this implemented by an external orchestration system (e.g. kubernetes) which drives rkt.


Decks completed feature

This PR is about completing a selected deck. Once you have done with all questions, you will see the message 'Deck is completed' and you can choose another deck. This will let the user know when has visited all questions from a topic. You also have the possibility to do the completed deck again.

Great addition! Makes for much smoother ux. awesome!