New release

[Jakub Kadlcik]

Hello,

we have updated the Copr stack to the newest versions of our packages.
This was a first major release after months, so you can expect many
enhancements.

The common theme for this release was to speed-up the frontend
interface, optimize internals and improve the user experience with
small UI changes.

The full list of release notes might come later.

Regards
COPR team
___
copr-devel mailing list -- copr-devel@lists.fedorahosted.org
To unsubscribe send an email to copr-devel-le...@lists.fedorahosted.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedorahosted.org/archives/list/copr-devel@lists.fedorahosted.org

New release & deploy

[Michal Novotny]

Hello,

we have just released & deployed the latest Copr stack. This one brings
some long-expected features. Mainly:

- APIv3
- Pagure Integration

Both features will be presented on Flock and we will also write some
tutorials/blog posts about them.

As for APIv3, you can download python-copr from
https://bodhi.fedoraproject.org/updates/FEDORA-2018-d5ac820aac and already
start experimenting with `from copr.v3 import Client`. It's pretty neat.

And for the integration with Pagure, please, take a look at tab
'Integration' (was called webhooks before) in a copr settings.

You can explore the features on your own in advance but we will provide the
necessary information very soon.

Enjoy!
Copr team

- https://bodhi.fedoraproject.org/updates/FEDORA-2018-8d91c1046a
- https://bodhi.fedoraproject.org/updates/FEDORA-2018-3fa42dc92f
- https://bodhi.fedoraproject.org/updates/FEDORA-2018-fc3c13f54e
- https://bodhi.fedoraproject.org/updates/FEDORA-2018-4bd4b0b6d4
- https://bodhi.fedoraproject.org/updates/FEDORA-2018-c4a24c92ba
- https://bodhi.fedoraproject.org/updates/FEDORA-2018-3c7de87cc1
- https://bodhi.fedoraproject.org/updates/FEDORA-2018-020246f336
- https://bodhi.fedoraproject.org/updates/FEDORA-2018-fcd54eff78
___
copr-devel mailing list -- copr-devel@lists.fedorahosted.org
To unsubscribe send an email to copr-devel-le...@lists.fedorahosted.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/copr-devel@lists.fedorahosted.org/message/RID3IDXFZO4GUFNUR6HIWDSPVQT4GOYF/

New Release

[Michal Novotny]

Hello,

we have deployed a new Copr stack. Hurray!

The main highlights are that copr-dist-git as the last missing piece has
been rewritten into python3 meaning that the whole stack now runs on
python3. Then some new openSUSE chroots were introduced. Thanks to Neal
Gompa, you can now build for:

openSUSE Tumbleweed i586, ppc64le, x86_64*
openSUSE Leap 15.0 x86_64

Then we added support for --with and --without rpmbuild options per chroot
setting. With those option, you tweak building of your packages if you need
to.

Then there were some fixes for forking and (redundant) auto-rebuilding.

See the updates below for full info and enjoy!
Copr team

copr-frontend:
https://bodhi.fedoraproject.org/updates/FEDORA-2018-673aed0334
copr-backend: https://bodhi.fedoraproject.org/updates/FEDORA-2018-761af1cac4
copr-dist-git:
https://bodhi.fedoraproject.org/updates/FEDORA-2018-5d2b196460
copr-keygen: https://bodhi.fedoraproject.org/updates/FEDORA-2018-875a98dd4a
copr-rpmbuild:
https://bodhi.fedoraproject.org/updates/FEDORA-2018-87ed23fbc6
copr-cli: https://bodhi.fedoraproject.org/updates/FEDORA-2018-e42e970966
___
copr-devel mailing list -- copr-devel@lists.fedorahosted.org
To unsubscribe send an email to copr-devel-le...@lists.fedorahosted.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/copr-devel@lists.fedorahosted.org/message/KB3DNSAYPLQJXGNWL6AWZGESMMVNKJ2Z/

Re: New release

[Dominik Turecek]

Hi,

we have released new versions of copr-cli and python-copr.
https://bodhi.fedoraproject.org/updates/FEDORA-2018-33e3bea3d3

Enjoy
COPR team

On Fri, Apr 27, 2018 at 7:40 AM, Michal Novotny  wrote:

> I am sorry there was a delay in the deployment process due to my human
> factor.
>
> We will need to optimize our release procedure.
>
> Note that builders are now also using the new rpkg-util package*,
> which brings some new functionality into SCM building.
>
> * https://bodhi.fedoraproject.org/updates/FEDORA-2018-85a4ea93f7
>
> clime
>
> On Fri, Apr 27, 2018 at 7:30 AM, Michal Novotny  wrote:
>
>> On Thu, Apr 26, 2018 at 9:39 PM, Dominik Turecek <
>> dture...@fedoraproject.org> wrote:
>>
>>> Hello,
>>>
>>> we have released new versions of backend, frontend, and rpmbuild.
>>> The release contains mostly fixes and unbundling of static libraries in
>>> frontend,
>>> as well as the addition of rpkg to COPR.
>>>
>>> We expect the packages to be deployed later today.
>>>
>>> Regards
>>> COPR team
>>>
>>> Updates:
>>> backend - https://bodhi.fedoraproject.org/updates/FEDORA-2018-7a486914e2
>>> frontend - https://bodhi.fedoraproject.org/updates/FEDORA-2018-5c6e60b4
>>> e7
>>> rpmbuild - https://bodhi.fedoraproject.org/updates/FEDORA-2018-212a96cf
>>> f2
>>
>>
>>
>> The deployment of those has been finished.
>>
>> COPR team
>>
>>
>>>
>>> ___
>>> copr-devel mailing list -- copr-devel@lists.fedorahosted.org
>>> To unsubscribe send an email to copr-devel-le...@lists.fedorahosted.org
>>>
>>
>>
>
> ___
> copr-devel mailing list -- copr-devel@lists.fedorahosted.org
> To unsubscribe send an email to copr-devel-le...@lists.fedorahosted.org
>
>
___
copr-devel mailing list -- copr-devel@lists.fedorahosted.org
To unsubscribe send an email to copr-devel-le...@lists.fedorahosted.org

Re: New release

[Michal Novotny]

I am sorry there was a delay in the deployment process due to my human
factor.

We will need to optimize our release procedure.

Note that builders are now also using the new rpkg-util package*,
which brings some new functionality into SCM building.

* https://bodhi.fedoraproject.org/updates/FEDORA-2018-85a4ea93f7

clime

On Fri, Apr 27, 2018 at 7:30 AM, Michal Novotny  wrote:

> On Thu, Apr 26, 2018 at 9:39 PM, Dominik Turecek <
> dture...@fedoraproject.org> wrote:
>
>> Hello,
>>
>> we have released new versions of backend, frontend, and rpmbuild.
>> The release contains mostly fixes and unbundling of static libraries in
>> frontend,
>> as well as the addition of rpkg to COPR.
>>
>> We expect the packages to be deployed later today.
>>
>> Regards
>> COPR team
>>
>> Updates:
>> backend - https://bodhi.fedoraproject.org/updates/FEDORA-2018-7a486914e2
>> frontend - https://bodhi.fedoraproject.org/updates/FEDORA-2018-5c6e60b4e7
>> rpmbuild - https://bodhi.fedoraproject.org/updates/FEDORA-2018-212a96cff2
>
>
>
> The deployment of those has been finished.
>
> COPR team
>
>
>>
>> ___
>> copr-devel mailing list -- copr-devel@lists.fedorahosted.org
>> To unsubscribe send an email to copr-devel-le...@lists.fedorahosted.org
>>
>
>
___
copr-devel mailing list -- copr-devel@lists.fedorahosted.org
To unsubscribe send an email to copr-devel-le...@lists.fedorahosted.org

Re: New release

[Michal Novotny]

On Thu, Apr 26, 2018 at 9:39 PM, Dominik Turecek  wrote:

> Hello,
>
> we have released new versions of backend, frontend, and rpmbuild.
> The release contains mostly fixes and unbundling of static libraries in
> frontend,
> as well as the addition of rpkg to COPR.
>
> We expect the packages to be deployed later today.
>
> Regards
> COPR team
>
> Updates:
> backend - https://bodhi.fedoraproject.org/updates/FEDORA-2018-7a486914e2
> frontend - https://bodhi.fedoraproject.org/updates/FEDORA-2018-5c6e60b4e7
> rpmbuild - https://bodhi.fedoraproject.org/updates/FEDORA-2018-212a96cff2



