set target.

presumably just a cvs alias issue as I can check out the external_images module
directly

Hi Pavel,

Did you check out the new module 'external_images' introduced by CWS
iconswitching2? An alias for this module exists, at least it did so last friday.
But I am not shure whether it is in the global 'OpenOffice2' alias.

I used OpenOffice2 alias and it was not checked out. But it is there (at least now).

And what is worst - module check doesn't check its existence.

vq: can we add this directory to module checks? Are there other directories that
are not checked?

Probably  those modules which must be present but aren't built are not covered
by module check. This check uses module dependencies as desribed in build.lst
files. But there are explicit dependencies on default_images and extenal_images.
We of course can introduce such depencies somewhere, should be no problem. Add
'external_images' as prerequisite for 'instsetoo_native'.

The directory is also not available on the Windows machine, where I checked out
the sources from anoncvs during the build process.

I was wise enough to put logging for the checkout: no external_images there.
Command used:

cvs -d :pserver:anoncvs@anoncvs.services.openoffice.org:/cvs -z9 co -r
${VERSION} OpenOffice2 >ooo_${VERSION}_src.cvslog 2>&1 || { echo ERROR; exit; }

Joost->Pavel: When I checked out the source anonymously, yesterday, the
ooo_crystal_images-1.tar.gz was available within the module external_images.
Maybe you started your cvs -co -r too early.

btw.

I used 
cvs -d:pserver:anoncvs@anoncvs.services.openoffice.org:/cvs co -r OOB680_m1
OpenOffice2

Joost: I always start my builds (Build-1) after the milestone is announced as
ready. I aften do build before, but I never upload such builds. After the
milestone is announced as ready, I checkout it from tunnel to my machine, create
tarball for machines on my local network and start builds there.

Windows and Solaris machines are on fast Internet networks so they checkout
their sources from anoncvs before every build. This is really strange...

I'll add timestamps to the checkout script for future evidence.

-> Pavel: now I understand what your problem might be: cvs tagging wasn't
completely finished at the moment the milestone was announced as ready.

Joost, thst's rubbish. Tagging was completely done when the new milestone was
anounced. Especially that file had already been tagged during the weekend.

ja: I can confirm - I never start checkout without checking if
zlib/prj/build.lst is tagged. And it was tagged. But somehow, the last module in
the CVS alias was not checked out. We have seen something similar in the past
(was it unodevtools?).

JA: that was my understanding yesterday... The checkout I did anonymously
contained the external_images module and Caolan got it as well...so where's the
problem ?

I built successfully using the taglist from tinderbox.
http://go-oo.org/tinderbox/tags/tag-latest-master-list 

Since I doubt that that module-list is generated by hand, there should be an
automated way to generate the alias file.

However, that list doesn't match the current tag, e.g. there are modules listed
that have no files with the current tag.

Maybe Pavel remembers my question about module "fondu" and others on IRC.

beware-full build-log!
http://go-oo.org/tinderbox/gunzip.cgi?tree=OOB680_m1&full-log=1139913194.19471#9

I paste an excerpt here, so that you don't have to get that >30MB beast.
7             Creating shadow-tree
8             Done creating shadow-tree
9             Updating /home/cl/programming/shadow/ to OOB680_m1 ..
10            WARNING: testshl not in current checkout, but in module list!
11            WARNING: unzip not in current checkout, but in module list!
12            WARNING: drawinglayer not in current checkout, but in module list!
13            WARNING: fondu not in current checkout, but in module list!
14            WARNING: external_images not in current checkout, but in module list!

> Since I doubt that that module-list is generated by hand, there should be an
> automated way to generate the alias file.
> 
> However, that list doesn't match the current tag, e.g. there are modules listed
> that have no files with the current tag.

The module list is generated ba hand and it has to contain more modules than
currently needed. The problem here ist that we have to use the same alias
(module list) for current milestones as well as for former ones, f.e. OOo 2.0.0
. Therefore it is not possible to remove modules from that list which were
needed formerly but are obsolete nowadays.

> 9             Updating /home/cl/programming/shadow/ to OOB680_m1 ..
> 10            WARNING: testshl not in current checkout, but in module list!
> 11            WARNING: unzip not in current checkout, but in module list!
> 12            WARNING: drawinglayer not in current checkout, but in module list!
> 13            WARNING: fondu not in current checkout, but in module list!
> 14            WARNING: external_images not in current checkout, but in module
list!

Do I understand this right that 'external_images' was missing in your check out,
too? That's the same issue Pavel fell about. Why does a cvs checkout leave out
this last module allthough it is tagged correctly?

