ci(release): fix releases not being published (fix #284)

Summary
Fixes #284

Changes

Add Set up Indra step to release.yml which creates a tag

Checklist

[x] I acknowledge and agree to the terms of the Developer Certificate of Origin.
[x] All contributed code can be distributed under the terms of the MIT License.
[x] I have read the contributing guidelines and code of
conduct.
[x] I have checked the "Allow edit from maintainers" option.
[ ] I have added appropriate unit tests for my changes.

I decided to name the step "Set up Indra" as #301 will require additional commands to be run, which can be placed in the same step.


keithsstuff

in specto only 2 things that work  when you click on movies people watching and latest movies

fixed

forgetit I got it to work I when to a Bata version  and in stalled it then re downloaded Jarvis16.1 and it now working accept for people watching in specto


Add URI#resolve and URI#relativize

This PR adds two complementary methods to URI:

URI#resolve(uri) resolves uri against self according to RFC 3986 section 5.2.
URI#relativize(uri) relativizes uri against self using query and fragment components from uri and a path component that describes a minimum-difference relative path between the paths of self and uri.

URI.parse("http://foo.com/bar/baz").resolve("../quux")                   # => http://foo.com/quux
URI.parse("http://foo.com/bar/baz").relativize("http://foo.com/bar/baz") # => ../quux`

#7697 contains a similar implementation for URI#resolve called URI#merge

I prefer merge. It's more explicit than resolve which is confusing —what is is supposed to resolve?
It's also explicitly named "merge" and "remove dot segments" in RFC 3986 sections 5.2.3 and 5.2.4. The term "resolve" is never used, even in section 5.2.2.
I had to dig the specs to start to understand what relativise could mean. I don't see any use case. I don't think it's frequent enough to be in stdlib.

The entire section 5 of  RFC 3986 is titled URI resolution and that's the common term for this, also used in many APIs. The RFC only refers to merging of paths.
Calling the entire resolution process merge seems to be a Rubyism. I don't think this is a good name, because it's pretty unspecific. Using the more expressive name resolve is better.

I had to dig the specs to start to understand what relativise could mean.

The docs explicitly state it's the inverse of #resolve.
#relativize is definitely not as commonly used as #resolve, so yeah, it might not fit into stdlib. But it's still useful and complements #resolve. The implementation is already not very complex and  I suppose the implementation of #relativize_path can eventually move to Path because having a similar method on Path would be nice.

@ysbaddaden is the only one suggesting the name merge (and really insisting on it, for whatever reason).
But I think it just doesn't fit. Programmers tend to think of merging as taking the "best" parts of two sequences, possibly by indiscriminately iterating over them.
And that's very misleading in this context because it's explicitly not this type of operation.
resolve makes a lot of sense to me, and @straight-shoota provides good justification as well.

But I think there's a mistake in the original post. The last example seems to be demonstrating relativize but actually calls resolve.

Fixed

I think there is still an issue in the opening comment:
It should probably be:
URI.parse("http://foo.com/bar/baz").relativize("http://foo.com/quux") # => ../quux`

Rebased on master

Rebased onto master.


[core] Batch small changes

[docs] Remove duplicated ids e286a5b: Help with https://validator.w3.org/nu/?doc=https%3A%2F%2Fnext.material-ui.com%2Fcomponents%2Fslider-styled%2F

[breakpoint] Fix NaN value 052a813: Help with https://validator.w3.org/nu/?doc=https%3A%2F%2Fnext.material-ui.com%2Fcomponents%2Fslider-styled%2F

[test] Lowercase to match BrowserStack API results 4741b07: The API: https://www.browserstack.com/docs/automate/api-reference/selenium/browser#get-browser-list
[docs] Use px f7acfbc: To match https://github.com/mui-org/material-ui/commit/8e280c28d5e5b42381cc0a3df2cb2e49ee9a9340#diff-c743b3b575d4f5b5345f50876aedc6c1R114

@oliviertassinari Is there any way this could be included in the stable release as well (particularly 052a813), or would that be against your current release workflow?

@oliviertassinari Is there any way this could be included in the stable release as well (particularly 052a813), or would that be against your current release workflow?

@stefaluc The objective of this commit was to simplify the logic (remove code), not to improve the behavior. doing down('xs') doesn't make sense, as far as I understand it.

@stefaluc The objective of this commit was to simplify the logic (remove code), not to improve the behavior. doing down('xs') doesn't make sense, as far as I understand it.

@oliviertassinari Thanks for the prompt response! I am trying to set custom breakpoints in my application but am receiving NaN values. It looks like I mistakenly assumed this PR as the fix for this issue, when in actuality it looks like https://github.com/mui-org/material-ui/pull/21759 may be the fix I am looking for. So, same question, but with regards to #21759 instead :grin:


Task

@MounikaR8790
Task  - its  empty file check and commit it back to github

@MounikaR8790
#2092 This PR is already approved check the code available in correct folders and make a commit then, raise a new PR mention that number it in tacker

can u plz check
On Fri, Jul 5, 2024 at 4:04 PM krish952-creator @.***>
wrote:

@MounikaR8790 https://github.com/MounikaR8790
#2092 https://github.com/vajrang-b/UiPathIn30Days/pull/2092 This PR is
already approved check the code available in correct folders and make a
commit then, raise a new PR mention that number it in tacker
—
Reply to this email directly, view it on GitHub
https://github.com/vajrang-b/UiPathIn30Days/pull/2092#issuecomment-2210635257,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/BJSUNDSYALQG5AW2XHTTSC3ZKZZDLAVCNFSM6AAAAABKJZPEDCVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDEMJQGYZTKMRVG4
.
You are receiving this because you were mentioned.Message ID:
@.***>


What format should I provide the proxy string as?

I'm having trouble getting caw to work with got, and I'm trying to figure out whether the issue is because of the proxy itself or because of how I'm configuring caw. If my proxy IP is something like <IP_ADDRESS> and port is 555 and it's an HTTPS proxy, should the string argument be exactly https://<IP_ADDRESS>:555, or does it expect it in a different format?

Also would there any difference in how to configure caw when using an HTTPS proxy to access an HTTP webpage vs an HTTPS webpage? Thank you!

You have to set protocol: https if you're accessing a HTTPS page. Otherwise it looks fine. If you don't set the proxy, it'll try to get it from environment flags.

So when accessing an HTTPS page, should it be like caw('https://<IP_ADDRESS>:555', {protocol: 'https'})? So https in both places, the proxy string as well as the protocol value?

And when accessing a regular HTTP page, it's caw('http://<IP_ADDRESS>:555', {protocol: 'http'}), so http in both places instead of https?


Bump rustc to 1.8 and revamp all CI

This bumps the minimum rustc to 1.8.0, "fixing" #257.  I normally
consider this a breaking change, but we were already broken due to
external factors, for which I couldn't find a workaround.
This adds 1.15.0 to the CI matrix to build stable num-derive.  We still
need nightly to run its tests though, because of compiletest_rs, and
dev-dependencies can't be optional.
The testing scripts are moved from .travis/ to ci/, as they don't really
need to be hidden.  It's also now consolidated into one test_full.sh
which considers $TRAVIS_BRANCH as needed.

@homu r+

:pushpin: Commit f58062f has been approved by hauleth

:hourglass: Testing commit f58062f with merge cd75d87...

Hold on, it failed because I wrote TRAVIS_BRANCH when I meant TRAVIS_RUST_VERSION.

@homu retry

@homu r=hauleth

:pushpin: Commit 1606fe7 has been approved by hauleth

:zap: Test exempted - status


[Feature request] Keep only n tagged images (and ignore specific tag)

Hi,
Fantastic work, thank you so much for solving this headache.
I have a feature request to keep only n-tagged images, and to always keep a specific tag as well.
Background:
I have a setup where I have two types of containers:

One "dev" container
Ongoing versioned containers (ie. latest)

Whenever I push to "dev" branch, it will create a new container tagged "dev", and untag the old "dev" container; this helps me to test the image before releasing it.
When I then merge to the "main" branch, a new versioned (e.g. 4.2.1) container is created.
Proposal
What I would love to do is the following:

When I run your github action, it should keep maximum n (say, 10) versioned images (e.g. 4.1.0, 4.1.1, 4.1.2, etc)
In addition, it should always keep "dev" (never remove it)
All other packages (all untagged, any older than 10 versions, and not being "dev") should be removed

Thanks!
That's a good idea. Let me look into it.
Something like?
    steps:
      - uses<EMAIL_ADDRESS>        with:
          keep-n-tagged: 10
          exclude-tags: dev
          token: ${{secrets.GITHUB_TOKEN}}

I think your proposal is perfecr

I've implemented the feature. Please test it out on the v1.0.1 or v1 tag/release. I added a dry-run option also if you want to test with that first to simulate everything

Hey, super cool that you built it so quickly, much appreciated.
I let it run with these settings, and got the following error
Settings:
      - name: "Clean up docker images"
        uses: dataaxiom/ghcr-cleanup-action@v1
        with:
          keep-n-tagged: 10
          exclude-tags: dev
          dry-run: true
          token: ${{secrets.GITHUB_TOKEN}}

Error:

Error: Cannot read properties of undefined (reading 'id')

Job:
https://github.com/ManiMatter/decluttarr/actions/runs/9083315844/job/24961774859

Btw - "cherry on top" - does the script print out at the very end how many containers it removed?
Would be cool to know (makes one feel good to know how much crap was removed) 🧹

Yes, it outputs the following kind of log currently:
deleting tagged images, keeping 0 versions
deleting package id: 216128070 digest:sha256:a6d2b38300ce017add71440577d5b0a90460d0e57fd7aec21dd0d1b0761bbfb2 tag:ubuntu
deleting package id: 216128003 digest:sha256:2af372c1e2645779643284c7dc38775e3dbbc417b2d784a27c5a9eb784014fb8 tag:architecture amd64
deleting package id: 216128018 digest:sha256:2f63021dc56651000aa1e250d42c3aa898a5cd61120aeb8daf9e7e0fd20b84e5 tag:architecture arm
deleting package id: 216128036 digest:sha256:462e829de9164b6c066246cddc265a936071744f689f0ea73daa92b4f9feb47e tag:architecture arm64
deleting package id: 216128051 digest:sha256:6250b8edd7248ca0764e8c10069113ac1c837becd6e1e5a92991dfa14dce842f tag:architecture ppc64le
deleting package id: 216128067 digest:sha256:4b24be9d94475438fe8313d8772be9c94e7c89d4e2b2d2a7570dcb3a7f51ee80 tag:architecture s390x

I've just found some further optimizations which I'll push and release right now, it includes a wildcard matching feature for the tag/exclude tags
It doesn't yet print out total number of images deleted.

cheers. will test it when the next version is ready, let me know

I've push the latest changes, v1 or v1.0.2.
I've verified the image order and some a bunch of different tests, however the code equality test is different between keep-n-tagged and keep-n-untagged which I'm still investigating/testing.

Can you trigger your pipeline again and see if the id error still exists?

I think I can harden then platform image deletion.I think you might have some manifests that don't link to actual images.  I'll make the change right now.

re-ran the job right now, ended up in the same place:
Error: Cannot read properties of undefined (reading 'id')
https://github.com/ManiMatter/decluttarr/actions/runs/9083315844/job/24964895577

I'm testing a fix. I've added some extra guards to handled corrupt manifests.
On the image order I have to sort the remaining "images" once all the processing is done, what I found was the sort function had to be reversed between keep-n-tagged and keep-n-untagged logic. Which I wouldn't expect, but my test showed it needed it. (Still need to verify it more)

Thanks for the PR!!!!!
I've made some changes on main branch. Can you retest using main?
uses: dataaxiom/ghcr-cleanup-action@main

pleasure.
Now it passes, but I see these warnings:

Warning: couldn't find image digest sha256:b25c425cb7b29392a93342a9f9b2d3f3655bf1bba0626d4949ccb29d9a2f2d94 in repository, skipping
Warning: couldn't find image digest sha256:9290ba706a8173b39325236be6e0803cbb0835b7cf4022aa63315a3709628539 in repository, skipping
Warning: couldn't find image digest sha256:45db222b16bd5b922b6cb9e7b08ea6486b9b72cf9d6a321041ec688348114a07 in repository, skipping
Warning: couldn't find image digest sha256:30d7d0a3727d7a82ccfb835281495bf45d96829efc1cb043308917fceab4c71d in repository, skipping
deleting package id: 195021580 digest:sha256:2d49d6d1a3fa6a9188d4f23ce3e4a1b1987ea57aa29dcb97e8fd4c9c64bcfab5 tag:v1.31.0
Warning: couldn't find image digest sha256:bb1dd8101ad4e1d372470cd5451ee20b9d46b7cfc680df682970eaddb8f49b80 in repository, skipping
Warning: couldn't find image digest sha256:f5715c3bb6f7886d201ebc7278e58e674a5eaa3f92fa07dfe9bdb5e0d7819213 in repository, skipping
Warning: couldn't find image digest sha256:1f9ee2ae5b0eb06322458d3e8c506e696f2ddbf72996cd909630071081e3c79a in repository, skipping
Warning: couldn't find image digest sha256:e272e95bbfd56c14318d38d36719b7a7d85055cf0f1c904a0259acb1e15a3c13 in repository, skipping
deleting package id: 195021156 digest:sha256:9273a4198824a8a15d1e0856e56e498a6f6f938116121e756dd9e2148ceb4fac tag:v1.30.0
Warning: couldn't find image digest sha256:7a4ba8b4397c604529532a4c945984e93d66dd1524a1a690b75494d9baf4b0aa in repository, skipping
Warning: couldn't find image digest sha256:7e9b63975b3803fe421b628987fd942f351985496f13355e15bb6911a2984ef0 in repository, skipping
Warning: couldn't find image digest sha256:0a39d1fa1509f0885a9a990a3515f42b69c59e9cef87fe295f0cc5cc82bead8b in repository, skipping
Warning: couldn't find image digest sha256:890a89fca7d0507d484f96d1f742a87d84f180331f149dd491136256e768f5cb in repository, skipping
deleting package id: 197541388 digest:sha256:07fd4058a1c233662ebdbc6c5bbd008fde13e1e9494451197ec96811dbf8e1f3

https://github.com/ManiMatter/decluttarr/actions/runs/9085371392/job/24968536043

thats great. yes I added those warnings, you have some corrupt image manifests, but all good. It just skips over them. Any way to tell if the action keep the most recent tags?

From what I see, the following are not removed:

dev (as being on the "exclude-tags" list)

latest/v1.42.0

v1.41.2

v1.41.1
v1.41.0
v1.40.0
v1.39.0
v1.38.0
v1.37.0
v1.36.0
v1.35.1

Which looks good. I see that the next version v1.35.0 is removed, so everything looks right.
Job:
https://github.com/ManiMatter/decluttarr/actions/runs/9085371392/job/24968536043
Images:
https://github.com/ManiMatter/decluttarr/pkgs/container/decluttarr/versions?filters[version_type]=tagged
On the warnings regarding the corrupt image manifests, would these remain there after the job has run?
Or asking differently, will these never be cleaned up?
If there was a way to kill those automatically, that'd be great (else the user sees the same message over and over again)

Warning: couldn't find image digest sha256:b25c425cb7b29392a93342a9f9b2d3f3655bf1bba0626d4949ccb29d9a2f2d94 in repository, skipping

That's great to hear it's all calculating the cleanup correctly. I would expect those warnings to be on only that job. The image manifests which have corruptions are deleted on that run so it won't loop through that manifest file again in a future job. When new tags come up for deletions on new jobs it would asses those manifests then for processing, which would be new errors.
I'm making a few minor changes (for stats output) and then I'll release 1.0.3 later today and retag v1
Thanks so much for the feature request and testing.

On the warnings regarding the corrupt image manifests, would these remain there after the job has run?
Or asking differently, will these never be cleaned up?
If there was a way to kill those automatically, that'd be great (else the user sees the same message over and over again)

I think I can answer my own question.
Here is what's happening. This github action doesn't properly work with multi-arch images, and kills the untagged images belonging to multi-arch images.
Here's an example:
https://github.com/ManiMatter/decluttarr/pkgs/container/decluttarr/195679913
This image has 3 architectures, but they were deleted by the github action.
Multi Arch Package: sha256:502b0b859a36e03643941232530b4a6ccf3a8a2bca1cb90700207f83b2b784c3

linux/amd64:  @sha256:b25c425cb7b29392a93342a9f9b2d3f3655bf1bba0626d4949ccb29d9a2f2d94
linux/arm64: @sha256:9290ba706a8173b39325236be6e0803cbb0835b7cf4022aa63315a3709628539
unknown/unknown: @sha256:45db222b16bd5b922b6cb9e7b08ea6486b9b72cf9d6a321041ec688348114a07

Your script correctly says that the 3 latter ones can't be found (no wonder, they were deleted).
This error goes away, if the parent package gets deleted (which it will, if by the settings it is in scope of deletion, for instance  may case when it's older then 10 versions).
I would have a suggestion though here: Why not add another setting "remove-broken-multi-arch-images"?
And then basically remove any multi arch package where the underlying manifests are not found anymore.
Reason: A multi-arch package that points into nirvana is useless... Any my take is that many people switching over from the other github action to yours will probably suffer from that problem.
What do you think?

Yeah, that's exactly what is likely happening. It's the main reason I wrote this version, none of the existing cleanup actions (even dedicated container ones supports multiarch images) which corrupted some of my images so I disabled the actions.
That's a interesting idea to proactively validate the image manifest. I almost think that should be a different standalone mode producing a report. As multi arch image may be corrupt but still work for a given platform, if that underlying image still exists the pull would likely work on a given host. In your case it looked like all the underlying images were gone. This issue did make me think of a scenario where maybe multiple multi-architecture manifests may point to the same image digest. I need to walk through the code on that potential.
I was thinking this morning another standalone mode could be a "recovery" mode whereby you could specify the package id's to recover any packages that were accidentally deleted from the action directly (unrelated to the issue above). Otherwise you have to jig some web api call manually to recover them.

Does this mean that you have already baked the removal in (without user having to specifically put a setting), or you are removing them "by chance" because they may fall into scope (e.g. because they are older than 10 versions)?

Yes, that's correct for the images that fall into scope on each run. But your idea would proactively valid the 10 other versions in your scenario, but it probably shouldn't touch them.

you're right, there could be multi-arch containers that miss some manifests, but not others.
Would this be a valid approach?
For containers not anyways in scope for removal:

remove multi arch containers that do not have a single valid underlying manifest (e.g. if i have 15 images, and nr. 9 is completly broken, it would take 1-8, 10&11, rather than 1-10 when selecting 10 images to keep)
spit out a warning for multi arch containers that have partially missing manifests (but not all)

For containers in scope for removal:

don't spit out a warning for missing manifests (just confuses and gets solved by this action anyways by removing the parent container)

you're right, there could be multi-arch containers that miss some manifests, but not others.
Would this be a valid approach?
with:
keep-n-tagged: 10
exclude-tags: dev
dry-run: true
token: ${{ secrets.GITHUB_TOKEN }}
partial-manifest-removal: true

By default, all multi-arch containers are removed where all underlying manifests are invalid (no setting is needed for that, imo should be default behavior of this action)
If partial-manifest-removal is true, also multi-arch containers are removed, where only some manifests are invalid
These two rules are executed before any other rules (for instance, selecting the keep-n-tagged)

In the part where the images are deleted, I would then not show the warning that the respective manifest is missing (simply skip that)
Thoughts?

Good suggestions.  It agree removing the warning for in scope deletions is probably a good idea.  I'll make that change.

remove multi arch containers that do not have a single valid underlying manifest (e.g. if i have 15 images, and nr. 9 is completly broken, it would take 1-8, 10&11, rather than 1-10 when selecting 10 images to keep)

That's a good idea for fully broken images in scope. Out of scope is a bit more problematic for the other cleanup modes (not keep-n-tagged) Let me review the code.

spit out a warning for multi arch containers that have partially missing manifests (but some are valid), and keep the container

For out of scope processing that might be more challenging as the current different modes: delete by untagged, delete by tag and keep-n-untagged operate a bit different to the keep-n-tagged. In my case I'm currently using the delete untagged (default), and expect the total number of images to grow without ever deleting released images. Maybe a "verify" option could be used to enable out of scope scanning/reporting, which then could be turned off when the images 'healthy'
You are probably right there are a lot of broken manifests out there in ghcr.io considering the lack of multi-arch support, so this kind of functionality would be useful for projects that switch to this action.

Let me think about your latest suggestion more, I'll back to you. As long as it can support all the cleanup modes I agree some better validation should be used.

just wanted to again thank you - fab work. really enjoing the exchange with you here on this :)

thanks for being my first external user/tester. it's validated that it's currently needed.

I've seen this new option:

Ghost Images
Multi architecture images which have no underlying platform packages are
automatically removed for the keep-n-untagged and keep-n-tagged modes and not
include in their count. Partially corrupt images are not removed by default, use
the validate option to be able to identify and then fix them.

with "fix them", does this mean it will remove those partially broken platform packages as we discussed above with the "partial-manifest-removal: true" flag? Or does this simply mean that the logs spit out which packages are broken, so that I can then go in and fix them myself?
Many thanks for clarifying :)