The deployment of those has been finished.

COPR team


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

New release

[Dominik Turecek]

Hello,

we have released new versions of backend, frontend, and rpmbuild.
The release contains mostly fixes and unbundling of static libraries in 
frontend,
as well as the addition of rpkg to COPR.

We expect the packages to be deployed later today.

Regards
COPR team

Updates:
backend - https://bodhi.fedoraproject.org/updates/FEDORA-2018-7a486914e2
frontend - https://bodhi.fedoraproject.org/updates/FEDORA-2018-5c6e60b4e7
rpmbuild - https://bodhi.fedoraproject.org/updates/FEDORA-2018-212a96cff2
___
copr-devel mailing list -- copr-devel@lists.fedorahosted.org
To unsubscribe send an email to copr-devel-le...@lists.fedorahosted.org

New release

[Michal Novotny]

Hello,

we have just deployed the latest COPR stack to the production. I will talk
more about it on Monday. For now, you can enjoy the new graphs that our
_very_ talented intern has made :)...

COPR team
___
copr-devel mailing list -- copr-devel@lists.fedorahosted.org
To unsubscribe send an email to copr-devel-le...@lists.fedorahosted.org

New Release

[Dominik Turecek]

Hi,

we have released new COPR stack. We have upgraded the frontend, distgit, keygen 
and builders to fedora 27.
COPR backend is still running on f25 due to incompatible python-nova client 
with current OpenStack.
The following changes were introduced:

copr-frontend 1.125-1
- added support for src.fp.o in build_on_pagure_commit.py
- provide default for source_json_dict in scm migration
- fix committish filter condition for auto-rebuilds
- fix SCM migrations not to use models that might be newer than db
- always use ref from the push/tag event for package auto-rebuild
- rather suggest dnf-modularity-stable repo
- update the info how to install a module
- fix code block spacing
- fix scm unification migrations for mock-scm
- show most recent post from our blog 

copr-backend 1.109-1
- terminate also 'in_use' builders if health checks have failed
- update copr_log_hitcounter to check ip against ignored pattern
- new msg bus options 
- disable DNF makecache timer/service
- fixed message duplication for multi-bus scenario

copr-selinux 1.47-1
- wrap map permission in an optional block

Best regards
COPR team
___
copr-devel mailing list -- copr-devel@lists.fedorahosted.org
To unsubscribe send an email to copr-devel-le...@lists.fedorahosted.org

New Release

[Michal Novotny]

Hello!

New COPR stack has just been released. It contains the following updates:

copr-frontend 1.124-1
- fixed build_on_pagure_commit.py
- optimized check_for_anitya_version_updates
- allow to set use_bootstrap_container via API

copr-backend 1.107-1
- kill all processes in copr-rpmbuild's process group
- add --drop-resultdir switch to copr-rpmbuild call
- release_vm immediately after VM is no longer needed
- remove --ignore-lock from createrepo_c

copr-rpmbuild 0.12-1
- fortify make_srpm
- compatibility with rpkg-client-0.11 and 0.12

These updates aim to fix the problems we have been facing recently. That
is, builder leaking on createrepo_c call, frontend timeouts due to slow
check_for_anitya_version_updates, non-working pagure-rebuilding, and it
also makes make_srpm method much, much safer by dropping user privileges in
the systemd-nspawn container and by employing --private-users=pick switch
which offsets container's user UIDs.

Enjoy!
COPR team
___
copr-devel mailing list -- copr-devel@lists.fedorahosted.org
To unsubscribe send an email to copr-devel-le...@lists.fedorahosted.org

Re: New release

[Pavel Raiskup]

On Monday, September 11, 2017 2:07:43 PM CEST Jean-Marc Liger wrote:
> To avoid space consumming, an optional feature to switch before build should
> be the best option for me.

This would be possible too, if such builds have been imported into
temporary ("soon" to be garbage collected) namespace on dist-git.

In my use-cases, much more convenient would be to have the setting
per-package (instead of per-build) basis.

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

Re: New release

[Michal Novotny]

Hello Jean-Marc,

On Mon, Sep 11, 2017 at 2:00 PM, Jean-Marc Liger <
jean-marc.li...@parisdescartes.fr> wrote:

> Hi Clime,
> Le 07/09/2017 à 22:46, Michal Novotny a écrit :
>
> 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.
>
> There will be more to follow regarding SRPM generation.
>
> Thank you for building on COPR
> COPR team
>
>
> Some (nice for me) features which were in the previous release have been
> reverted :
> - the original SRPM dist tag is present again in the package version ;
> - there is no more spec file in the result repository.
>
> What about it ?
>

You are right. I am aware of both. And both are fairly difficult to solve
right now.

We will try to come up with a solution to this.
Thank you a lot for your remarks!
Your input is very valuable.

> Regards,
>
> Jean-Marc
>
> ___
> copr-devel mailing list -- copr-devel@lists.fedorahosted.org
> To unsubscribe send an email to copr-devel-le...@lists.fedorahosted.org
>
>
___
copr-devel mailing list -- copr-devel@lists.fedorahosted.org
To unsubscribe send an email to copr-devel-le...@lists.fedorahosted.org

Re: New release

[Jean-Marc Liger]

Hi Pavel,

Le 08/09/2017 à 15:43, Pavel Raiskup a écrit :


On Friday, September 8, 2017 11:07:41 AM CEST Michal Novotny wrote:

On Fri, Sep 8, 2017 at 9:50 AM, Jean-Marc Liger 
jean-marc.li...@parisdescartes.fr> wrote:

Great, so DistGit won't be update if build fails ?

Right now, srpm is imported into DistGit before the actual rpm build.

Just additional note, this is nothing new (the dist-git was never updated if
dist-git failed to obtain the external sources).  The only thing which changed
now is that dist-git itself is not responsible for "srpm preparation", but it is
delegated to safer (and more parallelizable) place -> to builders.

JFTR: People obviously do care about dist-git content.  Since there is
temptation to stop importing the srpm into distgit (in future, since dist-git
import is way too space expensive).  Thus, we should really make sure that it
won't hurt the users, at least those who care about dist-git (so IMHO we should
really keep the dist-git feature as-is, at least as an optional feature).

Pavel
To avoid space consumming, an optional feature to switch before build 
should be the best option for me.


Regards,
Jean-Marc
___
copr-devel mailing list -- copr-devel@lists.fedorahosted.org
To unsubscribe send an email to copr-devel-le...@lists.fedorahosted.org

Re: New release

[Jean-Marc Liger]

Hi Clime,

Le 07/09/2017 à 22:46, Michal Novotny a écrit :

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.

There will be more to follow regarding SRPM generation.

Thank you for building on COPR
COPR team


Some (nice for me) features which were in the previous release have been 
reverted :

- the original SRPM dist tag is present again in the package version ;
- there is no more spec file in the result repository.

What about it ?

Regards,

Jean-Marc

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

Re: New release

[Michal Novotny]

Hello Robert,

On Sun, Sep 10, 2017 at 5:35 PM, Robert-André Mauchin 
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.
> >
> > There will be more to follow regarding SRPM generation.
> >
> > Thank you for building on COPR
> > COPR team
>
> Hello,
>
> I don't know what you've changed but since this release, my Rust packages
> aren't building anymore. Rust packages are depending on the latest RPM to
> handle rich dependencies ("with"), but now I get an error as if it was
> using an older rpm which doesn't understand "with":
>
> >
> >Munch({'cmd': ['rpkg', '--config', '/tmp/tmp4idk7_da/rpkg.conf',
> '--module-name', 'eclipseo/rust-libraries/rust-compiler_error', 'srpm'],
> 'stdout': '', 'stderr': "error: line 21: Unknown rich dependency op 'with':
> BuildRequires:  (crate(rand) >= 0.3.0 with crate(rand) < 0.4.0)\nerror:
> query of specfile /tmp/tmp4idk7_da/repo/compiler_error.spec failed, can't
> parse\n\nCould not execute srpm: Could not get n-v-r-e from ''",
> 'returncode': 1})
> >error: line 21: Unknown rich dependency op 'with': BuildRequires:
> (crate(rand) >= 0.3.0 with crate(rand) < 0.4.0)
> >error: query of specfile /tmp/tmp4idk7_da/repo/compiler_error.spec
> failed, can't parse
> >
> https://copr-be.cloud.fedoraproject.org/results/eclipseo/rust-libraries/
> fedora-rawhide-x86_64/00600465-rust-compiler_error/builder-live.log
>
> Please provide a fix for this.
>

