Successful install of PiVPN, but failed service start on reboot (RP3b, Jessie Lite via Noobs)

Hi all,
I am unable to start the OpenVPN service after install.  Looking for help reading the logs posted below.  I tried to find the answer to this issue before posting.  Many thanks to you in advance.
Raspberry Pi 3 b
Jessie Lite (installed via NOOBS over WAN)
16gb Sandisk (FAT32)
Logitech Unifying Receiver Keyboard
Immediately after the install, I ran the installation command (curl piped to bash) and successfully installed PiVPN.
After reboot, I noticed a service failure for OpenVPN:
https://pastebin.com/bA74Qi0M
Output of systemctl status<EMAIL_ADDRESS>https://pastebin.com/JPDkRt27
Output of command pivpn debug:
https://pastebin.com/aCuK1TWK
(note that I am using a registered domain and a CNAME to resolve requests to a dynDNS domain which keeps my IP updated... I can ping the domain to get the correct IP, and I can access lighttpd pages served from Pi to WAN via this domain, so I believe I've ruled out connectivity and port forwarding issues)
... which seems to indicate an issue with iptables setup/config.  When I click yes, the debug screen doesn't solve the issue:
::: Would you like us to try to fix this? [y/n]: y
modprobe: ERROR: ../libkmod/libkmod.c:557 kmod_search_moddep() could not open moddep file '/lib/modules/4.4.50-v7+/modules.dep.bin'
iptables v1.4.21: can't initialize iptables table `nat': Table does not exist (do you need to insmod?)
Perhaps iptables or your kernel needs to be upgraded.
modprobe: ERROR: ../libkmod/libkmod.c:557 kmod_search_moddep() could not open moddep file '/lib/modules/4.4.50-v7+/modules.dep.bin'
iptables v1.4.21: can't initialize iptables table `nat': Table does not exist (do you need to insmod?)
Perhaps iptables or your kernel needs to be upgraded.
::: Attempt at fix completed.
::: Run 'pivpn debug' again to see if we detect issues.

I suspected that apt-get update and apt-get upgrade might need to be run first.
So I uninstalled PiVPN with pivpn -u , ran sudo apt-get update, then sudo apt-get upgrade
Then re-installed PiVPN.  Same issue.
I can see iptables is installed
pi@shankvpn:/var/log $ sudo apt-get install iptables
Reading package lists... Done
Building dependency tree
Reading state information... Done
iptables is already the newest version.
0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.

Seems like a missing dependency.  Ever seen this?  Could it be a new issue due to a Jessie Lite update?
Would you recommend a different installation method for my debian distro?

Ok, according to pivpn debug some wierd problem with your iptables.
can you please post here the output of:
iptables -t nat -S

Appreciate you getting back to me.
pi@shankvpn:~ $ iptables -t nat -S
modprobe: ERROR: ../libkmod/libkmod.c:557 kmod_search_moddep() could not open moddep file '/lib/modules/4.4.50-v7+/modules.dep.bin'
iptables v1.4.21: can't initialize iptables table `nat': Table does not exist (do you need to insmod?)
Perhaps iptables or your kernel needs to be upgraded.
pi@shankvpn:~ $ sudo iptables -t nat -S
modprobe: ERROR: ../libkmod/libkmod.c:557 kmod_search_moddep() could not open moddep file '/lib/modules/4.4.50-v7+/modules.dep.bin'
iptables v1.4.21: can't initialize iptables table `nat': Table does not exist (do you need to insmod?)
Perhaps iptables or your kernel needs to be upgraded.

Should I just restart installation from the beginning?  I wouldn't mind doing so if it helps us debug any potential issues with the PiVPN script.
But if there's an easy fix, I'd accept that, too.

Hmm something wrong here! never seen such issue, there's a kernel module missing,
iptable_nat i belive.
have you been messing with Linux kernel? is this setup a clean setup? where did you get the raspbian image from?
let's try to fix this without reinstalling,
please provide me the output of:
lsmod | grep iptable

Have not messed with the Kernel, not intentionally.
The only other installs I've done are nginx and lighttpd, which I did after I couldn't get OpenVPN working.
pi@shankvpn:~ $ lsmod | grep iptable
pi@shankvpn:~ $ lsmod
Module                  Size  Used by
pi@shankvpn:~ $ sudo lsmod
Module                  Size  Used by
pi@shankvpn:~ $

I bought a new 16gb sandisk card, UHS-1, didn't format.
Downloaded Noobs network edition, and choose debian lite or jessie lite, whichever was shown on the screen... can't remember what it said.
Restarted, did some basic config in raspi-config, nothing earth-shattering.
Rebooted, tried PiVPN, rebooted, and got to this point.

sorry, I tend to forget to use sudo since I have the (bad) habit of using root user directly, so always use sudo with commands I provide, I will try to not forget it =P
lsmod should output a LOT MORE! your kernel might be cooked since it shows no modules at all.
maybe because of the way you imaged your sd card since you mentioned you didn't format it ...I usually remove all the partitions and use the unpartitioned card. however, I do it with Linux and use dd for it, never used noobs or Etcher which is mentioned here: https://www.raspberrypi.org/documentation/installation/installing-images/README.md
I think it would be a safe and easier bet to read again the raspbian installation guide and reinstall Raspbian Jessie Lite ( if you don't want Desktop environment ), and then come back and report us if everything wen't ok or not! ;)

I will do this.  Thanks for your help!

I am very happy to report no issues after reinstalling Jessie.
This time around, I downloaded the full version of NOOBS, not the smaller network-installed version.
I also chose Jessie instead of Jessie Lite.
OpenVPN started successfully after the PiVPN script and reboot completed.


Perf events and Lock profiling

The infrastructure for profiling HW and SW perf counters
Kernel tracepoints support
Lock profiling (contented monitorenter events)

will have a look later today

Thank you  for the review. I updated documentation and created CHANGELOG. I'm going to merge this now, but further comments are always welcome.


POD names needs to be updated

The name of the PODS needs to be updated..
[Enter feedback here]
The name of PODS needs to be updated..
microsoft-defender-collector-ds-*
microsoft-defender-collector-misc-*
microsoft-defender-publisher-ds-*

Document Details
⚠ Do not edit this section. It is required for learn.microsoft.com ➟ GitHub issue linking.

ID: 4fdb6909-77c6-4e99-628e-c46a90a32577
Version Independent ID: 3480e64a-0023-0a05-da12-250ef4154f54
Content: Container security architecture in Microsoft Defender for Cloud
Content Source: articles/defender-for-cloud/defender-for-containers-architecture.md
Service: defender-for-cloud
GitHub Login: @bmansheim
Microsoft Alias: benmansheim

@moravindMSFT
Thanks for your feedback! We will investigate and update as appropriate.

@moravindMSFT Thanks to you I updated the page. Good work! Watch for the update later today.
#please-close


create new provider like ChangeNotifier, but for dart only code

Is your feature request related to a problem? Please describe.
I have an app that has a cli and a gui (flutter) with common code backing them. I did a feature in the gui first and used ChangeNotifier since it seemed to be the easiest for that need - which worked fine. I ran into a compiler crash issue when I updated the cli side to use the common code. When I looked further, I realized ChangeNotifier comes from flutter and attempting to use that code with dart would crash (dart run .\bin\my_cli_entry_point.dart).
Describe the solution you'd like
I'd like a mutable state alternative to ChangeNotifier that works in dart only code, perhaps MutableStateNotifier.
Describe alternatives you've considered
I rewrote it using StateNotifier, but it seems a bit awkward compared to the ChangeNotifier implementation (for this use case).
Additional context
I'm using StorageBox to store some simple settings locally. Their internals write to a local file without an obvious way to mock out for testing, so I make a StorageBoxWrapper that I can fake for tests.
class StorageBoxWrapper {
  StorageBoxWrapper() : _sb = _initStorageBox();

  final StorageBox _sb;

  String operator [](String key) {
    return tryCast(_sb[key], '');
  }

  void operator []=(String key, String value) {
    _sb[key] = value;
  }

  static StorageBox _initStorageBox() =>
      StorageBox('settings', configPathPrefix: productId);
}

My original code basically just delegated to the wrapper:
class Settings extends ChangeNotifier {
  Settings({StorageBoxWrapper? storageBoxWrapper})
      : _sbw = storageBoxWrapper ?? GetIt.I<StorageBoxWrapper>();

  @visibleForTesting
  static const String key_apiKey = 'apiKey';

  final StorageBoxWrapper _sbw;

  String get apiKey {
    return _sbw[key_apiKey];
  }

  void setApiKey(String newApiKey) {
    final oldApiKey = apiKey;

    if (newApiKey != oldApiKey) {
      _sbw[key_apiKey] = newApiKey;
      notifyListeners();
    }
  }
}

My StateNotifier code:
@freezed
class Settings with _$Settings {
  factory Settings({required String apiKey}) = _Settings;
}

class SettingsNotifier extends StateNotifier<Settings> {
  SettingsNotifier({StorageBoxWrapper? storageBoxWrapper})
      : _sbw = storageBoxWrapper ?? GetIt.I<StorageBoxWrapper>(),
        super(Settings(apiKey: storageBoxWrapper?[key_apiKey] ?? ''));

  final StorageBoxWrapper _sbw;

  @visibleForTesting
  static const String key_apiKey = 'apiKey';

  void setApiKey(String newApiKey) {
    final oldApiKey = state.apiKey;

    if (newApiKey != oldApiKey) {
      _sbw[key_apiKey] = newApiKey;
      state = state.copyWith(apiKey: newApiKey);
    }
  }
}

In the new code, state is separate from the wrapper, but both need to be updated and maintained. Also, the client needs to get a different object depending on if they are reading or writing. During creation, I need to supply super with an initial state object which is just what the wrapper already knows.
All that said, it's entirely possible I could have done things in a better way, if I knew more, and then not felt like the new solution was more awkward.

Sorry, this is my first time using Riverpod and I don't immediately understand how I would use that. Would it be like my original Settings class, but it takes a ref object in constructor and does not extend ChangeNotifier? Then I could call ref.notifyListeners() in the same place I had called notifyListeners() before? Where does the ref come from?

It's be like the StateNotifier variant, but you would do:
  void setApiKey(String newApiKey) {
    final oldApiKey = state.apiKey;

    if (newApiKey != oldApiKey) {
      _sbw[key_apiKey] = newApiKey;
      state.apiKey = newApiKey;
      ref.notifyListeners();
    }
  }

That "ref" would be passed to the constructor of the class by the provider.

If I'm following correctly, I think that would be fine. Thanks for quick response!


Unnecessary query when eager loading

Laravel Version: 5.5.14
PHP Version: 7.1.3
Database Driver & Version:

Description:
When eager loading a relation, a query is still made if the values in IN are all empty. I feel an optimisation could be made to check to see if all the values in the IN will be empty and avoid the query.
Steps To Reproduce:
$widget = Widget::findOrFail(1);
$widget->parent_id = null;
$widget->save();

$widget->load('parent');

Results in the query SELECT * FROM widget_parents WHERE widget_parents.id IN (''). Unless I'm missing some edge cases that I can't think of, this will always return an empty result.

There may be domain logic that forbids widget_parents.id == '', but it is valid on a database level. You can have strings as primary keys.

My point is that a relationship will never join on a field with an empty value. Will it?

My point is that a relationship will never join on a field with an empty value. Will it?

Of course they can, if the field is the appropriate type. Example (postgres):
CREATE TABLE foo (
  id VARCHAR(1) PRIMARY KEY
);
CREATE TABLE bar (
  id     BIGSERIAL,
  foo_id VARCHAR(1) CONSTRAINT bar_foo_id_fkey REFERENCES foo
);

INSERT INTO foo (id) VALUES ('');
INSERT INTO bar (id, foo_id) VALUES (123, '');

SELECT *
FROM bar
  JOIN foo ON bar.foo_id = foo.id;
-- => will show the result correctly

Maybe you're mixing it up with WHERE … IN (NULL) which can never match?

For suggestions and feature requests please use the https://github.com/laravel/internals repo.


Adds test cases for compression

Wrong method is advertised
Multiple chained methods
Fixes #941
Test case 91 is in PR #191

The tests appear to fail in travis.

Yes, this was a dummy git mistake


Wire Up Existing Sys-Share Proxy and Sys to Maintemplatev2

Background
sys-share and sys has been refactored "just-enough" to conform to the spec specified at the main repo README and modular architecture document here.
Now we need to build it from the top (this repo)
What needs to be done

Current sys/main/pkg needs to call sys-share/pkg/service-proxy instead of directly calling generated rpc package, to satisfy the proxy design pattern from the spec.

Wire up current code at sys/main/pkg and sys/pkg to the main/deploy/templates/maintemplatev2. Should conform to the v2 spec mentioned in the background documents (single binary).

Make sure the top->bottom recursive build and tests succeeded, use current Makefile to drive the builds.

Steps To Do:
Sys-Share

Fully utilize sys-share/pkg as a proxy for sys-account (for now, 80% done).

For example:

[] sys-share will provide both in-process and out-of-process interface to the protobuf service ( like the spec)
[] Once the proxy is done, actually calls it from the sys/main/pkg where it will cater to both the needs from sdk-cli or from the actual sys-* server that is defined there.
[] The sys in turn will be called from the maintemplate (v2 atm), So basically the maintemplatev2 will be a sort of simulation of how the actual mod (or the maintemplate) will be done.
[] Make sure everything builds from the bottom-up.

Steps To Do:

[X] Fully utilize sys-share/pkg as a proxy for sys-account (for now, 80% done).

For example:

[] sys-share will provide both in-process and out-of-process interface to the protobuf service ( like the spec)
[] Once the proxy is done, actually calls it from the sys/main/pkg where it will cater to both the needs from sdk-cli or from the actual sys-* server that is defined there.
[] The sys in turn will be called from the maintemplate (v2 atm), So basically the maintemplatev2 will be a sort of simulation of how the actual mod (or the maintemplate) will be done.
[] Make sure everything builds from the bottom-up.


Added objects for enumerating multiattack options, addressing issue 116.

This is the change associated with the issue I submitted: #116
Please look it over and let me know what you think. Some of the monsters' multiattacks are almost impossible to represent in the way I've organized the data without adding more complexity. And I'm not sure that's worth it. Here are the ones that proved to be especially tricky because of special cases withing the multiattack description...
Glabrezu
The glabrezu makes four attacks: two with its pincers and two with its fists. Alternatively, it makes two attacks with its pincers and casts one spell.
Grick
The grick makes one attack with its tentacles. If that attack hits, the grick can make one beak attack against the same target.
Shambling Mound
The shambling mound makes two slam attacks. If both attacks hit a Medium or smaller target, the target is grappled (escape DC 14), and the shambling mound uses its Engulf on it.
Tyrannosaurus Rex
The tyrannosaurus makes two attacks: one with its bite and one with its tail. It can't make both attacks against the same target.
Violet Fungus
The fungus makes 1d4 Rotting Touch attacks.

@jbhaywood Sorry, I keep meaning to look at this but the diff is too big for github to load. So I keep putting off pulling this down locally and inspecting the diffs.
This also makes me suspect that this should probably be split into at least two different PRs. One that handles the multiattack shapes and one that handles adding in missing fields.

Looking at your branch I can tell the following monsters are missing multiattack options:

Animated Armor
Chimera
Chuul
Cult Fanatic
Deva
Doppelganger
Dragon Turtle
Drider
Erinyes
Glabrezu
Gladiator
Half-Red Dragon Veteran
Horned Devil
Hydra
Iron Golem
Knight
Kraken
Lamia
Lizardfolk
Merrow
Oni
Planetar
Purple Worm
Sahuagin
Scout
Shambling Mound
Spy
Tarrasque
Thug
Vampire Spawn
Veteran
Wight
Wyvern

Closing out in favor of #168, #169, and #170


nessus 容器内 Network interface not supported

出现这个问题
Network interface not supported The network interface 'eth0' does not support packet forgery. This prevents Nessus from determining whether some of the target hosts are alive and from performing a full port scan against them. You may partially work around this problem by editing your scan settings to disable 'Ping' (Uncheck General->Ping host) and by providing Nessus with credentials to the remote host to prevent a port scan from taking place, however it would be preferable to scan over a different network interface.
尝试安装libpcap-dev 后仍未解决，扫描选项剔除ping后，报错
`The nessusd.dump log file contained errors from the following plugins:

scada_profinet_network_detect.nbin reported 1 error
teredo_server_detect.nasl reported 1 error
labrea.nasl reported 2 errors
arcserve_discovery_service_detect.nasl reported 1 error
cisco_synful_knock.nbin reported 1 error
tftpd_detect.nasl reported 6 errors
slp_udp_detect.nasl reported 1 error
icmp_domain_name.nasl reported 1 error
icmp_timestamp.nasl reported 3 errors
huawei_cmd_exec.nbin reported 1 error
ike_detect.nasl reported 2 errors
upnp_xp.nasl reported 3 errors
nessus_syn_scanner.nbin reported 1 error
traceroute.nasl reported 12 errors
icmp_mask_req.nasl reported 3 errors
tcp_port_zero.nasl reported 3 errors
dhcp.nasl reported 1 error
ike2_detect.nasl reported 12 errors`

打扰了 centos的问题 换成ubuntu 妥了


feat(sort-imports): resolve aliased imports through tsconfig.json

Resolves #317
Description
Adds a tsconfigRootDir?: string option (can be changed if needed). When passed by the user, each time a file is linted, the nearest tsconfig.json file will be searched, read, and used to determine if an import is internal or not.
Will try to dynamically load (and cache) typescript so this should not impact non-typescript users.
The tsconfig.json search and cache algorithm was taken from https://github.com/typescript-eslint/typescript-eslint/blob/main/packages/typescript-estree/src/parseSettings/getProjectConfigFiles.ts 🙏.
Process

Linting is run for a given file
Check if tsconfigRootDir is entered. If not, sort as usual.
Ensures that typescript is present. If not, sort as usual.
If it is, search and read the closest tsconfig.json file and get the compiler options.
If no file is found, sort as usual. If an error occurs (config file is invalid, for example), throw an error.
For each import, use the compiler options to determine if that import can be marked as internal or internal-type (for the groups option).

Assigning the internal / internal-type / external / external-type group to an import
Reminder: currently, internal and internal-type are only assigned to groups that match the internalPattern option. Non-external imports are not automatically matched with the internal / internal-type group.
I have chosen to keep this, and add the following:
If an import is considered 'internal' according to the user's tsconfig, that import will be matched with the internal / internal-type group as if it was matching internalPattern.
Everything below also applies for type imports with internal-type and external-type.
For a given import:

If typescript is not present, use the standard process: the import is external if it starts with . or /.
Else: If typescript.isExternalModuleNameRelative(import), do not assign internal nor external at this stage.
If tsconfigRootDir is not entered or if no tsconfig.json file was found, do not assign internal nor external at this stage.
Get typescript information about the import using typescript.resolveModuleName.
If the resolution failed, assign external.
If the resolution succeeds, assign external if resolution.resolvedModule.isExternalLibraryImport === true, otherwise internal.

Performance
Tests on a ~10k files codebase.

[x] Investigate caching resolve attempts

Without caching resolve attempts

With caching resolve attempts

Without tsconfigRootDir option (what we have today)
(Some other rules were disabled)

Bottlenecks
Tests made while caching resolved attempts (~950ms)

Without searching tsconfig.json: ~900ms
Without typescript.resolveModuleName: ~620ms

Conclusion
Some significant performance hit despite caching.

Searching for the appropriate tsconfig.json: ~+15%
typescript.resolveModuleName: ~+75%
Reading and parsing the config: ~300ms?

What is the purpose of this pull request?

[x] New Feature

I've run some performance tests, you can see the results in the PR description.
Long story short, there is going to be a performance hit:

Searching for the appropriate tsconfig.json file is fast (<100ms in my test), but note that I tested it in a large project with a single file. Multiple tsconfig.json shouldn't affect the performance at this stage too much, though.
Reading/parsing tsconfig.json. I haven't tested that single stage too far, but I wouldn't be surprised if this takes 200+ms for large projects, or even more.
typescript.resolveModuleName: the function used to know whether an import is external or not according to typescript. Even with cache, this takes a non-negligible amount of time, probably ~300ms in my tests.

Without the option activated, the total time for everything was about 350ms.

I would actually love to be able to get feedback on whether this is going to be an issue or not.
@gavvvr Would you be okay for testing this in your project(s)? This will also be a great opportunity to make sure that the new algorithm works as expected in practice.

@gavvvr Would you be okay for testing this in your project(s)? This will also be a great opportunity to make sure that the new algorithm works as expected in practice.

Hello @hugop95. I don't have much code to test this. There are only several absolute imports in fd8e9a2ec snapshot of my open-source project. Right after this commit I switched to relative imports, because I wanted sorting/grouping by perfectionist plugin to work as expected :)
Those absolute imports appeared in my codebase only because I used vscode's hotkey to add missing imports. If you are still interested, that probably will be faster for you to test it (now you know where the codebase is). Unfortunately, I'm not much experienced with testing things, which are not yet on npm registry.

@gavvvr No worries, thanks!

@azat-io @OlivierZal
I have finished my work on this PR, performance concerns are addressed at the bottom of the PR description.
Overall, I have mixed feelings on this:
The good points:

Code specific to handling typescript import, searching for the tsconfig.json files, etc... are isolated from the rule, so not that much code added in the rule itself.
Performance impact is ok. It does make the rule take a longer time, but it's still acceptable.

The bad:

It's still a lot of code for one option in one rule.
I haven't been able to test this in a large repository with multiple configs (real use-case), so even if we have tests, they don't replicate complex use cases and we might still have bugs.
I don't know if it will be used: will it be worth maintaining in the end?

Still to discuss:

Are we keeping tsconfigRootDir  as the option's name (https://github.com/azat-io/eslint-plugin-perfectionist/pull/345#discussion_r1827315159)? What about the default value?

Current implementation looks good to me:

tsconfigRootDir name is consistent with existing eslint options (we could eventually also authorize the value true, like this is sometimes the case with some eslint options – e.g. projectService –, which would read languageOptions.parserOptions.tsconfigRootDir)
not enabled by default, so no impact on performances if the user doesn't explicitly fill it

Looks good. 👍
But I'd like to take some more time to test. Because the task is difficult.

@azat-io I aggree, no rush!

It works!
Perhaps we should also consider support for aliases from paths in tsconfig.json in the future. Thank you!


nwg-menu with waybar?

What's the recommended way to have nwg-menu available on waybar?

Haven't used waybar for years, but I'm pretty sure one can add a button there. For menu positioning, nwg-menu -h is your friend.

What I have is:
    "custom/nwg-menu": {
      "format": "MENU",
      "on-click": "nwg-menu",
      "tooltip": false,
    },

and it shows up correctly, let me choose a program to run, but does not run in and just prints what should be run on the terminal :)

