Add "Deployer" to available tools and option for linking SSH keys from host OS

ISSUE TYPE

Feature request

SUMMARY

Add Deployer (https://deployer.org/) to available tools, and add a possibility to link host system's SSH keys to container (needed by deployer to connect to remote hosts).

Have seen you added deployer, but how to bypass ssh keys from host system?

I am still thinking of a better solution.
As of now, you could add your ssh keys into bash/id_rsa directory and from within the container use it via ssh -i /etc/bashrc-devilbox.d/id_rsa

@carcade
The current idea is to extend the currently existing bash/ directory within the Devilbox git dir with the following structure:
bash/
    bash/       # <-- where you scripts to customize bash go
    ssh/         # <-- where you can put ssh keys

This way it is easier to further extend it with other stuff as requests come in.

@cytopia I really like the second idea.
@carcade Did you have any progress on this? I'm also using deployer

@carcade
The current idea is to extend the currently existing bash/ directory within the Devilbox git dir with the following structure:
bash/
    bash/       # <-- where you scripts to customize bash go
    ssh/        # <-- where you can put ssh keys

This way it is easier to further extend it with other stuff as requests come in.
Update
Second thought.
I could actually do a one-to-one mapping: Anything you put into bash/ will be added to the devilbox users home directory. So as an example:
bash/
    .config/nvim/init.vim
    .gitconfig
    .ssh/
        config
        id_rsa.pub
        id_rsa

This will then be available inside the PHP container by the same names in the devilbox home directory. That way you could add any configuration files and stuff you want.

Thanks for great support! But, unfortunately, i had switched from Devilbox to raw Apache + PHP installation.

@cytopia I really like the second idea.
@carcade Did you have any progress on this? I'm also using deployer

Hello. As I said, I had switched from Devilbox to raw Apache + PHP, and I'm using system installed deployer.

If that is all, you can close the issue. Thanks!

Is this feature enabled I have a use to setup ssh keys for authenticating with SVN

The above proposed directory structure is going to require some more heavy lifting on PHP-FPM images than initially thought.
But in order to make this possible for you, I have a quick-fix which should satisfy your need until this feature hits the master branch:
Add your ssh key into the bash/ directory and use the auto-start mechanism of the Devilbox to always copy (not move), this key to /home/devilbox/.ssh/. This allows all the magic happen automatically during docker-compose up/
See here for how to add custom autostart scripts: https://devilbox.readthedocs.io/en/latest/autostart/custom-scripts-globally.html

I found a way to use my local .ssh and .composer keys from my local linux home directory I just did the following in the docker-composer.yaml file

/home/.composer:/home/devilbox/.composer:rw${MOUNT_OPTIONS}

In this way the docker image can see my ssh keys and use them as they are mount under /home/devilbox/ folder
Not sure if this helps anyone with this or not.

Any news on this? I added this in the php section of docker-compose.yml in order to inherit my git config and ssh keys:
- ~/.gitconfig:/home/devilbox/.gitconfig
- ~/.ssh:/home/devilbox/.ssh

I don't think it's a long-term solution since it's editing the git-indexed docker-compose.yml. Any better suggestion? :D

@cytopia any suggestion? really appreciate devilbox, it's not part of my daily workflow :D

@nicolabeghin You can use docker-compose.overrides.yml to append these volumes to the docker container without directly editing the main yml file.
The overrides yml file is merged into the base file so you can override any setting.

thanks @science695 I assumed if a new volume: block is available in docker-compose.overrides.yml it would override the whole pre-existing volume: ??

Actually, the way I have seen it working is that the 2 arrays are merged, which makes it very easy to add new volumes, but very difficult to remove / modify volumes.

thanks a lot @science695 , all good!

Configurable directory for mounting ssh keys is now available.


"wemo list" Returns Nothing

I currently have 3 WeMo devices on my network and the wemo command returns nothing. The output of my debug when I run the command:
[root@localhost .wemo]# wemo -d list
DEBUG:ouimeaux.discovery:Binding datagram server to <IP_ADDRESS>:54321
INFO:ouimeaux.environment:Discovering devices
DEBUG:ouimeaux.discovery:Broadcasting M-SEARCH to <IP_ADDRESS>:1900
DEBUG:ouimeaux.discovery:Broadcasting M-SEARCH to <IP_ADDRESS>:1900
DEBUG:ouimeaux.discovery:Broadcasting M-SEARCH to <IP_ADDRESS>:1900
DEBUG:ouimeaux.discovery:Broadcasting M-SEARCH to <IP_ADDRESS>:1900
DEBUG:ouimeaux.discovery:Broadcasting M-SEARCH to <IP_ADDRESS>:1900
This is a pretty much a new install of Ouimeaux so pointing me toward any config options would be appreciated! I am running it on CentOS 7.

I punched a few holes in my firewall (port 54321) and I get the following output now (still comes back with no results):
[root@localhost .wemo]# wemo -d list
DEBUG:ouimeaux.discovery:Binding datagram server to <IP_ADDRESS>:54321
INFO:ouimeaux.environment:Discovering devices
DEBUG:ouimeaux.discovery:Broadcasting M-SEARCH to <IP_ADDRESS>:1900
DEBUG:ouimeaux.discovery:Received a response from <IP_ADDRESS>:60723
DEBUG:ouimeaux.discovery:Received a response from <IP_ADDRESS>:36791
DEBUG:ouimeaux.discovery:Found WeMo at <IP_ADDRESS>:36791
INFO:ouimeaux.environment:Unrecognized device type. USN=uuid:ebf5a0a0-1dd1-11b2-a90f-0050f1800000::upnp:rootdevice
DEBUG:ouimeaux.discovery:Received a response from <IP_ADDRESS>:4965
DEBUG:ouimeaux.discovery:Received a response from <IP_ADDRESS>:36185
DEBUG:ouimeaux.discovery:Received a response from <IP_ADDRESS>:47425
DEBUG:ouimeaux.discovery:Broadcasting M-SEARCH to <IP_ADDRESS>:1900
DEBUG:ouimeaux.discovery:Received a response from <IP_ADDRESS>:64830
DEBUG:ouimeaux.discovery:Received a response from <IP_ADDRESS>:44117
DEBUG:ouimeaux.discovery:Received a response from <IP_ADDRESS>:44117
DEBUG:ouimeaux.discovery:Received a response from <IP_ADDRESS>:52367
DEBUG:ouimeaux.discovery:Received a response from <IP_ADDRESS>:44117
DEBUG:ouimeaux.discovery:Received a response from <IP_ADDRESS>:44117
DEBUG:ouimeaux.discovery:Received a response from <IP_ADDRESS>:44117
DEBUG:ouimeaux.discovery:Received a response from <IP_ADDRESS>:43251
DEBUG:ouimeaux.discovery:Received a response from <IP_ADDRESS>:44117
DEBUG:ouimeaux.discovery:Received a response from <IP_ADDRESS>:44117
DEBUG:ouimeaux.discovery:Received a response from <IP_ADDRESS>:44117
DEBUG:ouimeaux.discovery:Received a response from <IP_ADDRESS>:52370
DEBUG:ouimeaux.discovery:Received a response from <IP_ADDRESS>:1900
DEBUG:ouimeaux.discovery:Received a response from <IP_ADDRESS>:4966
DEBUG:ouimeaux.discovery:Received a response from <IP_ADDRESS>:44854
DEBUG:ouimeaux.discovery:Received a response from <IP_ADDRESS>:43794
DEBUG:ouimeaux.discovery:Broadcasting M-SEARCH to <IP_ADDRESS>:1900
DEBUG:ouimeaux.discovery:Received a response from <IP_ADDRESS>:60716
DEBUG:ouimeaux.discovery:Received a response from <IP_ADDRESS>:44117
DEBUG:ouimeaux.discovery:Received a response from <IP_ADDRESS>:44117
DEBUG:ouimeaux.discovery:Received a response from <IP_ADDRESS>:52373
DEBUG:ouimeaux.discovery:Received a response from <IP_ADDRESS>:44117
DEBUG:ouimeaux.discovery:Received a response from <IP_ADDRESS>:44117
DEBUG:ouimeaux.discovery:Received a response from <IP_ADDRESS>:44117
DEBUG:ouimeaux.discovery:Received a response from <IP_ADDRESS>:44117
DEBUG:ouimeaux.discovery:Received a response from <IP_ADDRESS>:44117
DEBUG:ouimeaux.discovery:Received a response from <IP_ADDRESS>:44117
DEBUG:ouimeaux.discovery:Received a response from <IP_ADDRESS>:44117
DEBUG:ouimeaux.discovery:Received a response from <IP_ADDRESS>:44117
DEBUG:ouimeaux.discovery:Received a response from <IP_ADDRESS>:44117
DEBUG:ouimeaux.discovery:Received a response from <IP_ADDRESS>:44117
DEBUG:ouimeaux.discovery:Received a response from <IP_ADDRESS>:44117
DEBUG:ouimeaux.discovery:Received a response from <IP_ADDRESS>:44117
DEBUG:ouimeaux.discovery:Received a response from <IP_ADDRESS>:44117
DEBUG:ouimeaux.discovery:Received a response from <IP_ADDRESS>:44117
DEBUG:ouimeaux.discovery:Received a response from <IP_ADDRESS>:41853
DEBUG:ouimeaux.discovery:Received a response from <IP_ADDRESS>:4967
DEBUG:ouimeaux.discovery:Received a response from <IP_ADDRESS>:38779
DEBUG:ouimeaux.discovery:Received a response from <IP_ADDRESS>:55851
DEBUG:ouimeaux.discovery:Broadcasting M-SEARCH to <IP_ADDRESS>:1900
DEBUG:ouimeaux.discovery:Received a response from <IP_ADDRESS>:54983
DEBUG:ouimeaux.discovery:Received a response from <IP_ADDRESS>:37896
DEBUG:ouimeaux.discovery:Received a response from <IP_ADDRESS>:59754
DEBUG:ouimeaux.discovery:Received a response from <IP_ADDRESS>:4968
DEBUG:ouimeaux.discovery:Received a response from <IP_ADDRESS>:51985
DEBUG:ouimeaux.discovery:Received a response from <IP_ADDRESS>:1900
DEBUG:ouimeaux.discovery:Broadcasting M-SEARCH to <IP_ADDRESS>:1900
DEBUG:ouimeaux.discovery:Received a response from <IP_ADDRESS>:49802
DEBUG:ouimeaux.discovery:Received a response from <IP_ADDRESS>:44117
DEBUG:ouimeaux.discovery:Received a response from <IP_ADDRESS>:44117
DEBUG:ouimeaux.discovery:Received a response from <IP_ADDRESS>:52376
DEBUG:ouimeaux.discovery:Received a response from <IP_ADDRESS>:44117
DEBUG:ouimeaux.discovery:Received a response from <IP_ADDRESS>:44117
DEBUG:ouimeaux.discovery:Received a response from <IP_ADDRESS>:58660
DEBUG:ouimeaux.discovery:Received a response from <IP_ADDRESS>:44117
DEBUG:ouimeaux.discovery:Received a response from <IP_ADDRESS>:44117
DEBUG:ouimeaux.discovery:Received a response from <IP_ADDRESS>:44117
DEBUG:ouimeaux.discovery:Received a response from <IP_ADDRESS>:44117
DEBUG:ouimeaux.discovery:Received a response from <IP_ADDRESS>:34506
DEBUG:ouimeaux.discovery:Received a response from <IP_ADDRESS>:38866
DEBUG:ouimeaux.discovery:Received a response from <IP_ADDRESS>:52379
DEBUG:ouimeaux.discovery:Received a response from <IP_ADDRESS>:4969
[root@localhost .wemo]#

what wemo devices are you using? This shows it found one wemo device but could not classify it...

My network has 3 WeMo devices. 2 of the regular switches and 1 insight switch.
I'll attach the setup.xml files for the regular switches.
Here is the setup.xml of one of the regular switches:

1
0

urn:Belkin:device:controllee:1
WeMo Switch 1
Belkin International Inc.
http://www.belkin.com
Belkin Plugin Socket 1.0
Socket
1.0
http://www.belkin.com/plugin/
221228K01002E4
uuid:Socket-1_0-221228K01002E4
123456789
08863B7049E8
WeMo_WW_2.00.8326.PVT-OWRT-SNS
0|49153
0

jpg
100
100
100
icon.jpg

urn:Belkin:service:WiFiSetup:1
urn:Belkin:serviceId:WiFiSetup1
/upnp/control/WiFiSetup1
/upnp/event/WiFiSetup1
/setupservice.xml

urn:Belkin:service:timesync:1
urn:Belkin:serviceId:timesync1
/upnp/control/timesync1
/upnp/event/timesync1
/timesyncservice.xml

urn:Belkin:service:basicevent:1
urn:Belkin:serviceId:basicevent1
/upnp/control/basicevent1
/upnp/event/basicevent1
/eventservice.xml

urn:Belkin:service:deviceevent:1
urn:Belkin:serviceId:deviceevent1
/upnp/control/deviceevent1
/upnp/event/deviceevent1
/deviceservice.xml

urn:Belkin:service:crockpotevent:1
urn:Belkin:serviceId:crockpotevent1
/upnp/control/crockpot1
/upnp/event/crockpot1
/jardenservice.xml

urn:Belkin:service:jardenevent:1
urn:Belkin:serviceId:jardenevent1
/upnp/control/jardenevent1
/upnp/event/jardenevent1
/jardenservice.xml

urn:Belkin:service:firmwareupdate:1
urn:Belkin:serviceId:firmwareupdate1
/upnp/control/firmwareupdate1
/upnp/event/firmwareupdate1
/firmwareupdate.xml

urn:Belkin:service:rules:1
urn:Belkin:serviceId:rules1
/upnp/control/rules1
/upnp/event/rules1
/rulesservice.xml

  <service>
    <serviceType>urn:Belkin:service:metainfo:1</serviceType>
    <serviceId>urn:Belkin:serviceId:metainfo1</serviceId>
    <controlURL>/upnp/control/metainfo1</controlURL>
    <eventSubURL>/upnp/event/metainfo1</eventSubURL>
    <SCPDURL>/metainfoservice.xml</SCPDURL>
  </service>

  <service>
    <serviceType>urn:Belkin:service:remoteaccess:1</serviceType>
    <serviceId>urn:Belkin:serviceId:remoteaccess1</serviceId>
    <controlURL>/upnp/control/remoteaccess1</controlURL>
    <eventSubURL>/upnp/event/remoteaccess1</eventSubURL>
    <SCPDURL>/remoteaccess.xml</SCPDURL>
  </service>

  <service>
    <serviceType>urn:Belkin:service:deviceinfo:1</serviceType>
    <serviceId>urn:Belkin:serviceId:deviceinfo1</serviceId>
    <controlURL>/upnp/control/deviceinfo1</controlURL>
    <eventSubURL>/upnp/event/deviceinfo1</eventSubURL>
    <SCPDURL>/deviceinfoservice.xml</SCPDURL>
  </service>

  <service>
    <serviceType>urn:Belkin:service:smartsetup:1</serviceType>
    <serviceId>urn:Belkin:serviceId:smartsetup1</serviceId>
    <controlURL>/upnp/control/smartsetup1</controlURL>
    <eventSubURL>/upnp/event/smartsetup1</eventSubURL>
    <SCPDURL>/smartsetup.xml</SCPDURL>
  </service>

  <service>
    <serviceType>urn:Belkin:service:manufacture:1</serviceType>
    <serviceId>urn:Belkin:serviceId:manufacture1</serviceId>
    <controlURL>/upnp/control/manufacture1</controlURL>
    <eventSubURL>/upnp/event/manufacture1</eventSubURL>
    <SCPDURL>/manufacture.xml</SCPDURL>
  </service>

</serviceList>

/pluginpres.html

Sorry about the comment above. I cannot seem to be able to get it to display the XML properly. You can download the file from http://ocaff.com/switch1.xml

hmm... not really sure what went wrong. I did notice however that the switch for which you gave the xml was on firmware version 2.0 which wasn't supported until a couple hours ago. Perhaps git pull the latest version and try again?
I don't see why the devices wouldn't be recognized though... could there be a firewall interfering?

I pulled down the latest source and that didn't change anything.
I disabled by firewall on CentOS and that did not do anything
[root@localhost ouimeaux]# service iptables save
iptables: Saving firewall rules to /etc/sysconfig/iptables:[  OK  ]
[root@localhost ouimeaux]# service iptables stop
Redirecting to /bin/systemctl stop  iptables.service
[root@localhost ouimeaux]# wemo list
[root@localhost ouimeaux]# service iptables status
Redirecting to /bin/systemctl status  iptables.service
iptables.service - IPv4 firewall with iptables
Loaded: loaded (/usr/lib/systemd/system/iptables.service; disabled)
Active: inactive (dead)
Mar 19 06:55:08 localhost.localdomain systemd[1]: Stopped IPv4 firewall with ...
Hint: Some lines were ellipsized, use -l to show in full.
Here is the debug from getting the list:
DEBUG:ouimeaux.discovery:Binding datagram server to <IP_ADDRESS>:54321
INFO:ouimeaux.environment:Discovering devices
DEBUG:ouimeaux.discovery:Broadcasting M-SEARCH to <IP_ADDRESS>:1900
DEBUG:ouimeaux.discovery:Received a response from <IP_ADDRESS>:52232
DEBUG:ouimeaux.discovery:Received a response from <IP_ADDRESS>:65273
DEBUG:ouimeaux.discovery:Received a response from <IP_ADDRESS>:44117
DEBUG:ouimeaux.discovery:Received a response from <IP_ADDRESS>:44117
DEBUG:ouimeaux.discovery:Received a response from <IP_ADDRESS>:44117
DEBUG:ouimeaux.discovery:Received a response from <IP_ADDRESS>:44117
DEBUG:ouimeaux.discovery:Received a response from <IP_ADDRESS>:53164
DEBUG:ouimeaux.discovery:Found WeMo at <IP_ADDRESS>:53164
INFO:ouimeaux.environment:Unrecognized device type. USN=uuid:ebf5a0a0-1dd1-11b2-a90f-0050f1800000::upnp:rootdevice
DEBUG:ouimeaux.discovery:Received a response from <IP_ADDRESS>:44117
DEBUG:ouimeaux.discovery:Received a response from <IP_ADDRESS>:44117
DEBUG:ouimeaux.discovery:Received a response from <IP_ADDRESS>:44117
DEBUG:ouimeaux.discovery:Received a response from <IP_ADDRESS>:44117
DEBUG:ouimeaux.discovery:Received a response from <IP_ADDRESS>:58093
DEBUG:ouimeaux.discovery:Received a response from <IP_ADDRESS>:4074
DEBUG:ouimeaux.discovery:Received a response from <IP_ADDRESS>:1900
DEBUG:ouimeaux.discovery:Received a response from <IP_ADDRESS>:33113
DEBUG:ouimeaux.discovery:Broadcasting M-SEARCH to <IP_ADDRESS>:1900
DEBUG:ouimeaux.discovery:Received a response from <IP_ADDRESS>:60187
DEBUG:ouimeaux.discovery:Received a response from <IP_ADDRESS>:65276
DEBUG:ouimeaux.discovery:Received a response from <IP_ADDRESS>:60681
DEBUG:ouimeaux.discovery:Received a response from <IP_ADDRESS>:65279
DEBUG:ouimeaux.discovery:Received a response from <IP_ADDRESS>:34849
DEBUG:ouimeaux.discovery:Received a response from <IP_ADDRESS>:4075
DEBUG:ouimeaux.discovery:Received a response from <IP_ADDRESS>:33438
DEBUG:ouimeaux.discovery:Received a response from <IP_ADDRESS>:1900
DEBUG:ouimeaux.discovery:Broadcasting M-SEARCH to <IP_ADDRESS>:1900
DEBUG:ouimeaux.discovery:Received a response from <IP_ADDRESS>:58920
DEBUG:ouimeaux.discovery:Received a response from <IP_ADDRESS>:44117
DEBUG:ouimeaux.discovery:Received a response from <IP_ADDRESS>:65282
DEBUG:ouimeaux.discovery:Received a response from <IP_ADDRESS>:44117
DEBUG:ouimeaux.discovery:Received a response from <IP_ADDRESS>:44117
DEBUG:ouimeaux.discovery:Received a response from <IP_ADDRESS>:1900
DEBUG:ouimeaux.discovery:Received a response from <IP_ADDRESS>:47398
DEBUG:ouimeaux.discovery:Received a response from <IP_ADDRESS>:44117
DEBUG:ouimeaux.discovery:Received a response from <IP_ADDRESS>:44117
DEBUG:ouimeaux.discovery:Received a response from <IP_ADDRESS>:44117
DEBUG:ouimeaux.discovery:Received a response from <IP_ADDRESS>:42322
DEBUG:ouimeaux.discovery:Received a response from <IP_ADDRESS>:44117
DEBUG:ouimeaux.discovery:Received a response from <IP_ADDRESS>:44117
DEBUG:ouimeaux.discovery:Received a response from <IP_ADDRESS>:65285
DEBUG:ouimeaux.discovery:Received a response from <IP_ADDRESS>:51189
DEBUG:ouimeaux.discovery:Received a response from <IP_ADDRESS>:4077
DEBUG:ouimeaux.discovery:Broadcasting M-SEARCH to <IP_ADDRESS>:1900
DEBUG:ouimeaux.discovery:Received a response from <IP_ADDRESS>:60875
DEBUG:ouimeaux.discovery:Received a response from <IP_ADDRESS>:44117
DEBUG:ouimeaux.discovery:Received a response from <IP_ADDRESS>:44117
DEBUG:ouimeaux.discovery:Received a response from <IP_ADDRESS>:59882
DEBUG:ouimeaux.discovery:Received a response from <IP_ADDRESS>:44117
DEBUG:ouimeaux.discovery:Received a response from <IP_ADDRESS>:44117
DEBUG:ouimeaux.discovery:Received a response from <IP_ADDRESS>:44117
DEBUG:ouimeaux.discovery:Received a response from <IP_ADDRESS>:44117
DEBUG:ouimeaux.discovery:Received a response from <IP_ADDRESS>:44117
DEBUG:ouimeaux.discovery:Received a response from <IP_ADDRESS>:44117
DEBUG:ouimeaux.discovery:Received a response from <IP_ADDRESS>:65291
DEBUG:ouimeaux.discovery:Received a response from <IP_ADDRESS>:4079
DEBUG:ouimeaux.discovery:Received a response from <IP_ADDRESS>:44306
DEBUG:ouimeaux.discovery:Received a response from <IP_ADDRESS>:55703
DEBUG:ouimeaux.discovery:Broadcasting M-SEARCH to <IP_ADDRESS>:1900
DEBUG:ouimeaux.discovery:Received a response from <IP_ADDRESS>:56667
DEBUG:ouimeaux.discovery:Received a response from <IP_ADDRESS>:44117
DEBUG:ouimeaux.discovery:Received a response from <IP_ADDRESS>:65294
DEBUG:ouimeaux.discovery:Received a response from <IP_ADDRESS>:44117
DEBUG:ouimeaux.discovery:Received a response from <IP_ADDRESS>:44117
DEBUG:ouimeaux.discovery:Received a response from <IP_ADDRESS>:44117
DEBUG:ouimeaux.discovery:Received a response from <IP_ADDRESS>:44117
DEBUG:ouimeaux.discovery:Received a response from <IP_ADDRESS>:44117
DEBUG:ouimeaux.discovery:Received a response from <IP_ADDRESS>:44117
DEBUG:ouimeaux.discovery:Received a response from <IP_ADDRESS>:44117
DEBUG:ouimeaux.discovery:Received a response from <IP_ADDRESS>:44117
DEBUG:ouimeaux.discovery:Received a response from <IP_ADDRESS>:44117
DEBUG:ouimeaux.discovery:Received a response from <IP_ADDRESS>:44117
DEBUG:ouimeaux.discovery:Received a response from <IP_ADDRESS>:44117
DEBUG:ouimeaux.discovery:Received a response from <IP_ADDRESS>:44117
DEBUG:ouimeaux.discovery:Received a response from <IP_ADDRESS>:44117
DEBUG:ouimeaux.discovery:Received a response from <IP_ADDRESS>:44117
DEBUG:ouimeaux.discovery:Received a response from <IP_ADDRESS>:44117
DEBUG:ouimeaux.discovery:Received a response from <IP_ADDRESS>:39455
DEBUG:ouimeaux.discovery:Received a response from <IP_ADDRESS>:65298
DEBUG:ouimeaux.discovery:Received a response from <IP_ADDRESS>:65299
DEBUG:ouimeaux.discovery:Received a response from <IP_ADDRESS>:1900
DEBUG:ouimeaux.discovery:Received a response from <IP_ADDRESS>:38884
DEBUG:ouimeaux.discovery:Received a response from <IP_ADDRESS>:4080
DEBUG:ouimeaux.discovery:Received a response from <IP_ADDRESS>:33437
Some things to note here. The device that it found at <IP_ADDRESS>:53164. That device is my router, not a WeMo.
I also noticed this morning that in the debug it is not listing any IP addresses of my actual WeMo devices. This morning I have 2 of them on my network and their IP addresses are <IP_ADDRESS> and <IP_ADDRESS>.
Could the issue be that I am running a /16 network and that there are too many possible IP addresses to find?

It may be possible the list command is timing out without getting a response due to such a large network? I would think it would still work but why don't you try running wemo -d -t 120 server and see if it picks them up with a 2 minute discovery?

A 2 minute discovery didn't pick anything up. I will try a 10 minute one to see if that yields anything different.

The 10 minute crawl didn't pick anything up either.

FWIK we are sending out a multicast packet to the router to elicit a response from all UPnP devices on the network. All UPnP devices are required to send their response to the sender of the multicast packet.
UPnP seems to be enabled on the router as you are receiving responses. Do you have multiple routers in the environment? This is sometimes a headache for UPnP from a quick google.

I also notice you are running ouimeaux on an ip of <IP_ADDRESS> while your devices are on 10.1.1.X. Maybe your wemo devices don't support your Subnet Mask? Maybe try setting their IPs or your servers IP to be within the same /24 subnet? I don't think it is a problem with UPnP in general to be used across a /16 subnet but maybe the Belkin implementation is causing them not to respond?

That would not surprise me much. I've noticed that Belkin struggles on the software end of things (hence the reason I feel the need to control these things on my own).
Off topic question (and if this belongs in another topic, let me know).
Is it possible to use ouemeaux using just the IP address of the device? I have my devices setup to use a reserved IP address on my router so I can easily locate them on my network.

Essentially that is what ouimeaux is doing. The devices are UPnP devices which means that they most be communicated with using SOAP. There is not a REST API builtin. Unfortunately your devices are not responding to a UPnP discovery request which is a problem. You may be able to re-use the code and hardcode the IPs but you still need to communicate with SOAP on the correct ports (which change) and so it's not as simple as pointing your web browser at them.
I would suggest trying the set your DHCP reservations to be on 10.1.200.X first to see if that resolves the problem.

Just want to let you know I'm not falling off the wagon. I tried getting the IP address closer and that did not help.
I changed my network from a /16 to a /24 network in hopes that a smaller network would help move things along. Doing that so far has caused my WeMo's to not respond to the app at all. I think I will have to readd them to the app (after waiting for the DHCP leases to expire).

Maybe try resetting the firmware from the switches themselves and re-pair them to your network? I'm kind of lost for reasons why it's not working at this point!

I think I want to chalk it up to Belkin at this point. These things have been so temperamental ever since I got them.
Right now my router can see that they are connected and I am able to ping them, but the WeMo app cannot see them (and neither can Ouimeaux).
I think that whatever Belkin did with the last software update, they messed up the outlet's ability to respond to a UPnP message.

I just noticed that Ouimeaux can see the Roku devices on my network, but not my outlets.
I am going to unplug all the devices, let them sit for awhile and then try to add again. That worked once.

Maybe it was a botched firmware update and the app had the devices cached and then once you changed their IPs it couldn't find them again? Either way I'd recommend holding the reset button on the switches themselves to re-initialize them and then go through the setup process with the app.

Since you've got two different subnets is it possible that some of your devices are behind a comcast/dsl router and some of your other devices are behind a wifi router/switch? Maybe consolidating everything onto the same subnet will fix the issue.


Project "Container Default Resource Limit" settings allow you to define a default reservation greater than the default limit

Internal reference: SURE-4864
Reported in 2.6.5
Issue description:
The "Container Default Resource Limit" configuration on Rancher Projects permits creation of a default reservation for CPU/memory that exceeds the default limit for CPU/memory, in which instance Rancher produces no error within the UI and permits creation of this conflicting reservation/limit. The LimitRange resource fails to create in the Namespaces of the Project, with errors of the following format in the Rancher Pod logs:
2022/06/23 14:51:16 [ERROR] error syncing 'test': handler resourceQuotaSyncController: LimitRange "b91c5718-c334-4ec3-a66b-c50a7251a470" is invalid: spec.limits[0].defaultRequest[memory]: Invalid value: resource.Quantity{i:resource.int64Amount

{value:1048576000, scale:0}
, d:resource.infDecAmount{Dec*inf.Dec)(nil)}, s:"", Format:"BinarySI"}: default request value 1000Mi is greater than default limit value 2Mi, requeuing

