add test case for embeded constructors; re #1101

Signed-off-by: Casey Kuhlman<EMAIL_ADDRESS>

Hi,
I'm trying to run this test on burrow 0.25.0+commit.v0.24.3-78-gc44fbec9+2019-05-0
with this script  https://chat.hyperledger.org/channel/burrow?msg=asJMpTJmvWSKGEFXC
and I get this
[afx@proton bin]$ ./dep.sh
20703A7FDA5C5566EC487D05E50FBB15436BD6EF
log_channel=Info message="Using chain" Chain=<IP_ADDRESS>:10997 Signer=
log_channel=Info message="Loading Playbook File."
log_channel=Info message="Loading playbook file" path=/home/afx/go/src/github.com/hyperledger/burrow/bin filename=/home/afx/go/src/github.com/hyperledger/burrow/bin/deploy.yaml
log_channel=Info message="*****Executing Job*****" JobName=defaultAddr Type=Account
log_channel=Info message="Setting Account" account=20703A7FDA5C5566EC487D05E50FBB15436BD6EF
log_channel=Info message="*****Executing Job*****" JobName=deployD Type=Deploy
ERROR: Could not find contract in any of [contract.sol /home/afx/go/src/github.com/hyperledger/burrow/bin/bin/contract.sol /home/afx/go/src/github.com/hyperledger/burrow/bin/bin/contract.sol /home/afx/go/src/github.com/hyperledger/burrow/bin/contract.sol /home/afx/go/src/github.com/hyperledger/burrow/bin/contract.sol]log_channel=Info message="JOBS THAT FAILED" count=1
log_channel=Info message="Playbook result" jobNo=0 file=deploy.yaml error="Could not find contract in any of [contract.sol /home/afx/go/src/github.com/hyperledger/burrow/bin/bin/contract.sol /home/afx/go/src/github.com/hyperledger/burrow/bin/bin/contract.sol /home/afx/go/src/github.com/hyperledger/burrow/bin/contract.sol /home/afx/go/src/github.com/hyperledger/burrow/bin/contract.sol]" time=1.345762ms

borrow.log:
Sourcing config from first of: Config file at 'config.toml' then defaults
Sourcing config from Config file at 'config.toml'
Using validator address: 20703A7FDA5C5566EC487D05E50FBB15436BD6EF
{"caller":"blockchain.go:75","database_key":"426C6F636B636861696E5374617465","height":0,"log_channel":"Info","message":"Trying to load blockchain state from database","run_id":"a4e42bbd-6bd7-11e9-8505-d312d2f1ae3a","scope":"LoadOrNewBlockchain","time":"2019-05-01T06:09:14.060234723Z"}
{"caller":"blockchain.go:92","height":0,"log_channel":"Info","message":"No existing blockchain state found in database, making new blockchain","run_id":"a4e42bbd-6bd7-11e9-8505-d312d2f1ae3a","scope":"LoadOrNewBlockchain","time":"2019-05-01T06:09:14.060665492Z"}
{"caller":"kernel.go:134","height":0,"log_channel":"Info","message":"Creating new application state from genesis","run_id":"a4e42bbd-6bd7-11e9-8505-d312d2f1ae3a","scope":"NewKernel()","time":"2019-05-01T06:09:14.062143963Z"}
{"caller":"kernel.go:145","height":0,"log_channel":"Info","message":"State loading successful","run_id":"a4e42bbd-6bd7-11e9-8505-d312d2f1ae3a","scope":"NewKernel()","time":"2019-05-01T06:09:14.063749216Z"}
{"caller":"app.go:133","component":"ABCI_App","height":0,"log_channel":"Info","message":"Initial validator set matches","node_info":"Burrow_0.25.0_BurrowChain_B6FC16-61FECA_ValidatorID:20703A7FDA5C5566EC487D05E50FBB15436BD6EF","run_id":"a4e42bbd-6bd7-11e9-8505-d312d2f1ae3a","scope":"abci.NewApp","time":"2019-05-01T06:09:14.257245838Z"}
{"announce":"startup","burrow_version":"0.25.0+commit.v0.24.3-78-gc44fbec9+2019-05-01","caller":"processes.go:195","genesis_app_hash":"","genesis_hash":"61FECA34443953643AB4AD32DA0D05BDEC515D3F4EDD7C462957CB7961CD15F6","height":0,"launch_time":"2019-05-01 15:09:14.350281949 +0900 JST m=+0.382867141","log_channel":"Info","message":"Burrow is launching. We have marmot-off.","net_address":"658ea986d1cd15bfd6b00c13b8fbf5c8f2ead17c@<IP_ADDRESS>:26656","node_id":"658ea986d1cd15bfd6b00c13b8fbf5c8f2ead17c","run_id":"a4e42bbd-6bd7-11e9-8505-d312d2f1ae3a","scope":"NewKernel()","tendermint_version":"0.31.5","time":"2019-05-01T06:09:14.350914237Z","validator_address":"20703A7FDA5C5566EC487D05E50FBB15436BD6EF"}
{"caller":"http_server.go:19","component":"RPC_Info","height":0,"listen_address":"<IP_ADDRESS>:26658","log_channel":"Info","message":"Starting RPC HTTP server","run_id":"a4e42bbd-6bd7-11e9-8505-d312d2f1ae3a","scope":"NewKernel()","time":"2019-05-01T06:09:14.351779148Z"}
{"block_time":"2019-05-01 06:09:13 +0000 UTC","caller":"app.go:262","component":"ABCI_App","hash":"8C105979F9B00667B779ECABE8A2D295D9CFDC81F3FD47EE77631D657BD2C2F9","height":1,"last_block_duration":"0s","last_block_hash":"","last_block_time":"2019-05-01 06:09:13 +0000 UTC","log_channel":"Info","message":"Committing block","node_info":"Burrow_0.25.0_BurrowChain_B6FC16-61FECA_ValidatorID:20703A7FDA5C5566EC487D05E50FBB15436BD6EF","run_id":"a4e42bbd-6bd7-11e9-8505-d312d2f1ae3a","scope":"Commit()","tag":"Commit","time":"2019-05-01T06:09:14.795857905Z","txs":0}
{"caller":"execution.go:311","component":"Executor","height":1,"log_channel":"Info","message":"Executor committing","run_id":"a4e42bbd-6bd7-11e9-8505-d312d2f1ae3a","scope":"NewBatchCommitter","time":"2019-05-01T06:09:14.796231923Z"}
{"caller":"app.go:313","component":"ABCI_App","height":1,"log_channel":"Info","message":"Committed block","node_info":"Burrow_0.25.0_BurrowChain_B6FC16-61FECA_ValidatorID:20703A7FDA5C5566EC487D05E50FBB15436BD6EF","run_id":"a4e42bbd-6bd7-11e9-8505-d312d2f1ae3a","scope":"abci.NewApp","time":"2019-05-01T06:09:14.814622556Z"}
{"caller":"kernel.go:332","height":1,"log_channel":"Info","message":"Caught terminated signal so shutting down","run_id":"a4e42bbd-6bd7-11e9-8505-d312d2f1ae3a","scope":"NewKernel()","signal":"terminated","time":"2019-05-01T06:09:15.063320993Z"}
{"caller":"kernel.go:355","height":1,"log_channel":"Info","message":"Attempting graceful shutdown...","run_id":"a4e42bbd-6bd7-11e9-8505-d312d2f1ae3a","scope":"Shutdown","time":"2019-05-01T06:09:15.063434056Z"}
{"caller":"kernel.go:356","height":1,"log_channel":"Info","message":"Shutting down servers","run_id":"a4e42bbd-6bd7-11e9-8505-d312d2f1ae3a","scope":"Shutdown","time":"2019-05-01T06:09:15.063522425Z"}
{"caller":"kernel.go:362","height":1,"log_channel":"Info","message":"Shutting down server","run_id":"a4e42bbd-6bd7-11e9-8505-d312d2f1ae3a","scope":"Shutdown","server_name":"rpcConfig/GRPC","time":"2019-05-01T06:09:15.063568164Z"}
{"caller":"kernel.go:362","height":1,"log_channel":"Info","message":"Shutting down server","run_id":"a4e42bbd-6bd7-11e9-8505-d312d2f1ae3a","scope":"Shutdown","server_name":"rpcConfig/info","time":"2019-05-01T06:09:15.063736924Z"}
{"caller":"kernel.go:362","height":1,"log_channel":"Info","message":"Shutting down server","run_id":"a4e42bbd-6bd7-11e9-8505-d312d2f1ae3a","scope":"Shutdown","server_name":"StartupAnnouncer","time":"2019-05-01T06:09:15.063815656Z"}
{"announce":"shutdown","caller":"processes.go:163","elapsed_run_time":"713.569627ms","height":1,"log_channel":"Info","message":"Burrow is shutting down. Prepare for re-entrancy.","run_id":"a4e42bbd-6bd7-11e9-8505-d312d2f1ae3a","scope":"NewKernel()","shutdown_time":"2019-05-01 15:09:15.063851684 +0900 JST m=+1.096436768","time":"2019-05-01T06:09:15.063854408Z"}
{"caller":"kernel.go:362","height":1,"log_channel":"Info","message":"Shutting down server","run_id":"a4e42bbd-6bd7-11e9-8505-d312d2f1ae3a","scope":"Shutdown","server_name":"Tendermint","time":"2019-05-01T06:09:15.063894951Z"}
{"caller":"processes.go:147","height":1,"log_channel":"Info","message":"Tendermint Node has quit, closing DB connections...","run_id":"a4e42bbd-6bd7-11e9-8505-d312d2f1ae3a","scope":"NewKernel()","time":"2019-05-01T06:09:15.233886022Z"}
{"caller":"kernel.go:362","height":1,"log_channel":"Info","message":"Shutting down server","run_id":"a4e42bbd-6bd7-11e9-8505-d312d2f1ae3a","scope":"Shutdown","server_name":"Database","time":"2019-05-01T06:09:15.235217235Z"}
{"caller":"kernel.go:374","height":1,"log_channel":"Info","message":"Shutdown complete","run_id":"a4e42bbd-6bd7-11e9-8505-d312d2f1ae3a","scope":"Shutdown","time":"2019-05-01T06:09:15.235591906Z"}

What am I doing wrong ?
Thanks

@fastchain you want the contract.sol in the same location as the deploy.yaml

@seanyoung  thanks, I've missed it.  But now there is another one:
afx@proton ~/g/s/g/h/b/bin> ./dep.sh
C6CE6DA06446897CD6F0F7BD781DF56169C09BDF
log_channel=Info message="Using chain" Chain=<IP_ADDRESS>:10997 Signer=
log_channel=Info message="Loading Playbook File."
log_channel=Info message="Loading playbook file" path=/home/afx/go/src/github.com/hyperledger/burrow/bin filename=/home/afx/go/src/github.com/hyperledger/burrow/bin/deploy.yaml
log_channel=Info message="*****Executing Job*****" JobName=defaultAddr Type=Account
log_channel=Info message="Setting Account" account=C6CE6DA06446897CD6F0F7BD781DF56169C09BDF
log_channel=Info message="*****Executing Job*****" JobName=deployD Type=Deploy
log_channel=Info message="Contract path" path=contract.sol
ERROR: exit status 1log_channel=Info message="JOBS THAT FAILED" count=1
log_channel=Info message="Playbook result" jobNo=0 file=deploy.yaml error="exit status 1" time=1.986298134s

