00:26 <azonenberg> Yeeeah

00:27 <azonenberg> If anyone tells you the electronics industry is starting to recover

00:27 <azonenberg> they're either clueless or lying :p

03:25 <d1b2> <TiltMeSenpai> yeah it feels like we've gone from "yeah it'll definitely be available in another 50 weeks" to "you know what, we actually made that up, we actually have no clue what's going on"

03:42 <d1b2> <Darius> "Lead time: 50 weeks" definitely seemed like "I'm sure this problem will go away in a whole year"

03:42 <d1b2> <Darius> then "oh shit"

03:51 <d1b2> <TiltMeSenpai> right?

03:57 <d1b2> <Darius> yeah

03:58 <d1b2> <Darius> also, 50 weeks was probably the "lol fuck you we aren't making this right now" value then actually became a realistic number 😦

17:00 <azonenberg> Oh good news re my 4 GHz scope

17:01 <azonenberg> it turns out there was some miscommunication between customer service and the repair dept

17:01 <azonenberg> A different board is bad

17:01 <azonenberg> The board that actually needs replacement is one they have in stock

17:01 <azonenberg> So it should be shipping out next week woo

20:23 <d1b2> <dannas> Oh mama mia. submodules problemos after I tried fetching from upstream to my fork of scopehal-apps. fatal: cannot chdir to '../../../lib': No such file or directory Guess this is the day I will finally learn how git submodules works.

20:23 <d1b2> <dannas> opens git-scm.com's submodules page

20:27 <d1b2> <dannas> Hm, I wonder how git deals with a .gitmodules file that has relative URLs. Maybe I need to fork the submodule repos as well?

20:27 <d1b2> <dannas> reads on

20:27 <Degi> Hmm, there was some option like --recurse-submodules or so

20:31 <d1b2> <dannas> Running git submodule init followed by git submodule udate seems to have fixed the situation. Not quite sure why that was needed. I had run that sequence of commands before. Oh, git is still such a mystery to me after all these years. 🙂

20:37 <sajattack[m]> the magic command I usually use is `git submodule update --init --recursive`

20:39 <d1b2> <dannas> continues reading the docs

20:41 <d1b2> <dannas> I thought you only had to do that after a clone and that the submodules would automatically be checked out when you do later switch or checkouts.

20:45 <d1b2> <dannas> The docs seems to say that you only need to run git submodule update after pulling upstream changes when the submodules has changed. Which makes sense. And git status is supposed to tell me when the submodules has changed. So I'll treat my problem today as me messing something up and not remembering about it. Henceforth I'll just pull/fetch from Andrews repo and do a git submodule update if git status tells me it's needed.

21:20 <sajattack[m]> `git submodule update --init` is `git submodule init` and `git submodule update` in one command, and the recursive flag makes sure submodules of submodules are updated as well

21:37 <azonenberg> dannas: yes, you need to fork all of the submodules

21:37 <azonenberg> if we use relative paths

21:37 <azonenberg> This is annoying, but the alternative is to put absolute urls in .gitmodules

21:37 <azonenberg> which makes both forking and cloning annoying since i need to use a ssh url to push, but non-committers normally clone via https

21:37 <azonenberg> and if you fork the url of the submodule changes

21:38 <azonenberg> The least sucky option i've found is to simply say if you fork one repo, you have to fork all of the dependencies too

21:38 <azonenberg> even if you dont plan to change them

21:38 <azonenberg> and keeping those in sync with upstream is on you