Recipe grouping

Implements recipe grouping feature, see https://github.com/casey/just/issues/1776

I'm currently using the -g flag (for --groups) in this draft PR. This issue: https://github.com/casey/just/issues/1648 asks for a global feature, for which it would also be convenient to use the -g flag. I'm not sure which item should get the -g flag, and if so what would be a better alternate flag letter for either.

Nice!
You might want to rebase, I just merged a PR which allows overriding the confirm prompt using [confirm("prompt")], so there's some churn in attribute stuff.
I think [group: foo], as you have it, is definitely the nicest syntax. If we have it though, we should also have [confirm: "prompt"] too otherwise users will likely get confused.

I think probably the global flag should get -g, since I think it might be more commonly used. The easiest thing to do is probably to not assign short flags to either and wait for someone to complain that one should have a short flag.

Nice!
You might want to rebase, I just merged a PR which allows overriding the confirm prompt using [confirm("prompt")], so there's some churn in attribute stuff.
I think [group: foo], as you have it, is definitely the nicest syntax. If we have it though, we should also have [confirm: "prompt"] too otherwise users will likely get confused.

Solid, I was debating whether [attr: argument] or [attr(argument)] was a better syntax - if there's another attr now that uses () function-like syntax, that seems like the one to go with then.

I think probably the global flag should get -g, since I think it might be more commonly used. The easiest thing to do is probably to not assign short flags to either and wait for someone to complain that one should have a short flag.

Makes sense. This is a feature that I personally want and expect to use reasonably frequently, so I'd want to add a short flag. Maybe -r?

Nice!
You might want to rebase, I just merged a PR which allows overriding the confirm prompt using [confirm("prompt")], so there's some churn in attribute stuff.
I think [group: foo], as you have it, is definitely the nicest syntax. If we have it though, we should also have [confirm: "prompt"] too otherwise users will likely get confused.

Do we want to keep the [confirm(prompt)] syntax around and allow both, or get rid of it?

Makes sense. This is a feature that I personally want and expect to use reasonably frequently, so I'd want to add a short flag. Maybe -r?

Oh, hmmm, I see. --groups will list groups and organize by group when used with --list. So the two uses are just --groups and just --list --groups. What if we made --list organize by group by default? If there are groups in the justfile, I assume that people will want to see them.
Then you wouldn't have to do just --list --groups, which is a super long and annoying invocation. And maybe just --groups is less common, so it doesn't need a short flag?

Do we want to keep the [confirm(prompt)] syntax around and allow both, or get rid of it?

It made it into a release, so we should keep it. But I think the other reason for keeping it is that we might want to have attributes that take multiple arguments. So [attr: arg] is a convenient shorthand when there's a single argument, and [attr(arg)] can be use with one or more arguments.

Makes sense. This is a feature that I personally want and expect to use reasonably frequently, so I'd want to add a short flag. Maybe -r?

Oh, hmmm, I see. --groups will list groups and organize by group when used with --list. So the two uses are just --groups and just --list --groups. What if we made --list organize by group by default? If there are groups in the justfile, I assume that people will want to see them.
Then you wouldn't have to do just --list --groups, which is a super long and annoying invocation. And maybe just --groups is less common, so it doesn't need a short flag?

Do we want to keep the [confirm(prompt)] syntax around and allow both, or get rid of it?

It made it into a release, so we should keep it. But I think the other reason for keeping it is that we might want to have attributes that take multiple arguments. So [attr: arg] is a convenient shorthand when there's a single argument, and [attr(arg)] can be use with one or more arguments.

I like the idea of listing by groups by default. A justfile without any recipes with a [group] will have the same listing behavior as now so it won't break existing behavior. I agree that listing the group names themselves is uncommon and doesn't need a short option. And yeah I think the convention where [attribute: single-arg] is shorthand for [attribute(single-arg)] that doesn't apply to hypothetical multi-argument attributes is fine.

Alright, got this working like so:
justfile:
# Comment
[group: alpha]
a:

[group(alpha)]
[group(beta)]
b:

c:

[group:"multi word group"]
d:

[group("alpha")]
e:

[group: "beta"]
[group(alpha)]
f:

just --list output:
Available recipes:
(no group)
    c
[group: alpha]
    a # Comment
    b
    e
    f
[group: beta]
    b
    f
[group: multi word group]
    d

https://github.com/casey/just/issues/1344 is also probably taken care of by this PR

@casey this is ready for review

when merge?

I'm super busy with another project, so just is sadly being neglected right now. Honestly it'll probably take at least a month before I can start grinding down my GitHub notification backlog, which is insanely large at this point.

@neunenak,
In reading the docs that were added, I'm wondering if you would consider the following output. It's a little more readable to me and is based off of how Django does it.
$ just --list

Available recipes:

[no group]
    email-everyone

[lint]
    cpp-lint
    js-lint
    rust-lint

[rust jobs]
    rust-lint

Instead of:
$ just --list
Available recipes:
(no group)
    email-everyone # Not in a group
[group: lint]
    cpp-lint
    js-lint
    rust-lint
[group: rust jobs]
    rust-lint

@neunenak,
Thank you for the update! I'm really looking forward to this new feature getting added!

@neunenak,
Thank you for the update! I'm really looking forward to this new feature getting added!

Thanks! I'm gonna ping @casey about this PR again, hopefully this can get merged pretty quickly.

I started looking at this, and to be honest I don't really like the refactor into multiple functions. I don't really mind long functions, and generally don't like functions which are defined and only used once. I think I prefer being able to read a long linear function, and not indirect through other functions. Also, it makes the review harder, because it's hard to tell what changed and what didn't. Can you inline it back into a single function in Subcommand::list?


How would you remove a database item?

Hey, very good library so far, I really like the simplicity!
What I was not able to get working so far though is removing items from the database. The documentation does not include an example for that either.

Hi there. The library doesn't include the delete row functionality until now. Thanks for opening the issue. You can now use this functionality using

const db = require('electron-db');
const electron = require('electron');

db.deleteRow('customers', {'id':<PHONE_NUMBER>272}, (succ, msg) => {
  console.log(msg);
});


Update the "Hmm.. It's not here" page to include illustrations

Problem
When you try to access a report that you do not have access to we show a page that is on the duller side compared to the rest of the app:

Solution
Use some of our awesome illustrations to brighten the page up. For example, somthing like this woule be an instant improvement:

Curious what you think for this polish @shawnborton !

Triggered auto assignment to @CortneyOfstad (NewFeature), see https://stackoverflowteams.com/c/expensify/questions/14418#:~:text=BugZero process steps for feature requests for more details.

@shawnborton do we know how long it would take to possibly update this? The reason why I ask is that for Bug Zero, it indicates a WN post and taking this on as a project, but I don't think that this would be necessary. Thoughts?
Side note, I'm also starting my sabbatical at the end of this week so if we decide that a full WN process is needed, I will reapply the new feature label to have another member of BugZero take over 👍

Yeah I think this would be a super easy implementation personally, it's really just a matter of swapping out an icon for an illustration.

I'm on bug zero if needed @CortneyOfstad and I don't think this needs a WN post either. I was in two minds about how to label this honestly.. Its not a new feature really and and not a bug, more of an improvement which we haven't fleshed out in the bug zero process as far as I know

Maybe I should just move this to /Expensify and make it internal? Curious what ya think

No worries @MitchExpensify — definitely have come across some gray area options that just don't fit perfectly 😂
I agree that moving this to /Expensify and making it internal would be more than fine 👍

Cool, will get it over there! Thanks team 😄

@MitchExpensify okay to close this? I'm heading out on sabbatical so wanting to check if this needs to be reassigned or not. Thank you!

lil bump for review @mollfpr

No review needed I took care of it. its now on staging I believe

Nice

Reviewing label has been removed, please complete the "BugZero Checklist".

The solution for this issue has been :rocket: deployed to production :rocket: in version 1.3.3-2 and is now subject to a 7-day regression period :calendar:. Here is the list of pull requests that resolve this issue:

https://github.com/Expensify/App/pull/17642

If no regressions arise, payment will be issued on 2023-04-28. :confetti_ball:
After the hold period is over and BZ checklist items are completed, please complete any of the applicable payments for this issue, and check them off once done.

[ ] External issue reporter
[ ] Contributor that fixed the issue
[ ] Contributor+ that helped on the issue and/or PR

As a reminder, here are the bonuses/penalties that should be applied for any External issue:

Merged PR within 3 business days of assignment - 50% bonus
Merged PR more than 9 business days after assignment - 50% penalty

Made a reminder to pay out on the 28th 😄

Paid with bonus!


Warn users that this package is EOL at installation step

When I was setting up a new project, I had to use URL manipulation. From another project I knew there was this awesome URL package from the thephpleague. So I googled and found this right away. Since I knew this package was good, I installed it immediately and got it working.
Then I ran composer update a week later, and it told me that this package was EOL.
So this PR makes sure that other won't make the same silly mistake I made 🙈 ;)

well I believe this is the first sentence in the README file I can not be more explicit


Make PHI/PII Types Configurable

The PHI definitions and types are listed here in the usage documentation. They are defined in utils.js.
As per internal discussion, these should be configurable via setting. To accomplish this, I think the following should be done:

[ ] Support a new setting in the girder config: phi_pii_types
[ ] Add a default value containing all of the values currently present in the usage docs to the defaultConfig dictionary in config.py
[ ] Remove the value from utils.js, and get the information from the settings object instead (populated by API call)
[ ] Update customization documentation to include the ability to configure PHI/PII types

@manthey Does this seem like a sane approach?

@manthey Does this seem like a sane approach?

Yes, sounds perfect.


Modernize UI using flatlaf.

Add flatlaf dependency.
Change main panels margins to improve visuals.
This PR addresses enhancement request: #140
This is the new look, @superblaubeere27 what do you think?:

Hopefully increases compatibility 👍🏻

@superblaubeere27 Quick note, this is only applied to windows, but noticed some issues with mac on later jdks 15 & 17, when using UIManager.getSystemLookAndFeelClassName(). This display issues seem to be gone when applying this LAF too. Will confirm and open a new PR, for your review.


Tests fail with Weasyprint 57.0

Describe the issue
Given you pinned the Weasyprint version to <57.0, I know this is known, but I don't see an open issue for it.  Pinning to a lower version isn't a viable solution for downstream distributors, so this does need to be fixed:
ERROR: setUpClass (__main__.PdfWriterTests)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/tmp/autopkgtest-lxc.48kx6p_4/downtmp/build.obL/src/xxx/test.py", line 495, in setUpClass
    cls.elements_pdfxml = xmldoc(None, bytes=elements_pdfdoc)
  File "/usr/lib/python3/dist-packages/xml2rfc/walkpdf.py", line 96, in xmldoc
    return lxml.etree.fromstring(text)
  File "src/lxml/etree.pyx", line 3254, in lxml.etree.fromstring
  File "src/lxml/parser.pxi", line 1913, in lxml.etree._parseMemoryDocument
  File "src/lxml/parser.pxi", line 1793, in lxml.etree._parseDoc
  File "src/lxml/parser.pxi", line 1082, in lxml.etree._BaseParser._parseUnicodeDoc
  File "src/lxml/parser.pxi", line 615, in lxml.etree._ParserContext._handleParseResultDoc
  File "src/lxml/parser.pxi", line 725, in lxml.etree._handleParseResult
  File "src/lxml/parser.pxi", line 654, in lxml.etree._raiseParseError
  File "<string>", line 14199
lxml.etree.XMLSyntaxError: PCDATA invalid Char value 23, line 14199, column 11

----------------------------------------------------------------------
Ran 42 tests in 21.851s

FAILED (errors=1)```

Full test log is available at https://ci.debian.net/data/autopkgtest/testing/amd64/x/xml2rfc/27394437/log.gz

### Code of Conduct

- [X] I agree to follow the [IETF's Code of Conduct](https://github.com/ietf-tools/.github/blob/main/CODE_OF_CONDUCT.md)

Confirmed to be a Weasyprint issue fixed in https://github.com/Kozea/WeasyPrint/commit/71e9e257ccc7780f3c4e04893b11210bd06ad626 - closing.


Refactor tests

Subj

@alexbaden there are multiple matters

the recent version of conda run has a bug that it can be broken by some specific option even if this option is a part of a command we want to run; thus I moved commands into dedicated scripts; this also adds to readability

I wanted to remove code and build duplication for some time, so I finally made this along the previous change

I combined pytest and modin tests into one task; this is just a matter of taste; we may discuss further the name for a combined task or I can revert the change

I removed duplicated runs for python python/tests/test_pyhdk_bindings.py and python python/tests/test_pyhdk_sql.py; actually it was I who added them on Igor's request before pytest.yml was created so I have a responsibility to remove them if they are no longer needed; if they are needed I'll add them back, they run second time in a slightly different environment with modin installed; the tests from pytest.yml are moved as is into test-modin.sh

I replaced "Gtests (Sanity)" with "Gtests"  everywhere - this is also subjective and my variant is shorter

I combined pytest and modin tests into one task; this is just a matter of taste; we may discuss further the name for a combined task or I can revert the change; the tests from both pytest.yml and modin.yml were moved as is into test-modin.sh with the following exception (4)

I see... the file should probably be renamed, then.
Regardless - to me, this is a refactoring of existing jobs that is not strictly better than what we had before, with no functional changes (except perhaps merging the HDK + Modin tests, which is still a little unclear - @Garra1980 thoughts?). I also would tend to disagree that moving parts of the test to bash scripts improves readability. To me, it means I need to now look in two places to see what a test is doing, instead of just one.

@alexbaden that's a good question about readability, let me share my thoughts

the idea is to combine multiple lines of code into functional unit which have a descriptive name;
replacing two 200+ line files with one ~10 line file improves things as well

while readability question is subjective, another point has a stronger justification; we know now that conda run command line is buggy (-vx), thus we need to keep it minimal

@alexbaden let me elaborate that second reason a bit
if we will use conda run -n omnisci-dev sh script_name.sh in most places, we ensure their command line parser have less chances to parse our directives incorrectly

@Garra1980 told me, "do not change anything"; closing this PR


Connector build output

Steps to reproduce
Build the solution and the last connector is the only file in the artifacts directory
Expected behavior
Both the SecMgmtInsights.mez and SecMgmtInsights.PowerShell.mez files should be in the artifacts directory
Actual behavior
Only the output from the last built connector is found in the artifacts directory
Environment

Visual Studio 2019

This issue has been resolved with PR #19


No sortBy function available

Hi,
Thanks for starting this package. I definitely miss some of Kotlin's nice functions.
I've found this package when searching for sortBy on Dart Pub, but when I got to use it, there was no such function available.
The README has an example, but I can't find where the sortBy is implemented on the library.
Is the example there correct, or am I missing something?
Thanks

Hey,
Thanks for the info. The method is actually called sortedBy.
I will fix the docs in the next version 👍

The new version is now published ;)


Minor grammar edits

changes come from https://docs.google.com/document/d/1vp5ZMiXnBDN1EvGDk3vizSkwU_kt6iUxOGfOymFbtKA/edit#

Hey, I'm new to open source but I definitely like the look of this project! I'll start with the grammar edits just to ease myself in if that's ok?

Hey @Decmcc!
your help is greatly appreciated but @ellaknox just finished this ticket today. But I'd love to have a chat with you about your use case for our platform. I could invite you to our community Slack if that's alright with you :)

Hi @pascal-airy
Yeah that would be great! I'm very keen! Thanks:)


gulp generic AND gulp server throwing Code Error during build

Hello Snuffleupagus,
Thanks for your response. I cloned the code from https://github.com/mozilla/pdf.js#getting-the-code as suggested by you. Now, the code is throwing error and not working in dev & prod both environments. As I informed you earlier that we are using
Node 11.0.0, Chrome 84 and Windows7 for our development. Please help us to resolve this problem so we can move further and look into customization.
We are getting following errors when we run gulp server command:
Navigated to http://localhost:8888/web/viewer.html
app.js:1765 Uncaught (in promise) SyntaxError: Unexpected token '??=' in app.js
we found below syntax in app.js
this._contentLength ??= contentLength; // See getDownloadInfo-call above.
when I removed ?? then we got below error in ui_utils js.
Uncaught (in promise) SyntaxError: Unexpected token '||=' in ui_utils.js:866
(externalListeners ||= []).push(listener);
We don't know understand why this invalid syntax is there in your code-lab. Please help us to resolve it.
please see the screenshot below

We are getting following errors when we run gulp generic command:
same pdf worker error is coming
Uncaught (in promise) Error: Setting up fake worker failed: "Cannot load script at: http://localhost:8000/build/pdf.worker.js".
at api.js:2047
We don't see pdf.worker.js file in build folder.
build folder conatins only pdf.js and pdf.sandbox
please see the screen shot below.

Originally posted by @Faizranas in https://github.com/mozilla/pdf.js/issues/12860#issuecomment-761528497

Duplicate of #12860; please do not knowingly "spam" the bug tracker with duplicated issues!

Duplicate of #12860; please do not knowingly "spam" the bug tracker with duplicated issues!


The messaging between several users don't work

When I try to send a message to other user he don't recieve it. In the error-log I've got:
2015-09-26 10:33:29,381 ERROR    WebSocket
Traceback (most recent call last):
  File "/usr/lib/python2.7/dist-packages/sockjs/tornado/transports/websocket.py", line 59, in on_message
    self.session.on_messages(msg)
  File "/usr/lib/python2.7/dist-packages/sockjs/tornado/session.py", line 420, in on_messages
    self.conn.on_message(msg)
  File "/home/zulip/deployments/2015-09-26-19-22-05/zerver/lib/socket.py", line 167, in on_message
    self.authenticate_client(msg)
  File "/home/zulip/deployments/2015-09-26-19-22-05/zerver/lib/socket.py", line 139, in authenticate_client
    status = redis_client.hgetall(req_redis_key(inquiry))
  File "/usr/lib/python2.7/dist-packages/redis/client.py", line 1228, in hgetall
    return self.execute_command('HGETALL', name)
  File "/usr/lib/python2.7/dist-packages/redis/client.py", line 364, in execute_command
    connection.send_command(*args)
  File "/usr/lib/python2.7/dist-packages/redis/connection.py", line 301, in send_command
    self.send_packed_command(self.pack_command(*args))
  File "/usr/lib/python2.7/dist-packages/redis/connection.py", line 283, in send_packed_command
    self.connect()
  File "/usr/lib/python2.7/dist-packages/redis/connection.py", line 231, in connect
    raise ConnectionError(self._error_message(e))
ConnectionError: Error 111 connecting <IP_ADDRESS>:6379. Connection refused.

I installed server on the virtual machine (Ubuntu 14.04) I followed instructions from here https://zulip.org/server.html. Also I created self-signed ssl-certificate for ip-address of my vm.

I had the same issue. thte default redis config they write has settings not supported by ubuntu's included reddis. I commented them out, restarted reddis and it worked.

@carlokok Can you give the instruction how to fix it?

run /etc/init.d/reddis start,
it will fail with a line number, something with "vm" in it, open the reddis config file in /etc/reddis/ and pretty much remove everything from that line on.

Thank you! it seems that deprecated settings failed redis to start

I just checked and it looks like the only things we changed from the Debian Redis 2.4.14 package was commenting out saving:
-save 900 1
-save 300 10
-save 60 10000
+# save 900 1
+# save 300 10
+# save 60 10000

So I'm testing replaced Zulip puppet's configuration file with redis with the default trusty version + saving disabled.


Link to releases

Extend documentation to provide a link to available releases for those users that are not too familiar with using github. See e.g.Jenkins plugin

Direct link to latest release


Getting error in React App: Uncaught TypeError: _c.getElementById is not a function

Hi
I'd like to use a separate control bar in React App 18.2.0 and media-chrome 1.4.3, but getting this error:
media-control-bar.js:77 Uncaught TypeError: _c.getElementById is not a function
    at MediaControlBar.attributeChangedCallback (media-control-bar.js:77:1)
    at setValueForProperty (react-dom.development.js:798:1)
    at setInitialDOMProperties (react-dom.development.js:9720:1)
    at setInitialProperties (react-dom.development.js:9921:1)
    at finalizeInitialChildren (react-dom.development.js:10950:1)
    at completeWork (react-dom.development.js:22193:1)
    at completeUnitOfWork (react-dom.development.js:26596:1)
    at performUnitOfWork (react-dom.development.js:26568:1)
    at workLoopSync (react-dom.development.js:26466:1)
    at renderRootSync (react-dom.development.js:26434:1)

And here's my simple component:
        <div>
          <MediaController id="mc">
            <video slot="media" poster={poster} src={url}>
              <track src="" kind="captions" srcLang="en" />
            </video>
          </MediaController>
          <MediaControlBar mediaController="mc">
            <MediaPlayButton />
            <MediaSeekBackwardButton />
            <MediaSeekForwardButton />
            <MediaTimeRange />
            <MediaTimeDisplay showDuration />
            <MediaMuteButton />
            <MediaVolumeRange />
          </MediaControlBar>
        </div>

How can I fix that?

Thanks for filing the issue and providing relevant libraries/version numbers, @rizametovd ! I'll try to take a look at what's going on here ASAP. Will keep you posted on anything I uncover.

@cjpillsbury thanks in advance!
Meanwhile, may I one more question. There's a warning in console in my React App as well as in Media-Chrome Docs basic example: https://media-chrome.mux.dev/examples/vanilla/basic.html . Is it expected behavior?
content.js:1 CssSelectorGenerator: shadow root inferred You did not provide a root and the element is a child of Shadow DOM. This will produce a selector using ShadowRoot as a root. If you plan to use the selector using document as a root (e.g. document.querySelector), it will not work as intended.

hmmmm I'm not seeing that warning on https://media-chrome.mux.dev/examples/vanilla/basic.html when loaded into the latest versions of Chrome, Firefox, or Safari for macOS. Is this possibly a plugin/extension you have installed? Unless I missed something, CssSelectorGenerator isn't part of the media chrome codebase?

Unfortunately I don't know much about CssSelectorGenerator. I don't get this error if I use e.g. native html video tag or ReactPlayer. That is why I asked about console warning

Yeah I'm pretty sure that warning is not coming from our codebase. Not even sure what "content.js" is.

Found the issue (fixed in PR mentioned above)! Should have a release out soon. Surprised no one's run into this yet 😅.

Ok fix is released in a canary build: 1.4.4-canary.0-3bf7d18
Here's a codesandbox confirming that the issue is resolved in the canary build: https://codesandbox.io/s/magical-satoshi-qrp82z
If you don't mind testing it out on your end just to make sure it resolves your issue, that would be greatly appreciated. We should get an official build out soon regardless.


Add sepolia config

Description
Once it's properly merged.... https://github.com/eth-clients/merge-testnets/pull/14

Now merged.


It should exist a Summary editor for each part with formatted data content

BodyPart for exemple, but also LayoutPart.
This Summary edited data should be automatically used, if present, by all the default xxx.Summary.cshtml templates.
The actual default action for summary views is to truncate in the less dangerous place, not always good results when you are not blind and if an image is present, you can't keep it.
Yes I know that it is easy to add a second editable part to each contentitem where I need a summary view and redefine all my summary view to look if this part exists in the contentitem and use it in place of the blind truncate.
We could have an internal process for body part to input full text and summary text in the same dit session (maybe some tab to access summary). Same for other parts with formated input.
I am sure I am not the only.
Ideally we could input as many values as display types used.

Different people want different mechanisms for their summaries, of which you mention a few. I use the WordPress convention of including a <!--more--> cutting mark in the body where I want the summary to end: https://weblogs.asp.net/bleroy/my-body-summary-template-for-orchard

Astucieux, but different from writing a summary.

You've mentioned the other valid solution for writing a summary. It's not clear what you're asking for.

Yes I discovered that Orchard itself is not clear, si I adapt to the env. Great but not clear.
Envoyé à partir de mon sanyo phc 25

De : Bertrand Le<EMAIL_ADDRESS>Envoyé : 27/11/2015 09:50
À<EMAIL_ADDRESS>Cc<EMAIL_ADDRESS>Objet : Re: [Orchard] It should exist a Summary editor for each part with formatted data content (#6083)
You've mentioned the other valid solution for writing a summary. It's not clear what you're asking for.

Reply to this email directly or view it on GitHub:
https://github.com/OrchardCMS/Orchard/issues/6083#issuecomment-160074797

Another option could be to have a TextSummary string property added in the bodyPart.
I could create a BodyExPart but it means replacing the BodyPart in all the contentitems where Orchard or my own devs are using it. And BodyPart is in Core so I expect a lot of difficulties and not friendly code as replacing some dependencies ?
It would be easier to add  the new property in the xisting BodyPart and adapt is drivers/templates.


fix: remove dependency on im-rs

im-rs isn't super maintained, and our use really doesn't rise to needing the dep.

bors merge


fix(core): update login page & error message styles

What/Why?
This PR updates layout & styles for Login page that include:

reducing size for heading,
reduce margin bootom,
center "Forgot password" button on mobile

Also it unites message size & colour for error validation on form fields.
Testing
locally
https://github.com/user-attachments/assets/75a2be6d-0144-42b7-87e3-3ba71ed04436

Make sure to add a changeset


Is there a way to make it write longer texts?

it usually only outputs one paragraph, is there a way to make it write a more detailed and longer texts?

You could try and ask for a more elaborate and detailed answer by changing the template in in utils/makechain.ts?

I can control that in my fork by the maxTokens parameter that I am altering like this: https://github.com/groovybits/gaib/blob/main/utils/makechain.ts#L23 Also see how the prompts can provoke more complex / longer answers too. (I have more prompts setup in a config file in my fork you will notice).


Feature grow midi notes

Adds trim note left / right actions.
I don't get the command to work tho.

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


Dex Role and Rolebinding missing

Describe the bug
After creating a new ArgoCD instance with dex enabled, the integration with OpenShift SSO is not working, main reason is the missing DEX role(binding).
In other examples, on the same cluster is the ArgoCD creation with Dex integration working fine
To Reproduce
Steps to reproduce the behavior:

Create new ArgoCD kind
SSO not working
Role and Rolebinding for DEX is not available

Expected behavior
OpenShift SSO is working with ArgoCD
Screenshots
n/a
Additional context
Logs from dex pod
W1114 12:08:00.728631 1 reflector.go:324] pkg/mod/k8s.io/client-go@v0.23.1/tools/cache/reflector.go:167: failed to list *v1.Secret: secrets is forbidden: User "system:serviceaccount:bla-toolchain-gitops:bla-toolchain-gitops-argocd-dex-server" cannot list resource "secrets" in API group "" in the namespace "bla-toolchain-gitops"
E1114 12:08:00.728667 1 reflector.go:138] pkg/mod/k8s.io/client-go@v0.23.1/tools/cache/reflector.go:167: Failed to watch *v1.Secret: failed to list *v1.Secret: secrets is forbidden: User "system:serviceaccount:bla-toolchain-gitops:bla-toolchain-gitops-argocd-dex-server" cannot list resource "secrets" in API group "" in the namespace "bla-toolchain-gitops"

oc get role -n bla-toolchain-gitops
NAME                                                 CREATED AT
bla-toolchain-gitops-applicationset-controller       2022-11-14T09:15:18Z
bla-toolchain-gitops-argocd-application-controller   2022-11-14T09:15:15Z
bla-toolchain-gitops-argocd-redis                    2022-11-14T09:15:15Z
bla-toolchain-gitops-argocd-server                   2022-11-14T09:15:15Z
bla-toolchain-gitops-read                            2022-11-14T09:15:15Z

ArgoCD Kind spec
spec:
  server:
    autoscale:
      enabled: false
    grpc:
      ingress:
        enabled: false
    ingress:
      enabled: false
    resources:
      limits:
        cpu: 500m
        memory: 256Mi
      requests:
        cpu: 50m
        memory: 128Mi
    route:
      enabled: true
      tls:
        termination: reencrypt
    service:
      type: ''
  grafana:
    enabled: false
    ingress:
      enabled: false
    route:
      enabled: false
  prometheus:
    enabled: false
    ingress:
      enabled: false
    route:
      enabled: false
  applicationSet:
    resources:
      limits:
        cpu: 500m
        memory: 1Gi
      requests:
        cpu: 50m
        memory: 512Mi
  rbac:
    defaultPolicy: ''
    policy: |
      g, bla-toolchain, role:admin
    scopes: '[groups]'
  repo:
    resources:
      limits:
        cpu: '1'
        memory: 1Gi
      requests:
        cpu: 50m
        memory: 256Mi
  resourceExclusions: |
    - apiGroups:
      - "tekton.dev"
      kinds:
      - "PipelineRun"
      - "TaskRun"
      clusters:
      - "*"
  dex:
    groups:
      - bla-toolchain
    openShiftOAuth: true
    resources:
      limits:
        cpu: 500m
        memory: 256Mi
      requests:
        cpu: 50m
        memory: 128Mi
  ha:
    enabled: false
    resources:
      limits:
        cpu: 500m
        memory: 256Mi
      requests:
        cpu: 50m
        memory: 128Mi
  tls:
    ca: {}
  redis:
    resources:
      limits:
        cpu: 500m
        memory: 256Mi
      requests:
        cpu: 50m
        memory: 128Mi
  controller:
    processors: {}
    resources:
      limits:
        cpu: '1'
        memory: 2Gi
      requests:
        cpu: 250m
        memory: 1Gi
    sharding: {}

OpenShift 4.10.4
OpenShift GitOps 1.5.6

The problem is, if dex.groups is used.
I do not face the issue, if dex.groups is empty/not set!


[Mopidy: Failed to add some tracks]

I have installed the mopidy Container alone
and i inserted all Variables from Spotify.
Added my own Icecast Server for Playout.
When i click on a song or Playlist, i get the Error:
Mopidy: Failed to add some tracks
Any Help for this Issue?

If you run docker-compose logs -f from the root of the repo, what do you get? Mopidy is hardwired to use the built in liquidsoap server. You will need to edit the mopidy.conf file to get it to point to your icecast server.
It might be worth running the mopidy container from the official repo if that is what you want: https://hub.docker.com/r/jaedb/iris

If you run docker-compose logs -f from the root of the repo, what do you get? Mopidy is hardwired to use the built in liquidsoap server. You will need to edit the mopidy.conf file to get it to point to your icecast server.
It might be worth running the mopidy container from the official repo if that is what you want: https://hub.docker.com/r/jaedb/iris

Closing due to inactivity


Interface for getting pressed floors of an elevator (fixes #35).

Remove undocumented function getFirstPressedFloor.

Nice. I would prefer to name the function:
getFloorButtonStates()

Hmmm.. or maybe that should be a separate function. This one is like a helper function I suppose.

The internal elevator.buttonStates is an array of booleans for each floor but this function returns the numbers of the floors which have true in that. I thought this would be more useful as more often you'd want to know if any floors are pressed or get the first/last pressed floor or maybe even get the next pressed floor up/down from your current floor. Having a function return the boolean states would mean having to do that iteration manually every time any kind of such operation is wanted. But this is just my opinion...

Yeah this is good.

I will merge and then put back the removed function with a deprecation warning. Don't want to break people's code more than necessary.


Added metadata.json for Kaichat to select models

To fix issue #22

Looks good for metadata json. I like your format and maybe we can apply the same to other projects
For now, can you update the function for Quizzify under app/features/Quizzify/tools.py for where we actually call the model? I think we manually create a VertexAI instance and pass the hardcoded gemini-1.0-pro-002 but now that you have this on metadata use that variable instead

Done the changes. Could you please review it when you get time ? Thank you

Sure !!!

Since Langchain released a new way to authenticate outside of just the VertexAI class, we can actually use the GoogleGenerativeAI class and specify the model there
We will also need to have the model name definition within the metadata.json of the respective tool rather than separate file i suppose


Example not working on Android emulator

Installing and running the example on a local emulator (qemu x86_64) the app launches but no results are displayed.
Am i missing something?

Hi, yeah, you should enable mic in the settings - https://stackoverflow.com/questions/5924190/how-do-you-enable-a-microphone-input-in-the-android-emulator


Argument Type Error in Array Field

Amplify CLI Version
12.12.2
Question
// Model
Todo: a.model({
  content: a.string(),
  tags: a.string().array(),
})

// Nuxt 3 code.
I have created a plugin and can use $Amplify by following the steps in this document. Note: the link may redirect to Gen 1, but please check for Gen 2.
  const { data, errors } = await $Amplify.GraphQL.client.models.Todo.get(
    {
      id: '123456',
    },
    {
      selectionSet: ['tags'],
      authMode: 'userPool',
    },
  );

  const isTag = data.tags.includes('SPORTS');

The following code displays the type error: Argument of type 'string' is not assignable to parameter of type 'string[]'. When I hover over data, I see readonly tags: string[][];. Why does it show a 2D array when I have tags: ['SPORTS', 'TECH', 'MARKETING']?

Hi @jewells07 I was not able to reproduce this issue with the given schema and code snippet.
Here's a screenshot of the type when I hover over data.tags

And here's my reproduction app - the code is on the issue2682 branch
I did run into some errors around types, not the exact one you ran into. I had to uninstall the Vetur extension in VSCode, restarting VSCode (not just extensions), and making sure all my amplify packages were up to date by running the following commands:
npm i @aws-amplify/backend@latest @aws-amplify/backend-cli@latest

and
npm update @aws-amplify/data-schema

/
Hi 👋 Closing this as we have not heard back from you. If you are still experiencing this issue and in need of assistance, please feel free to comment and provide us with any information previously requested by our team members so we can re-open this issue and be better able to assist you.
Thank you!


[SEDONA-39] Fix lon/lat order in ST_Transform to be consistent with PostGIS

Did you read the Contributor Guide?

Yes, I have read Contributor Rules and Contributor Development Guide

Is this PR related to a JIRA ticket?

Yes, the URL of the assoicated JIRA ticket is https://issues.apache.org/jira/browse/SEDONA-39. The PR name follows the format [SEDONA-39] my subject.

What changes were proposed in this PR?
How was this patch tested?
Did this PR include necessary documentation updates?

Yes, I am adding a new API. I am using the current SNAPSHOT version number in since vX.Y.Z format.

Hi @jiayuasu ,
I think we should be aligned with PostGIS.
However, we must be clear about staying with lat/lon order and emphasize that users need to update their code if they use this version.

I agree with @netanel246 we should be consistent with what Postgis does. And definitely we need communicate that clearly with users.

@netanel246 @Imbruced Got it. I will then continue working on this PR.


pybitmessage dependency fixes & pytools 2016.2.1 -> 2017.4

Motivation for this change
forgot dependencies, upgraded pytools for it
Things done

[ ] Tested using sandboxing
(nix.useSandbox on NixOS,
or option build-use-sandbox in nix.conf
on non-NixOS)
Built on platform(s)

[x] NixOS
[ ] macOS
[ ] Linux

[ ] Tested via one or more NixOS test(s) if existing and applicable for the change (look inside nixos/tests)
[x] Tested compilation of all pkgs that depend on this change using nix-shell -p nox --run "nox-review wip"
[x] Tested execution of all binary files (usually in ./result/bin/)
[x] Fits CONTRIBUTING.md.

cc @Mic92

Here's btw why it worked without the deps:
https://github.com/Bitmessage/PyBitmessage/blob/master/src/openclpow.py#L22
(how creative!)


Add option to CLI to generate gziped output

It would be nice for cow to produce gzipped output from the CLI:
cow_tool convert my.csv --gz
Currently serialization to a file is hard-coded, so this brings up the bigger issue of serializing to stdout instead, and then having a parameter to serialize to a (gzipped) file if needed

I'm keeping the issue open, but recommend dropping this feature from the backlog (not developing it at all). Developing a feature like this will take away time from the core development of CoW, which is converting CSVs to linked data. A second reason is that it violates the UNIX principle of command-line tools: do one thing well. In short, CoW shouldn't try too much if other tools are already perfect solutions for it, the documentation can always be expanded to explain how to use those tools.
Finally, there are a myriad of command-line tools and software solutions to gzip a CSV. It also doesn't take too long, as I gzipped a 3.5GB CSV file to 0.9GB within a matter of minutes.

Hi Albert, Melvin;
To make this ability easily accessible for the less technical skilled user, I've implemented this function in the base COW branch. You can tell COW to produce gzipped output with the '--gzip' flag.

Xander


test: render with events utility refactoring

Motivation
Using an $on callback for testing is deprecated in Svelte v5 (PR #548). Instead, we will now use the events option of render, which itself will eventually be replaced by the library. To minimize changes in the Svelte v5 PR, we refactored the test to use a utility function that handles rendering and event binding.
Changes

Introduce and use renderWithEvents utilitiy.

So the events that we are passing now are at the same time new and already deprecated?

Yes, kind of. We do it this way so we don’t have to migrate all components at once. It reduces the number of changes needed for the upgrade by solely adapting few tests.

Is that TODO specific to that one test or would it apply to all tests?

Once this PR is merged and rebased into the Svelte v5 branch, only one TODO will remain.


Unexpected case-sensitive search result

Describe the bug
When the search query matches a term exactly (character for character), the search result appears to become case-sensitive unexpectedly, seemingly falling back to typo tolerance rules.
To Reproduce
Reproduction using a fresh, unconfigured index, using PHP:
> $client->deleteIndex('test')
= [
    "taskUid" => 204897,
    "indexUid" => "test",
    "status" => "enqueued",
    "type" => "indexDeletion",
    "enqueuedAt" => "2023-06-30T14:20:15.49074795Z",
  ]
> $client->index('test')->addDocuments([['id' => 1, 'test' => 'TestAB']])
= [
    "taskUid" => 204899,
    "indexUid" => "test",
    "status" => "enqueued",
    "type" => "documentAdditionOrUpdate",
    "enqueuedAt" => "2023-06-30T14:20:35.571879172Z",
  ]
> $client->index('test')->search('testa')->count()
= 1
> $client->index('test')->search('testab')->count()
= 0
> $client->index('test')->search('Testab')->count()
= 0
> $client->index('test')->search('TestAb')->count()
= 1
> $client->index('test')->search('testaB')->count()
= 1
> $client->index('test')->search('TestaB')->count()
= 1
> $client->index('test')->search('TestAB')->count()
= 1

This also occurs if the "offending" term appears in a much longer document.
Expected behavior
The search should be case insensitive even if a word is matched exactly.
Meilisearch version:
v1.2.0

Bonus: Capitalized words also lead to weirdness with typo tolerance.
Document contains lowercase "word":
> $client->deleteIndex('test')
= [
    "taskUid" => 221303,
    "indexUid" => "test",
    "status" => "enqueued",
    "type" => "indexDeletion",
    "enqueuedAt" => "2023-07-03T11:07:17.486684029Z",
  ]
> $client->index('test')->addDocuments([['id' => 1, 'test' => 'testab']])
= [
    "taskUid" => 221307,
    "indexUid" => "test",
    "status" => "enqueued",
    "type" => "documentAdditionOrUpdate",
    "enqueuedAt" => "2023-07-03T11:07:31.826627782Z",
  ]
> $client->index('test')->search('tetsab')->count()
= 1

Index contains "word" with capital letters:
> $client->deleteIndex('test')
= [
    "taskUid" => 221314,
    "indexUid" => "test",
    "status" => "enqueued",
    "type" => "indexDeletion",
    "enqueuedAt" => "2023-07-03T11:08:01.78582517Z",
  ]
> $client->index('test')->addDocuments([['id' => 1, 'test' => 'TestAB']])
= [
    "taskUid" => 221315,
    "indexUid" => "test",
    "status" => "enqueued",
    "type" => "documentAdditionOrUpdate",
    "enqueuedAt" => "2023-07-03T11:08:06.938675556Z",
  ]
> $client->index('test')->search('tetsab')->count()
= 0
> $client->index('test')->search('TetsAB')->count()
= 0

@Nextra thanks so much for raising this and your detailed steps 🙏🏻 We have an issue alreadythat we are targeting to add to v1.3.0 that should address this problem. That issue is here for reference: https://github.com/meilisearch/meilisearch/issues/3818

Ping from triage:

Severity 2 to 3: Affects a specific case of relevancy, very surprising results, workaround: index documents lowercased
Size medium

Hello 👋
Just wanted to highlight we have released the first RC (release candidate) of Meilisearch containing this change!
You can test it by using

the release assets
the Meilisearch Docker image

docker run -it --rm -p 7700:7700 -v $(pwd)/meili_data:/meili_data getmeili/meilisearch:v1.3.0-rc.2

If you encounter any bugs, please report them here.
Thanks in advance for your help and your involvement in Meilisearch ❤
🎉 The official and stable release containing this change will be available on July 31st, 2023
⚠ RC (release candidates) are not recommended for production


Update New-AzureADMSIdentityProvider.md

Updating the list of supported Identity Providers.

Docs Build status updates of commit 094334a:
:white_check_mark: Validation status: passed

File
Status
Preview URL
Details

azureadps-2.0-preview/AzureAD/New-AzureADMSIdentityProvider.md
:white_check_mark:Succeeded

For more details, please refer to the build report.
Note: If you changed an existing file name or deleted a file, broken links in other files to the deleted or renamed file are listed only in the full build report.

https://docs.microsoft.com/en-us/graph/api/identityprovider-post-identityproviders?view=graph-rest-1.0
The 'type' field mentions that idp for b2B scenarios can be only google. We can say the same here. That for non-b2c tenants, only Google is allowed.

Please don't make changes to the online content. make the change in the PowerShell source code instead.


[Snyk] Security upgrade fastlane from 2.214.0 to 2.215.0

This PR was automatically created by Snyk using the credentials of a real user.Snyk has created this PR to fix one or more vulnerable packages in the `rubygems` dependencies of this project.
Changes included in this PR

Changes to the following files to upgrade the vulnerable dependencies to a fixed version:

Gemfile

Gemfile.lock

Vulnerabilities that will be fixed
With an upgrade:

Severity
Priority Score (*)
Issue
Breaking Change
Exploit Maturity

551/1000  Why? Recently disclosed, Has a fix available, CVSS 5.3
Uncontrolled Resource Consumption SNYK-RUBY-REXML-6861566
No
No Known Exploit

(*) Note that the real score may have changed since the PR was raised.
Check the changes in this PR to ensure they won't cause issues with your project.

Note: You are seeing this because you or someone else with access to this repository has authorized Snyk to open fix PRs.
For more information:
🧐 View latest project report
🛠 Adjust project settings
📚 Read more about Snyk's upgrade and patch logic

Note: This is a default PR template raised by Snyk. Find out more about how you can customise Snyk PRs in our documentation.
Learn how to fix vulnerabilities with free interactive lessons:
🦉 Uncontrolled Resource Consumption

CircleCI App Distribution

Platform
Android

Name
Sunflower

ReleaseVersion
0.1.6

BuildVersion
1

Identifier
com.google.samples.apps.sunflower

Install URL
https://output.circle-artifacts.com/output/job/c5a566bd-d0bd-4542-9304-633cb1e17361/artifacts/0/index.html

QR Code


Update validation rules

src/Sdk/Validation/Validator.php:136

Please add safety to the usage of indexes, if for any reason \preg_match_all doesn't populate $matches properly you will get an exception for undefined index that you don't control because doesn't extends your exceptions.

src/Sdk/Validation/Validator.php:130

This explode might introduce a BC to the current implementation of the sdkblueprint.

The issue is with Regex validation rule, if you have a rule that defines a regex with a pipe in it this will break down the regex in multiple fragments.

Need to make sure to update the implementations before deploying it.

Yes completely agree but it means that we have to update the applications using the sdkblueprint to pass an array everytime we have a regex validation, not an issue but we have to do it.

I think that we are never too safe :) Let's add the safety to avoid having to change the code if one day \preg_match_all behaviour changes.

I agree that we need to be safe when we use array indexes in our code. However, IMO, the case is different here as the logic
 foreach (\array_keys($matches[0]) as $key) {
                $rules[$matches[1][$key]] = $matches[2][$key];
            }
 ``` is tight too much to the returned value of `preg_match_all`. Thus, if some day, the behavior of `preg_match_all` changed or the regex pattern changed, the code should break and we should updated the code accordingly. If we put the safety check, we may introduce a bug which can be hard to debug as all the tests will pass by the safety check. What do you think?