Could you try nwg-menu -wm hyprland or nwg-menu -wm sway, depending on what compositor you are on?

BINGO!
    "custom/nwg-menu": {
      "format": "MENU",
      "on-click": "nwg-menu -wm hyprland",
      "tooltip": false,
    },

works like a charm, thanks for explanation!

Can't look at the code at the moment, but the compositor should have been auto-detected, if I remember well. I'm not sure what goes wrong on your side. Or maybe I'm wrong. I don't use nwg-menu in real life.

The most important is that it works now :)


C# Language operators: ?.  Null Conditional operator

The migrated content does not include the ?. operator added in C# 6. The result is null if the LHS is null, right if LHS is not null.

Isn't this that article? Though it could use cleanup to be consistent with the other operator articles. And probably splitting into a C# and a VB article. And possibly also splitting ?. and ?[.

@svick I also want to make sure that ?? is covered, or at least linked to as well.


A problem during training

While I tried to use the train_imagenet.py training alexnet with my own data, the application was crashed. The computer used GTX 970 under windows 10. Anyone know why?

And I can run the example train_cifar10.py and train_mnist.py properly.

Have you checked the memory consumption?

This issue is closed due to lack of activity in the last 90 days. Feel free to reopen if this is still an active issue. Thanks!


Gulp file generation fixed

