[DEVOPS-155] Rework docker setup

Remove system installation of QEMU from Docker image (qemu-native will be built by yocto itself, if required)
As we (currently) use runqemu with slirp options (see https://www.yoctoproject.org/docs/latest/mega-manual/mega-manual.html#qemu-dev-command-line-syntax), we do not need privileged access, nor KVM support
yq is now built from source and therefore supports multi-architecture builds
Fixes https://github.com/iris-GmbH/iris-kas/issues/15

LGTM, maybe we could unify both docker images

Yeah... was thinking the same thing. However, as far as I can tell this could break the file ownership on local runs, as the jenkins dockerfile hardcodes a user ID of 1000. Any ideas?


Cannot select and pick a workflow after upgrading to v1.0.34

Provided you have 2 Logic App (Standard) workflows W1 and W2. We want to invoke workflow W2 from workflow W1.
When upgrading the VSCode Logic App (Standard) extension from 1.0.25 to 1.0.34, we are unable to see the list of workflows to pick from (should show W2) when using the Workflow Invoke action in workflow W1.

Please file an issue at Azure/logicapps for issues with the Logic Apps (Standard) extension. This repository is for the Logic Apps (Consumption) extension.


Implement ggshield web oauth flow

Implement ggshield login auth "web" method which implement the OAuth2 flow.
The core logic is implemented in OAuthClient.oauth_process(). In short it does

redirect to GitGuarian login page (with ggshield options)
open a local server to start listening
retrieve the code from the call to localhost
validate the token and retrieve its data
save the token to the config
open a tab to the "authenticated" page

port searching is good :+1:


Error: could not parse reference

I tried to use pack (for the first time) to build an image for a Node.js application with the following and am getting a cryptic error message:
$ pack build tpark.azurecr.io/tpark/testService:latest --path testService
Error: could not parse reference
Usage:
  pack build <image-name> [flags]

Flags:
      --builder string     builder (default "packs/samples")
  -h, --help               help for build
      --no-pull            don't pull images before use
  -p, --path string        path to app dir (default "/Users/timothypark/dev/rhom/ops2/services/locationService")
      --publish            publish to registry
      --run-image string   run image

This happens with both 0.0.4 and 0.0.5 - is this user error or a bug?

@timfpark The problem turns out to be due to the library we use to parse registry names not accepting tpark.azurecr.io/tpark/testService:latest (it does accept tpark.azurecr.io/tpark:latest). I am assuming that the image name you gave us is correct and that the error is in https://github.com/google/go-containerregistry
I will try to get an account with azure and submit a PR to go-containerregistry if necessary. (Or if you feel inspired to do the PR)

So on closer inspection @timfpark I believe that the problem is capitalization. The docker daemon does not allow capitalization and https://github.com/google/go-containerregistry is also enforcing that. If you change to all lower case then all should be good.

Ah - I didn't know that - I'll adjust accordingly.  Thanks for your help!


Avoid discarding const.

Fixes #6.

Regarding
- table->metadata = (uint16_t *)( (unsigned char *)allocation + VT_CAT( NAME, _metadata_offset )( table ) );
+ table->metadata = (void *)( (unsigned char *)allocation + VT_CAT( NAME, _metadata_offset )( table ) );

and
-   new_table.metadata = (uint16_t *)( (unsigned char *)allocation + VT_CAT( NAME, _metadata_offset )( &new_table ) );
+   new_table.metadata = (void *)( (unsigned char *)allocation + VT_CAT( NAME, _metadata_offset )( &new_table ) );

was Clang-Tidy complaining about this cast for some reason? The uint16_t * cast is necessary for C++ compatibility (as C++ disallows implicit conversion from void * to another pointer type).
And regarding
- static const uint16_t vt_empty_placeholder_metadatum = VT_EMPTY;
+ static uint16_t vt_empty_placeholder_metadatum = VT_EMPTY;

is this because Clang-Tidy complains about the (deliberate) casting-away of const in e.g. the _init function (table->metadata = (uint16_t *)&vt_empty_placeholder_metadatum;)? I'd rather leave vt_empty_placeholder_metadatum as const in order to make it very clear that the value of this "placeholder" is never changed. So maybe // NOLINT would be more appropriate here?

Regarding
- table->metadata = (uint16_t *)( (unsigned char *)allocation + VT_CAT( NAME, _metadata_offset )( table ) );
+ table->metadata = (void *)( (unsigned char *)allocation + VT_CAT( NAME, _metadata_offset )( table ) );

and
-   new_table.metadata = (uint16_t *)( (unsigned char *)allocation + VT_CAT( NAME, _metadata_offset )( &new_table ) );
+   new_table.metadata = (void *)( (unsigned char *)allocation + VT_CAT( NAME, _metadata_offset )( &new_table ) );

was Clang-Tidy complaining about this cast for some reason? The uint16_t * cast is necessary for C++ compatibility (as C++ disallows implicit conversion from void * to another pointer type).

No, this was clang itself compiling it. I think clang17, or whatever is in Alpine Linux 3.20.0.
It's necessary because char has an alignment of 1 and uint16_t an alignment of 2 so if it's off by one, it's a segfault on some platforms.
On platforms which are sensitive to alignment it matters and clang warns you about it regardless of platform.
The correct way (afaik) of telling a char pointer is correctly aligned to it's uint16_t pointer is to do an intermediate cast to void pointer.
On C at least, you don't need an explicit cast of void * to any other pointer, hence (uint16_t *)(void *) is unnecessary.
C++, I don't know as I don't use it.

And regarding
- static const uint16_t vt_empty_placeholder_metadatum = VT_EMPTY;
+ static uint16_t vt_empty_placeholder_metadatum = VT_EMPTY;

is this because Clang-Tidy complains about the (deliberate) casting-away of const in e.g. the _init function (table->metadata = (uint16_t *)&vt_empty_placeholder_metadatum;)? I'd rather leave vt_empty_placeholder_metadatum as const in order to make it very clear that the value of this "placeholder" is never changed. So maybe // NOLINT would be more appropriate here?

Actually it was gcc complaining about it.
const is just a clue for correctness. You can unconst a pointer and write to it regardless. Dangerous if the pointer is a static assignment, but that is effectively what you are doing here because metadata where you are assigning to is changeable.
So both compiler errors. I'm on holiday for a week and don't have access to my sources right now, but from memory these are my CFLAGS.
CFLAGS+=	-g -Wall -Wextra -Wundef
CFLAGS+=	-Wmissing-prototypes -Wmissing-declarations
CFLAGS+=	-Wmissing-format-attribute -Wnested-externs
CFLAGS+=	-Wcast-align -Wcast-qual -Wpointer-arith
CFLAGS+=	-Wreturn-type -Wswitch -Wshadow
CFLAGS+=	-Wcast-qual -Wwrite-strings
CFLAGS+=	-Wformat=2
CFLAGS+=	-Wpointer-sign -Wmissing-noreturn
CFLAGS+=       -Werror

I think I included -pedantic and -std=c23 as well, but can't be sure.

const is just a clue for correctness. You can unconst a pointer and write to it regardless. Dangerous if the pointer is a static assignment, but that is effectively what you are doing here because metadata where you are assigning to is changeable.

If the const variable is global, I believe compilers will typically store it in the program’s read-only “text” section. This is very desirable in this scenario, wherein the table’s ‘metadata` member could point to actual dynamically allocated metadata or this placeholder. It means that the program should crash if some bug causes a hash-table to attempt to write the the placeholder.

from memory these are my CFLAGS

Oh, I see. The issue here is the use of -Wcast-qual (in conjunction with -Werror). I've opened a new issue concerning support for optional diagnostics beyond -Wall -Wextra -Wpedantic (the diagnostics I already used when developing the library).


Error when column type is quoted custom enum

Describe the bug
I cannot listen to a table that has a column of type custom enum with double quotes.
To Reproduce
Steps to reproduce the behavior:

CREATE TYPE "MOOD" AS ENUM ('sad', 'ok', 'happy');

create table test (
  id bigint primary key,
  mood "MOOD"
);

Insert a row
Poll for changes

Expected behavior
I get back database changes without error.
Actual behavior
ERROR:  invalid input syntax for type json
DETAIL:  Token "MOOD" is invalid.
CONTEXT:  JSON data, line 1: ...:"bigint","value":1},{"name":"mood","type":""MOOD...

Additional context
wal2json issue: https://github.com/eulerto/wal2json/issues/224

Resolvable by upgrading to wal2json 2.4

@olirice gonna keep this open until we upgrade all projects to wal2json 2.4

closing b/c up was completed (tracking the regression in a new issue #40 )


Fix formatting for GitBook

Summary
Fix formatting issue in GitBook: https://mattermost.gitbook.io/plugin-jira/setup/configuration

Ticket Link

Hello @bbodenmiller,
Thanks for your pull request! A Core Committer will review your pull request soon. For code contributions, you can learn more about the review process here.

Codecov Report

Merging #725 (c7d857d) into jira-docs-3.0 (490c1a8) will not change coverage.
The diff coverage is n/a.

@@              Coverage Diff               @@
##           jira-docs-3.0     #725   +/-   ##
==============================================
  Coverage          32.10%   32.10%
==============================================
  Files                 52       52
  Lines               5270     5270
==============================================
  Hits                1692     1692
  Misses              3384     3384
  Partials             194      194

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 490c1a8...c7d857d. Read the comment docs.

Thanks, @bbodenmiller! This looks great. Could you let me know what changed in the formatting - I can see the bullet types changed and would be good to keep in mind for future editing.

Thanks, @bbodenmiller! This looks great. Could you let me know what changed in the formatting - I can see the bullet types changed and would be good to keep in mind for future editing.

@justinegeffen I just indented the bullets. They appear to render on GitHub without indenting but not GitBook.

Ah! Thanks a lot, @bbodenmiller. I've noticed that does happen on some pages in prod but not GitHub. I was just doing a diff here. Really appreciate the PR for this. :)

@jfrerich, I've merged this as it's a formatting change and not content-related.


Connecting for ArchLinux to a Windows 8 host

Hello,
I am trying to connect to a windows 8, the computers are both in the same LAN
$ xfreerdp /cert-ignore /v:<IP_ADDRESS> /u:myuser /p:mypass /sec:rdp
[01:17:31:697] [9532:9533] [ERROR][com.freerdp.legacy] - Property 474 does not
exist
[01:17:46:712] [9532:9533] [ERROR][com.freerdp.legacy] - freerdp_set_last_error
0x2000C

[01:17:46:712] [9532:9533] [ERROR][com.freerdp.legacy] - Error: protocol
security negotiation or connection failure

I added /cert-ignore and /sec:rdp in a futile attempt to make the error go away.
$ pacman -Qi freerdp
Name           : freerdp
Version        : 1:1.2.0_beta1+android9-1

Any suggestions would be welcome.

I've had this kind of problem with gateway on debian wheezy. It looks like authentification was not correct. Have you tried -sec-nla ? That is like "must" for Windows 2012 and perhaps aswell for Windows 8.

@LGLumi Nevermind me.
I just discovered that Windows 8 base does not actually have RDP
Shame on me, but that Remote assistance is really misleading.


Extend the tests in regexp/inspect_spec with over escaping combined with character classes

The specs have one test for escaped backslashes in Regexp#inspect:
it "does not over escape" do
  Regexp.new('\\\/').inspect.should == "/\\\\\\//"
end

The obvious implementation to make this spec pass is to simply escape every slash with another slash. This works in this case, but that causes an error in language/case_spec for something that is not related to the case statement:
it "tests with a regexp interpolated within another regexp" do
  digits_regexp = /\d+/
  case "foo43"
  when /oo(#{digits_regexp})/

This results in a regexp /oo(?-mix:\\d+)/, which now expects a slash followed by one or more d characters. This does not match the input, but does not indicate the escaping as the issue.
I tested my implementation with the these specs added, but this was more or less brute forcing every possibility. Also, because Regexp.new takes a String which has an additional layer of escaping, I peferred the // notation.
Regexp.new('\d+').inspect.should == "/\\d+/"
/\d+/.inspect.should == "/\\d+/"

Regexp.new('\\d+').inspect.should == "/\\d+/"
/\\d+/.inspect.should == "/\\\\d+/"

Regexp.new('\\\d+').inspect.should == "/\\\\d+/"
/\\\d+/.inspect.should == "/\\\\\\d+/"

Regexp.new('\\\\d+').inspect.should == "/\\\\d+/"
/\\\\d+/.inspect.should == "/\\\\\\\\d+/"

I think it would be better to at least include the following cases:
/\d+/ # Output should have 1 not escaped slash, since this should not be escaped
/\\d+/ # Output should have 1 escaped slash (so 2 slashes), this should be escaped
/\\\d+/ # Output should have 1 escaped and 1 not escaped slash (so 3 slashes)

Furthermore, I think it would be better to add an explicit test for the regexp embedded in regexp scenario like there is in the case spec now, just to make the test a bit more explicit and decouple it from the case statement.
I'm not that familiar with this project and how things are structured, can I just add a few tests to the inspect spec of regexp, and make a new spec file for the embedding tests?

For what it's worth: https://github.com/natalie-lang/natalie/pull/779 has a bit of a write up with the issues I encountered

I'm not that familiar with this project and how things are structured, can I just add a few tests to the inspect spec of regexp, and make a new spec file for the embedding tests?

Yes, just make a PR and based on the changes we can find out what's the right place.
Specs testing interpolating a regexp in another regexp should probably move to language/regexp_spec.rb.


Documentation

Misses basic tl:dr; or readme.
☝

This looks like a promising project to push JMAP forward. We are interested in extending this library.
A basic guide on how to use it would greatly help us evaluating it further!
I am wondering: Since this is called "proxy": Is this supposed to be a JMAP backend library or a simple proxy that translates JMAP into IMAP?

I am wondering: Since this is called "proxy": Is this supposed to be a JMAP backend library or a simple proxy that translates JMAP into IMAP?

This would interest me as well. I suppose something like mime-to-jmap would be needed and then some business logic around IMAP as well as some business logic around SMTP.


[backport PR1281] Update ReleaseNotes in preparation for the 9.1 release.

This is just backporting in the release notes that @Ouss4 put together, so I am going merge this myself.  Hopefully that does not bother anyone.


Date-range issue

Expected behaviour
Let's say I have two fields named DateStart and DateEnd in an input group. I'm using the date-range method. I expect that once I pick the DateStart, the DateEnd calendar should have all other dates less than the date picked on DateStart disabled.
Actual behaviour
I'm still able to pick earlier dates on DateEnd even after picking a date on DateStart field.
Datepicker version used
ex. 1.6.1.
Example code
$('.datepicker-daterange input').each(function() {
$(this).datepicker({
autoclose: true,
format: 'dd/mm/yyyy',
changeMonth: true,
changeYear: true
});
});

After having this exact same issue, and not being clear on the docs, I figured it out on the sandbox.
To instantiate a date-range you call the $.datepicker() function on the input group, not on each date field.

    <input type="text" class="input-sm form-control" name="start" />
    to
    <input type="text" class="input-sm form-control" name="end" />

$('#datepicker-range').datepicker({
    // your config here
});

Thanks for this @gutierrezps, I was caught out by this for much longer than I should have been.
The docs have still not been updated.


fix: cannot send multiple keys in puppeteer with pressKey

Motivation/Description of the PR
Applicable helpers:

[ ] Webdriver
[x] Puppeteer
[ ] Nightmare
[ ] REST
[ ] Appium
[ ] Protractor
[ ] TestCafe

The following code worked differently in webdriver an puppeteer: I.pressKey('abc'). In webdriver, abc is entered in the field whereas puppeteer throws an exception (Unknown key: abc). WebDriver gently uses the given keys if no special key can be identified. Puppeteer needs to know, whether it is a special key (keyboard.press) or if just a string should be typed (keyboard.type). With this fix, both drivers should work the same.
Type of change

[ ] Breaking changes
[ ] New functionality
[x] Bug fix
[ ] Documentation changes/updates
[ ] Hot fix
[ ] Markdown files fix - not related to source code

Checklist:

[x] Tests have been added
[ ] Documentation has been added (Run npm run docs)
[x] Lint checking (Run npm run lint)
[x] Local tests are passed (Run npm test)

 Here is an overview of what got changed by this pull request:

Clones removed
==============
+ test/helper/Puppeteer_test.js  -1

See the complete overview on Codacy

 Here is an overview of what got changed by this pull request:

Clones removed
==============
+ test/helper/Puppeteer_test.js  -1

See the complete overview on Codacy

This is very useful but implementation can not be scaled to other helpers.
Also, I agree with @martomo doubts about implementation.
I think we need to consider adding a new method like I.type('keys');
@Holorium sorry for taking me that long to decide on this, I really was not sure about what to do with this PR and how to manage it better. I think it is better to think more and take wise decisions than to work with consequences.


ci(mirror-main-branch): add a new workflow to mirror the main branch to the main distro branch

Description

It's useful if we mirror the main branch to the main distro branch (now it's humble).

The supported ROS distro becomes clear.

Distro branches can provide stable interfaces.
For example, if some user write the following reference in ansible-galaxy-requirements.yaml, it may cause drastic changes.
  - name: https://github.com/autowarefoundation/autoware.git#/ansible
    type: git
    version: main

However, if they depend on humble, the changes are relatively small.
  - name: https://github.com/autowarefoundation/autoware.git#/ansible
    type: git
    version: humble

Related: ROS 2 mirrors rolling to master. It's a little different usage from us.
https://github.com/ros2/ros2/blob/07c27c934a6a1269fec2828f4c1a4ff40430d44d/.github/workflows/mirror-rolling-to-master.yaml
Pre-review checklist for the PR author
The PR author must check the checkboxes below when creating the PR.

[x] I've confirmed the contribution guidelines.
[x] The PR follows the pull request guidelines.

In-review checklist for the PR reviewers
The PR reviewers must check the checkboxes below before approval.

[ ] The PR follows the pull request guidelines.

Post-review checklist for the PR author
The PR author must check the checkboxes below before merging.

[ ] There are no open discussions or they are tracked via tickets.

After all checkboxes are checked, anyone who has write access can merge the PR.

I've tested in another repository, and it worked.


Allow EnsureSolution to report if it already existed.

About the PR
This PR makes the method consistent with EnsureContainer's API.
Media

Changelog

If you wanted to make this analogous to ensurecomp with "out var" you would get the existing solution if it exists and a new solution if it doesn't

this should return bool and have an out Solution, not the other way around

reopen once you have time for this


⚠ Beamable Calendars (Basic) has degraded performance

In d663f43, Beamable Calendars (Basic) (https://api.beamable.com/object/calendars/platform/docs) experienced degraded performance:

HTTP code: 503
Response time: 14153 ms

Resolved: Beamable Calendars (Basic) performance has improved in 4890e44 after 10 minutes.