Yes, we are very sorry for this :(. We will provide the fix immediately in
the next release.


> Best regards,
>
> Robert-André.
> ___
> copr-devel mailing list -- copr-devel@lists.fedorahosted.org
> To unsubscribe send an email to copr-devel-le...@lists.fedorahosted.org
>
___
copr-devel mailing list -- copr-devel@lists.fedorahosted.org
To unsubscribe send an email to copr-devel-le...@lists.fedorahosted.org

Re: New release

[Robert-André Mauchin]

> 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.
> 
> There will be more to follow regarding SRPM generation.
> 
> Thank you for building on COPR
> COPR team

Hello,

I don't know what you've changed but since this release, my Rust packages 
aren't building anymore. Rust packages are depending on the latest RPM to 
handle rich dependencies ("with"), but now I get an error as if it was using an 
older rpm which doesn't understand "with":

>
>Munch({'cmd': ['rpkg', '--config', '/tmp/tmp4idk7_da/rpkg.conf', 
>'--module-name', 'eclipseo/rust-libraries/rust-compiler_error', 'srpm'], 
>'stdout': '', 'stderr': "error: line 21: Unknown rich dependency op 'with': 
>BuildRequires:  (crate(rand) >= 0.3.0 with crate(rand) < 0.4.0)\nerror: query 
>of specfile /tmp/tmp4idk7_da/repo/compiler_error.spec failed, can't 
>parse\n\nCould not execute srpm: Could not get n-v-r-e from ''", 'returncode': 
>1})
>error: line 21: Unknown rich dependency op 'with': BuildRequires:  
>(crate(rand) >= 0.3.0 with crate(rand) < 0.4.0)
>error: query of specfile /tmp/tmp4idk7_da/repo/compiler_error.spec failed, 
>can't parse
>
https://copr-be.cloud.fedoraproject.org/results/eclipseo/rust-libraries/fedora-rawhide-x86_64/00600465-rust-compiler_error/builder-live.log

Please provide a fix for this.

Best regards,

Robert-André.
___
copr-devel mailing list -- copr-devel@lists.fedorahosted.org
To unsubscribe send an email to copr-devel-le...@lists.fedorahosted.org

Re: New release

[Pavel Raiskup]

On Friday, September 8, 2017 11:07:41 AM CEST Michal Novotny wrote:
> On Fri, Sep 8, 2017 at 9:50 AM, Jean-Marc Liger 
> jean-marc.li...@parisdescartes.fr> wrote:
> > Great, so DistGit won't be update if build fails ?
>
> Right now, srpm is imported into DistGit before the actual rpm build.

Just additional note, this is nothing new (the dist-git was never updated if
dist-git failed to obtain the external sources).  The only thing which changed
now is that dist-git itself is not responsible for "srpm preparation", but it is
delegated to safer (and more parallelizable) place -> to builders.

JFTR: People obviously do care about dist-git content.  Since there is
temptation to stop importing the srpm into distgit (in future, since dist-git
import is way too space expensive).  Thus, we should really make sure that it
won't hurt the users, at least those who care about dist-git (so IMHO we should
really keep the dist-git feature as-is, at least as an optional feature).

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

Re: New release

[Michal Novotny]

Hey Jean-Marc,

On Fri, Sep 8, 2017 at 9:50 AM, Jean-Marc Liger <
jean-marc.li...@parisdescartes.fr> wrote:

> Hi,
>
> Le 07/09/2017 à 22:46, Michal Novotny a écrit :
>
>> 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.
>>
>
> Great, so DistGit won't be update if build fails ?
>
>
Right now, srpm is imported into DistGit before the actual rpm build. So it
should be updated if the rpm build fails. But it will not be updated if the
initial
srpm generation fails (that is the first step in the build process now
unless
SRPM upload or SRPM url sources are used, then it is being skipped).


> There will be more to follow regarding SRPM generation.
>>
>> Thank you for building on COPR
>> COPR team
>>
>
> JM
>
> ___
> copr-devel mailing list -- copr-devel@lists.fedorahosted.org
> To unsubscribe send an email to copr-devel-le...@lists.fedorahosted.org
>
___
copr-devel mailing list -- copr-devel@lists.fedorahosted.org
To unsubscribe send an email to copr-devel-le...@lists.fedorahosted.org

Re: New release

[Michal Novotny]

Hello Igor!

On Fri, Sep 8, 2017 at 9:18 AM, Igor Gnatenko <
ignatenkobr...@fedoraproject.org> wrote:

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

No, it does not. We will see if we can do anything about it in future.


> >
> > 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
>
___
copr-devel mailing list -- copr-devel@lists.fedorahosted.org
To unsubscribe send an email to copr-devel-le...@lists.fedorahosted.org

Re: New release

[Jean-Marc Liger]

Hi,

Le 07/09/2017 à 22:46, Michal Novotny a écrit :

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.


Great, so DistGit won't be update if build fails ?


There will be more to follow regarding SRPM generation.

Thank you for building on COPR
COPR team


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

Re: New release

[Igor Gnatenko]

-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

New release

[Michal Novotny]

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.

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

New Release

[Michal Novotny]

Hello,

we have just released copr-dist-git-0.33 and copr-frontend-1.116. These
packages are taking another step towards having a seamless integration with
SCM systems.

Mainly Tito method was renamed to SCM-1 source and MockSCM method was
renamed to SCM-2 source.

Backend for these two sources is already the same on copr-dist-git
(ScmProvider), only frontend forms are currently a bit different.

Note that we don't use Tito (nor mock-scm already for some time) so
tito.props is now just a silently ignored file.

What we did is that we defined two kinds of repositories: upstream and
downstream.

*Downstream repo:* is empty (except .spec, README, tito.props, hidden
files, currently) or contains at least one source or patch mentioned in the
specfile

*Upstream repo:* is not a downstream repo, meaning it contains something
significant not mentioned in .spec as source or patch

This definition allows us to auto-differentiate between the two kinds of
the repositories and do the right thing - either pack the repository
content as tarball with name specified in Source0 (upstream repo) or just
collect patches + sources there are already present (downstream repo).

There also might be just a spec file in the repository (or its
subdirectory) with the sources being downloaded from network completely
during rpm-build process.

This might sound complicated at first but really isn't. The idea is that
the system should do the right thing for you automatically.

We are very happy about these changes and further possibilities this brings
along and we hope you will be too.

COPR team
___
copr-devel mailing list -- copr-devel@lists.fedorahosted.org
To unsubscribe send an email to copr-devel-le...@lists.fedorahosted.org

New release/deploy

[Michal Novotny]

Hello,

we have just deployed copr-frontend-1.114, copr-dist-git-0.31, and
copr-rpmbuild 0.6 into production.

The updated COPR stack now offers quite a cool feature - building form a
.spec file directly by specifying URL or uploading it. You can even combine
.src.rpm and .spec files in the URL build method (the only one that
currently offers launching multiple builds at once).

copr-rpmbuild was updated to use %{disable_source_fetch 0} instead of
spectool for downloading additional sources. The macro has support directly
in rpm and is hence very preferred.

COPR team
___
copr-devel mailing list -- copr-devel@lists.fedorahosted.org
To unsubscribe send an email to copr-devel-le...@lists.fedorahosted.org

New release

[Michal Novotny]

Hello,

we have just deployed new copr-backend 1.101 and copr-frontend 1.112 and
copr-rpmbuild 0.3. This new release just adds basically three things:

- build canceling on builders have been fixed
- support for mock's feature use_bootstrap_container has been implemented
- mock 1.4.2 is now used on builders

Hope it works
COPR team

* https://bodhi.fedoraproject.org/updates/FEDORA-2017-f42902c438
* https://bodhi.fedoraproject.org/updates/FEDORA-2017-0b30de785d
___
copr-devel mailing list -- copr-devel@lists.fedorahosted.org
To unsubscribe send an email to copr-devel-le...@lists.fedorahosted.org

New release

[Michal Novotny]

Hello,

we have just released latest state of COPR server stack.

Main changes include:

- usage of standalone builder on a builder machine, yet to be officially
packaged
- custom dist-git branching (for different distros)
- dist-git import into separate branches is now only a single import task
(imports should be much faster than before)
- we have now f26 beta builders

Please, report us bugs.
COPR team
___
copr-devel mailing list -- copr-devel@lists.fedorahosted.org
To unsubscribe send an email to copr-devel-le...@lists.fedorahosted.org

New Release

[Michal Novotny]

Hello,

new copr-frontend 1.109, copr-dist-git 0.27, and copr-backend
1.99-1.git.1.1958572.fc25 have been deployed into production.

- copr-dist-git 0.27 fixes *Bug 1447102*
 - fedpkg build fail
during import phase

- copr-frontend 1.109 changes the way in which COPR creates a module when
the build is launched through UI. Previously, the already built (and
selected) packages have been used for creation of a module snapshot to
which the appropriate module meta-data were added. Now the module is built
from a scratch again.

The new copr-frontend version also addresses the following problems:

- non-working pagure webhooks by adding more debugging info into the
code and network-error fail-proofing it
- *Bug 1448333*
 - Unable
to edit someone's else project settings
- previously .git suffix in Git repo URL was needed for webhook
rebuilds of Tito and MockSCM packages, which was not very intuitive or
user-friendly. Now it works without the '.git' suffix as well.

- copr-backend 1.99-1.git.1.1958572.fc25 is a hotfix for appstream-builder
core dumps that we have been experiencing since the beginning of this year.
See *Bug 1426166*
 -
appstream-builder
core dumps for more information.

Best Regards
COPR team
___
copr-devel mailing list -- copr-devel@lists.fedorahosted.org
To unsubscribe send an email to copr-devel-le...@lists.fedorahosted.org

New Release

[Michal Novotny]

Hey folks,

yesterday, we have released the latest state of our COPR stack. It contains
a _lot_ of new features and even though it's not perfect, it's still pretty
damn good.

The main feature addition was perhaps support for building modules directly
from a modulemd file or from a SCM url by using our copr-cli command line
tool. You just pass a single parameter to get a module that can be
immediately installed into your system (if stars align, of course). You can
read more about this feature in this blog post of one of our main devs:
http://frostyx.cz/posts/copr-loves-modularity

Now, there is more. By using proper bash hacking, we unlocked another
pretty cool feature. COPR builds can now be reattached to backend after it
has been restarted. That means, our deployment process will no longer
interrupt your running build and no time is wasted. This feature can be
seen as one of the steps to provide an actual "quality of service".

And yeah, we _also_ added live logs. This feature has been demanded for
very long time and so it has finally landed. Needed to be said, it's a
mockchain output, so even though it's live there is not very much
information in it :).

We are quite excited about all of this and hope you will be too
Your COPR team
___
copr-devel mailing list -- copr-devel@lists.fedorahosted.org
To unsubscribe send an email to copr-devel-le...@lists.fedorahosted.org

New Release tomorrow

[Michal Novotny]

Hello, new COPR version will be deployed tomorrow at 9am UTC.

COPR team
___
copr-devel mailing list -- copr-devel@lists.fedorahosted.org
To unsubscribe send an email to copr-devel-le...@lists.fedorahosted.org

| New release

[Michal Novotny]

Hello!

The latest COPR packages were deployed into production. This release is big
bringing lots of new features and bugfixes. Here is a list of the most
important new features that you can find in the new stack:

- improved modularity UI and support for modulemd 1.0.2 for building modules
- build timeout set to 18 hours
- fedora-rawhide chroots renamed to fedora-26 chroots
- auto-prune on/off admin option added to project
- generation of mock configs by using copr-cli
- modularization of template and static files into copr-frontend-fedora
package
- possibility to cancel running builds
- fedmsg autorebuilds of pagure Copr repos
- very basic support for building from dist-git (only Fedora dist-git
supported at the moment)
- show html code for build badge
- speeding up home-page
- and others...please, see the change logs if you are interested (e.g.
https://pagure.io/copr/copr/c/10c7d1a598d1c9cb8ac7c7900a1e78a5aaed11ca?branch=master
)

COPR team

P.S.: currently there is an issue with mock_scm importing taking a long
time. Also note that you should now build for fedora-26 chroots instead of
the rawhide ones. In case of any questions about the release or a
particular feature in the release, please ask. We will do our best to clear
it up.
___
copr-devel mailing list -- copr-devel@lists.fedorahosted.org
To unsubscribe send an email to copr-devel-le...@lists.fedorahosted.org

New release

[Michal Novotny]