I fixed the "dist" file generation.
Closes issue #37

Thanks to @seeekr for the comment. I have to agree with what he´s writing, so we'll not merge this one.
Besides, please note that we've been working on a new version (see branch 0.3) for a while. I know that you are using master, but from our point of view it does not make sense to work on a PR which targets master and is in conflict with 0.3.

Hi @sehmaschine .
The issue of invalid dist file generation still persist. Wherein the error could be resolved with the changes suggested by @juanelojga in his PR #1. It would be nice if its reviewed and updated to the branch

Hi @pyalwin, I fixed the issue on a fork:
https://github.com/juanelojga/crudl
It's for the new version of crudl.


Do not release internal modules

Diktat has two internal modules: diktat-ksp-dev and diktat-common-test. They are not needed in maven central
Also, diktat builds gradle plugin, rulesset for ktlint and cli as fat jar. We can publish only them without internal apis which are not needed anyone in maven central.

Probably it's not required, we have GitHub releases where they are attached as assets. Also there we attach script for Windows


Dropped VS node goes to the visual scripting board's center instead of mouse cursor position

Linux Mint 64bit MATE 17.3
Godot version: 2.2 alpha (Aug 14th) 3db36684b183adbec93cce9fe91182186e389e06
When I drag from the "Available Nodes:" section and release my mouse, the visual node appears under my cursor, but as soon as I move it, it goes to the center of the board. This is unexpected behavior as it should follow directly under the cursor instead of going off screen as soon as it's movable.
Video: https://www.youtube.com/watch?v=jUHMtXavsmA

closing, seems fixed.

Thanks!


Cannot set upstream dhcpv4 options for authentication with ISP

My ISP (Sky, UK), uses dhcpv4 options 60 and 61 as part of its authentication and configuration management (it uses ClientId to authenticate the endpoint and the Vendor Class value to identify the firmware version).
I've not managed to find how to set these parameters for hnetd.
Even if I hard-code suitable values in hnetd/src/platform-openwrt.c's handle_restart_dhcp, there are duplicate Vendor Class parameters as udhcpc adds its own.
It's likely that I'm taking the wrong approach, but if not, I'm happy to lobby udhcpc to fix what looks like a known issue.
With a bit of support, I could even create a patch to set the parameters.

the 'hnet' proto supports setting client id already (see openwrt/hnet.sh - dhcpv4_clientid and dhcpv6_clientid options ) ; it basically just sets parameters to the underlying dhcp proto. I am not sure if underlying dhcp proto supports setting vendor class, but if it does, you could add that similarly.
Otherwise you could just edit the dhcp proto handler by hand (it is a shell script, which invokes udhcpc).

I couldn't see how the dhcp protocol handler was invoked by hnet. I did find a note to the effect that mixing dhcp and hnet on the same interface in /etc/config/network could cause a mess, so I assumed that it wasn't

src/platform-openwrt.c / handle_restart_dhcp creates dynamic sub-interface with hnet proto for the interface, and passes along that clientid for ipv6. ipv4 for some reason seems not to be handled :-p
The option 0x4d it sets up in the sendopts is the 'homenet' text for dhcp. Something similar could be done with client/vendor id.
(Apparently DHCPv4 client id code is partially done, and hnet.sh does not pass it along - DHCPv6 does seem to work. )