This should require a backend (as well as possible frontend validation) fix, such that this cannot occur when a user defines the Container Default Resource Limit for a Project via the Rancher2 Terraform Provider (https://registry.terraform.io/providers/rancher/rancher2/latest/docs/resources/project#container_resource_limit) or Rancher API.
Business impact:
The LimitRange resource for Namespaces in Project's with this bad configuration are not created, without any error to indicate this within Rancher UI
Repro steps:

Provision a Rancher v2.6.5 instance and a single all role node cluster
Create a test Project, with a single test Namespace, and under "Container Default Resource Limit" set the Memory Reservation to 1000Mi and Memory Limit to 2Mi
Observe you can successfully save the changes, but errors appear in Rancher Pod logs
Create a new test Project, with a single test Namespace, and under "Container Default Resource Limit" set a CPU Reservation of 2000 and a CPU Limit of 2000
Observe you can successfully save the changes, but similar errors appear in Rancher Pods logs:

2022/06/23 15:08:06 [ERROR] error syncing 'test2': handler resourceQuotaSyncController: LimitRange "94ad658d-f709-41f3-8bac-cd138fbca6fd" is invalid: spec.limits[0].defaultRequest[cpu]: Invalid value: resource.Quantity{i:resource.int64Amount {value:2, scale:0}
, d:resource.infDecAmount{Dec*inf.Dec)(nil)}, s:"2", Format:"DecimalSI"}: default request value 2 is greater than default limit value 1, requeuing

