letters not show in macos catalina

hi
how can i fix this?

We have been working on this and will have a confirmed fix release available soon.

Thanks for the hard work TechAdeptRDD . A few of us patiently waiting 😄

🤷🏽♂

Any progress on this? It has been almost 4 months...

Hello,
Thank you for following up. I had given up on the wallet and had not checked.
I have now installed v3.0.1-osx, but I still have the same problem. I have attached a picture of the wallet.  The wallet is unusable.
I’m very disappointed.
Thank you
Thaabit

On 30 Apr 2020, at 17:53, mrlando<EMAIL_ADDRESS>wrote:
Any progress on this? It has been almost 4 months...
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub https://github.com/reddcoin-project/reddcoin/issues/144#issuecomment-621941191, or unsubscribe https://github.com/notifications/unsubscribe-auth/AOZFLSL2MA2FCBS7KHEXYNLRPGNGPANCNFSM4JRF642Q.

I suggest you try running on Windows or Linux. You can try running the Windows version on osx under Wine or a proper VM. This issue with fonts on osx has existed for years and the developers are clearly not willing to resolve it.

Hello Henry,
Thank you for your prompt response, which I appreciate.
I think that I’ll dispose of the coins rather than frustrating myself over a poorly conceived OSX wallet.
Thank you for your kind assistance.
Stay safe.
Thaabit
Sent from my iPad

On Apr 30, 2020, at 11:16 PM, Henry Young<EMAIL_ADDRESS>wrote:

I suggest you try running on Windows or Linux. You can try running the Windows version on osx under Wine or a proper VM. This issue with fonts on osx has existed for years and the developers are clearly not willing to resolve it.
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub, or unsubscribe.

In order to accomodate MacOS Catalina changes and new build requirements,
Reddcoin (like many other cryptocurrency projects) has had to do extensive
work to achieve compatibility, and have completed most of the work required
in the last few months along with integrating other components of the
bitcoin 0.10 code base. If it was a simple fix, it would have long since
been released. A version compatible with Mac Catalina should be available
for general use in the next month or so as we complete the required
foundational work for those changes.
On Thu, Apr 30, 2020 at 6:21 PM thaabitalbertus<EMAIL_ADDRESS>wrote:

Hello Henry,
Thank you for your prompt response, which I appreciate.
I think that I’ll dispose of the coins rather than frustrating myself over
a poorly conceived OSX wallet.
Thank you for your kind assistance.
Stay safe.
Thaabit
Sent from my iPad

On Apr 30, 2020, at 11:16 PM, Henry Young<EMAIL_ADDRESS>wrote:

I suggest you try running on Windows or Linux. You can try running the
Windows version on osx under Wine or a proper VM. This issue with fonts on
osx has existed for years and the developers are clearly not willing to
resolve it.
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub, or unsubscribe.

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/reddcoin-project/reddcoin/issues/144#issuecomment-622147396,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AJNEI66KL7DJG7RY22QQ7WDRPH2V7ANCNFSM4JRF642Q
.

Might be an issue with the ancient version of Qt being used.
https://www.macworld.com/article/3528553/font-chaos-in-macos-catalina-and-how-to-deal-with-it.html

Thanks for the update @TechAdeptRDD, we will have to wait a little bit longer then.

woohoo the fix is out! the new release works just fine guys. have it running as normal on my MacBook Catalina . https://www.reddcoin.com/2020/06/13/reddcoin-core-3-10-0/

THANK YOU STEPHEN4X!
It works fine and appears to be slightly faster when booting!
Thank you again. Now I don’t have to fly blind any longer.
Thaabit

On 13 Jun 2020, at 15:38, stephen4x<EMAIL_ADDRESS>wrote:
woohoo the fix is out! the new release works just fine guys. have it running as normal on my MacBook Catalina . https://www.reddcoin.com/2020/06/13/reddcoin-core-3-10-0/ x-msg://6/url
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub https://github.com/reddcoin-project/reddcoin/issues/144#issuecomment-643625166, or unsubscribe https://github.com/notifications/unsubscribe-auth/AOZFLSPUQZCM45XELSIAROLRWN6OBANCNFSM4JRF642Q.

Thanks so much guys!!!!

On 13 Jun 2020, at 17:11, TechAdeptRDD<EMAIL_ADDRESS>wrote:
Closed #144 https://github.com/reddcoin-project/reddcoin/issues/144.
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub https://github.com/reddcoin-project/reddcoin/issues/144#event-3440875534, or unsubscribe https://github.com/notifications/unsubscribe-auth/AOZFLSPPRBCP7OIHW6NG6ILRWOJJZANCNFSM4JRF642Q.

Thank you so much to everyone involved!


lebab pt.2

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


networkName not updated on network change

networkId is updated on network change but doesn't appear to update networkName when using injectedWeb3 (MetaMask on Brave and Chrome) when logged out.
Issue seen in GSN Starter Kit when switching networks.
https://github.com/OpenZeppelin/starter-kit-gsn

@ylv-io It seems that event though networkName is updated, there is no event emitted to log this change.
https://github.com/OpenZeppelin/openzeppelin-network.js/blob/11866091daa0439581044778b5604c7837ebb6da/src/context/Web3Context.ts#L94-L100
I'm assuming perhaps this was because the event is the same as when networkId changes. Can you confirm this? If so, we should perhaps swap the order so that once the networkId change event is emitted, networkName has been changed as well.

I am seeing the current network ID and the previous network Name being displayed.

Hey @abcoathup. Thanks for digging this up. @frangio is absolutely right. It is a one line fix.

Fixed at https://github.com/OpenZeppelin/openzeppelin-network.js/commit/1944291b76c76bdc2e89378d8cdefac2815d4d20.

Manually tested with new version and now works as expected.  Thanks @ylv-io.


Eager macro-expansion failure: (wrong-number-of-arguments (2 . 2) 3)

Hello,
So I'm trying to use el-patch-defun to redefine the icomplete-completions function in order to make it look a little less ugly.
However, Emacs keeps throwing this error
Eager macro-expansion failure: (wrong-number-of-arguments (2 . 2) 3)

At first, I thought it was because the icomplete-completions function has to different parts in it's body...
The first
  (let* ((ignored-extension-re
          (and minibuffer-completing-file-name
               icomplete-with-completion-tables
               completion-ignored-extensions
               (concat "\\(?:\\`\\.\\./\\|"
                       (regexp-opt completion-ignored-extensions)
                       "\\)\\'")))
         (minibuffer-completion-table candidates))
    (minibuffer-completion-predicate
     (if ignored-extension-re
         (lambda (cand)
           (and (not (string-match ignored-extension-re cand))
                (or (null predicate)
                    (funcall predicate cand))))
       predicate))
    (md (completion--field-metadata (icomplete--field-beg)))
    (comps (icomplete--sorted-completions)
           (last (if (consp comps) (last comps)))
           (base-size (cdr last))
           (open-bracket (if require-match "(" "["))
           (close-bracket (if require-match ")" "]"))
           ;; `concat'/`mapconcat' is the slow part.
           (if (not (consp comps)))))