Hey
I haven't yet implemented a partial-manifest-removal mode, I feel like it pulls into scope images that you may not want to be deleted (especially for the other non- keep-n-tagged modes) (but it still may be a valid use case).  So currently you would have to then go and put the invalid images in for deletion on a next workflow run after running the validate mode.
I did add a few extra features:

Removal of ghost images in scope for (keep-n-tagged/keep-n-untagged modes. So it doesn't include them in the count and they get auto removed
I still log invalid images, but they don't show up a workflow warnings.
Added the 'validate' mode  which will scan all images and print out any images which are partially valid
Support using tags option on keep-n-tagged mode, additional to the exclude-tag.

I planning to build some automated tests next, it's quite a manual process to test all these scenarios. Once that is done then there is other options which could be added: deleting by date, by download count, package restoration etc

I'm impressed by how many features you have already added to this action in so little time!
Based on your this statement, my understanding is that packages that are fully broken (no working underlying manifests) are removed already.

Removal of ghost images in scope for (keep-n-tagged/keep-n-untagged modes. So it doesn't include them in the count and they get auto removed

However, I am not sure I understand how the partial-manifest-removal mode may conflict with the different action modes.

I feel like it pulls into scope images that you may not want to be deleted (especially for the other non- keep-n-tagged modes)

I understand there are essentially 4 modes.

Remove all untagged and keep all tagged
Remove n untagged and keep all tagged
Remove all untagged an keep n tagged
Remove specific tags

In all options, I would expect that if partial-manifest-removal is on, packages that are partially broken would be removed in any case. Meaning: Even if they are listed as "excluded" or if there are 10 untagged items of which one is partially broken and we say keep 100, it would still reduce the number to 9. E.g., the "fixing" should supersede everything.
I was thinking first whether something that is "excluded" should also be excluded from partial-manifest-removal. However, if we clearly document that partial-manifest-removal takes priority over exclusion, then I think it's fine that partial-manifest-removal supersedes. If we were to give priority to exclusion over partial-manifest-removal, it would start getting tricky because of wildcard support. If somebody is not OK with exclusion being ignored for partial-manifest-removal, then I guess the user should not use partial-manifest-removal, but instead use the "validate" option and remove these items manually.
What do you think?
I am probably missing an important aspect that you have in mind, when cautioning that the partial-manifest-removal may conflict with the other modes. Could you elaborate please? Maybe we can brainstorm it out together :)
Cheers

I currently have coded that exclusion takes priority over everything, and it currently supports wildcards. I have a pre processing step that process all the tags for exclusion. I think that should stay that way, while ironically it's a cleanup action it should take a super cautious approach to deletion and cleanup.
Your point about partial-manifest-removal in all cases for the other modes is where it gets tricky. As from a user perspective it kind of implies including into scope all images as you point out. But the untagged and tags modes currently leave all out of scope images alone. So it might lead to more user error unless there is more general approach about deleting.
I would propose changing the partial-manifest-removal to a delete-partial-manifests.  I was thinking yesterday that there may be a number of delete- options which are additive. Like delete-older-then, delete-downloads-less-then and delete-partial-manifests, which get processed before the keep and tags modes. In this setup the strangely mode 1 is really an explicit delete-untagged option, might might be default option.
So the core logic would be to process excludes, process delete options, then process the keep options.
Which then got me thinking the project needs automated testing asap. So that these other functions can be added easily and without breaking all the other modes. haha

makes me think that maybe the tags option should really be delete-tags instead to be clearer and in line with the other delete- options

agree to all you said :)
typescript / github actions etc are not my forte at all, and i'm actually studying how you are coding it, and am learning a lot from it. thank you

Hi ManiMatter
I've finally added a delete-partial-images option to the action (and a delete-ghost-images) Both of these options are set to false by default (previous the ghost image support was built in (and true). If delete-partial-images is set it will delete an images which are not complete before it process any other rules.
I'm still testing and plan to put in a test case (or 2) before I release it.
R.

Great news! I‘m excited to test it. Hope to find time tmrw to do so!
thanks so much for your work and for considering this feature suggestion!

I've also removed the delete untagged mode from the keep-n-tagged, so you'll need to add --delete-untagged to your setup if you want to delete untagged images. I've changed the setup so no you can have all the modes --keep-n-tagged --keep-n-untagged --delete-untagged --delete-tags now at the same time.

thanks for the info!

You can reference the main branch like this in your action setup, which will allow you test before release.
 uses: dataaxiom/ghcr-cleanup-action@main

I've let it run on "dry-run", looks promising

cleanup statistics:
multi architecture images deleted = 111
total images deleted = 570

I'm glad I won't have to delete those manually.
You mentioned that you want to add a few more checks and features before releasing v1.0.8.
Let me know when you think you are ready, I will then

let it run in dry-run again and see if I get above number still
let it run for real and let you know if the outcome looks right

I've released v1.0.8/v1 ff99a6e, so closing this issue.
BIG thanks for your feedback/help.

.. thanks so much for your help, I let it run productively... so happy I didn't have to do it manually.
One observation: The Dry-run number and the actual deletes differed. Could it be that dry-run double counts certain things?
 I can t see how looking at the code, so I'll need to run some tests and analyze more
Are you 100% sure that there was no change in the package repository between these runs?

I changed from the @main to @v1.0.8, remove dry-run and pushed the change, which would (based on my git flow) create 4 new containers (multi arch + 3 versions) and then clean up the packages.
so if anything, I‘d have expected the nr of packages go up (by 4) rather than down.
the only other 2 explanations I can think of is that what I tested a few days back (@main) and what i ran now (v1.0.8) are different, or that the dry run has some sort of double counts…
not a big issue though: the result looks correct after the cleanup
thanks again for your great work on this

I think the reduced count is likely as you commented out the keep-n-tagged, which the kust switched to cleaning up untagged images. So that didn't delete any tagged images (excepted 2 it looks like which were ghost images).

arghhhhhhhhhhh
You are 100% right. Sorry for wasting your time on the false alert

All good. It was good to verify. Thanks for all your help from the beginning. I think the 1.0.8 version is pretty solid, we'll see, haha.

Yes, it seems to work like a charm.
The only feature I‘m sad about is the one that considers #downloads, ie what we dont get on the API by github.
did you raise a feature request on their end by any chance?

Ah, downloads, that's true. I noticed in your repo you have some images in the 5k mark, so it will become and issue.
I've yet to look to see if there is an existing issue raised with GitHub. Seems strange that the info isn't available through the API. I saw some posts from people who scrap the webpage, but that that's not a good idea for this action I feel.

Yeah if we can avoid scrapping we should at all cost; would make the solution brittle and if scrapping incorrectly (and there are no safety measure to detect that) may lead to involuntary deletion.
Threshold-wise I would even set it lower in my case, 500 or 1000.. guess that should be parametrizable. That‘s a detail though, and irrelevant if we can‘t get hold of the download stats in the first place


2.0 fails to run for me; error in addXCTestTapAlertAction

Hi team
Congrats on getting 2.0 released, I'm excited to start using it, to remove a few custom hacks for activating the app to the foreground.
I tried to use 2.0 today and my tests fail to build when running it, after a 'pod repo update' + 'pod install'.
XCode logs a problem with addXCTestTapAlertAction's line:
               let index = self!.r.randomInt(lessThan: buttons.count)
It suggests a fix like this:
               let index = self!.r.randomInt(lessThan: Int(buttons.count))
Have I done something wrong, or is this legit?
Thanks
Daniel

Hi @deemicksee and thanks for an immediate feedback after the new release 😄
Regarding your issue, is it correct that your project is using Swift 3 version? The reason I'm asking is because of what Xcode is suggesting to you. It looks like an exact opposite of what we did to migrate to Swift 4. Look here: https://github.com/zalando/SwiftMonkey/pull/48/files#diff-884f34fe37364def7d3d15c22b1ddd3aL37
The new version 2.0 is not backwards compatible (perhaps I should add this info to the release notes) and it supports Swift 4 only (hence the major version bump to 2.0). If this is indeed the case that you have a Swift 3 project and you're using SwiftMonkey 2.0 then we have 2 options:

You would have to try migrating to Swift 4 yourself
I will add the feature you need to a new version 1.1.1 that will be Swift 3 compatible

What do you think?


Full Mode Image Loading

In full mode there are some issues with images not being loaded. Mostly all pictures are always requested from the server, shouldn't they be cached?

If you know the URL, just post here. I also had some image loading problems but it depends on the application.

I think this is working now?

Will check it.

Looks great


Desktop basic java

Have you read the Contributing Guidelines ?
YES
Description
Notepad is a word processing program which allows changing of text in computer file, Notepad is a simple text editor for basic text editing which enables computer users to create files.
Fixes #478

Checklist

[x] I've read the contribution guidelines.
[x] I've checked the issue list before deciding what to submit.
[x] I've edited the README.md and link to my code.

Related Issues or Pull Requests
(Write your answer here.)

@Bhushan-Thombre Your issue not been assigned wait for issue being assigned


Unable to specify port in Jussi node configuration

When pointing to my own node, I need to use a custom port number to by pass nginx for some testing.  When I supply a port number in the DEV_config.json for the steemd node, jussi complains about an invalid upstream node.

This is a good find. I will advocate for this in our next sprint. Thanks!

Is there any status on this being resolved?


Fix #575 - Change css links in examples and dist file

Changed css links

Thanks, but no changes should be committed to the dist/ folder as it will modify the current release. If you revert changes from dist/index.html file, i will merge it

Reverted! Will you create new release to fix the mistake on download?
Thanks, Vlad!

Thanks

Yes, it will be already fixed in next release


consider changing StorageController to a class that is instantiated with all of the stores

I see that all interface methods, in their constructors, take messageStore, dataStore, and now eventLog. e.g.

records-delete
records-write
records-query
records-read

but it seems like they're almost always passed to StorageController  to do stuff like queries, puts etc. i do see some areas that use just messageStore.query and not StorageController.query, presumably because StorageController also returns the respective data if its under a certain size?
it seems like, we could instantiate a StorageController instance in dwn.create and pass that to each individual handler. StorageController could simply have getters for messageStore when its needed individually.
curious to hear ppls thoughts here. basically, since we have StorageController now, we might as well leverage it to reduce the # of arguments that are passed to each interface method handler

I started working on this here: https://github.com/TBD54566975/dwn-sdk-js/pull/338
I just re-read @mistermoe's message above, I think the tests are failing in my PR because I've confused 'messageStore.querywithstorageController.query`, even though their argument lists are compatible.

StorageController is refactored and is on "less" critical path than before, for instance, put() is no longer going through StorageController. The debate in PR #338 also seems to suggest that it is not all bad that dependencies are injected explicitly, so closing this and we can reopen again if the code is become too unwieldy that requires a second look.


Type 'string' is not assignable to type 'ZRLineType | undefined'

Version
^5.4.1
Link to Minimal Reproduction
No response
Steps to Reproduce

Angular 15
ngx-echarts ^15.0.1

set datas in a component
datas: number[][][] = [     [         [50, 456],         [110, 456]       ] ];

create a series type 'lines'

const serieLine: echarts.LinesSeriesOption = {
          id: 'L',
          name: 'Route'
          type: 'lines',
          polyline: true,
          data: this.getCoordsData(0)
        };

build data in a method:

getCoordsData(datasIndex: number) {
    const res = [];

    const o = {
      coords: [[50,456], [110, 456]],
      name: i+'',

      lineStyle: {
        width: 5,
        opacity: 1,
        type: 'dotted'
      },
    };
    res.push(o);
    return res;
  }

Current Behavior
the error message on IDE is on the "data: this.getCoordsData(0)" line : The expected type comes from property 'data' which is declared here on type 'LinesSeriesOption$1'
so the problem come from "type: 'dotted'" because is string instead of ZRLineType
But I can't access "ZRLineType" for import
Expected Behavior
access to ZRLineType for import in typescript
Environment
- OS:
- Browser:
- Framework:

Any additional comments?
No response

Since you define the data outside the LinesSeriesOption object, TypeScript can't recognize the type of the data array. There are two ways to solve this issue,

Just add as const for lineStyle.type

function getCoordsData(datasIndex: number) {
    const res = [];
    const o = {
        coords: [[50, 456], [110, 456]],
        name: '',
        lineStyle: {
            width: 5,
            opacity: 1,
            type: 'dotted' as const
        }
    };
    res.push(o);
    return res;
}

Explicitly specify the type of o

function getCoordsData(datasIndex: number) {
    const res = [];
    const o: LinesSeriesOption['data'][number] = {
        coords: [[50, 456], [110, 456]],
        name: '',
        lineStyle: {
            width: 5,
            opacity: 1,
            type: 'dotted'
        }
    };
    res.push(o);
    return res;
}


Sandbox Swagger UI

CHANGES:

Swagger UI:

Split meep-swagger-ui into the following JS Apps:

meep-platform-swagger-ui

Platform Controller API
Mon Engine API

meep-sandbox-swagger-ui

Sandbox Controller API
Metrics Engine API
Location Service API
RNIS API
Mobility Group Service API

Platform Controller:

Serves platform Swagger UI

Accessible via http:<host>/api

Sandbox Controller:

Each instance serves swagger UI for its sandbox

Accessible via http:<host>/<sandbox name>/api

Added entrypoint.sh script to run at microservice start

Script sets sandbox name in base path in swagger API files to enable 'Try-it-out' feature

Virt Engine + Helm Charts:

Improved environment variable propagation @ helm chart install
Updated Ingress path rule & annotations to support sandbox swagger UI
Supported environemnt vars:

MEEP_SANDBOX_NAME: Propagated to all sandbox services by Virt Engine
MEEP_HOST_URL:  Provided to Virt Engine @ install time and propagated to sandbox services

meepctl:

Added support for swagger UI split
Bumped version to 1.4.3

TESTING:

UT & Cypress tests pass
Manually tested platform & sandbox APIs using 'Try-it-out' feature in swagger UI

No comments


Buffer Out-of-Bounds Error and Discord Closure Crash

Describe the bug
Upon closing Discord, the application crashes with a buffer out-of-bounds error.
To Reproduce
Steps to reproduce the behavior:

Launch the application.
Connect to Discord.
Client.user.setActivity()
Close Discord.
Observe the buffer out-of-bounds error.

Expected behavior
The application should gracefully handle disconnects upon closing Discord, allowing for appropriate cleanup or reconnection logic.
I attempted to catch this issue with both on('ERROR') and on('disconnect') to no avail.
Source code
So you understand my use case, my source is here: https://github.com/RagnarLothbrok-Odin/TraktDiscordPresence/blob/main/src/index.ts#L203
My changes almost look identical, just changed some things to work with your fork.
(please complete the following information):

OS: macOS
OS Version: macOS 14.3
Discord Version: Latest stable

Additional context
My use case:
// Function A
rpc = new Client({
                clientId: traktCredentials.discordClientId,
                transport: {
                    type: 'ipc',
                },
            });

rpc.on('ready', async () => {
                instanceState = ConnectionState.Connected;
                if (progressBar)progressBar.stop();
                progressBar = await generateProgressBar();
                progressBar.start(0, 0);
            });

await rpc.login();

// Function B
// Check if the RPC transport socket is connected
        if (!rpc.transport.isConnected) {
            rpc = null;

            // Respawn the RPC client (Function A)
            await new DiscordRPC().spawnRPC(this);
            return;
        }

Cam you post the stacktrace here

Got it.

Use the rpc.on("debug", console.debug) to figure out what is causing the issue, i am putting out a patch for Out-of-Bounds


Move yubikey import role check to avoid excessive passphrase prompting

When importing to a yubikeystore, we should reject non-root keys upfront before prompting for passphrases or attempting to read key bytes.
Signed-off-by: Riyaz Faizullabhoy<EMAIL_ADDRESS>

We really need to fix that whole keyPath inconsistency... but yeah, LGTM on this.
We should target Notary 0.4 (or whatever release we do after 0.3) for putting non-root roles in hardware, then this check disappears.

@cyli @diogomonica can we get another LGTM on this?

LGTM


 Read this article for reference

Can I work on this? @ashuvssut

Hi @Dexters-Hub! Any progress update?

Hi @Dexters-Hub! Any progress update?

I'm still working on it, The reference that you have sent  (using Navigation API) is deprecated and it is having some issues.

https://www.npmjs.com/package/nextjs-progressbar
You guys can use this. It's plug and play, highly customisable too

https://www.npmjs.com/package/nextjs-progressbar You guys can use this. It's plug-and-play, highly customizable too

Thank you @Manthan-Kuber


list and list --all include installed Xcodes

Hope this addresses #96. Both list and list --all include installed Xcodes, marking them as so:
$ xcversion list

7
7.0.1
7.1
7.1.1
7.2 (installed)

Did this as related to #99, so that we can download and stash Xcodes independently of what may be already installed.

Thanks!


500 on non-product Amazon URLs

Getting a 500 back for certain Amazon links. It seems browsing amazon's website in Incognito gives a whole bunch of non-normal product links, here's a few examples. I haven't done too much testing about which parts can be removed. I suspect these query parameters could show up in different orders as well.
Interestingly, with the deal link, if I remove all of the query parameters, only two products show up. If I leave them, more products show up. The tidier might have to parse the URL and reconstruct it with the minimum needed parameters instead of a regex wipe. Hard to say?
Deals: https://www.amazon.com/deal/8e4e81a3/?_encoding=UTF8&showVariations=true&_ref=dlx_gate_sd_dcl_tlt_8e4e81a3_dt&pd_rd_w=IDoV8&content-id=amzn1.sym.00000000-0000-0000-0000-000000000000&pf_rd_p=00000000-0000-0000-0000-000000000000&pf_rd_r=6JGAAKNB7XAKZ8QH16AE&pd_rd_wg=6TPwu&pd_rd_r=00000000-0000-0000-0000-000000000000&ref_=pd_gw_unk
Whatever this is: https://www.amazon.com/s?bbn=1266092011&rh=n%3A1266092011%2Cp_n_deal_type%3A23566065011&pd_rd_r=00000000-0000-0000-0000-000000000000&pd_rd_w=4cnu0&pd_rd_wg=PN9nP&pf_rd_p=00000000-0000-0000-0000-000000000000&pf_rd_r=2FMW7JZJK9NJVC2GT9K1&qid=1677022046&rnid=23566063011&ref=pd_gw_unk
And this: https://www.amazon.com/b?node=23597934011&pf_rd_r=2FMW7JZJK9NJVC2GT9K1&pf_rd_p=00000000-0000-0000-0000-000000000000&pd_rd_r=00000000-0000-0000-0000-000000000000&pd_rd_w=ce3td&pd_rd_wg=PN9nP&ref_=pd_gw_unk
Seasonal gift event I think?: https://www.amazon.com/gcx/Easter-Toys-&-Games/gfhz/events/?categoryId=easter-toys&pd_rd_r=00000000-0000-0000-0000-000000000000&pd_rd_w=J921W&pd_rd_wg=PN9nP&pf_rd_p=00000000-0000-0000-0000-000000000000&pf_rd_r=2FMW7JZJK9NJVC2GT9K1&ref_=pd_gw_unk&scrollState=eyJpdGVtSW5kZXgiOjAsInNjcm9sbE9mZnNldCI6MTA1NS45NjY2NzQ4MDQ2ODc1fQ%3D%3D&sectionManagerState=eyJzZWN0aW9uVHlwZUVuZEluZGV4Ijp7ImFtYWJvdCI6MH19

This can also happen when a URL doesn't contain the appropriate search string.  This was likely a copy-paste error, as later attempts worked so the string to tidy that was actually used is lost to time.
In short: Other than fixing these and hardening the tidying process, I need to write tests to catch these kind of things.

Well, crud.  gcx you can't just remove all of the query string like the deal and dp so I'll need to figure out what the magic query is.
/s is search and is likewise going to be difficult to tidy.  /b I can't even figure out what it is, but I did find this als which is easily tidyable:
https://www.amazon.com/discover/bn/sofas-couches?ref=sbl_mm_bn_sc
Going to keep investigating /s and /b too, see if I can't figure out what query is the magic one.


How do I configure to color coverage on Azure Functions (Python) Project?

I try to apply your extension to Azure Functions (Python) Project.
However, vscode editor lines are not colored, and "No Coverage" is displayed.
When I exuecute your project example, the editor lines are colored, and "xx% Coverage" is displayed.
So, my local machine seems to be fine.
My project repository is here.
And I upload 2 screenshots. (your project example and my Azure Functions project)

I switched to Python interpreter from project's .venv to local machine's global exe, however the problem didn't solve.
How do I configure to color coverage on Azure Functions (Python) Project?

@ecormaksin Thanks for the issue!
Good idea trying out the examples project that will cut down the amount of triaging I will need to ask you to do.
Based on your repo and your screenshots I would say you are missing a coverage file (.lcov).
Take a look at the readme for the python example to get an idea of how to generate a coverage file for your tests.
https://github.com/ryanluker/vscode-coverage-gutters/tree/master/example/python#readme
There is also a few previous github issues that mention generating code coverage files from python as well.
https://github.com/ryanluker/vscode-coverage-gutters/issues/224#issuecomment-530197803

@ryanluker Thank you for your reply.
Is it needed that the extension of a coverage file must be .lcov?
In your project example, .lcov file is not created, is it?
(That is because the command example is py.test foobar --cov-report xml:cov.xml --cov foobar.)
Coverage-gutter extension seems to search {lcov.info,cov.xml,coverage.xml,jacoco.xml,coverage.cobertura.xml}.
In my project, coverage.xml is created.
(coverage.xml is listed to .gitignore by default when I created the project using Azure Functions extension.)
I change pytest args from xml to xml:cov.xml, however the result does not change.

@ecormaksin You are correct that any of the file names matching will work .lcovl is just one example.
Where is the coverage.xml file in relation to the project? It will need to be inside the folder you open with vscode for the extension to find the file 🤔.

@ecormaksin I ran your example project locally and was able to get the coverage to be picked up by doing the following.
[1653143161420][coverageservice]: LOADING
[1653143161440][coverageservice]: Loading 1 file(s)
[1653143161440][coverageservice]: c:\Users\ryanl\dev\azure_functions_coverage_test\cov.xml
[1653143161440][coverageservice]: Loaded 1 data file(s)
[1653143161441][coverageservice]: Caching 6 coverage(s)
[1653143161441][coverageservice]: READY
[1653143161441][coverageservice]: RENDERING
[1653143161441][renderer][section test name]: module_a.py
[1653143161441][renderer][section file path]: C:\Users\ryanl\dev\azure_functions_coverage_test\shared_code\module_a.py
[1653143161441][coverageservice]: READY
[1653143161441][coverageservice]: Listening to file system at {c:\Users\ryanl\dev\azure_functions_coverage_test}/**/{lcov.info,cov.xml,coverage.xml,jacoco.xml,coverage.cobertura.xml}

(venv) PS C:\Users\ryanl\dev\azure_functions_coverage_test> py.test --cov-report xml:cov.xml --cov
========================================================== test session starts ==========================================================
platform win32 -- Python 3.10.4, pytest-7.1.2, pluggy-1.0.0
rootdir: C:\Users\ryanl\dev\azure_functions_coverage_test
plugins: cov-3.0.0
collected 2 items

tests\test_ClassB.py .                                                                                [ 50%]
tests\test_module_a.py .                                                                                [100%]

---------- coverage: platform win32, python 3.10.4-final-0 -----------
Coverage XML written to file cov.xml

=========================================================== 2 passed in 0.12s ===========================================================
(venv) PS C:\Users\ryanl\dev\azure_functions_coverage_test>

The key might have been to run the coverage report across the whole project. Let me know if that helps!
py.test --cov-report xml:cov.xml --cov

