Channels
doorman
infrastructure
random
zercurity
community-feeds
fleet-dev
code-review
queryhub
apple-silicon
carving
tls
fim
goquery
zentral
aws
querycon
golang
zeek
file-carving
fuzzing
auditing-warroom
linen-dev
fleetosquery
plugins
jobs
arm-architecture
darkbytes
process-auditing
uptycs
android_tests
selfgroup
vendor-feeds
fleet
eclecticiq-polylogyx-extension
ebpf
website
core
general
macos
kolide
osctrl
extensions
foundation
sql
officehours
linux
windows
Title
s
seph
03/18/2021, 12:14 AMI think https://github.com/osquery/osquery-toolchain/pull/23 is ready for review. And I want to get the toolchain builders more officially supporting aarch64
a
alessandrogario
03/18/2021, 12:16 AMcc @Stefano Bonicatti
t
theopolis
03/18/2021, 12:34 AMI’m curious why you think the toolchain repo is a better home compared to the existing osquery/osquery home that you have linked in the PR?
s
seph
03/18/2021, 12:36 AMI can be convinced to move it to the osquery repo.
But the bulk of the image is the tool chain. And if not for the cmske bug, it link it to the tool chain repos ci
Eg: I expect to rebuild that when the tool chain changes. And not much else
t
theopolis
03/18/2021, 12:38 AMTrue
My only ask is that we have it live in only one place so if we determine the toolchain repo then we should delete the existing dockerfile in osquery.
💯 1
s
Stefano Bonicatti
03/18/2021, 12:39 AMHum the Dockerfile is something more connected to the CI and the osquery repo than the toolchain. The CMake version in there might have to be updated, we might need to update the OS and also the list of packages (python stuff) for tests.
I don’t think that the change rate of that file is in sync with the toolchain. The toolchain repo was really meant for the compiler only, and all the files there are meant to produce a release tar.gz.
s
seph
03/18/2021, 12:40 AMYes. If we merge that I'll pr the removal.
It's also not osquery code. It's just kinda support crap.
But I don't feel super strongly. I just want it done. Happy to move the PR to the other repo.
t
theopolis
03/18/2021, 12:42 AMI have a slight bias towards having it in the osquery repo as we might want to change the toolchain around, make an official new release, then finally update the pinned release in the osquery dockerfile and publish that change distinctly.
I know the dockerfile in the osquery repo isn’t strictly what is on docker registry but I like to think that it’s the “source” representation.
s
seph
03/18/2021, 12:45 AMOkay. That's two votes to leave it in osquery. I'll defer on this. I'll move it after child bedtime. Please also review for content.
Updated to be https://github.com/osquery/osquery/pull/7011 have as look at that, review, thumb, etc.
t
theopolis
03/18/2021, 2:21 AMah, I just reviewed https://github.com/osquery/osquery-toolchain/pull/23#pullrequestreview-614928540 (I had it open in a window from a few hours before) hehe
s
seph
03/18/2021, 2:37 AMall good. I replied there and the one thing I implemented I did on the other one 🙂
Not sure there’s an convention around stage naming. I don’t see a lot of dockerfile stuff like this on the broader network. Mostly it seemed clear given the topdown read