10:17 p.m.
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
2:04 a.m.
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 <mrunge(a)matthias-runge.de>
4:17 a.m.
Hello Matthias,
On Tue, Aug 22, 2017 at 9:04 AM, Matthias Runge <mrunge(a)matthias-runge.de>
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 <mrunge(a)matthias-runge.de>
_______________________________________________
devel mailing list -- devel(a)lists.fedoraproject.org
To unsubscribe send an email to devel-leave(a)lists.fedoraproject.org
4:29 a.m.
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
6:35 a.m.
Hello Mikolaj,
On Tue, Aug 22, 2017 at 11:29 AM, Mikolaj Izdebski <mizdebsk(a)redhat.com>
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(a)lists.fedoraproject.org
To unsubscribe send an email to devel-leave(a)lists.fedoraproject.org
5:07 a.m.
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
6:51 a.m.
Hey Kamil,
On Tue, Aug 22, 2017 at 12:07 PM, Kamil Dudka <kdudka(a)redhat.com> 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(a)lists.fedoraproject.org
To unsubscribe send an email to devel-leave(a)lists.fedoraproject.org
9:40 a.m.
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 <kdudka(a)redhat.com> 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(a)lists.fedoraproject.org
> To unsubscribe send an email to devel-leave(a)lists.fedoraproject.org
10:03 a.m.
On Tue, Aug 22, 2017 at 4:40 PM, Kamil Dudka <kdudka(a)redhat.com> 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 <kdudka(a)redhat.com> 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(a)lists.fedoraproject.org
> > To unsubscribe send an email to devel-leave(a)lists.fedoraproject.org
10:15 a.m.
On Tuesday, August 22, 2017 5:03:06 PM CEST Michal Novotny wrote:
On Tue, Aug 22, 2017 at 4:40 PM, Kamil Dudka
<kdudka(a)redhat.com> 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 <kdudka(a)redhat.com> 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
9:10 p.m.
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 <kdudka(a)redhat.com>:
On Tuesday, August 22, 2017 5:03:06 PM CEST Michal Novotny wrote:
> On Tue, Aug 22, 2017 at 4:40 PM, Kamil Dudka <kdudka(a)redhat.com> 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 <kdudka(a)redhat.com>
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(a)lists.fedoraproject.org
To unsubscribe send an email to devel-leave(a)lists.fedoraproject.org
3:09 a.m.
Hello Rudolf,
On Thu, Aug 24, 2017 at 4:10 AM, Rudolf Kastl <che666(a)gmail.com> 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 <kdudka(a)redhat.com>:
> On Tuesday, August 22, 2017 5:03:06 PM CEST Michal Novotny wrote:
> > On Tue, Aug 22, 2017 at 4:40 PM, Kamil Dudka <kdudka(a)redhat.com> 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
<kdudka(a)redhat.com>
> 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(a)lists.fedoraproject.org
> To unsubscribe send an email to devel-leave(a)lists.fedoraproject.org
>
5:39 a.m.
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
3:46 a.m.
2017-08-22 5:17 GMT+02:00 Michal Novotny <clime(a)redhat.com>:
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.
6:58 a.m.
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
9:33 a.m.
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
2459
days inactive
2461
days old
15 comments
8 participants
participants (8)
-
Cheng Ye -
Juan Orti Alcaine -
Kamil Dudka -
Matthias Runge -
Michal Novotny -
Mikolaj Izdebski -
Miroslav Suchý -
Rudolf Kastl