text:
test: Add oghttp2 to codec_impl_fuzz_test.cc

Commit Message: test: Add oghttp2 to codec_impl_fuzz_test.cc.
Additional Description:
This PR updates test-only HttpVersion to split Http2 into Http2Nghttp2
and Http2Oghttp2, then enables the runtime config for oghttp2 under
Http2Oghttp2. This PR is meant to be part of envoyproxy#20224.
Risk Level: Low
Testing: bazel test //test/common/http:codec_impl_fuzz_test --config=libc++
Docs Changes:
Release Notes:
Platform Specific Features:
[Optional Runtime guard:]
[Optional Fixes #Issue]
[Optional Deprecated:]
[Optional API Considerations:]

Closing in favor of envoyproxy#20811

repo: birenroy/envoy


text:
Align & resize buttons on main screen

they're a bit small and could be larger

Code jam over, this is unlikely to get fixed.

source: gharchive/issue

license: MIT

license_type: permissive

license_source: github-api


text:
A short holiday

I just wanted to let you know that I am on a short holiday until May 7th!
Afterwards i will continue with fresh energy!
Sorry! 😁

Chris @bitbeans

Enjoy your vacation, Chris!

I kinda figured you were taking a break ;-)
Sorry for bombarding you with requests and bugs.
Have a good break!

repo: bitbeans/SimpleDnsCrypt

license: mit

license_source: bigquery


text:
Any way to do multisig with Ledger via HWI?

It seems that there is code that supports it here:
https://github.com/bitcoin-core/HWI/tree/master/hwilib/devices/ledger_bitcoin
I'm looking at the related PR and @achow101 says "I've implemented support for multisigs." Is there somewhere that shows this working / how this works? I can't find it.
I got a full PoC working of exporting an xpub, registering a wallet (collection of xpubs, quorum, script type, etc), showing an address on device, and then (after depositing funds) signing a transaction using the Ledger code that this appears based off of.
https://gist.github.com/mflaxman/386990be297e9a595936e8142e815e52
Basically, I'm trying to decide if I want to package/publish what I've done into some open source code that allows end-users to user their ledger for p2wsh transactions. I'm wondering:

Should I use hwilib for the dependency or from hwilib.devices.ledger_bitcoin import MultisigWallet vs from ledger_bitcoin import MultisigWallet. My default assumption is that hwilib would be a better dependency, but if it's an unsupported feature perhaps I should pull from upstream.
Does that really not exist? My gist above may be the only ledger p2wsh transactions to ever hit the bitcoin blockchain, but considering this feature was announced by Ledger ~5 months ago that seems hard to believe.

Yes, it is. What have you tried to do that does not work?
With the Ledger 2.0 app, in order to sign a multisig the policy needs to be registered on the device first, and then it will send back an HMAC that the client needs to present each time it wants to use that policy. However HWI does not have a way to store this HMAC nor does it have a way to register a wallet with the common interface. What HWI will do is register the policy each time observes a multisig policy. This means that from a user prospective, they will have to confirm the policy each time an action such as signing a transaction is done. This means that you can do multisigs with just descriptors and PSBTs without needing to explicitly register a policy or go into the device specific details.
With the Ledger 1.0 (legacy) app, all of this is possible, just without the need to register a wallet policy.
It should be noted that by using hwilib.devices.ledger_bitcoin that you are using an internal API that is not meant for external use. I suppose it should be prefixed with an underscore.

With the Ledger 1.0 (legacy) app, all of this is possible, just without the need to register a wallet policy.

Wait, ledger 1.0 supports multisig!? My understanding was that there was no way to display a multisig address on device, and signing couldn't detect change (effectively making it blind-signing for all but the most expert of users). That's how Electrum's implementation worked, and I had heard that it was a technical limitation that only ledger 2.0 finally enabled so I didn't dig into other implementations too closely.
I guess I'm still stuck on the question: is there a way a non-expert could send/receive using a ledger as part of a multisig transaction today (using HWI or something else) in a way that wasn't terribly insecure? I'm baffled that it doesn't appear possible outside of the gist I threw together. If you could provide a link to something showing otherwise it'd be greatly appreciated.

I suppose our definitions of "do multisig" slightly differ. Both versions of the Ledger Bitcoin app can sign multisigs. Ledger 2.0 will additionally display information about the multisig it is signing.
In both cases, you can use basically the same workflow with HWI and a you will get a signed multisig transaction. With both versions, you can use HWI's getxpub to get a xpub that you can use in your multisig. With both versions, you can provide a PSBT to signtx and it will return a PSBT with signatures for the multisig. With version 2, when you do signtx, HWI will figure out the multisig policies in the PSBT, register them with the device (which will require user interaction to confirm the registrattion), and then the device should be able to detect change for that policy.
Displaying a multisig address on Ledgers is not yet implemented.

I suppose our definitions of "do multisig" slightly differ.

Ya, I'm talking about:

Validating a receive address on the screen of your trusted display before giving it out to anyone for payment
Being able to tell what you're signing without blind signing (anything beyond "send X bitcoin to Y address with fee of Z" is too complicated for non-experts)

I feel strongly that it's a terrible idea to ever use a hardware that doesn't natively offer these features.
With that gist I threw together it seems ledger now supports multisig in a way that isn't dangerously insecure, there just isn't a UI yet to make it available to non-experts. Perhaps I'll work on that.
Closing this issue, I'll use other software to accomplish the goal. FWIW, I do think HWI adding support for secure multisig with ledger would be a great feature addition. In the meantime, I'd consider adding a lot of big scary warnings.
FYI: I didn't audit your signing flow (I couldn't validate a receive address first), but registering a new quorum on each sign has obvious dangers from a compromised host machine. Stateless Signer trustlessly validate change UTXOs already (Trezor first did this 6+ years ago), quorum registration is about receive address validation ONLY, there's no reason to do be doing that on signing (and it introduces big problems).

but registering a new quorum on each sign has obvious dangers from a compromised host machine. Stateless Signer trustlessly validate change UTXOs already (Trezor first did this 6+ years ago), quorum registration is about receive address validation ONLY, there's no reason to do be doing that on signing (and it introduces big problems).

HWI does it this way because it is stateless. It cannot remember the HMAC that the ledger returns for use in other commands, so it must do the policy registration each time it does something with the policy. Trezor works because it is stateful and it has the storage to persist the policy, while Ledgers do not have the storage and are stateless and so require the state to be client side. Unfortunately that does not work when the client side is also stateless as HWI is.

Trezor works because it is stateful and it has the storage to persist the policy

I think maybe you're thinking of single sig? Trezor has been detecting change outputs statelessly from the transaction since 2015. Now with PSBT (HT to you!) this is even easier, my stateless CLI multisig wallet validates change by calculating change outputs use the same xpubs/quorum as the inputs. You don't need to prompt the user to confirm something confusing; the device can cryptographically validate.
To be clear: I'm not saying that HWI should be stateful.

It cannot remember the HMAC that the ledger returns for use in other commands, so it must do the policy registration each time it does something with the policy.

Does it make sense for HWI to return the HMAC as an additional JSON field in those calls where the wallet policy is registered, and to accept it as an optional parameter for future calls that can use it to avoid repeat registration? Wallet software can then offer the stateful backing HWI lacks.

@achow101 would you mind responding to the last comment from @craigraw?

Does it make sense for HWI to return the HMAC as an additional JSON field in those calls where the wallet policy is registered, and to accept it as an optional parameter for future calls that can use it to avoid repeat registration? Wallet software can then offer the stateful backing HWI lacks.

I don't think it makes sense to do that as part of signtx, however it could make sense as a separate policy registration command if other wallets also support a similar workflow. I don't think it's useful to implement a feature that only one kind of device supports.

policy registration command

the other devices do implicit policy registration at any point (signing or checking address) and it works because they have a memory. whereas devices without memory need to store it externally in the memory of a computer. Devices like jade or coldcard already have policy registration workflow triggered implicitly. So IMHO we should support explicit policy registration to cover all the cases even for devices without memory; otherwise devices without memory will always be second class citizens

authors: achow101 bitcoin-eagle craigraw hodlwave mflaxman

repo: bitcoin-core/HWI


text:
Trezors: Update to work with firmware 2.3 and 1.9

Trezor firmware versions 2.3 and 1.9 changed a couple of things that were causing HWI to not work with them. This PR fixes those things.

Changed promptpin to use GetPublicKey message. The Ping message used previously no longer has a pin prompt option.
Updated messages and passphrase callback to match new passphrase workflow
Check for a session being initialized by doing a GetPublicKey and seeing if a FirmwareError is returned. If so, send an Initialize to start a session.

Due to the passphrase and session changes to the Trezor T, users using firmware 2.3 will be required to enter the passphrase on the host in the same way that is done with the Trezor 1

Entering passphrase on the device is definitively possible via python-trezor 0.12, see https://github.com/spesmilo/electrum/pull/6064

i don't understand why the previous code disallowed entering passphrase on host, and the new code enforces passphrase on host. If entering on device ever worked, there is no reason it should not work now. If entering on host works for T1, there is no reason it should not work for TT.

I think I understand why you disabled passphrase-on-host for TT. Is it because there is no place to prompt to enter on host / on device?
If that's the case, I'd suggest a different behavior: if passphrase is not specified on the command line, ask for passphrase on device. Otherwise use the supplied passphrase.
(Alternately, you could reuse promptpin to invoke the passphrase-on-device dialog on TT.)
I still don't understand why entering on host was briefly disallowed.

Entering passphrase on the device is definitively possible via python-trezor 0.12, see spesmilo/electrum#6064

The session changes mean that a user must enter their passphrase for every single command. Entering it every time on the device is a pain in the ass.

If that's the case, I'd suggest a different behavior: if passphrase is not specified on the command line, ask for passphrase on device. Otherwise use the supplied passphrase.

That's not a bad idea.

I still don't understand why entering on host was briefly disallowed.

I prefer that as much sensitive user info be entered on the device itself. So the preference is to have PINs and passphrases entered on the device. Previously the T would let you do that and it would cache the passphrase so users only had to do it once. So entering on the host was disallowed in order to require users enter the passphrase on the device. But with the session changes users would have to enter the passphrase with every single command they do. I found this experience to be cumbersome and annoying so I reversed the requirement: users must now enter on the host (this reversal is partially because we have no way to prompt users for which they want to do).

The session changes mean that a user must enter their passphrase for every single command.

Not if you implement sessions like we suggested earlier.

Dne pá 17. 4. 2020 18:31 uživatel Andrew Chow notifications@github.com
napsal:

The session changes mean that a user must enter their passphrase for every
single command. Entering it every time on the device is a pain in the ass.

this has been true for as long as TT exists though. there is no change. I
thought you resolved that by never ever calling Initialize.
the only difference is that now you can't call GetPublicNode on a freshly
plugged-in device, because there is no default session.
once you or something else calls Initialize for the first time (so a
session is created), that session remains open for as long as you don't
call Initialize again.

Not if you implement sessions like we suggested earlier.

Perhaps I misunderstand how sessions work. Or perhaps you are misunderstanding how HWI works. I'll try to explain why I don't want to do that.
As I understand it, sessions require the host software to store state. The device returns a 32 byte session id in a Features message and this session id must be sent in an Initialize message at the beginning of each connection in order to use the passphrase cached for that session. If it is not sent, the device begins a new session which means that the passphrase must be entered again (or a different passphrase entered).
Now the way that HWI works is that it connects to a device, does whatever is needed to complete the action specified by the user, and then disconnects. It must disconnect because it is a command line tool like trezorctl. For example. if the user does getxpub m/0h/0, then it connects to the device, sends Initialize, handles the response, sends a GetPublicKey message, handles the passphrase callback, etc. At the end, it gets the xpub, closes the device connection, returns the xpub, and exits. In this scenario, the user had to enter his passphrase. If we forced passphrase on device, he would have entered it on the device. Now suppose that user does getxpub m/0h/1. We do the same thing as above and the user has to enter his passphrase again. This is not a good experience.
So to have the good experience of the passphrase being cached on the first getxpub, we need to send that session id given in the Features message the first time he did getxpub. But how do we get that session id from the first invocation of getxpub to the second invocation? We can't just "store it in a variable" as you have suggested previously; the program exits entirely so anything that was in memory is lost. We'd have to make HWI store some state on disk. This means that we need to now add an entire framework for storing data on disk. We need to know where the data is going to be, allow the user to change the location, handle file I/O errors, etc. It's a whole lot more work just to store a single 32 byte string.
The crux of the problem is that I (and others) think that HWI shouldn't store anything on disk. It shouldn't need to store any state. No other device requires this. The problem it is trying to solve does not need to store state except for this one specific thing that you have recently added to your firmware. Frankly, I'm tired of having to constantly add Trezor specific things just to keep supporting your devices. This isn't a Trezor utility, it's a general purpose hardware wallet tool and it really should not have device specific commands and options (we already have 3 Trezor specific commands and I'd really like to get rid of them).
So if storing the session id in memory is not possible, and storing it on disk is unwanted, what other options are there? The only thing I can think of is that we make the user remember the session id and enter it on the command line every time. So now the user has to remember a 64 character hex string and remember to pass it in with a Trezor specific command line argument. But this workflow is ostensibly the same thing as making the user give the passphrase on the command line every time. Sure it is not the passphrase itself, but currently the session id is effectively just a proxy for the passphrase. However user passphrases are easier for the user to remember and does not change over time. The user experience between passing in a session id and passing in their passphrase is the same - on device they don't have to enter their passphrase for every command. It just has to be part of the command invocation which is easy to copy and paste.
This is why I've chosen to require the user enter the passphrase on the host. If I have misunderstood how sessions work or if you have any other ideas for how we could actually make use of sessions, please let me know.

The session changes mean that a user must enter their passphrase for every
single command. Entering it every time on the device is a pain in the ass.

this has been true for as long as TT exists though. there is no change. I
thought you resolved that by never ever calling Initialize.
the only difference is that now you can't call GetPublicNode on a freshly
plugged-in device, because there is no default session.
once you or something else calls Initialize for the first time (so a
session is created), that session remains open for as long as you don't
call Initialize again.

