[fpga] CW310 sporadic USB hang when setting PLLs

We use the CW310 board in CI and frequently flash the bitstream and load OpenTitan software over SPI (spiflash). All board interaction is going through cw310_loader.py (https://github.com/lowRISC/opentitan/blob/master/util/fpga/cw310_loader.py), which uses the ChipWhisperer Python APIs.
In most cases, this works fine.
However, in some cases (like 1 in 100 runs) the board "hangs" over USB, i.e. it doesn't respond over USB any more. Even though this is a tricky problem to debug, we need to find a way to make it work reliably with a much lower failure probability.
What I know so far:

The failures we've seen so far are happening when loading the software over SPI ("spiflash"), not when flashing the FPGA bitstream.
All board interaction is done from a Docker container, but I don't see anything indicating that this is causing problems. Neither the system, nor the container logs show any USB-related messages.
In the error cases we've seen, we had successful board interactions in the same container run preceding the failing ones.

Below is a log from a failing run where we tried to flash OpenTitan software onto the OpenTitan system. The bitstream was loaded earlier, and the same spiflash operation, with another software binary, was successful just seconds ago.
Command:
stdbuf -oL /azp/agent/_work/1/s/util/fpga/cw310_loader.py --firmware /azp/agent/_work/1/a/build-bin/sw/device/tests/dif_clkmgr_smoketest_fpga_nexysvideo.bin

STDOUT:
2021-06-08T02:13:36.0167869Z DEBUG    root:utils.py:363 CW310 Loader: Attemping to find CW310 FPGA Board:
2021-06-08T02:13:36.0169054Z DEBUG    root:utils.py:363     No bitstream specified
2021-06-08T02:13:36.0170184Z DEBUG    root:utils.py:363 Board found, setting PLL2 to 100 MHz

STDERR:
2021-06-08T02:13:39.2189113Z DEBUG    root:utils.py:363 Traceback (most recent call last):
2021-06-08T02:13:39.2190189Z DEBUG    root:utils.py:363   File "/azp/agent/_work/1/s/util/fpga/cw310_loader.py", line 65, in <module>
2021-06-08T02:13:39.2191050Z DEBUG    root:utils.py:363     main()
2021-06-08T02:13:39.2192104Z DEBUG    root:utils.py:363   File "/azp/agent/_work/1/s/util/fpga/cw310_loader.py", line 54, in main
2021-06-08T02:13:39.2193275Z DEBUG    root:utils.py:363     target.pll.pll_outfreq_set(100E6, 2)
2021-06-08T02:13:39.2195078Z DEBUG    root:utils.py:363   File "/root/.local/lib/python3.6/site-packages/chipwhisperer/hardware/naeusb/pll_cdce906.py", line 53, in pll_outfreq_set
2021-06-08T02:13:39.2196447Z DEBUG    root:utils.py:363     self.pllwrite(outnum, N=best[0], M=best[1], outdiv=best[2])
2021-06-08T02:13:39.2198074Z DEBUG    root:utils.py:363   File "/root/.local/lib/python3.6/site-packages/chipwhisperer/hardware/naeusb/pll_cdce906.py", line 338, in pllwrite
2021-06-08T02:13:39.2199255Z DEBUG    root:utils.py:363     self.cdce906write(13 + pllnum, outdiv & 0x7F)
2021-06-08T02:13:39.2200847Z DEBUG    root:utils.py:363   File "/root/.local/lib/python3.6/site-packages/chipwhisperer/hardware/naeusb/pll_cdce906.py", line 235, in cdce906write
2021-06-08T02:13:39.2202199Z DEBUG    root:utils.py:363     resp = self._usb.readCtrl(0x30, dlen=2)
2021-06-08T02:13:39.2203748Z DEBUG    root:utils.py:363   File "/root/.local/lib/python3.6/site-packages/chipwhisperer/hardware/naeusb/naeusb.py", line 796, in readCtrl
2021-06-08T02:13:39.2204941Z DEBUG    root:utils.py:363     return self.usbseralizer.readCtrl(cmd, value, dlen)
2021-06-08T02:13:39.2206364Z DEBUG    root:utils.py:363   File "/root/.local/lib/python3.6/site-packages/chipwhisperer/hardware/naeusb/naeusb.py", line 191, in readCtrl
2021-06-08T02:13:39.2207535Z DEBUG    root:utils.py:363     return self.process_rx(self.txrx(tx=cmdpacket))
2021-06-08T02:13:39.2208854Z DEBUG    root:utils.py:363   File "/root/.local/lib/python3.6/site-packages/chipwhisperer/hardware/naeusb/naeusb.py", line 299, in txrx
2021-06-08T02:13:39.2210325Z DEBUG    root:utils.py:363     response = self.usbdev().ctrl_transfer(payload[0], payload[1], payload[2], payload[3], payload[4], timeout=self._timeout)
2021-06-08T02:13:39.2211777Z DEBUG    root:utils.py:363   File "/usr/local/lib/python3.6/dist-packages/usb/core.py", line 1079, in ctrl_transfer
2021-06-08T02:13:39.2212627Z DEBUG    root:utils.py:363     self.__get_timeout(timeout))
2021-06-08T02:13:39.2213866Z DEBUG    root:utils.py:363   File "/usr/local/lib/python3.6/dist-packages/usb/backend/libusb1.py", line 901, in ctrl_transfer
2021-06-08T02:13:39.2214750Z DEBUG    root:utils.py:363     timeout))
2021-06-08T02:13:39.2215986Z DEBUG    root:utils.py:363   File "/usr/local/lib/python3.6/dist-packages/usb/backend/libusb1.py", line 602, in _check
2021-06-08T02:13:39.2217002Z DEBUG    root:utils.py:363     raise USBTimeoutError(_strerror(ret), ret, _libusb_errno[ret])
2021-06-08T02:13:39.2217959Z DEBUG    root:utils.py:363 usb.core.USBTimeoutError: [Errno 110] Operation timed out

Full log: 196.txt (original run) failing pipeline
This log output indicates that the board is OK at the beginning of the operation, but then fails when setting a particular clock in line 54:
https://github.com/lowRISC/opentitan/blob/c49ae2cefc95813dcde270243a37893746f36afc/util/fpga/cw310_loader.py#L54
The script ties to set another clock immediately before the failing operation, which apparently was successful.
Manually running lsusb -v, which also tries to access the USB device, agrees with the device "not responding". Here's the log: report.txt
My first guess would be that the reconfigured PLL somehow affected the USB operation.
@colinoflynn I know that's not a lot of information, but is there something you could think of to debug this further?

No that is good - should be able to run a stress test of it to see if we can shake this out. FYI - the PLL communication triggers some I2C traffic on the board. So if this is hanging somehow it may error out the USB, as I suspect it gets stuck "waiting forever" for some I2C ACK or similar. It might be a timing collision if there is another I2C transaction in process for example (the board polls the FPGA temp, also using the same I2C bus, I thought it was guarded but it makes me wonder if it collides with a temp poll & PLL read).
If you need a work-around: the PLL has EEPROM to set a default frequency. I can add that as an option to the loader & you could call that once on the board, then comment it out so it's not called everything. From then on the board will always come up with your requested frequency.

I've implemented the work-around here: https://github.com/newaetech/opentitan/commit/531520465e8dc8c0ba999bf475fcb8699e4db135 . I can start a PR for that if useful, or just steal it for now.
You'll need to run the board once with the --set-pll-defaults flag, after that it should come up with the same frequency setting in the future.

Thanks @colinoflynn! Would you mind doing a PR with that commit? We need to get it into the master tree to be used in the CI runs.
I'll then do a one-off run with the PLL setting after we reset the FPGA board.

Status update: as a workaround, we now avoid setting the PLL configuration for every run (PR #6879) in CI, but set the configuration manually when we connect the FPGA board to the CI runner. If that gives us more reliable connections then we have at least found the high-level problem. Time will tell.
Thanks @colinoflynn so far for your rapid response, much appreciated!

I opened a new issue on the main cw310 repo - however I can confirm I can trigger this bug by just looping the PLL code. So that makes it easy for us to reproduce - I'll leave any more details in the newaetech/cw310-bergen-board issue as we fix it. I'll update this issue here with anything major (hopefully - new firmware available for SAM3X that fixes it).

I can confirm I can trigger this bug by just looping the PLL code

That's good to hear! Easy to reproduce bugs are the best :smile:

This is fixed with a new firmware update at https://github.com/newaetech/cw310-bergen-board/tree/main/microfw/CW310/Debug - if you only update the FW it will now cause an error when the issue occurs. The firmware update mechanism is described at https://rtfm.newae.com/Targets/CW310 Bergen Board/#firmware-upgrade.
A matching update to the ChipWhisperer software (currently not in the main branch) does a smart-retry, so you won't see the error in most usage. But if you need the feature for some reason let me know & can detail this, otherwise it will get fixed in the next (or so) release.

Thanks a lot @colinoflynn! Unless you need more testing for the firmware, I'll wait with the update until the SW change has hit the develop branch (or made it into a release).
With the workaround we have in place right now, which avoids setting the PLLs at all, we got reliable testing for the last week or so (with around 250 test jobs processed), which removes the urgency from this issue and gives you time to come up with a fix without time pressure.

Marking as M2 Milestone for further triaging.

Closing, as this is an issue in the CW310's SAM3X firmware, and the upstream bug (https://github.com/newaetech/cw310-bergen-board/issues/3) is marked closed.


Train on real projected data

When I used it on real projected data, the loss was very large and it never converged. But when I used the DRR generated by Tigre, there was no problem with training.

Hi, here are my suggested steps.

Review the real projection data and rescale it if values are excessively large or small.
Check the scanner geometry, ensuring parameters like DSD, DSO, dVoxel, and dDetector are consistent with the projection data’s unit.
If feasible, normalize the scene to a unit cube to align with our dataset standards.
Adjust hyperparameters, including the learning rate, and consider tuning bound, which should be larger than the half size of your region of interest.


[Fork] Add validation of fee amount

If an outgoing transaction has fee < 100 groth, such transaction must not be going to the blockchain. Error message :"The minimum fee is 100 groth."

checked


Update api for galactic branch

As in https://github.com/luxonis/depthai-ros/issues/31

Thanks for the PR.


[0.5.0] version to 0.5.0

Coverage remained the same at 49.791% when pulling b5d01b8175dd0bf8900cf3f1b8244bfeb2c99a11 on nobodyiam:v0.5.0 into 1d3d05203a7a8a52a7312d71f63ae724ba4474db on ctripcorp:master.


MAX_PENDING_MESSAGES might not be approximate

MAX_PENDING_MESSAGES might not be approximate here, since it it only storing message data, and we can limit buffer using MAX_UNCONFIRMED_MESSAGES when delivering messages on target chain(relayers will help handle this.).
Beside, the side effect is it will limit the usage from client, and cause bad UX.
Originally posted by @HackFisher in https://github.com/darwinia-network/darwinia-bridge-sol/pull/77#r753075550

At serial channel, the proof needs all leaves/messages. MAX_PENDING_MESSAGES is necessary now.
At parallel channel, there is no limit such as MAX_PENDING_MESSAGES, MAX_CALLDATA_LENGTH etc...


setup.py does not exclude tests

The current setup.py does use automatic package discovery for installation. However, the current line does also discover the tests as packages.
packages=setuptools.find_packages(exclude=['img']),

Hence, they will be installed as package as well. This behavior is not usually not wanted.
The line should probably be:
packages=setuptools.find_packages(exclude=['tests','tests.*','img']),

Hi @tstorek
Please check my PR for this issue.


Todo: Implement profile/registry menu

Currently the profile select (called Registry in the game source-code) renders correctly and has a working text-input, but cannot have any of the profiles selected or a new one created.

Implement selection of profiles.
Implement creation and deletion of save files/profiles.
Suggestion: Display score on the right side of the text list interface
Suggestion: Display rank on the right side of the text list interface, as in Carnivores 1

This was inadvertently mostly completed, you can now select a profile and everything is in place to be able to delete existing profiles, the case for loading the MENUD* files needs to be added, will probably use MENU_REGISTER_DELETE as the state enum.
Lastly the ability to type in a name is there, but we need to accept VK_RETURN inputs and clicking "OK" if a profile is not selected or an empty profile slot is selected.  Pretty much all those capabilities are possible and just need their basic logic put into the input event to function.

Now complete, pending minor graphical fixes and future ability to scroll through the list of save files up to 99.
Commit: ac77146225d500dd78f0f4fe5b92ef248c3ac683


Run Gazebo simulation for 5 robots as the physical scenario.

I just run "roslaunch pioneer_mrs multi-robot.launch pose:=gazebo machine:=gazebo" to get results as in the physical scenario, but I get the log information as follows:
... logging to /home/ubuntu/.ros/log/e1cfbaaa-98f9-11eb-8e1a-04d4c4ad1764/roslaunch-ubuntu-20691.log
Checking log directory for disk usage. This may take a while.
Press Ctrl-C to interrupt
Done checking log file disk usage. Usage is <1GB.
RLException: cannot resolve host address for machine [hzteng]
The traceback for the exception was written to the log file.
So how can I solve this problem in Gazebo?
Thank u very much.

In config/robots.machine file and config/env.bash file, please replace hzteng with the hostname of your local machine (or localhost if you plan to run simulation only), and replace thz_ws with the actual folder name of the ROS workspace.
In details, robots.machine file is included in multi-robots.launch to load hostname for each machine. The hostname will then be resolved by /etc/hosts file to obtain the IP address of each machine in the network. hzteng was the hostname I used before in development and does not exist in your /etc/hosts file, so the error RLException: cannot resolve host address for machine [hzteng] comes.
In order to get this package run successfully, there are multiple places to change (hostname, workspace folder, ROS kinetic/melodic, etc.)

Thanks a lot, my problem has been solved.


Implement Rate Limiting on Requests

To enhance the stability and performance of our load balancer, we need to introduce a rate limiting feature that restricts the number of requests sent to each backend service to a specified limit per second. This implementation will provide a default global limit, with the ability to override this limit for individual backends.
Requirements:

Global Rate Limit: Define a default global rate limit for requests per second across all backends.

Override for Individual Backends: Allow each backend to specify its own rate limit, overriding the global setting.

Configuration Options:

A global configuration option (e.g., global_requests_per_second) for the default rate limit.
Backend-specific configuration (e.g., backend_requests_per_second) to set individual limits.

Handle Exceeding Limits: Ensure that appropriate responses are returned when the defined limit is exceeded (e.g., HTTP 429 Too Many Requests).

Hi @ardatosun
I can pick this up if that is okay ?


guide: document run-cache

So far affected commands are run/repro which create and/or use run cache. And push/pull/fetch/potentially status) that transfer (options for that are hidden for now) run cache to/from remote. Run cache is located in .dvc/cache/runs.

