02:02 <koobs> tardyp: have no had a report on python function support for any of my python ports

02:02 <koobs> tardyp: i run buildbots for Cpython upstream, so

02:03 <koobs> "using shell=True only on os.name==nt."

02:03 <koobs> that means also an issue on other !windows !freebsd os's ?

05:51 <tardyp> koobs: its more that in bsd, /bin/sh is not bash, and if you do sh -c yarn --version

05:52 <koobs> tardyp: does upstream python set a default shell

05:52 <tardyp> it will exit 1, because it tries to parse the option --version

05:52 <koobs> or is this the responsibility of the consumer?

05:52 <tardyp> its always /bin/sh

05:52 <koobs> im confused

05:52 <tardyp> so it is not really bsd's issue, but rather a bug on our side, which is not visible on bash systems

05:53 <koobs> report is subprocess.popen shell-=true ""does not work properly on FreeBSD 13"

05:53 <koobs> if its always /bin/sh why doesnt it work?

05:53 <koobs> oh right

05:53 <koobs> your calls assume bash

05:53 <koobs> ?

05:53 <tardyp> yes

05:53 <koobs> and you "need bash" ?

05:53 <koobs> or, you just want to call a shell

05:53 <tardyp> we don't need bash, but we don't see the bug with bash

05:53 <koobs> ok sweet

05:53 <koobs> can you call sh on freebsd?

05:53 <koobs> whats the 'design' you want?

05:54 <koobs> i mean its merged, but yeh

05:54 <koobs> what are the benefits to shell=true ?

05:54 <koobs> for buildbot

05:54 <koobs> vs not

05:54 <koobs> or is this just a case of, we found a bug, becaus eyou assumed bash, and we didnt have it, and excluding shell=true for everything !nt is "correct"

05:54 <koobs> and its only needed for nt ?

05:56 <tardyp> we do shell=True for windows specifically

05:56 <tardyp> because only shell=True uses $PATH on windows to find yarn

05:56 <koobs> ahh sweet

05:57 <koobs> tldr; portability bug fix identified by heterogeneous environments? :D

05:57 <koobs> \o/

05:57 <tardyp> windows implementation automatically joins the list in POpen, but it is not the case for posix

05:57 <tardyp> right

05:57 <koobs> tardyp: but yeh, dont think there's been a report on that

05:57 <koobs> thanks for the heads up

05:57 <koobs> and we do run the test suite for BB

05:57 <koobs> so

05:57 <koobs> its intertesting

07:19 <tardyp> koobs: you know if there is a way to change /bin/sh to /bin/bash or /bin/dash like in ubuntu?

07:21 <tardyp> cause we still dont know why it suddently failed at our freebsd 13 upgrade

20:43 <immae> Hello! I’m trying to understand the naming conventions in buildbot, and in particular about Workers: I’m currently defining a new type of (Latent) Worker, and I need to know if from buildbot PoV a Worker can only run one build at a time or not: if my Latent Worker is able to manager sevral jobs concurrently, do I have to register several instances of it in the master or is one sufficient?

20:44 <immae> (I’m reading the code to try to figure out the answer to the question but I cannot reach a definitive conclusion)

20:46 <skelly> tardyp: no, /bin/sh is ash on FreeBSD and is part of the base system

20:48 <dol-sen> immae, one job per builder at a time

20:48 <dol-sen> a worker can run multiple builders/jobs provided it has the resources available

20:48 <immae> dol-sen: builder or worker ?

20:48 <immae> ok

20:48 <dol-sen> one job per builder

20:49 <immae> so one job per builder, and you attach a builder to worker (which can handle as many as it wants)

20:49 <immae> right?

20:49 <dol-sen> pretty much yes

20:49 <immae> ok

20:49 <immae> Thanks for the clarification!

20:50 <dol-sen> if you need a certain builder to handle many parrallel jobs, deploy more workers

20:51 <dol-sen> the nmaster will pass the job to the next available worker

20:51 <immae> ok noted

20:52 <immae> Is there a place in the doc that describes this kind of architecture?

20:52 <immae> Or is it just "being used to it"?

20:57 <dol-sen> I think I just got used to it

21:01 <immae> ok

21:01 <dol-sen> http://docs.buildbot.net/current/manual/configuration/workers.html

21:02 <dol-sen> Note

21:02 <dol-sen> In Worker For Builders concept only one build from the same builder would run on the worker.

21:03 <dol-sen> if your hardware is capable of multiple jobs at the same time, you can deploy more workers on that hardware to handle multiple jobs

21:06 <immae> ah ok I understood the reverse :D

21:06 <immae> Good to know, thanks for the pointer :)

21:07 <immae> ah yes the link is very complete, that’s the doc I was looking for, thanks again!

21:18 <dol-sen> so one worker can handle multiple "DIFFERENT" builders in parallel, but only one build per builder at the same time

21:24 <immae> Ah, so if I have a builder A that is executed for, say, 2 different branches, and a builder B, then I can have a given worker take simultaneously one git-branch of A and B, but not both branches of A (in the last case I need to define two workers)

21:26 <immae> (I guess the best answer to that is to try it, otherwise I’ll never get a grasp of it :D )