And then a progn
(progn ;;(debug (format "Candidates=%S field=%S" candidates name))
    (format " %sNo matches%s" open-bracket close-bracket
            (if last (setcdr last nil))
            (let* ((most-try
                    (if (and base-size (> base-size 0))
                        (completion-try-completion
                         name candidates predicate (length name) md)
                      ;; If the `comps' are 0-based, the result should be
                      ;; the same with `comps'.
                      (completion-try-completion
                       name comps nil (length name) md))))
              (most (if (consp most-try) (car most-try)
                      (if most-try (car comps) "")))
              ;; Compare name and most, so we can determine if name is
              ;; a prefix of most, or something else.
              (compare (compare-strings name nil nil)
                       most nil nil completion-ignore-case)
              (ellipsis (if (char-displayable-p ?…) "…" "..."))
              (determ (unless (or (eq t compare) (eq t most-try)))
                      (= (setq compare (1- (abs compare)))
                         (length most)
                         (concat open-bracket
                                 (cond)))
                      ((= compare (length name))
                       ;; Typical case: name is a prefix.
                       (substring most compare))
                      ;; Don't bother truncating if it doesn't gain
                      ;; us at least 2 columns.
                      ((< compare (+ 2 (string-width ellipsis))) most)
                      (t (concat ellipsis (substring most compare)
                                 close-bracket)))
              ;;"-prospects" - more than one candidate
              (prospects-len (+ (string-width))
                             (or determ (concat open-bracket close-bracket)
                                 (string-width icomplete-separator)
                                 (+ 2 (string-width ellipsis)) ;; take {…} into account
                                 (string-width (buffer-string))
                                 (prospects-max
                                  ;; Max total length to use, including the minibuffer content.
                                  (* (+ icomplete-prospects-height
                                        ;; If the minibuffer content already uses up more than
                                        ;; one line, increase the allowable space accordingly.
                                        (/ prospects-len (window-width)))
                                     (window-width)))))
              ;; Find the common prefix among `comps'.
              ;; We can't use the optimization below because its assumptions
              ;; aren't always true, e.g. when completion-cycling (bug#10850):
              ;; (if (eq t (compare-strings (car comps) nil (length most)
              ;; 			 most nil nil completion-ignore-case))
              ;;     ;; Common case.
              ;;     (length most)
              ;; Else, use try-completion.
              (prefix (when icomplete-hide-common-prefix)
                      (try-completion "" comps
                                      (prefix-len))
                      (and (stringp prefix
                                    ;; Only hide the prefix if the corresponding info
                                    ;; is already displayed via `most'.
                                    (string-prefix-p prefix most t)
                                    (length prefix)))) ;;)
              prospects comp limit)))
  (if (or (eq most-try t) (not (consp (cdr comps))))
      (setq prospects nil)
    (when (member name comps)
      ;; NAME is complete but not unique.  This scenario poses
      ;; following UI issues:
      ;;
      ;; - When `icomplete-hide-common-prefix' is non-nil, NAME
      ;;   is stripped empty.  This would make the entry
      ;;   inconspicuous.
      ;;
      ;; - Due to sorting of completions, NAME may not be the
      ;;   first of the prospects and could be hidden deep in
      ;;   the displayed string.
      ;;
      ;; - Because of `icomplete-prospects-height' , NAME may
      ;;   not even be displayed to the user.
      ;;
      ;; To circumvent all the above problems, provide a visual
      ;; cue to the user via an "empty string" in the try
      ;; completion field.
      (setq determ (concat open-bracket "" close-bracket)))
    ;; Compute prospects for display.
    (while (and comps (not limit))
      (setq comp)
      (if prefix-len (substring (car comps) prefix-len) (car comps))
      comps (cdr comps)
      (setq prospects-len
            (+ (string-width comp))
            (string-width icomplete-separator)
            prospects-len)
      (if (< prospects-len prospects-max)))
    (push comp prospects
          (setq limit t)))
  (setq prospects (nreverse prospects))
  ;; Decorate first of the prospects.
  (when prospects
    (let ((first (copy-sequence (pop prospects))))
      (put-text-property 0 (length first)
                         'face 'icomplete-first-match first)
      (push first prospects
            ;; Restore the base-size info, since completion-all-sorted-completions
            ;; is cached.
            (if last (setcdr last base-size)))))
  (if prospects
      (concat determ
              "{"
              (mapconcat 'identity prospects icomplete-separator)
              (and limit (concat icomplete-separator ellipsis))
              "}")
    (concat determ " [Matched]"))

But that's not the case. I'm still getting the error that there's too many arguments when I place the large progn inside of the let*. Which doesn't make sense, because from what I can tell it's no different from examples provided in your Radian configuration.
Here's the plain icomplete-completions function. I'm not sure why I can find why el-patch-defun is throwing this error.

Here's what I did so far just editing the docstring, and I'm still seeing the same error:
(el-patch-defun icomplete-completions (name candidates predicate require-match)
   (el-patch-concat
     "Identify prospective candidates for minibuffer completion.

The display is updated with each minibuffer keystroke during
minibuffer completion.

Prospective completion suffixes (if any) are displayed"
     (el-patch-swap ", bracketed by
one of (), [], or {} pairs.  The choice of brackets is as follows:

  (...) - a single prospect is identified and matching is enforced,
  [...] - a single prospect is identified but matching is optional, or
  {...} - multiple prospects, separated by commas, are indicated, and
          further input is required to distinguish a single one."
                    ".")
     "If there are multiple possibilities, `icomplete-separator' separates them.

The displays for unambiguous matches have ` [Matched]' appended
\(whether complete or not), or ` [No matches]', if no eligible
matches exist.")
  (let* ((ignored-extension-re
          (and minibuffer-completing-file-name
               icomplete-with-completion-tables
               completion-ignored-extensions
               (concat "\\(?:\\`\\.\\./\\|"
                       (regexp-opt completion-ignored-extensions)
                       "\\)\\'")))
         (minibuffer-completion-table candidates))
   (minibuffer-completion-predicate
          (if ignored-extension-re
              (lambda (cand)
                (and (not (string-match ignored-extension-re cand))
                     (or (null predicate)
                         (funcall predicate cand))))
            predicate))
   (md (completion--field-metadata (icomplete--field-beg)))
   (comps (icomplete--sorted-completions)
         (last (if (consp comps) (last comps)))
         (base-size (cdr last))
         (open-bracket (if require-match "(" "["))
         (close-bracket (if require-match ")" "]"))
    ;; `concat'/`mapconcat' is the slow part.
    (if (not (consp comps)))
    (progn ;;(debug (format "Candidates=%S field=%S" candidates name))
      (format " %sNo matches%s" open-bracket close-bracket
        (if last (setcdr last nil))
        (let* ((most-try
                (if (and base-size (> base-size 0))
                    (completion-try-completion
                     name candidates predicate (length name) md)
                  ;; If the `comps' are 0-based, the result should be
                  ;; the same with `comps'.
                  (completion-try-completion
                   name comps nil (length name) md))))
         (most (if (consp most-try) (car most-try)
                       (if most-try (car comps) "")))
               ;; Compare name and most, so we can determine if name is
               ;; a prefix of most, or something else.
         (compare (compare-strings name nil nil)
                 most nil nil completion-ignore-case)
         (ellipsis (if (char-displayable-p ?…) "…" "..."))
         (determ (unless (or (eq t compare) (eq t most-try)))
           (= (setq compare (1- (abs compare)))
              (length most)
             (concat open-bracket
               (cond)))
          ((= compare (length name))
                                   ;; Typical case: name is a prefix.
           (substring most compare))
                                  ;; Don't bother truncating if it doesn't gain
                                  ;; us at least 2 columns.
          ((< compare (+ 2 (string-width ellipsis))) most)
          (t (concat ellipsis (substring most compare)
               close-bracket)))
         ;;"-prospects" - more than one candidate
         (prospects-len (+ (string-width))
          (or determ (concat open-bracket close-bracket)
               (string-width icomplete-separator)
               (+ 2 (string-width ellipsis)) ;; take {…} into account
               (string-width (buffer-string))
               (prospects-max
                ;; Max total length to use, including the minibuffer content.
                (* (+ icomplete-prospects-height
                      ;; If the minibuffer content already uses up more than
                      ;; one line, increase the allowable space accordingly.
                      (/ prospects-len (window-width)))
                   (window-width)))))
               ;; Find the common prefix among `comps'.
               ;; We can't use the optimization below because its assumptions
               ;; aren't always true, e.g. when completion-cycling (bug#10850):
               ;; (if (eq t (compare-strings (car comps) nil (length most)
               ;; 			 most nil nil completion-ignore-case))
               ;;     ;; Common case.
               ;;     (length most)
               ;; Else, use try-completion.
         (prefix (when icomplete-hide-common-prefix)
             (try-completion "" comps
               (prefix-len))
          (and (stringp prefix
                     ;; Only hide the prefix if the corresponding info
                     ;; is already displayed via `most'.
                     (string-prefix-p prefix most t)
                     (length prefix)))) ;;)
         prospects comp limit)))
    (if (or (eq most-try t) (not (consp (cdr comps))))
        (setq prospects nil)
      (when (member name comps)
        ;; NAME is complete but not unique.  This scenario poses
        ;; following UI issues:
        ;;
        ;; - When `icomplete-hide-common-prefix' is non-nil, NAME
        ;;   is stripped empty.  This would make the entry
        ;;   inconspicuous.
        ;;
        ;; - Due to sorting of completions, NAME may not be the
        ;;   first of the prospects and could be hidden deep in
        ;;   the displayed string.
        ;;
        ;; - Because of `icomplete-prospects-height' , NAME may
        ;;   not even be displayed to the user.
        ;;
        ;; To circumvent all the above problems, provide a visual
        ;; cue to the user via an "empty string" in the try
        ;; completion field.
        (setq determ (concat open-bracket "" close-bracket)))
      ;; Compute prospects for display.
      (while (and comps (not limit))
        (setq comp)
        (if prefix-len (substring (car comps) prefix-len) (car comps))
        comps (cdr comps)
        (setq prospects-len
                    (+ (string-width comp))
           (string-width icomplete-separator)
           prospects-len)
        (if (< prospects-len prospects-max)))
      (push comp prospects
          (setq limit t)))
    (setq prospects (nreverse prospects))
    ;; Decorate first of the prospects.
    (when prospects
      (let ((first (copy-sequence (pop prospects))))
        (put-text-property 0 (length first)
               'face 'icomplete-first-match first)
        (push first prospects
          ;; Restore the base-size info, since completion-all-sorted-completions
          ;; is cached.
          (if last (setcdr last base-size)))))
    (if prospects
        (concat determ
          "{"
          (mapconcat 'identity prospects icomplete-separator)
          (and limit (concat icomplete-separator ellipsis))
          "}")
      (concat determ " [Matched]")))))

When does that error get thrown? Is it while evaluating the el-patch-defun form, or afterwards? While using icomplete?
Can you get a backtrace with M-x toggle-debug-on-error?
Your patch does not validate against the version of icomplete-completeions that is shipped with my Emacs (version 28 from Git). You should start by copying and pasting the entire definition, and then only modify it by adding el-patch-... forms to show the changes.

To be clear, I evaluated the el-patch-defun form in your initial comment, and I didn't get an error.

Ah, I now see the one big mistake.
For some reason, when I copied the original function into my config the formatting of the function was extremely borked. An example is, somehow, a cond was formatted as such
   ;; This is inside of another form
     (cond))
   ((some-condition))
   (another-condition)
   ;; etc. etc.

I'll have to format the entire copied function properly and try again.

Yup, got everything formatted correctly and it works fine now.


libfreshplayer does not show up in Firefox 69.0.1 64bit

