Mailinglist Archive: yast-devel (53 mails)

< Previous Next >
Re: [yast-devel] Re: SP3 and factory have different binary sources
On Wed, 18 Jan 2017 17:20:26 +0100
Ludwig Nussel <lnussel@xxxxxxxx> 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 \,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 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.


To unsubscribe, e-mail: yast-devel+unsubscribe@xxxxxxxxxxxx
To contact the owner, e-mail: yast-devel+owner@xxxxxxxxxxxx

< Previous Next >
Follow Ups