BTreeIterator is very slow

You mention that forEach is more efficient than a regular for loop for BTrees, which isn't really ideal. It's true that it's a lot easier to write an efficient forEach implementation than to write an efficient iterator, but it's possible to write an efficient iterator! As a proof of concept, here's an improved BTreeIterator:
public class BTreeIterator<Key: Comparable, Value>: IteratorProtocol {
    public typealias Element = (Key, Value)
    typealias Node = BTreeNode<Key, Value>

    let node: Node

    var iterator: BTreeIterator?
    var index = -1

    init(root: Node) {
        node = root
        incrementChildIterator()
    }

    private func incrementChildIterator() {
        index += 1
        if !node.isLeaf && index < node.children.count {
            iterator = node.children[index].makeIterator()
        }
    }

    public func next() -> Element? {
        if let childIterator = iterator {
            if let nextElement = childIterator.next() {
                return nextElement
            }
            else {
                iterator = nil
                return next()
            }
        }
        else {
            guard index < node.elements.count else { return nil }

            defer { incrementChildIterator() }
            return node.elements[index]
        }
    }
}

My benchmarks show no significant performance difference between for-in and forEach, now. Let me know what you think!

This is neat! Reminds me a little of the segmented iterators article (http://lafstern.org/matt/segmented.pdf).
The iterator should be a COW value type, so it needs a simple wrapper struct; but other than that, this looks great.
BTreePath shouldn't be too slow, though. Maybe it should be refactored to speed it up as well.
I think it's time for me to set up a benchmarking build target (issue #5) — it's hard to reason about performance without verifiable measurements.

Interesting article, that's indeed very similar.
When I implemented in-order iteration on a binary search tree, I first went with recursive iteration (like the snippet above), but using a stack turned out to be way more efficient, because it wouldn't need an iterator for every single node. This isn't as much of a problem for B-Trees, it seems, because of the relatively low amount of nodes. Still, it might be worth exploring using a stack instead, as it also would allow using a struct rather than a class.

I was working on this some more, and it's looking really good. The only downside is that this approach without BTreeStrongPath doesn't really support makeIterator(from:), makeIterator(fromOffset:) and makeIterator(from:choosing:).
How big of a deal is this? I find it a bit counterintuitive to cal makeIterator() manually, so I'm not sure what I would use these functions for. Wouldn't it make more sense for the user tot first slice the tree and then iterate over it?

Adding those methods seemed like a good idea at the time, but I haven't actually found them very useful in practice. I don't think it'd be a big deal to remove them at all—the package's API surface is rather too large anyway. (Although if necessary I believe we could also write code to convert to/from your iterators and strong paths.) The same goes for the stoppable forEach variant: if iteration is fast, there is no need to include it.
I'm still surprised BTreeStrongPath turned out to be so slow — it doesn't really do anything that should cost much performance. It does keep track of the current offset, but it has the current node immediately available, which prevents the need for recursion on every iteration — so I'd've expected it to have comparable performance.
I had to work on SortedBag for another project, but now that's done I can hopefully start benchmarking soon — I really want to understand what's going on there.

I'll try to see if I can find out what's so slow about the current indexing as well. Meanwhile, maybe it's a good idea to add a 5.0 branch?

Ah, indeed, a new branch is a good idea.

OK, so I added a really simple iteration benchmark. It reproduces your results; iteration is indeed much slower than I expected:

What's remarkable is that BTreeIterator is even slower than traversing the tree using cursors.

I did a bunch of tests, and found something really interesting. If I copy the entire library to my project (so no import), and I run the tests under release mode from the command line, the 4.0.1 iterator is ridiculously fast. Ten times as fast as forEach.
Strangely enough, running the tests in Xcode itself doesn't show anything of the sort, as 1. forEach beats the iterator there, and 2. both are way slower than in the command line (forEach is about 4 times as slow, the iterator is about 200 (!) times as slow). I'm doing all tests in the standard release configuration, so I don't understand where these differences come from.
Could you try to reproduce any of this?

On 2016-11-09, at 00:30, Tim Vermeulen<EMAIL_ADDRESS>wrote:
I did a bunch of tests, and found something really interesting. If I copy the entire library to my project (so no import), and I run the tests under release mode from the command line, the 4.0.1 iterator is ridiculously fast. Ten times as fast as forEach.

In-module performance is expected to be ridiculuously fast (see below), but wow, forEach shouldn’t ever be slower than BTreeIterator -- these surprises make benchmarking fun. :-)

Strangely enough, running the tests in Xcode itself doesn't show anything of the sort, as 1. forEach beats the iterator there, and 2. both are way slower than in the command line (forEach is about 4 times as slow, the iterator is about 200 (!) times as slow). I'm doing all tests in the standard release configuration, so I don't understand where these differences come from.
Could you try to reproduce any of this?

