text:
HA-Bridge/SmartThings Shows Bulbs Offline After Latest (26.9) Firmware Update

Hi, I'm a developer on the hub firwmware at SmartThings.  We recently updated our local hue integration to have more direct support for "device health" within the SmartThings platform (along with other changes).  As a result of these changes, some users using HA-Bridge have complained that their bulbs are now showing as offline or toggling between offline/online (see https://community.smartthings.com/t/hub-firmware-release-notes-26-9/166632/10).
I do not currently run HA-Bridge but our current suspicion is that this occurs due to HA-Bridge not fully emulating the reachable attribute of the /api/<username>/lights/<id> endpoint in some way (or not supporting that endpoint at all).
We haven't done a deep dive into this as of yet but we suspect the right fix is for HA-Bridge to provide a better emulation of the bridge.  One simple solution to start out would be to "lie" and always present any attached devices as reachable.
If additional details are required from the SmartThings team just ping me on this issue and I'll do my best to get the right info back to you.

I am an HA-Bridge (v5.2.2), SmartThings Hub (v2), Alexa (4 Echos v1, and a few v1, v2 Echo dots) user that lost access to all my HA-Bridge devices after the ST firmware update on 6/27.   I've spent much of this past weekend troubleshooting mostly to no avail.  However, I have a few observations that may be useful to you.   The most significant of which is that reversion to HA-Bridge v3.5.1 fixed a longstanding inability of Alexa to discover HA-Bridge devices directly (i.e., not through ST).

In absence of ST=>HA-Bridge function since 6/27/2019, I tried to get Alexa to discover the HA-Bridge directly (not through ST) but have been unable to make it work.   I read many comments about multiple Echo's of different versions causing conflict and scaled back to only one and ensure it was directly connected to same router as HA-Bridge on Raspberry Pi.   None of this worked.  No discovery of HA-Bridge devices.   I varied the UPNP delay between 250ms and 1000ms without affect.   I used port 80, used LINK button.   Turned on UPNP for my router.   Checked for IGMP issues.   Troubleshooting per https://github.com/bwssytems/ha-bridge/wiki/Trouble-Shooting#nodiscover
None of this helped.

Finally, based on a clue I saw in another thread, I reverted HA-Bridge back to 3.5.1 and Alexa found all 81 HA-Bridge devices on the first try without going through ST Hub.   Direct Alexa discovery of HA-Bridge devices is ultimately what I want so that the ST Hub (and the cloud) is not the loop for devices that don't require it.

The loss of direct Alexa discovery is not recent.   Many months ago Alexa discovered my HA-Bridge devices directly, but at some point Alexa only began discovering them through ST.   For the most part this did not affect me so I ignored it.   This week's debacle with the ST firmware upgraded got me into troubleshooting Alexa discovery.

I still don't have ST working with HA-Bridge.  That does appear to be related to the 'device health' feature.  After many trials, I finally got ST to rediscover the HA-Bridge, but it was immediately declared 'OFFLINE' and hasn't changed and it never reloaded all the HA-Bridge child devices.

So what goodness in v3.5.1 should be resurrected to improve (or in my case enable) Alexa discovery?   I will sit here with 3.5.1 as a stopgap but I sure would like the other enhancements you have added in subsequent revisions.
Thanks for a great piece of software.
I've attached some logs of v5.2.2 failure and v3.5.1 success in case it helps you.
discovery_success_log_v351.txt
discovery_fail_log_v522.txt
Tom

@EnGamma In the RC version of ha-bridge, I put the original upnp broadcast message from v3.5.1 in it. You can also just turn on that message from the Bridge Control tab under the use upnp original.
@posborne As far as the attributes returned on the state message of the hue to have reachable=true, I'll double check to make sure that is set as that was the default.

I have this issue as well

@posborne Reachable in the state section is always set to true in the ha-bridge. What other state items are you looking at?

@posborne Reachable in the state section is always set to true in the ha-bridge. What other state items are you looking at?

Ok, I followed up with the primary maintainer of the hue integration code and I was off base with that initial theory as confirmed by your finding.
We think the problem is probably on our end and relates to trying to use TLS for V2 bridges.  Since HA-Bridge reports as a V2 bridge that was being attempted.  We will likely be considering a fix short term that either uses the version of the bridge (1.24+ for TLS) as a marker for TLS support or, temporarily, just using port 80 as we have in the past.  Longer term, we will of course want to use TLS whenever possible when talking to real bridges as otherwise hue credentials are in the clear.
Sorry for the confusion, I may play around with ha-bridge and get it setup on my unraid server at home so we have better dogfooding of that moving forward and test the fix we are prepping right now.  The TLS switchover may be affecting some customers who have bridges on older firmware anyhow.

Great news, I may incorporate HTTPS with TLS as well as that is where the hue API is at anyway, but that will be in the future.

@EnGamma If you could list what IP's are what in your log, that would be helpful

.170 is ST
.155 is Raspberry Pi running HA-Bridge
.48, .49 Harmony Hubs
.23, .91 .103, .138, .147, .214 are Alexa Echos or Echo Dots

@EnGamma In the RC version of ha-bridge, I put the original upnp broadcast message from v3.5.1 in it. You can also just turn on that message from the Bridge Control tab under the use upnp original.

I just tried v5.3.0RC8 and it failed with 'UPNP Original (simple version)' checked.  Log attached.
discovery_fail_log_v530RC8.txt
Yesterday, I tried other versions to find out where Alexa discovery stops working for me.  Summary of what I have found:
5.3.0RC8 => fails
5.2.2 => fails
5.2.1 => fails
4.5.6 => fails
4.3.1 => successful Alexa discovery
3.5.1 => successful Alexa discovery

@EnGamma This is very weird as your echos do ask for the hue lights from the ha-bridge which tells them they found lights... The message below is one of them:
Jul  1 19:18:58 HA-PI java[29458]: 2019-07-01 19:18:58,344 [qtp9662400-92] INFO  com.bwssystems.HABridge.hue.HueMulator - Traceupnp: hue lights list requested by user: 6GtNFc2ewsQuUlGtH4NNM5hmTgiisr5Jh4iafloa from address: 192.168.124.103
If you see these messages, the echo has discovered the ha-bridge and is asking for what lights it has.
Could you humor me and only have one echo running and the ha-bridge on RC8.  Also, please uncheck upnp original when you do this.
Also, I determined that the difference in v3.5.1 and the newer version is not what I put into the latest RC versions. I have that covered in RC9, but it is ever so slight.

@EnGamma The new release RC9 is out and now emulates the v3.5.1 properly when upnp original is selected. Also, this release has mDNS capabilities.

Could you humor me and only have one echo running and the ha-bridge on RC8. Also, please uncheck upnp original when you do this.

I've done this with both RC9 and then RC8, checked and unchecked and all failed.   Log attached.
discovery_log_v530RC9_v530RC8.txt

After failing with RC8 and RC9 I've reverted back to v4.3.1 for now.   Here is a clean log showing successful Alexa Discovery with this version.  Works 100% of the time.
discovery_success_log_v431.txt

https://community.smartthings.com/t/hue-integration-stopped-working-27-june-2019/166962/51

https://community.smartthings.com/t/hue-integration-stopped-working-27-june-2019/166962/51

Yes, this addresses the 6/27 problem with SmartThings, but it does not address the direct Alexa (Echo)=>HA-Bridge discovery problem, which predates that issue.   The 6/27 ST problem, however, is what got me back into troubleshooting why the direct Alexa discovery of HA-Bridge devices was failing.
For me, and I would imagine numerous others, not requiring ST to be in the middle is an important benefit.   I have lost control before due to ST issues, so one less dependency is desirable.

@bwssytems: Since I have a repeatable HA-Bridge version-dependent issue, I am willing to support any further troubleshooting I can help you with.

Thanks, still trying to figure out what's different as the code I see send to reflect what the older version is now doing. Will review some more. Also, don't use RC8 as that was not correct for the discovery portion.

@EnGamma From your RC9 log, the echo asks for the lights list, but seems to do it multiple times with this message: Jul  2 18:49:41 HA-PI java[20294]: 2019-07-02 18:49:41,171 [qtp31486706-93] INFO  com.bwssystems.HABridge.hue.HueMulator - Traceupnp: hue lights list requested by user: 6GtNFc2ewsQuUlGtH4NNM5hmTgiisr5Jh4iafloa from address: 192.168.124.103
So, the echo is fine with the UPNP handshake, but it seems it does not like something in the lights list. Would it be possible for you to post your device.db?

@EnGamma From your RC9 log, the echo asks for the lights list, but seems to do it multiple times with this message: Jul 2 18:49:41 HA-PI java[20294]: 2019-07-02 18:49:41,171 [qtp31486706-93] INFO com.bwssystems.HABridge.hue.HueMulator - Traceupnp: hue lights list requested by user: 6GtNFc2ewsQuUlGtH4NNM5hmTgiisr5Jh4iafloa from address: 192.168.124.103
So, the echo is fine with the UPNP handshake, but it seems it does not like something in the lights list. Would it be possible for you to post your device.db?

@bwssytems Here is the device.db file.  Thanks.
device.db.txt

Does anyone know if the SmartThings firmware will be updated to support the HA Bridge?  I’m still unable to connect and show HA Bridge offline.

I installed the smartapp Hue_B_Smart and got mine back.
Smartthings made a change from port 80 to port 443 for discovery which stopped Gen 1 Hue and HA-Bridge Smartthings connections.
There is talk of an update, but that was said to be released in the next several weeks.

Meanwhile support will manually reset the port to 80 for you.   This is not
normally user settable.  It may also revert to port 443 under certain
circumstances, I believe.
On Thu, Jul 11, 2019 at 19:51 audiofreak9 notifications@github.com wrote:

I installed the smartapp Hue_B_Smart
https://github.com/tmleafs/Hue_B_Smart and got mine back.
Smartthings made a change from port 80 to port 443 for discovery which
stopped Gen 1 Hue and HA-Bridge Smartthings connections.
There is talk of an update, but that was said to be released in the next
several weeks
https://community.smartthings.com/t/hue-integration-stopped-working-27-june-2019/166962/64?u=corey_murnaghan
.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/bwssytems/ha-bridge/issues/1107?email_source=notifications&email_token=ACSR2EJJSCNEVETSFUZQM7TP67BOXA5CNFSM4H4NBOMKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODZYJDSI#issuecomment-510693833,
or mute the thread
https://github.com/notifications/unsubscribe-auth/ACSR2ELG6SUEOVH5NWGUSXTP67BOXANCNFSM4H4NBOMA
.

Meanwhile support will manually reset the port to 80 for you.   This is not
normally user settable.  It may also revert to port 443 under certain
circumstances, I believe.

