Add option to enable garbage collection

Based on #28
Closes #63
Added one commit to bring the branch up to date with latest upstream
ref https://github.com/ddelange/docker-registry.helm/pull/1 for testing purposes, this can be installed with:
helm install --namespace ... https://github.com/ddelange/docker-registry.helm/releases/latest/download/helm-chart-docker-registry-2.2.0.tgz

cc @canterberry @kuzaxak

@canterberry what do you think? its opt-in, non-breaking, should be safe to merge?

First: thank you! I know you don't have to contribute anything at all, but you did! I and the community are grateful, and I don't show that gratitude early and often enough. So thank you.
Now, let's talk about how we can get this done!
Your general approach seems fine to me -- a new configuration block, clearly documented in the README, and disabled by default. When enabled, there's a cronjob that runs at some configurable frequency, using the registry's own CLI and configuration to perform the garbage collection. Great!
Can you distill that down into a [near-]completely additive changeset?
Rationale: You've done some refactoring here that goes above and beyond, which is great holistically, but in terms of code review, makes it much more difficult to evaluate the impact the changeset will have on existing code. For this chart in particular, I'm very hesitant to review any changes that aren't a slam-dunk, because I'm super cautious about breaking it, and since I'm not a user, personally, I rely on tidy changesets and easy code reviews to build that confidence to ship.
Another small thing: no need to increment the version in Chart.yaml. That's something I do as part of the release process, in case there are multiple PRs ready for merge around the same time.
Let's go! :tada:

Hi @canterberry 👋

For this chart in particular, I'm very hesitant to review any changes that aren't a slam-dunk, because I'm super cautious about breaking it, and since I'm not a user, personally, I rely on tidy changesets and easy code reviews to build that confidence to ship.

I can totally understand.

Can you distill that down into a [near-]completely additive changeset?

If you do a ctrl+F for include in the diff of this PR, there will be hits in both deployment.yaml and cronjob.yaml which require the same blocks. Turning this PR into an additive changeset would basically mean copy-pasting all of deployment.yaml into cronjob.yaml, and any future changes would need to happen in both places.
If you do a ctrl+F for define in the diff of this PR, you'll see the three blocks that were moved from deployment.yaml to _helpers.tpl (1:1 without changes) so that they can be used by both yamls via include.
I don't want to try to convince you to merge a PR you don't feel safe merging, but maybe there's a way of getting you a diff view that helps you review the PR. If you'd open these side by side, and do a visual inspect, maybe the triviality of the change becomes evident and we can get closer to that slam-dunk level? :)

envs

before
after

volumeMounts

before
after

volumes

before
after

I'll revert the version bump in any case. Please let me know what you think!

Would CI help boost confidence? e.g. https://github.com/helm/chart-testing-action
I think their example workflow would shows there's no changes to the rendered deployment.yaml

Thank for your diligence. I can tell you're trying to make it easier for me, and I appreciate the effort! It's not what I need, though, so I'd like to redirect that energy toward achieving our mutual goal of getting this welcome feature delivered.
In order to get this PR merged, please make it [near-]completely additive. No refactoring, no formatting changes. Just what is strictly necessary to deliver the feature as described. Only then will I feel comfortable reviewing the changeset. At that point, you might expect some minor feedback or changes requested, but that cycle time would be much shorter and I think we could get this merged quite quickly.

