Re: Build logs from local builds
On Mon, Oct 26 2009, Adam Majer wrote:
> On Wed, Oct 21, 2009 at 01:27:05PM +0200, Samuel Thibault wrote:
>> I confirm that usually not having the i386 or amd64 log is often a
>> One idea that was floating around was to have buildd always recompile
>> the package, even on archs the uploader has provided a binary version
>> for, to make sure packages are clean. That would somehow answer you
>> need (i.e. provide a build log for _all_ archs).
> Or here's a radical idea - allow source only uploads of packages.
And thus allow people to upload without ever building locally.
> People are lazy and like myself don't want to sync pbuilder and
> related stuff every time I want to upload something. Since my box is
> rarely up to date, this can result in dependencies lagging
> somewhat compared to official buildd. I generally don't check for any
> build-depends problems anyway with pbuilder unless buildd chokes.
> And for the Arch:all packages? I guess no check for this with lazy
> So how do I compare with the other maintainers? Or do all maintainers
> run pbuilder religiously for each upload?
I can't speak for everyone, but I have a single command to start
with a git working dir, fire up a virtual machine, build the package,
twice, and save the logs and all. Two more commands for lintian and
piuparts checks. ANd then install and test.
Essentially 3 commands, one of which is also the final commit to
the repo. And every saturday, I get a new root fs (I could do it more
often, but once a week has sufficed for most weeks).
> The requirement not allowing source only uploads is childish at best -
> it treats DD as children that can't check their packages compile on
> their own box.
Apparently, we can't depend on them to actually update their
pbuilder setup and check build dependencies. I doubt that building will
be so very important to lazy developers.
> I'm all in favour of removing uploaded binaries. But also allow source
> only uploads.
Given the stated inability to even sync pbuilder, I think it
would result in even more degraded quality of implementation.
Manoj Srivastava <email@example.com> <http://www.debian.org/~srivasta/>
1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C