Workaround:
N/A
Actual behavior:
Able to create Project Container Default Resource Limit configuration where the default reservation for CPU/memory exceeds the default limit for CPU/memory, resulting in errors when Rancher attempts to create the LimitRange resource in Project Namespaces
Expected behavior:
Unable to create Project Container Default Resource Limit configuration where the default reservation for CPU/memory exceeds the default limit for CPU/memory

Transferred to backend to investigate further. If UI validation is required, let us know over in rancher/dashboard.

This issue reproducible in rancher 2.7.3
newrancherserver:~ # kubectl get -n cattle-system deployment.apps/rancher -o json | jq -r .spec.template.spec.containers[].image
rancher/rancher:v2.7.3
newrancherserver:~ #
newrancherserver:~ # kubectl logs -f -n cattle-system deployment.apps/rancher  | grep resourceQuotaSyncController | head -1
2023/06/01 12:09:02 [ERROR] error syncing 'test': handler resourceQuotaSyncController: LimitRange "2ee6f535-0e91-433b-8a72-976d58a36be9" is invalid: spec.limits[0].defaultRequest[memory]: Invalid value: resource.Quantity{i:resource.int64Amount{value:1048576000, scale:0}, d:resource.infDecAmount{Dec:(*inf.Dec)(nil)}, s:"", Format:"BinarySI"}: default request value 1000Mi is greater than default limit value 2Mi, requeuing
newrancherserver:~ #

Update on this issue after some investigation.
This is not a resource quota problem, is a container default limit problem. Although they might seem like the same feature, they are not in the code. They also produce different objects/requests. Another important detail is the container default limits need to be set at the project level, not namespace level to be able to reproduce this issue. I don't think the level should matter, but there seems to be another bug that prevents a LimitRange object from being created when you set them at the namespace level and so you don't see the error when I think you should. That said, in the terms of this issue the controller seems to work as intended. Therefore a fix for this issue should be done at the Rancher webhook level by extending our current validation for projects/namespaces to check for container default limits as well. This would produce an error the UI can then make use of to warn the user when they've entered incompatible reserve/limit values for container resources.

Issue Recreate
I was able to recreate the issue in v2.8-head

Create a Rancher instance with v2.8.
Provision a downstream RKE1 single node all role cluster.
Create a new project, and under “Container Default Resource Limit” set the “Memory Reservation” value to 1000MiB and the “Memory Limit” value to 2MiB.
Create a namespace in the new project, and verify it successfully saves but errors are observed in Rancher logs.
Create another new project, and under "Container Default Resource Limit" set the "CPU Reservation" value to 2000mCPUs and the "CPU Limit" value to 1000m.
Create a namespace in the new project, and verify it successfully saves but errors are observed in Rancher logs.

Issues observed

Rancher allows you to create a Project Container Default Resource Limit configuration where the default reservation for CPU/Memory exceeds the default limit for CPU/Memory, which causes an error when Rancher attempts to create the LimitRange object in the Project's namespace.

2023/12/12 14:32:04 [ERROR] error syncing 'nc1': handler resourceQuotaSyncController: LimitRange "default-8fwx6" is invalid: spec.limits[0].defaultRequest[memory]: Invalid value: resource.Quantity{i:resource.int64Amount{value:1048576000, scale:0}, d:resource.infDecAmount{Dec:(*inf.Dec)(nil)}, s:"1000Mi", Format:"BinarySI"}: default request value 1000Mi is greater than default limit value 2Mi, requeuing
2023/12/12 14:45:34 [ERROR] error syncing 'nc2': handler resourceQuotaSyncController: LimitRange "default-bl79r" is invalid: spec.limits[0].defaultRequest[cpu]: Invalid value: resource.Quantity{i:resource.int64Amount{value:2, scale:0}, d:resource.infDecAmount{Dec:(*inf.Dec)(nil)}, s:"2", Format:"DecimalSI"}: default request value 2 is greater than default limit value 1, requeuing

QA TEST PLAN
Test Cases

1)	Creating Project Container Default Resource Limit CPU/Memory configuration individually
2)	Creating Project Container Default Resource Limit CPU/Memory configuration together
1 Creating Project Container Default Resource Limit CPU/Memory configuration individually
Test Steps:

Create a single node docker Rancher instance with v2.8-head.
Provision a downstream RKE1 single node all role cluster.
Create a new project, and under Container Default Resource Limit set the “Memory Reservation” value to 1000MiB and the “Memory Limit” value to 2MiB.
Create a namespace in the new project.
Verify that Rancher throws an error regarding the CPU Reservation/Limit
Check the Rancher logs to verify the error creating the LimitRange object (docker  logs)
Create a new project, and under “Container Default Resource Limit” set the “CPU Reservation” value to 2000mCPUs and the “CPU Limit” value to 1000mCPUs.
Create a namespace in the new project.
Verify that Rancher throws an error.
Check the Rancher logs to verify the error creating the LimitRange object (docker  logs)