@ryanluker Thank you for your help!
I could color vscode editor by changing .vscode\settings.json as follows:
before:
    "--cov=DurableFunctionsHttpStart",
    "--cov=shared_code"

after:
    "--cov=."

@ecormaksin excellent! Happy coding 😁


remove seconds to time input formats

time format is primarily for club events  ( most of which are club meetings)
No club meetings will ever need to be specific enough to warrant including seconds. Please remove it and help solve some initial confusion when using Lynbrook app

thank you!


Add support for \wsl$\ubuntu path

PR Summary
WSL2 introduces a new filesystem path to access the Linux filesystem from Windows.  Depending on the distro name, it would look like \\wsl$\ubuntu.  The problem is that this is not a valid UNC path so it gets rejected outright.
Fix is to check for this type of path and pass it off as a UNC path so that the filesystemprovider accepts it as a valid filesystem path.  The .NET APIs handle this just fine once it makes it that far into the code.
Manually validated dir \\wsl$\ubuntu and cd \\wsl$\ubuntu; dir
PR Context
Fix https://github.com/PowerShell/PowerShell/issues/10360
PR Checklist

[x] PR has a meaningful title

Use the present tense and imperative mood when describing your changes

[x] Summarized changes
[x] Make sure all .h, .cpp, .cs, .ps1 and .psm1 files have the correct copyright header
[x] This PR is ready to merge and is not Work in Progress.

If the PR is work in progress, please add the prefix WIP: or [ WIP ] to the beginning of the title (the WIP bot will keep its status check at Pending while the prefix is present) and remove the prefix when the PR is ready.

Breaking changes

[x] None
OR
[ ] Experimental feature(s) needed

[ ] Experimental feature name(s):

User-facing changes

[x] Not Applicable
OR
[ ] Documentation needed

[ ] Issue filed:

Testing - New and feature

[x] N/A or can only be tested interactively
OR
[ ] Make sure you've added a new test if existing tests do not effectively test the code changed

Tooling

[x] I have considered the user experience from a tooling perspective and don't believe tooling will be impacted.
OR
[ ] I have considered the user experience from a tooling perspective and enumerated concerns in the summary. This may include:

Impact on PowerShell Editor Services which is used in the PowerShell extension for VSCode (which runs in a different PS Host).
Impact on Completions (both in the console and in editors) - one of PowerShell's most powerful features.
Impact on PSScriptAnalyzer (which provides linting & formatting in the editor extensions).
Impact on EditorSyntax (which provides syntax highlighting with in VSCode, GitHub, and many other editors).

@rjmholt It seems your account lost permissions.

It seems your account lost permissions.

Apparently that's intended since I'm not a maintainer

@rjmholt I see the same for Paul account. But previously approve had green label.
/cc @TravisEz13

@rjmholt not a maintainer... yet

@iSazonov

But previously approve had green label.