Hello, we have just deployed a new version of copr-frontend package, which
deprecates F22 chroots and enables F25 ones. There is actually more than
that. Also pull request of Conan-Kudo (
https://github.com/fedora-copr/copr/pull/12) was included and few bugfixes
as well (#1368259 and #*1369392*
).

Enjoy.
clime
___
copr-devel mailing list
copr-devel@lists.fedorahosted.org
https://lists.fedorahosted.org/admin/lists/copr-devel@lists.fedorahosted.org

Re: New Release!

[Pavel Raiskup]

On Tuesday, September 6, 2016 10:18:31 AM CEST Michal Novotny wrote:
> On Tue, Aug 30, 2016 at 7:43 AM, Pavel Raiskup  wrote:
> 
> > On Tuesday, August 30, 2016 7:39:14 AM CEST Pavel Raiskup wrote:
> > > Currently it looks like such error-handling is not implemented anyway,
> > > we drop the build and it is re-submitted after some deadline.
> >
> > By "drop" here I mean that the build simply fails on BE, while it is still
> > in "running" state in FE databse.  That build is put in queue once again
> > after MAX_BUILD_TIMEOUT.handling non-responsive VMs.
> 
> But that's different from the (primitive) deferring mechanism where
> backend takes any job that frontend feeds it with and returns it back
> (effectively saying "try to give me this job later") if it finds out the
> job cannot be handled at the moment.

Right, that's why I say that the actual deferring is not needed at all.  Because
backend is not going to ask for build if it is not able to immediately handle
it.

> If you would like to use what you have described to implement
> "deferring", then I doubt you can fit it on that very well.

I don't follow here.

> I am satisfied with the current state and will implement more only
> if/when I find it insufficient (meaning "performing very badly") later
> but feel free to send us patches for this sooner if desired.

Now, slower architectures (ppc64le) will (a bit) delay the queues in faster
architectures (x86_64/i386).  Or am I wrong here?  Yes, it is not big issue.

But I just claim that the "major rewrite" (without code review!) reached
production too early, because it brings zero benefits.  It would be beneficial,
and I could appreciate it, if it was 1:1 replacement, but so far it is not.

Please consider having simple "Pull-request -> LGTM -> merge" commit process.

Pavel
___
copr-devel mailing list
copr-devel@lists.fedorahosted.org
https://lists.fedorahosted.org/admin/lists/copr-devel@lists.fedorahosted.org

Fwd: New Release!

[Michal Novotny]

On Tue, Aug 30, 2016 at 7:43 AM, Pavel Raiskup  wrote:

> On Tuesday, August 30, 2016 7:39:14 AM CEST Pavel Raiskup wrote:
> > Currently it looks like such error-handling is not implemented anyway,
> > we drop the build and it is re-submitted after some deadline.
>
> By "drop" here I mean that the build simply fails on BE, while it is still
> in "running" state in FE databse.  That build is put in queue once again
> after MAX_BUILD_TIMEOUT.handling non-responsive VMs.


But that's different from the (primitive) deferring mechanism where backend
takes any job that frontend feeds it with and returns it back (effectively
saying
"try to give me this job later") if it finds out the job cannot be handled
at the moment.

If you would like to use what you have described to implement "deferring",
then I doubt you can fit it on that very well.

I am satisfied with the current state and will implement more only if/when
I find it
insufficient (meaning "performing very badly") later but feel free to send
us patches
for this sooner if desired.


>
> Pavel
>
>
___
copr-devel mailing list
copr-devel@lists.fedorahosted.org
https://lists.fedorahosted.org/admin/lists/copr-devel@lists.fedorahosted.org

Re: New Release!

[Pavel Raiskup]

On Tuesday, August 30, 2016 7:39:14 AM CEST Pavel Raiskup wrote:
> Currently it looks like such error-handling is not implemented anyway,
> we drop the build and it is re-submitted after some deadline.

By "drop" here I mean that the build simply fails on BE, while it is still
in "running" state in FE databse.  That build is put in queue once again
after MAX_BUILD_TIMEOUT.

Pavel
___
copr-devel mailing list
copr-devel@lists.fedorahosted.org
https://lists.fedorahosted.org/admin/lists/copr-devel@lists.fedorahosted.org

Re: New Release!

[Pavel Raiskup]

On Tuesday, August 30, 2016 7:22:25 AM CEST Michal Novotny wrote:
> On Mon, Aug 29, 2016 at 3:33 PM, Pavel Raiskup  wrote:
> >   * You can lower the BE<->FE traffic, and significantly lower IO on
> > front-end --> because then you can first allocate appropriate VM, and
> > right after that assign job (not vice versa: take job, then try to
> > take VM and possibly defer the job).
> >
> 
> You wouldn't exactly allocate appropriate VM. Rather, some VMs were
> preallocated (ideally taking all the available resources and all busy
> building) and you would acquire a new build job of the fitting arch when one
> of them became free.

That's what I meant, but now it is correctly worded.

> I am not sure if we can completely remove job deferring because it is good for
> cases when a backend took a job it cannot (currently) handle.
> That, in theory, shouldn't happen with this approach of taking jobs only
> if there is an available VM of the job's required arch but you never
> know and deferring is better than dropping.

.. though s/defer/resubmit/ sounds better.  Currently it looks like such
error-handling is not implemented anyway, we drop the build and it is
re-submitted after some deadline.  Also the "defer" action would be rather
about trivial "running" -> "pending" transition.

Pavel
___
copr-devel mailing list
copr-devel@lists.fedorahosted.org
https://lists.fedorahosted.org/admin/lists/copr-devel@lists.fedorahosted.org

Re: New Release!

[Michal Novotny]

On Mon, Aug 29, 2016 at 3:33 PM, Pavel Raiskup  wrote:

> On Monday, August 29, 2016 1:04:58 PM CEST Michal Novotny wrote:
> > On Fri, Aug 26, 2016 at 6:22 PM, Pavel Raiskup 
> wrote:
> > > Does it spawn builders even if there is no build queue yet?
> >
> > Yes, it does. I completely cut off our backend dev instance from frontend
> > and repeated the fresh-start experiment.
> > This time the build queue was empty for sure and the builders were still
> > being spawned. I also confirmed in the
> > code that it should be so. These parts (around VmMaster ) weren't
> touched.
>
> Perfect, thanks.
>
> I've done a quick review of the patch now, and I pretty much like the
> backend's "take-one-task" only approach.  That way you can control the
> queue on frontend (with atomicity given by PostgreSQL), while still that
> is 'pull down' approach from backend.
>
> There is one drawback, however -- the ugly workaround DEFER_BUILD_SECONDS.
> The problem is that you now put all builds (all architectures) into one
> build queue (that has "starving" consequences if you wasn't using
> DEFER_BUILD_SECONDS).
>
> I would suggest you to add one additional argument into /backend/waiting/
> backend API -> requested architecture.
>

Good idea.


>   * Then, you can remove everything related to "defer" action both on BE
> and FE.
>
>   * You can lower the BE<->FE traffic, and significantly lower IO on
> front-end --> because then you can first allocate appropriate VM, and
> right after that assign job (not vice versa: take job, then try to
> take VM and possibly defer the job).
>

You wouldn't exactly allocate appropriate VM. Rather, some VMs were
preallocated
(ideally taking all the available resources and all busy building) and you
would acquire
a new build job of the fitting arch when one of them became free. I am not
sure if we can
completely remove job deferring because it is good for cases when a backend
took a job
it cannot (currently) handle. That, in theory, shouldn't happen with this
approach of taking jobs
only if there is an available VM of the job's required arch but you never
know and deferring is
better than dropping.

Also, the 'take-build' (load_job() in particular) method should be "atomic"
> ->
> automatically move the action into 'running' state, and completely remove
> the
> "starting" state, which has zero informational value anyway (users
> know/should
> know the build queue priority anyway).
>

That's probably right.


>
>   * Then we could much easily implement "multiple-backends"
> support, I wanted to have something like this for a long time.
>

Cannot see into this but sounds good.


> Pavel
>
>
___
copr-devel mailing list
copr-devel@lists.fedorahosted.org
https://lists.fedorahosted.org/admin/lists/copr-devel@lists.fedorahosted.org

Re: New Release!

[Pavel Raiskup]

On Monday, August 29, 2016 1:04:58 PM CEST Michal Novotny wrote:
> On Fri, Aug 26, 2016 at 6:22 PM, Pavel Raiskup  wrote:
> > Does it spawn builders even if there is no build queue yet?
> 
> Yes, it does. I completely cut off our backend dev instance from frontend
> and repeated the fresh-start experiment.
> This time the build queue was empty for sure and the builders were still
> being spawned. I also confirmed in the
> code that it should be so. These parts (around VmMaster ) weren't touched.

Perfect, thanks.

I've done a quick review of the patch now, and I pretty much like the
backend's "take-one-task" only approach.  That way you can control the
queue on frontend (with atomicity given by PostgreSQL), while still that
is 'pull down' approach from backend.

There is one drawback, however -- the ugly workaround DEFER_BUILD_SECONDS.
The problem is that you now put all builds (all architectures) into one
build queue (that has "starving" consequences if you wasn't using
DEFER_BUILD_SECONDS).

I would suggest you to add one additional argument into /backend/waiting/
backend API -> requested architecture.

  * Then, you can remove everything related to "defer" action both on BE
and FE.

  * You can lower the BE<->FE traffic, and significantly lower IO on
front-end --> because then you can first allocate appropriate VM, and
right after that assign job (not vice versa: take job, then try to
take VM and possibly defer the job).

Also, the 'take-build' (load_job() in particular) method should be "atomic" ->
automatically move the action into 'running' state, and completely remove the
"starting" state, which has zero informational value anyway (users know/should
know the build queue priority anyway).

  * Then we could much easily implement "multiple-backends"
support, I wanted to have something like this for a long time.

Pavel
___
copr-devel mailing list
copr-devel@lists.fedorahosted.org
https://lists.fedorahosted.org/admin/lists/copr-devel@lists.fedorahosted.org

Re: New Release!

[Pavel Raiskup]

On Friday, August 26, 2016 6:19:56 PM CEST Michal Novotny wrote:
> On Fri, Aug 26, 2016 at 4:50 PM, Pavel Raiskup  wrote:
> 
> > On Friday, August 26, 2016 4:15:50 PM CEST Michal Novotny wrote:
> > > On Fri, Aug 26, 2016 at 3:46 PM, Pavel Raiskup 
> > wrote:
> > > > Because in instance I maintain, we have currently like 7 builders
> > > > preallocated and booted, and thus backend doesn't have to wait till the
> > > > builder VM boots up.
> > >
> > > Spawning of virtual machines should/can be independent of copr-backend
> > process
> > > itself and of allocating worker processes. If that isn't so, that
> > > could be a nice improvement.
> >
> > That already worked -- I don't see benefits in removing that feature (we
> > wasted
> > a lot of time on it).  Just a reason to put "sad face" here.
> >
> 
> Then I have good news for you...It works now as well! :-) I have just started
> a fresh copr-backend instance (remove vms from OS, flush redis, restart
> backend) in our dev environment and it immediately began to spawn new
> builders.

Does it spawn builders even if there is no build queue yet?

Thanks, Pavel
___
copr-devel mailing list
copr-devel@lists.fedorahosted.org
https://lists.fedorahosted.org/admin/lists/copr-devel@lists.fedorahosted.org

Re: New Release!

[Michal Novotny]

On Fri, Aug 26, 2016 at 4:50 PM, Pavel Raiskup  wrote:

> On Friday, August 26, 2016 4:15:50 PM CEST Michal Novotny wrote:
> > On Fri, Aug 26, 2016 at 3:46 PM, Pavel Raiskup 
> wrote:
> > > Because in instance I maintain, we have currently like 7 builders
> > > preallocated and booted, and thus backend doesn't have to wait till the
> > > builder VM boots up.
> >
> > Spawning of virtual machines should/can be independent of copr-backend
> process
> > itself and of allocating worker processes. If that isn't so, that
> > could be a nice improvement.
>
> That already worked -- I don't see benefits in removing that feature (we
> wasted
> a lot of time on it).  Just a reason to put "sad face" here.
>