2 Creating Project Container Default Resource Limit CPU/Memory configuration together
Test Steps:

Create a single node docker Rancher instance with v2.8-head.
Provision a downstream RKE1 single node all role cluster.
Create a new project, and under Container Default Resource Limit set the “CPU Reservation” value to 2000mCPUs and the “CPU Limit” value to 1000mCPUs. Also, set the “Memory Reservation” value to 1000MiB and the “Memory Limit” value to 1000MiB.
Create a namespace in the new project.
Verify that Rancher throws an error regarding the CPU Reservation/Limit
Check the Rancher logs to verify the error creating the LimitRange object docker <container-name> logs
Create a new project, and under Container Default Resource Limit set the “CPU Reservation” value to 1000mCPUs and the “CPU Limit” value to 1000mCPUs. Also, set the “Memory Reservation” value to 2000MiB and the “Memory Limit” value to 1000MiB.
Create a namespace in the new project.
Verify that Rancher throws an error regarding the Memory Reservation/Limit
Check the Rancher logs to verify the error creating the LimitRange object docker <container-name> logs
Create a new project, and under Container Default Resource Limit set the “CPU Reservation” value to 2000mCPUs and the “CPU Limit” value to 1000mCPUs. Also, set the “Memory Reservation” value to 2000MiB and the “Memory Limit” value to 1000MiB.
Verify that Rancher throws an error regarding the CPU and Memory Reservation/Limit
Check the Rancher logs to verify the error creating the LimitRange objects docker <container-name> logs

QA Testing
Root cause
Neither norman nor webhook had any validation for container resource default limits. Users were free to create invalid
requests and limits for resources, which led to Rancher's controller being stuck in an error loop trying to create the
corresponding LimitRange objects, which the Kubernetes API server kept rejecting.
What was fixed, or what changes have occurred
We added validation to the webhook, so that it blocks the creation of projects that have invalid container resource
default limit configuration.
Areas or cases that should be tested
Creating a project with different values for container resource default limit configuration.
What areas could experience regressions?
Steps

Run Rancher with a custom build of the webhook (or an RC released with the change).
Create a project (try both a local and remote cluster).
Specify Container Default Resource Limits. Validation mimics the upstream behavior of the Kubernetes API server when
it validates LimitRanges. The container default resource configuration must have properly formatted quantities for
all requests and limits. Limits for any resource must not be less than requests.

Negative values are fine.
Equal values for request and limit for any resource are fine.
Bad values, like "apple", cause an error.
Set a resource to be greater than the limit and expect an error.
Note that the GPU resource has no effect, it just exists in the UI, ignore it. Test with CPU and memory only.

@maxsokolovsky could you please create a webhook RC? Also, a rancher PR might be needed to reference the webhook RC.

Moving this back to QA-Next-Up as there are 2.8-Next1 issues that are ready to test. Will get back to this after 2.8 issues are done.

All scenarios identified in the test plan have been validated with v2.9-ca18e7126d90c20c720dd570ea900c357baafa93-head.

Release note
Rancher now validates Container Default Resource Limit on Projects.
Validation mimics the upstream behavior of the Kubernetes API server when it validates LimitRanges. The container default resource configuration must have properly formatted quantities for all requests and limits.
Limits for any resource must not be less than requests.


[bug] ECS may failed when the ECS sold out

Describe the bug
Hi,
The latest feature quota of the ECS, may have some problems.
If the ECS in the region has sold out, the program will fail.

@killerdbob thanks for reporting this! What do you mean by the region is "sold out"? Also are you referring to a specific cloud?
Thanks,
Sarah

hi @sarahwooders, for example, “n2-standard-96” in some GCP regions is "sold out", not enough physical machines in this data centre. However, the quotas may still be big enough for the user, this will crash.
I found that there is SDK to check if the ECS is "sold out" in the region.

