<ldlework> johnw this is where I got it to, home.activation.viscosity = pkgs.hmpkgs.linkApplication { appName = "Viscosity.app"; };
<johnw> home.activation?
<ldlework> Yeah home-manager activation scripts
<johnw> ah
<ldlework> So with this, there's "user local" OSX app support 🤷‍♂️
<johnw> i won't be free to think about this until Friday
<ldlework> No worries.
zzamboni has joined #nix-darwin
<ldlework> Has anyone here successfully installed Hipchat on OSX?
<ldlework> With Nix I mean
zzamboni has quit [Remote host closed the connection]
zzamboni has joined #nix-darwin
zzamboni has quit [Quit: Leaving.]
zzamboni has joined #nix-darwin
angerman has quit []
angerman has joined #nix-darwin
zzamboni has quit [Quit: Leaving.]
wavewave has quit []
wavewave has joined #nix-darwin
zzamboni has joined #nix-darwin
zzamboni has quit [Quit: Leaving.]
zzamboni has joined #nix-darwin
zzamboni has quit [Quit: Leaving.]
zzamboni has joined #nix-darwin
zzamboni has quit [Quit: Leaving.]
zzamboni has joined #nix-darwin
<copumpkin> not I
<copumpkin> puffnfresh might have some thoughts about packaging that certain company's apps
<LnL> heh
philipcristiano has quit []
philipcristiano has joined #nix-darwin
jtojnar has joined #nix-darwin
savanni has quit []
savanni has joined #nix-darwin
zzamboni has quit [Ping timeout: 255 seconds]
zzamboni has joined #nix-darwin
codedmart has quit []
codedmart has joined #nix-darwin
zzamboni has quit [Quit: Leaving.]
zzamboni has joined #nix-darwin
zzamboni has quit [Ping timeout: 240 seconds]
pjan has quit [Remote host closed the connection]
victorbjelkholm has quit []
victorbjelkholm has joined #nix-darwin
pjan has joined #nix-darwin
<mitchty> i found a gist from him on getting hipchat working in emacs, i'd rather do that than use the 800 megs and constantly swapping electron app >.<
<cransom> what world have i come to where random functionality built into emacs has become more efficient than the dedicated app someone put out.
<cransom> forget the bitcoin miners, how much extra electricity has electron extracted from the planet.
<mitchty> dunno, but its just using jabber to connect to hipchat https://gist.github.com/egh/5f46b5d6d2061f305b46 is an evolved version
<cransom> just poking fun that the joke was emacs used to be the most bloated thing in the world.
<mitchty> heh, i was too, play on the 8/80 megs and constantly swapping acronym emacs got in the 80's/90's
<cransom> heh. your electron app only uses 800megs?
<mitchty> now that i said it, curious how much ram emacs is actually using
<mitchty> i use a pinned tab in safari normaly actually
<mitchty> which is using 723MiB of ram, so i'm close
<mitchty> emacs is at 268, but i use a ton of crap in there including gnus
<cransom> a gig of memory for cat gifs.
<cransom> though that was a couple months ago. i wonder if they did something recently to curb memory usage. it's "down" to 120megs now.
<mitchty> worth it then if its cat gifs
<cransom> oh, but 'slack helper' is using 480.
philr has quit [Ping timeout: 268 seconds]
<puffnfresh> ldlework: I haven't but I'm happy to help
<ldlework> puffnfresh cool, it is unlike other .app's I've seen
<ldlework> It doesn't extract to .pkg or anything
<ldlework> But there are these HFS Private Data Directories that are inside the .app
<ldlework> if I just copy HipChat.app from the .dmg to ~/Applications it doesn't work
<ldlework> Or just extract it manually with undmg or 7z and try to run the .app inside
<ldlework> nothing to do with nix
<ldlework> Its a weird one
<puffnfresh> oh wow
<ldlework> If I mount the image with hdiutil, then I can copy the .app
<ldlework> That works...
<ldlework> but that's crappy to have in your nix build process
<puffnfresh> so mounting works but undmg doesn't
<ldlework> yeah undmg extracts it
ChanServ has quit [shutting down]
<ldlework> But you can't run the result
<ldlework> Maybe something to do with code signing?
ChanServ has joined #nix-darwin
<puffnfresh> yeah looks like undmg doesn't do Apple Data Compression
jtojnar has quit [Ping timeout: 255 seconds]
<puffnfresh> so either compression or signing, I think
ndrei has joined #nix-darwin
<ndrei> Hi, I'm trying to install xcode/xcode command line tools with Nix, is it possible?
chrisbarrett has joined #nix-darwin
<LnL> those are not redistributable
<LnL> but why do you want the CLT we have clang, etc. in the stdenv
<ndrei> LnL: right, sorry, I was expecting something like Homebrew does, perhaps fetching them trough some public URL Apple is providing, but unsurprisingly not
<contrapumpkin> we do actually fetch the command-line SDK inside Nix automatically
<contrapumpkin> but we don't expose the CLT
<LnL> no we don't depend on those
<contrapumpkin> Xcode doesn't have a public URL
<contrapumpkin> as far as I know?
<ndrei> Yeah, sure, I was thinking of the tools
<contrapumpkin> but we went to great lengths to avoid depending on CLT or their headers in our core stdenv
<contrapumpkin> we could still provide the CLT if you really wanted them, but they don't offer much that we don't already
<ndrei> They are required by a build automation tool I'm using (Fastlane)
chrisbarrett has quit [Quit: chrisbarrett]
<contrapumpkin> are they really? or is it just hardcoded to look at certain paths, which then causes the CLT prompt to pop up?
<contrapumpkin> the latter is the more common case
<LnL> yeah, that's probably the case
<LnL> if you call /bin/bin/clang instead of whatever nix provides you'll get a messages about the CLT
<ndrei> I'm thinking of the latter, but I'm just a user, I haven't dug into the source. Well, I actually I'm not sure what's included with the CLT
chrisbarrett has joined #nix-darwin
<LnL> is this the nix package or are you trying to build it yourself?
<ndrei> yes, it's a nix package (fastlane)
<contrapumpkin> oh, the package is probably just broken then
<contrapumpkin> if it requires the CLT
<ndrei> no, it's a runtime dep
<contrapumpkin> what I mean is that packaging it properly would stop that from being a runtime dep
<contrapumpkin> and would handle it in the proper nix way
<ndrei> oh, yeah, sure, if the CLTs are indeed not required perhaps an upstream patch. Altough I'm not sure, the CLTs have some xcode build-related tools perhaps?
<contrapumpkin> not as far as I know. xcodebuild is only included with xcode
<contrapumpkin> afaik, CLT is fully subsumed by our machinery
<contrapumpkin> I had an index of them at some point a few years ago
<contrapumpkin> maybe something has changed
<contrapumpkin> but more likely fastlane is just trying to hit /usr/bin/clang and that causes a CLT propmt
<contrapumpkin> when it could just as easily use any other clang
<contrapumpkin> actually the one tool in CLT that we don't have is dsymutil
<contrapumpkin> but I doubt that really matters in most cases
<LnL> oh runtime, try running it in a nix-shell
<LnL> nix-shell -p stdenv
<ndrei> I've checked the source and comments just say that it's checking that Xcode is installed.. Eh, at any rate, I'm going on with the rest of my build process. I would like this to be fully automated and be able to build the OSX env from scratch, but I'm really pretty far with that so this doesn't bother me that much.
<LnL> \o/
<LnL> what did we want that for again? totally forgot :D
<copumpkin> well, it's the only thing we're technically missing from upstream
<copumpkin> at first I thought the xnu build required it but then I figured out how to build without debug symbols
<copumpkin> generally nice to have especially if nix starts doing debug symbols more generically
<copumpkin> we'd need to figure out how to pair it with what niksnut already does for the linux symbols
<copumpkin> but it'd be nice to generate detached debug symbols everywhere
<LnL> our swift build still doesn't work on darwin :')
<LnL> error: assertion failed at pkgs/development/libraries/glibc/default.nix
<LnL> and clang.cc.gcc
<contrapumpkin> :(
<dtz> swift doesn't work on linux either, atm :(
<dtz> need to bludgeon its clang into submission to Nix
<dtz> lol
<contrapumpkin> is their clang that different?
<contrapumpkin> can we just wrangle it to use our packaged one, rather than reinventing all the shit we had to do for the main one?
<dtz> no, they have some changes --certainly to LLVM and I believe to clang as well
<dtz> biggest problem is that they build it and then use it directly, so our cc-wrapper's aren't part of the picture
<dtz> well lemme rephrase my "no" above, please: I don't think we can and would be happy to be wrong
<dtz> :)
<contrapumpkin> worst case scenario, maybe we can take our current builds and overrideAttrs them to use the swift source trees?
<contrapumpkin> although apple uses weird clang+llvm combo source trees so maybe not
<johnw> contrapumpkin!