Just so you know, I have done some due diligence here and am not being blindly dismissive! I've tried reviewing the changeset multiple times, even again today, and it's exceedingly difficult to do with any degree of confidence because the changeset is not as identical as you describe. There are many minor deviations -- collectively a non-trivial refactoring. Further, without a comprehensive test suite to evaluate the correctness of all classes of variance in the chart output, an equality check on a single known output is insufficient to provide a satisfactory degree of confidence (although any such test case would be an improvement over nothing at all, and I'd love to have such a suite in this highly configurable chart!)

Hi @canterberry,
I've opened #68 with additional commit fd7fdca.
Once that merges, this PR will become a refactor-PR, with as diff the revert commit d78c010.
Is that what you are aiming for?

@ddelange Once you rebase and/or merge the latest into this PR, I'll take a thorough look. I think it makes sense, conceptually, that the CronJob's pod(s) and the Deployment's pod(s) run with matching environments and volumes. The only potential issue I see coming up in review is whether (and to what extent) any functional changes or regressions might have slipped in. None have yet caught my eye, though.

To inspect the changes in this PR, I ran the following command from a local clone of this PR's branch:
$ helm template --namespace meta-namespace --set namespace=target-namespace  --set garbageCollect.enabled=true drc .

In both the resulting CronJob and Deployment manifests, there were a couple of extra newlines preceding the env block:
              env:

                - name: REGISTRY_HTTP_SECRET
                  valueFrom:
                    secretKeyRef:
                      name: drc-docker-registry-secret
                      key: haSharedSecret
                - name: REGISTRY_STORAGE_FILESYSTEM_ROOTDIRECTORY
                  value: "/var/lib/registry"

While this doesn't seem to have any functional impact (helm upgrade --install --dry-run ... with the same arguments comes back successful), it's something that looks visually off, and I'd like to see that fixed. Other than that, I've finished a review pass and LGTM. I'd like to let it "bake" for a day or two to give others a change to review as well, just in case we've missed something.

env whitespaces fixed in 52a5d4b
tested with
helm template --debug . \
  --set serviceAccount.create=true \
  --set priorityClassName=high \
  --set extraEnvVars[0].name=TEST_NAME \
  --set extraEnvVars[0].value=TEST_VALUE \
  --set secrets.htpasswd=abc \
  --set tlsSecretName=abc \
  --set garbageCollect.enabled=true \
  --set proxy.enabled=true \
  --set storage=s3 /
  --set secrets.s3.secretKey=abc /
  --set secrets.s3.accessKey=def /
  --set s3.region=us-42 /
  --set s3.bucket=abc /
  --set s3.encrypt=abc

I think we're not there yet. This might be a sensible Github Workflow to comment (and edit that comment) with a diff on a PR:
alias helm_test_template='helm template --debug \
  --set serviceAccount.create=true \
  --set priorityClassName=high \
  --set podAnnotations.test=annotation \
  --set extraEnvVars[0].name=TEST_NAME \
  --set extraEnvVars[0].value=TEST_VALUE \
  --set secrets.htpasswd=abc \
  --set tlsSecretName=abc \
  --set garbageCollect.enabled=true \
  --set proxy.enabled=true \
  --set storage=s3 /
  --set secrets.s3.secretKey=abc /
  --set secrets.s3.accessKey=def /
  --set s3.region=us-42 /
  --set s3.bucket=abc /
  --set s3.encrypt=abc'
diff -u <(helm_test_template https://github.com/twuni/docker-registry.helm/archive/refs/heads/main.tar.gz) <(helm_test_template .)

gives in the ```diff syntax:
--- /dev/fd/63	2022-08-10 10:48:29.000000000 +0200
+++ /dev/fd/62	2022-08-10 10:48:29.000000000 +0200
@@ -12,7 +12,7 @@
     release: RELEASE-NAME
 type: Opaque
 data:
-  haSharedSecret: "S2pTbHFaeEtCZ2ppTHY3bQ=="
+  haSharedSecret: "TnZBakJNSWVpbXRKeWFSUw=="
   proxyUsername: ""
   proxyPassword: ""
 ---
@@ -99,7 +99,7 @@
         release: RELEASE-NAME
       annotations:
         checksum/config: 581c8cf6d59449d6c89ebf8ec1bef05751a9c8e281ca31f99c4e0291e054bfaf
-        checksum/secret: 153f24ee9a430e533197ba266c83c185b4f95d38cd6ee547c93eca76a1969b85
+        checksum/secret: 25156342abc38ff3b671e698c348aa9d5726d62a1a9bcb539437febc7e5b8ccc
     spec:
       securityContext:
         fsGroup: 1000
@@ -122,9 +122,9 @@
             httpGet:
               path: /
               port: 5000
-          resources:
+          resources:
             {}
-          env:
+          env:
             - name: REGISTRY_HTTP_SECRET
               valueFrom:
                 secretKeyRef:
@@ -132,14 +132,14 @@
                   key: haSharedSecret
             - name: REGISTRY_STORAGE_FILESYSTEM_ROOTDIRECTORY
               value: "/var/lib/registry"
-          volumeMounts:
-            - name: data
-              mountPath: /var/lib/registry/
+          volumeMounts:
             - name: "RELEASE-NAME-docker-registry-config"
               mountPath: "/etc/docker/registry"
-      volumes:
-        - name: data
-          emptyDir: {}
+            - name: data
+              mountPath: /var/lib/registry/
+      volumes:
         - name: RELEASE-NAME-docker-registry-config
           configMap:
             name: RELEASE-NAME-docker-registry-config
+        - name: data
+          emptyDir: {}

^ opened #70

Released in v2.2.1.


tap-google-sheets documentation needs more details

Migrated from GitLab: https://gitlab.com/meltano/hub/-/issues/179
Originally created by @mattesilver on 2021-12-08 16:01:08

I'm trying to configure tap-google-sheets for the first time.
https://hub.meltano.com/extractors/google-sheets page links to a google document describing adding a page to google search console.
Why google document? Doesn't Meltano have a documentation pages?
I'm sure the applicable information is somewhere in that document, but it's very confusing.

View 5 previous comments from the original issue on GitLab


Show claim information on transaction page

Not sure where exactly, but would be good to link claim information to a transaction:
https://explorer.lbry.io/tx/c8f97c7d6a1f312563d0b624053fb71f5b54cabb6cd3b5865b0e1de74c3d3c4c#output-0
should show: https://explorer.lbry.io/claims/6a0fcce2b1a8103b6eb80c45440f95866113fc63
or
should show: https://explorer.lbry.io/claims/21a1dc5fc37e06bf6e551ce52de38f27c0e2cc11
https://explorer.lbry.io/tx/2438dea1ae1622084aa64efe9fa110ee7136e16d551e74a93baa9fca3445fd2a#output-0

I initially thought of linking the CLAIM label to the claim itself, but I suppose we could also add a popover toggled on click or hover which shows a summary of the claim details.


Documentation for PDB support for custom resource with scale subresource

KEP: https://github.com/kubernetes/enhancements/blob/master/keps/sig-apps/20190412-pdb-support-for-custom-resources-with-scale-subresource.md
Tracking issue: https://github.com/kubernetes/enhancements/issues/981
Merged PR: https://github.com/kubernetes/kubernetes/pull/76294
/milestone 1.15
cc @christianh814

/assign @bradamant3

/milestone 1.15

Hi @mortent , @Bradamant3, @sftim  can this be approved at the state it is right now? We are looking to have all PR for release 1.15 merged by June 10th. Let me know if there is anything docs team can assist.

Readable English, valid Markdown, it makes sense to me.
/lgtm

/approve


please advise for VI61 development

hi there.
I have a VI61 and I'd like to extend this project to handle it. However, it seems like the format of packages doesn't quite line up; where I expected the vendor ID to appear I get 00 14 0e.
Take a look:
0000   00 1f fc 58 16 89 ff ff 53 03 01 1f 01 00 2d 00
0010   dc c3 9c 5c 00 00 00 00 8c 6d 02 00 8d ff ff ff
0020   14 00 00 00 14 00 00 00 00 00 00 00 00 00 00 00
0030   00 00 00 00 00 00 00 00 04 00 00 00 00 00 00 00
0040   14 f0 00 00 14 0e 00 40 14 64 00 04 14 00 00 25
0050   16 75 f7 00

The data in question is in the 0040 line.
I couldn't get wireshark to decode the "leftover capture data" as USB Audio, can you perhaps help with that?
Thanks. And if @baggypants or @abridgewater could weigh in, that'd be great. I can't find any other way to contact any of you, except perhaps @le1ca via email (but they hadn't touched the project in a while).
Thanks for your attention.

I have partial VI61 support in my working tree... but not committed because the device communication wasn't working properly and I didn't have time to sort it out and then the entire mess dropped away from my attention. IIRC, I had it working as far as file compatibility but not for talking to the hardware.
I couldn't get wireshark to do that either, so I ended up "just" learning to pick out the MIDI data "by eye".  That was a temporary skill, so it seems to have faded.  But a bit of looking through the given packet data reminds me: The USB Audio MIDI data is padded out for three MIDI bytes to four USB packet bytes.
So your actual packet looks more like f0 00 00 0e 00 40 64 00 04 00 00 25 75 f7. The "14" bytes at 0040 and every four positions thereafter are all saying something along the line of "MIDI packet continues, three bytes", and then the "16" at 0050 is saying "MIDI packet ends, two bytes".
Breaking it down a bit more:
f0 -- start of sysex packet
00 00 0e -- Alesis manufacturer ID
00 40 -- VI61 model ID
64 -- slot-update command
00 04 -- message length (4 bytes)
00 -- slot 0
00 25 -- offset 25 (hex, so decimal 37)
75 -- literal data
f7 -- end of sysex packet
With a bit of luck, I'll have access to hardware again starting around mid-April and can do some testing of my own.  And now that you've reminded me about it, I may go over what I've done for VI61 support so far and commit it, even if it doesn't do the protocol bits right.

I'm glad to see that you all are interested in extending the software to support more devices. I know I don't look active, but I am still sort of passively monitoring what's going on here. I'd be glad to merge a PR if one of you would like to make one. However, there isn't much I can do to help out with new device support since I'm not interested in buying a full suite of MIDI controllers at the moment. ;)

wonderful!
i can capture a whole bunch of sessions with the windows config tool (i'm using it via wine, it seems to work) and send them over. now that i understand how to read the capture data i might even be able to patch the tool properly.
@le1ca can you recall anything in particular you did/had to do to get the usb audio parts to show up as structured data in wireshark?

FWIW, i've got some success with this patch:
diff --git a/alesisvsysex/protocol/model.py b/alesisvsysex/protocol/model.py
index 1a9e134..52a5c86 100644
--- a/alesisvsysex/protocol/model.py
+++ b/alesisvsysex/protocol/model.py
@@ -134,6 +134,28 @@ class VI49Knobs (CompoundComponent):
         ('knob12', Knob, {'cc': IntValue(0x1f)})
     ]

+class VI61Knobs (CompoundComponent):
+
+    _COMPONENTS = [
+        ('knob1',  Knob, {'cc': IntValue(0x14)}),
+        ('knob2',  Knob, {'cc': IntValue(0x15)}),
+        ('knob3',  Knob, {'cc': IntValue(0x16)}),
+        ('knob4',  Knob, {'cc': IntValue(0x17)}),
+        ('knob5',  Knob, {'cc': IntValue(0x18)}),
+        ('knob6',  Knob, {'cc': IntValue(0x19)}),
+        ('knob7',  Knob, {'cc': IntValue(0x1a)}),
+        ('knob8',  Knob, {'cc': IntValue(0x1b)}),
+        ('knob9',  Knob, {'cc': IntValue(0x1c)}),
+        ('knob10', Knob, {'cc': IntValue(0x1d)}),
+        ('knob11', Knob, {'cc': IntValue(0x1e)}),
+        ('knob12', Knob, {'cc': IntValue(0x1f)}),
+        ('knob13', Knob, {'cc': IntValue(0x20)}),
+        ('knob14', Knob, {'cc': IntValue(0x21)}),
+        ('knob15', Knob, {'cc': IntValue(0x22)}),
+        ('knob16', Knob, {'cc': IntValue(0x23)})
+    ]
+
+
 class Pad (BasicComponent):

     _PARAMS = [
@@ -257,6 +279,24 @@ class VI49Switches3 (CompoundComponent):
         ('button36', Button, {'cc': IntValue(0x5b)})
     ]

+class VI49Switches4 (CompoundComponent):
+
+    _COMPONENTS = [
+        ('button37', Button, {'cc': IntValue(0x50)}),
+        ('button38', Button, {'cc': IntValue(0x51)}),
+        ('button39', Button, {'cc': IntValue(0x52)}),
+        ('button40', Button, {'cc': IntValue(0x53)}),
+        ('button41', Button, {'cc': IntValue(0x54)}),
+        ('button42', Button, {'cc': IntValue(0x55)}),
+        ('button43', Button, {'cc': IntValue(0x56)}),
+        ('button44', Button, {'cc': IntValue(0x57)}),
+        ('button45', Button, {'cc': IntValue(0x58)}),
+        ('button46', Button, {'cc': IntValue(0x59)}),
+        ('button47', Button, {'cc': IntValue(0x5a)}),
+        ('button48', Button, {'cc': IntValue(0x5b)})
+    ]
+
+
 class VIUnknown (BasicComponent):

     _PARAMS = [
@@ -441,3 +481,51 @@ class AlesisVI49 (AlesisModel):
                  ('Pitch Wheel', 'pwheel'))),
                ('Sustain', 'horizontal',
                 (('Sustain Pedal', 'sustain'),)))
+
+class AlesisVI61 (AlesisModel):
+
+    _PORT_PREFIX  = "VI61:VI61 MIDI 2"
+    _DEVICE_ID    = [0x00, 0x40]
+    _SLOT_CONFIG  = True
+    _LENGTH_DELTA = 0x00
+
+    _COMPONENTS = [
+        ('unknown',   VIUnknown,    {}),
+        ('keys',      VIKeys,       {}),
+        ('roll',      VIRoll,       {}),
+        ('transport', Transport,    {}),
+        ('pwheel',    VIPitchWheel, {}),
+        ('mwheel',    VIModWheel,   {}),
+        ('sustain',   VISustain,    {}),
+        ('knobs',     VI61Knobs,    {}),
+        ('pads',      VIPads,       {}),
+        ('switches',  VI49Switches, {}),
+        ('switches2',  VI49Switches2, {}),
+        ('switches3',  VI49Switches3, {}),
+        ('switches4',  VI49Switches4, {}),
+        ('midi2din',  VIMIDI2DIN,   {})
+    ]
+
+    _GROUPS = (('Knobs', 'vertical',
+                (('Knobs', 'knobs'),)),
+               ('Switches 1-12', 'vertical',
+                (('Switches', 'switches'),)),
+               ('Switches 13-24', 'vertical',
+                (('Switches', 'switches2'),)),
+               ('Switches 25-36', 'vertical',
+                (('Switches', 'switches3'),)),
+               ('Switches 37-48', 'vertical',
+                (('Switches', 'switches4'),)),
+               ('Pads', 'vertical',
+                (('Pads', 'pads'),)),
+               ('Roll', 'horizontal',
+                (('Roll', 'roll'),)),
+               ('Transport', 'vertical',
+                (('Transport', 'transport'),)),
+               ('Keys', 'vertical',
+                (('Keys', 'keys'),)),
+               ('Mod / Pitch', 'horizontal',
+                (('Mod Wheel', 'mwheel'),
+                 ('Pitch Wheel', 'pwheel'))),
+               ('Sustain', 'horizontal',
+                (('Sustain Pedal', 'sustain'),)))

I've added this debug output code (plus installed "hexdump" for it)
diff --git a/alesisvsysex/protocol/component.py b/alesisvsysex/protocol/component.py
index db81454..95e4cb0 100644
--- a/alesisvsysex/protocol/component.py
+++ b/alesisvsysex/protocol/component.py
@@ -1,5 +1,7 @@
 import struct

+from hexdump import hexdump
+
 __all__ = ['CompoundComponent', 'BasicComponent']

 class CompoundComponent (object):
@@ -65,12 +67,22 @@ class CompoundComponent (object):

     @classmethod
     def deserialize(cls, bytes):
+        print(cls.__name__, "deserializing some bytes:");
+        hexdump(bytes);
+        print("");
         idx = 0
         args = []
         for k, comp, _ in cls._COMPONENTS:
             l = comp.num_bytes()
+            print("key: ", k, " - index ", idx, " / length: ", l);
             args.append(comp.deserialize(bytes[idx:idx+l]))
             idx += l
+
+        print("end index:", idx);
+        print("");
+        print("----");
+        print("");
+
         return cls(*args)

 class BasicComponent (object):
@@ -134,11 +146,21 @@ class BasicComponent (object):

     @classmethod
     def deserialize(cls, bytes):
+        print(cls.__name__, "deserializing some bytes:");
+        hexdump(bytes);
+        print("");
         idx = 0
         args = []
         for k, cls2, _ in cls._PARAMS:
             l = cls2.num_bytes()
+            print("key: ", k, " - index ", idx, " / length: ", l);
             args.append(cls2.deserialize(bytes[idx:idx+l]))
             idx += l
+
+        print("end index:", idx);
+        print("");
+        print("----");
+        print("");
+
         return cls(*args)

The blob it gets from the device has the right length and none of the parameters complain about invalid values.
All I've tested so far was the parameters for the keybed (non-split) and the 48 switches (only the midi channel). Inputting data via the windows application is pretty tedious. I hope we can add some automation to the alesisvsysex tool for inputting things like "ranges of numbers" or whatever.

I see that you're starting from my version. Probably the best to start from in terms of supporting multiple hardware types in the same codebase, AND in terms of being able to use files from the windows tools (though IIRC the Vmini tool uses some completely stupid save format, so that won't work).
The _LENGTH_DELTA term on the device model defaults to 0, so you don't need to set it. Otherwise, the model code looks largely similar to what I already have.
Does upload to the device work for you?  It wasn't working for me when I tried it, but that could easily be a problem with my device in one direction or another, or simply me being in a hurry.

@timo I didn't have to do anything special to get wireshark to decode it; I think it was the deb available via the Ubuntu 14.04 repo

Does upload to the device work for you? It wasn't working for me when I tried it, but that could easily be a problem with my device in one direction or another, or simply me being in a hurry.

No, it doesn't, sadly. I haven't yet dumped the USB of what our tool sends compared to what the original does. are you interested in a capture file maybe?

Probably the most useful trace to have would be an upload from the Alesis program to some configuration slot other than the first, along with the configuration file being uploaded (I can probably recover the file from the trace, but if something crazy is going on then having both would show that quite well).
Beyond that, verification that downloading from the device works would be nice. And if it doesn't, a download trace and corresponding configuration file should help get that working a bit.

I managed to spend some time with my VI61 and got some USB traces from it, including upload and download traces from both alesisvsysex and the "normal" utility running under Wine.
Preliminary analysis suggests that the sysex packets are formatted well enough, but that occasionally there are USB packets sent with more than one sysex packet.  Notably, there are cases of two sysex packets and the start of a third, with the body of the third sent in the following USB packet, thus breaking a sysex packet across a USB packet boundary. The "normal" utility only ever sends one sysex packet per USB packet.
I am once again away from my VI61, and don't currently know when I will be getting back to it, but I can work with my VI49 in the mean time, as I would expect the same packet behavior (if not necessarily failure modes) as with the VI61.
Current theory: A 1ms delay between sending sysex packets may clear things up. This would be in the for loop at the bottom of model/alesis.py. The idea is to separate the MIDI packets as sent to the kernel driver by the time between successive USB "heartbeats", leading them to be sent in separate USB packets. This may-or-may-not be a hack.

Finally pushed a seemingly-working KLUDGE to get VI61 updates to run with some semblance of reliability.  And opened an issue on my branch about finding a better set of MIDI bindings, because RtMidi is missing critical functionality, and mido is two dependencies below that.


dlib called with BGR instead of RGB?

I've been reading through your code and most detector backend wrappers convert the colorspace from BGR to RGB before calling the external detector.
However, the dlib wrapper doesn't seem to do that and AFAIK dlib does expect RGB. Is that a bug?
(also please take a look at https://github.com/serengil/deepface/pull/563#issuecomment-1257541112)

no because we are using opencv for other detectors, but dlib handles it with its way

All the image loading happens in functions.load_image, right? So that means all images loaded with cv2 there are loaded as BGR and should be converted to RGB for non-opencv detectors.
https://github.com/serengil/deepface/blob/63de372d52b1fb9b99af57c87f80f28b6d5b1f30/deepface/commons/functions.py#L92
I guess this is actually the same problem as https://github.com/serengil/deepface/issues/532 - image loading should be consistent in either BGR or RGB and all detectors can then assume they get it like that.


chore: bdd-ghfjxy-import-1585581800 to 0.0.1

chore: Promote bdd-ghfjxy-import-1585581800 to version 0.0.1

[APPROVALNOTIFIER] This PR is NOT APPROVED
This pull-request has been approved by:
To fully approve this pull request, please assign additional approvers.
We suggest the following additional approvers:
If they are not already assigned, you can assign the PR to them by writing /assign  in a comment when ready.
The full list of commands accepted by this bot can be found here.
The pull request process is described here

Needs approval from an approver in each of these files:

OWNERS

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


WFLY-13855 remote-cache-container protocol-version allowed values con…

…tains last protocol version twice
Resolves
https://issues.redhat.com/browse/WFLY-13855

@pferraro Please review.


I find some vulnerabilitys in eosio-s2wasm

will get a bounty?

Processing of hackerone.com bounty submissions is ongoing.  To date, 85 issues have been processed.  Many have been paid and closed.  Your patience is appreciated.


Add flag to disable browser error watcher

Description
It is useful for staging prober tests where we don't control some sites such as auth providers and they might cause JS or network errors that don't fail test but trigger the error watcher. The main goal of brower error watcher to catch errors in civiform and that is covered well enough by browser tests.
Checklist
General

[x] Added the correct label: < feature | bug | dependencies | infrastructure | ignore-for-release >
[ ] Created tests which fail without the change (if possible)
[ ] Extended the README / documentation, if necessary

Codecov Report

Merging #3907 (f89334f) into main (8913d4e) will not change coverage.
The diff coverage is n/a.

@@            Coverage Diff            @@
##               main    #3907   +/-   ##
=========================================
  Coverage     80.79%   80.79%
  Complexity     2454     2454
=========================================
  Files           297      297
  Lines          9668     9668
  Branches        659      659
=========================================
  Hits           7811     7811
  Misses         1602     1602
  Partials        255      255

:mega: We’re building smart automated test selection to slash your CI/CD build times. Learn more


CI improvements

[ ] enable -sys tests
[x] nightly docs
[x] #481
[x] Windows job
[x] macOS job
[ ] Enable tests for macOS job, see https://github.com/gtk-rs/gtk4-rs/issues/1235

Once #182 is merged, only gdk-x11 & gtk4 -sys are still disabled
gdk4-x11 fails with
running 2 tests
In file included from tests/constant.c:5:
tests/manual.h:3:10: fatal error: gdk/gdkx.h: No such file or directory
    3 | #include <gdk/gdkx.h>
      |          ^~~~~~~~~~~~
compilation terminated.
test cross_validate_constants_with_c ... FAILED
In file included from tests/layout.c:5:
tests/manual.h:3:10: fatal error: gdk/gdkx.h: No such file or directory
    3 | #include <gdk/gdkx.h>
      |          ^~~~~~~~~~~~
compilation terminated.
test cross_validate_layout_with_c ... FAILED

failures:

---- cross_validate_constants_with_c stdout ----
thread 'cross_validate_constants_with_c' panicked at 'called `Result::unwrap()` on an `Err` value: "compilation command \"cc\" \"-Wno-deprecated-declarations\" \"-std=c11\" \"-D__USE_MINGW_ANSI_STDIO\" \"-I/usr/include/gtk-4.0\" \"-I/usr/include/pango-1.0\" \"-I/usr/include/glib-2.0\" \"-I/usr/lib64/glib-2.0/include\" \"-I/usr/include/harfbuzz\" \"-I/usr/include/freetype2\" \"-I/usr/include/libpng16\" \"-I/usr/include/libmount\" \"-I/usr/include/blkid\" \"-I/usr/include/fribidi\" \"-I/usr/include/libxml2\" \"-I/usr/include/cairo\" \"-I/usr/include/pixman-1\" \"-I/usr/include/gdk-pixbuf-2.0\" \"-I/usr/include/graphene-1.0\" \"-I/usr/lib64/graphene-1.0/include\" \"-mfpmath=sse\" \"-msse\" \"-msse2\" \"-I/usr/include/gio-unix-2.0\" \"-pthread\" \"tests/constant.c\" \"-o\" \"/tmp/abimkklbt/constant\" failed, exit code: 1"', gdk4-x11/sys/tests/abi.rs:116:39
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace

---- cross_validate_layout_with_c stdout ----
thread 'cross_validate_layout_with_c' panicked at 'called `Result::unwrap()` on an `Err` value: "compilation command \"cc\" \"-Wno-deprecated-declarations\" \"-std=c11\" \"-D__USE_MINGW_ANSI_STDIO\" \"-I/usr/include/gtk-4.0\" \"-I/usr/include/pango-1.0\" \"-I/usr/include/glib-2.0\" \"-I/usr/lib64/glib-2.0/include\" \"-I/usr/include/harfbuzz\" \"-I/usr/include/freetype2\" \"-I/usr/include/libpng16\" \"-I/usr/include/libmount\" \"-I/usr/include/blkid\" \"-I/usr/include/fribidi\" \"-I/usr/include/libxml2\" \"-I/usr/include/cairo\" \"-I/usr/include/pixman-1\" \"-I/usr/include/gdk-pixbuf-2.0\" \"-I/usr/include/graphene-1.0\" \"-I/usr/lib64/graphene-1.0/include\" \"-mfpmath=sse\" \"-msse\" \"-msse2\" \"-I/usr/include/gio-unix-2.0\" \"-pthread\" \"tests/layout.c\" \"-o\" \"/tmp/abi4Qbvyi/layout\" failed, exit code: 1"', gdk4-x11/sys/tests/abi.rs:156:37

& gtk4 with
In file included from tests/layout.c:5:
tests/manual.h:3:10: fatal error: gtk/gtk-a11y.h: No such file or directory
    3 | #include <gtk/gtk-a11y.h>
      |          ^~~~~~~~~~~~~~~~
compilation terminated.
test cross_validate_layout_with_c ... FAILED
In file included from tests/constant.c:5:
tests/manual.h:3:10: fatal error: gtk/gtk-a11y.h: No such file or directory
    3 | #include <gtk/gtk-a11y.h>
      |          ^~~~~~~~~~~~~~~~
compilation terminated.
test cross_validate_constants_with_c ... FAILED

failures:

---- cross_validate_layout_with_c stdout ----
thread 'cross_validate_layout_with_c' panicked at 'called `Result::unwrap()` on an `Err` value: "compilation command \"cc\" \"-Wno-deprecated-declarations\" \"-std=c11\" \"-D__USE_MINGW_ANSI_STDIO\" \"-I/usr/include/gtk-4.0\" \"-I/usr/include/pango-1.0\" \"-I/usr/include/glib-2.0\" \"-I/usr/lib64/glib-2.0/include\" \"-I/usr/include/harfbuzz\" \"-I/usr/include/freetype2\" \"-I/usr/include/libpng16\" \"-I/usr/include/libmount\" \"-I/usr/include/blkid\" \"-I/usr/include/fribidi\" \"-I/usr/include/libxml2\" \"-I/usr/include/cairo\" \"-I/usr/include/pixman-1\" \"-I/usr/include/gdk-pixbuf-2.0\" \"-I/usr/include/graphene-1.0\" \"-I/usr/lib64/graphene-1.0/include\" \"-mfpmath=sse\" \"-msse\" \"-msse2\" \"-I/usr/include/gio-unix-2.0\" \"-pthread\" \"tests/layout.c\" \"-o\" \"/tmp/abiA8bnMZ/layout\" failed, exit code: 1"', gtk4/sys/tests/abi.rs:156:37
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace

---- cross_validate_constants_with_c stdout ----
thread 'cross_validate_constants_with_c' panicked at 'called `Result::unwrap()` on an `Err` value: "compilation command \"cc\" \"-Wno-deprecated-declarations\" \"-std=c11\" \"-D__USE_MINGW_ANSI_STDIO\" \"-I/usr/include/gtk-4.0\" \"-I/usr/include/pango-1.0\" \"-I/usr/include/glib-2.0\" \"-I/usr/lib64/glib-2.0/include\" \"-I/usr/include/harfbuzz\" \"-I/usr/include/freetype2\" \"-I/usr/include/libpng16\" \"-I/usr/include/libmount\" \"-I/usr/include/blkid\" \"-I/usr/include/fribidi\" \"-I/usr/include/libxml2\" \"-I/usr/include/cairo\" \"-I/usr/include/pixman-1\" \"-I/usr/include/gdk-pixbuf-2.0\" \"-I/usr/include/graphene-1.0\" \"-I/usr/lib64/graphene-1.0/include\" \"-mfpmath=sse\" \"-msse\" \"-msse2\" \"-I/usr/include/gio-unix-2.0\" \"-pthread\" \"tests/constant.c\" \"-o\" \"/tmp/abi2lHNIo/constant\" failed, exit code: 1"', gtk4/sys/tests/abi.rs:116:39

That should be gdk/x11/gdkx.h. gtk-a11y.h does not exist in gtk4, that should be removed.
Fixing those I get some errors about symbols missing from gtk4-unix-print, probably need some adjustments in gir to add that

@jf2048 thanks, I pushed a commit fixing the gdk-x11 ffi tests. The only remaining one now is gtk-sys


Add fakes for the S3 service and use the standalone localstack

What's changing
Unit tests in the backend can benefit from a BytesIO/StringIO backed fake S3, with both FakeS3Client and FakeS3FS. Integration tests will use an existing localstack, if any.
The previously used localstack started by testcontainers has been removed.
How to test it
Just run the unit tests without the auxiiliary containers, and run the integration tests with the auxiliary containers.
Additional notes for reviewers
Fixes https://github.com/mozilla-ai/lumigator/issues/422
I already...

[x] added some tests for any new functionality
[x] updated the documentation
[x] checked if a (backend) DB migration step was required and included it if required

Not needed since this is a test improvement.

@aittalam @dpoulopoulos I'm reverting the background task patching in
https://github.com/mozilla-ai/lumigator/blob/d3c5abee2e50d5067e059c90128ef6e3edfcdf65/lumigator/python/mzai/backend/backend/tests/integration/api/routes/test_api_workflows.py#L50
The tests seem to run ok (I added a couple of extra log lines to be sure), so let's just keep the reference to this patching in case you notice the tests stalling again.

I think it'd be better to keep the mock and test the called task separately.
The main reason is that in those tests we are not evaluating whether the job completes but just that the system returns an ok. If we were to actually start the background task we'd have to wait for the job completion to test anything.
What is usually suggested in these cases is to mock the bgtask and test the method separately, which is something I will add.

I think it'd be better to keep the mock and test the called task separately. The main reason is that in those tests we are not evaluating whether the job completes but just that the system returns an ok.

Since test models are used in integration, actually the jobs are checked to completion (for example see https://github.com/mozilla-ai/lumigator/blob/236532695340a072a55c74c7bb3257cbfb2d7b70/lumigator/python/mzai/backend/backend/tests/integration/api/routes/test_api_workflows.py#L64). Currently the integration tests run in 5-6 mins but make sure that all the steps of a job are properly executed. Remember that some bugs were hidden because we didn't check the jobs to completion.


Missing features / enhancement proposal for Manage Zigbee Device / Bindings

Hi All,
First of all I hope this is the right place for this - as opposed to the homeassistant/core repository. Please comment if I'm wrong, I'll resubmit.
I would like here to point out a few missing features and unclear UX elements in the "Manage Zigbee Device" / "Bindings" Screen.
The Bindings are an important feature of the Zigbee protocol, as recognized by providing this panel in the first place.
However:

Current Bindings of a device are not shown
Unbinding is a "blind" thing. It works, but I have to know (or check with zha_toolkit) which bindings are currently active and whether they are active for a device or a group.
Layout is misleading (Clusters choice is below Groups, but should be available both for IEEE and for Group bindings)
Destination Endpoints are currently not selectable when creating / removing a binding

The current bindings of a device seem to be retrievable, at least using the zha-toolkit with the action zha_toolkit.binds_get.
Could this be built in this panel, too? Possibly with mention of the fact that the device should be waken up when clicking. They also could be cached like the rest upon registration. But maybe it should be clear that they might be outdated. Also, when creating a new bind, they could immediately be re-fetched to see if the binding succeeded.
I am adding a mockup of what I would expect (at least one verison of it, of course many other ideas are possible...).
Please apologize for the ugly design. The trash icon could also be replaced by a "break link" icon. And also the lists are just a proposal to visualize.
Kudos to all and Thanx for HA and ZHA!

I'd love to see this done as well.  it would make binding a lot easier to get into for people.  Many times people bind groups and the members not understanding how that can cause a lot of traffic that overloads your network and this would make it easy to see/fix after reading troubleshooting docs.

Hello everyone,
I think ZHA direct binding is very important because it ensures that lights can be switched on even if HA or its automation is not available. For example, when we carry out an update or are working on the automation. A rudimentary functionality should be available under all circumstances.
I think it would be good if the suggestion could be implemented in this or a similar way, because I find it really difficult to see whether all the bindings have been adopted as I intended. And if you haven't worked on it for a while, it would be much easier to continue with the work you have done so far.
Thanks
Thomas

Hi @dmulcahey , Hi all who watch this thread.
I think your idea to give bindings more room with an own page/view is quite the right direction.
I've been thinking about this idea, while experimenting with bindings in my very heterogeneous setup (IKEA, Tuya, Aqara, NOUS, Sonoff, Paul Neuhaus...). Please apologize in advance for this DLDR post, but, hey, You asked for it ;-).
Here are my thoughts...
-> An important note: With a little help from our favorite AI-enemies, I had my draft formatted a bit nicer and more readable (the tables, adding examples, and title formatting).  Every detail was verified, and the text content is 100% authored by me. I think it is very important to be always explicit and transparent on these matters, nowadays.... <-
Ideal Vision for a Bindings Map
In an ideal scenario, a second network map would display bindings graphically, allowing users to visually understand the relationships between devices. However, even if that remains aspirational, it cannot live without a tabular view (as the network panel would need, too), because it can get very difficult to visualize with many devices.
Current Challenges in Multi-Vendor Binding with ZHA
Given that one of (Z)HA’s missions is to support multi-vendor deployments and automations, the UX for handling binding must also offer a resilient and user-friendly way to handle the challenges associated with multi-vendor bindings. After experimenting with bindings in various scenarios, I’ve identified some issues, for example (and I'm quite sure it's not all...):

Binding Limitations: Some devices only allow one binding (per cluster? 2bt...).
Binding Restrictions: Some devices only support binding during the pairing phase.
Unadvertised Clusters: Certain devices, like some remotes, do not advertise all of their supported clusters (e.g., Cluster 0x0300 for Color Control), though they can still use those clusters if/when bound.
Device Wake Requirements: Many remotes and sensors require being woken up to respond to binding requests or queries. This can't be stressed enough...
Error Messaging: Frequently, a binding command reports an error, even when it succeeds.
Side-wish: Scenes Cluster Support: Some devices support the Scenes Cluster, which is great, but a whole new chapter for itself (and again, a feature that duplicates the HA-Scenes feature, so that might open a new discussion on how to honour it there...)

To manage these issues effectively, the UI should incorporate resilient tools and notices to help troubleshoot and verify bindings. For instance:

Always try to reload the bindings table immediately after binding
There should be both manual and background ways (not too-intrusive and as seldom as possible) to reload and cache binding tables
Prompt users to check setup and notify them if the device must be woken up.
Cache successful bindings and display a confidence level icon for each binding to indicate reliability.

Ideas of UI Components for Binding Management
Mainly, tables could facilitate binding management:
Current Bindings Table
Toolbar:

[x] Show / hide default (coordinator) bindings
Usual Filters for source and destination devices

Binding Name (optional)
Source Device
Source Endpoint
Cluster
Target (Device/Group)
Target Endpoint
Actions

Living Room Remote
Living Room Remote
1
OnOff (0x0006) [link]
Living Room Lights Group
1
Unbind Reload

Cellar Remote
Remote 2
1
OnOff (0x0006) [link]
Cellar Lamp
1
Unbind Reload

Garden Remote
Remote 3
1
Level Control (0x0008) [link]
Multi Powerplug
2
Unbind Reload

Thermostat Temp
Living Room Thermostat
1
Temperature Measurement (0x0402) [link]
Living Room Sensor
1
Unbind Reload

Color Control
Living Room Remote
1
Color Control (0x0300) [link]
Living Room RGB Light Group
1
Unbind Reload

This table format could provide an organized view with essential actions, icons, and filters to help users manage bindings...
(the links would be info-links that show some docs about that binding, at least for the ones that have been standardized...)
Device-Centric Bindings Table
Another idea could organize bindings by source device, with each device’s bindings displayed in a sub-table for easy overview. Maybe it makes even more sense than flat bindings, and would help group them in a more intuitive way:

Source Device
Bindings

Living Room Remote
 ClusterTarget Device/GroupTarget EndpointActions OnOff (0x0006) [link]Living Room Lights Group1Unbind Reload Color Control (0x0300) [link]Living Room RGB Light Group1Unbind Reload

Remote 2
 ClusterTarget Device/GroupTarget EndpointActions OnOff (0x0006) [link]Cellar Lamp1Unbind Reload

Remote 3
 ClusterTarget Device/GroupTarget EndpointActions Level Control (0x0008) [link]Multi Powerplug2Unbind Reload

Living Room Thermostat
 ClusterTarget Device/GroupTarget EndpointActions Temperature Measurement (0x0402) [link]Living Room Sensor1Unbind Reload

Enhancements on Device/Automation Pages/Lists (Binding Awareness)
Devices involved in bindings should display a notice or alert on their device panel - linking to the bindings page - so users are aware of existing bindings when creating automations. This should also be clearly visible in device lists.
I've been also thinking that in theory, bindings should even be handled as "shadow automations" added to the automations page (well-distinguished and with different handlers and a clear graphical distinction), but that's probably too much...
New Binding Creation Dialog
A Create New Binding dialog could allow multiple bindings to be created at once with interactive feedback:

Select Source Device: Choose the device initiating the binding.
Choose Clusters: Display the device’s advertised clusters first, followed by other standard clusters.
Select Target Devices: Choose target devices and specify target endpoints. Important note: Here it should be possible to:

Select one or more devices
Select one or more groups
Offer the User to auto-create a Group made of the selected devices (thus, give them the group), and then assign it to the source

Binding Feedback: Show status updates during binding, including prompts to wake up devices and success/failure messages (e.g., "Please wake up the device… Try 1… Success").

Summary...
This is a rough outline to ignite discussion. Incrementally improving the current panel-based UI, while adding missing features and solving bugs might be still the best first step: If the whole binding thing gets more accessible to more users, we will get more ideas and more experiences and expectations to make it better...
All the Best, and many great thanks for what we already have!


no error on empty result set. Is it ok?

Hi!
When query returns nothing I expect to get error pgx.ErrNoRows ("no rows in result set"). But there is not error. Is it bug of feature?
Example
package main

import (
	"context"
	"errors"
	"fmt"
	"log"

	"github.com/georgysavva/scany/pgxscan"
	pgx "github.com/jackc/pgx/v4"
	"github.com/jackc/pgx/v4/pgxpool"
)

func main() {
	dsn := "DATABASE_URL"
	conn, err := pgx.Connect(context.Background(), dsn)
	if err != nil {
		log.Fatal(err)
	}
	defer conn.Close(context.Background())

	var id int64
	err = conn.QueryRow(context.Background(), "select id from user where id = 11111").Scan(&id)
	if err != nil {
		fmt.Printf("pgx: equal? %v\n", errors.Is(err, pgx.ErrNoRows))
	}

	ctx := context.Background()
	db, _ := pgxpool.Connect(ctx, dsn)

	var users []*User
	err = pgxscan.Select(ctx, db, &users, `SELECT * FROM user where id = 11111`)
	if err != nil {
		fmt.Printf("equal? %v\n", errors.Is(err, pgx.ErrNoRows))
	}
}

type User struct {
	ID   int64
	Name string
}

I get output
pgx: equal? true

Hi. This is not a bug; it's a feature.
The pgxscan.Select() method you call is meant to get a list of rows. If there are no rows, the list is just empty. So it's expected and not an error.
The only time scany returns pgx.ErrNoRows is when you call pgxscan.ScaOne() or pgxscan.Get(), with the latter being just a wrapper around the former. These two methods expect to get exactly one row, and if there are none, they produce pgx.ErrNoRows. The same logic is behind the native conn.QueryRow() you used above. You ask it to scan a row, but there is none, so it returns an error.
Feel free to reopen if you have more questions.

Thank you!


Fixes for Strings.pl-PL.xaml

Fixes for pl-PL (Polish) language XAML file.
@Timthreetwelve small fixes for language file. Please review and merge. Thanks

Thank you!

@Timthreetwelve please update wiki page https://github.com/Timthreetwelve/WUView/wiki/Contribute-a-Translation


[crash] Exception in server tick loop - "This shouldn't happen"

OTG Plugin or Mod

[x] OTG Mod for Forge
[ ] OTG Plugin for Spigot

OTG Version

[x] 1.12.2_v8_r1
[ ] 1.12.2_v7_DEV_r26
[ ] 1.12.2-v6
[ ] 1.12.2-v5
[ ] 1.11.2-v8
[ ] 1.11.2-v9
[ ] 1.10.2-v21
[ ] Other - specify here

Forge or Spigot Versions
[Forge 1.12.2...2847]
Server/Client Log
[Description: Exception in server tick loop
java.lang.RuntimeException: This shouldn't happen
at com.pg85.otg.network.ServerConfigProvider.indexSettings(ServerConfigProvider.java:415)
at com.pg85.otg.network.ServerConfigProvider.loadBiomes(ServerConfigProvider.java:208)
at com.pg85.otg.network.ServerConfigProvider.loadSettings(ServerConfigProvider.java:134)
at com.pg85.otg.network.ServerConfigProvider.(ServerConfigProvider.java:74)
at com.pg85.otg.forge.world.WorldLoader.getOrCreateForgeWorld(WorldLoader.java:362)
at com.pg85.otg.forge.world.OTGWorldType.getBiomeProvider(OTGWorldType.java:146)
at net.minecraft.world.WorldProvider.init(WorldProvider.java:58)
at net.minecraft.world.WorldProvider.setWorld(WorldProvider.java:40)
at net.minecraft.world.WorldServer.(WorldServer.java:116)
at net.minecraft.server.integrated.IntegratedServer.loadAllWorlds(IntegratedServer.java:132)
at net.minecraft.server.integrated.IntegratedServer.init(IntegratedServer.java:233)
at net.minecraft.server.MinecraftServer.run(MinecraftServer.java:486)
at java.lang.Thread.run(Thread.java:745)]
What other plugins are you running?
[MC.eternal modpack + a couple of extra favourite mods (Like OTG)]
Description
[Already functioning world crashes upon world start and sends me back to start screen (Vanilla fix feature)]
[I was hoping to be able to play minecraft! x(]

I find the server tick loop exception to be pretty strange since i don't play on a server

Minecraft has run internally on a server even in single player for a while now.

I think I fixed it. Rolled back some mod versions after the MC eternal update, in order to play in my world again. I think betweenlands added some biomes in the latest update, which made me ran out of biome IDs. And then I rolled back some backups and deleting otg core too.


default springboot application got wrong message in index.html

Describe the bug
Default springboot application got wrong message in index.html.
It should be hello world!!! not hello word!!!
Screenshots

Would you please send a pull request?


Neuer Adapter: innoxel

Forum thread:
https://forum.iobroker.net/topic/50871/neuer-adapter-innoxel

RE-CHECK!

RE-CHECK!

Automated adapter checker
ioBroker.froeling

:thumbsup: No errors found
ioBroker.innoxel

[ ] :heavy_exclamation_mark: [E605] No actual year found in copyright. Please add "Copyright (c) 2022 matthsc<EMAIL_ADDRESS>at the end of README.md
[ ] :heavy_exclamation_mark: [E701] No actual year found in LICENSE. Please add "Copyright (c) 2022 matthsc<EMAIL_ADDRESS>at the start of LICENSE
[ ] :eyes: [W400] Cannot find "innoxel" in latest repository

ioBroker.lg-thinq

:thumbsup: No errors found
ioBroker.openhab

[ ] :heavy_exclamation_mark: [E104] No common.titleLang found in io-package.json
[ ] :heavy_exclamation_mark: [E150] No common.connectionType found in io-package.json
[ ] :heavy_exclamation_mark: [E152] No common.dataSource found in io-package.json
[ ] :heavy_exclamation_mark: [E140] width and height of logo are not equal
[ ] :heavy_exclamation_mark: [E301] Tests on Travis-ci.com are broken. Please fix.
[ ] :heavy_exclamation_mark: [E605] No actual year found in copyright. Please add "Copyright (c) 2017-2022 bluefox<EMAIL_ADDRESS>at the end of README.md
[ ] :heavy_exclamation_mark: [E701] No actual year found in LICENSE. Please add "Copyright (c) 2017-2022 bluefox<EMAIL_ADDRESS>at the start of LICENSE
[ ] :eyes: [W113] Adapter should support compact mode
[ ] :eyes: [W505] setTimeout found in "main.js", but no clearTimeout detected

ioBroker.rainbird

[ ] :heavy_exclamation_mark: [E150] No common.connectionType found in io-package.json
[ ] :heavy_exclamation_mark: [E152] No common.dataSource found in io-package.json
[ ] :heavy_exclamation_mark: [E605] No actual year found in copyright. Please add "Copyright (c) 2022 Marius Burkard<EMAIL_ADDRESS>at the end of README.md
[ ] :heavy_exclamation_mark: [E701] No actual year found in LICENSE. Please add "Copyright (c) 2022 Marius Burkard<EMAIL_ADDRESS>at the start of LICENSE

Add comment "RE-CHECK!" to start check anew

Automated adapter checker
ioBroker.froeling

:thumbsup: No errors found
ioBroker.innoxel

[ ] :heavy_exclamation_mark: [E605] No actual year found in copyright. Please add "Copyright (c) 2022 matthsc<EMAIL_ADDRESS>at the end of README.md
[ ] :heavy_exclamation_mark: [E701] No actual year found in LICENSE. Please add "Copyright (c) 2022 matthsc<EMAIL_ADDRESS>at the start of LICENSE
[ ] :eyes: [W400] Cannot find "innoxel" in latest repository

ioBroker.lg-thinq

:thumbsup: No errors found
ioBroker.openhab

[ ] :heavy_exclamation_mark: [E104] No common.titleLang found in io-package.json
[ ] :heavy_exclamation_mark: [E150] No common.connectionType found in io-package.json
[ ] :heavy_exclamation_mark: [E152] No common.dataSource found in io-package.json
[ ] :heavy_exclamation_mark: [E140] width and height of logo are not equal
[ ] :heavy_exclamation_mark: [E301] Tests on Travis-ci.com are broken. Please fix.
[ ] :heavy_exclamation_mark: [E605] No actual year found in copyright. Please add "Copyright (c) 2017-2022 bluefox<EMAIL_ADDRESS>at the end of README.md
[ ] :heavy_exclamation_mark: [E701] No actual year found in LICENSE. Please add "Copyright (c) 2017-2022 bluefox<EMAIL_ADDRESS>at the start of LICENSE
[ ] :eyes: [W113] Adapter should support compact mode
[ ] :eyes: [W505] setTimeout found in "main.js", but no clearTimeout detected

ioBroker.rainbird

[ ] :heavy_exclamation_mark: [E150] No common.connectionType found in io-package.json
[ ] :heavy_exclamation_mark: [E152] No common.dataSource found in io-package.json
[ ] :heavy_exclamation_mark: [E605] No actual year found in copyright. Please add "Copyright (c) 2022 Marius Burkard<EMAIL_ADDRESS>at the end of README.md
[ ] :heavy_exclamation_mark: [E701] No actual year found in LICENSE. Please add "Copyright (c) 2022 Marius Burkard<EMAIL_ADDRESS>at the start of LICENSE

Add comment "RE-CHECK!" to start check anew

lol ... you directly run into the year change :-)) Please update ... and I will do other review later

lol ... you directly run into the year change :-)) Please update ... and I will do other review later

Then here some review comments:

please sync the adapter settings and make sure default values for all are in io-package native section. I think there are some missing.
To automatically encrypt the password you also need sto edd "encryptedNative" withthat field into io-package.  Right now the password is not getting stored encrypted!
Please put the admin dependency into section "globalDependencies" instead of "dependencies" in io-package (else admin on the host where adapter runs needs to be in that version ... but there might be no admin on the host
Please add roles to https://github.com/matthsc/ioBroker.innoxel/blob/main/io-package.json#L103-L125 ... please choose matching values from https://github.com/ioBroker/ioBroker/blob/master/doc/STATE_ROLES.md
If you require nodejs 12 then please add this to the package.json as "engine" definition https://docs.npmjs.com/cli/v7/configuring-npm/package-json#engines
maybe better check in https://github.com/matthsc/ioBroker.innoxel/blob/main/src/main.ts#L180 that there is no former timeout running ... else you would overwrite it and can not end him anymore. Or can this never happen?

Just some small stuff, Just poke here when you have checked and addressed it.
PS: Happy new year

Then here some review comments:

please sync the adapter settings and make sure default values for all are in io-package native section. I think there are some missing.
To automatically encrypt the password you also need sto edd "encryptedNative" withthat field into io-package.  Right now the password is not getting stored encrypted!
Please put the admin dependency into section "globalDependencies" instead of "dependencies" in io-package (else admin on the host where adapter runs needs to be in that version ... but there might be no admin on the host
Please add roles to https://github.com/matthsc/ioBroker.innoxel/blob/main/io-package.json#L103-L125 ... please choose matching values from https://github.com/ioBroker/ioBroker/blob/master/doc/STATE_ROLES.md
If you require nodejs 12 then please add this to the package.json as "engine" definition https://docs.npmjs.com/cli/v7/configuring-npm/package-json#engines
maybe better check in https://github.com/matthsc/ioBroker.innoxel/blob/main/src/main.ts#L180 that there is no former timeout running ... else you would overwrite it and can not end him anymore. Or can this never happen?

Just some small stuff, Just poke here when you have checked and addressed it.
PS: Happy new year

A happy new year to you too, and thanks for the review and feedback!
I think I addressed all points and published as 0.1.1:

please sync the adapter settings and make sure default values for all are in io-package native section. I think there are some missing.

double checked everything, but didn't find any discrepancies between io-package.json, adapter-config.d.ts, and admin settings.tsx.

To automatically encrypt the password you also need sto edd "encryptedNative" withthat field into io-package.  Right now the password is not getting stored encrypted!

Done. Hope it is ok to have the field in both encryptedNative and protectedNative? Or should I only use one?

Please put the admin dependency into section "globalDependencies" instead of "dependencies" in io-package (else admin on the host where adapter runs needs to be in that version ... but there might be no admin on the host

Done

Please add roles to https://github.com/matthsc/ioBroker.innoxel/blob/main/io-package.json#L103-L125 ... please choose matching values from https://github.com/ioBroker/ioBroker/blob/master/doc/STATE_ROLES.md

Done

If you require nodejs 12 then please add this to the package.json as "engine" definition https://docs.npmjs.com/cli/v7/configuring-npm/package-json#engines

Done

maybe better check in https://github.com/matthsc/ioBroker.innoxel/blob/main/src/main.ts#L180 that there is no former timeout running ... else you would overwrite it and can not end him anymore. Or can this never happen?

It can't shouldn't happen, but I try to clear it now before setting it

A happy new year to you too, and thanks for the review and feedback!
I think I addressed all points and published as 0.1.1:

please sync the adapter settings and make sure default values for all are in io-package native section. I think there are some missing.

double checked everything, but didn't find any discrepancies between io-package.json, adapter-config.d.ts, and admin settings.tsx.

To automatically encrypt the password you also need sto edd "encryptedNative" withthat field into io-package.  Right now the password is not getting stored encrypted!

Done. Hope it is ok to have the field in both encryptedNative and protectedNative? Or should I only use one?

Please put the admin dependency into section "globalDependencies" instead of "dependencies" in io-package (else admin on the host where adapter runs needs to be in that version ... but there might be no admin on the host

Done

Please add roles to https://github.com/matthsc/ioBroker.innoxel/blob/main/io-package.json#L103-L125 ... please choose matching values from https://github.com/ioBroker/ioBroker/blob/master/doc/STATE_ROLES.md

Done

If you require nodejs 12 then please add this to the package.json as "engine" definition https://docs.npmjs.com/cli/v7/configuring-npm/package-json#engines

Done

maybe better check in https://github.com/matthsc/ioBroker.innoxel/blob/main/src/main.ts#L180 that there is no former timeout running ... else you would overwrite it and can not end him anymore. Or can this never happen?

It can't shouldn't happen, but I try to clear it now before setting it

Hope it is ok to have the field in both encryptedNative and protectedNative? Or should I only use one?

Two fields, two purposes ... :-) but in my eyes anything in encrspted should also be in protected

encryptedNative is for auto encryption
protectedNative makes sure that only your adapter instance or Admin adapter are allowed to read these fields. For all other "requestors" (getObject) the fields listed there will be removed before object is returned

Rest is fine, welcome in the repo


Image shortcode error with “jpg” file extensions

FYI, after updating @11ty/eleventy-img to 0.8.0 I was getting this error:
TypeError: Cannot read property 'reverse' of undefined

https://github.com/clenemt/eleventy-webpack/blob/2b0242d3abc63c7135bcad11b9fce73e7ff03a00/utils/shortcodes.js#L86
After reading through the changes, it turned out to be related to this fix https://github.com/11ty/eleventy-img/issues/64#issuecomment-778842404.
Regardless of whether the source image uses the jpg or jpeg extension, the returned object will use the jpeg key.
Here’s how I fixed it in my project:
let extension = path.extname(src).slice(1).toLowerCase();

// Normalize “jpg” extension to match what @11ty/eleventy-img does
extension = extension == 'jpg' ? 'jpeg' : extension;

Thanks, will have a look !


refactor: change weekly to daily checks and remove unsupported package docker-compose

typo in code

Please check and merge