[Qa-jenkins-dev] dpkg, apt and dose3 do not agree in many synthetic dependency situations involving multiarch

[Holger Levsen]

Hi josch,

On Fri, Aug 19, 2016 at 01:20:39PM +0200, Johannes Schauer wrote:
> Good idea! Lets name it dpkg_apt_dose3_solvers_agree then.
 
cool!

> > And then I wonder, for which package(s) this job does this or these tests?
> > for all?
> No, it runs this for 8624 synthetically created dependency situations.

why those 8624 situations? how where they chosen or created?

> I named it *_sid because the job is run *on* sid not because the job tests
> packages *from* sid.

those "dependency situations" are not taken from sid?

> > Also, please reflect what the job does in description: 'Build the master
> > branch of https://gitlab.mister-muffin.de/josch/deb-m-a-dep-check'
> 
> Okay, I will write:
> 
> | Checks if dose3, apt and dpkg agree on how to resolve the relationships
> | between two packages.

hm. see my questions above ;)

> > Last and probably *not* least, I dislike that the actual test code is living
> > on another server, I would much prefer to run code from stable or at least
> > sid or from jenkins.d.n.git - but then we have other jobs like this already…
> 
> I do not mind to put my code elsewhere. What do you mean by running the code
> from stable or sid? To upload the testing code as a package to Debian main? I'm
> afraid that the code will not be useful besides for this jenkins job. Which
> location of the git repository would be most comfortable for you?

I'd prefer to have it in jenkins.d.n.git but I see how this ain't
useful…

> > Do you plan to upload deb-m-a-dep-check to sid anytime soon? (Or why is it a
> > Debian package? (Which I conclude from the shell command to be run, I havent
> > actually looked at the git repo ;)
> 
> It is a Debian package because I was told that this allows to easily set up the
> dependencies that my job needs in the chroot. This way, the requirements for
> the job are self-contained inside the git repository in a machine readable way
> and do not live elsewhere. Another advantage is, that users who want to try it
> out themselves, do not have to install the dependencies on their machines
> manually but can just run sbuild or pbuilder which will then install the
> dependencies inside the chroot for them and run the script as part of the
> "build process".

hm, ok.

> > > > Running it takes about 40 minutes and currently requires that you are on
> > > > amd64
> > 
> > is it single-threaded or will it benefit from multiple cores?
> 
> It can be made to run in parallel very easily via xargs. If running it on X
> cores instead is a better choice for jenkins than having long runtimes on a
> single core, then I can add this.

yes, please do.

> I just naively thought that jenkins would
> prefer to have long running jobs that does not stress many cores much at the
> same time.

no, exactly the opposite: fast running jobs are better for the user
experience and we have lots of cores which should be used.
 
> No, this number improved considerably and now they agree in 72% of the test
> cases.
 
if I only understand what's been tested here…

> > I think there should be a job run for stretch too, with the same frequency
> > and probably a monthly run job for jessie as well.
> 
> As no packages from Debian main are tested, a job run on sid is sufficient.

I see…


-- 
cheers,
	Holger
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 811 bytes
Desc: Digital signature
URL: <http://lists.alioth.debian.org/pipermail/qa-jenkins-dev/attachments/20160824/0b4de9ad/attachment.sig>