Yeah, the permissions have been updated so that non-maintainers can't give merge-permitting approval, and there are a few of us on the PowerShell team who aren't maintainers (which makes sense to me -- they're different hats to wear).


[FocusFiles] Loading a file deleting all data on view + Error send by server not handled

Context
I'v got a form with both a dropfile section and classic fieldFor.
Architecture : DetailPage > Block > PageList > Line > action that open a popup containing the form.
Here the content of my popup :

Actual behaviour
issue 1 : if i load a file in the drop zone, all my fields gone blank (no matter where the data comes from).
issue 2 : If i save my object and get an error from server (on fields for instance). Then i can correct the fields, the filedropper still detect the file that i loaded but during the second save : file not found and i'm rejected from server (i must reload a file > lose my data, retype them etc...)
Expected behaviour

Keep data fields when i load a file
Keep the saved file even when there's errors happening during the save.

Versions
Focus-core : 0.11.3
Focus-component: 0.7.4
Focus-File: 0.1.2

@Pandakls The repository for this extension is https://github.com/KleeGroup/focus-file , can you recreate your issue here ?

I think there is a misunderstanding of the component behaviour here.
The UploadFileComponent should be separated from the form other elements. We will come see you in order to detail the way to do it.

Yes but i want my save action to save both the file and the data under

@Pandakls as seen with you, this is due to a setState in your component. The first and best solution is to separated the component holding Focus File from the form, and link them with a common parent.
The second solution is to keep the previous state when you upload a file, and restore it afterwards, as you did.
In any case, that's the expected behaviour, closing this now.


Blog Art: Diagram illustrating the flow of data on the factory floor when bridging OPC UA to MQTT.

Related Issue
No response
Description
Considerations:

Recreation of this diagram : https://raw.githubusercontent.com/FlowFuse/website/91e32a4971525ff75d9566420ea4d1e362a288f1/src/blog/2024/08/images/factory-floor-mqtt-opcua.png

Content reference
https://github.com/FlowFuse/website/pull/2431

Hi @sumitshinde-84


Nothing happens while extension installation

VSCode Version:
Version: 1.32.3 (user setup)
Commit: a3db5be9b5c6ba46bb7555ec5d60178ecc2eaae4
Date: 2019-03-14T23:43:35.476Z
Electron: 3.1.6
Chrome: 66.0.3359.181
Node.js: 10.2.0
V8: 6.6.346.32

OS Version: Windows_NT x64 10.0.17134

Steps to Reproduce:

I had one of the older version on pc (don't know exactly)
Uninstall older version
Install version 1.32.3
Open Vue project of mine
There was a suggestion to install extension Vetur
Click Install
result: Looks like VS Code in process of installing extension but nothing happens for a long time.
Also in Developer: Toggle Shared Process I see vs code tries to find not existing variable -

P.S. I tried to install previous versions but got the same behavior.
(Also, I don't use a proxy)

Does this issue occur when all extensions are disabled?: Yes/No

What is your TEMP folder setting? It looks like you have wrong TEMP folder path setting

@sandy081 Do you mean this? -

Yes


No support for no table height

I am using this project because I am not trying to hard-code in any table height. (I shouldn't have to hard-code anything but that's another story.)
I see in the docs that tableHeight is not required. However, per this CodeSandbox, it is (table won't render without it.

@MikeWarren2014 thanks for letting me know!
So the first thing I noticed was that there were some other unrelated errors in the CodeSandbox in Table.js. here's the updated version:
import React from "react";
import { Table } from "react-fluid-table";

const data = [{ id: 1, firstName: "Mike", lastName: "Warren", email: "Test" }];

const columns = [
  { key: "id", header: "ID" },
  { key: "firstName", header: "First" },
  { key: "lastName", header: "Last" },
  { key: "email", header: "Email" }
];

export const Example = () => (

);

The import was missing curly braces, and I changed employee to be a basic JS object.
And the way tableHeight currently works is a little tricky. It's not required if the component that wraps the table has a set height. So for example, it wouldn't be required in this case:

It's something that I am actively trying to solve, and I'll try and get a fix out for that in my next update

@MikeWarren2014 this should be fixed in version 0.3.2. The height should work as expected (you don't need to specify a height on the parent or on the component if you don't want to).
See the updated documentation


Resolved conflicts of all my open PRs

in case you agree with all of them. #13 #14 #15 #16

ping @joneshf

Thanks for the PRs!
This one PR has too many changes to review and merge all at once, so I'm going to close it. But, I'll review the individual ones when I get some time. Hopefully sooner rather than later.


fix socket.kickOut() v17

closes https://github.com/SocketCluster/socketcluster-server/issues/49

TODO

[ ] update typings https://github.com/DefinitelyTyped/DefinitelyTyped/blob/master/types/socketcluster-server/v15/serversocket.d.ts#L192
[ ] update docs


cobang: init at 0.9.6

Motivation for this change
#149074
Things done

Built on platform(s)

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

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

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

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

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

[x] Fits CONTRIBUTING.md.

When I try to run the app with nixpkgs-review I get following error:
cobang
Traceback (most recent call last):
  File "/nix/store/rs0932yak53a68yfkk4hdsskly5ap7h9-cobang-0.9.6/bin/..cobang-wrapped-wrapped", line 6, in <module>
    from cobang.__main__ import main
  File "/nix/store/rs0932yak53a68yfkk4hdsskly5ap7h9-cobang-0.9.6/lib/python3.9/site-packages/cobang/__main__.py", line 20, in <module>
    from .app import CoBangApplication
  File "/nix/store/rs0932yak53a68yfkk4hdsskly5ap7h9-cobang-0.9.6/lib/python3.9/site-packages/cobang/app.py", line 14, in <module>
    from PIL import Image
  File "/nix/store/ik33r2v6rzmglwni2dl4lq83ql7wjdlh-python3.8-Pillow-8.3.2/lib/python3.8/site-packages/PIL/Image.py", line 114, in <module>
    from . import _imaging as core
ImportError: cannot import name '_imaging' from 'PIL' (/nix/store/ik33r2v6rzmglwni2dl4lq83ql7wjdlh-python3.8-Pillow-8.3.2/lib/python3.8/site-packages/PIL/__init__.py)

Maybe there's a Python dependency missing?

@onny I don't think this is an issue with Pillow (PIL) being missing, as it goes further on the process to fetch a module. I was looking at Pillow docs and saw some info regarding how to import the modules, but what strikes me as weird is this not working on one place but working on the other.

I would vote to get it merged since it is working well in a clean install on my system :)

Setting this PR as a draft, as Pillow was updated to version 9 and this application does not support it

This pull request has been mentioned on NixOS Discourse. There might be relevant details there:
https://discourse.nixos.org/t/prs-ready-for-review/3032/755

This is a semi-automatic executed nixpkgs-review with nixpkgs-review-checks extension. It is checked by a human on a best effort basis and does not build all packages (e.g. lumo, tensorflow or pytorch).
Result of nixpkgs-review pr 149729 run on x86_64-linux 1

7 packages built:

cobang
python310Packages.kiss-headers
python310Packages.python-zbar
python310Packages.single-version
python39Packages.kiss-headers
python39Packages.python-zbar
python39Packages.single-version


Update automation-linux-hrw-install.md

Perhaps there is no need to edit the file if someone is just trying to check the version. Or, if someone is trying to edit the version, the command as is doesn't work, it needs a space between vi and /opt.
cat or less may be more appropriate in this case?

@SnehaSudhirG  Pull requests can't be merged when there are merge conflicts. After you resolve the conflicts, you can sign off again.
Conflicting files

articles/automation/automation-linux-hrw-install.md

For help with resolving merge conflicts, refer to the Contributor Guide, or try the Docs Support channel in Teams.

Thank you for your suggestion @RafaelRuales. The change has been made in a different PR. I'll close this PR now.


Reinforce universal newlines for orchestration template

proposed in https://github.com/ManageIQ/manageiq/issues/2082
We now ensure every saved template content has newline character "\n"
and the last line ends with  a newline

Nice! :+1:

What will happen with existing records?  Do they need to be recalculated in a migration?  Does it matter since it only affects developers?

@bzwei Since this fixes that issue in question, please change your commit message to have the text Fixes #2082 instead.  This let's GitHub know to auto-close the issue when the PR is merged.

@Fryguy I don't think there is a need for migration right now since the orchestration support is not rolled out yet.


Issue with VSCode's latest version.

Hey there folks!
Am I the only who is experiencing problems with this plugin and VSCode's latest version ?
My current version is 1.19.0.
Thanks in advance, for any kind of response!

Can you provide a GitHub repository I can clone that demos your problems. Then I can investigate.

@dbaeumer Yes mate, I think this one can help you

Trying to run npm install on that repro produces:
npm ERR! code 128
npm ERR! Command failed: C:\Program Files\Git\cmd\git.EXE checkout fbce4b9e478f808634a98dac48901ec6ed4ee9fd
npm ERR! fatal: reference is not a tree: fbce4b9e478f808634a98dac48901ec6ed4ee9fd
npm ERR!

npm ERR!      C:\Users\dirkb\AppData\Roaming\npm-cache\_logs\2017-12-21T09_03_18_122Z-debug.log

for me.
Can you provide me with a more self contained repository that demos this. And what exactly is not working for you.

All the others are private repositories, so I think now, but problem is auto fix on save. What you think ?

I'm also having a problem with eslint.autoFixOnSave not working.  However, I found that if I disable editor.formatOnSave that it starts working again.


Fix VSCode launch config for getting stuck when launching

:tada: This PR is included in version 0.8.0 :tada:
The release is available on GitHub release
Your semantic-release bot :package::rocket:


Vin/ADC7 in schematic

Hey, guys, awsome work!
On the wiring diagram, Vcc is connected to the A7 pin in the Arduino Nano, is that correct?
I have a battery pack which I'll use because it is rechargeable. I intended to connect the 5V regulated output from the driver board to the Vin Arduino pin.
Will try and give some feedback on my attempt here!
-Caio

Reread the build instructions. My bad! This is used to check the battery. Closing issue.


Support for: var x = x ?? throw new ArgumentNullException("x");

Please, support modern way to check for null
public class Foo
{
    object x;

    public Foo(object x)
    {
        this.x = x ?? throw new ArgumentNullException(nameof(x));
    }
}

C#7 syntax support is being tracked in #2455.
Support for Throw Expressions will be included in that issue.
We will post an update here once Throw Expressions are supported, but I'm going to close this issue as support will be tracked in #2455.


The Pile's _FEATURE spec seems to be incorrect

Describe the bug
If you look at https://huggingface.co/datasets/the_pile/blob/main/the_pile.py:
For "all"

the pile_set_name is never set for data
there's actually an id field inside of "meta"

For subcorpora pubmed_central and hacker_news:

the meta is specified to be a string, but it's actually a dict with an id field inside.

Steps to reproduce the bug
Expected results
Feature spec should match the data I'd think?
Actual results
Specify the actual results or traceback.
Environment info

datasets version:
Platform:
Python version:
PyArrow version:

Hi @dlwh, thanks for reporting.
Please note, that the source data files for "all" config are different from the other configurations.
The "all" config contains the official Pile data files, from https://mystic.the-eye.eu/public/AI/pile/
All data examples contain a "meta" dict with a single "pile_set_name" key:
In [1]: from datasets import load_dataset
        ds = load_dataset("the_pile", "all", split="train", streaming=True)
        item = next(iter(ds))
Downloading builder script: 9.09kB [00:00, 4.42MB/s]

In [3]: item["meta"]
Out[3]: {'pile_set_name': 'Pile-CC'}

On the other hand, all the other subset configs data files come from the Pile preliminary components directory: https://mystic.the-eye.eu/public/AI/pile_preliminary_components/
For theses components, the "meta" field may have different keys depending on the subset: "id", "language", "pmid",... Because of that, if we had kept the dict data format for the "meta" field, we would have an error when trying to concatenate different subsets, whose "meta" keys are not identical. In order to avoid that, the "meta" field is cast to str in all these cases, so that there is no incompatibility in their "meta" data type when concatenating.
You can check, for example, that for "pubmed_central" the "meta" field is cast to str:
In [4]: from datasets import load_dataset
        ds = load_dataset("the_pile", "pubmed_central", split="train", streaming=True)
        item = next(iter(ds))

In [5]: item["meta"]
Out[5]: "{'id': 'PMC6071596'}"

Feel free to reopen this issue if you have further questions.


Support multiple key-value pairs for same type meshConfigExtensionProvider

Currently, all of the meshConfigExtensionProvider are single one-offs, given that they can only exist as a single field in the meshConfigExtensionProvider: merge_iop.go#L168. I have a use case for the different AuthorityPolicy CRDs to use a different EnvoyExtAuthzHTTP but only one can exist at a time right now, even if it has a unique name. The meshConfigExtensionProvider struct can be updated to instead use map[key] EnvoyExtAuthzHTTP where the name is key. This would allow multiple of them to exist and able to be used in the mesh without error.

can you share more details about your nstallation (with istioctl or IstioOperator), a demo iop file would be better.

Do you want to use different providers for the same workload? I think even it's possible to specify different EnvoyExtAuthzHTTP  providers, the current limitation is one workload can only have one provider. Check this for more info https://github.com/istio/istio/issues/34041.

Ya, this can be marked as a duplicate of that open issue. Thanks for the reference. Will post any further discussion there.

Closed as a dup of https://github.com/istio/istio/issues/34041


scrollView inside bottomSheet

scroll view and list view have scroll problem when we put them inside anchor-bottom-sheet-behavior
actually android:nestedScrollingEnabled="true" not woking while its working with normal bottom sheet.

Hi, could you please provide:

a demonstration of expected behavior
a demonstration of actual behavior
ideally, a code sample showing usage

We haven't tested ScrollView and ListView children, although we use RecyclerViews extensively.

ScrollView and ListView scroll down normally but can not scrolled up.
but NestedScrollView working right Instead ScrollView
and NonScrollListView inside NestedScrollView working right instead ListView.
thanks.


[rtl,i2c] Rename FDATA READ field to READB

The name READ shadows the uvm_reg_field read() member function in the ral generated package.
This renaming should not affect the real hardware, only the programming model.

CHANGE AUTHORIZED: hw/ip/i2c/data/i2c.hjson
CHANGE AUTHORIZED: hw/ip/i2c/rtl/i2c_core.sv
CHANGE AUTHORIZED: hw/ip/i2c/rtl/i2c_reg_pkg.sv
CHANGE AUTHORIZED: hw/ip/i2c/rtl/i2c_reg_top.sv

I don't really understand why this is an important change to make right now. Renaming (unless there is a really good reason) should be avoided, especially in the RTL.

IIUC, ral.fdata.read shadows the read() function of the uvm_reg_field class, of which ral.fdata is an instance


Enhance variable handling

Adds handling of stringified booleans
Add integer validations
Move variable handling into sections in init.pp
Group spec tests for failures

@ghoneycutt if you like both PRs, please merge this one first. Rebasing will be easier on https://github.com/ghoneycutt/puppet-monit/pull/5

Thanks


Get copy writing for landing page drop section

Describe the feature you would like to request
Currently all of the Drop section are about Tokens. we need copy writing for Tickets and NFT
Provide a brief explanation of why this feature is necessary
Explain why is this feature necessary here.
Acceptance Criteria
List down criterias that should be included in this issue. This is to help reviewers look out for expected changes in PR.

[ ] Criteria 1
[ ] Criteria 2

Provide an estimation of how long the developers should spend on implementing this feature
Estimations can be in terms of hours or a specific deadline.
References
Include any URLs, screenshots, or source code that would be helpful as reference or inspiration towards implementing the feature.

Solved in PR109 from issue #111


Change Resource ID  to Asset ID

Description
I have changed the column name Resource ID to Asset ID in asset-list line number 76.
Fixes # (issue)
#1063
Type of change
documentation change
Please delete options that are not relevant.
List any documentation updates that are needed for the Wiki

Nice, this change looks much cleaner. Thank you. I think lines 505 and 646 need to be updated as well. They seem to be hard-coded references to the old table names. If you can make that update this should be good to go.


Please add a license file

I'd like to add this to awesome-zsh-plugins, but it doesn't have a license file.
Please add a license file - if you don't have one in mind,  I recommend using choosealicense.com to help choose an appropriate one.
Thanks!

Hi, thanks for reaching out.
I have a license file,  it can be found here.

Thanks. Could you please add a screen shot?

Thanks. Could you please add a screen shot?

Sure, I'm doing a big refractor at the moment, once that's finilised I'll add a usage GIF and update the docs.
Could you also let me know how you came across this repo? Thanks.

I use GitHub's earch to look for new zsh plugins and themes every day or two to keep the list updated, then order the results by recently updated.

Hi, added screenshot and docs (couldn't get a GIF unfortunately).

pngs are fine, I don't think there are any reasonably recent browsers that can't display them.


Programming exercises: Fix import from file not importing build values

Checklist
General

[x] This is a small issue that I tested locally and was confirmed by another developer on a test server.
[x] Language: I followed the guidelines for inclusive, diversity-sensitive, and appreciative language.
[x] I chose a title conforming to the naming conventions for pull requests.

Client

[x] Important: I implemented the changes with a very good performance, prevented too many (unnecessary) REST calls and made sure the UI is responsive, even with large data.
[x] I strictly followed the client coding and design guidelines.
[x] Following the theming guidelines, I specified colors only in the theming variable files and checked that the changes look consistent in both the light and the dark theme.
[x] I documented the TypeScript code using JSDoc style.
[x] I translated all newly inserted strings into English and German.

Motivation and Context

Fix issue #9183
Description

There was a discrepancy between server and client, where the server exports the windfile value with key windfile, while the client expects windFile. Some conditions were also added to the buildplan component to make sure values from file were correctly imported.
Steps for Testing

Prerequisites:

1 Instructor

Create the exercise with custom docker image and buildscript
Export the programming exercise (Download exercise button)
Import exercise from file
Check that Build script and docker image were correctly imported

Testserver States

[!NOTE]
These badges show the state of the test servers.
Green = Currently available, Red = Currently locked
Click on the badges to get to the test servers.

Review Progress

Performance Review

[ ] I (as a reviewer) confirm that the client changes (in particular related to REST calls and UI responsiveness) are implemented with a very good performance
[ ] I (as a reviewer) confirm that the server changes (in particular related to database calls) are implemented with a very good performance

Code Review

[ ] Code Review 1
[ ] Code Review 2

Manual Tests

[ ] Test 1
[ ] Test 2

Test Coverage

Summary by CodeRabbit
Summary by CodeRabbit

New Features

Introduced a new property isImportFromFile in relevant components to enhance functionality and manage file imports effectively.

Improvements

Updated all references from windFile to windfile across components and services for consistent property naming.

Bug Fixes

Ensured that all logic and components accurately reflect the updated property structure without breaking existing functionalities.

Tests

Updated test suites to align with the new property naming and ensure accurate testing of component behaviors.

It seems there is an edge case when importing an exercise with a custom docker image.

@pzdr7 Thnx for noticing the issue, it should be fixed now.

Something I noticed is that the import from file does not seem to trigger a proper solution / template build.

Yes, this is a known issue #8562


Add blanks card

Pull Request Test Coverage Report for Build 277

58 of 65 (89.23%) changed or added relevant lines in 8 files are covered.
1 unchanged line in 1 file lost coverage.
Overall coverage decreased (-0.07%) to 89.101%

Changes Missing Coverage
Covered Lines
Changed/Added Lines
%

src/main/java/seedu/address/logic/parser/AddCardCommandParser.java
14
15
93.33%

src/main/java/seedu/address/model/card/Card.java
22
23
95.65%

src/main/java/seedu/address/model/card/FillBlanksCard.java
12
14
85.71%

src/main/java/seedu/address/storage/XmlAdaptedCard.java
1
4
25.0%

Files with Coverage Reduction
New Missed Lines
%

src/main/java/seedu/address/storage/XmlSerializableAddressBook.java
1
87.5%

Totals

Change from base Build 273:
-0.07%

Covered Lines:
2011

Relevant Lines:
2257

💛  - Coveralls


Fix compilation with openssl 3.0

Fedora rawhide updated its openssl version to 3.0.
voms needs a minor fix to compile with it.

I withdraw this PR in favour of #98. That is more complete.


add functional tests for remote auth

related to this issue https://github.com/F5Networks/f5-common-python/pull/785

depends on https://github.com/F5Networks/f5-common-python/issues/786

ill deal with once we get Jenkins up


Develop

@s17t in future please send pull requests for changes independently (instead of bundling many commits together) and wait for review for at least couple of days.


fix: make priority calculations consistent for TestTxMempool_ReapMaxBytes

Description
This test is currently hyper flakey because it doesn't calculate priorities consistently due to the txs being different sizes.
closes #1132

realized that we have duplicate tests in cat, so I fixed those as well.


CB-8735 set CDP_ENV to PUBLIC_CLOUD when CM server starts rather than…

… with API
Previously, we set this env var with API call after them CM server has started.
However, CM team would like to rely on this env var during CM startup so they can
initialise the application accordingly. Making this change in the cm.settings
file is not viable as the different initialisation processes do not use this file
and it would be too late for the CM server to use this file hence the -env server
argumentum.

@lacikaaa I had to change the implementation to use -env as CM server arg rather than the settings file. Please re-review the changes.


Heiman Smart Siren EF (WarningDevice-EF-3.0)

Hi @ebaauw,
I am trying to setup Heiman Smart Siren. It seems to be properly exposed to the Homekit, but it looks like I'm missing the logic behind it.
Device exposed as a light:
    "26": {
        "etag": "47c6efa1604635b79db1fe577177acab",
        "hascolor": false,
        "manufacturername": "HEIMAN",
        "modelid": "WarningDevice-EF-3.0",
        "name": "Warning device 26",
        "state": {
            "alert": "none",
            "reachable": true
        },
        "swversion": "2019.5.23",
        "type": "Warning device",
        "uniqueid": "cc:cc:cc:ff:fe:d5:23:79-01"
    },

and as a Sensor for battery status I guess:
    "58": {
        "config": {
            "battery": 100,
            "on": true,
            "pending": [],
            "reachable": true
        },
        "ep": 1,
        "etag": "842608aafdd4d826751826ab1d40cd7e",
        "manufacturername": "HEIMAN",
        "modelid": "WarningDevice-EF-3.0",
        "name": "WarningDevice-EF-3.0",
        "state": {
            "alarm": false,
            "lastupdated": "none",
            "lowbattery": false,
            "tampered": false
        },
        "swversion": "2019.5.23",
        "type": "ZHAAlarm",
        "uniqueid": "cc:cc:cc:ff:fe:d5:23:79-01-0500"
    }

If I'm turning the siren "light" on, it only turns on for 2 seconds and turning itself off.
Can you explain please what I am missing?
Thanks a lot in advance!

This has been some time since I looked at this.  Looking at the code, homebridge-hue sends {"alert": "select"} to the “light” state.  The deCONZ REST API plugin set a duration of 1 (second) for select and 300 (5 minutes) for lselect.  I don’t think my Heiman Siren honours the duration (cannot test it right now), so I never noticed this before.
I activate my siren from deCONZ gateway rules, so I never bothered to expose lselect or blink to HomeKit.  Not sure how best to do that either - I’m open to suggestions.

@ebaauw thanks a lot for a quick reply.
Maybe to expose it as 3 separate lamps (select, lselect and blink) + to add the duration param?
I prefer to manage everything in Homekit, but just for me and I guess also other's knowledge, can you please share the example for your siren config on deCONZ side?

@ebaauw btw, just realized that I am getting a warning from the plugin side:
[2/3/2020, 2:37:03 PM] [Hue] Zigbee-GW: /sensors/58: warning: unknown ZHAAlarm sensor {"config":{"battery":100,"on":true,"reachable":true},"ep":1,"etag":"842608aafdd4d826751826ab1d40cd7e","manufacturername":"HEIMAN","modelid":"WarningDevice-EF-3.0","name":"WarningDevice-EF-3.0","state":{"alarm":null,"lastupdated":"none","lowbattery":null,"tampered":null},"swversion":"2019.5.23","type":"ZHAAlarm","uniqueid":"cc:cc:cc:ff:fe:d5:23:79-01-0500"}

I am getting a warning from the plugin

The warning is because I didn't whitelist this particular model.  It shouldn't affect the functionality, as it provides exactly the same ZigBee IAS WD interface as the older model.

can you please share the example for your siren config on deCONZ side?

In the deCONZ REST API, you'd simply create a rule with an action to set the siren's state.alert.

Maybe to expose it as 3 separate lamps

I'll have a look at exposing select, lselect and blink as separate services, each with their own On characteristic.

to add the duration param

There's currently no support for this by the REST API plugin, but this could easily be added re-using state.ontime (so PUT a body of {"alert": "lselect", "ontime": 10} to /lights/id/state to sound the alarm for 10 seconds instead of 300).
Homebridge-hue already exposes state.ontime to HomeKit for /lights resources exposed as Valve, using the standard SetDuration / Remaining Duration characteristics.  Apple's Home app only supports these characteristics for Valve services, hence the restriction.  They do work brilliantly in Eve for other services though; homebridge-zp uses this to expose the sleep timer on Sonos zone players.
So you'd either have to expose your siren as a Valve, or use Eve to create a HomeKit scene, which can then be recalled from the Home app (or from Siri).

I'll have a look at exposing select, lselect and blink as separate services, each with their own On characteristic.

No can do; I would need to refactor the code too much.
Instead, I now expose the SIren as an Outlet, with additional Duration and Mute characteristics.  Apple's Home app doesn't show these, but Eve supports them alright.  If you leave Duration on 0, homebridge-hue will issue an {"alert": "select"} when setting On; if you set it > 0, it will issue {"alert": "lselect", "ontime": Duration}.  If you set Mute, homebridge-hue will issue {"alert": "blink", "ontime": Duration}.  The On characteristic will remain on for the duration of the warning; it will switch off automatically afterwards.  You can also switch it off manually, to stop the active warning.
You can either set Duration and Mute once in Eve, and then use the tile in Home to issue the corresponding warning, or create a HomeKit scene in Eve, containing On, Duration, and Mute, and recall the scene from Home (or Siri).  Note that Duration and Mute reset on homebridge restart.  Note that you need deCONZ REST API v2.05.73 for support of state.ontime, or compile the REST API plugin yourself from my commit above.

In v0.11.52.


Cut a new release

Hi! Thanks for maintaining this great project.
With wlroots 0.6.0 giving a soname bump, this project will need another release before we can update wlroots in Arch Linux.

I'm currently maintaining cage for Arch Linux.
Building the 0.1 release of cage against wlroots 0.6 fails with:
1/9] Generating<EMAIL_ADDRESS>[2/9] Compiling C object<EMAIL_ADDRESS>[3/9] Compiling C object<EMAIL_ADDRESS>[4/9] Compiling C object<EMAIL_ADDRESS>FAILED<EMAIL_ADDRESS>cc -Icage@exe -I. -I.. -I/usr/include/libdrm -I/usr/include/pixman-1 -flto -fdiagnostics-color=always -pipe -D_FILE_OFFSET_BITS=64 -Wall -Winvalid-pch -Wextra -Wpedantic -Werror -std=c11 -O3 -DWLR_USE_UNSTABLE -Wall -Wundef -Wno-unused-parameter -march=x86-64 -mtune=generic -O2 -fno-plt -D_FORTIFY_SOURCE=2 -fPIE -MD -MQ<EMAIL_ADDRESS>-MF<EMAIL_ADDRESS>-o<EMAIL_ADDRESS>-c ../xdg_shell.c
../xdg_shell.c: In function ‘popup_unconstrain’:
../xdg_shell.c:102:14: error: ‘struct wlr_output’ has no member named ‘lx’
   .x = output->lx - view->x,
              ^~
../xdg_shell.c:103:14: error: ‘struct wlr_output’ has no member named ‘ly’
   .y = output->ly - view->y,
              ^~
[5/9] Compiling C object<EMAIL_ADDRESS>[6/9] Compiling C object<EMAIL_ADDRESS>[7/9] Compiling C object<EMAIL_ADDRESS>FAILED<EMAIL_ADDRESS>cc -Icage@exe -I. -I.. -I/usr/include/libdrm -I/usr/include/pixman-1 -flto -fdiagnostics-color=always -pipe -D_FILE_OFFSET_BITS=64 -Wall -Winvalid-pch -Wextra -Wpedantic -Werror -std=c11 -O3 -DWLR_USE_UNSTABLE -Wall -Wundef -Wno-unused-parameter -march=x86-64 -mtune=generic -O2 -fno-plt -D_FORTIFY_SOURCE=2 -fPIE -MD -MQ<EMAIL_ADDRESS>-MF<EMAIL_ADDRESS>-o<EMAIL_ADDRESS>-c ../output.c
../output.c: In function ‘handle_output_damage_frame’:
../output.c:204:7: error: implicit declaration of function ‘wlr_output_damage_make_current’; did you mean ‘wlr_output_damage_add_whole’? [-Werror=implicit-function-declaration]
  if (!wlr_output_damage_make_current(output->damage, &needs_swap, &damage)) {
       ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
       wlr_output_damage_add_whole
../output.c:270:7: error: implicit declaration of function ‘wlr_output_damage_swap_buffers’; did you mean ‘wlr_output_damage_add_box’? [-Werror=implicit-function-declaration]
  if (!wlr_output_damage_swap_buffers(output->damage, &now, &damage)) {
       ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
       wlr_output_damage_add_box
cc1: all warnings being treated as errors
[8/9] Compiling C object<EMAIL_ADDRESS>ninja: build stopped: subcommand failed.

It would be very awesome, if you could tag a new release, so that we can update wlroots to 0.6.

@dvzrv Not sure what you're showing with the output: wlroots 0.6.0 included breaking changes that Cage 0.1 did not contain.
In any case, thanks for notifying me. I have released Cage 0.1.1 so that you can package it in Arch Linux with wlroots 0.6.0 :)


Remove LICENSE and yarn.lock example

Aforementioned files are included when downloading the repo with create-spicetify-app and I think they shouldn't be for the following reasons:
LICENSE
Users should choose their own LICENSE. Right now it comes with the MIT license, with you as the copyright holder. I'm not an expert on this, but doesn't that make you the owner of every project generated?
yarn.lock
I think it's a good idea to run npn install or yarn after downloading/generating the project files, so the lockfile matches the users preferred package manager. For example, this package uses the yarn.lock from spicetify-creator, while I use npm, which will generate a package-lock.json.

Sound good. A few additions:

For a better overview I would turn this repo into a monorepo with create-spicetify-app and spicetify-creator meaning those packages would be in the same branch, but separate folders.
.gitignore and README.md would also be good to be included in the generate files script

I agree a Monorepo will make things way easier. But wouldn't it make more sense to turn the spicetify-creator repo into the Monorepo? (Because of its name)

Yeah, that may be a better idea.


[Bug] After using compression, DICOM files rendereed as brighter

Describe the Bug
As discussed during the office hours on July 4th, I am raising this issue for further investigation. Here is the background information regarding the issue. Please take a look at the anonymized DICOM file, which includes both the original and compressed versions.
We have converted the DICOM file to the compression format/transfer syntax using dmctk to "1.2.840.10<IP_ADDRESS>.51", which is the "JPEG Baseline (Processes 2 & 4): Default Transfer Syntax for Lossy JPEG 12-bit Image Compression (Process 4 only)." However, when the image is loaded onto the CS3D viewport, it appears much brighter, as if the window level has been changed. Upon checking the metadata, there are no indications of such changes. Further investigation revealed that the image has different RescaleSlope and RescaleIntercept metadata values. Interestingly, the image appears normal when viewed on the Weasis viewer.
Also, i am using the WadoURI loader to load images from the locally hosted server via HTTP
Here are the different images viewed on OHIF and Weasis viewer

Attaching originals and compressed zip
compressed.zip
original.zip
Steps to Reproduce
I used dcmtk tool to compress the DICOM with the following command
dcmcjpeg +ee +q 100 +sm 100 <input-file> <output-file>
Loaded image onto OHIF and Weassis to re-produce the issue
The current behavior
Image is appearing to be brighter as mentioned in above screenshot
The expected behavior
Image to be not bright and should look like viewed in Weasis in screenshot earlier
OS
macOS
Node version
None
Browser
Safari 17.5, Chrome Version 126.0.6478.127 (Official Build) (arm64)

@sedghi, can you help here? Or can you guide me to look into this issue further? Thank you.

Before I begin investigating, can you check with the latest OHIF master and Cornerstone 3D?https://viewer-dev.ohif.org/localbasichttps://www.cornerstonejs.org/live-examples/local.html


Hommagic: Requesting for new Modes and Settings additon for use in devices that can control more than one load

Hi,
Greetings from Hommagic Home Automation Systems, India. Most of our products support up to 3 loads to be controlled from a single device. This means that a device with device id xyz123 can control for example, 3 lights. By using just an OnOff trait, it would be impossible to address each loads and their parameters separately. The solution here would be to use Modes. Request you to kindly add the following modes , synonyms and settings to Google Smart Home to facilitate the compatibility of such devices as ours with Google Smart Home.
Modes                                          |  Modes_Synonyms

first switch, switch one
second switch, switch two
third switch, switch three
on timer for first switch, first on timer, on timer of first switch
on timer for second switch, second on timer, on timer of second switch
on timer for third switch, third on timer, on timer of third switch
off timer for first switch, first off timer, off timer of first switch
off timer for second switch, second off timer, off timer of second switch
off timer for third switch, third off timer, off timer of third switch
brightness of first switch, first switch brightness, brightness of switch one
brightness of second switch, second switch brightness, brightness of switch two
brightness of third switch, third switch brightness, brightness of switch three
Settings                                 |   Settings_synonyms

activate, arm
deactivate, disarm
increase, increment
decrease, decrement
H3, 3 hour, three hour
H5, 5 hour, five hour
H6, 6 hour, six hour
H7, 7 hour, seven hour
H9, 9 hour, nine hour
H10, 10 hour, ten hour
H11, 11 hour, eleven hour
H12, 12 hour, twelve hour
H13, 13 hour, thirteen hour
H14, 14 hour, fourteen hour
H15, 15 hour, fifteen hour
H16, 16 hour, sixteen hour
H17, 17 hour, seventeen hour
H18, 18 hour, eighteen hour
H19, 19 hour, nineteen hour
H20, 20 hour, twenty hour
H21, 21 hour, twenty one hour
H22, 22 hour, twenty two  hour
H23, 23 hour, twenty three hour
H24, 24 hour, twenty four hour
M15, 15 minutes, fifteen minutes
M30, 30 minutes, thirty minutes
M45, 45 minutes, fourty five minutes, forty five minutes
Regards,
Deepak Jayakumar
Director,
Hommagic Home Automation Systems,
www.hommagicindia.com

Would it make more sense to break up that device into three virtual devices that can be controlled independently?

Hi Fleker,
thanks for getting back for our query. We have already thought about splitting up the device into multiple virtual devices. However, it complicates our device side implementations and the implementation of our official android and ios apps. We are making use of the google cloud IOT service for our products. We are also quite unsure whether Google cloud IOT allows the concept of splitting up devices into virtual devices that make use of secured MQTT connection that involves public-private key pairs for connection. (Please correct me if I am wrong) Moreover, we feel that the straight forward solution would be to implement those modes and settings into the repository. There may arise requirements as such as ours from other clients of Google in near future, looking into the trend towards the product developments in the industry.
Regards,
Deepak Jayakumar
Director,
Hommagic Home Automation Systems,
www.hommagicindia.com

Would it make more sense to break up that device into three virtual devices that can be controlled independently?
Hi Fleker,
thanks for getting back for our query. We have already thought about splitting up the device into multiple virtual devices. However, it complicates our device side implementations and the implementation of our official android and ios apps. We are making use of the google cloud IOT service for our products. We are also quite unsure whether Google cloud IOT allows the concept of splitting up devices into virtual devices that make use of secured MQTT connection that involves public-private key pairs for connection. (Please correct me if I am wrong) Moreover, we feel that the straight forward solution would be to implement those modes and settings into the repository. There may arise requirements as such as ours from other clients of Google in near future, looking into the trend towards the product developments in the industry.

Regards,
Deepak Jayakumar
Director,
Hommagic Home Automation Systems,
www.hommagicindia.com

We also work with a device that supports up to 4 loads (outputs) and 4 switches (inputs). Users can connect any kind of device to the loads: lights, heaters, plug, doors/locks... so we present each load as a separate device and we use the appropriate type of device and traits for each of the channels.
We think this is the right approach as you can leverage all the existing devices and traits. Your users will be able to access the device using standard google home application and voice commands. For instance using commands like "switch on light 1" or whatever name they give each of the virtual devices instead of changing modes and sending custom commands of your "single" device.
In our implementation when we sync the user devices we use the device id and custom attributes to store all the information that we need to send the request to the real device. For instance, if our real device has the id "ASD123" in our systems/applications and in "channel 1" the user has connected a light with the name "Red light", we give the virtual device the id "ASD123|C1" and set it to type "light". Then when a user says "turn on the red light" we will receive in our google home handler the request, which contains the device id "ASD123|C1" so we know that we have to turn on the channel 1 of the ASD123 device.

stom attributes

Dear dtemes,
thanks a lot for commenting and that's so interesting to know. Do you have any links that explains in detail how these virtual devices can be set up and how the mapping of virtual to real devices can be implemented in firebase functions?
Thanks a lot in advance.
Regards,
Deepak Jayakumar
Director,
Hommagic Home Automation Systems,
www.hommagicindia.com

Unfortunately we do not have any link with explanations, but it should not be complicated, if your device has 3 channels, when a user requests a device sync instead of sending back the response with a single device, just send 3 different devices. Use a composite device id that consists in the real device id plus the channel, so when you process requests you can decompose it and know which device and channel you have to act on.
David

Unfortunately we do not have any link with explanations, but it should not be complicated, if your device has 3 channels, when a user requests a device sync instead of sending back the response with a single device, just send 3 different devices. Use a composite device id that consists in the real device id plus the channel, so when you process requests you can decompose it and know which device and channel you have to act on.
David

Dear David,
that was helpful indeed. We will try that option. Have a great weekend!
@Fleker: Thanks to you as well.
Since I feel that the solution to our issue is already here, I am closing this issue. Thanks to both of you for your support.
Regards,
Deepak Jayakumar
Director,
Hommagic Home Automation Systems,
www.hommagicindia.com


Remove search indexing step

Do not send policies to Rummager to add to the search index. This is now handled by the publishing API.
https://trello.com/c/qBXoGeWi/510-remove-rummager-code-from-policy-publisher
Marked as "do not merge" until policies have been fully migrated to the new index.

The publishing API is now sending policy docs to rummager, so this is ready to merge.


need to run 'make' twice - fails on first run

Something very odd requiring 'make' to need to be run twice before globbing works properly.

First 'make' ends with:
./miniperl -Ilib make_ext.pl cpan/PerlIO-via-QuotedPrint/pm_to_blib  MAKE="make" LIBPERL_A=libperl.a
Running pm_to_blib for cpan/PerlIO-via-QuotedPrint directly
./miniperl -Ilib make_ext.pl cpan/Pod-Checker/pm_to_blib  MAKE="make" LIBPERL_A=libperl.a
'^4A^23^39^29^08^B1^4Aa^08^36^24^23^28^25^23^1A^25^39K^BF^EE^U' and '^4A^23^39^29^08^B1^4Aa^08^36^24^23^28^25^23^1A^25^39K^BF^EE^U' are identical (not
Can't copy ^4A^23^39^29^08^B1^4Aa^08^36^24^23^28^25^23^1A^25^39K^BF^EE^U to ^4A^23^39^29^08^B1^4Aa^08^36^24^23^28^25^23^1A^25^39K^BF^EE^U: EDC5129I No
such file or directory. at Makefile.PL line 26.
Unsuccessful Makefile.PL(cpan/Pod-Checker): code=33024 at make_ext.pl line 532.
makefile:577: recipe for target 'cpan/Pod-Checker/pm_to_blib' failed
make: *** [cpan/Pod-Checker/pm_to_blib] Error 129
MAKE of PERL tree failed.
Subsequent make has the following:
Writing Makefile for PerlIO::via::QuotedPrint
Skip ../../lib/PerlIO/via/QuotedPrint.pm (unchanged)
./miniperl -Ilib make_ext.pl cpan/Pod-Checker/pm_to_blib  MAKE="make" LIBPERL_A=libperl.a
Generating a Unix-style Makefile
Writing Makefile for Pod::Checker
cp lib/Pod/Checker.pm ../../lib/Pod/Checker.pm
"../../miniperl" "-I../../lib" "-I../../lib" podchecker.PL podchecker
Extracting podchecker (with variable substitutions)
cp podchecker blib/script/podchecker
/u/ibmuser/perlport/perl5/cpan/Pod-Checker/../../miniperl "-I../../lib" -MExtUtils::MY -e 'MY->fixin(shift)' -- blib/script/podchecker
./miniperl -Ilib make_ext.pl cpan/Pod-Escapes/pm_to_blib  MAKE="make" LIBPERL_A=libperl.a
Running pm_to_blib for cpan/Pod-Escapes directly
./miniperl -Ilib make_ext.pl dist/if/pm_to_blib  MAKE="make" LIBPERL_A=libperl.a

this problem seems to have 'disappeared'. I doubt it really has. Switching over to 'dynamic builds' since that seems easier to diagnose problems and not have multiple copies of code to worry about (plus smaller executables)

fixed rebasing to 'blead'

indeed it has not 'disappeared'. There is a simpler test that shows the failure: tests/intermittent.pl fails intermittently when run with ASCII (appears that output is not properly being tagged?)


[WIP] kitura: update to Swift 5.2

Checklist:

[x] Read the Code of Conduct and Contributing Guidelines.

[x] Followed the commit message guidelines.

[x] Stack adheres to Appsody stack structure.

Modifying an existing stack:

[x] Updated the stack version in stack.yaml

Updates the Kitura stack to Swift 5.2 (depends on #779 - needs rebasing once that is merged)
Related Issues:

@djones6 @ianpartridge any update on this PR now that #779 has been merged?