That is true, support did change my HA-Bridge in ST to port 80, however I was unable to do a device discovery since that is performed on port 443 now with the ST update.
My lesson learned, don't delete devices in ST until there is an update to ST.  I deleted all my devices and the bridge from ST trying to troubleshoot before I knew there was a ST update.

I have added https support into the latest branch (but not released it yet), but it will require you to build tls keys to do this. Instructions need to be written.

@EnGamma One suggestion maybe encoding I changed from one version to the other for the return of the lights list. Could you try changing the two entries that have an apostrophe in it "Gregory's" and Kathy's" to be without it, "Gregorys" and Kathys",  as the Alexa does not care about those.

One suggestion maybe encoding I changed from one version to the other for the return of the lights list. Could you try changing the two entries that have an apostrophe in it "Gregory's" and Kathy's" to be without it, "Gregorys" and Kathys", as the Alexa does not care about those.
<Edit>
Also, I would suggest doing a renumber under RC9 as that will make the ids and unique ids cleaner.

@bwssytems

Removing apostrophes had no effect.
I renumbered under RC9 (to simpler 3-digit numbers) and Alexa is now discovering all devices!

Thank you.   I will continue to monitor.

@EnGamma Great! It looks like you have been using ha-bridge from the beginning as you had the high order numbers that were replaced. And the numbering scheme is now settable from a given start point. Also when renumbering, the Hue Unique Ids are regenerated to be more correct in the latest version.

I have added https support into the latest branch (but not released it yet), but it will require you to build tls keys to do this. Instructions need to be written.

Any update on when this would be ready?
I am holding off on switching as habridge has worked fine with my Alexas, domoticz , SmartThings and google home for years now and I'd rather wait if this is coming anytime soon :(

As of last Monday 7/20 the SmartThings firmware hotfix has been deployed so ha-bridge and ST (using port 80) should be working again.  Port 443/TLS has not been tested.  The solution on the ST side implemented for now decides the port/tls based on the reported version from the bridge.

@posborne
ST successfully found all my HA-Bridge devices, thanks!

Great! Closing this now. Any other issues outside of this should be reported elsewhere.

authors: EnGamma audiofreak9 bwssytems cbrittler danwooller posborne superczar

repo: bwssytems/ha-bridge


text:
xbox-smartglass-core-python commands dont execute

Hi! First of all, great work!
I have problem executing commands to control my Xbox One. I have plenty of other devices running commands but the xbox-smartglass-core-python doesnt fire off. The commands works in the terminal.
Example: xbox-poweroff --all
This will turn off all connected devices, works great in terminal, but not in HA Bridge. No error message, just a message that everthing went well....but nothing happens.
Anything you guys have been running into?
I have also tried putting those commands into python scripts and shell scripts, without any luck...
Cheers!
Running on Pi3 Raspbian Stretch lite

try putting cmd.exe before that so it will execute in a windows shell

Tried that but without success... HA says its running, but its not.

So, does the script uses specific paths to what it is executing? Since ha-bridge kicks off a process, it is not in a shell with environment variables loaded.

It uses load_entry_point to execute the commands...maybe thats why it wont work...? No specific paths... But I cant really see why it shouldnt work. I have also tried putting the command in both .sh and .py files and executed them from those script-files, but without any luck. I also rewritten them so I dont need any parameters any more, but no luck. Those scripts working from terminal but not in the HA.

You need to run this within a shell script with all of your environment variables set to run python.

bwssystems, you rock! Just had to set the env var to my python sites-packages in a shell-script and call the original command from there!

There ya go, I should put a FAQ in for this as java execution environment spins off a clean thread...not like you have when you login to your machine...

source: gharchive/issue

license_type: permissive

license_source: bigquery


text:
Column name must start with a letter or underscore

https://github.com/bxparks/bigquery-schema-generator/blob/11bf0a2bd90a4f00385528c13caef7c0d3125b87/bigquery_schema_generator/generate_schema.py#L250
sanitize logic allows numbers to start name of column.

As far as I'm concerned, it is the responsibility of the dataset owner to clean up the data for BigQuery, it's not the job of this project. I don't have any motivation to work on this. But if you send a clean PR with good unit tests, I'll take a look.

Just for completeness, there was a previous Discussion about this here:
https://github.com/bxparks/bigquery-schema-generator/discussions/84
The high level point is that this project is a schema generator, not a data sanitizer, so I consider this to be outside the scope of this project. I don't want to be in the business of trying to support every variation of how different people want to sanitize their own data.
Closing.

authors: bxparks somanishivam

repo: bxparks/bigquery-schema-generator

license_source: github-api


text:
fix: incorrect Logo colour, inverted elevation colour

Types of Changes
What types of changes does your code introduce? Put an x in all the boxes that apply:

[ ] Bug fix (non-breaking change which fixes an issue, please reference the issue id)
[ ] New feature (non-breaking change which adds functionality, make sure to open an associated issue first)
[ ] Breaking change (fix or feature that would cause existing functionality to change)
[ ] My change requires a change to the documentation
[ ] I have updated the documentation accordingly
[ ] I have added tests to cover my changes
[ ] All new and existing tests passed

Description
[Place a meaningful description here.]

:tada: This PR is included in version 9.3.1 :tada:
The release is available on:

npm package (@latest dist-tag)
GitHub release

Your semantic-release bot :package::rocket:

source: gharchive/pull-request

repo: bylapidist/components

license: MIT


text:
Replace special string constants with empty string.

On Linux, the special ACL entries for owner, group, other, and mask are represented by special @ strings:
owner -> kind=user, name="@ owner"
group -> kind=group, name="@ owner"
other -> kind=user, name="@ other"
mask -> kind=group, name="@ mask"
A problem is that an @ can appear in a user name. Instead, add two new AclEntryKind for 'other' and 'mask', then use an empty string to represent the special ACL entries. This is how the ACL text format works on Linux.
owner -> kind=user, name=""
group -> kind=group, name=""
other -> kind=other, name=""
mask -> kind=mask, name=""
The new AclEntryKind's of other and mask would only be available on Linux.

This change will also require new AclEntry factory methods:

AclEntry::allow_other
AclEntry::allow_mask

repo: byllyfish/exacl


text:
(jco componentWit) Failed to decode wit component unknown component version

Hello,
I am trying to transpile the hello world from bytecodealliance/cargo-component but it seems to be incompatible?
$ jco wit ./target/wasm32-wasi/debug/cargo_comp.wasm

(jco componentWit) ComponentError: Failed to decode wit component
unknown component version: 0xd (at offset 0x0)

I get the same error when I try to jco transpile ... wasm components I've built from wit-bingen and adapted using the preview2 adapter.
Am I missing something?

Window 10
jco version 0.7.0

Steps to reproduce:

clone https://github.com/bytecodealliance/cargo-component
cd example
cargo component build
jco wit ./target/wasm32-wasi/debug/service.wasm

(jco componentWit) ComponentError: Failed to decode wit component
unknown component version: 0xd (at offset 0x0)
    at componentWit (node_modules/@bytecodealliance/jco/cli.mjs:45393:13)
    at componentWit (node_modules/@bytecodealliance/jco/cli.mjs:47121:18)
    at async node_modules/@bytecodealliance/jco/cli.mjs:47475:9

Thanks for the reply! Good to know, this was driving me crazy. Will leave this here for others in the meantime, looking forward to the 0xd release 🚀🎉

Linking this to https://github.com/bytecodealliance/wasm-tools/pull/1027 aka "0xc is dead long live 0xd" for reference

Landed in https://github.com/bytecodealliance/jco/pull/86.

Thank you! You are the guy! Can't wait to use it =)

Hey, first of all thanks for the great work. Could it be that something went wrong with building the 0.8.0 release for npm. I installed the 0.8.0 version from npm, but when I run jco --version I get 0.7.0.

Yeah me too, which is weird because it was supposed to be fixed here https://github.com/bytecodealliance/jco/pull/88

I mean here: https://github.com/bytecodealliance/jco/pull/89
It hasn't been merged yet, but should fix it once merged
For what it's worth, I think the v8 functionality still works even though it displays v7

Great, thanks for the info

authors: DougAnderson444 JanKaul guybedford

repo: bytecodealliance/jco


text:
Is the uinit in binary size table correct?

Hi,
I am currently doing a preview of wasm running on MCU/RT-Thread.
The size of binary data is our major concern.
The wiki pages shows those numbers are in KB but they are quite simple codes. And the size of GCC binary doesn't make sense to me. I wonder if the units are wrong here?
https://github.com/bytecodealliance/wasm-micro-runtime/wiki/Performance#wasm-application-binary-size
Thanks.

Hi, thanks for reporting the issue! The units should be Bytes but not KB, we have updated the wiki page. Thanks.

authors: majianjia wenyongh

repo: bytecodealliance/wasm-micro-runtime


text:
Type propagation

When inferring types for the rewriting egraph tree during the translation from Wasm to the egraph some type information is missing. However, it can be inferred by the type relations between the nodes. For example for the i32.wrap_i64 operator, we always know that it returns an i32 constant and waits for the operand to be an i64 integer. This information could be propagated to the other nodes in the tree.
This new implementation does exactly that, it fixes some nodes to expect and receive specific types using fixed operators and function signatures. The type tree is traversed until is converges, if for some reason, a node has not a type (when it should) this type is gathered from the egraph eclass data.
cc @fitzgen

ping @fitzgen. Thanks for the feedback :)

Done 😄

repo: bytecodealliance/wasm-tools


text:
test failure in cranelift-bforest and cranelift-entity with: no global memory allocator found but one is required; link to std

I've run the tests via:
cargo build -j12
cargo test --all -j12

here's the full log: test-failure.zip
I wonder if this is related to https://github.com/bytecodealliance/cranelift/pull/1262

This is an old bug and appears related to no_std support, which we don't support; I will go ahead and close this.

authors: cfallin stefson

repo: bytecodealliance/wasmtime


text:
Automatically test examples in the book

What would it take to automatically test code examples in the book when we run cargo test --all, to make sure they keep working as the API evolves?

That's a great idea @joshtriplett - it looks like this was implemented after you opened this issue, testing of the examples in the book has was added in https://github.com/bytecodealliance/wasmtime/commit/c7fb1354528f5c431d6d82b5500be1f70539671a and is still present in the current version of the codebase:
https://github.com/bytecodealliance/wasmtime/blob/b438617e1238bec01ebc804c0087e4849df0dc87/.github/workflows/main.yml#L84
I believe that we can mark this issue as resolved/closed 👍

authors: JakeChampion joshtriplett


text:
Allow missing imports in WASM module through a feature flag