@{d433845b-4824-46f7-a4e5-e198e09c023c,Nathan Page}, I have added one more rule called in in order to add validation rule for currency in Pcizone SDK. Please review if you have a chance.


DisposeAsync

Implement the DisposeAsync method on the JinagaClient. It should perform an Unload, which awaits all pending operations.
Any calls to Fact, Query, Watch, or Subscribe after calling DisposeAsync should throw ObjectDisposedException.
Document an example that uses DisposeAsync to delete a local database. The example should:

Support IoC
Ensure that the outbound queue is empty
Continue user interaction before the task resolves
Clean up on application restart

Released in Jinaga 1.0.6


SSM: PutParameter requires Type for parameter updates

moto version: 4.1.11 using Python mocks (boto3 1.22.12/botocore 1.25.12)
Per AWS documentation, specifiying a Type in PutParameter request is not required when updating a parameter. However, when using moto, PutParameter Type field is required even if the parameter already exists and is intended to be updated.
import os

import boto3
import moto

os.environ = {
    "AWS_DEFAULT_REGION": "us-east-1",
    "AWS_ACCESS_KEY_ID": "testing",
    "AWS_SECRET_ACCESS_KEY": "testing",
    "AWS_SESSION_TOKEN": "testing",
}

with moto.mock_ssm():
    ssm_client = boto3.client("ssm")
    ssm_client.put_parameter(
        Description="Description",
        Name="Name",
        Type="String",
        Value="Value",
    )
    ssm_client.put_parameter(
        Name="Name",
        Overwrite=True,
        Value="UpdatedValue",
    )

In the code above, the second put_parameter call fails unexpectedly with the following exception.
botocore.exceptions.ClientError: An error occurred (ValidationException) when calling the PutParameter operation: 1 validation error detected: Value 'None' at 'type' failed to satisfy constraint: Member must satisfy enum value set: [SecureString, StringList, String]

When I tested this under moto 3.1.8, the Type parameter is not required for put_parameter. However, because the second call to put_parameter lacks a Type parameter, subsequent calls to describe_parameters results in a response that lacks a Type for parameters. The expected result in this case is that the parameter maintains the Type supplied in the initial put_parameter call that created the parameter.

Hi @joshuapmorgan, welcome to Moto! Thanks for raising this and for providing the repro - marking it as a bug.

@bblommers I can take a look

@rafcio19 I'm opening this back up, as the PR only solved one problem - the validation issue.
This is still outstanding:

The expected result in this case is that the parameter maintains the Type supplied in the initial put_parameter call that created the parameter.

I have installed the latest release (moto-4.1.13.dev24) and I am still getting an error when not including Type which is optional according to the SSM Docs.
Error: botocore.exceptions.ClientError: An error occurred (ValidationException) when calling the PutParameter operation: A parameter type is required when you create a parameter.

@bfbenf the OP's example is working like expected for me, from our tests:
@mock_ssm
def test_update_parameter():
    # Setup
    client = boto3.client("ssm", "us-east-1")
    param_name = "test_param"
    param_type = "String"
    updated_value = "UpdatedValue"
    client.put_parameter(
        Description="Description",
        Name=param_name,
        Type=param_type,
        Value="Value",
    )

    # Execute
    response = client.put_parameter(
        Name=param_name,
        Overwrite=True,
        Value=updated_value,
    )
    new_param = client.get_parameter(Name=param_name)

    # Verify
    assert response["ResponseMetadata"]["HTTPStatusCode"] == 200
    assert new_param["Parameter"]["Type"] == param_type
    assert new_param["Parameter"]["Value"] == updated_value

Can you try this test or share a code sample that's failing?

@rafcio19
Sorry, it took a while to get back to you. When I run the following, I get this error.
According to https://boto3.amazonaws.com/v1/documentation/api/latest/reference/services/ssm/client/put_parameter.html Type is an optional param
import unittest

import boto3
from moto import mock_ssm

@mock_ssm
class TestExample(unittest.TestCase):
    def test_update_parameter(self):
        # Setup
        client = boto3.client("ssm")
        client.put_parameter(
            Name="test/with/type",
            Type="String",
            Value="Value",
        )

        # Execute
        client.put_parameter(
            Name="test/without/type",
            Value="value",
        )

E
======================================================================
ERROR: test_update_parameter (tests.test_moto.TestExample)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/Users/bfbenf/dev/brewconf-wrapper/src/.venv/lib/python3.10/site-packages/moto/core/models.py", line 128, in wrapper
    result = func(*args, **kwargs)
  File "/Users/bfbenf/dev/tests/test_moto.py", line 19, in test_update_parameter
    client.put_parameter(
  File "/Users/bfbenf/dev//src/.venv/lib/python3.10/site-packages/botocore/client.py", line 534, in _api_call
    return self._make_api_call(operation_name, kwargs)
  File "/Users/bfbenf/dev/src/.venv/lib/python3.10/site-packages/botocore/client.py", line 976, in _make_api_call
    raise error_class(parsed_response, operation_name)
botocore.exceptions.ClientError: An error occurred (ValidationException) when calling the PutParameter operation: A parameter type is required when you create a parameter.

----------------------------------------------------------------------
Ran 1 test in 0.500s

FAILED (errors=1)

@bfbenf that's an expected error, Type is required when creating a new SSM parameter and you are creating a new parameter test/without/type:

Type (string) –
The type of parameter that you want to add to the system.
...
Warning
Specifying a parameter type isn’t required when updating a parameter. You must specify a parameter type when creating a parameter.

See https://boto3.amazonaws.com/v1/documentation/api/latest/reference/services/ssm/client/put_parameter.html


Use latest proguard

"Hidden" proguard update, split off from from https://github.com/com-lihaoyi/mill/pull/1933
It has Java 18 EA support, so I removed some checks where proguard was wouldn't run on Java 11

Do we care about https://github.com/com-lihaoyi/mill/blob/8409244890e4cffff0d159b7bc24fc500147e962/contrib/proguard/test/src/ProguardTests.scala#L22 being 2.13.8?
If not, I think this update is done. Thanks @lefou

Do we care about
https://github.com/com-lihaoyi/mill/blob/8409244890e4cffff0d159b7bc24fc500147e962/contrib/proguard/test/src/ProguardTests.scala#L22
being 2.13.8?
If not, I think this update is done. Thanks @lefou

Nice catch. Yes, we do. We define some sys properties in build.sc, e.g. TEST_SCALA_2_12_VERSION and TEST_SCALA_2_13_VERSION, and use then like this:
https://github.com/com-lihaoyi/mill/blob/62cf005d177b5e40e40dcf37602c7b5ef72d9a69/contrib/scoverage/test/src/HelloWorldTests.scala#L193

When I run mill contrib.proguard.test with override def scalaVersion = "2.12.1" changed to override def scalaVersion: String = sys.props.getOrElse("MILL_SCALA_2_13_VERSION", "2.13.8"), I get:
[error] ...../contrib/proguard/test/src/ProguardTests.scala:22:18: incompatible type in overriding
[error] def scalaVersion: mill.T[String] (defined in trait ScalaModule);
[error]  found   : String
[error]  required: mill.T[String]
[error]     (which expands to)  mill.define.Target[String]
[error]     override def scalaVersion: String = sys.props.getOrElse("MILL_SCALA_2_13_VERSION", "2.13.8")
[error]                  ^

I looked at HelloWorldTests but don't see how to cast a String to a Mill task/T. I haven't written any mill commands/tasks, could you help me understand how to solve this?

When I run mill contrib.proguard.test with override def scalaVersion = "2.12.1" changed to override def scalaVersion: String = sys.props.getOrElse("MILL_SCALA_2_13_VERSION", "2.13.8"), I get:
[error] ...../contrib/proguard/test/src/ProguardTests.scala:22:18: incompatible type in overriding
[error] def scalaVersion: mill.T[String] (defined in trait ScalaModule);
[error]  found   : String
[error]  required: mill.T[String]
[error]     (which expands to)  mill.define.Target[String]
[error]     override def scalaVersion: String = sys.props.getOrElse("MILL_SCALA_2_13_VERSION", "2.13.8")
[error]                  ^

I looked at HelloWorldTests but don't see how to cast a String to a Mill task/T. I haven't written any mill commands/tasks, could you help me understand how to solve this?

You are accidentally redefining the return type to String whereas it should be Target[String] or T[String] (T is an alias for Target). You want something like this:
override def scalaVersion: T[String] = T(sys.props.getOrElse("MILL_SCALA_2_13_VERSION", ???))

Please keep the ???, so we can detect situations, in which the property is missing.

I did some testing and for versions after scala 2.12.11 (for the test scalaVersion) I was getting:
Warning: scala.collection.immutable.VM: can't find referenced method 'void invoke()' in library class java.lang.invoke.MethodHandle
Note: scala.Enumeration accesses a field 'MODULE$' dynamically
Warning: there were 1 unresolved references to library class members.
         You probably need to update the library versions.
         (https://www.guardsquare.com/proguard/manual/troubleshooting#unresolvedlibraryclassmember)
Unexpected error
java.io.IOException: Please correct the above warnings first.

I've don't know much at all about proguard, but when searching the error I saw a lot of suggestions around "dontwarn".
The next commit puts a dontwarn in, and also an error log to try and make any users aware of something that may not be best practice with proguard.

If someone wants to optimise proguard later, they might be able to fix warnings like Note: duplicate definition of library class [jdk.internal.jrtfs.JrtPath] with stuff like https://stackoverflow.com/a/40077713/4261132 too

Just moved to another branch to update a different dep and have proguard failing as max JDK support is 14. This PR should make running all tests locally a bit more reliable (when the users JDK could be 11-20) 🚀

If happy, before merging there may be some updates to https://com-lihaoyi.github.io/mill/mill/0.10.3/Plugin_Proguard.html, e.g. Also, please note that Proguard doesn’t seem to work with scala 2.13 yet.

The changes look good to me. Could you also update the documentation about the Scala 2.13 situation? Thanks.

That's done. Thanks :)


📝 Update includes for docs/es/docs/tutorial/cookie-params.md

Fixes #12554

@tiangolo could you please review this documentation update for the Spanish translation? All checks have passed and there are no conflicts.

Hi @luigiPinna, thanks for your interest in contributing to FastAPI!
Since you’ve already created a separate PR (#12709) for the query-params file, could you please update this PR to include only the cookie-params file? Thank you!

Hi @alejsdev, thank you for the review. I changed the pr as requested. Now it contains only one file changed

Hi @luigiPinna, thanks for your effort, but I just noticed that this one was already covered in another PR (#12602) so I'll close this one but thanks for your effort. :raised_hands:


Catch NSException in macOS run loop to prevent crashs

Had a crash on macOS this morning due to an uncaught NSException. Don't ask me what I did to produce this, I have no idea, but it doesn't matter, since the exception stems from a macOS internal error (the log states: This is a bug in IOHIDFamily).
Anyway, we should catch spurious exceptions and not crash. I tested this new code by raising an exception manually (prints an error message now).
The crash log:
crash.txt

Cherry-picked for 3.0.7.


Address consolidation dependency on OnDemand/Spot labels

Description
What problem are you trying to solve?
Direct awareness of spot vs on-demand in consolidation (and possibly the way the respective labels are defined) may need to be revisited. For example, other cloud providers may have different terminology for "on-demand", and consequently prefer a different label.
How important is this feature to you?

Please vote on this issue by adding a 👍 reaction to the original issue to help the community and maintainers prioritize this request
Please do not leave "+1" or "me too" comments, they generate extra noise for issue followers and do not help prioritize the request
If you are interested in working on this issue or have submitted a pull request, please leave a comment

There used to be a (hacky) way to change the label value by assigning a different value to v1alpha5.CapacityTypeOnDemand on init, no longer possible since it is now a constant.

@jackfrancis

Great to call this out. I'd love to hear a concrete use case for how this might be used by another provider.
Right now, there's a little bit of magic with spot, where we choose to not consolidate for Spot on AWS. I'd like to explore making consolidation decisions with other vendors in mind.
Maybe a good topic for working group tomorrow.

There are probably two separate aspects here:

One is that v1alpha5.CapacityTypeOnDemand value is "on-demand" and is not adjustable. A provider attempting to use a different value to signify on-demand would generally work, except for the existing consolidation logic - even if the logic itself is Ok. (A workaround - changing the actual value of v1alpha5.CapacityTypeOnDemand is no longer available.) And maybe, given the current design, the proper answer is "don't do that" (just stick to "on-demand"), be would be good to explore alternatives. (And of course, standard upstream/Kubernetes labels is this area would be great - but we are not there yet.)

Another is actual consolidation decisions, and exploring making them with other vendors in mind. Also a good discussion!

Agree with those two points. Specifically, what values do you want to use for your provider?

Discussed with a wider group, and it turns out "on-demand" is actually falls somewhere between acceptable and correct. I hereby withdraw the first concern. 🙂
Still happy to discuss options around the second one.

@tallaxes what things can we consider on the second one any scenarios you would like to keep on the table ?


lnd is using 250 sat/kw instead of 253 sat/kw for estimation

Background
I'm testing the remote signer lnd setup with a watch-only node following the directions in remote-signer.md. I followed the instructions using a watch-only node and remote-signer node both pointed to the same testnet bitcoind instance. I created an address on the watch-only node and deposited to that address. The funds show up on both nodes, however the watch-only mode (which has autopilot enabled to open channels) attempts to create a channel but fails.
Your environment

v0.14.1-beta
Linux  5.10.0-1051-oem - Ubuntu 20.04
Bitcoin Core version v22.0.0

Steps to reproduce
Follow the instructions in remote-signer.md for testnet nodes. Enable autopilot on the watch only node. Create an address on the watch only node. Deposit funds to the address.
Expected behaviour
Autopilot successfully creates channels automatically.
Actual behaviour
Autopilot attempts to create channels automatically on the watch-only node but fails. A pending channel is created but no opening tx is broadcast and the funds disappear from the watch-only node, whereas the remote-signing node shows the full original balance and no pending channels.
$ lncli pendingchannels
{
    "total_limbo_balance": "0",
    "pending_open_channels": [
        {
            "channel": {
                "remote_node_pub": "03bae2db4b57738c1ec1ffa1c5e5a4423968cc592b3b39cddf7d495e72919d6431",
                "channel_point": "43fae67a46ac7693a3d3758fa88b26dbf9298af481c115ad2722628175a2834a:0",
                "capacity": "16777063",
                "local_balance": "16776122",
                "remote_balance": "0",
                "local_chan_reserve_sat": "167770",
                "remote_chan_reserve_sat": "167770",
                "initiator": "INITIATOR_LOCAL",
                "commitment_type": "ANCHORS",
                "num_forwarding_packages": "0"
            },
            "confirmation_height": 0,
            "commit_fee": "281",
            "commit_weight": "772",
            "fee_per_kw": "250"
        }
    ],
    "pending_closing_channels": [
    ],
    "pending_force_closing_channels": [
    ],
    "waiting_close_channels": [
    ]
}

Watch-only node logs
2021-12-08 00:06:09.190 [INF] FNDG: Initiating fundingRequest(local_amt=0.16777215 BTC (subtract_fees=true), push_amt=0 mSAT, chain_hash=000000000933ea01ad0ee984209779baaec3ced90fa3f408719526f8d77f4943, peer=03bae2db4b57738c1ec1ffa1c5e5a4423968cc592b3b39cddf7d495e72919d6431, min_confs=1)
2021-12-08 00:06:09.190 [INF] DISC: GossipSyncer(03bae2db4b57738c1ec1ffa1c5e5a4423968cc592b3b39cddf7d495e72919d6431): requesting new chans from height=0 and 2106558 blocks after
2021-12-08 00:06:09.191 [INF] CHFD: Performing funding tx coin selection using 250 sat/kw as fee rate
2021-12-08 00:06:09.200 [WRN] CHFD: Unable to find funding output for shim intent: unable to create witness script, no funding keys
2021-12-08 00:06:09.210 [INF] PEER: Negotiated chan series queries with 020ec0c6a0c4fe5d8a79928ead294c36234a76f6e0dca896c35413612a3fd8dbf8
2021-12-08 00:06:09.210 [INF] DISC: Creating new GossipSyncer for peer=020ec0c6a0c4fe5d8a79928ead294c36234a76f6e0dca896c35413612a3fd8dbf8
2021-12-08 00:06:09.210 [INF] NTFN: New block epoch subscription
2021-12-08 00:06:09.212 [INF] SRVR: Established connection to: 0274fa8311c650e76a1897db1cca2fb20d598ded5b62d72f452fd2debea3499d78@<IP_ADDRESS>:29735
2021-12-08 00:06:09.212 [INF] SRVR: Finalizing connection to 0274fa8311c650e76a1897db1cca2fb20d598ded5b62d72f452fd2debea3499d78@<IP_ADDRESS>:29735, inbound=false
2021-12-08 00:06:09.260 [INF] NTFN: New block epoch subscription
2021-12-08 00:06:09.260 [INF] PEER: Negotiated chan series queries with 0274fa8311c650e76a1897db1cca2fb20d598ded5b62d72f452fd2debea3499d78
2021-12-08 00:06:09.260 [INF] DISC: Creating new GossipSyncer for peer=0274fa8311c650e76a1897db1cca2fb20d598ded5b62d72f452fd2debea3499d78
2021-12-08 00:06:09.272 [INF] DISC: GossipSyncer(03bae2db4b57738c1ec1ffa1c5e5a4423968cc592b3b39cddf7d495e72919d6431): buffering chan range reply of size=6590
2021-12-08 00:06:09.272 [INF] DISC: GossipSyncer(03bae2db4b57738c1ec1ffa1c5e5a4423968cc592b3b39cddf7d495e72919d6431): filtering through 6590 chans
2021-12-08 00:06:09.275 [INF] DISC: GossipSyncer(03bae2db4b57738c1ec1ffa1c5e5a4423968cc592b3b39cddf7d495e72919d6431): starting query for 32 new chans
2021-12-08 00:06:09.275 [INF] DISC: GossipSyncer(03bae2db4b57738c1ec1ffa1c5e5a4423968cc592b3b39cddf7d495e72919d6431): querying for 32 new channels
2021-12-08 00:06:09.276 [INF] FNDG: Target commit tx sat/kw for pendingID(a22b5ecb85ea68aa40c4aa566ae29e2e63d72c2c5d76fe1e8f62b3ecd5e9750d): 250
2021-12-08 00:06:09.276 [INF] FNDG: Dust limit for pendingID(a22b5ecb85ea68aa40c4aa566ae29e2e63d72c2c5d76fe1e8f62b3ecd5e9750d): 0.00000354 BTC
2021-12-08 00:06:09.276 [INF] FNDG: Starting funding workflow with <IP_ADDRESS>:9735 for pending_id(a22b5ecb85ea68aa40c4aa566ae29e2e63d72c2c5d76fe1e8f62b3ecd5e9750d), committype=anchors-zero-fee-second-level
2021-12-08 00:06:09.276 [INF] FNDG: Initiating fundingRequest(local_amt=0.16777215 BTC (subtract_fees=true), push_amt=0 mSAT, chain_hash=000000000933ea01ad0ee984209779baaec3ced90fa3f408719526f8d77f4943, peer=020ec0c6a0c4fe5d8a79928ead294c36234a76f6e0dca896c35413612a3fd8dbf8, min_confs=1)
2021-12-08 00:06:09.277 [INF] CHFD: Performing funding tx coin selection using 250 sat/kw as fee rate
2021-12-08 00:06:09.277 [INF] FNDG: Initiating fundingRequest(local_amt=0.16777215 BTC (subtract_fees=true), push_amt=0 mSAT, chain_hash=000000000933ea01ad0ee984209779baaec3ced90fa3f408719526f8d77f4943, peer=0274fa8311c650e76a1897db1cca2fb20d598ded5b62d72f452fd2debea3499d78, min_confs=1)
2021-12-08 00:06:09.277 [WRN] ATPL: Unable to open channel to 020ec0c6a0c4fe5d8a79928ead294c36234a76f6e0dca896c35413612a3fd8dbf8 of 0.16777215 BTC: not enough witness outputs to create funding transaction, need 0.16777215 BTC only have 0 BTC  available
2021-12-08 00:06:09.277 [INF] SRVR: Disconnecting from 020ec0c6a0c4fe5d8a79928ead294c36234a76f6e0dca896c35413612a3fd8dbf8@<IP_ADDRESS>:9735
2021-12-08 00:06:09.277 [INF] PEER: disconnecting 020ec0c6a0c4fe5d8a79928ead294c36234a76f6e0dca896c35413612a3fd8dbf8@<IP_ADDRESS>:9735, reason: server: disconnecting peer 020ec0c6a0c4fe5d8a79928ead294c36234a76f6e0dca896c35413612a3fd8dbf8@<IP_ADDRESS>:9735
2021-12-08 00:06:09.277 [INF] PEER: unable to read message from 020ec0c6a0c4fe5d8a79928ead294c36234a76f6e0dca896c35413612a3fd8dbf8@<IP_ADDRESS>:9735: read tcp <IP_ADDRESS>:46800-><IP_ADDRESS>:9735: use of closed network connection
2021-12-08 00:06:09.278 [INF] CHFD: Performing funding tx coin selection using 250 sat/kw as fee rate
2021-12-08 00:06:09.278 [WRN] ATPL: Unable to open channel to 0274fa8311c650e76a1897db1cca2fb20d598ded5b62d72f452fd2debea3499d78 of 0.16777215 BTC: not enough witness outputs to create funding transaction, need 0.16777215 BTC only have 0 BTC  available
2021-12-08 00:06:09.278 [INF] SRVR: Disconnecting from 0274fa8311c650e76a1897db1cca2fb20d598ded5b62d72f452fd2debea3499d78@<IP_ADDRESS>:29735
2021-12-08 00:06:09.278 [INF] PEER: disconnecting 0274fa8311c650e76a1897db1cca2fb20d598ded5b62d72f452fd2debea3499d78@<IP_ADDRESS>:29735, reason: server: disconnecting peer 0274fa8311c650e76a1897db1cca2fb20d598ded5b62d72f452fd2debea3499d78@<IP_ADDRESS>:29735
2021-12-08 00:06:09.278 [INF] PEER: unable to read message from 0274fa8311c650e76a1897db1cca2fb20d598ded5b62d72f452fd2debea3499d78@<IP_ADDRESS>:29735: read tcp <IP_ADDRESS>:58388-><IP_ADDRESS>:29735: use of closed network connection
2021-12-08 00:06:09.329 [INF] DISC: GossipSyncer(03bae2db4b57738c1ec1ffa1c5e5a4423968cc592b3b39cddf7d495e72919d6431): no more chans to query
2021-12-08 00:06:09.329 [INF] DISC: GossipSyncer(03bae2db4b57738c1ec1ffa1c5e5a4423968cc592b3b39cddf7d495e72919d6431): applying gossipFilter(start=2021-12-08 00:06:09.329147575 -0500 EST m=+53.412366547, end=2158-01-14 06:34:24.329147575 -0500 EST)
2021-12-08 00:06:09.329 [INF] DISC: GossipSyncer(020ec0c6a0c4fe5d8a79928ead294c36234a76f6e0dca896c35413612a3fd8dbf8): applying gossipFilter(start=2021-12-08 00:06:09.329199431 -0500 EST m=+53.412418402, end=2158-01-14 06:34:24.329199431 -0500 EST)
2021-12-08 00:06:09.329 [INF] DISC: GossipSyncer(0274fa8311c650e76a1897db1cca2fb20d598ded5b62d72f452fd2debea3499d78): applying gossipFilter(start=2021-12-08 00:06:09.32928303 -0500 EST m=+53.412502002, end=2158-01-14 06:34:24.32928303 -0500 EST)
2021-12-08 00:06:09.342 [INF] SRVR: Established connection to: 031e276436d65a08be1fb0fab1cdb32c11c176737b2653b96ad437fa39da25af08@<IP_ADDRESS>:9735
2021-12-08 00:06:09.342 [INF] SRVR: Finalizing connection to 031e276436d65a08be1fb0fab1cdb32c11c176737b2653b96ad437fa39da25af08@<IP_ADDRESS>:9735, inbound=false
2021-12-08 00:06:09.344 [INF] FNDG: Recv'd fundingResponse for pending_id(a22b5ecb85ea68aa40c4aa566ae29e2e63d72c2c5d76fe1e8f62b3ecd5e9750d)
2021-12-08 00:06:09.378 [INF] DISC: Removing GossipSyncer for peer=020ec0c6a0c4fe5d8a79928ead294c36234a76f6e0dca896c35413612a3fd8dbf8
2021-12-08 00:06:09.378 [INF] DISC: Removing GossipSyncer for peer=0274fa8311c650e76a1897db1cca2fb20d598ded5b62d72f452fd2debea3499d78
2021-12-08 00:06:09.378 [INF] SRVR: Established connection to: 0241bc65c496503b1dd27bc80379cb959fb82ad26673d237b3c8f59289fb99742f@<IP_ADDRESS>:29735
2021-12-08 00:06:09.379 [INF] SRVR: Finalizing connection to 0241bc65c496503b1dd27bc80379cb959fb82ad26673d237b3c8f59289fb99742f@<IP_ADDRESS>:29735, inbound=false
2021-12-08 00:06:09.435 [INF] SRVR: Established connection to: 0230d84c21cb2be5a00e64d2704ebe2ff80602523480d8625d9532ba78302debe2@<IP_ADDRESS>:2000
2021-12-08 00:06:09.435 [INF] SRVR: Finalizing connection to 0230d84c21cb2be5a00e64d2704ebe2ff80602523480d8625d9532ba78302debe2@<IP_ADDRESS>:2000, inbound=false
2021-12-08 00:06:09.438 [INF] NTFN: New block epoch subscription
2021-12-08 00:06:09.438 [INF] PEER: Negotiated chan series queries with 031e276436d65a08be1fb0fab1cdb32c11c176737b2653b96ad437fa39da25af08
2021-12-08 00:06:09.439 [INF] DISC: Creating new GossipSyncer for peer=031e276436d65a08be1fb0fab1cdb32c11c176737b2653b96ad437fa39da25af08
2021-12-08 00:06:09.439 [INF] DISC: GossipSyncer(031e276436d65a08be1fb0fab1cdb32c11c176737b2653b96ad437fa39da25af08): applying gossipFilter(start=2021-12-08 00:06:09.43907987 -0500 EST m=+53.522298877, end=2158-01-14 06:34:24.43907987 -0500 EST)
2021-12-08 00:06:09.481 [INF] FNDG: pendingChan(a22b5ecb85ea68aa40c4aa566ae29e2e63d72c2c5d76fe1e8f62b3ecd5e9750d): remote party proposes num_confs=5, csv_delay=2015
2021-12-08 00:06:09.481 [INF] FNDG: Generated ChannelPoint(43fae67a46ac7693a3d3758fa88b26dbf9298af481c115ad2722628175a2834a:0) for pending_id(a22b5ecb85ea68aa40c4aa566ae29e2e63d72c2c5d76fe1e8f62b3ecd5e9750d)
2021-12-08 00:06:09.481 [INF] FNDG: Initiating fundingRequest(local_amt=0.16113925 BTC (subtract_fees=true), push_amt=0 mSAT, chain_hash=000000000933ea01ad0ee984209779baaec3ced90fa3f408719526f8d77f4943, peer=031e276436d65a08be1fb0fab1cdb32c11c176737b2653b96ad437fa39da25af08, min_confs=1)
2021-12-08 00:06:09.482 [INF] CHFD: Performing funding tx coin selection using 250 sat/kw as fee rate
2021-12-08 00:06:09.482 [WRN] ATPL: Unable to open channel to 031e276436d65a08be1fb0fab1cdb32c11c176737b2653b96ad437fa39da25af08 of 0.16113925 BTC: not enough witness outputs to create funding transaction, need 0.16113925 BTC only have 0 BTC  available
2021-12-08 00:06:09.482 [INF] SRVR: Disconnecting from 031e276436d65a08be1fb0fab1cdb32c11c176737b2653b96ad437fa39da25af08@<IP_ADDRESS>:9735
2021-12-08 00:06:09.482 [INF] PEER: disconnecting 031e276436d65a08be1fb0fab1cdb32c11c176737b2653b96ad437fa39da25af08@<IP_ADDRESS>:9735, reason: server: disconnecting peer 031e276436d65a08be1fb0fab1cdb32c11c176737b2653b96ad437fa39da25af08@<IP_ADDRESS>:9735
2021-12-08 00:06:09.482 [INF] PEER: unable to read message from 031e276436d65a08be1fb0fab1cdb32c11c176737b2653b96ad437fa39da25af08@<IP_ADDRESS>:9735: read tcp <IP_ADDRESS>:42690-><IP_ADDRESS>:9735: use of closed network connection
2021-12-08 00:06:09.483 [INF] DISC: Obtained 3 addrs to bootstrap network with
2021-12-08 00:06:09.506 [INF] PEER: Negotiated chan series queries with 0241bc65c496503b1dd27bc80379cb959fb82ad26673d237b3c8f59289fb99742f
2021-12-08 00:06:09.506 [INF] NTFN: New block epoch subscription
2021-12-08 00:06:09.506 [INF] DISC: Creating new GossipSyncer for peer=0241bc65c496503b1dd27bc80379cb959fb82ad26673d237b3c8f59289fb99742f
2021-12-08 00:06:09.506 [INF] FNDG: Initiating fundingRequest(local_amt=0.16777215 BTC (subtract_fees=true), push_amt=0 mSAT, chain_hash=000000000933ea01ad0ee984209779baaec3ced90fa3f408719526f8d77f4943, peer=0241bc65c496503b1dd27bc80379cb959fb82ad26673d237b3c8f59289fb99742f, min_confs=1)
2021-12-08 00:06:09.506 [INF] DISC: GossipSyncer(0241bc65c496503b1dd27bc80379cb959fb82ad26673d237b3c8f59289fb99742f): applying gossipFilter(start=2021-12-08 00:06:09.506374401 -0500 EST m=+53.589593376, end=2158-01-14 06:34:24.506374401 -0500 EST)
2021-12-08 00:06:09.507 [INF] CHFD: Performing funding tx coin selection using 250 sat/kw as fee rate
2021-12-08 00:06:09.507 [WRN] ATPL: Unable to open channel to 0241bc65c496503b1dd27bc80379cb959fb82ad26673d237b3c8f59289fb99742f of 0.16777215 BTC: not enough witness outputs to create funding transaction, need 0.16777215 BTC only have 0 BTC  available
2021-12-08 00:06:09.507 [INF] SRVR: Disconnecting from 0241bc65c496503b1dd27bc80379cb959fb82ad26673d237b3c8f59289fb99742f@<IP_ADDRESS>:29735
2021-12-08 00:06:09.507 [INF] PEER: disconnecting 0241bc65c496503b1dd27bc80379cb959fb82ad26673d237b3c8f59289fb99742f@<IP_ADDRESS>:29735, reason: server: disconnecting peer 0241bc65c496503b1dd27bc80379cb959fb82ad26673d237b3c8f59289fb99742f@<IP_ADDRESS>:29735
2021-12-08 00:06:09.507 [INF] PEER: unable to read message from 0241bc65c496503b1dd27bc80379cb959fb82ad26673d237b3c8f59289fb99742f@<IP_ADDRESS>:29735: read tcp <IP_ADDRESS>:53464-><IP_ADDRESS>:29735: use of closed network connection
2021-12-08 00:06:09.517 [INF] FNDG: Broadcasting funding tx for ChannelPoint(43fae67a46ac7693a3d3758fa88b26dbf9298af481c115ad2722628175a2834a:0):<PHONE_NUMBER>01015e3e161d077ed932f6959524068afa1ca77845355f7f3193e276b658f3b3ee040100000000000000000267ffff0000000000220020b3cc9065e0dbe9184b54dc71c290b6216cd04507c7a07792e97f87567a2af1a501e1f50400000000160014d70e810d47c55bf5713fa8160d66761e5eb81e1b02483045022100a926e17028235c5f2fd95774c773af3ac3120cfaf5af9f376e40dac9b527a4cf022015156f5f94cb6ed6c6f27f138198d2674a418713326f967a620db4bb846fe934012103222bcd1e6e959b745602c1dbd40aed9875e14f88ab232f29e6445648fd61fe6700000000
2021-12-08 00:06:09.518 [INF] LNWL: Inserting unconfirmed transaction 43fae67a46ac7693a3d3758fa88b26dbf9298af481c115ad2722628175a2834a
2021-12-08 00:06:09.552 [INF] LNWL: Removed invalid transaction: (*wire.MsgTx)(0xc001f3b800)({
 Version: (int32) 2,
 TxIn: ([]*wire.TxIn) (len=1 cap=15) {
  (*wire.TxIn)(0xc0017c7ec0)({
   PreviousOutPoint: (wire.OutPoint) 04eeb3f358b676e293317f5f354578a71cfa8a06249595f632d97e071d163e5e:1,
   SignatureScript: ([]uint8) <nil>,
   Witness: (wire.TxWitness) (len=2 cap=2) {
    ([]uint8) (len=72 cap=80) {
     00000000  30 45 02 21 00 a9 26 e1  70 28 23 5c 5f 2f d9 57  |0E.!..&.p(#\_/.W|
     00000010  74 c7 73 af 3a c3 12 0c  fa f5 af 9f 37 6e 40 da<EMAIL_ADDRESS>     00000020  c9 b5 27 a4 cf 02 20 15  15 6f 5f 94 cb 6e d6 c6  |..'... ..o_..n..|
     00000030  f2 7f 13 81 98 d2 67 4a  41 87 13 32 6f 96 7a 62  |......gJA..2o.zb|
     00000040  0d b4 bb 84 6f e9 34 01                           |....o.4.|
    },
    ([]uint8) (len=33 cap=48) {
     00000000  03 22 2b cd 1e 6e 95 9b  74 56 02 c1 db d4 0a ed  |."+..n..tV......|
     00000010  98 75 e1 4f 88 ab 23 2f  29 e6 44 56 48 fd 61 fe  |.u.O..#/).DVH.a.|
     00000020  67                                                |g|
    }
   },
   Sequence: (uint32) 0
  })
 },
 TxOut: ([]*wire.TxOut) (len=2 cap=15) {
  (*wire.TxOut)(0xc00084c740)({
   Value: (int64) 16777063,
   PkScript: ([]uint8) (len=34 cap=500) {
    00000000  00 20 b3 cc 90 65 e0 db  e9 18 4b 54 dc 71 c2 90  |. ...e....KT.q..|
    00000010  b6 21 6c d0 45 07 c7 a0  77 92 e9 7f 87 56 7a 2a  |.!l.E...w....Vz*|
    00000020  f1 a5                                             |..|
   }
  }),
  (*wire.TxOut)(0xc000d286a0)({
   Value: (int64) 83222785,
   PkScript: ([]uint8) (len=22 cap=500) {
    00000000  00 14 d7 0e 81 0d 47 c5  5b f5 71 3f a8 16 0d 66  |......G.[.q?...f|
    00000010  76 1e 5e b8 1e 1b                                 |v.^...|
   }
  })
 },
 LockTime: (uint32) 0
})

2021-12-08 00:06:09.552 [ERR] FNDG: Unable to broadcast funding tx<PHONE_NUMBER>01015e3e161d077ed932f6959524068afa1ca77845355f7f3193e276b658f3b3ee040100000000000000000267ffff0000000000220020b3cc9065e0dbe9184b54dc71c290b6216cd04507c7a07792e97f87567a2af1a501e1f50400000000160014d70e810d47c55bf5713fa8160d66761e5eb81e1b02483045022100a926e17028235c5f2fd95774c773af3ac3120cfaf5af9f376e40dac9b527a4cf022015156f5f94cb6ed6c6f27f138198d2674a418713326f967a620db4bb846fe934012103222bcd1e6e959b745602c1dbd40aed9875e14f88ab232f29e6445648fd61fe6700000000 for ChannelPoint(43fae67a46ac7693a3d3758fa88b26dbf9298af481c115ad2722628175a2834a:0): unmatched backend error: -26: min relay fee not met, 152 < 153
2021-12-08 00:06:09.552 [INF] CNCT: Creating new ChannelArbitrator for ChannelPoint(43fae67a46ac7693a3d3758fa88b26dbf9298af481c115ad2722628175a2834a:0)
2021-12-08 00:06:09.554 [INF] CNCT: ChannelArbitrator(43fae67a46ac7693a3d3758fa88b26dbf9298af481c115ad2722628175a2834a:0): starting state=StateDefault, trigger=chainTrigger, triggerHeight=2106558
2021-12-08 00:06:09.554 [INF] NTFN: New spend subscription: spend_id=1, outpoint=43fae67a46ac7693a3d3758fa88b26dbf9298af481c115ad2722628175a2834a:0, script=0 b3cc9065e0dbe9184b54dc71c290b6216cd04507c7a07792e97f87567a2af1a5, height_hint=2106558
2021-12-08 00:06:09.554 [INF] NTFN: Dispatching historical spend rescan for outpoint=43fae67a46ac7693a3d3758fa88b26dbf9298af481c115ad2722628175a2834a:0, script=0 b3cc9065e0dbe9184b54dc71c290b6216cd04507c7a07792e97f87567a2af1a5, start=2106558, end=2106558
2021-12-08 00:06:09.555 [INF] FNDG: Finalizing pending_id(a22b5ecb85ea68aa40c4aa566ae29e2e63d72c2c5d76fe1e8f62b3ecd5e9750d) over ChannelPoint(43fae67a46ac7693a3d3758fa88b26dbf9298af481c115ad2722628175a2834a:0), waiting for channel open on-chain
2021-12-08 00:06:09.555 [INF] CNCT: Close observer for ChannelPoint(43fae67a46ac7693a3d3758fa88b26dbf9298af481c115ad2722628175a2834a:0) active
2021-12-08 00:06:09.555 [INF] NTFN: New confirmation subscription: conf_id=1, txid=43fae67a46ac7693a3d3758fa88b26dbf9298af481c115ad2722628175a2834a, num_confs=5 height_hint=2106558
2021-12-08 00:06:09.556 [INF] FNDG: Waiting for funding tx (43fae67a46ac7693a3d3758fa88b26dbf9298af481c115ad2722628175a2834a) to reach 5 confirmations
2021-12-08 00:06:09.556 [INF] CHBU: Updating on-disk multi SCB backup: num_old_chans=0, num_new_chans=1
2021-12-08 00:06:09.557 [INF] PEER: Negotiated chan series queries with 0230d84c21cb2be5a00e64d2704ebe2ff80602523480d8625d9532ba78302debe2
2021-12-08 00:06:09.557 [INF] NTFN: New block epoch subscription
2021-12-08 00:06:09.557 [INF] FNDG: Initiating fundingRequest(local_amt=0.16777215 BTC (subtract_fees=true), push_amt=0 mSAT, chain_hash=000000000933ea01ad0ee984209779baaec3ced90fa3f408719526f8d77f4943, peer=0230d84c21cb2be5a00e64d2704ebe2ff80602523480d8625d9532ba78302debe2, min_confs=1)
2021-12-08 00:06:09.557 [INF] DISC: Creating new GossipSyncer for peer=0230d84c21cb2be5a00e64d2704ebe2ff80602523480d8625d9532ba78302debe2
2021-12-08 00:06:09.557 [INF] NTFN: Historical spend dispatch finished for request outpoint=43fae67a46ac7693a3d3758fa88b26dbf9298af481c115ad2722628175a2834a:0, script=0 b3cc9065e0dbe9184b54dc71c290b6216cd04507c7a07792e97f87567a2af1a5 (start=2106558 end=2106558) with details: <nil>
2021-12-08 00:06:09.558 [INF] CHFD: Performing funding tx coin selection using 250 sat/kw as fee rate
2021-12-08 00:06:09.558 [WRN] ATPL: Unable to open channel to 0230d84c21cb2be5a00e64d2704ebe2ff80602523480d8625d9532ba78302debe2 of 0.16777215 BTC: not enough witness outputs to create funding transaction, need 0.16777215 BTC only have 0 BTC  available
2021-12-08 00:06:09.558 [INF] SRVR: Disconnecting from 0230d84c21cb2be5a00e64d2704ebe2ff80602523480d8625d9532ba78302debe2@<IP_ADDRESS>:2000
2021-12-08 00:06:09.558 [INF] PEER: disconnecting 0230d84c21cb2be5a00e64d2704ebe2ff80602523480d8625d9532ba78302debe2@<IP_ADDRESS>:2000, reason: server: disconnecting peer 0230d84c21cb2be5a00e64d2704ebe2ff80602523480d8625d9532ba78302debe2@<IP_ADDRESS>:2000
2021-12-08 00:06:09.558 [INF] PEER: unable to read message from 0230d84c21cb2be5a00e64d2704ebe2ff80602523480d8625d9532ba78302debe2@<IP_ADDRESS>:2000: read tcp <IP_ADDRESS>:44692-><IP_ADDRESS>:2000: use of closed network connection
2021-12-08 00:06:09.567 [INF] CHBU: Updating backup file at /home/danielmcnally/.lnd-watch/data/chain/bitcoin/testnet/channel.backup
2021-12-08 00:06:09.571 [INF] CHBU: Swapping old multi backup file from /home/danielmcnally/.lnd-watch/data/chain/bitcoin/testnet/temp-dont-use.backup to /home/danielmcnally/.lnd-watch/data/chain/bitcoin/testnet/channel.backup
2021-12-08 00:06:09.581 [INF] SRVR: Established connection to: 03430676be33c112279097929f25f6f585c0fc71bc692d77d04975029ffb01e8b3@<IP_ADDRESS>:9735
2021-12-08 00:06:09.581 [INF] SRVR: Finalizing connection to 03430676be33c112279097929f25f6f585c0fc71bc692d77d04975029ffb01e8b3@<IP_ADDRESS>:9735, inbound=false
2021-12-08 00:06:09.583 [INF] DISC: Removing GossipSyncer for peer=031e276436d65a08be1fb0fab1cdb32c11c176737b2653b96ad437fa39da25af08
2021-12-08 00:06:09.583 [INF] DISC: GossipSyncer(0230d84c21cb2be5a00e64d2704ebe2ff80602523480d8625d9532ba78302debe2): applying gossipFilter(start=2021-12-08 00:06:09.583153703 -0500 EST m=+53.666372673, end=2158-01-14 06:34:24.583153703 -0500 EST)

There appear to be no relevant logs on the remote-signer node.

Here's the issue:

2021-12-08 00:06:09.552 [ERR] FNDG: Unable to broadcast funding tx: unmatched backend error: -26: min relay fee not met, 152 < 153

You might be limiting the mempool, or have the min relay fee set to a lower value?

You might be limiting the mempool, or have the min relay fee set to a lower value?

Interesting, I missed this in the logs. I'm going to look into this more closely and try some manual channel openings. My testnet node is using the default relay/mempool settings fwiw, and I used it just a couple days ago to back a regular lnd 0.14.1 node with autopilot enabled without issue - I tried to make this setup basically a copy of that one except with remote-signing enabled. Since it's just 1 sat off, I wonder if the watch-only node makes some rounding error that regular nodes don't make?

Hmm, ok I've seen this pop up:

2021-12-08 00:06:09.558 [INF] CHFD: Performing funding tx coin selection using 250 sat/kw as fee rate

But after sometime, it instead uses the proper 253 sat/kw.
So maybe let's rename this issue to:

lnd is using 250 sat/kw instead of 253 sat/kw for estimation

OK, I have some more details/info here, there may be a couple of separate issues that I just happen to be running into at the same time.

If I turn off autopilot and manually try to open a channel via the watch-only node with lncli openchannel, lnd still uses 250 sat/kw and fails to broadcast the tx and open the channel. This occurs even after I've let lnd run for a while and ensured it's synced to chain.
After a failed channel open attempt, my walletbalance on the watch-only node plunges to 0 for both confirmed and unconfirmed (my wallet started with a single utxo). The wallet balance reappears after restarting lnd.

~/.lnd-watch$ lncli walletbalance
{
    "total_balance": "0",
    "confirmed_balance": "0",
    "unconfirmed_balance": "0",
    "account_balance": {
        "default": {
            "confirmed_balance": "0",
            "unconfirmed_balance": "0"
        }
    }
}

Every failed channel open attempt leaves a zombie pending channel behind on the watch-only node that persists through restarts and many new blocks. You can see the list here, none of these channel_points were broadcast

~/.lnd-watch$ lncli pendingchannels
{
    "total_limbo_balance": "0",
    "pending_open_channels": [
        {
            "channel": {
                "remote_node_pub": "02c338d695293a620fa8249a3dfa740ecbf7c5be129a1df1d288c90976525d846f",
                "channel_point": "d535e4408624fbb5956b3cf3937e7e01741debbbe0ebee040db061708c038086:0",
                "capacity": "1000000",
                "local_balance": "999059",
                "remote_balance": "0",
                "local_chan_reserve_sat": "10000",
                "remote_chan_reserve_sat": "10000",
                "initiator": "INITIATOR_LOCAL",
                "commitment_type": "ANCHORS",
                "num_forwarding_packages": "0"
            },
            "confirmation_height": 0,
            "commit_fee": "281",
            "commit_weight": "772",
            "fee_per_kw": "250"
        },
        {
            "channel": {
                "remote_node_pub": "032b17669f46daedcce8fb569760b2dabb3782d266d6cfb905d3582a8f1d757d5d",
                "channel_point": "2339f3c719e1e723c858f3ce02a37886c7dc0c800719103e66b42d7385060bc7:0",
                "capacity": "16777063",
                "local_balance": "16776122",
                "remote_balance": "0",
                "local_chan_reserve_sat": "167770",
                "remote_chan_reserve_sat": "167770",
                "initiator": "INITIATOR_LOCAL",
                "commitment_type": "ANCHORS",
                "num_forwarding_packages": "0"
            },
            "confirmation_height": 0,
            "commit_fee": "281",
            "commit_weight": "772",
            "fee_per_kw": "250"
        },
        {
            "channel": {
                "remote_node_pub": "03511d864ff7ba88b21ab23eb30bbfd18b1188e1539a666951c4acf9c74e3b37fd",
                "channel_point": "54e8e6dc8cabe11cc6ed09dcc7e59e7d6cdae49c0f0c663f3850715830ec86c7:0",
                "capacity": "500000",
                "local_balance": "499059",
                "remote_balance": "0",
                "local_chan_reserve_sat": "5000",
                "remote_chan_reserve_sat": "5000",
                "initiator": "INITIATOR_LOCAL",
                "commitment_type": "ANCHORS",
                "num_forwarding_packages": "0"
            },
            "confirmation_height": 0,
            "commit_fee": "281",
            "commit_weight": "772",
            "fee_per_kw": "250"
        },
        {
            "channel": {
                "remote_node_pub": "03bae2db4b57738c1ec1ffa1c5e5a4423968cc592b3b39cddf7d495e72919d6431",
                "channel_point": "43fae67a46ac7693a3d3758fa88b26dbf9298af481c115ad2722628175a2834a:0",
                "capacity": "16777063",
                "local_balance": "16776122",
                "remote_balance": "0",
                "local_chan_reserve_sat": "167770",
                "remote_chan_reserve_sat": "167770",
                "initiator": "INITIATOR_LOCAL",
                "commitment_type": "ANCHORS",
                "num_forwarding_packages": "0"
            },
            "confirmation_height": 0,
            "commit_fee": "281",
            "commit_weight": "772",
            "fee_per_kw": "250"
        }
    ],
    "pending_closing_channels": [
    ],
    "pending_force_closing_channels": [
    ],
    "waiting_close_channels": [
    ]
}

This interferes with me being able to attempt another channel opening with the same peer.
~/.lnd-watch$ lncli openchannel --local_amt 500000 --node_key 03511d864ff7ba88b21ab23eb30bbfd18b1188e1539a666951c4acf9c74e3b37fd --sat_per_vbyte 2
[lncli] rpc error: code = Unknown desc = received funding error from 03511d864ff7ba88b21ab23eb30bbfd18b1188e1539a666951c4acf9c74e3b37fd: chan_id=a4d139658bed376094f3be480b0d5574edca97c6d786d43ca2fca92625624b31, err=Number of pending channels exceed maximum

Even if I specify a sat_per_vbyte of 2, which should be more than enough for mempool requirements, I still get a 250 sat/kw fee rate on the funding transaction which fails to broadcast.

~/.lnd-watch$ lncli openchannel --local_amt 1000000 --node_key 02c338d695293a620fa8249a3dfa740ecbf7c5be129a1df1d288c90976525d846f --sat_per_vbyte 2
{
	"funding_txid": "d535e4408624fbb5956b3cf3937e7e01741debbbe0ebee040db061708c038086"
}

The tx above never broadcast and the pending channel shows "fee_per_kw": "250". However, interestingly afterwards I saw this appear in the logs:
2021-12-09 00:00:58.456 [INF] CHFD: Performing funding tx coin selection using 500 sat/kw as fee rate

And if I restart lnd and then try another channel open with --sat_per_vbyte 2, it works!
$ lncli openchannel --local_amt 500000 --node_key 030f0bf260acdbd3edcad84d7588ec7c5df4711e87e6a23016f989b8d3a4147230 --sat_per_vbyte 2
{
	"funding_txid": "016d332b8a6ebb6e4203863eddeac3811331efe1052de3b239dd02800d98a146"
}

However, the pending channel entry still shows a fee_per_kw of 250, even though the actual tx that was broadcast uses 2 sat/vbyte as expected. And commit_fee is 181 even though the broadcast tx has a fee of 305 sats. https://blockstream.info/testnet/tx/016d332b8a6ebb6e4203863eddeac3811331efe1052de3b239dd02800d98a146
~/.lnd-watch$ lncli pendingchannels
{
    "total_limbo_balance": "0",
    "pending_open_channels": [
        ...
        {
            "channel": {
                "remote_node_pub": "030f0bf260acdbd3edcad84d7588ec7c5df4711e87e6a23016f989b8d3a4147230",
                "channel_point": "016d332b8a6ebb6e4203863eddeac3811331efe1052de3b239dd02800d98a146:0",
                "capacity": "500000",
                "local_balance": "499819",
                "remote_balance": "0",
                "local_chan_reserve_sat": "5000",
                "remote_chan_reserve_sat": "5000",
                "initiator": "INITIATOR_LOCAL",
                "commitment_type": "STATIC_REMOTE_KEY",
                "num_forwarding_packages": "0"
            },
            "confirmation_height": 0,
            "commit_fee": "181",
            "commit_weight": "600",
            "fee_per_kw": "250"
        },
        ...

I'd be happy to continue debugging/testing this or split this into multiple issues, let me know. For now since I finally have a funding tx broadcast I'm going to try to play around with that.

think i found the culprit: https://github.com/lightningnetwork/lnd/blob/master/chainreg/chainregistry.go#L451

After a failed channel open attempt, my walletbalance on the watch-only node plunges to 0 for both confirmed and unconfirmed (my wallet started with a single utxo). The wallet balance reappears after restarting lnd.

I assume this is because the TX is attempted to be published but then fails. This probably marks the UTXO as spent but the change output going back to the wallet isn't recognized as new UTXO. This isn't optimal but should not happen if the TX is published correctly.

Every failed channel open attempt leaves a zombie pending channel behind on the watch-only node that persists through restarts and many new blocks. You can see the list here, none of these channel_points were broadcast

This is not a bug by itself, as long as the UTXO that's being referenced isn't spent in another TX. You can use lncli abandonchannel if you're certain that the funding TX will never make it to the chain.
The double spend detection is covered by https://github.com/lightningnetwork/lnd/pull/5567 which we can hopefully pick back up for 0.15.0.

think i found the culprit: https://github.com/lightningnetwork/lnd/blob/master/chainreg/chainregistry.go#L451 sneaky magic number

I'll test this branch on my node that's running into this error.

I assume this is because the TX is attempted to be published but then fails. This probably marks the UTXO as spent but the change output going back to the wallet isn't recognized as new UTXO. This isn't optimal but should not happen if the TX is published correctly.

Should lnd "unmark" the utxo as spent in this case? I realize it's an edge case and can be resolved with a restart but it's still odd behavior.

This is not a bug by itself, as long as the UTXO that's being referenced isn't spent in another TX. You can use lncli abandonchannel if you're certain that the funding TX will never make it to the chain.

Does it make sense that the pending channel is created if the funding transaction fails to broadcast, though? It will never confirm, and the utxo being spent to fund the channel reappears in the wallet. The pending channel remains even after the utxo is spent.
And fwiw re: abandonchannel, I hit this error when I try it: [lncli] rpc error: code = Unknown desc = AbandonChannel RPC call only available in dev builds. Interestingly I was using lnd I compiled off a PR branch.

AbandonChannel RPC call only available in dev builds

That's a precaution, since you can lose funds if you use it incorrectly. Check lncli abandonchannel --help, there's an override flag.


Service Request: Jamendo

From Launchpad bug #1031344 by makilakixki:
Jamendo home page: http://www.jamendo.com/
There are some patches for Nuvola Player 2 in the old bug report.

Want to back this issue? Post a bounty on it! We accept bounties via Bountysource.

I'd like to add my voice to this. Jamendo is a service strictly for Creative Commons licensed music, and so a great thing for a Free Software Linux program like Nuvola to support :)

https://github.com/tiliado/nuvola-app-jamendo

Released with Nuvola 4.15.0, more info.


register for personal site

Requirements

[x] You have completed your website. (good enough)
[x] The website is reachable.
[x] The CNAME record doesn't contain https:// or /.
[x] There is sufficient information at the owner field.
[x] Your website is not hosting on the following due to SSL issues: Vercel, Netlify

Description
A personal website.
Link to Website
https://wesley-is-cool-dev.pages.dev/

Thank you for your submission, we really appreciate it. Like many open-source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution. You can sign the CLA by just posting a Pull Request Comment same as the below format.

I have read the CLA Document and I hereby sign the CLA

You can retrigger this bot by commenting recheck in this Pull Request. Posted by the CLA Assistant Lite bot.

bruh

I have read the CLA Document and I hereby sign the CLA


Add in debugging recipe, delete unused categories from cookbook TOC

Kenneth Auchenberg wrote a great recipe for debugging Vue within VSCode, and we agreed it should live in our cookbook as well. In addition to his great contribution, I've also added:

Alternative pattern: vue devtools
Alternative pattern: vuetron
Alternative pattern: simple debugging statement
As discussed, removal of sections for cookbook until we have a few more and can see more pertinent groupings

@auchenberg I would love to get your take on this as well.

Oh, that's too bad about the invalid sourcemaps. I'll synch with you offline about timeline. I can get the other changes in in the meantime.

Ok, I think I addressed all of the concerns in the review. Let me know if we need further changes :)

Sourcemap issue made some traction, getting this recipe in there :)