borrow.log:
Sourcing config from first of: Config file at 'config.toml' then defaults
Sourcing config from Config file at 'config.toml'
Using validator address: C6CE6DA06446897CD6F0F7BD781DF56169C09BDF
{"caller":"blockchain.go:75","database_key":"426C6F636B636861696E5374617465","height":0,"log_channel":"Info","message":"Trying to load blockchain state from database","run_id":"3e72848e-6beb-11e9-8047-44b00848496f","scope":"LoadOrNewBlockchain","time":"2019-05-01T08:29:32.112181626Z"}
{"caller":"blockchain.go:92","height":0,"log_channel":"Info","message":"No existing blockchain state found in database, making new blockchain","run_id":"3e72848e-6beb-11e9-8047-44b00848496f","scope":"LoadOrNewBlockchain","time":"2019-05-01T08:29:32.112520799Z"}
{"caller":"kernel.go:134","height":0,"log_channel":"Info","message":"Creating new application state from genesis","run_id":"3e72848e-6beb-11e9-8047-44b00848496f","scope":"NewKernel()","time":"2019-05-01T08:29:32.113233283Z"}
{"caller":"kernel.go:145","height":0,"log_channel":"Info","message":"State loading successful","run_id":"3e72848e-6beb-11e9-8047-44b00848496f","scope":"NewKernel()","time":"2019-05-01T08:29:32.114344544Z"}
{"caller":"app.go:133","component":"ABCI_App","height":0,"log_channel":"Info","message":"Initial validator set matches","node_info":"Burrow_0.25.0_BurrowChain_B6FC16-2926F5_ValidatorID:C6CE6DA06446897CD6F0F7BD781DF56169C09BDF","run_id":"3e72848e-6beb-11e9-8047-44b00848496f","scope":"abci.NewApp","time":"2019-05-01T08:29:32.279504984Z"}
{"announce":"startup","burrow_version":"0.25.0+commit.v0.24.3-78-gc44fbec9+2019-05-01","caller":"processes.go:195","genesis_app_hash":"","genesis_hash":"2926F50CA650CCCF542252F3A97128AABE0C074E96976ECFEC80900EEF2CD1BE","height":0,"launch_time":"2019-05-01 17:29:32.359327816 +0900 JST m=+0.324918630","log_channel":"Info","message":"Burrow is launching. We have marmot-off.","net_address":"253e5199588212b2634c99bb5b43513682d0b2df@<IP_ADDRESS>:26656","node_id":"253e5199588212b2634c99bb5b43513682d0b2df","run_id":"3e72848e-6beb-11e9-8047-44b00848496f","scope":"NewKernel()","tendermint_version":"0.31.5","time":"2019-05-01T08:29:32.359826513Z","validator_address":"C6CE6DA06446897CD6F0F7BD781DF56169C09BDF"}
{"caller":"http_server.go:19","component":"RPC_Info","height":0,"listen_address":"<IP_ADDRESS>:26658","log_channel":"Info","message":"Starting RPC HTTP server","run_id":"3e72848e-6beb-11e9-8047-44b00848496f","scope":"NewKernel()","time":"2019-05-01T08:29:32.36042474Z"}
{"block_time":"2019-05-01 08:29:32 +0000 UTC","caller":"app.go:262","component":"ABCI_App","hash":"E4D134EBEAD975E6A14E9D5B51407738EF0BCAD788CFC2D820B67D5CA9DA92EF","height":1,"last_block_duration":"0s","last_block_hash":"","last_block_time":"2019-05-01 08:29:32 +0000 UTC","log_channel":"Info","message":"Committing block","node_info":"Burrow_0.25.0_BurrowChain_B6FC16-2926F5_ValidatorID:C6CE6DA06446897CD6F0F7BD781DF56169C09BDF","run_id":"3e72848e-6beb-11e9-8047-44b00848496f","scope":"Commit()","tag":"Commit","time":"2019-05-01T08:29:32.789478035Z","txs":0}
{"caller":"execution.go:311","component":"Executor","height":1,"log_channel":"Info","message":"Executor committing","run_id":"3e72848e-6beb-11e9-8047-44b00848496f","scope":"NewBatchCommitter","time":"2019-05-01T08:29:32.789985934Z"}
{"caller":"app.go:313","component":"ABCI_App","height":1,"log_channel":"Info","message":"Committed block","node_info":"Burrow_0.25.0_BurrowChain_B6FC16-2926F5_ValidatorID:C6CE6DA06446897CD6F0F7BD781DF56169C09BDF","run_id":"3e72848e-6beb-11e9-8047-44b00848496f","scope":"abci.NewApp","time":"2019-05-01T08:29:32.805525356Z"}
{"block_time":"2019-05-01 08:29:32.733394167 +0000 UTC","caller":"app.go:262","component":"ABCI_App","hash":"C426B432279E7E90A0A4CAB8A9207E592BC73C72FBD4746D5E09DEF6DAD1BEBA","height":2,"last_block_duration":"0s","last_block_hash":"E4D134EBEAD975E6A14E9D5B51407738EF0BCAD788CFC2D820B67D5CA9DA92EF","last_block_time":"2019-05-01 08:29:32 +0000 UTC","log_channel":"Info","message":"Committing block","node_info":"Burrow_0.25.0_BurrowChain_B6FC16-2926F5_ValidatorID:C6CE6DA06446897CD6F0F7BD781DF56169C09BDF","run_id":"3e72848e-6beb-11e9-8047-44b00848496f","scope":"Commit()","tag":"Commit","time":"2019-05-01T08:29:33.179218832Z","txs":0}
{"caller":"execution.go:311","component":"Executor","height":2,"log_channel":"Info","message":"Executor committing","run_id":"3e72848e-6beb-11e9-8047-44b00848496f","scope":"NewBatchCommitter","time":"2019-05-01T08:29:33.179339502Z"}
{"caller":"app.go:313","component":"ABCI_App","height":2,"log_channel":"Info","message":"Committed block","node_info":"Burrow_0.25.0_BurrowChain_B6FC16-2926F5_ValidatorID:C6CE6DA06446897CD6F0F7BD781DF56169C09BDF","run_id":"3e72848e-6beb-11e9-8047-44b00848496f","scope":"abci.NewApp","time":"2019-05-01T08:29:33.190023651Z"}
{"block_time":"2019-05-01 08:29:33.133907513 +0000 UTC","caller":"app.go:262","component":"ABCI_App","hash":"2806673DD1B0BE4CE24655FE722D674D14AE47316E8C93865A4347CBA02801DA","height":3,"last_block_duration":"733.394167ms","last_block_hash":"C426B432279E7E90A0A4CAB8A9207E592BC73C72FBD4746D5E09DEF6DAD1BEBA","last_block_time":"2019-05-01 08:29:32.733394167 +0000 UTC","log_channel":"Info","message":"Committing block","node_info":"Burrow_0.25.0_BurrowChain_B6FC16-2926F5_ValidatorID:C6CE6DA06446897CD6F0F7BD781DF56169C09BDF","run_id":"3e72848e-6beb-11e9-8047-44b00848496f","scope":"Commit()","tag":"Commit","time":"2019-05-01T08:29:33.563950313Z","txs":0}
{"caller":"execution.go:311","component":"Executor","height":3,"log_channel":"Info","message":"Executor committing","run_id":"3e72848e-6beb-11e9-8047-44b00848496f","scope":"NewBatchCommitter","time":"2019-05-01T08:29:33.56405729Z"}
{"caller":"app.go:313","component":"ABCI_App","height":3,"log_channel":"Info","message":"Committed block","node_info":"Burrow_0.25.0_BurrowChain_B6FC16-2926F5_ValidatorID:C6CE6DA06446897CD6F0F7BD781DF56169C09BDF","run_id":"3e72848e-6beb-11e9-8047-44b00848496f","scope":"abci.NewApp","time":"2019-05-01T08:29:33.571310542Z"}
{"block_time":"2019-05-01 08:29:33.523210933 +0000 UTC","caller":"app.go:262","component":"ABCI_App","hash":"11657D90548B443D957ECBE64454EA3E74167402E9F2506AB10CEE67C834BE7A","height":4,"last_block_duration":"400.513346ms","last_block_hash":"2806673DD1B0BE4CE24655FE722D674D14AE47316E8C93865A4347CBA02801DA","last_block_time":"2019-05-01 08:29:33.133907513 +0000 UTC","log_channel":"Info","message":"Committing block","node_info":"Burrow_0.25.0_BurrowChain_B6FC16-2926F5_ValidatorID:C6CE6DA06446897CD6F0F7BD781DF56169C09BDF","run_id":"3e72848e-6beb-11e9-8047-44b00848496f","scope":"Commit()","tag":"Commit","time":"2019-05-01T08:29:33.950586061Z","txs":0}
{"caller":"execution.go:311","component":"Executor","height":4,"log_channel":"Info","message":"Executor committing","run_id":"3e72848e-6beb-11e9-8047-44b00848496f","scope":"NewBatchCommitter","time":"2019-05-01T08:29:33.950695709Z"}
{"caller":"app.go:313","component":"ABCI_App","height":4,"log_channel":"Info","message":"Committed block","node_info":"Burrow_0.25.0_BurrowChain_B6FC16-2926F5_ValidatorID:C6CE6DA06446897CD6F0F7BD781DF56169C09BDF","run_id":"3e72848e-6beb-11e9-8047-44b00848496f","scope":"abci.NewApp","time":"2019-05-01T08:29:33.961223783Z"}
{"block_time":"2019-05-01 08:29:33.905850465 +0000 UTC","caller":"app.go:262","component":"ABCI_App","hash":"EB3FC148AA0A936BFE1077CA3C5234521613A729B50D5B526790E2DDA9EE3B1E","height":5,"last_block_duration":"389.30342ms","last_block_hash":"11657D90548B443D957ECBE64454EA3E74167402E9F2506AB10CEE67C834BE7A","last_block_time":"2019-05-01 08:29:33.523210933 +0000 UTC","log_channel":"Info","message":"Committing block","node_info":"Burrow_0.25.0_BurrowChain_B6FC16-2926F5_ValidatorID:C6CE6DA06446897CD6F0F7BD781DF56169C09BDF","run_id":"3e72848e-6beb-11e9-8047-44b00848496f","scope":"Commit()","tag":"Commit","time":"2019-05-01T08:29:34.326229671Z","txs":0}
{"caller":"execution.go:311","component":"Executor","height":5,"log_channel":"Info","message":"Executor committing","run_id":"3e72848e-6beb-11e9-8047-44b00848496f","scope":"NewBatchCommitter","time":"2019-05-01T08:29:34.32632517Z"}
{"caller":"app.go:313","component":"ABCI_App","height":5,"log_channel":"Info","message":"Committed block","node_info":"Burrow_0.25.0_BurrowChain_B6FC16-2926F5_ValidatorID:C6CE6DA06446897CD6F0F7BD781DF56169C09BDF","run_id":"3e72848e-6beb-11e9-8047-44b00848496f","scope":"abci.NewApp","time":"2019-05-01T08:29:34.335048925Z"}
{"block_time":"2019-05-01 08:29:34.286307218 +0000 UTC","caller":"app.go:262","component":"ABCI_App","hash":"0EADD1382FC4318B7813BC661C24CEB969A92DD63C3901DFBE03A719B85E2E15","height":6,"last_block_duration":"382.639532ms","last_block_hash":"EB3FC148AA0A936BFE1077CA3C5234521613A729B50D5B526790E2DDA9EE3B1E","last_block_time":"2019-05-01 08:29:33.905850465 +0000 UTC","log_channel":"Info","message":"Committing block","node_info":"Burrow_0.25.0_BurrowChain_B6FC16-2926F5_ValidatorID:C6CE6DA06446897CD6F0F7BD781DF56169C09BDF","run_id":"3e72848e-6beb-11e9-8047-44b00848496f","scope":"Commit()","tag":"Commit","time":"2019-05-01T08:29:34.721593993Z","txs":0}
{"caller":"execution.go:311","component":"Executor","height":6,"log_channel":"Info","message":"Executor committing","run_id":"3e72848e-6beb-11e9-8047-44b00848496f","scope":"NewBatchCommitter","time":"2019-05-01T08:29:34.721813067Z"}
{"caller":"app.go:313","component":"ABCI_App","height":6,"log_channel":"Info","message":"Committed block","node_info":"Burrow_0.25.0_BurrowChain_B6FC16-2926F5_ValidatorID:C6CE6DA06446897CD6F0F7BD781DF56169C09BDF","run_id":"3e72848e-6beb-11e9-8047-44b00848496f","scope":"abci.NewApp","time":"2019-05-01T08:29:34.733788259Z"}
{"block_time":"2019-05-01 08:29:34.671991258 +0000 UTC","caller":"app.go:262","component":"ABCI_App","hash":"073841B994790EAD7C4E791904C7A7509E36E42756BD5D15D07B3DF41599CAEC","height":7,"last_block_duration":"380.456753ms","last_block_hash":"0EADD1382FC4318B7813BC661C24CEB969A92DD63C3901DFBE03A719B85E2E15","last_block_time":"2019-05-01 08:29:34.286307218 +0000 UTC","log_channel":"Info","message":"Committing block","node_info":"Burrow_0.25.0_BurrowChain_B6FC16-2926F5_ValidatorID:C6CE6DA06446897CD6F0F7BD781DF56169C09BDF","run_id":"3e72848e-6beb-11e9-8047-44b00848496f","scope":"Commit()","tag":"Commit","time":"2019-05-01T08:29:35.097079287Z","txs":0}
{"caller":"execution.go:311","component":"Executor","height":7,"log_channel":"Info","message":"Executor committing","run_id":"3e72848e-6beb-11e9-8047-44b00848496f","scope":"NewBatchCommitter","time":"2019-05-01T08:29:35.097248283Z"}
{"caller":"app.go:313","component":"ABCI_App","height":7,"log_channel":"Info","message":"Committed block","node_info":"Burrow_0.25.0_BurrowChain_B6FC16-2926F5_ValidatorID:C6CE6DA06446897CD6F0F7BD781DF56169C09BDF","run_id":"3e72848e-6beb-11e9-8047-44b00848496f","scope":"abci.NewApp","time":"2019-05-01T08:29:35.106748876Z"}
{"caller":"kernel.go:332","height":7,"log_channel":"Info","message":"Caught terminated signal so shutting down","run_id":"3e72848e-6beb-11e9-8047-44b00848496f","scope":"NewKernel()","signal":"terminated","time":"2019-05-01T08:29:35.104264995Z"}
{"caller":"kernel.go:355","height":7,"log_channel":"Info","message":"Attempting graceful shutdown...","run_id":"3e72848e-6beb-11e9-8047-44b00848496f","scope":"Shutdown","time":"2019-05-01T08:29:35.110800219Z"}
{"caller":"kernel.go:356","height":7,"log_channel":"Info","message":"Shutting down servers","run_id":"3e72848e-6beb-11e9-8047-44b00848496f","scope":"Shutdown","time":"2019-05-01T08:29:35.110872536Z"}
{"caller":"kernel.go:362","height":7,"log_channel":"Info","message":"Shutting down server","run_id":"3e72848e-6beb-11e9-8047-44b00848496f","scope":"Shutdown","server_name":"rpcConfig/GRPC","time":"2019-05-01T08:29:35.110889136Z"}
{"caller":"kernel.go:362","height":7,"log_channel":"Info","message":"Shutting down server","run_id":"3e72848e-6beb-11e9-8047-44b00848496f","scope":"Shutdown","server_name":"rpcConfig/info","time":"2019-05-01T08:29:35.110953348Z"}
{"caller":"kernel.go:362","height":7,"log_channel":"Info","message":"Shutting down server","run_id":"3e72848e-6beb-11e9-8047-44b00848496f","scope":"Shutdown","server_name":"StartupAnnouncer","time":"2019-05-01T08:29:35.111003576Z"}
{"announce":"shutdown","caller":"processes.go:163","elapsed_run_time":"2.751700433s","height":7,"log_channel":"Info","message":"Burrow is shutting down. Prepare for re-entrancy.","run_id":"3e72848e-6beb-11e9-8047-44b00848496f","scope":"NewKernel()","shutdown_time":"2019-05-01 17:29:35.111028326 +0900 JST m=+3.076619063","time":"2019-05-01T08:29:35.111029829Z"}
{"caller":"kernel.go:362","height":7,"log_channel":"Info","message":"Shutting down server","run_id":"3e72848e-6beb-11e9-8047-44b00848496f","scope":"Shutdown","server_name":"Tendermint","time":"2019-05-01T08:29:35.111066309Z"}
{"caller":"processes.go:147","height":7,"log_channel":"Info","message":"Tendermint Node has quit, closing DB connections...","run_id":"3e72848e-6beb-11e9-8047-44b00848496f","scope":"NewKernel()","time":"2019-05-01T08:29:35.130690497Z"}
{"caller":"kernel.go:362","height":7,"log_channel":"Info","message":"Shutting down server","run_id":"3e72848e-6beb-11e9-8047-44b00848496f","scope":"Shutdown","server_name":"Database","time":"2019-05-01T08:29:35.131007131Z"}
{"caller":"kernel.go:374","height":7,"log_channel":"Info","message":"Shutdown complete","run_id":"3e72848e-6beb-11e9-8047-44b00848496f","scope":"Shutdown","time":"2019-05-01T08:29:35.131152279Z"}

