An error when creating a large buffer prevents the use of the same name for future buffers

Thank you for this useful driver. It works well with u-dma-buf.
There seems to be some state stuck in the Manager after a buffer creation fails. This prevents future buffer creation with the same name.
For example, if I try to create a number of 64 MB buffers, on my system the fourth one fails (presumably due to lack of available contiguous space - it's a 4 GB embedded system):
# echo "create udmabuf0 0x4000000" > /dev/u-dma-buf-mgr
# echo "create udmabuf1 0x4000000" > /dev/u-dma-buf-mgr
# echo "create udmabuf2 0x4000000" > /dev/u-dma-buf-mgr
# echo "create udmabuf3 0x4000000" > /dev/u-dma-buf-mgr

The first three creations are OK. The fourth one is not. The Linux console displays the following in response to the fourth command:
[  153.542163] u-dma-buf-mgr: create udmabuf3 size=67108864
[  153.547967] cma: cma_alloc: reserved: alloc failed, req-size: 16384 pages, ret: -12
[  153.555662] ------------[ cut here ]------------
[  153.560273] WARNING: CPU: 1 PID: 890 at mm/page_alloc.c:5534 __alloc_pages+0x2c4/0xd30
[  153.568200] Modules linked in: uio_dmem_genirq iptable_nat nf_nat iptable_filter u_dma_buf_mgr(O) u_dma_buf(O) uio_pdrv_genirq
[  153.579609] CPU: 1 PID: 890 Comm: sh Tainted: G           O       6.1.5-xilinx-v2023.1 #1
[  153.587782] Hardware name: ZynqMP ZCU208 RevA (DT)
[  153.592563] pstate: 20000005 (nzCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--)
[  153.599524] pc : __alloc_pages+0x2c4/0xd30
[  153.603620] lr : __dma_direct_alloc_pages.constprop.0+0x148/0x210
[  153.609714] sp : ffff800009c3b690
[  153.613020] x29: ffff800009c3b690 x28:<PHONE_NUMBER>000000 x27: ffff0008035e3030
[  153.620157] x26: ffff0008034b1810 x25: ffff00080183c040 x24: ffff8000080c9bc0
[  153.627292] x23:<PHONE_NUMBER>000cc4 x22:<PHONE_NUMBER>00000e x21:<PHONE_NUMBER>003fff
[  153.634427] x20:<PHONE_NUMBER>ffffff x19:<PHONE_NUMBER>000000 x18:<PHONE_NUMBER>000006
[  153.641562] x17: 72202c7365676170 x16:<PHONE_NUMBER>31203a x15:<PHONE_NUMBER>200720
[  153.648697] x14:<PHONE_NUMBER>200720 x13: ffff8000094b6010 x12:<PHONE_NUMBER>00057c
[  153.655832] x11:<PHONE_NUMBER>0001d4 x10: ffff8000094e2010 x9 : ffff8000094b6010
[  153.662967] x8 : 00000000fffff7ff x7 :<PHONE_NUMBER>000000 x6 : 80000000fffff800
[  153.670102] x5 :<PHONE_NUMBER>005ff4 x4 :<PHONE_NUMBER>000000 x3 :<PHONE_NUMBER>000000
[  153.677237] x2 : ffff000802050fc0 x1 :<PHONE_NUMBER>000001 x0 : ffff800009575000
[  153.684372] Call trace:
[  153.686810]  __alloc_pages+0x2c4/0xd30
[  153.690560]  __dma_direct_alloc_pages.constprop.0+0x148/0x210
[  153.696298]  dma_direct_alloc+0x10c/0x324
[  153.700299]  dma_alloc_attrs+0x80/0xf0
[  153.704048]  udmabuf_object_setup+0x40/0xd0 [u_dma_buf]
[  153.709274]  udmabuf_platform_driver_probe+0x310/0x5d4 [u_dma_buf]
[  153.715455]  platform_probe+0x68/0xc0
[  153.719117]  really_probe+0xbc/0x2dc
[  153.722684]  __driver_probe_device+0x78/0xe0
[  153.726946]  driver_probe_device+0x40/0x120
[  153.731122]  __device_attach_driver+0xb8/0x134
[  153.735566]  bus_for_each_drv+0x7c/0xd4
[  153.739394]  __device_attach+0x9c/0x1a0
[  153.743222]  device_initial_probe+0x14/0x20
[  153.747397]  bus_probe_device+0x98/0xa0
[  153.751225]  device_add+0x374/0x880
[  153.754705]  platform_device_add+0xfc/0x230
[  153.758889]  udmabuf_platform_device_create+0x9c/0x164 [u_dma_buf]
[  153.765071]  u_dma_buf_device_create+0xc0/0xc4 [u_dma_buf]
[  153.770556]  udmabuf_manager_file_write+0x5f4/0x6cc [u_dma_buf_mgr]
[  153.776823]  vfs_write+0xc4/0x3a4
[  153.780129]  ksys_write+0x70/0x104
[  153.783523]  __arm64_sys_write+0x1c/0x2c
[  153.787438]  invoke_syscall+0x54/0x124
[  153.791188]  el0_svc_common.constprop.0+0x44/0xec
[  153.795893]  do_el0_svc+0x2c/0xc0
[  153.799200]  el0_svc+0x2c/0x84
[  153.802246]  el0t_64_sync_handler+0xf4/0x120
[  153.806508]  el0t_64_sync+0x190/0x194
[  153.810163] ---[ end trace<PHONE_NUMBER>000000 ]---
[  153.814804] u-dma-buf udmabuf3: dma_alloc_coherent(size=67108864) failed. return(0)
[  153.822467] u-dma-buf u-dma-buf.5.auto: driver setup failed. return=-12
[  153.829335] u-dma-buf u-dma-buf.5.auto: driver installed.
[  153.834741] u-dma-buf: probe of u-dma-buf.5.auto failed with error -12

There's no sysfs entry, confirming that the udmabuf3 buffer was not created:
# ls /sys/class/u-dma-buf/
udmabuf0  udmabuf1  udmabuf2

However if the name udmabuf3 is used again, even with a smaller buffer, it fails to create:
# echo "create udmabuf3 0x10000" > /dev/u-dma-buf-mgr
-sh: echo: write error: Invalid argument

 [  277.351016] u-dma-buf-mgr: create udmabuf3 size=65536
[  277.356122] u-dma-buf: device name(udmabuf3) or id(-2) is already exists
[  277.362827] u-dma-buf: platform device create entry failed. return=-22
[  277.369354] u-dma-buf-mgr: create error: udmabuf3 result = -22

I'm using u-dma-buf-mgr f1a9a01815bfc625c944dcd5bab5652ea3141a01 on Linux 6.1.5-xilinx-v2023.1 aarch64.

Ok, it turns out that even though the name has not been created in the /sys/class/u-dma-buf directory, it is still possible to delete it with:
# echo "delete udmabuf3" > /dev/u-dma-buf-mgr

This allows the name to be reused.
May I suggest that if the buffer creation fails, the name is dropped (forgotten) by the mgr, rather than retained? That would make it easier for a user-space program to work with u-dma-buf-mgr, because it can use the state of /sys/class/u-dma-buf to know what names are in use. Without this, a program cannot easily discover that a name is unusable as it doesn't appear in sysfs.

Thank you for the issue.

Please give me a little more time.

This is a u-dma-buf issue and has been fixed at https://github.com/ikwzm/udmabuf/issues/110.

Thank you :)


use of non standard properties in the test unit, versus Array.from()

from an es6 point of view, the following line is not correct as _values is a private property
https://github.com/WebReflection/es6-collections/blob/master/test/index.js#L284
So instead of doing
assert(JSON.stringify(o._values) === JSON.stringify([1, 3, 0]));

it should rather use Array.from (es6, so requires a polyfill on some browser), that allows to create a new Array instance from an array-like or iterable object. :
assert(JSON.stringify(Array.from(o.values())) === JSON.stringify([1, 3, 0]));

but then, the problem then is that Array.from does not work with the "fake" operator returned by o.values().
any chance you could look at it ?

iterables requires Symbols, this polyfill has no Symbols polyfill ... right?
The test is just quickly checking results are expected. I know it's quick and dirty, but I think it worked for the last 4 years so this ain't gonna change (I really don't have much time or interest for this project, feel free to use any other better alternative)

no worries, thanks for the feedback !
However if I may, othen than closing these tickets, you could also/rather indicate on the "main page" that you do not maintain this anymore ?

and thanks for the great work you provided all these years too :)

my bad, it is indicated ? or just added it ? :)

me being lazy, eventually I've managed to update both README and deprecate this module on npm.
It was really a quick fix that lasted even too much ;-)
Sorry for any inconvenience

also, I've closed these because I wanted to flag them as won't fix but apparently labels on github don't work anymore ¯_(ツ)_/¯


useRoute returns different result after await call

Environment

Operating System: Linux
Node Version:     v20.10.0
Nuxt Version:     3.9.0
CLI Version:      3.10.0
Nitro Version:    2.8.1
Package Manager<EMAIL_ADDRESS>Builder:          -
User Config:      extends, dir, alias, experimental, runtimeConfig, avModule, app, plugins, modules, yandexMaps, storybook
Runtime Modules:  ~/modules/entrypoint.ts<EMAIL_ADDRESS>~/modules/cache.ts, vue-yandex-maps/nuxt
Build Modules:    -

Reproduction
https://github.com/daniluk4000/nuxt3-async-route-bug

yarn && yarn dev
Open index page
Go to test page
Look to the console / printed result

Expected: same result
Received: second useRoute returns old page
Describe the bug
Calling useRoute after first async function on CSR in useAsyncData leads to different result.
export async function makeAsyncData() {
  //correct, new page
  console.log(useRoute().path);

  //Imagine code below is an inside composable
  await new Promise<void>((resolve) => resolve());

  //returns old page
  console.log(useRoute().path);
}

Additional context
Also message Calling useRoute within middleware may lead to misleading results. Instead, use the (to, from) arguments passed to the middleware to access the new and old routes. can sometimes be seen in console when using this.
Why are you even using it like this?
On real project the error can be reproduced when we call inner composable inside asyncData after await - to set some data, for example
Why don't you think it's intended?
Result should not differ since it's the same composable. It also works perfectly fine on server-side.
Logs
No response

After I looked into source code I think the only way to get this sorted is to modify nuxtApp._route before page actually opens, or make a new composable if this is a breaking change.
I'll try to add this to global middleware and try to test it. On first it seems like it works just fine.
    const app = useNuxtApp();
    app._route = to;

Currently testing this as workaround:
import { defineNuxtRouteMiddleware } from '#imports';

export default defineNuxtRouteMiddleware((to) => {
    const router = useRouter();

    for (const key in to) {
        //@ts-expect-error
        router.currentRoute.value[key] = to[key];
    }
});

Seems to work fine yet.
@danielroe sorry for pinging. What do you think of that issue? In my opinion route from to should be inside useNuxtApp and useRoute should get it's value from Nuxt App and not from injected value since Nuxt can save async context and Vue sadly can't save inject context. setCurrentInstance is not available for us as well (see https://github.com/vuejs/vue/issues/12939, https://github.com/vuejs/core/issues/4611, https://github.com/vuejs/core/pull/5472).

The name of the route (retrieved using useRoute().name or $route.name) remains the same even when navigating to a new route. If you click on a link, the middleware will check the navigation, but the route name will not change. If you click the same link again, the page will reload and the route name will update with the correct name, but the middleware will not fire this time.
Here is Reproduction => https://stackblitz.com/edit/github-wacyhg?file=app.vue

My final workaround solution there.
import { defineNuxtRouteMiddleware } from 'nuxt/app';
import { useStore } from '~/store';
import type { RouteLocationNormalized } from 'vue-router';

export default defineNuxtRouteMiddleware((to) => {
    if (import.meta.client) {
        const store = useStore();
        if (!store.pageRoute) store.pageRoute = {} as RouteLocationNormalized;
        Object.assign(store.pageRoute, to);
    }
});

export const usePageRoute = (): RouteLocationNormalized => {
    return useStore().pageRoute ?? useRoute();
};

Works fine on SSR & CSR. Doesn't affect whole page.


Support maps fields

Describe the feature
Support maps fields
Motivation
I have a model containing a map[string]string field but got an error while trying to insert it. are specific struct tags needed or is it actually unsupported?
This field is supported by clickhouse since I successfully used it using the sql driver directly.
data-type/map
[error] unsupported data type: &map[]
2024-06-03 13:51:20 ERR Failed to **** logs error="unsupported data type: &map[]: Table not set, please set it like: db.Model(&user) or db.Table(\"users\")"
2024-06-03 13:51:20 ERR Error storing record(s) error="unsupported data type: &map[]: Table not set, please set it like: db.Model(&user) or db.Table(\"users\")"
2024-06-03 13:51:20 DBG Closing partition consumer partition=0 topic=sessioncounter
panic: unsupported data type: &map[]: Table not set, please set it like: db.Model(&user) or db.Table("users")

Related Issues
none.

I made it work with this:
	Parameters     map[string]string `gorm:"type:Map(String,String)"`

how do you insert data. i'm having trouble with it though it's able to create the tables...


Not able to use a different from account for upgrades.upgradeProxy

According to the documentation, one should be able to upgrade a Proxy contract to a new logic contract via:
  const newProxy = await upgrades.upgradeProxy(proxy.address, newMain, { deployer })

However, I've tried changing deployer to a different account, and the caller of the transaction is always the same.
I'm using hardhat, not truffle.

Hello @fab-spring
This is an issue I have also encountered. This is because the transaction is sent using hardhat's hre.provider.
Unfortunately, I don't have an easy fix for you right now. I'll put that at the top or our list

Being able to set a new deployer would indeed be great.

There is some confusion about the deployer argument. This is Truffle's notion of a deployer object, the thing that keeps track of deployments during migrations.
For setting a new from argument, the workaround currently is to set it in the network configuration. But this doesn't work if you need different acounts for different deployments.

For setting a new from argument, the workaround currently is to set it in the network configuration.

Can you show an example for this?

Yes, for example in hardhat.config.js:
module.exports = {
  networks: {
    rinkeby: {
      from: '0x....',
    },
  },
};

Yes, sometimes we need different acount for different contract feature, such as during test. But below way is not working now:
const instance = await deployProxy(Box, [42], { from: newAccount });

For setting a new from argument, the workaround currently is to set it in the network configuration. But this doesn't work if you need different acounts for different deployments.

I apparently forgot about this, but the plugin will use the signer that comes attached to the ImplFactory in the Hardhat plugin, and I believe it also uses the same default that was set for the contract class passed in the Truffle plugin.

Closing in favor of https://github.com/OpenZeppelin/openzeppelin-upgrades/issues/85.


Can't run vitest tests in CI

I've run into an issue where laravel-vite-plugin is preventing vitest tests from running in a CI environment (BitBucket Pipelines in my case, but anything that sets the CI variable would do it).

Laravel Vite Plugin Version: 0.7.0 (0.6.1 or later)
Laravel Version: 9.36.4
Node Version: 16.14.0
NPM Version: 8.3.1
Host operating system: Linux
Web Browser & Version: N/A
Running in Sail / Docker: Docker (CI environment)

Description:
I'm working on a pretty standard Jetstream based, Inertia/Vue application which has been set up to use Vite according to the docs in this repository.  I needed some unit tests for my code, and followed https://vuejs.org/guide/scaling-up/testing.html#recipes to add vitest.  That all worked fine locally, including hot reloading, and running npm test run to run tests once.  When I added either npm test or npm test run to my CI server setup, my builds started failing with the following stack trace:
⎯⎯⎯⎯⎯⎯ Unhandled Error ⎯⎯⎯⎯⎯⎯⎯
Error: You should not run the Vite HMR server in CI environments. You should build your assets for production instead.
    at ensureCommandShouldRunInEnvironment (/opt/atlassian/pipelines/agent/build/node_modules/laravel-vite-plugin/dist/index.js:169:15)
    at config (/opt/atlassian/pipelines/agent/build/node_modules/laravel-vite-plugin/dist/index.js:54:13)
    at runConfigHook (file:///opt/atlassian/pipelines/agent/build/node_modules/vite/dist/node/chunks/dep-4da11a5e.js:63556:31)
    at processTicksAndRejections (node:internal/process/task_queues:96:5)
    at async resolveConfig (file:///opt/atlassian/pipelines/agent/build/node_modules/vite/dist/node/chunks/dep-4da11a5e.js:63076:14)
    at async createServer (file:///opt/atlassian/pipelines/agent/build/node_modules/vite/dist/node/chunks/dep-4da11a5e.js:62092:20)
    at async createVitest (file:///opt/atlassian/pipelines/agent/build/node_modules/vitest/dist/chunk-vite-node-externalize.72a4d20b.js:11390:18)
    at async startVitest (file:///opt/atlassian/pipelines/agent/build/node_modules/vitest/dist/chunk-vite-node-externalize.72a4d20b.js:11501:15)
    at async start (file:///opt/atlassian/pipelines/agent/build/node_modules/vitest/dist/cli.js:697:17)

Looking at the code in ensureCommandShouldRunInEnvironment it's looking to see if a production build is being run, or a bypass variable is set before it throws that error.  I think it should also be checking to make sure it's not a vitest test session as well.
Steps To Reproduce:

Take any Laravel application with Vite and laravel-vite-plugin set up.
Install vitest as per https://vuejs.org/guide/scaling-up/testing.html#recipes
Create a simple smoke test in resources/js/__tests__/smoke.test.js:

describe('smoke test', () => {
  it('is true', () => {
    expect(true).toBeTruthy()
  })
})

Execute npm test run to make sure everything works.  This will run the tests once and exit without starting HMR.
You can fake a CI environment and see the error by running CI=true npm test run.

I would expect the output from steps 5 and 5 to be the same, but 6 actually throws the stack track above as it thinks HMR is being invoked in CI.  If the CI env variable is set, and you don't include "run" on the command line vitest will run the tests once and not go into watch mode, so the fix isn't quite as simple as adding "run" to the commands checked at line 156.

You can set the env LARAVEL_BYPASS_ENV_CHECK=1 to bypass the env check.

That's absolutely the case, and does resolve the issue.  But laravel-vite-plugin doesn't require setting an environment variable  for production builds (because it knows HMR isn't involved).  However it does block a vitest CI build because it falsely believes HMR is required.  It's just not consistent.
If the solution is to require setting of the environment variable for vitest can this be documented somewhere?  It took a fair bit of work to discover the environment variable "fix" today, a documentation update that helps the next person would be appreciated.

We’d appreciate a pr to the docs 👍

I think we should just improve the error message to mention it. I don’t think we should document this tbh.

PR to improve the error message: https://github.com/laravel/vite-plugin/pull/165

Sorry for the delayed response.  I think the changes to the error message are a great improvement, and addresses the concern I had.  It was very confusing as a new user of vitest to be getting this error message that seemed unlreated to the issue at hand.  Now that the error messaging prompts with a possible solution, hopefully that'll save the next person from burning a few hours on this issue!
Thanks everyone for getting this done and released into the world!
:+1:

no problem. thank you for raising the issue and the feedback ❤


not an issue but just wondering how you did the renders used in the readme

I rendered them out in Blender and used GIMP to convert the PNGs into a GIF animation.

I rendered them out in Blender and used GIMP to convert the PNGs into a GIF animation.

how did you do animated textures in blender then

I rendered them out in Blender and used GIMP to convert the PNGs into a GIF animation.

how did you render them in blender, when i try it looks offcentered and weird

.


Plugin looking repo in lowercase

In composer.json I write:
"bower-asset/jQuery-contextMenu": "*", - https://github.com/swisnl/jQuery-contextMenu, last v2.1.0
but composer update brings other repo:
Installing bower-asset/jquery-contextmenu (v0.5.2) - https://github.com/nitinuttarwar/jquery-contextmenu

@AstRonin
https://github.com/francoispluchino/composer-asset-plugin/issues/70

And precisely this comment for the solution.

Issue closed, solution works


[DON'T MERGE] 5.0 API with guidance

This is a tracking PR so we don't lose track of branches and can capture process.
/cc @lbud

Per voice with @lbud - this branch now has all the latest changes from develop to help avoid the easy pitfall of OSRM_RELEASE environment setting getting out of sync. The osrm-contract step is expected to fail until the develop branch of osrm-backend has https://github.com/Project-OSRM/osrm-backend/pull/1955 included.

@springmeyer there seems to have accidentally merged develop in the branch instead of rebasing.

https://github.com/Project-OSRM/node-osrm/pull/152 Parts is back in the old PR.


Adding autoflush unit tests

@jtkech

@sebastienros
Okay, i was not able to update your branch directly, so i did the change that make the unit tests failing in #233, but where unit tests are not triggered.


Adds DONE iterator tombstone

This PR introduces the DONE iterator tombstone (via IteratorStepValue.DONE). As part of this, it replaces all uses of IteratorStep and IteratorValue with IteratorStepValue.

@romainmenke This is ready for review.


python310Packages.cocotb: unbreak on Darwin

Description of changes

Disable lto, see issue #19098

Replace -bundle in LDCXXSHARED env

Things done

Built on platform(s)

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

[ ] For non-Linux: Is sandbox = true set in nix.conf? (See Nix manual)
[ ] Tested, as applicable:

NixOS test(s) (look inside nixos/tests)
and/or package tests
or, for functions and "core" functionality, tests in lib/tests or pkgs/test
made sure NixOS tests are linked to the relevant packages

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

[ ] (Package updates) Added a release notes entry if the change is major or breaking
[ ] (Module updates) Added a release notes entry if the change is significant
[ ] (Module addition) Added a release notes entry if adding a new NixOS module
[ ] (Release notes changes) Ran nixos/doc/manual/md-to-db.sh to update generated release notes

[x] Fits CONTRIBUTING.md.

Result of nixpkgs-review pr 178918 run on aarch64-darwin 1

2 packages built:

python310Packages.cocotb
python39Packages.cocotb

Result of nixpkgs-review pr 178918 run on x86_64-darwin 1

2 packages built:

python310Packages.cocotb
python39Packages.cocotb


Entity is marked as invalid when it has one character #202

supporting 1 character entities

@rozele is added to the review. #Closed

closes #202

/azp run

/azp run


ROS Problem

Hi, I notice that the program is installed on the mac platform. How to install it on the mac?

This is a misunderstanding, the fact is that the environment required for this application is Ubuntu, and the MAC interface you see is just an Ubuntu theme.


[Suggestion] detection of the version of operating system

Thanks for this module, very helpful :)

@Mike-Benoit - thanks, this is where I landed; not intention to bloat her right now.  Thanks @alkemist  for the suggestion!  Closing for now.


Question about gptpdf

Hi there! I came across your project while exploring trending python repositories. I'm impressed by what you've built! I was wondering if you could share any insights into the most challenging aspect of developing this project? Thanks in advance!
Best regards,
@nectariferous
Telegram: t.me/nectariferous

You can email to me.


flow : add SocketInfo enhancer in pipeline

run skydive-unit-tests

rerun tests

rerun tests

rerun skydive-scale-tests

Codecov Report

:exclamation: No coverage uploaded for pull request base (master@b08f6f8). Click here to learn what that means.
The diff coverage is 100%.

@@            Coverage Diff            @@
##             master     #485   +/-   ##
=========================================
  Coverage          ?   61.23%
=========================================
  Files             ?      133
  Lines             ?    18388
  Branches          ?        0
=========================================
  Hits              ?    11259
  Misses            ?     6224
  Partials          ?      905

Impacted Files
Coverage Δ

common/common.go
100% <100%> (ø)

agent/agent.go
78.57% <100%> (ø)

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 b08f6f8...9bcde9c. Read the comment docs.

rerun skydive-scale-tests


feature(audioPassthrough): adding in basic audio passthrough functionality

Attempting to allow audio passthrough for defined codecs, per the existing ticket and my own needs. Usage is through --audio-passthrough=CODEC,CODEC2, and --use-audio-passthrough to simply passthrough all audio tracks. One additional feature crept in as well, the ability to preserve the number of audio channels in the source via the option --audio-channels=SOURCE.

Closing this as your fork https://github.com/mshick/mkvtomp4 accomplishes this, and I'm not working on this project anymore.


"Invariant failed" on npm start

We're getting this error when on npm start after a migration command. I don't think there are more stack lines, though. Any idea if this is a misconfig or a bug of some kind?
```Preparing to run: sh start.sh as root
fra [info]+ npx prisma migrate deploy
Datasource "db": SQLite database "sqlite.db" at "file:/data/sqlite.db"
No pending migrations to apply.

npm run start

start
remix-serve build
/myapp/node_modules/tiny-invariant/dist/tiny-invariant.cjs.js:10
throw new Error(prefix);
^
Error: Invariant failed
at invariant (/myapp/node_modules/tiny-invariant/dist/tiny-invariant.cjs.js:10:15)
at Object. (/myapp/build/index.js:443:35)
at Module._compile (node:internal/modules/cjs/loader:1103:14)
at Object.Module._extensions..js (node:internal/modules/cjs/loader:1157:10)
at Module.load (node:internal/modules/cjs/loader:981:32)
at Function.Module._load (node:internal/modules/cjs/loader:822:12)
at Module.require (node:internal/modules/cjs/loader:1005:19)
at require (node:internal/modules/cjs/helpers:102:18)

@mrkurt thanks for escalating this here. Still no success in overcoming this issue

@mrkurt ok, now that's weird. All fixed after I've tried re-building a couple of times. You might want to close this issue for now.

I'm getting this same exact issue with a freshly created app from Indie stack. If any has any suggestions I'm open. I imagine it's not  Fly related. I've tried changing NPM versions between node:16 node:16-bullseye-slim and node:14 and tried upgrading NPM to the latest with in the Docker container since I figured it could be a minor package version resolution issue difference between my Mac and the linux container. The node:14 container had an issue with the npx prisma ... command in start.sh, so it's inconclusive whether or not that would have worked.

I found the issue for anyone else who happens upon this. invariant is used to check for SESSION_SECRET and I did not have a SESSION_SECRET secret defined in Fly. Lo and behold, the README outlines this step just fine.

What to do if I found this issue?

@alifhaider you fill in a new issue with all details possible.


Electrum server not starting after changing password B

Hi there,
bitcoin and lnd node is synced and running.
I decided to change Password B (via raspiblitz menu), but after the reboot the Electrum deamon is not able to start.
I assume because of the password change? Any ideas how to fix that?
Any other services are working like a charm.

Jan 13 13:05:56 raspberrypi electrs[3088]:     JSON-RPC error: transport error: Didn't receive response data in time, timed out.
Jan 13 13:05:56 raspberrypi systemd[1]: electrs.service: Main process exited, code=exited, status=1/FAILURE
Jan 13 13:05:56 raspberrypi systemd[1]: electrs.service: Failed with result 'exit-code'.
Jan 13 13:06:56 raspberrypi systemd[1]: electrs.service: Service RestartSec=1min expired, scheduling restart.
Jan 13 13:06:56 raspberrypi systemd[1]: electrs.service: Scheduled restart job, restart counter is at 1.
Jan 13 13:06:56 raspberrypi systemd[1]: Stopped Electrs.
Jan 13 13:06:56 raspberrypi systemd[1]: Started Electrs.
Jan 13 13:06:56 raspberrypi electrs[11428]: Config { network: Bitcoin, db_path: "/mnt/hdd/app-storage/electrs/db/bitcoin", daemon_dir:
Jan 13 13:06:56 raspberrypi electrs[11428]: [2022-01-13T13:06:56.636Z INFO  electrs::metrics::metrics_impl] serving Prometheus metrics
Jan 13 13:06:56 raspberrypi electrs[11428]: [2022-01-13T13:06:56.687Z INFO  electrs::db] "/mnt/hdd/app-storage/electrs/db/bitcoin": 135
Jan 13 13:07:00 raspberrypi electrs[11428]: [2022-01-13T13:07:00.602Z INFO  electrs::chain] loading 718474 headers, tip=000000000000000
Jan 13 13:07:04 raspberrypi electrs[11428]: [2022-01-13T13:07:04.192Z INFO  electrs::chain] chain updated: tip=000000000000000000026912
Jan 13 13:07:34 raspberrypi electrs[11428]: [2022-01-13T13:07:34.480Z INFO  electrs::db] closing DB at /mnt/hdd/app-storage/electrs/db/
Jan 13 13:07:34 raspberrypi electrs[11428]: Error: daemon not available
Jan 13 13:07:34 raspberrypi electrs[11428]: Caused by:
Jan 13 13:07:34 raspberrypi electrs[11428]:     JSON-RPC error: transport error: Didn't receive response data in time, timed out.
Jan 13 13:07:34 raspberrypi systemd[1]: electrs.service: Main process exited, code=exited, status=1/FAILURE
Jan 13 13:07:34 raspberrypi systemd[1]: electrs.service: Failed with result 'exit-code'.
Jan 13 13:08:34 raspberrypi systemd[1]: electrs.service: Service RestartSec=1min expired, scheduling restart.
Jan 13 13:08:34 raspberrypi systemd[1]: electrs.service: Scheduled restart job, restart counter is at 2.
Jan 13 13:08:34 raspberrypi systemd[1]: Stopped Electrs.
Jan 13 13:08:34 raspberrypi systemd[1]: Started Electrs.
Jan 13 13:08:34 raspberrypi electrs[20319]: Config { network: Bitcoin, db_path: "/mnt/hdd/app-storage/electrs/db/bitcoin", daemon_dir:
Jan 13 13:08:34 raspberrypi electrs[20319]: [2022-01-13T13:08:34.633Z INFO  electrs::metrics::metrics_impl] serving Prometheus metrics
Jan 13 13:08:34 raspberrypi electrs[20319]: [2022-01-13T13:08:34.675Z INFO  electrs::db] "/mnt/hdd/app-storage/electrs/db/bitcoin": 136
Jan 13 13:08:38 raspberrypi electrs[20319]: [2022-01-13T13:08:38.635Z INFO  electrs::chain] loading 718474 headers, tip=000000000000000
Jan 13 13:08:42 raspberrypi electrs[20319]: [2022-01-13T13:08:42.138Z INFO  electrs::chain] chain updated: tip=000000000000000000026912
Jan 13 13:09:12 raspberrypi electrs[20319]: [2022-01-13T13:09:12.434Z INFO  electrs::db] closing DB at /mnt/hdd/app-storage/electrs/db/
Jan 13 13:09:12 raspberrypi electrs[20319]: Error: daemon not available
Jan 13 13:09:12 raspberrypi electrs[20319]: Caused by:
Jan 13 13:09:12 raspberrypi electrs[20319]:     JSON-RPC error: transport error: Didn't receive response data in time, timed out.

Edit:
sudo nano /home/electrs/.electrs/config.toml
and put the right passwordB.
then restart electrs.
Fixed in the dev branch fro the new release.

Wow, that was quick!
That fixed it, thanks.
Continue the great work.


inactive customer  showing issue

Inactive customer shouldn't show in customer  name listing
same issue occur in vendor name listing
1:HERE ABC PVT LTD is inactive

2:But this abc company is showing in customer name listing

issue closed


Enabling branch protection based on the branch patterns.

Prerequisites:

Is the functionality available in the GitHub UI? If so, please provide a link to information about the feature.

Yes, from github UI, I can enable branch protection rules on pattern like *-release which will apply these rules to all the branches with -release as the suffix.

Is the functionality available through the GitHub API? If the functionality is available, please provide links to the
API documentation (https://developer.github.com/v3/) as well as the Octokit documentation (https://octokit.github.io/).

Yes, this is available via github graphQL api ONLY. https://docs.github.com/en/graphql/reference/mutations#createbranchprotectionrule
https://docs.github.com/en/graphql/reference/input-objects#createbranchprotectionruleinput

If the functionality is not yet available in the API, it would be helpful if you
contacted support (https://support.github.com/) or posted in the Community Forum (https://github.community/). Please
include a link to the forum post if you create one or a copy of the response from support.

New Feature
Please describe the desired new functionality:
I want to enable branch protection rules based on a pattern. Today we can achieve this via Github UI and github graphQL apis. Adding this feature will help us to manage branch protection will less rules.

We are hitting the same issue. wildcard patterns are pretty common especially for "release" style branching in which a release would be something like "release/v1.0.0" and so branch protection would be "release/*" and branch protection rules would be critically important to configure and keep aligned.

This would make it a lot easier to manage as without it having multiple branches editing all of these into the ymls is a lot of time waste :(.

Just to point out that it's not only prefix patterns. This pattern is also possible to use: *[0-9].*[0-9x].x

I took a look at what needs to be done to change the Branch Protections code from REST to GraphQL. I see a few pain points

There is no API to get a branch protection. Only to get all branch protections for a repo and iterate through them
The https://docs.github.com/en/graphql/reference/input-objects#createbranchprotectionruleinput object has fields that are ID types and I have to get IDs for Apps, Users, Teams, repository, etc. before calling the API. That makes the API difficult to use. My goal was to modify safe-settings to use GraphQL instead of REST so that it can support wildcards.

Does anyone have ideas on how we can do this more efficiently?

I have implemented graph based branch protection rules internally to fit our usecases internally. I can push my changes to branch over the weekend if that is helpful.

@decyjphr @viks-confluent

I have implemented graph based branch protection rules internally to fit our usecases internally. I can push my changes to branch over the weekend if that is helpful.

has this been added ?

@jefeish Looks like their branch is here https://github.com/github/safe-settings/compare/main-enterprise...viks-confluent:safe-settings:gql-branch-protection

Noting that rulesets are now available https://docs.github.com/en/enterprise-cloud@latest/repositories/configuring-branches-and-merges-in-your-repository/managing-rulesets/managing-rulesets-for-a-repository
Unfortunately they also cannot use wildcards in the REST api, and graphql would need to be used https://docs.github.com/en/enterprise-cloud@latest/rest/repos/rules?apiVersion=2022-11-28#get-rules-for-a-branch

Is there any idea when this will be fixed?

Hey @viks-confluent, seems you have already implemented the fix on your fork. If it is working, would it be ok to make a PR into this main repo? That is if it suits the rules of making PR into this repo that is.


Link to create class command wrong

The link to watch how to create a class is wrong, it leads to:
https://github.com/nuvolabase/orientdb/wiki/Console-Command-Create-Db
Root page:
https://github.com/nuvolabase/orientdb/wiki/Console-Commands

Not relevant anymore, these docs pages no longer exist.
Closing
Thanks
Luigi


Fix sync

resolve #73

It seems that device-api packaging and release are possible after this pr is merged. Or should we solve this problem some other way? @hyunsik @libc-furiosa


Error during login step to datasphere from Power BI

I have added custom connector as detailed in the steps and tried to connect datasphere from Power BI.
After Get Data-> SAP Datasphere - Data(1.50) (Beta), I key in credentials and get message " uh oh Something went amiss". Detailed steps and screenshots added in word document.
Please let me know if I had missed something.
Custom Connector for PBI.docx
Thanks
Guru

update
I turned a setting in Power BI - Files - options - Global/security - Authentication from browser

And after which when I re-try to connect getting a different msg now.

Hi Olaf, can you please help on this matter.

Hi Guru263,
it seems that using your default web browser improved the situation. The following error message indicates, that the connection can't determine the URL to call.
One potential root cause could be an unexpected configuration file. Before you can use the connector, you need adjust the file connections.json - could you please verify the content? Note that the content changed from previous versions, e.g. you need to specify a host name and not the full URL any more.
Best regards, Olaf

Thanks Olaf.
I think I have followed as mentioned in the steps. Only given host name and not URL. Still it not works.

Could you please re-try with the latest version? I did a correction dealing with a similar error message.
If  the issue still persists, please re-open the conversation.
Best regards, Olaf


Create one scaling dedicated IAM role per project (not table)

Currently, project creates scaling role per table, which inconveniently increases resources count of CloudFormation stack, e.g. with larger number of tables it's more likely to reach 200 resources limit which is not shiftable.
As it's scalable targets that states which roles they're going to use, the ScalingRole can safely be configured as one global resource, it's also how it's exampled in AWS CloudFormation documentation

Good point 👍

It would also be useful to allow use of a role defined outside the stack.

I addressed this in plain JS version of this module at https://github.com/medikoo/serverless-plugin-dynamodb-autoscaling (still role name remains fixed at this point)

@sbstjn - Just had a very quick check of the source. Wouldn't just change this line fix it?
(Unless the is a reason to have an option to either have 1 role or multiple roles?)
  public role(): string {
    return clean(this.build(TEXT.ROLE))
  }

to
  public role(): string {
    return TEXT.ROLE
  }

This only works if you update/create the role to have permission for every table. I try to have the role permissions as restricted as possible and to avoid resources: * whenever possible. Therefore a new role is created for every with only permissions for that one specific table.

Basically https://github.com/medikoo/serverless-plugin-dynamodb-autoscaling/blob/master/lib/scaling-role-resource.json#L39 vs. https://github.com/sbstjn/serverless-dynamodb-autoscaling/blob/master/src/aws/role.ts#L62-L66

Yep, I had a play and could see it wasn't going to be so simple unfortunately.
I have little knowledge of CloudFormation. But could you create a single role that has access only to the tables that have been added to the capacities config?
e.g. loop through all the tables, build a list, and give that list of resources to the role.
Thanks for the great work btw, I spent a while trying to get the config working manually, gave up and this just worked in seconds!

serverless-plugin-dynamodb-autoscaling now reuses existing project's IAM role (so no single IAM role resource is created).
Project's IAM role provides lambdas with access to dynamo tables, and range of access is decided by owner of a project. Same range of access is automatically provided to autoscaling resources.

Thank you @medikoo ... just switched to your plugin, looks great & I like your configuration approach. There were so many roles being created across all of my dynamoDb's & stages that I couldn't assign the proper roles to the Cognito identity pool, the list was so long! Your work really helped us, thanks again.

well. I am switching to @medikoo for this very reason.

In my case, I haven't permission to create roles and I just can't use the plugin. Is there any way to workaroung on it by using this plugin ?
Weird: it worked before on same acoount and user :/


Enable virtual keyboard at login

Useful for devices with touchscreens like the Steam Deck. Provides a mode of input at login when a wired keyboard isn't available

Thank you very much for this!


Removed comma's from the ES6 class snippets

Small oversight on the ES6 class snippets where there's still a comma being appended.

Thanks and sorry for the delay!


Snyk scan

What this PR does / why we need it:
Which issue(s) this PR fixes (optional, in fixes #<issue number>(, fixes #<issue_number>, ...) format, will close the issue(s) when PR gets merged):
Fixes #2557
Type of changes
Please delete options that are not relevant.

[x] New feature (non-breaking change which adds functionality)

Release note:

NONE

/lgtm
/approve


Update howto-use-azure-monitor-workbooks.md

Added role info to pre-requisite

@dhanyahk : Thanks for your contribution! The author(s) have been notified to review your proposed change.

@Jak-MS : Thanks for your contribution! The author(s) have been notified to review your proposed change.

@cawrites, would you add a comment to show what action to take on this PR:
Merge the PR: `#sign-off`
Close the PR: `#please-close`
Wait on the PR: `#hold-off`

Thanks.

#sign-off

Thanks!


Add ability to use different API in different channels

Use different API per channel with fallback to global setting (preferred API).

Fixed in 35ee722


FAQ section for KitOps Site

Please design an FAQ section for the home page. This section should display the questions with collapsed answers. Let's start with 10 questions.

More than 1 Accordions can be open at the same time. (So the content doesn't jump)

@Jwilliamsr https://www.figma.com/file/COmS0qgbUJiOe24XguKOXI/KitOps---Landing-page?type=design&node-id=205%3A2866&mode=design&t=v7TxIXqVTUF1XAbl-1

@javisperez UX ticket for FAQ section


debug mode

Changes:

I decided to wrap slog because it's the most promising and flexible way to do logging in go. For now we use global logger, so any otel bridge or custom handler will be applied to lekko logs. Later we can expose a way to set lekko-specific logger.
Added LogInfo and LogError that wrap slog.Info and slog.Error respectfully and have the same API
It has to be in a separate package pkg/debug so it can be used both inside the SDK and in generated code.

Logging events:

log that debug mode is enabled
On initialization, print repo, opts and error (in case of failure)
evaluation
fallback

Examples:
❯ : LEKKO_DEBUG=true go run main.go
2024/07/08 15:06:43 INFO LEKKO_DEBUG=true, running in debug mode
2024/07/08 15:06:43 INFO LEKKO_API_KEY environment variable is not set, in-code fallback will be used
2024/07/08 15:06:49 INFO Lekko fallback result=ROOT

2024/07/08 15:25:03 INFO LEKKO_DEBUG=true, running in debug mode
2024/07/08 15:25:03 INFO Connected to Lekko repository=passichenko-lekko-1/lekko-configs opts=[{APIKey:lekko_3ff48a26-7d69-4868-b019-a46df6fafb87_5663e76f-040e-48c6-bf52-497a4bb824a3}]
2024/07/08 15:25:04 INFO Lekko evaluation name=default/title context=map[env:production] result="value:\"Hello from Lekko!\""
2024/07/08 15:25:04 INFO Lekko evaluation name=default/root-message context=map[] result="value:\"MY ROOT\""

#104  👈
main

This stack of pull requests is managed by Graphite. Learn more about stacking.

Join @passichenko and the rest of your teammates on  Graphite

let's ship for now, but I'm worried that we are requiring go 1.21, 1.20 is still getting security updates

let's ship for now, but I'm worried that we are requiring go 1.21, 1.20 is still getting security updates

Good point! I think we can follow officially supported versions:

Each major Go release is supported until there are two newer major releases.
from https://go.dev/doc/devel/release

So, based on that 1.20 is not officially supported (last minor was in Feb 2024). And 1.24 is coming out soon:

Go 1.23 is expected to be released in August 2024


[Feature] pls support linux

Before Requesting

[X] I found no existing issue matching my feature request
[X] This request is related to Millennium, and not a request for a specific theme/addon

Describe the feature you'd like!
pls add linux support
Anything else?
i would like to use it on linux, steam flatpak

Support is coming? its mentioned in the readme


Fix for home directory not found on Windows

After cross-compiling gof3r for windows/amd64 and running the binary
I got the following error,
home directory not found for current user

The fix for this error is to use the third-party package go-homedir, which
detects "the user's home directory without the use of cgo, so the library
can be used in cross-compilation environments."

Noting this here in so far as it is useful:
At least the commandline gof3r works fine so long as the HOME envar is defined (just did go get from a clean install of the go windows installer. I do my Windows commandline work from inside busybox-w32's ash shell, so that sets up a couple of other environment variables and lightly mangles the extant environment variables (converts \ to /, since / is also a valid path separator on Windows).
However, I was able to run it without it complaining.
I imagine that simply falling back on the value of USERPROFILE instead of HOME when HOME is undefined would be the "smallest code change" way of working with Windows. It might also be possible to just gracefully have gof3r "degrade" by dropping any functionality that needs a HOME dir, because I would imagine that the core feature set should work regardless of whether there is a HOME directory.

Actually, APPDATA is probably the "right-er" variable to use instead of USERPROFILE on Windows, because that's more in line with where the Windows-y way of putting application data is. I've edited my above comment accordingly as well.

@mentalisttraceur Thanks for the info, that's a good idea to gracefully degrade on windows and possibly also support APPDATA as well.
If you're interested in helping make this change, a pull request would be welcome. I don't have an easily-available windows system to test the change on so it might be a while before I can set one up.


Add Node Messages API snippets

Adding new Node snippets for Messages API. The specs are here.
Ticket: https://nexmoinc.atlassian.net/browse/DEVX-1787
Facebook

[ ] Send an Image Message
[ ] Send a Video Message
[ ] Send an Audio Message
[ ] Send a Message Template
[ ] Send a File Message

WhatsApp

[ ] Send a Message Template (MTM)
[ ] Send a Media Message Template*
[ ] Send an Image Message
[ ] Send a Contact
[ ] Send a Video Message
[ ] Send a Link Button*
[ ] Send a Location
[ ] Send an Audio Message
[ ] Send a Quick Reply Button*
[ ] Send a File Message

Unable to test these (*), due to the limitation of the Sandbox verify template
Viber

[ ] Send an Image Message

Should these samples be in the node-code-snippets repo?

Should these samples be in the node-code-snippets repo?

I can't find any repo of that name? And Alex pushed his most recent changes here (https://github.com/Nexmo/nexmo-node-code-snippets/pull/86)

🤦 We're in the nexmo-node-code-snippets repo already! Sorry, I misread this as the NDP repo before

Couple minor items - working with @pardel to see if I can get an account to test out the more advanced stuff.

Thanks @slorello89 . If you are referring to the WhatsApp template examples I think that might be quite hard to do - you would need to set up templates using either your own WhatsApp business account (hard to obtain AFAIK) or get access to the Sandbox templates (which I have found impossible). I've just based these on the curl examples we were given at some point, but have been unable to test them because the only Sandbox template available is the verify one, which I have documented here.


Possible problem PctAxis

Hi!
I am running examples 2 and 3 and they give the same result.
I was expecting to see a normalized (100%) bar stacked bar chart in example 3.
Any hints?
Example 2

Example 3

Example 3 should be equivalent to the 100% vertical stacked example from dimple.  I'll check into it to see that nothing has changed to disrupt this.  It was working fine earlier.  Does the horizontal stacked 100% also not work?

@jpmarindiaz Thanks so much for finding this error that was introduced in b4a5615f00688c9144e97e54bdbc4a5d3752e6d7 .  Somehow I missed it in my tests.  I believe this should now be resolved in 97a4704cb3bd7f83f947a988c43965c223d9c676.  Please let me know if it still does not work for you.
Also, happy you are trying it out.  Would love feedback.

@timelyportfolio Awesome! Thanks for fixing this so quickly.
Great implementation, I will refactor my package to use yours. Cheers

I think we can close this.  Happy to reopen if not complete.


[BUG] ZAP tool --> Primary Device is not correctly saved to zap file

Reproduction steps
I am facing an issue with ZAP tool. Primary Device is not correctly saved to zap file. For example, with PR #35410.
Reproduce steps

cd ~/connectedhomeip
./scripts/tools/zap/run_zaptool.sh examples/chef/devices/rootnode_waterleakdetector_0b067acfa3.zap
Edit EP1 and add Matter Power Source in the device list
Check that Primary Device is still Matter Water Leak Detector
Save save with CTRL+S
Close the ZCL windows
./scripts/tools/zap/run_zaptool.sh examples/chef/devices/rootnode_waterleakdetector_0b067acfa3.zap
Edit EP1 and notice that Primary Device is not Matter Water Leak Detector but Matter Power Source

Bug prevalence
Always
GitHub hash of the SDK that was being used
c6f66811c00f6c13e09938147a7c37310ee7bdc9
Platform
core
Platform Version(s)
N/A
Anything else?
No response

I don't know if it's linked, but you need to activate Power Source Configuration in the endpoint 0 in order to use PowerSource Cluster in other endpoints. Tell me if it helps !

I don't know if it's linked, but you need to activate Power Source Configuration in the endpoint 0 in order to use PowerSource Cluster in other endpoints. Tell me if it helps !

@QuentinCaldeira-eaton I used the contact sensor as an example and EP 0 does not contain this cluster.
This is not related to my issue.

@lboue ZAP tool issues go in https://github.com/project-chip/zap/issues

@lboue ZAP tool issues go in https://github.com/project-chip/zap/issues

https://github.com/project-chip/zap/issues/1420


ToT is red due to a row of infra failures

Lots of tests failed due to infra failure when updating task status:

Example build: https://ci.chromium.org/ui/p/flutter/builders/prod/Linux_android devtools_profile_start_test/2056/overview
AuthenticatedClientError:
  URI: https://flutter-dashboard.appspot.com/api/update-task-status
  HTTP Status: 500
  Response body:
Key not found: Commit:flutter/flutter/master/1c2c9421121f345392162e3dde0a784d0cbdb69b
#0      DatastoreDB.lookupValue (package:gcloud/src/db/db.dart:381:9)
<asynchronous suspension>
#1      UpdateTaskStatus._constructCommitKey (package:cocoon_service/src/request_handlers/update_task_status.dart:115:27)
<asynchronous suspension>
#2      UpdateTaskStatus._getTaskFromNamedParams (package:cocoon_service/src/request_handlers/update_task_status.dart:77:35)
<asynchronous suspension>
#3      UpdateTaskStatus.post (package:cocoon_service/src/request_handlers/update_task_status.dart:58:23)
<asynchronous suspension>
#4      RequestHandler.service.<anonymous closure> (package:cocoon_service/src/request_handling/request_handler.dart:52:22)
<asynchronous suspension>
#5      ApiRequestHandler.service.<anonymous closure> (package:cocoon_service/src/request_handling/api_request_handler.dart:151:7)
<asynchronous suspension>
#6      ApiRequestHandler.service (package:cocoon_service/src/request_handling/api_request_handler.dart:150:5)
<asynchronous suspension>
#7      main.<anonymous closure>.<anonymous closure> (file:///app/bin/server.dart:267:9)
<asynchronous suspension>

/cc @godofredoc @CaseyHillers This is the failure I mentioned yesterday when updating task status.

What is missing to move the test results processing to pub/sub?

@yusuf-goog was starting something in https://github.com/flutter/cocoon/pull/1574. Once a Cocoon handler has been added, we can update the devicelab test runner to push to pub sub instead of making http requests

Sounds like the problem here is that something is creating an entry in the data models that is out of sync with the handlers requests. We need to fix that race condition or avoid depending in the data model entry to exist.

To recap, this is what happened:

flutter/flutter is on the LUCI scheduler, which wasn't impacted by the GitHub outage today
Builds triggered and finished before Cocoon received webhook notifications to create the Task entities
When the luci builds sent /api/update-task-status they reached the 500 error

This is a duplicate of https://github.com/flutter/flutter/issues/78876, which we will mark as being fixed once moved to the cocoon scheduler.

After fixing the recipes the test has been passing consistently.

Any AIs for this being reopened? Since this was caused by the GitHub webhook outage, this will be obsolete once  https://github.com/flutter/flutter/issues/92300 is landed (which moves the scheduler to be dependent on GitHub webhooks)

It was reopened because we were missing the context of what actually fixed it. Thanks for updating!


Update docs for metrics-clojure, metrics-clojure-health

Bumps the version number for metrics-clojure to 2.6.1
Adds a directive to the metrics-clojure-health docs that
explicitly states that this package must be installed in order
to use the health checks

Thanks!

Thank you!


Refactor TE-14.2 with updated scale params

Pull Request Functional Test Report for #2924 / 71860e2455018421ff7a7c46070db14f9ed869f8
Virtual Devices

Device
Test
Test Documentation
Job
Raw Log

Arista cEOS

TE-14.1: gRIBI Scaling
244f9e70
Log

Cisco 8000E

TE-14.1: gRIBI Scaling
35b3ec16
Log

Cisco XRd

TE-14.1: gRIBI Scaling
efe9ad38
Log

Juniper ncPTX

TE-14.1: gRIBI Scaling
8f94d086
Log

Nokia SR Linux

TE-14.1: gRIBI Scaling
19755091
Log

Openconfig Lemming

TE-14.1: gRIBI Scaling
20244fc1
Log

Hardware Devices

Device
Test
Test Documentation
Raw Log

Arista 7808

TE-14.1: gRIBI Scaling

Cisco 8808

TE-14.1: gRIBI Scaling

Juniper PTX10008

TE-14.1: gRIBI Scaling

Nokia 7250 IXR-10e

TE-14.1: gRIBI Scaling

Help

Pull Request Test Coverage Report for Build<PHONE_NUMBER>
Details

17 of 17 (100.0%)  changed or added relevant lines in 1 file are covered.
No unchanged relevant lines lost coverage.
Overall coverage increased (+0.2%) to 55.663%

Totals

Change from base Build<PHONE_NUMBER>:
0.2%

Covered Lines:
1966

Relevant Lines:
3532

💛  - Coveralls


["ffmpegArgs" must not be a sparse array]

Hi dude..,
I have trying this video recorder but i got error message as below.

it means there is an undefined value in the ffmpegArgs array
do a console.log to find out which one is it
טום ים | Tepez
<EMAIL_ADDRESS>| M: +972 52 3200411 | Skype: tom.yam1
www.tepez.co.il
On Wed, Nov 16, 2016 at 2:56 PM, santhosh12992<EMAIL_ADDRESS>wrote:

Hi dude..,
I have trying this video recorder but i got error message as below.
[image: video]
https://cloud.githubusercontent.com/assets/23401123/20348153/23de6200-ac2a-11e6-962b-a739ee51cdfe.png
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/tepez/protractor-video-reporter/issues/10, or mute
the thread
https://github.com/notifications/unsubscribe-auth/ADHUcRv_jpTuIoA6JvCv2ANPeHtsbhMlks5q-v1sgaJpZM4Kz0ob
.

Since, ffmpegArgs  is optional i didnt used those in my config file.
var VideoReporter = require('protractor-video-reporter');
onPrepare: function() {
jasmine.getEnv().addReporter(new VideoReporter({
baseDirectory: path.join(__dirname, 'reports/videos/'),
}));
}
still i am facing the same issue.

You probably don't have the DISPLAY env variable defined

Hi tepez,
I am using windows. I am not able to troubleshoot this err. If required i will share you more details.
Thx.

Sorry, I've never run this on Windows, can't help with that

Thanks for your replay tepez.
Kindly let me know this as been made compatable with windows also.
thanks again.

@tomyam1
hey, getting this even on a mac.
protractor.conf
var ffmpeg = require('ffmpeg');
var VideoReporter = require('protractor-video-reporter');

jasmine.getEnv().addReporter(new VideoReporter({
                baseDirectory: 'videos/'
            }));

both ffmpeg & protractor-video-reporter are installed.
[15:48:27] E/launcher - Error: ValidationError: child "ffmpegArgs" fails because ["ffmpegArgs" must not be a sparse array]
Any ideas?

Also experienced this if I setup my reporter like so:
let videoReporter = new VideoReporter({
  baseDirectory: path.join(__dirname, reportDirs.video),
  //singleVideo: false,
});

I did not include ffmpegArgs.  The error report is misleading (there is no array at all, not even a sparse array).
Thanks!

Hello i'm also experiencing the same issue on OSX i installed the ffmpeg library, i could detect that the process.env.DISPLAY is undefined, please is there anyway to solve the problem?

I was able to have it run on both mac and windows to record protactor tests running.  Sample code can be found here https://stackoverflow.com/a/45803583/4425525
The order of parameters in the array matters, as they are sent to ffmpeg command line in that order.


Osmium only works with Xenon 1.0.0

Due to the Maven build system and the fact that Xenon only published version 1.0.0, it doesn't work with newer or development versions of Xenon. See also https://github.com/NLeSC/Xenon/issues/233.

Created a gradle branch, in which it is easy to add xenon to the lib/ directory while in development. It can be used as a replacement of most functions of Maven, unfortunately except maven site.


Different prompt for Code Millenials

See this prompt for reference:
https://github.com/BudEcosystem/code-millenials/blob/main/utils/prompt.py
I also double-checked asking in their HF repo.
However, this model will always produce space first in all my tests so, I'm not sure if it will work better with \n at the end or not (their eval prompt has \n)
PS. They report very high HumanEval but it didnt performed better than Wizard 33B 1.1, Deepseek coder 33B or Phind in my tests

Thanks for the issues!  I'm doing some travelling this month, will give these a go in early February when I'm back.

@krzysiekpodk  This prompt didn't seem to have much effect on the 34b, but really helped the 13b out to the point where it posted a higher score on senior then it's bigger brother.  Also added the 1b and 3b variants that popped up since the last eval.

This seems to be in accordance to my tests - something is wrong with this model or we don't know how to use it :(


Limit on number of concurrent FCPs

Most people have lives outside of Rust and only have a limited amount of time each week to dedicate to reading RFCs and commenting. Even when someone does have plenty of time, they can still get burnt out focusing on just a few really lively RFCs. When a whole truckload of RFCs are shoved through FCP at the same time, people end up only being able to pay attention to some of them, while other RFCs slip by unnoticed. The current situation is borderline ridiculous:

Rust is not currently lacking in things to implement or stabilize (we have 277 open tracking issues!), so perhaps it might be wise to limit the number of RFCs that can be in FCP at a given time. We should instead strive to have a slow continuous stream of RFCs so there is always something to comment on, but not so much that people are inundated.
And no, having an "impl period" where you don't merge RFCs and instead focus on implementation is not a valid excuse for cramming as many RFCs into FCP in preparation for that "impl period".

I'm not sure whether I agree or not.
At one hand, its the whole point of the RFC process to expose proposals to public scrutiny and to get feedback and feelings about proposals.  I'm not sure as back then I wasn't around, but I could guess there was a similarly high number of RFC mergers ahead of the 1.0 release. This was sort of justified because it was an one-time thing, but I don't think its a good habit to repeat that in the future.
At the other hand, some proposals got a lot of public scrutiny well before the RFC was opened, like the modules proposal. Many were certainly well managed (want to thank @aturon in particular for listening to every single critic!), and very transparent. And about many RFCs there isn't too much to discuss...
Lastly, I have the impression that most RFCs got a ton of comments despite of so many proposals in parallel. I guess many people in the Rust community shifted from writing crates and other stuff to discussing the language (not sure whether that's a good thing or not).

I agree this is a problem. There are multiple proposals at the moment that I care a lot about one way or another, but that I’ve burnt out of following closely.
As discussed in https://internals.rust-lang.org/t/announcing-the-impl-period-sep-18-dec-17/5676/8, I think this is a direct and natural consequence of announcing the "impl period". When you tell people that any proposal needs to "make it" by a certain date (or be subject to several months of delay), they feel a pressure to rush everything in at the same time.
This is exactly the problem that the rapid release schedule is designed to solve, except higher up in the "pipeline" (in design discussions rather than in landing code).
This effect is amplified by the Ergonomics Initiative ramping up around the same time, and producing RFCs that are not only numerous but also high-impact, and so naturally generating many comments. (These are good discussions to have, but the timing isn’t great.)

I highly resonate with the things previous comments are targeting. Coincidentally i read a hole lot more RFC's in the past few weeks than i usually did, just because i have plenty of time currently. So i am pretty much aware of the things that are happening and because of that i am not to worried about the current incident of the RFC/FCP "pileup" because they all look quite healthy for what i can tell. But this is really an exception because i don't know how i would feel about it if i had not so much time and would inevitably loos track of whats happening.
In my opinion this is a problem by itself and not because the current "pileup" turns out to be unhealthy for the development of the current RFCs – but i "could" in the future. Maybe its just me but this has the potential to turn out bad in the future – not that there is evidence currently its just a gut feeling that we can loose plenty of people in this process. And as SimonSapin already mentioned the "release often" and not heading towards a release date (beginning of impl period) felt really good in the past two years.
Not that i am against impl period or the current amount of FCPs its just something that i would like to discuss and having in mind for the future.

My personal take is that we need to make some "reforms" to the RFC system, but capping the number of concurrent RFCs is not where I would start. I see it as a symptom. Many of the problems that @aturon identified in this blog post are still relevant, for one thing. For another, I think there's been an increasing recognition of the fact that the RFC process as we have it now strongly encourages a "waterfall" or "design-first" style of development -- no surprise, since this was a goal when we first started it! (In particular, we were often doing too little design then.)
I would prefer to move towards a more "incremental" path, where we have a pool of ideas we may want to elaborate into final designs, and when we "accept an RFC" that is more like "beginning investigation". The RFC would then develop concurrently with the implementation and with live experimentation, with various "checkins" and "approval points" along the way. I think that would help to keep discussions on point -- and there is no substitute, when trying to evaluate a design, for having a working prototype.
In principle, this is not far off from the current system. That is, it's worth keeping in mind that accepting an RFC is only the first step towards stabilization: at that point, the implementation work begins, and discussion can continue on the tracking issue or elsewhere. Stabilization is the point where Things Get Real. (This is also a reason not to panic if you see a lot of ongoing FCP discussions -- still plenty of time to raise concerns.)
In practice, though, we tend to treat the RFC as far more final (for better and worse). In any case, maybe I'm just advocating for more extensive use of the eRFC-style approach, though I think we can do better than that. Done right, I think we can also use a revised process as a good springboard for helping people figure out how to get involved. Have to think on the details here some more.

@nikomatsakis I agree with what you said, but I think it misses a bigger issue: fatigue. While I would like to follow and contribute to RFCs, I simply can't read dozens of comments a day from a multiple high-velocity FCP-ed RFCs (there are currently 7 RFCs with >140 comments each!), and still have meaningful input to give back. At some point I simply skim the github emails or ignore...

I apologize in advance for the wall of text, but I think any response shorter than this wouldn't do all of the issues justice.
On Fatigue
I'm not fatigued by the number of RFCs. A lot of the RFCs currently in FCP are very small, uncontroversial changes that take a matter of minutes to digest. While I do think there are "too many" in FCP right now, I agree that the number is a symptom and by itself not a serious problem.
What I am personally fatigued by are a handful of specific RFCs. Namely, the paths and visibility RFC, the in-band lifetimes RFC, and the rand crate revision RFC. And it's not because of the length of the discussion. I think it's because the total complexity of all the points that are still "up in the air" is so high that I just can't keep it all in my head without spending more time than I'm personally willing to invest in being a part of those discussions. In particular, I was following the last few modules RFCs pretty closely despite their length, because those discussions were clearly and obviously making progress. I generally had a handle on what the major remaining controversies were, so when each one got closed and replaced by a new proposal, the content of that new proposal was completely unsurprising and obviously the right direction to go in.
For whatever reason, with these three RFCs it feels like the point of controversy is still "every word in the RFC" despite the weeks of discussion so far, and that's just too much disagreement for me to intellectually follow or stay invested in. I feel like to participate in any of those discussions I'd have to reread the entire thread and summarize all of it just to decide which points I want to comment on, because otherwise I'd probably accidentally ignore a half dozen sub-controversies that make my whole comment irrelevant or unpersuasive. For most of the other RFCs "in flight", I can just read the current version of the RFC itself and the last several comments, and I'll immediately be in a position to start writing if I have anything to say (like I did over here) without feeling like I'm about to waste everyone's time including my own.
Note that I keep saying "feels" because I strongly suspect these feelings are not actually true, and those discussions are going somewhere despite my inability to follow them, and if I did make a conscious effort to properly reevaluate those discussions I'd end up with a totally different feeling (it certainly wouldn't be the first time). But I completely lack the desire to do that right now, and I suspect many other people do as well because most of the recent discussion on those three RFCs seem to be dominated by the same handful of users (which is probably fine for the rand crate RFC, but for the other two I find that somewhat worrying).
So I suspect the fatigue problem is not just about having this many RFCs at the same time, but about having this many RFCs and multiple highly controversial RFCs at the same time. If it was just 10-15 "easy" RFCs in the FCP list, I doubt we'd be having this conversation.
So, why do we have this many FCPs?
Similar to the last section, I think the popular suggestion that "it's the impl period's fault" is part of the answer, but not the whole answer.
First, I want to emphasize that I believe the epochs debate is a major contributing factor to all of this, and it's almost certainly a one-off controversy that we aren't likely to have an analogue for next year or the year after. That subject required at least the epochs RFC, the dyn Trait RFC, and the various modules RFCs to be happening at the same time, because those discussions overlap far too much to reach the optimal consensus on any of them in isolation. None of those were easy discussions, but they had to happen, and they had to happen this year, and we do appear to have more or less reached a conclusion on how epochs should work and what the guidelines for epochal changes should be, so I don't think we're going to get anything quite like that again for a long while. For that reason, I think it's unlikely we'll get an FCP pileup quite this bad ever again even if we don't take any corrective action.
But it definitely didn't require this many RFCs to happen in tandem. My suspicion ever since this issue got opened is that a lot of the RFCs currently in FCP simply could and should have happened much earlier in the year. Let me try and substantiate that by breaking the FCP list into groups:
RFCs currently in FCP that probably needed to happen concurrently with the Great Epochs Debate of 2017:

Evolving Rust through Epochs (proposed Jul 3)
Clarify and streamline paths and visibility (proposed Aug 25)
In-band lifetime bindings (proposed Aug 28; the current draft doesn't use epochs, but I believe earlier drafts did)
Add impl Trait type alias and variable declarations (proposed Jul 20; while not directly relevant to epochs, the impl Trait and dyn Trait syntax disussions had a lot of overlap, and rightly so)

"Large" RFCs (>50 comments) currently in FCP that theoretically could have been proposed earlier in the year:

Ok wrapping: Improved support for writing code from an error handling mindset (proposed Aug 14)
Add the () → Result<(), _> coercion rule, for removing Ok(()) everywhere (proposd Aug 21)
Autoreferencing Copy Types (proposed Aug 16)

"Large" RFCs (>50 comments) currently in FCP that were proposed earlier in this year, and theoretically could have been FCP'd earlier:

Const generics (propoed May 11, discussion stopped Jun 28, no further comments until a friendly ping on Aug 8)
Const/static type annotation elision (proposed May 29, discussion stopped Jul 13, remained dormant for a month until schuster's Aug 13 data gathering comment)

"Large" RFCs (>50 comments) currently in FCP that were proposed earlier in the year, but the discussion took long enough that they probably couldn't have been FCP'd earlier:

Add align_offset intrinsic and [T]::align_to function. (proposed Jun 26, discussion stopped on Aug 3, but restarted on Aug 20)
Add external doc attribute to rustc (proposed May 4, discussion stopped Jul 25, FCP proposed Aug 9, FCP entered Aug 15)

"Small" RFCs (<50 comments) currently in FCP that theoretically could have been proposed and/or FCP'd earlier:

Nested groups in imports (proposed Aug 25)
Attributes for tools, 2.0 (proposed Aug 11)
Infer T: 'x outlives requirements on structs (proposed Aug 2)
Implied bounds (proposed Jul 28)
Allow Irrefutable Patterns in if-let and while-let statements (proposed Jul 27)
stable mechanism to specify the behavior of panic! in no-std applications (proposed Jul 20)
Allow crates to specify the version of Rust in which they are written (proposed Aug 9)
Copy/Clone Closures (proposed Aug 28)
compiler-generated Clone impls for Arrays and Tuples (proposed Aug 28)

After looking up all of these dates, the only clear trend I see is that too many RFCs were proposed in August and late July, and the number of FCPs we have right now is an inevitable consequence of that. To some extent this is random chance and not something a process improvement can ever prevent, but a large portion of the "late" proposals were part of the ergonomics initiative and came directly from the lang team, and I don't really recall any "official ergonomics RFCs" getting posted prior to July.
So I believe the reason we ended up in this situation is a combination of the impl period announcement and the ergonomics initiative posting most of its "official" RFCs concurrently. If it wasn't for the impl period, we could naturally correct for this ergonomics RFCs spike by simply putting off some RFCs or some FCPs for a few weeks. But I don't think the impl period by itself explains why so few of these RFCs were proposed earlier in the year. I can't really speculate on why that happened since I'm not part of the lang team, but I think that's something that needs to improve if we want to keep doing impl periods in future years (which I do, see next section).
On eRFCs, "waterfalls" and "limbo"
Recently, there have been a number of comments that our RFC process has become "too waterfall". eRFCs are typically suggested as part of the solution. I definitely agree with this sentiment and for certain specific RFCs I think it's an accurate diagnosis. In particular, this comment by woboats is the biggest truth bomb I've seen in a while.
But, as you may have already guessed, I don't think that's the whole problem. I think waterfall-ness is only a problem with some of our most complex and controversial RFCs. I don't think it's a systematic problem with the RFC process as a whole.
Something I've never really gotten around to expressing before is that, in my opinion, the systematic problem we actually have is that there are too many ideas and features stuck "in limbo". That's an extremely high-level claim that goes way beyond the RFC process, so bear with me for a minute while I unpack what I mean by that.
We have a lot of nightly-only features that are not yet stabilized. A lot of them have no clear path to stabilization. A lot of RFCs have been accepted and never implemented. Some accepted RFCs can't be fully implemented and a lot of nightly-only features can't be stabilized because of other seemingly tangential features (typically what I like to call the "core megafeatures") that have not been RFC'd, implemented and/or stabilized yet, or because of major compiler refactors that can't be easily tracked. There doesn't appear to be any attempt to tag or categorize these unshipped features by what if anything they're blocked on, so in general it's hard to tell why a feature hasn't shipped yet or what you can do to get it closer to shipping. There are also ideas (like CTFE) that, if I understand correctly, can't even be RFC'd until some major compiler refactors (like miri) land and get some time to settle.
This problem is very hard to quantify, and it'll never completely go away unless the language stagnates, although this problem quickly becomes its own kind of stagnation if it grows unchecked. I personally believe we've been designing new features faster than we've been shipping them, and the backlog is getting big enough and interdependent enough that we need to consciously spend less time proposing and designing new features and more time "breaking the logjam" to let us ship more of those features we've already designed, proposed, and mostly-but-not-quite-completely implemented. This is why I find the idea of an impl period exciting, refreshing and something I want to see every year if it goes well; it sounds like a clear acknowledgment of this problem and a serious commitment to both fixing it and keeping it more or less fixed long-term.
This is why the idea that eRFCs are part of the solution to "the RFC process" as a whole, rather than a handful of specific RFCs, strikes me as deeply worrying. Just as there's a limit to how many FCPs a "casual" Rust fan can process, there's a limit to how many experimental nightly-only features we can have going on at once and still expect to get enough quality feedback to keep them all moving towards stabilization. If eRFCs become too commonplace, I fear that's merely going to increase the number of features stuck in limbo.
To be clear, that doesn't mean I think we should stop proposing major new features entirely, or stop using eRFCs (or "experimental acceptance" or whatever we turn it into). Part of the reason the roadmap was such a great idea is that it gave us a clear list of things that we've more or less agreed are important enough to the Rust project that they do justify major new features. But we should avoid major new features that don't strongly contribute to the roadmap, and we absolutely need to avoid the roadmap-motivated features getting stuck in limbo themselves. That's why I think next year we need to focus less on new RFCs and more on pushing the existing RFCs the rest of the way to stabilization.
Conclusion?
So in the grand scheme of things, I think this FCP pileup is not only a symptom of too many RFCs, but that too many RFCs is itself partially a symptom of the real problem that we're designing more features than we're shipping, and we need to shift that focus more than we need to come up with process improvements to avoid future pileups. We should try to improve whatever process led to the ergonomics initiative happening all at once, but I have no way of knowing what that was much less how to solve it.
One small but concrete idea I had while writing this out: I think part of the reason people see RFCs as "the end" of a feature's design and eRFCs feel like a partial solution to that is that RFC FCPs are far more widely advertized than stabilization FCPs. Maybe This Week In Rust should have a section for stabilization FCPs, not just the stabilization PRs that get merged after the decision has already been made?

Just a quick note on this: a big chunk of the RFCs reached the end of FCP. I have merged/closed (as appropriate) all of the non-controversial cases, but plan to leave others open for further discussion.

Triage: @retep998 any plans on taking this to the RFC stage?


Failed to connect to W&B servers after 10 seconds "SIGWINCH handler was not None" error

wandb, version 0.8.33
Python 3.7.4
Linux

Description
While using jupyer notebooks  I always get this message while the cell execution halts.

What I Did
This seems not to be an connection problem since the run entry gets created in the wandb web interface.

Also when I run the same command from ipython terminal I get the following error
In [1]: import wandb

In [2]: config = {
   ...:     "steps": 25600,
   ...:     "batch_size": 128}

In [3]: wandb.init(name='run-42', project='dpg-control', config=config)
<IPython.core.display.HTML object>
SIGWINCH handler was not None: <Handlers.SIG_DFL: 0>
Failed to connect to W&B servers after 10 seconds.                    Letting user process proceed while attempting to reconnect.
Out[3]: W&B Run: https://app.wandb.ai/hadyelsahar/dpg-control/runs/21vzikrq

Hi Hady, I was having some trouble reproducing this issue— do you have any other tips for how I can recreate this behavior?

Hey @hadyelsahar
In the past year we've majorly reworked the CLI and UI for Weights & Biases. We're closing issues older than 6 months. Please comment to reopen.


the js file origin

I want to konw.
mediasoup-client-compile.js  mediasoupclient.min.js   EventEmitter.min.js
Did you write them yourself, or did you get it from somewhere.
thanks

Hi i compiled them using browserify

Ok,thank you.


Enable CORS

Describe the task
CORS is currently not functional in FAM
Acceptance Criteria

[ ] first
[ ] second
[ ] third

Additional context
Created this issue to keep #192 focused

@basilv - minimalist stub of an issue based on our CORS discussion this morning

Paired with Kevin to fix API to add * for origin. Will need better setting for prod.


Support for multiple metadata folders? (Android)

New Issue Checklist

[x] Updated fastlane to the latest version
[x] I have read the Contribution Guidelines

Issue Description
New to fastlane, from the Android side. Poked around and got everything working, but I have a somewhat unique case and I'm curious if it's already a feature, or to make a request.
I have an Android project that outputs 2 APK's with different package names. They both get uploaded to separate play store listings, one is a production listing, and one that lives only in the Beta channel (This enables both apps to be installed simultaneously).
com.myapp.production
com.myapp.staging
When trying to run supply init with a different package name, I get the following error (which is somewhat expected).
Metadata already exists at path './metadata'

Is there a way to have multiple metadata folders for the same project, so that I can upload these APK's to their respective listings? Thanks!

hey @kevinthecity! You'll want to use the metadata_path param.
When you run supply init add --metadata_path "someotherdirectory/metadata for one of the packages
In your Fastfile, if you set up separate lanes for them, you can also pass metadata_path to supply with the appropriate directory for each package.
Let me know it goes! 🚀

Hey Andrea, thanks for your help! Based on your suggestions, I was able to get it working. Here's the scoop for anyone who might stumble across this issue.
(1) If you were trying to use Supply as a tool on it's own, what I wanted was an advanced configuration that really needed Fastlane as well. Go up a level and install all of Fastlane, and set it up for your project.
(2) Fastlane asked me to put in a package name when I configured it, which ended up in my AppFile. I put one in because I didn't know if it actually needed it, but then I deleted it out of my AppFile afterwards. It also asked for the path to my json_key_file file, which I currently have stored locally. That path also lives in your AppFile, leave that alone.
(3) Using the metadata_path argument as @asfalcone suggested, I created 2 separate meta_data folders. I also passed in the package name on init.
supply init -p com.myapp.staging -m fastlane/myapp-staging
supply init -p com.myapp.production -m fastlane/myapp-production

This should create and initialize those folders. Note: That command wants to create the folder as well. If you have pre-emptively created the fastlane/myapp-production folder, it will say meta_data already exists, even though there's nothing in it, and further supply commands will fail because it's empty.
(4) Now, here's where Fastlane is needed. You need to modify / create lanes in your Fastfile for your purposes.
  desc "Deploy Staging build to Alpha Google Play Channel"
  lane :staging do
    gradle(task: "clean assembleStagingRelease")
    supply(
      package_name: "com.myapp.staging",
      track: "alpha",
      metadata_path: "fastlane/myapp-staging/",
      apk: "myapp/build/outputs/apk/myapp-staging-release.apk",
    )
  end

  desc "Deploy Production build to Alpha Google Play Channel"
  lane :production do
    gradle(task: "clean assembleProdRelease")
        supply(
      package_name: "com.myapp.production",
      track: "alpha",
      metadata_path: "fastlane/client-production/",
      apk: "myapp/build/outputs/apk/myapp-prod-release.apk",
    )
  end

Hopefully this works for you as it did for me, and thanks @asfalcone for the help!

Thank you so much for the details @kevinthecity 👍


Charm++ binaries cannot find __executable_start when built with -charm-shared

Original issue: https://charm.cs.illinois.edu/redmine/issues/1893

Currently cmitls uses the symbol __executable_start in order to find the .tbss segment's metadata.
extern void* __executable_start;

static Addr getCodeSegAddr(void) {
  return (Addr) &__executable_start;
}

static Ehdr* getELFHeader(void) {
  return (Ehdr*) getCodeSegAddr();
}

static Phdr* getProgramHeader(void) {
  Ehdr* ehdr = getELFHeader();
  return (Phdr*)((char *)ehdr + ehdr->e_phoff);
}

It has been reported that sometimes __executable_start is not present in the user's executable, preventing launch:
https://lists.cs.illinois.edu/lists/arc/charm/2018-05/msg00001.html

Runtime error:
$ ./
symbol lookup error: /lib_so/libconv-core.so: undefined symbol: __executable_start
ldd output:
$ ldd -r <my_executable>
...
undefined symbol: __executable_start    (/lib_so/libconv-core.so)
Compile and link are fine. This is only an error using g++ on linux, v7, 6, and 5, and not with clang or intel compilers.

In this circumstance, the problem affects any Charm++ program.

Original date: 2018-07-10 19:19:16

I found a way to reproduce this issue.
$ ./build LIBS netlrts-linux-x86_64-smp -j -g3 --build-shared --suffix=shared
$ cd netlrts-linux-x86_64-smp-shared/tests/ampi/privatization
$ make -j OPTS="-charm-shared" control tlsglobals
$ ./cxx-control
./cxx-control: symbol lookup error: /home/evan/charm/netlrts-linux-x86_64-smp-shared/lib_so/libconv-core.so: undefined symbol: __executable_start

Original date: 2018-07-10 20:16:59

Some initial research on the problem of seeing symbols in the main binary from shared objects suggests adding -rdynamic or -Wl,--export-dynamic to the toolchain invocation, but we already do this. Separately, calling dlsym(RTLD_DEFAULT, "__executable_start") returns NULL.

Original date: 2018-07-10 23:53:33

~~https://charm.cs.illinois.edu/gerrit/4338~~ https://github.com/UIUC-PPL/charm/commit/70ad6c9e7dae8852a50152686a5334e90808a80f


feat: add version command

What this PR does / why we need it:
This is a bit more than the commit message would say it is but when I was going through the Makefile I discovered that the build target uses incorrect paths to set the ldflags, i.e.
$(REPO_URL)/v2/internal/metadata.Release=$(TAG)

should be
$(REPO_URL)/v2/internal/manager/metadata.Release=$(TAG)

Hence this PR also contains that change and propagates usage of unified Makefile targets for building in Dockerfile.
Additionally in order to actually test that the binary contains the desired version information that we'd like it to I added version command so that the binary can be run for the sole reason to check the version information and get it in the following form:
{"release":"v2.8.1-23-gde3af6e2","repo":"git@github.com:Kong/kubernetes-ingress-controller.git","commit":"de3af6e2"}

As a cleanup exercises this PR also reformats some of the flags descriptions so that they align properly when binary usage information is printed out.
PR Readiness Checklist:
Complete these before marking the PR as ready to review:

[x] the CHANGELOG.md release notes have been updated to reflect any significant (and particularly user-facing) changes introduced by this PR

@rainest weird 🤔 Works on my machine ™
How about make generate.gateway-api-urls?

some sort of make default that you have and I don't? added a commit that should make it consistent.
13:10:44-0800 esenin $ make generate.gateway-api-urls
+zsh:39> make generate.gateway-api-urls
CRDS_STANDARD_URL=make[1]: Entering directory '/tmp/kubernetes-ingress-controller' github.com/kubernetes-sigs/gateway-api/config/crd/?ref=v0.5.1 make[1]: Leaving directory '/tmp/kubernetes-ingress-controller'\
	CRDS_EXPERIMENTAL_URL=make[1]: Entering directory '/tmp/kubernetes-ingress-controller' github.com/kubernetes-sigs/gateway-api/config/crd/experimental?ref=v0.5.1 make[1]: Leaving directory '/tmp/kubernetes-ingress-controller' \
	RAW_REPO_URL=make[1]: Entering directory '/tmp/kubernetes-ingress-controller' https://raw.githubusercontent.com/kubernetes-sigs/gateway-api/v0.5.1 make[1]: Leaving directory '/tmp/kubernetes-ingress-controller' \
	INPUT=/tmp/kubernetes-ingress-controller/test/internal/cmd/generate-gateway-api-urls/gateway_consts.tmpl \
	OUTPUT=/tmp/kubernetes-ingress-controller/test/consts/zz_generated_gateway.go \
	go generate -tags=generate_gateway_api_urls ./test/internal/cmd/generate-gateway-api-urls
/bin/sh: line 1: Entering: command not found
make: *** [Makefile:561: generate.gateway-api-urls] Error 127

13:10:48-0800 esenin $ make --no-print-directory generate.gateway-api-urls
+zsh:40> make --no-print-directory generate.gateway-api-urls
CRDS_STANDARD_URL=github.com/kubernetes-sigs/gateway-api/config/crd/?ref=v0.5.1\
	CRDS_EXPERIMENTAL_URL=github.com/kubernetes-sigs/gateway-api/config/crd/experimental?ref=v0.5.1 \
	RAW_REPO_URL=https://raw.githubusercontent.com/kubernetes-sigs/gateway-api/v0.5.1 \
	INPUT=/tmp/kubernetes-ingress-controller/test/internal/cmd/generate-gateway-api-urls/gateway_consts.tmpl \
	OUTPUT=/tmp/kubernetes-ingress-controller/test/consts/zz_generated_gateway.go \
	go generate -tags=generate_gateway_api_urls ./test/internal/cmd/generate-gateway-api-url


Lets vs. Just / Task / Taskctl / Tusk

Why should we use Lets instead of just, task, taskctl, or tusk?

Hi, thanks for the question. In general, it always depends on you use cases.
Lets has its specific and design choices that may or may  not be suitable for some users.
I'm gonna try to do a short comparison of all tools with lets from my own perspective, and let you decide which tool is better for your job:
Lets vs just
just has its own uniq syntax and for me it looks and works like make but at the same time provides better defaults, fixes some issues and inconveniences that make has. I think if you want something that looks and feels like better make then you should choose just.
lets has many similarities with just in features, for example env vars, shell redefinision, commands and depencencies between commands. lets uses yaml for configuration so it is less expressive than justfile because it has all limitations that yaml has.
lets vs task
First of all task and lets are very similar. The yaml configs, features, both written in go. task has more features for sure. Some features are very similar. So in case lets vs task in more cases the tools are interchangeable, so my advice is to choose based on features you need.
lets vs taskctl
taskctl is a very interesting project. Besides the fact that the developers are Ukrainians same as me, the project has its interesting ideas. It has yaml configuration as well as lets, and some features are similar to lets, but is has

pipilines which  are in some sense alternative to lets depends directive
taskctl can be embeded in any go app
contexts

Personally, I think lets and taskctl are created to resolve similar problems but design choices are different. It is har for me to say which tool is better because I've never used taskctl.
lets vs tusk
tusk is similar to lets-  it uses yaml, allows to describe and run tasks, has command's options syntax.
I may be wrong but it seems that tusk has a little less features than lets. Also the design choices made in tusk is much different in contrast with task or taskctl
Resume
So basically every tool is a task runner and can be used to solve similar problems.
They are all very similar in syntax (yaml), only just has its own syntax.
The have both similar and different features and it is up to user to decide which features are more useful
As for lets, it has some "uniq" features on some sense:

options that are valid docopt syntax and parsed info environment variables
checksums to verify the task result has changed
remote mixins used to include lets files from remote places (by url)
refs to reuse commands with predefined args and env
depends to build a DAGS of commands
global init and before directives which are executed at all startup and before each command repectively


Traffic from MS Teams conversational bot not reaching bot through Azure Application Gateway

Versions
SDK : 4.7
NodeJS: 10.20
OS: Alpine 3.11.6
Describe the bug
Traffic from MS Teams conversational bot not reaching bot through Azure Application Gateway
To Reproduce
Steps to reproduce the behavior:

Deploy Bot Application in AKS Cluster
Expose the service via Application Gateway
Enable Teams Channel
See Application Gateway for access logs. No traffic should be found

Expected behavior
Traffic from MS Teams should reach application gateway
Screenshots
If applicable, add screenshots to help explain your problem.
Additional context
StackOverflow
Traffic from webchat is logged in AzureDiagnostics table, but traffic from Teams is not reaching the application gateway, meaning no logs of traffic.
Same bot service, when the endpoint is changed to a self hosted bot receives the traffic from MS Teams via Microsoft.BotService
Note: Application gateway is configured with external public DNS, well known CA certificate, multi site listener and WAF disabled
[bug]

@Gousia-MSFT @Wajeed-msft Are you guys able to give any insight or assistance here?
@clearab as well.

@ramgesg - Could you please share the Bot Id and timestamp of the issue?

@Wajeed-msft , please find below the details;
BotID: 5a879d25-5db7-4481-844f-ba3d053e8b85
TimeStamp: 4/27/2020, 3:42:13.546 PM (UTC)
Note: The timestamp is as per application insights, hence there might have been minor latency
Additional information :
Activity ID:<PHONE_NUMBER>547
Activity type:  message
Bot ID: MBFBOT
Channel ID: msteams
Conversation ID: a:1vstDiztKcL0xGIiDfmxdvXOq8YBiaEK9sQOn9BSUR26SFEiSBmtEgBErUmtYaEQ1JnsKD5mL2NvaXWiO3jMp_BjCZYsaQrd2KTDTepiqqKP-Eirna2BrcRZDxLwm7mBb

@ramgesg - We are looking into logs for this.

Could not create SSL/TLS secure channel is a very generic error. Though from the connections settings on the bot endpoint it might be caused by cipher suites. SMBA supports following cipher suites:
TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA
If the bot doesn't have any of those enabled, then it can be a reason for the connectivity issue.
Here is similar post: https://github.com/microsoftgraph/microsoft-graph-comms-samples/issues/36#issuecomment-473683294

@Wajeed-msft, Thank you for the information. In our Azure Application gateway's SSL policy following cipher suites were missing; adding it resolved the issue. Can this be added in the documentation Bot works in Web Chat but not in other channels
Missing cipher suites:
TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA


iOS App

Collection of notes and stuff.

Basic app tutorial
Bluetooth Apple

Bluetooth cannot be used in the Xcode simulator according to this thread. Maybe a way around it is using a Mac target but this thread is old.

Yes, developing on a Mac target helps. However, it is sandboxed by default and one must enable Bluetooth Explicitly.

Now I got bluetooth enabled.

Check this later: https://diamantidis.github.io/2020/02/16/broadcast-and-scan-nearby-devices-using-corebluetooth

Some threads on companion apps:

https://forums.garmin.com/developer/connect-iq/f/discussion/4502/ios-companion-app/30449#30449
https://forums.garmin.com/developer/connect-iq/f/discussion/4502/ios-companion-app/30215#30215

Swift language guide - https://docs.swift.org/swift-book/LanguageGuide/TheBasics.html


pst update update cart func

Summary by Bito
This PR implements a new shopping cart system with member discounts and inventory management features, while modernizing order processing functionality. The update includes database operations for menu management and removes deprecated UI components. The changes streamline the codebase by eliminating outdated personal information and dashboard pages.

Unit tests added: False

Estimated effort to review (1-5, lower is better): 2

AI Code Review is in progress (usually takes <3 minutes unless it's a very large PR).

Changelist by Bito
This pull request implements the following key changes.

Key Change
Files Impacted

Feature Improvement - Shopping Cart and Order Processing Enhancement

- add_cart_s-information.php - Added new shopping cart functionality with order processing and member discount support

- adddish_sql_op.php - Implemented new dish addition functionality to inventory management

- process.php - Added database update functionality for menu items

Other Improvements - User Interface Cleanup

- personal_info.php - Removed outdated personal information page

- user dashboard.php - Removed deprecated user dashboard interface

Code Review Agent Run Status

Limitations and other issues: ❌ Failure - The AI Code Review Agent skipped reviewing this change because it is configured to exclude certain pull requests based on the source/target branch or the pull request status. You can change the settings here, or contact the agent instance creator at<EMAIL_ADDRESS>


Docs Typo - learn/index.md

In the learn preface section, there is a typo.
As seen in the file sst/www/docs/learn/index.md on line 29
The source for the app we are builing is on GitHub for reference

We are transition this repo to https://github.com/sst/v2 and are closing this issue for now. If it is still relevant please reopen it there - sorry for the trouble


Add hostport to use qrcp in local server with reverse proxy

Added hostport option to display really acceptable host:port via reverse proxy.
Fixes #169
If you think that FQDN is that and hostport should be passed to listen instead, please let me known.

Hello @mattn, thanks for this contribution. I didn't have time to review it yet, will hopefully do over the weekend.
Thanks,
C

I'm not too much convinced about the name of the flag.
Considering the following cases, I would rather go with something like --baseurl:

Case
Args
Printed URL

no reverse proxy
-i tun0 -p 8080
http://<IP_ADDRESS>:8080/send/A1s3

no reverse proxy
-i tun0 -p 8080
http://<IP_ADDRESS>:8080/send/A1s3

no reverse proxytls certs
--tls-(cert,key...) -i tun0 -p 8080
https://<IP_ADDRESS>:8080/send/A1s3

reverse proxytarget is localhost:8080
--baseurl http://example.com -i lo -p 8080
http://example.com/send/A1s3

reverse proxytarget is localhost:8080target on custom location
--baseurl http://example.com/qrcp -i lo -p 8080
http://example.com/qrcp/send/A1s3

reverse proxyreverse proxy port 3000target is localhost:8080
--baseurl http://example.com:3000 -i lo -p 8080
http://example.com:3000/send/A1s3

Basically, if baseurl is passed, other parameters that control the printed URL (i.e.: --secure) should be ignored.
What do you think?

I'm not too much convinced about the name of the flag.
Considering the following cases, I would rather go with something like --baseurl:

Case
Args
Printed URL

no reverse proxy
-i tun0 -p 8080
http://<IP_ADDRESS>:8080/send/A1s3

no reverse proxy
-i tun0 -p 8080
http://<IP_ADDRESS>:8080/send/A1s3

no reverse proxytls certs
--tls-(cert,key...) -i tun0 -p 8080
https://<IP_ADDRESS>:8080/send/A1s3

reverse proxytarget is localhost:8080
--baseurl http://example.com -i lo -p 8080
http://example.com/send/A1s3

reverse proxytarget is localhost:8080target on custom location
--baseurl http://example.com/qrcp -i lo -p 8080
http://example.com/qrcp/send/A1s3

reverse proxyreverse proxy port 3000target is localhost:8080
--baseurl http://example.com:3000 -i lo -p 8080
http://example.com:3000/send/A1s3

Basically, if baseurl is passed, other parameters that control the printed URL (i.e.: --secure) should be ignored.
What do you think?

I will close this for now.