00:52 <skelly> verm__: nope

01:11 <verm__> skelly: what are the mail issues?

01:11 <verm__> seems to be working fine is it the lists??

01:15 <verm__> skelly: jails need to be updated to get the lists working again

01:18 <verm__> hmm looks like the libs are already updated i'll try a pkg update

01:19 <skelly> figures, I haven't touched lists because it uses ports and it's extra work

01:19 <verm__> okay should be working now

01:19 <skelly> great

01:19 <verm__> haha yeah .. it's annoying.

01:20 <skelly> I thought that might be the case but didn't have time to investigate

01:20 <verm__> no worries

01:20 <skelly> I really want to set up poudriere to automate our custom mailman setup

01:20 <skelly> one little config change...

01:21 <verm__> heh sure whatever works

01:22 <skelly> it's pretty easy to run, since it automates the jails and everything, but I haven't fully figured out how to manage it

01:23 <verm__> well it certainly helps if we need to do anything by hand

09:50 <tardyp> https://docs.buildbot.net/ is down as well..

10:48 <tuxillo> hi

10:48 <tuxillo> can buildbot poll an API to looking for specific info?

10:48 <tuxillo> i.e. buildbot polling the redmine API looking for new "tickets"

13:27 <skelly> tardyp: services aren't starting automatically and Ansible isn't getting far enough to do it

13:28 <skelly> I can start them manually fine and did so for docs

13:34 <tardyp> you mean I need to fix ansible?

13:35 <tardyp> tuxillo: you want to start builds when there is a new ticket?

13:46 <skelly> I have a PR open that will get it further

13:57 <tuxillo> tardyp: yes. there is some mechanism in redmine that you can pipe emails from procmail to redmine directly in order to create tickets in a specific tracker. and, since redmine does not have webhooks, i was wondering if one could go and poll the redmine api

13:59 <tardyp> skelly: merged

14:00 <tardyp> tuxillo: you can in theory create a vcs poller which polls redmine api, but I am not sure if buildbot is the right tool for that

14:47 <tuxillo> i don't know, probably it isn't

19:22 <Zash> Hey! What's a sensible approach to testing the same codebase in a number of different environments (ie different OS/distros and versions thereof)? We currently have quite the number of workers each running inside their own LXC container, all on the same physical machine. I'm not sure this is optimal.

19:41 <skelly> generally one builder per environment (e.g. build-x-debian-10, etc) and all of those builders then are triggered from the same scheduler

19:41 <skelly> can also have one builder to build and that triggers all of the test builders using Triggerable