Compiling BTree in the same module as your source code will allow whole module optimization to kick in, which enables generic specialization. 4x-200x speedups are right in the expected range. (See the light green vs. dark green lines in README's benchmarks, for example; also, see the section on imported generics at the end:)
https://github.com/lorentey/BTree#remark-on-performance-of-imported-generics https://github.com/lorentey/BTree#remark-on-performance-of-imported-generics
This is a serious limitation for collection packages like BTree; unfortunately, we don’t have a way around it at this time. I think there is a way to specify a list of type parameters for which specific methods should be pre-specialized during module compilation (with @_specialize attributes), but AFAICT it’s not public API, and it might not work correctly yet. I haven’t tried it yet, but it would be worth a look.
You don’t see the same effect for stdlib types like Array because stdlib is essentially compiled anew with each module. This will not remain like this forever: once we have stable ABI, stdlib might become a normal Swift library, and Swift will have to provide new solutions to keep Array/Dictionary/etc performant. Perhaps third-party libraries will get to use those as well. (And if not, we can just propose to add new collections to stdlib.)
Compiled as an external module, BTree's algorithmic performance improvements can easily run laps over stdlib’s collection types -- but it takes quite a lot of elements for this to be measurable. For operations that don’t have algorithmic improvements (like iteration), a cross-module collection is unlikely to get close to what Array et al. provide, at least not in Swift 3 -- but we can often reduce the 200x slowdown to ~10x with carefully chosen API. (Cursor is a good example of this, although it’s nowhere near 10x.)
None if this is really worth worrying much about -- cross-module Swift collections should still be able to beat (or at least match) the performance of the best Objective-C collections; and we’ve been happily using those for decades.
However, optimizing for cross-module performance is very different to optimization when generic specialization is available. I’m not sure which kind we should optimize for in BTree’s case: I expect the vast majority of people will just use it via CocoaPods/Carthage/SPM, but there will definitely be some who’ll want to “inline” it into one of their modules for a speed boost.

Right, so I was aware about the optimisation limitations of imported generics. I think it's a shame that it probably won't be fixed very soon, but I don't doubt that it will be fixed eventually, so it would probably make the most sense to optimise for that (especially since people can already compile the library in their own module if they want to).
However, the 4x-200x differences were made between the command line and Xcode, not between importing and not importing. But I found out that I forgot to turn on whole-module optimisation, so that explains a lot!
Still, it's a big mystery why the iterator beats forEach (in my tests). Here's my benchmark:
let list = List(0 ..< 100_000_000)
let result =<PHONE_NUMBER>000000

let start = Date()

var sum = 0
for element in list {
    sum += element
}
print(sum == result) // true

let end = Date()
print(end.timeIntervalSince(start))

It runs in ~0.7 sec, while using forEach instead takes nearly 7 seconds. Do you see anything wrong with this particular benchmark?

@lorentey are the recommendations under https://github.com/lorentey/BTree#remark-on-performance-of-imported-generics still valid for Swift 5? It's been 3+ years since the last comment on this thread. Curious if copying the BTree project into a module is still required for a speed boost.

The technical limitation was resolved by the introduction of @inlinable, but this package has not adopted it.
We're working on a new "official" implementation in https://github.com/apple/swift-collections/issues/1 -- I expect that work will replace this package.


Update all project versions to 0.1.0-SNAPSHOT

The initial release version of the Eclipse PASS project will be: 0.1.0. To prepare for this release, all Java project versions should be updated to 0.1.0-SNAPSHOT.

repo
PR when available
PR reviewed
release deployed

main

pass-java-client

pass-messaging-support

pass-indexer

pass-nihms-loader

pass-grant-loader

pass-journal-loader

pass-notification-services

pass-doi-service

pass-indexer-checker

pass-fcrepo-jsonld

pass-fcrepo-jms

pass-authz

pass-package-providers

pass-deposit-services


Documentation display delay and hovered item preview caption

Pull Request Description
This PR adds a configurable delay before displaying documentation (task) and a "hovered item preview" caption on top of the panel when you hover some not-selected entry. (task). The caption design will be adjusted in a future PR with a style update.
https://user-images.githubusercontent.com/6566674/214233481-10550fcf-a106-4b11-b5a2-15283745cbbf.mp4
Important Notes
Checklist
Please include the following checklist in your PR:

[x] The documentation has been updated if necessary.
[x] All code conforms to the
Scala,
Java,
and
Rust
style guides.
All code has been tested:

[x] Unit tests have been written where possible.
[x] If GUI codebase was changed: Enso GUI was tested when built using BOTH
./run ide build and ./run ide watch.

This PR contains A LOT more code than needed for adding the delay for showing the documentation. Please update the description because it's hard to read the code not knowing what was the intention for all the changes.

Unfortunately, you saw an invalid state of the PR after the base branch switch, it is fixed now.


Fix merge conflicts in mstepien PR

Coverage remained the same at 67.86% when pulling ad7ac6a4e4689de452f0200cc736a850ad294979 on mstepien-patch-1 into ecfb87810c7c93623b9e7037c6809e55729d759c on master.


Add circle config and necessary wrappers to run the build

Need to verify this is correct with the docker images we're using and check published artifacts

Ok, this seems to be correct for 64 bit linux and osx


Swc fails to transpile optional chain operators in parentheses with an outer optional chain

Describe the bug
It seems like, in certain cases involving parentheses, the transpiler is not properly removing the optional chain operator even though es5 is the target. I've included a very small reproduction case for the issue.
Input code
// The type cast actually doesn't matter for reproducing the issue, but, I've included it to illustrate a realistic use case.
const foo = (a?.b as string)?.c;

Config
{
  "jsc": {
    "parser": {
      "syntax": "typescript",
      "tsx": true,
      "dynamicImport": true
    },
    "transform": {
      "react": {
        "refresh": true
      }
    },
    "target": "es5",
  },
  "module": {
    "type": "commonjs",
    "ignoreDynamic": true,
    "strictMode": false
  },
  "isModule": true
 }

Playground link
https://play.swc.rs/?version=1.3.66&code=H4sIAAAAAAAAA0vOzysuUUjLz1ewVdBItNdL0rTXS7YGAFJpoNwWAAAA&config=H4sIAAAAAAAAA1WPvQ6DMAyE9z4F8ty1S%2BcuHXgIKxgaRH5kG6kI8e5Nwk9hi7%2BzL3fzraqgFwPPak7PNERkIT7mRGTyit9EQKdIYthGhfuuqmRJeaQDNZNHZ83bxcC6iUVb1hVQRi9tYHf%2BhgmNnkBBLZN8zhbJ5GqF3FE%2BA5JHSVUUcKEZB%2FrXytHzlgnOBd%2FLVgBs5wPTa018KQKibI3WocmHLQ5Ch7uVevdfky23HyOpOp5KAQAA
Expected behavior
The output should not include any syntax that is invalid for es5.
Expected output:
var _a_b, _a;
var foo = (_a = a) === null || _a === void 0 ? void 0 : (_a_b = _a.b) === null || _a_b === void 0 ? void 0 : _a_b.c;

Actual behavior
The actual output still includes an optional chain operator.
Actual output:
var _this;
var foo = (_this = (a?.b)) === null || _this === void 0 ? void 0 : _this.c;

Version
1.3.66
Additional context
No response

This was fixed with https://github.com/swc-project/swc/pull/7614, released as v1.3.68. Using a more recent version on the playground will correctly transpile


Boost + static build + Visual Studio

Hello,
I am trying to use Boost with Hunter, the following way:

set(BOOST_CMAKE_ARGS BUILD_SHARED_LIBS=OFF)
hunter_config(Boost VERSION 1.60.0 CMAKE_ARGS "${BOOST_CMAKE_ARGS}")
Boost_USE_STATIC_LIBS ON
find_package(Boost CONFIG REQUIRED ...)

even if doing this the compiled libraries within .hunter are like -mt.lib and -mt-gd.lib, but not -mt-s.lib or -mt-sgd.lib (or such).
As an end result I have various MD_DynamicRelease (in Boost) vs MT_StaticRelease (in my application) conflicts.
Can anyone tell me what am I missing? Why isn't hunter building "really" the static versions for MSVC?
Thanks,

---
Want to back this issue? **[Post a bounty on it!](https://www.bountysource.com/issues/32791426-boost-static-build-visual-studio?utm_campaign=plugin&utm_content=tracker%2F1032790&utm_medium=issues&utm_source=github)** We accept bounties via [Bountysource](https://www.bountysource.com/?utm_campaign=plugin&utm_content=tracker%2F1032790&utm_medium=issues&utm_source=github).

set(BOOST_CMAKE_ARGS BUILD_SHARED_LIBS=OFF)

Has no effect, boost is always static. See feature request:

https://github.com/ruslo/hunter/issues/130

How come then that Visual Studio sees the compiled .libs as Dynamic libraries and not Static ones?

How come then that Visual Studio sees the compiled .libs as Dynamic libraries and not Static ones?

Do you see any boost*.dll?

Ok, it appears that I'm a bit lame. Of course the Hunter builds .libs and not .dlls, so they are static, however I also want to use static runtime libraries as well, so I enabled Boost_USE_STATIC_RUNTIME ON, and I also do /MD vs /MT changes in CFLAGS parameters.
It appears Boost_USE_STATIC_RUNTIME doesn't have any effect on building.
Or would hunter_config sort that out?
Thanks,

It appears Boost_USE_STATIC_RUNTIME doesn't have any effect on building

This one used in find_package, i.e. after Boost was built.

Or would hunter_config sort that out?

We need to add separate option to custom Boost build scheme. It means that since Boost doesn't use CMake as a build tool we have to do everything manually.

and I also do /MD vs /MT changes in CFLAGS parameters

As far as I know /MD conflicts with /MT so you have to build all the 3rd party packages you're using. Usually such flags should be added to toolchain.

Does it mean that currently I have no "stock" option in hunter to force static library and static runtime compilation of boost?

Does it mean that currently I have no "stock" option in hunter to force static library and static runtime compilation of boost?

No, it not implemented. For building shared library see https://github.com/ruslo/hunter/issues/130.
Feel free to open new feature request for runtime compilation. Also I think that fixing #130 is not hard, need to add shared to b2 configuration - patches welcome.


missing viewBox warning

We have an svg we are using as a border that we don't want to have a viewBox (because we don't want it to scale, but rather to fill the available space without scaling the border size).
This works fine. However, the addon emits a warning:
WARNING: [ember-svg-jar][inline] SVG files without viewBox found:
Path: bordered-rectangle.svg

There doesn't seem to be any way to suppress the warning.

Now you can suppress the warning like this:
{
  svgJar: {
    validations: {
      validateViewBox: false
    }
  }
}

https://github.com/ivanvotti/ember-svg-jar/blob/master/docs/configuration.md#validations

Terrific. Thanks Ivan!
On Tue, Mar 27, 2018 at 8:25 AM, Ivan Votti<EMAIL_ADDRESS>wrote:

Closed #57 https://github.com/ivanvotti/ember-svg-jar/issues/57.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/ivanvotti/ember-svg-jar/issues/57#event-1543084230,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAABYV-t9P_fJNxkv0zIeDI7T_mXI6SCks5tii-1gaJpZM4SgyR5
.

We're looking forward to a release with this change when you have a chance! 😄

@lukemelia Done. https://github.com/ivanvotti/ember-svg-jar/blob/master/CHANGELOG.md#v100


Is Text-Babbage-001 supported? If you do not support it, it would be helpful if you could implement it.

I tried the following code and got an error. I have a feeling that perhaps text-Babbage-001 and text-Ada-001 are not supported by the current llama index. However, I estimated that a large index would cost $20,000 for text-davinci-003, so to keep this down to a few hundred dollars, I really need to use text-Babbage-001, which is a personal problem.
If you don't mind, it would be very helpful if you could also implement a less expensive model as it may not affect the quality of the index that much.
「import os
import sys
from gpt_index import download_loader, GPTTreeIndex
from gpt_index.llm_predictor import LLMPredictor
pdf_file = sys.argv[1]
環境変数にAPIキーを設定
os.environ['OPENAI_API_KEY'] = "your_api_key_here"
model_name = "text-Babbage-001"
CJKPDFReader = download_loader("CJKPDFReader")
loader = CJKPDFReader(concat_pages=False)
Load the PDF data
documents = loader.load_data(file=pdf_file)
Create an LLMPredictor instance with text-Babbage-001
llm_predictor = LLMPredictor(model=model_name)
Create an index using GPTTreeIndex
index = GPTTreeIndex(llm_predictor=llm_predictor, openai_api_key=os.environ['OPENAI_API_KEY'])
Add documents to the index
index.add_documents(documents)
Save the index to the same directory as the PDF file
index_filename = os.path.join(
os.path.dirname(pdf_file), f"{os.path.splitext(os.path.basename(pdf_file))[0]}_index.json"
)
index.save_to_disk(index_filename)
print(f"Index saved to {index_filename}")」
「アクション“シェルスクリプトを実行”でエラーが起きました: “Traceback (most recent call last):
File "", line 19, in
TypeError: LLMPredictor.init() got an unexpected keyword argument 'model'”」

You can use text-babbage like this
(babbage might be lowercase or cuppercase, not sure)
from langchain.llms import OpenAI
llm_predictor=LLMPredictor(llm=OpenAI(temperature=0, model_name="text-Babbage-001"))

You can also consider using gpt-3.5, which is 10x cheaper than davinci
from langchain.chat_models import ChatOpenAI
llm_predictor=LLMPredictor(llm=ChatOpenAI(temperature=0, model_name="gpt-3.5-turbo))


Get Started with SAP Cloud Platform Trial

Hello,
Tutorial URL: https://developers.sap.com/tutorials/cp-trial-quick-onboarding.html
Step3 and its answer for "Enter the second item in the left hand-side navigation of a Cloud Foundry application"
Is the correct solution really working as I have tried a lot of answers without success :-)
Thank you + BR
Thomas

question already asked


Clarify effect of SCMODE and ACPERM on reserved encodings

(To avoid confusion, I'm using unrepresentable to mean permission combinations that don't have an encoding, e.g. any with ASR but no X, and reserved to mean an encoding that isn't constructible with ACPERM)
It's not defined what should happen if you try to change the M bit or permissions when the capability has a reserved permission encoding.
There's a note that I think addresses unrepresentable combinations: https://github.com/riscv/riscv-cheri/blob/f76f4a4f19297b4abc58bfaa62a087ab12542c13/src/insns/acperm_32bit.adoc?plain=1#L39-L40
(I interpret "are defined to return" to mean that you get the right result by following the legalisation rules, rather than that there's some other (implementation-defined?) definition somewhere)
GCPERM defines reserved encodings to return all zero permissions: https://github.com/riscv/riscv-cheri/blob/f76f4a4f19297b4abc58bfaa62a087ab12542c13/src/insns/gcperm_32bit.adoc?plain=1#L28-L29
It would be natural to add the same rule to the ACPERM decoding: https://github.com/riscv/riscv-cheri/blob/f76f4a4f19297b4abc58bfaa62a087ab12542c13/src/insns/acperm_32bit.adoc?plain=1#L31-L32
However, this has some surprising consequences, e.g. on RV64 if a capability's permissions field has reserved encoding 0b10000 (which would decode to ASR=1, X=R=W=C=0), trying to change the mode with SCMODE will cause the field to be re-encoded as 0b00000. Since this capability can't be tagged, this probably isn't a huge issue.
We could also just insist that SCMODE is a nop if the permission encoding is reserved. This still means that ACPERM could potentially re-encode the field, e.g. in the above case, ACPERM with all 1s would still cause legalisation to 0b00000, but I think that's less surprising.
Happy to file a PR if we agree on how to fix it, and sorry that there are so many annoying nits around this topic!

I think it would be simultaneously worth clarifying what happens if you use ACMODE to remove X permission of a capability with M=1. Some examples would probably help a lot.

@Timmmm I think you mean ACPERM - and the rule is specified:

@PRugg-Cap I think the solution is probably that SCMODE is a nop if X-permission isn't set, as the only pre-requisite for setting M is that X=1.
Does that cover it?

@tariqkurd-repo almost. I think something like "if the permissions encoding is not reserved and the X bit is clear", though we've been writing "is not reserved" as "can be produced by ACPERM", which is fine. That then resolves the SCMODE issue.
There still needs to be a clarification on ACPERM though about how the decoding happens when the field is reserved. As a concrete example, if I ACPERM the illegal RV64 encoding 0b10111 (ASR without X) with 0b11111, do I get 0b00000 (I refuse to decode the field, assume null perms, and reencode that, which is what I would assume) or 0b10111 (I continue to interpret the bits as usual, even in a reserved encoding)? Note that RV32 probably has to do the first one, because "continue to interpret the bits as usual" doesn't have an obvious meaning. In RV64, we'd be free to do the second one, but that may complicate repurposing those states later on.

hmm interesting, I would go with the first one and return 0b0000 if ACPERM encounters reserved permissions.

Agreed: I think then we just need to add that as point 1. ii. in the ACPERM rules. Something like "Reserved encodings give all null permissions".
To Tim's point, there's a slight oddity in the "common rules" that it has subpoints for each of the rules except M, telling you what to do, e.g. "1. ASR cannot be set without x being set i. Clear ASR unless X is set", but for point 3 it's just "3. M cannot be set without X being set" (though the subpoints seem kind of redundant anyway...)

ok - PR updated - please have a look!

Yep, I think that resolves all my issues. It's slightly amusing that the ACPERM rules are now self-referential, but I think it's clear. Thanks!

fixed in https://github.com/riscv/riscv-cheri/pull/271


hotfix for embedded event loops

Codecov Report

Merging #177 (7aec62c) into main (1eb941e) will increase coverage by 1.39%.
The diff coverage is 0.00%.

:exclamation: Your organization is not using the GitHub App Integration. As a result you may experience degraded service beginning May 15th. Please install the Github App Integration for your organization. Read more.
@@            Coverage Diff             @@
##             main     #177      +/-   ##
==========================================
+ Coverage   75.29%   76.69%   +1.39%
==========================================
  Files         110      110
  Lines        5513     5513
  Branches      715      715
==========================================
+ Hits         4151     4228      +77
+ Misses       1217     1130      -87
- Partials      145      155      +10

Impacted Files
Coverage Δ

tributary/streaming/graph.py
69.01% <0.00%> (ø)

... and 6 files with indirect coverage changes


feat(component): add scroll up/down gesture for ODD

Overview
This PR will add scroll up/down gesture for ODD.
The video is in the Jira ticket.
Close RCORE-322

Changelog

add a scroll up/down gesture

Review requests

Risk assessment
low

[ ] add jsdoc

Scroll issue was solved by Brent's scaffold branch, so we don't need this anymore.


Create proper OSGi bundle as artifact.

Allow to use the resulting artifact directly in an OSGi environment.

Thanks! :)


updated contributing file in reference to issue 71 in opd

When merged this will close issue https://github.com/openpolicedata/openpolicedata/issues/71


cargo build fails, throws error [E0252], when importing as dependency in new rust project

Describe the bug
Using reth as a dependency in another cargo project fails and the error "the name bytes is defined multiple times" in the file crates/primitives/src/lib.rs.
error comes from:
line 53:  "...use bytes::{self..."
&
line 103: "...bloom, bytes, ..."
included the build log error below.
tried building on m2 mac, Debian x86_64 on gcp, and ubuntu running through multipass on m2 mac. All three fail with the same error.
Steps to reproduce

cd example_build
cargo init
cargo add reth --git https://github.com/paradigmxyz/reth.git
cargo build

Node logs
Compiling reth-primitives v0.1.0-alpha.13 (https://github.com/paradigmxyz/reth#365acf08)
   Compiling tinystr v0.7.2
   Compiling ring v0.17.7
   Compiling litemap v0.7.2
   Compiling base64 v0.13.1
error[E0252]: the name `bytes` is defined multiple times
   --> /home/los/.cargo/git/checkouts/reth-36d3ea1d1152b20c/365acf0/crates/primitives/src/lib.rs:103:33
    |
53  | pub use bytes::{self, Buf, BufMut, BytesMut};
    |                 ---- previous import of the module `bytes` here
...
103 |     self, address, b256, bloom, bytes, eip191_hash_message, hex, hex_literal, keccak256, ruint,
    |                                 ^^^^^ `bytes` reimported here
    |
    = note: `bytes` must be defined only once in the type namespace of this module
help: you can use `as` to change the binding name of the import
    |
103 |     self, address, b256, bloom, bytes as other_bytes, eip191_hash_message, hex, hex_literal, keccak256, ruint,
    |                                 ~~~~~~~~~~~~~~~~~~~~

Platform(s)
Linux (x86), Mac (Apple Silicon)
What version/commit are you on?
v0.1.0-alpha.13
What database version are you on?
n/a
What type of node are you running?
None
What prune config do you use, if any?
n/a
If you've built Reth from source, provide the full command you used
No response
Code of Conduct

[X] I agree to follow the Code of Conduct

I see, @DaniPopes any suggestion for how to fix?
we could not reexport the bytes macro directly
or not reexport the bytes crate or rename the reexported mod

Remove bytes::{self} export in reth, https://github.com/alloy-rs/core/pull/462


Plugin checking wrong src directory for the standard library?

Go: go1.22.4 windows/amd64
GoLand: 2024.1.4
Templ: v0.2.747
Templ-jetbrains: 0.0.14

So I am not sure if I have done something wrong, but I am using the latest versions of templ and go and the latest of the plugin, however on load it just tells me
templ: packages.Load error: err: exit status 1: stderr: package unsafe is not in std (C:\Program Files\Go\bin\src\unsafe)
However, when I go look, my go is installed correctly in that directory but the standard library is NOT in bin, it is just in the src in the go folder, for example unsafe is located at
C:\Program Files\Go\src\unsafe
Is there something I can do to fix this? Or did I somehow install go or templ wrong? It works for everything except for this plugin so I doubt that is the case.

So it appears some other program decided it would be smart to change my main external GOROOT to the bin folder instead of the main folder. I just didn't notice because GoLand overrides that value, and when I type go env in the terminal it points to the right location. templ was just using the main one somehow instead of the GoLand one.


Add missing message to en.json

Summary
Add missing message to en.json
Ticket Link
N/A
Related Pull Requests
N/A

This issue has been automatically labelled "stale" because it hasn't had recent activity.
A core team member will check in on the status of the PR to help with questions.
Thank you for your contribution!
/cc @jasonblais @hanzei

/update-branch

Will try to auto merge this PR

Pull Request successfully merged
SHA: aa85043c71ec7c38cab2d6a973640d179b28c044


HHH-9529 - [enhancer] check that the field being accessed belongs to the entity being enhanced

Applied upstream.  Thanks for all the great work Luis!


Upgrade to Webpack 3

And remove/replace webpack-blocks in the process?
We currently have to since it only supports 1.x and 2.x

We should, that reduces the bundle size as well (I remember from the previous PR)
Since now that templates are in, we can totally ignore the last PR and create a whole new PR or totally start fresh.
@lukeed would you like to take it? Since you have already sth similar to that


Set default PSR7 Request method

The PSR7 request method is now "mandatory":
https://github.com/guzzle/psr7/commit/c5aea30ff82a3565e6d3decd18d74257c033daf6#diff-a788147295d6b475ecb28d093c1ba121R39

Thank you very much for this fix (and the additional ; )! I only found out yesterday when I was working on the tests that Guzzle had made it forbidden, but I forgot to fix this issue: https://github.com/woohoolabs/yang/issues/16


Create-FhirServerSamplesEnvironment.ps1 gives resouorce not found

I'm using the following command:
rverSamplesEnvironment.ps1 -EnvironmentName FHIRServerOS -EnvironmentLocation westus2 -UsePaaS $false -PersistenceProvider sql -SqlAdminPassword $(ConvertTo-SecureString -AsPlainText -Force "abcnnn")
At first, it provides the following warning after creating key vault:
WARNING: The provided information does not map to an AD object id.
WARNING: Access policy is not set. No user or application have access permission to use this vault. This can happen if
the vault was created by a service principal. Please use Set-AzKeyVaultAccessPolicy to set access policies.
Then come several errors with the first one "The Resource 'Microsoft.Web/sites/fhirserverossrvr' under resource group 'FHIRServerOS' was not found.
It seems something failed to create.
Any info would be helpful

Please see this one:

I still get the same error with lowercase name.... After looking at the error carefully, I may not be able to eastus2 for Azure SQL...
New-AzureRmResourceGroupDeployment : 12:04:46 AM - Resource Microsoft.ManagedIdentity/Identities 'default' failed with message '{
"error": {
"code": "ResourceNotFound",
"message": "The Resource 'Microsoft.Web/sites/fhirserverossrvr' under resource group 'fhirserveros' was not found."
}
}'
At C:\Data\Application Development\Samples\Complete FHIR Sample\fhir-server-samples\deploy\scripts\Create-FhirServerSamplesEnvironment.ps1:164 char:1

New-AzureRmResourceGroupDeployment -TemplateUri $sandboxTemplate -env ...

  + CategoryInfo          : NotSpecified: (:) [New-AzResourceGroupDeployment], Exception
  + FullyQualifiedErrorId : Microsoft.Azure.Commands.ResourceManager.Cmdlets.Implementation.NewAzureResourceGroupDeploymentCmdlet

New-AzureRmResourceGroupDeployment : 12:04:53 AM - Resource Microsoft.Sql/servers 'fhirserverossrvr' failed with message '{
"status": "Failed",
"error": {
"code": "ResourceDeploymentFailure",
"message": "The resource operation completed with terminal provisioning state 'Failed'.",
"details": [
{
"code": "ProvisioningDisabled",
"message": "Provisioning is restricted in this region. Please choose a different region. For exceptions to this rule please open a support request with Issue type of 'Service and subscription limits'."
}
]
}

That is a different error. I think this may be related to the issue with managed identity, which is mentioned here:
https://github.com/microsoft/fhir-server/issues/671
Could you try to just run the deployment a second time.

Still the same error.

I just tries in eastus and I am able to deploy and it is up and running.

Did you use similar command as the one below from your desktop PowerShell or in Azure Cloud shell? Am I missing any other parameters?
Create-FhirServerSamplesEnvironment.ps1 -EnvironmentName FHIRServerOS -EnvironmentLocation westus2 -UsePaaS $false -PersistenceProvider sql -SqlAdminPassword $(ConvertTo-SecureString -AsPlainText -Force "abcnnn")

Correction...
Create-FhirServerSamplesEnvironment.ps1 -EnvironmentName fhirserveros -EnvironmentLocation eastus -UsePaaS $false -PersistenceProvider sql -SqlAdminPassword $(ConvertTo-SecureString -AsPlainText -Force "abcnnn")

It seems the script won't work for me. I'll try manual. The only thing I can think of is that AzureRM is running on a compatibility mode since I have already upgraded to Az module

This was the last error I got... HTTP Error 502.5 - ANCM Out-Of-Process Startup Failure

It seems it finally worked after I ran the script twice. Not sure how. Is it supposed to create 2 Key Vault resources?

Yes, one KeyVault resource is for the OSS FHIR server deployment, the other one is for the demo environment details.
The problem with having to run the template twice should be temporary, there is a bug that is being resolved related to managed identity.

Thanks. this can be closed. I'll create a different thread if I encounter different issues or have questions. I'm now assessing the resources to test a few scenarios.

@AhsanSAlam just FYI, the fix for the managed identity issue has just been merged in https://github.com/microsoft/fhir-server/commit/5fa767414c9ecbe170e918f5d94a93006cff1374 and I just tested that the fhir-server-samples scenario deploys without errors in eastus with the parameters you have before (I changed the environment name, but otherwise the same).

Thank you for your help. I'll try it out.... This is very helpful since I'll be presenting at a meetup in couple weeks about Jumpstart with FHIR on Azure.


Formalization of approximate interface with an exact backing

This idea seems to crop up in a few places.  Essentially, exact structures can be taken as a special case of our sketch structures that take up less space.
In theory, Monoids could take advantage of this, and maybe we could simplify some logic by having implicit conversions?  And perhaps we could simplify some EventuallyMonoids.
Some examples would be:

String or Set[String] as exact BloomFilter
K or Set[K] as exact HLL
K, (K, Long), or TraversableOnce[(K, Long)] as exact CMS
(K, V) or TraversableOnce[(K, V)] as exact SketchMap

I'd say CMS[K] ~ Map[K, Long] and SketchMap[K, V] ~ Map[K, V]. But how would we use this?
These approximations are generally for datastructures and methods/functions. How do we codify that?

Yeah it's not completely clear to me, either.
But it occurs to me that all of these Monoids have/need a 'create' method that does the conversion involved here (more or less).  Perhaps we could have types like:
trait Exact[A, E] extends A {
  def exactData: E
}
trait ApproximationMonoid[A, E] extends Monoid[A] {
  def approximate(exactData: E): A
}
trait ExactMonoid[A, E] extends Monoid[Exact[A, E]]

Though this is already problematic due to 'extends A', because these things aren't really traits (SketchMap is a case class, even).

A minor tweak to your suggestion:
// A approximates E
  // ideally there would be some metric here, like maybe:
  // if we have |approx(f(e1, e2)) - f'(approx(e1), approx(e2))| < eps
  // for some approximating transformation f -> f' and some Metric[A].
trait Approximates[A, E, M[_]] {
  def approximate(e: E): A
  // get the approximate typeclass from the exact one.
  def transform(m: M[E]): M[A]
  def metric: Metric[A]
  def error: Double
}

sealed trait MaybeApprox[+A, +E] extends Any
case class Exact[E](exact: E) extends MaybeApprox[Nothing, A] with AnyVal
case class Approx[A](approx: A) extends MaybeApprox[A, Nothing] with AnyVal

// This is basically a renamed version of the EventuallyMonoid to be more what we are using it for
// with the addition of a new Typeclass: Approximates[A, E]
case class ApproximateMonoid[A, E](implicit exact: Monoid[E], approx: Approx[A, E]) extends Monoid[MaybeApprox[A, E]] ...
  // we can get Monoid[A] from approx and exact.

I think the signature of the Monoid would be a bit longer.  Something like:
class EventuallyApproxMonoid[A, E](
  makeApprox: E => A,
  p: E => Boolean
)(
  implicit
  exact: Monoid[E],
  approx: Monoid[A]
) extends Monoid[MaybeApprox[A, E]]

Something like this could be a great way to clean up our test code. I'm thinking about making something like
trait ApproximateProperty {
  type Params
  type Exact
  type Approximate
  type ExactResult
  type ApproximateResult

  def makeApproximate(p: Params, e: Exact): Approximate
  def exactResult(e: Exact): ExactResult
  def approximateResult(a: Approximate): ApproximateResult
  def claim(e: ExactResult, a: ApproximateResult): Boolean
  def probability(p: Params): Double
}

Example implementation:
CmsProperty extends ApproximateProperty {
  type Params = CMSParams
  type Exact = List[T]
  type Approximate = CountMinSketch[T]
  type ExactResult = Int
  type ApproximateResult = Int

  def makeApproximate(p: CMSParams, exact: List[T]) = {
    val cmsMonoid = CountMinSketchMonoid(params)
    cmsMonoid.sum(exact.map(cmsMonoid.create(_)))
  }
  def exactResult(list: List[T]) = list.getFrequency(x)
  def approximateResult(cms: CountMinSketch[T]) = cms.frequency(x)
  def claim(e: Int, a: Int) = e == a
  def probability(p: Params) = ???
}

This example doesn't check out because I don't know where to get the x in exactResult and approximateResult. Maybe there should be another def getArbitraryTestInput which returns a suitable x which we can feed into exactResult and approximateResult?
Does this seem like a good idea? My goal is to make something similar to scalacheck's Properties but for approximate properties. This could be useful in bounding the probabilities of test failures and such for each test.

Do we all mind if I close this and merge the discussion into #44 ?


MM-12420: Avoid slash duplications on gitlab urls configuration

Summary
Avoid slash duplications on gitlab urls configuration
Ticket Link
MM-12420
Checklist

[x] Ran make check-style to check for style errors (required for all pull requests)
[x] Ran make test to ensure unit and component tests passed

To break this specific case you have to change how the generated string done. It is done in a very concrete place and specifically for GitLab in this case.

cherry-picked to 5.4


UIWebView get covered with keyboard on iphone6/ios12.1

For some reason UIWebview gets messed up specifically on ios 12.1 after update. I have webview with textinput in bottom, and it's getting covered with keyboard. If i use WKWebView textinput is put too much away from keyboard and can be fixed with this code, but it's a bad solution in general
[UIView animateWithDuration:0 animations:^{
self.webView.scrollView.contentOffset = CGPointMake(0, 0);
}];

We're tracking this problem in #193 now -- closing in favor of that.
https://github.com/react-native-community/react-native-webview/issues/193#issuecomment-447513485


⚠ Bofrost.fr has degraded performance

In d0f52c5, Bofrost.fr (https://www.bofrost.fr) experienced degraded performance:

HTTP code: 200
Response time: 1881 ms

Resolved: Bofrost.fr performance has improved in 2df9aac after 8 minutes.


Issue with Charm

For some reason when charm is installed it removes the ability to craft the weapons from this mod and I have no idea why.

looks like charm injects into the recipe manager to early https://github.com/svenhjol/Charm/blob/master/src/main/java/svenhjol/charm/mixin/core/SortRecipesMixin.java (cause as far as I know the mixins get applied in the order of the mod list which goes from a to z) and recipes from this mod won't get added to the charm recipe list.
Should be an easy fix to set the charms recipemanager mixins priority lower

I too am facing this issue, however I have close to 0 experience in Java. Is there an easier way to fix this issue? Really love both mods, and don't want to remove either from the server.  I checked other weapon mods to see if it their recipes also got gobbled up and turns out they didn't.

PS. ignore that "close to 0" can't even start to edit a mod, for I don't know how. pls help me i'm stoopid

Looks like the charm dev changed the redirect mixin to a normal inject which should make it compatible now, don't know if he released something yet https://github.com/svenhjol/Charm/blob/master/src/main/java/svenhjol/charm/mixin/helper/AddSortingRecipeManagerMixin.java

Should be fixed with a later version of charm, reopen if still persistent.


Propagate environment #1358

Adds propagate-environment: true to all pipeline templates and removes the environment definition from docker compose files
Closes #1358

@ajain58 Great question, we have an informal & impure 🙃 practice of filing template updates as patches. This is dishonest to semver but the rationale is that existing projects are the ones that upgrade to new versions & review release notes, and once you've run skuba init then updates to the built-in templates don't really impact you beyond an FYI about about a best current practice.

That reminds me that we should update https://github.com/seek-oss/skuba/blob/master/CONTRIBUTING.md#creating-a-changeset

I did a quick test and pipeline variables which are defined within steps and/or on the pipeline at upload time also get passed to the container via the propagate-environment option.


QA: Soak testing

Problem description
At present Guardian instances are only used consistently for a relatively short time period. There is no knowledge of whether the system will degrade performance in any way after multiple days/weeks of consistent load.
Requirements

Develop an automated test infrastructure, to be run for at least 1 month for each release, with constant and varied test load.
Ensure system operational metrics are collected during the test.
Monitor and analyse the above to make sure the system can be operated to enterprise-grade SLAs in a BAU state.

Definition of done
Soak tests are triggered and automatically run for each release.
As a result the team has a reasonable idea of the BAU operations of Guardian.
Acceptance criteria

Soak tests cover iREC and VERRA demo scenarios, with consistent load
Test results from input for development work.

Prerequisites:

Running guardian on azure instance target instance
Access to source azure instance from which tests will be executed
-iREC and VERRA load test scripts developed using JMeter
-Access to Monitoring tools

NFA Requirements: Reliability test
Duration:

1 day
1 week
1 month
Number of concurrent users for consistent load?
Which user flows to be tested during reliability test?


Support/wagtail upgrades

Hi @nickmoreton , This PR contains all of the Wagtail upgrades without any linting.


readme: fix nix-shell installation instructions

Hello there.
First off, thanks for the project! I just discovered it and I'm in the phase of getting familiar.
I ran into an issue, though, when following the GTK install instructions (from the README) for the nix-shell.
TLDR
running the following the GTK et al. installation completed successfully:
nix-shell -p '<nixpkgs>' gtk4 pkgs.gtk3 gobjectIntrospection pkgconfig

Not quite in-depth but more elaborate description
As mentioned above, the GTK install instructions from README for the nix-shell didn't work for me.
They appear to be out of date, so I went ahead and fixed them.
In fact I just followed what nix-shell told me to do and that did end up working.
the change/fix as hinted by the nix-shell
-nix-shell -p '<nixpkgs>' gtk4 gnome3.gtk gobjectIntrospection pkgconfig
+nix-shell -p '<nixpkgs>' gtk4 pkgs.gtk3 gobjectIntrospection pkgconfig

Output from the original command, which failed:
~
 ➜  nix-shell -p '<nixpkgs>' gtk4 gnome3.gtk gobjectIntrospection pkgconfig
error: The ‘gnome.gtk’ alias was removed on 2022-01-13. Please use ‘pkgs.gtk3’ directly.
(use '--show-trace' to show detailed location information)

~
 (╯°□°）╯︵ ┻━┻ 1 🔥

pic (it did happen):

Output from the fixed command:
~
 (╯°□°）╯︵ ┻━┻ 1 🔥 nix-shell -p '<nixpkgs>' gtk4 pkgs.gtk3 gobjectIntrospection pkgconfig these 334 paths will be fetched (275.79 MiB download, 1187.41 MiB unpacked):
  /nix/store/043lz8mvyx5vxl058c1i586yqc8ax4ig-glibc-2.33-108-bin
  /nix/store/04yj0nllw5bqzzlay5m6zzbmyw7csgnk-glu-9.0.2
  /nix/store/06zvvrv13xrmjqkcwyh5x9yxvgx4hvqz-libseccomp-2.5.3-lib

...
... hundreds of lines later
...

copying path '/nix/store/h8k91x18zynw58yc0k34wv5i2k0jfijx-gtk4-4.6.0' from 'https://cache.nixos.org'...
copying path '/nix/store/apgij5a7rsa8d0j5zxdl2ji3vr8kji5g-gtk4-4.6.0-dev' from 'https://cache.nixos.org'...

~ via ❄  impure (shell)
 ➜  gtk4-<TAB><TAB>
gtk4-broadwayd            gtk4-demo-application     gtk4-launch               gtk4-update-icon-cache
gtk4-builder-tool         gtk4-encode-symbolic-svg  gtk4-print-editor         gtk4-widget-factory
gtk4-demo                 gtk4-icon-browser         gtk4-query-settings

~ via ❄  impure (shell)
 ➜  which gtk4-demo
/nix/store/apgij5a7rsa8d0j5zxdl2ji3vr8kji5g-gtk4-4.6.0-dev/bin/gtk4-demo

pic (this also did happen):

Hope this is OK.
Cheers!

Just ... gtk4 gtk3 ... should work, then. Can you make that change?
This is also quite a recent change (and I really don't like Nixpkgs randomly making breaking changes like these), so can you also clarify that?

Just ... gtk4 gtk3 ... should work, then. Can you make that change?
This is also quite a recent change (and I really don't like Nixpkgs randomly making breaking changes like these), so can you also clarify that?

sure, will do. and yeah, no, changes like this are not pleasant.

Just ... gtk4 gtk3 ... should work, then.

btw this has been the first time I have ever used nix-shell so thanks for explaining/pointing out redundant usage of "pkgs" word.

alright, so another package has broken (from the original instructions). [1][2]
I came to realize that matter-of-factly these are not just README instructions, it is equally defined in shell.nix and thus exactly the same story repeats when running nix-shell shell.nix [3][4].
 Please use ‘pkgs.gtk3’ directly.
(use '--show-trace' to show detailed location information)

…/gotk4-examples  master 🐹
(╯°□°）╯︵ ┻━┻ 1 🔥

[4]

so I wen ahead and performed what I thought was a "fix" for this as well.[5][6]
[5]
…/gotk4-examples  master 🐹
(╯°□°）╯︵ ┻━┻ 1 🔥  vim shell.nix

…/gotk4-examples  master +2 -2 ∆ 🐹 took 25s
➜  git diff shell.nix
Alias tip: gd shell.nix
diff --git a/shell.nix b/shell.nix
index 029ab99..f35f253 100644
--- a/shell.nix
+++ b/shell.nix
@@ -38,14 +38,14 @@ in gtkPkgs.mkShell {
                glib
                graphene
                gdk-pixbuf
-               gnome3.gtk
+               gtk3
                gtk4
                vulkan-headers
        ];

        nativeBuildInputs = with gtkPkgs; [
                # Build/generation dependencies.
-               gobjectIntrospection
+               gobject-introspection
                pkgconfig

                unstable.go

[6]

...and ran nix-shell shell.nix, which yielded the following and ended up with an error when building golang (part of the bootstrapping process).[7]
[7]
ugly log with a build error
```sh
…/gotk4-examples  master +2 -2 ∆ 🐹
➜  nix-shell shell.nix
copying path '/nix/store/hj2scqiwijyhwpcx01p3kh56cgsnqrkr-mirrors-list' from 'https://cache.nixos.org'...
copying path '/nix/store/sa6yrmwgn8k3b8digx7x4xfi05n65ms0-c-ares-1.18.1' from 'https://cache.nixos.org'...
copying path '/nix/store/0lppibz9ibanz2d3hz16j3bw1dq003pn-curl-7.81.0-man' from 'https://cache.nixos.org'...
copying path '/nix/store/f9v1pwhlz6ym4a1pqqpf169gzmhmhxbk-libev-4.33' from 'https://cache.nixos.org'...
copying path '/nix/store/d3iynqrw4mipb8n2fdkpc1p7diw79gbk-libkrb5-1.19.2' from 'https://cache.nixos.org'...
copying path '/nix/store/x38lg76ka1fpfdcj7fzqgpwhhbnsil37-nghttp2-1.43.0' from 'https://cache.nixos.org'...
copying path '/nix/store/chg62wzwa7ay7s93c0bjlv6w40d4h3dl-libkrb5-1.19.2-dev' from 'https://cache.nixos.org'...
copying path '/nix/store/ji1kgjq0m4zs2r6nrw01xxvlg4wz92jf-nghttp2-1.43.0-lib' from 'https://cache.nixos.org'...
copying path '/nix/store/ha4mvc8ljn1xfq4cqddw8qvr2r8xv0r5-openssl-1.1.1n' from 'https://cache.nixos.org'...
copying path '/nix/store/dd191smbav4qs2893r8rdyj146m8fi9n-perl-5.34.0' from 'https://cache.nixos.org'...
copying path '/nix/store/xp4ji3a1iqplchbhl18c6f56pq0fzy8l-libssh2-1.10.0' from 'https://cache.nixos.org'...
copying path '/nix/store/kif3ipq6xj2vyzvv49ymz28n735xdmzv-nghttp2-1.43.0-bin' from 'https://cache.nixos.org'...
copying path '/nix/store/ji8j47zvsaqgqyfk6yqkafvinp0zm6ha-curl-7.81.0' from 'https://cache.nixos.org'...
copying path '/nix/store/hvbhh8xl2d1hkb3rnx239d5arzlyrr4d-libssh2-1.10.0-dev' from 'https://cache.nixos.org'...
copying path '/nix/store/i8487ik9104lgdcai15dla4fxka2c01r-curl-7.81.0-bin' from 'https://cache.nixos.org'...
copying path '/nix/store/asyvzhrz4g55bijfcmfibkj1zl8rmycj-nghttp2-1.43.0-dev' from 'https://cache.nixos.org'...
copying path '/nix/store/zcr5ac8p4im98vald06drafxi6lvxazb-openssl-1.1.1n-bin' from 'https://cache.nixos.org'...
copying path '/nix/store/wi2rg946y960h35rk65p97i2ddda7b8k-stdenv-linux' from 'https://cache.nixos.org'...
copying path '/nix/store/9j2yplh003qgmdfcncaymszbzffp52bf-openssl-1.1.1n-dev' from 'https://cache.nixos.org'...
copying path '/nix/store/lamw53y46xh8h4gdffq5hxdwmyh0p821-unzip-6.0' from 'https://cache.nixos.org'...
copying path '/nix/store/sqabc90kngx62m6hrvxwla2xyn0irr1f-curl-7.81.0-dev' from 'https://cache.nixos.org'...
building '/nix/store/ry1kxa598lanna9nkqrxv6f4c261sgvm-source.drv'...
trying https://github.com/NixOS/nixpkgs/archive/3fdd780.tar.gz
% Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
Dload  Upload   Total   Spent    Left  Speed
100   155  100   155    0     0    369      0 --:--:-- --:--:-- --:--:--   369
100 25.3M    0 25.3M    0     0  5576k      0 --:--:--  0:00:04 --:--:-- 7098k
unpacking source archive /build/3fdd780.tar.gz
this derivation will be built:
/nix/store/y9mlbvjhywh0pif7965yb1br3mabmbwk-go-1.17.drv
these 100 paths will be fetched (178.59 MiB download, 827.73 MiB unpacked):
/nix/store/0160hhpdql1b6g6b696wkwh9kp2pzgi3-perl-5.34.0
/nix/store/03bnnzclgaby0yga8931bl5mwlav8v4v-lvm2-2.03.12-lib
/nix/store/04hz8rs4h6pni1l0zg12m6rwh4pz2h8r-gnupg-2.2.27
/nix/store/0vczr00yv7d43f9jpa6vlrciscpvnql1-attr-2.5.1
/nix/store/0zhm2wfi65077amz3rld3rsk2b41h7ip-zstd-1.5.0-bin
/nix/store/1c9cxr2qac1r1yis98rwxh7cdjd295il-tzdata-2021a
/nix/store/1flh34xxg9q3fpc88xyp2qynxpkfg8py-bash-4.4-p23
/nix/store/2qmkkrkk2d1jvin6iy8yvfh7iaawyqwm-gcc-wrapper-10.3.0
/nix/store/2xri2nhw2nxjlh4m0pfx53qxd057saj8-glibc-2.33-49-bin
/nix/store/43zy3j9a11icz158b336ahzf3bg7ykm1-zlib-1.2.11
/nix/store/4cnyjnpswvlvld2icvfhdp35xn1w61af-gnused-4.8
/nix/store/4vpcvif5vsdy26ipvnrssz2q9hsx09sj-cryptsetup-2.3.6
/nix/store/5kry9k64l4siw7f3qp4a5zyrdgjf85mi-gnumake-4.3
/nix/store/5p42ddhrpm6y8x0lcj5v546r560xav4g-libgpg-error-1.42
/nix/store/5qdpzap2z0l5rlz5znw4iyi6jk7rab5z-go-bootstrap
/nix/store/5wxfws16q9qf5zc34hdsshydwvmr3dc1-linux-pam-1.5.1
/nix/store/67mys81mgnmf5ghgnhgixpnp5xqv7m6l-libffi-3.4.2
/nix/store/6axjb5wjhz8cac510q6am28araw53ic7-systemd-minimal-247.6
/nix/store/73k2knwhv4zzizsjr1g1dqjvzkamx8bd-glibc-2.33-49
/nix/store/7a9g2jwkvzcsgr25dqvmziyj8fla3na2-pcre2-10.36
/nix/store/7af3psmdq8vpcvrn2ph1wjxwcqn19njk-pkg-config-wrapper-0.29.2
/nix/store/7b2jnb9j34r17yg4ifq1a435jla1z355-pcre-8.44-dev
/nix/store/7s3zipf5df68x3dwsg1x6c3gmqjca79k-which-2.21
/nix/store/7xp1yxk8d67ik4rfcbxxjrfv6fnch0p5-iana-etc-20210225
/nix/store/83m5017qivc9w2bir9kq3a8ng90apwln-libmicrohttpd-0.9.71
/nix/store/8dc4241ar7mfbygja6bivkjb8cmamp1g-dns-root-data-2019-01-11
/nix/store/8l2w5s51l0f3fls7hb95084hh8mqq5r7-nghttp2-1.43.0-lib
/nix/store/8qx9zz373vqq7wx7xszlnp0d5ww25cnr-libevent-2.1.12
/nix/store/8rvw5zr49pi7939whxrxxx3fkiwvkhpc-libcap-2.49-lib
/nix/store/959xr9vncijpkqnr34llswdj2dcsix6w-zstd-1.5.0
/nix/store/96xqj1bzp5mmq0rcfy0k58j8hgha6m87-lz4-1.9.3
/nix/store/9jsp95c5r4pl1pdqzy9z405wj39czpwa-stdenv-linux
/nix/store/apzq0zhwqhgqvwlnczpdgfz0wy4cnm5n-shadow-4.8.1
/nix/store/ax9fd42fnyb0snkasr1yn1dn92ayfm3v-bzip2-<IP_ADDRESS>.2
/nix/store/d46asbmn0aq41xia32r3k575w63ckfbq-db-4.8.30
/nix/store/df1n2a5cj24l0zfbhlcqx694bzlar94q-gzip-1.10
/nix/store/dp2xc2mvfy4gwbkz8g1qq71q12c3nhwy-linux-headers-5.12
/nix/store/fmyn0jdp41d2wg4pnapjlqwxxvsp3k2x-ed-1.17
/nix/store/fzhgkh90jm1lgvm63rhbmvnbs3dl2657-curl-7.76.1
/nix/store/g3yj32g7ysaz18qsfcr2ss51dwf1v6lp-xz-5.2.5-bin
/nix/store/g7s5zm08sii75w3w3jzxdrjaqc1isczj-libnftnl-1.2.0
/nix/store/ga6avwlcsw00lfwwgpfrjw6s8rsshl7h-libkrb5-1.18
/nix/store/gcwds7i87a6cpc5lx8bwn6xzbzfw2kp4-patchelf-0.13
/nix/store/h8ydv6bv2fk3rml4y4fv5rwvf67y9vgk-pkg-config-0.29.2
/nix/store/haf7rmqmbm8jpiqpm3fi1wax08j8i2d1-kmod-27
/nix/store/hp64yih1cc97gkhrcwmssv5lzj33vay2-libcap-ng-0.8.2
/nix/store/hq164navrcpj1w31r544n6qjdq4by92h-findutils-4.8.0
/nix/store/ifvrxbzgk94k420g8grcv38gpcppfhsh-nettle-3.7.3
/nix/store/j7s08fw8cx71kvxzyhkz7sqqm804s6bl-gcc-10.3.0
/nix/store/jwisgz90h92ki21p2lpzrnin8wj7nd3z-acl-2.3.1
/nix/store/kmqs0wll31ylwbqkpmlgbjrn6ny3myik-binutils-2.35.1
/nix/store/kpx9c45rbvkc1ijaxq89lq02v56i9v5a-nss-cacert-3.66
/nix/store/ld6727nv8jj0cj7l4jwzhxgdlcw9h7yb-procps-3.3.16
/nix/store/lglxa6zjxag1dy0d0lygb34jwv1s65g6-coreutils-8.32
/nix/store/ln4fj9h2xybi4yg9nzzfl3kddg1ykqml-systemd-247.6
/nix/store/maz16dk6bgdn0zsxr2vv4ciy5p5bkrlx-gnutar-1.34
/nix/store/mp1q3wb5jdx85jklmhywqswqkk9wrkg1-bash-interactive-4.4-p23
/nix/store/n7mhdax4xnsycd006nsx9lbajibm868k-libnetfilter_conntrack-1.0.8
/nix/store/nfg3xlik5pvn3av3hxg13zvmizniw5rh-vulkan-headers-<IP_ADDRESS>
/nix/store/ngxbinl207hg37x6pvrp31cj1nj5in3j-libapparmor-3.0.3
/nix/store/nlwr2haphv30zkcr66lyhnchilywxw4v-gawk-5.1.0
/nix/store/nmafclgs3ihgrry285prpk166fxay8pz-libpcap-1.10.1
/nix/store/p1vw61dq54ziibsb357739gggg4998jy-pcre-8.44
/nix/store/p21zz3jvnsk6h7pb83lm9hyl2hb7d2g8-gnugrep-3.6
/nix/store/p2zlvnhkfxr44g2sy6la03dq9lvch7ql-libseccomp-2.5.1-lib
/nix/store/pdna1n0llhb9ykwrqn66aw4jna2jhij8-audit-2.8.5
/nix/store/pjb0sy7rvzx1mrmk5b6kdaz39dq8h4zs-readline-7.0p5
/nix/store/plgn1wacp4nfvn4a5c3znd81a2lhxd27-libassuan-2.5.5
/nix/store/q68q448r514ak3vhf2m44ax6vhmxamjx-glibc-2.33-49-dev
/nix/store/q8pf4wwwll4l3fw45kxpk3wh5df8j0hz-kbd-2.4.0
/nix/store/q9z0ihw7a7jkhjp8jql1az28add1m4d6-libtasn1-4.17.0
/nix/store/qc0pnpfq9nv5y5icqhyg3qh34n9qmj4k-brotli-1.0.9-lib
/nix/store/qc54papkkxvbhrc7vsasav7kn889j560-popt-1.18
/nix/store/qplkhcpxqi30gnv84fqbf3x6h9qy8qgq-bzip2-<IP_ADDRESS>.2-bin
/nix/store/qs9ai71mpr7dsm1ili447x1nql3ga18q-patch-2.7.6
/nix/store/r185pknh7w746yhbq3f9iqbswpc8zf9p-libmnl-1.0.4
/nix/store/r3hbvnvp5hmlyjq6njp7hsc6syv7vj42-util-linux-2.36.2-bin
/nix/store/r72xzdagvpv0n5cwppnd5lhwy3gch0bs-p11-kit-0.24.0
/nix/store/rj21p3ba9xl9hgxfg1mpyrzgprshyra5-libgcrypt-1.9.3
/nix/store/rr10mjrr3zmwwq9mm0mr4zj7f6xd9b4r-libssh2-1.9.0
/nix/store/sdzj2vpvckwqp3j2n51gn7bzl20vnw77-unbound-1.13.2-lib
/nix/store/shg038k6xcn4hc34wk7z1iw7zk5k82m2-pcre-8.44-bin
/nix/store/sjbhvcixa61s0a3sarcx2h0wj2995785-ncurses-6.2
/nix/store/sqk0m9r2b8lg02d4v6n9p17si495dqf7-keyutils-1.6.3-lib
/nix/store/ssb3ji98gm99qg0pzvxkdg8z7s8bv4cj-json-c-0.15
/nix/store/vc0rpn5ya4y0208nc71ssbmlalc7vr7p-libidn2-2.3.2
/nix/store/vd8b8a6037r3s8y8dpfhrwjyl4aprj0v-gmp-6.2.1
/nix/store/vyqnqbp3yczrzjx2byk6p680q3mzanyw-gcc-10.3.0-lib
/nix/store/wc269vfvf8nls0kadpm07m06cgjn0iaz-glibc-2.33-49-static
/nix/store/wqggb5ilpgc1aw4fghy1qs1fjnl8d7sh-openssl-1.1.1l
/nix/store/xbv02l47l34dgc02w11v38n38mn704zm-iptables-1.8.7
/nix/store/y56fwb7pp4h2m017w80jmmcd4wsm2iff-diffutils-3.7
/nix/store/y6lg60virzfmp0q8z3nq6pa47j8sm2ci-gnutls-3.7.2
/nix/store/yyj367gn2fjzx8zqd3qf5ypfpq0xcgrx-util-linux-2.36.2
/nix/store/yz0cr6a6wcc6d1rci9fz32panl4bbpnj-libunistring-0.9.10
/nix/store/zbmzmwbdlrv38iwicm2d3ynn4rnvf4ds-libnfnetlink-1.0.1
/nix/store/zi15ncfp3b06yjh93yd88m99y3fds3jy-kexec-tools-2.0.20
/nix/store/zpfa1fc00k5r7zfknkigapxxn4kgiirc-binutils-wrapper-2.35.1
/nix/store/zr799zi12gns0j378ljr9cbv7mscnjfs-xz-5.2.5
/nix/store/zva08p0hb6dc4invg3dsa1z62r6xrbpv-expand-response-params
copying path '/nix/store/nfg3xlik5pvn3av3hxg13zvmizniw5rh-vulkan-headers-<IP_ADDRESS>' from 'https://cache.nixos.org'...
copying path '/nix/store/8dc4241ar7mfbygja6bivkjb8cmamp1g-dns-root-data-2019-01-11' from 'https://cache.nixos.org'...
copying path '/nix/store/7xp1yxk8d67ik4rfcbxxjrfv6fnch0p5-iana-etc-20210225' from 'https://cache.nixos.org'...
copying path '/nix/store/yz0cr6a6wcc6d1rci9fz32panl4bbpnj-libunistring-0.9.10' from 'https://cache.nixos.org'...
copying path '/nix/store/dp2xc2mvfy4gwbkz8g1qq71q12c3nhwy-linux-headers-5.12' from 'https://cache.nixos.org'...
copying path '/nix/store/vc0rpn5ya4y0208nc71ssbmlalc7vr7p-libidn2-2.3.2' from 'https://cache.nixos.org'...
copying path '/nix/store/kpx9c45rbvkc1ijaxq89lq02v56i9v5a-nss-cacert-3.66' from 'https://cache.nixos.org'...
copying path '/nix/store/73k2knwhv4zzizsjr1g1dqjvzkamx8bd-glibc-2.33-49' from 'https://cache.nixos.org'...
copying path '/nix/store/1c9cxr2qac1r1yis98rwxh7cdjd295il-tzdata-2021a' from 'https://cache.nixos.org'...
copying path '/nix/store/0vczr00yv7d43f9jpa6vlrciscpvnql1-attr-2.5.1' from 'https://cache.nixos.org'...
copying path '/nix/store/1flh34xxg9q3fpc88xyp2qynxpkfg8py-bash-4.4-p23' from 'https://cache.nixos.org'...
copying path '/nix/store/jwisgz90h92ki21p2lpzrnin8wj7nd3z-acl-2.3.1' from 'https://cache.nixos.org'...
copying path '/nix/store/pdna1n0llhb9ykwrqn66aw4jna2jhij8-audit-2.8.5' from 'https://cache.nixos.org'...
copying path '/nix/store/qc0pnpfq9nv5y5icqhyg3qh34n9qmj4k-brotli-1.0.9-lib' from 'https://cache.nixos.org'...
copying path '/nix/store/ax9fd42fnyb0snkasr1yn1dn92ayfm3v-bzip2-<IP_ADDRESS>.2' from 'https://cache.nixos.org'...
copying path '/nix/store/lglxa6zjxag1dy0d0lygb34jwv1s65g6-coreutils-8.32' from 'https://cache.nixos.org'...
copying path '/nix/store/qplkhcpxqi30gnv84fqbf3x6h9qy8qgq-bzip2-<IP_ADDRESS>.2-bin' from 'https://cache.nixos.org'...
copying path '/nix/store/y56fwb7pp4h2m017w80jmmcd4wsm2iff-diffutils-3.7' from 'https://cache.nixos.org'...
copying path '/nix/store/fmyn0jdp41d2wg4pnapjlqwxxvsp3k2x-ed-1.17' from 'https://cache.nixos.org'...
copying path '/nix/store/zva08p0hb6dc4invg3dsa1z62r6xrbpv-expand-response-params' from 'https://cache.nixos.org'...
copying path '/nix/store/hq164navrcpj1w31r544n6qjdq4by92h-findutils-4.8.0' from 'https://cache.nixos.org'...
copying path '/nix/store/nlwr2haphv30zkcr66lyhnchilywxw4v-gawk-5.1.0' from 'https://cache.nixos.org'...
copying path '/nix/store/vyqnqbp3yczrzjx2byk6p680q3mzanyw-gcc-10.3.0-lib' from 'https://cache.nixos.org'...
copying path '/nix/store/2xri2nhw2nxjlh4m0pfx53qxd057saj8-glibc-2.33-49-bin' from 'https://cache.nixos.org'...
copying path '/nix/store/d46asbmn0aq41xia32r3k575w63ckfbq-db-4.8.30' from 'https://cache.nixos.org'...
copying path '/nix/store/q68q448r514ak3vhf2m44ax6vhmxamjx-glibc-2.33-49-dev' from 'https://cache.nixos.org'...
copying path '/nix/store/wc269vfvf8nls0kadpm07m06cgjn0iaz-glibc-2.33-49-static' from 'https://cache.nixos.org'...
copying path '/nix/store/vd8b8a6037r3s8y8dpfhrwjyl4aprj0v-gmp-6.2.1' from 'https://cache.nixos.org'...
copying path '/nix/store/5kry9k64l4siw7f3qp4a5zyrdgjf85mi-gnumake-4.3' from 'https://cache.nixos.org'...
copying path '/nix/store/4cnyjnpswvlvld2icvfhdp35xn1w61af-gnused-4.8' from 'https://cache.nixos.org'...
copying path '/nix/store/maz16dk6bgdn0zsxr2vv4ciy5p5bkrlx-gnutar-1.34' from 'https://cache.nixos.org'...
copying path '/nix/store/5qdpzap2z0l5rlz5znw4iyi6jk7rab5z-go-bootstrap' from 'https://cache.nixos.org'...
copying path '/nix/store/df1n2a5cj24l0zfbhlcqx694bzlar94q-gzip-1.10' from 'https://cache.nixos.org'...
copying path '/nix/store/ssb3ji98gm99qg0pzvxkdg8z7s8bv4cj-json-c-0.15' from 'https://cache.nixos.org'...
copying path '/nix/store/sqk0m9r2b8lg02d4v6n9p17si495dqf7-keyutils-1.6.3-lib' from 'https://cache.nixos.org'...
copying path '/nix/store/ngxbinl207hg37x6pvrp31cj1nj5in3j-libapparmor-3.0.3' from 'https://cache.nixos.org'...
copying path '/nix/store/8rvw5zr49pi7939whxrxxx3fkiwvkhpc-libcap-2.49-lib' from 'https://cache.nixos.org'...
copying path '/nix/store/hp64yih1cc97gkhrcwmssv5lzj33vay2-libcap-ng-0.8.2' from 'https://cache.nixos.org'...
copying path '/nix/store/8qx9zz373vqq7wx7xszlnp0d5ww25cnr-libevent-2.1.12' from 'https://cache.nixos.org'...
copying path '/nix/store/67mys81mgnmf5ghgnhgixpnp5xqv7m6l-libffi-3.4.2' from 'https://cache.nixos.org'...
copying path '/nix/store/5p42ddhrpm6y8x0lcj5v546r560xav4g-libgpg-error-1.42' from 'https://cache.nixos.org'...
copying path '/nix/store/ga6avwlcsw00lfwwgpfrjw6s8rsshl7h-libkrb5-1.18' from 'https://cache.nixos.org'...
copying path '/nix/store/plgn1wacp4nfvn4a5c3znd81a2lhxd27-libassuan-2.5.5' from 'https://cache.nixos.org'...
copying path '/nix/store/rj21p3ba9xl9hgxfg1mpyrzgprshyra5-libgcrypt-1.9.3' from 'https://cache.nixos.org'...
copying path '/nix/store/r185pknh7w746yhbq3f9iqbswpc8zf9p-libmnl-1.0.4' from 'https://cache.nixos.org'...
copying path '/nix/store/04hz8rs4h6pni1l0zg12m6rwh4pz2h8r-gnupg-2.2.27' from 'https://cache.nixos.org'...
copying path '/nix/store/zbmzmwbdlrv38iwicm2d3ynn4rnvf4ds-libnfnetlink-1.0.1' from 'https://cache.nixos.org'...
copying path '/nix/store/g7s5zm08sii75w3w3jzxdrjaqc1isczj-libnftnl-1.2.0' from 'https://cache.nixos.org'...
copying path '/nix/store/n7mhdax4xnsycd006nsx9lbajibm868k-libnetfilter_conntrack-1.0.8' from 'https://cache.nixos.org'...
copying path '/nix/store/nmafclgs3ihgrry285prpk166fxay8pz-libpcap-1.10.1' from 'https://cache.nixos.org'...
copying path '/nix/store/p2zlvnhkfxr44g2sy6la03dq9lvch7ql-libseccomp-2.5.1-lib' from 'https://cache.nixos.org'...
copying path '/nix/store/xbv02l47l34dgc02w11v38n38mn704zm-iptables-1.8.7' from 'https://cache.nixos.org'...
copying path '/nix/store/q9z0ihw7a7jkhjp8jql1az28add1m4d6-libtasn1-4.17.0' from 'https://cache.nixos.org'...
copying path '/nix/store/5wxfws16q9qf5zc34hdsshydwvmr3dc1-linux-pam-1.5.1' from 'https://cache.nixos.org'...
copying path '/nix/store/96xqj1bzp5mmq0rcfy0k58j8hgha6m87-lz4-1.9.3' from 'https://cache.nixos.org'...
copying path '/nix/store/sjbhvcixa61s0a3sarcx2h0wj2995785-ncurses-6.2' from 'https://cache.nixos.org'...
copying path '/nix/store/ifvrxbzgk94k420g8grcv38gpcppfhsh-nettle-3.7.3' from 'https://cache.nixos.org'...
copying path '/nix/store/8l2w5s51l0f3fls7hb95084hh8mqq5r7-nghttp2-1.43.0-lib' from 'https://cache.nixos.org'...
copying path '/nix/store/wqggb5ilpgc1aw4fghy1qs1fjnl8d7sh-openssl-1.1.1l' from 'https://cache.nixos.org'...
copying path '/nix/store/r72xzdagvpv0n5cwppnd5lhwy3gch0bs-p11-kit-0.24.0' from 'https://cache.nixos.org'...
copying path '/nix/store/qs9ai71mpr7dsm1ili447x1nql3ga18q-patch-2.7.6' from 'https://cache.nixos.org'...
copying path '/nix/store/gcwds7i87a6cpc5lx8bwn6xzbzfw2kp4-patchelf-0.13' from 'https://cache.nixos.org'...
copying path '/nix/store/p1vw61dq54ziibsb357739gggg4998jy-pcre-8.44' from 'https://cache.nixos.org'...
copying path '/nix/store/7a9g2jwkvzcsgr25dqvmziyj8fla3na2-pcre2-10.36' from 'https://cache.nixos.org'...
copying path '/nix/store/p21zz3jvnsk6h7pb83lm9hyl2hb7d2g8-gnugrep-3.6' from 'https://cache.nixos.org'...
copying path '/nix/store/shg038k6xcn4hc34wk7z1iw7zk5k82m2-pcre-8.44-bin' from 'https://cache.nixos.org'...
copying path '/nix/store/0160hhpdql1b6g6b696wkwh9kp2pzgi3-perl-5.34.0' from 'https://cache.nixos.org'...
copying path '/nix/store/7b2jnb9j34r17yg4ifq1a435jla1z355-pcre-8.44-dev' from 'https://cache.nixos.org'...
copying path '/nix/store/h8ydv6bv2fk3rml4y4fv5rwvf67y9vgk-pkg-config-0.29.2' from 'https://cache.nixos.org'...
copying path '/nix/store/qc54papkkxvbhrc7vsasav7kn889j560-popt-1.18' from 'https://cache.nixos.org'...
copying path '/nix/store/7af3psmdq8vpcvrn2ph1wjxwcqn19njk-pkg-config-wrapper-0.29.2' from 'https://cache.nixos.org'...
copying path '/nix/store/pjb0sy7rvzx1mrmk5b6kdaz39dq8h4zs-readline-7.0p5' from 'https://cache.nixos.org'...
copying path '/nix/store/apzq0zhwqhgqvwlnczpdgfz0wy4cnm5n-shadow-4.8.1' from 'https://cache.nixos.org'...
copying path '/nix/store/mp1q3wb5jdx85jklmhywqswqkk9wrkg1-bash-interactive-4.4-p23' from 'https://cache.nixos.org'...
copying path '/nix/store/sdzj2vpvckwqp3j2n51gn7bzl20vnw77-unbound-1.13.2-lib' from 'https://cache.nixos.org'...
copying path '/nix/store/yyj367gn2fjzx8zqd3qf5ypfpq0xcgrx-util-linux-2.36.2' from 'https://cache.nixos.org'...
copying path '/nix/store/y6lg60virzfmp0q8z3nq6pa47j8sm2ci-gnutls-3.7.2' from 'https://cache.nixos.org'...
copying path '/nix/store/7s3zipf5df68x3dwsg1x6c3gmqjca79k-which-2.21' from 'https://cache.nixos.org'...
copying path '/nix/store/83m5017qivc9w2bir9kq3a8ng90apwln-libmicrohttpd-0.9.71' from 'https://cache.nixos.org'...
copying path '/nix/store/zr799zi12gns0j378ljr9cbv7mscnjfs-xz-5.2.5' from 'https://cache.nixos.org'...
copying path '/nix/store/43zy3j9a11icz158b336ahzf3bg7ykm1-zlib-1.2.11' from 'https://cache.nixos.org'...
copying path '/nix/store/haf7rmqmbm8jpiqpm3fi1wax08j8i2d1-kmod-27' from 'https://cache.nixos.org'...
copying path '/nix/store/kmqs0wll31ylwbqkpmlgbjrn6ny3myik-binutils-2.35.1' from 'https://cache.nixos.org'...
copying path '/nix/store/j7s08fw8cx71kvxzyhkz7sqqm804s6bl-gcc-10.3.0' from 'https://cache.nixos.org'...
copying path '/nix/store/zpfa1fc00k5r7zfknkigapxxn4kgiirc-binutils-wrapper-2.35.1' from 'https://cache.nixos.org'...
copying path '/nix/store/zi15ncfp3b06yjh93yd88m99y3fds3jy-kexec-tools-2.0.20' from 'https://cache.nixos.org'...
copying path '/nix/store/2qmkkrkk2d1jvin6iy8yvfh7iaawyqwm-gcc-wrapper-10.3.0' from 'https://cache.nixos.org'...
copying path '/nix/store/rr10mjrr3zmwwq9mm0mr4zj7f6xd9b4r-libssh2-1.9.0' from 'https://cache.nixos.org'...
copying path '/nix/store/r3hbvnvp5hmlyjq6njp7hsc6syv7vj42-util-linux-2.36.2-bin' from 'https://cache.nixos.org'...
copying path '/nix/store/fzhgkh90jm1lgvm63rhbmvnbs3dl2657-curl-7.76.1' from 'https://cache.nixos.org'...
copying path '/nix/store/g3yj32g7ysaz18qsfcr2ss51dwf1v6lp-xz-5.2.5-bin' from 'https://cache.nixos.org'...
copying path '/nix/store/959xr9vncijpkqnr34llswdj2dcsix6w-zstd-1.5.0' from 'https://cache.nixos.org'...
copying path '/nix/store/9jsp95c5r4pl1pdqzy9z405wj39czpwa-stdenv-linux' from 'https://cache.nixos.org'...
copying path '/nix/store/0zhm2wfi65077amz3rld3rsk2b41h7ip-zstd-1.5.0-bin' from 'https://cache.nixos.org'...
copying path '/nix/store/q8pf4wwwll4l3fw45kxpk3wh5df8j0hz-kbd-2.4.0' from 'https://cache.nixos.org'...
copying path '/nix/store/6axjb5wjhz8cac510q6am28araw53ic7-systemd-minimal-247.6' from 'https://cache.nixos.org'...
copying path '/nix/store/03bnnzclgaby0yga8931bl5mwlav8v4v-lvm2-2.03.12-lib' from 'https://cache.nixos.org'...
copying path '/nix/store/4vpcvif5vsdy26ipvnrssz2q9hsx09sj-cryptsetup-2.3.6' from 'https://cache.nixos.org'...
copying path '/nix/store/ln4fj9h2xybi4yg9nzzfl3kddg1ykqml-systemd-247.6' from 'https://cache.nixos.org'...
copying path '/nix/store/ld6727nv8jj0cj7l4jwzhxgdlcw9h7yb-procps-3.3.16' from 'https://cache.nixos.org'...
building '/nix/store/y9mlbvjhywh0pif7965yb1br3mabmbwk-go-1.17.drv'...
unpacking sources
unpacking source archive /nix/store/gmlfi1ml333hmgfmqgm9dn2lkdxr51pv-go1.17.linux-amd64.tar.gz
source root is go
setting SOURCE_DATE_EPOCH to timestamp<PHONE_NUMBER> of file go/pkg/linux_amd64_race/vendor/golang.org/x/net/nettest.a
patching sources
patching script interpreter paths in ./
./src/syscall/mksysnum_plan9.sh: interpreter directive changed from "#!/bin/sh" to "/nix/store/1flh34xxg9q3fpc88xyp2qynxpkfg8py-bash-4.4-p23/bin/sh"
./src/syscall/mksysnum_openbsd.pl: interpreter directive changed from "#!/usr/bin/env perl" to "/nix/store/0160hhpdql1b6g6b696wkwh9kp2pzgi3-perl-5.34.0/bin/perl"
./src/syscall/mksysnum_netbsd.pl: interpreter directive changed from "#!/usr/bin/env perl" to "/nix/store/0160hhpdql1b6g6b696wkwh9kp2pzgi3-perl-5.34.0/bin/perl"
./src/syscall/mksysnum_linux.pl: interpreter directive changed from "#!/usr/bin/env perl" to "/nix/store/0160hhpdql1b6g6b696wkwh9kp2pzgi3-perl-5.34.0/bin/perl"
./src/syscall/mksysnum_freebsd.pl: interpreter directive changed from "#!/usr/bin/env perl" to "/nix/store/0160hhpdql1b6g6b696wkwh9kp2pzgi3-perl-5.34.0/bin/perl"
./src/syscall/mksysnum_dragonfly.pl: interpreter directive changed from "#!/usr/bin/env perl" to "/nix/store/0160hhpdql1b6g6b696wkwh9kp2pzgi3-perl-5.34.0/bin/perl"
./src/syscall/mksysctl_openbsd.pl: interpreter directive changed from "#!/usr/bin/env perl" to "/nix/store/0160hhpdql1b6g6b696wkwh9kp2pzgi3-perl-5.34.0/bin/perl"
./src/syscall/mksyscall_libc.pl: interpreter directive changed from "#!/usr/bin/env perl" to "/nix/store/0160hhpdql1b6g6b696wkwh9kp2pzgi3-perl-5.34.0/bin/perl"
./src/syscall/mksyscall.pl: interpreter directive changed from "#!/usr/bin/env perl" to "/nix/store/0160hhpdql1b6g6b696wkwh9kp2pzgi3-perl-5.34.0/bin/perl"
./src/syscall/mkerrors.sh: interpreter directive changed from "#!/usr/bin/env bash" to "/nix/store/1flh34xxg9q3fpc88xyp2qynxpkfg8py-bash-4.4-p23/bin/bash"
./src/syscall/mkall.sh: interpreter directive changed from "#!/usr/bin/env bash" to "/nix/store/1flh34xxg9q3fpc88xyp2qynxpkfg8py-bash-4.4-p23/bin/bash"
./src/run.bash: interpreter directive changed from "#!/usr/bin/env bash" to "/nix/store/1flh34xxg9q3fpc88xyp2qynxpkfg8py-bash-4.4-p23/bin/bash"
./src/regexp/syntax/make_perl_groups.pl: interpreter directive changed from "#!/usr/bin/perl" to "/nix/store/0160hhpdql1b6g6b696wkwh9kp2pzgi3-perl-5.34.0/bin/perl"
./src/race.bash: interpreter directive changed from "#!/usr/bin/env bash" to "/nix/store/1flh34xxg9q3fpc88xyp2qynxpkfg8py-bash-4.4-p23/bin/bash"
./src/net/http/cgi/testdata/test.cgi: interpreter directive changed from "#!/usr/bin/perl" to "/nix/store/0160hhpdql1b6g6b696wkwh9kp2pzgi3-perl-5.34.0/bin/perl"
./src/make.bash: interpreter directive changed from "#!/usr/bin/env bash" to "/nix/store/1flh34xxg9q3fpc88xyp2qynxpkfg8py-bash-4.4-p23/bin/bash"
./src/internal/trace/mkcanned.bash: interpreter directive changed from "#!/usr/bin/env bash" to "/nix/store/1flh34xxg9q3fpc88xyp2qynxpkfg8py-bash-4.4-p23/bin/bash"
./src/cmd/go/testdata/failssh/ssh: interpreter directive changed from "#!/bin/sh" to "/nix/store/1flh34xxg9q3fpc88xyp2qynxpkfg8py-bash-4.4-p23/bin/sh"
./src/cmd/go/mkalldocs.sh: interpreter directive changed from "#!/usr/bin/env bash" to "/nix/store/1flh34xxg9q3fpc88xyp2qynxpkfg8py-bash-4.4-p23/bin/bash"
./src/cmd/compile/internal/ssa/gen/cover.bash: interpreter directive changed from "#!/usr/bin/env bash" to "/nix/store/1flh34xxg9q3fpc88xyp2qynxpkfg8py-bash-4.4-p23/bin/bash"
./src/clean.bash: interpreter directive changed from "#!/usr/bin/env bash" to "/nix/store/1flh34xxg9q3fpc88xyp2qynxpkfg8py-bash-4.4-p23/bin/bash"
./src/buildall.bash: interpreter directive changed from "#!/usr/bin/env bash" to "/nix/store/1flh34xxg9q3fpc88xyp2qynxpkfg8py-bash-4.4-p23/bin/bash"
./src/bootstrap.bash: interpreter directive changed from "#!/usr/bin/env bash" to "/nix/store/1flh34xxg9q3fpc88xyp2qynxpkfg8py-bash-4.4-p23/bin/bash"
./src/all.bash: interpreter directive changed from "#!/usr/bin/env bash" to "/nix/store/1flh34xxg9q3fpc88xyp2qynxpkfg8py-bash-4.4-p23/bin/bash"
./misc/wasm/go_js_wasm_exec: interpreter directive changed from "#!/bin/bash" to "/nix/store/1flh34xxg9q3fpc88xyp2qynxpkfg8py-bash-4.4-p23/bin/bash"
./misc/ios/clangwrap.sh: interpreter directive changed from "#!/bin/sh" to "/nix/store/1flh34xxg9q3fpc88xyp2qynxpkfg8py-bash-4.4-p23/bin/sh"
./misc/cgo/fortran/test.bash: interpreter directive changed from "#!/usr/bin/env bash" to "/nix/store/1flh34xxg9q3fpc88xyp2qynxpkfg8py-bash-4.4-p23/bin/bash"
./misc/arm/a: interpreter directive changed from "#!/usr/bin/env bash" to "/nix/store/1flh34xxg9q3fpc88xyp2qynxpkfg8py-bash-4.4-p23/bin/bash"
./lib/time/update.bash: interpreter directive changed from "#!/bin/bash" to "/nix/store/1flh34xxg9q3fpc88xyp2qynxpkfg8py-bash-4.4-p23/bin/bash"
applying patch /nix/store/7dc83qn7fiww0z7bwglwv27j4i5l0mzq-4e07fa9fe4e905d89c725baed404ae43e03eb08e.patch
patching file src/cmd/go/internal/work/exec.go
applying patch /nix/store/0iysyr1qfwnas38dj3lqxc7hc43y42p8-432db23601eeb941cf2ae3a539a62e6f7c11ed06.patch
patching file src/cmd/cgo/gcc.go
patching file src/cmd/cgo/godefs.go
patching file src/cmd/cgo/main.go
patching file src/cmd/cgo/out.go
patching file src/cmd/cgo/util.go
patching file src/cmd/go/internal/work/exec.go
configuring
no configure script, doing nothing
core file size          (blocks, -c) 0
data seg size           (kbytes, -d) unlimited
scheduling priority             (-e) 0
file size               (blocks, -f) unlimited
pending signals                 (-i) 94064
max locked memory       (kbytes, -l) 16384
max memory size         (kbytes, -m) unlimited
open files                      (-n) 10240
pipe size            (512 bytes, -p) 8
POSIX message queues     (bytes, -q) 819200
real-time priority              (-r) 0
stack size              (kbytes, -s) 8192
cpu time               (seconds, -t) unlimited
max user processes              (-u) 94064
virtual memory          (kbytes, -v) unlimited
file locks                      (-x) unlimited
building
no Makefile, doing nothing
Building Go cmd/dist using /nix/store/5qdpzap2z0l5rlz5znw4iyi6jk7rab5z-go-bootstrap/share/go. (go1.16 linux/amd64)
Building Go toolchain1 using /nix/store/5qdpzap2z0l5rlz5znw4iyi6jk7rab5z-go-bootstrap/share/go.

Building Go toolchain2 using go_bootstrap and Go toolchain1.
Building Go toolchain3 using go_bootstrap and Go toolchain2.
Building packages and commands for linux/amd64.
Installed Go for linux/amd64 in /build/go
Installed commands in /build/go/bin
The binaries expect /build/go to be copied or moved to /nix/store/1y1sxwam2jf1f5w9dqfg44wdpwappdch-go-1.17/share/go
installing
post-installation fixup
shrinking RPATHs of ELF executables and libraries in /nix/store/1y1sxwam2jf1f5w9dqfg44wdpwappdch-go-1.17
shrinking /nix/store/1y1sxwam2jf1f5w9dqfg44wdpwappdch-go-1.17/share/go/bin/gofmt
patchelf: cannot find section '.dynamic'. The input file is most likely statically linked
shrinking /nix/store/1y1sxwam2jf1f5w9dqfg44wdpwappdch-go-1.17/share/go/bin/go
shrinking /nix/store/1y1sxwam2jf1f5w9dqfg44wdpwappdch-go-1.17/share/go/pkg/tool/linux_amd64/asm
patchelf: cannot find section '.dynamic'. The input file is most likely statically linked
shrinking /nix/store/1y1sxwam2jf1f5w9dqfg44wdpwappdch-go-1.17/share/go/pkg/tool/linux_amd64/cgo
patchelf: cannot find section '.dynamic'. The input file is most likely statically linked
shrinking /nix/store/1y1sxwam2jf1f5w9dqfg44wdpwappdch-go-1.17/share/go/pkg/tool/linux_amd64/link
patchelf: cannot find section '.dynamic'. The input file is most likely statically linked
shrinking /nix/store/1y1sxwam2jf1f5w9dqfg44wdpwappdch-go-1.17/share/go/pkg/tool/linux_amd64/compile
patchelf: cannot find section '.dynamic'. The input file is most likely statically linked
shrinking /nix/store/1y1sxwam2jf1f5w9dqfg44wdpwappdch-go-1.17/share/go/pkg/tool/linux_amd64/addr2line
patchelf: cannot find section '.dynamic'. The input file is most likely statically linked
shrinking /nix/store/1y1sxwam2jf1f5w9dqfg44wdpwappdch-go-1.17/share/go/pkg/tool/linux_amd64/api
patchelf: cannot find section '.dynamic'. The input file is most likely statically linked
shrinking /nix/store/1y1sxwam2jf1f5w9dqfg44wdpwappdch-go-1.17/share/go/pkg/tool/linux_amd64/buildid
patchelf: cannot find section '.dynamic'. The input file is most likely statically linked
shrinking /nix/store/1y1sxwam2jf1f5w9dqfg44wdpwappdch-go-1.17/share/go/pkg/tool/linux_amd64/cover
patchelf: cannot find section '.dynamic'. The input file is most likely statically linked
shrinking /nix/store/1y1sxwam2jf1f5w9dqfg44wdpwappdch-go-1.17/share/go/pkg/tool/linux_amd64/doc
patchelf: cannot find section '.dynamic'. The input file is most likely statically linked
shrinking /nix/store/1y1sxwam2jf1f5w9dqfg44wdpwappdch-go-1.17/share/go/pkg/tool/linux_amd64/dist
patchelf: cannot find section '.dynamic'. The input file is most likely statically linked
shrinking /nix/store/1y1sxwam2jf1f5w9dqfg44wdpwappdch-go-1.17/share/go/pkg/tool/linux_amd64/fix
patchelf: cannot find section '.dynamic'. The input file is most likely statically linked
shrinking /nix/store/1y1sxwam2jf1f5w9dqfg44wdpwappdch-go-1.17/share/go/pkg/tool/linux_amd64/nm
patchelf: cannot find section '.dynamic'. The input file is most likely statically linked
shrinking /nix/store/1y1sxwam2jf1f5w9dqfg44wdpwappdch-go-1.17/share/go/pkg/tool/linux_amd64/objdump
patchelf: cannot find section '.dynamic'. The input file is most likely statically linked
shrinking /nix/store/1y1sxwam2jf1f5w9dqfg44wdpwappdch-go-1.17/share/go/pkg/tool/linux_amd64/pack
patchelf: cannot find section '.dynamic'. The input file is most likely statically linked
shrinking /nix/store/1y1sxwam2jf1f5w9dqfg44wdpwappdch-go-1.17/share/go/pkg/tool/linux_amd64/test2json
patchelf: cannot find section '.dynamic'. The input file is most likely statically linked
shrinking /nix/store/1y1sxwam2jf1f5w9dqfg44wdpwappdch-go-1.17/share/go/pkg/tool/linux_amd64/trace
shrinking /nix/store/1y1sxwam2jf1f5w9dqfg44wdpwappdch-go-1.17/share/go/pkg/tool/linux_amd64/pprof
shrinking /nix/store/1y1sxwam2jf1f5w9dqfg44wdpwappdch-go-1.17/share/go/pkg/tool/linux_amd64/vet
patchelf: cannot find section '.dynamic'. The input file is most likely statically linked
shrinking /nix/store/1y1sxwam2jf1f5w9dqfg44wdpwappdch-go-1.17/share/go/src/debug/dwarf/testdata/cppunsuptypes.elf
patchelf: wrong ELF type
shrinking /nix/store/1y1sxwam2jf1f5w9dqfg44wdpwappdch-go-1.17/share/go/src/debug/dwarf/testdata/cycle.elf
patchelf: wrong ELF type
shrinking /nix/store/1y1sxwam2jf1f5w9dqfg44wdpwappdch-go-1.17/share/go/src/debug/dwarf/testdata/line-clang-dwarf5.elf
shrinking /nix/store/1y1sxwam2jf1f5w9dqfg44wdpwappdch-go-1.17/share/go/src/debug/dwarf/testdata/line-clang.elf
shrinking /nix/store/1y1sxwam2jf1f5w9dqfg44wdpwappdch-go-1.17/share/go/src/debug/dwarf/testdata/line-gcc-dwarf5.elf
shrinking /nix/store/1y1sxwam2jf1f5w9dqfg44wdpwappdch-go-1.17/share/go/src/debug/dwarf/testdata/line-gcc.elf
shrinking /nix/store/1y1sxwam2jf1f5w9dqfg44wdpwappdch-go-1.17/share/go/src/debug/dwarf/testdata/ranges.elf
shrinking /nix/store/1y1sxwam2jf1f5w9dqfg44wdpwappdch-go-1.17/share/go/src/debug/dwarf/testdata/rnglistx.elf
patchelf: cannot find section '.dynamic'. The input file is most likely statically linked
shrinking /nix/store/1y1sxwam2jf1f5w9dqfg44wdpwappdch-go-1.17/share/go/src/debug/dwarf/testdata/split.elf
shrinking /nix/store/1y1sxwam2jf1f5w9dqfg44wdpwappdch-go-1.17/share/go/src/debug/dwarf/testdata/typedef.elf
shrinking /nix/store/1y1sxwam2jf1f5w9dqfg44wdpwappdch-go-1.17/share/go/src/debug/dwarf/testdata/typedef.elf4
patchelf: wrong ELF type
shrinking /nix/store/1y1sxwam2jf1f5w9dqfg44wdpwappdch-go-1.17/share/go/src/debug/elf/testdata/compressed-32.obj
patchelf: wrong ELF type
shrinking /nix/store/1y1sxwam2jf1f5w9dqfg44wdpwappdch-go-1.17/share/go/src/debug/elf/testdata/compressed-64.obj
patchelf: wrong ELF type
shrinking /nix/store/1y1sxwam2jf1f5w9dqfg44wdpwappdch-go-1.17/share/go/src/debug/elf/testdata/gcc-386-freebsd-exec
shrinking /nix/store/1y1sxwam2jf1f5w9dqfg44wdpwappdch-go-1.17/share/go/src/debug/elf/testdata/gcc-amd64-linux-exec
shrinking /nix/store/1y1sxwam2jf1f5w9dqfg44wdpwappdch-go-1.17/share/go/src/debug/elf/testdata/gcc-amd64-openbsd-debug-with-rela.obj
patchelf: wrong ELF type
shrinking /nix/store/1y1sxwam2jf1f5w9dqfg44wdpwappdch-go-1.17/share/go/src/debug/elf/testdata/go-relocation-test-clang-arm.obj
patchelf: wrong ELF type
shrinking /nix/store/1y1sxwam2jf1f5w9dqfg44wdpwappdch-go-1.17/share/go/src/debug/elf/testdata/go-relocation-test-clang-x86.obj
patchelf: wrong ELF type
shrinking /nix/store/1y1sxwam2jf1f5w9dqfg44wdpwappdch-go-1.17/share/go/src/debug/elf/testdata/go-relocation-test-gcc424-x86-64.obj
patchelf: wrong ELF type
shrinking /nix/store/1y1sxwam2jf1f5w9dqfg44wdpwappdch-go-1.17/share/go/src/debug/elf/testdata/go-relocation-test-gcc441-x86-64.obj
patchelf: wrong ELF type
shrinking /nix/store/1y1sxwam2jf1f5w9dqfg44wdpwappdch-go-1.17/share/go/src/debug/elf/testdata/go-relocation-test-gcc441-x86.obj
patchelf: wrong ELF type
shrinking /nix/store/1y1sxwam2jf1f5w9dqfg44wdpwappdch-go-1.17/share/go/src/debug/elf/testdata/go-relocation-test-gcc482-aarch64.obj
patchelf: wrong ELF type
shrinking /nix/store/1y1sxwam2jf1f5w9dqfg44wdpwappdch-go-1.17/share/go/src/debug/elf/testdata/go-relocation-test-gcc482-ppc64le.obj
patchelf: wrong ELF type
shrinking /nix/store/1y1sxwam2jf1f5w9dqfg44wdpwappdch-go-1.17/share/go/src/debug/elf/testdata/go-relocation-test-gcc492-arm.obj
patchelf: wrong ELF type
shrinking /nix/store/1y1sxwam2jf1f5w9dqfg44wdpwappdch-go-1.17/share/go/src/debug/elf/testdata/go-relocation-test-gcc492-mips64.obj
patchelf: wrong ELF type
shrinking /nix/store/1y1sxwam2jf1f5w9dqfg44wdpwappdch-go-1.17/share/go/src/debug/elf/testdata/go-relocation-test-gcc492-mipsle.obj
patchelf: wrong ELF type
shrinking /nix/store/1y1sxwam2jf1f5w9dqfg44wdpwappdch-go-1.17/share/go/src/debug/elf/testdata/go-relocation-test-gcc493-mips64le.obj
patchelf: wrong ELF type
shrinking /nix/store/1y1sxwam2jf1f5w9dqfg44wdpwappdch-go-1.17/share/go/src/debug/elf/testdata/go-relocation-test-gcc5-ppc.obj
patchelf: wrong ELF type
shrinking /nix/store/1y1sxwam2jf1f5w9dqfg44wdpwappdch-go-1.17/share/go/src/debug/elf/testdata/go-relocation-test-gcc531-s390x.obj
patchelf: wrong ELF type
shrinking /nix/store/1y1sxwam2jf1f5w9dqfg44wdpwappdch-go-1.17/share/go/src/debug/elf/testdata/go-relocation-test-gcc540-mips.obj
patchelf: wrong ELF type
shrinking /nix/store/1y1sxwam2jf1f5w9dqfg44wdpwappdch-go-1.17/share/go/src/debug/elf/testdata/go-relocation-test-gcc620-sparc64.obj
patchelf: wrong ELF type
shrinking /nix/store/1y1sxwam2jf1f5w9dqfg44wdpwappdch-go-1.17/share/go/src/debug/elf/testdata/go-relocation-test-gcc720-riscv64.obj
patchelf: wrong ELF type
shrinking /nix/store/1y1sxwam2jf1f5w9dqfg44wdpwappdch-go-1.17/share/go/src/debug/elf/testdata/go-relocation-test-gcc930-ranges-no-rela-x86-64
patchelf: cannot find section '.dynamic'. The input file is most likely statically linked
shrinking /nix/store/1y1sxwam2jf1f5w9dqfg44wdpwappdch-go-1.17/share/go/src/debug/elf/testdata/go-relocation-test-gcc930-ranges-with-rela-x86-64
patchelf: cannot find section '.dynamic'. The input file is most likely statically linked
shrinking /nix/store/1y1sxwam2jf1f5w9dqfg44wdpwappdch-go-1.17/share/go/src/debug/elf/testdata/zdebug-test-gcc484-x86-64.obj
patchelf: wrong ELF type
shrinking /nix/store/1y1sxwam2jf1f5w9dqfg44wdpwappdch-go-1.17/share/go/src/go/internal/gccgoimporter/testdata/escapeinfo.gox
patchelf: wrong ELF type
shrinking /nix/store/1y1sxwam2jf1f5w9dqfg44wdpwappdch-go-1.17/share/go/src/go/internal/gccgoimporter/testdata/time.gox
patchelf: wrong ELF type
shrinking /nix/store/1y1sxwam2jf1f5w9dqfg44wdpwappdch-go-1.17/share/go/src/go/internal/gccgoimporter/testdata/unicode.gox
patchelf: wrong ELF type
shrinking /nix/store/1y1sxwam2jf1f5w9dqfg44wdpwappdch-go-1.17/share/go/src/go/internal/gccgoimporter/testdata/v1reflect.gox
patchelf: wrong ELF type
shrinking /nix/store/1y1sxwam2jf1f5w9dqfg44wdpwappdch-go-1.17/share/go/src/runtime/pprof/testdata/test32
patchelf: cannot find section '.dynamic'. The input file is most likely statically linked
shrinking /nix/store/1y1sxwam2jf1f5w9dqfg44wdpwappdch-go-1.17/share/go/src/runtime/pprof/testdata/test32be
patchelf: cannot find section '.dynamic'. The input file is most likely statically linked
shrinking /nix/store/1y1sxwam2jf1f5w9dqfg44wdpwappdch-go-1.17/share/go/src/runtime/pprof/testdata/test64
patchelf: cannot find section '.dynamic'. The input file is most likely statically linked
shrinking /nix/store/1y1sxwam2jf1f5w9dqfg44wdpwappdch-go-1.17/share/go/src/runtime/pprof/testdata/test64be
patchelf: cannot find section '.dynamic'. The input file is most likely statically linked
shrinking /nix/store/1y1sxwam2jf1f5w9dqfg44wdpwappdch-go-1.17/share/go/src/runtime/race/race_linux_amd64.syso
patchelf: wrong ELF type
rewriting symlink /nix/store/1y1sxwam2jf1f5w9dqfg44wdpwappdch-go-1.17/bin to be relative to /nix/store/1y1sxwam2jf1f5w9dqfg44wdpwappdch-go-1.17
strip is /nix/store/kmqs0wll31ylwbqkpmlgbjrn6ny3myik-binutils-2.35.1/bin/strip
stripping (with command strip and flags -S) in /nix/store/1y1sxwam2jf1f5w9dqfg44wdpwappdch-go-1.17/bin
patching script interpreter paths in /nix/store/1y1sxwam2jf1f5w9dqfg44wdpwappdch-go-1.17
checking for references to /build/ in /nix/store/1y1sxwam2jf1f5w9dqfg44wdpwappdch-go-1.17...
patchelf: cannot find section '.dynamic'. The input file is most likely statically linked
patchelf: cannot find section '.dynamic'. The input file is most likely statically linked
patchelf: cannot find section '.dynamic'. The input file is most likely statically linked
patchelf: cannot find section '.dynamic'. The input file is most likely statically linked
patchelf: cannot find section '.dynamic'. The input file is most likely statically linked
patchelf: cannot find section '.dynamic'. The input file is most likely statically linked
patchelf: cannot find section '.dynamic'. The input file is most likely statically linked
patchelf: cannot find section '.dynamic'. The input file is most likely statically linked
patchelf: cannot find section '.dynamic'. The input file is most likely statically linked
patchelf: cannot find section '.dynamic'. The input file is most likely statically linked
patchelf: cannot find section '.dynamic'. The input file is most likely statically linked
patchelf: cannot find section '.dynamic'. The input file is most likely statically linked
patchelf: cannot find section '.dynamic'. The input file is most likely statically linked
patchelf: cannot find section '.dynamic'. The input file is most likely statically linked
patchelf: cannot find section '.dynamic'. The input file is most likely statically linked
patchelf: cannot find section '.dynamic'. The input file is most likely statically linked
patchelf: cannot find section '.dynamic'. The input file is most likely statically linked
patchelf: wrong ELF type
patchelf: wrong ELF type
patchelf: cannot find section '.dynamic'. The input file is most likely statically linked
patchelf: wrong ELF type
patchelf: wrong ELF type
patchelf: wrong ELF type
patchelf: wrong ELF type
patchelf: wrong ELF type
patchelf: wrong ELF type
patchelf: wrong ELF type
patchelf: wrong ELF type
patchelf: wrong ELF type
patchelf: wrong ELF type
patchelf: wrong ELF type
patchelf: wrong ELF type
patchelf: wrong ELF type
patchelf: wrong ELF type
patchelf: wrong ELF type
patchelf: wrong ELF type
patchelf: wrong ELF type
patchelf: wrong ELF type
patchelf: wrong ELF type
patchelf: wrong ELF type
patchelf: cannot find section '.dynamic'. The input file is most likely statically linked
patchelf: cannot find section '.dynamic'. The input file is most likely statically linked
patchelf: wrong ELF type
patchelf: wrong ELF type
patchelf: wrong ELF type
patchelf: wrong ELF type
patchelf: wrong ELF type
patchelf: cannot find section '.dynamic'. The input file is most likely statically linked
patchelf: cannot find section '.dynamic'. The input file is most likely statically linked
patchelf: cannot find section '.dynamic'. The input file is most likely statically linked
patchelf: cannot find section '.dynamic'. The input file is most likely statically linked
patchelf: wrong ELF type
…/gotk4-examples  master +2 -2 ∆ 🐹 via ❄  impure (nix-shell)
➜
</details>

and then the next-time I try to run the same thing (`nix-shell shell.nix`), *there is* ***no*** *problem*! as if no error occured during env setup.
what follows, though, is (following the README again) running `go run -v gtk4/simple` from the root of the project from inside the nix shell environment now: it fails to run the `gtk4/simple` app with the weird error [8].

[8]
```sh
…/gotk4-examples  master +2 -2 ∆ 🐹 via ❄  impure (nix-shell)
➜  go run -v gtk4/simple
Alias tip: gor -v gtk4/simple
package gtk4/simple is not in GOROOT (/nix/store/1y1sxwam2jf1f5w9dqfg44wdpwappdch-go-1.17/share/go/src/gtk4/simple)

..whereas if I just cd into the directory (gtk4/simple) and go run there, it worksTM[9]. do you have any idea as to why that may be like this?

Alias tip: gor -v .
go: downloading github.com/diamondburned/gotk4/pkg v0.0.0-20220221063304-bbd86ac49f1b
github.com/diamondburned/gotk4/pkg/cairo/internal/swizzle
go4.org/unsafe/assume-no-moving-gc
github.com/diamondburned/gotk4/pkg/core/slab
golang.org/x/sync/singleflight
github.com/diamondburned/gotk4/pkg/core/closure
github.com/diamondburned/gotk4/pkg/core/gextras
github.com/diamondburned/gotk4/pkg/core/gbox
github.com/diamondburned/gotk4/pkg/core/intern
github.com/diamondburned/gotk4/pkg/core/glib
github.com/diamondburned/gotk4/pkg/core/gcancel
github.com/diamondburned/gotk4/pkg/core/gerror
github.com/diamondburned/gotk4/pkg/cairo
github.com/diamondburned/gotk4/pkg/graphene
github.com/diamondburned/gotk4/pkg/glib/v2
github.com/diamondburned/gotk4/pkg/pango
github.com/diamondburned/gotk4/pkg/gio/v2
github.com/diamondburned/gotk4/pkg/gdkpixbuf/v2
github.com/diamondburned/gotk4/pkg/gdk/v4
github.com/diamondburned/gotk4/pkg/gsk/v4
github.com/diamondburned/gotk4/pkg/gtk/v4
github.com/diamondburned/gotk4-examples/gtk4/simple
2022/03/24 22:05:33 Warning: Gtk: Locale not supported by C library.
	Using the fallback 'C' locale.
2022/03/24 22:05:33 Message: Gsk: Failed to realize renderer of type 'GskGLRenderer' for surface 'GdkWaylandToplevel': Failed to create EGL display
# ^ at that point the app is running


Accidentally deleted Tools menu

Version information

Laravel: v5.8
Voyager: v1.2
PHP: 7.2
Database: MySQL 8.0

Description:
I accidentally deleted the Tools menu and can´t get it back.
Can anyone help me?

You can get what you need from here:
https://github.com/the-control-group/voyager/blob/1.2/publishable/database/seeds/MenuItemsTableSeeder.php

Questions should be asked in Slack, not here.


Popularity calculation Pipeline in SQL

Fixes

Fixes #431 by @kgodey
Description

This PR adds 3 Apache Airflow DAGs, defined at

src/cc_catalog_airflow/dags/recreate_image_popularity_calculation.py
src/cc_catalog_airflow/dags/refresh_all_image_popularity_data.py
src/cc_catalog_airflow/dags/refresh_image_view_data.py
These DAGs define a "pipeline" in the Upstream DB that culminate with the PostgreSQL materialized view image_view.  This new view has a column standardized_popularity containing a float between 0 and 1 representing the popularity of a given image within a given provider (the domain from which the image and its metadata were collected).

Technical details

The standardized_popularity value is calculated from a raw 'popularity metric' such as views, comments, likes, etc.  The current ones we use are

views in the case of Flickr
global_usage_count in the case of Wikimedia Commons (this is the number of 'wikiverse' pages that use an image).
We map the raw values to the interval [0, 1) via a process that allows us to pin a given percentile value within the real distribution (over the values taken by the raw metric for a given provider) to a desired value in the interval.  The current implementation pins the 85th percentile value to 0.85.

To calculate the standardized value in [0, 1) for a given metric, we do the following:

For some provider, calculate the 85th percentile value (denote it by V) within the distribution of the raw metric.  In this implementation, the percentile value is stored for each provider, metric pair in the materialized view image_popularity_constants in the value column.
Calculate a constant C = (1 -  0.85) / 0.85 * V.  This is also stored for each provider, metric pair in image_popularity_constants in the constant column.
For each image, with raw metric value of x, calculate the standardized popularity via P = x / (x + C).  In this implementation, this is stored in the standardized_popularity column of the image_view materialized view.

Related to the PR:  #426
Tests

There are a number of tests for the new functionality.
Also, the reviewer can follow the README to bring up the dev environment, then run the flicker_ingestion and wikimedia_commons_ingestion DAGs for awhile.  Once data has been collected, run the
recreate_image_popularity_calculation DAG, and then query the image_view in the local DB to see the results.
Screenshots

Checklist

[X] My pull request has a descriptive title (not a vague title like Update index.md).
[X] My pull request targets the default branch of the repository (main or master).
[X] My commit messages follow best practices.
[X] My code follows the established code style of the repository.
[X] I added tests for the changes I made (if applicable).
[ ] ~I added or updated documentation (if applicable).~
[X] I tried running the project locally and verified that there are no
visible errors.

Developer Certificate of Origin

Developer Certificate of Origin
Developer Certificate of Origin
Version 1.1

Copyright (C) 2004, 2006 The Linux Foundation and its contributors.
1 Letterman Drive
Suite D4700
San Francisco, CA, 94129

Everyone is permitted to copy and distribute verbatim copies of this
license document, but changing it is not allowed.

Developer's Certificate of Origin 1.1

By making a contribution to this project, I certify that:

(a) The contribution was created in whole or in part by me and I
    have the right to submit it under the open source license
    indicated in the file; or

(b) The contribution is based upon previous work that, to the best
    of my knowledge, is covered under an appropriate open source
    license and I have the right under that license to submit that
    work with modifications, whether created in whole or in part
    by me, under the same open source license (unless I am
    permitted to submit under a different license), as indicated
    in the file; or

(c) The contribution was provided directly to me by some other
    person who certified (a), (b) or (c) and I have not modified
    it.

(d) I understand and agree that this project and the contribution
    are public and that a record of the contribution (including all
    personal information I submit with it, including my sign-off) is
    maintained indefinitely and may be redistributed consistent with
    this project or the open source license(s) involved.

It should be noted that the reason not to use standard quantile normalization is to preserve some of the idiosyncrasies of the original distributions, while still ending up with a somewhat comparable standardized popularity.


Sorting of Pages in Templates

Hey,
when you sort collections right now the result does not properly handle upper / lowercase stuff.
Form a query like this:
{% set projects = taxonomy.findTaxonomy({'tag':'featured-project'}).order('header.owner') %}

You get this:
A
B
a
b

I would have expected this:
A
a
B
b

Problem is the sorting within the Pages Collection that uses asort without any options.
Since PHP 5.4 you can use Flags to state that you want a proper case honoring sorting:
asort($list, SORT_NATURAL | SORT_FLAG_CASE);

Can we add this as a default or will this implode anything?
cheers
Chris

I think that should be fixed as currently it's not an expected behavior. @rhukster agree?

Should be fixed in repo.


Add zsh completions for brew-services

This addresses code that was lost from the changes to the completions
scripts from oh-my-zsh. It requires a change to brew to install
completion scripts, but can be manually tested before then via symlink:
ln -s /usr/local/Homebrew/Library/Taps/homebrew/homebrew-services/completions/zsh/_brew_services /usr/local/share/zsh/site-functions/_brew_services

Fixes #73

@joshka Somewhat relatedly: you may want to pull this into the code repo too now: https://github.com/Homebrew/homebrew-completions/blob/master/brew-cask-completion.rb

It requires a change to brew to install
completion scripts, but can be manually tested before then via symlink:

👍 but will wait on the Homebrew/brew change before we merge this.

@MikeMcQuaid I've asked the original author to re-license the brew-cask completions from MIT to BSD, and will get them into brew when that issue is resolved (either with or without an extra header with license info).
https://github.com/xyb/homebrew-cask-completion/issues/4

@joshka Thanks!

Thanks again @joshka!


Add cantorsdust's mods

Cantordust has released their mods, added me as co-maintainer on Nexus, and explicitly given permission for community maintenance. Migrate their mods to community maintenance.
To do

[x] Make sure all mods are eligible.

mod
source code
license
co-maintainer

All Crops All Seasons
✓ GitHub
✓ GPL
✓

All Professions
✓ GitHub
✓ GPL
✓

Instant Grow Trees
✓ GitHub
✓ GPL
✓

Recatch Legendary Fish
✓ GitHub
✓ GPL
✓

Skull Cave Saver
✓ GitHub
✓ GPL
✓

TimeSpeed
✓ GitHub
✓ GPL
✓

[x] Check for unofficial versions.

mod
update
source code
license
maintainer interested?

All Crops All Seasons
none

All Professions
none

Instant Grow Trees
none

Recatch Legendary Fish
none

Skull Cave Saver
none

TimeSpeed
TimeSpeed 2.0
✓ GitHub
✓ GPL
✓ interested

[x] Migrate to community mods.

mod
merge into repo
update code
refactor
release new version

All Crops All Seasons
✓
✓
✓
✓

All Professions
✓
✓
✓
✓

Instant Grow Trees
✓
✓
✓
✓

Recatch Legendary Fish
✓
✓
✓
✓

Skull Cave Saver
✓
✓
✓
✓

TimeSpeed(including unofficial update)
✓
✓
✓
✓

Done! Beta versions have been released for all the mods, with non-beta versions to follow once Stardew Valley 1.2 is out of beta.


SAKIII-4006 fix embedcontent group association and modified addtolibrary

SAKIII-4006 fix embedcontent group association and modified addtolibrary function to handle multiple content items
https://jira.sakaiproject.org/browse/SAKIII-4006

Verified and merged.


Enable user to choose which Blockchain Explorer to use

[ ] design selection setting. Should be somewhere in Settings.
[ ] once done create a new issue for implementation

@TalgatNurdinov please upload for android

https://zpl.io/adrpoR5