You could follow up with Skypilot (https://github.com/skypilot-org/skypilot), they maintain a csv for every cloud. They record every "available" ECS in every "region", this prevented the user to provision "unavailable" ECS.
I also fix the cover according to Skypilot, just try to make Skyplane looks nicer. (https://github.com/skyplane-project/skyplane/pull/888)


Extend config.js suffix

Hi,
in the future release it would be useful to add the suffix keyword for service, template, directive and filter. (eg. CONTROLLER_SUFFIX: 'Ctrl' into utils/config.js file).
Thanks,
Lorenzo

Hi Lorenzo, I get that you would want to have some control over the naming conventions or even the general folder structure of your files. However we noticed that it takes a lot of time to make everything configurable and it brings a lot of edge cases without adding a real benefit as it's just a question of taste.
Right now there's a lot of time-consuming tasks on the horizon like Typescript support and many other which have absolute priority.
So right now requests like these are not a priority. If you are willing to contribute and invest some work. I'll be happy to help you with a PR. I'm closing this for now, if you're interested just comment again.


Support running benchmarks on a fixed CPU

The taskset command can be used to force a process to be run on a given CPU, which can prevent core swapping during the benchmarks, and make it more reliable to run asv multiple times in parallel. It would be nice to add a command-line option to make sure that all sub-processes run on a a fixed CPU using taskset (at the moment, I don't think taskset -c 0 asv run ... will have an impact on the subprocesses that run the benchmarks?)

Seems to me the affinity is inherited by subprocesses --- did you check?

@pv - I checked, but on my system, the python process that seemed to be created did not have an affinity, but I checked that the asv process did. However, that may be some mis-configuration on my system, so if you think it should work then feel free to close.

afaik, child processes on linux inherit affinity. However, openblas, mkl etc may change it.


Maybe a bug in RecycleView. Keeping multiselected items after rv.data update (sort, value added ...)

Maybe a bug in RecycleView because dessant test with CompoundSelection and seems to work.
I've a RecycleView which is automatically alpha ordered when rv.data changes. I can add entry to rv.data too.
What I've seen is that multiselect items are not tracked when rv.data is updated. Memory of selection is done on nodes indices not on rv items id(viewclass).
Here is a code to test (Python 3.5)
from kivy.app import App
from kivy.lang import Builder
from kivy.uix.boxlayout import BoxLayout
from kivy.properties import ListProperty, BooleanProperty, StringProperty
from kivy.uix.label import Label
from kivy.uix.popup import Popup

from kivy.uix.recycleview.layout import LayoutSelectionBehavior
from kivy.uix.recycleview.views import RecycleDataViewBehavior
from kivy.uix.behaviors.focus import FocusBehavior
from kivy.uix.recycleboxlayout import RecycleBoxLayout

kv = """
<Row@BoxLayout>:
    canvas.before:
        Color:
            rgba: 0.5, 0.5, 0.5, 1
        Rectangle:
            size: self.size
            pos: self.pos
    name: ''
    Label:
        text: root.name

<SelectableProjectLabel>:
    size_hint: .1, .1
    text: self.name
    canvas.before:
        Color:
            rgba: (.8, 0, .1, .3) if self.selected else (0, 0, 0, 1)
        Rectangle:
            pos: self.pos
            size: self.size

<AddProjectPopup>:
    title: 'Add Project'
    size_hint: .7, .7

    BoxLayout:
        orientation: 'vertical'
        project_name: name
        TextInput:
            id: name
            hint_text: "Enter project_name"
            multiline: False
            size_hint_y: None
            padding: [55, ( self.height - self.line_height ) / 2]
        Button:
            text: "Save"
            on_release: app.root.projects_list.append({'name': self.parent.project_name.text, 'selectable': True})
            size_hint_y: .2
        Button:
            size_hint_y: .2
            text: 'Back / Cancel'
            on_release: root.dismiss()

<Test>:
    BoxLayout:
        orientation: 'vertical'
        Button:
            text: "Add project"
            on_release: app.add_project_popup.open()
            size_hint_y: .2

        RecycleView:
            id: rv
            data: root.projects_list
            scroll_type: ['bars', 'content']
            scroll_wheel_distance: dp(114)
            bar_width: dp(10)
            viewclass: 'SelectableProjectLabel'
            ProjectsRecycleBoxLayout:
                id: rv_box
                multiselect: True
                touch_multiselect: True
                key_selection: 'selectable'
                orientation: 'vertical'
                height: self.minimum_height
                size_hint: 1, None
                default_size: None, dp(56)
                default_size_hint: 1, None
                spacing: '15dp'

"""

Builder.load_string(kv)

class Test(BoxLayout):
    projects_list = ListProperty(rebind=True)

    def __init__(self, **kwargs):
        super().__init__(**kwargs)
        self.projects_list.append({'name': 'aa', 'selectable': True})
        self.projects_list.append({'name': 'ee', 'selectable': True})

    def on_projects_list(self, instance, value):
        self.projects_list = sorted(value, key=lambda project: project['name'])

class AddProjectPopup(Popup):
    pass

class SelectableProjectLabel(RecycleDataViewBehavior, Label):

    index = None  # stores our index
    selected = BooleanProperty(False)
    selectable = BooleanProperty(False)
    name = StringProperty()

    def refresh_view_attrs(self, rv, index, data):
        self.index = index
        return super().refresh_view_attrs(rv, index, data)

    def on_touch_down(self, touch):
        if super().on_touch_down(touch):
            return True
        if self.collide_point(*touch.pos) and self.selectable:
            return self.parent.select_with_touch(self.index, touch)

    def apply_selection(self, rv, index, is_selected):
        self.selected = is_selected

class ProjectsRecycleBoxLayout(FocusBehavior, LayoutSelectionBehavior,
                               RecycleBoxLayout):
    pass

class TestApp(App):

    def build(self):
        self.add_project_popup = AddProjectPopup()
        return Test()

if __name__ == '__main__':
    TestApp().run()

Steps for testing:

Launch app
select project ‘ee’
Click Add project button
Add project named ‘b’
Click ‘save
Click ‘back’.
You will see that the previously selected line ‘ee’ is no more. ‘b’ is selected instead. I would like ‘ee’ stay selected or maybe I'm doing something wrong.
Let me know.

@matham, what do you think?

You have to select the last item and afterwards add an item above the last one.
The problem seems to be related to the sorting after the on_projects_list event.

I have a similar issue.  I clear the recycle view data, if there was a DataView item selected and I add new data to the RV, it will show the same (grid row in my case) DV item being selected, even though the RV has gotten new data.  I would assume the RV should clear any selections when RV.data == [].  It doesn't.

Same issue here!

Same here. 2 years and 4 months later still unresolved?


lib/systems: use execvp instead of shell for native emulator

Description of changes
Changes platform’s emulator to use a C script that calls execvp instead of runtimeShell. This makes it easier to use emulator in contexts where only a program path is accepted, but also avoids some POSIX shell quirks (see comment in the changes).
Things done

Built on platform(s)

[ ] x86_64-linux
[x] aarch64-linux
[ ] x86_64-darwin
[ ] aarch64-darwin

For non-Linux: Is sandboxing enabled in nix.conf? (See Nix manual)

[ ] sandbox = relaxed
[ ] sandbox = true

[ ] Tested, as applicable:

NixOS test(s) (look inside nixos/tests)
and/or package tests
or, for functions and "core" functionality, tests in lib/tests or pkgs/test
made sure NixOS tests are linked to the relevant packages

[ ] Tested compilation of all packages that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review rev HEAD". Note: all changes have to be committed, also see nixpkgs-review usage
[ ] Tested basic functionality of all binary files (usually in ./result/bin/)
24.11 Release Notes (or backporting 23.11 and 24.05 Release notes)

[ ] (Package updates) Added a release notes entry if the change is major or breaking
[ ] (Module updates) Added a release notes entry if the change is significant
[ ] (Module addition) Added a release notes entry if adding a new NixOS module

[ ] Fits CONTRIBUTING.md.

Add a :+1: reaction to pull requests you find important.

@Ericson2314, @alyssais, @roberth, ping 👀
The PR has been ready for review for 3 weeks…

Sorry about that. I can't always keep up.
Did you try env --?
The -- syntax is also available on darwin.
If that's not a good fit, I'm quite fond of this little program, which I think should always have existed; a simple building block like the true and false programs, so then I would suggest to make it a proper package, which is easy to find for users when they encounter it in an error message.

The issue with ${coreutils}/bin/env -- is that, ideally, we want selectEmulator to return an executable path instead of an unstructured string with some extra arguments appended—this just makes it easier to use in some contexts. We’d need some wrapping code to hide the arguments in selectEmulator, so might as well use a program that does execvp and nothing else for canExecute branch to avoid unnecessary layers of abstractions and indirection.
That said, I’m not really sure why emulator is a property of the platform and not a package set, i.e. stdenv.hostPlatform.emulator buildPackages instead of buildPackages.emulatorFor stdenv.hostPlatform with buildPackages.hostEmulator defined for convenience.

so then I would suggest to make it a proper package, which is easy to find for users when they encounter it in an error message.

Sounds good to me, should it be in by-name or build-support?

I see.

I’m not really sure why emulator is a property of the platform and not a package set

Me neither. It couples lib, which was supposed to be quite independent, to the package set.
We're already trying to get rid of functions in platforms so that equality works, so yeah, I think you're on to something.

by-name or build-support?

I see no reason not to use by-name, because it can be a proper package.
I did notice that it was had two names, doexec and exec-emulator.
I think a name like doexec makes it more widely applicable.
What do you think of a name like bin-exec or exec-args?

Moved to pkgs/by-name/bi/bin-exec.

I think we could use the exec binary from the execline package.

this just makes it easier to use in some contexts

What contexts?  Are we sure it's worth it?

I think we probably don't need to duplicate the exec program we already have packaged — the package containing it is tiny.

@alyssais, sounds reasonable. Another motivation for a bin-exec program was to allow arguments starting with - without wrappers (see https://github.com/NixOS/nixpkgs/pull/324071#issuecomment-2247771353), but currently this won’t work for other emulators (e.g. IIRC wine doesn’t support --) so we might as well use execline (although it’s a bit weird that it has its own execvpe implementation).

@roberth, ping 😅

It's probably ok, but how do we test this?
A code comment about that would be helpful, making it easy for any reviewer to test this and merge PRs like this confidently with little effort.

It's probably ok, but how do we test this?

@roberth, I don’t think we have any specific tests for emulators right now. I’ve tested the PR with nix build --file pkgs/top-level/release-small.nix rebuild on aarch64-linux and also nix build --file . librsvg (that uses an emulator in native case as well), but it’s a very brute-force way to test a change.

I’m not really sure why emulator is a property of the platform and not a package set

Me neither. It couples lib, which was supposed to be quite independent, to the package set.
We're already trying to get rid of functions in platforms so that equality works, so yeah, I think you're on to something.

I currently have a few non-trivial refactor PRs open and I don’t want to take on another tree wide change, but I’d like work on moving emulator selection functions from lib to pkgs (and add some tests along the way) once I’ll have enough time for this, unless somebody picks this up before me.

Adds 110 paths to drv deps in some cases https://github.com/NixOS/nixpkgs/pull/351768


solidrun-n6g: Add support for SolidRun N6G devices

This adds support for the SolidRun N6G Indoor and Outdoor devices.
Signed-off-by: Eric Bree<EMAIL_ADDRESS>

Can one of the admins verify this patch?

Hi @solidrun-ejb are you still planning on adding this board?

Hi,
can these commits be merged into just one commit? As per the last push, this PR added another commit that modifies the older commit. So the PR introduces some changes which are later on changed again in the same PR. This makes it difficult to review

Superseded by https://github.com/balena-os/balena-fsl-arm/pull/148


fix(scripts/{lint_style,mk_all}): limit return value to 125

so the executable's exit code can be used further in shell scripts, such as mathlib's CI.
See https://unix.stackexchange.com/a/418802 for background why a maximum of 125 is safest (on Linux).

@adomani Since you raised this issue (thanks again for pointing me in this direction!), would you like to take a look?

bors d+

It seems that the current solution satisfies everybody - let's land this. Thanks for the reviews and the keen comments!
bors r+


Auth Rewrite

moved from clerk auth to a custom > supabase auth + prisma
GOAL: to add oAuth at a later date (github, google)

LGTM!


Missing holiday methods in ProviderInterface

In v2.5 Yasumi::create now returns an instance of ProviderInterface, but this interface is missing most methods needed to actually do anything with holidays:

No isHoliday method
No getHolidayDates method (that is the one that my code is using)
No between method
No getHolidayNames method
No whenIs method

These would seem like the necessary methods to get a list of holidays and check if a date is a holiday or what holidays are within a certain timeframe. ProviderInterface has no method at all to check for holidays - which is why my static analyzers report Method Yasumi\ProviderInterface::getHolidayDates does not exist, and anybody using static analyzers and Yasumi will get these kind of errors. The methods are currently still there in AbstractProvider, but according to ProviderInterface they are not necessary.

@iquito Thank you very much for your issue. Some other users have already reported the same and I am working on a fix for this.

Thanks for your effort! I didn't see an issue for this yet, and v2.5 just came out, so I thought I would mention it in case this wasn't known yet :-)

Sorry, indeed not, however a PR was created that fixed one of the missing methods you mentioned. In the meantime I started working on a fix in a different branch. (https://github.com/azuyalabs/yasumi/tree/tests-fixes)

It could make sense to use two interfaces - a "user-facing" one that implements the methods to check for holidays, dates, etc. (representing a very stable set of methods that almost never need to change), and a "provider-facing" one that implements methods like "initialize" or "getHoliday", which might be important for the provider to work but seem less useful for somebody just using the library. Then you can just type hint the user-facing one for Yasumi::create but still internally check that both interfaces are implemented.

The AbstractProvider class is kind of a messy class, I admit. These two interface could certainly be identified.

Our PHPStan CI also reports now errors:
 ------ ------------------------------------------------------------------
  Line   src/Utility/Calendar.php
 ------ ------------------------------------------------------------------
  26     Call to an undefined method Yasumi\ProviderInterface::between().
 ------ ------------------------------------------------------------------

 ------ -------------------------------------------------------------------------
  Line   src/Utility/SprykerHolidays.php
 ------ -------------------------------------------------------------------------
  20     Call to private method christmasEve() of class Yasumi\Provider\Germany.
  21     Call to private method newYearsEve() of class Yasumi\Provider\Germany.
 ------ -------------------------------------------------------------------------

We will pin down back to 2.4 then for now.

@iquito All methods have been created with the intent to be public. I don't see any specific reason to make some of them protected/private. With that background, the ProviderInterface should have had all those methods defined, which unfortunately was not the case with the 2.5 release.
BTW, I've made fixes in the develop branch, so if you're interested you may want to test with that branch.

I mention it more because I don't know the exact motivations behind the methods, so I don't want to presume, and sometimes some methods exist but are more internal or legacy. The interface looks fine to me in the develop branch, although I would hide the initialize-method for the user (or you could mark it as @internal for now, so nobody calls it explicitly in their code), while all the other methods seem okay to expose.

Thanks for checking the fixes. Good idea to mark the initialize method to @internal.

@iquito The develop branch contains all recent bugfixes. You may want to check it out in your project if you like. I am preparing a new release soon addressing the latest identified issues.

I can report that PHPStan now is green again with develop branch :)

I would recommend to update "phpstan/phpstan": "^0.12", to "^1.2" now
Also level 7+ is recommended to have a good check for your API, 8 is nullable safety and nice to have, but 7 will help a lot with interface contracts and types as well.

@dereuromark Thanks! I had some issues with phpstan 1.2 before and had to revert to 0.12. I'll check that. Also checking for level 7 as well :)

What kind of issues? Maybe I have an idea. Had to fix myself hundreds of repos here :)

I don't recall specifically but got many false negatives. Anyway, upgraded to 1.4 and all seem good :)

The dev-develop branch fixes my phpstan errors as well.


Dovetail audio refactor

@chrisrhoden do you think this is in a good spot?

To merge? Yeah you can do that if you like. I don't think anything is super
broken.
On Thu, Apr 7, 2016 at 2:33 PM, Chris Kalafarski<EMAIL_ADDRESS>wrote:

@chrisrhoden https://github.com/chrisrhoden do you think this is in a
good spot?
—
You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHub
https://github.com/PRX/embed.prx.org/pull/14#issuecomment-207040475


0 Active Connections

I downloaded this windows wallet today.  I have windows 8.  I only noticed it said "not synced"  eventually I noticed on the bottom that it says "0 active connections"   There is a large error log.
Meanwhile I didn't realize it needed to sync, so I sent funds to this wallet from Bitconnect.
Is there a way to get this to connect?

Efsaturn. i have the same issues exactly as you did. please if you found the solution to that problem, could you please forward it the procedure to my email<EMAIL_ADDRESS>

i have the same issues exactly as you did. please if you found the solution to that problem, could you please forward it the procedure to my email<EMAIL_ADDRESS>* win10 64bit

same issue also. Any help would be appreciated.

Same issue. Did you guys manage to find a solution?

No.  I am not a techy.    So nothing for me todo but know I lost the coins sent there.

On Oct 6, 2017, at 8:17 AM, MudWar<EMAIL_ADDRESS>wrote:
Same issue. Did you guys manage to find a solution?
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub, or mute the thread.

Download this config file , it contain some nodes https://mega.nz/#!WQNDABhD!RJelGZ9ZJBDHVfT8jFO_l6jWM00puGcsBv5U6j6Rdc8  and then on windows os click on start and write this  %appdata%  and hit enter  then look for bitconnectcoin folder and copy the file that you just download it to the bitconnectcoin folder and now start the wallet and wait for a few minutes and see if you get any connection

Hi. Please check if this article helps. Please also check the comments there:
https://bitconnectexplained.wordpress.com/2017/09/03/how-to-make-bitconnect-wallet-work/
If it helps or you find some other solution please make a comment there. Thanks in advance and happy compounding. If you also don't already have a BitConnect sponsor you can choose me - I'm sharing the profits - details on that same blog.

@scorpio18 you are a rockstar! Thank you! Connected and syncing :)

i have the same issues exactly as you did. please if you found the solution to that problem, could you please forward it the procedure to my email<EMAIL_ADDRESS>* win7 - 64bit

It worked using a pc. I could not get my mac to find a connection. maybe there will be an update in the future for mac but until then I recommend downloading it on a pc.

Hi,
I had the same issue but, after I used this method, it was resolved using Windows computer:
Download this config file , it contain some nodes https://mega.nz/#!WQNDABhD!RJelGZ9ZJBDHVfT8jFO_l6jWM00puGcsBv5U6j6Rdc8 and then on windows os click on start and write this %appdata% and hit enter then look for bitconnectcoin folder and copy the file that you just download it to the bitconnectcoin folder and now start the wallet and wait for a few minutes and see if you get any connection.
Regards;
-----Original Message-----
From: "SMALLS"<EMAIL_ADDRESS>Sent: 10/10/2017 8:52 PM
To: "bitconnectcoin/bitconnectcoin"<EMAIL_ADDRESS>Cc: "Sayiha1085"<EMAIL_ADDRESS>"Comment"<EMAIL_ADDRESS>Subject: Re: [bitconnectcoin/bitconnectcoin] 0 Active Connections (#13)
It worked using a pc. I could not get my mac to find a connection. maybe there will be an update in the future for mac but until then I recommend downloading it on a pc.
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub, or mute the thread.

Sayiha1085
I don’t get start this program
Enviado do meu Smartphone
Em 10 de out de 2017, à(s) 17:04, Sayiha1085 <notifications<EMAIL_ADDRESS>escreveu:
Hi,
I had the same issue but, after I used this method, it was resolved using Windows computer:
Download this config file , it contain some nodes https://mega.nz/#!WQNDABhD!RJelGZ9ZJBDHVfT8jFO_l6jWM00puGcsBv5U6j6Rdc8 and then on windows os click on start and write this %appdata% and hit enter then look for bitconnectcoin folder and copy the file that you just download it to the bitconnectcoin folder and now start the wallet and wait for a few minutes and see if you get any connection.
Regards;
-----Original Message-----
From: "SMALLS" <notifications<EMAIL_ADDRESS>Sent: 10/10/2017 8:52 PM
To: "bitconnectcoin/bitconnectcoin" <bitconnectcoin<EMAIL_ADDRESS>Cc: "Sayiha1085" <ibrahimayuba2016<EMAIL_ADDRESS>"Comment" <comment<EMAIL_ADDRESS>Subject: Re: [bitconnectcoin/bitconnectcoin] 0 Active Connections (#13)
It worked using a pc. I could not get my mac to find a connection. maybe there will be an update in the future for mac but until then I recommend downloading it on a pc.
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub, or mute the thread.
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHubhttps://github.com/bitconnectcoin/bitconnectcoin/issues/13#issuecomment-335591170, or mute the threadhttps://github.com/notifications/unsubscribe-auth/AfK58dP52y9Q1Z0Znr7SVy_kIRO2EBn6ks5sq82vgaJpZM4Pb13g.

It already worked, im using win10 64bit, wait 2 hour to connect succesful
On Wed, Oct 11, 2017 at 4:11 PM, DiogenesAdv<EMAIL_ADDRESS>wrote:

Sayiha1085
I don’t get start this program
Enviado do meu Smartphone
Em 10 de out de 2017, à(s) 17:04, Sayiha1085<EMAIL_ADDRESS><EMAIL_ADDRESS>escreveu:
Hi,
I had the same issue but, after I used this method, it was resolved using
Windows computer:
Download this config file , it contain some nodes
https://mega.nz/#!WQNDABhD!RJelGZ9ZJBDHVfT8jFO_l6jWM00puGcsBv5U6j6Rdc8
and then on windows os click on start and write this %appdata% and hit
enter then look for bitconnectcoin folder and copy the file that you just
download it to the bitconnectcoin folder and now start the wallet and wait
for a few minutes and see if you get any connection.
Regards;
-----Original Message-----
From: "SMALLS" <notifications<EMAIL_ADDRESS>Sent: 10/10/2017 8:52 PM
To: "bitconnectcoin/bitconnectcoin"<EMAIL_ADDRESS><EMAIL_ADDRESS>Cc: "Sayiha1085"<EMAIL_ADDRESS><EMAIL_ADDRESS>"Comment"<EMAIL_ADDRESS><EMAIL_ADDRESS>Subject: Re: [bitconnectcoin/bitconnectcoin] 0 Active Connections (#13)
It worked using a pc. I could not get my mac to find a connection. maybe
there will be an update in the future for mac but until then I recommend
downloading it on a pc.
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub, or mute the thread.
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub<https://github.com/
bitconnectcoin/bitconnectcoin/issues/13#issuecomment-335591170>, or mute
the thread<https://github.com/notifications/unsubscribe-
auth/AfK58dP52y9Q1Z0Znr7SVy_kIRO2EBn6ks5sq82vgaJpZM4Pb13g>.
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/bitconnectcoin/bitconnectcoin/issues/13#issuecomment-335747001,
or mute the thread
https://github.com/notifications/unsubscribe-auth/Ae0qav_ADeTvJCj9FAOT2MkfG3G_4b4eks5srIYrgaJpZM4Pb13g
.

--
Best regards,
Do Thanh Hai | Skype<EMAIL_ADDRESS><EMAIL_ADDRESS>

It´s ok. \o/

Thank you.  3 people have posted the same file to download.  This did not solve my issue.   The only thing next I will try is to turn off my internet protection programs.    I have no connection and had sent in Oct 9 bitconnect coins to my wallet address before realizing that is said "not synched"
I am not in a network, only my computer wireless connected to my router.

If it's wireless, that's probably the problem - you're actually in a LAN.
You need to forward the BitConnect port at your router's settings. Check
how to do that:
https://bitconnectexplained.wordpress.com/2017/09/03/how-to-make-bitconnect-wallet-work/
2017-10-18 19:43 GMT+02:00 efsaturn<EMAIL_ADDRESS>
Thank you. 3 people have posted the same file to download. This did not
solve my issue. The only thing next I will try is to turn off my internet
protection programs. I have no connection and had sent in Oct 9 bitconnect
coins to my wallet address before realizing that is said "not synched"
I am not in a network, only my computer wireless connected to my router.
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/bitconnectcoin/bitconnectcoin/issues/13#issuecomment-337671086,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AGNfjmytY8KWCJ-81DhbHrUz9xnjYbr5ks5stjivgaJpZM4Pb13g
.

I am in the same boat.  Port 9239 is forwarded in my router for my IP address, but my bitconnect wallet just says (out of sync) and there are no connections in the bottom right corner.  Any suggestions are appreciated.

I’m in the same position as sethmo38. Can anyone verify the network proxy parameters they are using to make the wallet work? When I use the default port 9050 I get zero connections. When I use port 9239 I get 2-3 connections but no sync.

I figured it out. It did not create a bitconnect.conf file in my appdata folder. Download the bitconnect.conf file that Sayiha1085 posted and it should work.

What are you network settings?

 I adding the configuration file with the nodes so I’ll see if it will connect by the time I get back home

Still nothing

Solution for mac users:
Download the config file from the following link as scorpio mentioned https://mega.nz/#!WQNDABhD!RJelGZ9ZJBDHVfT8jFO_l6jWM00puGcsBv5U6j6Rdc8

Close bit connect wallet
Copy the downloaded bit connect.config file into the following path in mac:
/Users/Username/Library/Application Support/bitconnect
note: replace "Username" with your mac user name
Repoen Bitconnect wallet and you should have couple of active connections.
let it open and sync for couple of hours.

Good Luck!
Prabin

Ok this worked.  I had to configure the node.  I have a gateway modem so
the set up was a little confusing but finally figured it out.   When I
first opened the wallet it still said "0 active nodes" but a few seconds
later it showed bars and I had 1 bar and the note said "1 active
connection" and now after a few hours (it is reading a lot of blocks) has
my 10.24 BCC that I bought on 9/18.    I believe each 1 has increased about
$100.
Thank you, I didn't want to lose any more money.  But it is recovered.
On Wed, Oct 18, 2017 at 4:32 PM, Julian S<EMAIL_ADDRESS>wrote:

If it's wireless, that's probably the problem - you're actually in a LAN.
You need to forward the BitConnect port at your router's settings. Check
how to do that:
https://bitconnectexplained.wordpress.com/2017/09/03/how-
to-make-bitconnect-wallet-work/
2017-10-18 19:43 GMT+02:00 efsaturn<EMAIL_ADDRESS>
Thank you. 3 people have posted the same file to download. This did not
solve my issue. The only thing next I will try is to turn off my internet
protection programs. I have no connection and had sent in Oct 9
bitconnect
coins to my wallet address before realizing that is said "not synched"
I am not in a network, only my computer wireless connected to my router.
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
<https://github.com/bitconnectcoin/bitconnectcoin/
issues/13#issuecomment-337671086>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AGNfjmytY8KWCJ-
81DhbHrUz9xnjYbr5ks5stjivgaJpZM4Pb13g>
.

—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/bitconnectcoin/bitconnectcoin/issues/13#issuecomment-337757222,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AemYpeBK6aHPVZeBKOz5imcRNTPv-ntZks5stopygaJpZM4Pb13g
.

mine initially said "0 connections" but a few seconds later it did connect
and say "1 connection" maybe you closed it too soon.
On Sat, Oct 21, 2017 at 9:40 PM, sethmo38<EMAIL_ADDRESS>wrote:

I am in the same boat. Port 9239 is forwarded in my router for my IP
address, but my bitconnect wallet just says (out of sync) and there are no
connections in the bottom right corner. Any suggestions are appreciated.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/bitconnectcoin/bitconnectcoin/issues/13#issuecomment-338451016,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AemYpd7cXWBhQsZ4lZo4dpKa-rU2wDvjks5susdCgaJpZM4Pb13g
.

@efsaturn I'm glad it worked for you! 👍 I'm trying still to resolve sync issues. I have 3 active connections but taking way too long to sync!

Hello Prabin, I than you for helping the people (myself included) who are stuck with this wallet on their Mac's.
However I still can't seem to fix it.
I've downloaded the file that you posted and it's one that my mac says that it can't open or read. But also I have no idea how you 'copy the file' to /Users/Username/Library/Application Support/bitconnect
I can't figure out how to even find that location on my mac?! Do I use the search function, file function. I literally have no idea how to copy that file and place it where it needs to go  :(
I sound like such a tech simpleton right now

Hello @brokerstar, You don't have to open the file. Do the following to find the folder.

type /Users in the search bar
you will find couple of folders like guest, shared, and your username
open the folder that has the name of your username
then you can navigate to Library --> Application Support --> Bitconnect

Paste the file in this location. Close bit connect wallet and open it again. Let me know if it works.
Good luck :)

I think that's the problem. When I click users, then click on my user name, the next section that opens up doesn't have the options you mentioned.
I have desk top, documents, downloads, movies, music, pictures, public and applications.
I am using a MacBook Air, not sure if that has a baring on it?
Kind regards
Broker

I'm not sure if it's because maybe I'm using a MacBook Air?!
When I click on my user name, I do not have the options that you mentioned. I get the following: desktop, documents, downloads, movies, music, pictures, public, applications.

@brokerstar I think your hidden files are not visible
do the following to see all hidden files:

Open Terminal found in Finder > Applications > Utilities or simply search for terminal on search
In Terminal, paste the following: defaults write com.apple.finder AppleShowAllFiles YES
Press return
Hold the ‘Option/alt’ key, then right click on the Finder icon in the dock and click Relaunch.

let me know if this works

Ok, we have some change! So now I can see a section that says library (after I click on username), but it's faded out and it doesn't open when I click on it?

@brokerstar Indeed, It should be faded out. But it is not normal that it doesn't open.. :)
Did you relaunch the finder? if yes, then Try restarting your mac and it should work.
Let me know how it goes.. :)

I've shut the computer down totally and re-started it. The Library file is still showing, it's still faded,
ghost like (as you said it should be) but it still doesn't open, in fact none of the faded looking files that are on display (which were not there before) open?!
I'm glad this wasn't just me being totally IT illiterate, although I am for the most part ha ha.
Wish I'd sent a smaller test amount to that wallet now :/

@brokerstar Try this:

Note down the name of your user folder --> Let's say it is brokerstar
Press Shift-Cmd-G and paste /Users/brokerstar/Library and press Enter

See if it opens the folder. Let me know..

Ummm, that just opens a box on the top right of my screen, and when I type it in and press enter, it highlights matching words on the screen in orange?
My username is two names (first name and second name) do I simply type that in with no spaces? If that's the case, then it's still not working either.
I'm using El Capitan software and it's a fairly old MacBook Air, not sure if that has any baring on it either?

@brokerstar RIghtclick on the faded Library folder and select 'Get info'. See if the Locked option is unchecked?
To make it easy on the username, it is the name of the folder where Library is.. :) copy the name and use it in the path.. aka replacing brokerstar

Ok that's the pathway I entered then. Ok so I've right clicked on the file and other than the name of the file turning blue, nothing else happens. I tried left and right clicking, nothing at all. All of the none faded icons open fine though.

@brokerstar May be look at some Mac forum to find a solution. In the meantime, take a backup of your wallet and store it somewhere safe so that you don't loose your BCC coins..

Thanks man! But there are no coins in it, I sent some coins from my Bitconnect account to the wallet, and they never turned up :(

That's alright... It will show up in the wallet after you get the wallet to sync.
 :)

Thank you again for all of your help. I took your advice and went to a Mac forum where in the end this was the command line that opened up the library for me to access: chflags nohidden ~/Library
The wallet is working again now, so thank you so much.
Let me know if you have a Bitcoin tips/ donation link for your help! :)

I’m glad it worked finally! :)
There you go!
BTC: 1Ko7rmPfRKXiWhg3mZHcRaP62hyRUSvHFF

@scorpio18: Your file solved my problem, thank you!

@brokerstar the reason you cannot see these file folders is because they are hidden on your mac, there is a simple solution so you can see hidden folders. Open Finder, select your HD. You should then see Applications, Library, System. Hold down  <.>  for about 3 seconds, then you should see all the hidden files pop up. Click Users - Username (thats you) - Library - Application Support - bitconnect. That will take you to where you need to copy the config file. However, I have done this, and although I have gotten 1-3 connections, it doesn't seem to be downloading anything, no progress bar like I have seen others get.

Hi there, is there any other way to solve the 0 connection problem. As I have my mac connected and staking with no problems, but my windows 10 pc is not connecting. I have downloaded and pased the config file in the folder. still nothing. anyone that solved this without messing with router configurations etc? thanks

alright, I have read every comment and followed every piece of advice. I have turned off all firewalls, antivirus, what-have-you, before downloading. I've run as administrator. I've deleted all files except wallat.dat and started over. I downloaded the bitconnect.conf file and placed it in the bitconnect folder.
The only time I get connections is if I check the Connect through SOCKS proxy with a Proxy IP of <IP_ADDRESS> (default) POrt 9239 and SOCKS v.5. Even with the 2-3 connection I get, it will not sync. I check the debug file and nothing. not a single block. What am I doing wrong.
Also, I cannot modify my router settings. I'm in an area where it is not accessible and has been locked out by admin.

