On Jun 22, Lars Wirzenius wrote
> The following sequence of commands:
>
> dpkg-source -x foo.dsc
> cd foo-something
> dpkg-buildpackage -b -rsudo -us -uc
i switched to use debian/rules binary, debian/rules clean and
dpkg-genchanges in my script (why should dpkg-buildpackage call clean or
generate a diff or dsc file (that is turned of with -us -us i suppose) ?).
> If there is an error, the build will stop, but there is too much output
> to easily see all warnings and some minor errors that don't stop the
> build.
yes. but i don't know, what we can do here ? with normal compiling,
every gcc call creates a line of output. and if the package is sed-ing
some files, creating html/info/whatever documentation, we get a lot of
output.
> I doubt that the speed of the net connection is important, as long
> as you can transfer everything to your machine. The actual build
> can and must be automated.
that's not a problem. currently i scan one directory for new *.dsc
files, and build them (if they are not already in the list of *dsc files
proceded). i could change that to work with an source/ mirror of debian
packages (changing ${Incoming}/*.dsc to ${Incoming}/*/*.dsc :-).
> About 480 packages built properly, and about 200 had problems.
> Some packages had problems because they needed -dev versions
> of libraries I had neglected to install. I didn't post the
> full list because I hadn't investigated everything, and didn't
> want to point fingers.
hey, 480 packages built properly is still a good goal.
do you have log files of the other packages ? maybe a team could look at
them. most other packages will not need much work, i think.
regards, andreas
--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
[EMAIL PROTECTED] .
Trouble? e-mail to [EMAIL PROTECTED] .
