IRC logs for #openttd on OFTC at 2018-12-16
⏴ go to previous day
00:49:54 *** sla_ro|master has joined #openttd
00:55:59 *** sla_ro|master2 has quit IRC
02:07:59 *** Thedarkb1-T60 has joined #openttd
06:42:59 *** chomwitt has joined #openttd
08:42:23 *** Wacko1976 has joined #openttd
09:29:58 *** sla_ro|master has joined #openttd
10:40:38 *** TrueBrain has joined #openttd
10:58:34 *** Progman has joined #openttd
11:07:12 *** frosch123 has joined #openttd
13:28:01 *** jjavaholic has joined #openttd
13:31:53 *** Thedarkb1-T60 has joined #openttd
13:40:58 <nielsm> (is that accessible without login?)
13:43:23 <nielsm> is all the configuration made
13:43:37 <nielsm> well, and then a support repos with the static dependencies
13:55:41 <nielsm> and as far as I can tell it's possible to configure it so only the master branch has builds published automatically, while other branches/PRs need manual approval for each build
14:00:17 *** Wacko1976 has joined #openttd
14:00:26 <nielsm> let's see if I can make it pack things up too
14:03:28 <LordAro> where's a TrueBrain when you want one?
14:07:53 <dihedral> slap him - perhaps that triggers him :-P
14:16:48 *** dih is now known as dihedral
14:23:06 <nielsm> took me a while to realize that...
14:23:29 <nielsm> the @1 is the version of the task code to use
14:51:48 *** Thedarkb1-T60 has joined #openttd
14:54:07 <nielsm> now there is an Artifacts button in the top right and you can download it!!!
15:03:30 *** andythenorth has joined #openttd
15:45:14 *** andythenorth has joined #openttd
15:46:04 <nielsm> it works (both win32 and win64)
15:46:14 <nielsm> but it's missing the branch name for whatever reason
16:07:01 *** wodencafe has joined #openttd
16:38:42 <nielsm> also got a linux build working on azure now
16:39:12 <nielsm> not trying mac right away, because of dependencies
16:39:32 <nielsm> (not sure if liblzma etc are available)
16:45:56 <nielsm> ah, they do have homebrew installed on the macos images, so could fetch any extra libs via that
16:46:16 *** sla_ro|master has joined #openttd
16:46:46 <TrueBrain> nielsm: w00p, your pipeline makes the 4th pipeline "language" we have now for OpenTTD :D
16:46:56 <TrueBrain> I tried GCP and AWS .. didnt try Azure yet :P
16:47:04 <TrueBrain> they should unify their language tbfh :)
16:47:15 <nielsm> and lose any competitive advantage? :D
16:47:24 <TrueBrain> and I see you found out why I was asking to make OpenTTD work with vspkg instead of openttd-useful :P
16:47:45 <TrueBrain> dammit, I keep typing that wrong :P
16:48:00 <nielsm> yes it's a bit clunky to fetch dependencies like that, but not directly painful
16:48:05 <TrueBrain> it is the main reason why I like containers btw .. they define one way for all the pipelines how to compile
16:48:08 <TrueBrain> the pipelines just link it together
16:48:45 <TrueBrain> btw, how many Azure credits do you have? :P
16:48:59 <nielsm> since it's a public project
16:49:06 <TrueBrain> Azure does something with that?
16:49:17 <TrueBrain> (like said, I tried GCP and AWS .. it turns out to be crazy expensive to run OpenTTD there :P)
16:49:45 <TrueBrain> okay .. that is interesting
16:50:01 <TrueBrain> can they run containers? :D
16:50:25 <TrueBrain> GitHub should hurry up with their pipelines .. they can just copy/paste from Azure now!
16:51:13 <TrueBrain> that is seriously interesting
16:51:26 <nielsm> you can run containers on their linux offer
16:51:53 <nielsm> but if you want a custom/persistent machine you need to pay for the VM
16:52:03 <nielsm> it's only on-demand fresh machines you can build on for free
16:52:09 <TrueBrain> the containers are just meant as a reproducable way of compiling
16:52:26 <TrueBrain> (and to be able to targets all kinds of different Linux versions)
16:52:29 <nielsm> yeah these linux and windows builds are made on a fresh VM each time
16:53:08 <nielsm> but they only have ubuntu 16.04
16:53:34 <TrueBrain> I am a bit lost in your information here :) Can you run containers in the free open source thingy?
16:53:58 <nielsm> afaik you can, but you'd have to download the container to the free machine on every job
16:54:24 <TrueBrain> that is what happen son most, so that is not a real issue
16:54:51 <nielsm> otherwise you can have their pipeline kick off a job on a remote machine you manage yourself
16:55:06 <TrueBrain> that is not really solving anything :)
16:55:11 <TrueBrain> we can already do that :P In fact .. we do :)
16:55:21 <TrueBrain> that is just adding indirection :D
16:56:10 <TrueBrain> docker is even installed on their hosted ubuntu pool
16:56:56 <TrueBrain> even Windows Containers?! :o
16:58:41 <TrueBrain> native MacOS would for sure improve quality of the binary :)
17:00:30 <TrueBrain> guess it is fine to do MacOS and Windows natively, and run Linux in containers.
17:00:33 *** Wormnest has joined #openttd
17:00:34 <TrueBrain> nice find nielsm :D
17:00:54 <TrueBrain> kinda gave up on clouds after GCP and AWS :P I shouldn't have :D
17:00:58 <nielsm> daily builds and PR builds should maybe upload to our own server, and PR builds are then placed in a hold until manually released for DL
17:01:39 <TrueBrain> I think it should be a bit more complex; I wrote a bit about that a while ago in a hack.md link
17:01:58 <TrueBrain> but we can do both releases and CI with this, I assume?
17:02:19 * peter1138 looks briefly... looks promising.
17:03:12 <nielsm> another possibility for the (windows) dependencies would be to put the sources for them in a repos, make a CI pipeline for that, which publishes the libs and headers as a bild artifact, that can then be consumed later
17:03:28 <TrueBrain> nielsm: why not vcpkg?
17:03:44 <nielsm> if it has everything :)
17:03:58 <nielsm> I have zero experience using it
17:04:05 <nielsm> that's why I didn't try
17:04:23 <TrueBrain> in release-windows-msvc/Dockerfile
17:04:31 <TrueBrain> I install vcpkg, and install the packages we use
17:04:37 <TrueBrain> (used .. ICU is still in there)
17:04:58 <TrueBrain> except that I needed to fix a lot of paths because .... openttd-useful is weird
17:06:41 <TrueBrain> okay, ironicly, their Windows image doesn't have vcpkg installed :D
17:07:49 <TrueBrain> okay, using Windows Containers is not difficult too, if I understand this correctly
17:09:20 <TrueBrain> that is what I suggest how we trigger builds etc
17:09:37 <TrueBrain> most important ones are the first (PR validation) and last (Tags)
17:09:40 <TrueBrain> the other two are nice-to-have
17:16:38 <TrueBrain> very cool nielsm :D This might just solve a huge resource issue :P
17:16:40 <nielsm> what's the threat model for limiting exposure of initial check, and what is it for preventing builds of a PR until whitelist?
17:17:02 <TrueBrain> nielsm: sorry? I dont understand either question :(
17:17:04 <nielsm> (I see the threat model for not publishing builds of unreviewed code)
17:17:25 <nielsm> what are you meaning to defend against
17:17:39 <TrueBrain> "initial check", I dont get what you meant there :)
17:17:56 <nielsm> initial check = PR validation
17:18:16 <TrueBrain> ah; so that part only tells if it was okay yes/no, and logs
17:18:20 <TrueBrain> but no binaries etc
17:18:25 <TrueBrain> because the PR is considered untrusted
17:18:30 <TrueBrain> exactly what the reason you just mentioned :)
17:18:36 <nielsm> yes what is the threat?
17:18:45 <nielsm> what can an attacker do with code execution at that step?
17:18:52 <TrueBrain> exactly that; people creating PRs which remove OpenTTD and introduce their own "code"
17:19:06 <TrueBrain> it is about not publishing the binaries
17:19:27 <TrueBrain> so .. the risk is that someone donwloads the binaries, and execute it .. that part is obvious, so I am not sure I get your question :D
17:19:46 <TrueBrain> how I see it: new PR == untrusted code
17:19:54 <TrueBrain> so we run our CI over it, show the logs + exit code
17:20:00 <TrueBrain> no binaries to download, nothing
17:20:14 <TrueBrain> if someone marks the PR as "trusted", binaries can be created
17:20:21 <nielsm> yes that's why I suggest the simple mitigation of, put created binaries in a hold, for manual release by a truested person once the PR has been reviewed
17:20:40 <TrueBrain> the fact that you make the binaries available, means people can fuck up :)
17:20:48 <TrueBrain> never give the illusion those binaries are "trusted"
17:20:50 <TrueBrain> so never produce them :)
17:21:01 <TrueBrain> a failsafe, so to say :)
17:21:34 <TrueBrain> (as that "hold" will be on azure, which most likely published the binaries in some form .. :D)
17:22:02 <TrueBrain> from a security perspective: handle your untrusted code as untrusted. Not as some hybrid form
17:22:18 <nielsm> nah that's why I suggest not using the "publish artifact" step of azure since that does in fact publish it
17:22:36 <nielsm> and instead upload it to a private location
17:22:48 <TrueBrain> but that does mean the binaries do exiist :)
17:22:51 <TrueBrain> which is exactly my point :)
17:23:15 <TrueBrain> the only "downside" with my approach, that you compile the same code twice once per PR you want to preview
17:23:32 <TrueBrain> added bonus is that you dont need a secure private location with big markers: UNTRUSTED CODE :)
17:23:56 <TrueBrain> or am I missing your point?
17:24:40 *** gelignite has joined #openttd
17:25:11 *** Thedarkb1-T60 has joined #openttd
17:25:21 <LordAro> untrusted surely only really matters with your own infrastructure
17:25:32 <LordAro> using something like azure surely pushes that onto MS
17:25:43 <TrueBrain> only the building; we talk here about the resulting binary
17:25:56 <TrueBrain> the building itself is a different story (with different countermeasures)
17:26:11 <LordAro> oh, actually publishing artefacts for PRs? interesting
17:26:52 <TrueBrain> nielsm: guess my main reasoning is: the easier we keep the processing of "untrusted" code, the less mistakes will be made
17:27:44 <LordAro> make PR binaries private unless dev or dev approved?
17:27:59 <TrueBrain> that is what nielsm says, yes; thank you for catching up :P
17:28:09 *** ChanServ sets mode: +v tokai
17:28:12 <nielsm> a release hold for unverified PR artifacts is as secure as the people with access to it, and anyone with access to it could just as well be pulling the code to their own machine and building without verifying it first
17:28:39 <TrueBrain> it does require infrastructure to store those untrusted artifacts
17:28:43 <TrueBrain> make a mechanism to publish them
17:28:44 <LordAro> alternatively, are PR artefacts actually desirable?
17:29:05 <TrueBrain> (honest question btw)
17:29:31 <TrueBrain> for me it is easier to look at it like: 1 pipeline for untrusted code, never any binaries, never any worries
17:29:40 <TrueBrain> 1 pipeline for trusted code, which has binaries it publishes
17:30:17 <nielsm> there is a manual intervention step too, maybe that could be used to "pause" builds until someone manually resumes it
17:30:32 <TrueBrain> what is the gain? :)
17:30:45 <TrueBrain> also I assumed 90% of the PRs never get a preview btw
17:31:15 <TrueBrain> but why not just trigger a second pipeline? Isnt that a lot easier?
17:32:36 <TrueBrain> I hope we can build something that can be maintained easily for the next 10 years by as many people as possible
17:32:55 <TrueBrain> which mostly means removing the "security" part from the equation, and making sure it cannot go wrong to start with :)
17:33:16 <TrueBrain> (I have to add: I am working for an IT Security firm now for 4 years .. I am a bit paranoid :D Mostly because I have seen shit :P)
17:34:02 <TrueBrain> either way, I think we are overthinking it a bit at this moment in time :) Possibly we should first aim to having a CI, and being able to build tags :)
17:34:11 <Xaroth> I don't think you're being paranoid about it tbh
17:34:13 <TrueBrain> also for patchpacks :)
17:34:30 <Xaroth> 2 pipelines sounds like common sense
17:34:50 <TrueBrain> it is not so much related to "common sense". These are just choices you have to make
17:35:00 <TrueBrain> one isn't better than the other as much as they solve different needws
17:35:18 <nielsm> you can use the same pipeline but make the archive+publish steps dependent on Build.Reason != 'PullRequest'
17:37:15 <TrueBrain> nielsm: for example. Still 2 pipelines in the logic sense :) How we solve it technically .. all sounds good :)
17:37:34 <TrueBrain> I do wonder if we can take over the triggering of the build on Azure
17:37:48 <nielsm> azure can do time-based triggers yes
17:38:00 <TrueBrain> I was more looking for manual triggers
17:38:08 <TrueBrain> but I can imagine they dont allow that
17:38:10 <nielsm> there's also manual triggering
17:38:22 <TrueBrain> really? Cool .. can you also add variables to the triggering part?
17:38:43 <TrueBrain> as what I am thinking: basically, if a developer is whitelisted, his PR can be in preview immediatly. but we need something that does this whitelisting
17:38:48 <andythenorth> trying to prevent poisoned binaries by design is *not* tinfoil :P
17:39:04 <TrueBrain> nielsm: now that is interseting :D
17:39:06 <andythenorth> (hello coin miners)
17:39:27 <TrueBrain> nielsm: as if, for example, DorpsGek_II can trigger the builds, instead of azure "sensing" it
17:39:35 <TrueBrain> we can do cool tricks :)
17:40:49 <TrueBrain> owh, we are going to have so much fun with this :D
17:40:58 <TrueBrain> also means we can speed up CIs drasticly
17:41:08 <TrueBrain> as in: run all the builds at once
17:41:23 <TrueBrain> also means we can finally do the full matrix of compilers (to run once in a while)
17:41:40 <TrueBrain> I wonder if there is a fair use :P
17:41:43 <nielsm> the free tier on azure has up to 10 concurrent jobs
17:42:17 <nielsm> a job is forcibly killed after 6 hours
17:42:29 <TrueBrain> 6 hours?! that is a shitlong time
17:42:47 <TrueBrain> too bad GitHub Actions is still in beta
17:42:53 <TrueBrain> that too introduces pipelines
17:42:59 <TrueBrain> toooooo many pipeline systems
17:43:32 <TrueBrain> well, if you can nielsm, please do try the MacOS :D Would be nice to know if that "just works"
17:43:58 <TrueBrain> in the OpenTTD-CF are instructions how to install it, if you need any assistance
17:44:05 <TrueBrain> there too I believe ICU was removed, not sure :)
17:46:20 <nielsm> just trying a straight build no extra deps here
17:46:49 <TrueBrain> we dont have many deps :)
17:46:56 <andythenorth> ha we can watch it :)
17:46:59 <andythenorth> like modern jenkins
17:47:13 *** synchris has joined #openttd
17:47:39 <TrueBrain> I like how everything runs twice :P
17:48:16 <TrueBrain> once via your branch, once via your PR :P
17:48:24 <nielsm> huh, didn't even notice that
17:48:53 <nielsm> I should close the PR really
17:48:54 <TrueBrain> andythenorth: yeah, the live part is very nice
17:49:04 <nielsm> it was just one azure forced on me
17:49:17 <TrueBrain> if this works, it means we can really move to k8s .. as we than really have no use of a dedicated machine anymore
17:49:21 <TrueBrain> that makes me really happy
17:51:04 <TrueBrain> the Digitalocean CDN also seems very solid
17:51:10 <TrueBrain> means we can remove our own mirror network
17:51:18 *** sla_ro|master2 has joined #openttd
17:51:45 <TrueBrain> lol: D:\a\1\s\projects :D That folder :D
17:51:59 *** sla_ro|master2 has quit IRC
17:52:36 <nielsm> the mac build host is fast!
17:52:47 <TrueBrain> it really appears to be a native machine
17:53:12 <nielsm> ./configure --without-liblzma --without-liblzo2 --without-png
17:53:33 <nielsm> if anyone can look up the brew commandline to install those deps I'll add them :P
17:53:42 <TrueBrain> macports installed too?
17:53:51 <nielsm> nope, homebrew but not macports
17:53:59 <TrueBrain> you only 'difficult' part is that you want them 'static'
17:54:20 <nielsm> yeah dylibs are annoying
17:54:35 <TrueBrain> same reason we do static windows builds
17:54:54 <nielsm> many years ago I wrote some scripts for packaging and rejiggering dylibs install_path or whatever they're called for aegisub on mac
17:55:39 <TrueBrain> hmm .. I wonder how difficult integration with GitHub is for warnings/errors
17:55:44 <TrueBrain> you can show these on GitHub inline these days
17:56:06 <TrueBrain> you would think Azure can do this now, given GitHub is owned by the same company :P
17:56:43 <TrueBrain> it does report back to GitHub at least
17:57:21 <nielsm> I should also try making it package and publish the mac build artifact
17:57:32 <TrueBrain> means andythenorth can test it for you :P
17:57:54 <LordAro> our single macos user :p
17:58:06 <TrueBrain> they dont have docker on their MacOS agents
17:58:34 <nielsm> ms writes somewhere their mac builds are hosted on an external partner in the US, instead of on their own datacenters
17:58:59 <nielsm> I wonder if it's that hosting company that custom designed racks for mac mini and trashcan machines
17:59:33 <TrueBrain> that wouldn't surprise me
17:59:51 <TrueBrain> but this is seriously awesome
17:59:59 <TrueBrain> osxcross "works", but native builds are always better
18:00:57 <TrueBrain> configure didnt pick up on that :o
18:02:19 <TrueBrain> right, next week two weeks to get this linked to our current infrastructure I guess
18:02:23 <TrueBrain> I also want to get the new website live
18:02:29 <TrueBrain> still waiting for LordAro to make his gist into a PR
18:02:43 <TrueBrain> (also still waiting for his feedback on the hackmd, but not sure that will ever happen :D )
18:03:05 <LordAro> still got the tab open :p
18:03:43 <nielsm> anyone want to set up an official ottd org with azure? :)
18:03:44 <TrueBrain> yeah, if we can get CI in a decent shape and get the website live on DigitalOcean, that would be a nice win tbh :)
18:03:57 <TrueBrain> nielsm: next week, sure :P
18:04:33 <TrueBrain> at least, I assume your current setup works fine for this testing etc?
18:04:48 *** sla_ro|master has joined #openttd
18:05:25 <nielsm> eh I suppose half or more of this proof of concept needs to be replaced
18:05:42 <TrueBrain> if possible, I would love the Windows and Linux to be via docker
18:05:48 <TrueBrain> as that means more people can locally test it
18:05:52 <LordAro> mm, all them deprecation warnings for the objc
18:05:53 <TrueBrain> instead of having to do it via PRs :D
18:05:54 <nielsm> are windows deps handled as a binary bundle or with vcpkg?
18:06:17 <TrueBrain> yes, food! Good idea :D
18:06:27 <TrueBrain> again, awesome work nielsm :) Makes me really happy :D
18:07:10 <TrueBrain> (and as you might have noticed, I tried to move as much complexity as possible away from us .. like doing our own libaries is silly these days .. we should work on OpenTTD .. not on updating zlib dependency :D)
18:07:41 <TrueBrain> same reason we should really look into cmake :D
18:08:09 <LordAro> TrueBrain: i'll probably put some more work into cmake over christmas
18:19:56 <LordAro> TrueBrain: can't seem to make any comments on the doc itself, so:- No specific concerns, other than it'd probably be a good idea to have a specific mention of being able to manually upload binary releases (for the more obscure OSes OS/2, Linux deb/rpm/etc, etc etc) that won't ever be built via CI. Other than that is all implementation details, like making the generic Linux builder as old as "feasible",
18:20:02 <LordAro> for libc compatibility. And I imagine several things in the doc about implementation could be (about to be) out of date, wrt pipeslines. Charts sound interesting, think I want to look into them in more detail generally
18:34:55 <nielsm> re. using containers for build on windows, I guess my reservation is that I don't know how large a ready to use windows container image is, if you need to transfer multiple gigabytes to the build host before the actual build can start it sounds like a bad approach
18:43:26 *** sla_ro|master has joined #openttd
19:06:01 *** Progman has joined #openttd
19:29:05 *** Wacko1976_ has joined #openttd
19:56:13 *** jjavaholic has joined #openttd
19:59:13 <nielsm> this macos environment is annoying...
20:00:22 <nielsm> but also, if configure does not find zlib it just says "not found" but doesn't yell like it does with lzma
20:01:24 <nielsm> strange thing is that the homebrew xz package is installed, which does include liblzma2.dylib and liblzma2.a, as well as the headers
20:01:42 <nielsm> and macos should have a system zlib that's usable
20:01:54 <nielsm> it also won't detect the libpng I'm installing via homebrew
20:02:18 <nielsm> but the really bad thing is I can't inspect the environment to see where the files it wants actually are
20:02:49 <nielsm> (maybe I should instrument the build to produce some artifacts listing files etc)
20:04:23 <andythenorth> is it full shell access to macos?
20:04:29 <andythenorth> or some crippled interface?
20:04:50 <nielsm> I don't have login access
20:05:09 <nielsm> it just runs the jobs specified, through the build agent
20:05:49 <andythenorth> yeah, so instrumenting the build :|
20:06:46 <nielsm> ls -lR /usr > allthefiles.txt
20:07:03 <andythenorth> pkgutil might do something
20:07:14 <andythenorth> I usually play guessing games with brew though
20:09:54 <TrueBrain> nielsm: re: windows containers, they are deltas on top of eachother. The windows container host already has a few build in. So that should be fine. but we can test how bad it is :D
20:10:54 <TrueBrain> LordAro: ack and tnx :)
20:13:01 <nielsm> the brew install step takes forever because it also does a self update
20:15:13 <nielsm> TrueBrain: ah right, if you make the docker image build (compose?) step also run on azure ci and produce a build env artifact you can then import that artifact into actual builds
20:51:46 <nielsm> okay, zlib detection fails because apple probably doesn't provide a .pc file for it, and homebrew doesn't install it in a default search path (to not clash with the system version)
21:03:00 <TrueBrain> nielsm: that would be an anti-pattern (to use an artifact as docker image) :P But Azure has its own registry, and most likely the image is pretty small .. it is most likely faster than fetching openttd-useful even :P
21:03:04 <TrueBrain> but again .. something we can simply try :D
21:03:32 <TrueBrain> and it is a nice-to-have, so meh
21:04:53 <nielsm> I got my allfiles.txt so trying to construct a configure cmdline to just ignore pkg-config statically link the various compression libs
21:05:12 <TrueBrain> or just tickle andythenorth to fix it :P
21:05:38 <andythenorth> LordAro offers fixes-as-a-service ;P
21:05:38 <nielsm> is libpng and libpng16 the same thing....?
21:06:03 <TrueBrain> nielsm: they MIGHT be the same
21:06:09 <TrueBrain> libpng changed their API
21:06:19 <TrueBrain> libpng12 != libpng16
21:06:22 <TrueBrain> libpng .. is either of the two :P
21:06:39 <andythenorth> "The "master" branch is roughly equivalent to the "libpng16" branch. Development occurs in the "libpng16" and "libpng17" branches; "
21:09:13 <nielsm> ./configure --with-zlib --with-lzma --with-lzo2 --with-png INCLUDE=/usr/local/include "LIBS=-lz /usr/local/lib/liblzma.a /usr/local/lib/liblzo2.a /usr/local/lib/libpng.a"
21:09:17 <nielsm> does that look sensible?
21:10:18 <LordAro> is all that necessary?
21:10:49 <nielsm> it seems I have to force detection around pkg-config, and may as well static link then
21:11:22 <LordAro> i'd be surprised if INCLUDE is doing anything
21:11:29 <LordAro> and i'd do LIBS="blah blah"
21:11:45 <TrueBrain> and INCLUDE and LIBS before configure :)
21:11:55 <TrueBrain> but /usr/local, so I guess pkgconfig is just not in the place it is looking for?
21:12:31 <LordAro> "INCLUDE" and "LIBS" appear nowhere in configure/config.lib, i don't think those are the right variables...
21:12:50 <TrueBrain> what -should- work, or used to: --with-png=/usr/local/lib/libpng.a
21:12:55 <TrueBrain> but .. no clue if that still is the case :P
21:12:58 <TrueBrain> we are not helpful :(
21:13:02 <LordAro> i was wondering that, too
21:13:21 <LordAro> ideally of course, pkg-config would work
21:13:28 <TrueBrain> possibly something like: --with-pkgconfig=/usr/local/bin/pkg-config or something similar might work
21:13:31 <TrueBrain> no clue what exactly
21:13:33 <nielsm> I tried reading config.lib but couldn't figure out what --with-somelib=whatever actually does with whatever
21:13:34 <TrueBrain> I might have made typos :D
21:14:02 <TrueBrain> but LordAro knows more about this stuff these days :P
21:14:07 * andythenorth wonders what macos environment it is :P
21:14:11 <andythenorth> and why it's so arcane
21:14:27 <TrueBrain> it seems homebrew is just installed in /usr/local
21:14:31 <TrueBrain> what I would expect him to do tbh
21:15:00 <TrueBrain> brew install pkg-config at least exists
21:15:17 <LordAro> oh, LIBS & INCLUDE do appear in config.lib, dunno what i was talking about earlier
21:15:50 <nielsm> 2018-12-16T20:14:09.2010180Z configure: error: pkg-config zlib couldn't be found
21:15:51 <nielsm> 2018-12-16T20:14:09.2015590Z configure: error: you supplied '2', but it seems invalid
21:16:07 <TrueBrain> yeah .. '2' means you gave the exact location
21:16:34 <TrueBrain> so it basically says: cannot find the location you told me to look, or I didnt understand it
21:17:06 <LordAro> by the looks of config.lib, zlib detection is done via pkg-config, which means the --with-zlib=<foo> is used as the pkg config call
21:17:14 <TrueBrain> but okay, the other stuff I was talking about was just me blindly guessing .. not sure that is helping :) So I will leave it to others :P
21:17:33 <TrueBrain> config.lib has been ..... "altered" over the years :D
21:17:46 <TrueBrain> *cough* cmake *cough* :D
21:18:06 <glx> as long as it's not autoconf ;)
21:18:23 <LordAro> detect_zlib calls detect_pkg_config. detect_library is the function that uses $1 as a file
21:18:53 <LordAro> but only lzo2 & fluidsynth use that now
21:24:29 <nielsm> hmm, homebrew does provide a zlib.pc file but it doesn't seem to be installed
21:24:46 <nielsm> (one that points at the system libz that is)
21:33:22 <nielsm> hm nope, just specifying PKG_CONFIG_PATH is not good enough, it seems
22:38:51 <andythenorth> so what's the fashionable way to do powered wagons in newgrf now?
22:56:31 <andythenorth> implementation wise
22:57:14 <andythenorth> this is for TGV-type trains
23:02:59 <nielsm> overall I prefer realistic-ish fixed length multiple units, then it doesn't really matter where you place the power (and can ignore whether you have power on one or both end cars, or some or all axles)
23:07:00 *** andythenorth is now known as Guest309
23:07:10 *** andythenorth has joined #openttd
23:12:05 <andythenorth> I tried building them in 16/8 units
23:12:05 <andythenorth> but it's a bit fiddly to build in depot, they have to be dragged to make the consist
23:12:05 <andythenorth> wagons automatically are added
23:16:30 *** andythenorth has left #openttd
continue to next day ⏵
