Putting a break-point in typescript files, it jumps to another line

When using the Chrome debugger, putting breakpoints on a typescript file it not working very well. It makes the breakpoint jumps to another line. And when using a prettified file, the breakpoints gets set and stays on the line, but never get hit when the application is running.

That's because of known issues with source maps.

Leaving this open to remind myself to mention this in a doc.


sanoid/syncoid: Add package options

Allows changing the sanoid package to be used for these services.
Maintainers: @julm @lopsided98
Description of changes
Add package options to sanoid and syncoid modules.
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

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

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

[ ] Fits CONTRIBUTING.md.

Please squash the commits so we have a clean history.

Done.


composer command not found in latest spryker/php:8.0-debian

The image docker.io/spryker/php@sha256:0da43731eeb68b10c5556c2280f4779951a1079d6a5620551523efbb44e4cb74 (arm64 version of the tag 8.0-debian) does not have composer installed.
The following command does not produce any output. The expected output would be "/usr/bin/composer":
docker run --rm docker.io/spryker/php@sha256:0da43731eeb68b10c5556c2280f4779951a1079d6a5620551523efbb44e4cb74 bash -c 'command -v composer'

The arm64 version of the tag 8.1-debian seems to be fine because it prints the expected output:
docker run --rm docker.io/spryker/php@sha256:f4e94299c40953f91e59c555d8084415f722f9bf5c0ed156ed29a66bf77b6fc6 bash -c 'command -v composer'

Hi @elchenberg,
You can try to check with the latest digest - sha256:45bb8ca9a6fdd7cff62ed5843c89e08a213fa4e2f4982cd10d2dc0244bc8d6d4.

Looks good, thank you!


User FFD Show Decoder/filter instead of LAV Decoder

Hello,
I want to implement a media player using WPFMediaKit. I suppose by default it uses LAV Decoder. I want to use FFDShow decoder/filter. I went through all the issues as well as on stackoverflow but could not find any solution. There was one question on stackoverflow regarding ffdshow decoder but it did not provide example. i.e. https://stackoverflow.com/questions/46390432/how-to-use-ffdshow-with-wpf-mediakit
this is what i have tried in my code;
player.MediaUriPlayer.VideoDecoder = "FFDShow Video Decoder";
but when i stop and close the file, i could see the graph spitting information in my debug panel in Visual Studio and i saw the graph was still using LAV Video Decoder.
how can i set the ffdshow decoder through code?
any example would be highly appreciated as i don't know how to find filter id etc. and include in the wpfmediakit source.
thanks
rex

Debug MediaUriPlayer.OpenSource(). If the preferred VideoDecoder fails, then this falls back to the oldOpenSource() method, which just uses the first video decoder by the merit. Also, is DirectShowUtil.AddFilterToGraph successful?

Hi xmedeko,
thanks for your response. This is what i have done with the Test application provided in with the source code.
I uninstalled K-Lite code mega pack from my system. I downloaded ffdshow codec pack from https://sourceforge.net/projects/ffdshow-tryout/ and installed it.
I commented the following line in the test applicaiton;
mediaUriElement.MediaUriPlayer.SplitterSource = "ffdshow Video Decoder";
Then i ran the test application and selected an MP4 file from one of my folder. I started debug with OpenSource routine.
The function could not find LAV video decoder so it went to oldOpenSource code block.
In the CreateVideoRenderer function, i could see the program is moving to "CreateVideoMixingRenderer9" function call and created the renderer.
Next, the "VideoPinFrom" is null so hasvideo is set to false
finally it throws "Could not render any streams from the source Uri" message.
The message on the form says "Could not add SplitterSource to Graph".
I then stopped debugging and un-commented the following line;
mediaUriElement.MediaUriPlayer.SplitterSource = "ffdshow Video Decoder";
and ran the program. The opensource function found the ffdshow filter and added it into the graph but threw following error;
"Unable to cast COM object of type 'System.__ComObject' to interface type 'DirectShowLib.IFileSourceFilter'. This operation failed because the QueryInterface call on the COM component for the interface with IID '{56A868A6-0AD4-11CE-B03A-0020AF0BA770}' failed due to the following error: No such interface supported (Exception from HRESULT: 0x80004002 (E_NOINTERFACE))."
then the routine went to oldOpenSource() and still the hasvideo = false and finally "Could not render any streams from the source Uri" error.
I opened up "ffdshow video decoder configuration" window and set "libavcodec" as decoder to all the file types. Clicked on "Directshow control" tab and set the merit to very high and also unchecked both the check boxes to use ffdshow in mpc player...
Still there is no luck to play mp4 file.
any thoughts on why it would not play with ffdshow codec?
thanks
rex

I do not understand DirectX video in such a depth to help you.
It's strange the video filter does not implement IFileSourceFilter. Probably, the AddFilterToGraph() should skip such filters. If you run the program form VisualStudio, you should see debug logs from AddFilterToGraph() in the debug output, so you should see a log Added filter: ... and maybe some errors.
Also, check GraphStudioNext with your mp4 file. It will show you the default DirectX graph - which splitter and filters are used?
BTW are you sure you need ffdshow? The LAV codecs are considered to supersede the ffdshow. Check the https://sourceforge.net/projects/ffdshow-tryout/  - last update: 2015-08-09.

hi xmedeko,
it's working now.
I installed K-Lite codec corporate pack which doesn't have LAV video decoder. I ran the codec tool (Win7DSFilterTweaker_2.9.exe) and set ffdshow as preferred decoder.
I then ran Graphstudio and loaded the mp4 file and i could see ffdshow as the filter added into the graph.
I ran the program and now i can see it picking up the ffdshow filter and playing the video file as expected by the "oldOpenSource()" function..
thanks
rex

Maybe you can still set the SplitterSource and VideoDecoder not to fall into the oldOpenSource() and if you really want to enforce the ffdshow even on machines, which have LAV codecs installed.


Feature/improve failure output

Codecov Report

Merging #261 into master will increase coverage by <.01%.
The diff coverage is n/a.

@@            Coverage Diff             @@
##           master     #261      +/-   ##
==========================================
+ Coverage   54.22%   54.23%   +<.01%
==========================================
  Files         332      332
  Lines       56404    56404
==========================================
+ Hits        30586    30588       +2
+ Misses      25818    25816       -2

Impacted Files
Coverage Δ

src/lib/profiles/security/WeaveCert.cpp
84.41% <0%> (+0.64%)
:arrow_up:

Continue to review full report at Codecov.

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


A13 - Blockchain functional gaps

Details TBC

Can I jump on this @mo-jaber

Can I work on this @mo-jaber

I can jump on it when it is confirmed, @mo-jaber


Good one but Link is broken !!

good tutorial. but the link broken for "Scaffold identity into a Razor project with authorization" . please fix it ASAP.

Document Details
⚠ Do not edit this section. It is required for docs.microsoft.com ➟ GitHub issue linking.

ID: 94bfd895-d2af-390b-0801-428b36a27ff4
Version Independent ID: 0e0d870e-e49a-e16c-c259-68d58e701b8f
Content: Introduction to Identity on ASP.NET Core
Content Source: aspnetcore/security/authentication/identity.md
Product: aspnet-core
GitHub Login: @Rick-Anderson
Microsoft Alias: riande

@ajithk444  thanks for pointing that out. I'm fixing it now in #8020

@ajithk444 fixed. It should go live in the next 24 hours. Hope you found the correct link.

Thanks ! that was so quick. but still link is broken as it is not live yet i guess. Will check after 24 hrs. :)


Adding empty ontimeout

Might help on some of those IE9 network errors - http://cypressnorth.com/programming/internet-explorer-aborting-ajax-requests-fixed/

:+1:


Adds healthz-php to php fpm

This makes healthz-php available at /.lagoonhealthz and provides a fallback for non PHP supported applications.
Checklist

[x] Affected Issues have been mentioned in the Closing issues section
[ ] Documentation has been written/updated
[x] PR title is ready for changelog and subsystem label(s) applied

See #2011
Closing issues
Closes #2011

@bomoko nice work! just a couple of small questions :)


Missing dependencies in Accumulo iterators jar

The Gaffer common util classes are missing from the Accumulo iterators shaded jar. This means the accumulo iterators will fail unless you deploy the common util jar as well.

Merged into develop.


Depth buffer in VR mode isn't cleared in right eye when using renderer.clearDepth(); between scenes

If layering multiple scenes on top of each other and clearing the depth buffer between each one only the last scene in the right eye is rendered. It's as if the opacity in the scene isn't working to allow the scenes behind to show through. It works fine in the left eye but in the right I only see the last rendered scene.

Include an example please.

I'm rendering different scenes on top of each other and making them transparent to see through to the scenes behind:
manager.render( sceneLayer1, camera );
renderer.clearDepth();
manager.render( sceneLayer2, camera );
renderer.clearDepth();
This is the result I get:

It looks fine in the left eye but not the right; it seems the depth buffer is not being cleared between each layer in the right eye. Perhaps this is a problem with VREffect instead? Or maybe it's just me?

Could you link to the code, to see if I can repro?

It's a little tricky for me to as it's all wrapped into an app. I'll try and simplify it to show you.

http://gsa.extended-content.com/resources/3Demo/three.js/examples/webgl_loader_obj_mtl.html
Here you can see renderer.setClearColor( 0xffffff, 1); has been set. Using VR on Androidn, in the right eye the background is white meaning the scene is completely opaque (bad), whilst in the left it is black as it is transparent (good).
The model of the male is not appearing in mobile I'm not sure why.
Hope this makes sense!

Is this still happening using the latest versions of boilerplate/polyfill?

setClearColor doesn't work with viewports, you need to use the scissors function.


Ensure unique knob names across knob groups

Issue: #5391
What I did
Suffix knob names with the groupId, if provided (${name}_${groupId}).
How to test
I updated examples/official-storybook/stories/addon-knobs.stories.js to have a knob with the same name in two different groups.

Is this testable with Jest or Chromatic screenshots?
Yes
Does this need a new example in the kitchen sink apps?
No
Does this need an update to the documentation?
No

If your answer is yes to any of these, please make sure to include it in your PR.

@andrefgneves Thanks for the contribution! Haven't reviewed the code yet, but the idea makes sense and it's a good fix. We're in the middle of the 5.1 release, so I've marked this "do not merge" for the moment, and we'll get it in after the release is out in a few weeks. Sorry for the lag!


various atom updates

contains commits from @ulidtko and @archaeron forks
Please review

It looks good. I'm not actually using Atom anymore, so if anyone can say it works as intended, I'll happily merge this.

@fangel good, maybe we need @ulidtko and @archaeron attention

I'm closing this, as all these fixes are now on master


CI performance improvements

This has two fixes to improve CI performance:
Some latency hiding for the Loki deploy. We used to deploy Loki and then sit idly while k8s pulls the images, etc. This deploys the helm chart and then goes away to do the pachd build, and comes back to check on the progress later.
Recompute the cache more often. Right now the cache key doesn't change between runs, so the cache would get staler and staler for 30 days until it expired. This PR keys the module cache on the go.sum checksum, and accumulates the build cache for a week before rotating it.

Do you have a good way of seeing if the cache helps?

In the perfect case (no code changes), the build takes 1 minute, saving the cache takes 1.5 minutes, restoring the cache takes ~40s. By comparison, master today building with a stale cache takes ~5.5 minutes. About 3 minute savings (although I wish the cache performance was better). I'll keep an eye on how master and new branches perform and potentially do some tweaking.


Microsoft.MouseWithoutBorders version <IP_ADDRESS>7

Fixes https://github.com/microsoft/winget-pkgs/pull/16800
Microsoft Reviewers: Open in CodeFlow

Was about to open a new PR for the same thing, thanks for fixing it @ItzLevvie2

@ItzLevvie2 I just noticed this came through, and I had an older version on my machine. I tried to upgrade and it failed, so I stopped the service and tried again. Unfortunately, it didn't work. I uninstalled and did a new install. That time it worked, and it kept my settings. I think the UpgradeBehavior should be changed to "uninstallPrevious".


issue when using a DuckDb Macro

What happened?
I have a macro defined in DuckDb to access Parquet files on s3
CREATE MACRO cse(year, weekA, weekB) AS TABLE SELECT * FROM read_parquet(list_transform(
            generate_series(weekA, weekB),
            week -> format('s3://${BUCKET_PATH}/year={0}/week={1}/0.parquet', year, week)
        ));

in SQL I can do
SELECT count(*) FROM cse(2024, 1, 5);
but if I try to compile the following PRQL
from cse(2024,1,5)
aggregate {
   count this
}

it gives an error
[{"kind":"Error","code":null,"reason":"unexpected , while parsing function call","hints":[],"span":"1:13-14","display":"Error: \n   ╭─[:1:14]\n   │\n 1 │ from cse(2024, 1, 5)\n   │              ┬  \n   │              ╰── unexpected , while parsing function call\n───╯\n","location":{"start":[0,13],"end":[0,14]}}]}

PRQL input
see above

SQL output
See above

Expected SQL output
No response
MVCE confirmation

[X] Minimal example
[X] New issue

Anything else?
No response

Right now I seem to be "forced" to use an s-string which is not very neat, eg
from s"SELECT * FROM cse(2024, 1, 4)"
aggregate {
   count this
}

or something, is there a better way?

similarly if I have a field with a "reserved name" like "timestamp" I cannot directly use it, I need to use s"timestamp", for instance
aggregate {
   min_time = min s"timestamp" -- using "min timestamp" would generate an error because "timestamp" is a type
}

isn't there a way to see that what follows is necessarily a value, and should be coerced to a value?

Hi @maelp , good questions, thanks for opening an issue.
Check out https://prql-lang.org/book/reference/syntax/keywords.html — these are solvable with backticks and this. respectively:
from `cse(2024,1,5)`
aggregate {
   sum this.time
}

SELECT
  COALESCE(SUM(time), 0)
FROM
  "cse(2024,1,5)"