Then I have good news for you...It works now as well! :-) I have just
started a fresh
copr-backend instance (remove vms from OS, flush redis, restart backend) in
our
dev environment and it immediately began to spawn new builders.


> Pavel
>
>
___
copr-devel mailing list
copr-devel@lists.fedorahosted.org
https://lists.fedorahosted.org/admin/lists/copr-devel@lists.fedorahosted.org

Re: New Release!

[Pavel Raiskup]

On Friday, August 26, 2016 4:15:50 PM CEST Michal Novotny wrote:
> On Fri, Aug 26, 2016 at 3:46 PM, Pavel Raiskup  wrote:
> > Because in instance I maintain, we have currently like 7 builders
> > preallocated and booted, and thus backend doesn't have to wait till the
> > builder VM boots up.
> 
> Spawning of virtual machines should/can be independent of copr-backend process
> itself and of allocating worker processes. If that isn't so, that
> could be a nice improvement.

That already worked -- I don't see benefits in removing that feature (we wasted
a lot of time on it).  Just a reason to put "sad face" here.

Pavel
___
copr-devel mailing list
copr-devel@lists.fedorahosted.org
https://lists.fedorahosted.org/admin/lists/copr-devel@lists.fedorahosted.org

Re: New Release!

[Pavel Raiskup]

On Thursday, August 25, 2016 9:43:53 PM CEST Michal Novotny wrote:
> the queue is now maintained only in frontend and backend is served with tasks
> one by one. Workers are being spawned "on demand". Their maximum count is
> determined by configured maximum number of virtual machines that can be
> allocated. The code emerged as a reaction to the problem described in
> https://bugzilla.redhat.com/ show_bug.cgi?id=1344805.

Thanks for the link, but - ouch :( that sounds like a non-trivial step back.
At least for those who don't have super powerful Open Stack cloud which would
give them instances within 10s.

Pavel
___
copr-devel mailing list
copr-devel@lists.fedorahosted.org
https://lists.fedorahosted.org/admin/lists/copr-devel@lists.fedorahosted.org

Re: New Release!

[Michal Novotny]

Hello Pavel,

On Thu, Aug 25, 2016 at 2:21 PM, Pavel Raiskup  wrote:

> On Thursday, August 18, 2016 1:30:57 PM CEST Michal Novotny wrote:
> > 2) Waiting-queue logic has been rewritten. I believe there will be not
> much
> > of a perceived performance improvement but we managed to cut the relevant
> > code length almost by half and simplify some bits.
>
> Hms, thanks for the info.  That commit 1c51da66151df0e1add7ca877568d1
> 6584793bef
> removed a lot of code in scheduler, which was a debugged with care and took
> (really) non-trival efforts to get it working right ...
>
> What exactly changed, is there link for patch review to simplify reading,
> to
> follow reasoning behind?
>
Does that mean that we no longer preallocate workers (looks like
> 'max_workers'
> backend parameter disappeared)?  Where is the queue mainained now (python
> retask
> is missing)?
>

the queue is now maintained only in frontend and backend is served with
tasks one by
one. Workers are being spawned "on demand". Their maximum count is
determined by
configured maximum number of virtual machines that can be allocated. The
code emerged as
a reaction to the problem described in https://bugzilla.redhat.com/
show_bug.cgi?id=1344805.


> Pavel
___
copr-devel mailing list
copr-devel@lists.fedorahosted.org
https://lists.fedorahosted.org/admin/lists/copr-devel@lists.fedorahosted.org

Re: New Release!

[Pavel Raiskup]

On Thursday, August 18, 2016 1:30:57 PM CEST Michal Novotny wrote:
> 2) Waiting-queue logic has been rewritten. I believe there will be not much
> of a perceived performance improvement but we managed to cut the relevant
> code length almost by half and simplify some bits.

Hms, thanks for the info.  That commit 1c51da66151df0e1add7ca877568d16584793bef
removed a lot of code in scheduler, which was a debugged with care and took
(really) non-trival efforts to get it working right ...

What exactly changed, is there link for patch review to simplify reading, to
follow reasoning behind?

Does that mean that we no longer preallocate workers (looks like 'max_workers'
backend parameter disappeared)?  Where is the queue mainained now (python retask
is missing)?

Pavel
___
copr-devel mailing list
copr-devel@lists.fedorahosted.org
https://lists.fedorahosted.org/admin/lists/copr-devel@lists.fedorahosted.org

New Release!

[Michal Novotny]

Hello packagers & devs,

we have just deployed a new release of COPR eco-system. The changes made
are mainly internal but should help to solve some issues we have been
tackling recently. The most important upgrades are:

1) copr-dist-git service is now parallel ("multi-process"). That means that
if there is a problem with a job import, the other jobs won't be blocked.
Also we added import-job timing out so if import gets stuck, it doesn't get
stuck forever.

2) Waiting-queue logic has been rewritten. I believe there will be not much
of a perceived performance improvement but we managed to cut the relevant
code length almost by half and simplify some bits.

3) We have fixed appstream meta-data building - a bug that also influenced
forking. When a project was forked the rpm re-signing process kept looping.
Other actions were blocked by this. Hence, in addition to fix the root
cause (the meta-data building), we also needed to fix the forking logic to
handle the errors better.

4) We have introduced a first bits of support for modularity

So that's it. I hope COPR will serve you well.
COPR team
___
copr-devel mailing list
copr-devel@lists.fedorahosted.org
https://lists.fedorahosted.org/admin/lists/copr-devel@lists.fedorahosted.org

Re: New release of Copr

[Miroslav Suchý]

Dne 20.6.2016 v 13:49 Pavel Raiskup napsal(a):
> On Thursday, June 16, 2016 3:10:04 PM CEST Miroslav Suchy 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.
>>
>> If you want to give it try, then you can install it from our copr project.
> 
> Sorry I haven't posted earlier, I'm writing while I'm facing one bugreport.
> 
> Note that new python-copr library breaks the compatibility with older servers.
> While trying to submit new build (or request for new copr) from command line,
> frontend replies with (and copr-cli fails with):
> 
> Unknown arguments passed (non-existing chroot probably)"
> 
> That's because the new client library sends useless content in POST to
> frontend.  The older frontend was guarded against this.  Possibly we should
> be more careful to not break client/server protocol like that in future :).
> 
> Ugly "hot-fix" is attached.

I just talked to Pavel in person and we agreed that best way is to upgrade his 
instance.
But yeah... we will try to focus on backward compatibility next time.


-- 
Miroslav Suchy, RHCA
Red Hat, Senior Software Engineer, #brno, #devexp, #fedora-buildsys
___
copr-devel mailing list
copr-devel@lists.fedorahosted.org
https://lists.fedorahosted.org/admin/lists/copr-devel@lists.fedorahosted.org

Re: New release of Copr

[Pavel Raiskup]

On Thursday, June 16, 2016 3:10:04 PM CEST Miroslav Suchy 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.
> 
> If you want to give it try, then you can install it from our copr project.

Sorry I haven't posted earlier, I'm writing while I'm facing one bugreport.

Note that new python-copr library breaks the compatibility with older servers.
While trying to submit new build (or request for new copr) from command line,
frontend replies with (and copr-cli fails with):

Unknown arguments passed (non-existing chroot probably)"

That's because the new client library sends useless content in POST to
frontend.  The older frontend was guarded against this.  Possibly we should
be more careful to not break client/server protocol like that in future :).

Ugly "hot-fix" is attached.

Pavel
--- ./pkgs/rhcopr-frontend/copr-frontend-1.78/coprs_frontend/coprs/views/api_ns/api_general.py	2016-06-20 13:04:23.917502292 +0200
+++ raw	2016-06-20 13:39:53.958941383 +0200
@@ -97,11 +97,11 @@
 
 # are there any arguments in POST which our form doesn't know?
 # TODO: don't use WTFform for parsing and validation here
-if any([post_key not in form.__dict__.keys()
-for post_key in flask.request.form.keys()]):
-raise LegacyApiError("Unknown arguments passed (non-existing chroot probably)")
+# if any([post_key not in form.__dict__.keys()
+# for post_key in flask.request.form.keys()]):
+# raise LegacyApiError("Unknown arguments passed (non-existing chroot probably)")
 
