Re: Koschei update

[Mikolaj Izdebski]

On 05/21/2016 12:28 AM, Kevin Fenzi wrote:
> On Fri, 20 May 2016 09:10:58 -0600
> Orion Poplawski  wrote:
>> In some sense I think it's more important to be run for branched.
>> Are the branched builds run against updates-testing?  or only updates
>> + overrides? I'm thinking it would be better if it was the former.
> 
> I'm not sure koschei can do things differently here without additional
> build targets. I think it has to do scratch builds against
> base+stable+buildroot overrides just like any other build there would
> do.

Currently Koschei has to use a Koji build target, so unless a custom
target is added, it is what Kevin said.

But we are working on integration with Copr, which would allow things
like that. You would create your own Copr project, add any repos you
want and ask Koschei to run some builds there. You could build
potentially-breaking builds in Copr first and have them tested, it would
be possible to automatically test builds from upstream monitoring and so on.

-- 
Mikolaj Izdebski
Software Engineer, Red Hat
IRC: mizdebsk
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: Koschei update

[Kevin Fenzi]

On Fri, 20 May 2016 09:10:58 -0600
Orion Poplawski  wrote:

> I will just note that there definitely is a reasonable amount of
> churn in Rawhide that does tend to trigger notices of temporary build
> failures when say a soname was updated and dependent packages not yet
> built.  Personally I definitely appreciate the early detection of
> issues that koshei provides (and thanks again for a great tool), but
> I could imagine some people being annoyed.

I suppose thats true. Perhaps it could notify only after some time? 
But then if it notified everyone after some time no one would be fixing
things. 

> In some sense I think it's more important to be run for branched.
> Are the branched builds run against updates-testing?  or only updates
> + overrides? I'm thinking it would be better if it was the former.

I'm not sure koschei can do things differently here without additional
build targets. I think it has to do scratch builds against
base+stable+buildroot overrides just like any other build there would
do. 

kevin



pgpBSR91Qoq4J.pgp
Description: OpenPGP digital signature
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: Koschei update

[Orion Poplawski]

On 05/19/2016 10:52 AM, Kevin Fenzi wrote:
> On Thu, 19 May 2016 11:15:02 +0200
> Mikolaj Izdebski  wrote:
> 
>>> Perhaps we could look into just mass enabling it for all packages
>>> now?  
>>
>> Perhaps yes, but...
>>
>> Some people are not interested in Koschei at all.  It has been in
>> production for almost a year (and a few months more in Fedora cloud),
>> but less than 1/3 packages are enabled [2]. Maybe it's a problem of
>> awareness?
> 
> I think it's some awareness and some just lazyness. 
> 
> If there's no cases people can think of where the information would not
> be helpfull, perhaps we can just enable it for everything. 

I will just note that there definitely is a reasonable amount of churn in
Rawhide that does tend to trigger notices of temporary build failures when say
a soname was updated and dependent packages not yet built.  Personally I
definitely appreciate the early detection of issues that koshei provides (and
thanks again for a great tool), but I could imagine some people being annoyed.

In some sense I think it's more important to be run for branched.  Are the
branched builds run against updates-testing?  or only updates + overrides?
I'm thinking it would be better if it was the former.


-- 
Orion Poplawski
Technical Manager 303-415-9701 x222
NWRA, Boulder/CoRA Office FAX: 303-415-9702
3380 Mitchell Lane   or...@nwra.com
Boulder, CO 80301   http://www.nwra.com
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: Koschei update

[Kevin Fenzi]

On Thu, 19 May 2016 11:15:02 +0200
Mikolaj Izdebski  wrote:

> Since I heard several requests about that, I will try to enable EPEL 7
> (in staging for now).  If it goes well then we can think about
> enabling EPEL 6 or Fedora branches too.

ok. Thanks. There are many fewer epel7 packages than Fedora. 

> > Is there any reason these days not to enable it?   
> 
> There are some complains about Koschei's usage of Koji, so I wanted to
> be very careful with that.  But recently, thanks to Ralph Bean, a Koji
> feature was implemented [1] that should help mitigating the biggest
> problem I heard of.
> 
> > Perhaps we could look into just mass enabling it for all packages
> > now?  
> 
> Perhaps yes, but...
> 
> Some people are not interested in Koschei at all.  It has been in
> production for almost a year (and a few months more in Fedora cloud),
> but less than 1/3 packages are enabled [2]. Maybe it's a problem of
> awareness?

I think it's some awareness and some just lazyness. 

If there's no cases people can think of where the information would not
be helpfull, perhaps we can just enable it for everything. 
 
> I don't think we want to waste resources on rebuilding packages that
> no one wants to have in Koschei. Any packager, not only maintainer,
> can toggle Koschei flag in pkgdb2, so if someone wants they can just
> do it.

ok. I guess thats fair... perhaps we could enable it for a subset of
packages (ie all packages in important groups or something). 

Something to ponder on. 

kevin


pgpR9l7Tecyb4.pgp
Description: OpenPGP digital signature
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: Koschei update

[Mikolaj Izdebski]