-- Generated by PRQL compiler version:0.11.1 (https://prql-lang.org)

Does that make sense?

Thanks! However if I use this DuckDB MACRO
CREATE MACRO cse(year, weekA, weekB) AS TABLE SELECT * FROM read_parquet(list_transform(
            generate_series(weekA, weekB),
            week -> format('s3://${BUCKET_PATH}/year={0}/week={1}/0.parquet', year, week)
        ));

I think it doesn't create a "table" per-se, but should be used as SELECT * FROM cse(...)
do you think I should instead create a table? not sure if I can do this as a macro / function?
When I use your code I get the error:
Catalog Error: Table with name recent_cse(4) does not exist!

The generated SQL is this
WITH table_0 AS (
  SELECT
    bms_id,
    GREATEST(value.temperature_mosfet, value.temperature_ic) AS _expr_0,
    GREATEST(value.temperature_front, value.temperature_back) AS _expr_1,
    LEAST(value.temperature_front, value.temperature_back) AS _expr_2
  FROM
    "recent_cse(4)"
)
SELECT
  bms_id,
  MIN(_expr_2) AS min_temp_cells,
  MAX(_expr_1) AS max_temp_cells,
  MAX(_expr_0) AS max_temp_bms,
  COUNT(*) AS count
FROM
  table_0
WHERE
  _expr_2 < -10
  OR _expr_1 > 40
  OR _expr_0 > 70
GROUP BY
  bms_id

I guess it should not use the " character because I want the macro to be run in duckdb no?

I verified that if I run the same query without the quotes, eg not "cse" but directly cse it works
eg
WITH table_0 AS (
  SELECT
    bms_id,
    GREATEST(value.temperature_mosfet, value.temperature_ic) AS _expr_0,
    GREATEST(value.temperature_front, value.temperature_back) AS _expr_1,
    LEAST(value.temperature_front, value.temperature_back) AS _expr_2
  FROM
    recent_cse(4)
)
SELECT
  bms_id,
  MIN(_expr_2) AS min_temp_cells,
  MAX(_expr_1) AS max_temp_cells,
  MAX(_expr_0) AS max_temp_bms,
  COUNT(*) AS count
FROM
  table_0
WHERE
  _expr_2 < -10
  OR _expr_1 > 40
  OR _expr_0 > 70
GROUP BY
  bms_id

is there a way to generate this simply from PRQL?

And if I try
from s"recent_cse(4)"
derive {
  min_temp_cells = s"LEAST(value.temperature_front, value.temperature_back)",
  max_temp_cells = s"GREATEST(value.temperature_front, value.temperature_back)",
  max_temp_bms = s"GREATEST(value.temperature_mosfet, value.temperature_ic)",
}
filter min_temp_cells < -10 || max_temp_cells > 40 || max_temp_bms > 70
group bms_id (
  aggregate {
    min_temp_cells = min min_temp_cells,
    max_temp_cells = max max_temp_cells,
    max_temp_bms = max max_temp_bms,
    count = count this,
  }
)```

it says

s-strings representing a table must start with SELECT

Ah, so we want literally FROM cse(2024,1,5) and not the quoted FROM "cse(2024,1,5)".
In that case, I think we do need to use the from s"SELECT * FROM cse(2024, 1, 4)", since currently PRQL expects an identifier.
We do have prior art for something more with the read_parquet-like functions; so it's not out of the question to do something similar.

This probably isn't going to make this perfect immediately, but it would be possible to make a function so the inline call were elegant:
prql target:sql.duckdb

let cse = x y z -> s"select * from cse({x},{y},{z})"

from (cse 1 2 3)
derive x = 5

WITH table_0 AS (
  SELECT
    *
  from
    cse(1, 2, 3)
)
SELECT
  *,
  5 AS x
FROM
  table_0

-- Generated by PRQL compiler version:0.11.1 (https://prql-lang.org)

would be interesting if we could have something like this! Or allow macros and duckdb functions in PRQL or something

BTW is it possible to do a multi-line PRQL function (this does not seem to be shown in the documentation)
I'm trying to do a helper function, then call it like this
let checkTemps = numWeeks minCellTemp maxCellTemp maxBMSTemp -> (from (recent_cse numWeeks)
    derive {
      min_temp_cells = s"LEAST(value.temperature_front, value.temperature_back)",
      max_temp_cells = s"GREATEST(value.temperature_front, value.temperature_back)",
      max_temp_bms = s"GREATEST(value.temperature_mosfet, value.temperature_ic)",
    }
    filter min_temp_cells < minCellTemp || max_temp_cells > maxCellTemp || max_temp_bms > maxBMSTemp
    group bms_id (
      aggregate {
        min_temp_cells = min min_temp_cells,
        max_temp_cells = max max_temp_cells,
        max_temp_bms = max max_temp_bms,
        count = count this,
      }
    )
)

checkTemps 4 -10 40 70

but it doesn't work...

The -10 needs to be parenthesized...
let checkTemps = numWeeks minCellTemp maxCellTemp maxBMSTemp -> (
from (recent_cse)
    derive {
      min_temp_cells = s"LEAST(value.temperature_front, value.temperature_back)",
      max_temp_cells = s"GREATEST(value.temperature_front, value.temperature_back)",
      max_temp_bms = s"GREATEST(value.temperature_mosfet, value.temperature_ic)",
    }
    filter min_temp_cells < minCellTemp || max_temp_cells > maxCellTemp || max_temp_bms > maxBMSTemp
    group bms_id (
      aggregate {
        min_temp_cells = min min_temp_cells,
        max_temp_cells = max max_temp_cells,
        max_temp_bms = max max_temp_bms,
        count = count this,
      }
    )
)

checkTemps 4 (-10) 40 70

...works!
(also I changed (recent_cse numWeeks) as that's not a function in the example)
Parentheses can be a bit confusing in some limited circumstances — explained here: https://prql-lang.org/book/reference/syntax/operators.html#parentheses. The main thing we can do is to make the error messages much much better.

would be interesting if we could have something like this! Or allow macros and duckdb functions in PRQL or something

We could have something very very simple like duckdb_macro cse 1 2 3. It's not elegant.
How do you / others think about macros vs functions? To the extent they're overlapping, I would deprioritize work here — having a boilerplate function for each macro doesn't seem too bad. To the extent they'll be coexisting lots, we could think about improving the interface.

Would be helpful to have a better help message indeed! I thought the issue was something else
yes the boilerplate can work I agree, so not a big priority. It's just that I want to be able to do queries both in SQL and PRQL so I'd like to have macros available in both to avoid duplicating code
would it be possible to rewrite that macro in pure PRQL (eg do you have access to duckdb generate_series and list_transform in PRQL? possibly in order to have those available, having something like a ::duckdb:generate_series and ::duckdb:list_transform as tokens (or a kind of PRQL "module" that we could import like "import duckdb" and then "duckdb.generate_series", "duckdb.list_transform" and "duckdb.call_macro" could be useful?)

Maybe you want to see this.
https://eitsupi.github.io/querying-with-prql/method_chaining/

Sorry to use this issue to ask questions but I find that the documentation doesn't show all the power of PRQL yet, for instance: is there a way to do a ternary operation or an if / then / else in PRQL?
I'd like to do something like
select {
  result = someTemp < -10 ? "below" : "above"
}

is that possible?

You can use case https://prql-lang.org/book/reference/syntax/case.html

Thanks!
Last question (and small "bug report")
when I use this it works fine
let check_temperatures = numWeeks minCellTemp maxCellTemp maxBMSTemp -> (
  from (recent_cse numWeeks)
  derive {
    min_temp_cells = s"LEAST(value.temperature_front, value.temperature_back)",
    max_temp_cells = s"GREATEST(value.temperature_front, value.temperature_back)",
    max_temp_bms = s"GREATEST(value.temperature_mosfet, value.temperature_ic)",
  }
  filter min_temp_cells < minCellTemp || max_temp_cells > maxCellTemp || max_temp_bms > maxBMSTemp
  group bms_id (
    aggregate {
      min_temp_cells = min min_temp_cells,
      max_temp_cells = max max_temp_cells,
      max_temp_bms = max max_temp_bms,
      count = count this,
    }
  )
)

But if I'd like to "rephrase" the min_temp, max_temp, etc at the end to only display if they are above / under their respective threshold it fails, and the error message is weird (it complains about the "->" in the function definition)
let check_temperatures = numWeeks minCellTemp maxCellTemp maxBMSTemp -> (
  from (recent_cse numWeeks)
  derive {
    min_temp_cells = s"LEAST(value.temperature_front, value.temperature_back)",
    max_temp_cells = s"GREATEST(value.temperature_front, value.temperature_back)",
    max_temp_bms = s"GREATEST(value.temperature_mosfet, value.temperature_ic)",
  }
  filter min_temp_cells < minCellTemp || max_temp_cells > maxCellTemp || max_temp_bms > maxBMSTemp
  group bms_id (
    aggregate {
      min_temp_cells = min min_temp_cells,
      max_temp_cells = max max_temp_cells,
      max_temp_bms = max max_temp_bms,
      count = count this,
    }
    derive {
      min_temp_cells = case [
        min_temp_cells <= minCellTemp => min_temp_cells
        true => ""
      ],
      max_temp_cells = case [
        max_temp_cells >= maxCellTemp => max_temp_cells
        true => ""
      ],
      max_temp_cells = case [
        max_temp_bms >= maxBMSTemp => max_temp_bms
        true => ""
      ],
    }
  )
)

(another small nitpick: why not using the same "->" for case and function, and introducing another symbol like "=>" ?)

I think you forgot the comma in arrays.
case [
  foo # bad line
  bar
]

ah indeed you're right, but the error message is confusing, @max-sixty would there be a way to show the "correct" error in those cases?

@max-sixty would there be a way to show the "correct" error in those cases?

It's definitely possible. I'd say it's harder than I thought it would be when I originally proposed terser syntax...
For example, in that case we need to realize we're in a list, possibly attempt to execute a function bar with an argument foo & realize foo isn't a function — then add those up to say "maybe foo should have a trailing comma, and is part of a list". And we don't have column names atm.
I would really like to focus on this, and think this will be the focus of our GSOC application.

(another small nitpick: why not using the same "->" for case and function, and introducing another symbol like "=>" ?)

FYI there was some discussion on this in a past issue... I don't think anyone had a really strong view, we ended up favoring consistency with other langs


Fix panic for task in unknown state.

Similar with https://github.com/containerd/containerd/pull/3611.
Signed-off-by: Lantao Liu<EMAIL_ADDRESS>

@mikebrow Thanks for reviewing! Can you also take a look at https://github.com/containerd/cri/pull/1252?
Tests are failing because of that.


chore: Migrate Angular UI unit tests to React

Fixes: #1195

CircleCI build fails, the yarn test process is terminated with SIGKILL. Possibly running out of memory.

OK... --runInBand solved exit 137 problem in UI atlasmap-core test.


odo dev and odo remove binding does not unbind the application and service properly; broken

/kind bug

What versions of software are you using?
 Change the main.go file to the following.
package main

import (
	"context"
	"fmt"
	"net/http"
	"os"

	"go.mongodb.org/mongo-driver/mongo"
	"go.mongodb.org/mongo-driver/mongo/options"
	"go.mongodb.org/mongo-driver/mongo/readpref"
)

// Connection URI
var (
	USERNAME = os.Getenv("PERCONASERVERMONGODB_MONGODB_USER_ADMIN_USER")
	PASSWORD = os.Getenv("PERCONASERVERMONGODB_MONGODB_USER_ADMIN_PASSWORD")
	HOST     = os.Getenv("PERCONASERVERMONGODB_HOST")
	uri      = fmt.Sprintf("mongodb://%s:%s@%s:27017/?maxPoolSize=20&w=majority", USERNAME, PASSWORD, HOST)
)

func main() {
	http.HandleFunc("/", HelloServer)
	http.ListenAndServe("<IP_ADDRESS>:8080", nil)

}

func HelloServer(w http.ResponseWriter, r *http.Request) {
	// Create a new client and connect to the server
	client, err := mongo.Connect(context.TODO(), options.Client().ApplyURI(uri))

	if err != nil {
		fmt.Fprintf(w, "failed to connect to the server: %s", err.Error())
		return
	}
	defer func() {
		if err = client.Disconnect(context.TODO()); err != nil {
			fmt.Fprintf(w, "failed to disconnect: %s", err.Error())
			return
		}
	}()

	// Ping the primary
	if err := client.Ping(context.TODO(), readpref.Primary()); err != nil {
		fmt.Fprintf(w, "unable to connect to the server: %s", err.Error())
		return
	}
	fmt.Fprint(w, "Successfully pinged the server.")
}

Install SBO 1.3.1 and PerconaServerMongoDB 1.13.0 and wait for them both to install.
odo set namespace my-percona-server-mongodb-operator

5. Create mongodb service instance.
apiVersion: psmdb.percona.com/v1-11-0
kind: PerconaServerMongoDB
metadata:
  name: mongodb-instance
spec:
  platform: openshift
  crVersion: 1.11.0
  image: percona/percona-server-mongodb:4.4.10-11
  allowUnsafeConfigurations: true
  upgradeOptions:
    apply: 4.4-recommended
    schedule: "0 2 * * *"
  secrets:
    users: mongo-cluster-secrets
  replsets:
  - name: rs0
    size: 1
    volumeSpec:
      persistentVolumeClaim:
        resources:
          requests:
            storage: 1Gi
  sharding:
    enabled: true
    configsvrReplSet:
      size: 1
      volumeSpec:
        persistentVolumeClaim:
          resources:
            requests:
              storage: 1Gi
    mongos:
      size: 1

odo add binding and add the binding with mongodb. Does not matter how you bind.
odo dev
curl URL and should receive a 200 OK response.
odo remove binding --name go-framework-mongodb-instance
Wait for odo dev to finish its operations.
Check the pod for files or envvar. Check ServiceBinding resource.

Actual behavior
ServiceBinding resource exists even after odo remove binding is executed.
Expected behavior
ServiceBinding resource should have been deleted after odo remove binding is executed.
Any logs, error output, etc?
This bug was produced on minikube(--driver=podman) v1.25.2.
Might be fixed by #6189

/close
Duplicate issue: 6101


merging of SELinux policies produces duplicates

What happened:
I was recording File Integrity Operator policies using the SELinux log-enricher based recorder and the resulting merged policy has a ton of duplicates:
spec:
  allow:
    NetworkManager_etc_rw_t:
      dir:
      - read
      - read
      - read
      - read

What you expected to happen:
no duplicates
How to reproduce it (as minimally and precisely as possible):

create a namespace, label it for recording
create a profile recording
run FIO e2e tests there
delete profile recording

Anything else we need to know?:
I used today's git HEAD, so 0.5.0 with a bunch of minor patches
Environment:

Cloud provider or hardware configuration: AWS
OS (e.g: cat /etc/os-release): RHCOS
Kernel (e.g. uname -a): N/A
Others: N/A

/assign


Game crashes when placing the GregTech Basic Macerator

Describe the bug
Game crashes when placing the GregTech Basic Macerator. Checking the crash log, it's trying to set the light level to -1 which is invalid, and causing continuous crash.
Reproducibility

[X] I reproduced this issue with as few other mods as possible installed.
[ ] I am unable to reproduce this issue consistently.

Screenshots and/or videos
No response
Logs
https://mclo.gs/jGUzXns
Debug Logs
No response
Crash Reports
https://mclo.gs/jGUzXns
Alfheim Version
1.2
Forge Version
<IP_ADDRESS>59
MixinBooter Version
8.8
Java Version
1.8
Java Virtual Machine
Hotspot
Operating System
Windows 10
GPU Vendor
NVIDIA
Code of Conduct

[X] I agree to follow this project's Code of Conduct

It should be noted that in this case the latest version of GregTech Community Edition unofficial was used.

Could you try with this version: https://www.curseforge.com/minecraft/mc-mods/alfheim-lighting-engine/files/5201011

Fixed in Alfheim 1.3


Fast writer paths for Int16 and Byte

CsvDataWriter.GetWriter falls back to a boxing DataReader.GetValue() call for Byte/byte (TINYINT) and Int16/short (SMALLINT) types. This is not functionally wrong and these types aren't terribly common, but it's still needlessly wasteful to go through boxing for them when the input does contain them. With this all scalar types are covered except char (which remains the odd one out, as most providers don't use it at all in favor of string; with possible encoding issues, supporting that specially may be more complicated than is warranted).
This PR adds fast writer support (for both the typed and untyped cases) and fixes two other problems with the generic object path:

A copy-paste error had the value for long cast to int. As unboxing doesn't perform type conversions, this cast should fail at runtime.
There was no type check for decimal even though we have a writer for it, so this fell back to generic string formatting.

I didn't add tests for these since I'm not familiar enough with the code base to know what should be tested and where the tests should go, but obviously I recommend writing these before adding this code (especially for the long case, which is a bug rather than a perf improvement).

The test for the long bug is pretty simple (I just actually hit that in real code :P): have a writer return typeof(object) for every call to GetFieldType, then return a long in the call to GetValue; you'll get an InvalidCastException.


added missing import entry point tests (#7145)

Pull request opened by the merge tool on behalf of #7145

Merged in 7607acea566f67ebb0a89cd3f072147d9665bed1


Implement sort=None behavior

Implement sort=None behavior and regression tests.
Regression tests have been tested against origin/MASTER and comprise most of the cases I could think of.
There are no tests for indexes with duplicates, but with a quick check, the behavior of these won't be changed much when sort=None. In these cases, the sort won't happen and no warning will be issued.

TODO: change location of tests to test_append.py


Add support for CRI grpc interface

The workloads layer is still using the docker client to retrieve the list of containers and watch for events.

[ ] rename the misnamed containerd plugin to docker
[ ] add support for the CRI grpc interface. There are several options here.

This is the most important missing feature for me, because at my company we are making the switch to cri-containerd and the k8s-nodes will not even have docker installed any longer.

This is the most important missing feature for me, because at my company we are making the switch to cri-containerd and the k8s-nodes will not even have docker installed any longer.

Thanks, this is great feedback. We are bumping this up.

Just to be sure: I think the new title regarding CRI-O is not corrent. We are going to use containerd with CRI.
The corresponding Kubernetes (kubelet) flags are --container-runtime=remote --container-runtime-endpoint=<path-to-cri-containerd-socket>.
CRI-O is another implementation of CRI.

Just to be sure: I think the new title regarding CRI-O is not corrent. We are going to use containerd with CRI.

You are right, we have been tracking two different tasks with this issue. The addition of CRI interface support as well as testing with CRI-O which has been requested as well.

The implementation of CRI for containerd has been moved into the containerd-project as a plugin:
https://github.com/containerd/cri/releases/tag/v1.0.0-rc.0
This implements CRI v1alpha2 (Kubernetes 1.10). Is this important for you?

Is this will be available in 1.1 or we we can expect delay? According to #3585 feature freeze is in two days.

Is this will be available in 1.1 or we we can expect delay? According to #3585 feature freeze is in two days.

It looks like CRI/containerd support will make 1.1.

You have explicitly mentioned containerd, any reason that this implementation may not work for cri-o? We get rid of docker-related parts.

@ChiefAlexander @voidengineer @lorenz @AshleyByeUK @mskarbek @runiq @robodendron @sidcarter @martinbaillie @aaglenn @maximusfloydus
containerD and CRI-O support are merged and available in v1.1.0-rc2 feel free to try it out.


Make HEADERS frame payload non-indirect

Motivation:
In previous patches we shrank the size of HTTP2Frame by making various data types indirect in the frame payload. This included HEADERS, which is unfortunte as HEADERS frames are quite common.
This patch changes the layout of the HEADERS frame to remove the indirect case.
Modifications:

Move END_STREAM into an OptionSet.
Turn the two optional bits into flags in the aforementioned OptionSet
Replace the properties with computed properties.
Remove the indirect case

Result:
HEADERS frames are cheaper.

Can we add a unit test that checks that the size of FramePayload/HTTP2Frame doesn't exceed the maximum size of the inline existential storage? IIRC that would be 3 words / 24 Bytes on 64-bit systems.

Done.

The CI failure is interesting:
13:31:41 /code/Sources/NIOHTTP2/HTTP2Frame.swift:257:17: error: stored property 'booleans' of 'Sendable'-conforming struct 'Headers' has non-sendable type 'HTTP2Frame.FramePayload.Headers.Booleans'
13:31:41             var booleans: Booleans
13:31:41                 ^
13:31:41 /code/Sources/NIOHTTP2/HTTP2Frame.swift:226:20: note: consider making struct 'Booleans' conform to the 'Sendable' protocol
13:31:41             struct Booleans: OptionSet {
13:31:41                    ^
13:31:41                                       , Sendable

Booleans is an internal struct which is just made up of a single stored property which is Sendable. The compiler should be able to automatically synthesise Sendable conformance for us. Something is wrong here. Maybe @usableFromInline or the nesting is screwing with the compiler inference.

Updated.

Now we are hitting depreciation warnings because of the new NIO release:
15:38:56 /code/Tests/NIOHTTP2Tests/ConfiguringPipelineAsyncMultiplexerTests.swift:174:25: error: 'init(synchronouslyWrapping:configuration:)' is deprecated: This method has been deprecated since it defaults to deinit based resource teardown
15:38:56                     try NIOAsyncChannel(
15:38:56                         ^
15:38:56 /code/Tests/NIOHTTP2Tests/ConfiguringPipelineAsyncMultiplexerTests.swift:174:25: note: use 'init(wrappingChannelSynchronously:configuration:)' instead
15:38:56                     try NIOAsyncChannel(
15:38:56                         ^
15:38:56 /code/Tests/NIOHTTP2Tests/ConfiguringPipelineAsyncMultiplexerTests.swift:192:66: error: 'inbound' is deprecated: Use the executeThenClose scoped method instead.
15:38:56                     for try await receivedFrame in streamChannel.inbound {
15:38:56                                                                  ^
15:38:56 /code/Tests/NIOHTTP2Tests/ConfiguringPipelineAsyncMultiplexerTests.swift:195:49: error: 'outbound' is deprecated: Use the executeThenClose scoped method instead.
15:38:56                         try await streamChannel.outbound.write(ConfiguringPipelineAsyncMultiplexerTests.responseFramePayload)

I have reported the Sendable issue: https://github.com/apple/swift/issues/70019


Keep getting Connection Reset

pynetbox version
v7.2.0
NetBox version
v3.0.12
Python version
3.10
Steps to Reproduce

Get an API:

nb = pynetbox.api(args.api_url, token=args.token)

Create a VRF:

vrf = nb.ipam.vrfs.create(name="name", description="description")

Then try to obtain a cluster id

cluster_id = nb.virtualization.clusters.filter(cluster=cluster).__next__().id

This fails with a ConnectionResetError:
ERROR | ('Connection aborted.', ConnectionResetError(104, 'Connection reset by peer'))
Traceback (most recent call last):
  File "/home/rostskadat/git/upworks/Freelance-73-Gitlab-CICD/.venv/lib/python3.10/site-packages/urllib3/connectionpool.py", line 790, in urlopen
    response = self._make_request(
  File "/home/rostskadat/git/upworks/Freelance-73-Gitlab-CICD/.venv/lib/python3.10/site-packages/urllib3/connectionpool.py", line 536, in _make_request
    response = conn.getresponse()
  File "/project/.venv/lib/python3.10/site-packages/urllib3/connection.py", line 461, in getresponse
    httplib_response = super().getresponse()
  File "/usr/lib/python3.10/http/client.py", line 1375, in getresponse
    response.begin()
  File "/usr/lib/python3.10/http/client.py", line 318, in begin
    version, status, reason = self._read_status()
  File "/usr/lib/python3.10/http/client.py", line 279, in _read_status
    line = str(self.fp.readline(_MAXLINE + 1), "iso-8859-1")
  File "/usr/lib/python3.10/socket.py", line 705, in readinto
    return self._sock.recv_into(b)
ConnectionResetError: [Errno 104] Connection reset by peer

Expected Behavior
The error is intermittent. If I add an HTTPAdapter with a retry then it eventually works fine.
Observed Behavior
A ConnectionResetError was raised

I'd suggest moving this issue to a discussion as pynetbox does not raise ConnectionResetErrors, so the user needs some other help with the system.
There is no mention about the runtime environment but the output it not from from a pure cluster_id = ... statement.

Hello @markkuleinio ,
Thanks for your reply. I understand that it might not be an issue with pynetbox proper but I wasn't really sure where to start. I will however move this to a discussion.
Regards


Fix many compiler warnings.

This removes about 60 compile warnings on Mac with clang.
2 others which I'll leave for Tom as I'm not sure what he wants to do:
test/script_tests.cpp:920:58: warning: variable 'amount' is uninitialized when used here [-Wuninitialized]
uint256 hash1 = SignatureHash(scriptPubKey, txTo, 0, amount, SIGHASH_ALL);
^~~~~~
streaming/MessageBuilder.cpp:49:21: warning: comparison of constant 8 with expression of type 'Streaming::ValueType' is always true [-Wtautological-constant-out-of-range-compare]
assert(type < 8);
~~~~ ^ ~

test/script_tests.cpp:920:58: warning: variable 'amount' is uninitialized when used here

Good find :)
I directly blame upstream for being so sloppy with their naming. Using the leading "C" in "CAmount" would lead you to believe it is a class, as CSomething is used that way everywhere. In this case, CAmount is a simple typedef to a int64_t.
The main difference between those two is that one needs to be initialized, the other does not...
Thanks for these, I'll merge it when Teamcity give the All Ok.


[Suggestion] ASEAN flag

Could you please add ASEAN flag? Thank you so much.

Similar to #359, this flag doesn't fit in because it does not have an ISO 3166-1 alpha-2 country code.


docker run error

parallels@ubuntu-linux-20-04-desktop:~$ docker run --rm -it jonasvautherin/px4-gazebo-headless:1.13.1
[  0%] Built target ver_gen
[  0%] Generating ../../logs
[  0%] Built target git_gazebo
[  0%] Built target parameters_xml
[  0%] Built target logs_symlink
[  0%] Built target events_header
[  0%] Built target flighttasks_generated
[  0%] Built target uorb_headers
[  0%] Built target actuators_json
[  0%] Built target drivers_board
[  0%] Built target mixer_gen_6dof
[  0%] Built target mixer_gen
[  0%] Built target output_functions_header
[  0%] Built target version
[  0%] Built target wind_estimator
[  0%] Built target world_magnetic_model
[  0%] Built target git_gps_devices
[  0%] Built target git_mavlink_v2
[  0%] Performing build step for 'sitl_gazebo'
make[5]: warning: -jN forced in submake: disabling jobserver mode.
[  0%] Built target events_json
[  0%] Built target tinybson
[  0%] Built target perf
[  2%] Built target work_queue
[  2%] Built target geo
[  2%] Built target MixerBase
[  8%] Built target std_msgs
[ 19%] Built target sensor_msgs
[  2%] Built target mavlink_c_generate
[  2%] Built target component_general_json
[ 22%] Built target uorb_msgs
[ 23%] Built target mav_msgs
[ 27%] Built target physics_msgs
[ 22%] Built target HelicopterMixer
[ 23%] Built target MultirotorMixer
[ 29%] Built target klt_feature_tracker
[ 24%] Built target parameters
[ 31%] Built target nav_msgs
[ 24%] Built target NullMixer
[ 24%] Built target SimpleMixer
[ 46%] Built target models_gen
[ 25%] Built target romfs_gen_files_target
[ 25%] Built target px4_work_queue
[ 26%] Built target mixer
[ 48%] Built target gazebo_uuv_plugin
[ 50%] Built target gazebo_lidar_plugin
[ 27%] Built target px4_platform
[ 27%] Built target lockstep_scheduler
[ 53%] Built target gazebo_user_camera_plugin
[ 55%] Built target gazebo_groundtruth_plugin
[ 28%] Built target px4_daemon
[ 29%] Built target px4_layer
[ 57%] Built target gazebo_sonar_plugin
[ 59%] Built target gazebo_camera_manager_plugin
[ 30%] Built target bezier
[ 30%] Built target hysteresis
[ 30%] Built target airspeed
[ 62%] Built target OpticalFlow
[ 30%] Built target systemlib
[ 31%] Built target cdev
[ 31%] Built target battery
[ 63%] Built target gazebo_opticalflow_mockup_plugin
[ 31%] Built target circuit_breaker
[ 31%] Built target CollisionPrevention
[ 32%] Built target controllib
[ 65%] Built target gazebo_airspeed_plugin
[ 67%] Built target gazebo_airship_dynamics_plugin
[ 32%] Built target conversion
[ 32%] Built target l1
[ 32%] Built target landing_slope
[ 34%] Built target mathlib
[ 69%] Built target gazebo_controller_interface
[ 34%] Built target mixer_module
[ 35%] Built target motion_planning
[ 71%] Built target gazebo_vision_plugin
[ 35%] Built target npfg
[ 35%] Built target pid
[ 36%] Built target rc
[ 36%] Built target SlewRate
[ 36%] Built target SystemIdentification
[ 73%] Built target gazebo_gimbal_controller_plugin
[ 37%] Built target sensor_calibration
[ 75%] Built target gazebo_imu_plugin
[ 38%] Built target tecs
[ 38%] Built target tunes
[ 39%] Built target WeatherVane
[ 76%] Built target gazebo_wind_plugin
[ 39%] Built target arch_tone_alarm
[ 39%] Built target ArmAuthorization
[ 39%] Built target failure_detector
[ 79%] Built target gazebo_mavlink_interface
[ 40%] Built target HealthFlags
[ 40%] Built target ControlAllocation
[ 41%] Built target ActuatorEffectiveness
[ 80%] Built target gazebo_motor_model
[ 41%] Built target EKF2Utility
[ 42%] Built target FlightTask
[ 42%] Built target launchdetection
[ 81%] Built target gazebo_catapult_plugin
[ 42%] Built target runway_takeoff
[ 43%] Built target AttitudeControl
[ 44%] Built target zero_order_hover_thrust_ekf
[ 83%] Built target gazebo_multirotor_base_plugin
[ 44%] Built target PositionControl
[ 44%] Built target Takeoff
[ 45%] Built target RateControl
[ 85%] Built target gazebo_magnetometer_plugin
[ 46%] Built target geofence_breach_avoidance
[ 47%] Built target data_validator
[ 86%] Built target gazebo_usv_dynamics_plugin
[ 48%] Built target vehicle_acceleration
[ 48%] Built target vehicle_air_data
[ 48%] Built target vehicle_angular_velocity
[ 87%] Built target gazebo_barometer_plugin
[ 48%] Built target vehicle_gps_position
[ 88%] Built target gazebo_parachute_plugin
[ 50%] Built target vehicle_magnetometer
[ 50%] Built target vehicle_imu
[ 51%] Built target avoidance
[ 89%] Built target gazebo_drop_plugin
[ 51%] Built target drivers_accelerometer
[ 52%] Built target uORB
[ 90%] Built target ForceVisual
[ 52%] Built target drivers_gyroscope
[ 53%] Built target drivers_magnetometer
[ 54%] Built target modules__commander__commander_tests
[ 56%] Built target PreFlightCheck
[ 91%] Built target gazebo_gst_camera_plugin
[ 92%] Built target gazebo_irlock_plugin
[ 56%] Built target modules__control_allocator
[ 56%] Built target modules__dataman
[ 59%] Built target modules__ekf2
[ 60%] Built target modules__events
[ 93%] Built target gazebo_gps_plugin
[ 60%] Built target FlightTaskUtility
[ 96%] Built target gazebo_video_stream_widget
[ 60%] Built target FlightTaskDescend
[ 61%] Built target FlightTaskFailsafe
[ 61%] Built target modules__fw_att_control
[ 98%] Built target LiftDragPlugin
[ 61%] Built target fw_autotune_attitude_control
[ 62%] Built target modules__fw_pos_control_l1
[100%] Built target gazebo_opticalflow_plugin
[ 63%] Built target drivers__gimbal
[ 63%] Built target modules__gyro_calibration
[ 64%] Built target modules__gyro_fft
[ 64%] No install step for 'sitl_gazebo'
[ 65%] Built target modules__land_detector
[ 65%] Built target modules__landing_target_estimator
[ 67%] Built target modules__load_mon
[ 68%] Completed 'sitl_gazebo'
[ 70%] Built target modules__local_position_estimator
[ 69%] Built target modules__mag_bias_estimator
[ 70%] Built target modules__logger
[ 70%] Built target sitl_gazebo
[ 71%] Built target module__manual_control
[ 71%] Built target modules__mavlink__mavlink_tests
[ 72%] Built target modules__mc_att_control
[ 72%] Built target mc_autotune_attitude_control
[ 72%] Built target modules__mc_hover_thrust_estimator
[ 72%] Built target modules__mc_pos_control
[ 74%] Built target modules__mavlink
[ 74%] Built target modules__mc_rate_control
[ 74%] Built target modules__rc_update
[ 75%] Built target modules__replay
[ 75%] Built target modules__rover_pos_control
[ 77%] Built target modules__navigator
[ 77%] Built target modules__sensors
[ 78%] Built target modules__simulator__battery_simulator
[ 78%] Built target modules__simulator__sensor_baro_sim
[ 78%] Built target modules__simulator
[ 78%] Built target modules__simulator__sensor_gps_sim
[ 78%] Built target modules__simulator__sensor_mag_sim
[ 80%] Built target modules__uuv_att_control
[ 80%] Built target modules__temperature_compensation
[ 80%] Built target modules__uuv_pos_control
[ 80%] Built target modules__vtol_att_control
[ 81%] Built target systemcmds__dyn
[ 81%] Built target systemcmds__actuator_test
[ 81%] Built target systemcmds__failure
[ 81%] Built target systemcmds__led_control
[ 82%] Built target systemcmds__motor_test
[ 82%] Built target systemcmds__mixer
[ 82%] Built target systemcmds__param
[ 82%] Built target systemcmds__perf
[ 82%] Built target systemcmds__sd_bench
[ 82%] Built target systemcmds__pwm
[ 84%] Built target systemcmds__shutdown
[ 85%] Built target systemcmds__system_time
[ 85%] Built target systemcmds__tests__hrt_test
[ 88%] Built target systemcmds__tests
[ 88%] Built target systemcmds__topic_listener
[ 89%] Built target systemcmds__tune_control
[ 89%] Built target systemcmds__uorb
[ 89%] Built target systemcmds__ver
[ 89%] Built target systemcmds__work_queue
[ 89%] Built target modules__fake_imu
[ 89%] Built target modules__fake_gps
[ 89%] Built target examples__fake_magnetometer
[ 89%] Built target examples__fixedwing_control
[ 90%] Built target examples__hello
[ 90%] Built target examples__px4_mavlink_debug
[ 90%] Built target examples__px4_simple_app
[ 90%] Built target examples__rover_steering_control
[ 91%] Built target examples__uuv_example_app
[ 91%] Built target examples__work_item
[ 91%] Built target lib__cdev__test__cdev_test
[ 91%] Built target lib__controllib__controllib_test
[ 91%] Built target lib__rc__rc_tests
[ 91%] Built target modules__uORB__uORB_tests
[ 92%] Built target lib__work_queue__test__wqueue_test
[ 92%] Built target drivers__camera_trigger
[ 93%] Built target drivers__pwm_out_sim
[ 93%] Built target drivers__gps
[ 93%] Built target examples__rpm_simulator
[ 94%] Built target drivers__tone_alarm
[ 94%] Built target modules__airship_att_control
[ 94%] Built target modules__airspeed_selector
[ 94%] Built target modules__attitude_estimator_q
[ 95%] Built target modules__camera_feedback
[ 95%] Built target ArmStateMachine
[ 95%] Built target FlightTaskAuto
[ 95%] Built target FlightTaskManualAltitude
[ 95%] Built target FlightTaskTransition
[ 95%] Built target FlightTaskAutoFollowMe
[ 95%] Built target FlightTaskManualAltitudeSmoothVel
[ 96%] Built target modules__commander
[ 96%] Built target FlightTaskManualPosition
[ 96%] Built target FlightTaskManualAcceleration
[ 96%] Built target FlightTaskOrbit
[ 97%] Built target FlightTaskManualPositionSmoothVel
[ 98%] Built target modules__flight_mode_manager
[100%] Built target px4
Scanning dependencies of target gazebo_iris__empty
SITL ARGS
sitl_bin: /root/Firmware/build/px4_sitl_default/bin/px4
debugger: none
program: gazebo
model: iris
world: empty
src_path: /root/Firmware
build_path: /root/Firmware/build/px4_sitl_default
GAZEBO_PLUGIN_PATH :/root/Firmware/build/px4_sitl_default/build_gazebo
GAZEBO_MODEL_PATH :/root/Firmware/Tools/sitl_gazebo/models
LD_LIBRARY_PATH :/root/Firmware/build/px4_sitl_default/build_gazebo
Using: /root/Firmware/Tools/sitl_gazebo/models/iris/iris.sdf
ALSA lib confmisc.c:767:(parse_card) cannot find card '0'
ALSA lib conf.c:4528:(_snd_config_evaluate) function snd_func_card_driver returned error: No such file or directory
ALSA lib confmisc.c:392:(snd_func_concat) error evaluating strings
ALSA lib conf.c:4528:(_snd_config_evaluate) function snd_func_concat returned error: No such file or directory
ALSA lib confmisc.c:1246:(snd_func_refer) error evaluating name
ALSA lib conf.c:4528:(_snd_config_evaluate) function snd_func_refer returned error: No such file or directory
ALSA lib conf.c:5007:(snd_config_expand) Evaluate error: No such file or directory
ALSA lib pcm.c:2495:(snd_pcm_open_noupdate) Unknown PCM default
AL lib: (EE) ALCplaybackAlsa_open: Could not open playback device 'default': No such file or directory
not running gazebo gui
SITL COMMAND: "/root/Firmware/build/px4_sitl_default/bin/px4" "/root/Firmware/build/px4_sitl_default"/etc -s etc/init.d-posix/rcS -t "/root/Firmware"/test_data
Creating symlink /root/Firmware/build/px4_sitl_default/etc -> /root/Firmware/build/px4_sitl_default/tmp/rootfs/etc

______  __   __    ___
| ___ \ \ \ / /   /   |
| |_/ /  \ V /   / /| |
|  __/   /   \  / /_| |
| |     / /^\ \ \___  |
\_|     \/   \/     |_/

px4 starting.

INFO  [px4] Calling startup script: /bin/sh etc/init.d-posix/rcS 0
INFO  [init] found model autostart file as SYS_AUTOSTART=10016
INFO  [param] selected parameter default file eeprom/parameters_10016
[param] parameter file not found, creating eeprom/parameters_10016
  SYS_AUTOCONFIG: curr: 0 -> new: 1
  SYS_AUTOSTART: curr: 0 -> new: 10016
  CAL_ACC0_ID: curr: 0 -> new: 1310988
  CAL_GYRO0_ID: curr: 0 -> new: 1310988
  CAL_ACC1_ID: curr: 0 -> new: 1310996
  CAL_GYRO1_ID: curr: 0 -> new: 1310996
  CAL_ACC2_ID: curr: 0 -> new: 1311004
  CAL_GYRO2_ID: curr: 0 -> new: 1311004
* CAL_MAG0_ID: curr: 0 -> new: 197388
* CAL_MAG1_ID: curr: 0 -> new: 197644
* SENS_BOARD_X_OFF: curr: 0.0000 -> new: 0.0000
* SENS_DPRES_OFF: curr: 0.0000 -> new: 0.0010
* SYS_AUTOCONFIG: curr: 1 -> new: 0
* IMU_INTEG_RATE: curr: 200 -> new: 250
INFO  [dataman] data manager file './dataman' size is 7866640 bytes
PX4 SIM HOST: localhost
INFO  [simulator] Waiting for simulator to accept connection on TCP port 4560
INFO  [simulator] Simulator connected on TCP port 4560.
INFO  [commander] LED: open /dev/led0 failed (22)
* PWM_AUX_OUT: curr: 0 -> new: 1234
* PWM_MAIN_OUT: curr: 0 -> new: 1234
INFO  [init] Mixer: etc/mixers/quad_w.main.mix on /dev/pwm_output0
INFO  [init] setting PWM_AUX_OUT none
ERROR [mavlink] invalid partner ip '::ffff:<IP_ADDRESS>'

### Description
This module implements the MAVLink protocol, which can be used on a Serial link or UDP network connect
Usage: mavlink <command> [arguments...]
 Commands:

   start         Start a new instance
     [-d <val>]  Select Serial Device
                 values: <file:dev>, default: /dev/ttyS1
     [-b <val>]  Baudrate (can also be p:<param_name>)
                 default: 57600
     [-r <val>]  Maximum sending data rate in B/s (if 0, use baudrate / 20)
                 default: 0
     [-p]        Enable Broadcast
     [-u <val>]  Select UDP Network Port (local)
                 default: 14556
     [-o <val>]  Select UDP Network Port (remote)
                 default: 14550
     [-t <val>]  Partner IP (broadcasting can be enabled via -p flag)
                 default: <IP_ADDRESS>
     [-m <val>]  Mode: sets default streams and rates
                 values: custom|camera|onboard|osd|magic|config|iridium|minimal|extvision|extvisionmin|gimbal, default:
     [-n <val>]  wifi/ethernet interface name
                 values: <interface_name>
     [-f]        Enable message forwarding to other Mavlink instances
     [-w]        Wait to send, until first message received
     [-x]        Enable FTP
     [-z]        Force hardware flow control always on
     [-Z]        Force hardware flow control always off

   stop-all      Stop all instances

   stop          Stop a running instance
     [-u <val>]  Select Mavlink instance via local Network Port
     [-d <val>]  Select Mavlink instance via Serial Device
                 values: <file:dev>

   status        Print status for all instances
     [streams  ] Print all enabled streams

   stream        Configure the sending rate of a stream for a running instance
     [-u <val>]  Select Mavlink instance via local Network Port
     [-d <val>]  Select Mavlink instance via Serial Device
                 values: <file:dev>
     -s <val>    Mavlink stream to configure
     -r <val>    Rate in Hz (0 = turn off, -1 = set to default)

   boot_complete Enable sending of messages. (Must be) called as last step in startup script.
ERROR [px4] Startup script returned with return value: 65280
[100%] Built target gazebo_iris__empty
parallels@ubuntu-linux-20-04-desktop:~$

uname -ar?
docker --version?

parallels@ubuntu-linux-20-04-desktop:~/Desktop$ uname -ar
Linux ubuntu-linux-20-04-desktop 5.15.0-52-generic #58~20.04.1-Ubuntu SMP Thu Oct 13 13:10:09 UTC 2022 aarch64 aarch64 aarch64 GNU/Linux
parallels@ubuntu-linux-20-04-desktop:~/Desktop$ docker --version
Docker version 20.10.20, build 9fdeb9c
parallels@ubuntu-linux-20-04-desktop:~/Desktop$ docker run --rm -it jonasvautherin/px4-gazebo-headless:1.13.0
WARNING: The requested image's platform (linux/amd64) does not match the detected host platform (linux/arm64/v8) and no specific platform was requested
exec /root/entrypoint.sh: exec format error

@JonasVautherin

It looks like you're passing an IPv6 address rather than an IPv4, so it fails to parse that.

Yeah something is different in this VM (looks like a parallels VM), and the script fails to detect the host IP properly:

ERROR [mavlink] invalid partner ip '::ffff:<IP_ADDRESS>'

Also I guess it's an M1? Support for arm was added after 1.13.0, IIRC :sweat_smile:

WARNING: The requested image's platform (linux/amd64) does not match the detected host platform (linux/arm64/v8) and no specific platform was requested
exec /root/entrypoint.sh: exec format error

yes, it's m1 MacBook Pro, I running arm-based Ubuntu

Could you run:
docker run --rm -it --entrypoint /bin/bash jonasvautherin/px4-gazebo-headless:1.13.1

And there in the terminal run:
ip a
ip route

And show the output here?

now the ip is ok :
parallels@ubuntu-linux-20-04-desktop:~/Desktop$ docker run --rm -it jonasvautherin/px4-gazebo-headless:1.13.1
[  0%] Built target ver_gen
[  0%] Generating ../../logs
[  0%] Built target git_gazebo
[  0%] Built target parameters_xml
[  0%] Built target logs_symlink
[  0%] Built target events_header
[  0%] Built target flighttasks_generated
[  0%] Built target uorb_headers
[  0%] Built target actuators_json
[  0%] Built target drivers_board
[  0%] Built target mixer_gen_6dof
[  0%] Built target mixer_gen
[  0%] Built target output_functions_header
[  0%] Built target version
[  0%] Built target wind_estimator
[  0%] Built target world_magnetic_model
[  0%] Built target git_gps_devices
[  0%] Built target git_mavlink_v2
[  0%] Performing build step for 'sitl_gazebo'
make[5]: warning: -jN forced in submake: disabling jobserver mode.
[  0%] Built target events_json
[  0%] Built target tinybson
[  0%] Built target perf
[  2%] Built target work_queue
[  2%] Built target geo
[  3%] Built target std_msgs
[ 19%] Built target sensor_msgs
[  2%] Built target MixerBase
[  2%] Built target mavlink_c_generate
[  2%] Built target component_general_json
[ 23%] Built target physics_msgs
[ 27%] Built target mav_msgs
[ 22%] Built target uorb_msgs
[ 22%] Built target HelicopterMixer
[ 29%] Built target klt_feature_tracker
[ 31%] Built target nav_msgs
[ 23%] Built target MultirotorMixer
[ 24%] Built target parameters
[ 46%] Built target models_gen
[ 24%] Built target NullMixer
[ 24%] Built target SimpleMixer
[ 25%] Built target romfs_gen_files_target
[ 25%] Built target px4_work_queue
[ 48%] Built target gazebo_uuv_plugin
[ 26%] Built target mixer
[ 50%] Built target gazebo_lidar_plugin
[ 27%] Built target px4_platform
[ 27%] Built target lockstep_scheduler
[ 53%] Built target gazebo_user_camera_plugin
[ 55%] Built target gazebo_groundtruth_plugin
[ 28%] Built target px4_daemon
[ 29%] Built target px4_layer
[ 57%] Built target gazebo_sonar_plugin
[ 59%] Built target gazebo_camera_manager_plugin
[ 30%] Built target bezier
[ 30%] Built target hysteresis
[ 30%] Built target airspeed
[ 62%] Built target OpticalFlow
[ 63%] Built target gazebo_opticalflow_mockup_plugin
[ 31%] Built target cdev
[ 31%] Built target battery
[ 31%] Built target systemlib
[ 65%] Built target gazebo_airspeed_plugin
[ 31%] Built target circuit_breaker
[ 31%] Built target CollisionPrevention
[ 32%] Built target controllib
[ 67%] Built target gazebo_airship_dynamics_plugin
[ 32%] Built target conversion
[ 32%] Built target l1
[ 32%] Built target landing_slope
[ 69%] Built target gazebo_controller_interface
[ 34%] Built target mathlib
[ 34%] Built target mixer_module
[ 35%] Built target motion_planning
[ 71%] Built target gazebo_vision_plugin
[ 35%] Built target npfg
[ 35%] Built target pid
[ 36%] Built target rc
[ 73%] Built target gazebo_gimbal_controller_plugin
[ 36%] Built target SlewRate
[ 37%] Built target sensor_calibration
[ 75%] Built target gazebo_imu_plugin
[ 37%] Built target SystemIdentification
[ 38%] Built target tecs
[ 38%] Built target tunes
[ 39%] Built target WeatherVane
[ 76%] Built target gazebo_wind_plugin
[ 39%] Built target arch_tone_alarm
[ 39%] Built target failure_detector
[ 39%] Built target ArmAuthorization
[ 79%] Built target gazebo_mavlink_interface
[ 40%] Built target HealthFlags
[ 40%] Built target ControlAllocation
[ 80%] Built target gazebo_motor_model
[ 41%] Built target ActuatorEffectiveness
[ 41%] Built target EKF2Utility
[ 42%] Built target FlightTask
[ 81%] Built target gazebo_catapult_plugin
[ 42%] Built target launchdetection
[ 42%] Built target runway_takeoff
[ 83%] Built target gazebo_multirotor_base_plugin
[ 43%] Built target AttitudeControl
[ 44%] Built target zero_order_hover_thrust_ekf
[ 44%] Built target PositionControl
[ 44%] Built target Takeoff
[ 85%] Built target gazebo_magnetometer_plugin
[ 45%] Built target RateControl
[ 86%] Built target gazebo_usv_dynamics_plugin
[ 46%] Built target geofence_breach_avoidance
[ 47%] Built target data_validator
[ 48%] Built target vehicle_acceleration
[ 87%] Built target gazebo_barometer_plugin
[ 48%] Built target vehicle_angular_velocity
[ 48%] Built target vehicle_air_data
[ 48%] Built target vehicle_gps_position
[ 88%] Built target gazebo_parachute_plugin
[ 50%] Built target vehicle_imu
[ 50%] Built target vehicle_magnetometer
[ 51%] Built target avoidance
[ 89%] Built target gazebo_drop_plugin
[ 90%] Built target ForceVisual
[ 52%] Built target drivers_accelerometer
[ 52%] Built target uORB
[ 52%] Built target drivers_gyroscope
[ 52%] Built target lib__rc__rc_tests
[ 53%] Built target drivers_magnetometer
[ 91%] Built target gazebo_gst_camera_plugin
[ 92%] Built target gazebo_irlock_plugin
[ 53%] Built target modules__uORB__uORB_tests
[ 54%] Built target lib__work_queue__test__wqueue_test
[ 54%] Built target drivers__camera_trigger
[ 55%] Built target drivers__gps
[ 55%] Built target examples__rpm_simulator
[ 55%] Built target drivers__pwm_out_sim
[ 93%] Built target gazebo_gps_plugin
[ 56%] Built target drivers__tone_alarm
[ 96%] Built target gazebo_video_stream_widget
[ 56%] Built target modules__airship_att_control
[ 56%] Built target modules__airspeed_selector
[ 56%] Built target modules__attitude_estimator_q
[ 98%] Built target LiftDragPlugin
[100%] Built target gazebo_opticalflow_plugin
[ 57%] Built target modules__camera_feedback
[ 59%] Built target PreFlightCheck
[ 60%] Built target modules__commander__commander_tests
[ 60%] No install step for 'sitl_gazebo'
[ 60%] Built target modules__control_allocator
[ 60%] Built target modules__dataman
[ 63%] Built target modules__ekf2
[ 64%] Completed 'sitl_gazebo'
[ 65%] Built target modules__events
[ 65%] Built target FlightTaskUtility
[ 65%] Built target FlightTaskDescend
[ 67%] Built target FlightTaskFailsafe
[ 67%] Built target sitl_gazebo
[ 67%] Built target modules__fw_att_control
[ 67%] Built target fw_autotune_attitude_control
[ 68%] Built target modules__fw_pos_control_l1
[ 68%] Built target modules__gyro_calibration
[ 69%] Built target drivers__gimbal
[ 70%] Built target modules__gyro_fft
[ 71%] Built target modules__land_detector
[ 72%] Built target modules__load_mon
[ 72%] Built target modules__landing_target_estimator
[ 73%] Built target modules__local_position_estimator
[ 74%] Built target module__manual_control
[ 75%] Built target modules__logger
[ 75%] Built target modules__mag_bias_estimator
[ 76%] Built target mc_autotune_attitude_control
[ 76%] Built target modules__mc_att_control
[ 76%] Built target modules__mavlink__mavlink_tests
[ 76%] Built target modules__mc_hover_thrust_estimator
[ 76%] Built target modules__mc_pos_control
[ 76%] Built target modules__mc_rate_control
[ 78%] Built target modules__mavlink
[ 78%] Built target modules__rc_update
[ 79%] Built target modules__replay
[ 81%] Built target modules__navigator
[ 81%] Built target modules__rover_pos_control
[ 81%] Built target modules__sensors
[ 82%] Built target modules__simulator__battery_simulator
[ 82%] Built target modules__simulator
[ 82%] Built target modules__simulator__sensor_baro_sim
[ 82%] Built target modules__simulator__sensor_gps_sim
[ 82%] Built target modules__simulator__sensor_mag_sim
[ 84%] Built target modules__uuv_att_control
[ 85%] Built target modules__temperature_compensation
[ 85%] Built target modules__uuv_pos_control
[ 85%] Built target modules__vtol_att_control
[ 86%] Built target systemcmds__dyn
[ 86%] Built target systemcmds__actuator_test
[ 86%] Built target systemcmds__failure
[ 86%] Built target systemcmds__led_control
[ 87%] Built target systemcmds__mixer
[ 87%] Built target systemcmds__motor_test
[ 87%] Built target systemcmds__param
[ 87%] Built target systemcmds__perf
[ 87%] Built target systemcmds__pwm
[ 87%] Built target systemcmds__sd_bench
[ 88%] Built target systemcmds__shutdown
[ 88%] Built target systemcmds__system_time
[ 89%] Built target systemcmds__tests__hrt_test
[ 89%] Built target systemcmds__topic_listener
[ 92%] Built target systemcmds__tests
[ 92%] Built target systemcmds__tune_control
[ 93%] Built target systemcmds__uorb
[ 93%] Built target systemcmds__ver
[ 93%] Built target systemcmds__work_queue
[ 93%] Built target modules__fake_imu
[ 93%] Built target modules__fake_gps
[ 93%] Built target examples__fake_magnetometer
[ 93%] Built target examples__fixedwing_control
[ 94%] Built target examples__hello
[ 94%] Built target examples__px4_mavlink_debug
[ 94%] Built target examples__px4_simple_app
[ 94%] Built target examples__rover_steering_control
[ 95%] Built target examples__uuv_example_app
[ 95%] Built target examples__work_item
[ 95%] Built target lib__cdev__test__cdev_test
[ 95%] Built target lib__controllib__controllib_test
[ 95%] Built target ArmStateMachine
[ 95%] Built target FlightTaskAuto
[ 95%] Built target FlightTaskManualAltitude
[ 95%] Built target FlightTaskTransition
[ 95%] Built target FlightTaskAutoFollowMe
[ 96%] Built target FlightTaskManualPosition
[ 96%] Built target FlightTaskManualAltitudeSmoothVel
[ 96%] Built target modules__commander
[ 97%] Built target FlightTaskManualAcceleration
[ 97%] Built target FlightTaskOrbit
[ 97%] Built target FlightTaskManualPositionSmoothVel
[ 98%] Built target modules__flight_mode_manager
[100%] Built target px4
Scanning dependencies of target gazebo_iris__empty
SITL ARGS
sitl_bin: /root/Firmware/build/px4_sitl_default/bin/px4
debugger: none
program: gazebo
model: iris
world: empty
src_path: /root/Firmware
build_path: /root/Firmware/build/px4_sitl_default
GAZEBO_PLUGIN_PATH :/root/Firmware/build/px4_sitl_default/build_gazebo
GAZEBO_MODEL_PATH :/root/Firmware/Tools/sitl_gazebo/models
LD_LIBRARY_PATH :/root/Firmware/build/px4_sitl_default/build_gazebo
Using: /root/Firmware/Tools/sitl_gazebo/models/iris/iris.sdf
ALSA lib confmisc.c:767:(parse_card) cannot find card '0'
ALSA lib conf.c:4528:(_snd_config_evaluate) function snd_func_card_driver returned error: No such file or directory
ALSA lib confmisc.c:392:(snd_func_concat) error evaluating strings
ALSA lib conf.c:4528:(_snd_config_evaluate) function snd_func_concat returned error: No such file or directory
ALSA lib confmisc.c:1246:(snd_func_refer) error evaluating name
ALSA lib conf.c:4528:(_snd_config_evaluate) function snd_func_refer returned error: No such file or directory
ALSA lib conf.c:5007:(snd_config_expand) Evaluate error: No such file or directory
ALSA lib pcm.c:2495:(snd_pcm_open_noupdate) Unknown PCM default
AL lib: (EE) ALCplaybackAlsa_open: Could not open playback device 'default': No such file or directory
not running gazebo gui
SITL COMMAND: "/root/Firmware/build/px4_sitl_default/bin/px4" "/root/Firmware/build/px4_sitl_default"/etc -s etc/init.d-posix/rcS -t "/root/Firmware"/test_data
Creating symlink /root/Firmware/build/px4_sitl_default/etc -> /root/Firmware/build/px4_sitl_default/tmp/rootfs/etc

______  __   __    ___
| ___ \ \ \ / /   /   |
| |_/ /  \ V /   / /| |
|  __/   /   \  / /_| |
| |     / /^\ \ \___  |
\_|     \/   \/     |_/

px4 starting.

INFO  [px4] Calling startup script: /bin/sh etc/init.d-posix/rcS 0
INFO  [init] found model autostart file as SYS_AUTOSTART=10016
INFO  [param] selected parameter default file eeprom/parameters_10016
[param] parameter file not found, creating eeprom/parameters_10016
  SYS_AUTOCONFIG: curr: 0 -> new: 1
  SYS_AUTOSTART: curr: 0 -> new: 10016
  CAL_ACC0_ID: curr: 0 -> new: 1310988
  CAL_GYRO0_ID: curr: 0 -> new: 1310988
  CAL_ACC1_ID: curr: 0 -> new: 1310996
  CAL_GYRO1_ID: curr: 0 -> new: 1310996
  CAL_ACC2_ID: curr: 0 -> new: 1311004
  CAL_GYRO2_ID: curr: 0 -> new: 1311004
* CAL_MAG0_ID: curr: 0 -> new: 197388
* CAL_MAG1_ID: curr: 0 -> new: 197644
* SENS_BOARD_X_OFF: curr: 0.0000 -> new: 0.0000
* SENS_DPRES_OFF: curr: 0.0000 -> new: 0.0010
* SYS_AUTOCONFIG: curr: 1 -> new: 0
* IMU_INTEG_RATE: curr: 200 -> new: 250
INFO  [dataman] data manager file './dataman' size is 7866640 bytes
PX4 SIM HOST: localhost
INFO  [simulator] Waiting for simulator to accept connection on TCP port 4560
INFO  [simulator] Simulator connected on TCP port 4560.
INFO  [commander] LED: open /dev/led0 failed (22)
* PWM_AUX_OUT: curr: 0 -> new: 1234
* PWM_MAIN_OUT: curr: 0 -> new: 1234
INFO  [init] Mixer: etc/mixers/quad_w.main.mix on /dev/pwm_output0
INFO  [init] setting PWM_AUX_OUT none
INFO  [mavlink] mode: Normal, data rate: 4000000 B/s on udp port 18570 remote port 14550
INFO  [mavlink] mode: Onboard, data rate: 4000000 B/s on udp port 14580 remote port 14540
INFO  [mavlink] mode: Onboard, data rate: 4000 B/s on udp port 14280 remote port 14030
INFO  [mavlink] mode: Gimbal, data rate: 400000 B/s on udp port 13030 remote port 13280
INFO  [logger] logger started (mode=all)
INFO  [logger] Start file log (type: full)
INFO  [logger] [logger] ./log/2022-10-24/09_37_59.ulg
INFO  [logger] Opened full log file: ./log/2022-10-24/09_37_59.ulg
INFO  [mavlink] MAVLink only on localhost (set param MAV_{i}_BROADCAST = 1 to enable network)
INFO  [mavlink] MAVLink only on localhost (set param MAV_{i}_BROADCAST = 1 to enable network)
INFO  [px4] Startup script returned successfully
pxh> INFO  [tone_alarm] home set
INFO  [tone_alarm] notify negative

pxh>
pxh>
pxh> commander takeoff
pxh> INFO  [commander] Armed by internal command
INFO  [tone_alarm] arming warning
INFO  [navigator] Using minimum takeoff altitude: 2.50 m
INFO  [commander] Takeoff detected
WARN  [commander] Failsafe enabled: no RC and no datalink
INFO  [commander] Failsafe mode activated
INFO  [navigator] RTL HOME activated
INFO  [navigator] RTL: landing at home position.
INFO  [navigator] RTL: climb to 489 m (1 m above destination)
INFO  [tone_alarm] battery warning (fast)
INFO  [commander] Failsafe mode deactivated
INFO  [navigator] RTL: return at 489 m (1 m above destination)
INFO  [navigator] RTL: land at destination
INFO  [commander] Landing detected
INFO  [commander] Disarmed by landing
INFO  [tone_alarm] notify neutral
INFO  [logger] closed logfile, bytes written: 3787377

but don't have gazebo ? @JonasVautherin

parallels@ubuntu-linux-20-04-desktop:~/Desktop$ docker run --rm -it --entrypoint /bin/bash jonasvautherin/px4-gazebo-headless:1.13.1
root@3028512c5c40:/#

but don't have gazebo ?

Well it's headless, you will only see the PX4 shell :sweat_smile:

How can I use Docker like the official manual? The official image can run the sitl simulation directly, and the gazebo graphical interface can appear. like https://docs.px4.io/main/en/test_and_ci/docker.html.
It would be great if your Docker has this feature. I think you have the ability to build one. @JonasVautherin

but don't have gazebo ?

Well it's headless, you will only see the PX4 shell 😅

got it

now the ip is ok :

What did you change to make it work?

now the ip is ok :

What did you change to make it work?

I don't know, maybe a new network.

Ok, well happy to see that it works. I guess we can close it now :blush:


Unimplemented DMF control attributes

See http://www.byond.com/docs/ref/skinparams.html#allparamstable

[ ] is-checked
[ ] can-check
[ ] group
[ ] is-transparent
[ ] drop-zone
[x] title
[ ] titlebar
[ ] can-close
[ ] can-minimize
[ ] can-resize
[ ] is-maximized
[ ] image
[ ] image-mode
[ ] stretch
[ ] keep-aspect
[ ] transparent-color
[ ] alpha
[x] splitter (#1408)
[ ] multi-line
[ ] is-flat
[ ] pushbutton
[ ] icon-size
[ ] text-mode
[ ] on-show
[ ] on-hide
[ ] link-color
[ ] visited-color
[ ] cell-span
[ ] style
[ ] enable-http-images
[ ] focus
[ ] max-lines
[ ] flash
[ ] no-command
[ ] map-to
[ ] show-history
[ ] tab-background-color
[ ] tab-font-family
[ ] tab-font-size
[ ] tab-font-style
[ ] tab-text-color
[ ] tabs
[ ] show-url
[ ] use-title
[ ] highlight-color
[ ] allow-html

All possible control parameters were added as valid keywords in 6a03889def6fc42058c4aa4d817e3649bdfde16c. They currently don't do anything, and instead just print warnings to the console.

#1462 does is-checked, can-check, group
#1450 does on-show and on-hide

#1757 defines all the properties and their defaults but does not implement behaviour


Proposed call hierarchy

See https://github.com/rust-analyzer/rust-analyzer/pull/2698 for an example implementation.

@Marwes Can you take a look at this? I'd like to get it in so I can simplify rust-analyzer.

LGTM. Releasing as 0.68.1


Fix workspace build

When building examples as part of a workspace, linker can't find memory.x. This PR fixes that.

I'm not sure if memory.x should even be in this repository, it's only really used for the examples anyways and not part of the crate proper. It should probably rather be deleted, especially since I hope to have this crate support other chips which have the same USB peripheral but different memory layout (once I get around to doing that).
Personally I've fixed this by just having memory.x for whatever chip I'm using for testing in the workspace root.

Oh, yes, I forgot that build.rs is applied not only to the examples, but also to the library, introducing potential problems with linking for other crates.

Personally I've fixed this by just having memory.x for whatever chip I'm using for testing in the workspace root.

Thank you for the hint!


Null check

coverage: 100.0%. remained the same when pulling dcb72d353c8de8b977021067183b80b83de1b739 on jeffgbutler:misc-updates into eb12c08b28c9510130ff43ab4cf27269db932a5d on mybatis:master.


Edit progress on exercise cards

Value Proposition
As a user
I want to I want to edit the sets, reps and weight
So that I can adjust my training progress for every exercise
Description

Acceptance Criteria

[ ] there is an edit button next to sets, reps and weight.
[ ] when the user clicks the edit button, the input field opens and the user can change the entry
[ ] when the user clicks submit (the hook), the new entry is saved and the input field is closed again.

Tasks

[ ] create a new feature branch
[ ] create a styled component for the edit button
[ ] implement the edit button on the Card Footer for one field
[ ] write a function: when the edit button is clicked, the input field opens
[ ] create a styled component for the submit button.
[ ] implement the submit button in one field.
[ ] write a function: when the submit button is clicked, the new value is saved and the input field is closed again.
[ ] repeat this for the other two fields

Complexity
L

looks good 👍
as discussed it would be easier for the beginning to just have one edit button which controls one input field and later add the other two input fields.


Merge Pie and Pie.ShaderCompiler

Merge Pie and Pie.ShaderCompiler into one project, or more likely reverse the dependency (aka Pie references Pie.ShaderCompiler)

The dependency has now been reversed - Pie now depends on Pie.ShaderCompiler.


feat: add scripts to configure build of apk branch

Fixes : #1

@mariobehling Please review

@mariobehling I have checked the log of travis CI build for #8 and Yes, In this build no apk is generated. But  I think that this happened because the changes are made in travis.yml file thus, the Travis CI had used older scripts for this PR. To crosscheck the functionality I will send a new PR.


Add missing armv7 library variants.

This patch adds the following library variants.
            1. armv7r hard_vfpv3xd
            2. armv7a soft_vfpv3_d16.

Also disable the math_errhandling tests to the set of disabled
tests for the armv7r_hard_vfpv3xd library variant.These tests were
already disabled for the previously existing variants, due to a known
issue in compiler-rt where the floating point exceptions are not set
correctly for computations on types implemented in software.

This should also have tests in test/multilib/armv7a.test to make sure that they get selected correctly.

Added the tests.


raise error on undefined secrets

Change to SignStream class as it uses DataStream objects to create secret and payload streams.  This error should then be caught by jwsSign to adequately fail users downstream instead of failing silently.

You need to handle the case where SignStream takes a stream. Maybe the check in dataStream could be pushed higher up?

Yeah, I'm failing the streaming signing of RSA tests specifically because of this.  Trying to figure out a way to do just that, it just sucks that I can't run automated build and tests without creating PRs (failing in public is fun, right?)

You can, just run npm test

I don't have a node server at work, so I edit in atom directly and then create PRs.  I'm not even using this library, yet, but got down this rabbit hole when investigating using jwts for authentication on an app I'm working on in cloud9, then saw this issue. . . ;)

There, I added the test reported from the issue that raised this.
I did a naked return whenever a secret is undefined to make an undefined value propagate up through to jws.Sign, at which point, an 'error' should emit.
@willm , does this address your concern without having to change DataStream directly for streams?  I'd love a suggestion on how to write a test to catch the emit('error') functions though, for completeness.


KeyError: 'file'

2017-04-01 10:44:17,525 INFO werkzeug._log:87    <IP_ADDRESS> - - [01/Apr/2017 10:44:17] "GET /apispec_1.json HTTP/1.1" 500 -
Traceback (most recent call last):
  File "/usr/local/var/pyenv/versions/3.6.1/envs/brm-api/lib/python3.6/site-packages/flask/app.py", line 1997, in __call__
    return self.wsgi_app(environ, start_response)
  File "/usr/local/var/pyenv/versions/3.6.1/envs/brm-api/lib/python3.6/site-packages/werkzeug/contrib/profiler.py", line 103, in __call__
    p.runcall(runapp)
  File "/usr/local/var/pyenv/versions/3.6.1/lib/python3.6/cProfile.py", line 109, in runcall
    return func(*args, **kw)
  File "/usr/local/var/pyenv/versions/3.6.1/envs/brm-api/lib/python3.6/site-packages/werkzeug/contrib/profiler.py", line 96, in runapp
    appiter = self._app(environ, catching_start_response)
  File "/usr/local/var/pyenv/versions/3.6.1/envs/brm-api/lib/python3.6/site-packages/flask/app.py", line 1985, in wsgi_app
    response = self.handle_exception(e)
  File "/usr/local/var/pyenv/versions/3.6.1/envs/brm-api/lib/python3.6/site-packages/flask_cors/extension.py", line 161, in wrapped_function
    return cors_after_request(app.make_response(f(*args, **kwargs)))
  File "/usr/local/var/pyenv/versions/3.6.1/envs/brm-api/lib/python3.6/site-packages/flask/app.py", line 1540, in handle_exception
    reraise(exc_type, exc_value, tb)
  File "/usr/local/var/pyenv/versions/3.6.1/envs/brm-api/lib/python3.6/site-packages/flask/_compat.py", line 33, in reraise
    raise value
  File "/usr/local/var/pyenv/versions/3.6.1/envs/brm-api/lib/python3.6/site-packages/flask/app.py", line 1982, in wsgi_app
    response = self.full_dispatch_request()
  File "/usr/local/var/pyenv/versions/3.6.1/envs/brm-api/lib/python3.6/site-packages/flask/app.py", line 1614, in full_dispatch_request
    rv = self.handle_user_exception(e)
  File "/usr/local/var/pyenv/versions/3.6.1/envs/brm-api/lib/python3.6/site-packages/flask_cors/extension.py", line 161, in wrapped_function
    return cors_after_request(app.make_response(f(*args, **kwargs)))
  File "/usr/local/var/pyenv/versions/3.6.1/envs/brm-api/lib/python3.6/site-packages/flask/app.py", line 1517, in handle_user_exception
    reraise(exc_type, exc_value, tb)
  File "/usr/local/var/pyenv/versions/3.6.1/envs/brm-api/lib/python3.6/site-packages/flask/_compat.py", line 33, in reraise
    raise value
  File "/usr/local/var/pyenv/versions/3.6.1/envs/brm-api/lib/python3.6/site-packages/flask/app.py", line 1612, in full_dispatch_request
    rv = self.dispatch_request()
  File "/usr/local/var/pyenv/versions/3.6.1/envs/brm-api/lib/python3.6/site-packages/flask/app.py", line 1598, in dispatch_request
    return self.view_functions[rule.endpoint](**req.view_args)
  File "/usr/local/var/pyenv/versions/3.6.1/envs/brm-api/lib/python3.6/site-packages/flask/views.py", line 84, in view
    return self.dispatch_request(*args, **kwargs)
  File "/usr/local/var/pyenv/versions/3.6.1/envs/brm-api/lib/python3.6/site-packages/flask/views.py", line 149, in dispatch_request
    return meth(*args, **kwargs)
  File "/usr/local/var/pyenv/versions/3.6.1/envs/brm-api/lib/python3.6/site-packages/flasgger/base.py", line 478, in get
    endpoint=rule.endpoint, verb=verb
  File "/usr/local/var/pyenv/versions/3.6.1/envs/brm-api/lib/python3.6/site-packages/flasgger/base.py", line 76, in _parse_docstring
    obj.__globals__['__file__']
KeyError: '__file__'

0.6.1 workes fine, 0.6.2 breaks.

Caused by https://github.com/rochacbruno/flasgger/commit/7a3db9458cbed4e031dec688e1281f777016582e

hi tks for reporting
which example to reproduce the error? can you share example code for the app?

this may be replaced with inspect.getfile

inspect.getfile gets:
>>> inspect.getfile(obj)
'<decorator-gen-38>'

The view func has a decorator applied.

@messense I added a fix, and a test examples/decorator_package.py please try again ans let me know if works so I can release 0.6.3
Thanks

@rochacbruno It works, thanks.


[info] cppcheck 2.7 makes a debug build fail

This is only for std::string_view. I built cppcheck today from main, at https://github.com/danmar/cppcheck/commit/24e98591586aa689d3a4d6095f70da3358bc1989
/home/julien/Software/Others/json2cpp/src/json2cpp.hpp:20:48: performance: Function parameter 'document_name' should be passed by const reference. [passedByValue]
compile_results compile(const std::string_view document_name, const nlohmann::json &json);
                                               ^

I realize this is idiomatic, but I thought you may be interested in knowing that currently it will fail, as it is enabled by default (provided you have cppcheck installed already on your system)
Note: I opened a PR to cppcheck to allow passing std::string_view by value: https://github.com/danmar/cppcheck/pull/3817

Great, now all of my tests are failing because we're using cppcheck 2.7 by default now.

@aminya can you provide insight here as to how best mitigate this bug in cppcheck 2.7, which is now the default installed with project_options it seems?
I don't see any way to pass extra parameters to cppcheck. I could force it back down to 2.6? Putting a linter comment in each location seems like a very bad idea.

cppcheck is not installed by default as part of project_options. If your project doesn't work with cppcheck, you can disable it in CMakeLists.txt. You have enabled it by default because you are using dynamic_project_options, which hides the options.
https://github.com/cpp-best-practices/project_options#usage
You can also pass the version of cppcheck you want to setup-cpp https://github.com/lefticus/json2cpp/blob/78b075cc86a78831572ac6aae83a95200dc77b8d/.github/workflows/ci.yml#L146

My point is that right now we have 2 options: use cpp_check, or don't use cpp_check. We have no way of setting individual flags or options like we do with gcc/clang/msvc/clang-tidy.
Do you think it's worth adding a configuration option to to project_options for this?

I never personally use this as I do not require an external force to address them. Sometimes warnings are genuine warnings and not errors.

Interesting, do you manually sort through the logs for each compiler and platform that is checked to see if any warnings are generated?

FYI, https://github.com/danmar/cppcheck/pull/3817 was merged upstream.

Thanks @jmarrec . I still feel like I just have to disable this check. clang-tidy provides its own guidance, and actually knows something about the types.


Wrong path when opening integrated terminal

VSCode Version: 1.8.1
OS Version: macOS 10.12.2

Steps to Reproduce:

Click open integrated termianl
I get this error:
The terminal process command /opt/local/bin/bash failed to launch (exit code: 1)

VSCode appears to find the wrong bash. I do not have a bash in /opt/local/bin/bash

A follow up on this issue. It appears that vscode launched from non-terminal also does not have the correct environment variable.

On /opt/local/bin/bash: The setting defaults to $SHELL which defines the default terminal shell, if his is a work computer it's likely an issue with how your org set it up.
On the env: You are probably setting your environment variables in .bashrc, this defines your env only when running through bash. This is why it runs fine through the terminal as it's already executed .bashrc. You can try:

Move the env variables to .profile
Run bash as a login shell using: "terminal.integrated.shellArgs.osx": ["-l"]

See https://code.visualstudio.com/docs/editor/integrated-terminal#_linux-os-x for more info


Endless mode level selection screen forgets how many cryptocoins were won

When you restart a previously won level in endless mode the cryptocoin won count is reset
if you don't finish the level a second time the "x of 3 coins won" line is missing completely, which is extra annoying in combination with #144 .
If you do finish it a second time, it says "0 of 3 coins won"
I understand the coins work differently in endless mode when compared to mission mode anyway as you cannot come back for a lost coin later.
So the obvious thing here would be to display (and remember) the amount of coins won in total in that level (including attacker coins).
When the level is repeated, the coins won count can be increased.

Has been fixed in 1.34. (Hopefully, at least.)


Updating EvmHelpers on Arbitrum

Codecov Report
Patch and project coverage have no change.

Comparison is base (cf03a17) 47.30% compared to head (a6b83f1) 47.30%.

Additional details and impacted files
@@           Coverage Diff           @@
##           master      #15   +/-   ##
=======================================
  Coverage   47.30%   47.30%
=======================================
  Files          10       10
  Lines         260      260
  Branches       53       53
=======================================
  Hits          123      123
  Misses        137      137

:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Have feedback on the report? Share it here.


Unable to bind to mouse buttons

Lorien version:

release v0.6.0
OS/device including version:

Windows
Issue description:

Nothing happened, I should have been able to bind brush to mouse button 5
Steps to reproduce:
Go to the settings, then keybinds. Chose something then try to use special mouse buttons, such as back and forward

+1, Would also like to have the ability to bind mouse buttons.

+1, Yeah i would like to use my side buttons as UNDO and REDO while sketching.


Update to Portainer 2.0

When can the update to version 2.0 be expected?
https://github.com/portainer/portainer

Probably never, this add-on is most likely to be deprecated.
Portainer chooses a different path of 2.0, which is not a good direction for the add-on.


Fix invalid Haml option warnings

When I use middleman-blog with Haml 5+, I get the following warnings
Haml::TempleEngine: Option :lang is invalid
Haml::TempleEngine: Option :locale is invalid

because middleman-blog adds lang and locale to metadata:
https://github.com/middleman/middleman-blog/blob/v4.0.2/lib/middleman-blog/blog_data.rb#L235
This patch is for resolving these warnings in the most conservative way. We could opt-in limited keys from @options, but taking this conservative way would allow us to avoid unwanted impacts.

Wondering if we have a test for i18n helpers in haml. I thought these were included for that support.

Maybe this https://github.com/middleman/middleman/commit/4d5c50968? According to the commit and https://github.com/middleman/middleman/commit/28a0071be, the options[:locale] and options[:lang] are for controlling ::I18n.locale and they seem to have nothing to do with any of Haml options.
For your reference, in Haml::Engine (and underlying Haml::TempleEngine) does not have neither :locale nor :lang in its options https://github.com/haml/haml/blob/v5.1.1/lib/haml/temple_engine.rb#L10-L30.

Since you closed this, I guess you removed :locale and :lang from @options in another change? These are still invalid options in the Haml side and continue to be warned if they haven't been.


Performance issue: EllipsisBehavior

Here screenshot from performance profiler.
After some navigation from pages EllipsisBehavior start to lag application especially on mobile devices.
It should be improved.

Again, plain hook on LayoutUpdated event is wrong. It become a disaster when page layout is changed frequently. It's a case when there is a ListView on page. ListView is virtualizing items control, so it create and destroy list items on demand. Layout is changed any time list is scrolled. If there is multi-phased rendering in ListView items for scroll optimization - things are going even worse. Layout updated not only on item rendering but also on every rendering phase.
I think it's fundamentally wrong to hook on LayoutUpdated event in T10 library.

Update: LayoutUpdated is a RoutedEvent, so we have to check if event source is right control.
Routed events can be catched from other sources and in a case of LayoutUpdated, event source should be validated.

Here is why hook on LayoutUpdate and do some expensive work (like iterating over visual tree to find "More" button) is fundamentally wrong.
https://msdn.microsoft.com/en-us/library/windows/apps/windows.ui.xaml.frameworkelement.layoutupdated

When you handle LayoutUpdated, do not rely on the sender value. For LayoutUpdated, sender is always null, regardless of where the handler is attached. This is to prevent handlers from assigning any meaning to sender, such as implying that it was that specific element that fired the event out of the visual tree. LayoutUpdated implies that something in the overall visual tree has changed, and each specific object anywhere in the tree has the option of handling this occurrence. If you're familiar with lower-level render API design, you can equate LayoutUpdated being fired as similar to a "redraw needed" flag being set as part of an object-driven, retained-mode rendering logic.
Because LayoutUpdated fires in many circumstances and isn't always specific to an object that actually changes, consider whether handling the SizeChanged event instead is more appropriate for your scenario.

@JerryNixon look at it, it seems like architectural flaw in library design

@JerryNixon Fixed problem in #906 pull request. It greatly optimize performance of "ellipsis" button search in EllipsisBehavior.
For most common use-case of behavior (with PageHeader control - implying most people use PageHeader with T10) I used some architecturally unpleasant hack (cache button reference in private field and allow access to it via internal method for same-assembly EllipsisBehavior class). It somewhat smells but performance optimized.
If behavior will be used with other CommandBar descendant, optimized method of button search in visual tree. Replaced manual visual tree walk with obvious call to FindName on templated visual tree root. Only 3 WinRT interop calls instead of plenty WinRT calls in XamlUtils.AllChildren<Control>(commandBar).
But, it does not solve whole problem with LayoutUpdated event handling. I don't understand why LayoutUpdated event is used. I logically assume it's used to "automatically" catch primary and secondary command buttons visibility for Auto behavior mode. It's simple but fundamentally flawed from performance perspective. Maybe there is other reason for LayoutUpdated event which I do not know. Anyway, this pull request is only a partial solution which fix blatant performance degradation because of expensive manual tree walk on every LayoutUpdated event.
As I observed in debugger, LayoutUpdated event really raised on every visual tree change at page, no matter where. In many dynamic UI and virtualizing ListView scenarios it turn into a complete disaster.
As I posted above with screenshot from performance profiler, original LayoutUpdated handler used more CPU time than complex custom markup rendering engine used. If you look at that rendering engine - it parse potentially complex markup tree (with links, quotes, font styles and so on), calculate placement of text blocks and graphic primitives on canvas and insert these visual tree elements on canvas, engine partially written in C++ for better WinRT interop performance. And, such a complex task consume less CPU time than merely LayoutUpdated event handler!. Just imagine scale of disaster. Even on top tier Lumia 950 it works laggy and unpredictable. On Lumia 920 it visually suffocated.
Usage of LayoutUpdated event handling should be validated. Why?

And, I must add to said above.
LayoutUpdated event involved in system layout updating cycle.
Expensive work (such as manual visual tree walk) inside layout update cycle ruin UI smoothness and responsiveness.


Introduce a new implenentation of implicit shadowing

Avoid building up a set of all in-scope implicits during each implicit
search.
Instead, do the filtering of shadowed implicits in a second pass.

Related to: https://github.com/scala/scala/pull/7757

Baseline
[info] HotScalacBenchmark.compile:·gc.alloc.rate.norm                       ../corpus           latest  -Ystop-after:typer       false  2.12.9-bin-c35194d-SNAPSHOT  @/code/akka/akka-stream-tests/target/akka-stream-tests-test.args  sample    4<PHONE_NUMBER>.000 ±   10829315.614    B/op

New:
[info] HotScalacBenchmark.compile:·gc.alloc.rate.norm                       ../corpus           latest  -Ystop-after:typer       false  2.12.9-bin-e5d2f52-SNAPSHOT  @/code/akka/akka-stream-tests/target/akka-stream-tests-test.args  sample    4<PHONE_NUMBER>.000 ±    5947894.601    B/op

0.90x reduction.

Promoted to https://github.com/scala/scala/pull/8109


Gurl, the DSL you gave me is so wrong. This is a Camel Route not a null in output log of Kaoto backend for almost all routes

for instance, with:
- from:
    uri: timer:demo
    steps:
    - to:
        uri: twitter-directmessage:example

This answer from the backend means you didn't send the right DSL as parameter.

the requests seem to contain the correct DSL (Camel Route) or no dsl:

No more occurring when moving to Kaoto 2 as there is no more backend


fix Unknown setting charset for clickhouse driver

Codecov Report
Base: 79.82% // Head: 79.89% // Increases project coverage by +0.06% :tada:

Coverage data is based on head (56ec7ef) compared to base (0876e00).
Patch coverage: 50.00% of modified lines in pull request are covered.

Additional details and impacted files
@@            Coverage Diff             @@
##           master    #2375      +/-   ##
==========================================
+ Coverage   79.82%   79.89%   +0.06%
==========================================
  Files         589      587       -2
  Lines       48836    48716     -120
==========================================
- Hits        38984    38922      -62
+ Misses       7870     7820      -50
+ Partials     1982     1974       -8

Flag
Coverage Δ

go-1.15-386
?

go-1.15-amd64
?

go-1.16-386
?

go-1.16-amd64
79.85% <50.00%> (-0.02%)
:arrow_down:

go-1.17-386
79.86% <50.00%> (+<0.01%)
:arrow_up:

go-1.17-amd64
79.87% <50.00%> (-0.03%)
:arrow_down:

go-1.18-386
?

go-1.18-amd64
?

Flags with carried forward coverage won't be shown. Click here to find out more.

Impacted Files
Coverage Δ

contrib/drivers/clickhouse/clickhouse.go
73.82% <50.00%> (ø)

container/gmap/gmap_hash_str_any_map.go
97.00% <0.00%> (-1.00%)
:arrow_down:

contrib/config/kubecm/kubecm_kube.go

contrib/config/kubecm/kubecm.go

Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here.

:umbrella: View full report at Codecov.
:loudspeaker: Do you have feedback about the report comment? Let us know in this issue.


Rust rewrite

Better dev xp (tooling)
Better cross-compile
Less mem management concerns
Smaller wheels
Async support

I postpone the switch to Rust for now.


Error pages unstyled

See https://github.com/django-oscar/django-oscar/commit/f381d1f370bc0b1cc462e021829b7e8bb0664de4#commitcomment-8974172

@mbertheau what is pending in this issue?

fixed by an other pr


Lock oc_erchef to 1.0 while keeping jiffy at latest

chef-mover and moser depend on modules provided by oc_erchef.  To ensure that the upgrades work correctly into the future, the version of oc_erchef we depend on must be locked.  Otherwise, changes to the modules in oc_erchef could break the migration scripts.
This is NOT the long term solution, but will allow us to continue to safely put out new builds without breaking upgrades.
Jiffy has been manually bumped to a recent revision that works on RHEL 7

cc @chef/lob

:+1:

LGTM