I think you misunderstood me.

> However, that list doesn't match the current tag, e.g. there are modules 
> listed that have no files with the current tag.

> The module list is generated ba hand and it has to contain more modules than
> currently needed.

I meant the module-list of the tinderbox, not the cvs-module list.

> 9             Updating /home/cl/programming/shadow/ to OOB680_m1 ..
> 10            WARNING: testshl not in current checkout, but in module list!
> 11            WARNING: unzip not in current checkout, but in module list!
> 12            WARNING: drawinglayer not in current checkout, but in module list!
> 13            WARNING: fondu not in current checkout, but in module list!
> 14            WARNING: external_images not in current checkout, but in module
list!

> Do I understand this right that 'external_images' was missing in your check 
> out, too? That's the same issue Pavel fell about.

Yes, it was missing from my checkout, but that was based on SRC680_m156 (and I
don't use the aliases anymore to update - only used it to do the initial checkout).

What my build-script does is to check whether the requested Milestone/CWS
matches that of the current checkout and create a shadow-script of the checkout.
If the current checkout doesn't match the required ones, it will update the
shadowtree using the module-list from tinderbox.

> Why does a cvs checkout leave out this last module allthough it is tagged 
> correctly?

No, the script then checkouts the modules that are listed in tinderbox, but do
not appear on disk.

But from those additional modules, external_images is the only one that actually
is tagged with the desired tag:
$ pwd
/home/cl/programming/shadow
$ ls testshl unzip drawinglayer fondu external_images
ls: testshl: No such file or directory
ls: unzip: No such file or directory
ls: drawinglayer: No such file or directory
ls: fondu: No such file or directory
external_images:
CVS/  ooo_crystal_images-1.tar.gz

e.g. the others are either no longer needed or not yet integrated.

############################
The point I was trying to make is, that the Tinderbox knows about these modules,
 so to me it seems possible to align the cvs-modules files accordingly & in an
automated way, similar to how the tinderbox-tag-list is created (Although I have
no idea how that list is achieved)

To avoid some confusion,

> I built successfully using the taglist from tinderbox.
> http://go-oo.org/tinderbox/tags/tag-latest-master-list 
>
> Since I doubt that that module-list is generated by hand, there should be an
> automated way to generate the alias file.

that list is generated with:
<http://cvs.gnome.org/viewcvs/ooo-build/bin/tag-latest-master?view=markup>

So this "module list" is just the filtered output of the OpenOffice2 alias of a
cvs co -c.

Why am I the owner of this issue?

From IRC:

Creating empty external_images/prj/build.lst and adding external_images to
instsetoo_native/prj/build.lst should be enough.

Thanks ause.

I'll test it and cws it.

.

Adding external_images to instsetoo_native/prj/build.lst is what I meant yesterday:
>  We of course can introduce such depencies somewhere, should be no problem. Add
> 'external_images' as prerequisite for 'instsetoo_native'.
Is it really necessary to add a dummy build.lst in external_images itself? Does
not make sense to me, but I have not checked build.pl how it collects its
dependencies. Just try it.

After adding external_images to instsetoo_native/prj/build.lst (appended it
after postprocess):

oo@oo:~/BuildDir/ooo_OOB680_m1_src/instsetoo_native> build --all --show 2>&1|head -5
build -- version: 1.145

Fetching dependencies for module external_images from solver... failed...
Fetching from CVS...  failed

oo@oo:~/BuildDir/ooo_OOB680_m1_src/instsetoo_native> mkdir ../external_images/prj
oo@oo:~/BuildDir/ooo_OOB680_m1_src/instsetoo_native> touch
../external_images/prj/build.lst
oo@oo:~/BuildDir/ooo_OOB680_m1_src/instsetoo_native> build --all --show 2>&1|head -5
build -- version: 1.145


=============
Building project external_images
oo@oo:~/BuildDir/ooo_OOB680_m1_src/instsetoo_native> 

So we have to create empty build.lst or handle such directories in a special way.

ause: is it ok for you to create empty build.lst file there.

I do not like it ;-)

i don't like it either...

and i'm also split how to go on with it.
to populate all modules with an empty build.lst is a quick way to solve the
checkmodules problem.
on the other hand it seems wrong to me as these modules rather represent some
kind of storage than something to build. from my point of view, build.pl, the
tool to _build_ modules, shouldn't have to care about these modules at all.

not 2.0.3 related...

WONTFIX (for now).

No clear/clean solution at hand.

.