lol. I've just about managed to reverse engineer some of that, although it's not at all clear to me how to find out how the various bits fit together. 0x4d is even more weird in that it's a length/string structure. Presumably the other types are delimited some other way. I'll see if I can code up the parameters directly into the dhcp.sh

fwiw, the fact that udhcpc handles some parameters by name (e.g. clientid, vendorclass) but does not check that the relevant parameters have been passed in sendopts seems to create the confusion. Also, I seemed to get different behaviour depending on the order in which I encoded the parameters as space separated key:value pairs :-(

Suggestion works. Thanks, I can now reproduce the tcpdump from my sky box using openwrt.

fwiw, the dhcpv4_clientid didn’t work for me. could be finger trouble as it’s v. hard to work out what’s supposed to happen.

On 2 Oct 2016, at 17:31, Markus Stenberg<EMAIL_ADDRESS>wrote:
the 'hnet' proto supports setting client id already (see openwrt/hnet.sh - dhcpv4_clientid and dhcpv6_clientid options ) ; it basically just sets parameters to the underlying dhcp proto. I am not sure if underlying dhcp proto supports setting vendor class, but if it does, you could add that similarly.
Otherwise you could just edit the dhcp proto handler by hand (it is a shell script, which invokes udhcpc).
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub https://github.com/sbyx/hnetd/issues/61#issuecomment-250980333, or mute the thread https://github.com/notifications/unsubscribe-auth/AAFk4MQIMbxzDX85cS_-oxGI-0_7X6kPks5qv9x0gaJpZM4KMDIt.


Update Search-AdminAuditLog.md

"Unlimited" does throw an error when attempted to use.
Per source code we limit the number of results to 250k.

:white_check_mark: Validation status: passed

File
Status
Preview URL
Details

exchange/exchange-ps/exchange/policy-and-compliance-audit/Search-AdminAuditLog.md
:white_check_mark:Succeeded
View (exchange-ps)

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.

:white_check_mark: Validation status: passed

File
Status
Preview URL
Details

exchange/exchange-ps/exchange/policy-and-compliance-audit/Search-AdminAuditLog.md
:white_check_mark:Succeeded
View (exchange-ps)

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.


No feedback after Approve & Submit

Type: Bug
I just approved a PR in vscode. After hitting Approve and Submit the Leave a comment empties as only feedback. I was confused for a bit and had to double-check if it worked.
Should I be able to, to approve multiple times?
Maybe the description can open to show the latest comment and PR state?
Extension version: 0.49.2022082209
VS Code version: Code - Insiders 1.71.0-insider (235a92a3693176fbf9af16ec5b829c458a1d682f, 2022-08-22T05:17:16.753Z)
OS version: Darwin x64 21.6.0
Modes:
Sandboxed: No

Yes, github.com allows you to approve multiple times. I'll see what I can add to the focus view to make it clearer that your approve went through.

You should see your username and a checkmark after you approve and submit:

Do you not see this?

@alexr00 sorry for the delay. I just tried this out again and it does feel very hidden. One idea would be to open (focus) the PR description, as this has a much large area for completed reviews?
Maybe there are ways that we can add to our UX toolbox to highlight subtle changes in smaller UI elements like icons (cc @daviddossett)

I'd prefer to add further emphasis to the focus view rather than open the full PR description. As a user of the view myself, I don't want the whole description editor open when all I need to do is approve the PR. I'm interested in @daviddossett input on this as well!

I'll take a look at this next week—bit backed up at the moment after being OOF.

No rush, I put this in the October Milestone!

Adding on to this, currently if there's multiple reviewers on a PR it's possible your name / 'approval status' is hidden without scrolling

Coming back to this now, I think this is another good candidate for https://github.com/microsoft/vscode/issues/166891
In the meantime, would it make sense to match the colors used in the PR list here @alexr00? The icon would probably jump out more than it does now.

👍 colors added with https://github.com/microsoft/vscode-pull-request-github/pull/4329

Closing as we have colors in addition to the symbols.


simplify marshal/ummarshal logic, make parser stricter, update tests, fix readme

Great code change indeed thanks


Text is slightly off on several components

This is visible in snapshot:

I can't find any differences in the css, or visually looking at them side by side, so I'm going to close this.


Fix ssh keys being removed at login time

Description
The copy-paste phenomenon made the manager key for the tenant update query that happens at login to match the one used during ssh keys update. This made ssh keys being deleted when the user first opened the dashboard (while setting the new lastLogin value).

/deploy-staging

/deploy-staging

/deploy-staging

/merge


Add arm64v8 image

adding arm64v8 support would be great!

I installed successfully k3s on arm64 with weave Net overlay network on a RockPro64 cluster
and made my own private local-path-provisioner arm64v8 instance using Alpine Linux instead of Ubuntu:18.04. Alpine Linux image size is 84Mi, testing was successful.
$ uname -a
Linux <server> 4.4.167-1161-rockchip-ayufan-g6f1664023387 #1 SMP Fri Mar 22 23:03:38 UTC 2019 aarch64 aarch64 aarch64 GNU/Linux
<user>@<server>:<home-dir>$ k get all -n local-path-storage
NAME                                          READY   STATUS    RESTARTS   AGE
pod/local-path-provisioner-6868fbd6c6-nvjk5   1/1     Running   0          22m

NAME                                     READY   UP-TO-DATE   AVAILABLE   AGE
deployment.apps/local-path-provisioner   1/1     1            1           22m

NAME                                                DESIRED   CURRENT   READY   AGE
replicaset.apps/local-path-provisioner-6868fbd6c6   1         1         1       22m

IMHO alpine linux reduce the footprint even further.
Should I make a PR using Alpine Linux?

@giminni Sure, that would be great!
Though I don't have a setup to test arm64, so I would be unable to fix if there is anything wrong with Arm. But I am OK on accepting a PR for arm64 as long as there is no impact on running with x86.

@giminni we switched to Alpine in #13 , I think adding arm64/multi-arch support can build off that potentially?

have any arm images been pushed anywhere?

Can anyone try @km4rcus 's image? The build has been merged to master as well.

@yasker can you initiate a build to docker hub?

I haven't tried that specific build but I did build it for arm myself and it is working

v0.0.8 released and the image pushed. Let me know if it works.

@yasker I don't see any multi-arch image tags on docker hub and also no manifest to support multi-arch

@vchrisb sorry, not familiar with multi arch build. Let me check what should I do for an arm image.

https://github.com/prometheus/prometheus/pull/5031 may have a useful example of "what to do" re: multi-arch

@yasker , please take a look at
https://github.com/rancher/dapper/blob/master/scripts/build
for a rancher-approved dapper-style example.

arm image seems to be missing as well, this is what I got on a raspberry pi:
kubectl logs -n local-path-storage pod/local-path-provisioner-69fc9568b9-vg4m2                             standard_init_linux.go:211: exec user process caused "exec format error"

@yasker please take a look at #24 , thanks!

@tamsky Thanks for the help! I will check it.

Can we /reopen this ticket as it is still waiting for #24 to be merged?

Multiarch supported in v0.0.11 release.
https://github.com/rancher/local-path-provisioner/releases/tag/v0.0.11


protocol sporadically stalls after buyproceduresignature

Protocol sporadically stalls after buyproceduresignature is sent by Bob.
Whenever it stalls, Alice's monero syncer has multiple tasks related to the same address (reflected by the Event details: ... and xmr_locked was already set to true messages in Alice's log).
This log is from #158, but it's also happened when testing over-the-wire with https://github.com/Lederstrumpf/farcaster-node/tree/debug_shared_view_key and https://github.com/Lederstrumpf/farcaster-node/tree/monero_sweep0_partial too (haven't tested on other branches since getting until this issue requires a correct aggregation of view key shares).
Extract Alice's log:
[2021-11-03T14:32:04Z INFO  farcaster_node::service] farcasterd started
[2021-11-03T14:32:05Z INFO  farcaster_node::service] walletd started
[2021-11-03T14:32:05Z INFO  farcaster_node::farcasterd::runtime] walletd daemon is connected
[2021-11-03T14:32:15Z INFO  farcaster_node::farcasterd::runtime] Starting listener for incoming LN peer connections on <IP_ADDRESS>:9735
[2021-11-03T14:32:15Z INFO  farcaster_node::farcasterd::runtime] New instance of peerd launched with PID 5087
[2021-11-03T14:32:15Z INFO  farcaster_node::farcasterd::runtime] Connection daemon listens for incoming LN peer connections on <IP_ADDRESS>:9735
[2021-11-03T14:32:15Z INFO  farcaster_node::farcasterd::runtime] Maker: Public offer registered 0x69f5…9971
peerd: lightning peer network connection microservice
[2021-11-03T14:32:15Z INFO  peerd] Local node id: 03ca93477c8b136e579c41365eff8f16f3d455b8514c39f5efc94aea1905ee686c
[2021-11-03T14:32:24Z INFO  farcaster_node::service] peerd<03ca93477c8b136e579c41365eff8f16f3d455b8514c39f5efc94aea1905ee686c@<IP_ADDRESS>:9735> started
[2021-11-03T14:32:24Z INFO  farcaster_node::farcasterd::runtime] peerd<03ca93477c8b136e579c41365eff8f16f3d455b8514c39f5efc94aea1905ee686c@<IP_ADDRESS>:9735> daemon is connected
[2021-11-03T14:32:24Z INFO  farcaster_node::farcasterd::runtime] Connection 03ca93477c8b136e579c41365eff8f16f3d455b8514c39f5efc94aea1905ee686c@<IP_ADDRESS>:9735 is registered; total 1 connections are known
[2021-11-03T14:32:30Z INFO  farcaster_node::walletd::runtime] Loading Wallet::Alice
[2021-11-03T14:32:30Z INFO  farcaster_node::farcasterd::runtime] New instance of swapd launched with PID 5092
swapd: farcaster swap microservice
[2021-11-03T14:32:30Z INFO  farcaster_node::swapd::runtime] Initial state: AliceState(Start)
[2021-11-03T14:32:31Z INFO  farcaster_node::service] swap<0xaa91271ac17db80c785be9f0729eb4cb6ccee04b6818c1feeaccec193e295b54> started
[2021-11-03T14:32:31Z INFO  farcaster_node::farcasterd::runtime] swap<0xaa91271ac17db80c785be9f0729eb4cb6ccee04b6818c1feeaccec193e295b54> daemon is connected
[2021-11-03T14:32:31Z INFO  farcaster_node::farcasterd::runtime] Swap 0xaa91…5b54 is registered; total 1 swaps are known
[2021-11-03T14:32:31Z ERROR microservices::esb::controller] ESB request processing error: transport-level protocol error: service is offline or not responding
[2021-11-03T14:32:31Z INFO  farcaster_node::swapd::runtime] Accepting swap as Maker with swap id 0xaa91…5b54 from Taker remote peer peerd<03ca93477c8b136e579c41365eff8f16f3d455b8514c39f5efc94aea1905ee686c@<IP_ADDRESS>:9735>
[2021-11-03T14:32:31Z INFO  farcaster_node::swapd::runtime] Making swap 0xaa91…5b54 from remote peer Taker peerd<03ca93477c8b136e579c41365eff8f16f3d455b8514c39f5efc94aea1905ee686c@<IP_ADDRESS>:9735>
syncerd: blockchain tasks management microservice
[2021-11-03T14:32:32Z INFO  farcaster_node::syncerd::runtime] Creating new monero syncer
syncerd: blockchain tasks management microservice
[2021-11-03T14:32:32Z INFO  farcaster_node::syncerd::runtime] Creating new bitcoin syncer
[2021-11-03T14:32:32Z INFO  farcaster_node::syncerd::bitcoin_syncer] New ElectrumRpc at height 2102371
[2021-11-03T14:32:32Z INFO  farcaster_node::syncerd::bitcoin_syncer] New ElectrumRpc at height 2102371
[2021-11-03T14:32:32Z INFO  farcaster_node::syncerd::bitcoin_syncer] New ElectrumRpc at height 2102371
[2021-11-03T14:32:32Z INFO  farcaster_node::swapd::runtime] Alice: forwarding reveal
[2021-11-03T14:32:32Z INFO  farcaster_node::swapd::runtime] Alice sets remote_params
[2021-11-03T14:32:33Z INFO  farcaster_node::service] syncer<Monero> started
[2021-11-03T14:32:33Z INFO  farcaster_node::farcasterd::runtime] syncer<Monero> daemon is connected
[2021-11-03T14:32:33Z INFO  farcaster_node::service] syncer<Bitcoin> started
[2021-11-03T14:32:33Z INFO  farcaster_node::farcasterd::runtime] syncer<Bitcoin> daemon is connected
[2021-11-03T14:32:33Z INFO  farcaster_node::swapd::runtime] Bitcoin new height 2102371
[2021-11-03T14:32:34Z INFO  farcaster_node::swapd::runtime] Monero new height 956827
[2021-11-03T14:32:38Z INFO  farcaster_node::swapd::runtime] Monero new height 956828
[2021-11-03T14:32:41Z INFO  farcaster_node::swapd::runtime] Watching tx Lock 85c036be97558a391e343f1df2b7ecfbad45c1aff878fa68da21a8df80a3d8a3
[2021-11-03T14:32:41Z INFO  farcaster_node::swapd::runtime] Watching tx Cancel e6e0ab3e1bc8731d6577b7c45f8898587a24bdf9c2dbd0636c36994e0b6953c1
[2021-11-03T14:32:41Z INFO  farcaster_node::swapd::runtime] Watching tx Refund 774221ac2401772ba417adf9e7353accd2a8b3f448f7a8f1a493e270ad4eb7f9
[2021-11-03T14:32:41Z INFO  farcaster_node::swapd::runtime] received tx Punish from walletd
[2021-11-03T14:32:52Z INFO  farcaster_node::swapd::runtime] tx Cancel not on the mempool
[2021-11-03T14:32:52Z INFO  farcaster_node::swapd::runtime] tx Refund not on the mempool
[2021-11-03T14:32:52Z INFO  farcaster_node::swapd::runtime] tx Lock not on the mempool
[2021-11-03T14:33:02Z INFO  farcaster_node::swapd::runtime] tx Lock on mempool but hasn't been mined
[2021-11-03T14:33:02Z INFO  farcaster_node::swapd::runtime] tx Lock final: 0 confirmations
[2021-11-03T14:33:02Z INFO  farcaster_node::swapd::runtime] Alice, please send 0.000000010000 XMR to 57aRARGYK7VT3TQrYe859SPbb1qbcjmFMRuLgJYYJ3DfWdU8NxffqxZZU3WziE93QBcusta5ZVoPXH2SAfz6vnHFAavwHpW
[2021-11-03T14:33:02Z INFO  farcaster_node::swapd::runtime] Matched Alice
[2021-11-03T14:33:02Z INFO  farcaster_node::swapd::runtime] XMR view key: aadb490e2e5cdc969c32e902a9248f612ae23669af156f913c4d318a85a99901
[2021-11-03T14:33:02Z INFO  farcaster_node::swapd::runtime] XMR spend key: 84d3fc1c0bcaac74853adc251ab3bc8e04db56a681f53dd04dd4e1fdfdb6e89d
[2021-11-03T14:33:02Z INFO  farcaster_node::swapd::runtime] Alice, please send 0.000000010000 XMR to 56s6KsMm8dhLVPrqQRY55DQkmC87Fsi4UbqoyuTunAYPTRQDXFYUwFrXG3Kgru3m5e2CuTf9gubWUNSQVXnBXKXBC9FWVRD
[2021-11-03T14:33:02Z INFO  farcaster_node::swapd::runtime] Watching address AccLock 56s6KsMm8dhLVPrqQRY55DQkmC87Fsi4UbqoyuTunAYPTRQDXFYUwFrXG3Kgru3m5e2CuTf9gubWUNSQVXnBXKXBC9FWVRD
[2021-11-03T14:33:05Z WARN  farcaster_node::syncerd::monero_syncer] wallet doesn't exist, generating a new wallet: Server error: Failed to open wallet
[2021-11-03T14:33:19Z INFO  farcaster_node::swapd::runtime] Watching tx Buy eed9fce007a301aee299087e93bb83e0de818ecb578e844b1a95b042f0efc41f
[2021-11-03T14:33:19Z INFO  farcaster_node::swapd::runtime] received tx Cancel from walletd
[2021-11-03T14:33:19Z INFO  farcaster_node::swapd::runtime] tx Lock on mempool but hasn't been mined
[2021-11-03T14:33:19Z INFO  farcaster_node::swapd::runtime] tx Lock final: 0 confirmations
[2021-11-03T14:33:19Z INFO  farcaster_node::swapd::runtime] Alice, please send 0.000000010000 XMR to 57aRARGYK7VT3TQrYe859SPbb1qbcjmFMRuLgJYYJ3DfWdU8NxffqxZZU3WziE93QBcusta5ZVoPXH2SAfz6vnHFAavwHpW
[2021-11-03T14:33:19Z INFO  farcaster_node::swapd::runtime] Matched Alice
[2021-11-03T14:33:19Z INFO  farcaster_node::swapd::runtime] XMR view key: aadb490e2e5cdc969c32e902a9248f612ae23669af156f913c4d318a85a99901
[2021-11-03T14:33:19Z INFO  farcaster_node::swapd::runtime] XMR spend key: 84d3fc1c0bcaac74853adc251ab3bc8e04db56a681f53dd04dd4e1fdfdb6e89d
[2021-11-03T14:33:19Z INFO  farcaster_node::swapd::runtime] Alice, please send 0.000000010000 XMR to 56s6KsMm8dhLVPrqQRY55DQkmC87Fsi4UbqoyuTunAYPTRQDXFYUwFrXG3Kgru3m5e2CuTf9gubWUNSQVXnBXKXBC9FWVRD
[2021-11-03T14:33:19Z INFO  farcaster_node::swapd::runtime] Watching address AccLock 56s6KsMm8dhLVPrqQRY55DQkmC87Fsi4UbqoyuTunAYPTRQDXFYUwFrXG3Kgru3m5e2CuTf9gubWUNSQVXnBXKXBC9FWVRD
[2021-11-03T14:33:19Z INFO  farcaster_node::swapd::runtime] received tx Buy from walletd
[2021-11-03T14:33:19Z INFO  farcaster_node::swapd::runtime] tx Lock on mempool but hasn't been mined
[2021-11-03T14:33:19Z INFO  farcaster_node::swapd::runtime] tx Lock final: 0 confirmations
[2021-11-03T14:33:19Z INFO  farcaster_node::swapd::runtime] Alice, please send 0.000000010000 XMR to 57aRARGYK7VT3TQrYe859SPbb1qbcjmFMRuLgJYYJ3DfWdU8NxffqxZZU3WziE93QBcusta5ZVoPXH2SAfz6vnHFAavwHpW
[2021-11-03T14:33:19Z INFO  farcaster_node::swapd::runtime] Matched Alice
[2021-11-03T14:33:19Z INFO  farcaster_node::swapd::runtime] XMR view key: aadb490e2e5cdc969c32e902a9248f612ae23669af156f913c4d318a85a99901
[2021-11-03T14:33:19Z INFO  farcaster_node::swapd::runtime] XMR spend key: 84d3fc1c0bcaac74853adc251ab3bc8e04db56a681f53dd04dd4e1fdfdb6e89d
[2021-11-03T14:33:19Z INFO  farcaster_node::swapd::runtime] Alice, please send 0.000000010000 XMR to 56s6KsMm8dhLVPrqQRY55DQkmC87Fsi4UbqoyuTunAYPTRQDXFYUwFrXG3Kgru3m5e2CuTf9gubWUNSQVXnBXKXBC9FWVRD
[2021-11-03T14:33:19Z INFO  farcaster_node::swapd::runtime] Watching address AccLock 56s6KsMm8dhLVPrqQRY55DQkmC87Fsi4UbqoyuTunAYPTRQDXFYUwFrXG3Kgru3m5e2CuTf9gubWUNSQVXnBXKXBC9FWVRD
[2021-11-03T14:33:20Z INFO  farcaster_node::syncerd::syncer_state] new_tx seen: 7efd5fca0387561de80dea0de385911d8a559b1c72acbbd83ab196d0bcb3b2b0
[2021-11-03T14:33:20Z INFO  farcaster_node::syncerd::syncer_state] new_tx seen: 7efd5fca0387561de80dea0de385911d8a559b1c72acbbd83ab196d0bcb3b2b0
[2021-11-03T14:33:20Z INFO  farcaster_node::swapd::runtime] Event details: 8 [176, 178, 179, 188, 208, 150, 177, 58, 216, 187, 172, 114, 28, 155, 85, 138, 29, 145, 133, 227, 13, 234, 13, 232, 29, 86, 135, 3, 202, 95, 253, 126]<PHONE_NUMBER>0000 [] [0]
[2021-11-03T14:33:20Z WARN  farcaster_node::swapd::runtime] setting xmr_locked
[2021-11-03T14:33:20Z INFO  farcaster_node::swapd::runtime] Watching tx AccLock b0b2b3bcd096b13ad8bbac721c9b558a1d9185e30dea0de81d568703ca5ffd7e
[2021-11-03T14:33:20Z INFO  farcaster_node::swapd::runtime] Event details: 6 [176, 178, 179, 188, 208, 150, 177, 58, 216, 187, 172, 114, 28, 155, 85, 138, 29, 145, 133, 227, 13, 234, 13, 232, 29, 86, 135, 3, 202, 95, 253, 126]<PHONE_NUMBER>0000 [] [0]
[2021-11-03T14:33:20Z WARN  farcaster_node::swapd::runtime] xmr_locked was already set to true
[2021-11-03T14:33:20Z INFO  farcaster_node::swapd::runtime] Watching tx AccLock b0b2b3bcd096b13ad8bbac721c9b558a1d9185e30dea0de81d568703ca5ffd7e
[2021-11-03T14:33:22Z INFO  farcaster_node::swapd::runtime] tx Buy not on the mempool
[2021-11-03T14:33:23Z INFO  farcaster_node::swapd::runtime] tx AccLock on mempool but hasn't been mined
[2021-11-03T14:33:23Z INFO  farcaster_node::syncerd::syncer_state] new_tx seen: 7efd5fca0387561de80dea0de385911d8a559b1c72acbbd83ab196d0bcb3b2b0
[2021-11-03T14:33:23Z INFO  farcaster_node::swapd::runtime] Event details: 9 [176, 178, 179, 188, 208, 150, 177, 58, 216, 187, 172, 114, 28, 155, 85, 138, 29, 145, 133, 227, 13, 234, 13, 232, 29, 86, 135, 3, 202, 95, 253, 126]<PHONE_NUMBER>0000 [] [0]
[2021-11-03T14:33:23Z WARN  farcaster_node::swapd::runtime] xmr_locked was already set to true
[2021-11-03T14:33:23Z INFO  farcaster_node::swapd::runtime] Watching tx AccLock b0b2b3bcd096b13ad8bbac721c9b558a1d9185e30dea0de81d568703ca5ffd7e
[2021-11-03T14:33:24Z INFO  farcaster_node::swapd::runtime] tx AccLock on mempool but hasn't been mined
[2021-11-03T14:33:25Z INFO  farcaster_node::swapd::runtime] tx AccLock on mempool but hasn't been mined
[2021-11-03T14:34:57Z INFO  farcaster_node::swapd::runtime] Monero new height 956829
[2021-11-03T14:34:58Z INFO  farcaster_node::swapd::runtime] tx AccLock mined with 1 confirmations
[2021-11-03T14:34:58Z INFO  farcaster_node::swapd::runtime] tx AccLock mined with 1 confirmations
[2021-11-03T14:34:58Z INFO  farcaster_node::swapd::runtime] tx AccLock mined with 1 confirmations
[2021-11-03T14:35:20Z INFO  farcaster_node::swapd::runtime] Monero new height 956830