-elif form.validate_on_submit():
+if form.validate_on_submit():
 infos = []
 
 try:
@@ -259,13 +259,12 @@
 @api_req_with_copr
 def copr_new_build(copr):
 
-# are there any arguments in POST which our form doesn't know?
-if any([post_key not in form.__dict__.keys()
-for post_key in flask.request.form.keys()]):
-raise LegacyApiError("Unknown arguments passed (non-existing chroot probably)")
+# # are there any arguments in POST which our form doesn't know?
+# if any([post_key not in form.__dict__.keys()
+# for post_key in flask.request.form.keys()]):
+# raise LegacyApiError("Unknown arguments passed (non-existing chroot probably!)")
 
 if not form.validate_on_submit():
 raise LegacyApiError("Invalid request: bad request parameters")
@@ -313,9 +312,12 @@
 form = forms.BuildFormUploadFactory(copr.active_chroots)(csrf_enabled=False)
 
 # are there any arguments in POST which our form doesn't know?
-if any([post_key not in form.__dict__.keys()
-for post_key in flask.request.form.keys()]):
-raise LegacyApiError("Unknown arguments passed (non-existing chroot probably)")
+# if any([post_key not in form.__dict__.keys()
+# for post_key in flask.request.form.keys()]):
+# keys_allowed = ' '.join(form.__dict__.keys())
+# keys_added = ' '.join(flask.request.form.keys())
+# s = keys_allowed + " => " + keys_added
+# raise LegacyApiError("Unknown arguments passed (non-existing chroot probably)" + s)
 
 if not form.validate_on_submit():
 raise LegacyApiError("Invalid request: bad request parameters")
___
copr-devel mailing list
copr-devel@lists.fedorahosted.org
https://lists.fedorahosted.org/admin/lists/copr-devel@lists.fedorahosted.org

Re: New release of Copr

[Michal Novotny]

I am not a fan of letting "the old one" die. The whole package building and
manipulation interface as well as lately added commands like buildpypi,
buildgem, buildtito, buildmock, watch-build were implemented in the
clientv1 and with API1. The reason is that the code for API1 and in the
original python copr client is much better structured and development there
is significantly easier.

clime


On Thu, Jun 16, 2016 at 9:23 PM, Jakub Kadlcik  wrote:

> > Looks like it was not implemented in client_v2 in python-copr...
>
> Hi Igor,
> the copr-cli still uses the legacy client, so it was added there. We
> should really migrate it to client_v2 and let the old one die.
>
> I don't know what are Mirek's plans for next sprints, but maybe I could
> work on it.
>
> Jakub
>
>
> - Original Message -
> From: "Igor Gnatenko" 
> To: "Cool Other Package Repositories" 
> Sent: Thursday, June 16, 2016 5:26:24 PM
> Subject: Re: New release of Copr
>
> On Thu, Jun 16, 2016 at 3:10 PM, Miroslav Suchy  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
> ___
> copr-devel mailing list
> copr-devel@lists.fedorahosted.org
>
> https://lists.fedorahosted.org/admin/lists/copr-devel@lists.fedorahosted.org
>
___
copr-devel mailing list
copr-devel@lists.fedorahosted.org
https://lists.fedorahosted.org/admin/lists/copr-devel@lists.fedorahosted.org

Re: New release of Copr

[Jakub Kadlcik]

> Looks like it was not implemented in client_v2 in python-copr...

Hi Igor,
the copr-cli still uses the legacy client, so it was added there. We should 
really migrate it to client_v2 and let the old one die.

I don't know what are Mirek's plans for next sprints, but maybe I could work on 
it.

Jakub


- Original Message -
From: "Igor Gnatenko" 
To: "Cool Other Package Repositories" 
Sent: Thursday, June 16, 2016 5:26:24 PM
Subject: Re: New release of Copr

On Thu, Jun 16, 2016 at 3:10 PM, Miroslav Suchy  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
___
copr-devel mailing list
copr-devel@lists.fedorahosted.org
https://lists.fedorahosted.org/admin/lists/copr-devel@lists.fedorahosted.org

Re: New release of Copr

[Igor Gnatenko]

On Thu, Jun 16, 2016 at 3:10 PM, Miroslav Suchy  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

New release of Copr

[Miroslav Suchy]

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.


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

Re: New Release !

[Michal Novotny]

> Package handling through copr-cli
(creating/editing/deleting/listing/fetching)

For this new feature, you will need the latest update of copr-cli (1.51)
and python-copr (1.70).

Currently, they are to be found here:
https://bodhi.fedoraproject.org/updates/FEDORA-2016-14c6d04e21 for F23 and
also in the official COPR repository here:
https://copr.fedorainfracloud.org/coprs/g/copr/copr/

python-copr 1.70 also fixes building from command line by using copr-cli
for the current production instance (see *Bug 1340650*
 - SRPM builds
submitted from CLI fail: "invalid request").

clime

On Mon, May 30, 2016 at 10:26 AM, Miroslav Suchý  wrote:

> Dne 27.5.2016 v 20:59 Michal Novotny napsal(a):
> > a new COPR version was released and put into production today. Apart
> from numerous bug fixes, we have also introduced
> > couple of cool new features:
> > - Building RubyGems
>
> Jakub wrote nice blog post about this feature:
>   http://frostyx.cz/posts/copr-rubygems
>
> --
> Miroslav Suchy, RHCA
> Red Hat, Senior Software Engineer, #brno, #devexp, #fedora-buildsys
> ___
> copr-devel mailing list
> copr-devel@lists.fedorahosted.org
>
> https://lists.fedorahosted.org/admin/lists/copr-devel@lists.fedorahosted.org
>
___
copr-devel mailing list
copr-devel@lists.fedorahosted.org
https://lists.fedorahosted.org/admin/lists/copr-devel@lists.fedorahosted.org

Re: New Release !

[Miroslav Suchý]

Dne 27.5.2016 v 20:59 Michal Novotny napsal(a):
> a new COPR version was released and put into production today. Apart from 
> numerous bug fixes, we have also introduced
> couple of cool new features:
> - Building RubyGems

Jakub wrote nice blog post about this feature:
  http://frostyx.cz/posts/copr-rubygems

-- 
Miroslav Suchy, RHCA
Red Hat, Senior Software Engineer, #brno, #devexp, #fedora-buildsys
___
copr-devel mailing list
copr-devel@lists.fedorahosted.org
https://lists.fedorahosted.org/admin/lists/copr-devel@lists.fedorahosted.org

New Release !

[Michal Novotny]

Hello,

a new COPR version was released and put into production today. Apart from
numerous bug fixes, we have also introduced couple of cool new features:
- Building RubyGems
- Package handling through copr-cli
(creating/editing/deleting/listing/fetching)
- speeding up Package view
- build timeout increased to 24 hours
- searching by package names
- enable other group users to edit the project settings

I hope, you will enjoy those.

The bugfixes include:
- Bug 1337446 - Broken links to builds in package tab
- Bug 1336360 - reverse naming for custom and mageia chroots
- Bug 1333792 - do not count group projects
- Bug 1334625 - Search for coprs owned by a group does not work
- Bug 1334575 - Missing package name in "Recent builds" tab for upload/url
builds
- Bug 1334390 - Bad link in Recent Builds for group project
- Bug 1333082 - Disable createrepo does not work on group project

clime
___
copr-devel mailing list
copr-devel@lists.fedorahosted.org
https://lists.fedorahosted.org/admin/lists/copr-devel@lists.fedorahosted.org

New release

[Miroslav Suchý]

Hi,
today I released new version of Copr.

There is
* lot of bugfixes. Mainly related to group projects.
* fix related to generation of GPG keys (see email on fedora devel mailing 
list).
* performance improvements for projects with 5+ builds
* copr-dist-git machine has been migrated to Fedora 23, which enable usage of 
Weak and Rich dependencies in spec file
* there is errata for F24 and F23 for python-copr and copr-cli which have been 
released in new version too.

-- 
Miroslav Suchy, RHCA
Red Hat, Senior Software Engineer, #brno, #devexp, #fedora-buildsys
___
copr-devel mailing list
copr-devel@lists.fedorahosted.org
https://lists.fedorahosted.org/admin/lists/copr-devel@lists.fedorahosted.org

New release

[Miroslav Suchý]