Hello,
Followed the build and install procedure from README.md
libfreshwrapper-flashplayer.so is in /usr/lib64/mozilla/plugins,
/usr/lib/mozilla/plugins and ~/.mozilla/plugins. It does not
show up under plugins in firefox. Hope there is something
that can be done.
Thank you.

First, the version of Firefox looks unusual. It's not an extended support release which I believe is 68. But it's also not the current version, which is 74.
Since Flash is almost gone from popular websites, I don't really use it. So I can't say for sure if freshplayerplugin was working in 69.0.1. It works on 74.0 though.
As for the possible reasons, it may be pluginreg.dat file contains stale data. If for some reason plugin crashed, Firefox remembers that in pluginreg.dat, and doesn't try to load failed plugin again. Sometimes it helps to stop the browser, remove pluginreg.dat, and start the browser again. File is located in your profile directory. You may find where it is on about:support page, search for "Profile Directory".
Another reason is freshplayerplugin built in previous versions of an OS. If it's not fresh-built, it may help to build from source again. Also freshplayerplugin loads PepperFlash itself, so your system libraries should be relatively recent. PepperFlash from desktop Chrome usually works on almost every distro versions, but if you use PepperFlash from ChromeOS, you may need recent libc and libstdc++.

Thanks very much for your answer.
Yeah sorry i'm on 73.0.1 now. Freshly installed fedora 31 workstation
but had not updated for the first time.
Removed pluginreg.dat
Started fresh, did the: cmake thing, make and make install.
copied libfreshwrapper-flashplayer.so to several locations
including where the firefox rpm installs firefox
so it's now in:
/usr/lib64/mozilla/firefox/plugins
/usr/lib/mozilla/firefox/plugins
/lib64/mozilla/firefox/plugins
/lib/mozilla/firefox/plugins
/usr/local/lib/mozilla/plugins
/usr/local/lib64/mozilla/plugins
~/.mozilla/plugins
and where about:support says the profile directory is: ~/.mozilla/firefox/2vq1u8b3.default-1517998618273-1526802550388
It still doesn't show up in firefox plugins.
Even if the libpepflashplayer.so can't be found freshplayer should still show up in firefox, right?

