I'm trying to figure out exactly what code is being called on the other side of this bluetooth/bluez btattach call using strace. While I'm pretty sure I have guessed the code that is handling it from context, I'd like to still understand the parts that go into this.
Command am running:
sudo strace btattach -P bcm -B hci_pty2
Getting Bumble - Python Bluetooth Stack going on Mac and Linux with QEMU + UTM
I tried to follow the example here: (https://github.com/google/bumble/blob/main/examples/README.md#running-run_controllerpy-with-a-bluez-host-running-on-linux) but it may need updating to change the order of running stuff and some of the params to the example file (or I need to read it more carefully).
Anyway, I had a freshly installed QEMU based VM running Debian Bookworm - got this started via the UTM app which was new to me and handy for this quick hack. Also useful for quick hacks, I used the default networking offerd by the UTM inteface (host networking or whatever it is called) to avoid having to deal with ports and routing. Installed a few bits, most relevantly bluez and socat.
On my host machine (mac) I cloned the Bumble repo, venv-ed, pipped and so on so I c
| # Copyright 2021-2022 Google LLC | |
| # | |
| # Licensed under the Apache License, Version 2.0 (the "License"); | |
| # you may not use this file except in compliance with the License. | |
| # You may obtain a copy of the License at | |
| # | |
| # https://www.apache.org/licenses/LICENSE-2.0 | |
| # | |
| # Unless required by applicable law or agreed to in writing, software | |
| # distributed under the License is distributed on an "AS IS" BASIS, |
| public void ThisIsAnOldMethod() | |
| { | |
| // carry on with remaining functions | |
| var testedCode = new TestedCode(parameter1, parameter2); | |
| testedCode.DoTheNewThingWeTested(); | |
| // carry on with remaining functions | |
| } |
| find ~/ -name 'package.json' | xargs jq -sr '.[].scripts | keys[]' | sort | uniq |
| (defmacro dbg[x] `(let [x# ~x] (println '~x "=" x#) x#)) |
| java.lang.Exception: Kablammo | |
| at cheese_factory.mozarella$load_cheese_by_id.invoke (NO_SOURCE_FILE:1) | |
| clojure.core$map$fn__4207.invoke (core.clj:2485) | |
| clojure.lang.LazySeq.sval (LazySeq.java:42) | |
| clojure.lang.LazySeq.seq (LazySeq.java:60) | |
| clojure.lang.RT.seq (RT.java:484) | |
| clojure.core$seq.invoke (core.clj:133) | |
| clojure.core$map$fn__4207.invoke (core.clj:2479) | |
| clojure.lang.LazySeq.sval (LazySeq.java:42) | |
| clojure.lang.LazySeq.seq (LazySeq.java:60) |
| (defn make-cheese | |
| [name | |
| region | |
| country | |
| aoc? | |
| pdo? | |
| doc? | |
| milk-origin | |
| milk-origin-subspecies | |
| pastuerized? |
| puts ["ass", "write", "mouth", "check", "cash"].permutation(5).to_a.shuffle.map {|words| "Your #{words[0]} is #{words[1]}ing #{words[2]}s that your #{words[3]} can't #{words[4]}!".gsub(/writeing/, "writing").gsub(/asss/, "asses")} |
I am writing some bootstrapping scripts to manage downloading a bunch of data from s3, creating a postgres db, dumping the data into it. Dependencies are on s3cmd and postgres being available from your local package manager.
The idea behind these scripts is largely to guide someone new to the project in setting up their machine with the right data in the right location. Where they need to get access keys and other credentials (from me by magic secure pixie delivery, not in source control), I want them to know what they need and where to plug these things into the script where possible. It's about getting a smart person up and running quickly, avoiding many manual steps etc. I don't need to go full, all-out puppet - happy to make the script stop with a message "Now go and install foreman".
The fact I am concerned with databases etc. is more to do with the nature of our current project. It's a technique I have used/seen used in the past to set up AWS permissions, local dev servers and the like. I originally s