Will also need to update run-cache flags in run/repro to explain them through the run-cache concept.

Hey there I wanna work on this issue . Could you assign me this ?

Hi @sarthakforwet ! I don't think it is suitable for contribution, as it is a WIP feature. Please check out need-help and good-first-issue labels, they should have something more suitable :slightly_smiling_face:

Hi @sarthakforwet indeed please further explore the issues for something that seems a little smaller and more defined. I believe I sent some specific links in my GSoD email reply to you to some recommended issue labels. Feel free to reach out to me directly via email or on Discord for help on issue selection it you're still unsure. Thanks!

A suggested place to start is to add an "execution and reproduction" section to the dvc run cmd ref. similar to this: https://github.com/iterative/dvc.org/pull/1464/files

More info that would be good to include for this ticket, from https://github.com/iterative/dvc.org/pull/1448#discussion_r443124577:

Run-Cache can generate outputs in a suitable condition and that too indirectly (eg: only on run/repro), whereas a lockfile will always provide you with outputs without rerunning.
RunCache can generate lockfile. Even though you have a run-cache, you should still use lockfile because for the outputs.
get/import commands work well only if you have a lockfiile.

(Thanks @skshetry)

Hello! So this continues to be a major discrepancy between released DVC and published docs. I know it's being worked on but at least basic mentions of this should exist in the docs for now. Is it still the plan for someone from engineering to submit a draft proposal adding such mentions? Thanks! Cc @efiop @shcheklein

@jorgeorpinel Likely no drafts until experiments are here or https://github.com/iterative/dvc/issues/4223 .

Hi @efiop! I'm finally finishing up some basic docs for this (sort of needed to doc dvc exp). Quick questions:

potentially status

status didn't end up working with the run-cache at all right?

dvc gc doesn't have a way to specifically DO, or DO NOT collect outputs referenced in the run-cache, right?

Thanks

Correct, not yet.

Correct.

Feel free to reopen or make another issue if/when the run-cache implementation/terminology/etc change, or if more docs should be written. Thanks


Simplify CI setup

Previously, there were many instances of duplicate code across the
scripts used by CI. Now, we have added scripts/resources.sh which
includes common functions to limit redundancies.
Related-Issue: IBM/cloud-journeys#1
Signed-off-by: Matt Langbehn<EMAIL_ADDRESS>

Looking good!


Moving LIB_DIR visible for all make process

Fix https://github.com/adoptium/aqa-tests/issues/4914

Grinder https://ci.adoptium.net/view/Test_grinder/job/Grinder/8216/
parallel https://ci.adoptium.net/view/Test_grinder/job/Grinder/8217/ - cancelled as check the child jobs no lib issue.

We do not have any issues in Jenkins. This PR has to be validated in local runs or run aqa.

It validates locally


REST API should be configurable (e.g. able to listen on IPv6 addresses)

The REST API is hard coded to INADDR_ANY:
https://github.com/openthread/ot-br-posix/blob/92059387fc5bc253cda65a75293d511b58383b38/src/rest/rest_web_server.cpp#L125
This should be configurable, similar to the otbr-web service, with preferably a default of in6addr_any
Note that otbr-web also defaults to IPv4, however it can be easily configured with override "-a ::" to work on IPv6. Some pages work fine using IPv6, however the Topology page in particular is broken (it calls directly to the API).

@sgryphon It sounds good to me! Are you willing to submit a PR for this?

This is resolved by https://github.com/openthread/ot-br-posix/pull/1670


adds a wacky Hello World header to the end of the layout

This is a test PR

I created this PR for a demo. Closing it!


[BUG] Values of Assignees column and Base column are swapped on PRs view

Describe the bug
SSIA
To Reproduce
Steps to reproduce the behavior:

Make defaults.layout.prs.assignees.hidden false in your config file.
Make defaults.layout.prs.base.hidden false in your config file.
Launch gh-dash.

Expected behavior
Values of Assignees column and Base column aren't  swapped on PRs view.
Screenshots

Desktop (please complete the following information):

OS: Mac

I'll try to fix it.


Error if users don't have email on node.js

So took me forever to figure this out as there was no error handling on the user.save(). But if someone logs in with facebook or twitter. They don't get an email unless you request it specifically. So my users were getting null for the email.
Here is the error I was getting.
{ [MongoError: E11000 duplicate key error index: test.users.$email_1 dup key: { : null }]
  name: 'MongoError',
  message: 'E11000 duplicate key error index: test.users.$email_1 dup key: { : null }',
  driver: true,
  code: 11000,
  index: 0,
  errmsg: 'E11000 duplicate key error index: test.users.$email_1 dup key: { : null }',
  getOperation: [Function],
  toJSON: [Function],
  toString: [Function] }

And because there was a unique index on the email, it was silently failing. So to get it to work I had to turn off the unique on:
email: { type: String, unique: false, lowercase: true },

Thanks @Lazymondaysunday!
We'll add this information to a FAQ, though this seems like more of an issue with setting up the social networking services rather than something inherent to Satellizer.
Let us know if there's anything else we can do from the framework side. Appreciate the help!


Appears to be sending Byte message rather then Text

when i send via Stompngo I seem to be publishing messages as ActiveMqByte Messages
Jan 06 15:26:32 DEBUG tropo-cdr2 [voiceCdrSpringListenerBillwise-1] BillingBridge - Received message of type [class org.apache.activemq.command.ActiveMQBytesMessage] from consumer [ActiveMQMessageConsumer { value=ID:tropo-cdr2.prod.us-west-2xxxxxxx-43243-1417638886581-0:0:1:1, started=true }] of session [PooledSession { ActiveMQSession {id=ID:tropo-cdr2.prod.us-west-2.aws.xxxxxx-43243-1417638886581-0:0:1,started=true} }]

I am using the Send function which as I understand it should be sending a string to the queue
package main

import (
	"bufio"
	"fmt"
	"github.com/gmallard/stompngo"
	"gopkg.in/alecthomas/kingpin.v1"
	"net"
	"os"
)

var (
	queueName     = kingpin.Flag("queue", "Destination").Default("/queue/client_test").Short('q').String()
	serverAddr    = kingpin.Flag("server", "STOMP server endpoint").Default("<IP_ADDRESS>").Short('s').String()
	serverPort    = kingpin.Flag("port", "STOMP server port").Default("61613").Short('p').String()
	fileToProcess = kingpin.Flag("file", "File to process").Short('f').String()
	workerCount   = kingpin.Flag("workers", "Number of workers to send/receive").Short('w').Int()
	serverUser    = kingpin.Flag("user", "Username").OverrideDefaultFromEnvar("STOMP_USER").String()
	serverPass    = kingpin.Flag("pass", "Password").OverrideDefaultFromEnvar("STOMP_PASS").String()

	client Client
	done   = make(chan bool)
)

//var done = make(chan bool)

type Client struct {
	Host     string
	Port     string
	User     string
	Password string
	Uuid     string
	Queue    string

	NetConnection   net.Conn
	StompConnection *stompngo.Connection
}

func init() {
	kingpin.Version("0.0.1")
	kingpin.Parse()

	// Set default of 4 workers
	if *workerCount == 0 {
		*workerCount = 4
	}

}

// Setups connection options
func (client *Client) setOpts() {

	client.Host = *serverAddr
	client.Port = *serverPort
	client.Uuid = stompngo.Uuid()
	client.Queue = *queueName

	if *serverUser != "" {
		client.User = *serverUser
	}

	if *serverPass != "" {
		client.Password = *serverPass
	}
}

// Creates net connection
func (client *Client) netConnection() (conn net.Conn, err error) {
	conn, err = net.Dial("tcp", net.JoinHostPort(client.Host, client.Port))
	if err != nil {
		fmt.Println(err)
		return nil, err
	}

	client.NetConnection = conn
	return
}

func (client *Client) stompConnection() *stompngo.Connection {
	headers := stompngo.Headers{
		"accept-version", "1.1",
		"host", client.Host,
		"login", client.User,
		"passcode", client.Password,
	}

	conn, err := stompngo.Connect(client.NetConnection, headers)
	if err != nil {
		fmt.Println(err)
		os.Exit(0)
	}

	client.StompConnection = conn
	return conn
}

func (client *Client) Connect() (conn *stompngo.Connection) {
	client.setOpts()
	client.netConnection()

	conn = client.stompConnection()

	return
}

func (client *Client) Disconnect() {
	client.StompConnection.Disconnect(stompngo.Headers{})
	client.NetConnection.Close()
}

//  Start main
//
//
func main() {

	fmt.Println("Starting connection")
	_ = client.Connect()
	defer client.Disconnect()

	dataCh := make(chan string, *workerCount)

	// Start workers
	fmt.Println("Create workers")
	for id := 1; id <= *workerCount; id++ {
		go sender(id, &client, dataCh)
	}

	//  Start reader go routine
	fmt.Println("Read file")
	go fileReader(*fileToProcess, dataCh)

	<-done

	fmt.Println("Done")
}

//  Read from file and put data line by line on channel
func fileReader(path string, dataCh chan<- string) {
	inFile, _ := os.Open(path)
	defer inFile.Close()
	scanner := bufio.NewScanner(inFile)
	scanner.Split(bufio.ScanLines)

	for scanner.Scan() {
		dataCh <- scanner.Text()
	}
	close(dataCh)
}

//  Read from channel and put on queue
func sender(id int, client *Client, dataCh <-chan string) {

	for message := range dataCh {
		headers := stompngo.Headers{"destination", *queueName, "id", client.Uuid, "persistent", "true"}
		err := client.StompConnection.Send(headers, message)
		if err != nil {
			fmt.Println(err)
		}
	}

	done <- true
}

Hrm, I was able to get past this by suppressing the contentLength header
headers := stompngo.Headers{"destination", *queueName, "suppress-content-length", "true", "id", client.Uuid, "persistent", "true"}

Not sure I understand why that resolved my issue...

It solved your issue because it is the way ActiveMQ works, and is to assist with interaction between STOMP and JMS clients.
One description of this is here:
http://activemq.apache.org/stomp.html

If you are still using the stompngo package please try the current v.1.0.2 tag.
Tag information:
b1f1d966dd7b4c6e07278089c658aef2fb44749d refs/tags/v1.0.2
Document that version number in any issue reports.
Thanks for the support.
Guy


Jittering on Window Resize

When resizing window the window is jittering and providing a bad experience. This is With demo app om Surface 4

I tried to simulate this error here, but not success. Maybe its fixed?


Allow biolink to boot up without a running instance of owlsim

It would be convenient to allow to biolink to start up without owlsim running, and have the /sim endpoints return a message if an owlsim endpoint is currently booting (or not configured at all)
we'll need to make an effort to not continuously pin certain endpoints while owlsim is caching IC metrics, so it may be best to use an async call to track boot up, specifically
${OWLSIM}/getAttributeInformationProfile?r=HP:0000924&r=HP:0000707&r=HP:0000152&r=HP:0001574&r=HP:0000478&r=HP:0001626&r=HP:0001939&r=HP:0000119&r=HP:0025031&r=HP:0002664&r=HP:0001871&r=HP:0002715&r=HP:0000818&r=HP:0003011&r=HP:0002086&r=HP:0000598&r=HP:0003549&r=HP:0001197&r=HP:0001507&r=HP:0000769

this would be super useful but i'm not sure I'll get to it, @kevinschaper @putmantime remind me to give an overview of where all this lives and possible solutions


Update the CI workflow

Hi. I applied the changes the same as the following PRs to the CI workflow here:

https://github.com/stripe-samples/accept-a-payment/pull/1385
https://github.com/stripe-samples/accept-a-payment/pull/1612

Also, I updated Flask and Capybara configurations to fix failing tests.

@hideokamoto-stripe Hi Hide, I added some changes to make CI green 🍏 Also, left a couple of comments 🙏

0895bfb
e1fb639
1489d9c
feb849c