Same issue, has that file been changed?

None of the addnode=<...> seem to connect, despite many network configurations
I don't see a Username field or line as described in the instructions above  (from @prabinjoel  )
Using proxy only disguises the connection issue
Most of this determined from looking in the debug logs

I'm so angry, I'm gonna have to go buy a damn PC just so I can access my wallet. Damn it!!!!!! I'm literally going to buy a pc today so I can access my BCC, transfer them out of my account, and back into BTC.

In the bitconnect.conf file which in place in the appdata fokder, donI need to change the user id and password to something else ?
It says your user ID and your password ?
Help please !

@kapilmar There is no userid or password in the config file, it is just a list of nodes. You need to place it in the C:\Users[your_username]\AppData\Roaming\bitconnect folder, and restart bitconnect-Qt. Then wait for a couple of minutes, and you will see it connecting to the nodes.

MY SOLUTION - MY UPDATED CONFIG FILE (WIN 7)
Copy the config file to the data directory C:\ Users \ USERNAME \AppData\Roaming\bitconnect
bitconnect_config_win_updated.zip
Okay I spent a couple nights working on this. Thanks to Wedwo and RJohnson3 for their helpful posts. It appears that the CONFIG file is missing and not in the data directory. The "install program" doesn't really install anything. It's more like a self executable that drops files into a hidden data directory in your user profile. Here's my solution for WIN 7 32- bit and 64-bit OSes.

First disable all firewall and anti-virus programs

Extract the Bitconnect program to a new folder under Program Files of your choice. Run the BitConnect-window executable once to create the data directory. Then close it.

Find the hidden data directory C:\Users\ USERNAME \AppData\Roaming\bitconnect
USERNAME=whatever you are logged in as

Download the config file provided by Wedwo and append it with rJohnson3's addresses. I will try to attach my config file here to help you. You can clean it up with a text editor. See the above link for my updated config file.

Copy the config file to the data directory C:\Users\ USERNAME \AppData\Roaming\bitconnect

Leave all firewall and anti-virus programs off and Re-Run the Bitconnect program.

The program should connect within a couple mins. Just be patient.  Re-Run your program from the Program Files after installing the config file and create a shortcut for future use. Check the debug file Help | Debug window | Open Debug log and scroll all the way to the bottom to see the latest updates. It should say connecting to DIFFERENT addresses. If it only mentions one address, then the config file is not in the right place or not configured right. It should be trying to connect to multiple addresses.

You can add port forwarding (TCP, UDP port 9239) to your router but that's optional.

Downloading should take about 3 hours +

Re-enable firewall and anti-virus. Add the program and port 9239 to a white list. You can always just use the default firewall in Windows 7. Easier to use. If the firewall or anti-virus gives you hell, just leave it off. I would not use your personal computer with all of your important files on it. Use a dedicated computer or junk computer.

Summary
BitConnect program = runs from the folder you choose (Program Files or anywhere)
Data Supporting Directory = hidden in the user profiles.
C:\ Users \ USERNAME \ AppData \ Roaming \ bitconnect
You can see this in the debug file at the very top when it is first created.
Install the config file here.

had the same issue and there response was
Bitconnect Support team : New blocks are continuously being created (about once every 2 minutes).
So if you don't leave your client continuously connected, or when you're connecting for the first time, then when you do connect it will be out of sync and need to download and verify new blocks.
You need to wait until download the bitconnect blockchain. Don't worry about your balance, it will back in your wallet after download bitconnect blockchain successfully.
Thanks!
Oct 15, 2017 11:15 PM (System)

I'm very new to this and I have to say thank you to everyone who contributed as I have it up and running no probs anymore. Thumbs up to you.
Druccy

You can follow this guide: https://bitconnect.co/bitconnect-learning/77/how-to-solve-synchronization-issue-on-the-desktop-wallet


[ffmpeg] [Build error] [configure] [test_ld failed]

Host Environment

OS: Windows-10
Compiler: MSVC-19.0.24215.1
vcpkg-tool version: 2022-05-05-67e17c1782801cf481be9ac0b3765dff3e4bdeb8
vcpkg-scripts version: 162a88fa4 2022-07-28
ffmpeg verson: 4.4.1#14

To Reproduce
Steps to reproduce the behavior:
./vcpkg install ffmpeg:x86-windows-static
Failure logs

ConsoleCMake Error at scripts/cmake/vcpkg_execute_required_process.cmake:96 (message):
    Command failed: D:/App/vcpkg/downloads/tools/msys2/79d5b6b790550399/usr/bin/bash.exe ./build.sh
    Working Directory: D:/App/vcpkg/buildtrees/ffmpeg/x64-windows-static-rel
    Error code: 1
    See logs for more information:
    D:\App\vcpkg\buildtrees\ffmpeg\build-x64-windows-static-rel-out.log

Call Stack (most recent call first):
ports/ffmpeg/portfile.cmake:548 (vcpkg_execute_required_process)
scripts/ports.cmake:147 (include)

build-x64-windows-static-rel-out.log=== CONFIGURING ===
cl.exe is unable to create an executable file.
C compiler test failed.

If you think configure made a mistake, make sure you are using the latest
version from Git.  If the latest version fails, report the problem to the
<EMAIL_ADDRESS>mailing list or IRC #ffmpeg on irc.libera.chat.
Include the log file "ffbuild/config.log" produced by configure as this will help
solve the problem.

config.logtest_ld cc
test_cc
BEGIN /c/Users/XXXX/AppData/Local/Temp/ffconf.xmA29ylu/test.c
    1	int main(void){ return 0; }
END /c/Users//AppData/Local/Temp/ffconf.xmA29ylu/test.c
cl.exe @D:/App/vcpkg/buildtrees/ffmpeg/x64-windows-static-rel/cflags.rsp -nologo -DHAVE_UNISTD_H=0 -c -Fo/c/Users/XXXX/AppData/Local/Temp/ffconf.xmA29ylu/test.o /c/Users/XXXX/AppData/Local/Temp/ffconf.xmA29ylu/test.c
test.c
C:\Users\XXXX\AppData\Local\Temp\ffconf.xmA29ylu\test.c : fatal error C1083: Cannot open compiler generated file: 'D:\c\Users\XXXX\AppData\Local\Temp\ffconf.xmA29ylu\test.o': No such file or directory
C compiler test failed.

Additional context
The issue is clear that test_ld uses a wrong path[D:\c\Users\XXXX\AppData\Local\Temp\ffconf.xmA29ylu\test.o], which actully is path[C:\Users\XXXX\AppData\Local\Temp\ffconf.xmA29ylu\test.o]

D:\c\Users\XXXX\AppData\Local\Temp\ffconf.xmA29ylu\test.o this path is incorrect.

Can you please provide full log config.log?
Thanks.

Can you please provide full log config.log?
Thanks.

config.log

cl.exe @D:/App/vcpkg/buildtrees/ffmpeg/x64-windows-static-rel/cflags.rsp -nologo -DHAVE_UNISTD_H=0 -c -Fo/c/Users/RHTX/AppData/Local/Temp/ffconf.xmA29ylu/test.o /c/Users/RHTX/AppData/Local/Temp/ffconf.xmA29ylu/test.c

source code: in configure:
test_cc(){
    log test_cc "$@"
    cat > $TMPC
    log_file $TMPC
    test_cmd $cc $CPPFLAGS $CFLAGS "$@" $CC_C $(cc_o $TMPO) $TMPC
}

The test tmp file path should be relative, not absoult.

cc @dg0yt Any ideas for this cross check?

Just tried ffmpeg:arm64-linux:
The portfile's prefix detection is wrong and passes --cross-prefix=/<path>/aarch64-linux-gnu- when it should pass aarch64-linux-gnu-.
https://github.com/microsoft/vcpkg/blob/e6a000679745f8ea3f98067e5f3753d3cbecb948/ports/ffmpeg/portfile.cmake#L463-L466
Here, the regex should be: "([^\/]*-)gcc$". I just added related code in the x264 PR.

@Tangle-1990 Could you please test the modification of dg0yt locally? Thank you!

@Tangle-1990 Could you please test the modification of dg0yt locally? Thank you!
Well, the solution is not work. I checked the configure file, it seems that cl.exe not support unix-like absolute path[like "/c/Users/RHTX/AppData/Local/Temp/ffconf.xmA29ylu/test.o"] and in the msys2 envirenment cl.exe dosen't transfer the unix-like path to window-like path but regards the unix-like path as a relative path.

@Cheney-W My comment only deals with cross_prefix, https://github.com/microsoft/vcpkg/issues/26048#issuecomment-1204849497. Windows triplets is a different story.
-Fo/c/Users/XXXX/AppData/Local/Temp/ffconf.xmA29ylu/test.o seems to target
C:\Users\XXXX\AppData\Local\Temp\ffconf.xmA29ylu\test.o, but the error message reports
D:\c\Users\XXXX\AppData\Local\Temp\ffconf.xmA29ylu\test.o. At some point, there is a conversion missing between Windows paths (C:) and MSYS Unix paths (/c). Maybe a missing compiler wrapper?

Hi, I checked the configure file, there is a option "--toolchain" could impact the tmpdir path, but the configure executes with this parameter not setted.
And there is code chunk in portfile.cmake which would set --toolchain
if(VCPKG_DETECTED_MSVC)
    set(OPTIONS "--toolchain=msvc ${OPTIONS}")
    # This is required because ffmpeg depends upon optimizations to link correctly
    string(APPEND VCPKG_COMBINED_C_FLAGS_DEBUG " -O2")
    string(REGEX REPLACE "(^| )-RTC1( |$)" " " VCPKG_COMBINED_C_FLAGS_DEBUG "${VCPKG_COMBINED_C_FLAGS_DEBUG}")
    string(REGEX REPLACE "(^| )-Od( |$)" " " VCPKG_COMBINED_C_FLAGS_DEBUG "${VCPKG_COMBINED_C_FLAGS_DEBUG}")
    string(REGEX REPLACE "(^| )-Ob0( |$)" " " VCPKG_COMBINED_C_FLAGS_DEBUG "${VCPKG_COMBINED_C_FLAGS_DEBUG}")
endif()

it seems that vcpkg not detects msvc.

add --toolchain msvc for MSVC in portfile.cmake

@Tangle-1990  Can you please add set(OPTIONS "${OPTIONS} --toolchain=msvc") to ports/ffmpeg/portfile.cmake line 519 then try again?
if(CC_path)
    vcpkg_add_to_path(PREPEND "${CC_path}")
