builder bug: fetching patch from URL when it's already in CVS

Elan Ruusamäe glen at delfi.ee
Tue Apr 4 19:24:30 CEST 2006


On Tuesday 04 April 2006 18:09, Andrzej Krzysztofowicz wrote:
> Elan =?iso-8859-1?q?Ruusam=E4e?= wrote:
> > On Tuesday 04 April 2006 16:27, Jakub Bogusz wrote:
> > > $ ./builder -bp -r LINUX_2_6 kernel.spec
> > > [...]
> > > --15:21:35--  http://bluetooth-alsa.sourceforge.net/sco-mtu.patch
> > >            => `sco-mtu.patch'
> > > [...]
> > > cvs server: move away sco-mtu.patch; it is in the way
> > > C sco-mtu.patch
> > >
> > > builder shouldn't fetch anything from URLs given in SourceX/PatchX if
> > > it's present in CVS/distfiles and fetching from CVS/df is not disabled
> > > by command line option. And it didn't... till some day.
> > > It seems to be some bug introduced quite recently.
> >
> > the  builder behavior was updated, to fetch first remote urls, and then
> > group cvs up to one single execution. the speedup was 3 minutes vs 3
> > seconds for kernel.spec! and with this technology how can builder know if
> > file exists in cvs/df without fetching it via cvs up/wget?
> >
> > i noticed the bug too, and i wasn't sure is it worth to fix, as if the
> > source patch and patch in cvs are identical, there's no such warning
> > issued. so in most cases just update the patch in SOURCES?
>
> The main intention for disabling fetching sources by builders from URLs
> were security reasons. Maybe the new behaviour should be optional, for
> disabling it on builders?
it doesn't change for src-builders, as builders always use *only* 
SOURCES/distfiles, no url fetching.

> > and if url and sources are not identical then there should not put full
> > url in specfile.
>
> AFAIR, some sources change periodically; having an URL for them and not
> using distfiles you can easily know when they change and the md5 needs to
> be updated. Why to disable this feature?
it's rather side effect ;)
and there was speaken PATCHx (which have no md5), not SOURCEx, and afaik 
SOURCEx is not affected.

-- 
glen


More information about the pld-devel-en mailing list