Re: New release
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On Thu, 2017-09-07 at 22:46 +0200, Michal Novotny wrote: > Hello! > > We have just released new COPR stack. There is one big important > change: > > SRPMs are now built on builders before they get imported into > DistGit. Does it enable "external repositories"? Because I need patched RPM to build SRPM. > > There will be more to follow regarding SRPM generation. > > Thank you for building on COPR > COPR team > ___ > copr-devel mailing list -- copr-devel@lists.fedorahosted.org > To unsubscribe send an email to copr-devel- > le...@lists.fedorahosted.org - -- - -Igor Gnatenko -BEGIN PGP SIGNATURE- iQIzBAEBCAAdFiEEhLFO09aHZVqO+CM6aVcUvRu8X0wFAlmyRCgACgkQaVcUvRu8 X0ysCBAAnF8Jx2PIjWPQOKvmng81lyW43HllXZcxkPfA0Wery9qOA4DeNwQeY3sO VVD4F7J8wp3CMTWJmQPPq7iQ8FOsFj/1QUkdkGrWE+oNUc/iKbiDx3kn8PrhROKz fJxcIYHAMdFhNBQdh1T+a9yOXDP32qvUN4V9BhFWZNhISNSV7YlChUyi0vXa828L iI5EF86ISFI7nv2494ipyluhrCP9SzhaCmo1UeUhRcdZM1di0IrKVVtkwsKH8D+S nzAFZYdibQMi+ZLpHyps9GLHlAqSvx0cFdYOfSazYz8+8zBDPeAeeeJIsRyHKm/Z Vo/N+DzcDKNCdJBkwCOG350bORk2n+Z9NeuuzIbpuf18O4d3xkAvb3Bh9E0JQU6N Ve1BrCFiUwfL5umzO37Kr0bbX46kkN5rA1hcOBN2B0cgtjiCRFa4jbQGKXJpF7Ba 2YA3OcpMVyY+5FbCk2rHQZC+/EkJnKQRbjRD2aqzsZx7CebqFoCnBxlBIYBtzrzR CeYxDLl9m3zKuDXo71oC4WJt54oYvq9TLYLanvd0oOoIiOop2T3xDGN57PFrcl+e oliMShwqLah4FG+ppF10s9C86rNEvkM6ubsYhZ87Nw3SbZpAdKXkqKKRDu/4KpCo /4hSBb1Q6IywOm9V2g+SGDaMmeFa0BMEeLr0o+hmcyiOjIenQWI= =bpPU -END PGP SIGNATURE- ___ copr-devel mailing list -- copr-devel@lists.fedorahosted.org To unsubscribe send an email to copr-devel-le...@lists.fedorahosted.org
Re: CI projects in Copr
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On Wed, 2017-08-23 at 13:47 +0200, Miroslav Suchý wrote: > Hi, Hi, > I am gathering informations about various use of CI with Copr. Do you > use Copr for building packages for nightlies? For > building packages before pull request is merged? Do you have your set > up described somewhere? What is the name of your > project? We do! Both. Our project name is: DNF So our setup is pretty simple, our tool clones multiple repositories locally, builds SRPMs for them (it might be spec in upstream or upstream repo + downstream spec) and then creates temporary COPR repository and builds RPMs in there. Then we download those RPMs locally and do something with them (build container with them and run many tests). > > Please let me know. Either here or via private reply. > It will help me to understand your use of Copr and to make Copr > better. I would like to see: * only one and supported / good API * probably ability for some good integration with custom tools as we use (rpm-gitoverlay) * or ability to push custom specs / sources into git repo so we don't need to build SRPMs locally, we would just do git commit + git push and COPR would build everything * "Temporary" repositories -- repositories which automatically getting removed after some time, we need such repos for pull request testing and after few weeks no one will look into / use them, so it can be safely removed * Faster builds (for 7-8 packages we are building, it takes ~20 minutes to build because we do it sequentially, but we can't do anything about that), probably some re-use of builders or faster spawning builds would help here, not sure * auto-rebuilds like koschei does (but I don't really want to see koschei as separate service, it should be built-in for better integration). Ideally this should be in Fedora/Koji as well, but it really depends what's COPR is aiming to do > > Thanks in advance. > > Miroslav Suchy > ___ > copr-devel mailing list -- copr-devel@lists.fedorahosted.org > To unsubscribe send an email to copr-devel-leave@lists.fedorahosted.o > rg - -- - -Igor Gnatenko -BEGIN PGP SIGNATURE- iQIzBAEBCAAdFiEEhLFO09aHZVqO+CM6aVcUvRu8X0wFAlmdgHgACgkQaVcUvRu8 X0w63w/9GS6eMuw2WIrbNSZeZbmxKg2kWIG5NwLHLQrHUEmEcAPRUa2X8+rao62w XQduQeA3tWR7Hktxr5GFGYxVe/5zQ5uFQQrfTyJKan8rryzOvs8xPbcNbH6VcWyJ qVAzbbQMIAmHFZItHmvxrCbJgRYmlTCQnDGSpYVrwfnXiGSq/vHu3AvnxBUdZuSz PFaDP1kfgfS/BpB9hD91AiuAKySCcfc74DpMVA3NXIbldum5UX8HtVID0EWglKf7 XmGttLQ5ng1vxZqRVf/6fFt2frj5ZYlEUlRYiLHk66uNGJ0aP1DkAAPCVaNoVtqw A7ZXWjVxRJshYZnEZuKLtQvq1QYAvNjT3zcoiJ8Pf7E8TXHZsEn//Cu2Lyjtzl3b NiqrHQaZa5nwKB4NYfZY1EZFcvNSHZjDyN67iaisoVU4swmoCIvak5hOjhuxNzdg Clcel8BXzI0S5XwuvrZBOfDBXa6bs6Ffkwj5EQmiXQH013zGAGg+RMAxRdAnRiqF eEthDiXlMcEWmt/FRjy/z5t4n4VXsAtgytT+zTksaoXQAJdJJAL0J43fYUfqGTyS Nq1kZ/Li7KExCa8B9jZ1VViIuZruYlqDtUQWdNBRm2vKPvngcL56PhmRkMUq5Btu ExCXvfMXaRmFSLQhej5q/K182KpycawR4Z1C/NVzm92iWOUMCIw= =VqpT -END PGP SIGNATURE- ___ copr-devel mailing list -- copr-devel@lists.fedorahosted.org To unsubscribe send an email to copr-devel-le...@lists.fedorahosted.org
Re: New COPR release
On Tue, 2017-02-28 at 15:33 +0100, Michal Novotny wrote: > Hey folks, > > updated COPR stack has been just deployed into production. This > included > several steps: > > 1) new release of copr-frontend (1.107-1) has been deployed > The main features of this release include re-enabling fedora-rawhide > as > chroot names, compatibility with python2-flask-whooshee-0.4.1-2, and > finally updates related to support of Module Build Service (MBS). What means this magic version number? is it some special build of flak- whooshee or what? > > 2) copr-backend was redeployed for mock 1.3.4 support > The backend configuration was updated to support the new mock 1.3.4. > Note > that fedora-26-* chroots will not work until the respective > repositories > are publicly available. Before, rawhide repositories were used for > f26 > chroots but today, that needed to be changed for the rawhide > branching. > Mainly because of this unpleasant config switching, we decided that > returning fedora-rawhide -* back is the best option. It will be kept > as > long as mock keeps it. We run on mock and we need to play with it > well. > Note that previous backend rawhide repositories are available in your > backend directories "-backup" suffixed. Otherwise, we are starting > from > scratch there and new repositories will be auto-created for the new > rawhide > builds. We are also starting fresh on copr-dist-git where the > previous > master branch has been renamed to master-backup and new master is > ready for > you. > > 3) a long-standing copr-keygen issue "Keygen service error" has been > hopefully fixed > This issue should no longer occur (at least not for the same reason). > Let > me know if it runs well. We'll see :) > > There are still unsolved network problems, which cause COPR to > underperform > these days while also requiring day-to-day copr-backend service > stop/starts. We are now going to debug these into depth. > > The ultimate goal now is to make COPR stable and reliable. > > Thank you > COPR team > _______ > copr-devel mailing list -- copr-devel@lists.fedorahosted.org > To unsubscribe send an email to copr-devel-leave@lists.fedorahosted.o > rg -- -Igor Gnatenko signature.asc Description: This is a digitally signed message part ___ copr-devel mailing list -- copr-devel@lists.fedorahosted.org To unsubscribe send an email to copr-devel-le...@lists.fedorahosted.org
Re: upcoming branching
On Mon, 2017-02-20 at 21:28 +0100, Michal Novotny wrote: > On Mon, Feb 20, 2017 at 8:20 PM, Igor Gnatenko <ignate...@redhat.com> > wrote: > > > On Mon, 2017-02-20 at 16:16 +0100, Michal Novotny wrote: > > > Hello, > > > > > > as soon as branching is done and f26 repo links become available, > > > we > > > will > > > switch the current fedora-26-* chroots from rawhide to use the > > > f26 > > > repositories. > > > > I'm more interested in fedora-27-* being added... > > > > Hello, are you in favor of adding fedora-27 or rather fedora-rawhide > back? > This is more general question to the crowd. Both are technically > possible > but the question is what is less confusing. Does anything of it bring > you > less work? f26 -> f27 -> etc has probably higher maintenance cost. it depends. if you are planning to do mass-rebuild after branching in all copr repos, then I prefer rawhide. If not, I prefer fXY. > > > > > > > > COPR team > > > ___ > > > copr-devel mailing list -- copr-devel@lists.fedorahosted.org > > > To unsubscribe send an email to copr-devel-leave@lists.fedorahost > > > ed.o > > > rg > > > > -- > > -Igor Gnatenko > > ___ > > copr-devel mailing list -- copr-devel@lists.fedorahosted.org > > To unsubscribe send an email to copr-devel-leave@lists.fedorahosted > > .org > > > > > > ___ > copr-devel mailing list -- copr-devel@lists.fedorahosted.org > To unsubscribe send an email to copr-devel-leave@lists.fedorahosted.o > rg -- -Igor Gnatenko signature.asc Description: This is a digitally signed message part ___ copr-devel mailing list -- copr-devel@lists.fedorahosted.org To unsubscribe send an email to copr-devel-le...@lists.fedorahosted.org
Re: upcoming branching
On Mon, 2017-02-20 at 16:16 +0100, Michal Novotny wrote: > Hello, > > as soon as branching is done and f26 repo links become available, we > will > switch the current fedora-26-* chroots from rawhide to use the f26 > repositories. I'm more interested in fedora-27-* being added... > > COPR team > ___ > copr-devel mailing list -- copr-devel@lists.fedorahosted.org > To unsubscribe send an email to copr-devel-leave@lists.fedorahosted.o > rg -- -Igor Gnatenko signature.asc Description: This is a digitally signed message part ___ copr-devel mailing list -- copr-devel@lists.fedorahosted.org To unsubscribe send an email to copr-devel-le...@lists.fedorahosted.org
COPR shows "failed", but in fact build succeeded
https://copr.fedorainfracloud.org/coprs/rpmsoftwaremanagement/rpm-gitoverlay-1480969917.509235/build/485123/ -- -Igor Gnatenko ___ copr-devel mailing list -- copr-devel@lists.fedorahosted.org To unsubscribe send an email to copr-devel-le...@lists.fedorahosted.org
Re: New release of Copr
On Thu, Jun 16, 2016 at 3:10 PM, Miroslav Suchy <msu...@redhat.com> wrote: > Hi, > I just upgraded Copr instance to new version. > > There is one big change. You can now lower priority of your build. > It was introduced to easy rebuild of rubygems and pypi. But it can be used > by CI systems later. > > Copr-cli from our git, has --background option already. It lowers the > priority. But due compatibility reason we will not push the package into > main Fedora and we will wait one or two weeks. Looks like it was not implemented in client_v2 in python-copr... > > If you want to give it try, then you can install it from our copr project. > > Mirek > ___ > copr-devel mailing list > copr-devel@lists.fedorahosted.org > https://lists.fedorahosted.org/admin/lists/copr-devel@lists.fedorahosted.org -- -Igor Gnatenko ___ copr-devel mailing list copr-devel@lists.fedorahosted.org https://lists.fedorahosted.org/admin/lists/copr-devel@lists.fedorahosted.org
Re: Packaging upstream with released tarballs in Copr
I think MockSCM is that what you need. - Original Message - > From: "Martin Novák" <mt...@seznam.cz> > To: copr-devel@lists.fedorahosted.org > Sent: Sunday, April 17, 2016 5:38:48 PM > Subject: Packaging upstream with released tarballs in Copr > > Hello, > > It appears there's currently no option to build a package by just a > SPEC file which contains valid Source0 URL. > > There's a project on GitHub with released tarballs, which I'd like to > package in Copr (and later in Fedora perhaps). The easiest method for > building that package in Copr for me would be to link a SPEC file from > my GitHub repository which I'd regulary update with new project > releases.* > > Copr however offers only Tito and Mock SCM builds. From what I read, > it seems to me that both methods expect upstream and packaging files > to be in same repository. Is it true? If not, is there any example of > a Tito/MockSCM project linking external tarball which builds on Copr? > > If yes, then maintaining a forked repository seems a bit cumbersome to > me. For each release Git tag in the upstream repository, I'd have to > create a new child tag for the release with a SPEC file and it doesn't > seem Tito automates this case so I'd have to cherry-pick the SPEC file > from my master branch and modify it. Of course I can automate this > with a script also in my master branch, but it feels "custom" to me. > Is there any proper method? > > > Even though I've researched the topic I'm still newbie to packaging > and Git so please have mercy. > > Thank you. > > > * Or linking repository and specifying subdirectory and SPEC file name > so that the repository could contain more projects and a project > could contain patches. > ___ > copr-devel mailing list > copr-devel@lists.fedorahosted.org > https://lists.fedorahosted.org/admin/lists/copr-devel@lists.fedorahosted.org > -- -Igor Gnatenko ___ copr-devel mailing list copr-devel@lists.fedorahosted.org https://lists.fedorahosted.org/admin/lists/copr-devel@lists.fedorahosted.org
