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 >> problem. >> >> 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. Goodness. > And for the Arch:all packages? I guess no check for this with lazy > maintainer. > 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 -- Vanilla wafer. Manoj Srivastava <sriva...@debian.org> <http://www.debian.org/~srivasta/> 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org