First of all can we use rocketchat please, a closed pull request isn't the most appopriate.
Looks like the error message needs improving but I think solc is not in your path or is not working. What does solc --version say?

First of all can we use rocketchat please, a closed pull request isn't the most appopriate.

Sure!  what is rocket chat?

solc --version say?

0.4.24+commit.e67f0147.Emscripten.clang
So it seems  the problem is here.
Is it possible somehow to use compiled contract (abi,bin) in this setup? (I would like to use online compiler to make reproducible tests)

@fastchain https://chat.hyperledger.org/channel/burrow
You need the native solc binary, not the emscripten version.
If you type make bin/solc in the burrow source directory, it will download it. Then copy bin/solc into your path somewhere. If you have run a build of burrow it should already be there.


Help with this error message.

synack23:~ owner$ java -jar  -Dupnp.config.address=<IP_ADDRESS> -Dharmony.address=<IP_ADDRESS> -Dserver.port=8081<EMAIL_ADDRESS>-Dharmony.pwd=XXX /Users/owner/Desktop/ha-bridge-1.2.3.jar
[main] INFO com.bwssystems.HABridge.HABridge - HA Bridge (v1.2.3) starting setup....
[main] INFO com.bwssystems.harmony.HarmonyServer - setup initiated ....
[main] INFO com.bwssystems.harmony.HarmonyServer - activity changed: [15689828] Watch Roku
[main] WARN com.bwssystems.HABridge.dao.DeviceRepository - Error reading the file: data/device.db - Does not exist or is not readable. continuing...
[main] INFO com.bwssystems.HABridge.devicemanagmeent.DeviceResource - HABridge device management service started....
[main] INFO com.bwssystems.HABridge.hue.HueMulator - Hue emulator service started....
[main] INFO com.bwssystems.HABridge.upnp.UpnpSettingsResource - Hue description service started....
2016-01-05 09:44:04.015:INFO::Thread-5: Logging initialized @3016ms
[Thread-5] INFO spark.webserver.JettySparkServer - == Spark has ignited ...
[Thread-5] INFO spark.webserver.JettySparkServer - >> Listening on <IP_ADDRESS>:8081
2016-01-05 09:44:04.061:INFO:oejs.Server:Thread-5: jetty-9.3.z-SNAPSHOT
2016-01-05 09:44:04.092:INFO:oejs.ServerConnector:Thread-5: Started ServerConnector@970bf99{HTTP/1.1,[http/1.1]}{<IP_ADDRESS>:8081}
2016-01-05 09:44:04.092:INFO:oejs.Server:Thread-5: Started @3093ms
[main] INFO com.bwssystems.HABridge.upnp.UpnpListener - UPNP Discovery Listener starting....
[main] ERROR com.bwssystems.HABridge.upnp.UpnpListener - UpnpListener encountered an error opening sockets. Shutting down
java.net.BindException: Address already in use
at java.net.PlainDatagramSocketImpl.bind0(Native Method)
at java.net.AbstractPlainDatagramSocketImpl.bind(AbstractPlainDatagramSocketImpl.java:94)
at java.net.DatagramSocket.bind(DatagramSocket.java:392)
at java.net.DatagramSocket.(DatagramSocket.java:242)
at java.net.DatagramSocket.(DatagramSocket.java:299)
at java.net.DatagramSocket.(DatagramSocket.java:271)
at com.bwssystems.HABridge.upnp.UpnpListener.startListening(UpnpListener.java:42)
at com.bwssystems.HABridge.HABridge.main(HABridge.java:106)
[main] INFO com.bwssystems.HABridge.upnp.UpnpListener - UPNP Discovery Listener Stopped
As far as I understand I use the address <IP_ADDRESS> (my computers address for the HA Bridge) and <IP_ADDRESS> (the Harmony Hubs address).

You have another program or an instance of the bridge already running. The port 50000 is already used by the other program and you cannot start this one. Look around on how to kill processes and stop it and retry.

Did this get resolved?

Closing this issue. Assuming it's resolved.

Hi.
I'm facing the same error. I'm using echo, raspberry and an HC2(fibaro).
The point is that using the same equipment I'm trying to compare 2 different bridges, with one .jar from armzilla stored on one microSD and another one being from this site stored on a different microSD.
I ran the first one and the config panel was working perfectly, then i came across this .jar and tried setting up the bridge with a different SD, however encountered the error mentioned above. Both the codes being the same
I'm a bit new to this and need some help. TIA!

The code after running shows - UPNP up and running, hence I'm not sure that if there is an error or not.
I was trying - http://localhost:8080/configuration.html and gave me a 404 - version 2.0.3.
however it was the panel for the 1st .jar(armzilla), however I read it just now that the config page is for our .jar's is- http://localhost:8080
can this be the reason?

You need to make sure that the ports are different for each of the bridges for the server port and the upnp response port. Read both instructions and adjust accordingly.


Publishment

Hello! Super cool work! Why you not yet published it to npm? Are you interested in it?

sorry
I published 0.3.0


Add badge in readme.md LFx security scanning

As a developer
I would like to add a badge added to the readme.md
So I catch security flaws early by making them more visible

https://security.lfx.linuxfoundation.org/#/a094100001Cb6HaAAJ/foundation-details

Duplicate with #107


Introduce TransactionSelectionContext to pass data between selectors and plugin

Some tx selector plugins needs more context about the current tx being evaluated, for example the current minGasPrice, or the effective price of the tx and possibly more data in the future, for this we introduce the TransactionSelectionContext to hold that data and pass it across all the selectors and the plugin. Another advantage of this context is to avoid to compute multiple time the same data, in case it is needed in more that one selector.
This PR will be ported to main Besu repo as well.

lgtm, does it make sense to have onTransactionSelected and onTransactionNotSelected also passing the TransactionEvaluationContext instead of PendingTransaction so that plugins can handle the events with the same information that performed the evaluation?

@Gabriel-Trintinalia good suggestion, will pass the context to those method too

Will we be able to get RLP encoded transaction size in the plugin, without it being a part of the new context?

Will we be able to get RLP encoded transaction size in the plugin, without it being a part of the new context?

that information is already provided by Transaction::getSize

I am merging this since all the comments have been resolved and it is needed to unblock the plugin side.
I will open the same PR on main Besu repo so if you still have feedback you can add there.


BINF-481: implement to prod

Awesome work!
However, there do need to be tests for CI/CD to be successful, could you copy some tests in and update them as needed so that make test passes locally?

Done. just realized that i forgot to push.


Bluetooth: Controller: Introduce scan_aux_chain context

Introduces the concept of ll_scan_aux_chain, that allows for keeping track of several advertising chains with a minimal overhead. This replaces using several scan aux sets each with an associated ticker IDs
Only one ticker is used for following chains; This is achieved by having the scheduled chains in a sorted list and restarting the ticker when the first in the list expires
EVENT_DONE_EXTRA_TYPE_SCAN_AUX now includes a pointer to the lll structure to identify which chain to flush (to avoid race conditions)
New implementation is hidden behind a config for now (defaults
to off): BT_CTLR_SCAN_AUX_USE_CHAINS
Other minor changes:

rx_incomplete node pointer was moved to ll_sync_set
data_len removed from ll_sync_set (it uses the chains instead)

This is very welcome improvement to the Controller, hope my recently PRs are not too much of conflict?
Is it possible to keep old design conditionally compiled out for two zephyr releases, i.e. old design remains as default for one release cycle (Zephyr v4.0.99) and new design for the next (Zephyr v4.1.99), and we delete the old one subsequently (Zephyr v4.2.0). We have design listing with the current design and hence, this will allow users to compare the performance improvements, and us to have some time to ensure there is not regression in conformance.

This is very welcome improvement to the Controller, hope my recently PRs are not too much of conflict?

It should be fine I think - I just need to rebase once more.

Is it possible to keep old design conditionally compiled out for two zephyr releases, i.e. old design remains as default for one release cycle (Zephyr v4.0.99) and new design for the next (Zephyr v4.1.99), and we delete the old one subsequently (Zephyr v4.2.0). We have design listing with the current design and hence, this will allow users to compare the performance improvements, and us to have some time to ensure there is no regression in conformance.

Sure that should be doable; Though in that case I think it will be better to basically switch out the entire scan_aux.c implementation - otherwise it will get very messy. I'll get that done.

@jakkra This PR should give higher extended adv report rate with lower RAM requirements, compare to use of BT_CTLR_SCAN_AUX_SET.

New implementation is now hidden behind config BT_CTLR_SCAN_AUX_USE_CHAINS (defaulting to off). We should have at least a few tests enabling it though; I'll look at that next.