endif()
set(OPTIONS "${OPTIONS} --toolchain=msvc")
message(STATUS "Building Options: ${OPTIONS}")

Thanks.

add --toolchain msvc for MSVC in portfile.cmake

I have tried add this, and build success with msvc.
Sorry, I miss this comment https://github.com/microsoft/vcpkg/issues/26048#issuecomment-1207719518 before my last comment.

@Tangle-1990 Can you please add set(OPTIONS "${OPTIONS} --toolchain=msvc") to ports/ffmpeg/portfile.cmake line 519 then try again?
if(CC_path)
    vcpkg_add_to_path(PREPEND "${CC_path}")
endif()
set(OPTIONS "${OPTIONS} --toolchain=msvc")
message(STATUS "Building Options: ${OPTIONS}")

Thanks.

Hi, guys. Sorry for reply to you so late. Well, I add --toolchain=msv at portfile.cmake:101
elseif(VCPKG_TARGET_IS_WINDOWS)
    string(APPEND OPTIONS " --target-os=win32")
    string(APPEND OPTIONS " --toolchain=msvc")
elseif(VCPKG_TARGET_IS_OSX)

where I think wouldn't break down it's portablity, and now I build ffmpeg succeed.
But I thought the best fixed is to find out why VCPKG_DETECTED_MSVC not setted.


Desktop Duplication, Nvenc Encoding Issue

Desktop Duplcation : DXGI_NOT_SUPPORTED
Nvenc Encoding : SetSharpDevice Issue
(in my laptop)

maybe it wasn't a bug, or graphics card driver issue


Provide a solution for Null-values

If the data source does not contain a value in a data field, an error message appears when the HTML file is created.
A solution is needed for this.

Fixed with version 1.30.02


Update doc sample app + sizeToFit() documentation

Update example app source code
Plus:

Add missing sizeToFit() documentation.
Add links to sample app's example source code

Codecov Report

Merging #71 into master will not change coverage.
The diff coverage is 100%.

@@          Coverage Diff           @@
##           master     #71   +/-   ##
======================================
  Coverage    99.3%   99.3%
======================================
  Files          15      15
  Lines        3617    3617
======================================
  Hits         3592    3592
  Misses         25      25

Impacted Files
Coverage Δ

Tests/AdjustSizeSpec.swift
100% <100%> (ø)
:arrow_up:

Continue to review full report at Codecov.

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


cmd/vet: Doesn't complain when the field tags are not parsable by the reflect: StructTag.Get() call

Hi, I have noticed a problem with go vet that have stung me recently.
Go vet doesn't report an error in the field tag formatting.
Let's take an example struct :
// TestStruct comment
type TestStruct struct {
	A string `json:"jsona",xml:"xmla"`
}

As you can see I have set the field tags, and while the tags looks OK, the tag format is incorrect. To illustrate, the example code:
package main

import (
	"fmt"
	"reflect"
)

// TestStruct comment
type TestStruct struct {
	A string `json:"jsona",xml:"xmla"`
}

func main() {

	var theStruct = TestStruct{"A"}

	fmt.Println("First field tag: ", reflect.TypeOf(theStruct).Field(0).Tag)
	fmt.Println("Json tag value:  ", reflect.TypeOf(theStruct).Field(0).Tag.Get("json"))
	fmt.Println("XML tag value:   ", reflect.TypeOf(theStruct).Field(0).Tag.Get("xml"))
}

Did return
First field tag:  json:"jsona",xml:"xmla"
Json tag value:   jsona
XML tag value:

The problem here is the coma character between json and xml tags.
The go vet tool doesn't complain about this type of error and I would like to fix it if it is OK.
I will raise a pull request if the maintainers agree that this is a bug in the go vet tool indeed.

Yes, i think go vet should detect this case. But note that we don't use
pull request, please send a CL instead. See
https://golang.org/doc/contribute.html.

Actually the tags are parseable in this case. The tag json:"jsona",xml:"xmla" is the same as json:"jsona" ,xml:"xmla". That is, there is an entry with key json and an entry with key ,xml. If you did tag.Get(",xml") you could retrieve the second one.
That said, it's obviously a mistake and probably one vet should catch even though it's not technically illegal. Will send a CL.


Installing hooks for Windows functions fails (64-bit)

We are currently experiencing a lot of issues installing hooks in 64-bit Windows functions that worked just fine half a year ago.
For example:
UnmapViewOfFile (module Kernel32.dll) throws "Hooking near (conditional) jumps is not supported."
RegDeleteKeyTransactedA (module advapi32.dll) throws "Hooking near conditional jumps is not supported."
RegDeleteKeyTransactedW (module advapi32.dll) throws "Hooking far conditional jumps is not supported."
And besides that, installing a hook in RegOpenKeyExW (module advapi32.dll) does not throw an exception, but the hook does not work as intended. The function starts with a relative jump ("48 FF 25 19 EC 09 00"), which is copied verbatim to the end of the hook (which is at a different address). Calling the function after installing the hook results in an access violation.
There are probably more functions with similar problems, but this is what we encountered so far.
Are you aware of this issue (and the fact those same functions worked fine earlier)?
Do you have any idea if can or will fix these problems and when?
Is there a way we can motivate you to look at this issue sooner? ;)
Maarten
Senior Developer
www.utomik.com

Hi Maarten, those APIs may have changed since before perhaps? Or is this a problem that only occurs in the latest version?
The RegOpenKeyExHook one could be a bug that I'll have to look at. You can contact me direct if you would like to discuss options for me helping you out with the first couple of hooks.
Cheers,
Justin

Hi Justin,
Thanks for the quick response.
We are using the same EasyHook source as we did 6 months ago. And I'm sure the mentioned hooks worked fine back then. We can only assume the implementation in the dll files was updated by Microsoft.
I have send you an email.
Maarten

Hi Maarten,
On Windows 10 x64.
Running the TestFuncHooks.exe here replicates the issue you have with RegDeleteKeyTransactedA. The tool seems to be having trouble reading the export redirection as for advapi32.dll it is saying most functions are redirected to another function, might be the case just seems a bit prolific so might need to test - if it is correct then you can hook one of the methods it "says" it redirects to.
UnmapViewOfFile seems to be fine. Haven't looked at RegOpenKeyExW.
Cheers,
Justin

It appears that MacType font smoothing is using EasyHook or some variation that's named EasyHK. With the recent Windows 10 Anniversary update 1607 there is a need to use patched EasyHK dll's which are available (MacType-Patch 1.12). The EasyHK32.dll patch is working but not the EasyHK64.dll so it looks like MacType-Patch developers and users are waiting for EasyHook to fix its 64-bit issues. I have had to change my Firefox browser from 64-bit to 32-bit in order to continue to enjoy using MacType but all other native 64-bit processes such as file explorer dialogs are not able to use MacType's font smoothing.
Regards,
Walter

@shunk380 what 64-bit issues are you referring to?

@spazzarama In the MacType Details box (see screenshot) which is a list of application processes where MacType loading status shows as running, disabled or in error, MacType shows an error when trying to load for all of the 64-bit processes. For all of the 32-bit processes, MacType loads and shows as running. I couldn't find any more information on the nature of the error in any log file or in the Windows event viewer.

@shunk380 thanks although unfortunately this doesn't help identify if the problem is in EasyHook or not and if so what the problem might be, it could simply be that one of the APIs have changed that are being hooked and are no longer compatible.
Meanwhile I'll check if I have similar issues with latest win10 in tests

I confirm this issue is happening to me aswell


C++ code for Preorder, Inorder, Post-order and Level-order Traversal of a Binary Tree

Aim
Objectives of the script:

Clear and concise code for preorder, inorder, postorder and level order traversals of a Binary Tree
Decoding and understanding the process of various methods of traversals in a binary tree

Details
Features of the script:

Efficient and easy-to-understand code (fully working, along with the main function)
I will be covering multiple approaches with time complexity analysis
Step-by-step explanation of the solution will be provided
Can you assign me this issue under HacktoberFest 2021?

Programming language

[ ] C
[x] C++
[ ] Java
[ ] Python

@Ayush7614 Can you assign me this issue under HacktoberFest 2021?

@Ayush7614 I can add these solutions in Java. Can you please assign me this issue?


Improve SPOOF Protection protecting FROM header

SPOOF protection is not complete, we can still cheat "From" field.
Context

We need to ensure From field in email is owned by connected user sending email.
Expected Behavior

If FROM field is not owner by connected user sending email, email must be refused and not sent.
Actual Behavior

You can still SPOOF even using SPOOF_PROTECTION. How ? Using From mail header.
SPOOF_PROTECTION enables smtpd_sender_login_maps/smtpd_sender_restrictions, which protects MAIL FROM. However, you can still spoof using FROM field in mail header. This is not currently protected in Docker MailServer
Possible Fix

According to https://unix.stackexchange.com/a/567047, it can't be solved directly in Postfix. It can be solved using Milter. I didn't test. We're using LDAP and I don't know compatibility.
Steps to Reproduce

Enables SPOOF_PROTECTION
Send an email with FROM Header (!= MAIL FROM sent to SMTP)
Receive email with spoofed address

Your Environment

Amount of RAM available: 8 Go
Mailserver version used: v6.2.1
Docker version used: 19.05.03
Environment settings relevant to the config:
Any relevant stack traces ("Full trace" preferred):

Thanks for the good detective work. Personally I would not like to fix this if it is not supported in upstream. For me the risk that authenticated users that are allowed to send e-mail can spoof their From headers is a lesser evil than the more complex and error-prone setup with a milter for this. We could of course make it optional so that it is turned on by a new option or by code in user-patches.sh (with a wiki that describes how).

This issue was closed due to one or more of the following reasons:

Age
Contributor inactivity
The issue seems to be resolved

If you think this happened by accident, or feel like this issue was not actually resolved, please feel free to re-open it. If there is an issue you could resolve in the meantime, please open a PR based on the current master branch so we can review it.


Adding Animations and Transitions

I would like to add some animations/transitions to the home page to make it look for interactive and appealing

I want to work on this issue as a contributor.
Pleasure Assign so that I can show my skills under GSSoC'23.


Propose a new top level hierarchy

What this PR does / why we need it

Towards https://github.com/giantswarm/giantswarm/issues/29977
Miro screenshot

Things to check/remember before submitting

If you made content changes

Run make dev to render and proofread content changes locally.
Bump last_review_date in the front matter header if you reviewed the entire page.

Another thought I had: Do we need "Getting Started" on the top level?
I'm imagining "Getting Started" as a step by step tutorial, which would feat neatly into the "Tutorials" section.

Imo a "Getting started" section is quite common and also worth to highlight on the top level. This should cover all the basics and yes most likely in a hands-on (tutorial-like) style.

The PR however doesn't make sense to me, as the actual pages are empty and not accessible. The front page links still lead to the vintage section, which I found confusing. I see no reason to merge this PR in the current state.

I am going ahead here after some days for reviews. We can always polish future PRs


Fix: build script

Describe the changes
This PR updates the build script to only run when a:

PR is opened or marked as "ready for review"
OR a commit contains changes in any of the following files/directories:

icicle/**
src/**
Cargo.toml
build.rs

@jeremyfelder Merge with https://github.com/ingonyama-zk/icicle/commit/c63fa6299182402109476c30fa5670b346e95390 - Rust code style check addition

@jeremyfelder Merge with c63fa62 - Rust code style check addition

@LeonHibnik Do we want to run both?
It might be a good idea to have a separate PR that introduces them as checks and fixes the warnings/changes they are currently producing otherwise we will be forced to bypass the checks until it is fixed.

It might be a good idea to have a separate PR

Updated to be a part of #107


Merge example utilities

[] Plotting utils vs. plotting helpers
[] Example setups for the box and sedimentation models
### Tasks
- [ ] Merge plotting utils and plotting helpers

@sajjadazimi

Closes #89