Hi,
today I released new version of Copr.

There is
* lot of bugfixes. Mainly related to group projects.
* fix related to generation of GPG keys (see email on fedora devel mailing 
list).
* performance improvements for projects with 5+ builds
* copr-dist-git machine has been migrated to Fedora 23, which enable usage of 
Weak and Rich dependencies in spec file
* there is errata for F24 and F23 for python-copr and copr-cli which have been 
released in new version too.

-- 
Miroslav Suchy, RHCA
Red Hat, Senior Software Engineer, #brno, #devexp, #fedora-buildsys
___
copr-devel mailing list
copr-devel@lists.fedorahosted.org
https://lists.fedorahosted.org/admin/lists/copr-devel@lists.fedorahosted.org

New release of Copr

[Miroslav Suchý]

I just deployed in production new version of Copr.

It is mostly bugfix release.
It contains one new feature, but it has some performance issues so I'm not 
going to announce it yet. If you discover it,
then feel free to test it, but do not use it too much :)
-- 
Miroslav Suchy, RHCA
Red Hat, Senior Software Engineer, #brno, #devexp, #fedora-buildsys
___
copr-devel mailing list
copr-devel@lists.fedorahosted.org
https://lists.fedorahosted.org/admin/lists/copr-devel@lists.fedorahosted.org

Re: New release of Copr

[Miroslav Suchy]

On 11/10/2015 04:01 PM, Jean-Marc LIGER wrote:
> So, there is a little but annoying bug with the Build ID order : 9
> is evaluated as superior as 10. This may also affect the Last build
> package information which isn't correct now.

https://bugzilla.redhat.com/show_bug.cgi?id=1272184

New version with this fix will be deployed soon (I really hoped for
yesterday... so matter of days).

Mirek
___
copr-devel mailing list
copr-devel@lists.fedorahosted.org
https://lists.fedorahosted.org/mailman/listinfo/copr-devel

Re: New release of Copr

[Jean-Marc LIGER]

Hi Miroslav,

As usual, new Copr release is really better than previous release, and 
as usual I'm really sorry to point out some slight regression.


So, there is a little but annoying bug with the Build ID order : 9 
is evaluated as superior as 10. This may also affect the Last build 
package information which isn't correct now.


Regards,
Jean-Marc



Le 15/10/2015 11:33, Miroslav Suchý a écrit :

It is my pleasure to announce new version of Copr.
   https://copr.fedoraproject.org/

What's new? Group projects!

When you log in. You can see in right column link "My Groups". There you can 
see list of your FAS groups and you can
activate them. In fact, you actually create alias for them. E.g. FAS group "gitmock" can 
be named "mock" in Copr.
You can click on Copr group in right column. That navigate you to url in format:

  https://copr.fedoraproject.org/groups/g/mock/coprs/

Where are listed all projects of this group. And you can create new group 
project there too.
Every member of that FAS group can administer it and build there. Due to the 
OpenID limitations, you have to
log-out/log-in to see your groups (or whenever you join new group in FAS).

Since copr-cli-1.45 (in updates-testing right now) you can submit package to 
group project like:
   copr-cli build @GROUP/PROJECT
e.g
   copr-cli build @mock/mock-dev

Creation of group project is not possible from command line right now due 
OpenID restriction and you have to use WebUI.
This may change in near future.

There is no API method in APIv1. But we provide APIv2
   http://copr-rest-api.readthedocs.org/en/latest/
which has methods to manipulate with groups.

To create new group in FAS, just follow:
   https://admin.fedoraproject.org/accounts/group/new

If you have some personal project and you want to change it to group project, 
then please let me know and we change it
manually.


___
copr-devel mailing list
copr-devel@lists.fedorahosted.org
https://lists.fedorahosted.org/mailman/listinfo/copr-devel

Re: New release of Copr

[Miroslav Suchý]

Dne 15.10.2015 v 13:39 Stuart Campbell napsal(a):
> Excellent feature. Does this imply that we can now request FAS groups
> for non-fedora projects?  For example, I am working on some software and
> want to package it and make it available to users via copr. There are a
> number of people who I want to have access so groups is a fantastic
> solution.

As long as it is for Copr projects I do not see reason, why it should be 
rejected.

-- 
Miroslav Suchy, RHCA
Red Hat, Senior Software Engineer, #brno, #devexp, #fedora-buildsys
___
copr-devel mailing list
copr-devel@lists.fedorahosted.org
https://lists.fedorahosted.org/mailman/listinfo/copr-devel

Re: New release of Copr

[Stuart Campbell]

Excellent feature. Does this imply that we can now request FAS groups
for non-fedora projects?  For example, I am working on some software and
want to package it and make it available to users via copr. There are a
number of people who I want to have access so groups is a fantastic
solution.

Cheers
Stu

-- 
Dr Stuart Campbell
email: s...@fedoraproject.org

On Thu, 15 Oct 2015, at 05:33 AM, Miroslav Suchý wrote:
> It is my pleasure to announce new version of Copr.
>   https://copr.fedoraproject.org/
> 
> What's new? Group projects!
> 
> When you log in. You can see in right column link "My Groups". There you
> can see list of your FAS groups and you can
> activate them. In fact, you actually create alias for them. E.g. FAS
> group "gitmock" can be named "mock" in Copr.
> You can click on Copr group in right column. That navigate you to url in
> format:
> 
>  https://copr.fedoraproject.org/groups/g/mock/coprs/
> 
> Where are listed all projects of this group. And you can create new group
> project there too.
> Every member of that FAS group can administer it and build there. Due to
> the OpenID limitations, you have to
> log-out/log-in to see your groups (or whenever you join new group in
> FAS).
> 
> Since copr-cli-1.45 (in updates-testing right now) you can submit package
> to group project like:
>   copr-cli build @GROUP/PROJECT
> e.g
>   copr-cli build @mock/mock-dev
> 
> Creation of group project is not possible from command line right now due
> OpenID restriction and you have to use WebUI.
> This may change in near future.
> 
> There is no API method in APIv1. But we provide APIv2
>   http://copr-rest-api.readthedocs.org/en/latest/
> which has methods to manipulate with groups.
> 
> To create new group in FAS, just follow:
>   https://admin.fedoraproject.org/accounts/group/new
> 
> If you have some personal project and you want to change it to group
> project, then please let me know and we change it
> manually.
> -- 
> Miroslav Suchy, RHCA
> Red Hat, Senior Software Engineer, #brno, #devexp, #fedora-buildsys
> ___
> copr-devel mailing list
> copr-devel@lists.fedorahosted.org
> https://lists.fedorahosted.org/mailman/listinfo/copr-devel
___
copr-devel mailing list
copr-devel@lists.fedorahosted.org
https://lists.fedorahosted.org/mailman/listinfo/copr-devel

New release of Copr

[Miroslav Suchý]

It is my pleasure to announce new version of Copr.
  https://copr.fedoraproject.org/

What's new? Group projects!

When you log in. You can see in right column link "My Groups". There you can 
see list of your FAS groups and you can
activate them. In fact, you actually create alias for them. E.g. FAS group 
"gitmock" can be named "mock" in Copr.
You can click on Copr group in right column. That navigate you to url in format:

 https://copr.fedoraproject.org/groups/g/mock/coprs/

Where are listed all projects of this group. And you can create new group 
project there too.
Every member of that FAS group can administer it and build there. Due to the 
OpenID limitations, you have to
log-out/log-in to see your groups (or whenever you join new group in FAS).

Since copr-cli-1.45 (in updates-testing right now) you can submit package to 
group project like:
  copr-cli build @GROUP/PROJECT
e.g
  copr-cli build @mock/mock-dev

Creation of group project is not possible from command line right now due 
OpenID restriction and you have to use WebUI.
This may change in near future.

There is no API method in APIv1. But we provide APIv2
  http://copr-rest-api.readthedocs.org/en/latest/
which has methods to manipulate with groups.

To create new group in FAS, just follow:
  https://admin.fedoraproject.org/accounts/group/new

If you have some personal project and you want to change it to group project, 
then please let me know and we change it
manually.
-- 
Miroslav Suchy, RHCA
Red Hat, Senior Software Engineer, #brno, #devexp, #fedora-buildsys
___
copr-devel mailing list
copr-devel@lists.fedorahosted.org
https://lists.fedorahosted.org/mailman/listinfo/copr-devel