I understood that debci-update is
supposed to do the work of looping against all suite and calling
debci-batch doesn't seem to work on all
suite as it uses debci_suite by default - may be I am again wrong
PS - last question: by default owner of
/usr/share/debci is root:root - is your default user debci ? do
you change owner of lock files and /usr/share/debci to debci user
or do you expect to have root ?
Hello Paul, thanks for the answers
Hope Debconf will be a good one for
I have investigated a bit further:
- it reads
$debci_base_dir/lib/environment.sh so get debci_suite value and
set a couple of variables like debci_autopkgtest_incoming_dir,
debci_packages_dir, debci_status_dir which are then used in the
As such I do believe that it doesn't
do a full job regarding all series but do work only on
I then can suggest something if
debci-status allows -s suite
parameter but my experience is the suite info is not used
/usr/share/debci$ debci status -s
testing -l |grep -i pass|wc
7075 14150 438668
/usr/share/debci$ debci status -s unstable -l |grep -i pass|wc
7075 14150 438668
So I traced execution and if you
specify -s suite parameter we set ENV(debci_suite) to the proper
value but then in debci-status line 54 in the FILE.join() we use
the Debci.config.packages_dir which is set by default config and
not updated by our parameter.
Have you already seen that trace
while it is executing ?
Exception `NoMethodError' at
/usr/lib/ruby/vendor_ruby/debci/html/status.erb:25 - undefined
method `' for nil:NilClass
Traceback (most recent call last):
16: from bin/debci-generate-html:33:in `<main>'
15: from /usr/lib/ruby/vendor_ruby/debci/html.rb:31:in
14: from /usr/lib/ruby/vendor_ruby/debci/html.rb:151:in
/usr/lib/ruby/vendor_ruby/debci/html/status.erb:25:in `block (4
levels) in expand_template': undefined method `' for
On 7/22/2019 10:02 PM, Paul Gevers
Terceiro is better at this, but I expect him to be busy with Debconf.
On 22-07-2019 10:27, Thierry Fauck@linux.ibm.com wrote:
- chake/debian-ci-config: Do I understand that master node is dedicated
to that task meaning it is the node running the collector ?
In our setup, yes.
How many network interfaces do you need per node 2 or 3 ? are they
Per worker you mean? I think 1 is enough. I think you're seeing two in
our configuration because that is how AWS works. The arm64 farm I am
trying to get working only uses one IIAC.
- How do you manage the different suites since the tools like
debci-generate-index only use the suite specified in debci_suite variable ?
Our workers generate one lxc container per suite that is supported. In
our case each worker can run tests for all the supported suites.
debci-generate-index runs on the master. I haven't checked what it would
be doing with the debci_suite variable (as it doesn't make sense to me
there, but maybe I am missing something).
I tried to have - for example one system for testing, one for unstable
and one for stable and I modified debci-generate-index to loop against
all suites defined in debci_suite_list but then I figured out that tools
like debci_status reports only the current suite - is that true ? is the
suite info part of the database ?
I'm pretty sure the suite is part of it yes. I can't comment on the
And since that time the status charts are completely strange because -
for example - the total number of packages in the suite is wrong (it
matches the unstable count I had once) or it varies from very few up to
the total count .... meaning nothing is clean.
So really my question is - (even if I don't put in the equation chake
and do manually because I have very few servers for now) how do you
manage the different suites on the master - or do you have multiple
masters or virtual masters ....
No, just one master to rule them all.
-Thanks in advance for your help clarifying my mind with that great tool
Although I can't answer all your questions, I hope it helps. Don't
hesitate to continue asking.
Thierry Fauck @ fr.ibm.com