text:
Change libiio dependency to new pylibiio package

Checklist

[x] Used a personal fork of the feedstock to propose changes
[x] Bumped the build number (if the version is unchanged)
[ ] Reset the build number to 0 (if the version changed)
[x] Re-rendered with the latest conda-smithy (Use the phrase @conda-forge-admin, please rerender in a comment in this PR for automated rerendering)
[x] Ensured the license file is being packaged.

Hi! This is the friendly automated conda-forge-linting service.
I just wanted to let you know that I linted all conda-recipes in your PR (recipe) and found it was in an excellent condition.

repo: conda-forge/pyadi-iio-feedstock


text:
MAINT: Bump version into v0.11.3

Cherry-pick changes from https://github.com/conda-forge/pyaedt-feedstock/pull/103 and add the missing dependency.

Hi! This is the friendly automated conda-forge-linting service.
I was trying to look for recipes to lint for you, but it appears we have a merge conflict. Please try to merge or rebase with the base branch to resolve this conflict.
Please ping the 'conda-forge/core' team (using the @ notation in a comment) if you believe this is a bug.

source: gharchive/pull-request

authors: SMoraisAnsys conda-forge-admin

repo: conda-forge/pyaedt-feedstock

license_type: permissive

license_source: github-api


text:
Split into librsgislib (C++) and rsgislib (Python bindings)

As RSGISLib is a C++ library with Python bindings, splitting would mean the C++ component only needs to be build once for each platform (which takes most of the build time) then just the Python bindings need to be built for each Python distribution. Would work exactly the same as for libgdal and gdal, with librsgislib being a dependency of rsgislib.
Advantage is would reduce build time. Disadvantage is two feedstocks to keep track of which is slightly more complicated, would also end up with a feedstock with 'lib' at the start and end (but I don't think this is a good reason not to do it)

Sounds good to me :+1:

source: gharchive/issue

authors: danclewley gillins

repo: conda-forge/rsgislib-feedstock


text:
Add explicit dependency on libiconv, use run_exports

Fixes #10
Fixes #11

Checklist

[x] Used a personal fork of the feedstock to propose changes
[x] Bumped the build number (if the version is unchanged)
[ ] Reset the build number to 0 (if the version changed)
[x] Re-rendered with the latest conda-smithy (Use the phrase @conda-forge-admin, please rerender in a comment in this PR for automated rerendering)
[ ] Ensured the license file is being packaged.

Hi! This is the friendly automated conda-forge-linting service.
I just wanted to let you know that I linted all conda-recipes in your PR (recipe) and found it was in an excellent condition.

authors: conda-forge-linter xhochy

repo: conda-forge/rsync-feedstock


text:
Release 0.8.1

Checklist

[ ] Used a personal fork of the feedstock to propose changes
[ ] Bumped the build number (if the version is unchanged)
[ ] Reset the build number to 0 (if the version changed)
[ ] Re-rendered with the latest conda-smithy (Use the phrase @conda-forge-admin, please rerender in a comment in this PR for automated rerendering)
[ ] Ensured the license file is being packaged.

Hi! This is the friendly automated conda-forge-linting service.
I just wanted to let you know that I linted all conda-recipes in your PR (recipe) and found it was in an excellent condition.

@conda-forge-admin, please rerender

authors: conda-forge-linter holgern

repo: conda-forge/scikit-optimize-feedstock


text:
docs: 📝 hacktoberfest banner removed

Checklist

[x] Used a personal fork of the feedstock to propose changes
[x] Bumped the build number (if the version is unchanged)
[ ] Reset the build number to 0 (if the version changed)
[x] Re-rendered with the latest conda-smithy (Use the phrase @conda-forge-admin, please rerender in a comment in this PR for automated rerendering)
[x] Ensured the license file is being packaged.

Hi! This is the friendly automated conda-forge-linting service.
I just wanted to let you know that I linted all conda-recipes in your PR (recipe/meta.yaml) and found it was in an excellent condition.
I do have some suggestions for making it better though...
For recipe/meta.yaml:

PyPI default URL is now pypi.org, and not pypi.io. You may want to update the default source url.

@conda-forge-admin, please rerender

Hi! This is the friendly automated conda-forge-linting service.
I just wanted to let you know that I linted all conda-recipes in your PR (recipe/meta.yaml) and found it was in an excellent condition.

authors: conda-forge-admin onuralpszr

repo: conda-forge/supervision-feedstock


text:
New version and change in maintainer

Checklist

[x ] Used a fork of the feedstock to propose changes
[ ] Bumped the build number (if the version is unchanged)
[ x] Reset the build number to 0 (if the version changed)
[ ] Re-rendered with the latest conda-smithy (Use the phrase @conda-forge-admin, please rerender in a comment in this PR for automated rerendering)
[ x] Ensured the license file is being packaged.

Hi! This is the friendly automated conda-forge-linting service.
I wanted to let you know that I linted all conda-recipes in your PR (recipe) and found some lint.
Here's what I've got...
For recipe:

There are 1 too many lines.  There should be one empty line at the end of the file.
license_file entry is missing, but is required.

For recipe:

License is not an SPDX identifier (or a custom LicenseRef) nor an SPDX license expression.

Documentation on acceptable licenses can be found here.

Hi! This is the friendly automated conda-forge-linting service.
I just wanted to let you know that I linted all conda-recipes in your PR (recipe) and found it was in an excellent condition.

@conda-forge-admin, please rerender

Good with me. I handed over maintenance a while back.

Thanks @ocefpaf!

authors: conda-forge-linter dharhas emiliom ocefpaf

repo: conda-forge/ulmo-feedstock


text:
MNT: rerender

Hi! This is the friendly automated conda-forge-webservice.
I've started rerendering the recipe as instructed in #2.
If I find any needed changes to the recipe, I'll push them to this PR shortly. Thank you for waiting!
Here's a checklist to do before merging.

[ ] Bump the build number if needed

Fixes #2

Hi! This is the friendly automated conda-forge-linting service.
I just wanted to let you know that I linted all conda-recipes in your PR (recipe/recipe.yaml) and found it was in an excellent condition.

Hi! This is the friendly conda-forge automerge bot!
Commits were made to this PR after the automerge label was added. For security reasons, I have disabled automerge by removing the automerge label. Please add the automerge label again (or ask a maintainer to do so) if you'd like to enable automerge again!

repo: conda-forge/write-good-feedstock


text:
Stop distributing development files

The expected output
CHANGELOG.md
LICENSE
README.md
css/
package.json
scss/

This is how to check
npm pack
tar --list --file sprucecss-1.2.0.tgz|cut -d/ -f2|LC_COLLATE=C sort -u

Awesome, thanks Viktor!

authors: adamlaki szepeviktor

repo: conedevelopment/sprucecss

license: MIT


text:
gh action updates

manual upgrades from #431 and #432.
potentially interesting read https://pin-gh-actions.kammel.dev/
Rationale:
Not because of being paranoid but mainly because it's considered a good security practice. That practice is also checked by tools like OpenSSF Scorecard so if our repos are benchmarked using that common tooling, it shows we are "compliant".

we make the checks monthly it should be bearable

added a commit to make the cadence monthly. it's "on the first day of the month"

repo: confidential-containers/operator


text:
Is there any way to share consumer connections?

The producer and admin client have the idea of sharing connections. DependentProducerBuilder for instance, so we can reuse the connection to Kafka when producing to multiple topics. Is there a technical reason this doesn't exist for consumers, or is it simply because it hasn't been added?

There's no technical reason at the kafka API level, but the client (including librdkafka) consumers are designed for high bandwidth streaming use cases and don't allow you to assign to (or subscribe to) more than one set of topics. as other use cases emerge I think this will change, but it's not the case at the moment.

The consumer protocol has a couple of blocking protocol requests which make it troublesome to reuse a single connection for multiple consumers.

right, stupid me, fetch for instance. something else we've put some thought into is what an API for splitting messages from a single consumer based on headers or topic might look like. today, you could build something like that on top of a Consumer<byte[],byte[]>.

Thanks, that makes sense!

authors: dfturn edenhill mhowlett

repo: confluentinc/confluent-kafka-dotnet


text:
Handle structural sharing

Tanstack seems to have added a noisy console.error log for queries that return data that is not JSON-serializable. Since some of connect-query's tests use BigInt, we now see the following in the logs when running tests:
StructuralSharing requires data to be JSON serializable. To fix this, turn off structuralSharing or return JSON-serializable data from your queryFn. [@"connectrpc.eliza.v1.PaginatedService","List",#page:0,,"infinite",]: TypeError: Do not know how to serialize a BigInt

An attempt at disabling structuralSharing for tests was made in #404 but closed in favor of a proper investigation into handling this more robustly. Tanstack recommends to either turn off structuralSharing in your queries or to return JSON serializable data from your queryFn. So, we should investigate these as a better course of action.

Actually, looking at the docs for useQuery, the structuralSharing option can also take the form of a function. If we just provide this option by modifying createUseQueryOptions that should actually handle this in all cases (we'll need to modify createUseInfiniteQueryOptions as well). Looking at the signature this might not even really require waiting for protobuf-es@v2 wither since it's just a simple compare method that returns a bool.

Looking at the signature this might not even really require waiting for protobuf-es@v2 either since it's just a simple compare method that returns a bool.

It's either a boolean, or a function that implements the structural sharing logic:
    structuralSharing?: boolean | ((oldData: unknown | undefined, newData: unknown) => unknown);

But I expect that a simplistic implementation can use protobuf-es' equals() to compare old with new, and return old if equal, maintaining the reference.
With v2, this needs to be a per-query option since equals() is a function that takes a schema as an argument instead of an object method with the schema curried in. Any change we make is ideally forwards-compatible.
I don't want to move too many things around at once, but I agree we don't technically have to wait for v2.

This will be fixed in v2 by https://github.com/connectrpc/connect-query-es/pull/414. We will cut a pre-release shortly.

authors: paul-sachs smaye81 timostamm

repo: connectrpc/connect-query-es


text:
[ST] Execution Reverted

Describe the bug
A user is trying to bridge oLIT from Arbitrum to Ethereum but gets an "execution reverted" error. As far as I'm aware there aren't any liquidity constraints for this token like there are on Alchemix assets. The user tried deleting the decimals and also inputting just 1 oLIT but still got the error.
Link to ticket in discord
https://discord.com/channels/454734546869551114/1200875338897563808/1200875541239189544

A different user is trying to bridge NEXT from Gnosis Chain to Arbitrum but also got execution reverted. Then they tried to bridge to Polygon and got this error:

https://discord.com/channels/454734546869551114/1200879162634813491/1200880415980929165

These were caused by the bridge being paused

repo: connext/monorepo


text:
[Snyk] Upgrade env-var from 6.1.1 to 6.3.0

Snyk has created this PR to upgrade env-var from 6.1.1 to 6.3.0.

:information_source: Keep your dependencies up-to-date. This makes it easier to fix existing vulnerabilities and to more quickly identify and fix newly disclosed vulnerabilities when they affect your project.

The recommended version is 3 versions ahead of your current version.
The recommended version was released 6 months ago, on 2020-07-27.

Note: You are seeing this because you or someone else with access to this repository has authorized Snyk to open upgrade PRs.
For more information:
🧐 View latest project report
🛠 Adjust upgrade PR settings
🔕 Ignore this dependency or unsubscribe from future upgrade PRs

Coverage remained the same at 99.401% when pulling ce2e5098c56c303734d0d33db9e8343d8fb2d716 on snyk-upgrade-ac38b4ac6b9278ed0863f66040ec3f52 into 1e9c07d41ebcea0bb6832bb592742107bb2a10b9 on master.

authors: connorads coveralls

repo: connorads/lockbot


text:
new hljs themes

hljs 9.13.0 has introduced a bunch of new themes that are lovely, and I'd love to see them in react-syntax-highlighter 🙇🏻♂

updated and added in v10.2.0
thanks!

Thanks Conor!
On Mon, Mar 11, 2019 at 2:53 AM Conor Hastings notifications@github.com
wrote:

Closed #175
https://github.com/conorhastings/react-syntax-highlighter/issues/175.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/conorhastings/react-syntax-highlighter/issues/175#event-2192422514,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AC82HFWMvGyjkyq4C760MbVUVAy1aCiQks5vVUamgaJpZM4bjRw1
.

@conorhastings the styles in the new update seem to be in /esm/styles/**.js and /cjs/styles/**.js while /dist/styles/**.js has not been updated, is that intentional or a bug? 😅

@Superpencil this is intentional, was a breaking change in v10, old files on my computer are still being published, will publish a new version without dist/styles later tonight, thanks

@conorhastings Alrighty then!

authors: Superpencil conorhastings

repo: conorhastings/react-syntax-highlighter

license: mit

license_source: bigquery


text:
Run many node in this blockchain

As you say, if I want to run two nodes in this blockchain, so I have to run 2 command in 2 separated terminal:
$ node bin/naivecoin.js -p 3001 --name 1
$ node bin/naivecoin.js -p 3002 --name 2 --peers http://localhost:3001
So if I want to run more than 2 node, for example 3 node, so what list of peers in the third terminal?
Is that true:
$ node bin/naivecoin.js -p 3001 --name 1
$ node bin/naivecoin.js -p 3002 --name 2 --peers http://localhost:3001
$ node bin/naivecoin.js -p 3003 --name 3 --peers http://localhost:3001, http://localhost:3002
If I run like that, it return an errors:
warn - thuong3: Unable to get latest block from http://localhost:3002,/blockchain/blocks/latest: connect ECONNREFUSED 127.0.0.1:80
warn - thuong3: Unable to send me to peer http://localhost:3002,/node/peers: connect ECONNREFUSED 127.0.0.1:80
warn - thuong3: Unable to send me to peer http://localhost:3002,/node/peers: connect ECONNREFUSED 127.0.0.1:80
warn - thuong3: Unable to get transations from http://localhost:3002,/blockchain/transactions: connect ECONNREFUSED 127.0.0.1:80
warn - thuong3: Unable to send me to peer http://localhost:3002,/node/peers: connect ECONNREFUSED 127.0.0.1:80
warn - thuong3: Unable to send me to peer http://localhost:3002,/node/peers: connect ECONNREFUSED 127.0.0.1:80

I think the problem is because of how you set the peers, try to do this instead:
node bin/naivecoin.js -p 3003 --name 3 --peers http://localhost:3001 --peers http://localhost:3002
Best

authors: conradoqg votinhthuong

repo: conradoqg/naivecoin


text:
Add price of token Lime 0x7bc75e291e656e8658d66be1cc8154a3769a35dd

iMe Lab token
Binance smart chain 0x7bc75e291e656e8658d66be1cc8154a3769a35dd

The BSC chain token currently only supports debank data

repo: consenlabs/token-profile


text:
Ct(chives token)

修改图片

你好，请symbol": "CT(ChivesToken)",无括号内容，谢谢。

authors: Lazybin wenyanwang


text:
Add json file and logo.png

Token symbol: ACG
Token contract address: 0x984C134A8809571993Fd1573fB99F06Dc61E216f
a json file is added to erc20 directory, which named by contract address with checksum.
a 120 * 120 ACG token logo is added to images directory, which named as same as the json file.

请提供透明背景 PNG, 并检查 CI 报错。

authors: ArtChainGlobal makoshan


text:
add UENC info

团队背景：
UENC 团队主要以美国硅谷与中国地区的技术力量为主，中国区团队核心成员有成熟的15年C语言开发经验，早期主要从事大数据安全工作，美国硅谷以哈佛大学和斯坦福大学的年轻硕士为骨干力量，其中UENC联合创始人哈佛大学NetSprig从2014年开始就已经进入区块链行业并取得部分跨链技术的成果，UENC预计将于2019年4月主网上线，利用自主创新的DPOW算法初步实现小额实时交易，并通过技术迭代完成与其他网络的跨链传输，UENC将用核心的跨链技术构建全球价值网络。
项目基本情况:
UENC是一个以跨链为技术方向的可扩展基础公链，在底层技术和架构上进行优化和创新，支持不同区块链网络之间的价值传递。UENC通过对网络价值传递过程中的用户关注度的不同，对该过程进行分类，构建新的共识，以及通过重构基于DHT的混合式点对点网络，建立高效的节点组合结构，从而快速提升公链交易速度。
更多关于 UENC的信息

官网: http://enchain.cc//
白皮书: http://enchain.cc/index.php?s=member&c=api&m=file&id=85
Github: https://t.me/imTokenGroup
Biyong：https://0.plus/UniversalEnergyChain
Twitter: https://twitter.com/ENChain_enc
Telegram:https://t.me/UniversalEnergyChain

媒体报道

金色财经 https://m.jinse.com/blockchain/191917.html

建议 gas limit: 100000

这个文件不是我们的，是原来里面就有的。原来项目是大写，我提交后会编译报错，所以我把它改成了小写。


text:
Add QFil-token

官方公告：www.qfil.cc
项目基本情况：
Qualified Filecoin Hashrate Token（QFIL）是由0.001T的真实Filecoin算力抵押的通证，矿工为QFIL矿池贡献算力，智能合约将算力进行抵押换取发行QFIL通证。
QFIL的价格锚定了真实有效的Filecoin标准算力，持有QFIL等同于拥有Filecoin网络底层算力，因此QFIL代表着潜在的挖矿能力和未来收益，所以在二级市场上，QFIL是没有清算风险的、且具备高价值杠杆能力的通证。
在QFIL智能合约中通过Dapp链上质押QFIL可让用户有权获得以FIL形式发放的挖矿奖励。QFIL流通量情况（新增）将在去中心化浏览器进行公示，可通过链上查询。
项目说明：
根据Filecoin挖矿FIP-004提案，在区块高度170,000时执行FIP-004提案（已实施），当日挖矿收益的25%立即释放，75%按照180天线性释放。因此QFIL锚定的单位算力随着时间增长，单位算力享受的每日挖矿产出相较于前日增加，即包含当日挖矿产出释放部分25%与累积此前线性解锁的产出之和，因此QFIL将不同于BTC、ETH等贬值型算力通证。
发行标准：
QFIL流通总量（单位：个）=QFIL矿池满存标准算力（单位：T）*10
仅当与QFIL合作的、合格的Filecoin标准算力被投入到Filecoin挖矿网络中时，QFIL才被铸造和发行。因此，该项目没有也不会举行私募（Advisor Sale）与公募（Public Sale）活动，同时该项目也没有团队预留部分的通证。
QFIL的铸造受到QFIL DAO（QFIL项目管理自治社区）的监督，项目团队将会定期向QFIL DAO发布QFIL生态报告，并配合社区发布第三方审计报告，接受社区的监督。
项目机制：
随存随取机制：每枚QFIL通证锚定0.001 T的Filecoin算力，通过在QFIL的Dapp申请质押QFIL，获得对应算力的挖矿收益FIL，按T+1发放，随时可领取，也可在Dapp中通过一键闪兑FIL为QFIL进行复投，以增加Filecoin标准算力，也可随时进行QFIL取消质押，并且从Dapp提现。
50% 额外收益机制：当每日Dapp质押的QFIL通证数量少于QFIL实际流通量的50%时，QFIL底层算力资产每日挖矿收益的50%将被转入QFIL Dapp智能合约，按照比例分发给合格质押者。当每日Dapp质押的QFIL通证数量大于或等于QFIL实际流通量的50%时，则按照实际比例进行分发。剩余挖矿收益（当日未分配的）将用于安全保证金和QFIL流动性管理资金。
增强收益机制：质押挖矿用户达到一定质押时间，可申请Filecoin算力产出的套利增强收益策略，年化不低于10%，并且由QFIL安全保证金进行收益保障。
反向行权机制：用户满足拥有1 P的标准算力，即1,024,000枚QFIL通证，可向QFIL DAO提出申请，进行反向资产获取，即使用QFIL算力通证进行行权，领取兑现算力通证锚定的硬件矿机。
项目优势：
1.Filecoin具备完整的矿业产业链和技术生态，潜力巨大，并且市值全球排名前30，增长空间大，能够承接比特币和以太坊的资金外溢，目前价格平稳处于低位，后续增长空间大。
2.QFIL具备业内成熟一流的矿业技术和设备能力，运维稳定，并且接受全球合格矿工加入矿池，发行基于实际算力抵押产生的QFIL进行流通。
3.QFIL大大降低FIL挖矿门槛：每一个QFIL代表着真实有效的标准算力，具备即时挖矿的效率，让非专业矿工对挖矿服务商的选择变得非常简单。
4.QFIL为全球矿工释放了现金流动性，大大提高了挖矿资金的使用效率，并为Filecoin挖矿生态创造了一个更加自由广阔的市场。
5.QFIL具备高流动性，可在一二级市场同时流通，方便用户自由交易。
6.QFIL具备高安全性，牛市升值潜力高于FIL，熊市具备持续收入能力。
7.QFIL的50%额外收益机制有助于QFIL的价格稳定，有助于参与QFIL质押挖矿用户的挖矿收益增强；增强收益策略有助于扩大矿工收益。
技术路线：
2020年10月
FIL矿池技术储备，完成项目启动的准备工作
2021年1月
标准算力通证QFIL完成第一批次的铸造
2021年3月
发布QFIL Dapp V1，上线QFIL质押挖矿FIL功能
2021年4月
推出去中心化社区治理模型QFIL DAO，扩大QFIL合作矿池生态
2021年5月
发布QFIL Dapp V2，上线FIL-QFIL闪兑、FIL抵押借贷、联合挖矿等功能
2021年7月
启动矿池扩容计划，进行QFIL第二批次的铸造
2021年8月
发布QFIL Dapp V3，接入更多DeFi模块
2021年12月
进一步扩大QFIL合作矿池生态，引入更多合作伙伴
转账所需 Gas Limit（对 ERC-20 项目方）：60000
更多关于 QFIL-token 的信息：
官网：www.qfil.cc
电报群：https://t.me/QFIL_Official
推特：https://twitter.com/qfilorg

Json格式不正确，请修正后重新提交。


text:
Topdown consistency checks: Validate number of top down messages

This is the start of a series of updates to enhance topdown finality robustness and accuracy.
This PR adds a simple check to ensure the number of top down messages received is actually correct. The purpose of this is that after running a few tests, some RPC nodes, especially when querying historical data, might not return events completely. Adding this check will alert this from happening and let throws an error/stops parent syncer for node operator to perform checks.
As the gateway already exposes the applied top down nonce by subnet, one just needs to query the consecutive historical state to deduce the number of top down messages.
Draft: updating unit tests.

@aakoshh For:
1. Perhaps if someone is confident in the RPC, they can make this check optional in the settings and save some time by not executing extra queries.

With the past few days, I would say we just check this regardless, I have fewer trust in RPC nodes now. Even if the RPC is not missing any events, it could joined a partitioned network.
2.Perhaps the nonces could be added to the IPC finality the votes are about, but that would require major refactoring in the voting.

Yeah, I think this came up a couple of times, but mostly in bottom up checkpoint. But we still haven't seen a very strong case for the refactoring.

Recording here that @cryptoAtwill encountered an unexpected roadblock because of this: https://github.com/filecoin-project/lotus/issues/11205. It turns out that eth_call in Lotus behaves non-deterministically depending on how the node operator configured this env variable: LOTUS_SKIP_APPLY_TS_MESSAGE_CALL_WITH_GAS.
On Glif nodes, it's configured to skip the execution of requested block prior to applying the call, resulting in the call being executed on the prestate of the requested height, instead of the poststate (which is the general expectation).
This PR attempts to solve this: https://github.com/filecoin-project/lotus/pull/11905, but it seems to be in some form of limbo.

@raulk That PR needs a review from someone who knows the ETH RPC stack really well but Steb is currently fully focused on F3. Would you or Mikers or Fridrick have the time to review it ?

authors: aarshkshah1992 cryptoAtwill raulk

repo: consensus-shipyard/ipc


text:
feat: restructure icons package

What does this PR do?

[x] restructure icons package

Support many import types:

@consolelabs/icons

@consolelabs/icons/line

@consolelabs/icons/line/icon-arrow-down
...

@chinhld12 this looks awesome. Can you update the storybook to separate the icons to groups?

Updated

repo: consolelabs/web-foundation


text:
🛑 tdm.incongru.org is down

In 1506c65, tdm.incongru.org (https://tdm.incongru.org) was down:

HTTP code: 0
Response time: 0 ms

Resolved: tdm.incongru.org is back up in 4cb1e1f.

repo: constructions-incongrues/status


text:
Userspace Convertor: Manifest Deduplication

Adds manifest deduplication, which prevents re-conversion of an already converted image if its result is known and already stored within the registry. This change also includes adjustments to support cross repo mounts for whole images, improvements for the userspace db functionality, usage samples and corresponding unit tests.
What this PR does / why we need it:
This change extends the functionality of the user space convertor's deduplication functionality to avoid reconverting already converted manifests. This is an optimization to avoid converting duplicates.
Which issue(s) this PR fixes:
Fixes #249
Please check the following list:

[x]  Does the affected code have corresponding tests, e.g. unit test, E2E test?
[x]  Does this change require a documentation update?
[ ]  Does this introduce breaking changes that would require an announcement or bumping the major version?
[x]  Do all new files have an appropriate license header?

I added the mentioned changes, can we revisit this to get it merged in?

@WaberZhuang  ptal

LGTM

authors: estebanreyl liulanzheng yuchen0cc

repo: containerd/accelerated-container-image


text:
Containerd not started for specific path (mkdir /run: read-only file system)

Description
I have a binary containerd and want to run it on my keenetic router
the /run directory doesnot exists and / is on read only filesystem and I try to change it.
I attempt to change relevant options but not changing anything.
Why it want to create /run and how to change it
/tmp/docker # ./containerd --address=/var/run/docker/containerd/containerd.sock --root=/var/run/docker/containerd --state=/var/run --log-level=debug
containerd: mkdir /run: read-only file system

/tmp/docker # ./containerd -v
containerd github.com/containerd/containerd v1.7.22 7f7fdf5fed64eb6a7caf99b3e12efcf9d60e311c

Steps to reproduce the issue

Describe the results you received and expected
Containerd not running as expected
What version of containerd are you using?
v1.7.22
Any other relevant information
No response
Show configuration if it is related to CRI plugin.
No response

containerd uses (and creates if not exist) /run/containerd folder to create and store transient data files (e.g., containerd related sockets, container bundles, etc). So /run should be writable to make containerd work IMO.

Is it possible to overide this path?

state path was changed, as mentioned in original description, but error is still apears

but error is still apears

The default /run/containerd state folder is still hardcoded and used in a few places
https://github.com/containerd/containerd/issues/11075#:~:text=Although you can change the State folder through containerd config%2C the default /run/containerd is still hard coded and used by a few other dependencies. %2310502 (comment)

repo: containerd/containerd


text:
Is the Single Instance right?

I see such code in containerd client.go:
// ContainerService returns the underlying container Store
func (c *Client) ContainerService() containers.Store {
	if c.containerStore != nil {
		return c.containerStore
	}
	c.connMu.Lock()
	defer c.connMu.Unlock()
	return NewRemoteContainerStore(containersapi.NewContainersClient(c.conn))
}

Everytime I call client.ContainerService(), the c.containerStore always is nil. So the if syntax can be removed? If we need a global single instance for containerStore, should set c.containerStore after call NewRemoteContainerStore?

Steps to reproduce the issue:
1.
2.
3.
Describe the results you received:
Describe the results you expected:
Output of containerd --version:
v1.3.0

Any other relevant information:

There are a few important mutability considerations here. c.containerStore is not a mutable value and can be safely checked and accessed without locking. On the other hand, the underlying connection can be mutated, such as with Reconnect. For this reason, a lock is acquired and a new instance is created whenever requesting access to the service. Note that while a new instance is created, there is no underlying initialization that happens for this instance. This pattern allows the caller to scope the service accordingly, normally accessed once per higher level operation. There isn't really a good way with the grpc clients today to scope these objects longer than a single grpc connection object. The grpc connection object itself has gotten fairly robust and is not tied to any single underlying connection. If we got rid of Reconnect, then we could probably hold a single instance.

authors: dmcgowan wi-cuckoo


text:
Use x/sys/unix instead of syscall

From a discussion on runc, the syscall package in Go is not well supported and we should be switching over to the sys/unix package instead.
We will have to port over the existing code but we should also be using this package in the future for all new code that is written.
runc: https://github.com/opencontainers/runc/issues/1364

this issue seems closable: https://github.com/containerd/containerd/pull/712

There are still a few places using syscall that could be replaced

I only changed the syscall usage in the execution code and didn't not touch anything else.

authors: AkihiroSuda crosbymichael dmcgowan


text:
Enable runc debug in shim

Enable runc debug for shim.
/cc @Random-Liu
closes #2243

LGTM

Codecov Report

Merging #2314 into master will not change coverage.
The diff coverage is n/a.

@@           Coverage Diff           @@
##           master    #2314   +/-   ##
=======================================
  Coverage   45.51%   45.51%
=======================================
  Files          83       83
  Lines        9190     9190
=======================================
  Hits         4183     4183
  Misses       4331     4331
  Partials      676      676

Flag
Coverage Δ

#linux
50.04% <ø> (ø)
:arrow_up:

#windows
41.24% <ø> (ø)
: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 a70e26c...530849f. Read the comment docs.

LGTM

authors: codecov-io crosbymichael ehazlett stevvooe


text:
Windows: appveyor: Build shim binary from Microsoft/hcsshim repo

Signed-off-by: John Howard jhoward@microsoft.com

Revendor Microsoft/hcsshim
Update appveyor to build containerd-shim-runhcs-v1.exe and runhcs.exe from hcsshim repo
Bumps appveyor to golang 1.12.1

This is a phased approach to removing the existing "v1" shim code for Windows from the containerd repo in preparation for v1.3. This first step ensures that the shim (and runhcs.exe although that will be removed later) are built during CI from the commit of hcsshim in the vendor.conf file.
Note that although built, this first step does not update the test scripts execution lines to include the path of the built binaries, so they will still use the shim binary build from the containerd/containerd repo.

Codecov Report

Merging #3128 into master will increase coverage by 3.99%.
The diff coverage is n/a.

@@            Coverage Diff             @@
##           master    #3128      +/-   ##
==========================================
+ Coverage   43.58%   47.57%   +3.99%
==========================================
  Files         104       93      -11
  Lines       11156     8608    -2548
==========================================
- Hits         4862     4095     -767
+ Misses       5555     3783    -1772
+ Partials      739      730       -9

Flag
Coverage Δ

#linux
47.57% <ø> (ø)
:arrow_up:

#windows
?

Impacted Files
Coverage Δ

remotes/docker/auth.go
63.82% <0%> (-3.97%)
:arrow_down:

remotes/docker/status.go
21.42% <0%> (-3.58%)
:arrow_down:

platforms/cpuinfo.go
3.77% <0%> (-0.85%)
:arrow_down:

log/context.go
36.84% <0%> (-0.66%)
:arrow_down:

namespaces/context.go
55% <0%> (-0.56%)
:arrow_down:

errdefs/grpc.go
74.6% <0%> (-0.4%)
:arrow_down:

remotes/docker/pusher.go
0% <0%> (ø)
:arrow_up:

content/local/locks.go
100% <0%> (ø)
:arrow_up:

labels/validate.go
100% <0%> (ø)
:arrow_up:

platforms/defaults.go
100% <0%> (ø)
:arrow_up:

... and 61 more

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 68c44f8...8040e2b. Read the comment docs.

@jterry75 @dmcgowan @crosbymichael PTAL.

Thanks @jhowardmsft! This is a great first step!
LGTM

authors: codecov-io jhowardmsft jterry75


text:
Fix typo in description comment

Signed-off-by: Phil Estes estesp@linux.vnet.ibm.com

Codecov Report

Merging #3290 into master will not change coverage.
The diff coverage is n/a.

@@          Coverage Diff           @@
##           master   #3290   +/-   ##
======================================
  Coverage    44.4%   44.4%
======================================
  Files         113     113
  Lines       12231   12231
======================================
  Hits         5431    5431
  Misses       5966    5966
  Partials      834     834

Flag
Coverage Δ

#linux
48.33% <ø> (ø)
:arrow_up:

#windows
39.66% <ø> (ø)
: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 b99a66c...62609d6. Read the comment docs.

authors: codecov-io estesp


text:
Fix double /dev/shm mount.

Cherrypick #816.
Signed-off-by: Lantao Liu lantaol@google.com

/retest

The test failure seems to be a test-infra bug. It should not use Kubernetes 1.12 to test.

/test pull-cri-containerd-node-e2e

@mikebrow I'm so sorry.... I thought you've LGTMed.......

/LGTM

authors: Random-Liu mikebrow

repo: containerd/cri


text:
Use golangci lint

We now use golangci-lint and apply some lint fixes.

Codecov Report

Merging #367 (9ed3030) into main (099b74f) will not change coverage.
The diff coverage is n/a.

:exclamation: Current head 9ed3030 differs from pull request most recent head 990498a. Consider uploading reports for the commit 990498a to get more accurate results

@@          Coverage Diff          @@
##            main    #367   +/-   ##
=====================================
  Coverage   6.89%   6.89%
=====================================
  Files          2       2
  Lines         29      29
  Branches      17      17
=====================================
  Hits           2       2
  Misses        27      27

authors: codecov-commenter saschagrunert

repo: containers/conmon-rs


text:
Podman does not ship systemd units for APIv2

Is this a BUG REPORT or FEATURE REQUEST? (leave only one on its own line)
/kind bug
Description
The new release podman-1.8.2-1 is still not shipping systemd units for the new APIv2 in Fedora.
It seems it exists in the repository in contrib/systemd/system/podman.service though.
Steps to reproduce the issue:
$ rpm -ql podman | grep systemd
/usr/lib/systemd/system/io.podman.service
/usr/lib/systemd/system/io.podman.socket
/usr/lib/systemd/user/io.podman.service
/usr/lib/systemd/user/io.podman.socket

These are though units for varlink and not for the REST API.
Package info (e.g. output of rpm -q podman or apt list podman):
podman-1.8.2-1.fc31.x86_64

I have patched the spec files and retriggered builds so we can get this release updated without having to bump the release.

I guess this was fixed in #5567

authors: marusak rhatdan

repo: containers/libpod


text:
WIP: Test github.com/mtrmac/image:mirror-reference

Just to run tests for https://github.com/containers/image/pull/912 .

The c/image PR was merged, so this is no longer necessary.


text:
invalid opcode on KVM guest

When trying to use the netavark networking stack with Podman on Arch Linux, I am getting a "invalid opcode" error when starting any container.
This is a KVM guest managed by a VPS provider, so if this is a CPU instruction passthrough issue, it's probably unlikely I'll be able to get them to change the CPU mode so that more instructions are exposed. I don't see anywhere in the documentation what instruction sets I need to run netavark.
Versions:
netavark 1.0.3
podman 4.1.0
kernel: device vethdcfc935f left promiscuous mode
kernel: podman1: port 1(vethdcfc935f) entered disabled state
kernel: traps: netavark[1685] trap invalid opcode ip:55beb0d236c8 sp:7ffc555f92a0 error:0 in netavark[55beb0b89000+460000]
systemd[1]: Started Process Core Dump (PID 1695/UID 0).
systemd-coredump[1696]: [🡕]  Process 1685 (netavark) of user 0 dumped core.

Module linux-vdso.so.1 with build-id 378b7a2b733e1cd98f6f9840062ab85f6b4c663e
Module ld-linux-x86-64.so.2 with build-id fc93487393eea02b5bc6e76e48976fc325294c24
Module libc.so.6 with build-id 388993b6ef62f964bc7bf473c069fbfe957b9e44
Module libm.so.6 with build-id 210ec9905e41825671210f8f7d0b24d6c371196a
Module libgcc_s.so.1 with build-id 63dfd9229f32a325dc1c95d35bf9106fa9ed1031
Module netavark with build-id e90d94a4c388d0f10b6887f0d327a3e174c24b4c
Stack trace of thread 1685:
#0  0x000055beb0d236c8 n/a (netavark + 0x1ed6c8)
#1  0x000055beb0c814c5 n/a (netavark + 0x14b4c5)
#2  0x000055beb0cb9c79 n/a (netavark + 0x183c79)
#3  0x000055beb0ba11fa n/a (netavark + 0x6b1fa)
#4  0x000055beb0ba47b3 n/a (netavark + 0x6e7b3)
#5  0x000055beb0ba8f29 n/a (netavark + 0x72f29)
#6  0x000055beb0fb6b1e n/a (netavark + 0x480b1e)
#7  0x000055beb0ba2982 n/a (netavark + 0x6c982)
#8  0x00007fd56b213290 n/a (libc.so.6 + 0x29290)
#9  0x00007fd56b21334a __libc_start_main (libc.so.6 + 0x2934a)
#10 0x000055beb0b9ebb5 n/a (netavark + 0x68bb5)
ELF object binary architecture: AMD x86-64

lscpu output:
Architecture:            x86_64
  CPU op-mode(s):        32-bit, 64-bit
  Address sizes:         46 bits physical, 48 bits virtual
  Byte Order:            Little Endian
CPU(s):                  3
  On-line CPU(s) list:   0-2
Vendor ID:               GenuineIntel
  BIOS Vendor ID:        Bochs
  Model name:            QEMU Virtual CPU version (cpu64-rhel6)
    BIOS Model name:       CPU @ 2.0GHz
    BIOS CPU family:     1
    CPU family:          6
    Model:               13
    Thread(s) per core:  1
    Core(s) per socket:  1
    Socket(s):           3
    Stepping:            3
    BogoMIPS:            4401.32
    Flags:               fpu de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pse36 clflush mmx fxsr sse sse2 syscall nx lm nopl cpuid tsc_known_freq pni cx16 hypervisor lahf_lm pti
Virtualization features:
  Hypervisor vendor:     KVM
  Virtualization type:   full
Caches (sum of all):
  L1d:                   96 KiB (3 instances)
  L1i:                   96 KiB (3 instances)
  L2:                    12 MiB (3 instances)
NUMA:
  NUMA node(s):          1
  NUMA node0 CPU(s):     0-2
Vulnerabilities:
  Itlb multihit:         KVM: Mitigation: VMX unsupported
  L1tf:                  Mitigation; PTE Inversion
  Mds:                   Vulnerable: Clear CPU buffers attempted, no microcode; SMT Host state unknown
  Meltdown:              Mitigation; PTI
  Spec store bypass:     Vulnerable
  Spectre v1:            Mitigation; usercopy/swapgs barriers and __user pointer sanitization
  Spectre v2:            Mitigation; Retpolines, STIBP disabled, RSB filling
  Srbds:                 Not affected
  Tsx async abort:       Not affected

What distro is this? Can you build from source and see if this works?

What distro is this? Can you build from source and see if this works?

Sorry, I edited in that info late. I'm using Arch Linux.
I modified their official PKGBUILD to compile the latest commit, and still the same error. For reference, here are the build options I used:
pkgname=netavark
_commit=3e82f1c451e2059febeab224ddf5041bc2342264
pkgver=1.0.3
pkgrel=2
pkgdesc="Container network stack"
arch=(x86_64)
url="https://github.com/containers/netavark"
license=(Apache)
depends=(gcc-libs glibc)
makedepends=(cargo git libgit2 mandown)
optdepends=('aardvark-dns: for authorative DNS server')
provides=(container-network-stack=2)
source=(git+https://github.com/containers/netavark.git#commit=$_commit)
sha256sums=('SKIP')

prepare() {
  cd $pkgname
  cargo fetch --locked --target "$CARCH-unknown-linux-gnu"
}

build() {
  export RUSTUP_TOOLCHAIN=stable
  export CARGO_TARGET_DIR=target

  cd $pkgname
  cargo build --frozen --release --all-features
  make -C docs
}

check() {
  export RUSTUP_TOOLCHAIN=stable

  cd $pkgname
  cargo test --frozen --all-features
}

package() {
  cd $pkgname
  install -vDm 755 target/release/$pkgname -t "$pkgdir/usr/lib/podman/"
  make DESTDIR="$pkgdir" PREFIX=/usr install -C docs
  install -vDm 644 README.md -t "$pkgdir/usr/share/doc/$pkgname/"
}

Do you get a core file ?

Do you get a core file ?

Yes, core dumps are created. I have attached them for you. There's multiple ones after each attempt, but that's probably because of how quadlet sets up the systemd service to retry
coredump.tar.gz

ah! when you start this without quadlet does it work ok?

ah! when you start this without quadlet does it work ok?

I still get a fatal 'trap invalid opcode' error in the journal, but this time podman prints out "Error: netavark: : EOF"
Command used:
podman run -d \
    --net=services \
    -p 80:80 \
    -p 443:443 \
    -v caddy_data:/data \
    -v caddy_config:/config \
    -v /etc/Caddyfile:/etc/caddy/Caddyfile \
    caddy:alpine

contents of podman network inspect services

contents of podman network inspect services

[
     {
          "name": "services",
          "id": "2360b1d08c51924cd01f247f368a0378e41bbd3394973c63e9904080107a419a",
          "driver": "bridge",
          "network_interface": "podman1",
          "created": "2022-05-14T00:13:33.792044793-04:00",
          "subnets": [
               {
                    "subnet": "10.89.0.0/24",
                    "gateway": "10.89.0.1"
               }
          ],
          "ipv6_enabled": false,
          "internal": false,
          "dns_enabled": true,
          "ipam_options": {
               "driver": "host-local"
          }
     }
]

Also went ahead and tried the default podman bridge by removing --net. No difference

I'm going to close this. I no longer have access to the VM in question

repo: containers/netavark


text:
[skip-ci] Packit: constrain koji and bodhi to the fedora package

This helps to avoid dup downstream jobs. Doesn't affect upstream.

ah this one's a 400 error

/packit build


text:
aardvark: only use systemd-run when systemd is available

According to sd_booted(3) checking if /run/systemd/system exists is good
enough to see if systemd is booted.
While this check is not perfect it will at least allow us to use it
inside a container where systemd binaries are installed but the
container is run without systemd, see
https://github.com/containers/podman/issues/13533
Another option would be to use the systemd dbus API. I gave it a try but
couldn't figure out the exact format we have to send and also had
trouble connecting to the rootless session.
For now this should help to get aardvark working inside a container.

@mheon @baude @flouthoc PTAL

GH is down :|


text:
rootful podman fails with recent youki

I found rootful podman run with recent youki fails.
[ori@localhost youki]$ sudo podman --runtime $(pwd)/youki run quay.io/podman/hello
[DEBUG crates/youki/src/main.rs:92] 2022-12-16T00:38:24.961484949+09:00 started by user 0 with ArgsOs { inner: ["/home/ori/devel/src/github.com/containers/youki/youki", "delete", "--force", "aeb2eb9982d5e605608606c4009c300de3bf58ac938cb42f0c66c634f666834f"] }
[DEBUG crates/youki/src/commands/delete.rs:8] 2022-12-16T00:38:24.961997393+09:00 start deleting aeb2eb9982d5e605608606c4009c300de3bf58ac938cb42f0c66c634f666834f
[DEBUG crates/libcontainer/src/container/container_delete.rs:36] 2022-12-16T00:38:24.962203955+09:00 container status: Stopped
[DEBUG crates/libcontainer/src/container/container_delete.rs:42] 2022-12-16T00:38:24.962309935+09:00 config: YoukiConfig { hooks: None, cgroup_path: "machine.slice:libpod:aeb2eb9982d5e605608606c4009c300de3bf58ac938cb42f0c66c634f666834f" }
[DEBUG crates/libcontainer/src/container/container_delete.rs:45] 2022-12-16T00:38:24.962344402+09:00 remove dir "/run/youki/aeb2eb9982d5e605608606c4009c300de3bf58ac938cb42f0c66c634f666834f"
Error: failed to delete container aeb2eb9982d5e605608606c4009c300de3bf58ac938cb42f0c66c634f666834f

Caused by:
    container state does not contain cgroup manager
ERRO[0000] Removing container aeb2eb9982d5e605608606c4009c300de3bf58ac938cb42f0c66c634f666834f from runtime after creation failed
Error: OCI runtime error: /home/ori/devel/src/github.com/containers/youki/youki: [DEBUG crates/youki/src/main.rs:92] 2022-12-16T00:38:24.892489813+09:00 started by user 0 with ArgsOs { inner: ["/home/ori/devel/src/github.com/containers/youki/youki", "--systemd-cgroup", "create", "--bundle", "/var/lib/containers/storage/overlay-containers/aeb2eb9982d5e605608606c4009c300de3bf58ac938cb42f0c66c634f666834f/userdata", "--pid-file", "/var/run/containers/storage/overlay-containers/aeb2eb9982d5e605608606c4009c300de3bf58ac938cb42f0c66c634f666834f/userdata/pidfile", "aeb2eb9982d5e605608606c4009c300de3bf58ac938cb42f0c66c634f666834f"] }
[DEBUG crates/libcontainer/src/container/init_builder.rs:100] 2022-12-16T00:38:24.897153686+09:00 container directory will be "/run/youki/aeb2eb9982d5e605608606c4009c300de3bf58ac938cb42f0c66c634f666834f"
[DEBUG crates/libcontainer/src/container/container.rs:191] 2022-12-16T00:38:24.897231672+09:00 Save container status: Container { state: State { oci_version: "v1.0.2", id: "aeb2eb9982d5e605608606c4009c300de3bf58ac938cb42f0c66c634f666834f", status: Creating, pid: None, bundle: "/var/lib/containers/storage/overlay-containers/aeb2eb9982d5e605608606c4009c300de3bf58ac938cb42f0c66c634f666834f/userdata", annotations: Some({}), created: None, creator: None, use_systemd: None }, root: "/run/youki/aeb2eb9982d5e605608606c4009c300de3bf58ac938cb42f0c66c634f666834f" } in "/run/youki/aeb2eb9982d5e605608606c4009c300de3bf58ac938cb42f0c66c634f666834f"
[DEBUG crates/libcontainer/src/rootless.rs:51] 2022-12-16T00:38:24.897379897+09:00 This is NOT a rootless container
[INFO crates/libcgroups/src/common.rs:232] 2022-12-16T00:38:24.897583381+09:00 systemd cgroup manager with system bus true will be used
[INFO crates/libcgroups/src/common.rs:232] 2022-12-16T00:38:24.898363447+09:00 systemd cgroup manager with system bus true will be used
Error: failed to construct cgroups path

Caused by:
    0: failed to create container
    1: failed to construct cgroups path
    2: failed to get systemd control group
    3: Did not receive a reply. Possible causes include: the remote application did not send a reply, the message bus security policy blocked the reply, the reply timeout expired, or the network connection was broken.
[ori@localhost youki]$

I bisected and found the first bad commit was 5aec0ffd4dbf0f01325abeb757823738d75eef42.
[ori@localhost youki]$ git show --quiet 5aec0ffd4dbf0f01325abeb757823738d75eef42
commit 5aec0ffd4dbf0f01325abeb757823738d75eef42 (HEAD)
Author: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com>
Date:   Mon Jul 18 12:19:59 2022 +0000

    chore(deps): bump dbus from 0.9.5 to 0.9.6

    Bumps [dbus](https://github.com/diwic/dbus-rs) from 0.9.5 to 0.9.6.
    - [Release notes](https://github.com/diwic/dbus-rs/releases)
    - [Commits](https://github.com/diwic/dbus-rs/compare/dbus-v0.9.5...dbus-v0.9.6)

    ---
    updated-dependencies:
    - dependency-name: dbus
      dependency-type: direct:production
      update-type: version-update:semver-patch
    ...

    Signed-off-by: dependabot[bot] <support@github.com>

I'm confused but after testing with dbus v0.9.5, I re-ran youki with dbus v0.9.6, but could not reproduce the symptom.
I don't why the symptom disappeared (I ran rustup update, I wonder if that had any effect...), but I can never reproduce the symptom anymore.
Let me close this issue, thanks.

@orimanabu hmm... Curious. Thanks for your report. If you will find a way to reproduce this problem, feel free to reopen this issue.

repo: containers/youki


text:
Add support for seccomp filter flags

Container runtimes like crun already support the flags: https://github.com/containers/crun/commit/fefabffa2816ea343068ed036a86944393db189a
We now support the flags SECCOMP_FILTER_FLAG_SPEC_ALLOW, SECCOMP_FILTER_FLAG_TSYNC as well as SECCOMP_FILTER_FLAG_LOG and refactor the flag code into the filter context.

Codecov Report

Merging #733 (2cf3324) into main (673d2e1) will decrease coverage by 0.09%.
The diff coverage is 37.14%.

@@            Coverage Diff             @@
##             main     #733      +/-   ##
==========================================
- Coverage   72.52%   72.43%   -0.10%
==========================================
  Files          86       86
  Lines       11740    11763      +23
==========================================
+ Hits         8515     8520       +5
- Misses       3225     3243      +18


text:
Traevik v2.1.0 rc3 Dashboard: Lists Only First 10 Routers

Do you want to request a feature or report a bug?
Bug
What did you do?
Create 11 IngressRoute CRDs and visit the Dashboard's HTTP Routers Page
What did you expect to see?
11 of those routers listed, or the ability to page through them
What did you see instead?
Only the first 10 routers listed. Some are from Traefik itself, like PathPrefix(/api).
The badge count on top looks correct, reporting HTTP Routers (14).
The previous/next page buttons on the bottom of the list are disabled.
I see the xhr call for /api/overview reporting correctly as well.
{
	"http": {
		"routers": {
			"total": 14,
			"warnings": 0,
			"errors": 0
		},
		"services": {
			"total": 14,
			"warnings": 0,
			"errors": 0
		},
		"middlewares": {
			"total": 3,
			"warnings": 0,
			"errors": 0
		}
	},
	"tcp": {
		"routers": {
			"total": 0,
			"warnings": 0,
			"errors": 0
		},
		"services": {
			"total": 0,
			"warnings": 0,
			"errors": 0
		}
	},
	"features": {
		"tracing": "",
		"metrics": "",
		"accessLog": true
	},
	"providers": ["KubernetesCRD"]
}

Output of traefik version: (What version of Traefik are you using?)
v2.1.0 rc3
What is your environment & configuration (arguments, toml, provider, platform, ...)?
Kubernetes Deployment with 1 replica
- --api
- --api.dashboard=true
- --api.insecure=true
- --serversTransport.insecureSkipVerify=true
- --accesslog=true
- --entrypoints.web.Address=:8000
- --entryPoints.web-secure.Address=:4443
- --entryPoints.web.forwardedHeaders.insecure
- --entryPoints.web-secure.forwardedHeaders.insecure
- --providers.kubernetescrd
- --certificatesResolvers.default.acme.httpChallenge.entryPoint=web
- --certificatesresolvers.default.acme.email=__my_email_address__
- --certificatesresolvers.default.acme.storage=/somewhere/acme.json
- --ping
- --log=true

duplicate of #5959

authors: ldez ystan-

repo: containous/traefik


text:
marathon and traefik 2.1 dial wrong IP and return 504 gateway timeout

Bug
What did you do?
I have deployed the following app on marathon:
{
  "id": "/whoami",
  "cpus": 0.1,
  "mem": 256.0,
  "instances": 3,
  "labels": {
    "traefik.enable": "true",
    "traefik.http.routers.whoami.rule": "Host(`traefik-testing.mydomain.com`)",
    "traefik.http.routers.whoami.entrypoints": "web"
  },
  "container": {
    "type": "DOCKER",
    "docker": {
      "image": "containous/whoami",
      "network": "BRIDGE",
      "portMappings": [
        {
          "containerPort": 80,
          "hostPort": 0,
          "name": "http-api",
          "protocol": "tcp"
        }
      ]
    }
  },
  "readinessChecks": [
    {
      "name": "readinessCheck",
      "protocol": "HTTP",
      "path": "/",
      "portName": "http-api",
      "intervalSeconds": 30,
      "timeoutSeconds": 10,
      "httpStatusCodesForReady": [200],
      "preserveLastResponse": false
    }
  ],
  "healthChecks": [
    {
      "path": "/",
      "portIndex": 0,
      "protocol": "HTTP",
      "gracePeriodSeconds": 30,
      "intervalSeconds": 10,
      "timeoutSeconds": 30,
      "maxConsecutiveFailures": 3
    }
  ]
}

This is the docker-compose.yml used to start the traefik container on localhost, that can reach marathon on the LAN through http://192.168.0.22:8080:
version: '3'
services:
  reverse-proxy:
    image: traefik:v2.1
    network_mode: "host"
    ports:
      - "80:80"
      - "443:443"
      - "8080:8080"
    volumes:
      - "/var/run/docker.sock:/var/run/docker.sock:ro"
      - "./traefik.yaml:/etc/traefik/traefik.yaml"
      - "./letsencrypt:/letsencrypt"

What did you expect to see?
I expect to be able to succeed this command:
curl -H 'Host: traefik-testing.mydomain.com' -L http://localhost

What did you see instead?
Curl response:
Gateway Timeout

traefik debug log:
Output of traefik version: (What version of Traefik are you using?)
v2.1

What is your environment & configuration (arguments, toml, provider, platform, ...)?
This is my traefik.yaml
log:
  level: "DEBUG"
entryPoints:
  web:
    address: ":80"
  web-secure:
    address: ":443"
providers:
  marathon:
    endpoint: "http://192.168.0.22:8080"
    watch: true

If applicable, please paste the log output in DEBUG level (--log.level=DEBUG switch)
reverse-proxy_1  | time="2019-12-11T13:45:56Z" level=debug msg="'504 Gateway Timeout' caused by: dial tcp 212.95.74.75:31400: i/o timeout"

Note: the IP it dial as nothing to do with my LAN, it is owned by my ISP and it is not even my WAN address.
On the dashboard, IP are correctly guessed and all are reachable by telnet from traefik host.
I am out of idea, it simply does not work with marathon, any idea what is failing here?
Thanks and best!

Hi! I'm Træfiker :robot: the bot in charge of communication regulation.
Thanks for your interest in Traefik!
We dedicate the issue tracker to bug reports and feature requests only. My advanced AI has spotted that your issue might be a configuration problem or relates to something that doesn't look like a bug.
To confirm this, please join our Community Forum and reach out to us on the Traefik section.
In case I'm wrong (well, that would be embarrassing :sweat_smile:), my developers will re-open the issue and fix me!
In the meantime, you can double check Traefik's documentation.

Thanks @traefiker but I bet you are wrong. I am reading in loop the documentation and my configuration should not behave like that. IP retrieval on marathon seems to have a bug. Can we please investigate?

After some investigation, it seems that traefik is having an issue to resolve DNS that can be resolved by the host.
dial tcp 212.95.74.75:31400: i/o timeout happen because it's my ISP fall back when accessing a wrong domain. https://212.95.74.75:443 look like this

I expect things to work because the host can talk to any service in my network, instead it fail to resolve a DNS or break something related to DNS that it can't proxy to that DNS served by marathon and fallback to the ISP ip.
I believe there should not have any DNS resolution here and that's most likely a bug....

Seems related to https://github.com/containous/traefik/issues/1243

I did some tcpdump,
My /etc/resolv.conf:
# Generated by NetworkManager
search numericable.fr
nameserver 8.8.8.8
nameserver 8.8.4.4

It seems that dev-11.numericable.fr is really redirecting to 212.95.74.75
I was configuring marathon with an intranet host (dev-11), this was the tcp dump:
/ # tcpdump -ni any port 53
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on any, link-type LINUX_SLL (Linux cooked v1), capture size 262144 bytes

23:37:25.891422 IP 192.168.0.16.34846 > 8.8.8.8.53: 378+ AAAA? dev-11.numericable.fr. (39)
23:37:25.891479 IP 192.168.0.16.50642 > 8.8.8.8.53: 43249+ A? dev-11.numericable.fr. (39)
23:37:25.904896 IP 8.8.8.8.53 > 192.168.0.16.34846: 378 1/1/0 CNAME nc-ass-vip.sdv.fr. (120)
23:37:25.930865 IP 8.8.8.8.53 > 192.168.0.16.50642: 43249 2/0/0 CNAME nc-ass-vip.sdv.fr., A 212.95.74.75 (84)
23:37:26.739694 IP 192.168.0.16.37848 > 8.8.8.8.53: 4284+ A? static.asm.skype.com. (38)
23:37:26.801338 IP 8.8.8.8.53 > 192.168.0.16.37848: 4284 3/0/0 CNAME static-asm-skype.trafficmanager.net., CNAME neu1-authgw.cloudapp.net., A 13.94.102.123 (138)
23:37:41.825827 IP 192.168.0.16.52410 > 8.8.8.8.53: 11463+ A? static.asm.skype.com. (38)
23:37:41.838653 IP 8.8.8.8.53 > 192.168.0.16.52410: 11463 3/0/0 CNAME static-asm-skype.trafficmanager.net., CNAME neu1-authgw.cloudapp.net., A 13.94.102.123 (138)
23:37:41.865510 IP 192.168.0.16.58649 > 8.8.8.8.53: 5711+ A? c1.iggcdn.com. (31)
23:37:41.880401 IP 8.8.8.8.53 > 192.168.0.16.58649: 5711 1/0/0 A 34.102.138.247 (47)
23:37:41.903823 IP 192.168.0.16.57996 > 8.8.8.8.53: 58412+ A? pixel.adsafeprotected.com. (43)
23:37:41.925646 IP 8.8.8.8.53 > 192.168.0.16.57996: 58412 2/0/0 CNAME anycast.pixel.adsafeprotected.com., A 199.166.0.26 (81)
23:37:41.947066 IP 192.168.0.16.60551 > 8.8.8.8.53: 42171+ A? fonts.googleapis.com. (38)
23:37:41.961610 IP 8.8.8.8.53 > 192.168.0.16.60551: 42171 1/0/0 A 216.58.215.42 (54)
23:37:50.180251 IP 192.168.0.16.48654 > 8.8.8.8.53: 14439+ A? d3cv4a9a9wh0bt.cloudfront.net. (47)
23:37:50.191554 IP 8.8.8.8.53 > 192.168.0.16.48654: 14439 4/0/0 A 13.225.84.215, A 13.225.84.133, A 13.225.84.80, A 13.225.84.126 (111)

It was fallbacking to dev-11.numericable.fr, so I have configured a fqdn (dev-11.yeutech.vn) with marathon, now the tcpdump look like:

/ # tcpdump -ni any port 53 tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on any, link-type LINUX_SLL (Linux cooked v1), capture size 262144 bytes 23:45:51.408693 IP 192.168.0.16.52437 > 8.8.8.8.53: 60928+ A? static.asm.skype.com. (38) 23:45:51.435049 IP 8.8.8.8.53 > 192.168.0.16.52437: 60928 3/0/0 CNAME static-asm-skype.trafficmanager.net., CNAME neu1-authgw.cloudapp.net., A 13.94.102.123 (138) 23:45:51.457513 IP 192.168.0.16.58807 > 8.8.8.8.53: 13877+ A? edge.skype.com. (32) 23:45:51.465513 IP 8.8.8.8.53 > 192.168.0.16.58807: 13877 3/0/0 CNAME edge-skype-com.s-0001.s-msedge.net., CNAME s-0001.s-msedge.net., A 13.107.3.128 (110) 23:45:51.488500 IP 192.168.0.16.51746 > 8.8.8.8.53: 41661+ A? csm.nl.eu.criteo.net. (38) 23:45:51.497684 IP 8.8.8.8.53 > 192.168.0.16.51746: 41661 1/0/0 A 178.250.2.150 (54) 23:45:56.754038 IP 192.168.0.16.56726 > 8.8.8.8.53: 6818+ AAAA? dev-11.yeutech.vn. (35) 23:45:56.754055 IP 192.168.0.16.42437 > 8.8.8.8.53: 59618+ A? dev-11.yeutech.vn. (35) 23:45:57.177981 IP 8.8.8.8.53 > 192.168.0.16.56726: 6818 NXDomain 0/1/0 (91) 23:45:57.178003 IP 8.8.8.8.53 > 192.168.0.16.42437: 59618 NXDomain 0/1/0 (91) 23:45:57.178478 IP 192.168.0.16.40609 > 8.8.8.8.53: 17534+ AAAA? dev-11.yeutech.vn.numericable.fr. (50) 23:45:57.178504 IP 192.168.0.16.54313 > 8.8.8.8.53: 63898+ A? dev-11.yeutech.vn.numericable.fr. (50) 23:45:57.205267 IP 8.8.8.8.53 > 192.168.0.16.54313: 63898 2/0/0 CNAME nc-ass-vip.sdv.fr., A 212.95.74.75 (95) 23:45:57.217886 IP 8.8.8.8.53 > 192.168.0.16.40609: 17534 1/1/0 CNAME nc-ass-vip.sdv.fr. (131) 23:46:06.521472 IP 192.168.0.16.34661 > 8.8.8.8.53: 33403+ A? static.asm.skype.com. (38) 23:46:06.552800 IP 8.8.8.8.53 > 192.168.0.16.34661: 33403 3/0/0 CNAME static-asm-skype.trafficmanager.net., CNAME neu1-authgw.cloudapp.net., A 13.94.102.123 (138) 23:46:06.574352 IP 192.168.0.16.43737 > 8.8.8.8.53: 24754+ A? static-asm.secure.skypeassets.com. (51) 23:46:06.597444 IP 8.8.8.8.53 > 192.168.0.16.43737: 24754 6/0/0 CNAME 1180c.wpc.azureedge.net., CNAME 1180c.ec.azureedge.net., CNAME lb.apr-1180c.edgecastdns.net., CNAME hlb.apr-1180c-0.edgecastdns.net., CNAME cs10.wpc.v0cdn.net., A 68.232.34.200 (225) 23:46:06.618327 IP 192.168.0.16.44711 > 8.8.8.8.53: 51941+ A? www.googleapis.com. (36) 23:46:06.634170 IP 8.8.8.8.53 > 192.168.0.16.44711: 51941 1/0/0 A 216.58.201.234 (52)
--

I am still confused, because my /etc/hosts is having :
/ # cat /etc/hosts | grep dev-11
192.168.0.22 dev-11.yeutech.vn dev-11

host file seems to be ignored by traefik...

After doing:

using marathon with FQDN dev-11.yeutech.vn
creating a real DNS, dev-11.yeutech.vn
opening marathon private port publicly

I was able to query my server. But I don't know how to fix it, because the port can't remain publicly open, and I don't know why /etc/hosts does not get resolved causing all those issue.
Any idea?

Not related to #1243, it seems that /etc/hosts is ignored totally by traeffic.
Related to https://stackoverflow.com/questions/49476452/traefik-forwarding-to-a-host-and-overriding-ip
/etc/nsswitch.conf is absent from the system, doing:
echo "hosts: files dns" > /etc/nsswitch.conf

will solve the issue of /etc/hosts being ignore.

authors: kopax traefiker


text:
examples/k8s: Add missing type on service

When following the tutorial, k8s complains about the traefik-ingress-service:
$ kubectl apply -f traefik-ds.yaml
serviceaccount "traefik-ingress-controller" unchanged
daemonset.extensions "traefik-ingress-controller" created
The Service "traefik-ingress-service" is invalid:
* spec.ports[0].nodePort: Forbidden: may not be used when `type` is 'ClusterIP'
* spec.ports[1].nodePort: Forbidden: may not be used when `type` is 'ClusterIP

The default type seems to be wrong for this use-case. Setting it to the same type as it was previously set by traefik-deployment.yaml.

When I kubectl create -f examples/k8s/traefik-ds.yaml I get:
serviceaccount "traefik-ingress-controller" created
daemonset "traefik-ingress-controller" created
service "traefik-ingress-service" created

The service for daemonset should not have a nodeport in the example.

Hello @GeertJohan,
Thanks for your PR, however, we feel that the current files are correct.
Please feel free to discuss on our slack: https://slack.traefik.io/ if you have any more questions.
Thanks!

I got the same problem:
kubectl version:
kubectl version
Client Version: version.Info{Major:"1", Minor:"10", GitVersion:"v1.10.4", GitCommit:"5ca598b4ba5abb89bb773071ce452e33fb66339d", GitTreeState:"clean", BuildDate:"2018-06-06T08:13:03Z", GoVersion:"go1.9.3", Compiler:"gc", Platform:"linux/amd64"}
Server Version: version.Info{Major:"1", Minor:"10", GitVersion:"v1.10.4", GitCommit:"5ca598b4ba5abb89bb773071ce452e33fb66339d", GitTreeState:"clean", BuildDate:"2018-06-06T08:00:59Z", GoVersion:"go1.9.3", Compiler:"gc", Platform:"linux/amd64"}

Service file, as same as the github one
kind: Service
apiVersion: v1
metadata:
  name: traefik-ingress-service
  namespace: kube-system
spec:
  selector:
    k8s-app: traefik-ingress-lb
  ports:
    - protocol: TCP
      port: 80
      name: web
    - protocol: TCP
      port: 8080
      name: admin

Output:
kubectl apply -f traefik-service.yaml
The Service "traefik-ingress-service" is invalid:
* spec.ports[0].nodePort: Forbidden: may not be used when `type` is 'ClusterIP'
* spec.ports[1].nodePort: Forbidden: may not be used when `type` is 'ClusterIP'

What is the spec.ports anyway? Why kubectl consider them as nodePort but you say no?

authors: GeertJohan catscarlet dtomcej


text:
detailed call information on panic

Proposal
The current code panic cannot locate the code location. Can you provide panic related information, such as the name and line number of the calling function
Background

Workarounds

This information does not contain the internal information of the script. All the errors cannot be located in the script

Additional work is indeed necessary to dump a stack trace at interpreter level. Only runtime stack trace is available right now.

Thanks for sharing this type of information, it is so useful for me. nice work keep it up. Software Testing Training in Chennai  |  Software Testing Training in Anna Nagar |  Software Testing Training in OMR |  Software Testing Training in Porur | Software Testing Training in Tambaram |  Software Testing Training in Velachery

repo: containous/yaegi


text:
Messfunktion: Rückgängig und Abbrechen ist fehlerhaft

Teilstrecken bleiben in der Karte sichtbar, wenn die Funktion 'Rückgängig' genutzt wird

Zeichnen eines Polygons:

Lezten Schritt Rückgängig machen:

Beim Abbrechen der Zeichnung

bleiben die Messwerte in der Karte und
das Zeichenwerkzeug ist nicht mehr aktiv, obwohl es im Dialog noch aktiv dargestellt wird. Eine Karteninteraktion ist gar nicht mehr möglich (auch kein Pan), bis das Werkzeug deaktiviert wird.

Die Funktionen "Undo", "Redo" und "Cancel" wurden im Bezug auf das Messen überarbeitet und funktionieren jetzt wie erwartet. Beim "Rückgängig"-Machen des letzten Schritts wird die zugehörige Messung entfernt und beim "Wiederholen" des Schritts erneut angezeigt. Beim Abbrechen werden alle Messungen des zuletzt gezeichneten Objekts entfernt und das Sketching-Tool wieder aktiviert.

authors: marcwilkes mkrage-ct

repo: conterra/mapapps-sketching-enhanced


text:
Messfunktion: Es sollte konfigurierbar sein, ob die Kantenlängen von Polygonen in der Karte dargestellt werden.

Die Darstellung von Teilstrecken und Kanten soll im Dialog aktivert bzw. deaktiviert werden können. Die Voreinstellungen sollen konfigurierbar sein. Idealerweise kann man dies für jeden Geometrietyp individuell einstellen, so dass z.B. Teilstrecken bei Linienzügen dargestellt werden, einzelne Kanten eines Polygons aber nicht.

Innerhalb des Sketching Dialogs öffnet sich beim Aktivieren des Messens nun ein weiterer Abschnitt mit zwei Checkboxen, in denen eingestellt werden kann, ob Linien und Kantenlängen angezeigt werden sollen oder nicht. Die Voreinstellungen dazu sind über die app.json konfigurierbar.


text:
Backport Symfony app endpoint code to php images

Since PHP images are effectively doing the same thing, and other images aren't really related to Symfony but extending it just for this functionality, move it to the PHP images so it's more accessible.
Note there is a non-BC change here in the PHP image, in that the image no longer has the app endpoint enabled by default. This is because most

tested and fixed a few issues, but also I:

renamed APP_ENDPOINT_REDIRECT to APP_ENDPOINT_REWRITE (rebased into the original commit)
changed the strict mode to hide the PHP files so as if they weren't there

repo: continuouspipe/dockerfiles


text:
Add doc for steps to work on fork of project

Based on various blogs the standard procedure to work on a fork of a go project on github seems to be as follows :

Set GOPATH
Install the original repo and its dependencies using git get command. This actually does a git clone for all the src directories so you do not need to do that
go get -u github.com/contiv/netplugin
Go to the downloaded src directory
cd $GOPATH/src/github.com/contiv/netplugin
Do git remote add
git remote add fork <your GitHub fork URL, pasted from the clipboard>
Make your code changes then:
git push fork

(if instead you wanted to just push changes to contiv repo directly you would skip step 4. Basically there is no need to do git clone either ways as go does that for you).
e.x. see
http://blog.campoy.cat/2014/03/github-and-go-forking-pull-requests-and.html
Or,
https://github.com/limetext/lime/wiki/Forking
If this sounds correct - let me know if I should update/add doc with this info.

@mapuri  and @sachja Can we close this issue now  ?

yes, this is an old issue. Let's open new issue if needed.

Closing it now !

authors: gaurav-dalvi mapuri sachja

repo: contiv/netplugin


text:
Added EPG resource

Create EPG resource to allocate EPG IDs. This replaces the global EPG state that was maintained.

LGTM other than minor comments.

Closing this. Working on a separate ID resource to handle this properly. Will raise a separate PR

authors: DivyaVavili abhinandanpb


text:
Added capability to change the loading dialog and snackbar's message text.

As above.
using(var dialog = await MaterialDialog.Instance.LoadingDialogAsync(message: "Something is running"))
{
await Task.Delay(5000) // Represents a task that is running.
dialog.Text = "Something else is running now!";
await Task.Delay(5000) // Represents a task that is running.
}
using(var snackbar = await MaterialDialog.Instance.LoadingSnackbarAsync(message: "Something is running"))
{
await Task.Delay(5000) // Represents a task that is running.
snackbar.Text = "Something else is running now!";
await Task.Delay(5000) // Represents a task that is running.
}

Hi. Can you make a pull request to the dev branch instead?


text:
Support ON-PREM API Key credentials

The current version of Python Client uses username/password for on-prem and API Key for Control-M Helix.
The v21 on-prem supports API Key as well.
I think that Environment class can be changed to support this. The default constructor functions as well the documentation is a little misleading, saying that the API are different based on the type of environment.
This class - IMO - should be changed just to specify to what type of authentication the user will use and where he will connect. Some values can be pre-populated as it is right now (ie. Workbench = localhost).

Is this functionality still planned to be added?

Just use SaaS option but point to on-prem endpoint. Works.

Od: Jordan @.>
Wysłane: Wednesday, July 31, 2024 7:42:44 PM
Do: controlm/ctm-python-client @.>
DW: Wojciech Zaremba @.>; Author @.>
Temat: Re: [controlm/ctm-python-client] Support ON-PREM API Key credentials (Issue #51)
Is this functionality still planned to be added?
—
Reply to this email directly, view it on GitHubhttps://github.com/controlm/ctm-python-client/issues/51#issuecomment-2261035461, or unsubscribehttps://github.com/notifications/unsubscribe-auth/AKTG66V2YUGCUDPLWTPSHK3ZPEOZJAVCNFSM6AAAAABLY6MBHCVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDENRRGAZTKNBWGE.
You are receiving this because you authored the thread.Message ID: @.***>

authors: TheMadLeprechaun wzaremba

repo: controlm/ctm-python-client


text:
🛑 MPS - TESTPROCESS is down

In 5ed7d8e, MPS - TESTPROCESS ($TESTPROCESS_URL) was down:

HTTP code: 0
Response time: 0 ms

Resolved: MPS - TESTPROCESS is back up in 2563791 after 5 minutes.

repo: conuti-das/status-lfrcs


text:
Document BuildMemory rack param

Release Playbook

[ ] Rebase against master
[ ] Code review
[ ] Merge into master
[ ] Verify changes at http://site-staging.convox.com
[ ] Promote release on site-production in the convox/production Rack

 https://github.com/convox/site/pull/304

authors: idris soulshake

repo: convox/site


text:
Fix docker-compose config on Apple silicon

Description
Adds an explicit platform to relevant python service definitions in both local.yml and production.yml.
Checklist:

[x] I've made sure that tests are updated accordingly (especially if adding or updating a template option)
[x] I've updated the documentation or confirm that my change doesn't require any updates

Rationale
When running from scratch on Apple Silicon, the default django service would continuously poll for a postgres connection. After logging the psycopg2 exception in the container entrypoint, I found that the script was silencing a connection error stating the following:
SCRAM authentication requires libpq version 10 or above

Upon further investigation, I found that there was an inconsistency with some versions of the python image that would install an outdated version of libpq. According to the Docker Desktop documentation:

Not all images are available for ARM64 architecture. You can add --platform linux/amd64 to run an Intel image under emulation.

We can specify this within the docker-compose files by setting the platform property on a service.

Thanks for the fix! 🎉

Hello.
I start play with project on Friday  and continue today. That's why I notice this change.
Issue
When I try to build image:
docker-compose -f local.yml build
I receive errors:
Unsupported config option for services.celerybeat: 'platform'
Unsupported config option for services.celeryworker: 'platform'
Unsupported config option for services.django: 'platform'
Unsupported config option for services.docs: 'platform'
Unsupported config option for services.flower: 'platform'

Reaserch
I thing I found similar issue:
https://github.com/blabla1337/skf-flask/issues/744
Context
os
VERSION="18.04.6 LTS (Bionic Beaver)"
docker version
Client: Docker Engine - Community
 Version:           20.10.12
 API version:       1.41
 Go version:        go1.16.12
 Git commit:        e91ed57
 Built:             Mon Dec 13 11:45:27 2021
 OS/Arch:           linux/amd64
 Context:           default
 Experimental:      true

Server: Docker Engine - Community
 Engine:
  Version:          20.10.12
  API version:      1.41 (minimum version 1.12)
  Go version:       go1.16.12
  Git commit:       459d0df
  Built:            Mon Dec 13 11:43:36 2021
  OS/Arch:          linux/amd64
  Experimental:     false
 containerd:
  Version:          1.4.12
  GitCommit:        7b11cfaabd73bb80907dd23182b9347b4245eb5d
 runc:
  Version:          1.0.2
  GitCommit:        v1.0.2-0-g52b36a2
 docker-init:
  Version:          0.19.0
  GitCommit:        de40ad0

docker-compose version
docker-compose version 1.26.0, build d4451659
docker-py version: 4.2.1
CPython version: 3.7.7
OpenSSL version: OpenSSL 1.1.0l  10 Sep 2019

@foarsitter
Thank for your help. I confirm platform works  with:
docker-compose version 1.29.2, build 5becea4c
docker-py version: 5.0.0
CPython version: 3.7.10
OpenSSL version: OpenSSL 1.1.0l  10 Sep 2019

repo: cookiecutter/cookiecutter-django