Re: COPR strategy

[Miroslav Suchý]

Dne 24.8.2017 v 13:58 Cheng Ye napsal(a):

Hi,

Making the builddir accessible for failed build would be helpful. Some test 
suits will store log in a file in buildir without echoing anything else 
helpful. Without access to  builddir, it could be difficult to debug.  However, 
copying the builddir from mock directory to somewhere accessible could be a 
cumbersome task.



Mock actually support this.
https://github.com/rpm-software-management/mock/wiki/Plugin-ChrootScan

The question is how to define this in Copr per package? As every package will 
need different artifacts.

Mirek
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: COPR strategy

[Cheng Ye]

Hi,

Making the builddir accessible for failed build would be helpful. Some test 
suits will store log in a file in buildir without echoing anything else 
helpful. Without access to  builddir, it could be difficult to debug.  However, 
copying the builddir from mock directory to somewhere accessible could be a 
cumbersome task. 

Thanks,
Ye Cheng
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: COPR strategy

[Miroslav Suchý]

Dne 24.8.2017 v 04:10 Rudolf Kastl napsal(a):

Hey,

I am currently maintaining llvm trunk and mesa git snapshot repos for f25 and f26 at: 
https://copr.fedorainfracloud.org/coprs/che.


One thing i would love to see is the ability to have a buildrepo and a release repo and beeing able to sync from build 
to release once a complete buildchain successfully built.


More thorough description of the problem and a possible solution:

* you have a dependency chain of 3 packages to build
* you need to regen repos after each package because the next package in the tree depends on the first one. (like clang 
on llvm)

* then after building the first 2 packages the 3rd package breaks ... you end 
up with a broken dep chain in the repo.



You can do that:

* go to Settings of project
* Check "Create repositories manually"

Build your 3 packages. During this stage your new builds will not be in available in project repository, but will be 
available via special /devel/ repository, which is available during build time in your Copr project.

So your users will not see those package, but your builds will see it.

You can even test it if it works if you change baseurl and append /devel/ to 
the end of url.

Once finished go to the main page of your project and in right column click on "Regenerate" in "Regenerate Repositories" 
form.


Finally you can go to Settings and uncheck "Create repositories manually".

Mirek
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: COPR strategy

[Juan Orti Alcaine]

2017-08-22 5:17 GMT+02:00 Michal Novotny :
> Hello,
>
> we will have soon a planning meeting that should determine a more long-term
> strategy and bring us to a team agreement on what COPR currently is and what
> it should be in half a year or so.
>
> I would like to kindly ask for some input here on the devel list to find out
> what the actual expectations of COPR are and if there are any ideas about
> what could COPR bring to the game.
>

Hi,

I would like to be able to build for more arches, mainly arm.
I guess the limitation is because hardware for that architecture is
needed. Is not possible to cross-build the packages?
It would be great if the noarch packages were available to all architectures.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: COPR strategy

[Michal Novotny]

Hello Rudolf,

On Thu, Aug 24, 2017 at 4:10 AM, Rudolf Kastl  wrote:

> Hey,
>
> I am currently maintaining llvm trunk and mesa git snapshot repos for f25
> and f26 at: https://copr.fedorainfracloud.org/coprs/che.
>
> One thing i would love to see is the ability to have a buildrepo and a
> release repo and beeing able to sync from build to release once a complete
> buildchain successfully built.
>
> More thorough description of the problem and a possible solution:
>
> * you have a dependency chain of 3 packages to build
> * you need to regen repos after each package because the next package in
> the tree depends on the first one. (like clang on llvm)
> * then after building the first 2 packages the 3rd package breaks ... you
> end up with a broken dep chain in the repo.
>
> Now a workaround would be to do scratch builds first and then final repo
> builds. But e.g. for llvm (only the llvm library) that means... over 100
> minutes buildtime using 4 builders (32bit / 64bit for 2 distro versions).
>
> What i would love to see is to be able to build in one repository and then
> send (copy/rsync whatever) the built chain over to a release repository.
> This way also testing is possible before pushing the stuff to consumers.
>
>
So, this is interesting. This is something like auto-forking from one
project to another after a successful batch build (under development). It
actually could work just inside one project if the batch building would be
done separately from the main project repo and only be included if
successful. Ok, thanks for this input. I think we can do something about
this.


> kind regards,
> Rudolf Kastl
>
>
>
> 2017-08-22 17:15 GMT+02:00 Kamil Dudka :
>
>> On Tuesday, August 22, 2017 5:03:06 PM CEST Michal Novotny wrote:
>> > On Tue, Aug 22, 2017 at 4:40 PM, Kamil Dudka  wrote:
>> > > On Tuesday, August 22, 2017 1:51:44 PM CEST Michal Novotny wrote:
>> > > > Hey Kamil,
>> > > >
>> > > > On Tue, Aug 22, 2017 at 12:07 PM, Kamil Dudka 
>> wrote:
>> > > > > On Tuesday, August 22, 2017 9:04:24 AM CEST Matthias Runge wrote:
>> > > > > > - the ability to directly upload srpms; that is, one can store
>> spec
>> > > > > >
>> > > > > >   files etc. on the local machine. I'm undecided, if
>> integrating a
>> > > > > >   distgit on copr would solve any issues or would introduce
>> more,
>> > >
>> > > like
>> > >
>> > > > > >   diverging specs.
>> > > > >
>> > > > > Building packages from dist-git is already possible via 'copr
>> > > > > buildfedpkg'.
>> > > > > The problem is that the last time I tried, it only worked for the
>> > >
>> > > official
>> > >
>> > > > > Fedora branches.  All attempts to build something from a
>> > >
>> > > private-kdudka-*
>> > >
>> > > > > branch failed with the well known "Could not find the dist from
>> branch
>> > > > > name"
>> > > > > failure of fedpkg.  Unless arbitrary dist-git branches are
>> suported,
>> > >
>> > > the
>> > >
>> > > > > 'copr buildfedpkg' command is pretty useless.
>> > > >
>> > > > Actually, we already support arbitrary dist-git branches in COPR
>> > >
>> > > Sounds good.  I wanted to check this:
>> > >
>> > > % copr buildfedpkg --branch private-kdudka-libcurl-nss --clone-url
>> > > https://src.fedoraproject.org/rpms/curl.git kdudka/tmp
>> > >
>> > > Build was added to tmp:
>> > >   https://copr.fedorainfracloud.org/coprs/build/592748/
>> > >
>> > > Created builds: 592748
>> > > Watching build(s): (this may be safely interrupted)
>> > >
>> > >   16:20:56 Build 592748: importing
>> > >
>> > > But the task hangs indefinitely in the "importing" state.  You can see
>> > > that
>> > > http://copr-dist-git.fedorainfracloud.org/per-task-logs/592748.log
>> still
>> > > grows with obvious periodicity.
>> > >
>> > > Am I doing anything wrong?
>> >
>> > Uh, not really. fedpkg was not installed on the production machine thus
>> the
>> > import was failing.
>> > Note that this is still slightly under development but it should
>> definitely
>> > work as a feature in
>> > any case.
>>
>> OK.  Thank you for working on it!  I am looking forward to use it one
>> day...
>>
>> > > Kamil
>> > >
>> > > > and we also aim
>> > > > to be able to build from any dist-git (at least being based on
>> > > > https://src.fedoraproject.org/rpms/dist-git).
>> > > >
>> > > > Currently we also support building from copr-dist-git in addition to
>> > >
>> > > Fedora
>> > >
>> > > > DistGit but
>> > > > we need to reflect that in our API and in copr-cli interface by
>> renaming
>> > > > the subcommand.
>> > > > (or providing the new generic one while keeping the old one for some
>> > >
>> > > time)
>> > >
>> > > > Then there is actually also the new rpkg client (based on pyrpkg
>> lib):
>> > > > https://src.fedoraproject.org/rpms/rpkg-client
>> > > > that you can use for launching COPR builds from any dist-git repo
>> being
>> > > > locally checked out.
>> > > >
>> > > > > Kamil
>> 

Re: COPR strategy

[Rudolf Kastl]

Hey,

I am currently maintaining llvm trunk and mesa git snapshot repos for f25
and f26 at: https://copr.fedorainfracloud.org/coprs/che.

One thing i would love to see is the ability to have a buildrepo and a
release repo and beeing able to sync from build to release once a complete
buildchain successfully built.

More thorough description of the problem and a possible solution:

* you have a dependency chain of 3 packages to build
* you need to regen repos after each package because the next package in
the tree depends on the first one. (like clang on llvm)
* then after building the first 2 packages the 3rd package breaks ... you
end up with a broken dep chain in the repo.

Now a workaround would be to do scratch builds first and then final repo
builds. But e.g. for llvm (only the llvm library) that means... over 100
minutes buildtime using 4 builders (32bit / 64bit for 2 distro versions).

What i would love to see is to be able to build in one repository and then
send (copy/rsync whatever) the built chain over to a release repository.
This way also testing is possible before pushing the stuff to consumers.

kind regards,
Rudolf Kastl



2017-08-22 17:15 GMT+02:00 Kamil Dudka :

> On Tuesday, August 22, 2017 5:03:06 PM CEST Michal Novotny wrote:
> > On Tue, Aug 22, 2017 at 4:40 PM, Kamil Dudka  wrote:
> > > On Tuesday, August 22, 2017 1:51:44 PM CEST Michal Novotny wrote:
> > > > Hey Kamil,
> > > >
> > > > On Tue, Aug 22, 2017 at 12:07 PM, Kamil Dudka 
> wrote:
> > > > > On Tuesday, August 22, 2017 9:04:24 AM CEST Matthias Runge wrote:
> > > > > > - the ability to directly upload srpms; that is, one can store
> spec
> > > > > >
> > > > > >   files etc. on the local machine. I'm undecided, if integrating
> a
> > > > > >   distgit on copr would solve any issues or would introduce more,
> > >
> > > like
> > >
> > > > > >   diverging specs.
> > > > >
> > > > > Building packages from dist-git is already possible via 'copr
> > > > > buildfedpkg'.
> > > > > The problem is that the last time I tried, it only worked for the
> > >
> > > official
> > >
> > > > > Fedora branches.  All attempts to build something from a
> > >
> > > private-kdudka-*
> > >
> > > > > branch failed with the well known "Could not find the dist from
> branch
> > > > > name"
> > > > > failure of fedpkg.  Unless arbitrary dist-git branches are
> suported,
> > >
> > > the
> > >
> > > > > 'copr buildfedpkg' command is pretty useless.
> > > >
> > > > Actually, we already support arbitrary dist-git branches in COPR
> > >
> > > Sounds good.  I wanted to check this:
> > >
> > > % copr buildfedpkg --branch private-kdudka-libcurl-nss --clone-url
> > > https://src.fedoraproject.org/rpms/curl.git kdudka/tmp
> > >
> > > Build was added to tmp:
> > >   https://copr.fedorainfracloud.org/coprs/build/592748/
> > >
> > > Created builds: 592748
> > > Watching build(s): (this may be safely interrupted)
> > >
> > >   16:20:56 Build 592748: importing
> > >
> > > But the task hangs indefinitely in the "importing" state.  You can see
> > > that
> > > http://copr-dist-git.fedorainfracloud.org/per-task-logs/592748.log
> still
> > > grows with obvious periodicity.
> > >
> > > Am I doing anything wrong?
> >
> > Uh, not really. fedpkg was not installed on the production machine thus
> the
> > import was failing.
> > Note that this is still slightly under development but it should
> definitely
> > work as a feature in
> > any case.
>
> OK.  Thank you for working on it!  I am looking forward to use it one
> day...
>
> > > Kamil
> > >
> > > > and we also aim
> > > > to be able to build from any dist-git (at least being based on
> > > > https://src.fedoraproject.org/rpms/dist-git).
> > > >
> > > > Currently we also support building from copr-dist-git in addition to
> > >
> > > Fedora
> > >
> > > > DistGit but
> > > > we need to reflect that in our API and in copr-cli interface by
> renaming
> > > > the subcommand.
> > > > (or providing the new generic one while keeping the old one for some
> > >
> > > time)
> > >
> > > > Then there is actually also the new rpkg client (based on pyrpkg
> lib):
> > > > https://src.fedoraproject.org/rpms/rpkg-client
> > > > that you can use for launching COPR builds from any dist-git repo
> being
> > > > locally checked out.
> > > >
> > > > > Kamil
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
>
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: COPR strategy

[Kamil Dudka]

On Tuesday, August 22, 2017 5:03:06 PM CEST Michal Novotny wrote:
> On Tue, Aug 22, 2017 at 4:40 PM, Kamil Dudka  wrote:
> > On Tuesday, August 22, 2017 1:51:44 PM CEST Michal Novotny wrote:
> > > Hey Kamil,
> > > 
> > > On Tue, Aug 22, 2017 at 12:07 PM, Kamil Dudka  wrote:
> > > > On Tuesday, August 22, 2017 9:04:24 AM CEST Matthias Runge wrote:
> > > > > - the ability to directly upload srpms; that is, one can store spec
> > > > > 
> > > > >   files etc. on the local machine. I'm undecided, if integrating a
> > > > >   distgit on copr would solve any issues or would introduce more,
> > 
> > like
> > 
> > > > >   diverging specs.
> > > > 
> > > > Building packages from dist-git is already possible via 'copr
> > > > buildfedpkg'.
> > > > The problem is that the last time I tried, it only worked for the
> > 
> > official
> > 
> > > > Fedora branches.  All attempts to build something from a
> > 
> > private-kdudka-*
> > 
> > > > branch failed with the well known "Could not find the dist from branch
> > > > name"
> > > > failure of fedpkg.  Unless arbitrary dist-git branches are suported,
> > 
> > the
> > 
> > > > 'copr buildfedpkg' command is pretty useless.
> > > 
> > > Actually, we already support arbitrary dist-git branches in COPR
> > 
> > Sounds good.  I wanted to check this:
> > 
> > % copr buildfedpkg --branch private-kdudka-libcurl-nss --clone-url
> > https://src.fedoraproject.org/rpms/curl.git kdudka/tmp
> > 
> > Build was added to tmp:
> >   https://copr.fedorainfracloud.org/coprs/build/592748/
> > 
> > Created builds: 592748
> > Watching build(s): (this may be safely interrupted)
> > 
> >   16:20:56 Build 592748: importing
> > 
> > But the task hangs indefinitely in the "importing" state.  You can see
> > that
> > http://copr-dist-git.fedorainfracloud.org/per-task-logs/592748.log still
> > grows with obvious periodicity.
> > 
> > Am I doing anything wrong?
> 
> Uh, not really. fedpkg was not installed on the production machine thus the
> import was failing.
> Note that this is still slightly under development but it should definitely
> work as a feature in
> any case.

OK.  Thank you for working on it!  I am looking forward to use it one day...

> > Kamil
> > 
> > > and we also aim
> > > to be able to build from any dist-git (at least being based on
> > > https://src.fedoraproject.org/rpms/dist-git).
> > > 
> > > Currently we also support building from copr-dist-git in addition to
> > 
> > Fedora
> > 
> > > DistGit but
> > > we need to reflect that in our API and in copr-cli interface by renaming
> > > the subcommand.
> > > (or providing the new generic one while keeping the old one for some
> > 
> > time)
> > 
> > > Then there is actually also the new rpkg client (based on pyrpkg lib):
> > > https://src.fedoraproject.org/rpms/rpkg-client
> > > that you can use for launching COPR builds from any dist-git repo being
> > > locally checked out.
> > > 
> > > > Kamil
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: COPR strategy

[Michal Novotny]

On Tue, Aug 22, 2017 at 4:40 PM, Kamil Dudka  wrote:

> On Tuesday, August 22, 2017 1:51:44 PM CEST Michal Novotny wrote:
> > Hey Kamil,
> >
> > On Tue, Aug 22, 2017 at 12:07 PM, Kamil Dudka  wrote:
> > > On Tuesday, August 22, 2017 9:04:24 AM CEST Matthias Runge wrote:
> > > > - the ability to directly upload srpms; that is, one can store spec
> > > >
> > > >   files etc. on the local machine. I'm undecided, if integrating a
> > > >   distgit on copr would solve any issues or would introduce more,
> like
> > > >   diverging specs.
> > >
> > > Building packages from dist-git is already possible via 'copr
> > > buildfedpkg'.
> > > The problem is that the last time I tried, it only worked for the
> official
> > > Fedora branches.  All attempts to build something from a
> private-kdudka-*
> > > branch failed with the well known "Could not find the dist from branch
> > > name"
> > > failure of fedpkg.  Unless arbitrary dist-git branches are suported,
> the
> > > 'copr buildfedpkg' command is pretty useless.
> >
> > Actually, we already support arbitrary dist-git branches in COPR
>
> Sounds good.  I wanted to check this:
>
> % copr buildfedpkg --branch private-kdudka-libcurl-nss --clone-url
> https://src.fedoraproject.org/rpms/curl.git kdudka/tmp
> Build was added to tmp:
>   https://copr.fedorainfracloud.org/coprs/build/592748/
> Created builds: 592748
> Watching build(s): (this may be safely interrupted)
>   16:20:56 Build 592748: importing
>
> But the task hangs indefinitely in the "importing" state.  You can see that
> http://copr-dist-git.fedorainfracloud.org/per-task-logs/592748.log still
> grows with obvious periodicity.
>
> Am I doing anything wrong?
>


Uh, not really. fedpkg was not installed on the production machine thus the
import was failing.
Note that this is still slightly under development but it should definitely
work as a feature in
any case.



>
> Kamil
>
> > and we also aim
> > to be able to build from any dist-git (at least being based on
> > https://src.fedoraproject.org/rpms/dist-git).
> >
> > Currently we also support building from copr-dist-git in addition to
> Fedora
> > DistGit but
> > we need to reflect that in our API and in copr-cli interface by renaming
> > the subcommand.
> > (or providing the new generic one while keeping the old one for some
> time)
> >
> > Then there is actually also the new rpkg client (based on pyrpkg lib):
> > https://src.fedoraproject.org/rpms/rpkg-client
> > that you can use for launching COPR builds from any dist-git repo being
> > locally checked out.
> >
> > > Kamil
> > > ___
> > > devel mailing list -- devel@lists.fedoraproject.org
> > > To unsubscribe send an email to devel-le...@lists.fedoraproject.org
>
>
>
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: COPR strategy

[Kamil Dudka]

On Tuesday, August 22, 2017 1:51:44 PM CEST Michal Novotny wrote:
> Hey Kamil,
> 
> On Tue, Aug 22, 2017 at 12:07 PM, Kamil Dudka  wrote:
> > On Tuesday, August 22, 2017 9:04:24 AM CEST Matthias Runge wrote:
> > > - the ability to directly upload srpms; that is, one can store spec
> > > 
> > >   files etc. on the local machine. I'm undecided, if integrating a
> > >   distgit on copr would solve any issues or would introduce more, like
> > >   diverging specs.
> > 
> > Building packages from dist-git is already possible via 'copr
> > buildfedpkg'.
> > The problem is that the last time I tried, it only worked for the official
> > Fedora branches.  All attempts to build something from a private-kdudka-*
> > branch failed with the well known "Could not find the dist from branch
> > name"
> > failure of fedpkg.  Unless arbitrary dist-git branches are suported, the
> > 'copr buildfedpkg' command is pretty useless.
> 
> Actually, we already support arbitrary dist-git branches in COPR

Sounds good.  I wanted to check this:

% copr buildfedpkg --branch private-kdudka-libcurl-nss --clone-url 
https://src.fedoraproject.org/rpms/curl.git kdudka/tmp
Build was added to tmp:
  https://copr.fedorainfracloud.org/coprs/build/592748/
Created builds: 592748
Watching build(s): (this may be safely interrupted)
  16:20:56 Build 592748: importing

But the task hangs indefinitely in the "importing" state.  You can see that
http://copr-dist-git.fedorainfracloud.org/per-task-logs/592748.log still
grows with obvious periodicity.

Am I doing anything wrong?

Kamil

> and we also aim
> to be able to build from any dist-git (at least being based on
> https://src.fedoraproject.org/rpms/dist-git).
> 
> Currently we also support building from copr-dist-git in addition to Fedora
> DistGit but
> we need to reflect that in our API and in copr-cli interface by renaming
> the subcommand.
> (or providing the new generic one while keeping the old one for some time)
> 
> Then there is actually also the new rpkg client (based on pyrpkg lib):
> https://src.fedoraproject.org/rpms/rpkg-client
> that you can use for launching COPR builds from any dist-git repo being
> locally checked out.
> 
> > Kamil
> > ___
> > devel mailing list -- devel@lists.fedoraproject.org
> > To unsubscribe send an email to devel-le...@lists.fedoraproject.org

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: COPR strategy

[Michal Novotny]

Hey Kamil,

On Tue, Aug 22, 2017 at 12:07 PM, Kamil Dudka  wrote:

> On Tuesday, August 22, 2017 9:04:24 AM CEST Matthias Runge wrote:
> > - the ability to directly upload srpms; that is, one can store spec
> >   files etc. on the local machine. I'm undecided, if integrating a
> >   distgit on copr would solve any issues or would introduce more, like
> >   diverging specs.
>
> Building packages from dist-git is already possible via 'copr buildfedpkg'.
> The problem is that the last time I tried, it only worked for the official
> Fedora branches.  All attempts to build something from a private-kdudka-*
> branch failed with the well known "Could not find the dist from branch
> name"
> failure of fedpkg.  Unless arbitrary dist-git branches are suported, the
> 'copr buildfedpkg' command is pretty useless.
>

Actually, we already support arbitrary dist-git branches in COPR and we
also aim
to be able to build from any dist-git (at least being based on
https://src.fedoraproject.org/rpms/dist-git).

Currently we also support building from copr-dist-git in addition to Fedora
DistGit but
we need to reflect that in our API and in copr-cli interface by renaming
the subcommand.
(or providing the new generic one while keeping the old one for some time)

Then there is actually also the new rpkg client (based on pyrpkg lib):
https://src.fedoraproject.org/rpms/rpkg-client
that you can use for launching COPR builds from any dist-git repo being
locally checked out.


>
> Kamil
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
>
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: COPR strategy

[Michal Novotny]

Hello Mikolaj,

On Tue, Aug 22, 2017 at 11:29 AM, Mikolaj Izdebski 
wrote:

> On 08/22/2017 11:17 AM, Michal Novotny wrote:
> >> - it would be great, if there is a possibility to trigger rebuilds on
> >>   dependent packages, like rebuild required packages after ABI bump.
> >>
> >
> > Right, this would be a nice option. I could imagine this being
> implemented
> > as a configurable fedmsg listener that would launch rebuilds on certain
> > events
> > like bumps of certain packages, branching event, and possibly others.
>
> This is implemented by Koschei. Not enabled until at least Copr frontend
> completes RFR process. I can enable it in staging sooner, provided that
> Koschei can get Copr credentials for authenticating through its API.
>
>
This would be cool! I am looking forward to exploring this.


>
> --
> Mikolaj Izdebski
> Software Engineer, Red Hat
> IRC: mizdebsk
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
>
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: COPR strategy

[Kamil Dudka]

On Tuesday, August 22, 2017 9:04:24 AM CEST Matthias Runge wrote:
> - the ability to directly upload srpms; that is, one can store spec
>   files etc. on the local machine. I'm undecided, if integrating a
>   distgit on copr would solve any issues or would introduce more, like
>   diverging specs.

Building packages from dist-git is already possible via 'copr buildfedpkg'.  
The problem is that the last time I tried, it only worked for the official 
Fedora branches.  All attempts to build something from a private-kdudka-* 
branch failed with the well known "Could not find the dist from branch name" 
failure of fedpkg.  Unless arbitrary dist-git branches are suported, the
'copr buildfedpkg' command is pretty useless.

Kamil
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: COPR strategy

[Mikolaj Izdebski]

On 08/22/2017 11:17 AM, Michal Novotny wrote:
>> - it would be great, if there is a possibility to trigger rebuilds on
>>   dependent packages, like rebuild required packages after ABI bump.
>>
> 
> Right, this would be a nice option. I could imagine this being implemented
> as a configurable fedmsg listener that would launch rebuilds on certain
> events
> like bumps of certain packages, branching event, and possibly others.

This is implemented by Koschei. Not enabled until at least Copr frontend
completes RFR process. I can enable it in staging sooner, provided that
Koschei can get Copr credentials for authenticating through its API.


-- 
Mikolaj Izdebski
Software Engineer, Red Hat
IRC: mizdebsk
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: COPR strategy

[Michal Novotny]

Hello Matthias,

On Tue, Aug 22, 2017 at 9:04 AM, Matthias Runge 
wrote:

> On Tue, Aug 22, 2017 at 05:17:56AM +0200, Michal Novotny wrote:
> > Hello,
> >
> > we will have soon a planning meeting that should determine a more
> long-term
> > strategy and bring us to a team agreement on what COPR currently is and
> > what it should be in half a year or so.
> >
> > I would like to kindly ask for some input here on the devel list to find
> > out what the actual expectations of COPR are and if there are any ideas
> > about what could COPR bring to the game.
>
> So, as a starter, what I really like about copr is:
>
> - it is actually a incubator, a tool to get packages or collections of
>   packages built. One can easily experiment without actually disturbing
>   other users. Copr lowers the entry barrier for new pacakgers.
>
> - the ability to directly upload srpms; that is, one can store spec
>   files etc. on the local machine. I'm undecided, if integrating a
>   distgit on copr would solve any issues or would introduce more, like
>   diverging specs.
>
> - the ability to include external repositories, like the one from CentOS
>   project.
>
>
Thanks! Good to hear what features are appreciated.



> What I would like to see:
>
> - maybe a easy possibility to build packages triggered by upstream
>   source changes. This is comparable to delorean[1]. I'm not sure if it
>   needs to be re-implemented.
>

We actually have this possibility implemented through SCM-1 and SCM-2
source types and webhook mechanism.


> - prioritization of manually uploaded tasks vs. automatic builds. If
>   that really lowers the waiting time for builds it to be discussed.
>   Maybe adding a "bulk" flag to tag builds as: build it, when a builder
>   is available, but it's not a priority. Send a message once the build
>   is done.
>

We have added --background tag which is very similar to --bulk tag you
are suggesting. It's a user option (choice) to tag a build like this if he
or she
wants to.


>
> - it would be great, if there is a possibility to trigger rebuilds on
>   dependent packages, like rebuild required packages after ABI bump.
>

Right, this would be a nice option. I could imagine this being implemented
as a configurable fedmsg listener that would launch rebuilds on certain
events
like bumps of certain packages, branching event, and possibly others.


>
>
> Thanks,
> Matthias
>
> [1] https://www.rdoproject.org/what/dlrn/
> --
> Matthias Runge 
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
>
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: COPR strategy

[Matthias Runge]

On Tue, Aug 22, 2017 at 05:17:56AM +0200, Michal Novotny wrote:
> Hello,
> 
> we will have soon a planning meeting that should determine a more long-term
> strategy and bring us to a team agreement on what COPR currently is and
> what it should be in half a year or so.
> 
> I would like to kindly ask for some input here on the devel list to find
> out what the actual expectations of COPR are and if there are any ideas
> about what could COPR bring to the game.

So, as a starter, what I really like about copr is:

- it is actually a incubator, a tool to get packages or collections of
  packages built. One can easily experiment without actually disturbing
  other users. Copr lowers the entry barrier for new pacakgers.

- the ability to directly upload srpms; that is, one can store spec
  files etc. on the local machine. I'm undecided, if integrating a
  distgit on copr would solve any issues or would introduce more, like
  diverging specs.

- the ability to include external repositories, like the one from CentOS
  project.

What I would like to see:

- maybe a easy possibility to build packages triggered by upstream
  source changes. This is comparable to delorean[1]. I'm not sure if it
  needs to be re-implemented.

- prioritization of manually uploaded tasks vs. automatic builds. If
  that really lowers the waiting time for builds it to be discussed.
  Maybe adding a "bulk" flag to tag builds as: build it, when a builder
  is available, but it's not a priority. Send a message once the build
  is done.

- it would be great, if there is a possibility to trigger rebuilds on
  dependent packages, like rebuild required packages after ABI bump.


Thanks,
Matthias

[1] https://www.rdoproject.org/what/dlrn/
-- 
Matthias Runge 
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

COPR strategy

[Michal Novotny]

Hello,

we will have soon a planning meeting that should determine a more long-term
strategy and bring us to a team agreement on what COPR currently is and
what it should be in half a year or so.

I would like to kindly ask for some input here on the devel list to find
out what the actual expectations of COPR are and if there are any ideas
about what could COPR bring to the game.

clime
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org