Re: COPR strategy
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
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
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
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
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 >> ___ >> devel mailing list -- devel@lists.fedoraproject.org >> To u
Re: COPR strategy
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
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
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
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
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
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
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
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
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
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
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