Extract Bob's log:
[2021-11-03T14:32:03Z INFO  farcaster_node::service] farcasterd started
[2021-11-03T14:32:04Z INFO  farcaster_node::service] walletd started
[2021-11-03T14:32:04Z INFO  farcaster_node::farcasterd::runtime] walletd daemon is connected
[2021-11-03T14:32:22Z INFO  farcaster_node::farcasterd::runtime] client<17112696337254950198> daemon is connected
peerd: lightning peer network connection microservice
[2021-11-03T14:32:23Z INFO  peerd] Local node id: 0258bb74c5803422f8d58e41cf177ecc899c2a5070ab711150a1480700816839d5
[2021-11-03T14:32:23Z INFO  peerd] Connecting to 03ca93477c8b136e579c41365eff8f16f3d455b8514c39f5efc94aea1905ee686c@<IP_ADDRESS>:9735
[2021-11-03T14:32:24Z INFO  farcaster_node::farcasterd::runtime] New instance of peerd launched with PID 1196551
[2021-11-03T14:32:24Z INFO  farcaster_node::farcasterd::runtime] Public offer registered: 0x69f5…9971
[2021-11-03T14:32:24Z INFO  farcaster_node::service] peerd<03ca93477c8b136e579c41365eff8f16f3d455b8514c39f5efc94aea1905ee686c@<IP_ADDRESS>:9735> started
[2021-11-03T14:32:24Z INFO  farcaster_node::peerd::runtime] Initializing connection with the remote peer
[2021-11-03T14:32:24Z INFO  farcaster_node::farcasterd::runtime] peerd<03ca93477c8b136e579c41365eff8f16f3d455b8514c39f5efc94aea1905ee686c@<IP_ADDRESS>:9735> daemon is connected
[2021-11-03T14:32:24Z INFO  farcaster_node::farcasterd::runtime] Connection 03ca93477c8b136e579c41365eff8f16f3d455b8514c39f5efc94aea1905ee686c@<IP_ADDRESS>:9735 is registered; total 1 connections are known
[2021-11-03T14:32:24Z ERROR microservices::esb::controller] ESB request processing error: transport-level protocol error: service is offline or not responding
[2021-11-03T14:32:28Z INFO  farcaster_node::walletd::runtime] Send 1500 sats to address: tb1qenzzteqgw5acwe0cltjaae8vvye0jgmyl6xaqy
[2021-11-03T14:32:28Z INFO  farcaster_node::walletd::runtime] Loading Wallet::Bob
[2021-11-03T14:32:28Z INFO  farcaster_node::farcasterd::runtime] New instance of swapd launched with PID 1196573
swapd: farcaster swap microservice
[2021-11-03T14:32:28Z INFO  farcaster_node::swapd::runtime] Initial state: BobState(Start)
[2021-11-03T14:32:29Z INFO  farcaster_node::service] swap<0xaa91271ac17db80c785be9f0729eb4cb6ccee04b6818c1feeaccec193e295b54> started
[2021-11-03T14:32:29Z INFO  farcaster_node::farcasterd::runtime] swap<0xaa91271ac17db80c785be9f0729eb4cb6ccee04b6818c1feeaccec193e295b54> daemon is connected
[2021-11-03T14:32:29Z INFO  farcaster_node::farcasterd::runtime] Swap 0xaa91…5b54 is registered; total 1 swaps are known
[2021-11-03T14:32:29Z ERROR microservices::esb::controller] ESB request processing error: transport-level protocol error: service is offline or not responding
[2021-11-03T14:32:29Z INFO  farcaster_node::swapd::runtime] Proposing to the Maker that I take the swap offer with id 0xaa91…5b54
syncerd: blockchain tasks management microservice
syncerd: blockchain tasks management microservice
[2021-11-03T14:32:29Z INFO  farcaster_node::syncerd::runtime] Creating new bitcoin syncer
[2021-11-03T14:32:29Z INFO  farcaster_node::syncerd::runtime] Creating new monero syncer
[2021-11-03T14:32:29Z INFO  farcaster_node::syncerd::bitcoin_syncer] New ElectrumRpc at height 2102371
[2021-11-03T14:32:29Z INFO  farcaster_node::syncerd::bitcoin_syncer] New ElectrumRpc at height 2102371
[2021-11-03T14:32:29Z INFO  farcaster_node::syncerd::bitcoin_syncer] New ElectrumRpc at height 2102371
[2021-11-03T14:32:30Z INFO  farcaster_node::service] syncer<Bitcoin> started
[2021-11-03T14:32:30Z INFO  farcaster_node::service] syncer<Monero> started
[2021-11-03T14:32:30Z INFO  farcaster_node::farcasterd::runtime] syncer<Bitcoin> daemon is connected
[2021-11-03T14:32:30Z INFO  farcaster_node::farcasterd::runtime] syncer<Monero> daemon is connected
[2021-11-03T14:32:31Z INFO  farcaster_node::swapd::runtime] Watching Funding address with Script(OP_0 OP_PUSHBYTES_20 ccc425e408753b8765f8fae5dee4ec6132f92364)
[2021-11-03T14:32:32Z INFO  farcaster_node::syncerd::bitcoin_syncer] registering address BtcAddressAddendum { address: None, from_height: 0, script_pubkey: Script(OP_0 OP_PUSHBYTES_20 ccc425e408753b8765f8fae5dee4ec6132f92364) } with script_status None
[2021-11-03T14:32:32Z INFO  farcaster_node::swapd::runtime] Monero new height 956827
[2021-11-03T14:32:33Z INFO  farcaster_node::swapd::runtime] Bob sets remote_params
[2021-11-03T14:32:33Z INFO  farcaster_node::swapd::runtime] Bitcoin new height 2102371
[2021-11-03T14:32:37Z INFO  farcaster_node::swapd::runtime] Monero new height 956828
[2021-11-03T14:32:38Z INFO  farcaster_node::syncerd::syncer_state] new_tx seen: b0c3523e14aa0ad2ef5d7110102539f92ece8c34804abe6afdb01d5938429c74
[2021-11-03T14:32:38Z INFO  farcaster_node::swapd::runtime] Funding tx in mempool or blockchain, sending it to wallet: b0c3523e14aa0ad2ef5d7110102539f92ece8c34804abe6afdb01d5938429c74
[2021-11-03T14:32:38Z INFO  farcaster_node::walletd::runtime] bob's wallet informs swapd that funding was successfully updated
[2021-11-03T14:32:41Z INFO  farcaster_node::swapd::runtime] Watching tx Lock 85c036be97558a391e343f1df2b7ecfbad45c1aff878fa68da21a8df80a3d8a3
[2021-11-03T14:32:41Z INFO  farcaster_node::swapd::runtime] Watching tx Cancel e6e0ab3e1bc8731d6577b7c45f8898587a24bdf9c2dbd0636c36994e0b6953c1
[2021-11-03T14:32:41Z INFO  farcaster_node::swapd::runtime] Watching tx Refund 774221ac2401772ba417adf9e7353accd2a8b3f448f7a8f1a493e270ad4eb7f9
[2021-11-03T14:32:41Z INFO  farcaster_node::swapd::runtime] received Lock
[2021-11-03T14:32:41Z INFO  farcaster_node::swapd::runtime] Broadcasting Lock tx 85c036be97558a391e343f1df2b7ecfbad45c1aff878fa68da21a8df80a3d8a3
[2021-11-03T14:32:41Z INFO  farcaster_node::swapd::runtime] Matched Bob
[2021-11-03T14:32:41Z INFO  farcaster_node::swapd::runtime] XMR view key: aadb490e2e5cdc969c32e902a9248f612ae23669af156f913c4d318a85a99901
[2021-11-03T14:32:41Z INFO  farcaster_node::swapd::runtime] XMR spend key: 84d3fc1c0bcaac74853adc251ab3bc8e04db56a681f53dd04dd4e1fdfdb6e89d
[2021-11-03T14:32:41Z INFO  farcaster_node::swapd::runtime] Watching address AccLock 56s6KsMm8dhLVPrqQRY55DQkmC87Fsi4UbqoyuTunAYPTRQDXFYUwFrXG3Kgru3m5e2CuTf9gubWUNSQVXnBXKXBC9FWVRD
[2021-11-03T14:32:41Z INFO  farcaster_node::swapd::runtime] Watching tx Buy eed9fce007a301aee299087e93bb83e0de818ecb578e844b1a95b042f0efc41f
[2021-11-03T14:32:41Z INFO  farcaster_node::swapd::runtime] Watching Buy address with Script(OP_0 OP_PUSHBYTES_20 de2dcadd71582915b1bfa5e4f88fb20b6cdeadb5)
[2021-11-03T14:32:41Z INFO  farcaster_node::swapd::runtime] received tx Cancel from walletd
[2021-11-03T14:32:41Z INFO  farcaster_node::swapd::runtime] received tx Refund from walletd
[2021-11-03T14:32:44Z WARN  farcaster_node::syncerd::monero_syncer] wallet doesn't exist, generating a new wallet: Server error: Failed to open wallet
[2021-11-03T14:32:44Z INFO  farcaster_node::syncerd::bitcoin_syncer] successfully broadcasted tx 85c036be97558a391e343f1df2b7ecfbad45c1aff878fa68da21a8df80a3d8a3
[2021-11-03T14:32:46Z INFO  farcaster_node::syncerd::bitcoin_syncer] registering address BtcAddressAddendum { address: None, from_height: 2102321, script_pubkey: Script(OP_0 OP_PUSHBYTES_20 de2dcadd71582915b1bfa5e4f88fb20b6cdeadb5) } with script_status None
[2021-11-03T14:32:46Z INFO  farcaster_node::syncerd::syncer_state] new_tx seen: 43e85925430868b68caf2aab5f6597e8ee14cb9b4bd30c1c325aa343eecb9b99
[2021-11-03T14:32:46Z INFO  farcaster_node::syncerd::syncer_state] new_tx seen: b59319d2abf4d8e835b4e1e78992d3fccf6c2e2a79143bd1c452e1f8e5f50503
...
TRUNCATED ADDRESS REUSE
...
[2021-11-03T14:32:47Z WARN  farcaster_node::swapd::runtime] expected BobState(BuySigB), found BobState(CoreArb). Any chance you reused the destination/refund address in the cli command? For your own privacy, do not reuse bitcoin addresses. Txid 9354313cc50814b64b391bdb48229c8ba377d823dc68c819762ad65b29967190
[2021-11-03T14:32:47Z WARN  farcaster_node::swapd::runtime] expected BobState(BuySigB), found BobState(CoreArb). Any chance you reused the destination/refund address in the cli command? For your own privacy, do not reuse bitcoin addresses. Txid 41f106eb87c82cfcafaeaf23e25c7938943278fd559a39c82c44ad44b7400975
[2021-11-03T14:32:47Z WARN  farcaster_node::swapd::runtime] expected BobState(BuySigB), found BobState(CoreArb). Any chance you reused the destination/refund address in the cli command? For your own privacy, do not reuse bitcoin addresses. Txid 9a49ef6dfee7a5b9ac080cf6852f4e7a48526da95f9a45289dcaaac69e96dd9e
[2021-11-03T14:32:49Z INFO  farcaster_node::swapd::runtime] tx Lock on mempool but hasn't been mined
[2021-11-03T14:32:49Z INFO  farcaster_node::swapd::runtime] tx Lock final: 0 confirmations
[2021-11-03T14:32:49Z INFO  farcaster_node::swapd::runtime] tx Buy not on the mempool
[2021-11-03T14:32:49Z INFO  farcaster_node::swapd::runtime] tx Refund not on the mempool
[2021-11-03T14:32:49Z INFO  farcaster_node::swapd::runtime] tx Cancel not on the mempool
[2021-11-03T14:33:17Z INFO  farcaster_node::syncerd::syncer_state] new_tx seen: 7efd5fca0387561de80dea0de385911d8a559b1c72acbbd83ab196d0bcb3b2b0
[2021-11-03T14:33:17Z INFO  farcaster_node::swapd::runtime] Watching tx AccLock b0b2b3bcd096b13ad8bbac721c9b558a1d9185e30dea0de81d568703ca5ffd7e
[2021-11-03T14:33:19Z INFO  farcaster_node::swapd::runtime] sending buyproceduresignature at state BobState(CoreArb)
[2021-11-03T14:34:57Z INFO  farcaster_node::swapd::runtime] Monero new height 956829
[2021-11-03T14:34:58Z INFO  farcaster_node::swapd::runtime] tx AccLock mined with 1 confirmations
[2021-11-03T14:35:21Z INFO  farcaster_node::swapd::runtime] Monero new height 956830
[2021-11-03T14:35:22Z INFO  farcaster_node::swapd::runtime] tx AccLock mined with 2 confirmations
[2021-11-03T14:35:28Z INFO  farcaster_node::swapd::runtime] Monero new height 956831
[2021-11-03T14:35:29Z INFO  farcaster_node::swapd::runtime] tx AccLock mined with 3 confirmations
[2021-11-03T14:38:41Z INFO  farcaster_node::swapd::runtime] Monero new height 956832
[2021-11-03T14:38:42Z INFO  farcaster_node::swapd::runtime] tx AccLock mined with 4 confirmations

Addressed in https://github.com/farcaster-project/farcaster-node/pull/158 , https://github.com/farcaster-project/farcaster-node/pull/158/commits/7760928da28c9efe51a3b60e31868b00aa08235a


TLF reidentification when needed related to rekey

Rekey ends up calling getMDLocked and thus we add an identity if we didn't have the md already locally in memory.

Thanks for doing this @taruti.  Is this intended to fix KBFS-1163?  I don't think it does -- it just moves the identify around to happening in folderBranchOps rather than KeyManagerStandard, but it still uses the same, possibly bogus, MD served up by the server.
What we really need is some what to verify that the TlfHandle associated with the MD is actually the one associated the the TlfID.  The parts of the MD that determine the TlfHandle can currently be forged by the server and so we need to somehow compare them to a handle provided by the user.  This is usually done by the fact that the user accessed the folder through a path including the set of users, but in the case of a rekey we don't have that option.
@akalin-keybase should take a look and chime in though, since he has thought about this issue more.

Rebased and fixed things.

@strib maybe you should take a quick look in case i missed something

Broken by changes in master, investigating.


[SILOptimizer] Don't diagnose infinite recursion if a block is noreturn

Blocks that end in unreachable or otherwise call into noreturn functions
shouldn't trip the infinite recursion diagnostic.