Van: Rinat Ibragimov<EMAIL_ADDRESS>Verzonden: woensdag 11 maart 2020 23:21
Aan: i-rinat/freshplayerplugin<EMAIL_ADDRESS>CC: TrIPpY-<EMAIL_ADDRESS>Author<EMAIL_ADDRESS>Onderwerp: Re: [i-rinat/freshplayerplugin] libfreshplayer does not show up in Firefox 69.0.1 64bit (#384)
First, the version of Firefox looks unusual. It's not an extended support release which I believe is 68. But it's also not the current version, which is 74.
Since Flash is almost gone from popular websites, I don't really use it. So I can't say for sure if freshplayerplugin was working in 69.0.1. It works on 74.0 though.
As for the possible reasons, it may be pluginreg.dat file contains stale data. If for some reason plugin crashed, Firefox remembers that in pluginreg.dat, and doesn't try to load failed plugin again. Sometimes it helps to stop the browser, remove pluginreg.dat, and start the browser again. File is located in your profile directory. You may find where it is on about:support page, search for "Profile Directory".
Another reason is freshplayerplugin built in previous versions of an OS. If it's not fresh-built, it may help to build from source again. Also freshplayerplugin loads PepperFlash itself, so your system libraries should be relatively recent. PepperFlash from desktop Chrome usually works on almost every distro versions, but if you use PepperFlash from ChromeOS, you may need recent libc and libstdc++.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHubhttps://github.com/i-rinat/freshplayerplugin/issues/384#issuecomment-597907627, or unsubscribehttps://github.com/notifications/unsubscribe-auth/ABPYAPCBMEWVACP2RSTC2ILRHAFGDANCNFSM4LFDFMLA.

fedora 31

As far as I know, Fedora uses SELinux. So it could be lack of SELinux policy that prevents library from loading. I'm not familiar with SELinux enough to check if that's the case. I usually just disabled it completely, but that was for testing purposes. The right solution would be to add a policy.

Even if the libpepflashplayer.so can't be found freshplayer should still show up in firefox, right?

Yeah, it should. PepperFlash is loaded dynamically, so it should not prevent freshplayerplugin itself from loading.

@i-rinat
There is an amazing project that will make any SWF made the last 20 years working for ever on the net.
https://github.com/ruffle-rs/ruffle
contributors are welcome!

Thanks again. With selinux disable it also doesn't show up in firefox.

Van: Rinat Ibragimov<EMAIL_ADDRESS>Verzonden: vrijdag 13 maart 2020 12:38
Aan: i-rinat/freshplayerplugin<EMAIL_ADDRESS>CC: TrIPpY-<EMAIL_ADDRESS>Author<EMAIL_ADDRESS>Onderwerp: Re: [i-rinat/freshplayerplugin] libfreshplayer does not show up in Firefox 69.0.1 64bit (#384)
fedora 31
As far as I know, Fedora uses SELinux. So it could be lack of SELinux policy that prevents library from loading. I'm not familiar with SELinux enough to check if that's the case. I usually just disabled it completely, but that was for testing purposes. The right solution would be to add a policy.
Even if the libpepflashplayer.so can't be found freshplayer should still show up in firefox, right?
Yeah, it should. PepperFlash is loaded dynamically, so it should not prevent freshplayerplugin itself from loading.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHubhttps://github.com/i-rinat/freshplayerplugin/issues/384#issuecomment-598679907, or unsubscribehttps://github.com/notifications/unsubscribe-auth/ABPYAPBYAWSOYMJPFPRYRMTRHILLHANCNFSM4LFDFMLA.

@TrIPpY-
check the right permissions of your libs

They are mostly all rwxr-xr-x

Van: ROBERT MCDOWELL<EMAIL_ADDRESS>Verzonden: vrijdag 13 maart 2020 14:04
Aan: i-rinat/freshplayerplugin<EMAIL_ADDRESS>CC: TrIPpY-<EMAIL_ADDRESS>Mention<EMAIL_ADDRESS>Onderwerp: Re: [i-rinat/freshplayerplugin] libfreshplayer does not show up in Firefox 69.0.1 64bit (#384)
@TrIPpY-https://github.com/TrIPpY-
check the right permissions of your libs
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHubhttps://github.com/i-rinat/freshplayerplugin/issues/384#issuecomment-598709292, or unsubscribehttps://github.com/notifications/unsubscribe-auth/ABPYAPEOLERMDCPARGBQRX3RHIVNXANCNFSM4LFDFMLA.

OK, I've tried to install Fedora 31 into a virtual machine. And indeed freshplayerplugin doesn't show up in about:plugins in Firefox. It's not permissions or SELinux interfering, it's just Fedora 31 have Wayland session enabled by default, and uses custom Firefox build with Wayland support enabled by default. As NPAPI plugins are tightly bound to X server technology, there is no way to support them in Wayland-enabled Firefox builds. So, plugins do not work there.
If you still need plugins, you have to run Firefox as GDK_BACKEND=x11 firefox. It will then work through implicitly started Xwayland. Or you may download Firefox build from Mozilla's website. While it supports Wayland too, it still uses X11 backend by default.

Ah. makes sense. Few versions back Fedora introduced wayland. I have this problem since 27 or 28. Thanks for your time.Op 13 mrt. 2020 19:17 schreef Rinat Ibragimov<EMAIL_ADDRESS>OK, I've tried to install Fedora 31 into a virtual machine. And indeed freshplayerplugin doesn't show up in about:plugins in Firefox. It's not permissions or SELinux interfering, it's just Fedora 31 have Wayland session enabled by default, and uses custom Firefox build with Wayland support enabled by default. As NPAPI plugins are tightly bound to X server technology, there is no way to support them in Wayland-enabled Firefox builds. So, plugins do not work there.
If you still need plugins, you have to run Firefox as GDK_BACKEND=x11 firefox. It will then work through implicitly started Xwayland. Or you may download Firefox build from Mozilla's website. While it supports Wayland too, it still uses X11 backend by default.
—You are receiving this because you were mentioned.Reply to this email directly, view it on GitHub, or unsubscribe.


Scalar addition issue on Element-wise operations

Describe your problem and how to reproduce it:
For the challenge "Rosetta Code: Element-wise operations", it says that operation("s_add",[[1,2],[3,4]],[[1,2],[3,4]]) should return [[3,4],[5,6]].  However, to find this value, you simply add 2 to each element, which is scalar addition.  The second input should just be the number 2.
Add a Link to the page with the problem:
https://www.freecodecamp.org/learn/coding-interview-prep/rosetta-code/element-wise-operations
Tell us about your browser and operating system:

Browser Name: Firefox
Browser Version: 82
Operating System: Linux Mint

A quick peek in to the relevant test shows:
  - text: operation("s_add",[[1,2],[3,4]],[[1,2],[3,4]]) should return [[3,4],[5,6]].
    testString: assert.deepEqual(operation('s_add', [[1, 2], [3, 4]], 2), [[3, 4], [5, 6]]);

The test itself calls the function as you've describe, so the text should be updated to match. I think this one could be opened to first timers. 🙂
Nice catch!

Thank you!  I really like noticing these details

I am a first time contributor, Can I take this issue?

Heya @msreekm~! Thank you for your interest in contributing!
As a heads up, issues labelled first timers only or help wanted are open for contribution and do not require permission. We typically accept the first comprehensive PR that fixes the issue.
If you have not done so already, I encourage you to read our contributing guidelines.

ok will create a PR soon, thanks

Hi, i would like to work on this too

create a PR

I also would like to work


Use docker images for the 'prepare' step

The prepare step is pretty similar for every build and I'm wondering if we could improve the action execution time by creating some Docker images with the 'prepare' already executed in them.
We could recreate the Docker images on the push events to main branch when prepare script is modified, so the images would be always available with the latest changes.

As discussed in person caching the internet is hard so let's not do that. Also it takes only a minute (and could be speed up if needed).


[Hub Generated] Review request for Microsoft.DataProtection to add version preview/2023-06-01-preview

This is a PR generated at OpenAPI Hub. You can view your work branch via this link.
ARM API Information (Control Plane)
Changelog
Add a changelog entry for this PR by answering the following questions:

What's the purpose of the update?

[ ] new service onboarding
[x] new API version
[ ] update existing version for new feature
[ ] update existing version to fix swagger quality issue in s360
[x] Other, please clarify

When are you targeting to deploy the new service/feature to public regions? Please provide the date or, if the date is not yet available, the month.
When do you expect to publish the swagger? Please provide date or, the the date is not yet available, the month.
By default, Azure SDKs of all languages (.NET/Python/Java/JavaScript for both management-plane SDK and data-plane SDK, Go for management-plane SDK only ) MUST be refreshed with/after swagger of new version is published. If you prefer NOT to refresh any specific SDK language upon swagger updates in the current PR, please leave details with justification here.

Contribution checklist (MS Employees Only):

[x] I commit to follow the Breaking Change Policy of "no breaking changes"
[x] I have reviewed the documentation for the workflow.
[x] Validation tools were run on swagger spec(s) and errors have all been fixed in this PR. How to fix?

If any further question about AME onboarding or validation tools, please view the FAQ.
ARM API Review Checklist

Applicability: :warning:
If your changes encompass only the following scenarios, you should SKIP this section, as these scenarios do not require ARM review.

Change to data plane APIs
Adding new properties
All removals

Otherwise your PR may be subject to ARM review requirements. Complete the following:

[x] Check this box if any of the following apply to the PR so that the label "ARMReview" and "WaitForARMFeedback" will be added by bot to kick off ARM API Review.  Missing to check this box in the following scenario may result in delays to the ARM manifest review and deployment.

Adding a new service
Adding new API(s)
Adding a new API version
-[ ] To review changes efficiently, ensure you copy the existing version into the new directory structure for first commit and then push new changes, including version updates, in separate commits. You can use OpenAPIHub to initialize the PR for adding a new version. For more details refer to the wiki. Note that this doesn't apply if you are trying to merge a PR that was previously in the private repository.

[x] Ensure you've reviewed following guidelines including ARM resource provider contract and REST guidelines. Estimated time (4 hours). This is required before you can request review from ARM API Review board.

[ ] If you are blocked on ARM review and want to get the PR merged with urgency, please get the ARM oncall for reviews (RP Manifest Approvers team under Azure Resource Manager service) from IcM and reach out to them.

Breaking Change Review Checklist
If you have any breaking changes as defined in the Breaking Change Policy, request approval from the Breaking Change Review Board.
Action: to initiate an evaluation of the breaking change, create a new intake using the template for breaking changes. Additional details on the process and office hours are on the Breaking Change Wiki.
NOTE: To update API(s) in public preview for over 1 year (refer to Retirement of Previews)
Please follow the link to find more details on PR review process.

This PR is created on top of existing approved PR https://github.com/Azure/azure-rest-api-specs/pull/22359 with new api-version 2023-06-01-preview. We're also rolling out our resource provider Backup Vault manifest with this version. Added DoNotMerge label.

/azp run unifiedPipeline

this js sdk breaking change is not caused by this pr

Synced with previous stable version 2023-05-01.
Base of this PR is 2023-04-01-preview hence sync with stable version 2023-05-01 also showing it as diff against main.
PR was approved by ARM team. Please review commits range: https://github.com/Azure/azure-rest-api-specs/pull/24388/files/0d73ef4b828b72ea468a51b2bd79a90896926d2d..7a56adbf92c894faf50f54b743bdad39f83c715a

      "type": "string"

Should this be an enum?

Refers to: specification/dataprotection/resource-manager/Microsoft.DataProtection/preview/2023-06-01-preview/dataprotection.json:4090 in c5829d7. [](commit_id = c5829d709e41246de2737ddfbfa406e23cd561cc, deletion_comment = False)

},

Why are these operations being removed? Wouldn't these cause breaking changes to existing customers?
Refers to: specification/dataprotection/resource-manager/Microsoft.DataProtection/preview/2023-06-01-preview/dataprotection.json:1530 in 0d73ef4. [](commit_id = 0d73ef4, deletion_comment = True)

Mistakenly I had removed APIs from previous preview version 2023-04-01-preview, now added back.

      "type": "string"

Should this be an enum?
Refers to: specification/dataprotection/resource-manager/Microsoft.DataProtection/preview/2023-06-01-preview/dataprotection.json:4090 in c5829d7. [](commit_id = c5829d7, deletion_comment = False)

I had removed changes from previous preview version 2023-04-01-preview, now added back and considered stable version 2023-05-01 as base.

This PR is to introduce Encryption Settings(a.k.a CMK). This is public PR. Private repo PR is already approved https://github.com/Azure/azure-rest-api-specs/pull/22359 with new api-version 2023-06-01-preview

Please look at this commit range to review delta(Encryption Settings for Backup vault resource) easily:
https://github.com/Azure/azure-rest-api-specs/pull/24388/files/0ef66795af66cdd0c271d30705261b30d8f08f40..7a56adbf92c894faf50f54b743bdad39f83c715a#diff-e01730bef05f078dea17a81543f32433fd6a0abc15286484fb43dde0b93505b6

For these two failures, BaseResourceProperties is already present in stable version 2023-05-01 and this object is not part of this PR.
So, we can add the below labels.
Approved-SdkBreakingChange-Go
Approved-SdkBreakingChange-Python

      "$ref": "#/definitions/BaseResourceProperties",

I didn't understand the purpose of this field? What is being added as part of resourceProperties? I already see an objectType and resourceType fields here?

Refers to: specification/dataprotection/resource-manager/Microsoft.DataProtection/preview/2023-06-01-preview/dataprotection.json:5756 in e4a92d6. [](commit_id = e4a92d651f15314847948b40d81ca7f8e31f9d95, deletion_comment = False)

      "$ref": "#/definitions/BaseResourceProperties",

I didn't understand the purpose of this field? What is being added as part of resourceProperties? I already see an objectType and resourceType fields here?
Refers to: specification/dataprotection/resource-manager/Microsoft.DataProtection/preview/2023-06-01-preview/dataprotection.json:5756 in e4a92d6. [](commit_id = e4a92d6, deletion_comment = False)

This change is part of stable API version
https://github.com/Azure/azure-rest-api-specs/blob/c5829d709e41246de2737ddfbfa406e23cd561cc/specification/dataprotection/resource-manager/Microsoft.DataProtection/stable/2023-05-01/dataprotection.json
So not sure why it was added.

      "type": "string"

Please respond to this comment.
In reply to:<PHONE_NUMBER>
Refers to: specification/dataprotection/resource-manager/Microsoft.DataProtection/preview/2023-06-01-preview/dataprotection.json:4090 in c5829d7. [](commit_id = c5829d7, deletion_comment = False)

This change is also part of stable API version 2023-05-01

https://github.com/Azure/azure-rest-api-specs/blob/main/specification/dataprotection/resource-manager/Microsoft.DataProtection/stable/2023-05-01/dataprotection.json

@rkmanda please guide about the following required labels:

/pr RequestMerge


BADGE REQUEST [Oalo#7117]

What is your Discord Tag?
Oalo#7117
What is your UID (User ID)?
743606486063644673
What is the image for the badge that you want? Please make sure that the image is hosted on a trusted domain, such as i.imgur or cdn.discordapp.
https://i.imgur.com/vYyV7hU.png
Additional Confirmation:

[x] My badge does not contain any NSFW material.
[x] My badge is not a badge that signifies that I am an official developer / staff for Discord or client mod communities.

done


[ENH] Design and API for Early Classification

Early classification revolves around allowing classifiers to take incomplete series (i.e, the first half of a series recorded over a day) and decide whether it can make an accurate prediction or not with the presented partial time series. These algorithms are similar enough to the rest of the classification package that they could just reside in a sub-package for now, such as classification/early_classification.
While most of the current classification API is suitable for these algorithms, some issues may arise and will require discussion:

How do we deal with an algorithm refusing to make a prediction? Both in the sense of what would we actually return (None seems reasonable) and how would we go about testing, as returning this is likely to break some of the standard classifier ones.
How do we verify input when predicting? Some algorithms can only make decisions at specific series lengths (commonly in 5% intervals), do any additions need to be made for this, or should it be left to the individual algorithm?
Some algorithms keep data from previous prediction attempts, i.e. a decision at 15% of the series may use information from the decisions at 5% and 10%. Do we require any additional predict inputs to accommodate this? How do we reset for new data when predicting?
Do we require an extended base class for any of this? Would having it anyway help with testing, or would it be better as a tag?

Good first implementations would be TEASER and a simple probability threshold for making the decision.

@patrickzib has shown interest in the topic from previous discussions, though anyone feel free to contribute and edit the issue if necessary.

I have put up a draft PR #1630 containing probability threshold early classifier as a test. I have set it up to follow the current classification API as much as possible. We can completely revamp any part of it as we make decisions, but it may require an extended base class to be implemented.
To make sure the current tests pass and that we can use BaseClassifier, a second function is used to determine whether the predictions/probabilities are safe.

Interesting question! :) I would rather say, one should keep the classifier state-less

Agreed, currently I have set up the decision method to take and return a tuple of values containing the current state. The second option could get very expensive depending on the algorithm.

Any objections to closing this issue? Any problems with the early classification base class or early classifiers should be raised as a separate issue, IMO.

no, I thought we arrived at a consolidated design through discussions on the early classification PR.
Perhaps just link those discussions here, then close?

That's fair.
Initial discussion regarding early classification is mostly in the TEASER PR: #2162
The early classification base class PR and discussion is here: #2235


Unable to locate package termux adb

![Uploading Screenshot_20241007-224412.png…]()

![Uploading Screenshot_20241007-224412.png…]()

Ss not showing


change access modifier from internal to protected/public

Trying to create another base32 implementation other than the ones provided. However:

Base32Encoding.ToBase32() has internal access modifier. Line 294
Base32Encoding.GetOrCreateLookupTable() has internal access modifier. Line 83

Could you make those protected or public so that an inheriting class has access to those?

Looks like Base32Encoding.ToBytes() and Base32Encoding.Validate() need to be made protected or public. As well as the LookupTable class.


V1.2 dev-ingredient branch

Codecov Report

Merging #39 (507430e) into dev-ingredient (dfa1474) will not change coverage.
The diff coverage is 0.00%.

@@                Coverage Diff                @@
##             dev-ingredient      #39   +/-   ##
=================================================
  Coverage             72.07%   72.07%
  Complexity              401      401
=================================================
  Files                    70       70
  Lines                  1257     1257
  Branches                127      127
=================================================
  Hits                    906      906
  Misses                  317      317
  Partials                 34       34

Impacted Files
Coverage Δ

...rc/main/java/fridgy/logic/commands/AddCommand.java
100.00% <ø> (ø)

...c/main/java/fridgy/logic/commands/ExitCommand.java
100.00% <ø> (ø)

...c/main/java/fridgy/logic/commands/FindCommand.java
100.00% <ø> (ø)

...rc/main/java/fridgy/model/util/SampleDataUtil.java
14.28% <0.00%> (ø)

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update dfa1474...507430e. Read the comment docs.


refactor: simplify FillPluginsDefaults signature

Codecov Report

Merging #116 (6d747f3) into main (bfe90b4) will decrease coverage by 0.94%.
The diff coverage is 66.66%.

@@            Coverage Diff             @@
##             main     #116      +/-   ##
==========================================
- Coverage   44.46%   43.52%   -0.95%
==========================================
  Files          42       42
  Lines        3805     3805
==========================================
- Hits         1692     1656      -36
- Misses       1793     1838      +45
+ Partials      320      311       -9

Flag
Coverage Δ

2.0.5
39.13% <66.66%> (ø)

2.1.4
?

2.2.2
?

2.3.3
?

2.4.0
?

community
39.13% <66.66%> (ø)

enterprise
43.02% <66.66%> (-1.14%)
:arrow_down:

enterprise-<IP_ADDRESS>
?

enterprise-<IP_ADDRESS>
43.02% <66.66%> (ø)

enterprise-<IP_ADDRESS>
?

enterprise-<IP_ADDRESS>
?

integration
43.52% <66.66%> (-0.95%)
:arrow_down:

Flags with carried forward coverage won't be shown. Click here to find out more.

Impacted Files
Coverage Δ

kong/utils.go
86.00% <66.66%> (ø)

kong/workspace_service.go
32.75% <0.00%> (-20.69%)
:arrow_down:

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update bfe90b4...6d747f3. Read the comment docs.


add nix flake for reproducible builds

With this, the project can be built reproducibly on any linux system which has the nix package manager installed,
using a single command:
nix-shell -p nixFlakes --run "nix build github:zehome/MLVPN"

Besides the reproducibility aspect, the benefit of this is, that any kind of build instructions become obsolete. No build dependencies need to be installed by the user, etc...

Could you add the help / info on NIX inside the README ?

Added readme section
Added cross build target
Added static targets
Added static cross build targets

Added readme section
Added cross build target
Added static targets
Added static cross build targets

Thank you for the contribution. I've tried to build using nix, but without success. I'm stuck with
error: experimental Nix feature 'nix-command' is disabled; use '--experimental-features nix-command' to override

I've not investigated that much, as I'm not a nix user myself..
-> % nix --version
nix (Nix) 2.3.10

Is there an other step to get this thing working?

Sorry, I forgot about the fact that some nix features we use here are not yet enabled by default.
I edited the readme now, to set the correct config option via environment variable.
Before you start the build, use this commend to enter the shell with all necessary features enabled:
NIX_CONFIG="experimental-features = flakes nix-command" nix-shell -p nixFlakes


Nest into struct for slice of pointer of struct

This fixes #68.

Coverage remained the same at 100.0% when pulling d12dfe1bb0d170e417efc5a4f8af9968adcdce24 on 17media:ptr-struct into 14f46232cd7bc732dc67313a9e4d3d210e082587 on fatih:master.

Thanks @roylou. Sorry for the late response. This looks nice, I'm just going to add a comment so it's clearer a little bit.


Add spin up --build option

Fixes #1735.

A separate cloud plugin PR would be needed for spin deploy --build.

$ spin up --build
Building component hello3 with `cargo build --target wasm32-wasi --release`
   Compiling hello3 v0.1.0 (/home/ivan/testing/hello3)
    Finished release [optimized] target(s) in 0.38s
Finished building all Spin components
Logging component stdio to ".spin/logs/"

Serving http://<IP_ADDRESS>:3000
Available Routes:
  hello3: http://<IP_ADDRESS>:3000 (wildcard)

Buildception: I tried it with spin build --up --build and spin watch --build although it did some wasted work there was no recursion or unexpected CPU / disk usage.  At least not in my simple test case.  I am a bit concerned that there might be lurking possibilities for buildception in spin watch --build, and that it looks enough like the opposite of spin watch --skip-build for people to think that it's a good idea to pass it, but not enough to really worry about it for now!

This feature is interesting! I am a little concerned about the potential confusion this may cause with both spin build --up and spin up --build being 2 different ways to do the same thing.  Spin watch emulates a part of the spin up --build behavior, which could mean 3 different ways to do the same thing.
I do not have very strong opinions here but wanted to bring it up to see if other people had similar concerns.

I share some of @karthik2804 and @itowlson's concerns. What is the use case we're trying to support here? I'm a little wary to be littering --build flags through every sub-command in Spin.

Is he real "solution" here to remove (or-deprecate) spin build --up now that we have spin watch? If I remember correctly that was the order in which they were implemented. So we went from spin build && spin up to spin build --up and now spin watch.
Maybe @michelleN can give some more nuances to the original issue, to help understand the motivation.

spin build --up != spin watch and we should not force people to use the latter when they want the former.
Not meaning to speak for @michelleN but my impression from discussion at the time was that people were asking for a way to make sure their applications were up to date before they ran or (especially) deployed them.  That's why I defined an environment variable to this, so that people who wanted to always build when they upped or deployed could set it in .profile and forget it.

spin build --up != spin watch and we should not force people to use the latter when they want the former.

Agreed.

Not meaning to speak for @michelleN but my impression from discussion at the time was that people were asking for a way to make sure their applications were up to date before they ran or (especially) deployed them. That's why I defined an environment variable to this, so that people who wanted to always build when they upped or deployed could set it in .profile and forget it.

I'm realizing it was actually me who raised the original issue on Slack:

I would love some sort of warning to be displayed if you spin cloud deploy without having run spin build first. The amount of time I've wasted wondering why my code isn't working only to realize that I forgot to rebuild the app is silly.
Lots of ways we could do this but one might be to have spin cloud deploy keep a cache of the last deployed app and then warn you if you're redeploying the same app

I was only looking for a warning from spin deploy and then it morphed into the ability to have spin deploy build your code with a --build flag. I guess given the original issue I'm not really sure how we arrived at adding a --build flag to spin up.

Maybe @michelleN can give some more nuances to the original issue, to help understand the motivation.

Yea, I should have added more context to the original issue. It's been bothering me that I have to think about the build step every time I want to iterate on my application so my hope is we can replace spin build --up with spin up --build. up is the action that the user most likely wants and it's more intuitive (to me) to make build an option of up rather than the other way around. It's much less likely that the user wants to build and not up. If we add --build as an option to up then the user only really needs to know about one command, one action: spin up. Linking --build to an environment variable that we recommend setting further reduces cognitive load.
When @calebschoepp mentioned his issue, I thought this might resolve both of our concerns so my bad for trying to morph those together without adding context!

I agree with --build being more appropriate on spin up than --up on spin build. I would prefer we potentially remove --up on spin build with 2.0 maybe?
I totally agree with spin deploy --build.

When @calebschoepp mentioned his issue, I thought this might resolve both of our concerns so my bad for trying to morph those together without adding context!

No worries. I guess stylistically I'm not the biggest fan of --build and --up flags for my own workflow, but I totally see how others would find them helpful. I'm content to move forward with adding these things.
I didn't see any issues on the code side of things.


Make TPM key templates and key creation function accessible

This change makes the TPM key templates and key creation function accessible to other package, for example vtpm or recovertpm to reduce code duplication. There is functional changes in this PR.

There is functional changes in this PR.

Did you mean that there are NO functional changes? If not, please specify the functional changes.

There is functional changes in this PR.

Did you mean that there are NO functional changes? If not, please specify the functional changes.

sorry, there is no functional changes.


New Smartthings app/platform

Hi.
Do you, or anybody else, know if the bridge will continue to work if we migrate to the new app?

Migrated everything yesterday, was worried about all my DTH's, discovered today MQTT stopped working. So, first blink, no?

samsung hosed everything with the new improvements that don't do anything.  Nice job samsung!!

This is correct, wish I had noticed this before uninstalling my openhab2 smartthing binding that was working and installing docker, setting it up -.-
 I can confirm docker is running port 8080 is open, no traffic is received from smartthing hub via tcpdump. Connection from docker to mosquitto seems to work, no data.

This is correct, wish I had noticed this before uninstalling my openhab2 smartthing binding that was working and installing docker, setting it up -.-
 I can confirm docker is running port 8080 is open, no traffic is received from smartthing hub via tcpdump. Connection from docker to mosquitto seems to work, no data.

I have the new app and it all works correctly.

Any solution?

Mine has worked with out issue. I updated my DH a couple months ago to allow more info from my refrigerator to be passed and it's still working fine

I appear to be getting all sorts of timeouts lately.  I cannot even delete my "MQTT Bridge" device or the SmartApp because I get this error:

Hibernate operation: could not delete: [physicalgraph.device.DevicePreferences#d2404290-d3ed-402c-bdbb-5092d665bb7d]; uncategorized SQLException for SQL [delete from device_preferences where id=? and version=?]; SQL state [25S03]; error code [0]; (conn=1125550) Communications link failure with primary host na02useast1-datamgmt.cluster-cojnp12rqtju.us-east-1.rds.amazonaws.com:3310. Connection timed out; nested exception is java.sql.SQLException: (conn=1125550) Communications link failure with primary host na02useast1-datamgmt.cluster-cojnp12rqtju.us-east-1.rds.amazonaws.com:3310. Connection timed out

I am getting similar errors when trying to configure the SmartApp for the first time.  Is this functional or should I abandon further efforts?
10:02:02 PM: debug Installed with settings: [battery:[Bedroom Sensor, Office Sensor], bridge:MQTT Bridge]
10:02:22 PM: error org.springframework.jdbc.UncategorizedSQLException: Hibernate operation: Could not execute JDBC batch update; uncategorized SQLException for SQL [insert into event_subscription (version, data, date_created, device_id, filter_events, handler, hub_id, installed_smart_app_id, last_updated, location_id, name, id) values (?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?)]; SQL state [25S03]; error code [0]; (conn=27053913) Communications link failure with primary host na04useast2-datamgmt.cluster-cwcarkwvvr9r.us-east-2.rds.amazonaws.com:3310. Connection timed out; nested exception is java.sql.BatchUpdateException: (conn=27053913) Communications link failure with primary host na04useast2-datamgmt.cluster-cwcarkwvvr9r.us-east-2.rds.amazonaws.com:3310. Connection timed out @line 504 (initialize)


just typo fixed

now looks more professional.

Hey @MuminjonGuru,
Thank you very much. I really appreciate that!


rspec fails on chefdk 0.11.2

undefined method `step_into?' for nil:NilClass
$ chef -v
Chef Development Kit Version: 0.11.2
chef-client version: 12.7.2
berks version: 4.2.0
kitchen version: 1.5.0
full(er) error
$ chef exec rspec
Run options: include {:focus=>true}

All examples were filtered out; ignoring {:focus=>true}

================================================================================
Recipe Compile Error in /var/folders/9r/g1wlns1j29bg0c7b_6fr7b480000gr/T/d20160308-15455-1fq9xca/cookbooks/docker/libraries/_autoload.rb
================================================================================

NoMethodError
-------------
undefined method `step_into?' for nil:NilClass

Cookbook Trace:
---------------
  /var/folders/9r/g1wlns1j29bg0c7b_6fr7b480000gr/T/d20160308-15455-1fq9xca/cookbooks/docker/libraries/_autoload.rb:10:in `rescue in <top (required)>'
  /var/folders/9r/g1wlns1j29bg0c7b_6fr7b480000gr/T/d20160308-15455-1fq9xca/cookbooks/docker/libraries/_autoload.rb:1:in `<top (required)>'

Relevant File Content:
----------------------
/var/folders/9r/g1wlns1j29bg0c7b_6fr7b480000gr/T/d20160308-15455-1fq9xca/cookbooks/docker/libraries/_autoload.rb:

  3:  rescue LoadError
  4:    run_context = Chef::RunContext.new(Chef::Node.new, {}, Chef::EventDispatch::Dispatcher.new)
  5:
  6:    require 'chef/resource/chef_gem'
  7:
  8:    docker = Chef::Resource::ChefGem.new('docker-api', run_context)
  9:    docker.version '= 1.26.2'
 10>>   docker.run_action(:install)
 11:  end
 12:

F

you need to run bundle install

This seems to be similar to sethvargo/chefspec#676
I wonder, is it normal to make a run_context in an rb file in the libaries folder? So you're trying to run resources during cookbook compilation? Would there maybe be some way to use the chef_gem resource in the various DockerCookbook resource actions so it has the real run_context?

We stay away from using chef_gem so a recipe doesn't need to be included.
This is only an issue if you don't install the gem deps listed in the Gemfile; which you should be if you are running these tools.

But you are using chef_gem, just not in a recipe. And if you used a chef_gem resource as a resource in the actions of your resources, no one would need to have some recipe included either (the same way the DockerCookbook resources use all sorts of other resources in the actions: execute, package, etc.)
And certainly if someone is running the specs for the docker cookbook itself they should do bundle install. But there's nothing (that I could find at least) that gave me any indication that some other cookbook that depends on the docker should have gem 'docker-api' in its Gemfile

The current method is very much improved compared to our old method of vendoring the required gems; which caused gem conflicts (specifically excon). chef_gem isn't accessible during loading of the libraries, so it will fail out. That is why we load it the way we do.
With that said, we are all for improving it even further. Feel free to submit a PR if you get that working.

Got ya. My usual first step with any cookbook is to run rspec.
I am using vanilla install of ChefDK which comes with docker-api (1.26.0).
on a side note, I tried kitchen test xx against a few suits and got below error every time.
Demand that cannot be met: (docker = 2.5.8) Artifacts for which there are conflicting dependencies: compat_resource = 12.7.3 -> []Unable to find a solution for demands: apt (2.9.2), apt-docker (0.3.0), compat_resource (12.7.3), docker (2.5.8), docker_test (0.5.1), etcd (3.2.5), yum (3.10.0), yum-docker (0.3.0)]
I am not against closing this bug.

Sounds like you need to run berks install

I am not against having this issue closed, unless @b-dean has any additional comments.

Feel free to close it. I putting docker-api in the Gemfile of any cookbook that depends on docker is a bit annoying, but solves the problem. I haven't had time to see if I could figure out a different way to get that docker-api gem installed in chef. If I ever look at it, I'll mention this issue on a PR.

got ya. closing as is.


fix(common): synchronize cancel for long-running operations

Cancellation of a long-running operation (1) happens asynchronously
with the flow of callbacks, and (2) requires access to the currently
running operation name. This means we must serialize reads/writes of
that name, so introduce a member mutex.
And given that we now have a mutex, use it to guard canceled_
as well, avoiding the need for atomic operations. Also mark the
operation as cancelled when that happens before the operation name
is first set.
Finally, update the DatabaseAdminConnectionTest.CreateBackupCancel
test to allow for AsyncCancelOperation() not being called before
the polling policy expires.
Fixes #6854.

This change is

Do you think it is possible to write some unit test for this? I cannot think of a reasonable one.

I could not either, at least without intrusively adding hooks to control ordering.  So the conclusion I came to is that tsan is our friend, albeit scheduling dependent.


[RFC] Reindex-from-Snapshot (RFS)

What/Why
In this RFC we propose to develop new, standardized tooling that will enable OpenSearch users to more easily move data between platforms and versions.  The phrase we’ve been using to describe this approach so far is Reindex-from-Snapshot (RFS).  At a high level, the idea is to take a snapshot of the source cluster, pull the source docs directly from the snapshot, and re-ingest them on the target using its REST API.  This would add an additional option to the mix of traditional snapshot/restore and using the reindex REST API on the source cluster.  It is hoped that this approach will combine many of the best aspects of the two existing methods of data movement while avoiding some of their drawbacks.
What users have asked for this feature?
Many users need to maintain a full copy of historical data in their ES/OS cluster (e.g. the “Search” use-case).  For these users, moving to a new cluster entails moving that data, ideally with as little effort and as little impact on the source cluster as possible.  Improving the experience for this process will enable users to upgrade their cluster versions more easily and move to new platforms more easily.
What problem are you trying to solve?
When moving historical data from a source cluster to a target cluster, there are two broad aspects that need to be considered: (1) moving the data to the target efficiently and (2) ensuring the moved data is usable on the target.  (2) is especially important when the target cluster’s ES/OS major version does not match the source cluster.  The two existing data movement solutions both have tradeoffs with regards to these aspects, which we will briefly explore below.
The goal of this proposal is to have a data movement solution that is both efficient and able to ensure the data is usable on the target, even if the target is beyond the Lucene backwards compatibility limit.
Existing Solution: Snapshot/Restore
Snapshot/Restore makes a copy of the source cluster at the filesystem level and packs the copy into format that can be more easily stored where the user desires (on disk, in network storage, in the cloud, etc).  When the user wants to restore the copy, the target cluster has its nodes retrieve the portions of the snapshot relevant to them, unpack them locally, and load them via Lucene.  The data in the snapshot is not re-ingested by ES/OS.
Snapshot/Restore is better at moving the data efficiently.  It reduces strain on the source cluster by avoiding the cost of pulling all historical data through the REST API and enables the target cluster to stand up without having to re-ingest the historical data through its REST API.  As a side benefit, it also enables users to rehydrate a cluster from a backup in cold storage.  However, it is not an option if the major version of the target is no more than a single increment from the source (a limitation driven by Lucene backwards compatibility, see [1]).  Additionally, once data has been moved to a newer major version using Snapshot/Restore (e.g. from v1.X to v2.X), it must be reindexed before it can be moved an even newer major version (e.g. from v2.X to v3.X); this is also due to Lucene backwards compatibility.
Existing Solution: Reindex REST API
The Reindex REST API allows users to set up an operation on the source cluster that will cause it to send all documents in the specified indices to a target cluster for re-ingestion.  Some versions of ES/OS support the option of parallelizing this process within a given index using sliced scrolls [2].  This process operates at the application layer on both the source and target clusters.
The Reindex REST API on the source cluster is useful when the user needs to move to a target cluster beyond the Lucene backwards compatibility limit, or when snapshot/restore otherwise isn’t an option.  Re-ingesting the source documents on the target using the reindex API bypasses the backwards compatibility issue by creating new Lucene indices on the target instead of trying to read the source Lucene indices in the target cluster.  However, the faster you perform the data movement (such as by using sliced scrolls), the greater the impact on the ability of the source cluster to serve production traffic.  Additionally, having to operate at the application layer means that the overhead of the distributed system comes into play rather than being able to transfer data at the filesystem level.  Finally, the Reindex REST API is only usable for an index if the source cluster has retained an original copy of every document in that index via the _source feature [3].
[1] https://opensearch.org/docs/2.12/install-and-configure/upgrade-opensearch/index/#compatibility
[2] https://www.elastic.co/guide/en/elasticsearch/reference/7.10/docs-reindex.html#docs-reindex-slice
[3] https://www.elastic.co/guide/en/elasticsearch/reference/7.10/docs-reindex.html
How would the proposal solve that problem?
The core idea of RFS is to write a set of tooling to perform the following workflow:

Take a snapshot of the source cluster, using the standard API/process.
Run the tool.  It takes in the location of the snapshot (local disk, S3, etc) and the ES/OS Indices to be restored, then parses the snapshot to find the relevant metadata files and snapshot blob-files in the snapshot.
Then for each shard of each ES/OS Index to be restored, the tool would:

Copy the snapshot blob-files to disk (if they are not already local)
Unpack them to their original Lucene file format
Use Lucene to read the shard’s files as a Lucene Index and pull the original source documents from the _source field [1]
PUT the source documents to the target cluster, allowing the target to re-ingest the document and create new Lucene Indices.  The target cluster can be scaled up to facilitate re-ingestions, then scaled down to meet expected production demand.

This approach appears to combine the benefits of both snapshot/restore and using the reindex API on the source cluster.  Most importantly, it removes the strain on the source cluster during data movement while also bypassing the Lucene backwards compatibility limit by re-ingesting the data on the target cluster.  Additionally, it allows users to rehydrate a historical cluster’s dataset from a snapshot, potentially reducing the cost of a data movement by removing the need to have the source cluster running.  Finally, it opens up the possibility of skipping the ES/OS snapshot entirely and operating directly from disk images (such as an EBS Volume snapshot), which some users have already had success with (see [2]).
[1] https://www.elastic.co/guide/en/elasticsearch/reference/7.10/mapping-source-field.html
[2] https://blogs.oracle.com/cloud-infrastructure/post/behind-the-scenes-opensearch-with-oci-vertical-scaling
What could the user experience be like?
The user experience could be as follows:

The user creates a new target cluster of the desired ES/OS version on the desired platform.  They would likely want to initially set the replica number to 0 to speed up ingestion by avoiding the need to duplicate to the data nodes from each shard’s master.  They may also wish to temporarily spin up a set of dedicated ingestion nodes [1] to further speed up writes.
The user registers a new, empty snapshot repository on their source cluster.  Making a new repository simplifies the process of parsing a snapshot’s details from the repository and increases the speed of creating the snapshot, as there is no need to consider or perform incremental snapshots.  This repository would be in a network-accessible location so that the RFS tooling could easily access its contents.
The user makes a snapshot of the source cluster into the new, empty repository.
The user passes the RFS tooling the location/connection details/access permissions for both the snapshot and the target cluster, and tells it to “go”.
RFS will perform the steps required to parse the snapshot, retrieve the portions relevant at a given time, extract the _source documents from retrieved snapshot portions, and reindex them against the target cluster (as explained in more detail above).
The user reconfigures the target cluster to their “production” settings (probably add replicas, probably remove the additional ingest nodes)

[1] https://www.elastic.co/guide/en/elasticsearch/reference/7.10/ingest.html
What are the limitations/drawbacks of the proposal?
Community feedback is greatly welcomed on this point, but the following occur to the author:

_source Flag: The approach relies on having the original documents stored in the Lucene index via the _source field.  If the user has disabled this feature on their index, it will not be possible to extract the original documents from the snapshot using Lucene, and therefore not be possible to re-play them against the target cluster.  Without the original document, it becomes harder (impossible?) to move the data across multiple major versions at full fidelity.  However, this is not a problem unique to the proposed solution; using the Reindex REST API has the same limitation.
Version Compatibility: The tooling may need to support a path from each version to each other version to reach its full potential.  This could be initially simplified to just supporting one minor version of each major version as a source/target, and having users first upgrade to that minor version on their source.  It is currently unclear whether this simplification would be sufficient long term, or how much work would be involved if that simplification is not sufficient.  As a data point, the author was able to add support for ES 6.8 to his simplified prototype scripts about a day after first having support for OS 7.10.
Plugin Compatibility: Parsing snapshots requires custom classes to understand the metadata files and (potentially) the blobbed Lucene files in the snapshot.  These classes are loaded into the Elasticsearch/OpenSearch process when the node stands up (see here [1]).  We may need access to to the user’s plugins in order to parse their snapshots.

[1] https://github.com/elastic/elasticsearch/blob/6.8/server/src/main/java/org/elasticsearch/node/Node.java#L425
Have you tested this approach?
Yes.  The author has some proof-of-concept scripts working that will take an Elasticsearch 6.8.23 snapshot [1] and move its contents to an OpenSearch 2.11 target cluster.  The also has another version of the scripts [2] that unpacks an Elasticsearch 7.10.2 snapshot and performs replay against an Elasticsearch 7.10.2 target.  As a PoC, there is obviously more development to be done to make them production-ready.
[1] https://github.com/chelma/reindex-from-snapshot/tree/6.8
[2] https://github.com/chelma/reindex-from-snapshot/tree/7.10

Hope this is can be implemented as a OpenSource library which different clients can use in their own framework to migrate data.

Thanks @chelma for the proposal

Unpack them to their original Lucene file format
Use Lucene to read the shard’s files as a Lucene Index and pull the original source documents from the _source field [1]

Are you saying instead of restoring an index completely, we restore only _source stored field and then trigger reindexing on target cluster?
Also what is main problem we are trying to solve here - version upgrade or customer wants to change mappings/ fields getting indexed? If it is former i.e. mainly for upgrade, there are other approaches which may be more efficient and we are planning to experiment like @Bukhtawar pointed out, where instead of paying the cost of parsing the document and then generate lucene data structure on the target index during re-ingestion. It will directly trigger upgrade of the lucene segment using new version IndexWriter via pseudo merge. If it is the latter problem where the index mappings are changed, then this would be useful.
Also what are the changes you expect in the core to implement this? Do you intend to write a separate plugin here?

@Bukhtawar @shwetathareja
There are a few, overlapping problems we're trying to solve that have combined to lead us to this particular approach.  I'll try to outline our problem set, hope it makes sense.  Keep in mind that not every data movement requires all of the following points, but our solution should address them all to support more complex situations.

Enable Elasticsearch/OpenSearch users running clusters on-prem or self-managed on a cloud hosting provider (e.g. EC2) to move to a new "location".  This entails shifting the historical data and ongoing traffic to a new cluster, which may or may not be on the previous platform (on-prem, self-managed cloud, managed cloud).
Enable Elasticsearch/OpenSearch users running clusters on-prem or self-managed on a cloud hosting provider (e.g. EC2) to move to a different version of Elasticsearch/OpenSearch - either an upgrade, a downgrade, or a "side-grade".  The initial focus is on upgrades and side-grades.  An example would be going from ES 6.8 to OS 2.11 (upgrade), or maybe ES 7.17 to OS 1.3 (side-grade).
To support (2), provide the opportunity and ability for users to transform their data and configuration, as appropriate, from the source version to something compatible with the target version.
Minimize the operational risk and financial cost of performing the movement.  A typical movement, as we see it, likely requires a user to begin caching their existing traffic to the source, move their historical data to the target, replay the cached traffic against the target,  feed new traffic to both source/target, then cut over.  According to our research, it becomes very expensive very quickly to perform this cacheing.  Reducing the overall time to perform the movement is therefor a big win, as it reduces both risk and cost.  Removing impact to the source cluster's ability to serve traffic is also a win on both fronts.

Based on our research/understanding, the existing options for such movement are not ideal on one or more of those fronts.  I discussed Snapshot/Restore and the Reindex REST API in the RFC above, but probably should have talked about iterative Lucene-level singleton merges as well.  While iterative Lucene singleton merges do allow you to progress up through the version chain, from what I understand addressing feature incompatibilites or changes at the Lucene level (manipulating the raw Lucene index) will be much harder than at the Elasticsearch/OpenSearch level (manipulating JSON, for the most part).  It will also be harder to include the user in that process because it will require much more expertise to perform.  Including the user in the process seems valuable because it might not be obvious what the "right" answer for a transformation is.  Additionally, iterative singleton merges are, definitionally, iterative - you have to do some work for each major version hop (or maybe every other?), instead of going directly to the version you want.  As a hypothetical, what would the user experience be like with to go from ES 5.X to OS 2.X with singleton merges?
To answer another question - our current thought for the first cut of this is to make tooling completely outside the ES/OS stack and cluster to perform this work (no change to the existing OS codebase).  This helps facilitate (4) above, by enabling greater parallelism without impacting the source cluster and increasing the speed of the movement.  E.g. have a fleet of workers each be responsible for a single shard of a single index in the snapshot, pull the portion of the snapshot related to that shard, extract the _source, perform a transformation, and reindex on the temporarily scaled-up target.  Fanning out to the shard level has major advantages, as the size of each shard is self-limiting and it decouples the duration of historical migration from the size of the overall data set being migrated; it only takes as long as the biggest shard.  In this scenario (not running on the source/target nodes, a "capped" size to the work per worker, large costs associated with duration of historical data migration), the CPU/IO/network bandwidth usage of the workers appears less important of a consideration compared to the other factors.
That said - skipping the snapshot part entirely and just mounting a virtual disk from a filesystem snapshot of the source cluster is a great optimization which we had planned to explore in later iterations.  We didn't propose it as part of the initial cut because Snapshots provided a lingua franca that all users can speak - regardless of what platform they are starting on.  This allows us to hit a broader portion of the community with our initial efforts, at the cost of some additional CPU/IO/bandwidth on the workers.
I hope that all makes sense, and really curious to get your thoughts!

@shwetathareja

Are you saying instead of restoring an index completely, we restore only _source field and then trigger reindexing on target cluster?

Realized I didn't respond to this question in the previous post.  Yes, that is the idea.  AFAIK, if the goal is to reindex, the _source doc is all you need.  The best way I know to get those currently is to pull down each shard, treat it as a separate Lucene index, and extract the _source field from each doc in Lucene.  We then batch the contents of the _source fields paired with the _id field into bulk PUTs to the target cluster and ship them along.  The target cluster will then reindex them.

[Triage - attendees 1 2 3 4 5 6]
@chelma Thanks for filing, looking forward to seeing more discussion here.

Thanks @chelma for your detailed response. I agree with different complex situations that you called above during migrations and we need tooling that can address them.

As a hypothetical, what would the user experience be like with to go from ES 5.X to OS 2.X with singleton merges?

With iterative singleton merges, these merges have to be run for every major version. Hence, an iterative process that could be running in the background based on merge policy and other configurations.

our current thought for the first cut of this is to make tooling completely outside the ES/OS stack and cluster to perform this work (no change to the existing OS codebase).

👍

Fanning out to the shard level has major advantages, as the size of each shard is self-limiting and it decouples the duration of historical migration from the size of the overall data set being migrated; it only takes as long as the biggest shard.

Parallelization at shard level would definitely speed up the historical data migration significantly.
I am seeing this proposal as one click (fast) migration of historical data (where snapshot restore can't work due to certain requirements) without requiring to setup a cluster.

The best way I know to get those currently is to pull down each shard, treat it as a separate Lucene index, and extract the _source field from each doc in Lucene. We then batch the contents of the _source fields paired with the _id field into bulk PUTs to the target cluster and ship them along.

I would like to see performance no. at a shard level of this vs reindex API where it uses scroll to get documents. We can take theis opportunity to improve the existing re-index API based on the learning from this.

Capturing an offline convo w/ @Bukhtawar for posterity:

There does appear to be a branch in experience based on whether the _source docs are available.  If the _source is available, a reindexing approach like proposed in the RFC provides value over a singleton merge based approach.  If the _source doc isn't available, singleton merges appear like the best approach.
The "limits" to shard size are more convention and best practice than a technical hard limit; while many shards will be no larger than 10's of GBs, some users may have multi-TB shards.
Fortunately, there's an optimization available that reduces the unit of work beyond the shard level (as mentioned by @shwetathareja above).  In the original RFC, it was proposed to download the entire shard's data, unpack it, and then extract the _source docs from it.  However, @Bukhtawar pointed out that only a subset of the files in the snapshot are needed to retrieve the _source docs.  Additionally, if the snapshot is stored in a place like S3 where you can remotely read sections of files, these files can broken up/streamed in chunks to be processed by the workers.  This means that the workers can each own a portion of the _source docs in a given shard, and sequentially retrieve them as needed from the source without needing to retrieve the entire shard's data.

@shwetathareja Some thoughts/responses:

With iterative singleton merges, these merges have to be run for every major version. Hence, an iterative process that could be running in the background based on merge policy and other configurations.

That part makes sense; I'd be curious to hear your thoughts on what to do when a change in Elasticsearch/OpenSearch/Lucene behavior or features between major versions requires some manual effort to transform the data in the source to a format that matches the target.  Maybe there's a type change, for example.  Definitely not an expert on this topic, but people bring up stuff like geopoints which changed their representation.  AFAIK, there's been other changes where some editorial discretion is required to navigate the upgrade.  That brings up whether the user needs to be involved in the process.  Do you know if this angle has been explored?  It's something we're starting to think about and it would be awesome to hear that the problems is either easier than we currently believe or there's prior art we can avail ourselves of.

I would like to see performance no. at a shard level of this vs reindex API where it uses scroll to get documents. We can take this opportunity to improve the existing re-index API based on the learning from this.

As mentioned above, @Bukhtawar had a great point that we can split work beyond the shard level to portions of the _source doc in a shard.  I think that has the potential to make a big impact on the performance by increasing the possible parallelization while reducing the storage needed on the workers and the work they actually need to perform.  Will keep you posted as we get further along and get to testing relative performance.

when a change in Elasticsearch/OpenSearch/Lucene behavior or features between major versions requires some manual effort to transform the data in the source to a format that matches the target

@chelma this banks on the fact that Lucene itself provides backward compatibility with last major version. Hence, when the iterative empty merge would run for segments, it create the new lucene files with new IndexWriter. If there is a type change, it depends where the breaking change lies, in the software handling in OpenSearch or underlying storage format for lucene. Both, provides back compatibility with last major version. This idea has not be POCed yet. I will open a tracking github issue for this.

@chelma Congratulations, RFS is implemented and part of the Migration Assistant.  With this in mind I am going to close out this RFC, thanks everyone for your comments.


[BUG] Incorrect alignment of triangle character with text in Agents details popup

Describe the bug
Incorrect alignment of triangle character with text in Agents details popup
To Reproduce
Steps to reproduce the behavior:

Go to Agents section
Click on any agent item Details link

Expected behavior

Align triangle character with the top of the text
If there is a row with no data, do not display the tiangle character

Screenshots

@YanetABUC I think this is done

Found this bug


Additional options for component initialization

Summary of the feature request
In the TMS project we run UI tests for all pages and features, which can take 20 minutes (and growing). During our patching of some flaky tests we noticed that our test framework didn't play nice with timeouts and animations. We run unique CSS now if the project is in a test environment that disables animations, and we monkey patch in some code that hijacks the setTimeout and set it to 0ms so all sheets are instant. Disabling animations has cut the tests in half, so it would be preferable to have additional options during component.init() so we can disable everyting in the same place.
Solution(?)
Having the option to initialize like this would be preferable:
dg.sheet.init({ options: { timeout: 0, animations: false } })
Current workaround:
We are currently running optional CSS and JS code that overwrites both the animations and the timeout.
Why is this change important to you? How would you use it?
How can it benefit other users?
Benefits:
For UI tests this eliminates time spent waiting for tests to clear (or not), and makes for faster builds in the azure pipeline.

An alternative way to look at it could be to tie it to prefers-reduced-motion?

Update. After reading about prefers-reduced-motion doc, I think we will implement this solution.


email/contact to sent security vulns

Hi, I believe I found a DoS on express so before I post it on this public issue list, is there a contact (email) that I can use to send the info and PoC?

Please send it to my email address, which you can find on my GitHub profile.

Hi @DinisCruz , I just saw you tried to contact me on Skype. Sorry for not seeing that, I wasn't expecting that so was never looking :S Based on your profile, I probably missed you now from time zone differences, but if you want to try Skype again tomorrow, I'll be sure to watch it for your reach out!


Creating a custom rke1 cluster switches UI to cluster list view instead of create/edit form

This issue is identical to https://github.com/rancher/dashboard/issues/7646, but in the 2.7.x milestone.

On 2.7-head commit id: a2ef50b

Edit an RKE1 cluster
User is navigated to the cluster edit page.
The original issue seen is NOT observed anymore.
No 404s seen in the console
Create RKE1 cluster switches correctly to Create cluster page