I've added the possibility to allow missing imports in modules. This has been discussed here.
To re-iterate the need for this, there are use-cases where not all host programs VMs have been updated to the latest version that exports all functions required by modules that execute on these hosts.
In such instances it's more convenient to dynamically check a feature flag and call the native methods only if they exist vs emitting different binaries for each VM version.
For example, this allows your WASM program to use this type of pattern:
// call specific function to check for functionality before calling a method that might not exist
if (vm_host_has_feature("feature_name") {
     call_function_from_vm_because_it_should_exist_here();
} else {
     fallback_bhv();
}

If the you call a missing import it will cause the VM issue a trap.
Once optional imports are standard and implemented, the escape hatch can be removed, in the meantime it's a really useful feature to have.
Maybe @tschneidereit can review this since we discussed it on zulip?

API-wise I personally feel like this would instead be a flag on Linker rather than a compile-time option, but the code is also so small here to support this I think it may be worthwhile exploring how we might be able to support this externally. Creating a Func::new which simply panics or returns a trap isn't so hard, and ideally clients that would specifically like to allow imports they don't allow could opt-in easily by implementing such behavior.
For example one option to implement this externally today is that instead of Linker::instantiate you'd use Linker::get manually on the module's imports, filling in missing ones as necessary. Put another way I think you could write a function that takes &Linker and &Module and instantiates the module with this behavior only using the public API of the wasmtime crate.
One worry I'd have with this as-is as well is that it assumes all missing imports are missing function imports, but it could be a missing import of any type and it's not entirely clear what you'd do for the other types of missing imports (e.g. a missing imported table for example).

Yes, it just allows functions to be missing, for other things it still has the behavior it had today, as I'm not sure what a "sane" alternative would be for missing non-functions.
I like your alternative, I wasn't aware it's possible. do you have an example where those APIs are used that I could start from?

I believe a function like this should work for your purposes:
fn instantiate(linker: &Linker, module: &Module) -> Result<Instance> {
    let mut imports = Vec::new();
    for import in module.imports() {
        match linker.get(&import) {
            Some(value) => imports.push(value),
            None => match import.ty() {
                ExternType::Func(ty) => imports.push(
                    Func::new(linker.store(), ty, |_, _, _| {
                        Err(Trap::new("function not implemented"))
                    })
                    .into(),
                ),
                _ => anyhow::bail!("import not defined"),
            },
        }
    }
    Instance::new(linker.store(), module, &imports)
}

I do feel that having a Linker flag for this would be good, perhaps called something like unstable_allow_missing_function_imports or so, to make the "functions only" part clear.
Additionally, it'd be great to also add this as an option --unstable-allow-missing-function-imports to the CLI. @AlexEne, do you think that's something you could add?

Yes, I can check how to add that to the CLI too. (and fix the name)

@tschneidereit on the command line option. I've added a unstable_allow_missing_function_imports in wasmtime/src/lib.rs in CommonOptions, and in the Config class from wasmtime/src/config.rs.
I've also added a boolean setting in the linker, but it's unclear to me where I should configure the linker to use that value from Config.

I don't think that this needs to be in Config, at most I think it just needs a flag on Linker. @tschneidereit would you be ok with just a CLI flag, though? Since this is easy enough to implement externally and since this is in theory behavior that will get subsumed by wasm standards in the future, I'd prefer to avoid changing the Linker type if we can.
@AlexEne for the C API I think wasm_importtype_t already exists, and for acquiring the store you could either store that in a global variable or use the wasmtime_* APIs for functions which give you a wasmtime_caller_t which you can acquire the store from. We may not have the method in the C API yet to get the wasm_store_t from that but it's possible to implement.

Yes, wasm_importtype_t exists, the one that I mentioned was ImportType (the rust counterpart and parameter to linker.get(  as that's currently defined as pub(crate) and can't be created in order to call the linker current method. It's not a big deal, I can shuffle things around so it's possible to create it from the c-api crate.

It seems that there isn't really an consensus on how to proceed with this, so I will close this PR for now, and will handle this in my mirror as my use-case can be solved by a patch of a couple of lines in the linker that makes this behavior default.
Once optional imports are implemented this would not be needed anyway.

authors: AlexEne alexcrichton tschneidereit


text:
Fix a tiny issue with BufWriter

BufWriter had a tiny issue: the cap was not updated, which would cause successive writes to erase start from the beginning each time.

 Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.You have signed the CLA already but the status is still pending? Let us recheck it.

authors: CLAassistant Miaxos

repo: bytedance/monoio


text:
Test Issue By Bytepay: lowly boat

This issue is for bytepay test

/bytepay task 0.001DOT

Bytepay: Finish This Task, sulnong will pay you 0.001 DOT.
Comment in Following instruction to apply for this task
/bytepay apply
Visit http://bytepay.local-dev.com for more detail

/bytepay apply

Bytepay: Task has been assigned to @Emptycity-tear.

/bytepay bind 5FU6HZLVj74hF1sBxAFQ7PkS6HQbVF3gAFDLPLV37YFNKNjV

@Emptycity-tear:
Bind Success.
Now Your Own Polka Address Is: 5FU6HZLVj74hF1sBxAFQ7PkS6HQbVF3gAFDLPLV37YFNKNjV
Previous Is: 5FU6HZLVj74hF1sBxAFQ7PkS6HQbVF3gAFDLPLV37YFNKNjV

/bytepay pay

@Emptycity-tear:
sulnong have paid for this task, visit https://westend.subscan.io/extrinsic/0xb59db226b4a3565f8a8d50b203adbea8d11c3b443102a7596d96382eab8ff392 for detail

/bytepay pay @Emptycity-tear 0.01DOT

@fanux:
Seems your account have only 0 DOT available, less than 0.01 DOT you want pay.
Please recharge token on http://localhost:10086 first.

authors: CryptoPayLabBot Emptycity-tear fanux sulnong

repo: bytepayment/bytepaytest


text:
Duplicate rows

Created function:
build_activities <- function(trips) {
+

create list of events labeled arrive or depart

events <- trips %>%

# exlude all other trip attributes

dplyr::select(houseid, personid, strttime, endtime, whyfrom, whyto) %>%

# gather times

tidyr::gather(strtend, time, strttime, endtime) %>%

dplyr::group_by(houseid, personid) %>%

# there have been errors where a time stamp is wrongly labeled and

# wrongly arranged here...and again on line 57

dplyr::arrange(time, .by_group = TRUE) %>%

dplyr::mutate(

  event = ifelse(strtend == "strttime", "depart", "arrive"),

  activity = ifelse(event == "depart", whyfrom, whyto)

)

create the first activity for each person with a start time at 4 AM

first_activity <- events %>%

# take the starting point of each person

dplyr::slice(1) %>%

# creates a starting time for each person at 4:00:00 am

dplyr::transmute(

  activity = as.character(whyfrom),

  time = lubridate::as_datetime("2017-10-10 4:00:00"),

  event = "arrive"

)

create the last activity for each person with an end time of 4AM the next day

last_activity <- events %>%

dplyr::slice(n()) %>%

dplyr::transmute(

  activity = as.character(whyto),

  time = lubridate::as_datetime("2017-10-11 4:00:00"),

  event = "depart"

)

combine events with first and last activity

spread by either arrive or depart

events %>%

dplyr::full_join(first_activity) %>%

dplyr::full_join(last_activity) %>%

dplyr::arrange(time, .by_group = TRUE) %>%

dplyr::select(-whyfrom, -whyto, -strtend) %>%

dplyr::group_by(houseid, personid, event) %>%

dplyr::mutate(activity_number = as.integer(factor(time))) %>%

tidyr::spread(event, time) %>%

dplyr::arrange(arrive, .by_group = TRUE)

Ran function:

build_activities(nhts_trips)
Joining, by = c("houseid", "personid", "time", "event", "activity")
Joining, by = c("houseid", "personid", "time", "event", "activity")

Received error:
Error: Each row of output must be identified by a unique combination of keys.
Keys are shared for 4 rows:

291998, 291999
840390, 840391

stop(fallback)
signal_abort(cnd)
abort(glue("Each row of output must be identified by a unique combination of keys.",
"\nKeys are shared for {shared} rows:", "\n{rows}"))
spread.data.frame(., event, time)
tidyr::spread(., event, time)
dplyr::arrange(., arrive, .by_group = TRUE)
events %>% dplyr::full_join(first_activity) %>% dplyr::full_join(last_activity) %>%
dplyr::arrange(time, .by_group = TRUE) %>% dplyr::select(-whyfrom,
-whyto, -strtend) %>% dplyr::group_by(houseid, personid,
event) %>% dplyr::mutate(activity_number = as.integer(factor(time))) %>%  ...
build_activities(nhts_trips)

Any idea why I'm getting these duplicate rows?

name: Label issues
on:
issues:
types:

reopened
opened
jobs:
label_issues:
runs-on: ubuntu-latest
permissions:
issues: write
steps:
name: Label issues
uses: andymckay/labeler@5c59dab
with:
add-labels: "bug"
repo-token: ${{ secrets.GITHUB_TOKEN }}

Closing for lack of response

authors: coudykid gregmacfarlane


text:
🛑 Wodemo的一楼 is down

In 587170f, Wodemo的一楼 (https://bywhite.wodemo.net) was down:

HTTP code: 0
Response time: 0 ms

Resolved: Wodemo的一楼 is back up in 9db4a1e.


text:
use notebook latest version

use notebook latest version

@chncaesar PTAL

repo: byzer-org/byzer-build


text:
"panic: runtime error: integer divide by zero" - getting error on docker container

Try to run this on docker container getting error
panic: runtime error: integer divide by zero, any help please?

Hi @harshapic ! Could you tell me your source code using go-prompt.
I can't help you without it.

yes its using go-prompt
/home/sdp/go/src/github.com/xxxxx/sdp-cli-client/vendor/github.com/c-bata/go-prompt/prompt.go:50 +0xe0
main.main()
/home/sdp/go/src/github.com/xxxxx/sdp-cli-client/main.go:78 +0x764
Tried to run on docker container with base "ubuntu:16.04"
docker version: Docker version 17.03.2-ce, build f5ec1e2

import (
"fmt"
"github.com/c-bata/go-prompt"

)
Actually if i run it on ubuntu machine my code is working fine when i copy executable to docker container and if i try to run it it giving me error

Sorry, It's difficult to help you from these information.
Is sdp-cli-client your private project? I need to check the source code and need to know how you use go-prompt.

ok let me create a test project and create docker container with it and will give you source code

this is my sample test project, it has everything even with dockerfile.
Steps to replicate issue:

CGO_ENABLED=0 GOOS=linux go build -a -installsuffix cgo -o yang-cli
docker build -t yang-cli .
docker run -it yang-cli /bin/sh

yang-cli.tar.gz

you will get this issue:
yangcli  (rev-)
Please use exit or Ctrl-D to exit this program..
Bye!
panic: runtime error: integer divide by zero
goroutine 1 [running]:
github.com/yang-cli/vendor/github.com/c-bata/go-prompt.(*Render).Render(0xc4200d6000, 0xc420069d80, 0xc4200cc810)
/home/sdp/go/src/github.com/yang-cli/vendor/github.com/c-bata/go-prompt/render.go:134 +0x50c
github.com/yang-cli/vendor/github.com/c-bata/go-prompt.(*Prompt).Run(0xc42008bce0)
/home/sdp/go/src/github.com/yang-cli/vendor/github.com/c-bata/go-prompt/prompt.go:50 +0xe0
main.main()
/home/sdp/go/src/github.com/yang-cli/main.go:44 +0x5a3

but same thing it works properly on my developer machine

@c-bata  ru able to reproduce issue on docker container?

This is kind of a race condition between the time taken for docker to complete allocation of psuedo terminal and go-prompts initial window calculations.
Fix submitted in https://github.com/c-bata/go-prompt/pull/32

thank you @bcicen

authors: bcicen c-bata harshapic

repo: c-bata/go-prompt

license: mit


text:
Update all examples to work in 1.3.0

Goal: all existing examples working in 1.3.0.
Progress so far on branch "examples-to-1.3"

Updated examples to use A-Frame 1.3.0
Updated to use three-to-cannon v4
Updated examples to use latest environment component & sphere colliders
Updated CANNON-shape2mesh to use BufferGeometry rather than Geometry.  This affects all of: convex polyhedron, trimesh & heightfield.  These all need testing, but existing examples don't cover all of these.
Updated invert -> inverse for Quaternions (reflecting THREE.js interface change)

Examples all now seem to run cleanly with no errors, but some behaviour issues remain...
Current status:

ammo - OK
cannon - Turning "debug" on reveals that cylinder and cone physics geometries are out by 90 degrees.
compound - Need to test interactions in VR (can't test on desktop)
constraints-ammo - OK
constraints - Need to test interactions in VR (can't test on desktop)
materials - Interactions (force-pushable) don't seem to work (though this works in other examples)
spring - OK
stress- Mostly OK.  Interactions (force-pushable) seem only about 90% reliable?
sweeper - Sweeper bar does not sweep the objects away
ttl - Cylinder physics geometry is rotated 90 degrees vs visible geometry.

Also, some examples use teleport controls, which generates a warning, but there doesn't seem to be a fix available yet.

Geometries out by 90 degrees was an issue with my three-to-cannon v4 updates.  Now fixed.
Remaining issues:
compound - Need to test interactions in VR (can't test on desktop)
constraints - Need to test interactions in VR (can't test on desktop)
materials - Interactions (force-pushable) don't seem to work (though this works in other examples)
stress- Mostly OK. Interactions (force-pushable) seem only about 90% reliable?
sweeper - Sweeper bar does not sweep the objects away
ttl - TTL timer happens for box, but not for cylinder or sphere.  Unclear whether that is expected...?
My latest efforts are published here

More fixes

issues with force-pushable resolved by tightening up raycast targets
added interactivity to compound & constraints

Only remaining issues are:

sweeper - Sweeper bar does not sweep the objects away
ttl - TTL timer happens for box, but not for cylinder or sphere. Unclear whether that is expected...?

For ttl, seems likely this is down to CANNON.js behaviour rather than aframe-physics-system.  Very much doubt there is anything to fix here.  So just need to figure out why the sweeper doesn't work...

Remaining problems with materials & sweeper are due to these examples using "driver: worker".
Using the non-physics driver, both work fine.  I have updated these examples not to use "driver: worker" and will raise a new issue to track getting "driver: worker" fully operational.

repo: c-frame/aframe-physics-system


text:
Change Blocklist store to use different "storage" adapters

Consider the use of some sort of storage adapters for the block list like:
Some could be:
Based on a External storage solution

SQL
BoltDB
Redis
LevelDB

Based on Filesystem storage

JSON (Used currently)
Protobufs

We could also investigate the use of lookup through the storage solution, instead of loading the whole blocklist in memory

github.com/syndtr/goleveldb/leveldb is very fast and manages its own in-memory caching. You could store blocklists in leveldb and query it directly in the DNS query path, rather than storing them in memory or doing your own caching, and this should have very little performance impact compared to typical DNS lookup.

Thanks for your suggestion. I will take a look at it.

authors: c-mueller dichro

repo: c-mueller/ads


text:
Create And Implement Homepage Component - WebiU 2.0

Is your feature request related to a problem? Please describe.
Implement Homepage Component

Hi mahender,
can you assign this issue to me.


text:
fix: change format of enabled linters

Signed-off-by: Tyler Witlin tyler@codezero.io
Description
Changes the format of the enabled linters to enable all of them.
Type of change

[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 not work as expected)
[ ] This change requires a documentation update
[ ] Technical improvement or removal of technical debt.
[x] Minor change: comments, documentation, trivial fixes

How Has This Been Tested?
Please describe the tests that you ran to verify your changes. Provide instructions so we can reproduce. Please also list any relevant details for your test configuration.

[ ] Unit Tests

Optional:

[ ] Functional Tests
[ ] Integration Tests

The way that megaliter parses arguments just requires it to be on one line, or else it doesn't enable any of the linters.


text:
Add Reflect everywhere, use bevy::reflect::TypePath instead of Named

Add Reflect everywhere
I want to add Reflect for several reasons:

it contains some convenience utilities such as getting the variant name of an enum, or in general getting the stable path of a name
it looks like the ecosystem will use Reflection for the editor so it might be a good idea to start using it
it has potential to allow me to split the protocol into multiple pieces, and use reflection, instead of having a giant enum for the MessageProtocol and ComponentProtocol
allows for debugging via bevy_inspector_egui

Still, we have a big breaking change, which is that every protocol-related type (Channel,Message,Input) now need to implement Reflect.
TODO: add reflect for each resource/component and register them
Remove the Named trait
Now that all types are Reflect, we can get rid of the Named trait and just use reflect::TypePath

This is amazing :)
Lmk if u want a review

Closing for now as the Named trait is not needed anymore (the message name is taken from the protocol directly)

authors: Nul-led cBournhonesque

repo: cBournhonesque/lightyear


text:
Possible to add a access control allow origin header?

Hi there,
I have experimented some with your wonderful application, but have an issue that I would like to take up for discussion.
I'm trying to use localroast for mocking API data for one of my applications on localhost, but unfortunately when running it I get a CORS error.
Would it be possible to implement an access control allow origin header? Something like this:
Access-Control-Allow-Origin: *
This would make it possible to use it to mock data in an application running on a different localhost port.
Thanks in advance!

@jenseo This is now implemented in v0.4.0. I hope it helps.

authors: caalberts jenseo

repo: caalberts/localroast


text:
Update rooms.json

Moved SSF to the garden and updated the cemetery to remove the YT embed

These descriptions are all from Pride. They need to be for October. Isn't there a document with room descriptions somewhere? If not, I can rewrite them, but these can't be Pride

authors: LadyAbigor kacycrider

repo: cabinweekend/jitsi-party


text:
Expand GitHub Actions docs into a full guide

Notably, this mentions how to run multi-line run commands inside a devenv shell, which addresses a question I saw on our Discord.

Not sure what Cloudflare Pages is so upset about 🤔

The Cloudflare issue should be fixed in #827.

repo: cachix/devenv


text:
Review Front-End Optimization - Part #1: Overall Improvements

can we remove jquery?
what else can we remove?
add autoprefixing? (via gulp)
pre & postcss? csso? (via gulp)
create dist/ folder for production (use gulp)
html, image, & css minification and optimization (via gulp)

Which of these will help us build features faster? Because we should optimize for that first.

@tdooner an api ;)

Touché

authors: jnmarcus tdooner

repo: caciviclab/disclosure-frontend-alpha


text:
UrlGenerator could not be converted to string

laravel 5.2
Caffeinated\Themes\Themes.php online 378
Solution : https://github.com/laravel/framework/issues/11479
change url() to url('/')

+1 Fixed the problem for me :)

I guess it's fixed in https://github.com/caffeinated/themes/pull/36

Yup, thanks for catching this @UnderlineWords

repo: caffeinated/themes


text:
Server Side Progress Bars

Display information about transfers in real time instead of after the transfer is complete.

Implemented by b18a7f249ed3f51a9ce3f7b3e48e2eaff5f5a78f 6364aa1f2e6382b4c08d3fb1a7ffdbb11251a0c7 and 8dba8d3cb7be470cbc6144a0f064e8e74f45a3cf.

repo: caffinatedmonkey/dnd


text:
Simple arrow animation suggestion

@xjensen
https://github.com/cagov/design-system/issues/640

Although the original issue said to use an 'X" icon, I was wondering if it would make more sense to use a up / down arrow animation (my PR has this up / down animation for reference)? The up / down arrow seems to be used already for drop downs when there is a full row present whereas the only time I see the "X" icon used in a dropdown is in the "Menu" where it goes from a hamburger icon to an "X". The "Menu" on the top right though is a button whereas the "Components" dropdown is a full row.
If the "X" makes more sense, I was also wondering where I can find the "X" icon itself? It looks like the arrow is drawn using a   tag but I couldn't find the equivalent for the "X". Also I was wondering if someone could explain how the "X" animation works? I believe I found it in the "hamburger-inner" tag in but was confused as to how it turns into the "X" and if I would need to do something for the arrow -> "X" transition?

@kmbrlygl - can you take a look and see if the proposed up/down arrow would be a better alternative to the X (close) icon in the page menu.

Thanks for looping me in. For the specific components menu, I think that makes sense and is similar to the interaction inside our overall site menu when you tap on "Style guides" (not the menu itself, the sub-menu that appears under "Style guides").
Semi-related, but our new accordion design uses a right arrow/down arrow to open and close the accordion (see #712). I don't think it needs to be the exact same here, but using the arrows feels like the right direction and will help make our visual language a little more consistent.

Sweet thanks for the feedback!

Looks good!

Seeing if I can switch the base in order to include this in the next release (around beginning of June)
Q: Is there an issue this pertains to?
Sounds like there is a change in close buttons. Anything else I should know as Release Ranger?

authors: alexhu00 chachasikes kmbrlygl timothyshambra xjensen

repo: cagov/design-system


text:
[feature] Improve the performance when saving/exporting the model

Is this a BUG REPORT or FEATURE REQUEST?:

Uncomment only one, leave it on its own line:
/kind bug
/kind feature

What happened:
Using config file: /home/gaocegege/.ormb/config.json
Using /home/gaocegege/.ormb as the root path
ref:       localhost:5000/machinelearning/onnx-model:v1
digest:    a575cb4d62801c295caea441b2e431867148a82718c53551425c8beac8fcaf99
size:      28.9 MiB
format:    ONNX
v1: saved

Currently, Saving an 30M ONNX example takes about 30s.
Showing nodes accounting for 43.26s, 96.37% of 44.89s total
Dropped 93 nodes (cum <= 0.22s)
Showing top 10 nodes out of 50
      flat  flat%   sum%        cum   cum%
    28.96s 64.51% 64.51%     28.96s 64.51%  runtime._ExternalCode
     4.61s 10.27% 74.78%      4.61s 10.27%  racecall
     3.90s  8.69% 83.47%     13.36s 29.76%  compress/flate.(*compressor).deflate
     2.04s  4.54% 88.02%      2.04s  4.54%  racecalladdr
     1.33s  2.96% 90.98%      1.33s  2.96%  runtime.raceread
     0.73s  1.63% 92.60%      1.85s  4.12%  compress/flate.(*huffmanBitWriter).writeCode
     0.71s  1.58% 94.19%      1.03s  2.29%  compress/flate.(*compressor).findMatch
     0.35s  0.78% 94.97%      0.71s  1.58%  compress/flate.hash4 (inline)
     0.34s  0.76% 95.72%      0.34s  0.76%  runtime.racewrite
     0.29s  0.65% 96.37%      0.29s  0.65%  crypto/sha256.block

We should optimize it.
What you expected to happen:
How to reproduce it (as minimally and precisely as possible):
Anything else we need to know?:

Ref https://stackoverflow.com/questions/53188616/runtime-externalcode-cpu-usage-is-too-high-up-to-80

It is weird. When we disabled the CGO:
Showing nodes accounting for 2280ms, 88.72% of 2570ms total
Dropped 57 nodes (cum <= 12.85ms)
Showing top 10 nodes out of 64
      flat  flat%   sum%        cum   cum%
     840ms 32.68% 32.68%     2120ms 82.49%  compress/flate.(*compressor).deflate
     380ms 14.79% 47.47%      380ms 14.79%  compress/flate.(*compressor).findMatch
     310ms 12.06% 59.53%      310ms 12.06%  crypto/sha256.block
     200ms  7.78% 67.32%      390ms 15.18%  compress/flate.(*huffmanBitWriter).writeTokens
     140ms  5.45% 72.76%      190ms  7.39%  compress/flate.(*huffmanBitWriter).writeCode
     130ms  5.06% 77.82%      140ms  5.45%  compress/flate.(*huffmanEncoder).bitCounts
     100ms  3.89% 81.71%      120ms  4.67%  sort.doPivot
      60ms  2.33% 84.05%      400ms 15.56%  compress/flate.(*huffmanBitWriter).indexTokens
      60ms  2.33% 86.38%       60ms  2.33%  compress/flate.hash4
      60ms  2.33% 88.72%       80ms  3.11%  sort.insertionSort

I am not sure why there is a huge difference between the two tests.

@simon-cj Can you also try on macOS?
time ./bin/ormb save ./examples/ONNX-model test

I am trying to check if there is any data race.

Ref https://groups.google.com/g/golang-nuts/c/uytOgKskQdg

@simon-cj Can you also try on macOS?
time ./bin/ormb save ./examples/ONNX-model test

on MacOS,the result as following:
Using config file: /Users/caicloud/.ormb/config.json
Using /Users/caicloud/.ormb as the root path
ref:       test
digest:    70e6cccaae9ed383562bfa6c8f8797eca133e5e1c8a6b4fe3055184eb828ddd2
size:      28.9 MiB
format:    ONNX
: saved
./bin/ormb save ./examples/ONNX-model test  39.41s user 0.80s system 94% cpu 42.488 total

the CPU is high too on MacOS.

It is strange. Most time is spent on native shared libraries. I will have a deep dive into it.
Currently, we can solve it by CGO_ENABLED=0

Confirmed by @hezhizhen that it is not from cgo, it is from race detection instead.

authors: gaocegege simon-cj

repo: caicloud/ormb


text:
undefined method `each'

Do I have a versioning issue?  I'm getting the following message when attempting to run this:
slack-timezone-converter.rb:44:in ': undefined method each' for nil:NilClass (NoMethodError)

Re-cloned, problem fixed... not sure why.

repo: caiosba/slack-timezone-converter


text:
Archive support

One thing i always hated was archive support in Windows /Linux .. a lot of ( non IT literate ) people really struggle with archives and a a UI should take care of it .
I have even blogged about it .
http://www.shanghai-software.com/blog/archive/2010/05/13/why-do-we-need-to-deal-with-archives.aspx

Cairo uses the existing Windows archive support and there are no plans to change this.

authors: bklooste cairoshell

repo: cairoshell/cairoshell


text:
GH2728: Add dotnet nuget source commands

Fixes #2728.

@devlead okay, I'll have a look and fix them.

@devlead rebase off develop tip (as at ~40m ago) was sufficient.

@gitfool  your changes have been merged, thanks for your contribution 👍

authors: devlead gitfool

repo: cake-build/cake


text:
🛑 xmr-node.cakewallet.com:18081 is down

In 0a55178, xmr-node.cakewallet.com:18081 (xmr-node.cakewallet.com) was down:

HTTP code: 0
Response time: 0 ms

Resolved: xmr-node.cakewallet.com:18081 is back up in 593965c after 6 minutes.

repo: cake-tech/upptime-cakewallet


text:
Fix date format so it works when mssql is not configured in us-english.

We cannot run migrations due to problems with date format in the phinxlog table. We use mssql with spanish date format: "dmy". Phinx always use the format 'Y-m-d H:i:s' which is not recognized by mssql with this configuration. Our change sets a date format in the SqlServerAdapter that is always recognized by mssql, regardless language configuration.
Environment:
PHP 5.4.45
SQL Server 2012

Closing this due to age, conflicts and no response from author. Please open a new Issue if you would like this re-opened.

authors: JayPHP hermesti

repo: cakephp/phinx


text:
Collision with component name property for render method view

https://github.com/calebporzio/livewire/commit/8d0137fa7919a6b4b3babf6245c044fcb524046e#diff-c694a29ec41709ca1a5f5e8a29f6467eR45
This line performs a check to either use the $this->name property or build a name from the class name. This results in a collision with components that have a property called name like contact forms or user editing forms.
<?php

namespace App\Http\Livewire;

use Livewire\Component;

class UpdateContactInformation extends Component
{
    /** @var string */
    public $name;
}

With this code you can start typing in a name in an input and an error modal will pop up that will tell you something to the effect of View [value of $name] doesn't exist.
My first idea for a solution would be to create a method like getName() that developers can use to apply a custom name to their component instead of relying on a base $name property which will commonly be overwritten by various components.

I think that's a great solution - is this something that you could PR?

Done in https://github.com/calebporzio/livewire/pull/131

authors: calebporzio faustbrian

repo: calebporzio/livewire


text:
🛑 calgo-lab.de is down

In ccca25c, calgo-lab.de (https://calgo-lab.de) was down:

HTTP code: 0
Response time: 0 ms

Resolved: calgo-lab.de is back up in aee9e59 after 16 minutes.

repo: calgo-lab/uptime


text:
Invariant Violation: addComponentAsRefTo(...)

I get this error with the latest react (0.13.1) (I am probably doing something dumb)
my html looks like this:
<!doctype html>

My js looks like this (before it's compiled by browserify):
var React = require("react")
var mui = require("material-ui")
window.React = React
var Foo = React.createClass({
  displayName: "Foo",
  render: function () {
    return React.createElement("div", {},
      React.createElement(mui.FlatButton, {label:"primary"})
    )
  }
})
window.Foo = Foo

I get this error though:
Uncaught Error: Invariant Violation: addComponentAsRefTo(...): Only a ReactOwner can have refs. This usually means that you're trying to add a ref to a component that doesn't have an owner (that is, was not created inside of another component's render method). Try rendering this component inside of a new top-level component which will hold the ref.
ps. Material-ui looks awesome.

I'm running into this issue as well. Seems to be happening with many of the components.

I had to end up downgrading to an older version of material-ui. This is the one library that's keeping me from upgrading to React v0.13 :disappointed:

Same issue here :(

me too ... Im going to have to dump material-ui i need 0.13 bad

Make sure you don't have multiple React versions bundled/used at the same time - this error message is the default one when having React collisions it seems. I'm using React v0.13.2 and v0.7.4 of MaterialUI (latest in npm) successfully.
As an example I had a shim for React in my browserify config, but the bundle contained the React version shipped with material-ui because the shim wasn't set to be global.

:+1: @omg-a-bear

Thanks @omg-a-bear

:tada: I had forgotten to add externalify to` app.browserify.options.json (Meteor)

I encountered this issue too, after rebuilding material-ui source with my new code added. the React required inside the node_modules/material-ui was different version from React I am using in master project.

@plantvsbirds agree. The same issue here, and generally that alpha is requiring React 14+ and the beta is requiring the React 15+
In general, it's a pain in the ass as my whole project is based on the React 14 and I have to down-grade the material-ui to make this working back.
.... everything was ok, until I had to reinstall whole node_modules. Someone has broken the versioning hardly by going from alpha to beta with react 15. Huge PITA ;-)

@przeor - what does your dependancy look like?

Ran into this ... rm -r node_modules and then npm install fixed it for me.

authors: TimothyKrell alexmchardy andrewmclagan drewlesueur fredericgrati hai-cea mbrookes nickradford omg-a-bear plantvsbirds przeor

repo: callemall/material-ui


text:
[Popover] Add missing animated=false

This PR changes two things: <Popover animated={false} /> was not respected, it is now displayed as <Paper> if open, and null if closed. It also removes the if (!Animation) case because Animation defaults to PopoverAnimationDefault if it is false.

@zalmoxisus It should address one of your issue with the DropDownMenu.

I'm not entirely sure I can add a test for that, since RenderToLayer uses unstable_renderSubtreeIntoContainer to render outside of the React flow (ie, <RenderToLayer /> always appears empty to Enzyme).

authors: nathancahill oliviertassinari


text:
Add tenfold's customizations and notes to Nami latest version

callinize/callinize-node-server#9358
The issue was happening because Asterisk 13 uses AMI version greater than 2 and the version of the library we're using right now has a regex blocking the AMI version. The latest version of the library has it fixed. The regex is located in the file src/nami.js#L61.

Old version: this.welcomeMessage = "Asterisk Call Manager/(1\\.[0-3]|2\\.\\d\\.\\d)" + this.EOL;
New version: this.welcomeMessage = "Asterisk Call Manager/.*" + this.EOL;

The other thing that changed was the logger. In the version we're using someone hardcoded the logger inside of the library to use our logger:

var logger = require('../../../logger');

The new version has an implementation to receive it amongst its parameters, which is easier and a better approach. So, in the PR to upgrade the version on callinize/callinize-node-server I'll also update the current code to pass the logger strategy as a parameter.
Other than that, the other changes are copies from the customized version we're using (even the comments). The library update also brings more Actions and flexibility when using some of them.

@kessiler can you review? This is a blocker on a couple installs.

Sean, I already reviewed this. It will go out this weekend.

@rhaylander make the necessary changes to release it on npm before I merge this in master.

Name must be "nami-raw-callinize"

authors: kessiler rhaylander spinegar

repo: callinize/Nami


text:
Micro Apps

Can it be used to develop micro apps without dependancies between them, if so how to do so ?

Yes, you probably want to include some dependencies to be shared like React and React Native. You can configure how you want to include dependencies inside chunks: https://webpack.js.org/plugins/split-chunks-plugin/#optimizationsplitchunks

@zamotany it would be great if this repo has an example for such usecase.

Closing this due to inactivity. If you want to provide more info or an example with "micro app" concept implement feel free to open a new issue and a PR :)

authors: RafikiTiki ramzitannous zamotany

repo: callstack/repack


text:
WIP: Add dimensional and type data to yxi outputs

This PR adds memory-type (Sequential or Combinational) data, explicit dimensionality sizes and idx sizes, and makes yxi look for both @external memories and ref memories (before it was limited to just @external memories).
I would be happy to hear any thoughts on the naming of the information output, or if there is something we wanted to be output that is being missed @ayakayorihiro.
Currently a draft because this doesn't compile correctly with a normal cargo build.
This is because the yxi backend is not gated behind any feature flags, but relies on calyx-ir/utils to have access to serde, which is gated behind --features serialize. So I guess we can either gate yxi behind --features serialize or --features yxi or remove the gating of serde in calyx-ir/utils. It might be worth noting that the yxi backend already has a non-gated dependency on serde. Dunno if that's the way things should be.
cc @rachitnigam @EclecticGriffin Any thoughts on best way to proceed with the feature gating issue?

wrt feature gating, I think that the simplest option might just be to add an yxi feature (which itself depends on serialization) and so consequently doesn't compile the axi backend if the feature is not given. I think this is reasonable and how other crates handle this type of stuff in practice, but if we don't want to add another feature then I guess the entire axi backend needs to be behind the serialization feature. I suppose they're both identical.
I prefer one of the above over making the axi backend a no-op when the serialization feature is not used since that seems needlessly confusing

I think we should eventually move AXI out of thr compiler and mame it a standalone tool

Sorry for the late reply on this, the new JSON fields are great!! This should be all the info I need for my testbench creation script :slightly_smiling_face:

I think the dependencies look better now, could either/both of you confirm? @EclecticGriffin @rachitnigam
The yxi backend now only gets compiled with a cargo build --features yxi

Most changes seems fine except the one comment I left. Overall, I'd like for YXI to be a separate tool from the Calyx compiler because it doesn't need the rest of the optimization infrastructure.

Thanks for taking a look.
I think I'd need a bit of guidance on how to start migrating YXI out of the compiler, could maybe talk about this synchronously/on slack? My main concern is the fact that YXI currently relies on the IR to get information about memories. Would YXI just be standalone with dependencies on the IR? Not exactly sure what that looks like in practice.

authors: EclecticGriffin ayakayorihiro nathanielnrn rachitnigam

repo: calyxir/calyx


text:
Add parallax to home page

Closes issue #13.

Add parallax to home page

This PR was closed because it don't work for some elements.


text:
Change the description on the readme so that it is clear the bot is general purpose

The description on the README.md would have someone believe the bot is only intended for the UFCC discord and not general purpose. I'm proposing we change the wording so that it instead says something like "in use on UFCC discord" instead "for UFCC's discord". Maybe even state specifically that it is general purpose.

I can look into this. I can change up the wording so it makes it clear that it is general purpose and could be used for any chat room, and it is use on the FCC chat in specific.

Fixed up everything in the pull request so I closed it

repo: campDevs/DiscordBot


text:
Add management of udev objects

With udev part of systemd these days, it is handy to have a place to set custom udev rules (for folks that need that like me).

Almost there 😁

Almost there 😁

My local PDK seems to be b0rked, so I'll have to rely on travis to validate my tests for now.

My local PDK seems to be b0rked, so I'll have to rely on travis to validate my tests for now.

Now we wait…
I'll tackle the migration to GH Actions soon(-ish).

Now we wait…
I'll tackle the migration to GH Actions soon(-ish).

I think travis is happy again.

authors: jcpunk raphink

repo: camptocamp/puppet-systemd


text:
Camunda bpmn with mockbean, not detecting Java class instance

I have written bpmn flow. This BPMN just contains Service Task. This service task is implemented by Java Class   ServiceInstantiationFeasibilityReqToSLODelegate.
Below code works fine without mock.
@RunWith(SpringRunner.class)
@SpringBootTest
@ContextConfiguration(locations = "/applicationContext_forNetworkSlicing.xml")
public class InputValidationTest {
@Autowired
private RuntimeService runtimeService;

@Autowired
@Rule
public ProcessEngineRule processEngineRule;

private static MsoLogger LOGGER = MsoLogger.getMsoLogger(MsoLogger.Catalog.GENERAL, HandleUnexpectedError.class);

@Test
@Deployment(resources = {"process/ProcessServiceInstantiationFeasibility.bpmn"})
public void validateIncomingReq() {
    // given
	BpmnAwareTests.init(processEngineRule.getProcessEngine());
    Map<String, Object> variables = new HashMap<>();
    variables.put("id","42");
    variables.put("href","http://serverlocation:port/orderManagement/serviceOrder/42");

    // when
    ProcessInstance instance = runtimeService
            .startProcessInstanceByKey("ProcessServiceInstantiationFeasibility", "businessKey", variables);

    // then
    BpmnAwareAssertions.assertThat(instance).isEnded().hasPassedInOrder(
            "StartEvent_Feasibility",
            "ScriptTask_ValidateIncomReq",
            "ServiceTask_call_SLO",
            "ServiceTask_ServInstanceFeasCompletion",
            "EndEvent_Feasibility"
    );
}

}
@Component
public class ServiceInstantiationFeasibilityReqToSLODelegate implements JavaDelegate {
private static MsoLogger LOGGER = MsoLogger.getMsoLogger(MsoLogger.Catalog.GENERAL, ServiceInstantiationFeasibilityReqToSLODelegate.class);
private static final String LOGMARKER = "[NETWORK-SLICE-FEASIBILITY-CHECK]";
public void prepareServiceInstantiationFeasibility(DelegateExecution execution) {
execution.setVariableLocal("statusCode", true);
}
public void sendRequestToSLO(DelegateExecution execution) {
//rest call
}
@Override
public void execute(DelegateExecution execution) throws Exception {
LOGGER.info(LOGMARKER + "==ServiceInstantiationFeasibilityReqToSLODelegate==");
  prepareServiceInstantiationFeasibility(execution);

  sendRequestToSLO(execution);

}
}
If I want to mock class ServiceInstantiationFeasibilityReqToSLODelegate as MockServiceInstantiationFeasibilityReqToSLODelegate , I have declared as below:
@MockBean
private MockServiceInstantiationFeasibilityReqToSLODelegate serviceInstantiationFeasibilityReqToSLODelegate;

During execution, it is not detecting Java Class instance. Means MockServiceInstantiationFeasibilityReqToSLODelegate .execute(...) is not getting called. Content of ServiceInstantiationFeasibilityReqToSLODelegate and MockServiceInstantiationFeasibilityReqToSLODelegate  are same.
How to fix this??

Now I have modified to add doAnswer() as below:
		doAnswer((i) -> {
			i.callRealMethod();
			return null;
		}).when(serviceInstantiationFeasibilityReqToSLODelegate).execute(any(DelegateExecution.class));

        ProcessInstance instance = runtimeService
                .startProcessInstanceByKey("ProcessServiceInstantiationFeasibility", "businessKey", variables);

Now MockServiceInstantiationFeasibilityReqToSLODelegate .execute(...)  is getting called. But whatever set variable "statusCode" is not visible to Gateway.
16:46:54.011 [main] ERROR org.camunda.bpm.engine.context - ENGINE-16004 Exception while closing command context: Unknown property used in expression: #{statusCode}. Cause: Cannot resolve identifier 'statusCode'
org.camunda.bpm.engine.ProcessEngineException: Unknown property used in expression: #{statusCode}. Cause: Cannot resolve identifier 'statusCode'
at org.camunda.bpm.engine.impl.el.JuelExpression.getValue(JuelExpression.java:60)
Please help me to fix this.

execute() method is not calling prepareServiceInstantiationFeasibility() in mocking case. Anyone knows why this issue? Without mocking, it calls.

Hi @maheshps-huawei ,
Please do not create issues here.
Could you please post this in the forum - https://forum.camunda.org/

since the only isssue left here is the "auto" history level ... shouldn't we just move/close  it  and disable issues on repo for good?

Hi @jangalinski,
I agree. I will take care.

repo: camunda/camunda-bpm-spring-boot-starter


text:
DMN XML not correctly updated when changing IDs of Tables

Describe the Bug

When changing IDs of Tables in a DMN, the relations get lost on the diagram but remain in the XML.
Steps to Reproduce

Expected Behavior

When changing the IDs of an element, all relations get updated correctly.
Environment

Camunda Modeler Version: all versions

Related to SUPPORT-7040

This popped up in support. I linked relevant support case in issue description

@barmac Is there a chance that we can backport this to dmn-js@7.x?

@barmac Is there a chance that we can backport this to dmn-js@7.x?

We can do that.

authors: barmac michaldytko nikku

repo: camunda/camunda-modeler


text:
Keep positions of Boundary Events and edge waypoints when resizing a Sub-Process

The expected result would have been:

Closed via https://github.com/camunda/camunda-modeler/commit/79dc1a4e218ac9eabbfc3d1d585821fb12c7a297.

authors: falko nikku


text:
Add a feedback option

options: email, add an issue to the repo

This is in the blue banner at the top of each page.

repo: canada-ca/devex-pages


text:
Remove references to "program" on the New Team page

Hi @markwooff !  Just noticed these mentions of Program in the +New Team page.....

Quick one to fix :) this has now been updated.

authors: RachelMuston markwooff

repo: canada-ca/devex


text:
YAML linting and formating

The current YAML format was linted using the following service and follows it's conventions
http://www.yamllint.com/
When PRBot submits a change it's rewriting the whole file in a different format and that makes it hard to see what changes were made to the files.
Possible solutions:

Re-lint the YAML before sending it through PRBot
Update current YAML files to match format used by PRBot

Hi, we can use a linter for YAML files. I found this script:  https://github.com/adrienverge/yamllint,, we can writing a custom configuration file with our rules , https://yamllint.readthedocs.io/
I created a PR that shows how we can use this script, Add linter for YAML files #234. https://github.com/canada-ca/ore-ero/pull/234

@smellems I'll also work to see if I can figure out how to change the formatting of the YAML writer. I can't seem to find a good browser-supporting YAML parsing library. The one I've got has bare bones documentation. I'll dig deeper and work with @WJXHenry to get this resolved.

YamlLint was added to the build.  Not sure if it could also reformat the YAML.. but I guess reformatting (linting) would have to be done by CanadaBot

YAML formatting was updated for all files but it still does not match when an update is submitted using the form.
I only updated my email in #523

My latest pull request should take care of this. @imadeDev and I went through all the files to adapt them to how jsyaml format files, so when it's merged, this should be resolved. There's also different format we can pass to the jsyaml object config (when using the dump method), but I think it's safer to use the default version and adapt around it than the other way around.

Additionally, @j-rewerts mentionned that if it happens again, it might come from a known issue of PRB0T when it's not updated its own fork, creating a divergence between the pull request and master. One workaround is to manually delete PRB0T forked repo, so it force it to refork from master and not use its current outdated version.
There's two issues regarding this:
https://github.com/PRB0t/PRB0t/issues/45
https://github.com/PRB0t/PRB0t/issues/25
But otherwise it shouldn't be an issue anymore

authors: fredericlestage-vdm imadeDev j-rewerts smellems

repo: canada-ca/ore-ero


text:
🛑 Ubuntu.com smart start guide is down

In d538112, Ubuntu.com smart start guide (https://ubuntu.com/smartstart/guide) was down:

HTTP code: 503
Response time: 75 ms

Resolved: Ubuntu.com smart start guide is back up in c30db76.

repo: canonical-web-and-design/upptime


text:
feat: expose loki retention-period config

Issue
Currently the cos-lite-bundle does not offer any way to configure Loki retention.
Solution
Charm loki-k8s-operator offers since few months ago a new config key named retention-period that allows to configure Loki to the specified retention and activates the compactor in Loki. It'd be great if we can expose this setting in the cos-lite-bundle.
Context
When deploying the bundle, an operator typically wants some retention policy for the logs, and as the bundle is currently there is no way to configure any.
Testing Instructions
Render the bundle with loki_retention_period=30.
Observe Loki configuration to contain these two settings:
retention_enabled: True

and in the limits_config there should be
retention_period: 30d

Adjusted ruff syntax
It was not in the scope of this PR but for the linter in the CI to work I fixed the ruff syntax, which now expects the keyword check after ruff and before the path. Let me know if you prefer I do that in a separate PR.

Close after discussing with @ca-scribner the goal of the bundle is showcase a light-weight COS deployment. I think nevertheless is very informative to have an example extra setting.

repo: canonical/cos-lite-bundle


text:
After changing nagios_host_context in nrpe related to cos-proxy, the old check names are still present in nrpe_lookups.csv

Bug Description
After changing nagios_host_context in nrpe related to cos-proxy, all nrpe targets are re-added to nrpe_lookup.csv with the updated names. Old checks, however, can still be found there.
To Reproduce

Deploy cos-proxy and nrpe, relate them using the monitors relation
Wait for the model to settle, inspect nrpe_lookup.csv contents
Change nrpe config:

juju config nrpe-container nagios_host_context=bootstack-test

Wait for the model to settle and check nrpe_lookup.csv. New (the same but updated) checks with "bootstack-test" prefix will show up in the juju_unit column, but the old entries without the prefix will be still there.

Environment
rev 46 of cos-proxy, I didn't try to reproduce in rev 47 yet
Relevant log output
It's the same env that was reported in #88.

Additional context
No response

Thanks @przemeklal.
Can you tell if this is a regression due to #89?
I.e. was config change reflected correctly in the csv prior to this recent change?

It was there before #89.
Another observation is that if an entry for a juju unit was missing there with the old nagios_host_context, it's also missing among the updated entries, e.g.

searching for glance/2 check_reboot entries (there are 3 instances after 2 config changes)

grep glance\/2 nrpe_lookup.csv | grep check_reboot

10.169.10.80_check_reboot,glance,glance/2,check_reboot,10.169.10.80
10.169.10.80_check_reboot,bootstack-redacted-context-1-glance,bootstack-redacted-context-2-glance/2,check_reboot,10.169.10.80
10.169.10.80_check_reboot,bootstack-redacted-context-2-glance,bootstack-redacted-context-2-glance/2,check_reboot,10.169.10.80

searching for glance/0 - it doesn't exist with any context (issue #88)
root@juju-e9cbb4-3-lxd-6:/etc/vector# grep glance\/0 nrpe_lookup.csv | grep check_reboot
root@juju-e9cbb4-3-lxd-6:/etc/vector#

Input from @przemeklal :
graph LR
cos-proxy --- |monitors| nrpe
glance ---|nrpe_external_master| nrpe

glance is an app monitored by nrpe
for each nrpe check, cos-proxy needs to add a line to the csv file
nrpe charm has a config option, nagios_host_context, which sets a prefix to identify the particular cloud the particular glance target is coming from.
after config changed (from no prefix to some prefix), cos-proxy appended the lines to the csv file instead of replacing the old targets. Every time this config option changes, a new line is appended while the old ones are still kept there.
need to look at the monitors relation changed handler and see how the csv is generated.

authors: przemeklal sed-i

repo: canonical/cos-proxy-operator


text:
Fix integration tests (make -> tox)

The Makefile was removed, so we must use tox directly here now.

Manually running the tests: https://github.com/canonical/hardware-observer-operator/actions/runs/10986372682  It seems these tests are not auto run for PRs.

repo: canonical/hardware-observer-operator


text:
Switch Loki to use the ROCK on ghcr.io

Issue
We are currently running Loki using the upstream OCI image.
Solution
We are now building our own ROCKs for the observability stack. We should also make sure we're using them so that effort is not in vain.
Testing Instructions

Deploy the charm with the new resource
Verify functionality is still there

Release Notes
Switch from upstream OCI image to ROCK

Maybe the API changed.
Maybe we need image tests on the rock repo for any api call we use in the charm.

Maybe the API changed. Maybe we need image tests ~on the rock repo~ for any api call we use in the charm.

Seems the API did not change, it is a Loki bug:
root@loki-0:/usr/bin# loki -version
loki, version  (branch: , revision: )
  build user:
  build date:
  go version:       go1.19.6
  platform:         linux/amd64

You're correct, @Abuelodelanada. This is what we're lacking in the ROCK currently:
https://github.com/grafana/loki/blob/8b8d2ca382d29c0d5612dee956dfe48ae2b51d10/Makefile#L50-L51

Already fixed last week. New build already has it:
❯ podman run --rm -it  ghcr.io/canonical/loki:latest -- /usr/bin/loki -version
loki, version 2.7.4 (branch: HEAD, revision: 98421b0c0)
  build user:       root@rockcraft-loki-1364396
  build date:       2023-03-16T08:39:26Z
  go version:       go1.19.6
  platform:         linux/amd64

authors: Abuelodelanada rbarry82 sed-i simskij


text:
[DPE-4401] Add retention time for full backups

Issue
Link to issue: https://warthogs.atlassian.net/browse/DPE-4401
Link to spec: https://docs.google.com/document/d/1WWMt_Q71cUIrpfYirp5TRCdkJXMjFSWCH6CTnKrO4YA/edit
The parameter delete-older-than-days (from s3-integrator) is used to set up retention time (in days) as a pgBackRest parameter, allowing for uses to configure a retention policy for their backups.
Solution

Fetches delete-older-than-days parameter from S3-integrator relation data.
Includes data_platform_libs patch from https://github.com/canonical/data-platform-libs/pull/168
Set pgBackRest parameters repo1-retention-full and repo1-retention-full-type=time
Modifies unit tests to check for a retention time in days.

Testing

Tested locally,
Unit tests assures delete-older-than-days is correctly fetched from s3 parameters,
Still in discussion about how to proceed about integration testing this feature.

I'll go ahead and merge this, regarding the test_backups.py stability, I have two follow-up tickets to investigate them further, as it is out of scope of this change. Thanks!


text:
test-branch/execute-job/comment-from-wrong-user-on-pr/8a35d656-f5cf-4d8e-ac3e-4967259ae08e

PR for testing 9d3f9cdcf3605127bc4c5d1fe5479fed227071ca

/canonical/self-hosted-runners/run-workflows 9d3f9cdcf3605127bc4c5d1fe5479fed227071ca

repo: canonical/repo-policy-compliance-tests


text:
test-branch/execute-job/fork-branch/ae0f8803-30ac-46bd-bee0-91c8679a09f9

PR for testing ed5649dc6429c52310023a7a3d197bbe296e2701

padding /canonical/self-hosted-runners/run-workflows ed5649dc6429c52310023a7a3d197bbe296e2701 padding

repo: canonical/repo-policy-compliance


text:
execute-job/wrong-commit-sha-on-pr/0a8ca4c1-f673-4f1d-8e6a-362452a728b6

PR for testing 823165e8ad64868a7f01e8f651d45bd7b1fafb2b

/canonical/self-hosted-runners/run-workflows a556329d0f19affa608643d746ee6f7c818c627b


text:
WIP: bump Seldon ROCKs version 1.15.x -> 1.17.1 for release 1.8

This PR updates Seldon ROCKs from Seldon version 1.15.x to 1.17.1. The process has been thoroughly documented in the issue below and reviewer may consult it about details.
Closes #37

Moving this PR to https://github.com/canonical/seldonio-rocks/pull/46

Moving this PR to https://github.com/canonical/seldonio-rocks/pull/46

repo: canonical/seldonio-rocks


text:
tempo integration with prometheus is bork

Bug Description
tempo coordinator errors out on relation to prometheus
To Reproduce
juju relate tempo prometheus
Environment
microk8s on top of openstack on top of multipass
(good luck)
Relevant log output
unit-tempo-0: 12:48:47 WARNING unit.tempo/0.juju-log metrics-endpoint:38: 'source_url' should start with a scheme, such as 'http://'. Assuming 'http:/
/' since none is present.
unit-tempo-0: 12:48:47 ERROR unit.tempo/0.juju-log metrics-endpoint:38: Uncaught exception while in charm code:
Traceback (most recent call last):
  File "/var/lib/juju/agents/unit-tempo-0/charm/./src/charm.py", line 390, in <module>
    main(TempoCoordinatorCharm)
  File "/var/lib/juju/agents/unit-tempo-0/charm/venv/ops/main.py", line 551, in main
    manager.run()
  File "/var/lib/juju/agents/unit-tempo-0/charm/venv/ops/main.py", line 530, in run
    self._emit()
  File "/var/lib/juju/agents/unit-tempo-0/charm/venv/ops/main.py", line 519, in _emit
    _emit_charm_event(self.charm, self.dispatcher.event_name)
  File "/var/lib/juju/agents/unit-tempo-0/charm/venv/ops/main.py", line 147, in _emit_charm_event
    event_to_emit.emit(*args, **kwargs)
  File "/var/lib/juju/agents/unit-tempo-0/charm/venv/ops/framework.py", line 348, in emit
    framework._emit(event)
  File "/var/lib/juju/agents/unit-tempo-0/charm/venv/ops/framework.py", line 860, in _emit
    self._reemit(event_path)
  File "/var/lib/juju/agents/unit-tempo-0/charm/venv/ops/framework.py", line 950, in _reemit
    custom_handler(event)
  File "/var/lib/juju/agents/unit-tempo-0/charm/lib/charms/prometheus_k8s/v0/prometheus_scrape.py", line 1527, in set_scrape_job_spec
    self._set_unit_ip()
  File "/var/lib/juju/agents/unit-tempo-0/charm/lib/charms/prometheus_k8s/v0/prometheus_scrape.py", line 1572, in _set_unit_ip
    relation.data[self._charm.unit]["prometheus_scrape_unit_address"] = unit_address
  File "/var/lib/juju/agents/unit-tempo-0/charm/venv/ops/model.py", line 1792, in __setitem__
    self._validate_write(key, value)
  File "/var/lib/juju/agents/unit-tempo-0/charm/venv/ops/model.py", line 1760, in _validate_write
    raise RelationDataTypeError(f'relation data values must be strings, not {type(value)}')
ops.model.RelationDataTypeError: relation data values must be strings, not <class 'NoneType'>
unit-tempo-0: 12:48:47 ERROR juju.worker.uniter.operation hook "metrics-endpoint-relation-joined" (via hook dispatching script: dispatch) failed: exit
 status 1
unit-tempo-0: 12:48:47 INFO juju.worker.uniter awaiting error resolution for "relation-joined" hook

Additional context
No response

It's easier to see even without the whole setup-on-setup:

deploy cos-lite first, then deploy tempo-coordinator and tempo-worker
jhack imatrix fill
no profit

It works if you deploy coordinator and worker first and relate them, then add cos-lite and jhack imatrix fill.
It might be an issue with the shared coordinator-worker object.

authors: PietroPasotti mmkay


text:
checks for worker readiness

Issue
Fixes #20
Solution
This PR adds a pebble check that curls localhost:3200/ready and sets status according to the response:
Waiting if the status looks like:
root@tempo-worker-0:/# curl localhost:3200/ready
Some services are not Running:
Running: 16
Starting: 1

and Blocked if any non-2xx code is returned or anything weird happens.

@lucabello we should see if we can generalize this and lift it to Worker

It seems there is a bit of a race condition here. I tried to deploy worker from this branch at 21:26 and ended up having a 503 on the very first healthcheck:
unit-tempo-worker-k8s-0: 21:26:24 WARNING unit.tempo-worker-k8s/0.juju-log tempo-cluster:3: No Loki endpoints available
unit-tempo-worker-k8s-0: 21:26:24 WARNING unit.tempo-worker-k8s/0.juju-log tempo-cluster:3: Could not check the current worker configuration due to a failure in retrieving the file: not-found - stat /etc/worker/config.yaml: no such file or directory
unit-tempo-worker-k8s-0: 21:26:24 INFO unit.tempo-worker-k8s/0.juju-log tempo-cluster:3: Pushed new worker configuration
unit-tempo-worker-k8s-0: 21:26:25 ERROR unit.tempo-worker-k8s/0.juju-log tempo-cluster:3: Error while getting worker status.
Traceback (most recent call last):
  File "/var/lib/juju/agents/unit-tempo-worker-k8s-0/charm/./src/charm.py", line 145, in status
    with urllib.request.urlopen("http://localhost:3200/ready") as response:
  File "/usr/lib/python3.10/urllib/request.py", line 216, in urlopen
    return opener.open(url, data, timeout)
  File "/usr/lib/python3.10/urllib/request.py", line 525, in open
    response = meth(req, response)
  File "/usr/lib/python3.10/urllib/request.py", line 634, in http_response
    response = self.parent.error(
  File "/usr/lib/python3.10/urllib/request.py", line 563, in error
    return self._call_chain(*args)
  File "/usr/lib/python3.10/urllib/request.py", line 496, in _call_chain
    result = func(*args)
  File "/usr/lib/python3.10/urllib/request.py", line 643, in http_error_default
    raise HTTPError(req.full_url, code, msg, hdrs, fp)
urllib.error.HTTPError: HTTP Error 503: Service Unavailable

It has caused the node to show up in juju status as "down", although Tempo was already started (with some hiccups):

2024-08-15T19:26:31.285Z [tempo] level=error ts=2024-08-15T19:26:31.285688811Z caller=frontend_processor.go:67 msg="error contacting frontend" address=127.0.0.1:9096 err="rpc error: code = Canceled desc = context canceled"
2024-08-15T19:26:31.285Z [tempo] level=error ts=2024-08-15T19:26:31.285698547Z caller=frontend_processor.go:67 msg="error contacting frontend" address=127.0.0.1:9096 err="rpc error: code = Canceled desc = context canceled"
2024-08-15T19:26:31.286Z [tempo] level=info ts=2024-08-15T19:26:31.285780279Z caller=compactor.go:127 msg="waiting until compactor is ACTIVE in the ring"
2024-08-15T19:26:31.286Z [tempo] level=info ts=2024-08-15T19:26:31.285794656Z caller=compactor.go:133 msg="compactor is ACTIVE in the ring"
2024-08-15T19:26:31.286Z [tempo] level=info ts=2024-08-15T19:26:31.285802874Z caller=compactor.go:142 msg="waiting until compactor ring topology is stable" min_waiting=1m0s max_waiting=5m0s
2024-08-15T19:26:32.172Z [tempo] level=error ts=2024-08-15T19:26:32.172469447Z caller=rate_limited_logger.go:27 msg="pusher failed to consume trace data" err="empty ring"
2024-08-15T19:26:41.295Z [tempo] level=info ts=2024-08-15T19:26:41.29557041Z caller=flush.go:177 msg="head block cut. enqueueing flush op" userid=single-tenant block=06846c6b-9382-4fe7-8d42-1cf614df877b
2024-08-15T19:26:46.114Z [tempo] level=info ts=2024-08-15T19:26:46.11449179Z caller=flush.go:253 msg="completing block" userid=single-tenant blockID=06846c6b-9382-4fe7-8d42-1cf614df877b
2024-08-15T19:26:46.128Z [tempo] level=info ts=2024-08-15T19:26:46.127827026Z caller=flush.go:260 msg="block completed" userid=single-tenant blockID=06846c6b-9382-4fe7-8d42-1cf614df877b duration=13.358217ms
2024-08-15T19:26:46.128Z [tempo] level=info ts=2024-08-15T19:26:46.128081071Z caller=flush.go:309 msg="flushing block" userid=single-tenant block=06846c6b-9382-4fe7-8d42-1cf614df877b
2024-08-15T19:26:46.287Z [tempo] level=warn ts=2024-08-15T19:26:46.287084878Z caller=pool.go:250 msg="removing distributor_pool failing healthcheck" addr=10.1.157.77:9096 reason="failing healthcheck status: NOT_SERVING"
2024-08-15T19:27:31.286Z [tempo] level=info ts=2024-08-15T19:27:31.286782079Z caller=compactor.go:146 msg="compactor ring topology is stable"
2024-08-15T19:27:31.286Z [tempo] level=info ts=2024-08-15T19:27:31.286877429Z caller=tempodb.go:504 msg="polling enabled" interval=5m0s blocklist_concurrency=50
2024-08-15T19:27:31.297Z [tempo] level=info ts=2024-08-15T19:27:31.29723053Z caller=poller.go:238 msg="writing tenant index" tenant=single-tenant metas=1 compactedMetas=0
2024-08-15T19:27:31.305Z [tempo] level=info ts=2024-08-15T19:27:31.305720935Z caller=poller.go:133 msg="blocklist poll complete" seconds=0.018810101
2024-08-15T19:27:31.305Z [tempo] level=info ts=2024-08-15T19:27:31.305795381Z caller=compactor.go:159 msg="enabling compaction"
2024-08-15T19:27:31.305Z [tempo] level=info ts=2024-08-15T19:27:31.305811069Z caller=tempodb.go:476 msg="compaction and retention enabled."
2024-08-15T19:27:31.306Z [tempo] level=info ts=2024-08-15T19:27:31.305875921Z caller=app.go:214 msg="Tempo started"

After the next update-status hook, so after 5 minutes, everything went to normal.
unit-tempo-worker-k8s-0: 21:31:45 INFO juju.worker.uniter.operation ran "update-status" hook (via hook dispatching script: dispatch)

Will keep it running for the night, check the status and then and try to break s3 config tomorrow morning.

Okay, morning update: node survived the night. I changed s3-integrator config to be invalid to break Tempo and the status is:
16 Aug 2024 09:57:12+02:00  workload   active     (all roles) ready.
16 Aug 2024 10:00:26+02:00  juju-unit  executing  running tempo-cluster-relation-changed hook
16 Aug 2024 10:00:32+02:00  workload   blocked    node down (see logs)

so it's all right. Then I fixed the URL again and after a few minutes node went back to the ready state.

I'mma wait to see if https://github.com/canonical/cos-lib/pull/55 gets merged soon, and in that case drop this pr and go for #22 instead

closing in favor of #22


text:
🛑 mir-server.io is down

In 93ed123, mir-server.io (https://mir-server.io) was down:

HTTP code: 503
Response time: 274 ms

Resolved: mir-server.io is back up in 2b5d063 after 6 minutes.

repo: canonical/upptime


text:
🛑 Snapcraft.io is down

In 854976d, Snapcraft.io (https://snapcraft.io) was down:

HTTP code: 0
Response time: 0 ms

Resolved: Snapcraft.io is back up in d13883f after 18 minutes.


text:
Optimization Method in Solver

Find a better solver for the placement of the buildings.

Merged into master

repo: canoo/code-of-gotham