Can you also test an apply of a noreturn function?

@swift-ci please smoke test Linux platform

I smoke tested the wrong platform :cry:
@swift-ci please smoke test macOS platform

I'm not sure this is a good idea. You'll miss warning about cases like
func test(x: Int) {
  guard x > 0 else {
    fatalError("x must be positive")
  }
  test(x: x)
}

which, for all intents and purposes, is indeed infinitely recursive. (Sure, maybe I should be using precondition, but…)

It's worth noting that clang's recursion check, which this is based on, currently does this:

Though given the prevalence of guard in the language, we might not want to emulate clang.
I still think we should do this because it's otherwise a false positive.

We certainly don't want the false positive. I just don't know if "returns Never" is the right condition long-term.

@jrose-apple I wonder if we could special case 'fatalError inside a guard'. You're right that it's super unfortunate that we'd lose the case you brought up. Could (do?) we tag a block as being the body of a guard?

Eh, I don't know if we want to privilege guard in that way either. The example I wrote didn't use guard let and so someone could have easily written if. Maybe it's "fatalError as the only code in a block"?

There are 2 different cases here that are very similar, that both trip the warning.
enum MyNever {}

func blackHole() -> MyNever {
  blackHole()
}

func kaboom() -> MyNever {
  if Bool.random() {
    kaboom()
  }
  blackHole()
}