Put it ready for review so the clock gets ticking towards merge-able state for v4.0.0.

Comparing support for 9 simultaneous extended advertising reception support:
[181/182] Linking C executable zephyr/zephyr.elf
Memory region         Used Size  Region Size  %age Used
           FLASH:       68736 B         1 MB      6.56%
             RAM:       28812 B       256 KB     10.99%
        IDT_LIST:          0 GB        32 KB      0.00%
Generating files from /home/jack/workspace/zephyrproject/zephyr/build/observer_nrf52840/zephyr/zephyr.elf for board: nrf52840dk
(python) [jack@vich-archlinux-dell-laptop observer_nrf52840]$ git diff
diff --git a/samples/bluetooth/observer/prj_extended.conf b/samples/bluetooth/observer/prj_extended.conf
index cab86c38d14..fed3afef1c7 100644
--- a/samples/bluetooth/observer/prj_extended.conf
+++ b/samples/bluetooth/observer/prj_extended.conf
@@ -14,4 +14,9 @@ CONFIG_BT_CTLR_SCAN_DATA_LEN_MAX=1650

 # Increase Zephyr Bluetooth LE Controller Rx buffer to receive complete chain
 # of PDUs
-CONFIG_BT_CTLR_RX_BUFFERS=9
+CONFIG_BT_CTLR_RX_BUFFERS=18
+
+CONFIG_BT_CTLR_ADVANCED_FEATURES=y
+CONFIG_BT_CTLR_SCAN_AUX_SET=9
+# CONFIG_BT_CTLR_SCAN_AUX_USE_CHAINS=y
+# CONFIG_BT_CTLR_SCAN_AUX_CHAIN_COUNT=9

[181/182] Linking C executable zephyr/zephyr.elf
Memory region         Used Size  Region Size  %age Used
           FLASH:       69412 B         1 MB      6.62%
             RAM:       28364 B       256 KB     10.82%
        IDT_LIST:          0 GB        32 KB      0.00%
Generating files from /home/jack/workspace/zephyrproject/zephyr/build/observer_nrf52840/zephyr/zephyr.elf for board: nrf52840dk
(python) [jack@vich-archlinux-dell-laptop observer_nrf52840]$ git diff
diff --git a/samples/bluetooth/observer/prj_extended.conf b/samples/bluetooth/observer/prj_extended.conf
index cab86c38d14..7dbe1c22f46 100644
--- a/samples/bluetooth/observer/prj_extended.conf
+++ b/samples/bluetooth/observer/prj_extended.conf
@@ -14,4 +14,9 @@ CONFIG_BT_CTLR_SCAN_DATA_LEN_MAX=1650

 # Increase Zephyr Bluetooth LE Controller Rx buffer to receive complete chain
 # of PDUs
-CONFIG_BT_CTLR_RX_BUFFERS=9
+CONFIG_BT_CTLR_RX_BUFFERS=18
+
+CONFIG_BT_CTLR_ADVANCED_FEATURES=y
+# CONFIG_BT_CTLR_SCAN_AUX_SET=9
+CONFIG_BT_CTLR_SCAN_AUX_USE_CHAINS=y
+CONFIG_BT_CTLR_SCAN_AUX_CHAIN_COUNT=9

Summary 1: Flash increase by 676 bytes, RAM reduced by 448 bytes.
Increasing the chain by 1 (to 10):
[181/182] Linking C executable zephyr/zephyr.elf
Memory region         Used Size  Region Size  %age Used
           FLASH:       68736 B         1 MB      6.56%
             RAM:       28940 B       256 KB     11.04%
        IDT_LIST:          0 GB        32 KB      0.00%
Generating files from /home/jack/workspace/zephyrproject/zephyr/build/observer_nrf52840/zephyr/zephyr.elf for board: nrf52840dk
(python) [jack@vich-archlinux-dell-laptop observer_nrf52840]$ git diff
diff --git a/samples/bluetooth/observer/prj_extended.conf b/samples/bluetooth/observer/prj_extended.conf
index cab86c38d14..07439181f19 100644
--- a/samples/bluetooth/observer/prj_extended.conf
+++ b/samples/bluetooth/observer/prj_extended.conf
@@ -14,4 +14,9 @@ CONFIG_BT_CTLR_SCAN_DATA_LEN_MAX=1650

 # Increase Zephyr Bluetooth LE Controller Rx buffer to receive complete chain
 # of PDUs
-CONFIG_BT_CTLR_RX_BUFFERS=9
+CONFIG_BT_CTLR_RX_BUFFERS=18
+
+CONFIG_BT_CTLR_ADVANCED_FEATURES=y
+CONFIG_BT_CTLR_SCAN_AUX_SET=10
+# CONFIG_BT_CTLR_SCAN_AUX_USE_CHAINS=y
+# CONFIG_BT_CTLR_SCAN_AUX_CHAIN_COUNT=10

[181/182] Linking C executable zephyr/zephyr.elf
Memory region         Used Size  Region Size  %age Used
           FLASH:       69412 B         1 MB      6.62%
             RAM:       28428 B       256 KB     10.84%
        IDT_LIST:          0 GB        32 KB      0.00%
Generating files from /home/jack/workspace/zephyrproject/zephyr/build/observer_nrf52840/zephyr/zephyr.elf for board: nrf52840dk
(python) [jack@vich-archlinux-dell-laptop observer_nrf52840]$ git diff
diff --git a/samples/bluetooth/observer/prj_extended.conf b/samples/bluetooth/observer/prj_extended.conf
index cab86c38d14..2c997cf3b77 100644
--- a/samples/bluetooth/observer/prj_extended.conf
+++ b/samples/bluetooth/observer/prj_extended.conf
@@ -14,4 +14,9 @@ CONFIG_BT_CTLR_SCAN_DATA_LEN_MAX=1650

 # Increase Zephyr Bluetooth LE Controller Rx buffer to receive complete chain
 # of PDUs
-CONFIG_BT_CTLR_RX_BUFFERS=9
+CONFIG_BT_CTLR_RX_BUFFERS=18
+
+CONFIG_BT_CTLR_ADVANCED_FEATURES=y
+# CONFIG_BT_CTLR_SCAN_AUX_SET=9
+CONFIG_BT_CTLR_SCAN_AUX_USE_CHAINS=y
+CONFIG_BT_CTLR_SCAN_AUX_CHAIN_COUNT=10

Summary 2: Flash increase 0 bytes, RAM increased by 64 bytes (compared to 128 bytes for BT_SCAN_AUX_SET use).

Summary 2: Flash increase 0 bytes, RAM increased by 64 bytes (compared to 128 bytes for BT_SCAN_AUX_SET use).

Interesting - downstream we only get an increase per count of 44 bytes. Maybe due to padding differences?... I don't see anything that should affect the size configuration wise.

Summary 2: Flash increase 0 bytes, RAM increased by 64 bytes (compared to 128 bytes for BT_SCAN_AUX_SET use).

Interesting - downstream we only get an increase per count of 44 bytes. Maybe due to padding differences?... I don't see anything that should affect the size configuration wise.

I get the visual impression of running the observer that BT_CTLR_SCAN_AUX_SET generate more advertising report compared to BT_CTLR_SCAN_AUX_CHAINS.

One thing we may want to look at is the value of ticks_min_delta in chain_insert_in_sched_list - i.e. the minimum difference in timestamp required for insertion into the scheduling list. I have currently set it to EVENT_OVERHEAD_XTAL_US + EVENT_OVERHEAD_START_US, but that may be too conservative. I am also not really sure what EVENT_OVERHEAD_XTAL_US is supposed to cover.

Ah, use of EVENT_OVERHEAD_XTAL_US  can explain, you do not need this value only EVENT_OVERHEAD_END_US + EVENT_OVERHEAD_START_US should suffice as the CPU overhead between radio end (last bit on air) to radio start (first bit on air), in thoery. I did not consider here the radio ramp up etc... though.

I get the visual impression of running the observer that BT_CTLR_SCAN_AUX_SET generate more advertising report compared to BT_CTLR_SCAN_AUX_CHAINS.
May be @jakkra could help us here on the rate of advertising reports in his ecosystem.

CONFIG_BT_CTLR_RX_BUFFERS=18
CONFIG_BT_CTLR_SCAN_AUX_SET=9

=> ~200 packets/s
CONFIG_BT_CTLR_RX_BUFFERS=18
CONFIG_BT_CTLR_SCAN_AUX_USE_CHAINS=y
CONFIG_BT_CTLR_SCAN_AUX_CHAIN_COUNT=9

=> ~200 packets/s
Note: Did not change the ticks_min_delta suggestion.

@Tronil One minor change request that I requested, then we are good to get this merged :-)

Done :+1:


chore: allow customising window handle safe area padding

Situation: We should be able to use toolbar within sub view and that need not have this padding
Solution: Let end dev customise this padding
Pre-launch Checklist

[ ] I have incremented the package version as appropriate and updated CHANGELOG.md with my changes
[ ] I have added/updated relevant documentation
[ ] I have run "optimize/organize imports" on all changed files
[ ] I have addressed all analyzer warnings as best I could

Still a draft, I will write tests and let you know when it's ready.

@junaid1460 I assume this aims to address #359?

@junaid1460 I assume this aims to address #359?

No, I didn't look at it before this, I just tried this library and found this padding blocking my design goal, it was hardcoded.

I have made couple of more changes. un related to original change, pulldown button isn't customizable right now

@junaid1460 are you still working on this?

@junaid1460 are you still working on this?

Nope, I think we can close it or if you like to take over please do so. I have lost the context.


Do not delaycompress in logrotate

It basically has only downsides when used in combination with copytruncate
See #85

Any chance of this going in?

@CAFxX will be in the upcoming stemcell update.

@CAFxX i was just chatting with @tylerschultz and there is an interesting point about ease of grepping for recently rotated logs. wdyt about that use case?

wdyt about that use case?

I think that zgrep is your friend (as it works on both compressed and uncrompressed files) :)

@CAFxX ya, DK pointed that out right away. LGTM. Let's please merge into develop instead of master.

Great, thanks!

@tylerschultz @cppforlife ready for merge to develop


api.getState is not defined.

function login(){
  const statePath = sysPath.resolve(__dirname, "api-state.json");
  try {
    const stateContent = fs.readFileSync(statePath).toString("utf8");
    const apiContext = JSON.parse(stateContent);
    return skypeHttp.connect({
      state: apiContext,
      verbose: false
    });

  } catch (err) {
    return promptCredentials()
      .then((credentials) => skypeHttp.connect({
        credentials: credentials,
        verbose: false
      }));
  }

}

If I use this then in the resultant api object getState is not defined.

Very sorry that is a feature in master, we should be updating the npm package within the next few weeks once we finalize master.  If you do want to use that feature currently you could use master.

Didn't realize that, my other question was related to this. Is this safe to store this entire state in Keytar?

Yes you can stringify the entire state no problem.  Also you can reply on closed ticket (as the keytar is more related to the other) if desired.   Sorry for the confusion on the API we are doing some rapid development currently and working to finalize the stability of state restore.


Improvements from and for OSCMaaS

This change is

Codecov Report

Merging #600 into master will increase coverage by 0.01%.
The diff coverage is 35.42%.

@@             Coverage Diff              @@
##             master     #600      +/-   ##
============================================
+ Coverage     58.14%   58.15%   +0.01%
- Complexity    18681    18682       +1
============================================
  Files          1932     1932
  Lines         99432    99393      -39
  Branches      10101    10100       -1
============================================
- Hits          57816    57805      -11
+ Misses        38539    38513      -26
+ Partials       3077     3075       -2

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 8be89e4...dab73c5. Read the comment docs.

Reviewed 1 of 1 files at r1, 7 of 7 files at r2.
Review status: all files reviewed at latest revision, 4 unresolved discussions, some commit checks failed.

oscm-accountmgmt-unittests/javasrc-it/org/oscm/accountservice/bean/AccountServiceBeanIT.java, line 2212 at r2 (raw file):

                l_organization = accountMgmtLocal.registerOrganization(
                        l_organization, null, userDetails, null, "DE",
                        marketplaceId, null, OrganizationRoleType.SUPPLIER);

Almost  all tests have now marketplaceId as parameter.  Does this mean the service is only tested for marketplace? Register organization is called also without marketplace context.

oscm-accountmgmt/javasrc/org/oscm/accountservice/bean/AccountServiceBean.java, line 1447 at r2 (raw file):

        VOOrganization result = null;
        Marketplace mp = new Marketplace(marketplaceId);
        mp = (Marketplace) dm.getReferenceByBusinessKey(mp);

