Re: alpine_1.0+dfsg-2_source.changes REJECTED
* Cyril Brulebois <cyril.brulebois@enst-bretagne.fr> [080112 12:13]:
> But nothing ensures it is built in a chroot, which might occasion
> disparities between uploaded binaries and built-on-the-buildd-network
> binaries.
Binaries do not need a chroot, just a clean unstable environment.
While a minimal chroot is good to test against missing
build-dependencies, a full real-world system is needed to test for
missing build-conflicts or configure switches to disable specific
autodetections.
So when you get disparities between a package build in a pure unstable
environment and on a buildd or a minimal chroot, that is not a bug
in the process but a bug in the package, which would not be catched
when only using buildds.
> And no log is available for that build. Not to mention the
> disparities between (build-)dependencies' versions in case the package
> stays in NEW for some time.
disparities can also happen with differently fast buildds or just by the
differences of the different architectures. Things should be able to
work with this.
> I find it a shame to rely on everyone to upload binaries to save time on
> Debian resources, rather than having a comprehensive and reliable buildd
> network.
Please, don't argue against things by claiming stupid reasons and then
arguing how stupid those reasons are. And for source only uploads please
take a look at Ubuntu. I really hope we do not want to go that path and
up with totally unuseable packages (in the sense of can't possibly ever
do the single thing that package is there for) ending up in stable releases.
> About the above: it's not like i386 is a rare architecture and
> it isn't possible to find some machines that could act as build daemons.
There is a i386 buildd. Quite some people are uploading amd64 packages.
I personally usually only upload sparc binaries with my sources.
Sometimes the i386 buildd makes problems, sometimes another buildd.
Nothing specific with i386 here.
Hochachtungsvoll,
Bernhard R. Link
Reply to: