BIND 10 Team Call



  • Not Shane ;)
  • Larissa
  • Jelte
  • Michal
  • Kambe
  • Aharen
  • Fujiwara
  • Jinmei
  • haikuo
  • Jeremy
  • Mukund

Sprint status

We are pretty well underway, but there is a danger, lots of the tickets that are left depend on some that have not been finished yet.

So please finish up review and merges soon.

Jinmei: what is the status of #1999?
Jeremy plans on merging it.
Jelte: Should we deprecate the old version?
Jeremy: Certainly not right now (some systems still offer latest version as a library package)

Statistics check-in

Check-in on the status of design changes for statistics.

Ticket 2135 is ready for review, and the wikipage is updated. New plan was sent to -dev list.

Some comments have been sent to the list already, we probably need some priority list for the work. Larissa will look at it.

jreed: I recall there is some internet draft about snmp for dns and am curious if this stats will be related to this.
jinmei: I think this is independent
jelte: well, the front may be, but at least we should try to use the framework, and not need to collect it twice

There has been some recent work on this, and people at ISC have been quite involved with that (not us though), so we can ask them for advice.

Valgrind status

We agreed to enable it, but had some problems getting a set of exclusions. What is the status?

Jeremy ran it about 35 times, adding suppressions every time, but it still failed about half the time, so it seemed random.

Jinmei: so it is not automated yet?
Jeremy: the builder is setup but the cron job is not enabled.
Jelte: I guess not, so we still have some work to get that finished (and that's not even fixing the existing reports)
Jeremy: someone who knows valgrind should look over the output i got, and maybe see if he can create a good suppression list, or maybe even fix the failures that are left
Jinmei: perhaps a topic for a hardening sprint?
Jeremy: it probably needs to go on a sprint, maybe i should create a tickets

Mukund: it would be nice if the build status pages also include the make check output for this
(there is )
We could just put it up and add supressions as they are reported by the builder

jreed: Look at  and

Michal: do we run with optimizations? Those could do nasty things to the stack. We should run it without.

Jeremy: there is another problem. At one point it printed a suppression it couldn't parse later on
Mukund: we can probably delete the particular line it failed on manually, and the rest of the suppression should work

Jeremy will play with it more today, and if it still doesn't work he'll create a ticket.

PuppetLabs? work on BIND 10

The Puppet developers contacted us about adding BIND 10 support to Puppet. Larissa and Shane were on a call with some of their team. Larissa reports (hopefully). Already have modules to automate configuration and system admin processes for BIND 9 and DHCP.

Questions from Larissa:

  • does anyone have puppet experience?
  • does anyone want to learn puppet? (we may be able to get free training)
  • anyone have thoughts or recommendations to the puppet devs about what would be useful to try automating first in bind10?

Let larissas know if you have any thoughts about this.

Jeremy: we should wait until at least after the beta, so the basics are locked in some more.
We should (also) ask our ops team.
Jelte: I have no experience myself, so need to investigate, but depending on how it works with changing backends (if at all), maybe we do need to get in early/

Rename which libraries?

For we decided last week that as we're going to rename libutil, we should probably rename more, but I don't think we should/need to rename all of them (libdns++ for instance?) Also, the proposal was to add b10 to them, do we still want to do that?


Jinmei: as i said previously i would rather see some higher-level design and clarification of which library is considered public/internal and what kind of naming scheme is appropriate for each, and then do it in a consistent way, rather than renaming everything to libb10<foo> in an ad-hoc way. But at the same time, I realize that at least libutil is a real problem.

Mukund proposed we just need to prefix all of them

jreed make wiki to start brainstorming:

We shall defer the ticket for a few days, so we can at least talk about the options first (before we wildly start renaming things).

Recent regression and boost version requirement

see there seem to be other failure modes

Vorner: two options: detect and fail at configure time, or write own offset_ptr (nontrivial but also not very complicated)
Jinmei: this is a problem with very specific versions (boost>1.45 and clang <forgotnumber>, it should be reasonably easy to detect it)

Vorner: the other problem was also fixed by upgrading afaik
Jinmei: did someone upgrade boost on that machine? I only upgraded the freebsd machine
Jelte: er, so the other problem just disappeared?
Jeremy: the netbsd machine has not been changed.
Vorner: There were no code changes either...
Jinmei: so we should first check what happened for this one.

See problem at /usr/pkg/include/boost/intrusive/detail/memory_util.hpp:154:42: error: variadic templates only available with -std=c++0x or -std=gnu++0x

Vorner: which one did you fix? variadic templates or const-difference?
Jinmei: mutable-something

Jinmei: I would like to avoid writing our own offset_ptr, even if it is relatively easy. (because we'll need to maintain it etc.). We should first investigate this and hopefully find a localized fix.

Jelte: do we need a ticket?
Jinmei: i'll take a quick look and if it seems to be nontrivial i think we need to create a ticket.


vorner: today, merge of 1976 created a few build failures that look easy enough but i have no time left today. I will address them though, so don't panic about the error reports.
jeremy: and the checkout failures should be fixed now.

meeting closed at 15:39UTC

Last modified 6 years ago Last modified on Jul 24, 2012, 4:16:26 PM