This was not true in my testing. I guess that's a bug.
In my experimentation, every time I did something without sending Initialize after opening the connection, I always got a non-specific FirmwareError. When I looked into it, this error was because there was no session for that connection.

Your utility is being used essentially as a library for projects like Wasabi, BTCPay and maybe others. If it's not acceptable to pass session_id as a parameter to your utility, then it is not meant to be used as a library and you should communicate this clearly in the readme. I will then point these projects to read that particular line in the readme and recommend them using something else.

So now the user has to remember a 64 character hex string and remember to pass it in with a Trezor specific command line argument.

I am not sure what's the problem here. If I understand it correctly, a user needs to provide  -d <path> on everycall. This is not different to providing -d <path> -s <session>. You can even combine these two into one string. I am pretty users copy-paste the path from the enumerate call anyway as they can change on every device connection. From that regard, it is just making the "path" identifier longer.

@molnard @lontivero This conversation does not look good. Could you handle the situation?

@prusnak

If I understand it correctly, a user needs to provide -d  on every call now.

No.  You can get away with only specifying the master xpub fingerprint, which is unchanging as long as the seed stays the same.  E.g.:
$ ./hwi.py enumerate
[{"type": "trezor", "path": "webusb:002:2", "model": "trezor_t", "needs_pin_sent": false, "needs_passphrase_sent": false, "fingerprint": "01234567"}]

$ ./hwi.py -f 01234567 getdescriptors
{"receive": ["pkh([01234567/44h/0h/0h]xpub[...]

# <physically disconnect device, reconnect, enter pin>

$ ./hwi.py -f 01234567 getdescriptors
{"receive": ["pkh([01234567/44h/0h/0h]xpub[...]

Having to run ./hwi.py enumerate each time I connect the device and then modify any commands I want to reuse from my bash history with a new sessionid sounds annoying; it'd be nice if that could be avoided.

@prusnak Would it be possible to implement backwards compatibility with a new firmware?
It would be really uncomfortable for both of us getting numerous support requests regarding it :/

If a change results in user programs breaking, it's a bug in the kernel. - Linus

@harding I typically do the poor-man's version as well: -t <device type> which of course only works if there is one of each type plugged in

which is unchanging as long as the seed stays the same

You ignore the passphrase completely in the scenario you are describing. The whole discussion here is because of the passphrase.

Would it be possible to implement backwards compatibility with a new firmware?

We are backward compatible. If your client doesn't understand the new API it will fall back to entering the passphrase on the host. What we are discussing here is to bring a new feature: a user can enter the passphrase on the device and they do not have to enter it again for future invocations of HWI if they provide the correct session_id.

@prusnak

You ignore the passphrase completely in the scenario you are describing. The whole discussion here is because of the passphrase.

That's fair, I've never used a passphrase with a Trezor.  However, it seems likely to me given @instagibbs's comment that -d <device_id> doesn't need to be specified for every command even if a passphrase is in use.  (I don't have a spare Trezor to use to test that assertion, though.)

Following up on what @matejcik said, I have been able to restore the previous behavior of having the passphrase entered on device once. After some further testing, the non-specific FirmwareError was only occurring if an Initialize had never been sent. The most recent changes are to do a GetPublicKey to see if it fails, and if it does, then an Initialize will be sent. So we are able to keep the current session open. I no longer was able to reproduce that non-specific FirmwareError on new connections to the device, so I will just call that either a failure in testing methodology, or a bug in a previous firmware revision.
What users experience with these changes should be identical to what they experienced previously.

You ignore the passphrase completely in the scenario you are describing.

I don't think he does. The scenario he describes with using the fingerprint is a common use case. The fingerprint is dependent on the passphrase as it is derived from the key at m/0h. With sessions, the user will always have to provide the session id in order to get the same fingerprint.

We are backward compatible.

While the bulk of this discussion has been about the passphrases, there are other issues this PR fixes which are due to the API not being backwards compatible. Namely the changes to Ping are not backwards compatible as we were expecting the pin_protection field to still be in Ping and have some effect. But that is no longer the case.

@prusnak as you mentioned above, HWI is being used by a couple of projects like Wasabi, BTCPayServer and maybe others too. I know that many of our users love to be able to use their Trezor wallets with Wasabi and the same has to be the case with other projects too.
Two different Wasabi users reported yesterday that they cannot use Trezor with Wasabi after upgrading the firmware and I don't know how many other users could have been affected. Anyway, this is one of those situations where all our projects lose so, could it be possible for Trezor to release a new firmware that makes the interface behaves as before?

Two different Wasabi users reported yesterday that they cannot use Trezor with Wasabi

Unusable Trezor with Wasabi will be fixed when this PR is merged.

could it be possible for Trezor to release a new firmware that makes the interface behaves as before?

No, sorry. Take your time to understand the discussed issue and you'll see there is no regression. And with the change we introduced, the Wasabi UX will be much better for the user. (As they won't have to enter the passphrase again even when switching between different wallets).

Thank you for the cooperation here @prusnak @achow101 @matejcik and @harding !
I agree that we should focus on long-term goals. With all respect, HWI and projects built on the top should be taken into account when checking the compatibility of the upcoming firmware. This issue struct out of the blue and surprised us, more importantly, the users. That is the worst thing can happen on any term.
It seems we can fix this current issue. Also, it attracts the attention that these kinds of changes cannot be done one-sidedly. Preventing cooperation is required.
@achow101 elegant solution! Let me know if I can do some testings on it. Wasabi will publish a new hotfix release with the fix, hopefully soonish.

Here are builds of this PR for testing
hwi-mac.tar.gz
hwi-linux.tar.gz
hwi-win.tar.gz

This version works on old firmware of Trezor T, this is good enough ACK for me.
Testing the new version of firmware now

Updated my Trezor, and it still work. Thank @achow101 !

Tested with numerous HW wallets and firmwares. Works well!

Tested with the binary on macOS but got Could not open client or get fingerprint information: FirmwareError: Firmware error", "code": -13.
However, when I tested (on macOS) from source it worked well for me, both models One and T, both older and the new firmware and both with and without passphrases.
@molnard just to be sure, was the passphrase enabled when you plugged in the device?
For me it does trigger the passphrase input.

I tested with the binaries only (updated according to the edited comment https://github.com/bitcoin-core/HWI/pull/319#issuecomment-615884187)
@ben-kaufman yes the same device is working on windows, there I can enter my passphrase during the enumerate phase.
I have another Trezor_T without the passphrase. It works fine on both OS.

@molnard Yes, I get the same error with the binary, but not when using from the source.

Here are builds of this PR for testing
hwi-mac.tar.gz
hwi-linux.tar.gz
hwi-win.tar.gz
edit: wrong mac build.

@achow101 are you sure the new macOS build linked is correct?

@achow101 are you sure the new macOS build linked is correct?

Nope. I don't have a mac so I can't test it out myself. The macOS builds come from travis, so I probably grabbed the wrong one. But now I can't find the build from this PR...
If the source works, then it should be fine. It looks like there are also some other issues with macOS builds currently.

No problem, it is working - good job, thx!

On Linux I am getting the following error after running our unit tests on HWI:
Error Message:
   WalletWasabi.Hwi.Exceptions.HwiException : 'hwi --testnet enumerate' exited with incorrect exit code: 255.

Zero is the desired. Did you change the exit code?

Installed an Ubuntu 18.04 and dig deeper. With the new release it is not working.
[1810] Error loading Python lib '/tmp/_MEInzgskp/libpython3.6m.so.1.0': dlopen: /lib/x86_64-linux-gnu/libc.so.6: version `GLIBC_2.28' not found (required by /tmp/_MEInzgskp/libpython3.6m.so.1.0)
2020-04-21 15:52:43 ERROR	ConnectHardwareWalletViewModel (140)	WalletWasabi.Hwi.Exceptions.HwiException: 'hwi enumerate' exited with incorrect exit code: 255.
   at WalletWasabi.Hwi.HwiClient.SendCommandAsync(IEnumerable`1 options, Nullable`1 command, String commandArguments, Boolean openConsole, CancellationToken cancel, Boolean isRecursion) in /home/user/WalletWasabi/WalletWasabi/Hwi/HwiClient.cs:line 57
   at WalletWasabi.Hwi.HwiClient.EnumerateAsync(CancellationToken cancel, Boolean isRecursion) in /home/user/WalletWasabi/WalletWasabi/Hwi/HwiClient.cs:line 249
   at WalletWasabi.Gui.Tabs.WalletManager.HardwareWallets.ConnectHardwareWalletViewModel.EnumerateIfHardwareWalletsAsync() in /home/user/WalletWasabi/WalletWasabi.Gui/Tabs/WalletManager/HardwareWallets/ConnectHardwareWalletViewModel.cs:line 414
   at WalletWasabi.Gui.Tabs.WalletManager.HardwareWallets.ConnectHardwareWalletViewModel.<>c__DisplayClass6_0.<<-ctor>b__13>d.MoveNext() in /home/user/WalletWasabi/WalletWasabi.Gui/Tabs/WalletManager/HardwareWallets/ConnectHardwareWalletViewModel.cs:line 129

There weren't any changes to exist codes. I'm not seeing anything unusual with it on Arch.
If you use HWI by itself, do you get the same issue? Is there any error output besides the exit code?

There weren't any changes to exit codes. I'm not seeing anything unusual with it on Arch.
If you use HWI by itself, do you get the same issue? Is there any error output besides the exit code?

According to @lontivero:

Yes, Ubuntu 18.04 comes with libc6 (2.27) and this new hwi requires (2.28).

This upgrade is necessary? It will break HWI for Ubuntu 18.04 users.

According to @lontivero:

Yes, Ubuntu 18.04 comes with libc6 (2.27) and this new hwi requires (2.28).

This upgrade is necessary? It will break HWI for Ubuntu 18.04 users.

Hmm. That's odd. The docker container that does the build should be using debian stretch which has an older libc6. I'll investigate that.

@molnard @lontivero I've redone a build from scratch (nuked the docker containers and rebuilt them) and uploaded the results. These match the travis results too (the previous ones didn't) so the containers were probably dirty from build system changes I was experimenting with. Can you try the new binaries? They should be linked to an older libc.

Where are the new binaries?

On the releases page. I overwrote the original release.

It works in the Ubuntu 18.04 (no libc6 error). Thank you!

Tested, works well! Thx!

source: gharchive/pull-request

authors: NicolasDorier achow101 ben-kaufman harding instagibbs lontivero matejcik molnard nopara73 prusnak


text:
Parse params directly instead of through node (partial revert #10244)

This PR is part of the process separation project.

This is a partial revert of https://github.com/bitcoin/bitcoin/pull/10244. It changes gui code to go back to using gArgs and Params() functions directly instead of using interfaces::Node to handle arguments.
These changes were originally pushed as part of https://github.com/bitcoin/bitcoin/pull/19461. Motivation is to support a new GUI process connecting to an already running node process. Details are explained in commit messages, but in addition to spawning a new bitcoin-node process, we want bitcoin-gui to connect to an existing bitcoin-node process. So for that reason it should be able to parse its own parameters, rather than rely on the node.

Concept ACK. The reasoning as explained in the commit message makes sense to me. Maybe a better PR title would be "Parse params directly instead of through node (Partially revert #10244)". And then in the PR description: "In addition to spawning a new bitcoin-node process, we want bitcoin-gui to connect to an existing bitcoin-node proces. So for that reason it should be able to parse its own parameters, rather than rely on the node."

I'll try to describe the desired behavior as I understand it.
When a bitcoin-gui process starts there are two possibilities: (a) to spawn a new bitcoin-node process and connect to it, or (b) to connect to an existing bitcoin-node process.
In variant (a) the bitcoin-gui process parses arguments (from the command line and from a config file) and passes them to the bitcoin-node process, which in turn does not even look into the config file.
In variant (b) the existing bitcoin-node process already has parsed its arguments (from the command line and from a config file), and  the bitcoin-gui process parses its own command-line arguments and (the same?) config file.
Did I understand the concept correct?
How the possible conflicts between different process parsed arguments should be resolved?

Concept ACK.

Not passing an interfaces::Node argument to the BitcoinApplication and OptionsModel constructors implies that the internal states of the constructed objects with m_node initialized to nullptr are consistent and legitimate. Therefore, their node() getters shouldn't include assert(m_node). I think the responsibility to check the pointer should be moved to callers.

Thanks for reviewing! I looked into many things but wound up not making changes for reasons described below.
re: https://github.com/bitcoin-core/gui/pull/35#issuecomment-660603032

Not passing an interfaces::Node argument to the BitcoinApplication and OptionsModel constructors implies that the internal states of the constructed objects with m_node initialized to nullptr are consistent and legitimate. Therefore, their node() getters shouldn't include assert(m_node).

I don't think this follows. It's ok for functions to have preconditions, and this is a pretty straightforward precondition to have for an accessor returning a reference.

I think the responsibility to check the pointer should be moved to callers.

We might just have a style disagreement here, but if there are specific changes you are looking for, maybe you could post them or describe them in more detail. I don't think we need to have pointers and null checks in places where the pointers can never be null. There's only one place in the PR that actually needs to check for a null node: the splash screen code handling the Q keypress needs to check if the node is connected before sending it a shutdown request. Everywhere else, references and not pointers are more appropriate and have been retained.
re: https://github.com/bitcoin-core/gui/pull/35#pullrequestreview-451120856

I think the m_shutdown member should be dropped due to the following reasons:

m_shutdown is needed so the splash screen can be shown instantly without waiting for anything and the Q key can function requesting a shutdown as soon as possible. Maybe this change could be moved to https://github.com/bitcoin/bitcoin/pull/19461, but you could also say the same about all other changes in this PR. I hope the cleanups in this PR make sense by themselves, but the actual motivation for this PR is to enable https://github.com/bitcoin/bitcoin/pull/19461.

the m_shutdown member could require be protected by a mutex

A mutex would only be required if Qt signals are used incorrectly. GUI state should be accessed by one thread.

nano-nit: why not apply clang-format-diff.py for each commit?

I read diffs to understand changes and having unrelated formatting changes mixed into commits makes this harder.

I think the m_shutdown member should be dropped due to the following reasons:

m_shutdown is needed so the splash screen can be shown instantly without waiting for anything and the Q key can function requesting a shutdown as soon as possible.

I understand this motivation. But the splash screen is not derived from QDialog with own event loop, it is derived from QWidget and it will wait for the main event loop which starts in https://github.com/bitcoin-core/gui/blob/49b993ddb2cea18b7ba8691ea9b572c9e9bbcb9c/src/qt/bitcoin.cpp#L604

I think the m_shutdown member should be dropped due to the following reasons:

m_shutdown is needed so the splash screen can be shown instantly without waiting for anything and the Q key can function requesting a shutdown as soon as possible.

I understand this motivation. But the splash screen is not derived from QDialog with its own event loop, it is derived from QWidget and it will wait for the main event loop which starts in
https://github.com/bitcoin-core/gui/blob/49b993ddb2cea18b7ba8691ea9b572c9e9bbcb9c/src/qt/bitcoin.cpp#L604

What is this comment referring to and what is it asking for? I think we both agree handling a null pointer in the splashscreen is not strictly needed here. It's needed to handle the delayed gui->node connection implemented in https://github.com/bitcoin/bitcoin/pull/19461. The point of all the changes in this PR is to reduce size and complexity of https://github.com/bitcoin/bitcoin/pull/19461. I think it makes sense to handle null node pointer in the splash screen here in this PR which is first introducing the pointer variable, even though the variable won't have a null value until https://github.com/bitcoin/bitcoin/pull/19461.

Concept ACK.

Concept ACK

@ryanofsky Mind rebasing? (no DrahtBot's notifications in this repo for now)

🐙 This pull request conflicts with the target branch and needs rebase.
Want to unsubscribe from rebase notifications on this pull request? Just convert this pull request to a "draft".

Rebased 49b993ddb2cea18b7ba8691ea9b572c9e9bbcb9c -> 1a0875f151be1827a2f880cc63b1022455665c0d (pr/ipc-guiarg.2 -> pr/ipc-guiarg.3, compare) due to conflicts with https://github.com/bitcoin/bitcoin/pull/19561 and https://github.com/bitcoin/bitcoin/pull/15935

🐙 This pull request conflicts with the target branch and needs rebase.
Want to unsubscribe from rebase notifications on this pull request? Just convert this pull request to a "draft".

Rebased 1a0875f151be1827a2f880cc63b1022455665c0d -> 37b7eba5c4d3a77aa3fbd40fa7f066dad6d393c1 (pr/ipc-guiarg.3 -> pr/ipc-guiarg.4, compare) due to conflict with https://github.com/bitcoin/bitcoin/pull/19098

🐙 This pull request conflicts with the target branch and needs rebase.
Want to unsubscribe from rebase notifications on this pull request? Just convert this pull request to a "draft".

Rebased 37b7eba5c4d3a77aa3fbd40fa7f066dad6d393c1 -> 333507a1f3e1941367756dc7974c7c9720d03b4a (pr/ipc-guiarg.4 -> pr/ipc-guiarg.5, compare) due to conflict with https://github.com/bitcoin/bitcoin/pull/19011

re-run ci

🐙 This pull request conflicts with the target branch and needs rebase.
Want to unsubscribe from rebase notifications on this pull request? Just convert this pull request to a "draft".

re-ACK 519cae8fd6, only change is rebase and addressed nits of my previous review last week 🌄
Show signature and timestamp
Signature:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

re-ACK 519cae8fd6, only change is rebase and addressed nits of my previous review last week 🌄
-----BEGIN PGP SIGNATURE-----

iQGzBAEBCgAdFiEE+rVPoUahrI9sLGYTzit1aX5ppUgFAlwqrYAACgkQzit1aX5p
pUj6Ggv+LwP3f/BQc39c/CE6YAwsMHH0yuGCrTpPSZ2Mg4LFVAMNs5Frf7X/WTK3
knd0Wqn8uXL1ohllgYw/RpANRre871edpLXP9DANpAF1mkFM8oQIwLesi2B26TWK
eQWmTbXHeXzmx3TDeyRlNbnd7YQjYWv46qaLaqgtstSzTM5KQG24D2qLL85YgdvK
iGzfDQqNsfVlt8KQa1edWtMi/tbnSKIERKdC1oGjBdWbg/hliwabsDpjaFtgACSS
CwWyz4yVrKcN3fd9KRkkA+InJIdCGxNx2Tkqvof1f7d3P9RZ3OSlVhz6b7/Z2V6a
kucVgTo/bFOdza6AQ+7K6yT3fuYOyhRvwUY2U9CD1heLUFVdaDouCVwqj1AsSTU7
/eqMwOmldW/hrxxVM+Pnm767VryXYMSkOzjBUlEKjrBgSaQSR9PPe4gZ2spAzDYX
R4CIzdXuxLnmYqgY6ynhaQI//XlBg+Kj68oNYcT/ccKuEkMreYjmnta3T7vtiB3b
SONP0kHM
=zDRb
-----END PGP SIGNATURE-----

Timestamp of file with hash ecc68c0f8f95794d4615f84e2642dbc3ee12d9db23d521fe606e763336bf3551  -

authors: DrahtBot MarcoFalke Sjors hebasto luke-jr promag ryanofsky

repo: bitcoin-core/gui


text:
transaction relay policy zh translation

A Chinese translation for a transcript about 'transaction relay policy' by Gloria Zhao in Adapting Bitcoin 2021

Thanks for your review. I will do my best.

repo: bitcointranscripts/bitcointranscripts


text:
Where is the 20mb consensus code?

Sorry if it is obvious but I cannot find the code for the 20mb fork.

Right in the readme, it says, "Please note that Bitcoin XT does not currently change anything about block size limits, although a future version might."

Gavin hasn't submitted any patches to XT to change the block size limit yet. When/if he does submit, the release notes will record the fact that the new version votes for a new block size limit.

@mikehearn why did you git commit --amend instead of adding that line in a seperate commit ... :/ ?

The README explains:
The patch set is a set of commits on top of each branch, with the patches
being rebased on the master branch when time permits and rebased on top of
the release branches when a new upstream release is made. Therefore XT does
not have its own release cycle.
Patches, or changes to patches, are handled with rebases. Therefore we
force push over previous pushes. Don't fork from the Bitcoin XT repository
unless you're able to handle that

Thanks for the heads up. I was under the impression that there was a branch with the new consensus code.

authors: erasmospunk marzig76 mikehearn rubensayshi

repo: bitcoinxt/bitcoinxt


text:
license

Include the license in the NuGet file.

Pull Request Test Coverage Report for Build 3162917183

0 of 0   changed or added relevant lines in 0 files are covered.
No unchanged relevant lines lost coverage.
Overall coverage remained the same at 92.308%

Totals

Change from base Build 3162886841:
0.0%

Covered Lines:
59

Relevant Lines:
63

💛  - Coveralls

authors: bitfaster coveralls


text:
Fix Infer ConfigureAwait test warnings

Fix build warnings:

coverage: 97.188% (+0.2%) from 97.032% when pulling 6e52fda0674141649afadc9d0687131d1cd7b29d on users/alexpeck/testasync into 822e160b18dd7f212280140850c112add7e8b931 on main.


text:
SCTE 35 inserts and Variable maintenance

Added basic insert SCTE35 messages.
Removed unusable System Variables.
Updated live event variables to use the correct URL paths.
Added average_fps as a live event variable.
Added NODE-TLS_REJECT_UNAUTHORIZED for Elementals that do not have authentication.

Thanks for this! One note, is we probably need to add an upgrade script for the new config rejectUnauthorizedInfo option to make sure it has a value.
Here's a little about upgrade scripts, and here's an example of one from another module with the config object. I think once that is added we should be good!

Yeah, that makes sense, this is my first time adding to a companion module so I didn't even realize what upgrade.js did.
I implemented it the same way it was in the example.

authors: bryce-seifert wyatt-vaughan


text:
Template projects localization issues

1- Some translations in french are missing
2- Compare attribute does not work properly

Closed by #3789

repo: bitfoundation/bitplatform


text:
Bug: Compatibility issue with MacOS Catalina on v1.7.0 or higher

Disclaimer:
Please go through existing issues to avoid creating duplicates. If you found a similar issue please post a comment there. If you are uncertain your issue is related to others then create the issue. Obvious ignorance of this rule might get you blocked from posting new issues. Please tick the box below to show that you have followed the guideline.

[x] I have checked for a similar issue and sure it hasn't been reported before.

Describe the bug
Installing v1.7.0 or higher does not appear to be compatible with MacOS Catalina (version 10.15.6).
After installing eqMac and it's driver, the application launches normally. There is audio playing through the app but no EQ effects or other presets are working (no changes can be heard).
Animated audio visualizer is also not seen when music is playing.
This issue is true for both 1.7.1 and 1.7.0.
Tested with older build v1.6.2 and all features working normal.
Expected behaviour
All EQ features and visualizer functioning on latest version of eqMac 1.7.1
Setup information:

Audio device used for playback: Audio-Technica ATH-AD500X, DAC-X6 (FX Audio)
Audio transmission interface: USB (DAC), 3.5mm headphone
macOS Version: 10.15.6
eqMac Version 1.7.1

Additional information
App works normally after installing older builds. V1.6.2 is working. I plan to update OS to BigSur soon and will update if issue is still OS specific.

Also tested this without the DAC and plugged straight to headphone port but still the same issue was replicated.

confirming on catalina with 1.7.0., no effects or volume control.
downgrading to 1.6.2. was an easy fix

downgrading an app is in general never a "fix" but merely a temporary work-around, until there is a fix .. ;)

thank you for your wise words, downgrading did indeed fix the problem of eqmac not working.

yess i have the same iusse and how do i downgrade it

Same Issue here on 10.13.6 won't open at all after upgrade to newest version. Where I can find older versions ?
thanks

yess i have the same iusse and how do i downgrade it

You can find all releases here https://github.com/bitgapp/eqMac/releases

Tganks but i dowloaded the downgrade version and it still bring the new verstion?

Tganks but i dowloaded the downgrade version and it still bring the new verstion?

Be sure to scroll down far enough for 1.6.2 download from the releases page and do not accept auto update when launching the app.

I'm looking into this now, very strange as I tested everything before the release and there were no complains during a Beta rollout.
Will report back when I find something.
Apologize for the issues this has caused :(

Catalina is not supported/ supplied with security updates by Apple anymore so is considered an unsafe and dying OS. There is no need to run it because with the Clover bootloader, newer versions of macOS even run on older Macs which Apple decided to block. @Acorn9443 by any means, upgrade to at least Big Sur, please!
Therefore @nodeful no need at all to apologize - no need for you to fix this, unless in an act of generosity, if you feel like it 👍

@LeeBinder thanks for explanation of something I very much agree with :) There is no need nowadays to stay on older OS versions.
I did find the issue that was causing this:
To better support latest versions of macOS I updated the SDK which completely broke the code library linking for older versions of macOS. I managed to fix it by embedding the libraries with the app itself, which will cause a slight increase in size of the binary but needs to be done to support older OS (which I'm still keen on doing because it's a little bit of work and is a slight competitive edge)
I will be releasing update v1.7.2 in the coming hours.

Here's the release:
https://github.com/bitgapp/eqMac/releases/download/v1.7.2/eqMac.dmg
Can you please try it out and let me know if this has fixed the issue

Good job. I do have a Catalinia test installation in which v.1.7.x stopped working, too, so can also test your new upcoming gem :)

kudos Roman - v.1.7.2 confirmed working again in my "Catalina for testing" installation 👍 🥇

@nodeful thank you so much!
Updated to 1.7.2 and confirming app in now working like a dream on Catalina ✌

@Acorn9443 out of interest & curiosity: what makes you stick to Catalina? Some app that doesn't run anymore in current macOS?

@Acorn9443 out of interest & curiosity: what makes you stick to Catalina? Some app that doesn't run anymore in current macOS?

I run a non-apple PC build running macOS, aka a 'Hackintosh'. Nature of the build means updating OS is a bit more involved (updating and validating config.plist, Kexts, Drivers, etc) so I only do it when totally necessary out of laziness, lol
I'll be updating to Big Sur in the coming weeks for work-related app requirements though.

OK gotcha, thanks for shedding light on the mystery. Good luck updating your hack.

authors: Acorn9443 Jackxei LeeBinder Stafa2 benfade nodeful

repo: bitgapp/eqMac


text:
Home bottom tab can trigger multiple sheets at once

All bottom sheets appear to load when clicking multiple times in quick succession.

-Verified this issue on dev app version 1.4.2(202)

-Verified this issue on dev app version 1.4.2(202)

authors: AliMeer cakesoft-swati

repo: bithyve/hexa


text:
Update scalafmt-core to 3.7.0

Updates org.scalameta:scalafmt-core from 3.6.1 to 3.7.0.
GitHub Release Notes - Version Diff
I'll automatically update this PR to resolve conflicts as long as you don't change it yourself.
If you'd like to skip this version, you can just close this PR. If you have any feedback, just mention me in the comments below.
Configure Scala Steward for your repository with a .scala-steward.conf file.
Have a fantastic day writing Scala!

Adjust future updates
Add this to your .scala-steward.conf file to ignore future updates of this dependency:
updates.ignore = [ { groupId = "org.scalameta", artifactId = "scalafmt-core" } ]

Or, add this to slow down future updates of this dependency:
dependencyOverrides = [{
  pullRequests = { frequency = "30 days" },
  dependency = { groupId = "org.scalameta", artifactId = "scalafmt-core" }
}]

labels: library-update, early-semver-minor, semver-spec-minor, commit-count:1

Superseded by #273.

repo: bitlap/zim


text:
dht_crawler.save_pieces configuration option is ignored.

Have you checked the roadmap on the website, and existing issues, before opening a duplicate issue?
Yes
Describe the bug
dht_crawler.save_pieces configuration option is ignored. It looks like it is not referenced at all in persist.go's createTorrentModel function, while the the other space-saving option dht_crawler.save_files_threshold is referenced and respected. This causes the database to grow in size quite a bit faster than before.
To Reproduce
Steps to reproduce the behavior:

Setup bitmagnet from docker
Use the default configuration option for dht_crawler.save_pieces: false or set the option manually.
Check the pieces and piece_length columns in torrents table of the database as things are crawled and see that they are not null.
Watch the database expand as it fills with pieces data

Expected behavior
By default, pieces and piece_length should not be saved and should be null in the database.
General (please complete the following information):

Bitmagnet version: v0.1.0 (v0.0.7 seems unaffected)
OS and version: Fedora 39
Browser and version (if issue is with WebUI): N/A

Additional context
Add any other context about the problem here.

Same problem with overgrowing DB
Did you find a temporary solution for this?

Ah thanks - that was a bit of an oversight! Just about to release a fix for this. To recover the used space you'll need to do:
update torrents set pieces = null, piece_length = null where pieces is not null;

(this may take a few minutes)

authors: Send8213 hunmar mgdigital

repo: bitmagnet-io/bitmagnet


text:
Add Support for tailwind.config.js files

My company, in addition to the default tailwind classes, has defined a number of others in tailwind.config.js. It isn't helpful to have these autocompletions if  it doesn't include the custom ones.

I completely understand your pain. I feel it myself! However, this is a non-trivial change—if it's even possible—and it would have some performance implications that must be considered. Atom expects a JSON array of completions, and we currently use a build script to generate [completions] for the default Tailwind classes.
In order to provide completions on a per-project basis, we'll have to find a way to check for tailwind.config.js in a project (easy), parse the custom config stuff (easy), and generate modified JSON completions on the fly (potentially hard). I don't have experience with responding to file changes from within a plugin, but I'll look into it. Thanks for the nudge, @mneumark.

authors: bitmanic mneumark

repo: bitmanic/atom-tailwindcss


text:
Align supported platforms

Align supported platforms with https://developer.bitmovin.com/playback/docs/supported-platforms-devices-player#react-native

Closing in favor of #126, missed that PR

repo: bitmovin/bitmovin-player-react-native


text:
java-k8s Dockerfile using legacy Debian Jessie backports

I was following the Deploy A Java Application On Kubernetes With Helm tutorial and encountered the following error message when running docker build build-app -t jhipster
Step 3/6 : RUN echo "deb http://http.debian.net/debian jessie-backports main" >> /etc/apt/sources.list &&     install_packages ca-certificates-java/jessie-backports openjdk-8-jdk-headless bzip2
 ---> Running in 9a2993d6777d
W: Failed to fetch http://http.debian.net/debian/dists/jessie-backports/main/binary-amd64/Packages  404  Not Found

E: Some index files failed to download. They have been ignored, or old ones used instead.
apt failed, retrying
W: Failed to fetch http://http.debian.net/debian/dists/jessie-backports/main/binary-amd64/Packages  404  Not Found

E: Some index files failed to download. They have been ignored, or old ones used instead.
apt failed, retrying
W: Failed to fetch http://http.debian.net/debian/dists/jessie-backports/main/binary-amd64/Packages  404  Not Found

E: Some index files failed to download. They have been ignored, or old ones used instead.
The command '/bin/sh -c echo "deb http://http.debian.net/debian jessie-backports main" >> /etc/apt/sources.list &&     install_packages ca-certificates-java/jessie-backports openjdk-8-jdk-headless bzip2' returned a non-zero code: 100

It seems that the jessie-backports source was recently removed. I then tried using http://archive.debian.org/debian as the source but got this error:
Step 3/6 : RUN echo "deb http://archive.debian.org/debian jessie-backports main" >> /etc/apt/sources.list &&     install_packages ca-certificates-java/jessie-backports openjdk-8-jdk-headless bzip2
 ---> Running in 2b914bb08812
E: Release file for http://archive.debian.org/debian/dists/jessie-backports/InRelease is expired (invalid since 110d 2h 21min 18s). Updates for this repository will not be applied.
apt failed, retrying
E: Release file for http://archive.debian.org/debian/dists/jessie-backports/InRelease is expired (invalid since 110d 2h 21min 23s). Updates for this repository will not be applied.
apt failed, retrying
E: Release file for http://archive.debian.org/debian/dists/jessie-backports/InRelease is expired (invalid since 110d 2h 21min 28s). Updates for this repository will not be applied.
The command '/bin/sh -c echo "deb http://archive.debian.org/debian jessie-backports main" >> /etc/apt/sources.list &&     install_packages ca-certificates-java/jessie-backports openjdk-8-jdk-headless bzip2' returned a non-zero code: 100

I also tried using newer stretch-backports but got this error:
Step 3/6 : RUN echo "deb http://http.debian.net/debian stretch-backports main" >> /etc/apt/sources.list &&     install_packages ca-certificates-java/stretch-backports openjdk-8-jdk-headless bzip2
 ---> Running in 138ec0113c33
Reading package lists...
Building dependency tree...
Reading state information...
Package openjdk-8-jdk-headless is not available, but is referred to by another package.
This may mean that the package is missing, has been obsoleted, or
is only available from another source

apt failed, retrying
E: Release 'stretch-backports' for 'ca-certificates-java' was not found
E: Package 'openjdk-8-jdk-headless' has no installation candidate
Reading package lists...
Building dependency tree...
Reading state information...
Package openjdk-8-jdk-headless is not available, but is referred to by another package.
This may mean that the package is missing, has been obsoleted, or
is only available from another source

E: Release 'stretch-backports' for 'ca-certificates-java' was not found
E: Package 'openjdk-8-jdk-headless' has no installation candidate
apt failed, retrying
Reading package lists...
Building dependency tree...
Reading state information...
Package openjdk-8-jdk-headless is not available, but is referred to by another package.
This may mean that the package is missing, has been obsoleted, or
is only available from another source

E: Release 'stretch-backports' for 'ca-certificates-java' was not found
E: Package 'openjdk-8-jdk-headless' has no installation candidate
The command '/bin/sh -c echo "deb http://http.debian.net/debian stretch-backports main" >> /etc/apt/sources.list &&     install_packages ca-certificates-java/stretch-backports openjdk-8-jdk-headless bzip2' returned a non-zero code: 100

So I guess there some related changes that need to be made.

Hi, @archelangelo.
Thank you for reporting this. I've created an internal task to update the tutorial. I can't give you an ETA, but I'll come back to you when it's done.
In the meantime, you may try using the minideb-extras:stretch image instead of the jessie one, and installing the packages from the stretch repos:
FROM bitnami/minideb-extras:stretch-r386

RUN install_packages ca-certificates-java openjdk-8-jdk-headless bzip2

Regards,
Alejandro

authors: alemorcuq archelangelo

repo: bitnami/tutorials


text:
Notes on setup

Great to see a go API!
I found a few things in the instructions.

environ.sh isn't checked into the repo
ginkgo install instructions are missing go get github.com/onsi/ginkgo/ginkgo

Typically, go projects are checked out to the $GOPATH proper. Go's standard tools are very closely hooked to VCS and it makes everything a lot easier to have code in $GOPATH. This might be why the setup midway deletes everything and starts over again.
go get github.com/bitpay/go-bitpay
cd $GOPATH/src/github.com/bitpay/go-bitpay
git remote add origin git@github.com:<username>/go-bitpay.git

This can be done with just git as well by using $GOPATH as the destination: go get github.com/bitpay/go-bitpay $GOPATH/src/github.com/bitpay

Thanks for the feedback!  There's some discussion internally on how we're going to end up distributing this library while simultaneously maintaining a development branch, separate repo, etc...  If you don't mind, I'd love to open up a dialog with you off GH to pick your brain on "how things are done" in the Go community.  You look like you've done a lot with the language based on your account so I'm sure you can lend a lot of insight!  Drop an email to integrations@bitpay.com when you have a moment which will reach my entire team including the developer that's been working on this project specifically.
Thanks again!
Rich

Does this issue belong here or on the bitpay-go-cli repo?

Okay, so I made a couple of changes to the ReadMe to indicate that these instructions reference the reference project, not this repo. Following the instructions as written should result in a working repo with all of the test dependencies, etc.

authors: drewwells ionux philosodad

repo: bitpay/bitpay-go


text:
this plugin is a big trash

nothing work you have waste my time this plugi doesn't work
big trash don't lost your time to install

It actually does work? Maybe try a bit more before opening an issue claiming it doens't work. Also might want to specify what isn't working.

authors: DaanTul ledarky

repo: bitpay/cordova-plugin-qrscanner


text:
Getting full opaque camera view

If you can help I asked about the problem here:
http://stackoverflow.com/questions/43225506/cordova-cordova-qrscanner-plugin-opaque-camera-view

I took a shot at answering it – hopefully that helps!


text:
是非Zaifにも対応して頂けませんか

こんにちは。
素晴らしいツールの開発ありがとうございます。
表題のとおりですが、Zaifにも対応いただけると大変ありがたいです。
検討よろしくお願いいたします！

Zaifに対応させる予定はありません。
理由は、Zaifの提供しているAPIが非常に不安定なためです。
また、APIに限らずZaifの約定動作は不可解・不自然であり、その原因がシステム上の問題なのか、他のなんらかの「意図」があるのかわかりません。

authors: bitrinjani cclemonasa


text:
🛑 Luogu Ti is down

In 26d0b9d, Luogu Ti (https://ti.luogu.com.cn/problemset) was down:

HTTP code: 0
Response time: 0 ms

Resolved: Luogu Ti is back up in d8ab61d.

repo: bitsstdcheee/luogu-status


text:
ExecJS::ProgramError

Hello,
I'm using a sidekiq job to generate a temp password. But quite often I get ExecJS::ProgramError: ExecJS::ProgramError error while checking the strength of generated password. The error message is not very informative, but I guess the devise_zxcvbn / zxcvbn-js causes it.
Any ideas what could be wrong?
devise_zxcvbn (2.1.1)
  zxcvbn-js (~> 4.2.0)

def weak_password?(password)
  Devise.zxcvbn_tester.test(password, []).score < Devise.min_password_score
end

ExecJS.runtime.name #=> "therubyracer (V8)"

@handcrab Could you please show me your Gemfile.lock I am interested in a version of therubyracer

I've tried to run this with these gems and it works. I guess I have to set the same version of therubyracer and zxcvbn-js...
therubyracer (0.12.2)
  libv8 (~> 3.16.14.0)
  ref
zxcvbn-js (4.4.2)
  execjs

@handcrab I could not reproduce the issue with following versions
    devise_zxcvbn (2.1.1)
      devise
      zxcvbn-js (~> 4.2.0)
    rails (5.0.2)
    sidekiq (2.17.6)
    therubyracer (0.12.3)
      libv8 (~> 3.16.14.15)
      ref

Can you please provide with more info on the versions of the gems and/or the sample application where the error can be reproduced?
class User
  def weak_password?(password)
    Devise.zxcvbn_tester.test(password, []).score < Devise.min_password_score
  end
end

class HardWorker
  include Sidekiq::Worker
  def perform
    puts User.new.weak_password?("123")
  end
end

irb(main):009:0> HardWorker.perform_async
2017-03-29T15:19:18Z 9522 TID-ovzi54q3o INFO: Sidekiq client with redis options {}
=> "74826ba2d48b195a20495197"

authors: IlkhamGaysin dreamfall handcrab


text:
Simulator hand velocity

Hand velocity is awesome for simple drag and drop.
dragged_item_pos:add(lovr.headset.getVelocity('left'))

I still want to add the angular velocities to both head and hand for completeness.

I'm gonna close this since it's been a draft for a while, but feel free to resubmit if you want to revisit this!

authors: bjornbytes jmiskovic

repo: bjornbytes/lovr


text:
Typescript integration

Is there a way to have Typescript integration? I would love to be able to get the Types.

I don't use typescript so I'm not the best person to create the type definitions if anyone wants to improve the typescript integration i'm happy to merge any PR related to that
for reference this looks related to #8 too, so just linking it here.

repo: bjrmatos/sequelize-auto-import


text:
How to get started? Are docs wrong?

Hi All,
Looking at bgfx for an idea.
I am here: https://bkaradzic.github.io/bgfx/build.html
trying to build bgfx and run examples on iOS.
I managed to run
cd bgfx
make
make projgen

I don't see this piece anymore:
Due to inability to set working directory for an Xcode project from GENie configuration file, it has to be set manually for each example project:

    Open “Edit scheme...” dialog for a given project.
    Select “Run” settings.
    Check “Use custom working directory” and enter following path: ${PROJECT_DIR}/../../../examples/runtime.

but when I try and run anything from within XCode, I just get errors upon errors. Probably because I can set a working directory.
Does anyone know how to fix this?

You can't set working directory for iOS. I am adding the contents of examples/runtime (font, images, .. folders) as folder references to the example project.
Without setting this only 00-helloworld example works,

Can you tell me how to get the examples working?
I'm using the Xcode workspace and actually nothing compiles. I can comile bgfx into libraries on the command-line though.

Ah this just happening since I switch to new option in GENie...

@attilaz Thank you. Yes, switching to c++11 did fix everything and I can run examples. Yes, just 00, the rest crash as you mentioned. Is there a forum for bgfx discussion?

https://gitter.im/bkaradzic/bgfx

@slackmoehrle
see: https://bkaradzic.github.io/bgfx/build.html?highlight=scheme#xcode
Here's my steps:
// git clone 3 bgxx repos into ~/bgfx/ (or wherever)
cd bgfx/
../bx/tools/bin/darwin/genie --with-examples xcode9
open ./.build/projects/xcode9/bgfx.xcworkspace
// Select Target 'example-01-cubes'
// Edit Scheme ...
// Select 'Options' "tab"
// Check 'use custom working directory'
// Fill in full path (or use open dialog) 'xxxxx/bgfx/examples/01-cubes'
// ** I don't know the valid relative path, should be possible

Unfortunately you have to do this for any project you want to run. There's got to be a way to use some tool to automate the editing of these?

I need to fix GENie for Xcode.
If you revert this locally, you won't need to set -std=c++11 manually...
https://github.com/bkaradzic/bx/commit/468e39c2570786aac1d8a4003084b5d3ced025cd

Actually looks like the latest HEAD has combined the examples using imgui as simplified launcher. So you only need to set the working directory in one or a few example projects.
// either full path
/Users/name/path/to/bgfx/examples/runtime
// or possibly relative to proj
$(PROJECT_DIR)/../../../examples/runtime

authors: attilaz bkaradzic slackmoehrle stevetranby

repo: bkaradzic/bgfx