On 07. 11. 19 9:55, Fabio Valentini wrote:
> On Thu, Nov 7, 2019, 09:25 Miro Hrončok <mhroncok(a)redhat.com
> <mailto:mhroncok@redhat.com>> wrote:
>
> On 06. 11. 19 23:10, Randy Barlow wrote:
> > On Wed, 2019-11-06 at 21:32 +0100, Miro Hrončok wrote:
> >> Is there any good way to get notified about this sort of problems in
> >> timely manner prior to the update being pushed? This is currently not
> >> optimal.
> >
> > I'm not familiar with an existing solution to this problem, but I
agree
> > that it is not optimal.
> >
> > I had a chat or three with Brian Stinson about some ways we could deal
> > with problems like this. Today, when we CI packages (i.e., Bodhi
> > gating), we typically just run the tests associated with the package
> > being altered. Brian suggested that we could *also* run the tests of
> > the packages that depend on the package being altered, against the
> > altered package. This way if a change to something (like pyramid) would
> > break a dependent package's tests (such as cornice), then the update
> > for pyramid should get a failed test result on its tests tab. The
> > problem is that this does increase the load on the test system greatly,
> > but perhaps we can get enough hardware to make that OK. Not sure.
>
>
> Having this sort of CI would be awesome, however it looks like it's not on
the
> top of the TODO list:
>
> RFE: Koschei-like CI (opened 8 months ago)
>
https://pagure.io/fedora-ci/general/issue/45
>
> RFE: Check if dependent packages install (opened 8 months ago)
>
https://pagure.io/fedora-ci/general/issue/46
>
> Support automatic execution of tests of dependent components (opened 1 year
ago)
>
https://pagure.io/fedora-ci/general/issue/7
>
>
> And either way, since CI is opt-in, I would need to go and setup CI for all of
> dependencies (including transitive) of all my packages. I haven't really
> checked
> how big is this tree but I suppose it is enormous.
>
>
> Would an automated daily report (like the broken rawhide deps report that we
> used to have) help? I could hack that together for different fedora branches +
> updates-testing pretty easily, and adding notifications when a broken dependency
> gets added in -testing wouldn't be hard either.
I've mostl started this thread to see if I indeed need to script this.
If you could look into it, ut would be awesome.
This is very useful as starting point (rawhide example):
$ sudo dnf --repo=rawhide makecache
$ installcheck x86_64 /var/cache/dnf/rawhide*.solv*
(Igor has shown this to me at Flock.)
It would probably need some interface that let me filter my packages. And
multi-repo for released Fedora.
This is what we use for Python 2 in rawhide:
https://github.com/fedora-python/portingdb/blob/master/portingdb/check_ft...
Oh, I didn't know installcheck existed.
I've used repoclosure to get unsatisfied dependencies for all packages
(including unsatisfied BRs).
My initial work is here:
I'll set up a cron job to generate and push this data daily.
Once (or if) the list of broken stuff ever gets smaller I can also set
up automated notifications ...
Fabio
> --
> Miro Hrončok
> --
> Phone: +420777974800
> IRC: mhroncok
> _______________________________________________
> devel mailing list -- devel(a)lists.fedoraproject.org
> To unsubscribe send an email to devel-leave(a)lists.fedoraproject.org
> Fedora Code of Conduct: