Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
archive rebuilds
1 view
Skip to first unread message
Lucas Nussbaum
May 12, 2013, 5:30:01 AM5/12/13
to
Hi!
First, thanks all for volunteering!
>From now on, let's use the debian-qa@ list for coordination (so, please
subscribe, if not done already)
I'll try to walk you through the tools used to do rebuilds and bug
filing. There are three big steps.
Step 1: Use AWS to run all the tests and generate logs
Step 2: Scan the logs (that's done automatically), generate list of
failures. Also upload the logs to some public place
Step 3: Look at each failure and submit bugs (that's done
semi-automatically)
In that mail, I will address Step 1. Once at least two of you have achieved it,
I'll move to Step 2.
There's some documentation (not completely up-to-date) on
http://wiki.debian.org/qa.debian.org/ArchiveTesting
For Step 1, most of the instructions are in
http://anonscm.debian.org/gitweb/?p=collab-qa/cloud-scripts.git;a=blob_plain;f=README;hb=HEAD
In the context of this "tutorial", your 'mission' is to rebuild all
packages that take between 100 and 110 seconds to build, and to get the
build logs for them.
First, I need your SSH key, so that you can connect to AWS.
Then, connect to our "master" node on EC2. That node must never be shut
down. I recommend you add sthing like:
Host ec2
User root
Hostname ec2-50-17-69-153.compute-1.amazonaws.com
to your .ssh/config.
In order to make your life slightly easier (and to reduce a bit the risks in
case of mistakes :) ), I've already reserved 5 "medium" instances for you. So
you don't need to do the resources reservation steps of README. The list of
those nodes is in /root/cloud-scripts/nodes.m1.medium.tutorial.
It also means that you must run masternode with the --no-halt switch, so that
nodes are not shut down are the end of the rebuild.
Then, everything happens in /root/cloud-scripts/
Read README, generate a list of tasks, check that you can connect to the
"builder" nodes, and rebuild those packages. In two of you happen to follow
that tutorial at the same time, generate a list of tasks with an ID so that log
names don't conflict.
Please let me know if you have questions (either by mail or on IRC, #debian-qa).
When you are done, take a look around (esp. at masternode and process-tasks),
and let me know, so that we can move to Step 2.
Lucas
--
To UNSUBSCRIBE, email to debian-q...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Archive: http://lists.debian.org/20130512090...@xanadu.blop.info
First, thanks all for volunteering!
>From now on, let's use the debian-qa@ list for coordination (so, please
subscribe, if not done already)
I'll try to walk you through the tools used to do rebuilds and bug
filing. There are three big steps.
Step 1: Use AWS to run all the tests and generate logs
Step 2: Scan the logs (that's done automatically), generate list of
failures. Also upload the logs to some public place
Step 3: Look at each failure and submit bugs (that's done
semi-automatically)
In that mail, I will address Step 1. Once at least two of you have achieved it,
I'll move to Step 2.
There's some documentation (not completely up-to-date) on
http://wiki.debian.org/qa.debian.org/ArchiveTesting
For Step 1, most of the instructions are in
http://anonscm.debian.org/gitweb/?p=collab-qa/cloud-scripts.git;a=blob_plain;f=README;hb=HEAD
In the context of this "tutorial", your 'mission' is to rebuild all
packages that take between 100 and 110 seconds to build, and to get the
build logs for them.
First, I need your SSH key, so that you can connect to AWS.
Then, connect to our "master" node on EC2. That node must never be shut
down. I recommend you add sthing like:
Host ec2
User root
Hostname ec2-50-17-69-153.compute-1.amazonaws.com
to your .ssh/config.
In order to make your life slightly easier (and to reduce a bit the risks in
case of mistakes :) ), I've already reserved 5 "medium" instances for you. So
you don't need to do the resources reservation steps of README. The list of
those nodes is in /root/cloud-scripts/nodes.m1.medium.tutorial.
It also means that you must run masternode with the --no-halt switch, so that
nodes are not shut down are the end of the rebuild.
Then, everything happens in /root/cloud-scripts/
Read README, generate a list of tasks, check that you can connect to the
"builder" nodes, and rebuild those packages. In two of you happen to follow
that tutorial at the same time, generate a list of tasks with an ID so that log
names don't conflict.
Please let me know if you have questions (either by mail or on IRC, #debian-qa).
When you are done, take a look around (esp. at masternode and process-tasks),
and let me know, so that we can move to Step 2.
Lucas
--
To UNSUBSCRIBE, email to debian-q...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Archive: http://lists.debian.org/20130512090...@xanadu.blop.info
Paul Wise
May 12, 2013, 5:40:02 AM5/12/13
to
On Sun, May 12, 2013 at 5:01 PM, Lucas Nussbaum wrote:
> our "master" node on EC2. That node must never be shut down.
Why is this? Is it because the node isn't using a persistent IP
> our "master" node on EC2. That node must never be shut down.
address (I forget the correct terminology)?
--
bye,
pabs
http://wiki.debian.org/PaulWise
--
To UNSUBSCRIBE, email to debian-q...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Thomas Goirand
May 12, 2013, 5:50:02 AM5/12/13
to
On 05/12/2013 05:01 PM, Lucas Nussbaum wrote:
> First, I need your SSH key, so that you can connect to AWS.
Hi Lucas,
> First, I need your SSH key, so that you can connect to AWS.
Thanks for all these details. I haven't read it all yet, but I will.
You may find it here:
http://www.gplhost.com/ssh-pubkeys/zigo
Let me know when I can connect.
Thomas
--
To UNSUBSCRIBE, email to debian-q...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Niels Thykier
May 12, 2013, 6:00:01 AM5/12/13
to
On 2013-05-12 11:47, Thomas Goirand wrote:
> On 05/12/2013 05:01 PM, Lucas Nussbaum wrote:
>> First, I need your SSH key, so that you can connect to AWS.
>
> Hi Lucas,
>
> Thanks for all these details. I haven't read it all yet, but I will.
>
> You may find it here:
> http://www.gplhost.com/ssh-pubkeys/zigo
>
> Let me know when I can connect.
>
> Thomas
>
>
You probably want to sign the key.
> On 05/12/2013 05:01 PM, Lucas Nussbaum wrote:
>> First, I need your SSH key, so that you can connect to AWS.
>
> Hi Lucas,
>
> Thanks for all these details. I haven't read it all yet, but I will.
>
> You may find it here:
> http://www.gplhost.com/ssh-pubkeys/zigo
>
> Let me know when I can connect.
>
> Thomas
>
>
~Niels
--
To UNSUBSCRIBE, email to debian-q...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Lucas Nussbaum
May 12, 2013, 6:50:02 AM5/12/13
to
On 12/05/13 at 17:47 +0800, Thomas Goirand wrote:
> On 05/12/2013 05:01 PM, Lucas Nussbaum wrote:
> > First, I need your SSH key, so that you can connect to AWS.
>
> Hi Lucas,
>
> Thanks for all these details. I haven't read it all yet, but I will.
>
> You may find it here:
> http://www.gplhost.com/ssh-pubkeys/zigo
>
> Let me know when I can connect.
Added.
> On 05/12/2013 05:01 PM, Lucas Nussbaum wrote:
> > First, I need your SSH key, so that you can connect to AWS.
>
> Hi Lucas,
>
> Thanks for all these details. I haven't read it all yet, but I will.
>
> You may find it here:
> http://www.gplhost.com/ssh-pubkeys/zigo
>
> Let me know when I can connect.
Lucas
--
To UNSUBSCRIBE, email to debian-q...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Lucas Nussbaum
May 12, 2013, 7:40:02 AM5/12/13
to
On 12/05/13 at 17:30 +0800, Paul Wise wrote:
> On Sun, May 12, 2013 at 5:01 PM, Lucas Nussbaum wrote:
>
> > our "master" node on EC2. That node must never be shut down.
>
> Why is this? Is it because the node isn't using a persistent IP
> address (I forget the correct terminology)?
Just because it costs basically nothing to keep it alive, and it's
> On Sun, May 12, 2013 at 5:01 PM, Lucas Nussbaum wrote:
>
> > our "master" node on EC2. That node must never be shut down.
>
> Why is this? Is it because the node isn't using a persistent IP
> address (I forget the correct terminology)?
more convenient that way. It's true that we could shut it down.
Lucas
--
To UNSUBSCRIBE, email to debian-q...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
david suarez
May 12, 2013, 7:50:01 AM5/12/13
to
Let me know when you added it.
DavidThomas Goirand
May 12, 2013, 8:30:02 AM5/12/13
to
On 05/12/2013 05:54 PM, Niels Thykier wrote:
> You probably want to sign the key.
>
> ~Niels
Can an ssh key be pgp signed? I didn't know.
> You probably want to sign the key.
>
> ~Niels
How do I do that?
Thomas
--
To UNSUBSCRIBE, email to debian-q...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Niels Thykier
May 12, 2013, 8:30:02 AM5/12/13
to
On 2013-05-12 14:20, Thomas Goirand wrote:
> On 05/12/2013 05:54 PM, Niels Thykier wrote:
>> You probably want to sign the key.
>>
>> ~Niels
> Can an ssh key be pgp signed? I didn't know.
> How do I do that?
>
> Thomas
>
>
The key can be GPG signed like any other text file. If you clear sign
> On 05/12/2013 05:54 PM, Niels Thykier wrote:
>> You probably want to sign the key.
>>
>> ~Niels
> Can an ssh key be pgp signed? I didn't know.
> How do I do that?
>
> Thomas
>
>
it like David did, the file itself cannot be used directly (i.e. the
receiver have to extract the SSH key first). Alternatively you could
have included a link to a detached signature. Example:
http://www.gplhost.com/ssh-pubkeys/zigo
http://www.gplhost.com/ssh-pubkeys/zigo.asc
Either way would provide a way to verify that the key publish over HTTP
is from/approved by you.
~Niels
--
To UNSUBSCRIBE, email to debian-q...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
David Suárez
May 12, 2013, 12:10:02 PM5/12/13
to
On Domingo, 12 de mayo de 2013 13:58:45 usted escribió:
>
> Lucas
Hi,
Ok, step 1 done.
I cloned early the cloud-scripts git repo and i'm looking at the souce code.
David
--
To UNSUBSCRIBE, email to debian-q...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Archive: http://lists.debian.org/201305121800.378...@gmail.com
> On 12/05/13 at 13:43 +0200, david suarez wrote:
> > Hi,
> >
> > Here's my ssh key:
> > https://dl.dropboxusercontent.com/u/50951262/id_rsa.pub.asc
> >
> > Let me know when you added it.
>
> Added.
> > Hi,
> >
> > Here's my ssh key:
> > https://dl.dropboxusercontent.com/u/50951262/id_rsa.pub.asc
> >
> > Let me know when you added it.
>
>
> Lucas
Hi,
Ok, step 1 done.
I cloned early the cloud-scripts git repo and i'm looking at the souce code.
David
--
To UNSUBSCRIBE, email to debian-q...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Nathan Handler
May 12, 2013, 5:30:03 PM5/12/13
to
On Sun, May 12, 2013 at 4:01 AM, Lucas Nussbaum <lu...@debian.org> wrote:
> In that mail, I will address Step 1. Once at least two of you have achieved it,
> I'll move to Step 2.
I have also completed all of the tasks in Step 1. My tasks and log
> In that mail, I will address Step 1. Once at least two of you have achieved it,
> I'll move to Step 2.
files are available at [1] for anyone interested.
Nathan
[1] http://people.debian.org/~nhandler/.ec2/
--
To UNSUBSCRIBE, email to debian-q...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
David Suarez
May 12, 2013, 5:40:02 PM5/12/13
to
El 12/05/2013 23:24, "Nathan Handler" <nhan...@debian.org> escribió:
>
> On Sun, May 12, 2013 at 4:01 AM, Lucas Nussbaum <lu...@debian.org> wrote:
> > In that mail, I will address Step 1. Once at least two of you have achieved it,
> > I'll move to Step 2.
>
> I have also completed all of the tasks in Step 1. My tasks and log
> files are available at [1] for anyone interested.
>
> Nathan
>
> [1] http://people.debian.org/~nhandler/.ec2/
>
>
We have to publish the results?
Lucas Nussbaum
May 13, 2013, 1:30:02 AM5/13/13
to
On 12/05/13 at 23:37 +0200, David Suarez wrote:
> El 12/05/2013 23:24, "Nathan Handler" <nhan...@debian.org> escribi�:
/tmp/logs, since that what we will use in Step 2.
Lucas
--
To UNSUBSCRIBE, email to debian-q...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Archive: http://lists.debian.org/20130513051...@xanadu.blop.info
> El 12/05/2013 23:24, "Nathan Handler" <nhan...@debian.org> escribi�:
> >
> > On Sun, May 12, 2013 at 4:01 AM, Lucas Nussbaum <lu...@debian.org> wrote:
> > > In that mail, I will address Step 1. Once at least two of you have
> achieved it,
> > > I'll move to Step 2.
> >
> > I have also completed all of the tasks in Step 1. My tasks and log
> > files are available at [1] for anyone interested.
> >
> > Nathan
> >
> > [1] http://people.debian.org/~nhandler/.ec2/
> >
> >
> We have to publish the results?
No, but please make sure that you find the corresponding logs in
> > On Sun, May 12, 2013 at 4:01 AM, Lucas Nussbaum <lu...@debian.org> wrote:
> > > In that mail, I will address Step 1. Once at least two of you have
> achieved it,
> > > I'll move to Step 2.
> >
> > I have also completed all of the tasks in Step 1. My tasks and log
> > files are available at [1] for anyone interested.
> >
> > Nathan
> >
> > [1] http://people.debian.org/~nhandler/.ec2/
> >
> >
> We have to publish the results?
/tmp/logs, since that what we will use in Step 2.
Lucas
--
To UNSUBSCRIBE, email to debian-q...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
david suarez
May 13, 2013, 2:20:02 AM5/13/13
to
OK, tasks generated with the correct upper and lower parameters. Build log and packages logs in ec2 master node.
On 12/05/13 at 23:37 +0200, David Suarez wrote:
> El 12/05/2013 23:24, "Nathan Handler" <nhan...@debian.org> escribió:
> >
> > On Sun, May 12, 2013 at 4:01 AM, Lucas Nussbaum <lu...@debian.org> wrote:
> > > In that mail, I will address Step 1. Once at least two of you have
> achieved it,
> > > I'll move to Step 2.
> >
> > I have also completed all of the tasks in Step 1. My tasks and log
> > files are available at [1] for anyone interested.
> >
> > Nathan
> >
> > [1] http://people.debian.org/~nhandler/.ec2/
> >
> >
> We have to publish the results?
Lucas Nussbaum
May 13, 2013, 4:20:02 AM5/13/13
to
Hi,
So, Step 2. I described it as:
In Step 2, we will:
- scan the logs to identify failed builds. For that, we will use
cqa-scanlogs, which is installed on the master node, and available as
part of the collab-qa-tools package, which source can be found on
http://anonscm.debian.org/viewvc/collab-qa/collab-qa-tools/
cqa-scanlogs parses build logs and extracts the interesting part
automatically.
- move logs of failures to a public place. Currently, under
http://people.debian.org/~lucas/logs/, but we need to change that.
- prepare a list of failures that will be used for Step 3, such as
http://anonscm.debian.org/viewvc/collab-qa/archive-rebuilds/2013-05-09-unstable-amd64/failed.2013-05-09.txt?revision=2673&view=markup
That step is actually completely automatized in that script:
http://anonscm.debian.org/viewvc/collab-qa/archive-rebuilds/fetch-and-process-results-aws?revision=2276&view=markup
The problem is that everything is hardcoded.
Your tasks here are:
- build and install collab-qa-tools locally
- look at fetch-and-process-results-aws, understand what it does, do
every step manually replacing steps you can't do as is (e.g. upload
logs somewhere else)
- ideally, hack fetch-and-process-results-aws so that your own settings
(different place to put logs) are available.
You will note that at the end of the script, we use a script called
"merge-results.rb". That script 'imports' a list of failures (+ bugs
filed) into the current list. That allows you to concentrate on the
unknown failures, and to auto-fill all known failures with the
corresponding bug numbers.
In Step 3, we will look at using the list of failures to file bugs.
Side task for Steps 1 and 2:
I am often asked to perform custom rebuilds. Typically, rebuild of
unstable with a custom GCC version. There's on my TODO list right now,
about rebuilding unstable with GCC 4.8. For that, Matthias Klose has
prepared at
deb http://people.debian.org/~doko/tmp/tinstall ./
To run a custom rebuild, you need to specify a 'mode' to
generate-tasks-rebuild, e.g.:
./generate-tasks-rebuild --no-arch-all -m binary-only -m parallel -m gcc48-unstable -i gcc48 > tasks.gcc48.json
That mode is then added in the json description of tasks, so
process-task can use it to customize the way it calls sbuild, e.g.:
if task['modes'].include?('gcc48-unstable')
if not File::exists?('/tmp/change-gcc48-unstable')
File::open('/tmp/change-gcc48-unstable', 'w') do |fd|
fd.puts <<-EOF
#!/usr/bin/sudo bash
set -e -x
id
deb http://people.debian.org/~doko/tmp/gcc-4.8 ./ >> /etc/apt/sources.list
echo 'APT::Get::AllowUnauthenticated "1";' > /etc/apt/apt.conf.d/99allow-unauth
apt-get update
apt-get -y upgrade
EOF
end
system("chmod a+rx /tmp/change-gcc48-unstable")
end
sbuildopt += ' --chroot-setup-commands=/tmp/change-gcc48-unstable'
end
Generally, when running such custom rebuilds, what's interesting is the
difference between a normal rebuild and the custom one. So usually, you do
something such as (example from README):
# gcc 4.8
./generate-tasks-rebuild --no-arch-all -m binary-only -m parallel -m gcc48-unstable -i gcc48 > tasks.gcc48.json
./generate-tasks-rebuild --no-arch-all -m binary-only -m parallel -i normal > tasks.normal.json
./merge-tasks tasks.gcc48.json tasks.normal.json > tasks.json
You task here is to hack process-task so that it can be used to run a custom
rebuild using doko packages, and to test that it works against a few packages.
(It might be that only the URL in process-task needs to be changed ; I'm not sure).
Then, move "normal" and "gcc48" logs to separate directories, use cqa-scanlogs
to list failures, and use 'compare-results.rb' to compare both list of
failures. Try to find one package that succeeds in the normal rebuild, but
fails in the gcc 4.8 one. (there's a list of bugs that should affect only gcc
4.8 filed by Matthias Klose at
http://bugs.debian.org/cgi-bin/pkgreport.cgi?tag=ftbfs-gcc-4.8;users=debia...@lists.debian.org)
Lucas
--
To UNSUBSCRIBE, email to debian-q...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Archive: http://lists.debian.org/20130513081...@xanadu.blop.info
So, Step 2. I described it as:
Scan the logs (that's done automatically), generate list of
failures. Also upload the logs to some public place
At the end of Step 1, we have all the logs on EC2 in /tmp/logs.
failures. Also upload the logs to some public place
In Step 2, we will:
- scan the logs to identify failed builds. For that, we will use
cqa-scanlogs, which is installed on the master node, and available as
part of the collab-qa-tools package, which source can be found on
http://anonscm.debian.org/viewvc/collab-qa/collab-qa-tools/
cqa-scanlogs parses build logs and extracts the interesting part
automatically.
- move logs of failures to a public place. Currently, under
http://people.debian.org/~lucas/logs/, but we need to change that.
- prepare a list of failures that will be used for Step 3, such as
http://anonscm.debian.org/viewvc/collab-qa/archive-rebuilds/2013-05-09-unstable-amd64/failed.2013-05-09.txt?revision=2673&view=markup
That step is actually completely automatized in that script:
http://anonscm.debian.org/viewvc/collab-qa/archive-rebuilds/fetch-and-process-results-aws?revision=2276&view=markup
The problem is that everything is hardcoded.
Your tasks here are:
- build and install collab-qa-tools locally
- look at fetch-and-process-results-aws, understand what it does, do
every step manually replacing steps you can't do as is (e.g. upload
logs somewhere else)
- ideally, hack fetch-and-process-results-aws so that your own settings
(different place to put logs) are available.
You will note that at the end of the script, we use a script called
"merge-results.rb". That script 'imports' a list of failures (+ bugs
filed) into the current list. That allows you to concentrate on the
unknown failures, and to auto-fill all known failures with the
corresponding bug numbers.
In Step 3, we will look at using the list of failures to file bugs.
Side task for Steps 1 and 2:
I am often asked to perform custom rebuilds. Typically, rebuild of
unstable with a custom GCC version. There's on my TODO list right now,
about rebuilding unstable with GCC 4.8. For that, Matthias Klose has
prepared at
deb http://people.debian.org/~doko/tmp/tinstall ./
To run a custom rebuild, you need to specify a 'mode' to
generate-tasks-rebuild, e.g.:
./generate-tasks-rebuild --no-arch-all -m binary-only -m parallel -m gcc48-unstable -i gcc48 > tasks.gcc48.json
That mode is then added in the json description of tasks, so
process-task can use it to customize the way it calls sbuild, e.g.:
if task['modes'].include?('gcc48-unstable')
if not File::exists?('/tmp/change-gcc48-unstable')
File::open('/tmp/change-gcc48-unstable', 'w') do |fd|
fd.puts <<-EOF
#!/usr/bin/sudo bash
set -e -x
id
deb http://people.debian.org/~doko/tmp/gcc-4.8 ./ >> /etc/apt/sources.list
echo 'APT::Get::AllowUnauthenticated "1";' > /etc/apt/apt.conf.d/99allow-unauth
apt-get update
apt-get -y upgrade
EOF
end
system("chmod a+rx /tmp/change-gcc48-unstable")
end
sbuildopt += ' --chroot-setup-commands=/tmp/change-gcc48-unstable'
end
Generally, when running such custom rebuilds, what's interesting is the
difference between a normal rebuild and the custom one. So usually, you do
something such as (example from README):
# gcc 4.8
./generate-tasks-rebuild --no-arch-all -m binary-only -m parallel -m gcc48-unstable -i gcc48 > tasks.gcc48.json
./generate-tasks-rebuild --no-arch-all -m binary-only -m parallel -i normal > tasks.normal.json
./merge-tasks tasks.gcc48.json tasks.normal.json > tasks.json
You task here is to hack process-task so that it can be used to run a custom
rebuild using doko packages, and to test that it works against a few packages.
(It might be that only the URL in process-task needs to be changed ; I'm not sure).
Then, move "normal" and "gcc48" logs to separate directories, use cqa-scanlogs
to list failures, and use 'compare-results.rb' to compare both list of
failures. Try to find one package that succeeds in the normal rebuild, but
fails in the gcc 4.8 one. (there's a list of bugs that should affect only gcc
4.8 filed by Matthias Klose at
http://bugs.debian.org/cgi-bin/pkgreport.cgi?tag=ftbfs-gcc-4.8;users=debia...@lists.debian.org)
Lucas
--
To UNSUBSCRIBE, email to debian-q...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
David Suárez
May 13, 2013, 2:30:02 PM5/13/13
to
Hi,
You can find the Failure logs at https://gist.github.com/deiv/5570248
Im going for the bonus task.
By the way, the same logic that do 'fetch-and-process-results-aws' can not be
replicated with the -r argument of cqa-scanlogs, something like 'cqa-scanlogs
-r Failed' ? (assuming we will only focus on failed builds).
David
--
To UNSUBSCRIBE, email to debian-q...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Archive: http://lists.debian.org/201305132224.332...@gmail.com
You can find the Failure logs at https://gist.github.com/deiv/5570248
Im going for the bonus task.
By the way, the same logic that do 'fetch-and-process-results-aws' can not be
replicated with the -r argument of cqa-scanlogs, something like 'cqa-scanlogs
-r Failed' ? (assuming we will only focus on failed builds).
David
--
To UNSUBSCRIBE, email to debian-q...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Lucas Nussbaum
May 13, 2013, 4:10:02 PM5/13/13
to
On 13/05/13 at 22:24 +0200, David Su�rez wrote:
> Hi,
>
> You can find the Failure logs at https://gist.github.com/deiv/5570248
>
> Im going for the bonus task.
Excellent!
> Hi,
>
> You can find the Failure logs at https://gist.github.com/deiv/5570248
>
> Im going for the bonus task.
> By the way, the same logic that do 'fetch-and-process-results-aws' can not be
> replicated with the -r argument of cqa-scanlogs, something like 'cqa-scanlogs
> -r Failed' ? (assuming we will only focus on failed builds).
stores the list of successful builds, because it's useful to be able to
look at failures from an historical perspective (e.g. "when did this pkg
start failing to build?").
We will use '-r' in Step 3, in order to file bugs matching specific
failures. It's generally easier to file all similar failures at the same
time.
Lucas
--
To UNSUBSCRIBE, email to debian-q...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Lucas Nussbaum
May 14, 2013, 12:10:04 PM5/14/13
to
Hi,
Let's discuss Step 3, which I originally described as:
mins. (Well, with the long waiting period between Step 1 and Step 2).
Step 3 is the most time-consuming part.
At the end of Step 2, you should have:
- all the logs for failed builds available somewhere on the web
- all the logs for failed builds available locally
- the list of failures, merged with the previous list, in e.g.
collab-qa/archive-rebuilds/2013-05-09-unstable-amd64/failed.2013-05-09.txt
That list should contain lines with "TODO". That's the bugs that need to
be filed.
That step is quite simple. It consists in going through each log and filing the
corresponding bug. Of course, it's partially automated to be efficient.
Let's start by setting up your local environment. I recommend that you use mutt
for bug filing, because it's fast to start. And also a local MTA such as
nullmailer. nullmailer is great, because its queue is available in a directory,
and you can still remove mails from the queue before you flush it. That's great
in the "oh, I didn't realize that all those failures I just filed are actually
the same one and should not be filed" case.
Also, install collab-qa-tools locally.
Go to the directory with the logs.
$ export TODOFILE=~/collab-qa/archive-rebuilds/2013-05-09-unstable-amd64/failed.2013-05-09.txt
(point to the list of failures)
$ export DATE=2013/05/14
that date is used to generate the path to the log files, and the BTS usertag.
$ cqa-scanlogs -t $TODOFILE
You already know this tool. That way, it only lists bugs still marked TODO.
$ cqa-fetchbugs -t $TODOFILE
That fetches the list of known bugs matching some regexp in .bugs.srcpkg files.
Those files will be used by cqa-annotate. To refresh this "cache", just
rm .bugs.*
The goal here is to identify bugs to file, and also bugs to NOT file
(typically, when you have 20 failures with the identical error message, you
should make sure that you should really file 20 bugs and not just one against
another common dep). Use grep, common sense, and some manual analysis.
Generally, the most easy bugs are the ones tagged GCC_ERROR or LD_ERROR.
The most interesting ones (in terms of analysis and "wtf potential") are found
in the ones tagged UNKNOWN.
BUILDDEPS bugs are rarely filed as is: they are often failures caused by
another package.
To file bugs, use
$ cqa-annotate -t $TODOFILE -r REGEXP
with REGEXP being, e.g.:
- GCC_ERROR
- "ommand not found"
- ... any string from the one-line bug summary
cqa-annotate is a hackish interactive script. For each bug matching REGEXP, it
will present you with a prompt. real-life example:
| ######## argparse_1.2.1-2_unstable.log ########
^ name of the log
| --------- Error:
| fakeroot debian/rules clean
| pyversions: computed set of supported versions is empty
| dh_testdir
| dh_testroot
| [ ! -e html ] || rm -rf html
| [ ! -e doc.orig ] || mv doc.orig doc
| set -e; for pyver in ; do \
| python$pyver setup.py clean --all; \
| done
| [ -f argparse.pyc ] && rm -f argparse.pyc
| make: *** [clean] Error 1
^ multi-line log extract. that's the one that would end up in the mail body.
| ----------------
| XXX
^ one-line log extract. that's the one that would end up in the mail subject.
if it's XXX, it means that nothing meaningful could be found, and you need to
write your own summary (usually copy/pasting the appropriate line from
the log).
| ----------------
| package: argparse
^ name of the source package
| lines: 11
^ number of lines in the log extract. if it's too long, it's a good idea to edit
it manually. Don't send megabytes of logs to the BTS.
| 1: 556262 minor argparse: FTBFS of unstable/testing sources on lenny ||
| 2: 707117 serious argparse: FTBFS: make: *** [clean] Error 1 ||
^ that's the list of possible bugs that could match this failure, as fetched
by cqa-fetchbugs.
At this point, you can press:
's' to skip that bug. it remains TODO in $TODOFILE
'v 1' or 'v 2' to view bug number 1 or 2 using w3m -dump
'1' or '2' to confirm that this is actually bug number 1 or 2. The bug number will replace TODO in $TODOFILE.
'sev 1' or 'sev 2' to indicate that this is actually bug number 1 or 2, and that bug severity must be increased to 'serious' (using bts severity nnn serious).
'r' to report a bug.
If you press 'r', mutt opens. Edit the email as needed, then send it.
Once the mail is sent, cqa-annotate asks for confirmation:
edit TODOFILE? ('n' if not!)
(just press enter)
at this point, TODO is replaced by NNN in $TODOFILE.
When you are done filing bugs, you can replace all those NNN by actual bug numbers. For that, you need to use e.g.:
cqa-importbugnumbers debi...@lists.debian.org qa-ftbfs-20130509 < $TODOFILE > tmp
the two parameters are bug username and usertag.
You mission this time:
- pick up ~100 random packages from the list of packages that failed to build on
2013-05-09 and are still marked TODO. it's a good idea to ignore the remaining
GCC_ERROR bugs: those don't need to be filed.
grep TODO failed.* | grep -v GCC_ERROR | cut -d ' ' -f 1 | shuf | head -n 100
should give you something.
- rebuild them. (use generate-tasks-rebuild with -i pkglist)
- file 10 bugs using everything described above.
(make sure to double-check the content of the emails, esp. the URLs.
Those are hardcoded, so you could hack ./lib/collab-qa/log-parser.rb
to put your own URL for now. In the future, it should be customizable
differently (env variables? small config file ?))
- commit the bug numbers to the list for 20130509.
- report here. :)
We will do a full archive rebuild "for real" in a few days, which will involve
reserving more build nodes, too.
And also do the gcc 4.8 rebuild with more nodes.
Three final words:
- one difficult aspect is to find a good balance between
spending too much time yourself on each bug, and making mistakes,
that make other people spend too much time on the bugs you filed.
I'm sure you will learn :-)
- when people can't reproduce the failures, a good way to move forward
is to ask for a full build log using pbuilder, and for a diff between
your log and their log. Usually, this solves 80% of the unreproducible
failures. Also remember that masternode.rb automatically restarts
failed builds once, so you know it failed two times in a row if it
ends up in your list.
- sometimes (rarely) people get angry. Don't get discouraged by that.
Most of the people are grateful about the bug filing.
Lucas
--
To UNSUBSCRIBE, email to debian-q...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Archive: http://lists.debian.org/20130514160...@xanadu.blop.info
Let's discuss Step 3, which I originally described as:
Look at each failure and submit bugs (that's done
semi-automatically)
When you will get used to them, Steps 1 and 2 will take less than 15
semi-automatically)
mins. (Well, with the long waiting period between Step 1 and Step 2).
Step 3 is the most time-consuming part.
At the end of Step 2, you should have:
- all the logs for failed builds available somewhere on the web
- all the logs for failed builds available locally
- the list of failures, merged with the previous list, in e.g.
collab-qa/archive-rebuilds/2013-05-09-unstable-amd64/failed.2013-05-09.txt
That list should contain lines with "TODO". That's the bugs that need to
be filed.
That step is quite simple. It consists in going through each log and filing the
corresponding bug. Of course, it's partially automated to be efficient.
Let's start by setting up your local environment. I recommend that you use mutt
for bug filing, because it's fast to start. And also a local MTA such as
nullmailer. nullmailer is great, because its queue is available in a directory,
and you can still remove mails from the queue before you flush it. That's great
in the "oh, I didn't realize that all those failures I just filed are actually
the same one and should not be filed" case.
Also, install collab-qa-tools locally.
Go to the directory with the logs.
$ export TODOFILE=~/collab-qa/archive-rebuilds/2013-05-09-unstable-amd64/failed.2013-05-09.txt
(point to the list of failures)
$ export DATE=2013/05/14
that date is used to generate the path to the log files, and the BTS usertag.
$ cqa-scanlogs -t $TODOFILE
You already know this tool. That way, it only lists bugs still marked TODO.
$ cqa-fetchbugs -t $TODOFILE
That fetches the list of known bugs matching some regexp in .bugs.srcpkg files.
Those files will be used by cqa-annotate. To refresh this "cache", just
rm .bugs.*
The goal here is to identify bugs to file, and also bugs to NOT file
(typically, when you have 20 failures with the identical error message, you
should make sure that you should really file 20 bugs and not just one against
another common dep). Use grep, common sense, and some manual analysis.
Generally, the most easy bugs are the ones tagged GCC_ERROR or LD_ERROR.
The most interesting ones (in terms of analysis and "wtf potential") are found
in the ones tagged UNKNOWN.
BUILDDEPS bugs are rarely filed as is: they are often failures caused by
another package.
To file bugs, use
$ cqa-annotate -t $TODOFILE -r REGEXP
with REGEXP being, e.g.:
- GCC_ERROR
- "ommand not found"
- ... any string from the one-line bug summary
cqa-annotate is a hackish interactive script. For each bug matching REGEXP, it
will present you with a prompt. real-life example:
| ######## argparse_1.2.1-2_unstable.log ########
^ name of the log
| --------- Error:
| fakeroot debian/rules clean
| pyversions: computed set of supported versions is empty
| dh_testdir
| dh_testroot
| [ ! -e html ] || rm -rf html
| [ ! -e doc.orig ] || mv doc.orig doc
| set -e; for pyver in ; do \
| python$pyver setup.py clean --all; \
| done
| [ -f argparse.pyc ] && rm -f argparse.pyc
| make: *** [clean] Error 1
^ multi-line log extract. that's the one that would end up in the mail body.
| ----------------
| XXX
^ one-line log extract. that's the one that would end up in the mail subject.
if it's XXX, it means that nothing meaningful could be found, and you need to
write your own summary (usually copy/pasting the appropriate line from
the log).
| ----------------
| package: argparse
^ name of the source package
| lines: 11
^ number of lines in the log extract. if it's too long, it's a good idea to edit
it manually. Don't send megabytes of logs to the BTS.
| 1: 556262 minor argparse: FTBFS of unstable/testing sources on lenny ||
| 2: 707117 serious argparse: FTBFS: make: *** [clean] Error 1 ||
^ that's the list of possible bugs that could match this failure, as fetched
by cqa-fetchbugs.
At this point, you can press:
's' to skip that bug. it remains TODO in $TODOFILE
'v 1' or 'v 2' to view bug number 1 or 2 using w3m -dump
'1' or '2' to confirm that this is actually bug number 1 or 2. The bug number will replace TODO in $TODOFILE.
'sev 1' or 'sev 2' to indicate that this is actually bug number 1 or 2, and that bug severity must be increased to 'serious' (using bts severity nnn serious).
'r' to report a bug.
If you press 'r', mutt opens. Edit the email as needed, then send it.
Once the mail is sent, cqa-annotate asks for confirmation:
edit TODOFILE? ('n' if not!)
(just press enter)
at this point, TODO is replaced by NNN in $TODOFILE.
When you are done filing bugs, you can replace all those NNN by actual bug numbers. For that, you need to use e.g.:
cqa-importbugnumbers debi...@lists.debian.org qa-ftbfs-20130509 < $TODOFILE > tmp
the two parameters are bug username and usertag.
You mission this time:
- pick up ~100 random packages from the list of packages that failed to build on
2013-05-09 and are still marked TODO. it's a good idea to ignore the remaining
GCC_ERROR bugs: those don't need to be filed.
grep TODO failed.* | grep -v GCC_ERROR | cut -d ' ' -f 1 | shuf | head -n 100
should give you something.
- rebuild them. (use generate-tasks-rebuild with -i pkglist)
- file 10 bugs using everything described above.
(make sure to double-check the content of the emails, esp. the URLs.
Those are hardcoded, so you could hack ./lib/collab-qa/log-parser.rb
to put your own URL for now. In the future, it should be customizable
differently (env variables? small config file ?))
- commit the bug numbers to the list for 20130509.
- report here. :)
We will do a full archive rebuild "for real" in a few days, which will involve
reserving more build nodes, too.
And also do the gcc 4.8 rebuild with more nodes.
Three final words:
- one difficult aspect is to find a good balance between
spending too much time yourself on each bug, and making mistakes,
that make other people spend too much time on the bugs you filed.
I'm sure you will learn :-)
- when people can't reproduce the failures, a good way to move forward
is to ask for a full build log using pbuilder, and for a diff between
your log and their log. Usually, this solves 80% of the unreproducible
failures. Also remember that masternode.rb automatically restarts
failed builds once, so you know it failed two times in a row if it
ends up in your list.
- sometimes (rarely) people get angry. Don't get discouraged by that.
Most of the people are grateful about the bug filing.
Lucas
--
To UNSUBSCRIBE, email to debian-q...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Thomas Goirand
May 14, 2013, 1:00:02 PM5/14/13
to
On 05/12/2013 05:01 PM, Lucas Nussbaum wrote:
> Hi!
>
> First, thanks all for volunteering!
>
> >From now on, let's use the debian-qa@ list for coordination (so, please
> subscribe, if not done already)
>
> I'll try to walk you through the tools used to do rebuilds and bug
> filing. There are three big steps.
>
> Step 1: Use AWS to run all the tests and generate logs
Your readme says:
> Hi!
>
> First, thanks all for volunteering!
>
> >From now on, let's use the debian-qa@ list for coordination (so, please
> subscribe, if not done already)
>
> I'll try to walk you through the tools used to do rebuilds and bug
> filing. There are three big steps.
>
> Step 1: Use AWS to run all the tests and generate logs
0. Local configuration
----------------------
in .bashrc:
export EC2_PRIVATE_KEY=~/.ec2/pk-5ZQPKTH4FX2YWIYSKAHTFBCR4QGTKNN3.pem
export EC2_CERT=~/.ec2/cert-5ZQPKTH4FX2YWIYSKAHTFBCR4QGTKNN3.pem
export EC2_URL=https://ec2.us-east-1.amazonaws.com
then try 'ec2-describe-instances'
Those commands can be needed to set up the environment:
export PATH=$PATH:~/.ec2/bin
export EC2_HOME=~/.ec2
export JAVA_HOME=/usr/lib/jvm/default-java
However, I failed to find a .ec2 folder anywhere. Where may I find it?
Also, can't I use the euca2ools instead of java? Why do we need java
anyway? Is that part of what AWS provides?
Sorry if the above seems very dumb questions... I'm not used to AWS yet.
Cheers,
Thomas
--
To UNSUBSCRIBE, email to debian-q...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Lucas Nussbaum
May 14, 2013, 1:10:02 PM5/14/13
to
On 14/05/13 at 18:05 +0200, Lucas Nussbaum wrote:
> You mission this time:
> - pick up ~100 random packages from the list of packages that failed to build on
> 2013-05-09 and are still marked TODO. it's a good idea to ignore the remaining
> GCC_ERROR bugs: those don't need to be filed.
> grep TODO failed.* | grep -v GCC_ERROR | cut -d ' ' -f 1 | shuf | head -n 100
> should give you something.
> - rebuild them. (use generate-tasks-rebuild with -i pkglist)
That should have been --include, not -i.
> You mission this time:
> - pick up ~100 random packages from the list of packages that failed to build on
> 2013-05-09 and are still marked TODO. it's a good idea to ignore the remaining
> GCC_ERROR bugs: those don't need to be filed.
> grep TODO failed.* | grep -v GCC_ERROR | cut -d ' ' -f 1 | shuf | head -n 100
> should give you something.
> - rebuild them. (use generate-tasks-rebuild with -i pkglist)
(Thanks nhandler for noticing.)
Lucas
--
To UNSUBSCRIBE, email to debian-q...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Lucas Nussbaum
May 14, 2013, 1:30:02 PM5/14/13
to
reservation. Yes, I must admit that so far I've been using the
EC2-provided tools, not the ones packaged in Debian. That's sthing that
should be looked into.
Lucas
--
To UNSUBSCRIBE, email to debian-q...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Nathan Handler
May 15, 2013, 5:00:02 PM5/15/13
to
On Tue, May 14, 2013 at 11:05 AM, Lucas Nussbaum <lu...@debian.org> wrote:
> You mission this time:
> - pick up ~100 random packages from the list of packages that failed to build on
> 2013-05-09 and are still marked TODO. it's a good idea to ignore the remaining
> GCC_ERROR bugs: those don't need to be filed.
> grep TODO failed.* | grep -v GCC_ERROR | cut -d ' ' -f 1 | shuf | head -n 100
> should give you something.
> - rebuild them. (use generate-tasks-rebuild with -i pkglist)
> - file 10 bugs using everything described above.
> (make sure to double-check the content of the emails, esp. the URLs.
> Those are hardcoded, so you could hack ./lib/collab-qa/log-parser.rb
> to put your own URL for now. In the future, it should be customizable
> differently (env variables? small config file ?))
> - commit the bug numbers to the list for 20130509.
> - report here. :)
I have successfully filed my 10 bugs (relevant files at [1]). I will
> You mission this time:
> - pick up ~100 random packages from the list of packages that failed to build on
> 2013-05-09 and are still marked TODO. it's a good idea to ignore the remaining
> GCC_ERROR bugs: those don't need to be filed.
> grep TODO failed.* | grep -v GCC_ERROR | cut -d ' ' -f 1 | shuf | head -n 100
> should give you something.
> - rebuild them. (use generate-tasks-rebuild with -i pkglist)
> - file 10 bugs using everything described above.
> (make sure to double-check the content of the emails, esp. the URLs.
> Those are hardcoded, so you could hack ./lib/collab-qa/log-parser.rb
> to put your own URL for now. In the future, it should be customizable
> differently (env variables? small config file ?))
> - commit the bug numbers to the list for 20130509.
> - report here. :)
commit the bug numbers to the list for 20130509 as soon as my request
to join collab-qa on alioth is approved.
Nathan
[1] http://people.debian.org/~nhandler/.ec2/
--
To UNSUBSCRIBE, email to debian-q...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Boris Pek
May 16, 2013, 8:50:03 AM5/16/13
to
Hi Nathan,
> I have successfully filed my 10 bugs (relevant files at [1]). I will
> commit the bug numbers to the list for 20130509 as soon as my request
> to join collab-qa on alioth is approved.
>
> [1] http://people.debian.org/~nhandler/.ec2/
Please remove all strings with error [2] from your list because this bug
was already fixed. See [3] for details.
And I am going to close related bugs which you recently opened. So do not
worry about them.
[2] FTBFS: xtime.hpp:23:5: error: expected identifier before numeric
[3] http://bugs.debian.org/695826
Best regards,
Boris
--
To UNSUBSCRIBE, email to debian-q...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Archive: http://lists.debian.org/3509413...@web6e.yandex.ru
> I have successfully filed my 10 bugs (relevant files at [1]). I will
> commit the bug numbers to the list for 20130509 as soon as my request
> to join collab-qa on alioth is approved.
>
Please remove all strings with error [2] from your list because this bug
was already fixed. See [3] for details.
And I am going to close related bugs which you recently opened. So do not
worry about them.
[2] FTBFS: xtime.hpp:23:5: error: expected identifier before numeric
[3] http://bugs.debian.org/695826
Best regards,
Boris
--
To UNSUBSCRIBE, email to debian-q...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Lucas Nussbaum
May 16, 2013, 12:00:04 PM5/16/13
to
On 15/05/13 at 15:33 -0500, Nathan Handler wrote:
> On Tue, May 14, 2013 at 11:05 AM, Lucas Nussbaum <lu...@debian.org> wrote:
> > You mission this time:
> > - pick up ~100 random packages from the list of packages that failed to build on
> > 2013-05-09 and are still marked TODO. it's a good idea to ignore the remaining
> > GCC_ERROR bugs: those don't need to be filed.
> > grep TODO failed.* | grep -v GCC_ERROR | cut -d ' ' -f 1 | shuf | head -n 100
> > should give you something.
> > - rebuild them. (use generate-tasks-rebuild with -i pkglist)
> > - file 10 bugs using everything described above.
> > (make sure to double-check the content of the emails, esp. the URLs.
> > Those are hardcoded, so you could hack ./lib/collab-qa/log-parser.rb
> > to put your own URL for now. In the future, it should be customizable
> > differently (env variables? small config file ?))
> > - commit the bug numbers to the list for 20130509.
> > - report here. :)
>
> I have successfully filed my 10 bugs (relevant files at [1]). I will
> commit the bug numbers to the list for 20130509 as soon as my request
> to join collab-qa on alioth is approved.
(approved)
> On Tue, May 14, 2013 at 11:05 AM, Lucas Nussbaum <lu...@debian.org> wrote:
> > You mission this time:
> > - pick up ~100 random packages from the list of packages that failed to build on
> > 2013-05-09 and are still marked TODO. it's a good idea to ignore the remaining
> > GCC_ERROR bugs: those don't need to be filed.
> > grep TODO failed.* | grep -v GCC_ERROR | cut -d ' ' -f 1 | shuf | head -n 100
> > should give you something.
> > - rebuild them. (use generate-tasks-rebuild with -i pkglist)
> > - file 10 bugs using everything described above.
> > (make sure to double-check the content of the emails, esp. the URLs.
> > Those are hardcoded, so you could hack ./lib/collab-qa/log-parser.rb
> > to put your own URL for now. In the future, it should be customizable
> > differently (env variables? small config file ?))
> > - commit the bug numbers to the list for 20130509.
> > - report here. :)
>
> I have successfully filed my 10 bugs (relevant files at [1]). I will
> commit the bug numbers to the list for 20130509 as soon as my request
> to join collab-qa on alioth is approved.
Lucas
--
To UNSUBSCRIBE, email to debian-q...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Lucas Nussbaum
May 16, 2013, 2:20:01 PM5/16/13
to
On 12/05/13 at 11:01 +0200, Lucas Nussbaum wrote:
> In order to make your life slightly easier (and to reduce a bit the risks in
> case of mistakes :) ), I've already reserved 5 "medium" instances for you. So
> you don't need to do the resources reservation steps of README. The list of
> those nodes is in /root/cloud-scripts/nodes.m1.medium.tutorial.
> It also means that you must run masternode with the --no-halt switch, so that
> nodes are not shut down are the end of the rebuild.
Hi,
> In order to make your life slightly easier (and to reduce a bit the risks in
> case of mistakes :) ), I've already reserved 5 "medium" instances for you. So
> you don't need to do the resources reservation steps of README. The list of
> those nodes is in /root/cloud-scripts/nodes.m1.medium.tutorial.
> It also means that you must run masternode with the --no-halt switch, so that
> nodes are not shut down are the end of the rebuild.
The nodes were shut down, so I've started 5 other nodes, still listed in
nodes.m1.medium.tutorial.
Please remember to use --no-halt!
Lucas
--
To UNSUBSCRIBE, email to debian-q...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
David Suarez
May 16, 2013, 4:10:01 PM5/16/13
to
I used it :)
Lucas Nussbaum
May 17, 2013, 2:50:01 AM5/17/13
to
Hi,
When you have done all three steps successfully, I will send you an
archive with the Debian QA EC2 account key. Using it, you can reserve
and terminate instances.
We use "spot instances" (instances at a lower price that can be
terminated by Amazon if the "market price" becomes higher than the price
we are offering). Generally, I use m2.xlarge instances, with several
"slots" per node (masternode's -s option).
See README, and check that you can successfully use
ec2-request-spot-instances, ec2-describe-instances, and
ec2-terminate-instances
Now, real work. We need to:
- do another full archive rebuild, and process all the results
- do a gcc4.8 rebuild. the contact for that is do...@debian.org. He told
that he would like to be notified before we start the rebuild, so that
he can update the packages.
- do a openjdk7 rebuild. The contact for that is nthy...@debian.org.
Please pick up one of the tasks, and coordinate here!
Let me know if you have questions.
Lucas
--
To UNSUBSCRIBE, email to debian-q...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Archive: http://lists.debian.org/20130517064...@xanadu.blop.info
When you have done all three steps successfully, I will send you an
archive with the Debian QA EC2 account key. Using it, you can reserve
and terminate instances.
We use "spot instances" (instances at a lower price that can be
terminated by Amazon if the "market price" becomes higher than the price
we are offering). Generally, I use m2.xlarge instances, with several
"slots" per node (masternode's -s option).
See README, and check that you can successfully use
ec2-request-spot-instances, ec2-describe-instances, and
ec2-terminate-instances
Now, real work. We need to:
- do another full archive rebuild, and process all the results
- do a gcc4.8 rebuild. the contact for that is do...@debian.org. He told
that he would like to be notified before we start the rebuild, so that
he can update the packages.
- do a openjdk7 rebuild. The contact for that is nthy...@debian.org.
Please pick up one of the tasks, and coordinate here!
Let me know if you have questions.
Lucas
--
To UNSUBSCRIBE, email to debian-q...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Lucas Nussbaum
May 17, 2013, 3:10:02 AM5/17/13
to
On 17/05/13 at 08:49 +0200, Lucas Nussbaum wrote:
> Now, real work. We need to:
> - do another full archive rebuild, and process all the results
> - do a gcc4.8 rebuild. the contact for that is do...@debian.org. He told
> that he would like to be notified before we start the rebuild, so that
> he can update the packages.
> - do a openjdk7 rebuild. The contact for that is nthy...@debian.org.
Forgot something:
> Now, real work. We need to:
> - do another full archive rebuild, and process all the results
> - do a gcc4.8 rebuild. the contact for that is do...@debian.org. He told
> that he would like to be notified before we start the rebuild, so that
> he can update the packages.
> - do a openjdk7 rebuild. The contact for that is nthy...@debian.org.
during my last archive rebuild, two packages's build hang, which is
rather painful to handle. Those were ns3 and gcc-snapshot.
Someone should try to reproduce that, investigate that, and file a
proper bug report.
Lucas
--
To UNSUBSCRIBE, email to debian-q...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
david suarez
May 17, 2013, 6:30:02 AM5/17/13
to
Hi,
>Forgot something:
>during my last archive rebuild, two packages's build hang, which is
>rather painful to handle. Those were ns3 and gcc-snapshot.
>Someone should try to reproduce that, investigate that, and file a
>proper bug report.
I'm still doing step3, so if Nathan wants to take the work.
Let me know about.Nathan Handler
May 17, 2013, 8:20:01 AM5/17/13
to
On Fri, May 17, 2013 at 5:21 AM, david suarez <david.s...@gmail.com> wrote:
>>Forgot something:
>>during my last archive rebuild, two packages's build hang, which is
>>rather painful to handle. Those were ns3 and gcc-snapshot.
>>Someone should try to reproduce that, investigate that, and file a
>>proper bug report.
>
> I'm still doing step3, so if Nathan wants to take the work.
No problem, I can take care of them later today.
>>Forgot something:
>>during my last archive rebuild, two packages's build hang, which is
>>rather painful to handle. Those were ns3 and gcc-snapshot.
>>Someone should try to reproduce that, investigate that, and file a
>>proper bug report.
>
> I'm still doing step3, so if Nathan wants to take the work.
Nathan
--
To UNSUBSCRIBE, email to debian-q...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
david suarez
May 17, 2013, 10:20:01 AM5/17/13
to
Hi,
Thanks Nathan. If i can help you later Ill ask you.
David
David Suárez
May 17, 2013, 4:30:02 PM5/17/13
to
On Viernes, 17 de mayo de 2013 08:49:14 Lucas Nussbaum escribió:
> Hi,
Hi,
I send a patch to add support for specifying output directory. Now, we can
work at same time.
The script on ec2 masternode is modified while the patch is accepted and
aplied. New option is '-d', see 'masternode -h' for help.
David
--
To UNSUBSCRIBE, email to debian-q...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Archive: http://lists.debian.org/201305180019.426...@gmail.com
> Hi,
>
> Please pick up one of the tasks, and coordinate here!
>
> Lucas
> Please pick up one of the tasks, and coordinate here!
>
Hi,
I send a patch to add support for specifying output directory. Now, we can
work at same time.
The script on ec2 masternode is modified while the patch is accepted and
aplied. New option is '-d', see 'masternode -h' for help.
David
--
To UNSUBSCRIBE, email to debian-q...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
David Suárez
May 18, 2013, 2:10:02 PM5/18/13
to
On Martes, 14 de mayo de 2013 18:05:28 Lucas Nussbaum escribió:
>
> When you are done filing bugs, you can replace all those NNN by actual bug
> numbers. For that, you need to use e.g.: cqa-importbugnumbers
> debi...@lists.debian.org qa-ftbfs-20130509 < $TODOFILE > tmp the two
> parameters are bug username and usertag.
>
> You mission this time:
> - pick up ~100 random packages from the list of packages that failed to
> build on 2013-05-09 and are still marked TODO. it's a good idea to ignore
> the remaining GCC_ERROR bugs: those don't need to be filed.
> grep TODO failed.* | grep -v GCC_ERROR | cut -d ' ' -f 1 | shuf | head -n
> 100 should give you something.
> - rebuild them. (use generate-tasks-rebuild with -i pkglist)
> - file 10 bugs using everything described above.
> (make sure to double-check the content of the emails, esp. the URLs.
> Those are hardcoded, so you could hack ./lib/collab-qa/log-parser.rb
> to put your own URL for now. In the future, it should be customizable
> differently (env variables? small config file ?))
> - commit the bug numbers to the list for 20130509.
> - report here. :)
Done, you can find logs at http://deiv.vzpla.net/
>
> When you are done filing bugs, you can replace all those NNN by actual bug
> numbers. For that, you need to use e.g.: cqa-importbugnumbers
> debi...@lists.debian.org qa-ftbfs-20130509 < $TODOFILE > tmp the two
> parameters are bug username and usertag.
>
> You mission this time:
> - pick up ~100 random packages from the list of packages that failed to
> build on 2013-05-09 and are still marked TODO. it's a good idea to ignore
> the remaining GCC_ERROR bugs: those don't need to be filed.
> grep TODO failed.* | grep -v GCC_ERROR | cut -d ' ' -f 1 | shuf | head -n
> 100 should give you something.
> - rebuild them. (use generate-tasks-rebuild with -i pkglist)
> - file 10 bugs using everything described above.
> (make sure to double-check the content of the emails, esp. the URLs.
> Those are hardcoded, so you could hack ./lib/collab-qa/log-parser.rb
> to put your own URL for now. In the future, it should be customizable
> differently (env variables? small config file ?))
> - commit the bug numbers to the list for 20130509.
> - report here. :)
Still need to commit bug numbers.
--
To UNSUBSCRIBE, email to debian-q...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
David Suárez
May 19, 2013, 6:20:02 AM5/19/13
to
On Viernes, 17 de mayo de 2013 09:04:19 Lucas Nussbaum escribió:
> On 17/05/13 at 08:49 +0200, Lucas Nussbaum wrote:
> > Now, real work. We need to:
> > - do another full archive rebuild, and process all the results
> > - do a gcc4.8 rebuild. the contact for that is do...@debian.org. He told
> > that he would like to be notified before we start the rebuild, so that
> > he can update the packages.
> > - do a openjdk7 rebuild. The contact for that is nthy...@debian.org.
>
> Forgot something:
> during my last archive rebuild, two packages's build hang, which is
> rather painful to handle. Those were ns3 and gcc-snapshot.
> Someone should try to reproduce that, investigate that, and file a
> proper bug report.
>
> Lucas
Hi,
> On 17/05/13 at 08:49 +0200, Lucas Nussbaum wrote:
> > Now, real work. We need to:
> > - do another full archive rebuild, and process all the results
> > - do a gcc4.8 rebuild. the contact for that is do...@debian.org. He told
> > that he would like to be notified before we start the rebuild, so that
> > he can update the packages.
> > - do a openjdk7 rebuild. The contact for that is nthy...@debian.org.
>
> Forgot something:
> during my last archive rebuild, two packages's build hang, which is
> rather painful to handle. Those were ns3 and gcc-snapshot.
> Someone should try to reproduce that, investigate that, and file a
> proper bug report.
>
> Lucas
We have to coordinate here.
Nathan have you started with some of the tasks ?
David
--
To UNSUBSCRIBE, email to debian-q...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Lucas Nussbaum
May 21, 2013, 8:50:01 AM5/21/13
to
Hi,
Someone terminated the master node (by mistake). I've restarted it, and
re-added the SSH keys.
The new master node address is ec2-107-22-58-191.compute-1.amazonaws.com
If you had logs on it, they are lost, unfortunately.
Lucas
Someone terminated the master node (by mistake). I've restarted it, and
re-added the SSH keys.
The new master node address is ec2-107-22-58-191.compute-1.amazonaws.com
If you had logs on it, they are lost, unfortunately.
Lucas
Lucas Nussbaum
May 21, 2013, 2:50:02 PM5/21/13
to
Please, guys. The "master" node must never be stopped or terminated. If
you grep through instances, make sure to exclude m1.small instances to
exclude it.
Its new address is ec2-54-224-232-135.compute-1.amazonaws.com
Lucas
--
To UNSUBSCRIBE, email to debian-q...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
David Suárez
Jun 2, 2013, 9:40:02 AM6/2/13
to
Hi,
On Viernes, 17 de mayo de 2013 08:49:14 Lucas Nussbaum escribió:
I dont know what other tasks is doing Nathan.
Could you tell me what is your status here Nathan ? Could I help with any of
the others ones ?
Thanks,
David
--
To UNSUBSCRIBE, email to debian-q...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Archive: http://lists.debian.org/201306021530.021...@gmail.com
On Viernes, 17 de mayo de 2013 08:49:14 Lucas Nussbaum escribió:
> Now, real work. We need to:
> - do another full archive rebuild, and process all the results
> - do a gcc4.8 rebuild. the contact for that is do...@debian.org. He told
> that he would like to be notified before we start the rebuild, so that
> he can update the packages.
> - do a openjdk7 rebuild. The contact for that is nthy...@debian.org.
>
> Please pick up one of the tasks, and coordinate here!
Full archive rebuild done.
> - do another full archive rebuild, and process all the results
> - do a gcc4.8 rebuild. the contact for that is do...@debian.org. He told
> that he would like to be notified before we start the rebuild, so that
> he can update the packages.
> - do a openjdk7 rebuild. The contact for that is nthy...@debian.org.
>
> Please pick up one of the tasks, and coordinate here!
I dont know what other tasks is doing Nathan.
Could you tell me what is your status here Nathan ? Could I help with any of
the others ones ?
Thanks,
David
--
To UNSUBSCRIBE, email to debian-q...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Lucas Nussbaum
Jun 3, 2013, 2:50:01 AM6/3/13
to
Hi,
On 02/06/13 at 15:30 +0200, David Suárez wrote:
> Hi,
>
> On Viernes, 17 de mayo de 2013 08:49:14 Lucas Nussbaum escribió:
> > Now, real work. We need to:
> > - do another full archive rebuild, and process all the results
> > - do a gcc4.8 rebuild. the contact for that is do...@debian.org. He told
> > that he would like to be notified before we start the rebuild, so that
> > he can update the packages.
> > - do a openjdk7 rebuild. The contact for that is nthy...@debian.org.
> >
> > Please pick up one of the tasks, and coordinate here!
>
> Full archive rebuild done.
Yeah \o/
On this side, once you have waited for the feedback (in case of possible
mistakes you could have done), the goal is of course to get to zero
failures not linked to a bug by doing other rebuilds. ;)
Lucas
--
To UNSUBSCRIBE, email to debian-q...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Archive: http://lists.debian.org/2013060306...@xanadu.blop.info
On 02/06/13 at 15:30 +0200, David Suárez wrote:
> Hi,
>
> On Viernes, 17 de mayo de 2013 08:49:14 Lucas Nussbaum escribió:
> > Now, real work. We need to:
> > - do another full archive rebuild, and process all the results
> > - do a gcc4.8 rebuild. the contact for that is do...@debian.org. He told
> > that he would like to be notified before we start the rebuild, so that
> > he can update the packages.
> > - do a openjdk7 rebuild. The contact for that is nthy...@debian.org.
> >
> > Please pick up one of the tasks, and coordinate here!
>
> Full archive rebuild done.
On this side, once you have waited for the feedback (in case of possible
mistakes you could have done), the goal is of course to get to zero
failures not linked to a bug by doing other rebuilds. ;)
Lucas
--
To UNSUBSCRIBE, email to debian-q...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
0 new messages