On Wed, 18 Jan 2017 17:20:26 +0100 Ludwig Nussel <[email protected]> wrote:
> [if there were replies for this on the list only I didn't get them] > > Any update here? One more idea, that can really helps in less expensive way ( regarding changes to our build system ). See current topic on @research mailing list ( internal sorry ). Maybe we can build our tarball with tar -cv --mtime=@0 --owner=0 --group=0 \ --pax-option=exthdr.name=%d/PaxHeaders/%f,atime:=0,ctime:=0,mtime:=0 \ -f tar2.tar h so it will be same even if created on different machines. Will this work for you? Josef > > Josef Reidinger wrote: > > during silent time between christmass and new year Ludwig contact me > > ( in CC ), that they have problem to see that we have same source > > for SP3 and factory. In general problem is that it is created by two > > different jenkins worker, so in the end tarballs have different > > timestamps and for scripts it is different tarballs unless they > > implement non-trivial comparison. > > > Ludwig also have some ideas how to solve it. One is using link from > > OBS to IBS. Then remaining challenge is to create submit requests > > in IBS. One idea can be to have jenkins workers that only send sr. > > Another idea I have which can be even easier is to simply have job > > that compare version of SP3 and Devel:YaST:SP3 and if it differs, > > then create submit request. If we do it in reasonable times ( like > > once in a hour ), then I think it is good balance between > > performance and up to date source. > > Last week I talked with Adrian and mls. One open feature request for > them is to somehow allow automatic triggering of submit requests > within obs if a build succeeded. So in the longer run obs itself may > help speeding this up. > > > We also have one more challenge and it is how to make external > > worker more reliable as currently we have only one external worker > > for yast, so we should add some redundancy here. It probably need > > some discussion if we can e.g. provide some of our VMs to operate on > > external network. > > > > Any more ideas? Or do you thing that we do not need to care about > > binary incompatibility? > > We do need to care, otherwise sources are simply not identical. > > cu > Ludwig > -- To unsubscribe, e-mail: [email protected] To contact the owner, e-mail: [email protected]