On 05/19/2016 12:40 AM, Kevin Fenzi wrote:
> On Wed, 18 May 2016 05:03:51 +0200
> Mikolaj Izdebski  wrote:
>> Last week Koschei [1] was updated to latest upstream release (1.6.1).
>> The new version comes with one particularly interesting feature -
>> Koschei is now able to track more than one package collection at time,
>> which means that it could be possible to use it for Fedora branches
>> other than just rawhide, for EPEL, or even for side tags in Koji.
>> Currently only rawhide is enabled, but if there's enough interest then
>> it should be possible to enable other targets too.
> 
> I think it would be lovely if it were enabled for epel as well. 

Since I heard several requests about that, I will try to enable EPEL 7
(in staging for now).  If it goes well then we can think about enabling
EPEL 6 or Fedora branches too.

> Is there any reason these days not to enable it? 

There are some complains about Koschei's usage of Koji, so I wanted to
be very careful with that.  But recently, thanks to Ralph Bean, a Koji
feature was implemented [1] that should help mitigating the biggest
problem I heard of.

> Perhaps we could look into just mass enabling it for all packages now?

Perhaps yes, but...

Some people are not interested in Koschei at all.  It has been in
production for almost a year (and a few months more in Fedora cloud),
but less than 1/3 packages are enabled [2]. Maybe it's a problem of
awareness?

I don't think we want to waste resources on rebuilding packages that no
one wants to have in Koschei. Any packager, not only maintainer, can
toggle Koschei flag in pkgdb2, so if someone wants they can just do it.


[1] https://pagure.io/koji/pull-request/77
[2] As of time of wringing this, there are 22,030 packages (including
retired and EPEL-only packages).  6,197 packages are enabled in Koschei.

-- 
Mikolaj Izdebski
Software Engineer, Red Hat
IRC: mizdebsk
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: Koschei update

[Vít Ondruch]

Dne 19.5.2016 v 10:47 Mikolaj Izdebski napsal(a):
> On 05/18/2016 10:40 AM, Vít Ondruch wrote:
>> Could you please enable CI for ruby? Or actually the ruby-rails group
>> for every Fedora branch?
> It doesn't work this way. Once new targets are added to Koschei, all
> packages will be monitored there. It's all or nothing.
>

Ah, ok, then add them please ;)


V.

--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: Koschei update

[Mikolaj Izdebski]

On 05/18/2016 08:37 PM, Raphael Groner wrote:
> +1 branched/alpha (could help with upcoming mass rebuild issues)

Mass rebuilds are done in rawhide, before branching.

-- 
Mikolaj Izdebski
Software Engineer, Red Hat
IRC: mizdebsk
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: Koschei update

[Mikolaj Izdebski]

On 05/18/2016 10:40 AM, Vít Ondruch wrote:
> Could you please enable CI for ruby? Or actually the ruby-rails group
> for every Fedora branch?

It doesn't work this way. Once new targets are added to Koschei, all
packages will be monitored there. It's all or nothing.

-- 
Mikolaj Izdebski
Software Engineer, Red Hat
IRC: mizdebsk
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: Koschei update

[Kevin Fenzi]

On Wed, 18 May 2016 05:03:51 +0200
Mikolaj Izdebski  wrote:

> TL;DR Koschei now supports targets other than rawhide (not enabled
> yet) and should correctly handle weak and rich deps.
> 
> Full version:
> 
> Last week Koschei [1] was updated to latest upstream release (1.6.1).
> The new version comes with one particularly interesting feature -
> Koschei is now able to track more than one package collection at time,
> which means that it could be possible to use it for Fedora branches
> other than just rawhide, for EPEL, or even for side tags in Koji.
> Currently only rawhide is enabled, but if there's enough interest then
> it should be possible to enable other targets too.

I think it would be lovely if it were enabled for epel as well. 

Is there any reason these days not to enable it? 

Perhaps we could look into just mass enabling it for all packages now?

kevin


pgpAc6Z1PHCOY.pgp
Description: OpenPGP digital signature
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: Koschei update

[Raphael Groner]

> Koschei is now able to track more than one package collection at time,
> which means that it could be possible to use it for Fedora branches
> other than just rawhide, for EPEL, or even for side tags in Koji.
> Currently only rawhide is enabled, but if there's enough interest then
> it should be possible to enable other targets too.

+1 EPEL, at least 7
+1 branched/alpha (could help with upcoming mass rebuild issues)
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: Koschei update

[Vít Ondruch]

Hi Mikolaj,

This is sweet! Thx.


Could you please enable CI for ruby? Or actually the ruby-rails group
for every Fedora branch?


Best,


Vít



Dne 18.5.2016 v 05:03 Mikolaj Izdebski napsal(a):
> TL;DR Koschei now supports targets other than rawhide (not enabled
> yet) and should correctly handle weak and rich deps.
>
> Full version:
>
> Last week Koschei [1] was updated to latest upstream release (1.6.1).
> The new version comes with one particularly interesting feature -
> Koschei is now able to track more than one package collection at time,
> which means that it could be possible to use it for Fedora branches
> other than just rawhide, for EPEL, or even for side tags in Koji.
> Currently only rawhide is enabled, but if there's enough interest then
> it should be possible to enable other targets too.
>
> Along with the update, Koschei backend was reinstalled on Fedora 23
> system (instead of RHEL 7), which allowed us to use features of latest
> hawkey and libsolv - from now on Koschei correctly ignores weak
> dependencies and supports rich dependencies.
>
> [1] https://fedoraproject.org/wiki/Koschei
>
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org