Fix "Send" button is missing on password protected PDF preview

Details

Fixed Issues

$ https://github.com/Expensify/App/issues/39870
PROPOSAL: https://github.com/Expensify/App/issues/39870#issuecomment-2044086513
Tests

Go to any chat
Try to send a password protected PDF (there is one attached to this report, password: "Test12345")
On the preview before sending, tap on "enter the password"
Enter the password and tap on "Confirm"
Verify that: "Send" button should be displayed below de PDF

[x] Verify that no errors appear in the JS console

Offline tests

QA Steps

Go to any chat
Try to send a password protected PDF (there is one attached to this report, password: "Test12345")
On the preview before sending, tap on "enter the password"
Enter the password and tap on "Confirm"
Verify that: "Send" button should be displayed below de PDF

[x] Verify that no errors appear in the JS console

PR Author Checklist

[x] I linked the correct issue in the ### Fixed Issues section above
[x] I wrote clear testing steps that cover the changes made in this PR

[x] I added steps for local testing in the Tests section
[x] I added steps for the expected offline behavior in the Offline steps section
[x] I added steps for Staging and/or Production testing in the QA steps section
[x] I added steps to cover failure scenarios (i.e. verify an input displays the correct error message if the entered data is not correct)
[x] I turned off my network connection and tested it while offline to ensure it matches the expected behavior (i.e. verify the default avatar icon is displayed if app is offline)
[x] I tested this PR with a High Traffic account against the staging or production API to ensure there are no regressions (e.g. long loading states that impact usability).

[x] I included screenshots or videos for tests on all platforms
[x] I ran the tests on all platforms & verified they passed on:

[x] Android: Native
[x] Android: mWeb Chrome
[x] iOS: Native
[x] iOS: mWeb Safari
[x] MacOS: Chrome / Safari
[x] MacOS: Desktop

[x] I verified there are no console errors (if there's a console error not related to the PR, report it or open an issue for it to be fixed)
[x] I followed proper code patterns (see Reviewing the code)

[x] I verified that any callback methods that were added or modified are named for what the method does and never what callback they handle (i.e. toggleReport and not onIconClick)
[x] I verified that the left part of a conditional rendering a React component is a boolean and NOT a string, e.g. myBool && <MyComponent />.
[x] I verified that comments were added to code that is not self explanatory
[x] I verified that any new or modified comments were clear, correct English, and explained "why" the code was doing something instead of only explaining "what" the code was doing.
[x] I verified any copy / text shown in the product is localized by adding it to src/languages/* files and using the translation method

[x] If any non-english text was added/modified, I verified the translation was requested/reviewed in #expensify-open-source and it was approved by an internal Expensify engineer. Link to Slack message:

[x] I verified all numbers, amounts, dates and phone numbers shown in the product are using the localization methods
[x] I verified any copy / text that was added to the app is grammatically correct in English. It adheres to proper capitalization guidelines (note: only the first word of header/labels should be capitalized), and is either coming verbatim from figma or has been approved by marketing (in order to get marketing approval, ask the Bug Zero team member to add the Waiting for copy label to the issue)
[x] I verified proper file naming conventions were followed for any new files or renamed files. All non-platform specific files are named after what they export and are not named "index.js". All platform-specific files are named for the platform the code supports as outlined in the README.
[x] I verified the JSDocs style guidelines (in STYLE.md) were followed

[x] If a new code pattern is added I verified it was agreed to be used by multiple Expensify engineers
[x] I followed the guidelines as stated in the Review Guidelines
[x] I tested other components that can be impacted by my changes (i.e. if the PR modifies a shared library or component like Avatar, I verified the components using Avatar are working as expected)
[x] I verified all code is DRY (the PR doesn't include any logic written more than once, with the exception of tests)
[x] I verified any variables that can be defined as constants (ie. in CONST.js or at the top of the file that uses the constant) are defined as such
[x] I verified that if a function's arguments changed that all usages have also been updated correctly
[x] If any new file was added I verified that:

[x] The file has a description of what it does and/or why is needed at the top of the file if the code is not self explanatory

[x] If a new CSS style is added I verified that:

[x] A similar style doesn't already exist
[x] The style can't be created with an existing StyleUtils function (i.e. StyleUtils.getBackgroundAndBorderStyle(theme.componentBG))

[x] If the PR modifies code that runs when editing or sending messages, I tested and verified there is no unexpected behavior for all supported markdown - URLs, single line code, code blocks, quotes, headings, bold, strikethrough, and italic.
[x] If the PR modifies a generic component, I tested and verified that those changes do not break usages of that component in the rest of the App (i.e. if a shared library or component like Avatar is modified, I verified that Avatar is working as expected in all cases)
[x] If the PR modifies a component related to any of the existing Storybook stories, I tested and verified all stories for that component are still working as expected.
[x] If the PR modifies a component or page that can be accessed by a direct deeplink, I verified that the code functions as expected when the deeplink is used - from a logged in and logged out account.
[x] If the PR modifies the UI (e.g. new buttons, new UI components, changing the padding/spacing/sizing, moving components, etc) or modifies the form input styles:

[x] I verified that all the inputs inside a form are aligned with each other.
[x] I added Design label and/or tagged @Expensify/design so the design team can review the changes.

[x] If a new page is added, I verified it's using the ScrollView component to make it scrollable when more elements are added to the page.
[x] If the main branch was merged into this PR after a review, I tested again and verified the outcome was still expected according to the Test steps.

Screenshots/Videos

Android: Native

https://github.com/Expensify/App/assets/161821005/5a50ceb2-4129-472f-b0b7-4d4c2fab78ce

Android: mWeb Chrome

https://github.com/Expensify/App/assets/161821005/8ffb83f6-420a-447e-a242-d0d5372b3d39

iOS: Native

https://github.com/Expensify/App/assets/161821005/44b03cb2-2087-4378-8b6e-572eadc8823f

iOS: mWeb Safari

https://github.com/Expensify/App/assets/161821005/606ea5f5-9217-4465-967c-d52e1e632be4

MacOS: Chrome / Safari

MacOS: Desktop

:hand: This PR was not deployed to staging yet because QA is ongoing. It will be automatically deployed to staging after the next production release.

🚀 Deployed to staging by https://github.com/thienlnam in version: 1.4.63-0 🚀

platform
result

🤖 android 🤖
success ✅

🖥 desktop 🖥
success ✅

🍎 iOS 🍎
success ✅

🕸 web 🕸
success ✅

🚀 Deployed to production by https://github.com/mountiny in version: 1.4.63-21 🚀

platform
result

🤖 android 🤖
success ✅

🖥 desktop 🖥
success ✅

🍎 iOS 🍎
success ✅

🕸 web 🕸
success ✅


WLAlertHelper createAlertControllerForReason without reason and pass Text dynamically

Hi,
WLAlertHelper createAlertControllerForReason,
how to do, without reason and pass Text dynamically from anywhere ?
For Example,
[WLAlertHelper createAlertControllerForReason:@"This text will be dynamic, NOT Pre-Defined in Alert.JSON"];

@umair2ooo
You can add a placeholder alert in your Alerts.json file, which will look like this:
"1": {
        "reason" : "DynamicReason",
        "title": "%@",
        "body": "%@"
    },

Optionally define the enum with your alert reasons
enum {
    DynamicReason = 1,
}

And use the following method:
[WLAlertHelper createAlertControllerForReason:DynamicReason titleArguments:@[@"Your dynamic title"] bodyArguments:@[@"Your dynamic body"] delegate:nil];

It works :-)
Thanks


trace graph requests

grah currently does not trace as the ocis pkg middleware for tracing is executed only after the graph tracer (which now actually adds a span to the trace).

superseded by
https://github.com/owncloud/ocis/pull/6695 and
https://github.com/owncloud/ocis/pull/6988


ci: Link checker flakiness.

New link checker is flaky as well =D
https://github.com/thanos-io/thanos/pull/3209/checks?check_run_id=1156310870
cc @daixiang0
Life is hard.

Sad news :(

We removed it for now. Waiting for replacement.

I see istio uses htmltest, do not find flafkiness, shall we try it?


fix typescript build issue

Hi, you don't want this merged?

no
On Wed, Apr 26, 2023 at 7:33 PM Danny Veldhoen @.***>
wrote:

Hi, you don't want this merged?
—
Reply to this email directly, view it on GitHub
https://github.com/dveldhoen/easyinvoice/pull/90#issuecomment-1523477696,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/ASHIDCEZSJOTMFZHJO3TX2DXDETJNANCNFSM6AAAAAAXMNUQCI
.
You are receiving this because you modified the open/close state.Message
ID: @.***>


Request: InventoryTweaks interaction in 1.12.1

Issue description:
InventoryTweaks mod has feature to drop everything from inventory to an opened storage by pressing [spacebar]+[leftclick]. This feature works nicely with most storage providing mods. I tried this with Refined Storage in Grid or Crafting Grid, it doesn't work. I am not sure if this request should be for InventoryTweaks team or for your team, please let me know. I am using refinedstorage-1.5.17, forge <IP_ADDRESS>7, InventoryTweaks-1.63+beta.108. Thanks.

api doesn't allow it


Accept empty required array

Fixes the following issue:
{
  "detail": "ValidationError (Person:60dde7de07e53d16f3766b54) (Field is required and cannot be empty: ['organizationIds'])",
  "status": 500,
  "title": "Internal error"
}

Pull Request Test Coverage Report for Build 990835940

0 of 0   changed or added relevant lines in 0 files are covered.
No unchanged relevant lines lost coverage.
Overall coverage remained the same at 66.755%

Totals

Change from base Build 983583345:
0.0%

Covered Lines:
1504

Relevant Lines:
2253

💛  - Coveralls

Closing because this PR is empty after updating it.


Interactive Python: guests cannot execute cells

Describe what happened:
When trying to execute code cells as a guest, I recieve an error message "The host doesn't allow running this command. If needed, ask them to enable it."
Even enabling the option "Liveshare > Languages: Allow Guest Command Control" does not help.
However, it does work in version 1.0.2478 of Live Share, but appears broken in the most recent version 1.0.2619.
What was your system configuration?
Product and Version [VS/VSCode]: VS Code 1.47.3
OS Version[macOS/Windows]: Ubuntu 20.04 and Ubuntu 18.04.5 LTS and Windows 10
Live Share Extension Version: 1.0.2619
Steps to Reproduce / Scenario:

Start VS Code with Live Share and Python extension
Log in to Live Share
Open an empty folder in VS Code
Create a file named test.py with content #%% on the first line and print("Hello World") on the second line and save it.
Open a second instance of VS Code on the same machine (it should be logged in to Live Share, too)
In the first instance, start a collaboration session and invite onself. Make sure that there is a shared Jupyter Server in the session.
In the second instance, accept the invitation.
In the second instance, open test.py
In the second instance, click "run cell" above the hello world code line.
The error message appears. (In the older version 1.0.2478, at this point, the code cell gets executed and both instances can see the output).

@BrunoGuardia , i open a bug to track this potential regression, can you assign to someboy in the team, maybe @IlyaBiryukov ?

I also ran into this issue

@fubaduba @aletsdelarosa , this is the same issue as guest command control not being respected.

This should now be resolved! Please reopen if you find otherwise.


Add new rules within configmap.

Background:
I use registry.k8s.io/node-problem-detector/node-problem-detector prebuilt image within /config/kernel-monitor.json rules.
Issue:
If I want to add my own additional rule for System Log Monitor, I have to add this rule e.g. into /config/kernel-monitor.json file and build the whole image from the scratch.
Gentle request:
Can you add possibility to add new rules within e.g. configmaps? The goal is to have a possibility to add additional rules without building our own image.

Seems I created issue to fast :/ as I can see I can add new rules by mounting my own config in node-problem-detector container. So, sorry for disturbing :/ and I'm closing the issue ...


Fix for Existential2Specialized functions that get inlined in the caller with appropriate dealloc_stack order

Fix for Existential2Specialized functions that get inlined in the caller with wrong dealloc_stack order

@slavapestov I found a case where when the existential specialized function gets inlined into caller running into a verifier error with dealloc_stack order. I changed the logic to insert dealloc_stack only before return instructions. Earlier I was doing it with destroy_addr instructions.

Created another PR for all bug fixes.


[SDL2]: Initial fullscreen not "active"

Can be checked with SDL1 and 2 builds of residualvm.
The SDL1 version is effectively immediately usable after start, while the SDL2 version need a mouse click into the launcher to become usable.
e.g. the buttons change color when the mouse pointer hovers over it.
This does not work right away with SDL2.
Could be a similar problem as it was with #98

Cannot reproduce. When I move mouse pointer over buttons in either window or fullscreen mode, they "activate", or turn brighter.
Please double-triple check that you are linking against the latest SDL2 lib. I don't have other ideas right now.

Yep, does not happen anymore.
Seems i had reverted to SDL2.0.9 when i did the tests.
Thank you for your time


API

Create a documentation for each entrypoint (Http verb, url, parameters, response code, etc...)

Reviewed and Approved.


String sort localization / 字符串排序本地化

After this change, users will be able to sort their voicebanks in a certain language, such as pinyin (zh-cn). This would be very convenient if the user have many voicebanks installed.
The sorting order can be different from the UI language. For example, If a Chinese user have a lot of Japanese voicebanks installed, he may want to sort his voicebanks in Japanese while seeing OpenUtau's UI in Chinese.

Here is microsoft's official documentation on the neccessarity of localized string sorting: https://learn.microsoft.com/en-us/globalization/locale/sorting-and-string-comparison


Compile inline styles to the identified style format (SCSS, LESS, etc)

Bug Report or Feature Request (mark with an x)
- [ X ] bug report -> please search issues before submitting
- [ ] feature request

Versions.
Angular CLI: 1.5.0
Node: 8.9.1
OS: darwin x64
macOS Sierra 10.12.6
Repro steps.

run ng new foo --styles scss
create a component with inline styles
add scss styles to it
run ng serve -o

The log given by the failure.
The style compile as CSS, even though we set them to be SCSS in the cli json file
Desired functionality.
I would like to see angular transpile inline styles and external files styles using the identified selection.
Mention any other details that might be useful.
The workaround is to move styles for SCSS to their own file, using the styleUrls metadata.

Hi @johnpapa,
Inline styles will not be rendered with a special renderer, unfortunately. It is impossible for us to know which styles you want your inline style to be, and even so we don't have control over how inline styles are compiled; we do not resolve them like we do with external styles.
This is a limitation of the angular compiler itself.
I'm going to close this as working as intended.
Cheers!

I do not understand ... if the CLI knows it is SASS (aka scss), then how do we not know what to tell the compiler?
How are external file templates different? Is it because SASS just hits those extensions by default and the webpack compiler for sass, less, etc are always there?

FYI there was a PR to do this (https://github.com/angular/angular-cli/pull/8145).

if the CLI knows it is SASS (aka scss)

We do by the file extension. For inline styles we don't. The PR referred by Filipe is a hack that creates fake files and refactor the component.


[flaky ci] [Serial][rfe_id:393][crit:high][vendor:cnv-qe@redhat.com][level:system] VM Live Migration with a live-migrate eviction strategy set with multiple VMIs with eviction policies set [test_id:3245]should not migrate more than two VMIs at the same time from a node

Is this a BUG REPORT or FEATURE REQUEST?:

Uncomment only one, leave it on its own line:

/kind bug

/kind enhancement

/triage build-watcher
What happened:
Test [Serial][rfe_id:393][crit:high][vendor:cnv-qe@redhat.com][level:system] VM Live Migration with a live-migrate eviction strategy set with multiple VMIs with eviction policies set [test_id:3245]should not migrate more than two VMIs at the same time from a node flaked before #444 got merged.
Offending lane: https://prow.apps.ovirt.org/view/gcs/kubevirt-prow/pr-logs/pull/kubevirt_kubevirt/4444/pull-kubevirt-e2e-k8s-1.17/1325754118735663104
PR history:  https://prow.apps.ovirt.org/pr-history?org=kubevirt&repo=kubevirt&pr=4444
Test stacktrace:
tests/migration_test.go:1880
Timed out after 240.000s.
Expected
    <[]string | len:4, cap:4>: ["node01", "node01", "node01", "node01"]
to consist of
    <[]interface {} | len:4, cap:4>: ["node02", "node02", "node02", "node02"]
the missing elements were
    <[]interface {} | len:4, cap:4>: ["node02", "node02", "node02", "node02"]
the extra elements were
    <[]interface {} | len:4, cap:4>: ["node01", "node01", "node01", "node01"]
tests/migration_test.go:1935

Related: #4219
What you expected to happen:
How to reproduce it (as minimally and precisely as possible):
Anything else we need to know?:
Environment:

KubeVirt version (use virtctl version):
Kubernetes version (use kubectl version):
VM or VMI specifications:
Cloud provider or hardware configuration:
OS (e.g. from /etc/os-release):
Kernel (e.g. uname -a):
Install tools:
Others:

Grouped in #4544
/close


I'm trying to implement General Constraints of Type Indicator

Hi! First of all, thanks for the crate!
For my use case, I need the General Constraints of type Indicator (is "Generic Indicator Constraints" a better name?). I'd love to contribute an implementation of them, but currently there are some places where I'm not entirely sure how to best incorporate them into existing types. I was curious whether you would be interested in adding them in the near future (maybe you have goals of higher priority right now?). In case you are, here are where I'm so far:
This constraint type has the following form:
<binary_variable> == <binary_value> => <linear_constraint>

the RHS is easy - it's just a LinExpr
the LHS, on the hand, looks kind of like a LinExpr, but much more constrained. So constrained in fact, that I thought it would be easier to just accept separately a (binary)[^1] variable and a bool as its value. Among other things, this would roughly correspond to the C API:

int GRBaddgenconstrIndicator (
    GRBmodel  *model,
    const char	 *name,
    int		 binvar,
    int		 binval,
    int		 nvars,
    const int	 *ind,
    const double *val,
    char	 sense,
    double	 rhs
)

So the final function would look something like this (this is based on Model::add_constr):
pub fn add_genconstr_indicator(
        &mut self,
        name: &str,
        ind: Var,
        ind_val: bool,
        con: IneqExpr,
    ) -> Result<Constr> {
        let constrname = CString::new(name)?;
        let (lhs, sense, rhs) = con.into_normalised_linear()?;
        let (vinds, cval) = self.get_coeffs_indices_build(&lhs)?;
        self.check_apicall(unsafe {
            ffi::GRBaddgenconstrIndicator(
                self.ptr,
                constrname.as_ptr(),
                todo!("binvar -> coef (by using `get_coeffs_indices_build`?"),
                ind_val as ffi::c_int,
                cval.len() as ffi::c_int,
                vinds.as_ptr(),
                cval.as_ptr(),
                sense as ffi::c_char,
                rhs,
            )
        })?;

        Ok(self.constrs.add_new(self.update_mode_lazy()?))
    }

... with ffi::GRBaddgenconstrIndicator looking as follows:
pub fn GRBaddgenconstrIndicator(
        model: *mut GRBmodel,
        name: c_str,
        binvar: c_int,
        binval: c_int,
        nvars: c_int,
        ind: *const c_int,
        val: *const c_double,
        sense: c_char,
        rhs: c_double,
    ) -> c_int;

So, let me know what you think, and whether I should make a (draft) PR so that you could examine the changes more easily. Thanks in advance!
[^1]: docs say you can pass any variable here, and it will be coerced to binary

todo!("binvar -> coef (by using `get_coeffs_indices_build`?"),

after some more digging, I think this would be done either with Model::get_index or Model::get_index_build. Not entirely sure what the difference between these is and which one I'm supposed to use, but I think it's the latter?

Hi! This is very much in-the weeds.  In the C API, Gurobi variables, linear constraints, quadratic constraints, etc are all represented by continguous indices starting from 0.  The index manager (IdxManager) is in charge of mapping the Rust types like Var, Constr and friends to the C indices, handling the changes to indices that result from removing and adding constraints.  Model::get_index and Model::get_index_build just call the IdxManager methods.
The reason for the different methods is that some operations, like querying attributes require a call to model.update() first.  Other operations, like building a constraint from freshly-added variables, do not require an explicit model.update().
The former will call Model::get_index under the hood, and the latter will call Model::get_index_build.  You are right, for adding general indicator constraints, we want Model::get_index_build.    I think general constraints will be the same, so we'll need to add a new GenConstr model object, as well as a new index manager field to Model.
You could always work around the general constraints by implementing them manually, using big-M constraints:

Thanks for the detailed answer!
I've gathered some of the stuff with indices while looking through the crate, but your explanation certainly cleared up some of the more obscure details, so thanks! I think I have general intuition now, so I'll try looking into GenConstr and the IdxManager thing.
As I understand it, add_genconstr_indicator won't work as it's implemented currently -- but it seems that something is wrong in ffi::GRBaddgenconstrIndicator also. Cargo says it can't find it -- which is weird, because I've just placed it right besides the other constraint functions, more specifically right after this one:[^1]
https://github.com/ykrist/rust-grb/blob/74a73d876d11fff0848fae409c20bee2bfc90f64/grb-sys2/src/lib.rs#L68-L78
Would you happen to know why that could be? I've tried cargo clean-ing and rebuilding both grb-sys2 and grb (multiple times), but to no avail.
I've read a bit about the big-M constraints, and I have found a way to encode b == 1 => x == z using them -- but what I need is b == 1 => x >= z... which, now that I think of it, I could probably implement using a slack variable? Nevertheless, I think adding a support of them to the crate might be worthwhile.
[^1]: I really should make this into a PR instead of trying to describe everything with words shouldn't I :sweat_smile:


Process and Thread ID should be ulong

On non-windows platforms the process and thread IDs may be pointer sized.  Make them ulong instead of uint for compatibility.

Looks like uint is standard on linux, and I think OS X.  I'm not going to make this change.

The runtime and SOS use uint (32bit) for thread and process ids and have never had a problem even though on Linux the pid_t type is usually a ulong.

@mikem8361 I was going by this, which says the pid is always 32bits, at least on intel architectures.  I wonder if that's true for arm and other architectures...

I was agreeing with you conclusion if that wasn't clear. I think (but not sure) it applies to arm/arm64 also.

I was agreeing with you conclusion if that wasn't clear. I think (but not sure) it applies to arm/arm64 also.

Yes, sorry.  We are on the same page.  I was just thinking out loud.  =)

We may want to reconsider reopening because on MacOS process/threads id do and can get larger than an uint.  I forgot/did know this at the time.

#define	PID_MAX		99999

https://github.com/apple/darwin-xnu/blob/a449c6a3b8014d9406c2ddbdc81795da24aa7443/bsd/sys/proc_internal.h#L639
For reference: https://apple.stackexchange.com/questions/51119/whats-the-maximum-pid-for-mac-os-x

Yes, it looks like process ids are uint/32bit but thread ids on MacOS are not. From Leandro Pereira who changed the runtime PAL get current thread id functions to return 64bit ids:
I don’t know what’s the deal with the Process and Thread IDs in MacOS.  On Linux, there seems to be a relationship between them.  On MacOS, they seem to be different kinds of animal (pid_t is 32-bit for instance: https://github.com/apple/darwin-xnu/blob/master/bsd/sys/_types.h#L72).
Looking at the implementation for pthread_threadid_np(), it seems it just returns the cached value returned by __thread_selfid(), which is the system call I used to use in one of my portable programs to obtain the thread id:
Where the cache is set: https://github.com/apple/darwin-libpthread/blob/master/src/pthread.c#L1641
Where the cache is used: https://github.com/apple/darwin-libpthread/blob/master/src/pthread.c#L1118
If you look at the syscall prototype, you’ll see it’s defined to return a uint64_t:
https://github.com/apple/darwin-libpthread/blob/master/src/pthread.c#L270
With these in mind, it seems safe to assume here that sizeof(tid_t) – even though that type doesn’t exist – is indeed 64-bit on MacOS.  (And pid_t remains 32-bit.)

I'll make the change in ClrMD 2.1.


Appstudio update hacbs-test-project-sqvh

Pipelines as Code configuration proposal
To start the PipelineRun, add a new comment with content /ok-to-test
For more detailed information about running a PipelineRun, please refer to Pipelines as Code documentation Running the PipelineRun
To customize the proposed PipelineRuns after merge, please refer to Build Pipeline customization

Pipelines as Code CI has failed.There was an error creating the PipelineRun: hacbs-test-project-sqvh-on-pull-request-
creating pipelinerun hacbs-test-project-sqvh-on-pull-request- in namespace rhtap-demo-qoht-tenant has failed.
Tekton Controller has reported this error: the namespace of the provided object does not match the namespace sent on the request

Pipelines as Code CI has failed.There was an error creating the PipelineRun: hacbs-test-project-sqvh-on-pull-request-
creating pipelinerun hacbs-test-project-sqvh-on-pull-request- in namespace rhtap-demo-vrlo-tenant has failed.
Tekton Controller has reported this error: the namespace of the provided object does not match the namespace sent on the request

Pipelines as Code CI has failed.There was an error creating the PipelineRun: hacbs-test-project-sqvh-on-pull-request-
creating pipelinerun hacbs-test-project-sqvh-on-pull-request- in namespace rhtap-demo-pqbp-tenant has failed.
Tekton Controller has reported this error: the namespace of the provided object does not match the namespace sent on the request

Pipelines as Code CI has failed.There was an error creating the PipelineRun: hacbs-test-project-sqvh-on-pull-request-
creating pipelinerun hacbs-test-project-sqvh-on-pull-request- in namespace rhtap-demo-pgat-tenant has failed.
Tekton Controller has reported this error: the namespace of the provided object does not match the namespace sent on the request

Pipelines as Code CI has failed.There was an error creating the PipelineRun: hacbs-test-project-sqvh-on-pull-request-
cannot patch pipelinerun hacbs-test-project-sqvh-on-pull-request-: failed to patch pipelinerun rhtap-demo-hfag-tenant/logURL with hacbs-test-project-sqvh-on-pull-request-xbc45: pipelineruns.tekton.dev "hacbs-test-project-sqvh-on-pull-request-xbc45" not found


Regionality metric & modern vizlab

This calculates regionality based on work we did 2 years ago and adds a rudimentary graph to the index.html (see below), all using the modern vizlab framework. Just run vizlab::vizmake() and you should see this on the front page:

Calculation method still needs verification + need better viz of this metric :) Both of those are planned work for other people.
Related to https://github.com/usgs-makerspace/wbeep-sandboxr/issues/14

I don't remember either.....at one point we needed added the compression because we had such a small setup on Jenkins....but then we got a bigger memory footprint...I might have un-compressed them.... I think either will work now.

Hmm I didn't realize something I had done overwrote that. So where should I change saveRDS? Or should I?

It's in all the saveRDS calls. e.g. here: https://github.com/USGS-VIZLAB/internal-analytics/pull/228/files#diff-9edf981e79692fc872681e16d4bf7ad7L23.  It may not actually be something you changed, just got pulled along since this branch got so old?  I'd say just leave it for now, we can change it later if things get really slow .

Go ahead and merge when you're ready


Requirement Analysis (QUESTION)

Is it possible to plot a cursor on the text in between and make it properly editable? I have used https://github.com/uptechteam/MotionViews-Android but this does not provide cursor as the text it plotted as a bitmap.

I think that is not possible to put a cursor between text.


support for options in requestFullscreen()

this is a very useful library. Yet I noticed that in Android Chrome it fails to hide the navigation bar. In order to do that, navigationUI: 'hide' option needs to be provided to requestFullscreen(), but it is not possible to pass through fscreen.
More information on options here

I think adding an options argument to fscreen.requestFullscreen makes sense.
Until then you should be able to use fscreen.requestFullscreenFunction(element)(options) to pass in options.

Until then you should be able to use fscreen.requestFullscreenFunction(element)(options) to pass in options.

and this basically solves my problem. thanks!


Feature/initialization helper

Initial improvements for: https://github.com/conceptadev/typeorm-seeding/issues/5
There is a new initialization helper that gets called automatically when running the seeders via CLI. If you are building a programmatic seed script, you can call SeederSource.initialize() manually as well.
Also added some helpers for easily retrieving Repositories from inside Seeder and Factory classes.

Lovely!

Fixes https://github.com/conceptadev/typeorm-seeding/issues/5


chore: Make python3.11 the default python

Description
Make python3.11 the default python in the brew.Dockerfile image.
This is required because, for now, the Helm chart expected having a python command in the path.
Which issue(s) does this PR fix

Fixes #?

PR acceptance criteria
Please make sure that the following steps are complete:

[ ] GitHub Actions are completed and successful
[ ] Unit Tests are updated and passing
[ ] E2E Tests are updated and passing
[ ] Documentation is updated if necessary (requirement for new features)
[ ] Add a screenshot if the change is UX/UI related

How to test changes / Special notes to the reviewer

PR has been cherry-picked


Unable to install plugin with inspec 4.7.3

Describe the bug
Unable to install the plugin on my Macbook, get a generic error saying it failed.
Environment
OS: MacOS 10.14.5
Inspec: 4.7.3
InSpec-Iggy: 0.5.0
To Reproduce
install dmg from Chef then run from iterm2 inspec plugin install inspec-iggy
Expected behavior
plugin to install successfully
Additional context
Here is the debug output
inspec plugin install inspec-iggy --log-level=debug
[2019-07-15T16:18:50+01:00] DEBUG: PluginLoader: refusing to re-register plugin 'inspec-supermarket': an existing plugin with that name was loaded via bundle-loading from /opt/inspec/embedded/lib/ruby/gems/2.6.0/gems/inspec-4.7.3/lib/bundles/inspec-supermarket.rb
[2019-07-15T16:18:50+01:00] DEBUG: PluginLoader: refusing to re-register plugin 'inspec-plugin-manager-cli': an existing plugin with that name was loaded via core-loading from /opt/inspec/embedded/lib/ruby/gems/2.6.0/gems/inspec-4.7.3/lib/plugins/inspec-plugin-manager-cli/lib/inspec-plugin-manager-cli.rb
[2019-07-15T16:18:50+01:00] DEBUG: PluginLoader: refusing to re-register plugin 'inspec-artifact': an existing plugin with that name was loaded via core-loading from /opt/inspec/embedded/lib/ruby/gems/2.6.0/gems/inspec-4.7.3/lib/plugins/inspec-artifact/lib/inspec-artifact.rb
[2019-07-15T16:18:50+01:00] DEBUG: PluginLoader: refusing to re-register plugin 'inspec-habitat': an existing plugin with that name was loaded via core-loading from /opt/inspec/embedded/lib/ruby/gems/2.6.0/gems/inspec-4.7.3/lib/plugins/inspec-habitat/lib/inspec-habitat.rb
[2019-07-15T16:18:50+01:00] DEBUG: PluginLoader: refusing to re-register plugin 'inspec-init': an existing plugin with that name was loaded via core-loading from /opt/inspec/embedded/lib/ruby/gems/2.6.0/gems/inspec-4.7.3/lib/plugins/inspec-init/lib/inspec-init.rb
[2019-07-15T16:18:50+01:00] DEBUG: PluginLoader: refusing to re-register plugin 'inspec-compliance': an existing plugin with that name was loaded via core-loading from /opt/inspec/embedded/lib/ruby/gems/2.6.0/gems/inspec-4.7.3/lib/plugins/inspec-compliance/lib/inspec-compliance.rb
Traceback (most recent call last):
	22: from /usr/local/bin/inspec:181:in `<main>'
	21: from /usr/local/bin/inspec:181:in `load'
	20: from /opt/inspec/embedded/lib/ruby/gems/2.6.0/gems/inspec-bin-4.7.3/bin/inspec:11:in `<top (required)>'
	19: from /opt/inspec/embedded/lib/ruby/gems/2.6.0/gems/inspec-4.7.3/lib/inspec/base_cli.rb:31:in `start'
	18: from /opt/inspec/embedded/lib/ruby/gems/2.6.0/gems/thor-0.20.3/lib/thor/base.rb:466:in `start'
	17: from /opt/inspec/embedded/lib/ruby/gems/2.6.0/gems/thor-0.20.3/lib/thor.rb:387:in `dispatch'
	16: from /opt/inspec/embedded/lib/ruby/gems/2.6.0/gems/thor-0.20.3/lib/thor/invocation.rb:126:in `invoke_command'
	15: from /opt/inspec/embedded/lib/ruby/gems/2.6.0/gems/thor-0.20.3/lib/thor/command.rb:27:in `run'
	14: from /opt/inspec/embedded/lib/ruby/gems/2.6.0/gems/thor-0.20.3/lib/thor.rb:238:in `block in subcommand'
	13: from /opt/inspec/embedded/lib/ruby/gems/2.6.0/gems/thor-0.20.3/lib/thor/invocation.rb:115:in `invoke'
	12: from /opt/inspec/embedded/lib/ruby/gems/2.6.0/gems/thor-0.20.3/lib/thor.rb:387:in `dispatch'
	11: from /opt/inspec/embedded/lib/ruby/gems/2.6.0/gems/thor-0.20.3/lib/thor/invocation.rb:126:in `invoke_command'
	10: from /opt/inspec/embedded/lib/ruby/gems/2.6.0/gems/thor-0.20.3/lib/thor/command.rb:27:in `run'
	 9: from /opt/inspec/embedded/lib/ruby/gems/2.6.0/gems/inspec-4.7.3/lib/plugins/inspec-plugin-manager-cli/lib/inspec-plugin-manager-cli/cli_command.rb:100:in `install'
	 8: from /opt/inspec/embedded/lib/ruby/gems/2.6.0/gems/inspec-4.7.3/lib/plugins/inspec-plugin-manager-cli/lib/inspec-plugin-manager-cli/cli_command.rb:322:in `install_from_remote_gem'
	 7: from /opt/inspec/embedded/lib/ruby/gems/2.6.0/gems/inspec-4.7.3/lib/plugins/inspec-plugin-manager-cli/lib/inspec-plugin-manager-cli/cli_command.rb:364:in `install_attempt_install'
	 6: from /opt/inspec/embedded/lib/ruby/gems/2.6.0/gems/inspec-4.7.3/lib/inspec/plugin/v2/installer.rb:70:in `install'
	 5: from /opt/inspec/embedded/lib/ruby/gems/2.6.0/gems/inspec-4.7.3/lib/inspec/plugin/v2/installer.rb:282:in `install_from_remote_gems'
	 4: from /opt/inspec/embedded/lib/ruby/gems/2.6.0/gems/inspec-4.7.3/lib/inspec/plugin/v2/installer.rb:317:in `install_gem_to_plugins_dir'
	 3: from /opt/inspec/embedded/lib/ruby/gems/2.6.0/gems/inspec-4.7.3/lib/inspec/plugin/v2/installer.rb:317:in `each'
	 2: from /opt/inspec/embedded/lib/ruby/gems/2.6.0/gems/inspec-4.7.3/lib/inspec/plugin/v2/installer.rb:319:in `block in install_gem_to_plugins_dir'
	 1: from /opt/inspec/embedded/lib/ruby/2.6.0/rubygems/specification.rb:1414:in `activate'
/opt/inspec/embedded/lib/ruby/2.6.0/rubygems/specification.rb:2292:in `check_version_conflict': can't activate net-scp-1.2.1, already activated net-scp-2.0.0 (Gem::LoadError)
	19: from /usr/local/bin/inspec:181:in `<main>'
	18: from /usr/local/bin/inspec:181:in `load'
	17: from /opt/inspec/embedded/lib/ruby/gems/2.6.0/gems/inspec-bin-4.7.3/bin/inspec:11:in `<top (required)>'
	16: from /opt/inspec/embedded/lib/ruby/gems/2.6.0/gems/inspec-4.7.3/lib/inspec/base_cli.rb:31:in `start'
	15: from /opt/inspec/embedded/lib/ruby/gems/2.6.0/gems/thor-0.20.3/lib/thor/base.rb:466:in `start'
	14: from /opt/inspec/embedded/lib/ruby/gems/2.6.0/gems/thor-0.20.3/lib/thor.rb:387:in `dispatch'
	13: from /opt/inspec/embedded/lib/ruby/gems/2.6.0/gems/thor-0.20.3/lib/thor/invocation.rb:126:in `invoke_command'
	12: from /opt/inspec/embedded/lib/ruby/gems/2.6.0/gems/thor-0.20.3/lib/thor/command.rb:27:in `run'
	11: from /opt/inspec/embedded/lib/ruby/gems/2.6.0/gems/thor-0.20.3/lib/thor.rb:238:in `block in subcommand'
	10: from /opt/inspec/embedded/lib/ruby/gems/2.6.0/gems/thor-0.20.3/lib/thor/invocation.rb:115:in `invoke'
	 9: from /opt/inspec/embedded/lib/ruby/gems/2.6.0/gems/thor-0.20.3/lib/thor.rb:387:in `dispatch'
	 8: from /opt/inspec/embedded/lib/ruby/gems/2.6.0/gems/thor-0.20.3/lib/thor/invocation.rb:126:in `invoke_command'
	 7: from /opt/inspec/embedded/lib/ruby/gems/2.6.0/gems/thor-0.20.3/lib/thor/command.rb:27:in `run'
	 6: from /opt/inspec/embedded/lib/ruby/gems/2.6.0/gems/inspec-4.7.3/lib/plugins/inspec-plugin-manager-cli/lib/inspec-plugin-manager-cli/cli_command.rb:100:in `install'
	 5: from /opt/inspec/embedded/lib/ruby/gems/2.6.0/gems/inspec-4.7.3/lib/plugins/inspec-plugin-manager-cli/lib/inspec-plugin-manager-cli/cli_command.rb:322:in `install_from_remote_gem'
	 4: from /opt/inspec/embedded/lib/ruby/gems/2.6.0/gems/inspec-4.7.3/lib/plugins/inspec-plugin-manager-cli/lib/inspec-plugin-manager-cli/cli_command.rb:364:in `install_attempt_install'
	 3: from /opt/inspec/embedded/lib/ruby/gems/2.6.0/gems/inspec-4.7.3/lib/inspec/plugin/v2/installer.rb:70:in `install'
	 2: from /opt/inspec/embedded/lib/ruby/gems/2.6.0/gems/inspec-4.7.3/lib/inspec/plugin/v2/installer.rb:282:in `install_from_remote_gems'
	 1: from /opt/inspec/embedded/lib/ruby/gems/2.6.0/gems/inspec-4.7.3/lib/inspec/plugin/v2/installer.rb:316:in `install_gem_to_plugins_dir'
/opt/inspec/embedded/lib/ruby/gems/2.6.0/gems/inspec-4.7.3/lib/inspec/plugin/v2/installer.rb:325:in `rescue in install_gem_to_plugins_dir': can't activate net-scp-1.2.1, already activated net-scp-2.0.0 (Inspec::Plugin::V2::InstallError)

could you retry with an explicit version i.e. inspec plugin install -v 0.6.0 inspec-iggy ?

Hi @clavery-chef just tested this and the installation works all OK, i have done some general patching on my machine so will post the latest versions of MacOS and inspec i have running on the machine
OS: MacOS 10.14.6
Inspec: 4.12.0
inspec plugin install -v 0.6.0 inspec-iggy
Fetching inspec-iggy-0.6.0.gem
inspec-iggy plugin, version 0.6.0, installed from rubygems.org%

Im guessing the Inspec plugin install doesn't like installing without a version its a n open issue/fr - https://github.com/inspec/inspec/issues/4296, feel free to add your +1

Closing.
mattray@clamps[13:11]2.6.5(master*)~
$ inspec plugin install inspec-iggy
Fetching inspec-iggy-0.7.0.gem
inspec-iggy plugin, version 0.7.0, installed from rubygems.org
mattray@clamps[13:12]2.6.5(master*)~
$ inspec iggy version
Iggy v0.7.0

Hi ,
I'm trying to install inspec-iggy and i get the below error, can anyone please help me on this as i can see the same error in this issue and its closed.I'm using inspec 4.18.51
$ inspec version
4.18.51
inspec plugin install inspec-iggy --log-level=debug
[2020-02-03T11:19:30+00:00] DEBUG: PluginLoader: refusing to re-register plugin 'inspec-supermarket': an existing plugin with that name was loaded via bundle-loading from /opt/chefdk/embedded/lib/ruby/gems/2.6.0/gems/inspec-4.18.51/lib/bundles/inspec-supermarket.rb
[2020-02-03T11:19:30+00:00] DEBUG: PluginLoader: refusing to re-register plugin 'inspec-plugin-manager-cli': an existing plugin with that name was loaded via core-loading from /opt/chefdk/embedded/lib/ruby/gems/2.6.0/gems/inspec-4.18.51/lib/plugins/inspec-plugin-manager-cli/lib/inspec-plugin-manager-cli.rb
[2020-02-03T11:19:30+00:00] DEBUG: PluginLoader: refusing to re-register plugin 'inspec-artifact': an existing plugin with that name was loaded via core-loading from /opt/chefdk/embedded/lib/ruby/gems/2.6.0/gems/inspec-4.18.51/lib/plugins/inspec-artifact/lib/inspec-artifact.rb
[2020-02-03T11:19:30+00:00] DEBUG: PluginLoader: refusing to re-register plugin 'inspec-habitat': an existing plugin with that name was loaded via core-loading from /opt/chefdk/embedded/lib/ruby/gems/2.6.0/gems/inspec-4.18.51/lib/plugins/inspec-habitat/lib/inspec-habitat.rb
[2020-02-03T11:19:30+00:00] DEBUG: PluginLoader: refusing to re-register plugin 'inspec-init': an existing plugin with that name was loaded via core-loading from /opt/chefdk/embedded/lib/ruby/gems/2.6.0/gems/inspec-4.18.51/lib/plugins/inspec-init/lib/inspec-init.rb
[2020-02-03T11:19:30+00:00] DEBUG: PluginLoader: refusing to re-register plugin 'inspec-compliance': an existing plugin with that name was loaded via core-loading from /opt/chefdk/embedded/lib/ruby/gems/2.6.0/gems/inspec-4.18.51/lib/plugins/inspec-compliance/lib/inspec-compliance.rb
[2020-02-03T11:19:30+00:00] DEBUG: PluginLoader: refusing to re-register plugin 'train-habitat': an existing plugin with that name was loaded via system_gem-loading from train-habitat
[2020-02-03T11:19:30+00:00] DEBUG: PluginLoader: refusing to re-register plugin 'train-aws': an existing plugin with that name was loaded via system_gem-loading from train-aws
[2020-02-03T11:19:30+00:00] DEBUG: PluginLoader: refusing to re-register plugin 'train-winrm': an existing plugin with that name was loaded via system_gem-loading from train-winrm
Traceback (most recent call last):
22: from /usr/local/bin/inspec:349:in <main>'         21: from /usr/local/bin/inspec:349:in load'
20: from /opt/chefdk/embedded/lib/ruby/gems/2.6.0/gems/inspec-bin-4.18.51/bin/inspec:11:in <top (required)>'         19: from /opt/chefdk/embedded/lib/ruby/gems/2.6.0/gems/inspec-4.18.51/lib/inspec/base_cli.rb:35:in start'
18: from /opt/chefdk/embedded/lib/ruby/gems/2.6.0/gems/thor-0.20.3/lib/thor/base.rb:466:in start'         17: from /opt/chefdk/embedded/lib/ruby/gems/2.6.0/gems/thor-0.20.3/lib/thor.rb:387:in dispatch'
16: from /opt/chefdk/embedded/lib/ruby/gems/2.6.0/gems/thor-0.20.3/lib/thor/invocation.rb:126:in invoke_command'         15: from /opt/chefdk/embedded/lib/ruby/gems/2.6.0/gems/thor-0.20.3/lib/thor/command.rb:27:in run'
14: from /opt/chefdk/embedded/lib/ruby/gems/2.6.0/gems/thor-0.20.3/lib/thor.rb:238:in block in subcommand'         13: from /opt/chefdk/embedded/lib/ruby/gems/2.6.0/gems/thor-0.20.3/lib/thor/invocation.rb:115:in invoke'
12: from /opt/chefdk/embedded/lib/ruby/gems/2.6.0/gems/thor-0.20.3/lib/thor.rb:387:in dispatch'         11: from /opt/chefdk/embedded/lib/ruby/gems/2.6.0/gems/thor-0.20.3/lib/thor/invocation.rb:126:in invoke_command'
10: from /opt/chefdk/embedded/lib/ruby/gems/2.6.0/gems/thor-0.20.3/lib/thor/command.rb:27:in run'          9: from /opt/chefdk/embedded/lib/ruby/gems/2.6.0/gems/inspec-4.18.51/lib/plugins/inspec-plugin-manager-cli/lib/inspec-plugin-manager-cli/cli_command.rb:121:in install'
8: from /opt/chefdk/embedded/lib/ruby/gems/2.6.0/gems/inspec-4.18.51/lib/plugins/inspec-plugin-manager-cli/lib/inspec-plugin-manager-cli/cli_command.rb:362:in install_from_remote_gem'          7: from /opt/chefdk/embedded/lib/ruby/gems/2.6.0/gems/inspec-4.18.51/lib/plugins/inspec-plugin-manager-cli/lib/inspec-plugin-manager-cli/cli_command.rb:410:in install_attempt_install'
6: from /opt/chefdk/embedded/lib/ruby/gems/2.6.0/gems/inspec-4.18.51/lib/inspec/plugin/v2/installer.rb:70:in install'          5: from /opt/chefdk/embedded/lib/ruby/gems/2.6.0/gems/inspec-4.18.51/lib/inspec/plugin/v2/installer.rb:288:in install_from_remote_gems'
4: from /opt/chefdk/embedded/lib/ruby/gems/2.6.0/gems/inspec-4.18.51/lib/inspec/plugin/v2/installer.rb:324:in install_gem_to_plugins_dir'          3: from /opt/chefdk/embedded/lib/ruby/gems/2.6.0/gems/inspec-4.18.51/lib/inspec/plugin/v2/installer.rb:324:in each'
2: from /opt/chefdk/embedded/lib/ruby/gems/2.6.0/gems/inspec-4.18.51/lib/inspec/plugin/v2/installer.rb:326:in block in install_gem_to_plugins_dir'          1: from /opt/chefdk/embedded/lib/ruby/2.6.0/rubygems/specification.rb:1414:in activate'
/opt/chefdk/embedded/lib/ruby/2.6.0/rubygems/specification.rb:2292:in check_version_conflict': can't activate minitest-5.11.3, already activated minitest-5.10.3 (Gem::LoadError)         19: from /usr/local/bin/inspec:349:in '
18: from /usr/local/bin/inspec:349:in load'         17: from /opt/chefdk/embedded/lib/ruby/gems/2.6.0/gems/inspec-bin-4.18.51/bin/inspec:11:in <top (required)>'
16: from /opt/chefdk/embedded/lib/ruby/gems/2.6.0/gems/inspec-4.18.51/lib/inspec/base_cli.rb:35:in start'         15: from /opt/chefdk/embedded/lib/ruby/gems/2.6.0/gems/thor-0.20.3/lib/thor/base.rb:466:in start'
14: from /opt/chefdk/embedded/lib/ruby/gems/2.6.0/gems/thor-0.20.3/lib/thor.rb:387:in dispatch'         13: from /opt/chefdk/embedded/lib/ruby/gems/2.6.0/gems/thor-0.20.3/lib/thor/invocation.rb:126:in invoke_command'
12: from /opt/chefdk/embedded/lib/ruby/gems/2.6.0/gems/thor-0.20.3/lib/thor/command.rb:27:in run'         11: from /opt/chefdk/embedded/lib/ruby/gems/2.6.0/gems/thor-0.20.3/lib/thor.rb:238:in block in subcommand'
10: from /opt/chefdk/embedded/lib/ruby/gems/2.6.0/gems/thor-0.20.3/lib/thor/invocation.rb:115:in invoke'          9: from /opt/chefdk/embedded/lib/ruby/gems/2.6.0/gems/thor-0.20.3/lib/thor.rb:387:in dispatch'
8: from /opt/chefdk/embedded/lib/ruby/gems/2.6.0/gems/thor-0.20.3/lib/thor/invocation.rb:126:in invoke_command'          7: from /opt/chefdk/embedded/lib/ruby/gems/2.6.0/gems/thor-0.20.3/lib/thor/command.rb:27:in run'
6: from /opt/chefdk/embedded/lib/ruby/gems/2.6.0/gems/inspec-4.18.51/lib/plugins/inspec-plugin-manager-cli/lib/inspec-plugin-manager-cli/cli_command.rb:121:in install'          5: from /opt/chefdk/embedded/lib/ruby/gems/2.6.0/gems/inspec-4.18.51/lib/plugins/inspec-plugin-manager-cli/lib/inspec-plugin-manager-cli/cli_command.rb:362:in install_from_remote_gem'
4: from /opt/chefdk/embedded/lib/ruby/gems/2.6.0/gems/inspec-4.18.51/lib/plugins/inspec-plugin-manager-cli/lib/inspec-plugin-manager-cli/cli_command.rb:410:in install_attempt_install'          3: from /opt/chefdk/embedded/lib/ruby/gems/2.6.0/gems/inspec-4.18.51/lib/inspec/plugin/v2/installer.rb:70:in install'
2: from /opt/chefdk/embedded/lib/ruby/gems/2.6.0/gems/inspec-4.18.51/lib/inspec/plugin/v2/installer.rb:288:in install_from_remote_gems'          1: from /opt/chefdk/embedded/lib/ruby/gems/2.6.0/gems/inspec-4.18.51/lib/inspec/plugin/v2/installer.rb:323:in install_gem_to_plugins_dir'
/opt/chefdk/embedded/lib/ruby/gems/2.6.0/gems/inspec-4.18.51/lib/inspec/plugin/v2/installer.rb:332:in `rescue in install_gem_to_plugins_dir': can't activate minitest-5.11.3, already activated minitest-5.10.3 (Inspec::Plugin::V2::InstallError)


New style labels

Make sure we supply both old-style and new-style tags
The only exception is when old-style tag is in base image - we should set new-style only in this case

Coverage decreased (-0.004%) to 87.717% when pulling 91474030a7f106b84653db4268178e950eec687b on vrutkovs:new-style-labels into 9f2b77b516c2b23bab05491b105848f663b5d3f6 on projectatomic:master.

Coverage decreased (-0.004%) to 87.717% when pulling 64ae7eed1d39805c22fee6d98a901ec2f0560a81 on vrutkovs:new-style-labels into 9f2b77b516c2b23bab05491b105848f663b5d3f6 on projectatomic:master.

Coverage decreased (-0.004%) to 87.717% when pulling 64ae7eed1d39805c22fee6d98a901ec2f0560a81 on vrutkovs:new-style-labels into 9f2b77b516c2b23bab05491b105848f663b5d3f6 on projectatomic:master.

Coverage decreased (-0.004%) to 87.717% when pulling 648789cc668d6296426f8cf76e1d393514ae4294 on vrutkovs:new-style-labels into 9f2b77b516c2b23bab05491b105848f663b5d3f6 on projectatomic:master.

@twaugh, right, rewrote the commit message, I hope it makes sense now

Coverage decreased (-0.004%) to 87.717% when pulling 82ff692f1049438458148923a5de8ca4064be3b0 on vrutkovs:new-style-labels into 9f2b77b516c2b23bab05491b105848f663b5d3f6 on projectatomic:master.

Renamed the var to 'is_old_inherited'

Coverage decreased (-0.004%) to 87.717% when pulling 1af44373474d71731c2b48f507f2cd16803a4f2b on vrutkovs:new-style-labels into 9f2b77b516c2b23bab05491b105848f663b5d3f6 on projectatomic:master.

LGTM, thanks.

@lcarva, want to take a look before this gets merged?

Oh, thought of something else we should do before merging.

Any places in atomic-reactor that assume the labels 'Name', 'Version', 'Release', 'BZComponent' etc are present should be changed to look for 'name', 'version', 'release', 'com.redhat.component' etc.

Right, lets include this here, working on it

[ ] tag_by_labels
[ ] tag_from_config
[ ] add_dockerfile (comments and error message only I think)
[ ] assert_labels
[ ] docs/plugins.md

Coverage increased (+0.01%) to 87.733% when pulling a514ee607a255a1adb556b44de2b3d2e09d3b5e6 on vrutkovs:new-style-labels into 9f2b77b516c2b23bab05491b105848f663b5d3f6 on projectatomic:master.

Coverage increased (+0.01%) to 87.733% when pulling 425b515550d206c3ab0c1ca7dbdff005b9324cfd on vrutkovs:new-style-labels into 9f2b77b516c2b23bab05491b105848f663b5d3f6 on projectatomic:master.

This just in -- we should use 'authoritative-source-url' and not 'authoritative-source'. It seems 'authoritative-source' may have been a mistake in the specification.
See https://github.com/projectatomic/ContainerApplicationGenericLabels/pull/74

we should use 'authoritative-source-url' and not 'authoritative-source'

Right, that's a typo, replaced it

Coverage decreased (-4.0%) to 83.74% when pulling 3136240c6602e234d747301c044041269f25ada9 on vrutkovs:new-style-labels into 9f2b77b516c2b23bab05491b105848f663b5d3f6 on projectatomic:master.

Coverage increased (+0.01%) to 87.733% when pulling bcbdda8b8ee647dd3c5abfd2c93fd0a812470587 on vrutkovs:new-style-labels into 9f2b77b516c2b23bab05491b105848f663b5d3f6 on projectatomic:master.


add kafka workflow

Checklist

[ ] run npm run test and npm run benchmark
[ ] tests and/or benchmarks are included
[ ] documentation is changed or added
[ ] commit message and code follows the Developer's Certification of Origin
and the Code of conduct

Why are we adding this here even if it's just for a single plugin?

I feel like this is a good place to centralize service-related workflows
For instance, if I ever need to look for a specific workflow (like kafka), I might forget which plugin uses it and just check here


Dualshock4

Initial support for the DualShock 4 controller
The DualShock 4 controller is now supported as one of the valid tracked controller types. All buttons and rumble states are accessible to the client (including steamvr plugin). The tracking is still in pretty rough early state. The 'ControllerPositionEstimation ' struct has been replaced with a 'ControllerOpticalPoseEstimation' since the optical pose estimate can now compute the orientation of the tracking shape (if it's the new "lightbar" tracking shape). There is a new framework in place for blending between optical tracking and IMU tracking using an optical tracking metric (see issue #72). This will get rolled into the Kalman filter work in some form or another.
I'll post a video with more details about all the work that went into these changes later tonight.

I did a bunch of testing (testing multiple controllers, new calibration tools, tracker calibration, etc) to make sure I didn't break any existing psmove controller support. I need to merge this into master so that I can start the integration of these changes into the CAPI branch tomorrow.
Also the explanation video for this PR is going to take me another night to finish. I'll post a link to that in here when I finish here for reference.

@HipsterSloth We all know how difficult it is to estimate a work flow and I for one am very impressed by your progress!
I managed to build this (using msvs 2015) and have some thoughts if you like:

I was caught out by the new OpenCV implementation. Building took so long for me because my dl speed is only 3.4 Mbps. Could some kind of progress bar be added so that you know it's downloading and hasn't just crashed? I used the task manger to check my network usage so I knew it was still downloading.
I noticed the colour calibration for the DS4 needs different values than the PSMove (at least in my set up). I wondered if two sets of colour information could be saved.
The only time the Steam controller model showed in SteamVR it was representing one of the PSMove controllers. The DS4 never had a model (verified by seeing nothing at the end of the laser pointer).
The new accelerometer calibration works but nothing happens in the test screens for either the DS4 or the PSMoves.
To make navigating the the calibration tool easier would it be possible to always show the next and previous buttons and after editing a setting for a specific controller or tracker can the screen return to that device's subscreen?
Finally I noticed the lag during the tracker pose calibration some people have mentioned and it was because the CPU usage was very high. Luckily for me I could just stop something that I normally have running that used about 20%. Do these latest changes require more CPU power (like the DS4 tracking perhaps)?

I hope some of these thoughts might help.
(attached my build if anyone else wants a go)
PSMS-6ca7793.7z.001.zip
PSMS-6ca7793.7z.002.zip

@zelmon64 Thanks for slogging through the setup process and giving this a test! Responses inline:

Building took so long for me because my dl speed is only 3.4 Mbps. Could some kind of progress bar be added so that you know it's downloading and hasn't just crashed?

Sorry about that. Getting OpenCV compiling with MSVC 2015 has been a painful transition. In OpenCV3.1 the binary installer no longer has the pieces we need to build psmove service in the configurations we want. This meant having to download and build opencv from source. In the past this required the user to manually pull down OpenCV into the right place and build it yourself. We didn't want to go back to that, so we decided to give cmake's External Project command a try as part of the build scripts. That command will auto-download and compile OpenCV as part of the PSMoveService project's build. I assume you saw the same output when building OpenCV?
2>------ Build started: Project: opencv (ExternalProjectTargets\opencv\opencv), Configuration: Debug x64 ------
2>  Building Custom Rule C:/cboulay-git/PSMoveService_master/CMakeLists.txt
2>  CMake does not need to re-run because C:\cboulay-git\PSMoveService_master\build\CMakeFiles\generate.stamp is up-to-date.
2>  Creating directories for 'opencv'
2>  Performing download step (git clone) for 'opencv'
2>  Cloning into 'opencv'...
   <long wait>
2>  Checking out files:   8% (387/4792)
2>  Checking out files:   9% (432/4792)
...

Unfortunately, there is no option I could find for the external project command that display download progress for the git download. There is a 'LOG_DOWNLOAD 1' option but it doesn't appear to do anything when set :/. There might some way to accomplish the download step with a custom build step, but my cmake kung-fu is weak.

The DS4 never had a model (verified by seeing nothing at the end of the laser pointer).

Who has two thumbs and forgot to check in dualshock4_controller.obj?

I keep forgetting that .obj is in the .gitignore list.

I noticed the colour calibration for the DS4 needs different values than the PSMove (at least in my set up). I wondered if two sets of colour information could be saved.

Yeah I noticed that yesterday too when testing having both DS4 and PSMoves at the same time that the yellow color I calibrated on the PSMove didn't work for the DS4 tracking. We absolutely could save an alternate set of color configs per controller. I hadn't bothered with it yet because the use case we have here at work will only be using the ds4 controller, but that does need to get fixed before people can broadly use this. I'll try to get to that before the end of the week. It's not a hard change fortunately (mostly just some UI and plumbing).

The new accelerometer calibration works but nothing happens in the test screens for either the DS4 or the PSMoves.

Sorry I should have talked about how this works in the release notes. The PSMove won't give any valid linear acceleration data back at the moment (intentionally zero'd out) until the the Kalman filter is done. The linear acceleration I was computing before was too noisy. As for the DS4, you will only see the linear acceleration show up once the camera has seen the light bar at least once. This is an odd quirk of how I have positional filter operating. This will also get fixed as I continue to work on the DS4.

To make navigating the the calibration tool easier would it be possible to always show the next and previous buttons and after editing a setting for a specific controller or tracker can the screen return to that device's subscreen?

Absolutely. That was driving me crazy yesterday too. I'll fix that now.

Do these latest changes require more CPU power (like the DS4 tracking perhaps)?

Yeah I think my usage of cv::SolvePnP to get the ds4 pose isn't cheap (doing an iterative solve of a non-linear optimization problem). I have another approach I want to try when using multicam that will allow me to use triangulation to solve the pose instead of SolvePnP. It should definitely be cheaper and hopefully more reliable. The single camera case will still have to use SolvePnP, but hopefully because one is only using one camera in that case the perf hit won't be so bad.
Also the CPU should should only happen when using the DS4. There shouldn't be any new perf hit if you are just using the PSMove. But if there is an unexpected perf hit, I'd love to know.
This was very helpful. Thanks a bunch for trying this out and writing this up! I'm going to continue working on DS4 tracking over the next week or two. Hopefully I can get it to a somewhat usable state. I'll take care of the simple stuff today and then make an official release tomorrow along with the video.

That command will auto-download and compile OpenCV as part of the PSMoveService project's build.

In the external project you can override the DOWNLOAD_COMMAND and use git clone --depth 1 so the OpenCV download is much smaller.

Oh, even better, you can just add GIT_SHALLOW 1 without overriding the download_command. This is a fairly new feature... trying to find the version now...

Looks like 3.6. Giving that a try now...

It looks like it worked? I deleted cmake and grabbed cmake 3.6.1, then cleared out the /deps folder and the /build folder. I didn't see any change in output, but I think it downloaded a bit faster for me? My download is pretty quick for me, so it's hard to tell.

I just checked in fixes for the open cv build thing, adding the missing controller model, remembering which controller/tracker you had selected when switching between menus, and finally the per controller color filter settings (see Issue #95). I did some initial testing on the per controller filtering, but it's possible I missed some edge cases so let me know if you run into any issues or have feedback on the implementation. I'll hold back on pushing a release out until that get's tested by someone else since I don't want to ship broken color filter tools.

Part 1 of the video explaining this changes is up:

For @cboulay most of the stuff in part 1 is stuff you already know very well, but gives context for part 2 that I'm going to finish tomorrow. This video covers motivation for doing this work, differences between tracking the PSMove and the DualShock4, and trying to calibrate the accelerometer values. Part 2/2 will cover calibrating the gyroscope, extracting the optical pose of the controller, showing the tracking progress so far in steamvr and the future work I have planned.
Let me know if you guys have any questions or corrections for the video.

@HipsterSloth I updated to cmake 3.6.1 and had a ago.

The config tool menu is so much more convenient to navigate thanks.
OpenCV didn't seem any quicker but it may be because I didn't actually time it for comparison.
I started off with unpaired controllers to fully test it. Pairing the PSMoves was a cinch but the DS4 didn't work (but there's no problem pairing that with the native tool).
I started by checking the controllers' orientation and the DS4 kept crashing during the gyro test DS4 gyro break.txt. This happens randomly but after only a few seconds. The error spews into the log and is only stopped by closing the config tool. I couldn't find where the log was getting saved to (another bug?) so I just copied it.
All the models seemed fine in SteamVR now (the laser shoots out of the bottom of the DS4?).
I have to get closer to my cameras to get the DS4 recognised. I don't think it's a bug, just something to note because the light bar is smaller and thin so it gets aliased with the low resolution.

I think that's everything.
Again here's a copy for any one else (the build size is much smaller now for some reason)
PSMS-4cef4b1.7z.txt

@zelmon64 Thanks again for your comprehensive testing and write-up! It's much appreciated.

I started off with unpaired controllers to fully test it. Pairing the PSMoves was a cinch but the DS4 didn't work (but there's no problem pairing that with the native tool).

Yeah the pairing for the DS4 is not great (and by not great I mean terrible). It worked for me BUT it required many attempts (retrying for a minute sometimes) to get it to take. Getting pairing in Windows seems to be a timing sensitive operation per device type. I'm currently using the same pairing timings as the PSMove. Which native pairing tool are you using? I should take a look at that and see what I can learn.

I started by checking the controllers' orientation and the DS4 kept crashing during the gyro test

Whoops. Good catch. Looks like I'm putting too much data in the UDP controller packet when using that test tool. I need to either cut down what I'm sending or increase the UDP packet size (currently 500 bytes). I'll try and fix that today since that's likely a pretty easy tweak.

I couldn't find where the log was getting saved to (another bug?) so I just copied it.

I recently had to rip out my usage of boost logging (OS X build problem, see end of issue #35) and replace it with my own simpler implementation. My simpler implementation doesn't have logging to file yet. I actually want to completely redo how we handle logging. We current use iostream style logging (as compared to printf style logging). It's hard to make iostream style logging multi-threaded safe, so I would rather just redo it all as printf style logging. But that's a big undertaking and I wanted to get the other filtering stuff done first. Unfortunately that means people have to copy out of the log window for now, which is a bummer.

(the laser shoots out of the bottom of the DS4?).

Hmm. I'm rotating the DS4 model 90 degrees in the steamvr plugin to get the controller model to line correctly with the orientation the service is providing. Maybe I should do that rotation somewhere else. I'll have to think about where the best place to do that rotation is (maybe in the source model?).

I have to get closer to my cameras to get the DS4 recognised. I don't think it's a bug, just something to note because the light bar is smaller and thin so it gets aliased with the low resolution.

Yeah that 's definitely the issue with the DS4 and why Sony had to upgrade to the PS4 Camera to get a consumer friendly tracking range. I'm hoping a combination of a recenter button and better IMU filtering (with the Kalman filter) will help with that somewhat. Once the filter work is in a good place I'm going to look back into supporting higher resolution cameras.
Do you know of any HD webcams that can update at 60hz btw? The Logitech C920 used to support that, but then they started hardware locking that feature. It seems like it's hard to find a reasonably priced HD camera that can update at 60hz.

Yeah the pairing for the DS4 is not great (and by not great I mean terrible). It worked for me BUT it required many attempts (retrying for a minute sometimes) to get it to take. Getting pairing in Windows seems to be a timing sensitive operation per device type. I'm currently using the same pairing timings as the PSMove. Which native pairing tool are you using? I should take a look at that and see what I can learn.

I'm just using the basic Windows 10 Bluetooth settings connecting tool. I'm wondering if you're missing the part about putting the DS4 into pairing mode by holding the share button when you turn it on with the PS button. When I use that I can reliably reconnect it to different computers.

Hmm. I'm rotating the DS4 model 90 degrees in the steamvr plugin to get the controller model to line correctly with the orientation the service is providing. Maybe I should do that rotation somewhere else. I'll have to think about where the best place to do that rotation is (maybe in the source model?).

Just to clarify, I would expect the laser to shoot out from the light bar but instead it's coming from whre the bar code is.

Do you know of any HD webcams that can update at 60hz btw? The Logitech C920 used to support that, but then they started hardware locking that feature. It seems like it's hard to find a reasonably priced HD camera that can update at 60hz.

That's a bummer about the C920, that's my favourite webcam (and the only one I own apart from the PSEye). The only one I can think of is the Logitech Quickcam 9000 Pro Doc_Ok used in that tracking video but again I think it's limit is 30Hz. I'll keep an eye out.

EDIT: I just tried running the "test orientation" on the DS4 controller but I couldn't repro the issue here at work. If you look in PSMoveControllerInterface.h is MAX_OUTPUT_DATA_FRAME_MESSAGE_SIZE set to 500 for you? Also have you run a clean build? I'll try a a fresh build at home and see if the issue repros there. Also if you change MAX_OUTPUT_DATA_FRAME_MESSAGE_SIZE to something larger (like 600?) does that fix it for you?

I did the same git instructions for a fresh build you gave me last time (minus the hacks) and followed the build from scratch wiki. The value in PSMoveProtocolInterface.h  was set to 500 so I changed it to 600 and rebuilt. The crashing did not happen again but no controller would remain lit. I then returned to 500 and the lights returned to normal but the crash did not reoccur (I don't know why).

Part 1 of the video explaining this changes is up:

I'm just using the basic Windows 10 Bluetooth settings connecting tool. I'm wondering if you're missing the part about putting the DS4 into pairing mode by holding the share button when you turn it on with the PS button. When I use that I can reliably reconnect it to different computers.

Oh! I have never tried holding the share button. I will try that next time.

Turns out the DS4 gyro test is only crashing when only the DS4 is connected.

Interesting. I'll give that test case a try tomorrow.
Also I have part 2 of the DS4 video up.

@cboulay This video goes into the details of the current optical pose extraction for the ds4 and the IMU blending. I'd love any feedback you have on this, especially if anything sticks out about how to best proceed with making the DS4 UKF model.

@HipsterSloth I saw you said you are holding off the release because of the DS4 gyro crashing. Have you been able to recreate it? Should I run some more tests?  Related to this, I'm curious if the DS4 pairing mode made any difference for you?

@zelmon64 I have not repro'd that crash yet, but I haven't really investigated too much. Haven't tried the pairing tests either. I was pretty much head down working on kalman filter stuff all thu/fri. I'd actually be curious if you get any gyro crash with just using the psmove. If not I might put out a release with the new code since it has a few new fixes in it. Until the Kalman filter work is done the ds4 isn't officially supported anyway (since the tracking is really usable yet).

@HipsterSloth That's very fair - I'm really looking forward to the Kalman filter!
I haven't had any gyro crashes with the psmoves. So far the DS4 only crashes during the guro test if it is detected as the first or second controller. It does not seem to crash if it is the third (yellow).
When I started this round of tests I had only one psmove connected and it had the Steam Controller model. What is interesting is that the laser was coming out where it should (the top instead of the back).  This model swap seems to only happen on the first run but I can't say for sure.


Cannot install docker-ce on ubuntu 16.04

sudo add-apt-repository
"deb [arch=amd64] https://download.docker.com/linux/$(. /etc/os-release; echo "$ID")
$(lsb_release -cs)
stable"
This leads to:
aptsources.distro.NoDistroTemplateException: Error: could not find a distribution template for Ubuntu/xenial

It seems the command is using differs a bit from what is presented on the install docs, specifically this part

Have you tried using this ^^ instead?

Yes Joao,
I keep getting the following error, also when following the official guide:
sudo add-apt-repository    "deb [arch=amd64] https://download.docker.com/linux/ubuntu \
   $(lsb_release -cs) \
   stable"
Traceback (most recent call last):
  File "/usr/bin/add-apt-repository", line 95, in <module>
    sp = SoftwareProperties(options=options)
  File "/usr/lib/python3/dist-packages/softwareproperties/SoftwareProperties.py", line 114, in __init__
    self.reload_sourceslist()
  File "/usr/lib/python3/dist-packages/softwareproperties/SoftwareProperties.py", line 607, in reload_sourceslist
    self.distro.get_sources(self.sourceslist)
  File "/usr/lib/python3/dist-packages/aptsources/distro.py", line 89, in get_sources
    (self.id, self.codename))
aptsources.distro.NoDistroTemplateException: Error: could not find a distribution template for Ubuntu/xenial

I've tested the install procedure on a Ubuntu 16.04 and everything seems to work.
Searching around I think the problem might with the way your machine is configured.
To troubleshoot this try apt-get install some package and see if fails. If it fails, the problem is with your config and not with the Docker docs, in which case you can try to use the article above to fix your problem.

It worked after I did a apt-get upgrade. Must have been some old module. Thanks Joao!

Glad I was able to help 🙌

If someone has issues with installation on Ubuntu I created copy/paste cheat-sheet link


[Test@Oracle] - PartitionIDSpec shouldIncludePartitionColumnsIntoUPDATEAndDELETE

Hi @ipolevoy
I've been attempting to integrate Oracle with our current TravisCI setup, but, during the process, I've noticed there are at couple of tests failing:
This seems to be failing because of the use of reserved keywords in the schema. For instance:
org.javalite.activejdbc.DBException:
java.sql.SQLSyntaxErrorException: ORA-00928: missing SELECT keyword
, query: INSERT INTO passengers (mode, user_id, vehicle) VALUES (?, ?, ?), params: pavement, 1, bike
	at org.javalite.activejdbc.PartitionIDSpec.shouldIncludePartitionColumnsIntoUPDATEAndDELETE(PartitionIDSpec.java:21)

I've attempted to run the queries:
⚠ INSERT INTO passengers (mode, user_id, vehicle) VALUES ( 'pavement', 1, 'bike') - fails with the same error
✔ INSERT INTO passengers ("mode", user_id, vehicle) VALUES ( 'pavement', 1, 'bike') - works perfectly
Apparently MODE is an Oracle reserved keyword
How should we handle these cases? Start escaping the column names? Change the schemas do avoid the use of reserved keywords?
Edit: I've decided to break this issue into multiple parts:

https://github.com/javalite/activejdbc/issues/754
https://github.com/javalite/activejdbc/issues/756
https://github.com/javalite/activejdbc/issues/757

@jfcabral I need to setup Oracle on my  dev box to start fixing these. Will try to get them fixed this / next week

Closing since this was fixed by #766


How to use the new version code ,the filefolder of "update"

I have seen the newest updated code, so how to use this?

please comment for this problem. thank you


Using prepared statement with WHERE somecol IN (?) and array argument?

Is it possible to use prepared statement to do something like:
knex.raw('SELECT id FROM users WHERE id IN (?)', [ [1, 2, 3] ])

No, though I'm looking into expanding the capabilities of argument interpolation. I'll consider this case.

Ok thanks.

just curious, why not just do select('id').from('users').whereIn('id', val)?

I think my statement was a bit more complex than that and didn't have time to figure out the right knex methods Thanks for pointing this out though.

Actually - so prepared statements don't convert arrays as you'd want there. Instead what I'm going to look at is creating a standard convention of interpolating values (potentially anything with a toSQL fn), so you could have some helper function on knex wrap the array so it knows to expand into the (?, ?, ?) format.

@tgrlesser Any progress on this? I've run into this problem too.
Is there a temporary work around in the mean time?

@tgriesser
This feature is much needed for postgres functions array_append(), array_replace(), ect.
Is there a work around for passing arrays into knex.raw() ?

Nevermind, you can already do what I wanted...

Any news on this? Or is this already possible?

Ops, wrong button. Anyways this could be probably considered duplicate since there are other issues about how array values are interpreted.

Usecase (Postgres):
const countries = ['NL', 'BE', 'DE'];
knex('destination').select(
    knex.raw(`(CASE
        WHEN "countryCode" IN :countries THEN 'EU'
        ELSE 'WORLD'
    END) AS "region"`, { countries })
).toString();

Result:
select (CASE
        WHEN "countryCode" IN '{"NL","BE","DE"}' THEN 'EU'
        ELSE 'WORLD'
END) AS "region" from "destination"

Expected:
select (CASE
        WHEN "countryCode" IN ('NL','BE','DE') THEN 'EU'
        ELSE 'WORLD'
END) AS "region" from "destination"

Current workaround:
const countries = ['NL', 'BE', 'DE'];
knex('destination').select(
    knex.raw(`(CASE
        WHEN "countryCode" IN (${countries.map(code => `'${code}'`).join(', ')}) THEN 'EU'
        ELSE 'WORLD'
    END) AS "region"`)
).toString();

@edorivai postgres has at least 4 different syntaxes for arrays, so it cannot possibly guess which one you mean.
I think this issue should have proper feature request filed. One way to support this would be to have some wrappers for arrays, which tells to knex how that array should be rendered in query.
Something like:
knex.raw("where in ?", [asList([1,2,3,4])])

would output:
where in (1,2,3,4)

Maybe in your case ANY could work like mentioned here: https://github.com/tgriesser/knex/issues/1537


Adds rehydrate and targetDocument props to Provider

Description
This fixes this issue https://github.com/robinweser/fela/issues/787. We simply add the missing props to the typescript declaration
Packages
List all packages that have been changed.

react-fela
preact-fela

Checklist
Quality Assurance

You can also run yarn run check to run all 4 commands at once.


Logo design

Jakob Sohm designed us a sweet looking logo that I will request from him next week.

This is done, right?

@stefnotch yup!
Let's close it


license of showdown_1.9.0: GPL or BSD?

Hi, my team would like to use the package showdown_1.9.0 and to approve that I've to verify all its licenses (included those of all of the modules included), and to do that I've to analyze its source code.
Now I've noted that the Readme declares it under GPL V2, while the license.txt is BSD.
Could you please clarify what is the license of showdown_1.9.0?
Thanks.

Hi, any news on this?

Sorry for the delay in answering the question. That is, in fact, a mistake. I've checked the code and previous versions are under BSD. I will fix the readme as soon as possible.

Perfect, thanks!

FYI, showdown 2.0.0 is moving to MIT license


Add support for logging to a file (prerequisite for CloudWatch logging).

In order to support CloudWatch logging, this PR allows us to write to a log file in addition to outputting to journalctl. The benefit of which is that we don't have to write a systemd unit just for tailing the journalctl logs and passing them to a file in order for the awslogs agent to send them to CloudWatch.
It's an optional parameter since not everyone is necessarily running on systemd (or want this).

Might it just be better to log directly to cloudwatch logs with something like https://github.com/kdar/logrus-cloudwatchlogs?

Thoughts on https://github.com/buildkite/lifecycled/pull/38 as an alternative @itsdalmo?

Closing in favor of #38 👍


parrot: init at 1.6.0

Description of changes
Added parrot a discord music bot written in rust

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)
[x] 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/)
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.

I removed darwin from platforms because i do not have a darwin system to test with and the build is failing as is

Alright should work on darwin now, lets see what happens with borgo

This pull request has been mentioned on NixOS Discourse. There might be relevant details there:
https://discourse.nixos.org/t/prs-already-reviewed/2617/1075


Using babili with ES2015 transforms and a super class breaks code

With<EMAIL_ADDRESS>and<EMAIL_ADDRESS>the following code breaks:
class AClass extends SomeClass {
    constructor() {
        super("some arg");
        this.func(this.val = "some value");
        this.val.someProperty = "some value";
    }
}

This seems to be related to the super call, as without it (and the extends SomeClass) everything is fine.
Here's a gist with the two different files I gave to Babel, and the output: https://gist.github.com/kenzierocks/4e198af6c75f359dc6ffffcfc62b1861
My .babelrc:
{ "presets": ["es2015","babili"] }

Related #189 (probably).

Also, sending passPerPreset: true works.
Anyway, I will debug more regarding this.

Ah yea, looks like the same. I'll close in favor of that one.


Add ability to define environment variables for builder pods.

Hi Binderhub, Jupyterhub Team,
First I would like to say what a great tool Binderhub is. The options it gives, the UI, the possibilities to use different ML tools, languages, packages and it is all open source!!!. Great software.
Proposed change

Not sure if this was already asked but I am trying to set custom environment variable that would be visible in builder pod when repo2docker is running. I am basically trying to set environment variable as<EMAIL_ADDRESS>that comes from secret so that pip can install packages from my private repository when building an image based on requirements.txt
Alternative options

PodPresets would have worked but they were removed from Kubernetes 1.20.
Who would use this feature?

Anyone who wants to run notebooks that depend on custom Python packages that needs to be installed from private repository.
(Optional): Suggest a solution

It should be possible to expose env as a Python class traitlet so that it can be set and then append to it in the code. Right now the env is local to submit() function in https://github.com/jupyterhub/binderhub/blob/master/binderhub/build.py#L257 and I am not able to figure how to provide custom environment variable into the builder pod for repo2docker. Any suggestion would be appreciated.

As part of https://github.com/jupyterhub/binderhub/issues/1318 we are defining an interface for the Builder. This means it'll be much easier to extend and configure. For instance, a new Build.env traitlet could be added and its value set in the standard binderhub_config.py file.


1.18.1

After crouching to turn off chop, then un-crouching, the on screen icon does not re-appear indicating a chop will happen.

Fixed in 0.15.3. Thanks for reporting!


Dumping Emergency files when installed A9LH using old version of the guide

You could add a section for 3DS which already have A9LH installed but using an old version of your guide, to dump the emergency files, you just need to boot the OTPHelper.bin payload, and go to: "NAND Backup & Restore" and here, choose: "Dump Emergency Files".

This really isn't needed once a9lhax is already installed and they have functional backups.