@hideokamoto-stripe I also opened a similar PR for checkout-one-time-paymens. Could you take a look when convenient? Thanks 🙇
https://github.com/stripe-samples/checkout-one-time-payments/pull/563

LGMT!


extreamly slow booting

Come from https://github.com/paritytech/substrate/issues/13947#issuecomment-1530938700
I'd catch nperf data from my Azure VM (premium SSD), and the node running in a Docker container, nperf running in the container too.
The current status is the node is stuck on booting, and it is not because of Cumulus reason, and the node is fresh sync last week (stop when speed reduced to 0 bps)
Here are flaming graphs I record the boot starting

flaminggraph.zip
the file system is ext4 without any configuration, the node is --state-pruning=archive-canonical --blocks-pruning=archive-canonical

Upgraded latest parity-db, the slow boot problem exists, here's another flaming graph

exit.svg.zip
Here's another flaming graph for the node stuck on exiting

Upgraded latest parity-db, the slow boot problem still exists (it takes about 8 minutes to start the node which using Azure premium SSD), here's another flaming graph

Are you sure this database was created with parity-db 0.4.7? Previous versions created a long queue of write-ahead log files that would take a long time to process on start. So if you already a database created by an older version and open it with 0.4.7, it will be slow the first time.

Upgraded latest parity-db, the slow boot problem still exists (it takes about 8 minutes to start the node which using Azure premium SSD), here's another flaming graph

Are you sure this database was created with parity-db 0.4.7? Previous versions created a long queue of write-ahead log files that would take a long time to process on start. So if you already a database created by an older version and open it with 0.4.7, it will be slow the first time.

I can confirm I'm using 0.4.7, and I have removed the old database before I do the new sync.
The boot time is faster than the previous version (the previous will take more than half an hour to start, 0.4.7 about 7 minutes)

What does ls -alh log* show inside chains/polkadot/paritydb/full/ dir before the slow start?


zedrem seems to be stuck