func kaboom2() -> MyNever {
  if Bool.random() {
    blackHole()
  }
  kaboom2()
}

I personally think neither kaboom nor kaboom2 should trip the warning, but I feel much stronger that kaboom should not trip the warning.

Taking a different approach.


Does this module work in the Server Only mode??

Hi
I am using magicmirror in a rpi 1b as a server and I am not able to run your module...
Does it work in the Server Only mode??
Thanks in advance
Alejandro

Hi
Yeah, it seems it can a problem related to the browser rather than a problem related to the server mode itself.
I have seen in https://github.com/lpage30/MMM-Webview (same module from another developer???) that the he points out that "The webviews rendered by this module in MagicMirror only render in the electron browser (used by MagicMirror). I have not been able to remotely render these views in Chrome or Firefox when 'browsing' to my MagicMirror server. Many online comments indicate that webview is also considered a potential security risk (which I've waived as I control my internal mirror)."
I am afraid I haven't found any solution for this issue in the MM2 forum...

The solution I can think of would be to render it non-server only and connect with x11vnc?


add unique version number to each build

When looking at a running cluster it is impossible to tell which revision of the pmem-csi driver is running. Let's build a unique version string into the binary with a -version flag (as in https://github.com/intel/oim/commit/e38285d4729b80c56c8107aa4e9f730658ade13b) and in addition, always print that when the driver runs (currently missing in OIM).

excellent point, must-to-have for tracking and clarity!
One question: driver currently already carries version information which is now hard-coded to "0.0.1", and used as response to "CSI identity plugin-info", here reported by driver in unified mode:
$ csc identity plugin-info
"pmem-csi"      "0.0.1"

But this information is not utilized in ways we consider useful for development, right?

shown in output/log when driver starts
recorded as part of csi-sanity output

Does the pointed OIM method create a parallel version tracking mechanism to plugin-info, or does it
overwrite the existing one, and if parallel, should we try to unify those two version records?

I was too pessimistic about "not utilized", plugin-info query is performed near end of make test_e2e  we run now (part of csi-sanity, right):
pmem-csi-unified-0/pmem-driver: Using default GetPluginInfo
pmem-csi-unified-0/pmem-driver: GRPC response: name:"pmem-csi" vendor_version:"0.0.1"

In OIM there is just one version, and GetPluginInfo reports that.

What is the plan or example of -version flag use (in running cluster, or overall)? Do I have to create/modify deployment file adding -version flag, deploy the container, and look to log files?
What is is the likelyhood anybody really doing that in practice? And what's the advantage of that compared to deployment without -version flag, in case we print the version always during start (what we should do).
My point is, if the only running method is deployment from registry, then cmd-line style -version flag is not so useful/easy to use, so is it worth the effort of adding it.
Is it enough to just add print of version in startup log of every component we have, and report same info via plugin-info API.
I think in real deployments, version gets fixed to some value via deployment file, so user/admin will not re-check it anyway (or does it from logs). That leaves development-time use for version string,
and that is also much better covered via log file use, or trace in csi-sanity report file.

@okartau  I implemented the versioning as make variable, by default it generates version from git.


Decompilation of [REDACTED].so.bc failed

I've sent an email to<EMAIL_ADDRESS>with a google drive link to the input file, the output files, and the file that contains the output of running the decompiler. Subject line is the same as this issue

Thank you for the report. From the output, retdec-llvmir2hll has failed in phase signed/unsigned types fixing. This might suggest that the reason is insufficient stack space (see #47, #64, #454, #465). I will try to reproduce the issue to confirm.

I was able to reproduce the issue. It is indeed caused by insufficient stack space. If you are on Linux, you can increase the maximal stack size via ulimit -Ss X, where X is the new size (you can also use ulimit -Ss unlimited to remove the limit entirely). After removing the stack limit, I was able to get through that phase.
I will leave the issue open for further future investigation why so much stack space is needed.

@s3rvac is there anything I can do for this on windows?

@TheElementalOfCreation On Windows, the stack size for an executable program is stored in the program. To change the size, you will have to edit the program. You can try using editbin.


dm: fix integration test in rocky8.9

What problem does this PR solve?

Issue Number: close https://github.com/pingcap/tiflow/issues/11752
What is changed and how it works?
Check List
Tests

Integration test
https://do.pingcap.net/jenkins/blue/organizations/jenkins/pingcap%2Ftiflow%2Fpull_dm_integration_test/detail/pull_dm_integration_test/3401/pipeline/

Questions
Will it cause performance regression or break compatibility?
Do you need to update user documentation, design documentation or monitoring documentation?
Release note
Please refer to [Release Notes Language Style Guide](https://pingcap.github.io/tidb-dev-guide/contribute-to-tidb/release-notes-style-guide.html) to write a quality release note.

If you don't think this PR needs a release note then fill it with `None`.

/ok-to-test

/retest
not relate fail

"Message": "startLocation: [position: (dm-it-d057503c-049a-4b78-8f1f-52dd03595422-b19zl-29htb-bin.000001, 42228), gtid-set: 013005f3-a328-11ef-a043-827aabe578a7:1-194], endLocation: [position: (dm-it-d057503c-049a-4b78-8f1f-52dd03595422-b19zl-29htb-bin.000001, 42353), gtid-set: 013005f3-a328-11ef-a043-827aabe578a7:1-195], origin SQL: [alter table shardddl1.tb1 add column b int after a]: fail to do etcd txn operation: txn commit failed",

/retest
not relate fail

mkdir /home/jenkins/agent/workspace/pingcap/tiflow/pull_dm_integration_test/mysql-ssl
cp -r /var/lib/mysql/.pem /home/jenkins/agent/workspace/pingcap/tiflow/pull_dm_integration_test/mysql-ssl/
cp: cannot stat '/var/lib/mysql/.pem': No such file or directory
script returned exit code 1

/test verify

/retest

/retest

/retest

/test dm-integration-test

/test cdc-integration-kafka-test dm-integration-test

/retest

/retest

/retest

/retest
flaky test