Re: COPR src.fp.o auto-rebuilds

On Tue, Mar 20, 2018 at 1:22 PM, Michal Schorm <msch...@redhat.com> wrote: > Thanks for the tip. > I just started using it and it works great! :) > > I'm not hooking forked repository, but private branches instead. > The use case is to have multiple versions of package

Release monitoring for COPR

What's the best way to monitor for new releases on a package in copr? I know the release-monitoring.org has "COPR" as a distribution that it knows about, but I'm not sure if that's the same as the copr repositories we have available. I'm also not sure how to tell it which package in whi

Re: COPR src.fp.o auto-rebuilds

Michal Novotny wrote: >>>> >>>> >>>> Hello, >>>> >>>> you can now very easily setup auto-rebuilds for your src.fp.o package: >>>> >>>> 1) make a SCM package in COPR with Clone URL pointing to the src.fp.o >>&g

Re: COPR src.fp.o auto-rebuilds

> The use case is to have multiple versions of packages available in >> COPR - especially MariaDB 10.3 and MySQL 8 which are still in >> developement. > > Note that there are no "private" branches in Fedora. Everything is kept > forever and available for public. &

Re: COPR src.fp.o auto-rebuilds

ltiple versions of packages available in > COPR - especially MariaDB 10.3 and MySQL 8 which are still in > developement. Note that there are no "private" branches in Fedora. Everything is kept forever and available for public. - -- - -Igor Gnatenko -BEGIN PGP SIGNATURE

Re: COPR src.fp.o auto-rebuilds

Thanks for the tip. I just started using it and it works great! :) I'm not hooking forked repository, but private branches instead. The use case is to have multiple versions of packages available in COPR - especially MariaDB 10.3 and MySQL 8 which are still in developement. -- Michal Schorm

f28-ppc64le chroots finally working in COPR

Hello, the fedora-28-ppc64le chroot was no working up until now due to lack of compose. This was resolved however in issue. https://pagure.io/releng/issue/7357 clime ___ devel-announce mailing list -- devel-annou...@lists.fedoraproject.org To

f28-ppc64le chroots finally working in COPR

Hello, the fedora-28-ppc64le chroot was no working up until now due to lack of compose. This was resolved however in issue. https://pagure.io/releng/issue/7357 clime ___ devel-announce mailing list -- devel-announce@lists.fedoraproject.org To

COPR src.fp.o auto-rebuilds

Hello, you can now very easily setup auto-rebuilds for your src.fp.o package: 1) make a SCM package in COPR with Clone URL pointing to the src.fp.o fork (please, use the https:// cloning option) 2) make sure "Webhook Rebuild" checkbox is checked when you are creating the pac

Re: Usefulness of `copr mock-config ` feature?

Pavel On Tuesday, February 13, 2018 10:54:55 AM CET Pavel Raiskup wrote: Because we are unable to find a consensus on implementation details, it's likely we'll drop this feature from copr API and it will be probably a bit more

Re: Usefulness of `copr mock-config ` feature?

y, I wanted to CC fedora devel before, forwarding. > > > > >>> > > > > >>> Pavel > > > > >>> > > > > >>> On Tuesday, February 13, 2018 10:54:55 AM CET Pavel Raiskup > wrote: > > > > >>> >

Re: Usefulness of `copr mock-config ` feature?

t; > > > >> On 2018-02-13 11:47, Pavel Raiskup wrote: > > > >> > > > >>> Sorry, I wanted to CC fedora devel before, forwarding. > > > >>> > > > >>> Pavel > > > >>> > > > >>> On Tuesday

Re: Usefulness of `copr mock-config ` feature?

before, forwarding. > > >>> > > >>> Pavel > > >>> > > >>> On Tuesday, February 13, 2018 10:54:55 AM CET Pavel Raiskup wrote: > > >>> > > >>>> Because we are unable to find a consensus on implementation details, >

Re: Usefulness of `copr mock-config ` feature?

>>> > >>>> Because we are unable to find a consensus on implementation details, > >>>> it's > >>>> likely we'll drop this feature from copr API and it will be probably a > >>>> bit > >>>> more complicated to setup mock

Re: Usefulness of `copr mock-config ` feature?

Hi, BTW, in my own very basic use of copr, I'm mostly annoyed with: 1. copr failing builds because of problems syncing repodata → not my problem as packager, retry till you manage to sync repositories and package groups 2. copr sometimes starting the next build, before finishing syncing

Re: Usefulness of `copr mock-config ` feature?

C fedora devel before, forwarding. >>> >>> Pavel >>> >>> On Tuesday, February 13, 2018 10:54:55 AM CET Pavel Raiskup wrote: >>> >>>> Because we are unable to find a consensus on implementation details, >>>> it's >>>> likely we

Re: Usefulness of `copr mock-config ` feature?

CET Pavel Raiskup wrote: >> >>> Because we are unable to find a consensus on implementation details, it's >>> likely we'll drop this feature from copr API and it will be probably a >>> bit >>> more complicated to setup mock chroot for local tests in future

Re: Usefulness of `copr mock-config ` feature?

On 2018-02-13 11:47, Pavel Raiskup wrote: Sorry, I wanted to CC fedora devel before, forwarding. Pavel On Tuesday, February 13, 2018 10:54:55 AM CET Pavel Raiskup wrote: Because we are unable to find a consensus on implementation details, it's likely we'll drop this feature from copr API

Re: Usefulness of `copr mock-config ` feature?

Sorry, I wanted to CC fedora devel before, forwarding. Pavel On Tuesday, February 13, 2018 10:54:55 AM CET Pavel Raiskup wrote: > Because we are unable to find a consensus on implementation details, it's > likely we'll drop this feature from copr API and it will be probably a bit

Re: COPR + pagure + rpkg HOWTO?

On Tue, Feb 6, 2018 at 1:54 AM, Miroslav Suchý <msu...@redhat.com> wrote: > Dne 3.2.2018 v 15:45 Richard Shaw napsal(a): > > > > so I can stop uploading package to my fedorapeople public_html site and > build via URLs. > > Another option is to use > copr-cli

Re: COPR + pagure + rpkg HOWTO?

Dne 3.2.2018 v 15:45 Richard Shaw napsal(a): > > so I can stop uploading package to my fedorapeople public_html site and build > via URLs. Another option is to use copr-cli build foo.src.rpm which nowdays can submit src.rpm directly from your machine to Copr. This feature is in

Re: COPR + pagure + rpkg HOWTO?

Hello Richard, On Sat, Feb 3, 2018 at 3:45 PM, Richard Shaw <hobbes1...@gmail.com> wrote: > I would like to manage a COPR via SCM (in this case pagure) > > I'm assuming using rpkg would be a good way to do this? Or should I forget > that and just use plain git+copr-cl

COPR + pagure + rpkg HOWTO?

I would like to manage a COPR via SCM (in this case pagure) I'm assuming using rpkg would be a good way to do this? Or should I forget that and just use plain git+copr-cli? There is OK documentation for the independent tools but I can't seem to find a HOWTO that ties it all together. I want

Re: copr mailist?

Dne 30.1.2018 v 23:03 Adrian Sevcenco napsal(a): > Hi! I was wondering what would be the best place to ask help about problems > building packages on copr... https://lists.fedorahosted.org/archives/list/copr-de...@lists.fedorahosted.org/ Mi

copr mailist?

Hi! I was wondering what would be the best place to ask help about problems building packages on copr... Thank you and sorry for off-topic, Adrian smime.p7s Description: S/MIME Cryptographic Signature ___ devel mailing list -- devel

Planned Outage: COPR BACKEND upgrade - 2018-01-16 09:00 UTC

Planned Outage: COPR BACKEND upgrade - 2018-01-16 09:00 UTC There will be an outage starting at 2018-01-16 09:00 UTC, which will last approximately 0.5 hours. To convert UTC to your local time, take a look at http://fedoraproject.org/wiki/Infrastructure/UTCHowto or run: date -d '2018-01-16 09

Re: Copr dependency rebuild with circular dependencies

Thanks Nicolas. That makes sense. Would you advise that the compatibility package remains in rawhide after the mass rebuild? Best, James. On Tue, 2018-01-09 at 20:06 +0100, nicolas.mail...@laposte.net wrote: > Hi, > > Regardless of the build infra, you will need to create a compat > package

Re: Copr dependency rebuild with circular dependencies

Hi, Regardless of the build infra, you will need to create a compat package with the old lib version to make it available during bootstraping Regards, -- Nicolas Mailhot ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an

Copr dependency rebuild with circular dependencies

Hi all. Apologies for cross-posting, but I am running out of ideas. Suppose one updates libmpfr in a copr repository, which bumps the soname. Both GCC and libmpc depend on libmpfr, and so must be rebuilt, but neither GCC nor libmpc can be rebuilt without an existing libmpc, which, in turn

COPR: usage of http:// in python client

Hello, we have found out that http://copr.fedoraproject.org was used as default API endpoint if no copr_url was specified for CoprClient initialization. This is now fixed in the latest version of python-copr (python-copr-1.84) and we recommend updating to that version. Also we have decided

long waiting times for COPR jobs

Hello, lately, COPR pending job queues are holding jobs for pretty long time (even hours). This is a buggy behaviour and we will be doing our best to fix this issue in the following days. Thank your for your patience COPR team ___ devel-announce

Re: CI projects in Copr

We have finished the SCM source type implementation. You can read more in this blog post: https://clime.github.io/2017/10/24/COPR-SCM.html Thank you for the feedback! clime On Wed, Sep 27, 2017 at 10:28 PM, Michal Novotny <cl...@redhat.com> wrote: > Hello, > > On Tue, Sep 5,

Re: CI projects in Copr

initialized by a set of predefined buildroot packages (i.e. fedpkg, wget,). Both solutions will be fairly equivalent, except in the first case the script will be stored in a Git repository, whereas in the second, it will be stored in the COPR database. The latter will likely offer more more freed

Re: CI projects in Copr

On Fri, Sep 1, 2017 at 11:20 AM, Gerd Hoffmann <kra...@redhat.com> wrote: > Hi, > > > It's easier on implementation. That's the main reason. I generally > > believe that > > what's easier on implementation is better. > > It's maybe easier on the c

Re: CI projects in Copr

On 4.9.2017 19:27, Michal Novotny wrote: > I might contact you for more information, but alright, if you feel the custom > script is more convenient, > then I am all for it. But first, I would like to make a proposal of each > option (with screenshots and > just complete feature request

Re: CI projects in Copr

ess that usually I will get response from upstream > like that: > -- we will not add Makefile just because of COPR that is not important > for us in any way > -- we will not modify Makefile just because of... > etc. > > It would work for us where we are upstream, but it is

Re: CI projects in Copr

I apologize for late response as I was on holiday. Not sure if you already talked together about that but I agree with Pavel. `make srpm` solves only _one_ type of troubles. I guess that usually I will get response from upstream like that: -- we will not add Makefile just because of COPR

Re: CI projects in Copr

On Friday, September 1, 2017 12:16:32 PM CEST Michal Novotny wrote: > On Fri, Sep 1, 2017 at 8:55 AM, Marc Dequènes (Duck) > > On 09/01/2017 01:28 AM, Michal Novotny wrote: > > > But I think an off-line talk might be the best. Depends on you. > > > > I can understand you don't

Re: AppStream and COPR

properly integrated into our repodata (like it's supposed to be, and >>> how it is in openSUSE, Mageia, and even in COPR). >>> >>> We should be making AppStream data support first-class, not >>> third-class. :( >> >> This is interesting. Can you point

Re: AppStream and COPR (was: Splitting AppStream data into Workstation/Server)

ce" indeed downloads it for me. > You can see the appstream bundle in the repodata folder: > https://copr-be.cloud.fedoraproject.org/results/mvo/cockpit-app-freeipa/fedora-26-x86_64/repodata/669caf74c17cec488cc84ee5eadf4f4f02c7b34a84fd4664b4148c1422e4186d-appstream.xml.gz > > And i

Re: AppStream and COPR (was: Splitting AppStream data into Workstation/Server)

, and >> how it is in openSUSE, Mageia, and even in COPR). >> >> We should be making AppStream data support first-class, not >> third-class. :( > > This is interesting. Can you point me to more information about > AppStream and COPR? > There's no real documentation

AppStream and COPR (was: Splitting AppStream data into Workstation/Server)

Neal Gompa <ngomp...@gmail.com> writes: > [...] It's already kind of second-class in Fedora because it's not > properly integrated into our repodata (like it's supposed to be, and > how it is in openSUSE, Mageia, and even in COPR). > > We should be making AppStream dat

Re: CI projects in Copr

On Fri, Sep 1, 2017 at 1:41 PM, Gerd Hoffmann wrote: > Hi, > > > Right, this is cool. The problem is that the upstream repo would need > > to be configured to provide a public message that something has been > > changed > > in it (i.e. new release) so the question is how to

Re: CI projects in Copr

Hi, > Right, this is cool. The problem is that the upstream repo would need > to be configured to provide a public message that something has been > changed > in it (i.e. new release) so the question is how to do this part. Ah, right, setting up a webhook needs access to the upstream repo too.

Re: CI projects in Copr

ust a matter of taste. Also the thing is that we first need to actually make some changes in COPR code for this to "fit-in" so we don't even need to argue now. We can wait until we have things ready for it. > > I'm really new in here, I'm only using Copr/mock-scm and besides a few

Re: CI projects in Copr

2017-09-01 11:20 GMT+02:00 Gerd Hoffmann : > So, what would be really helpful, especially for CI with the option to > build and test every upstream commit, would be support for *two* git > repos. One git repo where the spec-file and other build-related stuff > lives (distgit

Re: CI projects in Copr

Hello Gerd, On Fri, Sep 1, 2017 at 11:20 AM, Gerd Hoffmann <kra...@redhat.com> wrote: > Hi, > > > It's easier on implementation. That's the main reason. I generally > > believe that > > what's easier on implementation is better. > > It's maybe easier on

Re: CI projects in Copr

Hi, > It's easier on implementation. That's the main reason. I generally > believe that  > what's easier on implementation is better. It's maybe easier on the copr side, but not for the copr users ... If you can modify the upstream project (either because you are upstream, or in case

Re: CI projects in Copr

. I think it would be best to improve on collaborative talks together. Also being asked for rational may seem boring but is really necessary to understand each-other and is in no way a provocative behavior, even if Pavel seems to like teasing you :-). I'm really new in here, I'm only using Copr/m

Re: CI projects in Copr

the script) that has > > meaning only if 'custom' has been selected (that will occur on more > places in > > the code). > > False. With 'make srpm' you still want to specify where the Makefile is. > I hope you don't expect that the only-for-copr Makefiles will be added to >

Re: CI projects in Copr

srpm' you still want to specify where the Makefile is. I hope you don't expect that the only-for-copr Makefiles will be added to the root of all the project in the wild... Anyway, I did not expected that you will complain about *one argument* in API or anywhere else, that's nitpick. How expensive is tha

Re: CI projects in Copr

on 'make srpm'; that sounds like you try > to push > > > the copr users somewhere, to "standardize something". > > > > It's easier on implementation. That's the main reason. I generally > believe > > that what's easier on implementation is better. >

Re: CI projects in Copr

On Thursday, August 31, 2017 11:43:08 AM CEST Michal Novotny wrote: > On Thu, Aug 31, 2017 at 8:43 AM, Pavel Raiskup <prais...@redhat.com> wrote: > > I'm curious why you insist on 'make srpm'; that sounds like you try to push > > the copr users somewhere, to "standar

Re: CI projects in Copr

ion point of view) seems to be to > automatically call > > `make srpm` command in the source git repo if user selects `make srpm` > as a > > srpm generator method > > I'm curious why you insist on 'make srpm'; that sounds like you try to > push the > copr users somewhere, to &quo

Re: CI projects in Copr

Hello, I'm using Jenkins for pOCCI testsuite tool [1] (COPR repository is [2]). I'm building everything in Jenkins using my own scripts for several OS (Fedora/EPEL, Debian), but I've added also COPR as optional step in the build workflow. Source rpms are generated locally by Jenkins

Re: CI projects in Copr

point of view) seems to be to automatically > > call > > `make srpm` command in the source git repo if user selects `make srpm` as a > > srpm generator method > > I'm curious why you insist on 'make srpm'; that sounds like you try to push > the > copr users somewhere, to "sta

Re: CI projects in Copr

cts `make srpm` as a > srpm generator method I'm curious why you insist on 'make srpm'; that sounds like you try to push the copr users somewhere, to "standardize something". Please allow specifying custom script, relatively placed in the git repository. That's exactly the same thing

Re: CI projects in Copr

Hello Martin, On Wed, Aug 23, 2017 at 2:02 PM, Martin Sehnoutka <msehn...@redhat.com> wrote: > Hi, > > I'm using Copr for build on commit for dnssec-trigger project: > https://github.com/InfrastructureServices/dnssec-trigger-fedora > It's using tito. > > But I'm

Re: CI projects in Copr

Hello Petr, On Thu, Aug 24, 2017 at 1:35 PM, Petr Stodulka <pstod...@redhat.com> wrote: > > > On 24.8.2017 08:04, Pavel Raiskup wrote: > > On Wednesday, August 23, 2017 1:46:46 PM CEST Miroslav Suchý wrote: > >> Do you use Copr for building packages for nigh

Re: COPR strategy

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

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

Re: CI projects in Copr

On 24.8.2017 08:04, Pavel Raiskup wrote: > On Wednesday, August 23, 2017 1:46:46 PM CEST Miroslav Suchý wrote: >> Do you use Copr for building packages for nightlies? For building packages >> before pull request is merged? > > Yes, not particulary me -- but I helped to g

Re: COPR strategy

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 app

Re: CI projects in Copr

On 23/08/17 04:46 AM, Miroslav Suchý wrote: > 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 t

Re: COPR strategy

2017-08-22 5:17 GMT+02:00 Michal Novotny <cl...@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. > >

Re: COPR strategy

t;> > > > Hey Kamil, >> > > > >> > > > On Tue, Aug 22, 2017 at 12:07 PM, Kamil Dudka <kdu...@redhat.com> >> wrote: >> > > > > On Tuesday, August 22, 2017 9:04:24 AM CEST Matthias Runge wrote: >> > > > > > - the a

Re: CI projects in Copr

On Wednesday, August 23, 2017 1:46:46 PM CEST Miroslav Suchý wrote: > Do you use Copr for building packages for nightlies? For building packages > before pull request is merged? Yes, not particulary me -- but I helped to guys in pgjdbc project to setup CI: https://copr.fedorainfracloud.org

Re: COPR strategy

ne 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 > > > &g

Re: f27 builds in COPR fail without logs

arma when it appears so that it reaches Fedora repos a >> bit faster. >> > > It is there waiting for your karma. [facepalm] I had seen the updates in bodhi, but for some reason I was waiting for an fc27 update... What are copr builders running by the way? __

Re: CI projects in Copr

Hi, We are making daily builds of Anaconda in Copr for Rawhide[1] and actual Fedora[2]. These daily builds are used for our other test suites. [1]: https://copr.fedorainfracloud.org/coprs/g/rhinstaller/Anaconda/ [2]: https://copr.fedorainfracloud.org/coprs/g/rhinstaller/Anaconda-dev el/ On Wed

Re: CI projects in Copr

Hi, As the maintainer of the Pantheon DE components and elementary apps, I have a setup that runs "nightly" builds of 59 of those packages in the "decathorpe/elementary-nightly" COPR repository for all supported fedora releases. This "CI-like" setup helps me catch

Re: CI projects in Copr

Hi, I'm using Copr for build on commit for dnssec-trigger project: https://github.com/InfrastructureServices/dnssec-trigger-fedora It's using tito. But I'm looking for a different way of doing this. Especially when I work on some upstream project and I don't want to force them to include tito

Re: f27 builds in COPR fail without logs

Dne 22.8.2017 v 14:53 Michal Novotny napsal(a): Eventually, a new version should pop up here: https://bodhi.fedoraproject.org/updates/?packages=mock You can give it Karma when it appears so that it reaches Fedora repos a bit faster. It is there waiting for your karma. Mirek

CI projects in Copr

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? Please let me know. Either here or via

Re: COPR strategy

Aug 22, 2017 at 12:07 PM, Kamil Dudka <kdu...@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 > > > > > > > > > > fil

Re: COPR strategy

, 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

Re: COPR strategy

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

Re: f27 builds in COPR fail without logs

On Tue, Aug 22, 2017 at 3:53 PM, Michal Novotny wrote: > Eventually, a new version should pop up here: > https://bodhi.fedoraproject.org/updates/?packages=mock > > You can give it Karma when it appears so that it reaches Fedora repos a bit > faster. Oh, I had never given much

Re: f27 builds in COPR fail without logs

Eventually, a new version should pop up here: https://bodhi.fedoraproject.org/updates/?packages=mock You can give it Karma when it appears so that it reaches Fedora repos a bit faster. On Tue, Aug 22, 2017 at 2:41 PM, Alexander Ploumistos < alex.ploumis...@gmail.com> wrote: > Thanks Michal. Is

Re: New copr-frontend release

try to > refetch the URL, which may no longer be valid). Instead, I got an error > message that it does not have any sources to fetch. > It actually works like you expect for uploaded SRPMs and URL SRPMs. For both these build types, imported copr-dist-git sources are being used. This will

Re: f27 builds in COPR fail without logs

Thanks Michal. Is there someplace I should monitor to know when the f27 mock will be available? ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: New copr-frontend release

tch. I ended up passing the output SRPMs of the Copr builds as the SRPM URLs for new builds as a workaround. (I prefer the automatic forking option, but unfortunately, the F26 branching happened before it was introduced, so it used the old model, where rawhide was renamed to f26 and the rawhide c

Re: COPR strategy

cided, 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

Re: COPR strategy

ossibly 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 fo

Re: f27 builds in COPR fail without logs

. clime On Tue, Aug 22, 2017 at 12:33 PM, Alexander Ploumistos < alex.ploumis...@gmail.com> wrote: > Hello, > > For the past hour or so, I've been trying to rebuild my copr packages > for f27 and rawhide. While there were some hiccups with rawhide, e.g. > not finding mirrors to dow

f27 builds in COPR fail without logs

Hello, For the past hour or so, I've been trying to rebuild my copr packages for f27 and rawhide. While there were some hiccups with rawhide, e.g. not finding mirrors to download packages, after resubmitting them a couple of times, all builds were successful. On the other hand, f27 builds fail

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 > div

Re: COPR strategy

nted > 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, p

Re: COPR strategy

> 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 a

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

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

Re: New copr-frontend release

vin, >> > >> > sorry for the late response caused by me being on vacations. >> > >> > On Sat, Aug 12, 2017 at 2:35 AM, Kevin Kofler <kevin.kof...@chello.at> >> > wrote: >> > >> > > Hi, >> > > >> > > Mi

Re: New copr-frontend release

, Aug 12, 2017 at 2:35 AM, Kevin Kofler <kevin.kof...@chello.at> > > wrote: > > > > > Hi, > > > > > > Michal Novotny wrote: > > > > - "Follow Fedora branching" project switch that (if enabled) makes > COPR > > > > for

Re: New copr-frontend release

Michal Novotny wrote: > > > - "Follow Fedora branching" project switch that (if enabled) makes COPR > > > fork your rawhide chroots into the newly branched ones > > > and hence user will have your packages available in their f27 systems > > > and they

Re: New copr-frontend release

Hello Kevin, sorry for the late response caused by me being on vacations. On Sat, Aug 12, 2017 at 2:35 AM, Kevin Kofler <kevin.kof...@chello.at> wrote: > Hi, > > Michal Novotny wrote: > > - "Follow Fedora branching" project switch that (if enabled) makes COP

Re: New copr-frontend release

Hi, Michal Novotny wrote: > - "Follow Fedora branching" project switch that (if enabled) makes COPR > fork your rawhide chroots into the newly branched ones > and hence user will have your packages available in their f27 systems > and they will also be available fo

New copr-frontend release

Hello, I am sending these release notes also to fedora-devel list (and not just copr-devel list as usually) because they contain information about upcoming Fedora branching and what features COPR provides to move the set of packages from your rawhide chroots into the newly branched ones. We have

mock's dual bootstrapping enabled by default for existing copr projects

Hello, while working on another thing, I noticed that when use_bootstrap_container project option was introduced (Wed Jun 14 this year), it was introduced as enabled for existing COPR projects at that time. That was not exactly intended as this feature is experimental. Enabling this option makes

Planned Outage: fedora infrastructure cloud / copr reboots - 2017-06-26 21:00 UTC

and rebooting the fedorainfracloud. This will affect copr builds, frontend and backend as well as any other applications hosted in the cloud.fedoraproject.org or fedorainfracloud.org domains. Affected Services: copr: frontend, backend and builds. *.fedorainfracloud.org

Re: COPR Arm Builds?

re old ARM machines which were used for Secondary Arch Koji. But they > are very small. They are not capable to > handle VMs. So to use them for Copr it needs to: That is actually incorrect, they can run VMs just fine, just not large amounts of them, but the openstack side of things should be

<    2   3   4   5   6   7   8   9   10   11   >