I issued ./zedrem and it got stuck.
using strace it seems like a server problem:
connect(4, {sa_family=AF_INET, sin_port=htons(443), sin_addr=inet_addr("<IP_ADDRESS>")}, 16) = -1 EINPROGRESS (Operation now in progress)
epoll_create1(O_CLOEXEC)                = 5
epoll_ctl(5, EPOLL_CTL_ADD, 4, {EPOLLIN|EPOLLOUT|EPOLLET|0x2000, {u32=2846585544, u64=139924291154632}}) = 0
epoll_wait(5, {}, 128, 0)               = 0
epoll_wait(5, {{EPOLLOUT, {u32=2846585544, u64=139924291154632}}}, 128,<PHONE_NUMBER>) = 1
futex(0x877620, FUTEX_WAKE, 1)          = 1
getsockopt(4, SOL_SOCKET, SO_ERROR, [0], [4]) = 0
getsockname(4, {sa_family=AF_INET, sin_port=htons(56969), sin_addr=inet_addr("<IP_ADDRESS>")}, [16]) = 0
getpeername(4, {sa_family=AF_INET, sin_port=htons(443), sin_addr=inet_addr("<IP_ADDRESS>")}, [16]) = 0
setsockopt(4, SOL_TCP, TCP_NODELAY, [1], 4) = 0
write(4, "\26\3\1\0\217\1\0\0\213\3\3x\252\355\342\tz\351RJ\241[\225\340\253#{\272\22E\2007"..., 148) = 148
read(4, 0xc208052800, 1024)             = -1 EAGAIN (Resource temporarily unavailable)
epoll_wait(5, {}, 128, 0)               = 0
epoll_wait(5,

Sorry for the late reply, does this still happen? It seems to work for me just fine.

Please reopen if this is still an issue.

I can confirm that it works now.
thanks


math expressions of features

As I'd like to use new generated features for further clustering or model interpretability, their math expressions are needed. How can I simply fetch math expressions of new features? thanks.
(Model interpretability is important. People won't use those features they don't know why)

Please refer to line 39-41 in the example code https://github.com/IIIS-Li-Group/OpenFE/blob/master/examples/california_housing.py to see how to print the math expressions of the new features.


Improvements to get_manifest_digests utility function

This function now gives more debugging output to aid diagnosis of a
situation in which only one of the two expected media types is seen on
the Pulp server.
As part of this, the function has been improved to aid readability.
There are now two more functions:

guess_manifest_media_type() takes a bytes object and attempts to
decode it and interpret the JSON in order to decide which manifest media
type it is
manifest_is_media_type() takes a requests.Response object and an
expected media type and attempts to confirm or deny that the manifest
returned in the response is of the expected media type

The media type guessing has also been improved. Previously in the
absence of a Content-Type HTTP response header, API v1 manifests could
not be identified at all (they lack a mediaType key). Now, if there is
no mediaType key the schemaVersion key will be inspected. This allows us
to reasonably guess at the manifest being API v1.
Signed-off-by: Tim Waugh<EMAIL_ADDRESS>

Needs additional tests for the new functions.

added to rn:

plugins dealing with manifest digests will log more details to improve the ability to diagnosis situations when only one of the two media types appears on a pulp server
under # Improvements

Yikes! That pulls OSBS-5099 into the current sprint then, unless we revert the merge.


WIP: Delete istio-iptables.sh and istio-clean-iptables.sh

FYI: PR: https://github.com/istio/istio/pull/18962 started making use of golang implementation

@abhide: The following test failed, say /retest to rerun them all:

Test name
Commit
Details
Rerun command

release-test_istio
c650a190ca8b68a2727dad9ae8a9ed466b9ed74f
link
/test release-test_istio

Instructions for interacting with me using PR comments are available here.  If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. I understand the commands that are listed here.

Looks like the sidecar.deb is stil using the old shell script

Looks like the sidecar.deb is stil using the old shell script

@howardjohn Not quite sure where this is failing?
I don't see where its picking up tools/packaging/common/istio-iptables from?
make: *** No rule to make target 'tools/packaging/common/istio-iptables', needed by '/tmp/tmp.1TYxJtF8Qd/build/work/out/linux_amd64/release/istio-sidecar.deb'.  Stop.

It should be from the sidecar.deb make target I think? I can look closer
later
On Sat, Nov 30, 2019, 11:41 AM Amey Bhide<EMAIL_ADDRESS>wrote:

Looks like the sidecar.deb is stil using the old shell script
@howardjohn https://github.com/howardjohn Not quite sure where this is
failing?
I don't see where its picking up tools/packaging/common/istio-iptables
from?
make: *** No rule to make target 'tools/packaging/common/istio-iptables',
needed by
'/tmp/tmp.1TYxJtF8Qd/build/work/out/linux_amd64/release/istio-sidecar.deb'.
Stop.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/istio/istio/pull/19273?email_source=notifications&email_token=AAEYGXNWJR4KYO3ISXARQA3QWK6WXA5CNFSM4JSMT2F2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEFQSPAY#issuecomment-560015235,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AAEYGXOK3ZRZ2ICOQ2Q3Z6LQWK6WXANCNFSM4JSMT2FQ
.

tools/packaging/deb/istio.mk currently contains:
ISTIO_DEB_DEST:=... \
                ${ISTIO_DEB_BIN}/istio-iptables \
                ...
$(foreach DEST,$(ISTIO_DEB_DEST),\
        $(eval ${ISTIO_OUT}/istio-sidecar.deb:   tools/packaging/common/$(notdir $(DEST))) \
        ...

So make will evaluate the following rule:
${ISTIO_OUT}/istio-sidecar.deb: tools/packaging/common/istio-iptables

tools/packaging/common/istio-iptables does not exist (unlike tools/packaging/common/istio-iptables.sh), which is why make fails.
You need to remove the istio-iptables and istio-clean-iptables paths from the ISTIO_DEB_DEST variable.
Instead, I'd suggest trying adding istio-iptables istio-clean-iptables to the SIDECAR_DEB_DEPS, which already contains the other Golang binary dependencies.

@abhide: The following test failed, say /retest to rerun them all:

Test name
Commit
Details
Rerun command

release-test_istio
06887aa9357eadc83dae94cecaed71384a27ceff
link
/test release-test_istio

Instructions for interacting with me using PR comments are available here.  If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. I understand the commands that are listed here.

Not sure where this fails.
make istio-demo.yaml works for me.
Did a git grep Copying in repo. Don't see any place where istio-iptables.sh is getting copied.
@rlenglet @howardjohn any ideas?

https://github.com/istio/release-builder/blob/ce17e987ee032f07ae86b06750ee5c3e071b9a46/pkg/build/archive.go#L52

Thanks @howardjohn. I guess I need to remove it from that repo first then.
I guess we branch all repos identically? Just want to make sure remove that from release-builder repo master branch won't impact any maintenance/patch release for previous versions?

Yes we branch (almost) every repo the same. Changes to master won't impact
old releases. Furthermore, the SHA of the release-builder we use is pinned,
so you can make the change and it won't impact other PRs that still depend
on that file existing, since it won't be updated until your PR merges,
which will update the SHA as well
On Fri, Dec 6, 2019 at 5:38 PM Amey Bhide<EMAIL_ADDRESS>wrote:

Thanks @howardjohn https://github.com/howardjohn. I guess I need to
remove it from that repo first then.
I guess we branch all repos identically? Just want to make sure remove
that from release-builder repo master branch won't impact any
maintenance/patch release for previous versions?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/istio/istio/pull/19273?email_source=notifications&email_token=AAEYGXPHCQWII6EQXBWOF43QXL5AVA5CNFSM4JSMT2F2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEGF2TTI#issuecomment-562801101,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AAEYGXPE7UKHDEPADDVL3HDQXL5AVANCNFSM4JSMT2FQ
.

Thanks for confirming @howardjohn. Pushed a PR to istio/release-builder

/test release-test_istio

@abhide: The following test failed, say /retest to rerun them all:

Test name
Commit
Details
Rerun command

release-test_istio
06887aa9357eadc83dae94cecaed71384a27ceff
link
/test release-test_istio

Instructions for interacting with me using PR comments are available here.  If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. I understand the commands that are listed here.

Thanks @howardjohn. update SHA in prow/release-commit.sh

lgtm but we should wait for a resolution to https://github.com/istio/istio/issues/19380 before merging?

#19380 is closed
@howardjohn Do you have other concerns?


Support the plugin targeting interface and annotation

For a long time, we support the target class of plugin must be an explicit class name, by returning full name of AbstractClassEnhancePluginDefine.enhanceClassName().
It's easy enough but not powerful, as Spring annotation style became more and more popular, supporting to intercept classes with a certain annotation seems more and more important. And supporting annotation is similar with supporting interface implementation.
But, I have to change the return value of AbstractClassEnhancePluginDefine.enhanceClassName(). It is pained, since we have finished a big refactor, and I miss this.
cc @ascrutae @pengys5

Check this https://github.com/raphw/byte-buddy/issues/322#issuecomment-314840872 for interface.
Use the hasSuperType().

Provided 4 types match for enhance class:

byName
byClassAnnotationMatch
byMethodAnnotationMatch
byHierarchyMatch


Add voting method to vote_fact_dim

From going through some of the voter history files, it looks like at least some have method of voting, so we should probably add that to the vote_fact_dim. I'm assuming there's "In-person" and "absentee", but not sure if/how many other options there are

@BenGalewsky unless we had something else in mind for this, I think the PR closed it. I'm closing now, but if it's not done feel free to reopen


Fix the PMT-specific default dark noise values

Fixes #159
I also modified the .mac file - it will pick up the PMT-specific defaults by default now. I can revert the last commit if you don't want it @eosullivan

Sure, it seems reasonable to include these macro changes in the pull request so that it is clear you no longer need to set the values in the macro when changing photosensor types (and so you aren't explictly specifying the 20" PMT dark rate in the defualt macro, which would overwrite the changes we are trying to make here). Could you do some basic verification to show that this PR automatically grabs the right dark rate values from the photosensor? Maybe a nice quick test would be to simulate HK and show that the right dark rate values for the B&L tubes are now being set automatically without needing to set them in the macro. And also confirm that setting the value in the macro still changes the dark rate since we don't want to lose that functionality.

I've added a few .mac scripts (for a variety of combinations of detector/user-set/PMT-default) & a quick exit - give $WCSIMDIR/testing/run.sh a go, let me know when you're satisfied it's working as expected, and I'll revert these two commits

Ok, so I ran some verification tests. First I used your macros, which cout the dark rate and the convert rate to the screen, to confirm that the PR seemed to be doing what it said it should do. Everything looked fine.
I wanted to also see it a bit more visually to make sure the final product (in this case, simple outputs like the number of hits) was acting as expected. I'll include these test plots here for posterity.
Test 1: Compare the 40% photocoverage cylinder with no dark rate set in the macro for the develop branch vs. no dark rate set in the macro for this PR. The hits in the develop branch are less than in hits in this PR, which is consistent with the dark noise in the develop branch being lower than that in this PR (which we would expect from the B&L dark rate being set as the PMT dark rate).

Test 2: Compare the 40% photocoverage cylinder with the proper B&L dark rate and convert rate set in the macro for the develop branch vs. no dark rate set in the macro with this PR. We get identical results, which suggests that this PR now properly sets the default B&L dark rate parameters.

Test 3: Compare the 40% photocoverage cylinder with no dark rate set in the macro for this PR vs. the dark rate set to 3 Hz (lower than the default) in the marco for this PR. We set the number of hits decreasing as we set the dark rate lower in the macro, which suggests that we are still able to set the dark rate manually in the macro.

Test 4: Run the SK configuration with no dark rate set in the macro for this PR vs. with no dark rate set in the macro for the develop branch. I only ran ten events, but I confirmed that I saw no change (as expected, since the SK configuration dark rate was not affected by this bug).
So, long story short, I am satisfied that this is doing as it should. Revert the last two commits and we'll get this merged in.

Great, thanks. It's ready to go.


Add missing closing apostrophe for zoomOutText default value

Never mind.  There's an existing pull request for that #6208


feat: clean up and redo docs

:tada: This PR is included in version 1.86.0 :tada:
The release is available on:

npm package (@latest dist-tag)
GitHub release

Your semantic-release bot :package::rocket:


PROD SUPPORT : Multiple accused flow treatment

Describe the bug
Multiple accused flow treatment
@mehulseg24 need more clarity @ansh-egov

This is duplicate ticket please refer to #2615


fix(provider-wit-bindgen): exported bundled arg invocation name

Feature or Problem

This commit fixes a bug in determining the struct name for bundled exports. Code that was using expected a WIT interface name was receiving a WIT inteface path (which is .-delimited), and attempting to use it directly, rather that converting to a valid Rust identifier.
Related Issues

Release Information

Consumer Impact

Testing

Unit Test(s)

Acceptance or Integration

Manual Verification

I also have seen this issue occur for the member name of the struct as well not just for functions in the past, however not entirely sure if that was my fault. Just something to be aware of.


on IOS get_my_rosters after login and then logout and then login return empty list

ios only, android receive roster on this scenario correctly

Login
get Roster - receive full roster will return correct result
logout
login
get Roster return empty list

Can you please share debug logs here and i can help ? @dkramorov

Closed due to inactivity

hey, i have the same problem, plus on ios when i login and getRosters the list is empty, but when i refresh it, it gets all the rosters!!!!


Update troubleshooting.md

adding Note for gcc-high and DoD cloud EXO not being supported from Azure cloud Shell

@TonyD12ms, thanks!
#sign-off


Inconsistant notebook options

URL to the relevant documentation
https://docs.quantum.ibm.com/transpile/defaults-and-configuration-options
Please describe the UI problem.
Some pages have the "download notebook" options like below

While other pages do not have this option:

We should try to make this constant across all pages with code cells (in other words, across all pages minus the introduction).

I agree. Duplicate of https://github.com/Qiskit/documentation/issues/169. The other benefit of rewriting to Jupyter notebooks is that it allows us to test if the code has become invalid, whereas we can't test that with MDX unless we invent a bunch of infrastructure we decided we don't want to do.


Merge UI dashboard to Manage the pipeline

Pipeline ui manager - https://github.com/DorTruzman/PipeRTManager
The ui manager will be as another service in the docker-compose.

#43

#43 - Add routes in order to communicate with the pipeline GUI


Consume unread data

I have a producer keep producing messages and have a consumer starts/stops from time to time. But every time the consumer starts, it only will receive "PartitionEOF" event and only consume new message. So how I do pick up messages from last read position? I am using the code from AdvancedConumser.

if you are using the code exactly as it is in the advanced consumer it should not behave in this way. please provide example source demonstrating the problem (and any other relevant information) and I'll take a look.

To clarify a bit, that example should be automatically committing offsets. Offset commits allow an application to track where it last processed data for a topic partition and resume from that last position. Since that example enables automatically committing offsets, the expectation is that when you restart the application it will pick up where it last left off.
If that is not the behavior you see, it sounds like you may have possibly adjusted some settings or code that change the behavior. Seeing the code you're executing or understanding what you've changed in the example might help track down the problem.

Thanks for the reply. I am new to Kafka, my problem is the producer will produce to a brand new topic before the consumer starts, then when the consumer subscribe to the new topic, it will only receive the new messages.

make sure auto.offset.reset is set to 'smallest' (as in the advanced consumer example). This parameter specifies what happens if no offsets have been committed by a consumer group for a topic/partition yet, and by default it's set to latest (iirc).

Thanks Matt, I was missing that setting, you save my day, cheers.

no worries @zhe0wang and goodluck! Kafka is very rewarding once you get the hang of it.


Compiles with numpy 2.0

Codecov Report
All modified and coverable lines are covered by tests :white_check_mark:

Project coverage is 75.63%. Comparing base (e131cc1) to head (0ef9083).
Report is 2 commits behind head on main.

Additional details and impacted files
@@            Coverage Diff             @@
##             main      #19      +/-   ##
==========================================
+ Coverage   73.87%   75.63%   +1.76%
==========================================
  Files          13       18       +5
  Lines         712      977     +265
==========================================
+ Hits          526      739     +213
- Misses        186      238      +52

:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Have feedback on the report? Share it here.


MB-10864: Add support for running tests with gotestsum

MB-10864
Summary
The current go-junit-reporter does not include the log/failure
message in the XML, which makes it harder to see the error in
CircleCI.
gotestsum JUnit XML support does include the error message, but it
runs the tests different. This adds support for gotestsum while trying
to keep support for go-junit-reporter so we can switch back quickly if
we need to.
Verification Steps for Author
These are to be checked by the author.

[ ] Request review from a member of a different team.
[ ] Have the Jira acceptance criteria been met for this change?

Verification Steps for Reviewers
These are to be checked by a reviewer.

Run make server_test locally
See the tests run in CI successfully

Messages

:book:
:link: MB-10864

  Generated by :no_entry_sign: dangerJS against d5b6fd0909ce475f51e9e907a0210654e9bd7037


Renamed install_plugin definition to prevent conflict

Hi,
I've tried to use the newrelic_plugin and it worked well. However As soon I've added an other cookbook(elasticsearch) to my metadata it failed.
It's coming from a conflict between the definition install_plugin in newrelic_plugin_chef and the install_plugin method from elasticsearch cookbook.
recipes/mysql.rb was trying to install a plugin but it was actually calling the elasticsearch method, therefore I got errors like this :
Chef::Exceptions::ResourceNotFound:
       resource ruby_block[Install plugin: newrelic_mysql_plugin] is configured to notify resource service[elasticsearch] with action restart, but service[elasticsearch] cannot be found in the resource collection. ruby_block[Install plugin: newrelic_mysql_plugin] is defined in /var/folders/0p/l33795bn35ng4f_6p_7sqtbm2tcccx/T/d20141103-22587-13abh3b/cookbooks/elasticsearch/libraries/install_plugin.rb:35:in `install_plugin'

I've not been able to find a better solution than to rename the definition in newrelic_plugins_chef. It's a small change, and should prevent any further conflict.
It's a big blocker for us, and I guess it would be for other people too.
Thank you!

Hello, could we have an update on this PR?

Any update on this?

Any update on this? @jstenhouse ?

Any updates?

This is so simple to fix and so annoying to encounter! @jstenhouse sorry to pester you but what's NewRelic's policy for merging? Why is this still open?

@BackSlasher we are using this for now => https://github.com/rackspace-cookbooks/newrelic_plugins_chef. There is no commit since last year, so not much to maintain on the fork

 Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.You have signed the CLA already but the status is still pending? Let us recheck it.

 Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.You have signed the CLA already but the status is still pending? Let us recheck it.


dental pulp canal terms

Add:
abnormal dental pulp canal morphology (child of abnormal dental pulp morphology MP:0013250)
DEF: any structural anomaly of the portion of the dental pulp cavity within the root of a tooth
SYN: abnormal pulp canal morphology
SYN: abnormal root canal morphology
SOURCE: https://www.ncbi.nlm.nih.gov/mesh/68003786
enlarged dental pulp canal
DEF: increased size of the portion of the dental pulp cavity within the root of a tooth
SYN: enlarged pulp canals
SYN: enlarged dental pulp canals
SYN: large pulp canals
SYN: enlarged tooth pulp canals
SYN: enlarged root canals
Annotation in J:89498

Added:
abnormal dental pulp canal morphology MP:0030559
enlarged dental pulp canal MP:0030560


build: let webpack proxy server handle more content encoding

SUMMARY
A small tweak for local dev-server (npm run dev-server) proxying to a production Superset service. Sometimes production Superset backend runs behind nginx servers with different compression configuration. This PR allows the dev the dev server to be able to handle both Brotli and Deflate compression, in addition to gzip.
cc @kristw
BEFORE/AFTER SCREENSHOTS OR ANIMATED GIF
N/A
TEST PLAN

Start Superset Flask server, put it behind nginx with Brotli enabled
Start Superset frontend dev server and proxy it the backend by npm run dev-server --superset http://{your_server_url}
You should see the page correctly rendered instead of garbled text.

ADDITIONAL INFORMATION

[ ] Has associated issue:
[ ] Changes UI
[ ] Requires DB Migration.
[ ] Confirm DB Migration upgrade and downgrade tested.
[ ] Introduces new feature or API
[ ] Removes existing feature or API

Codecov Report

Merging #11376 into master will decrease coverage by 5.89%.
The diff coverage is n/a.

@@            Coverage Diff             @@
##           master   #11376      +/-   ##
==========================================
- Coverage   65.78%   59.89%   -5.90%
==========================================
  Files         838      394     -444
  Lines       39845    24944   -14901
  Branches     3655        0    -3655
==========================================
- Hits        26214    14939   -11275
+ Misses      13531    10005    -3526
+ Partials      100        0     -100

Flag
Coverage Δ

#cypress
?

#javascript
?

#python
59.89% <ø> (-1.06%)
:arrow_down:

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

Impacted Files
Coverage Δ

superset/db_engines/hive.py
0.00% <0.00%> (-85.72%)
:arrow_down:

superset/databases/commands/create.py
31.91% <0.00%> (-59.58%)
:arrow_down:

superset/db_engine_specs/hive.py
53.90% <0.00%> (-30.08%)
:arrow_down:

superset/views/database/mixins.py
59.64% <0.00%> (-22.81%)
:arrow_down:

superset/db_engine_specs/presto.py
69.76% <0.00%> (-12.32%)
:arrow_down:

superset/db_engine_specs/mysql.py
79.59% <0.00%> (-12.25%)
:arrow_down:

superset/databases/commands/update.py
85.71% <0.00%> (-8.17%)
:arrow_down:

superset/databases/api.py
83.49% <0.00%> (-7.08%)
:arrow_down:

superset/databases/dao.py
94.11% <0.00%> (-5.89%)
:arrow_down:

superset/views/database/validators.py
78.94% <0.00%> (-5.27%)
:arrow_down:

... and 461 more

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 6fe7b4a...c96a6b3. Read the comment docs.


false 'Parameter "Text is declared by reference but never changed in method (AA0150)'

Describe the bug
The mentioned warning is reported spuriously when the argument is changed, ~but only in certain branching conditions. It should not fire if the argument can be changed within the method. Not all paths will change all variables...~
To Reproduce
Steps and to reproduce the behavior:
This code causes the warning :

~Changing the exit() for a ; so the code always flows to the assignment suppresses the warning, but that is obviously wrong, and I can't imagine any workaround that wouldn't be noisy and stupid.~
Expected behavior
no warning!
5. Versions:

AL Language: 6.0.344420
Business Central: n/a

In fact, this isn't dependent on branching; I wrongly concluded that because the warning goes away briefly after changing the code to the below - but it just comes back once it reanalyses.

The error also propagates through callers of the originally shown function:

another, simpler example:

I can't replicate this with AL extension 7.1.441584, so thanks!
https://github.com/microsoft/AL/issues/6184 also seems in need of closing.

Nope, I spoke too soon. Changing something unrelated in the project caused AA0150 to come back again...

However... if I then click on those warnings, to go to the file/location, they disappear!! ...for a few seconds, and then come back. This is some X-Files stuff ;-)

@dtkb This behavior is "normal", unfortunately. This is not specific to any warning code. You cannot rely on the "Problems" list, but you can run "AL: Package" instead, to not miss any warning.

OK, I don't recall noticing that before, or maybe I just normally fix warnings too fast after clicking on them to notice 0:-) I figured it was worth mentioning in case 'abnormal'. Thanks!

Thanks for reporting this issue. Sorry we haven’t completed it yet, but we’ve had to prioritize elsewhere. We’re planning to give the CodeCop engine and its rules an overhaul in a future major release. Thanks for your patience.
For this case consider using Pragma Warning Directive.


Color area is still selectable after closing the picker

Do you want to request a feature or report a bug?

bug

What is the current behavior?
After dragging the color selector in the color area and closing the picker, it seems like the listener still exists and the user is able to change the selector further.

If the current behavior is a bug, please provide the steps to reproduce and

open the picker
drag the color selector around
close the picker
move your mouse over the previously visible color selector area
move the mouse around while dragging

What is the expected behavior?
It shouldn't be possible to drag the color selector after closing the picker.
I think this is also an issue because the content below the color area isn't usable after closing it.
Your environment:
Version (see Pickr.version): 1.2.3
Used bundle (es5 or normal one): es5
Used theme (default is classic): classic
Browser-version:  chromium 75
Operating-system:  linux

I'd almost say this is a chrome bug. If you take a look at the dev console, you see pickr has visibility: hidden which should deny any interaction. If you unfocused the tab this isn't possible anymore. And check it out in firefox and edge, the issue seems to be only with chrome...

Just checked it in FF and it also happens there :(
There's no cursor adjustment though.

Oh, my bad. Seems like I forgot to adjust the delay of visibility - and I thought I'd finally discover a chrome bug 😅 Fixed in e1c0eeb39b352c3d0511780d7b194d8de8f638f4


Enterprise Cloud Addendum Updates - Fall 2019

Opening this pull request to show changes that are currently live: https://help.github.com/en/github/site-policy/github-enterprise-cloud-addendum.
The updates in this pull request cover:

Removal of irrelevant reference to scheduled downtime

Thanks @meentastic! Merging now.


File size is zero when downloading appliance backup

The GET call to download a backup returns 302 which is not handled by download_to_stream method in connections module. This results in zero size backup files.
Used the script found in the examples backups.py
response = oneview_client.backups.download(backup_details['downloadUri'], filename)

closing the issue as PR #19 is merged


Are objects and components the same things?

If objects and components are the same things, then I suggest we pick one of the terms and use that everywhere, to avoid confusion.
The attribute "cId" is used to refer to component id. Changing this would be a diffucult braking change, so if we want to change something, weI suggest we rename object to component.

The current core doc refers to following the Datex II meta-model. Is this still relevant, and what does it imply?

If objects and components are the same things, then I suggest we pick one of the terms and use that everywhere, to avoid confusion.
The attribute "cId" is used to refer to component id. Changing this would be a diffucult braking change, so if we want to change something, weI suggest we rename object to component.

From a protocol point of view, the are the same thing. The choice of terminology was used in order to better fit with other STA-specific documents. I'm in favor of changing this in the future

The current core doc refers to following the Datex II meta-model. Is this still relevant, and what does it imply?

This was written a long time ago. I'm not an expert of Datex II but I believe this text is outdated. But I think that nowadays Datex II contains traffic signal related information as well, so perhaps Datex II is a competing standard nowadays. Sometimes Datex II is criticized for low performance (maybe because it uses XML?) , making it unsuitable for some use cases, but I'm not sure about it's latest developments.

OK then let's device on object or component and be consistent: #186
And let's remove reference to Datex II: #185

closing in favour of #186


gomod2nix: init at 1.4.0

Description of changes
This adds gomod2nix, a generator for Nix expressions using Go modules (and the associated build infrastructure).
It has quite some differences to buildGoModule which are laid out in https://www.tweag.io/blog/2021-03-04-gomod2nix/.
I don't feel quite ready yet to promote buildGoApplication and mkGoEnv to first-class top-level attributes so in nixpkgs these will be accessed by gomod2nix.buildGoApplication & gomod2nix.mkGoEnv respectively.
This is developed external over at https://github.com/tweag/gomod2nix/.
This work has been sponsored by both the NLNet Foundation under the NGI Zero program and by Tweag.

Due to a mistake this is a new instance of #188035. See that PR for previous discussion.
Things done

Built on platform(s)

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

[ ] For non-Linux: Is sandbox = true set in nix.conf? (See Nix manual)
[x] 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/)
22.11 Release Notes (or backporting 22.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
[ ] (Release notes changes) Ran nixos/doc/manual/md-to-db.sh to update generated release notes

[x] Fits CONTRIBUTING.md.

Repating myself from: https://github.com/NixOS/nixpkgs/pull/188035#issuecomment-1226881009

I intend to merge this within the next couple of days unless there are any objections.

The update script seems broken, doesn't seem to eval.  I said previously I won't block on this so if you just want to drop it from this PR and deal with it in a follow up I'm fine with that.
Can you share your plans and time frame for promoting for this?

The update script seems broken, doesn't seem to eval. I said previously I won't block on this so if you just want to drop it from this PR and deal with it in a follow up I'm fine with that.

I made a fix to make the updater work in the case that pname isn't explicitly passed.

Can you share your plans and time frame for promoting for this?

I have patches ready for all the Go packages I maintain in nixpkgs and will announce the availability of gomod2nix in nixpkgs shortly after at least a few of those have been merged.
I will however not try to go on some crusade to get everyone to adopt it immediately.
Additionally I also have patches for most of the packages that still use vgo2nix ready too, it's just blocked on this PR.

@zowoq FYI the upstream repo has been moved to nix-community.

I think the case-sensitive problems in https://github.com/NixOS/nixpkgs/issues/129730 may also be a problem for this?

I made a fix to make the updater work in the case that pname isn't explicitly passed.

Sorry, still doesn't seem to work. Can you add an example to this PR?

I have patches ready for all the Go packages I maintain in nixpkgs

Not any of the podman packages please.

will announce the availability of gomod2nix in nixpkgs shortly after at least a few of those have been merged.

Can we wait at least a couple weeks on this? I'd like to do some testing and fix some nits first. I really don't see why this needs to be rushed, at one point I thought the upstream project had been abandoned. IIRC the go no vendor patch was added 18 months ago.

FYI the upstream repo has been moved to nix-community.

Cool, thanks.

Can we wait at least a couple weeks on this? I'd like to do some testing and fix some nits first. I really don't see why this needs to be rushed

Sure that could wait, no problem.

Not any of the podman packages please.

I was talking about the ones where I'm the sole maintainer,.

I think the case-sensitive problems in https://github.com/NixOS/nixpkgs/issues/129730 may also be a problem for this?

I don't think so, I could add a test case for it though.

Sorry, still doesn't seem to work. Can you add an example to this PR?

Sure, I've added repackaged a fairly low impact package in this PR.

oh the whole thing gets stuffed into the toml. src, version and everything. TBH I really don't like this:
{ lib
, gomod2nix
, fetchFromGitHub
}:

gomod2nix.buildGoApplication {
  pname = "trillian";
  pwd = ./.;
  meta = {
    homepage = "https://github.com/google/trillian";
    description = "A transparent, highly scalable and cryptographically verifiable data store.";
    license = [ lib.licenses.asl20 ];
    maintainers = [ lib.maintainers.adisbladis ];
  };
}

oh the whole thing gets stuffed into the toml. src, version and everything. TBH I really don't like this:

You could rewrite it in a more verbose way if you wanted to. Look at how https://github.com/nix-community/gomod2nix/blob/master/generic.nix is constructed for example.
There are very good reasons to do it this way though. In buildGoModule src and vendorSha256 requires you to update multiple hashes which is absolutely terrible UX.
I didn't want to repeat this terrible UX and made the code generated file the only thing you need to update as a single atomic unit.
Otherwise we'd have a similarly bad user experience once again for very little reason.

To get the package version I either need to query the package via nix or grep the toml?

To get the package version I either need to query the package via nix or grep the toml?

In this instance, yes.

Sorry but I think burying the version in the toml is absolutely horrible.

Sorry but I think burying the version in the toml is absolutely horrible.

Ok, I don't see the problem. There is plenty of prior art in nixpkgs already.

There is plenty of prior art in nixpkgs already.

Package sets or separate packages like this?

I don't see the problem.

Searching "github.com/google/trillian" to find the version isn't a problem?  Seems like we're trading one form of bad UX for another?

Package sets or separate packages like this?

Both. Ruby packages comes to mind.

Searching "github.com/google/trillian" to find the version isn't a problem? Seems like we're trading one form of bad UX for another?

Would you feel better if we also stuck the version attribute in the top-level attributes in the toml file?

Ruby packages comes to mind.

If you mean bundlerEnv with gemset.nix and gemfile.lock that seems very different. Any others? I'm actually curious as I can't think of any. haskell, emacs, vim, node all seem much easier to inspect visually.

Would you feel better if we also stuck the version attribute in the top-level attributes in the toml file?

Only marginally. Would need to be enforced, I really don't want debates over it and packages flipping back and forth between (buried in toml|top of toml|set in default.nix).

You could rewrite it in a more verbose way if you wanted to. Look at how https://github.com/nix-community/gomod2nix/blob/master/generic.nix or https://github.com/crypto-org-chain/chain-main/blob/master/default.nix are constructed for example.

I'm kinda worried about the fact that this is possible. At the moment there is (basically) one way of writing a go package, this seems to allow a lot more variation (and more debates). Consistency is good UX also.

Any others? I'm actually curious as I can't think of any. haskell, emacs, vim, node all seem much easier to inspect visually.

Carnix is another one (code generator), so is poetry2nix (reads pyproject.toml).
I think it's disingenuous to say that Emacs is easier to inspect visually, the majority of that lives in massive auto generated files. The same goes for Haskell, Node & many more.
My take is that this comment is just bike shedding.

I'm kinda worried about the fact that this is possible. At the moment there is (basically) one way of writing a go package, this seems to allow a lot more variation (and more debates).

Which is intentional. The needs of a packager packaging up an application in a private repo has somewhat different concerns than someone packaging something that is developed entirely outside of the package tree.
buildGoModule lacks this flexibility which (imo) makes it unusable as a tool to integrate into a typical development workflow.
gomod2nix was designed with both use cases in mind.

Did you do some testing with big go.mod files and how they behave like https://github.com/golangci/golangci-lint/blob/master/go.mod and more complex ones like https://github.com/open-policy-agent/gatekeeper/blob/master/go.mod ? Also what if the project uses replace where we can't use go install with the package name?

oh the whole thing gets stuffed into the toml. src, version and everything. TBH I really don't like this:

same for me. This is not very great from a reviewers perspective who needs to double check that people did not forgot to update version or some hash.

Glad to see a solution without vendorSha256!

Trying this again: If there is nothing new and actionable by Friday (2022-09-09) I will merge this.

Trying this again: If there is nothing new and actionable by Friday (2022-09-09) I will merge this.

You haven’t responded to a few concerns from Sandro and myself. Between us we’ve done the majority of the go maintenance for the last year so I don’t think our concerns should be dismissed.

There is no src attribute explicitly being set.

I am not really a fan of this. If I want to access the source files nix is building things from to investigate and debug packages I often use nix build .#name.src and I would tell people to do that when debugging. Could we add it at least as an alias back to make things more uniform with other packages?

I don’t think this has been addressed?

Also we need to make sure that it is clear in the documentation that goPackagePath here has nothing to do with buildGoPackage.

Renaming goPackagePath to goModPath, goSrcPath or something else would eliminate any confusion with buildGoPackage.

what is your plan for documentation?

I don’t mind if this PR is merged without docs but I think having docs is a blocker for gomod2nix, etc being promoted.

oh the whole thing gets stuffed into the toml. src, version and everything. TBH I really don't like this:

same for me. This is not very great from a reviewers perspective who needs to double check that people did not forgot to update version or some hash.

This hasn’t been addressed. As you asked for something actionable: I’d like to see the src/hash/version not treated as just another dep and be moved to the top of the toml with the other attributes.
I consider this a blocker for merging this PR.

Did you do some testing with big go.mod files and how they behave like https://github.com/golangci/golangci-lint/blob/master/go.mod and more complex ones like https://github.com/open-policy-agent/gatekeeper/blob/master/go.mod ? Also what if the project uses replace where we can't use go install with the package name?

Sandro's asked about this twice (in this PR and https://github.com/NixOS/nixpkgs/pull/188035#issuecomment-1227681465) and there doesn't seem to have been a response?

As someone who's also been packaging go modules a bunch I agree with all @zowoq & @SuperSandro2000 's points in that comment

I'll try this out with cosign which has a bajillion dependencies


Method lookup fails for derived types

The method lookup routine fails to find a suitable method when you pass an argument that's an instance of the derived class which the argument was defined, e.g method foo() is declared as void foo(String s) and you pass an instance of the Text class, which extends String.

Fixed.


Add helper to get timestamp from a token

Codecov Report

Merging #4 into 2.x will increase coverage by 0.57%.
The diff coverage is 100%.

@@             Coverage Diff              @@
##                2.x       #4      +/-   ##
============================================
+ Coverage     92.15%   92.72%   +0.57%
- Complexity       11       12       +1
============================================
  Files             1        1
  Lines            51       55       +4
============================================
+ Hits             47       51       +4
  Misses            4        4

Impacted Files
Coverage Δ
Complexity Δ

src/Branca.php
92.72% <100%> (+0.57%)
12 <1> (+1)
: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 77939d8...251b598. Read the comment docs.


request Ivy support

Which platform(s) does your issue occur on?

Both
iOS/Android versions 7.0.1
Pixel 3 XL

Please, provide the following version numbers that your issue occurs with:

CLI: 7.0.7
Cross-platform modules: (check the 'version' attribute in the
<EMAIL_ADDRESS>file in your project)
Runtime(s): Both is 7.0.1
Plugin(s): nativescript-collectionview ^2.0.36

Please, tell us how to recreate the issue in as much detail as possible.
install this package in Angular 10 with Ivy enabled
ERROR in node_modules/nativescript-collectionview/angular/index.d.ts:1:22 - error NG6002: Appears in the NgModule.imports of AppModule, but could not be resolved to an NgModule class.

This likely means that the library (nativescript-collectionview/angular) which declares CollectionViewModule has not been processed correctly by ngcc, or is not compatible with Angular Ivy. Check if a newer version of the library is available, and update if so. Also consider checking with the library's authors to see if the library is expected to be compatible with Ivy.

fixed, I used only version of this plugin named "nativescript-collectionview" instead of "@nativescript-community/ui-collectionview"


Illegal instruction on centos7.0

I built paddle from source code on centos7.0 successfully.
But when I try to run paddle_trainer or other binary files, it raise:
[root@iZ28zy4uk59Z bin]# ./paddle_trainer
Illegal instruction
What is wrong?

Perhaps it's because your cpu does not support avx. Can you try with cmake -DWITH_AVX=OFF?

it works, thanks very much.


[SPARK-47771][PYTHON][TESTS] Make max_by, min_by doctests deterministic

What changes were proposed in this pull request?
Make max_by, min_by doctests deterministic
Why are the changes needed?
they do fail when testing env (python version, cpu, etc) changes
Does this PR introduce any user-facing change?
no
How was this patch tested?
ci
Was this patch authored or co-authored using generative AI tooling?
no

thanks, merged to master


vagrant broken in a new WiFi network

Issue description
I've temporarily moved to another place, and now that I am on the new WiFi, I experience the following.
When I call most of vagrant commands, I get the following error:
[ihar@laptop:~/boxes/ct]$ vagrant up
/nix/store/4fi9gbwcmd78zjymj4zdvfn68yzh2938-ruby-2.4.4/lib/ruby/2.4.0/resolv.rb:111:in `=~': stack level too deep (SystemStackError)
	from /nix/store/4fi9gbwcmd78zjymj4zdvfn68yzh2938-ruby-2.4.4/lib/ruby/2.4.0/resolv.rb:111:in `each_address'
	from /nix/store/4fi9gbwcmd78zjymj4zdvfn68yzh2938-ruby-2.4.4/lib/ruby/2.4.0/resolv.rb:94:in `getaddress'
	from /nix/store/4fi9gbwcmd78zjymj4zdvfn68yzh2938-ruby-2.4.4/lib/ruby/2.4.0/resolv.rb:45:in `getaddress'
	from /nix/store/4fi9gbwcmd78zjymj4zdvfn68yzh2938-ruby-2.4.4/lib/ruby/2.4.0/resolv-replace.rb:12:in `getaddress'
	from /nix/store/4fi9gbwcmd78zjymj4zdvfn68yzh2938-ruby-2.4.4/lib/ruby/2.4.0/resolv-replace.rb:34:in `bind'
	from /nix/store/4fi9gbwcmd78zjymj4zdvfn68yzh2938-ruby-2.4.4/lib/ruby/2.4.0/resolv.rb:655:in `bind_random_port'
	from /nix/store/4fi9gbwcmd78zjymj4zdvfn68yzh2938-ruby-2.4.4/lib/ruby/2.4.0/resolv.rb:765:in `block (2 levels) in lazy_initialize'
	from /nix/store/4fi9gbwcmd78zjymj4zdvfn68yzh2938-ruby-2.4.4/lib/ruby/2.4.0/resolv.rb:748:in `each'
	from /nix/store/4fi9gbwcmd78zjymj4zdvfn68yzh2938-ruby-2.4.4/lib/ruby/2.4.0/resolv.rb:748:in `block in lazy_initialize'
	from /nix/store/4fi9gbwcmd78zjymj4zdvfn68yzh2938-ruby-2.4.4/lib/ruby/2.4.0/resolv.rb:743:in `synchronize'
	from /nix/store/4fi9gbwcmd78zjymj4zdvfn68yzh2938-ruby-2.4.4/lib/ruby/2.4.0/resolv.rb:743:in `lazy_initialize'
	from /nix/store/4fi9gbwcmd78zjymj4zdvfn68yzh2938-ruby-2.4.4/lib/ruby/2.4.0/resolv.rb:778:in `sender'
	from /nix/store/4fi9gbwcmd78zjymj4zdvfn68yzh2938-ruby-2.4.4/lib/ruby/2.4.0/resolv.rb:525:in `block in fetch_resource'
	from /nix/store/4fi9gbwcmd78zjymj4zdvfn68yzh2938-ruby-2.4.4/lib/ruby/2.4.0/resolv.rb:1133:in `block (3 levels) in resolv'
	from /nix/store/4fi9gbwcmd78zjymj4zdvfn68yzh2938-ruby-2.4.4/lib/ruby/2.4.0/resolv.rb:1131:in `each'
	from /nix/store/4fi9gbwcmd78zjymj4zdvfn68yzh2938-ruby-2.4.4/lib/ruby/2.4.0/resolv.rb:1131:in `block (2 levels) in resolv'
	from /nix/store/4fi9gbwcmd78zjymj4zdvfn68yzh2938-ruby-2.4.4/lib/ruby/2.4.0/resolv.rb:1130:in `each'
	from /nix/store/4fi9gbwcmd78zjymj4zdvfn68yzh2938-ruby-2.4.4/lib/ruby/2.4.0/resolv.rb:1130:in `block in resolv'
	from /nix/store/4fi9gbwcmd78zjymj4zdvfn68yzh2938-ruby-2.4.4/lib/ruby/2.4.0/resolv.rb:1128:in `each'
	from /nix/store/4fi9gbwcmd78zjymj4zdvfn68yzh2938-ruby-2.4.4/lib/ruby/2.4.0/resolv.rb:1128:in `resolv'
	from /nix/store/4fi9gbwcmd78zjymj4zdvfn68yzh2938-ruby-2.4.4/lib/ruby/2.4.0/resolv.rb:520:in `fetch_resource'
	from /nix/store/4fi9gbwcmd78zjymj4zdvfn68yzh2938-ruby-2.4.4/lib/ruby/2.4.0/resolv.rb:510:in `each_resource'
	from /nix/store/4fi9gbwcmd78zjymj4zdvfn68yzh2938-ruby-2.4.4/lib/ruby/2.4.0/resolv.rb:407:in `each_address'
	from /nix/store/4fi9gbwcmd78zjymj4zdvfn68yzh2938-ruby-2.4.4/lib/ruby/2.4.0/resolv.rb:117:in `block in each_address'
	from /nix/store/4fi9gbwcmd78zjymj4zdvfn68yzh2938-ruby-2.4.4/lib/ruby/2.4.0/resolv.rb:116:in `each'
	from /nix/store/4fi9gbwcmd78zjymj4zdvfn68yzh2938-ruby-2.4.4/lib/ruby/2.4.0/resolv.rb:116:in `each_address'
	from /nix/store/4fi9gbwcmd78zjymj4zdvfn68yzh2938-ruby-2.4.4/lib/ruby/2.4.0/resolv.rb:103:in `getaddresses'
	from /nix/store/4fi9gbwcmd78zjymj4zdvfn68yzh2938-ruby-2.4.4/lib/ruby/2.4.0/resolv.rb:52:in `getaddresses'
	from /nix/store/4fi9gbwcmd78zjymj4zdvfn68yzh2938-ruby-2.4.4/lib/ruby/2.4.0/resolv-replace.rb:52:in `send'
	from /nix/store/4fi9gbwcmd78zjymj4zdvfn68yzh2938-ruby-2.4.4/lib/ruby/2.4.0/resolv.rb:811:in `send'
	from /nix/store/4fi9gbwcmd78zjymj4zdvfn68yzh2938-ruby-2.4.4/lib/ruby/2.4.0/resolv.rb:673:in `request'
	from /nix/store/4fi9gbwcmd78zjymj4zdvfn68yzh2938-ruby-2.4.4/lib/ruby/2.4.0/resolv.rb:529:in `block in fetch_resource'
	from /nix/store/4fi9gbwcmd78zjymj4zdvfn68yzh2938-ruby-2.4.4/lib/ruby/2.4.0/resolv.rb:1133:in `block (3 levels) in resolv'
	from /nix/store/4fi9gbwcmd78zjymj4zdvfn68yzh2938-ruby-2.4.4/lib/ruby/2.4.0/resolv.rb:1131:in `each'
	from /nix/store/4fi9gbwcmd78zjymj4zdvfn68yzh2938-ruby-2.4.4/lib/ruby/2.4.0/resolv.rb:1131:in `block (2 levels) in resolv'
	from /nix/store/4fi9gbwcmd78zjymj4zdvfn68yzh2938-ruby-2.4.4/lib/ruby/2.4.0/resolv.rb:1130:in `each'
	from /nix/store/4fi9gbwcmd78zjymj4zdvfn68yzh2938-ruby-2.4.4/lib/ruby/2.4.0/resolv.rb:1130:in `block in resolv'
	from /nix/store/4fi9gbwcmd78zjymj4zdvfn68yzh2938-ruby-2.4.4/lib/ruby/2.4.0/resolv.rb:1128:in `each'
	from /nix/store/4fi9gbwcmd78zjymj4zdvfn68yzh2938-ruby-2.4.4/lib/ruby/2.4.0/resolv.rb:1128:in `resolv'
	from /nix/store/4fi9gbwcmd78zjymj4zdvfn68yzh2938-ruby-2.4.4/lib/ruby/2.4.0/resolv.rb:520:in `fetch_resource'
	from /nix/store/4fi9gbwcmd78zjymj4zdvfn68yzh2938-ruby-2.4.4/lib/ruby/2.4.0/resolv.rb:510:in `each_resource'
	from /nix/store/4fi9gbwcmd78zjymj4zdvfn68yzh2938-ruby-2.4.4/lib/ruby/2.4.0/resolv.rb:407:in `each_address'
	from /nix/store/4fi9gbwcmd78zjymj4zdvfn68yzh2938-ruby-2.4.4/lib/ruby/2.4.0/resolv.rb:117:in `block in each_address'
	from /nix/store/4fi9gbwcmd78zjymj4zdvfn68yzh2938-ruby-2.4.4/lib/ruby/2.4.0/resolv.rb:116:in `each'
	from /nix/store/4fi9gbwcmd78zjymj4zdvfn68yzh2938-ruby-2.4.4/lib/ruby/2.4.0/resolv.rb:116:in `each_address'
	from /nix/store/4fi9gbwcmd78zjymj4zdvfn68yzh2938-ruby-2.4.4/lib/ruby/2.4.0/resolv.rb:103:in `getaddresses'
	from /nix/store/4fi9gbwcmd78zjymj4zdvfn68yzh2938-ruby-2.4.4/lib/ruby/2.4.0/resolv.rb:52:in `getaddresses'
	from /nix/store/4fi9gbwcmd78zjymj4zdvfn68yzh2938-ruby-2.4.4/lib/ruby/2.4.0/resolv-replace.rb:52:in `send'
	from /nix/store/4fi9gbwcmd78zjymj4zdvfn68yzh2938-ruby-2.4.4/lib/ruby/2.4.0/resolv.rb:811:in `send'
	from /nix/store/4fi9gbwcmd78zjymj4zdvfn68yzh2938-ruby-2.4.4/lib/ruby/2.4.0/resolv.rb:673:in `request'
	from /nix/store/4fi9gbwcmd78zjymj4zdvfn68yzh2938-ruby-2.4.4/lib/ruby/2.4.0/resolv.rb:529:in `block in fetch_resource'
	from /nix/store/4fi9gbwcmd78zjymj4zdvfn68yzh2938-ruby-2.4.4/lib/ruby/2.4.0/resolv.rb:1133:in `block (3 levels) in resolv'
	from /nix/store/4fi9gbwcmd78zjymj4zdvfn68yzh2938-ruby-2.4.4/lib/ruby/2.4.0/resolv.rb:1131:in `each'
	from /nix/store/4fi9gbwcmd78zjymj4zdvfn68yzh2938-ruby-2.4.4/lib/ruby/2.4.0/resolv.rb:1131:in `block (2 levels) in resolv'
	from /nix/store/4fi9gbwcmd78zjymj4zdvfn68yzh2938-ruby-2.4.4/lib/ruby/2.4.0/resolv.rb:1130:in `each'
	from /nix/store/4fi9gbwcmd78zjymj4zdvfn68yzh2938-ruby-2.4.4/lib/ruby/2.4.0/resolv.rb:1130:in `block in resolv'
	from /nix/store/4fi9gbwcmd78zjymj4zdvfn68yzh2938-ruby-2.4.4/lib/ruby/2.4.0/resolv.rb:1128:in `each'
	from /nix/store/4fi9gbwcmd78zjymj4zdvfn68yzh2938-ruby-2.4.4/lib/ruby/2.4.0/resolv.rb:1128:in `resolv'
	from /nix/store/4fi9gbwcmd78zjymj4zdvfn68yzh2938-ruby-2.4.4/lib/ruby/2.4.0/resolv.rb:520:in `fetch_resource'
	from /nix/store/4fi9gbwcmd78zjymj4zdvfn68yzh2938-ruby-2.4.4/lib/ruby/2.4.0/resolv.rb:510:in `each_resource'
	from /nix/store/4fi9gbwcmd78zjymj4zdvfn68yzh2938-ruby-2.4.4/lib/ruby/2.4.0/resolv.rb:407:in `each_address'
	from /nix/store/4fi9gbwcmd78zjymj4zdvfn68yzh2938-ruby-2.4.4/lib/ruby/2.4.0/resolv.rb:117:in `block in each_address'
	from /nix/store/4fi9gbwcmd78zjymj4zdvfn68yzh2938-ruby-2.4.4/lib/ruby/2.4.0/resolv.rb:116:in `each'
	from /nix/store/4fi9gbwcmd78zjymj4zdvfn68yzh2938-ruby-2.4.4/lib/ruby/2.4.0/resolv.rb:116:in `each_address'
	from /nix/store/4fi9gbwcmd78zjymj4zdvfn68yzh2938-ruby-2.4.4/lib/ruby/2.4.0/resolv.rb:103:in `getaddresses'
	from /nix/store/4fi9gbwcmd78zjymj4zdvfn68yzh2938-ruby-2.4.4/lib/ruby/2.4.0/resolv.rb:52:in `getaddresses'
	from /nix/store/4fi9gbwcmd78zjymj4zdvfn68yzh2938-ruby-2.4.4/lib/ruby/2.4.0/resolv-replace.rb:52:in `send'
	from /nix/store/4fi9gbwcmd78zjymj4zdvfn68yzh2938-ruby-2.4.4/lib/ruby/2.4.0/resolv.rb:811:in `send'
	from /nix/store/4fi9gbwcmd78zjymj4zdvfn68yzh2938-ruby-2.4.4/lib/ruby/2.4.0/resolv.rb:673:in `request'
	from /nix/store/4fi9gbwcmd78zjymj4zdvfn68yzh2938-ruby-2.4.4/lib/ruby/2.4.0/resolv.rb:529:in `block in fetch_resource'
	from /nix/store/4fi9gbwcmd78zjymj4zdvfn68yzh2938-ruby-2.4.4/lib/ruby/2.4.0/resolv.rb:1133:in `block (3 levels) in resolv'
	from /nix/store/4fi9gbwcmd78zjymj4zdvfn68yzh2938-ruby-2.4.4/lib/ruby/2.4.0/resolv.rb:1131:in `each'
	from /nix/store/4fi9gbwcmd78zjymj4zdvfn68yzh2938-ruby-2.4.4/lib/ruby/2.4.0/resolv.rb:1131:in `block (2 levels) in resolv'
	from /nix/store/4fi9gbwcmd78zjymj4zdvfn68yzh2938-ruby-2.4.4/lib/ruby/2.4.0/resolv.rb:1130:in `each'
	from /nix/store/4fi9gbwcmd78zjymj4zdvfn68yzh2938-ruby-2.4.4/lib/ruby/2.4.0/resolv.rb:1130:in `block in resolv'
	from /nix/store/4fi9gbwcmd78zjymj4zdvfn68yzh2938-ruby-2.4.4/lib/ruby/2.4.0/resolv.rb:1128:in `each'
	from /nix/store/4fi9gbwcmd78zjymj4zdvfn68yzh2938-ruby-2.4.4/lib/ruby/2.4.0/resolv.rb:1128:in `resolv'
	from /nix/store/4fi9gbwcmd78zjymj4zdvfn68yzh2938-ruby-2.4.4/lib/ruby/2.4.0/resolv.rb:520:in `fetch_resource'
	from /nix/store/4fi9gbwcmd78zjymj4zdvfn68yzh2938-ruby-2.4.4/lib/ruby/2.4.0/resolv.rb:510:in `each_resource'
	from /nix/store/4fi9gbwcmd78zjymj4zdvfn68yzh2938-ruby-2.4.4/lib/ruby/2.4.0/resolv.rb:407:in `each_address'
	from /nix/store/4fi9gbwcmd78zjymj4zdvfn68yzh2938-ruby-2.4.4/lib/ruby/2.4.0/resolv.rb:117:in `block in each_address'
	from /nix/store/4fi9gbwcmd78zjymj4zdvfn68yzh2938-ruby-2.4.4/lib/ruby/2.4.0/resolv.rb:116:in `each'
	from /nix/store/4fi9gbwcmd78zjymj4zdvfn68yzh2938-ruby-2.4.4/lib/ruby/2.4.0/resolv.rb:116:in `each_address'
	from /nix/store/4fi9gbwcmd78zjymj4zdvfn68yzh2938-ruby-2.4.4/lib/ruby/2.4.0/resolv.rb:103:in `getaddresses'
	from /nix/store/4fi9gbwcmd78zjymj4zdvfn68yzh2938-ruby-2.4.4/lib/ruby/2.4.0/resolv.rb:52:in `getaddresses'
	from /nix/store/4fi9gbwcmd78zjymj4zdvfn68yzh2938-ruby-2.4.4/lib/ruby/2.4.0/resolv-replace.rb:52:in `send'
	from /nix/store/4fi9gbwcmd78zjymj4zdvfn68yzh2938-ruby-2.4.4/lib/ruby/2.4.0/resolv.rb:811:in `send'
	from /nix/store/4fi9gbwcmd78zjymj4zdvfn68yzh2938-ruby-2.4.4/lib/ruby/2.4.0/resolv.rb:673:in `request'
	from /nix/store/4fi9gbwcmd78zjymj4zdvfn68yzh2938-ruby-2.4.4/lib/ruby/2.4.0/resolv.rb:529:in `block in fetch_resource'
	from /nix/store/4fi9gbwcmd78zjymj4zdvfn68yzh2938-ruby-2.4.4/lib/ruby/2.4.0/resolv.rb:1133:in `block (3 levels) in resolv'
	from /nix/store/4fi9gbwcmd78zjymj4zdvfn68yzh2938-ruby-2.4.4/lib/ruby/2.4.0/resolv.rb:1131:in `each'
	from /nix/store/4fi9gbwcmd78zjymj4zdvfn68yzh2938-ruby-2.4.4/lib/ruby/2.4.0/resolv.rb:1131:in `block (2 levels) in resolv'
	from /nix/store/4fi9gbwcmd78zjymj4zdvfn68yzh2938-ruby-2.4.4/lib/ruby/2.4.0/resolv.rb:1130:in `each'
	from /nix/store/4fi9gbwcmd78zjymj4zdvfn68yzh2938-ruby-2.4.4/lib/ruby/2.4.0/resolv.rb:1130:in `block in resolv'
	from /nix/store/4fi9gbwcmd78zjymj4zdvfn68yzh2938-ruby-2.4.4/lib/ruby/2.4.0/resolv.rb:1128:in `each'
	from /nix/store/4fi9gbwcmd78zjymj4zdvfn68yzh2938-ruby-2.4.4/lib/ruby/2.4.0/resolv.rb:1128:in `resolv'
	from /nix/store/4fi9gbwcmd78zjymj4zdvfn68yzh2938-ruby-2.4.4/lib/ruby/2.4.0/resolv.rb:520:in `fetch_resource'
	from /nix/store/4fi9gbwcmd78zjymj4zdvfn68yzh2938-ruby-2.4.4/lib/ruby/2.4.0/resolv.rb:510:in `each_resource'
	from /nix/store/4fi9gbwcmd78zjymj4zdvfn68yzh2938-ruby-2.4.4/lib/ruby/2.4.0/resolv.rb:407:in `each_address'
	from /nix/store/4fi9gbwcmd78zjymj4zdvfn68yzh2938-ruby-2.4.4/lib/ruby/2.4.0/resolv.rb:117:in `block in each_address'
	 ... 2426 levels...
	from /nix/store/4fi9gbwcmd78zjymj4zdvfn68yzh2938-ruby-2.4.4/lib/ruby/2.4.0/resolv.rb:1128:in `each'
	from /nix/store/4fi9gbwcmd78zjymj4zdvfn68yzh2938-ruby-2.4.4/lib/ruby/2.4.0/resolv.rb:1128:in `resolv'
	from /nix/store/4fi9gbwcmd78zjymj4zdvfn68yzh2938-ruby-2.4.4/lib/ruby/2.4.0/resolv.rb:520:in `fetch_resource'
	from /nix/store/4fi9gbwcmd78zjymj4zdvfn68yzh2938-ruby-2.4.4/lib/ruby/2.4.0/resolv.rb:510:in `each_resource'
	from /nix/store/4fi9gbwcmd78zjymj4zdvfn68yzh2938-ruby-2.4.4/lib/ruby/2.4.0/resolv.rb:407:in `each_address'
	from /nix/store/4fi9gbwcmd78zjymj4zdvfn68yzh2938-ruby-2.4.4/lib/ruby/2.4.0/resolv.rb:117:in `block in each_address'
	from /nix/store/4fi9gbwcmd78zjymj4zdvfn68yzh2938-ruby-2.4.4/lib/ruby/2.4.0/resolv.rb:116:in `each'
	from /nix/store/4fi9gbwcmd78zjymj4zdvfn68yzh2938-ruby-2.4.4/lib/ruby/2.4.0/resolv.rb:116:in `each_address'
	from /nix/store/4fi9gbwcmd78zjymj4zdvfn68yzh2938-ruby-2.4.4/lib/ruby/2.4.0/resolv.rb:103:in `getaddresses'
	from /nix/store/4fi9gbwcmd78zjymj4zdvfn68yzh2938-ruby-2.4.4/lib/ruby/2.4.0/resolv.rb:52:in `getaddresses'
	from /nix/store/4fi9gbwcmd78zjymj4zdvfn68yzh2938-ruby-2.4.4/lib/ruby/2.4.0/resolv-replace.rb:52:in `send'
	from /nix/store/4fi9gbwcmd78zjymj4zdvfn68yzh2938-ruby-2.4.4/lib/ruby/2.4.0/resolv.rb:811:in `send'
	from /nix/store/4fi9gbwcmd78zjymj4zdvfn68yzh2938-ruby-2.4.4/lib/ruby/2.4.0/resolv.rb:673:in `request'
	from /nix/store/4fi9gbwcmd78zjymj4zdvfn68yzh2938-ruby-2.4.4/lib/ruby/2.4.0/resolv.rb:529:in `block in fetch_resource'
	from /nix/store/4fi9gbwcmd78zjymj4zdvfn68yzh2938-ruby-2.4.4/lib/ruby/2.4.0/resolv.rb:1133:in `block (3 levels) in resolv'
	from /nix/store/4fi9gbwcmd78zjymj4zdvfn68yzh2938-ruby-2.4.4/lib/ruby/2.4.0/resolv.rb:1131:in `each'
	from /nix/store/4fi9gbwcmd78zjymj4zdvfn68yzh2938-ruby-2.4.4/lib/ruby/2.4.0/resolv.rb:1131:in `block (2 levels) in resolv'
	from /nix/store/4fi9gbwcmd78zjymj4zdvfn68yzh2938-ruby-2.4.4/lib/ruby/2.4.0/resolv.rb:1130:in `each'
	from /nix/store/4fi9gbwcmd78zjymj4zdvfn68yzh2938-ruby-2.4.4/lib/ruby/2.4.0/resolv.rb:1130:in `block in resolv'
	from /nix/store/4fi9gbwcmd78zjymj4zdvfn68yzh2938-ruby-2.4.4/lib/ruby/2.4.0/resolv.rb:1128:in `each'
	from /nix/store/4fi9gbwcmd78zjymj4zdvfn68yzh2938-ruby-2.4.4/lib/ruby/2.4.0/resolv.rb:1128:in `resolv'
	from /nix/store/4fi9gbwcmd78zjymj4zdvfn68yzh2938-ruby-2.4.4/lib/ruby/2.4.0/resolv.rb:520:in `fetch_resource'
	from /nix/store/4fi9gbwcmd78zjymj4zdvfn68yzh2938-ruby-2.4.4/lib/ruby/2.4.0/resolv.rb:510:in `each_resource'
	from /nix/store/4fi9gbwcmd78zjymj4zdvfn68yzh2938-ruby-2.4.4/lib/ruby/2.4.0/resolv.rb:407:in `each_address'
	from /nix/store/4fi9gbwcmd78zjymj4zdvfn68yzh2938-ruby-2.4.4/lib/ruby/2.4.0/resolv.rb:117:in `block in each_address'
	from /nix/store/4fi9gbwcmd78zjymj4zdvfn68yzh2938-ruby-2.4.4/lib/ruby/2.4.0/resolv.rb:116:in `each'
	from /nix/store/4fi9gbwcmd78zjymj4zdvfn68yzh2938-ruby-2.4.4/lib/ruby/2.4.0/resolv.rb:116:in `each_address'
	from /nix/store/4fi9gbwcmd78zjymj4zdvfn68yzh2938-ruby-2.4.4/lib/ruby/2.4.0/resolv.rb:103:in `getaddresses'
	from /nix/store/4fi9gbwcmd78zjymj4zdvfn68yzh2938-ruby-2.4.4/lib/ruby/2.4.0/resolv.rb:52:in `getaddresses'
	from /nix/store/4fi9gbwcmd78zjymj4zdvfn68yzh2938-ruby-2.4.4/lib/ruby/2.4.0/resolv-replace.rb:52:in `send'
	from /nix/store/4fi9gbwcmd78zjymj4zdvfn68yzh2938-ruby-2.4.4/lib/ruby/2.4.0/resolv.rb:811:in `send'
	from /nix/store/4fi9gbwcmd78zjymj4zdvfn68yzh2938-ruby-2.4.4/lib/ruby/2.4.0/resolv.rb:673:in `request'
	from /nix/store/4fi9gbwcmd78zjymj4zdvfn68yzh2938-ruby-2.4.4/lib/ruby/2.4.0/resolv.rb:529:in `block in fetch_resource'
	from /nix/store/4fi9gbwcmd78zjymj4zdvfn68yzh2938-ruby-2.4.4/lib/ruby/2.4.0/resolv.rb:1133:in `block (3 levels) in resolv'
	from /nix/store/4fi9gbwcmd78zjymj4zdvfn68yzh2938-ruby-2.4.4/lib/ruby/2.4.0/resolv.rb:1131:in `each'
	from /nix/store/4fi9gbwcmd78zjymj4zdvfn68yzh2938-ruby-2.4.4/lib/ruby/2.4.0/resolv.rb:1131:in `block (2 levels) in resolv'
	from /nix/store/4fi9gbwcmd78zjymj4zdvfn68yzh2938-ruby-2.4.4/lib/ruby/2.4.0/resolv.rb:1130:in `each'
	from /nix/store/4fi9gbwcmd78zjymj4zdvfn68yzh2938-ruby-2.4.4/lib/ruby/2.4.0/resolv.rb:1130:in `block in resolv'
	from /nix/store/4fi9gbwcmd78zjymj4zdvfn68yzh2938-ruby-2.4.4/lib/ruby/2.4.0/resolv.rb:1128:in `each'
	from /nix/store/4fi9gbwcmd78zjymj4zdvfn68yzh2938-ruby-2.4.4/lib/ruby/2.4.0/resolv.rb:1128:in `resolv'
	from /nix/store/4fi9gbwcmd78zjymj4zdvfn68yzh2938-ruby-2.4.4/lib/ruby/2.4.0/resolv.rb:520:in `fetch_resource'
	from /nix/store/4fi9gbwcmd78zjymj4zdvfn68yzh2938-ruby-2.4.4/lib/ruby/2.4.0/resolv.rb:510:in `each_resource'
	from /nix/store/4fi9gbwcmd78zjymj4zdvfn68yzh2938-ruby-2.4.4/lib/ruby/2.4.0/resolv.rb:407:in `each_address'
	from /nix/store/4fi9gbwcmd78zjymj4zdvfn68yzh2938-ruby-2.4.4/lib/ruby/2.4.0/resolv.rb:117:in `block in each_address'
	from /nix/store/4fi9gbwcmd78zjymj4zdvfn68yzh2938-ruby-2.4.4/lib/ruby/2.4.0/resolv.rb:116:in `each'
	from /nix/store/4fi9gbwcmd78zjymj4zdvfn68yzh2938-ruby-2.4.4/lib/ruby/2.4.0/resolv.rb:116:in `each_address'
	from /nix/store/4fi9gbwcmd78zjymj4zdvfn68yzh2938-ruby-2.4.4/lib/ruby/2.4.0/resolv.rb:103:in `getaddresses'
	from /nix/store/4fi9gbwcmd78zjymj4zdvfn68yzh2938-ruby-2.4.4/lib/ruby/2.4.0/resolv.rb:52:in `getaddresses'
	from /nix/store/4fi9gbwcmd78zjymj4zdvfn68yzh2938-ruby-2.4.4/lib/ruby/2.4.0/resolv-replace.rb:52:in `send'
	from /nix/store/4fi9gbwcmd78zjymj4zdvfn68yzh2938-ruby-2.4.4/lib/ruby/2.4.0/resolv.rb:811:in `send'
	from /nix/store/4fi9gbwcmd78zjymj4zdvfn68yzh2938-ruby-2.4.4/lib/ruby/2.4.0/resolv.rb:673:in `request'
	from /nix/store/4fi9gbwcmd78zjymj4zdvfn68yzh2938-ruby-2.4.4/lib/ruby/2.4.0/resolv.rb:529:in `block in fetch_resource'
	from /nix/store/4fi9gbwcmd78zjymj4zdvfn68yzh2938-ruby-2.4.4/lib/ruby/2.4.0/resolv.rb:1133:in `block (3 levels) in resolv'
	from /nix/store/4fi9gbwcmd78zjymj4zdvfn68yzh2938-ruby-2.4.4/lib/ruby/2.4.0/resolv.rb:1131:in `each'
	from /nix/store/4fi9gbwcmd78zjymj4zdvfn68yzh2938-ruby-2.4.4/lib/ruby/2.4.0/resolv.rb:1131:in `block (2 levels) in resolv'
	from /nix/store/4fi9gbwcmd78zjymj4zdvfn68yzh2938-ruby-2.4.4/lib/ruby/2.4.0/resolv.rb:1130:in `each'
	from /nix/store/4fi9gbwcmd78zjymj4zdvfn68yzh2938-ruby-2.4.4/lib/ruby/2.4.0/resolv.rb:1130:in `block in resolv'
	from /nix/store/4fi9gbwcmd78zjymj4zdvfn68yzh2938-ruby-2.4.4/lib/ruby/2.4.0/resolv.rb:1128:in `each'
	from /nix/store/4fi9gbwcmd78zjymj4zdvfn68yzh2938-ruby-2.4.4/lib/ruby/2.4.0/resolv.rb:1128:in `resolv'
	from /nix/store/4fi9gbwcmd78zjymj4zdvfn68yzh2938-ruby-2.4.4/lib/ruby/2.4.0/resolv.rb:520:in `fetch_resource'
	from /nix/store/4fi9gbwcmd78zjymj4zdvfn68yzh2938-ruby-2.4.4/lib/ruby/2.4.0/resolv.rb:510:in `each_resource'
	from /nix/store/4fi9gbwcmd78zjymj4zdvfn68yzh2938-ruby-2.4.4/lib/ruby/2.4.0/resolv.rb:407:in `each_address'
	from /nix/store/4fi9gbwcmd78zjymj4zdvfn68yzh2938-ruby-2.4.4/lib/ruby/2.4.0/resolv.rb:117:in `block in each_address'
	from /nix/store/4fi9gbwcmd78zjymj4zdvfn68yzh2938-ruby-2.4.4/lib/ruby/2.4.0/resolv.rb:116:in `each'
	from /nix/store/4fi9gbwcmd78zjymj4zdvfn68yzh2938-ruby-2.4.4/lib/ruby/2.4.0/resolv.rb:116:in `each_address'
	from /nix/store/4fi9gbwcmd78zjymj4zdvfn68yzh2938-ruby-2.4.4/lib/ruby/2.4.0/resolv.rb:103:in `getaddresses'
	from /nix/store/4fi9gbwcmd78zjymj4zdvfn68yzh2938-ruby-2.4.4/lib/ruby/2.4.0/resolv.rb:52:in `getaddresses'
	from /nix/store/4fi9gbwcmd78zjymj4zdvfn68yzh2938-ruby-2.4.4/lib/ruby/2.4.0/resolv-replace.rb:52:in `send'
	from /nix/store/4fi9gbwcmd78zjymj4zdvfn68yzh2938-ruby-2.4.4/lib/ruby/2.4.0/resolv.rb:811:in `send'
	from /nix/store/4fi9gbwcmd78zjymj4zdvfn68yzh2938-ruby-2.4.4/lib/ruby/2.4.0/resolv.rb:673:in `request'
	from /nix/store/4fi9gbwcmd78zjymj4zdvfn68yzh2938-ruby-2.4.4/lib/ruby/2.4.0/resolv.rb:529:in `block in fetch_resource'
	from /nix/store/4fi9gbwcmd78zjymj4zdvfn68yzh2938-ruby-2.4.4/lib/ruby/2.4.0/resolv.rb:1133:in `block (3 levels) in resolv'
	from /nix/store/4fi9gbwcmd78zjymj4zdvfn68yzh2938-ruby-2.4.4/lib/ruby/2.4.0/resolv.rb:1131:in `each'
	from /nix/store/4fi9gbwcmd78zjymj4zdvfn68yzh2938-ruby-2.4.4/lib/ruby/2.4.0/resolv.rb:1131:in `block (2 levels) in resolv'
	from /nix/store/4fi9gbwcmd78zjymj4zdvfn68yzh2938-ruby-2.4.4/lib/ruby/2.4.0/resolv.rb:1130:in `each'
	from /nix/store/4fi9gbwcmd78zjymj4zdvfn68yzh2938-ruby-2.4.4/lib/ruby/2.4.0/resolv.rb:1130:in `block in resolv'
	from /nix/store/4fi9gbwcmd78zjymj4zdvfn68yzh2938-ruby-2.4.4/lib/ruby/2.4.0/resolv.rb:1128:in `each'
	from /nix/store/4fi9gbwcmd78zjymj4zdvfn68yzh2938-ruby-2.4.4/lib/ruby/2.4.0/resolv.rb:1128:in `resolv'
	from /nix/store/4fi9gbwcmd78zjymj4zdvfn68yzh2938-ruby-2.4.4/lib/ruby/2.4.0/resolv.rb:520:in `fetch_resource'
	from /nix/store/4fi9gbwcmd78zjymj4zdvfn68yzh2938-ruby-2.4.4/lib/ruby/2.4.0/resolv.rb:510:in `each_resource'
	from /nix/store/4fi9gbwcmd78zjymj4zdvfn68yzh2938-ruby-2.4.4/lib/ruby/2.4.0/resolv.rb:407:in `each_address'
	from /nix/store/4fi9gbwcmd78zjymj4zdvfn68yzh2938-ruby-2.4.4/lib/ruby/2.4.0/resolv.rb:117:in `block in each_address'
	from /nix/store/4fi9gbwcmd78zjymj4zdvfn68yzh2938-ruby-2.4.4/lib/ruby/2.4.0/resolv.rb:116:in `each'
	from /nix/store/4fi9gbwcmd78zjymj4zdvfn68yzh2938-ruby-2.4.4/lib/ruby/2.4.0/resolv.rb:116:in `each_address'
	from /nix/store/4fi9gbwcmd78zjymj4zdvfn68yzh2938-ruby-2.4.4/lib/ruby/2.4.0/resolv.rb:94:in `getaddress'
	from /nix/store/4fi9gbwcmd78zjymj4zdvfn68yzh2938-ruby-2.4.4/lib/ruby/2.4.0/resolv.rb:45:in `getaddress'
	from /nix/store/4fi9gbwcmd78zjymj4zdvfn68yzh2938-ruby-2.4.4/lib/ruby/2.4.0/resolv-replace.rb:12:in `getaddress'
	from /nix/store/4fi9gbwcmd78zjymj4zdvfn68yzh2938-ruby-2.4.4/lib/ruby/2.4.0/resolv-replace.rb:25:in `initialize'
	from /nix/store/4fi9gbwcmd78zjymj4zdvfn68yzh2938-ruby-2.4.4/lib/ruby/2.4.0/net/http.rb:904:in `open'
	from /nix/store/4fi9gbwcmd78zjymj4zdvfn68yzh2938-ruby-2.4.4/lib/ruby/2.4.0/net/http.rb:904:in `block in connect'
	from /nix/store/4fi9gbwcmd78zjymj4zdvfn68yzh2938-ruby-2.4.4/lib/ruby/2.4.0/timeout.rb:93:in `block in timeout'
	from /nix/store/4fi9gbwcmd78zjymj4zdvfn68yzh2938-ruby-2.4.4/lib/ruby/2.4.0/timeout.rb:103:in `timeout'
	from /nix/store/4fi9gbwcmd78zjymj4zdvfn68yzh2938-ruby-2.4.4/lib/ruby/2.4.0/net/http.rb:902:in `connect'
	from /nix/store/4fi9gbwcmd78zjymj4zdvfn68yzh2938-ruby-2.4.4/lib/ruby/2.4.0/net/http.rb:887:in `do_start'
	from /nix/store/4fi9gbwcmd78zjymj4zdvfn68yzh2938-ruby-2.4.4/lib/ruby/2.4.0/net/http.rb:876:in `start'
	from /nix/store/4fi9gbwcmd78zjymj4zdvfn68yzh2938-ruby-2.4.4/lib/ruby/2.4.0/net/http.rb:1407:in `request'
	from /nix/store/4fi9gbwcmd78zjymj4zdvfn68yzh2938-ruby-2.4.4/lib/ruby/2.4.0/net/http.rb:1165:in `get'
	from /nix/store/7wq1sxnc90mzn8bry8n58i1fqdx2hflf-ruby2.4.4-hashicorp-checkpoint-0.1.5/lib/ruby/gems/2.4.0/gems/hashicorp-checkpoint-0.1.5/lib/checkpoint.rb:91:in `check'
	from /nix/store/1i29w05n3kyk46gx4m1hlv96324brmdv-vagrant-2.0.2/lib/ruby/gems/2.4.0/gems/vagrant-2.0.2/lib/vagrant/util/checkpoint_client.rb:78:in `block in check'

Steps to reproduce
Just install vagrant and then call vagrant global-status.
Technical details
[ihar@laptop:~/boxes/ct]$ nix-shell -p nix-info --run "nix-info -m"
 - system: `"x86_64-linux"`
 - host os: `Linux 4.14.56, NixOS, 18.03.132915.d6c6c7fcec6 (Impala)`
 - multi-user?: `yes`
 - sandbox: `no`
 - version: `nix-env (Nix) 2.0.4`
 - channels(ihar): `""`
 - channels(root): `"nixos-18.03.132915.d6c6c7fcec6"`
 - nixpkgs: `/nix/var/nix/profiles/per-user/root/channels/nixos/nixpkgs`

[ihar@laptop:~/boxes/ct]$ vagrant --version
Vagrant 2.0.2

The workaround works as follows:
export VAGRANT_DISABLE_RESOLV_REPLACE=1

I believe this issue is the same as: https://github.com/hashicorp/vagrant/issues/9595 that was fixed in 2.0.4: https://github.com/hashicorp/vagrant/pull/9644/commits/30e7e81eab1d7fbb65ceb79afe3133e8df59b1e4 (it's still 2.0.2 in my nixos setup).
My /etc/resolv.conf is as follows:
[ihar@laptop:~]$ cat /etc/resolv.conf
# Generated by resolvconf
nameserver fe80::1%wlp4s0
nameserver <IP_ADDRESS>
options edns0

I guess the proper fix is to either export this envvar for all users, or to bump vagrant version.

Not reproducible anymore, Linux Kernel 4.X, newer Vagrant available