How the default tenant fits in this logic? The tenant key of the VOOrganization will be overwritten.

oscm-identitymgmt/javasrc/org/oscm/identityservice/bean/IdentityServiceBean.java, line 2723 at r2 (raw file):

        // TODO DEL
        Tenant tenant = null;
        try {

The logic with the tenant from marketplace is removed here. Creating user is also possible from marketplace portal. Is this tested with different tenants?

oscm-identitymgmt/javasrc/org/oscm/identityservice/bean/IdentityServiceBean.java, line 2730 at r2 (raw file):

ignore
It is better to write a log warning here, instead of ignoring. This is the case is the tenant is not known to the system. It should not happen, but it would be easier for analyzing if problem occurs.

Comments from Reviewable

@MiethanerR please provide the build numbers with which this issue is tested.

Review status: 6 of 11 files reviewed at latest revision, 4 unresolved discussions, some commit checks failed.

oscm-accountmgmt/javasrc/org/oscm/accountservice/bean/AccountServiceBean.java, line 1447 at r2 (raw file):
Previously, StavrevaS (Suzana Stavreva) wrote…
How the default tenant fits in this logic? The tenant key of the VOOrganization will be overwritten.

A marketplace within the default tenant has a null value as tenant reference. The 0 tenant key value in the organization is also an indicator for the default tenant.

oscm-identitymgmt/javasrc/org/oscm/identityservice/bean/IdentityServiceBean.java, line 2723 at r2 (raw file):
Previously, StavrevaS (Suzana Stavreva) wrote…
The logic with the tenant from marketplace is removed here. Creating user is also possible from marketplace portal. Is this tested with different tenants?

Yes, the marketplace logic was not reachable so I removed it.

oscm-identitymgmt/javasrc/org/oscm/identityservice/bean/IdentityServiceBean.java, line 2730 at r2 (raw file):
Previously, StavrevaS (Suzana Stavreva) wrote…

ignore
It is better to write a log warning here, instead of ignoring. This is the case is the tenant is not known to the system. It should not happen, but it would be easier for analyzing if problem occurs.

For the default tenant it is expected that a exception is thrown, so a warning would be only confusing in my opinion.

oscm-accountmgmt-unittests/javasrc-it/org/oscm/accountservice/bean/AccountServiceBeanIT.java, line 2212 at r2 (raw file):
Previously, StavrevaS (Suzana Stavreva) wrote…
Almost  all tests have now marketplaceId as parameter.  Does this mean the service is only tested for marketplace? Register organization is called also without marketplace context.

I reverted these changes.

Comments from Reviewable

Build: OSCMaaS-Delivery #6


Allow using AdapterBase in MethodMock

Reopened rebased #7

I accidentally found new use for @def_method_mock (?), because it worked on older Transactron in other project.
It is nice to use (and more intuitive than in testbench example use) for proving input / collecting output of input-only and output-only Methods in modules, instead of writing call loops, and can be used directly for driving SimpleTestCircuit generated TestbenchIOs.

The example test feels kind of weird. The most troubling thing is the active process: if forgotten, the test will be passing without testing anything.


Issue while building for iOS

This is the error message I get from XCode when I try to build for iOS:
ld: library not found for -lFirebaseCore

Have you tried going into /platforms/ios and running pod install?

@hvaughan3 yeah I tried, same error, this is the full log:
ld: warning: directory not found for option '-L/Users/myuser/Library/Developer/Xcode/DerivedData/<project-name>-eoqjibawueiuqvaaqrftdapxdovs/Build/Products/Debug-iphoneos/FirebaseCore'
ld: warning: directory not found for option '-L/Users/myuser/Library/Developer/Xcode/DerivedData/<project-name>-eoqjibawueiuqvaaqrftdapxdovs/Build/Products/Debug-iphoneos/FirebaseInstanceID'
ld: warning: directory not found for option '-L/Users/myuser/Library/Developer/Xcode/DerivedData/<project-name>-eoqjibawueiuqvaaqrftdapxdovs/Build/Products/Debug-iphoneos/FirebaseMessaging'
ld: warning: directory not found for option '-L/Users/myuser/Library/Developer/Xcode/DerivedData/<project-name>-eoqjibawueiuqvaaqrftdapxdovs/Build/Products/Debug-iphoneos/GoogleUtilities'
ld: warning: directory not found for option '-L/Users/myuser/Library/Developer/Xcode/DerivedData/<project-name>-eoqjibawueiuqvaaqrftdapxdovs/Build/Products/Debug-iphoneos/Protobuf'
ld: warning: directory not found for option '-L/Users/myuser/Library/Developer/Xcode/DerivedData/<project-name>-eoqjibawueiuqvaaqrftdapxdovs/Build/Products/Debug-iphoneos/nanopb'
ld: library not found for -lFirebaseCore
clang: error: linker command failed with exit code 1 (use -v to see invocation)


Disable chip.native.DL logger for now

Temporary disable the logger of chip.native.DL because it now logs a whole list of errors when its trying to bind to internal interfaces on the HA supervisor set-up.
2024-02-27 16:49:00 core-matter-server chip.native.DL[223] CHIP_ERROR MDNS failed to join multicast group on veth3cdf62f for address type IPv4: src/inet/UDPEndPointImplSockets.cpp:777: Inet Error 0x00000110: Address not found
2024-02-27 16:49:00 core-matter-server chip.native.DL[223] CHIP_ERROR MDNS failed to join multicast group on vethe5c361f for address type IPv4: src/inet/UDPEndPointImplSockets.cpp:777: Inet Error 0x00000110: Address not found
2024-02-27 16:49:00 core-matter-server chip.native.DL[223] CHIP_ERROR MDNS failed to join multicast group on vethc8dbc91 for address type IPv4: src/inet/UDPEndPointImplSockets.cpp:777: Inet Error 0x00000110: Address not found
2024-02-27 16:49:00 core-matter-server chip.native.DL[223] CHIP_ERROR MDNS failed to join multicast group on veth624a4d1 for address type IPv4: src/inet/UDPEndPointImplSockets.cpp:777: Inet Error 0x00000110: Address not found
2024-02-27 16:49:00 core-matter-server chip.native.DL[223] CHIP_ERROR MDNS failed to join multicast group on veth1ff504c for address type IPv4: src/inet/UDPEndPointImplSockets.cpp:777: Inet Error 0x00000110: Address not found
2024-02-27 16:49:00 core-matter-server chip.native.DL[223] CHIP_ERROR MDNS failed to join multicast group on vethdcab12e for address type IPv4: src/inet/UDPEndPointImplSockets.cpp:777: Inet Error 0x00000110: Address not found

Ah man, so we really have to supress all error logs from the SDK? :cry:
I'd prefer if we can leave them on.
But if we must disable them by default, then let's use the new SDK argument. Just set this to default:
parser.add_argument(
    "--log-level-sdk",
    type=str,
    default="error",
    help="Matter SDK logging level. Example --log-level-sdk detail, default=error, possible=(none, error, progress, detail, automation)",
)

Ah man, so we really have to supress all error logs from the SDK? 😢

For now I think we should as the logs are meaningless for users and only cause frustration.
At least those first logged messages on HAOS should be hidden for now (and the real fix will be switching to macvlan instead of host networking)

Ah man, so we really have to supress all error logs from the SDK? 😢

For the record: the proposal in this PR is not to suppress all sdk logging but just the "chip.native.DL" part that logs those interface issues. It still logs issues with mdns and case sessions with this change.

We'll close this one in favor of https://github.com/project-chip/connectedhomeip/pull/32356


Feature: support tables

Would it be nice if it was possible to add a table?

This would require a custom segment that could be added into the area. However, it would require modifying how the caret/selection works.

tablo oluşturma özelliği olursa iyi olur.

tablo oluşturma özelliği olursa iyi olur.

Google translates this as: "it would be better if the table creation feature."


fix godoc bug

@funkygao Thanks for the fix! Can you please change the commit to raft: fix godoc about starting a node ?

commit message updated according your spec

LGTM. Thanks!


Filtered Actions

Issue summary
I am having issues with the start and select keys being operational for SNES.
in retro_env.py printing "action" prior to filtering, shows a value for select and start, however if you print action after filtering it will show 0.
action = self.data.filter_action(action)
While most games may not require start or select, the game Super Metroid requires both, (one for selecting weapons, and the other for menuing to turn items on and off).
commenting out the filter_action seems to work, but I'm not sure what the larger implications are.

A better question might be "What does filtering actually do?" I think if I understood the goal up front, it might make sense and I can figure out the more "correct" solution.

The point of filtering actions is to prevent your agent from attempting key presses or combinations that aren't useful in the game, to reduce the search space. For example, in Super Mario Bros, unfiltered actions will include the Start button, which pauses the game, but filtered actions won't.

@endrift is there somewhere you can edit the filtered actions per game? For Super Metroid for example it's important you can access the start screen during the game, so you can turn on and off different upgrades occasionally. (or refill health as that is one operation that is useful).

Yes, they can be overridden per game in the scenario.json, see https://github.com/openai/retro/blob/98fe0d328e1568836a46e5fce55a607f47a0c332/retro/data/stable/KidChameleon-Genesis/scenario.json for an example. Each top-level is a set of buttons that can be pressed independently of each other one, so you can press up, down or none × left, right or none × all of the variants in the bottom row.


hide/show field group based on another field

I'm submitting a ...  (check one with "x")
[ ] bug report => search github for a similar issue or PR before submitting
[ ] feature request
[ ] support request
[X] Query

How can I use hideExpression to hide/show a field group?
I have tried but not working. Can you please share an example.

see https://github.com/ngx-formly/ngx-formly/issues/704#issuecomment-364661614


add unit tests for models/featureFlag

New Test Coverage

We are using fetching and storing by username and not by userId, which will cause problem in future if username changes.

This endpoint is getting deprecated. New endpoint :

https://github.com/Real-Dev-Squad/website-backend/issues/563


Helm 3: --wait flag does not seem to wait.

I ran the following command which you can find in the open-match Makefile. It does not seem that --wait waits for the resources to be ready. This is from a new GKE cluster and can also repro by deleting the chart via helm delete open-match.
The output that comes out is:
helm upgrade open-match --install --wait --debug install/helm/open-match \
        --timeout=10m \
        --namespace=open-match \
        --set openmatch.image.registry=gcr.io/jeremyedwards-gaming-dev \
        --set openmatch.image.tag=0.0.0-dev-67e02bd \
        --set grafana.enabled=true \
        --set jaeger.enabled=true \
        --set prometheus.enabled=true \
        --set redis.enabled=true \
        --set openmatch.monitoring.stackdriver.enabled=true \
        --set openmatch.monitoring.stackdriver.gcpProjectId=jeremyedwards-gaming-dev \
        --debug
history.go:108: [debug] getting history for release open-match
Release "open-match" does not exist. Installing it now.
printer.go:84: [debug] Original chart version: ""
printer.go:84: [debug] CHART PATH: /usr/local/google/home/jeremyedwards/workspace/helm/open-match/install/helm/open-match

client.go:78: [debug] building resources from manifest
client.go:83: [debug] creating 79 resource(s)
wait.go:47: [debug] beginning wait for 79 resources with timeout of 10m0s

Output of helm version:
version.BuildInfo{Version:"v3.0.0-alpha.1", GitCommit:"b9a54967f838723fe241172a6b94d18caf8bcdca", GitTreeState:"clean"}

Output of kubectl version:
Client Version: version.Info{Major:"1", Minor:"14", GitVersion:"v1.14.2", GitCommit:"66049e3b21efe110454d67df4fa62b08ea79a19b", GitTreeState:"clean", BuildDate:"2019-05-16T16:23:09Z", GoVersion:"go1.12.5", Compiler:"gc", Platform:"linux/amd64"}
Server Version: version.Info{Major:"1", Minor:"13+", GitVersion:"v1.13.6-gke.0", GitCommit:"14c9138d6fb5b57473e270fe8a2973300fbd6fd6", GitTreeState:"clean", BuildDate:"2019-05-08T16:22:55Z", GoVersion:"go1.11.5b4", Compiler:"gc", Platform:"linux/amd64"}

Cloud Provider/Platform (AKS, GKE, Minikube etc.):
GKE

As of right now, --wait is partially re-implemented in Helm 3. We've done some refactoring in https://github.com/helm/helm/pull/5735 to clean up the client interface. We're planning on restoring --wait but wanted to take the time to re-think the internal design.
cc @adamreese

@thomastaylor312 is this safe to close now that #5961, #5970 and #5971 have been merged?

Yes. Sorry I missed this issue. @jeremyje please let me know if you see any more problems

Hi
I'm using Helm 3.0.1 and --wait still doesn't seem to work.
I've deployed a broken chart with wrong image reference and helm  marked a release as deployed even despite of the fact that pod failed to start.
Helm version:
version.BuildInfo{Version:"v3.0.1", GitCommit:"7c22ef9ce89e0ebeb7125ba2ebf7d421f3e82ffa", GitTreeState:"clean", GoVersion:"go1.13.4"}
Output of helm install ...:
install.go:148: [debug] Original chart version: ""
install.go:165: [debug] CHART PATH: /home/test/test-service

client.go:87: [debug] creating 6 resource(s)
wait.go:51: [debug] beginning wait for 6 resources with timeout of 5m0s
NAME: testing
LAST DEPLOYED: Mon Dec 16 13:06:04 2019
NAMESPACE: test
STATUS: deployed
REVISION: 1
TEST SUITE: None
USER-SUPPLIED VALUES:

@shreben Can you share your chart? Generally when that happens it is due to only having 1 replica in your Deployment. However, I have also see it happen where a pod is "flapping" (it goes ready for a bit and then fails). If there is a problem here, we should probably isolate what it doesn't wait for and open a new issue

Hi
I'm using a custom chart developed by myself from scratch.
Here is my resultant deployment.yaml after templating:
apiVersion: apps/v1
kind: Deployment
metadata:
  name: dev-base
  namespace: test
  labels:
    app.kubernetes.io/name: base
    app.kubernetes.io/instance: dev-base
    app.kubernetes.io/managed-by: helm
    app.kubernetes.io/part-of:
    helm.sh/chart: base-1.2.0
    helm.sh/release: dev
  annotations:
    kubernetes.io/change-cause: 1.2.0
spec:
  replicas: 1
  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxSurge: 1
      maxUnavailable: 1
  selector:
    matchLabels:
      app.kubernetes.io/instance: dev-base
  template:
    metadata:
      labels:
        app.kubernetes.io/name: base
        app.kubernetes.io/instance: dev-base
        app.kubernetes.io/managed-by: helm
        app.kubernetes.io/part-of:
        helm.sh/chart: base-1.2.0
        helm.sh/release: dev
      annotations:
        checksum/config: 6f72dbccb8d1a3d882ec9b648ae9dfd9a24c2fea5d730e1eecc90569496bcc0e
        prometheus.io/scrape: "true"
        prometheus.io/port: "8081"
        prometheus.io/path: "/-system/prometheus"
    spec:
      serviceAccountName: "default"
      automountServiceAccountToken: false
      containers:
        - name: dev-base
          image: "/kubernetes-demo-service:"
          imagePullPolicy: Always
          env:
          - name: JVM_ARGS
            value: "-agentlib:jdwp=transport=dt_socket,server=y,suspend=n,address=*:8082"
          - name: JVM_INIT_MEM
            value: "256M"
          - name: JVM_MAX_MEM
            value: "256M"
          livenessProbe:
            httpGet:
              path: /-system/health
              port: 8081
            failureThreshold: 3
            initialDelaySeconds: 15
            periodSeconds: 10
            timeoutSeconds: 5
          readinessProbe:
            httpGet:
              path: /-system/health
              port: 8081
            failureThreshold: 3
            initialDelaySeconds: 15
            periodSeconds: 10
            timeoutSeconds: 5
          volumeMounts:
          - name: config
            mountPath: /config/application.yml
            readOnly: true
            subPath: application.yml
          resources:
            limits:
              cpu: 1
              memory: 512M
            requests:
              cpu: 0.25
              memory: 512M
      volumes:
        - name: config
          configMap:
            defaultMode: 0444
            name: dev-base

Number of replicas is 1, indeed. I suppose "flapping" didn't take place because of completely wrong image reference, pod cannot start by any circumstances.
So, as I understood, correct me if I'm wrong, --wait will only work if there are at least 2 replicas?

Yes, it will, but that is due to the math involved. If you only have 1 replica and you've specified that 1 replica can be unavailable, then the deployment is technically "ready" if 1 pod is unavailable. Completely open to adding logic that handles the case where only one replica is specified


Fix version hash

Apparently when version.go was updated to include the commitTime, the actual commit hash was changed from "commit" to "commitHash". But the Makefile was not updated to reflect this change resulting in the "bee version" command always showing "-dev" instead of the commit hash.
This one-word patch allows the Makefile to populate the new "commitHash" value which then corrects the "bee version" output to include the hash instead of "-dev".

This change is

I give up.  Will someone PLEASE make a PR that actually fixes the Makefile issue?


Include package local versions in --generate-hashes

Enables using --generate-hashes with packages that have local versions (https://peps.python.org/pep-0440/#local-version-identifiers). Some public projects, like PyTorch (https://download.pytorch.org/whl/cpu) use local versions for distributing different builds of their packages.

Contributor checklist

[x] Provided the tests for the changes.
[x] Assure PR title is short, clear, and good to be included in the user-oriented changelog

Maintainer checklist

[ ] Assure one of these labels is present: backwards incompatible, feature, enhancement, deprecation, bug, dependency, docs or skip-changelog as they determine changelog listing.
[ ] Assign the PR to an existing or new milestone for the target version (following Semantic Versioning).

I'd expect this to be behind a CLI option..

@webknjaz I'll update the wording to make it clearer, but this is a bugfix, not a behaviour change.
pip-tools won't generate correct installable hashes when local versions are involved (e.x. pytorch). When no local versions are available the behaviour is the same as the current one.

How so? PEP 440 specifically say that the local versions are not to be uploaded to package indexes. This implies that these are private package versions, as far as said PEP is concerned, at least.
pip-tools retrieves the package hashes for the public packages.
I'd say it's reasonable to make this optional to prevent supply-chain attacks.
Pinning the hashes is a security feature, making it possible to hijack them with private packages implicitly makes this a desired attack vector IMHO. Hence the opt-in.

Closing since I didn't have the time to address comments in the past year :(


Receive "...wasm: Syntax error: end of file unexpected" when running "cargo test"

Describe the Bug
When I run cargo test --target wasm32-unknown-unknown on my crate, I get:
serde v1.0.126
   Compiling ryu v1.0.5
   Compiling lazy_static v1.4.0
   Compiling serde_json v1.0.64
   Compiling itoa v0.4.7
   Compiling wasm-bindgen v0.2.74
   Compiling quote v1.0.9
   Compiling wasm-bindgen-backend v0.2.74
   Compiling wasm-bindgen-macro-support v0.2.74
   Compiling wasm-bindgen-macro v0.2.74
   Compiling foobar v0.1.0 (/mydir/foobar)
    Finished test [unoptimized + debuginfo] target(s) in 29.02s
     Running unittests (target/wasm32-unknown-unknown/debug/deps/foobar-e65e2b4cd23331b9.wasm)
/mydir/foobar/target/wasm32-unknown-unknown/debug/deps/foobar-e65e2b4cd23331b9.wasm: 1: /mydir/foobar/target/wasm32-unknown-unknown/debug/deps/foobar-e65e2b4cd23331b9.wasm: Syntax error: end of file unexpected
error: test failed, to rerun pass '--lib'

Note that both

wasm-pack build --target web
cargo build --target wasm32-unknown-unknown

Do succeed.

Steps to Reproduce

Set up pre-requisite wasm-bindgen tooling.
run cargo test --target wasm32-unknown-unknown on this crate.

Expected Behavior
I expect (barring bugs of mine) the test to pass.
Actual Behavior
Tooling fails to build wasm file, emitting the above error.
Additional Context
src/lib.rs:
use wasm_bindgen::prelude::*;
use std::collections::HashMap;
use serde::{Serialize, Deserialize};

#[cfg(test)]
mod tests {
    use super::*;
    #[test]
    fn it_works() {
	let json = send_example_to_js();
	assert!(!json.is_string())
    }
}

#[derive(Serialize, Deserialize)]
pub struct Example {
    pub field1: HashMap<u32, String>,
    pub field2: Vec<Vec<f32>>,
    pub field3: [f32; 4],
}

#[wasm_bindgen]
pub fn send_example_to_js() -> JsValue {
    let mut field1 = HashMap::new();
    field1.insert(0, String::from("ex"));
    let example = Example {
        field1,
        field2: vec![vec![1., 2.], vec![3., 4.]],
        field3: [1., 2., 3., 4.]
    };
    JsValue::from_serde(&example).unwrap()
}

Cargo.toml:
[package]
name = "foobar"
version = "0.1.0"
authors = ["Mike"]
edition = "2018"

[lib]
crate-type = ["cdylib"]

[dependencies]
serde = { version = "1.0", features = ["derive"] }
wasm-bindgen = { version = "0.2.74", features = ["serde-serialize"] }

Thanks for the report! The problem here is cargo is trying to execute a *.wasm as it if were a native executable. Your OS is then reporting the somewhat obscure error message. (I don't know why)
Wasm-bindgen's tests are intended to be run as wasm-bindgen-test-runner the-wasm-file.wasm, which you can configure with Cargo by setting the CARGO_TARGET_WASM32_UNKNOWN_UNKNOWN_RUNNER environment variable (more info about this in cargo's docs)

Thanks for the report! The problem here is cargo is trying to execute a *.wasm as it if were a native executable. Your OS is then reporting the somewhat obscure error message. (I don't know why)
Wasm-bindgen's tests are intended to be run as wasm-bindgen-test-runner the-wasm-file.wasm, which you can configure with Cargo by setting the CARGO_TARGET_WASM32_UNKNOWN_UNKNOWN_RUNNER environment variable (more info about this in cargo's docs)

Perfect! In retrospect that makes a lot of sense. I'll do the above.

Sure enough. wasm-pack test --node now works. Thanks again.


Use the new SDK functionality (EventGridSubscriber) to consume events.

Use the new SDK functionality (EventGridSubscriber) to consume events.

Looks good!


Implements acf command framework (#316)

Will impl the suggestion as outlined in #316
Current Progress:

[x] Base EMF Commad

[x] Toggle
[x] Next
[x] Shop
[x] Sell All
[x] Help
[x] Migrate

[x] Admin Command

[x] Competition Command
[x] Reload
[x] Version
[x] Addons
[x] Fish
[x] nbt-rod
[x] bait
[x] clearbaits
[x] rewardtypes
[x] Lists

[x] Fish
[x] Rarities

[x] Adapt Config & Commands to use CommandHelp (Optional)

Others:

[x] Rarity Context
[x] Fish Context
- [ ] Command arguments "-x:"
- [ ] "-q"
- [ ] "-p"

Don't merge this yet. We found some bugs that need to be fixed


Problem with "last updated" (Package) for OAI-PMH Request

OAI-PMH notices changes on packages by checking "last updated", but this doesn't refresh after a TIPP update, because TIPPs are a class of its own. So Systems using the OAI-PMH API don't get information on changed TIPPs.
Possible solutions:

Refresh of "last updated" on the package level after a tipp change
Additional API for TIPP changes as endpoint for OAI-PMH
Alternative API for TIPPs without OAI-PMH

Out of the three posible soilutions, i would recommend the first one. Changing just a date on a TIPP doesn't make sense, especially since the TIPPs are considered immutable. A second API endpoint giving "just the same informations like another, BUT:..." seems weird too. Ideally, delivering the correct date would only be an additional clause in the SQL statement.


Make "field value" accessible to get/setProperty mocking

Expected Behavior
Something like that should be possible:
        val mock = spyk(Team(), recordPrivateCalls = true)

        every { mock.person } answers { fieldValue as String + "A" }
        every { mock.person = any() } answers { fieldValue = value as String + "B" }
        every { mock getProperty "person" } answers { fieldValue as String + "A" }
        every { mock setProperty "person" value any() } answers { fieldValue = value as String + "B" }

Released 1.7.17. Should be fixed there http://mockk.io/#property-backing-fields


Add colors to external console

it would be necessary to add colors in the external console for the different things as for example the information of launching or the titles as for example the plugins load ect, it's certainly a lot of detail but I think it's important

Would need to refactor and use a tui library like tui-rs or cursive instead of a simple windows AllocConsole.
Was bound to need this at some point anyway.


Pass yum_package options to underlying python helper

Description
When working with custom repo that are disabled by default, we need to enable them on-demand. The python helper handles that properly but the yum package provider does not pass user's options in all cases.
Most of the time there is no issue because in normal cases you should not need to enable any repository to work with "installed" packages.
However in some rare cases, you may have multiple installed versions of a given package. In that situation, python libraries used by the helper will do some extra work that may (will) requires to enable the repo.
See call to _compare_providers in http://yum.baseurl.org/download/docs/yum-api/3.2.27/yum-pysrc.html#YumBase._bestPackageFromList
Not passing the options in that case, will result in an unclear error:

' * No candidate version available for "package" '

And often will lock/corrupt the rpm db.
Related Issue
I think this should fix #7215, at least the symptoms are the same.
By fixing the above behavior it should also avoid to trigger #8515 in that one case.
Types of changes

[x] Bug fix (non-breaking change which fixes an issue)
[ ] New feature (non-breaking change which adds functionality)
[ ] Breaking change (fix or feature that would cause existing functionality to change)
[ ] Chore (non-breaking change that does not add functionality or fix an issue)

Checklist:

[x] I have read the CONTRIBUTING document.
[ ] I have run the pre-merge tests locally and they pass.
[ ] I have updated the documentation accordingly.
[ ] I have added tests to cover my changes.
[x] All new and existing tests passed.
[x] All commits have been signed-off for the Developer Certificate of Origin.

so that certainly look like correct code, but its lacking tests, needs tests and should really look at why these tests are apparently succeeding even though it appears they have no right to be:
https://github.com/chef/chef/blob/master/spec/functional/resource/yum_package_spec.rb#L607-L653

Okay so cleared it up on slack.
The problem is that yum is, of course, weird, and sometimes you need the repo options even only to get what is installed.  Which is not something I was aware of when I was writing this.  The whatavailable check correctly passes options in because it has to, but whatinstalled doesn't get it, because I didn't think it was necessary, but turns out there are edge conditions.

On thinking about this I'm kind of inclined to just ship this, code looks obvious once I accept that yum is weird, testing looks hard.

thanks for merging this fix!  we are getting hit with this issue quite often, and looking forward to seeing this fix in a new version of chef-client soon!


Monthly app improvement status on App.co

post a status update on a public page  and then provide the link to that post on DE or somewhere

Based on @friedger 's idea.
There are many use-cases for having apps report on their monthly improvements:

Input for DE voters to see how apps are progressing.
Input for NIL reviewer to understand if an auth or Gaia issue has been fixed.
Cross-posting on PH to gain upvotes.
Good content for marketing app mining
Good user updates / marketing for apps on app.co

Feature proposal: Create a comment/change log feature in app.co and then aggregate those updates onto a monthly page that summarizes all apps and all their improvements. Not required in anyway.
Note, this is blocked by some missing functionality in app.co.

Similar to #138. Could be closed.


Revert "Remove 2FA for CIV VI"

Created a file almost identical to epicgames.js. I think its just better to update the epicgames.js instead

That's a good idea


How to export real-time PM to csv files?

I'm interested in exporting real-time performance metric (such as focus, interest) into CSV files or other files and then visualizing the data, aiming to create an interactive experience. However, since Cortex has just upgraded to V2, I'm not sure which example suits my goal. It will be great if someone could tell me more about exporting the real-time data into CSV files.
Thank you so much!

That's very helpful. I'll try it out. Thank you!


Implements basic endpoints.

Need to create Client with follow url endpoints:
GET /info
POST /b/my_data
POST /b/my_data/{blobName}
GET /b/my_data/{blobName}?ts=timeStampValue
All endpoints should implement according to the Readme https://github.com/reduct-storage/reduct-storage#reduct-storage
Who to ask questions about the task: https://github.com/flipback

Hey @Rumpelshtinskiy , it is better to use the documentation of APIs:
https://docs.reduct-storage.dev - stable v0.1.1 version
https://docsdev.reduct-storage.dev - dev v0.2.0 version.

@matepocz took over the project and is working according to his plan.


Update readme to have newer browser standards.

IE8 is not supported so checking if addEventListener is on the document isn't necessary.
Browser Compatibility
IE Support
The type attribute hasn't been needed since 1995.

The default, which is used if the attribute is absent, is "text/javascript".

Source

@blainesch what happened?

@simison pr zero :umbrella: :sunflower:

I'll pull this one in anyway - thanks, not outdated, sorry it was hanging so long :)

:+1: :dancer:

:beers:


sqlserver__alter_column_type - Not working for column change

Hi,
this macro generates an error on a simple length adjustment of a column.
I am using SQL Server 2022 (on prem) with dbt-core 1.3.2 and dbt-sqlserver 1.3.1.
To replicate setup an incremental model.

Setup the your table to include a column like varchar(50), alter the column to include varchar (5000) sql below
Run your model, which will trigger the alter_column_type macro
It will fail

The change generates this code:
alter table "mydb"."myschema"."myschema_accounting_sequences_processed" add dwh_business_key__dbt_alter character varying(50);
update "mydb"."myschema"."myschema_accounting_sequences_processed" set dwh_business_key__dbt_alter = dwh_business_key;
alter table "mydb"."myschema"."myschema_accounting_sequences_processed" drop column dwh_business_key;
exec sp_rename '"mydb".myschema.myschema_accounting_sequences_processed.dwh_business_key__dbt_alter', 'dwh_business_key', 'column'

The code results in this error:
('42S22', '[42S22] [Microsoft][ODBC Driver 18 for SQL Server][SQL Server]Invalid column name "dwh_business_key__dbt_alter". (207) (SQLExecDirectW)')

It is the same error as the last comment of #169
In SQL Server it is not allowed to have an alter table statement dirctly followed by an update statement in the same batch.
You have to use GO in between.
So if you execute the statements line by line, everything works fine. But in a single batch they won't.
I am not sure what this change would mean for consitency and rollback scenarioes in case of errors.
But probably the suggestion from @panasenco in #169 would be a better implementation?

fixed in #376


update k8s registry domain

What type of PR is this?
/kind cleanup
Any specific area of the project related to this PR?
/area plugins
What this PR does / why we need it:

update k8s registry domain

part of https://github.com/kubernetes/k8s.io/issues/4780
/assign @leogr
Which issue(s) this PR fixes:

Fixes #
Special notes for your reviewer:

[APPROVALNOTIFIER] This PR is NOT APPROVED
This pull-request has been approved by: cpanato
Once this PR has been reviewed and has the lgtm label, please assign jasondellaluce for approval. For more information see the Kubernetes Code Review Process.
The full list of commands accepted by this bot can be found here.

Needs approval from an approver in each of these files:

OWNERS

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

/assign @jasondellaluce

I agree on keeping them both. Some k8s version will still remain in the old domain so it makes sense to whitelist them both. In the future we would consider removing the old one.

sound good and thanks for the feedback, i will update those and add a comment
@leogr @darryk10

[APPROVALNOTIFIER] This PR is NOT APPROVED
This pull-request has been approved by: cpanato
Once this PR has been reviewed and has the lgtm label, please ask for approval from jasondellaluce. For more information see the Kubernetes Code Review Process.
The full list of commands accepted by this bot can be found here.

Needs approval from an approver in each of these files:

OWNERS

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

LGTM label has been added.  Git tree hash: 890f19f92c5002b381bcc06a73be8083ee408446

[APPROVALNOTIFIER] This PR is APPROVED
This pull-request has been approved by: cpanato, leogr
The full list of commands accepted by this bot can be found here.
The pull request process is described here

Needs approval from an approver in each of these files:

OWNERS [leogr]

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

/unhold
LGTM, thanks!


API to calculate amount of any asset they can transfer for free ...

... as a consequence of trading activity.
The UI should probably show the netparam which shows how much it decays each epoch.
''''''''''''''''''''
probably ignore what's below.
'''''''''''''''''''''
What do we need to cover?

clearly the upper bound on maximum fee per transfer
I guess the current “trading activity accrued discount”?
for delayed transfers it should either refuse to answer (because it can’t guarantee value of netparams).
what about recurring transfers?

From @barnabee: think we can be a bit :face_with_cowboy_hat:

estimate only the first instance of a recurring transfer (as if it was a single transfer)
always estimate as if the transfer happened right now
But I think it ideally would take into account the accrued trading fee discount as well as the cap.========

https://github.com/vegaprotocol/specs/pull/2373


Updated package dependencies

While I was setting up the project on my machine I realized that some dependencies are outdated.
If this is by intention then please ignore this PR and close it.
Tests are still passing with upgraded dependencies.
The app did also still build and I was able to run it, but I'm not familiar with the functionality, so you might want to double check it to ensure nothing breaks.

Yes, I know that at least when I last built the package (which was quite a while ago) the flutter-bloc package was not on the newest versions.
I didn't have time to pull it up to the latest version.
There were some API changes that effected the signature of some classes, therefore, I couldn't simply update to the latest version and had no time for porting.

Okay, then I would keep this one on hold until there was a further investigation about the compatibility with the new versions.


Use commonmark instead of marked

marked isn't actively maintained anymore and has a few bugs.
This PR will make it consistent with nteract and use commonmark as a markdown renderer. If anyone feels strongly against commonmark we can also consider using markdown-it.
As an added bonus this reduces our dependencies.

Uh oh, I merged the other PR -- you'll need to rebase this one.

No problem. Already rebased


fix: handle np.ndarray(N) where N is a scalar in compute results

@douglasdavis note that we also technically support returning CuPy arrays (even if the support isn't 100% right now). Perhaps we need to duck-type the result?

Angus Hollands @.***> writes:

@douglasdavis note that we also technically support returning CuPy arrays (even if the support isn't 100% right now). Perhaps we need to duck-type the result?

Yeah in that case duck typing the check indeed makes sense- I'll fix it
:) thanks!


add featureGates params to chart

Signed-off-by: calvin<EMAIL_ADDRESS>/kind feature
add featureGates params to chart

/lgtm


BenchmarkDotNet

Would there be any interest in adding a BenchmarkDotNet benchmark project to the official branch?
e.g. https://github.com/Numpsy/SharpZipLib/commit/a22ed77c994fedca550382fb1ece9cc4da6ad6d0
Can be useful for testing performance of changes and such, e.g.
Using the master branch:
CRC32 benchmark:

|             Method |     Toolchain |    Mean |    Error |   StdDev | Ratio |
|------------------- |-------------- |--------:|---------:|---------:|------:|
|   Crc32LargeUpdate | .NET Core 2.1 | 1.017 s | 0.0023 s | 0.0020 s |  1.00 |
|   Crc32LargeUpdate |        net471 | 1.021 s | 0.0066 s | 0.0062 s |  1.00 |

ZipOutputStream benchmark:

|               Method |     Toolchain |     Mean |    Error |   StdDev | Ratio |
|--------------------- |-------------- |---------:|---------:|---------:|------:|
| WriteZipOutputStream | .NET Core 2.1 | 704.3 ms | 2.094 ms | 1.635 ms |  1.00 |
| WriteZipOutputStream |        net471 | 706.8 ms | 4.888 ms | 4.333 ms |  1.00 |

vs. using PR #319
CRC32 benchmark:

|             Method |     Toolchain |     Mean |     Error |    StdDev | Ratio |
|------------------- |-------------- |---------:|----------:|----------:|------:|
|   Crc32LargeUpdate | .NET Core 2.1 | 201.2 ms | 0.6512 ms | 0.5438 ms |  0.99 |
|   Crc32LargeUpdate |        net471 | 203.8 ms | 0.5946 ms | 0.5271 ms |  1.00 |

ZipOutputStream benchmark:

|               Method |     Toolchain |     Mean |     Error |    StdDev | Ratio |
|--------------------- |-------------- |---------:|----------:|----------:|------:|
| WriteZipOutputStream | .NET Core 2.1 | 503.5 ms | 0.6950 ms | 0.6501 ms |  0.98 |
| WriteZipOutputStream |        net471 | 513.3 ms | 2.3856 ms | 1.9921 ms |  1.00 |

Sure! I have mostly written performance tests using Stopwatch before, but it's not ideal.

Great! I created a test project specifically for testing the CRC32 changes, but it's a lot better to have this integrated in the project.


Commented unused code and updated existing code

🔧 Code Cleanup & Refactor

🧹 Removed unnecessary comments to improve code readability
🔄 Reordered code for better structure
🏗 Refactored to use primary constructors
✏ Commented out unused code for future reference while maintaining clarity
⚠ Added missing null checks to enhance stability and prevent potential runtime issues
🔤 Renamed some variable names to follow C# naming conventions

I fixed your suggestions and updated the packages. Thank you for your contribution 💪🏼


remove wrong performance measurement in task assignee selector, share destination pages

Details

remove Timing, Performance measurements
migrate useCallback updateOptions into one useEffect

Fixed Issues
$ https://github.com/Expensify/App/issues/19772
PROPOSAL: https://github.com/Expensify/App/issues/19772#issuecomment-1567504829
Tests

Open a chat
Go to "Assign Task" section
Enter the task title and click on the "Next" button
Then click on "Confirm task"
Click on "To" and select a user

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

Offline tests
Same as Tests
QA Steps
Same as Tests

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

PR Author Checklist

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

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

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

[x] Android / native
[x] Android / Chrome
[x] iOS / native
[x] iOS / Safari
[x] MacOS / Chrome / Safari
[x] MacOS / Desktop

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

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

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

[x] I verified all numbers, amounts, dates and phone numbers shown in the product are using the localization methods
[x] I verified any copy / text that was added to the app is grammatically correct in English. It adheres to proper capitalization guidelines (note: only the first word of header/labels should be capitalized), and is approved by marketing by adding the Waiting for Copy label for a copy review on the original GH to get the correct copy.
[x] I verified proper file naming conventions were followed for any new files or renamed files. All non-platform specific files are named after what they export and are not named "index.js". All platform-specific files are named for the platform the code supports as outlined in the README.
[x] I verified the JSDocs style guidelines (in STYLE.md) were followed

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

[x] A similar component doesn't exist in the codebase
[x] All props are defined accurately and each prop has a /** comment above it */
[x] The file is named correctly
[x] The component has a clear name that is non-ambiguous and the purpose of the component can be inferred from the name alone
[x] The only data being stored in the state is data necessary for rendering and nothing else
[x] For Class Components, any internal methods passed to components event handlers are bound to this properly so there are no scoping issues (i.e. for onClick={this.submit} the method this.submit should be bound to this in the constructor)
[x] Any internal methods bound to this are necessary to be bound (i.e. avoid this.submit = this.submit.bind(this); if this.submit is never passed to a component event handler like onClick)
[x] All JSX used for rendering exists in the render method
[x] The component has the minimum amount of code necessary for its purpose, and it is broken down into smaller components in order to separate concerns and functions

[x] If any new file was added I verified that:

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

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

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

[x] If the PR modifies code that runs when editing or sending messages, I tested and verified there is no unexpected behavior for all supported markdown - URLs, single line code, code blocks, quotes, headings, bold, strikethrough, and italic.
[x] If the PR modifies a generic component, I tested and verified that those changes do not break usages of that component in the rest of the App (i.e. if a shared library or component like Avatar is modified, I verified that Avatar is working as expected in all cases)
[x] If the PR modifies a component related to any of the existing Storybook stories, I tested and verified all stories for that component are still working as expected.
[x] If a new page is added, I verified it's using the ScrollView component to make it scrollable when more elements are added to the page.
[x] If the main branch was merged into this PR after a review, I tested again and verified the outcome was still expected according to the Test steps.
[x] I have checked off every checkbox in the PR author checklist, including those that don't apply to this PR.

Screenshots/Videos

Web
https://github.com/Expensify/App/assets/108292595/1d72a8f8-d3cb-4674-98b0-5255d9194ddc

Mobile Web - Chrome
https://github.com/Expensify/App/assets/108292595/4e37fe21-e767-443a-9344-4ff1243a8efe

Mobile Web - Safari
https://github.com/Expensify/App/assets/108292595/870513c0-6d0c-4bf0-aba7-cc329c9ea33c

Desktop
https://github.com/Expensify/App/assets/108292595/ad5913f6-77d3-44a8-beee-e9853e39e256

iOS
https://github.com/Expensify/App/assets/108292595/65a1214e-d70e-467a-b444-69ca23e37a15

Android
https://github.com/Expensify/App/assets/108292595/be3523a3-9fd4-45d9-8332-e44d77b46c5b

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

🚀 Deployed to staging by https://github.com/arosiclair in version: 1.3.30-0 🚀

platform
result

🤖 android 🤖
success ✅

🖥 desktop 🖥
success ✅

🍎 iOS 🍎
success ✅

🕸 web 🕸
success ✅

🚀 Deployed to production by https://github.com/luacmartins in version: 1.3.30-5 🚀

platform
result

🤖 android 🤖
success ✅

🖥 desktop 🖥
success ✅

🍎 iOS 🍎
success ✅

🕸 web 🕸
success ✅


On 1.20.6

Thank you for allowing me to use this, it will be a great help to me.
So, I want to use this on 1.20.6 as well.
Could you please update this?

yeah well said, we fudging need it

Agreed.

Its actually quite easy to fix it yourself. First, rename all the folders that end in s, except for tags, to have no s. E.g. advancements -> advancement.
Then, go to the functions delta:internal/subtick/begin_launch and end_launch respectively, and change the first two summon commands to this
In begin_launch:
summon minecraft:area_effect_cloud ~ ~10000 ~ {ReapplicationDelay:-1,Radius:0f,Duration:1,Age:-1,WaitTime:0,potion_contents:{custom_effects:[{id:"minecraft:instant_damage",amplifier:0,duration:1}]},Tags:["delta.init.aec"]}
summon minecraft:bat ~ ~10000 ~ {DeathLootTable:"minecraft:empty",NoAI:1b,Health:1.0f,Tags:["delta.pre_explosion"],PersistenceRequired:1b}'

In end_launch:
summon minecraft:area_effect_cloud ~ ~12000 ~ {ReapplicationDelay:-1,Radius:0f,Duration:1,Age:-1,WaitTime:0,potion_contents:{custom_effects:[{id:"minecraft:instant_damage",amplifier:0,duration:1}]},Tags:["delta.init.aec"]}
summon minecraft:bat ~ ~12000 ~ {DeathLootTable:"minecraft:empty",NoAI:1b,Health:1.0f,Tags:["delta.post_explosion"],PersistenceRequired:1b}

Finally, go the the item_modifier folder, and change the .json file inside to this:
{
  "function": "minecraft:copy_custom_data",
  "source": {
    "type": "minecraft:storage",
    "source": "delta:storage"
  },
  "ops": [
    {
      "source": "CustomModelData",
      "target": "CustomModelData",
      "op": "replace"
    }
  ]
}

Its actually quite easy to fix it yourself. First, rename all the folders that end in s, except for tags, to have no s. E.g. advancements -> advancement. Then, go to the functions delta:internal/subtick/begin_launch and end_launch respectively, and change the first two summon commands to this In begin_launch:
summon minecraft:area_effect_cloud ~ ~10000 ~ {ReapplicationDelay:-1,Radius:0f,Duration:1,Age:-1,WaitTime:0,potion_contents:{custom_effects:[{id:"minecraft:instant_damage",amplifier:0,duration:1}]},Tags:["delta.init.aec"]}
summon minecraft:bat ~ ~10000 ~ {DeathLootTable:"minecraft:empty",NoAI:1b,Health:1.0f,Tags:["delta.pre_explosion"],PersistenceRequired:1b}'

In end_launch:
summon minecraft:area_effect_cloud ~ ~12000 ~ {ReapplicationDelay:-1,Radius:0f,Duration:1,Age:-1,WaitTime:0,potion_contents:{custom_effects:[{id:"minecraft:instant_damage",amplifier:0,duration:1}]},Tags:["delta.init.aec"]}
summon minecraft:bat ~ ~12000 ~ {DeathLootTable:"minecraft:empty",NoAI:1b,Health:1.0f,Tags:["delta.post_explosion"],PersistenceRequired:1b}

Finally, go the the item_modifier folder, and change the .json file inside to this:
{
  "function": "minecraft:copy_custom_data",
  "source": {
    "type": "minecraft:storage",
    "source": "delta:storage"
  },
  "ops": [
    {
      "source": "CustomModelData",
      "target": "CustomModelData",
      "op": "replace"
    }
  ]
}

Could you by any chance fix it for 1.21 because it doesnt work and i really need it.


Inability to define the same profile for multiple users

Because the $title of a resource is used to define a profile name within .aws/credentials, you cannot create the same profile for multiple users; i.e. 'default'.  If you attempt to do this, a puppet run will result in duplicate declaration errors.
Resource declarations can be used multiple times in puppet, as opposed to classes (which is one of the main things that differentiate them).  This is useful when you want to create multiple files, multiple vhosts, multiple aws creds:
Example:
foo::bar { ‘title’: }
foo::bar { ‘title2’: }
foo::bar { ‘title3’: }
The restriction here is that the resource title must be unique, otherwise you trigger a duplicate declaration error.
Because 'title' is used as a variable within an ERB template for profile creation (i.e., title3 “becomes” the profile name), this approach prohibits you from defining the same profile for different users.  As we know, it is very practical to use ‘default’ for different users, as that is what the AWS SDK will use, by default.
The solution is to move the profile name out of the title into a param, and make the corresponding adjustments to variable assignments and .erb template.  Thus, you can adhere to the “unique title” requirement of puppet, avoid dup declarations, and still support multiple user accounts using the same profile name, i.e., “default”.  Example:
define aws_creds::profile(
$user                  = 'root',
$aws_profile           = 'default',
$aws_access_key_id     = undef,
$aws_secret_access_key = undef,
) {
if $aws_access_key_id == undef {
fail ('no aws_access_key_id provided')
}
...
...
concat::fragment{ "${user}${aws_profile}":
target  => "${homedir}/.aws/credentials",
content => template('aws_creds/credentials_concat.erb')
}
}
concat.erb:
[<%=@aws_profile%>]
aws_access_key_id=<%=@aws_access_key_id%>
aws_secret_access_key=<%=@aws_secret_access_key%>

I'm not sure I understand the use case here. Why would the same users on a host use the same AWS credentials (or other parameter in the .aws/credentials file)?

if, on a single system, multiple users need an AWS cli profile called "default" (since most tools / libraries make it difficult to use named profiles), this isn't possible to achieve given your use of $title. I agree that the solution should be to make an aws_profile param if you want something other than "default", and the actual $title can be ignored other than puppet's internal use.

@justindowning
The use case isn't the same users on the same system, it is  different users on the same system, using the same profile name within their credentials/config files (i.e., 'default').  This is very useful when you deploy different IAM creds for different users on the same system, depending on the AWS perms you want to authorize for each user (super-users vs S3 bucket manager).  The way it is handled currently, you need to define a different resource title for each user, which would translate to different profile names.  This would require unpleasant adjustments on the cli/sdk.  Example:
User A creds file:
[default]
aws_access_key_id=AKIAIOSFODNN7EXAMPLE
aws_secret_access_key=wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY
User B creds file:
[default2]  <==== necessary to use "default2" in the resource declaration to avoid dup declaration
aws_access_key_id=AKIAI44QH8DHBEXAMPLE
aws_secret_access_key=je7MtGbClwBF/2Zp9Utk/h3yCo8nvbEXAMPLEKEY
User B must then do:
aws ec2 describe-instances --profile default2
Parameterizing the profile name allows both users to use default, requiring no adjustments on the CLI or within an SDK (boto, etc).
jgnagy's commit looks good; in fact he simplified my approach by retaining the use of $title within the concat::fragment statements (which will always be unique).

FYI implementing the code changes per @jgnagy or my advice will certainly be a backwards compatibility breaking release.

My PR includes an update to the README that briefly describes the change as breaking. It wouldn't hurt to accentuate that a bit more if the PR is accepted, perhaps with a minor (or even major) version bump.

I created https://github.com/justindowning/puppet-awscli/issues/24, but realised the issue probably  makes more sense to be fixed as part of this. Please note the naming format of a named profile is different between ~/.aws/credentials and ~/.aws/config.

@jccl I modified the .erb template to incorporate your changes.  Good catch, thanks.  Tested as working in my env.

@jccl and @mvolhontseff, agreed, this is a good catch, and I'm happy to integrate a check (and appropriate logic) for this here if we all agree it makes sense to do so.

@jgnagy - updated config_concat.erb and submitted a pull request

Merged, and I updated the README. We'll see if all the tests still pass, then maybe @justindowning can merge this in for us.

Merged #23 🎉


[CSL-57] Presense of headerDifficulty and difficultyL is confusing

@gromak

@neongreen
Fixed in CSL-756 branch

@gromak
Great!


Make first versioned Alpha release

A version 0.0.1 package ready to extract and run should be released soon, both for Linux and as an EXE build for Windows. It should be released once all of the code and commands are fairly well documented.

Finished in release v0.0.1-alpha.