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*
<https://bugzilla.redhat.com/show_bug.cgi?id=1340650> - SRPM builds
submitted from CLI fail: "invalid request").

clime

On Mon, May 30, 2016 at 10:26 AM, Miroslav Suchý <msu...@redhat.com> 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

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

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

Tackling COPR service performance issues

[Michal Novotny]

Hello guys,

we, COPR team, are very sorry for the latest service occasional
unavailability. There were several performance issues that we needed to
sort out:

1) High memory consumption in API1 on a copr detail - resolved by code
optimization
2) Timeouts on search index updating - resolved by employing regular batch
index updates instead of event-triggered ones
3) Memory consumption needed to render RubyGems monitor page - this was
tackled by rewriting the code from SQLAlchemy to pure SQL

The RubyGems and PyPI package/build/monitor pages still take a long time
for their delivery. Mirek Suchy implemented streamed server responses to
prevent page timeouts which should alleviate the situation a little bit. We
are open to any further ideas that could help us make these COPR resources
more available.

After the mentioned updates, the COPR service availability should be much
better. If any further issues should occur, we will react promptly.

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

service outage

[Michal Novotny]

Hello folks,

there will be an outage starting at 2016-07-22 02:00 UTC and will last
approximately 4 hours.

The reason is OpenStack upgrade on cloud machines where COPR runs. Please
see https://fedorahosted.org/fedora-infrastructure/ticket/5410.

After that, we will be back :).

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

Re: Please kill my 47 hours old build

[Michal Novotny]

Done :-). M.

On Thu, Aug 11, 2016 at 7:21 PM, Miro Hrončok  wrote:

> https://copr.fedorainfracloud.org/coprs/g/python/python33/build/439804/
>
> Thanks
> --
> Miro Hrončok
> --
> Phone: +420777974800
> IRC: mhroncok
> ___
> 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: builld process in trouble ?

[Michal Novotny]

> By the way, at least two of my builds have been run twice, when I sent my
e-mail saturday.

This may happen if the backend service is restarted.


Thank you for the info! We are working on the new build queue process that
will hopefully be more reliable.

Best Regards
clime

On Mon, Jul 11, 2016 at 11:22 AM, Jean-Marc LIGER <
jean-marc.li...@parisdescartes.fr> wrote:

> Hello Michal,
>
> It's ok now and since yesterday's lunch time.
>
> Before, there was one build, I haven't noticed the name, in running mode
> for many hours and the other builds which were in waiting/starting mode.
>
> By the way, at least two of my builds have been run twice, when I sent my
> e-mail saturday.
>
> Regards,
> Jean-Marc
>
> Le 11/07/16 à 10:30, Michal Novotny a écrit :
>
> Hello Jean,
>
> what kind of trouble? Currently, it seems to work well. Sorry that we
> didn't react earlier by the way.
>
> Can you point us to the problematic build? I'll take closer look at it
> afterwards.
>
> Best regards
> clime
>
>
>
> On Sat, Jul 9, 2016 at 1:48 PM, Jean-Marc Liger <
> jean-marc.li...@parisdescartes.fr> wrote:
>
>> Hi,
>>
>> The build process seems in trouble.
>>
>> Regards,
>>
>> Jean-Marc
>> ___
>> copr-devel mailing list
>> copr-devel@lists.fedorahosted.org
>>
>> https://lists.fedorahosted.org/admin/lists/copr-devel@lists.fedorahosted.org
>>
>
>
>
> ___
> copr-devel mailing 
> listcopr-devel@lists.fedorahosted.orghttps://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: builld process in trouble ?

[Michal Novotny]

Hello Jean,

what kind of trouble? Currently, it seems to work well. Sorry that we
didn't react earlier by the way.

Can you point us to the problematic build? I'll take closer look at it
afterwards.

Best regards
clime



On Sat, Jul 9, 2016 at 1:48 PM, Jean-Marc Liger <
jean-marc.li...@parisdescartes.fr> wrote:

> Hi,
>
> The build process seems in trouble.
>
> Regards,
>
> Jean-Marc
> ___
> 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

New releases of COPR packages

[Michal Novotny]

Hello,

we have released the following packages today:

- python-copr 1.72
- copr-cli 1.53
- copr-frontend 1.97
- copr-backend 1.91
- copr-selinux 1.43

It will take some time until they get into stable repos but if you do not
want to wait, you can find the built packages in our official COPR repo -
https://copr.fedorainfracloud.org/coprs/g/copr/copr/builds/ :).

Some of the most prominent features and bugfixes that the just released
packages offer are:

*Bug 1346288*  - Server
returning error 500 after large package upload
- this bug occurred randomly all over the site and was caused by heavy load
on our search index database. We took some of the load away by various
optimizations and the error should not occur anymore.

*Bug 1335237*  - copr
create command missing --disable_createrepo
 - fixed

*Bug 1335236*  - Internet
access during builds flag needed in CLI create/modify commands
 - we have added --enable-net parameter to copr-cli create/modify commands

*Bug 1346945*  - Project
List filled with automated builds
 - we have added --unlisted-on-hp parameter to copr-cli create/modify
commands

*Bug 1344805*  - Many
queued tasks from same user can block other user tasks
 - we have added --background option to new build in CLI that lowers
priority of the job and which is used to run the automated builds (you can
use it too if you feel like a super nice and charming person ;))

Additionally, we said "NO" to url and upload package types (or package
source types, more specifically) and removed those from copr-cli and
python-copr package manipulation interface. It was a hard decision but, for
the time being, the best possible as the url and upload builds are best to
be done with the old method of manually submitting a single 'New
build' whether it is via UI or copr-cli build command. It kind of makes
sense (on the second look) because source for these package is fixed to a
certain version and release of the package (either you upload package of a
certain version or you specify a link to it) and this limitation cannot
easily be overcome.

BUT for all the other package types (Tito/PyPI/MockSCM/RubyGems), you can
use a new cool command: copr-cli build-package --name pkgname coprname.

To use this, you first need to have a default source defined for the
package and this can be done in UI ('Packages' Tab in your splendid copr)
or through copr-cli's package manipulation interface, e.g.:
copr-cli add-package-tito --name pkgname --git-url someurl coprname.

What else...oh yeah, the version of python-copr 1.70 broke compatibility
with COPR frontend 1.92 and older (it was the 'source_type' error, sorry
for that). Well, python-copr 1.72 is much better in this matter and is
compatible with almost every available copr-frontend except for 1.93 ,
which is history now and was also screwed up to work together with
python-copr 1.70 (and copr-cli 1.51). Well, I guess we were trying to move
a bit too fast at that point...but, heh, let's keep that pace and just try
to avoid silly stones on the road.

clime

P.S.: I forgot to mention that the next release(s) will bring huge amount
of internal COPR improvements, be it multi-threaded copr-dist-git or
copr-backend with some crazy simplifications (+ optimizations) in build &
action task workflow (It all started with Mirek's great new design
proposal).

P.P.S: Related erratas:
https://bodhi.fedoraproject.org/updates/FEDORA-2016-e4496e8bda
https://bodhi.fedoraproject.org/updates/FEDORA-2016-af777aa589
https://bodhi.fedoraproject.org/updates/FEDORA-2016-313a6bfe5a
https://bodhi.fedoraproject.org/updates/FEDORA-2016-570ac5dcaf
___
copr-devel mailing list
copr-devel@lists.fedorahosted.org
https://lists.fedorahosted.org/admin/lists/copr-devel@lists.fedorahosted.org

New COPR release

[Michal Novotny]

Hey folks,

it is our great pleasure to announce that newly released packages have just
been deployed on COPR machines, that is:

copr-frontend *1.105-1*
copr-backend *1.96-1*
copr-dist-git *0.24-1*

These packages are f25 compatible (including copr-keygen) and offer some
new features:

copr-frontend:
- always show "Regenerate" button for recreating backend repodata
- display and improve info on modularity support in module details
- handle GitHub tag event webhooks
- option to login with krb5 now available

copr-backend:
- switched usage of deprecated ansible 1.x Runner for python-paramiko
module to be compatible with ansible 2
- support for STOMP (Simple Text Oriented Message Protocol) for sending
build info messages as an alternative to fedmsg

copr-dist-git:
- docker image upgraded to f25

You can find the complete list in the package changelogs, if required.

To make a long story short, apart from upgrades to run on F25, there is
also momentum to make COPR more general-purpose build system that can be
installed and used on other distributions too. Modularity support is still
a work in progress, although we are making some interesting progress. We
are also continuously aiming to improve user experience.

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

Re: Copr Dependencies for EL

[Michal Novotny]

On Wed, Feb 8, 2017 at 10:59 AM, Martin Juhl  wrote:

> Hi
>
> I have identified some missing dependencies for building COPR for
> CentOS/RHEL...
>
> Frontend:
>
> python-flask-whooshee: Is build in the Copr project, but needs to have added 
> EPEL as a build target, can you do that??
>
>
This package is also in Fedora, see
https://bodhi.fedoraproject.org/updates/FEDORA-2017-b3afc21666 for the
latest version of it. It is built in @copr/copr because we need the latest
version from upstream. That will be now provided by the update above. You
can make a package request for EPEL7.

> python-requests: I have requested a build: 
> https://bugzilla.redhat.com/show_bug.cgi?id=1420248
>
>
So this seems to be in RHEL, CentOS already. No need to include in EPEL
then?

>
> python-flask-script: I have requested a build: 
> https://bugzilla.redhat.com/show_bug.cgi?id=1420252
>
> Good.

>
>
> Backend:
>
> sphinx: Is this package needed?? I don't think it was there in v. 1.94... I 
> have requested a build: https://bugzilla.redhat.com/show_bug.cgi?id=1420257
>
>
Docs are built only for Fedora (see the spec), not for other distros. So
BuildRequires of python-sphinx should be conditioned by %if 0%{?fedora}
(currently it is not). Only python-sphinx is needed for docs building.
"sphinx" is a search engine and totally unrelated to copr-backend so that
BuildRequire can be removed. Please send a PR if you have time.

>
>
> I have also created a tracker bug, but I'm unsure how to use it?? is there a 
> way to link these build requests to the bug???: 
> https://bugzilla.redhat.com/show_bug.cgi?id=1420243
>
> You can also just track the progress in that bugzilla that you have
created (https://bugzilla.redhat.com/show_bug.cgi?id=1420243). Not sure if
we need anything more fancy.

>
> I'm also pulling in my collegue, Helgi Waag, to help me on this project...
>
> Great. Any help appreciated.

clime

>
> Regards
>
> /Martin
>
>
> ___
> 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

fedmsg hotfix

[Michal Novotny]

Hello, I will deploy fedmsg hotfix tomorrow at 7:30am UTC. I am very sorry
for the inconvenience.

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

Re: fedmsg structure change?

[Michal Novotny]

On Tue, Jan 24, 2017 at 10:40 PM, Pierre-Yves Chibon <pin...@pingoured.fr>
wrote:

> On Tue, Jan 24, 2017 at 01:36:59PM +0100, Michal Novotny wrote:
> >On Tue, Jan 24, 2017 at 11:44 AM, Pierre-Yves Chibon <
> pin...@pingoured.fr>
> >wrote:
> >
> >  On Tue, Jan 24, 2017 at 11:30:33AM +0100, Michal Novotny wrote:
> >  >Â  Â  Yes, untested changes got into production. We are sorry. I am
> >  currently
> >  >Â  Â  working on a fix.
> >
> >  If that made it up to production, then we'll need to adjust
> fedmsg_meta
> >  to
> >  support these messages as well.
> >
> >  fedmsg_meta should work for all our published messages (published
> and
> >  stored on
> >  datagrepper).
> >
> >Okay, these messages have all empty body (the "msg" attribute), e.g
> >`build.end`:
> >
> >  {
> >"source_name": "datanommer",
> >"i": 3,
> ...
> >"timestamp": 1485166967.0,
> >"msg_id": "2017-db23086c-2001-496e-a59f-10b92c466ae5",
> >"topic": "org.fedoraproject.prod.copr.build.end",
> >"source_version": "0.6.5",
> >"signature": "HJEOhP93vZFUk3cjIzggxZqIT+IRaLpKF/t21Kn0AcQ9B1VJEe+
> myerAAJMZfuXppGQqsFyzcPFx\nu+9p7geI5NqNxnN+diUXNlxbXN9/
> VN0X3vX7U4mbc0/zLyGcbKWIn/pcskbM5qYC2lJHLov0pMwq\nrbq/B0N3CxBL2og0Fj8=\n",
> >"msg": {}
> >  }
> >
> >Does fedmsg_meta need to be adjusted even so?
>
> Yeah, fedmsg_meta should be able to process all the messages stored in
> datagrepper, otherwise it breaks datagrepper and a few other apps.
>
> So we'll end up with some not so useful message: "a build ended in copr"
> but we
> should add them.
>

A malformed message (processed with the current fedmsg_meta:

*copr.build.start*
<https://apps.fedoraproject.org/datagrepper/raw?topic=org.fedoraproject.prod.copr.build.start>
Automated
build of the None copr has been started JSON
<https://apps.fedoraproject.org/datagrepper/id?id=2017-a8154546-d8eb-401c-9b66-9984572885da_raw=true=extra-large>

fedmsg_meta might already account for the case of missing fields. Looking
at the

code, I think this is the case.  Let me, please, know what you think.

>
> The easiest for this type of changes is to use test-driven-development,
> add the
> new message to the test, fill in the expectations and then adjust the
> processor
> to handle those cases.
>
> Pierre
> ___
> 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 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

Re: upcoming branching

[Michal Novotny]

On Mon, Feb 20, 2017 at 8:20 PM, Igor Gnatenko <ignate...@redhat.com> wrote:

> On Mon, 2017-02-20 at 16:16 +0100, Michal Novotny wrote:
> > Hello,
> >
> > as soon as branching is done and f26 repo links become available, we
> > will
> > switch the current fedora-26-* chroots from rawhide to use the f26
> > repositories.
> I'm more interested in fedora-27-* being added...
>

Hello, are you in favor of adding fedora-27 or rather fedora-rawhide back?
This is more general question to the crowd. Both are technically possible
but the question is what is less confusing. Does anything of it bring you
less work? f26 -> f27 -> etc has probably higher maintenance cost.


> >
> > COPR team
> > ___
> > copr-devel mailing list -- copr-devel@lists.fedorahosted.org
> > To unsubscribe send an email to copr-devel-leave@lists.fedorahosted.o
> > rg
>
> --
> -Igor Gnatenko
> ___
> 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: upcoming branching

[Michal Novotny]

On Tue, Feb 21, 2017 at 7:56 AM, Pavel Raiskup  wrote:

> On Tuesday, February 21, 2017 7:18:51 AM CET Igor Gnatenko wrote:
> > it depends. if you are planning to do mass-rebuild after branching in
> > all copr repos, then I prefer rawhide. If not, I prefer fXY.
>
> We had some off-list discussion with Michal and he was talking about
> something
> like "Settings -> Other Options" radio button:
>
> [ ] Fedora branching: Copy builds from Fedora N-1
> [ ] Fedora branching: Rebuild all packages from Fedora N-1
> [x] Fedora branching: Nothing happens
>
>
Something like that. I intended to allow both copying into a newly added
chroot and also
rebuilding all project packages for it. First as manually invoked user
action and then perhaps
add some automation. This can, however, work with both rawhide and just fXY
scheme.

Did I get this right?  Maybe we should have RFE for it?
>
>
The "copy builds" option is already sort-of implemented (worked for rawhide
> ->
> stable branching) but some fixes are needed per bug 1400941.
>

Yes, that's true, I would rather see that action to be implemented as
"fork-chroot" kind
to leave db records about builds that were copied (forked) but backend
logic is implemented.


>
> Pavel
>
> > >
> > >
> > > > >
> > > > > COPR team
> > > > > ___
> > > > > copr-devel mailing list -- copr-devel@lists.fedorahosted.org
> > > > > To unsubscribe send an email to copr-devel-leave@lists.fedorahost
> > > > > ed.o
> > > > > rg
> > > >
> > > > --
> > > > -Igor Gnatenko
> > > > ___
> > > > copr-devel mailing list -- copr-devel@lists.fedorahosted.org
> > > > To unsubscribe send an email to copr-devel-leave@lists.fedorahosted
> > > > .org
> > > >
> > > >
> > >
> > > ___
> > > copr-devel mailing list -- copr-devel@lists.fedorahosted.org
> > > To unsubscribe send an email to copr-devel-leave@lists.fedorahosted.o
> > > rg
> >
> >
>
> ___
> 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: upcoming branching

[Michal Novotny]

On Tue, Feb 21, 2017 at 7:18 AM, Igor Gnatenko <ignate...@redhat.com> wrote:

> On Mon, 2017-02-20 at 21:28 +0100, Michal Novotny wrote:
> > On Mon, Feb 20, 2017 at 8:20 PM, Igor Gnatenko <ignate...@redhat.com>
> > wrote:
> >
> > > On Mon, 2017-02-20 at 16:16 +0100, Michal Novotny wrote:
> > > > Hello,
> > > >
> > > > as soon as branching is done and f26 repo links become available,
> > > > we
> > > > will
> > > > switch the current fedora-26-* chroots from rawhide to use the
> > > > f26
> > > > repositories.
> > >
> > > I'm more interested in fedora-27-* being added...
> > >
> >
> > Hello, are you in favor of adding fedora-27 or rather fedora-rawhide
> > back?
> > This is more general question to the crowd. Both are technically
> > possible
> > but the question is what is less confusing. Does anything of it bring
> > you
> > less work? f26 -> f27 -> etc has probably higher maintenance cost.
> it depends. if you are planning to do mass-rebuild after branching in
> all copr repos, then I prefer rawhide. If not, I prefer fXY.
>

I plan to allow rebuilding all packages in a new chroot if users welcome
such option.


> >
> >
> > > >
> > > > COPR team
> > > > ___
> > > > copr-devel mailing list -- copr-devel@lists.fedorahosted.org
> > > > To unsubscribe send an email to copr-devel-leave@lists.fedorahost
> > > > ed.o
> > > > rg
> > >
> > > --
> > > -Igor Gnatenko
> > > ___
> > > copr-devel mailing list -- copr-devel@lists.fedorahosted.org
> > > To unsubscribe send an email to copr-devel-leave@lists.fedorahosted
> > > .org
> > >
> > >
> >
> > ___
> > copr-devel mailing list -- copr-devel@lists.fedorahosted.org
> > To unsubscribe send an email to copr-devel-leave@lists.fedorahosted.o
> > rg
>
> --
> -Igor Gnatenko
>
> ___
> 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: fedmsg structure change?

[Michal Novotny]

Otherwise, in the fix that I am going to apply tomorrow, there will some
additional fields for chroot.start and build.start messages.

For chroot.start:
- status (int)
- version (str)

For build.start:
- status (int)
- version (str)
- chroot (str)

The old fields will be all there with the same type. Only some new fields
will be added. I hope that does not represent a problem for fedmsg_meta or
anybody. I am aware that an ideal way would be to just leave the old
message interface as it was but the code would get very ugly.  Of course, I
will do it if needed.

clime


On Tue, Jan 24, 2017 at 1:36 PM, Michal Novotny <cl...@redhat.com> wrote:

>
>
> On Tue, Jan 24, 2017 at 11:44 AM, Pierre-Yves Chibon <pin...@pingoured.fr>
> wrote:
>
>> On Tue, Jan 24, 2017 at 11:30:33AM +0100, Michal Novotny wrote:
>> >Yes, untested changes got into production. We are sorry. I am
>> currently
>> >working on a fix.
>>
>> If that made it up to production, then we'll need to adjust fedmsg_meta to
>> support these messages as well.
>>
>> fedmsg_meta should work for all our published messages (published and
>> stored on
>> datagrepper).
>>
>
>
> Okay, these messages have all empty body (the "msg" attribute), e.g
> `build.end`:
>
> {
>   "source_name": "datanommer",
>   "certificate": 
> "LS0tLS1CRUdJTiBDRVJUSUZJQ0FURS0tLS0tCk1JSUVUakNDQTdlZ0F3SUJBZ0lDQVBZd0RRWUpL\nb1pJaHZjTkFRRUZCUUF3Z2FBeEN6QUpCZ05WQkFZVEFsVlQKTVFzd0NRWURWUVFJRXdKT1F6RVFN\nQTRHQTFVRUJ4TUhVbUZzWldsbmFERVhNQlVHQTFVRUNoTU9SbVZrYjNKaApJRkJ5YjJwbFkzUXhE\nekFOQmdOVkJBc1RCbVpsWkcxelp6RVBNQTBHQTFVRUF4TUdabVZrYlhObk1ROHdEUVlEClZRUXBF\nd1ptWldSdGMyY3hKakFrQmdrcWhraUc5dzBCQ1FFV0YyRmtiV2x1UUdabFpHOXlZWEJ5YjJwbFkz\nUXUKYjNKbk1CNFhEVEUwTURReU16RTBNamsxTVZvWERUSTBNRFF5TURFME1qazFNVm93Z2R3eEN6\nQUpCZ05WQkFZVApBbFZUTVFzd0NRWURWUVFJRXdKT1F6RVFNQTRHQTFVRUJ4TUhVbUZzWldsbmFE\nRVhNQlVHQTFVRUNoTU9SbVZrCmIzSmhJRkJ5YjJwbFkzUXhEekFOQmdOVkJBc1RCbVpsWkcxelp6\nRXRNQ3NHQTFVRUF4TWtZMjl3Y2kxamIzQnkKTFdKbExtTnNiM1ZrTG1abFpHOXlZWEJ5YjJwbFkz\nUXViM0puTVMwd0t3WURWUVFwRXlSamIzQnlMV052Y0hJdApZbVV1WTJ4dmRXUXVabVZrYjNKaGNI\nSnZhbVZqZEM1dmNtY3hKakFrQmdrcWhraUc5dzBCQ1FFV0YyRmtiV2x1ClFHWmxaRzl5WVhCeWIy\ncGxZM1F1YjNKbk1JR2ZNQTBHQ1NxR1NJYjNEUUVCQVFVQUE0R05BRENCaVFLQmdRQ2UKREs5VFQy\nM05BdTZPWTVGMnVVNHpMRW9Ld2k1RnRRTU5jVWV5eDdmOHJxMUZXaUxDWHBjWFhpU2tzUE1XV1NM\nWQo5SHNoa1pvM3ZjMHFSRXVBWDNweWRuM2VFRDA0UExrUmRlaWpvSXA5L0Y2YlZ3MmlLMDdXRmc5\nU2MwNlRsKzhSCld1RHNaeTQ1SVJKYXhCRTlJaHBYL0x2Y2JnQ1cvZmVHVGp5WG1iRHd0UUlEQVFB\nQm80SUJWekNDQVZNd0NRWUQKVlIwVEJBSXdBREF0QmdsZ2hrZ0JodmhDQVEwRUlCWWVSV0Z6ZVMx\nU1UwRWdSMlZ1WlhKaGRHVmtJRU5sY25ScApabWxqWVhSbE1CMEdBMVVkRGdRV0JCUm5lNTg0d3Bs\nWGYrZVE2K25zSTZCbm5BNENaRENCMVFZRFZSMGpCSUhOCk1JSEtnQlJyUUZyNUVnaUpXZWRaNVFY\nMUFoMEtUbjhVQUtHQnBxU0JvekNCb0RFTE1Ba0dBMVVFQmhNQ1ZWTXgKQ3pBSkJnTlZCQWdUQWs1\nRE1SQXdEZ1lEVlFRSEV3ZFNZV3hsYVdkb01SY3dGUVlEVlFRS0V3NUdaV1J2Y21FZwpVSEp2YW1W\namRERVBNQTBHQTFVRUN4TUdabVZrYlhObk1ROHdEUVlEVlFRREV3Wm1aV1J0YzJjeER6QU5CZ05W\nCkJDa1RCbVpsWkcxelp6RW1NQ1FHQ1NxR1NJYjNEUUVKQVJZWFlXUnRhVzVBWm1Wa2IzSmhjSEp2\nYW1WamRDNXYKY21lQ0NRRGpVQjVIVHhjZVJUQVRCZ05WSFNVRUREQUtCZ2dyQmdFRkJRY0RBakFM\nQmdOVkhROEVCQU1DQjRBdwpEUVlKS29aSWh2Y05BUUVGQlFBRGdZRUFVazNlbjBYUXpDQm5IUlh4\nZDhyOHp2ZFAwVURvbEpiUysyTEl3Z3NDClJDMnNkZ1UwNGdFblYxdFpVTjNydEk1SzQ2MnpKT0JQ\nOFhQd3h4eUZMN1lOYmVtWTgyTG52Y1pHdzliMGdxTDMKdHNKbzllSFV5SXBZMG93TlVKdzgzU1Ax\neFJvb3NwVGJRK3BsNm9qdjVPNVpGZ1lBUG1yckRWZ0M4a2gzRlp4Rgp0SWc9Ci0tLS0tRU5EIENF\nUlRJRklDQVRFLS0tLS0K\n",
>   "i": 3,
>   "timestamp": 1485166967.0,
>   "msg_id": "2017-db23086c-2001-496e-a59f-10b92c466ae5",
>   "topic": "org.fedoraproject.prod.copr.build.end",
>   "source_version": "0.6.5",
>   "signature": 
> "HJEOhP93vZFUk3cjIzggxZqIT+IRaLpKF/t21Kn0AcQ9B1VJEe+myerAAJMZfuXppGQqsFyzcPFx\nu+9p7geI5NqNxnN+diUXNlxbXN9/VN0X3vX7U4mbc0/zLyGcbKWIn/pcskbM5qYC2lJHLov0pMwq\nrbq/B0N3CxBL2og0Fj8=\n",
>   "msg": {}
> }
>
> Does fedmsg_meta need to be adjusted even so?
> clime
>
>
>>
>> Pierre
>>
>>
>> >On Tue, Jan 24, 2017 at 11:02 AM, Pierre-Yves Chibon <
>> pin...@pingoured.fr>
>> >wrote:
>> >
>> >  Hi all,
>> >
>> >  We have recently been receiving emails about wrongly formatted
>> fedmsg
>> >  message
>> >  coming from copr in stg.
>> >  Has there been any changes made to the structure of the messages
>> sent in
>> >  stg?
>> >
>> >  To give you an idea, this is what we received:
>> >  Traceback (most recent call last):
>> >  Â  File "/usr/lib/python2.7/site-packages/moksha/hub/api/consumer.
>> py&

New COPR release

[Michal Novotny]

Hey folks,

updated COPR stack has been just deployed into production. This included
several steps:

1) new release of copr-frontend (1.107-1) has been deployed
The main features of this release include re-enabling fedora-rawhide as
chroot names, compatibility with python2-flask-whooshee-0.4.1-2, and
finally updates related to support of Module Build Service (MBS).

2) copr-backend was redeployed for mock 1.3.4 support
The backend configuration was updated to support the new mock 1.3.4. Note
that fedora-26-* chroots will not work until the respective repositories
are publicly available. Before, rawhide repositories were used for f26
chroots but today, that needed to be changed for the rawhide branching.
Mainly because of this unpleasant config switching, we decided that
returning fedora-rawhide -* back is the best option. It will be kept as
long as mock keeps it. We run on mock and we need to play with it well.
Note that previous backend rawhide repositories are available in your
backend directories "-backup" suffixed. Otherwise, we are starting from
scratch there and new repositories will be auto-created for the new rawhide
builds. We are also starting fresh on copr-dist-git where the previous
master branch has been renamed to master-backup and new master is ready for
you.

3) a long-standing copr-keygen issue "Keygen service error" has been
hopefully fixed
This issue should no longer occur (at least not for the same reason). Let
me know if it runs well.

There are still unsolved network problems, which cause COPR to underperform
these days while also requiring day-to-day copr-backend service
stop/starts. We are now going to debug these into depth.

The ultimate goal now is to make COPR stable and reliable.

Thank you
COPR team
___
copr-devel mailing list -- copr-devel@lists.fedorahosted.org
To unsubscribe send an email to copr-devel-le...@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: Mageia chroots enabled

[Michal Novotny]

Correction: Mageia-6 and *Mageia-cauldron chroots. Sorry for that!

On Wed, Sep 21, 2016 at 1:31 PM, Michal Novotny <cl...@redhat.com> wrote:

> Hello all,
>
> we have just enabled Mageia-6 and Mageia-x86_64 chroots for i586 + x86_64
> archs. So if you want to build something for Mageia (
> https://www.mageia.org/), please, feel free to try.
>
> 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

Mageia chroots enabled

[Michal Novotny]

Hello all,

we have just enabled Mageia-6 and Mageia-x86_64 chroots for i586 + x86_64
archs. So if you want to build something for Mageia (https://www.mageia.org/),
please, feel free to try.

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

Re: copr-dist-git branch naming and mock names

[Michal Novotny]

I think that only real restriction on branch naming is in fedpkg/fedpk-copr
(load_rpmdefines function).
I think that's the heart of the issue. If you could provide a sane default
case for parsing branch_merge variable,
then we could adjust everything else (e.g. mock_chroot_name -> branch,
branch -> os
conversions in frontend or dist-git.conf if needed).

clime

On Wed, Sep 21, 2016 at 4:59 PM, Pavel Raiskup  wrote:

> So far in Copr, there is  "inherited" git branch naming from Fedora's
> dist-git, i.e.  'f24' for fedora 24, el5 for 'epel-5' and epel7 for
> 'epel-7'.  The chroots in Fedora Copr are named 'fedora-N-ARCH' or
> 'epel-N-ARCH', today there started 'mageia-N-ARCH' chroots (with mga6,
> shouldn't there be mag6?).  But Copr is not supposed to be used by Fedora
> only.
>
> The problem I internally solved/workaround-ed are RHEL chroots.  Those are
> named 'rhel-VERSION-ARCH'.  To have it done there are several patches
> (against dist-git, backend, and front-end packages).
>
> The problem, for example is, that 'el6' branch is "by default" allocated
> for 'epel-6-ARCH' chroots, and can not be used by RHEL.  There are
> multiple versions of RHEL-6 too (like rhel-6.dev-x86_64).
>
> I'm curious whether we could "rename" the existing branches to some more
> consistent, "future-friendly" strings.  For example:
>
> -> 'fedora/25'  (the actual f25)
> -> 'fedora/rawhide' (the actual master)
> -> 'centos/7'   (the actual epel7)
> -> 'centos/6'   (the actual el6)
> -> 'mageia/6'   (the actual mga6)
> -> 'epel/7' (doesn't exist yet ..)
> -> 'rhel/version'   (exists internally ..)
>
> For OCD like me, it would be really pretty having it "cleanly" named, but
> it would be also useful for 'chroot-id <-> branch-name <-> dist-tag'
> converting (which now requires downstream _code_ patching, not only
> configuration).
>
> Also, if we used such naming, there's no need to think again what the
> 'master'
> branch is used for ... (rhel? fedora? epel?) and for the future, adding
> other distributions (or complements for say rpmfusion) would be easy.
>
> I don't remember why I chose 'fedora/25' "downstream" instead of
> 'fedora-25', it IMO doesn't matter, and as I have it already done O:-) I
> prefer '/' separator.  But that basically doesn't matter.
>
> Anyway --> is something like that acceptable upstream?  I have patches for
> it already (this would require copying branches within existing git
> repositories).  There is plan B:  propose this patches but add options
> turning this behavior on/off, whatever default we'll choose.
>
> While we are on that, could we discuss renaming from 'epel-*' to
> 'centos-*'?  Because we don't tell the truth entirely if we claim those are
> epel-* chroots.
>
> Pavel
> ___
> 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: Fwd: [Bug 1376844] New: Please start using processes like code-review, etc.

[Michal Novotny]

On Wed, Sep 21, 2016 at 3:32 PM, Pavel Raiskup  wrote:

>
> :) Consider that others consume Copr sources ...
>
> > What is important for me is not important for you and vice versa.
>

I would say that every commit is important.


>
> ... and have Copr working, want to have it as stable as possible, and are
> planning regular updates with new releases.  So to answer your question:
> Whatever could complicate updating is worth having a look (by other
> consumers)
> whether it is (a) necessary, (b) shouldn't be made optional; or (c) at
> worth
> study hard how to re-configure properly.
>
> Typical "hint" can be:
>
> - "you have to hack something on XX (backend e.g)" because you changed
> something
>   on "YY (e.g. dist git)", and whetever else component.
>
> - API changes, copr client should detect that server supports older API
>
> - You need to change deployment scripts, others will need this too
>
> - you put requirement on software that is not in base Fedora repo, be that
> yum
>   repo or other software repo ... (like dockerhub)
>
> Yup, it is on my TODO list to make the upstream packages usable for me too
> (because otherwise it is real pain), but so far (except for client side) I
> need
> to re-build the packages with downstream patches.  If there was something
> docker-related, I would have to rebuild the images probably too...
>

You don't need to rebuild any images manually, just restart
copr-dist-git.service.

clime


>
> Pavel
> ___
> 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: move to pagure

[Michal Novotny]

On Mon, Nov 7, 2016 at 3:07 PM, Pavel Raiskup <prais...@redhat.com> wrote:

> On Monday, November 7, 2016 1:36:11 PM CET Michal Novotny wrote:
> > Hey,
> >
> > I'd like to ask the community if it's alright to officially move to
> pagure.
> > I should have probably asked earlier but I haven't thought about it, I
> must
> > admit. Pagure is an open-source project tight to Fedora Infrastructure,
> > which COPR can use to its advantage. Auto-rebuilds launched on new
> commits
> > are already working by employing great fedmsg infrastructure bus. I think
> > there might be more possibilities there that I cannot see at the moment.
> > Another advantage is that we can move our COPR wiki to Pagure from
> > fedorahosted.org (going to be sunset) and have both code base and wiki
> on
> > pagure.io and therefore use only one platform for these two. I probably
> > won't be able to move closed pull requests from Github, which I wanted to
> > do, but I have already started (really just started) working on that
> > feature into pagure-importer so that other projects can have this.
>
> I have a suggestion then.   Please let the github repo live indefinitely,
> without pushing anything which is not in pagure.  Only edit project
> description.
>
> It would be nice to have that github repo synced automatically as an
> mirror, for marketing purposes (for both Copr and Pagure).
>

Keeping the Github repo as a pointer might be a good idea.


>
> > If you have any objections against moving to Pagure, please, tell.
>
> I'm fine, but still would like to have this done WRT @coprgit FAS group.
>

Contributing people from this group or from any other group will be added.


> Pavel
> ___
> 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: Build respawing?

[Michal Novotny]

Basically, there is a difference in build-time calculation for chroots and
builds. For chroot, it is end_time - start_time and for build it is
chroot_max_end_time - chroot_min_end_time (in other words, for a build, all
its chroots are considered in time calculation).

The thing is that your x86_64 build got stuck and was restarted after 48
hours at which point chroot's start_time got reset. You can find out where
it got stuck from the logs prev_build_backup subdirectory in the build's
results directory.

It's quite common that kernel (or long-running) builds get restarted. I am
not sure why exactly it happens and if we should take a look at it. Let us
know if the problems are reoccurring.

clime



On Mon, Oct 24, 2016 at 3:28 PM, Michael J Gruber <
michaeljgruber+fedoraproj...@gmail.com> wrote:

> Hi there,
>
> in https://copr.fedorainfracloud.org/coprs/mjg/kernel-hp6715b/builds/, I
> have an x86_64 build with some strange stats:
>
> 467858  kernel  4.7.9-200.hp6715b.fc24  3 days ago  9 hours
>  running
>
> Build time goes up for a few hours and then apparentyl gets reset on that
> page, but keeps growing on the build's page https://copr.fedorainfracloud.
> org/coprs/mjg/kernel-hp6715b/build/467858/.
>
> The corresponding i386 finished in due time.
>
> Should I somehow cancel and resubmit that build to get it unstuck? I never
> had that with (almost) the same spec before, it's fedora's kernel spec plus
> 1 more patch.
> ___
> 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: codebase moved to pagure.io

[Michal Novotny]

Hello Vit,

do you mean line 3 in the README.md? ("Project Page") That is should be ok.
It says

https://fedorahosted.org/copr/

I updated repo link in that page. Thanks!


On Fri, Oct 21, 2016 at 1:19 PM, Vít Ondruch <vondr...@redhat.com> wrote:

> Shouldn't be this line updated?
>
>
> https://pagure.io/copr/copr/blob/master/f/README.md?text=True#_3
>
>
> And the fedorahosted should be update as well IMO.
>
>
>
> Vít
>
>
>
>
> Dne 21.10.2016 v 13:00 Michal Novotny napsal(a):
>
> Hello folks,
>
> codebase will be now hosted on pagure.io (https://pagure.io/copr/copr).
> We would like to start working on this platform. Not that Github is bad but
> I think that pagure.io will be good place as well.
>
> 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: tail the logs

[Michal Novotny]

This is not yet implemented. I agree, it would be nice.

On Tue, Nov 29, 2016 at 4:31 AM, Ryan H. Lewis  wrote:

> Koji allows us to the the logs more or less as they are generated. Is it
> possible to do the same with koji? I have long builds ~30 minutes -- 1
> hour. It is nice to see where things are while the logs get generated..
> ___
> 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

| planned hotfix deployment for build restarting

[Michal Novotny]

Today (11/22) at 4pm UTC, I will apply a hotfix for build restarting. Also,
I will attempt to address https://bugzilla.redhat.com/
show_bug.cgi?id=1395582 for ppc64le builders.

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

| Re: Loading changes to an own Copr project

[Michal Novotny]

On Thu, Nov 17, 2016 at 11:10 AM, Antonio Trande 
wrote:

> Hi all.
>
> How can i commit changes to my Copr project without uploading source
> code archive every time?
>
>
You want to push changes to copr-dist-git (
http://copr-dist-git.fedorainfracloud.org) without a rebuild? That's not
currently possible.


>
> --
> ---
> Antonio Trande
> mailto: sagitter 'at' fedoraproject 'dot' org
> https://fedoraproject.org/wiki/User:Sagitter
> GPG Key: 0x6CE6D08A
> Check on https://keys.fedoraproject.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

| codebase moved to pagure.io

[Michal Novotny]

Hello folks,

codebase will be now hosted on pagure.io (https://pagure.io/copr/copr). We
would like to start working on this platform. Not that Github is bad but I
think that pagure.io will be good place as well.

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

| Re: codebase moved to pagure.io

[Michal Novotny]

After some discussion, the main argument against move to pagure is that
commit-induced auto-rebuilding of COPR packages will be disabled by this.

I am working on alleviating this issue. Hopefully, it will go well.

clime

On Mon, Oct 24, 2016 at 11:32 AM, Miroslav Suchý <msu...@redhat.com> wrote:

> Dne 21.10.2016 v 13:00 Michal Novotny napsal(a):
> > codebase will be now hosted on pagure.io <http://pagure.io> (
> https://pagure.io/copr/copr). We would like to start
> > working on this platform. Not that Github is bad but I think that
> pagure.io <http://pagure.io> will be good place as well.
>
> Sorry to say that, but this changed was not discussed neither here nor in
> the team. So I have to reject this. The
> upstream will stay on GitHub for now. It may change in future, but not now.
> Please continue sending PRs to GitHub.
>
> --
> Miroslav Suchy, RHCA
> Red Hat, Senior Software Engineer, #brno, #devexp, #fedora-buildsys
> ___
> 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: codebase moved to pagure.io

[Michal Novotny]

On Thu, Oct 27, 2016 at 7:56 PM, Pierre-Yves Chibon 
wrote:

> Pagure supports web-hook as well as fedmsg for notifying of an action.
> There is also of course the possibility to add COPR as some sort of CI
> service
> like we have for jenkins but that would be a little more work on pagure
> itself.
>
>
> Let me know if I can help with something!
>

Thank you. I have already implemented some basic fedmsg listener that
launches builds
on pagure.git.receive message. It works but it would be nice to extend the
message with
the information about modified paths in the repository so that only the
corresponding sub-package(s)
are rebuilt (in COPR repo, there are 10 subpackages at least, which is
quite a lot of building when
only one of them has been actually updated). I will gladly send a PR for
this unless there happens
to be some better way.

Pierre
> ___
> 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: codebase moved to pagure.io

[Michal Novotny]

On Mon, Oct 31, 2016 at 8:40 AM, Pierre-Yves Chibon 
wrote:

> We used to send more info but had to trim it down due to some massive
> commits
> that were basically breaking datagrepper (OutOfMemory), but if there is an
> use-case I'm fine with expending the amount of information sent.
> Worst case, do the computation client-side, listen to fedmsg, get the
> start and
> stop commits and see which files were touched in between.
>

In the simplest case, we would need directory/file names of level 1 where
there was
a change. That's perhaps a little too specific though. I would still very
much welcome
this or overall list of modified paths. Not saying, I can't put together
some really messy
code to get that information from the patches :).

Pierre
> ___
> 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: codebase moved to pagure.io

[Michal Novotny]

On Mon, Oct 31, 2016 at 12:05 PM, Pierre-Yves Chibon <pin...@pingoured.fr>
wrote:

> On Mon, Oct 31, 2016 at 11:59:47AM +0100, Michal Novotny wrote:
> >On Mon, Oct 31, 2016 at 8:40 AM, Pierre-Yves Chibon <
> pin...@pingoured.fr>
> >wrote:
> >
> >  We used to send more info but had to trim it down due to some
> massive
> >  commits
> >  that were basically breaking datagrepper (OutOfMemory), but if
> there is
> >  an
> >  use-case I'm fine with expending the amount of information sent.
> >  Worst case, do the computation client-side, listen to fedmsg, get
> the
> >  start and
> >  stop commits and see which files were touched in between.
> >
> >In the simplest case, we would need directory/file names of level 1
> where
> >there was
> >a change. That's perhaps a little too specific though. I would still
> very
> >much welcome
> >this or overall list of modified paths. Not saying, I can't put
> together
> >some really messy
> >code to get that information from the patches :).
>
> If you're not against shelling out commands, you could try:
>
> Get the list of commits:
>   git rev-list old_commit..new_commit
>
> Get the list of file changed in a specific commit:
>   git diff-tree --no-commit-id --name-only -r 
>

The problem is that we don't have the repository cloned at the point the
fedmsg is received.
And to always clone the repo to run the commands would be a bit troublesome.


>
> Pierre
> ___
> 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: Fork "from" or "to" rawhide?

[Michal Novotny]

The lighttpd aliases/redirects will be good to keep copr project's baseurls
with *rawhide* in it working. You might want to use those.

On Mon, Oct 10, 2016 at 5:10 PM, Pavel Raiskup <prais...@redhat.com> wrote:

> Hi Michal,
>
> On Monday, October 10, 2016 4:39:11 PM CEST Michal Novotny wrote:
> > The current state is that 'rawhide' is going to be renamed to f26.
> >
> > I'll additionally setup aliases (or redirects) from
> >
> > /results/*/*/fedora-rawhide-$basearch/ *to* /results/*/*/fedora-26-$
> basearch/
> >
> > so that no links are lost.
> >
> > There will be no need to rebuild any existing builds.
>
> How exactly users will use the aliases links?  Should I think about those
> aliases too in internal Copr?
>
> Pavel
>
>
___
copr-devel mailing list -- copr-devel@lists.fedorahosted.org
To unsubscribe send an email to copr-devel-le...@lists.fedorahosted.org

Re: COPR chroots additions/deletions

[Michal Novotny]

The reason is that the backend_rawhide_to_release command that I used for
transition of builds from rawhide to f26 copies only the latest successful
builds for each package. Your needed dependency, however, comes from a
build 468985 that was marked as failed but still contains (as the only one)
the required package kde-workspace-libs that in turn contains
libtaskmanager.so.4. What was actually copied was the resubmitted build *469002
*
containing only kde-workspace-libs for f23 chroot that failed in the
previous build. Smarter backend_rawhide_to_release command could be
implemented that looks at individual chroots and copies them from even
failed builds. For this case, I, however, just copied the build 468985 into
fedora-26-x86_64 and fedora-26-i386 chroots (ppc64le was not built).
*
*
On Sat, Dec 3, 2016 at 8:59 PM, Sérgio Basto  wrote:

> On Sáb, 2016-12-03 at 19:27 +, cl...@redhat.com wrote:
> > Do you have "manual createrepo" option enabled for your project? I.e.
> > does devel subdirectory exist in the repo?
>
> No , I don't have manual repo enabled , the repo was rawhide repo but
> now is f26 , builroot fail to have packages from that project .
>
>
> --
> Sérgio M. B.
>
> ___
> 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: python-novaclient package??

[Michal Novotny]

On Mon, Dec 5, 2016 at 4:18 PM, Martin Juhl <m...@casalogic.dk> wrote:

> Hi
>
> Yes, copr-be is running as copr:
>
> root@copr02 playbooks]# ps uax |grep copr
> copr 10065  0.0  1.2 240084 23144 ?Ss   10:57   0:03
> RedisLogHandler
> copr 21706  0.0  1.8 306404 34176 ?Ss   13:17   0:00 Copr VMM
> base process
> copr 21707  0.0  2.3 351736 43416 ?Ss   13:17   0:00
> /usr/bin/python /usr/bin/copr_be.py
> copr 21716  0.0  1.6 453868 30804 ?Sl   13:17   0:01 Event
> Handler
> copr 21717  0.2  1.9 883352 37496 ?S13:17   0:11 VM master
>
> And I have just testet ssh from the Copr user.. it works...
>
> Where should the mockbuilder user be created?? I have created the user
> myself, but am I missing a package???
>
>
mockbuilder is a custom user afaik. I also met this error when I ran
backend inside a docker container but you are not doing that right? As a
debugging method, you can extract code from check_health in
backend/backend/vm_manage/check.py into a self-contained script to run that
separately from the rest of copr-backend. You can also strace the script if
that shows anything. 'Inappropriate IOCTL on device' might mean that you
try to read/write on tty you do not have access to but not sure if this
information will help you in any way.

/Martin
>
>
> - Original meddelelse -
> Fra: "Michal Novotny" <cl...@redhat.com>
> Til: "copr-devel" <copr-devel@lists.fedorahosted.org>
> Sendt: mandag, 5. december 2016 15:12:47
> Emne: Re: python-novaclient package??
>
> On Mon, Dec 5, 2016 at 2:58 PM, Martin Juhl < m...@casalogic.dk > wrote:
>
>
> Hi
>
> I haven't done anything to the ansible.cfg file... should I replace it
> with the one from the copr-backend package???
>
>
>
> You can try that (move backend/conf/playbooks/ansible.cfg into
> /etc/ansible) but on my machine I successfully use default ansible1.9
> config and health checker works with that. Just to make sure...can you ssh
> mockbuilder@localhost as `copr` user (I assume your backend.service is
> running as `copr` user)?
>
> BQ_BEGIN
>
> # config file for ansible -- http://ansible.com/
> # ==
>
> # nearly all parameters can be overridden in ansible-playbook
> # or with command line flags. ansible will read ANSIBLE_CONFIG,
> # ansible.cfg in the current working directory, .ansible.cfg in
> # the home directory or /etc/ansible/ansible.cfg, whichever it
> # finds first
>
> [defaults]
>
> # some basic default values...
>
> inventory = /etc/ansible/hosts
> #library = /usr/share/my_modules/
> remote_tmp = $HOME/.ansible/tmp
> pattern = *
> forks = 5
> poll_interval = 15
> sudo_user = root
> #ask_sudo_pass = True
> #ask_pass = True
> transport = smart
> #remote_port = 22
> module_lang = C
>
> # plays will gather facts by default, which contain information about
> # the remote system.
> #
> # smart - gather by default, but don't regather if already gathered
> # implicit - gather by default, turn off with gather_facts: False
> # explicit - do not gather by default, must say gather_facts: True
> gathering = implicit
>
> # additional paths to search for roles in, colon separated
> #roles_path = /etc/ansible/roles
>
> # uncomment this to disable SSH key host checking
> #host_key_checking = False
>
> # change this for alternative sudo implementations
> sudo_exe = sudo
>
> # what flags to pass to sudo
> #sudo_flags = -H
>
> # SSH timeout
> timeout = 10
>
> # default user to use for playbooks if user is not specified
> # (/usr/bin/ansible will use current user as default)
> #remote_user = root
>
> # logging is off by default unless this path is defined
> # if so defined, consider logrotate
> #log_path = /var/log/ansible.log
>
> # default module name for /usr/bin/ansible
> #module_name = command
>
> # use this shell for commands executed under sudo
> # you may need to change this to bin/bash in rare instances
> # if sudo is constrained
> #executable = /bin/sh
>
> # if inventory variables overlap, does the higher precedence one win
> # or are hash values merged together? The default is 'replace' but
> # this can also be set to 'merge'.
> #hash_behaviour = replace
>
> # list any Jinja2 extensions to enable here:
> #jinja2_extensions = jinja2.ext.do ,jinja2.ext.i18n
>
> # if set, always use this private key file for authentication, same as
> # if passing --private-key to ansible or ansible-playbook
> #private_key_file = /path/to/file
>
> # format of string {{ ansible_managed }} available within Jinja2
> # templates indicates to users editing te

Re: COPR shows "failed", but in fact build succeeded

[Michal Novotny]

There was Gateway Timeout on copr-keygen. The machine was  likely
overloaded at that time.

On Mon, Dec 5, 2016 at 10:58 PM, Igor Gnatenko  wrote:

> https://copr.fedorainfracloud.org/coprs/rpmsoftwaremanagement/rpm-
> gitoverlay-1480969917.509235/build/485123/
> --
> -Igor Gnatenko
> ___
> copr-devel mailing list -- copr-devel@lists.fedorahosted.org
> To unsubscribe send an email to copr-devel-le...@lists.fedorahosted.org
>
___
copr-devel mailing list -- copr-devel@lists.fedorahosted.org
To unsubscribe send an email to copr-devel-le...@lists.fedorahosted.org

Re: python-novaclient package??

[Michal Novotny]

On Mon, Dec 5, 2016 at 11:47 AM, Martin Juhl  wrote:

> Ok... Might have fixed that myself...
>
> Using the /centos/7.2.1511/cloud/x86_64/openstack-kilo/ it seems to
> work...
>
> Now i'm getting:
>
> ==> /var/log/copr-backend/vmm.log <==
> [2016-12-05 11:15:37,384][  
> INFO][vmm.event_handler][manager.py:add_vm_to_pool:175]
> registered new VM: Copr builder 94671718 127.0.0.1
> [2016-12-05 11:18:37,256][  INFO][vmm.event_handler][event
> _handle.py:on_health_check_result:112] check fail threshold reached: 2,
> terminating: {u'vm_ip': u'127.0.0.1', u'vm_name': u'Copr builder
> 760126240', u'topic': u'health_check', u'result': u'failed', u'msg': u'VM
> is not responding to the testing playbook.Runner options: {\'remote_user\':
> \'mockbuilder\', \'timeout\': 5, \'pattern\': \'127.0.0.1\', \'forks\': 1,
> \'host_list\': \'127.0.0.1,\', \'transport\': u\'paramiko\'}Ansible raw
> response:\n{\'dark\': {\'127.0.0.1\': {\'msg\': "FAILED: (25,
> \'Inappropriate ioctl for device\')", \'failed\': True}}, \'contacted\':
> {}}'}
> [2016-12-05 11:18:37,257][  INFO][vmm.event_handler][manag
> er.py:start_vm_termination:283] VM Copr builder 760126240 queued for
> termination
>


> Any ideas
>
>

I saw this error ('Inappropriate ioctl for device') when ansible2 default
config was used by ansible1.9 being installed after ansible2. Can you show
us your /etc/ansible/ansible.cfg? Is it default conf for ansible1.9
package? I assume that ssh mockbuilder@localhost otherwise works ok in your
setup.



>
> --
> *Fra: *"mj" 
> *Til: *"copr-devel" 
> *Sendt: *mandag, 5. december 2016 10:53:35
> *Emne: *python-novaclient package??
>
> Hi guys
>
> Still playing around with getting COPR to work on RHEL/CentOS..
>
> I'm very close.. Only think I have one issue left.. When ansible is
> spawning a new build instance it fails...
>
> [root@copr02 playbooks]# ansible-playbook -i inventory -c ssh
> /usr/share/doc/copr-backend-1.94/playbooks/spawn_local.yml
> Traceback (most recent call last):
>   File "/usr/bin/ansible-playbook", line 324, in 
> sys.exit(main(sys.argv[1:]))
>   File "/usr/bin/ansible-playbook", line 264, in main
> pb.run()
>   File "/usr/lib/python2.7/site-packages/ansible/playbook/__init__.py",
> line 310, in run
> play = Play(self, play_ds, play_basedir, vault_password=self.vault_pass
> word)
>   File "/usr/lib/python2.7/site-packages/ansible/playbook/play.py", line
> 194, in __init__
> self._tasks  = self._load_tasks(self._ds.get('tasks', []),
> load_vars)
>   File "/usr/lib/python2.7/site-packages/ansible/playbook/play.py", line
> 682, in _load_tasks
> role_name=role_name
>   File "/usr/lib/python2.7/site-packages/ansible/playbook/task.py", line
> 255, in __init__
> self.async_seconds = template.template_from_string(play.basedir,
> self.async_seconds, all_vars)
>   File "/usr/lib/python2.7/site-packages/ansible/utils/template.py", line
> 346, in template_from_string
> environment.filters.update(_get_filters())
>   File "/usr/lib/python2.7/site-packages/ansible/utils/template.py", line
> 54, in _get_filters
> plugins = [ x for x in utils.plugins.filter_loader.all()]
>   File "/usr/lib/python2.7/site-packages/ansible/utils/plugins.py", line
> 232, in all
> self._module_cache[path] = imp.load_source('.'.join([self.package,
> name]), path)
>   File "/usr/share/doc/copr-backend-1.94/playbooks/filter_plugins/os_nova.py",
> line 1, in 
> from novaclient.v1_1.client import Client
> ImportError: No module named v1_1.client
>
> I have installed the python-novaclient module from
> "centos/7.2.1511/cloud/x86_64/openstack-mitaka/" but it seems to be too
> new, as v1_1.client seems to be deprecated??
>
> Which version do you use on Fedora???
>
> Regards
>
> Martin
> ___
> 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: failed to post data to frontend

[Michal Novotny]

On Mon, Dec 5, 2016 at 1:47 PM, Martin Juhl  wrote:

> Hi
>
> I'm getting these errors/warnings:
>
> ==> /var/log/copr-backend/backend.log <==
> [2016-12-05 11:57:15,358][WARNING][backend.main][frontend.py:_
> post_to_frontend_repeatedly:48] failed to post data to frontend, repeat
> #20
> [2016-12-05 11:57:20,452][WARNING][backend.main][frontend.py:_
> post_to_frontend_repeatedly:48] failed to post data to frontend, repeat
> #21
>
>
> /etc/copr/copr-be.conf:
>
> [backend]
>
> # URL where are results visible
> # default is http://copr
> results_baseurl=https://copr02.casalogic.lan
>
> # default is http://coprs/rest/api
> frontend_base_url=http://copr02.casalogic.lan/api
>
> # must have same value as BACKEND_PASSWORD from have frontend in
> /etc/copr/copr.conf
> # default is PASSWORDHERE but you really should change it. really.
> frontend_auth=mjp123
>
> dist_git_url=copr02.casalogic.lan
>
>
>
>
> /etc/copr/copr.conf:
>
> # Directory and files where is stored Copr database files
> DATA_DIR = '/var/lib/copr/data'
> DATABASE = '/var/lib/copr/data/copr.db'
> OPENID_STORE = '/var/lib/copr/data/openid_store'
> WHOOSHEE_DIR = '/var/lib/copr/data/whooshee'
>
> # salt for CSRF codes
> SECRET_KEY = 'mjp123'
>
> BACKEND_PASSWORD = 'mjp123'
>
> #CSRF_ENABLED = True
> # as of Flask-WTF 0.9+
> WTF_CSRF_ENABLED = True
>
>
>
> Well, is your
>
> Anything else I need to check??? Or any URLs that are wrong..??
>


frontend_base_url should be set to http://copr02.casalogic.lan/


if that is were your frontend instance can be found.

Also note that your results_baseurl is probably not correct as it should be
url of your backend machine with /results (in default setup) at the end.


> Regards
>
> Martin
> ___
> 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: dist-git is failing to import

[Michal Novotny]

On Mon, Dec 5, 2016 at 4:46 PM, Martin Juhl  wrote:

> When trying to import, dist-git is failing:
>
> [15:12:20][DEBUG][dist_git.dist_git_importer][dist_git_importer:392] 1.
> Try to get task data
> [15:12:20][INFO][dist_git.dist_git_importer][dist_git_importer:484] 2.
> Task: 9-epel7, importing the package: http://copr02.casalogic.lan/
> tmp/tmpuxT8L3/copr-mocks-1.5-1.el7.src.rpm
> [15:12:20][DEBUG][dist_git.dist_git_importer][dist_git_importer:361]
> downloading package http://copr02.casalogic.lan/
> tmp/tmpuxT8L3/copr-mocks-1.5-1.el7.src.rpm
> [15:12:20][DEBUG][dist_git.dist_git_importer][dist_git_importer:428]
> Verifying packagage, getting  name and version.
> [15:12:20][DEBUG][dist_git.dist_git_importer][dist_git_importer:457] make
> sure repos exist: mrmeee/Fisk/copr-mocks
> [15:12:20][DEBUG][dist_git.dist_git_importer][dist_git_importer:415]
> importing srpm into the dist-git
> [15:12:20][DEBUG][dist_git.srpm_import][srpm_import:57] repo_dir:
> /tmp/tmpFpUmZy/copr-mocks
> [15:12:20][DEBUG][dist_git.srpm_import][srpm_import:77] clone the pkg
> repository into tmp directory
> [15:12:20][DEBUG][pyrpkg][__init__:1279] Checking out a specific branch
> ssh://copr-dist-git@localhost/mrmeee/Fisk/copr-mocks
> [15:12:20][DEBUG][pyrpkg][__init__:952] Running git clone -b epel7
> ssh://copr-dist-git@localhost/mrmeee/Fisk/copr-mocks --origin origin and
> logging output
> [15:12:20][INFO][pyrpkg][__init__:973] Cloning into 'copr-mocks'...
>
> [15:12:20][DEBUG][dist_git.srpm_import][srpm_import:79] import the source
> rpm into git and save filenames of sources
> [15:12:20][DEBUG][pyrpkg][__init__:680] Creating repo object from
> /tmp/tmpFpUmZy/copr-mocks
> [15:12:21][DEBUG][pyrpkg][__init__:1105] Running: rpm -qp --nosignature
> --qf %{NAME} /tmp/tmphDba9m/package.src.rpm
> [15:12:21][DEBUG][pyrpkg][__init__:1120] Running: rpm -qpl
> /tmp/tmphDba9m/package.src.rpm
> [15:12:21][INFO][dist_git.srpm_import][srpm_import:86] save the source
> files into lookaside cache
> [15:12:21][ERROR][dist_git.dist_git_importer][dist_git_importer:500]
> Exception raised during srpm import:
> Traceback (most recent call last):
>   File "/usr/share/copr/dist_git/dist_git_importer.py", line 493, in
> do_import
> task.git_hash = self.git_import_srpm(task, fetched_srpm_path)
>   File "/usr/share/copr/dist_git/dist_git_importer.py", line 419, in
> git_import_srpm
> return do_git_srpm_import(self.opts, filepath, task, tmp)
>   File "/usr/share/copr/dist_git/srpm_import.py", line 112, in
> do_git_srpm_import
> raise PackageImportException("Failed to import the source rpm:
> {}".format(src_filepath))
> PackageImportException: Failed to import the source rpm:
> /tmp/tmphDba9m/package.src.rpm
> [15:12:21][DEBUG][dist_git.dist_git_importer][dist_git_importer:465]
> Sending back:
> {"task_id": "9-epel7", "error": "srpm_import_failed"}
> [15:12:21][DEBUG][dist_git.dist_git_importer][dist_git_importer:392] 1.
> Try to get task data
> [15:12:21][DEBUG][dist_git.dist_git_importer][dist_git_importer:399] No
> new tasks to process
>
> Any way to get the importer to throw some more info
>
> Or anyone who recognize this error...
>

What is the version of pyrpkg package on your machine? This is also one of
the trickier errors. To debug that, you need to look into
actual_do_git_srpm_import in dist-git/srpm_import.py.


>
> When running the script defined in the installation (
> https://pagure.io/fork/mrmeee/copr/copr/blob/master/f/dist-git)... I get:
>
> [root@copr02 new]# /usr/share/copr/dist_git/dist_git_importer.py
> Traceback (most recent call last):
>   File "/usr/share/copr/dist_git/dist_git_importer.py", line 13, in
> 
> from .exceptions import CoprDistGitException, PackageImportException,
> PackageDownloadException, SrpmBuilderException, \
> ValueError: Attempted relative import in non-package
> ___
> 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

| Upcoming release today

[Michal Novotny]

Hello,

today at 7pm UTC, the latest COPR stack will be deployed into production.

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

Re: COPR chroots additions/deletions

[Michal Novotny]

I am glad it finally works. Let us know in case of any further problems.

Thank you

On Sun, Jan 1, 2017 at 6:16 PM, Sérgio Basto <ser...@serjux.com> wrote:

> On Sex, 2016-12-09 at 16:27 +, Sérgio Basto wrote:
> > On Sex, 2016-12-09 at 11:41 +, Michal Novotný wrote:
> > >
> > > >
> > > >
> > > > On Sáb, 2016-12-03 at 22:41 +0100, Michal Novotny wrote:
> > > >
> > > > I built successfully 2 packages for 26 and on 3rd fails [1] with
> > > > same
> > > > error:
> > > > Failed to synchronize cache for repo
> > > > 'coprbecloudfedoraprojectorg_results_sergiomb_kde4for23_fedora26i
> > > > 38
> > > > 6_de
> > > > vel', disabling.
> > > >
> > > > analyzing i686 root.log (to avoid confusions) :
> > > > error: nothing provides libjasper.so.1 needed by kdelibs-
> > > > 6:4.14.24-
> > > > 1.fc26.i686 but I just build kdelibs-6:4.14.26-1.fc26 at first
> > > > build !
> > > >
> > > >
> > > > I didn't understand what you mean by backend_rawhide_to_release
> > > > and
> > > > why
> > > > it fail to synchronize , what I can try ?
> > > Please, find out which package provides libjasper.so.1 and rebuild
> > > it
> > > for f26 before building your "3rd" package.
> > I already did that, kdelibs-6:4.14.26-1.fc26 was rebuilt with new
> > libjasper
>
> Now it is working well [1]
> still have Failed to synchronize cache for repo
> 'coprbecloudfedoraprojectorg_results_sergiomb_kde4for23_fedora26x86_64_devel',
> disabling.
> but it use packages from
> coprbecloudfedoraprojectorg_results_sergiomb_kde4for23_fedora26x86_64
>
> Thank you.
>
> [1]
> https://copr-be.cloud.fedoraproject.org/results/
> sergiomb/kde4for23/fedora-26-x86_64/00494325-kde-baseapps/root.log.gz
>
> > >
> > > >
> > > >
> > > >
> > > > Thanks.
> > > >
> > > > [1]
> > > > https://copr.fedorainfracloud.org/coprs/sergiomb/kde4for23/build/
> > > > 48
> > > > 5509
> > > > /
> > > > https://copr.fedorainfracloud.org/coprs/sergiomb/kde4for23/build/
> > > > 48
> > > > 5516
> > > > /
> > > > https://copr.fedorainfracloud.org/coprs/sergiomb/kde4for23/build/
> > > > 48
> > > > 5591
> > > > /
> > > ___
> > > copr-devel mailing list -- copr-devel@lists.fedorahosted.org
> > > To unsubscribe send an email to copr-devel-leave@lists.fedorahosted
> > > .o
> > > rg
> --
> Sérgio M. B.
>
> ___
> 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: please clean deleted builds

[Michal Novotny]

All gpgme builds were deleted from sergiomb/kde4for23. I still wonder why
they stayed there.

On Tue, Mar 28, 2017 at 12:34 PM, Sérgio Basto  wrote:

>
> Hi
> in https://copr-be.cloud.fedoraproject.org/results/sergiomb/kde4for23/
>
> please delete all gpgme builds
>
> 00521854-gpgme/
>
> they are at least  in fedora-24-x86_64/ fedora-25-x86_64/ fedora-25-
> i386/
> For exampple in fedora-24-i386 I got 2: 00521836-gpgme/ and 00521854-
> gpgme/
>
>
> Thanks,
> --
> Sérgio M. B.
> ___
> 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: copr-cli Upstream URL

[Michal Novotny]

Hello Jun,

It's located here: https://pagure.io/copr/copr/blob/master/f/cli.

The links will be fixed in the next release.

Best Regards
clime

On Wed, Apr 12, 2017 at 6:22 PM, Jun Aruga  wrote:

> Hello,
>
> Where is new upstream URL of copr-cli?
> I want to see latest source code of that.
>
> I think below URL is old.
>
> https://admin.fedoraproject.org/pkgdb/package/rpms/copr-cli/
>   Upstream: https://fedorahosted.org/copr/
>
> http://pkgs.fedoraproject.org/cgit/rpms/copr-cli.git/tree/copr-cli.spec
>   L21, L23
>   https://fedorahosted.org/copr/
>
> Kind regards,
> Jun
>
> ___
> 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

[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

COPR rawhide repo links

[Michal Novotny]

Dear rawhide users,

if you have enabled a COPR repo in the last three months (since the
beginning of December last year till yesterday), then it points to
fedora-$releasever-$basearch. You can reenable it by using `dnf copr enable
` to get .repo file pointing to actual fedora-rawhide chroot in
the given project.

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

Re: COPR rawhide repo links

[Michal Novotny]

Hey Vit,

On Mon, Mar 6, 2017 at 1:20 PM, Vít Ondruch <vondr...@redhat.com> wrote:

> I don't understand what are you doing again and again with the repository
> settings. Looking at my doublecmd repository [1], I am missing F25 versions
> there and neither it works for my rawhide:
>

Missing f25 chroot in your project means you probably haven't added it.


The package is not available in rawhide because it needs to be rebuilt for
the rawhide chroot now when the rawhide chroot was added back as a new
chroot.


I am very sorry for this inconvenience and if it is too much of a trouble,
let us know and perhaps we can figure out how to make it easier. We can
e.g. copy your builds from f26 to the rawhide chroot but such builds won't
be in our db nor in dist-git. That's why this wasn't done automatically.

> ~~~
>
> Failed to synchronize cache for repo 'vondruch-doublecmd', disabling.
>
> ~~~
>
>
> I don't want to update my project just because there was some branching. I
> don't need to care about it in Fedora, so why it does not work in Copr? Or
> was this change to keep it working from now forewer?
>
 The last change - returning rawhide - was to keep it working like this
from now. There was not any other change in this regard. The email was just
a follow-up info. I am very sorry for the trouble and we will make sure we
do our best to alleviate any issues, whether related to this or not, and
bring the best possible features from now on. We will make sure we provide
means you will not need to care about branching next time.

For COPR team
clime

> Vít
>
>
> [1] https://copr.fedorainfracloud.org/coprs/vo is ndruch/doublecmd/
> <https://copr.fedorainfracloud.org/coprs/vondruch/doublecmd/>
>
> Dne 4.3.2017 v 10:00 Michal Novotny napsal(a):
>
> Dear rawhide users,
>
> if you have enabled a COPR repo in the last three months (since the
> beginning of December last year till yesterday), then it points to
> fedora-$releasever-$basearch. You can reenable it by using `dnf copr enable
> ` to get .repo file pointing to actual fedora-rawhide chroot in
> the given project.
>
> Sorry for this
> clime
>
>
> ___
> 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

COPR deploy

[Michal Novotny]

Hello, we have just deployed copr-frontend 1.117 and copr-dist-git 0.34.
The deploy is quite special because the packages' origin is Fedora
Infrastructure repositories for the first time and not @copr/copr repo as
it used to be. That is because we have switched to deploying COPR only from
official Fedora repositories (and from the dedicated Infrastructure
repositories for hotfixing) to be able to get Fedora Infrastructure support.

Apart from that, those two packages fix several bugs:

- *Bug 1473671*  - Could
not parse /tmp/tmpGj3KZs/rust-bytecount.spec with error can't parse specfile
- *Bug 1473361*  - New
SCM 2 build does not recall the 'Subdirectory' setting
- DistGitProvider has been reimplemented
- *Bug 1460399*  - Build
breadcrumb incorrect for group project (yet to be closed)
- sqlalchemy deprecation warnings fixed
- monitor page fixed from jinja 2.9
- #106  Renaming a spec file in a
newer version causes the build to fail

And also SELinux was set to Enforcing on copr-dist-git machine...

We have also updated docs with respect to the SCM source type
https://docs.pagure.org/copr.copr/user_documentation.html#scm. There is one
bit missing and that is that copr-cli buildmock currently stands for SCM-2
and copr-cli buildtito currently stands for SCM-1.

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: copr-dist-git hotfixes

[Michal Novotny]

Hello Richard,

On Sun, Jul 16, 2017 at 1:13 AM, Richard Shaw  wrote:

> Maybe unrelated but I noticed that in the last few builds I did that all
> the log entries were entered twice...
>
>
This is probably related to
https://github.com/rpm-software-management/mock/issues/73.


> Thanks,
> Richard
>
> ___
> 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 copr-frontend release

[Michal Novotny]

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 just released copr-frontend-1.118. Mainly this release prepares for
the upcoming branching by adding two features:

  - Batch package rebuilding ("Rebuild all" button in Packages view) so
that you can rebuild all your packages in the new chroots.
If you have build dependencies placed in you copr chroot as well, I
recommend linking the rawhide chroot first in "Repos"
setting ("Edit" button next to the chroot name in project settings) or
in "External repositories" field to be found in your project settings.
Otherwise you will probably need to click the "Rebuild all packages"
button a few times to get all the packages built successfully
(alas manual mockchain). We plan to introduce automatic build ordering
(based on BuildRequires) to optimize this feature in the foreseeing future.

  - "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 for your upcoming builds
 (meaning you don't need to bootstrap anything from scratch). It might
take a few days after branching for this to actually take effect because
 the new chroots need to be enabled in COPR first (and they should also
be in mock for that as well so that building in them works).

You can enable the "Follow Fedora branching" option in project settings and
it will basically ensure that your rawhide builds will be copied
into the new fedora-27-* ones when they become available in COPR.

Also, we have added syntax highlighting in code blocks in project
description and instructions and we switched the used library for markdown
rendering
(now python-CommonMark, before python-markdown).

Thank you for using COPR
COPR team

Full copr-frontend changelog:
- fork all succeeded buildchroots in RawhideToRelease
- follow Fedora branching project's option added
- allow to modify copr chroots
- syntax highlight in project description and instructions
- fix 500 on /api/coprs/build/ for auto-rebuilds
- Bug 1409894 - COPR invalidly renders markdown
- basic rebuild all packages feature added

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

Re: New copr-frontend and copr-rpmbuild deploy

[Michal Novotny]

Thank you for the kind words, Jeandet. Note however that current solution
is just provisional. In near future, there will be new build method
build-spec that will cover exactly your use-case and will close this bug:
*Bug 1420540* <https://bugzilla.redhat.com/show_bug.cgi?id=1420540> - RFE:
Easy way to build directly from spec file.

You currently use the MockSCM method and it works for you but that's just
kind of an "accident". With MockSCM method you should have a Git repo
containing all the sources and the spec file next to them so the correct
solution for you would be to fork the vera repository and make the required
modifications in your Git fork (like adding a spec file in there ;)).

I am sorry that you will need one more change to make it work correctly.
For the time being, it's a hack. Please, if you can, watch this mailing
list. We will try to deliver changes soon for your satisfaction.

COPR team

On Thu, Jun 29, 2017 at 9:34 PM, Jeandet Alexis <
alexis.jean...@member.fsf.org> wrote:

> Hi Michal & COPR team,
>
> Fetching sources from github works now! Thank you :).
> I really like COPR.
>
> Best regards,
> Alexis.
> Le jeudi 29 juin 2017 à 16:08 +0200, Michal Novotny a écrit :
>
> Hello,
>
> we have just deployed the latest upstream version of copr-frontend to fix
> an issue with invalid quoting of baseurl for an additional repo if it
> contained '$' symbol. You may check the logs for errors if you use an
> additonal repos feature.
>
> We have also built the latest upstream copr-rpmbuild version to fix
> building in custom chroots, to fix https://bugzilla.redhat.com/
> show_bug.cgi?id=1461875 and also to experimentally employ spectool for
> downloading external sources identified by Source directive in .spec file.
> Note that you need network enabled for this feature to work.
>
> This is mainly a "hotfix" release.
>
> 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: Mock SCM git repo Name Vs package name

[Michal Novotny]

Hello, please, see the answer below...

On Tue, Jun 27, 2017 at 11:41 AM, jeandet <alexis.jean...@member.fsf.org>
wrote:

> Hello Michal,
>
> Thank you for your help, I'm not a RPM/Mock/Copr pro, you confirm that my
> spec file is Ok, and that copr should use spectool to fetch sources?
> If yes I'll be happy to submit the request.
>
> Then I didn't find examples of packages using github on copr, is there
> people doing this?
>


Hello, your specfile probably would be ok if we supported spectool. I think
we will but a user request at bugzilla or on pagure (
https://pagure.io/copr/copr) would help ;). You can e.g. see
https://copr.fedorainfracloud.org/coprs/g/mock/mock/ as an example project
hosted on Github that uses MockSCM build method.


>
> Best regards,
> Alexis.
> Le mardi 27 juin 2017 à 11:13 +0200, Michal Novotny a écrit :
>
> COPR does not currently use spectool so the required sources are not
> downloaded for you as in the command-line example you provided. You can
> file a request here: https://bugzilla.redhat.com/
> enter_bug.cgi?product=Copr so that we start to use spectool :) (the RFE
> will be welcome).
>
> On Sun, Jun 25, 2017 at 7:22 PM, jeandet <alexis.jean...@member.fsf.org>
> wrote:
>
> Hi,
>
> I'm quite lost here, I followed the doc here:
> https://fedoraproject.org/wiki/Packaging:SourceURL?rd=Packag
> ing/SourceURL#Git_Hosting_Services
>
> My spec file is here:
> https://github.com/jeandet/vera-rpm
>
> Does not build on copr:
> https://copr.fedorainfracloud.org/coprs/ajeandet/SciQLop/build/570647/
>
> On my machine it works with:
> spectool -g -R vera.spec && rpmbuild -bs ./vera.spec && rpmbuild -bb
> ./vera.spec
>
> With mock:
> sudo mock -r fedora-25-x86_64 --scm-enable --scm-option method=git
> --scm-option package=vera --scm-option git_get='git clone
> https://github.com/jeandet/vera-rpm' --scm-option --spec='vera.spec'
> --scm-option branch=master --scm-option write_tar=True -v
>
> I get errors on checkout:
>
> DEBUG: Executing command: ['git', 'checkout', 'master'] with env
> environ({'HOME': '/root', 'DISPLAY': ':1', 'USERHELPER_UID': '0', 'SHELL':
> '/bin/bash', 'TERM': 'xterm-256color', 'LOGNAME': 'root', 'LANG':
> 'fr_FR.UTF-8', 'PATH': '/usr/sbin:/usr/bin:/sbin:/bin:/root/bin', 'USER':
> 'root'}) and shell False
> ERROR: Exception occurred in preexec_fn.
> Traceback (most recent call last):
>   File "/usr/libexec/mock/mock", line 886, in 
> main()
>   File "/usr/lib/python3.5/site-packages/mockbuild/trace_decorator.py",
> line 89, in trace
> result = func(*args, **kw)
>   File "/usr/libexec/mock/mock", line 701, in main
> run_command(options, args, config_opts, commands, buildroot, state)
>   File "/usr/lib/python3.5/site-packages/mockbuild/trace_decorator.py",
> line 89, in trace
> result = func(*args, **kw)
>   File "/usr/libexec/mock/mock", line 720, in run_command
> scmWorker.get_sources()
>   File "/usr/lib/python3.5/site-packages/mockbuild/trace_decorator.py",
> line 89, in trace
> result = func(*args, **kw)
>   File "/usr/lib/python3.5/site-packages/mockbuild/scm.py", line 102, in
> get_sources
> util.do(shlex.split(command), shell=False, cwd=self.src_dir,
> env=os.environ)
>   File "/usr/lib/python3.5/site-packages/mockbuild/trace_decorator.py",
> line 89, in trace
> result = func(*args, **kw)
>   File "/usr/lib/python3.5/site-packages/mockbuild/util.py", line 532, in
> do
> preexec_fn=preexec,
>   File "/usr/lib64/python3.5/subprocess.py", line 676, in __init__
> restore_signals, start_new_session)
>   File "/usr/lib64/python3.5/subprocess.py", line 1283, in _execute_child
> raise child_exception_type(err_msg)
> subprocess.SubprocessError: Exception occurred in preexec_fn.
>
> Best regards,
> Alexis.
> Le mercredi 31 mai 2017 à 14:19 +0200, Michal Novotny a écrit :
>
> The problem is with this line: https://github.com/jeandet/ver
> a/blob/master/vera.spec#L26, where you specify -n vera-master for
> %autosetup. That's how directory is called in
> https://github.com/jeandet/vera/archive/master.tar.gz. But in dist-git
> the directory in the tarball is called vera++-1.3 (name of the package +
> version). If the command was %autosetup -q, it would work. Are you able to
> change the name of the directory in the archive at
> https://github.com/jeandet/vera/archive/master.tar.gz?
>
> clime
>
> On Wed, May 31, 2017 at 11:59 AM, Michal Novotny <cl...@redhat.com> wrote:
>
> Hello, I am just deploying a new version of copr-dist-git that should fix
> that particular problem so you can tr

Re: Builders are in pending mode

[Michal Novotny]

It should be alright now even though still quite slow. We were hitting open
ports limit is now alleviated. New builder spawning could be probably a
little bit more aggressive to utilize resources better and also should be
faster. We still have have some open slots for new builders but they are
not used as the builders are being terminated after quick builds.

clime

2017-06-29 11:31 GMT+02:00 Jean-Marc Liger <
jean-marc.li...@parisdescartes.fr>:

> Hi,
>
> It seems that the builders are locked in pending mode ?
>
> Regards,
>
>
>
> * Jean-Marc LIGER Ingénieur Systèmes et Réseaux de Communication *
> FACULTÉ DE MÉDECINE
> Direction Technique, Informatique, Réseaux et Multimédia
> 15 rue de l’École de Médecine – 75270 Paris cedex 06
> Tél : +33 (0)1 53 10 46 17 <+33%201%2053%2010%2046%2017>
>
>
> ___
> 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 copr-frontend and copr-rpmbuild deploy

[Michal Novotny]

Hello,

we have just deployed the latest upstream version of copr-frontend to fix
an issue with invalid quoting of baseurl for an additional repo if it
contained '$' symbol. You may check the logs for errors if you use an
additonal repos feature.

We have also built the latest upstream copr-rpmbuild version to fix
building in custom chroots, to fix
https://bugzilla.redhat.com/show_bug.cgi?id=1461875 and also to
experimentally employ spectool for downloading external sources identified
by Source directive in .spec file. Note that you need network enabled for
this feature to work.

This is mainly a "hotfix" release.

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

Re: repodata directory is not updated after build

[Michal Novotny]

Hello, it should be fixed now. Sorry for the problems.

clime

2017-04-25 13:39 GMT+02:00 Jean-Marc Liger <
jean-marc.li...@parisdescartes.fr>:

> Hi,
>
> Since yesterday, my repodata directories are not updated after each build.
>
> Regards,
> --
>
>
>
> * Jean-Marc LIGER Ingénieur Systèmes et Réseaux de Communication *
> FACULTÉ DE MÉDECINE
> Direction Technique, Informatique, Réseaux et Multimédia
> 15 rue de l’École de Médecine – 75270 Paris cedex 06
> Tél : +33 (0)1 53 10 46 17 <+33%201%2053%2010%2046%2017>
>
>
> ___
> 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

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

[Michal Novotny]

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 mock setup two chroots during build:

- "bootstrap" one with the latest dnf, rpm (and other build tools) for the
given build chroot (e.g. fedora-26-x86_64)
- the one where the build is actually run (which is of the same os,
version, and arch as the bootstrap one) and that is initially setup by the
tools from the bootstrap one

This makes build last a bit longer (in order of minutes depending on
package download speed) and it might cause a build to fail unexpectedly in
case there is e.g. bug in rawhide dnf (or in experimental dnf that is built
in your copr chroot).

If this option is disabled, host (builder) system dnf is used to setup the
build chroot. There is no bootstrap chroot setup and hence it is faster.

The longer running time might be a problem so, please, if you are a long
term users of COPR and you don't want the feature enabled, check your
project settings and disable it.

Sorry for accidentally enabling it
clime
___
copr-devel mailing list -- copr-devel@lists.fedorahosted.org
To unsubscribe send an email to copr-devel-le...@lists.fedorahosted.org

Re: fedora-26-ppc64le fails with Public key for gcc-7.0.1-0.15.fc26.ppc64le.rpm is not installed

[Michal Novotny]

Hello Sérgio,

this is now fixed. Thank you a lot for your report!

clime

On Sat, May 6, 2017 at 8:27 PM, Sérgio Basto  wrote:

> Hi,
>
> from [1]
> DEBUG util.py:439:  warning: /var/lib/mock/fedora-26-
> ppc64le-mockbuilder-28693/root/var/cache/dnf/fedora-
> 716ef756fbe46d11/packages/gcc-7.0.1-0.15.fc26.ppc64le.rpm: Header V3
> RSA/SHA256 Signature, key ID 64dab85d: NOKEY
> DEBUG util.py:439:  Importing GPG key 0x3B921D09:
> DEBUG util.py:439:   Userid : "Fedora 26 Secondary (26) <
> fedora-26-second...@fedoraproject.org>"
> DEBUG util.py:439:   Fingerprint: 19AA 0442 2491 9109 8B3D 8035 4560 FD4D
> 3B92 1D09
> DEBUG util.py:439:   From   : /usr/share/distribution-gpg-
> keys/fedora/RPM-GPG-KEY-fedora-26-secondary
> DEBUG util.py:439:  Key imported successfully
> DEBUG util.py:439:  Import of key(s) didn't help, wrong key(s)?
> DEBUG util.py:439:  Error:
> DEBUG util.py:439:  Public key for gcc-7.0.1-0.15.fc26.ppc64le.rpm is not
> installedFailing package is: gcc-7.0.1-0.15.fc26.ppc64le
> DEBUG util.py:439:   GPG Keys are configured as: file:///usr/share/
> distribution-gpg-keys/fedora/RPM-GPG-KEY-fedora-26-secondary
> DEBUG util.py:577:  Child return code was: 1
> DEBUG util.py:188:  kill orphans
>
>
> Hope the information will be useful.
> Thanks
>
>
> [1]
> https://copr-be.cloud.fedoraproject.org/results/
> sergiomb/kde4for23/fedora-26-ppc64le/00548243-kde-runtime/root.log
> https://copr.fedorainfracloud.org/coprs/sergiomb/kde4for23/build/548243/
>
> --
> Sérgio M. B.
> ___
> 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

[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

Planned outtage

[Michal Novotny]

Hello guys, there is planned cloud outage in one hour:

https://pagure.io/fedora-infrastructure/issue/6135

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

Re: Mock SCM git repo Name Vs package name

[Michal Novotny]

COPR does not currently use spectool so the required sources are not
downloaded for you as in the command-line example you provided. You can
file a request here: https://bugzilla.redhat.com/enter_bug.cgi?product=Copr
so that we start to use spectool :) (the RFE will be welcome).

On Sun, Jun 25, 2017 at 7:22 PM, jeandet <alexis.jean...@member.fsf.org>
wrote:

> Hi,
>
> I'm quite lost here, I followed the doc here:
> https://fedoraproject.org/wiki/Packaging:SourceURL?rd=
> Packaging/SourceURL#Git_Hosting_Services
>
> My spec file is here:
> https://github.com/jeandet/vera-rpm
>
> Does not build on copr:
> https://copr.fedorainfracloud.org/coprs/ajeandet/SciQLop/build/570647/
>
> On my machine it works with:
> spectool -g -R vera.spec && rpmbuild -bs ./vera.spec && rpmbuild -bb
> ./vera.spec
>
> With mock:
> sudo mock -r fedora-25-x86_64 --scm-enable --scm-option method=git
> --scm-option package=vera --scm-option git_get='git clone
> https://github.com/jeandet/vera-rpm' --scm-option --spec='vera.spec'
> --scm-option branch=master --scm-option write_tar=True -v
>
> I get errors on checkout:
>
> DEBUG: Executing command: ['git', 'checkout', 'master'] with env
> environ({'HOME': '/root', 'DISPLAY': ':1', 'USERHELPER_UID': '0', 'SHELL':
> '/bin/bash', 'TERM': 'xterm-256color', 'LOGNAME': 'root', 'LANG':
> 'fr_FR.UTF-8', 'PATH': '/usr/sbin:/usr/bin:/sbin:/bin:/root/bin', 'USER':
> 'root'}) and shell False
> ERROR: Exception occurred in preexec_fn.
> Traceback (most recent call last):
>   File "/usr/libexec/mock/mock", line 886, in 
> main()
>   File "/usr/lib/python3.5/site-packages/mockbuild/trace_decorator.py",
> line 89, in trace
> result = func(*args, **kw)
>   File "/usr/libexec/mock/mock", line 701, in main
> run_command(options, args, config_opts, commands, buildroot, state)
>   File "/usr/lib/python3.5/site-packages/mockbuild/trace_decorator.py",
> line 89, in trace
> result = func(*args, **kw)
>   File "/usr/libexec/mock/mock", line 720, in run_command
> scmWorker.get_sources()
>   File "/usr/lib/python3.5/site-packages/mockbuild/trace_decorator.py",
> line 89, in trace
> result = func(*args, **kw)
>   File "/usr/lib/python3.5/site-packages/mockbuild/scm.py", line 102, in
> get_sources
> util.do(shlex.split(command), shell=False, cwd=self.src_dir,
> env=os.environ)
>   File "/usr/lib/python3.5/site-packages/mockbuild/trace_decorator.py",
> line 89, in trace
> result = func(*args, **kw)
>   File "/usr/lib/python3.5/site-packages/mockbuild/util.py", line 532, in
> do
> preexec_fn=preexec,
>   File "/usr/lib64/python3.5/subprocess.py", line 676, in __init__
>     restore_signals, start_new_session)
>   File "/usr/lib64/python3.5/subprocess.py", line 1283, in _execute_child
> raise child_exception_type(err_msg)
> subprocess.SubprocessError: Exception occurred in preexec_fn.
>
> Best regards,
> Alexis.
> Le mercredi 31 mai 2017 à 14:19 +0200, Michal Novotny a écrit :
>
> The problem is with this line: https://github.com/jeandet/
> vera/blob/master/vera.spec#L26, where you specify -n vera-master for
> %autosetup. That's how directory is called in https://github.com/jeandet/
> vera/archive/master.tar.gz. But in dist-git the directory in the tarball
> is called vera++-1.3 (name of the package + version). If the command was
> %autosetup -q, it would work. Are you able to change the name of the
> directory in the archive at https://github.com/jeandet/
> vera/archive/master.tar.gz?
>
> clime
>
> On Wed, May 31, 2017 at 11:59 AM, Michal Novotny <cl...@redhat.com> wrote:
>
> Hello, I am just deploying a new version of copr-dist-git that should fix
> that particular problem so you can try that. There seems to be a problem
> later on in building phase but we need to solve it afterwards. clime
>
> On Wed, May 31, 2017 at 12:54 AM, Jeandet Alexis <
> alexis.jean...@member.fsf.org> wrote:
>
> Hi,
>
> I try to build a package from gtihub, it seems that git repo name must be
> the same that package name in spec file?
> Looking this build:
> https://copr.fedorainfracloud.org/coprs/ajeandet/SciQLop/build/559025/
> Looking the log here:
> http://copr-dist-git.fedorainfracloud.org/per-task-logs/559025-f25.log
> I tried on my desktop, I had to replace the following options:
> package=vera by package=vera++
> and
> git_get=git clone --depth 1 https://github.com/jeandet/vera.git vera by
> git_get=git clone --depth 1 https://github.com/jeandet/vera.git vera++
>
> Did I miss something? On github, it seems that I can't call my repo
> vera++

New copr-frontend released

[Michal Novotny]

Hello,

just a quick update...

new copr-frontend (1.110) has been released (and deployed). It contains
Gitlab webhooks support (see Settings -> Webhooks in your COPR projects for
more info) as new a feature and it also attempts to fix Pagure projects
auto-rebuilds.

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

W21 2017 status

[Michal Novotny]

COPR:
- improved copr-dist-git's performance by reimplementing MockScmProvider
- again made Pagure repo auto-rebuilding script more error-prone
- implemented Gitlab webhooks
- did some brainstorming with Pavel Raiskup
- reviewed https://pagure.io/copr/copr/pull-request/11
- released and deployed copr-frontend 1.110
- redeployed copr-dist-git machine from scratch due to journal log errors

DIST-GIT:
- tested dist-git-1.1 on pkgs01.stg
- implemented https://github.com/release-engineering/dist-git/issues/14

MODULARITY:
- made a small PoC for module to Dockerfile conversion:
https://pagure.io/module2Dockerfile
___
copr-devel mailing list -- copr-devel@lists.fedorahosted.org
To unsubscribe send an email to copr-devel-le...@lists.fedorahosted.org

Re: please clean deleted builds

[Michal Novotny]

Right, that means it wasn't cancelled on builder for some reason. We will
look into that this week. Thank you!

clime

On Sun, May 28, 2017 at 4:41 AM, Sérgio Basto <ser...@serjux.com> wrote:

> On Wed, 2017-03-29 at 10:25 +0200, Michal Novotny wrote:
> > All gpgme builds were deleted from sergiomb/kde4for23. I still wonder
> > why they stayed there.
>
> I found the way to leave files after deleted builds, by accident I sent
> one wrong rpm to copr , I cancel and deleted it, but after a while that
> build had been built successfully and voilá, build copr page [1] gives
> "404 not found" but builds are there [2]
>
> [1]
> https://copr.fedorainfracloud.org/coprs/sergiomb/kde4for23/build/557644
> [2]
> https://copr-be.cloud.fedoraproject.org/results/
> sergiomb/kde4for23/fedora-25-x86_64/00557644-kde-baseapps/
>
>
> --
> Sérgio M. B.
> ___
> 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: Mock SCM git repo Name Vs package name

[Michal Novotny]

Hello, I am just deploying a new version of copr-dist-git that should fix
that particular problem so you can try that. There seems to be a problem
later on in building phase but we need to solve it afterwards. clime

On Wed, May 31, 2017 at 12:54 AM, Jeandet Alexis <
alexis.jean...@member.fsf.org> wrote:

> Hi,
>
> I try to build a package from gtihub, it seems that git repo name must be
> the same that package name in spec file?
> Looking this build:
> https://copr.fedorainfracloud.org/coprs/ajeandet/SciQLop/build/559025/
> Looking the log here:
> http://copr-dist-git.fedorainfracloud.org/per-task-logs/559025-f25.log
> I tried on my desktop, I had to replace the following options:
> package=vera by package=vera++
> and
> git_get=git clone --depth 1 https://github.com/jeandet/vera.git vera by
> git_get=git clone --depth 1 https://github.com/jeandet/vera.git vera++
>
> Did I miss something? On github, it seems that I can't call my repo
> vera++, how can I override previous options?
>
> Best regards,
> Alexis.
>
> ___
> 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: Mock SCM git repo Name Vs package name

[Michal Novotny]

The problem is with this line:
https://github.com/jeandet/vera/blob/master/vera.spec#L26, where you
specify -n vera-master for %autosetup. That's how directory is called in
https://github.com/jeandet/vera/archive/master.tar.gz. But in dist-git the
directory in the tarball is called vera++-1.3 (name of the package +
version). If the command was %autosetup -q, it would work. Are you able to
change the name of the directory in the archive at
https://github.com/jeandet/vera/archive/master.tar.gz?

clime

On Wed, May 31, 2017 at 11:59 AM, Michal Novotny <cl...@redhat.com> wrote:

> Hello, I am just deploying a new version of copr-dist-git that should fix
> that particular problem so you can try that. There seems to be a problem
> later on in building phase but we need to solve it afterwards. clime
>
> On Wed, May 31, 2017 at 12:54 AM, Jeandet Alexis <
> alexis.jean...@member.fsf.org> wrote:
>
>> Hi,
>>
>> I try to build a package from gtihub, it seems that git repo name must be
>> the same that package name in spec file?
>> Looking this build:
>> https://copr.fedorainfracloud.org/coprs/ajeandet/SciQLop/build/559025/
>> Looking the log here:
>> http://copr-dist-git.fedorainfracloud.org/per-task-logs/559025-f25.log
>> I tried on my desktop, I had to replace the following options:
>> package=vera by package=vera++
>> and
>> git_get=git clone --depth 1 https://github.com/jeandet/vera.git vera by
>> git_get=git clone --depth 1 https://github.com/jeandet/vera.git vera++
>>
>> Did I miss something? On github, it seems that I can't call my repo
>> vera++, how can I override previous options?
>>
>> Best regards,
>> Alexis.
>>
>> ___
>> 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: 62 packages importing none building?

[Michal Novotny]

The importing queue was stuck due to improper error handling in
copr-dist-git package. We have deployed a new hotfixed copr-dist-git
version that should solve it.

Sorry for the problems
COPR team

On Sun, Jun 4, 2017 at 3:59 PM, Richard Shaw  wrote:

> Anyone know what's up?
>
> Thanks,
> Richard
>
> ___
> 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: builds failing

[Michal Novotny]

This should be now fixed as well.

Thank you!
COPR

On Sat, Jun 10, 2017 at 3:53 PM, Thomas Moschny 
wrote:

> > We have deployed the a version that should solve both the
> > problems. Let us know if it works or if it doesn't.
>
> The *ppc64le builders still seem to fail due to these problems.
>
> - Thomas
> ___
> 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: "No such file or directory" when building SRPM

[Michal Novotny]

Yes, there was an error in the new copr-rpmbuild script that it completely
ignored patches (and other files apart from tarball and spec) and it also
supported only one tarball reference in source file. I have deployed a new
version that should solve the problems.

clime

On Sat, Jun 10, 2017 at 3:12 AM, Jonathan Leroy 
wrote:

> Hi,
>
> I get the following error when I try to build a package by using SRPM
> upload method:
>
> Start: buildsrpm
> Start: rpmbuild -bs
> error: File /builddir/build/SOURCES/plexmediaplayer-qtwebengine.patch:
> No such file or directory
>
> Obviously, the file SOURCES/plexmediaplayer-qtwebengine.patch is
> present in the uploaded SRPM.
> Full log: https://copr-be.cloud.fedoraproject.org/results/
> jleroy/PlexMediaPlayer/fedora-25-x86_64/00563632-
> plexmediaplayer/builder-live.log
>
> Thanks,
>
> --
> Jonathan Leroy
> ___
> 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

builds failing

[Michal Novotny]

Hello,

as it proved the new builder script that we now use was written to
simplistically (incorrectly). It ignored patches and supported only one
tarball reference. We have deployed the a version that should solve both
the problems. Let us know if it works or if it doesn't.

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

Re: "No such file or directory" when building SRPM

[Michal Novotny]

This is related to --no-clean option that we currently use with mock.
I will need to collect a bit more info if we can really drop this option
(as the relative
conan call works without it). There will be a new release on Wed (at
latest), so you can
try afterwards. If you urgently need the build now, however, try to fully
specify the path to
conan (i.e. ~/.local/bin/conan).

On Sat, Jun 10, 2017 at 5:29 PM, Jonathan Leroy <jonat...@harrycow.fr>
wrote:

> 2017-06-10 12:31 GMT+02:00 Michal Novotny <cl...@redhat.com>:
> > Yes, there was an error in the new copr-rpmbuild script that it
> completely
> > ignored patches (and other files apart from tarball and spec) and it also
> > supported only one tarball reference in source file. I have deployed a
> new
> > version that should solve the problems.
>
> Thank you, the SRPM build is now working.
>
> But I now have another error: binaries installed via pip are no longer in
> $PATH:
>
> pip install --user git+https://github.com/jleroy/
> conan.git@gcc-71-dumpversion
> Collecting git+https://github.com/jleroy/conan.git@gcc-71-dumpversion
>   Cloning https://github.com/jleroy/conan.git (to gcc-71-dumpversion)
> to /tmp/pip-zHt08L-build
> [...]
>   Running setup.py install for conan: started
> Running setup.py install for conan: finished with status 'done'
> Successfully installed PyJWT PyYAML astroid
> backports.functools-lru-cache bottle colorama conan configparser
> distro fasteners future isort lazy-object-proxy mccabe monotonic
> node-semver patch pluginbase pylint requests six wrapt
> You are using pip version 8.1.2, however version 9.0.1 is available.
> You should consider upgrading via the 'pip install --upgrade pip' command.
> + conan remote add plex https://conan.plex.tv
> /var/tmp/rpm-tmp.rjbj9w: line 33: conan: command not found
>
> Full log : https://copr-be.cloud.fedoraproject.org/results/jleroy/PlexM
> ediaPlayer/fedora-25-x86_64/00563742-plexmediaplayer/build.log.gz
>
> --
> Jonathan Leroy
> ___
> 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: "No such file or directory" when building SRPM

[Michal Novotny]

On Wed, Jun 14, 2017 at 10:57 AM, Jonathan Leroy 
wrote:

> 2017-06-12 11:12 GMT+02:00 Jonathan Leroy :
> > Thank you Michal.
> > I will wait for the new release.
>
> There is a DNS resolution problem this morning :
>
>  fatal: unable to access 'https://github.com/jleroy/conan.git/': Could
> not resolve host: github.com



Actually, this is a bug. systemd-nspawn "chroots" are now used for building
and there is a different
config option for network-enabling them. Now it's rpmbuild_networking,
before it was use_host_resolv.

I have already fixed the bug but it will take a bit of time until the new
copr-rpmbuild package will get
propagated to builders. Until then, all the builds will have networking
disabled (which should not really
be a problem while the opposite would be a problem).

Apart from that, we still use --no-clean option for the mock build. I could
not find the exact reason why
~/.local/bin is not in PATH when this option is used after previously
setting up the chroot env
with mock --buildsrpm. I think it will become clear to me at some point but
not quite there yet.

Anyway, could you explain your use-case a bit? From the comments in the
spec I can see it's a bit of
a workaround. Would it be perhaps possible for you to use our pyp2rpm build
method to first translate
the required packages into rpms, which could be then (Build)Required in
plexmediaplayer? I suspect
that would be a cleaner way, although a bit more work is probably required
depending on the number
of PyPI-only dependencies.

clime




>
>
> Full log : https://copr-be.cloud.fedoraproject.org/results/
> jleroy/PlexMediaPlayer/fedora-25-x86_64/00565167-
> plexmediaplayer/build.log.gz
>
> --
> Jonathan Leroy
> ___
> 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 is not working properly

[Michal Novotny]

Hello,

since Sunday, we have been fighting with an issue on copr-dist-git machine
that causes all imports and hence builds fail when it occurs. Apart from
corrupted journal logs, we have not been able to find any other possible
cause(s). These were cleaned up today and so far the service has been
running without problems but the problem might possibly still come back. We
hope we can fix this bug once for all soon (if not yet fixed).

COPR team

P.S.: See also
https://lists.fedoraproject.org/archives/list/copr-devel@lists.fedorahosted.org/thread/JUTFFH36GKP3XLA2TFDG2JTH36GXS5SZ/
___
copr-devel mailing list -- copr-devel@lists.fedorahosted.org
To unsubscribe send an email to copr-devel-le...@lists.fedorahosted.org

Re: Mock SCM git repo Name Vs package name

[Michal Novotny]

I believe 'spectool -g mock.spec' does not do anything because Source is
just a filename and not URL. The spec in the mock project does not include
external resources. It relies on the sources being generated into the local
directory by Tito method. Thanks a lot for filling the bug by the way. It
was meanwhile incorrectly assigned to a different system component but
well...what can you do. I made this new issue
https://pagure.io/copr/copr/issue/96, where you can follow the progress.

clime

On Tue, Jun 27, 2017 at 10:40 PM, Jeandet Alexis <
alexis.jean...@member.fsf.org> wrote:

> Le mardi 27 juin 2017 à 15:24 +0200, Michal Novotny a écrit :
>
> Hello, please, see the answer below...
>
> On Tue, Jun 27, 2017 at 11:41 AM, jeandet <alexis.jean...@member.fsf.org>
> wrote:
>
> Hello Michal,
>
> Thank you for your help, I'm not a RPM/Mock/Copr pro, you confirm that my
> spec file is Ok, and that copr should use spectool to fetch sources?
> If yes I'll be happy to submit the request.
>
> Then I didn't find examples of packages using github on copr, is there
> people doing this?
>
>
>
> Hello, your specfile probably would be ok if we supported spectool. I
> think we will but a user request at bugzilla or on pagure (
> https://pagure.io/copr/copr) would help ;). You can e.g. see
> https://copr.fedorainfracloud.org/coprs/g/mock/mock/ as an example
> project hosted on Github that uses MockSCM build method.
>
> Thank you, I tried to fetch mock sources with 'spectool -g mock.spec' it
> doesn't work while building mock in mock works as expected.
> Is there something related to to %setup -q Vs %autosetup -n?
>
> BTW: https://bugzilla.redhat.com/show_bug.cgi?id=1465480
>
>
> Best regards,
> Alexis.
> Le mardi 27 juin 2017 à 11:13 +0200, Michal Novotny a écrit :
>
> COPR does not currently use spectool so the required sources are not
> downloaded for you as in the command-line example you provided. You can
> file a request here: https://bugzilla.redhat.com/en
> ter_bug.cgi?product=Copr so that we start to use spectool :) (the RFE
> will be welcome).
>
> On Sun, Jun 25, 2017 at 7:22 PM, jeandet <alexis.jean...@member.fsf.org>
> wrote:
>
> Hi,
>
> I'm quite lost here, I followed the doc here:
> https://fedoraproject.org/wiki/Packaging:SourceURL?rd=Packag
> ing/SourceURL#Git_Hosting_Services
>
> My spec file is here:
> https://github.com/jeandet/vera-rpm
>
> Does not build on copr:
> https://copr.fedorainfracloud.org/coprs/ajeandet/SciQLop/build/570647/
>
> On my machine it works with:
> spectool -g -R vera.spec && rpmbuild -bs ./vera.spec && rpmbuild -bb
> ./vera.spec
>
> With mock:
> sudo mock -r fedora-25-x86_64 --scm-enable --scm-option method=git
> --scm-option package=vera --scm-option git_get='git clone
> https://github.com/jeandet/vera-rpm' --scm-option --spec='vera.spec'
> --scm-option branch=master --scm-option write_tar=True -v
>
> I get errors on checkout:
>
> DEBUG: Executing command: ['git', 'checkout', 'master'] with env
> environ({'HOME': '/root', 'DISPLAY': ':1', 'USERHELPER_UID': '0', 'SHELL':
> '/bin/bash', 'TERM': 'xterm-256color', 'LOGNAME': 'root', 'LANG':
> 'fr_FR.UTF-8', 'PATH': '/usr/sbin:/usr/bin:/sbin:/bin:/root/bin', 'USER':
> 'root'}) and shell False
> ERROR: Exception occurred in preexec_fn.
> Traceback (most recent call last):
>   File "/usr/libexec/mock/mock", line 886, in 
> main()
>   File "/usr/lib/python3.5/site-packages/mockbuild/trace_decorator.py",
> line 89, in trace
> result = func(*args, **kw)
>   File "/usr/libexec/mock/mock", line 701, in main
> run_command(options, args, config_opts, commands, buildroot, state)
>   File "/usr/lib/python3.5/site-packages/mockbuild/trace_decorator.py",
> line 89, in trace
> result = func(*args, **kw)
>   File "/usr/libexec/mock/mock", line 720, in run_command
> scmWorker.get_sources()
>   File "/usr/lib/python3.5/site-packages/mockbuild/trace_decorator.py",
> line 89, in trace
> result = func(*args, **kw)
>   File "/usr/lib/python3.5/site-packages/mockbuild/scm.py", line 102, in
> get_sources
> util.do(shlex.split(command), shell=False, cwd=self.src_dir,
> env=os.environ)
>   File "/usr/lib/python3.5/site-packages/mockbuild/trace_decorator.py",
> line 89, in trace
> result = func(*args, **kw)
>   File "/usr/lib/python3.5/site-packages/mockbuild/util.py", line 532, in
> do
> preexec_fn=preexec,
>   File "/usr/lib64/python3.5/subprocess.py", line 676, in __init__
> restore_signals, start_new_session)
>   File "/usr/lib64/python3.5/subprocess.py", line 1283, in

Re: Error 500 : Internal Server Error ('url')

[Michal Novotny]

The problem should be fixed now. Please try and let me know.

clime

On Thu, Oct 5, 2017 at 4:39 PM, Michal Novotny <cl...@redhat.com> wrote:

> Hey,
>
> On Thu, Oct 5, 2017 at 2:56 PM, Miro Hrončok <mhron...@redhat.com> wrote:
>
> I may have found an issue with copr:
>>
>>
> Yes, it's a bug when accessing not-so-new builds that have not-updated
> build definition in DB.
> I can fix it manually in DB and in any case, this will be fixed upon next
> copr-frontend deploy
> (might be more than week though). Let me know if you want fast fix. I can
> do it immediately then.
>
>
>> 1. go to https://copr.fedorainfracloud.org/coprs/g/python/pypy35/builds/
>> 2. click a build ID -> https://copr.fedorainfracloud.
>> org/coprs/g/python/pypy35/build/564097/
>>
>> Error 500 : Internal Server Error
>> 'url'
>>
>> Note: This is a repository owned by a group.
>>
>> --
>> Miro Hrončok
>> --
>> Phone: +420777974800
>> IRC: mhroncok
>> ___
>> 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: Error 500 : Internal Server Error ('url')

[Michal Novotny]

Hey,

On Thu, Oct 5, 2017 at 2:56 PM, Miro Hrončok  wrote:

I may have found an issue with copr:
>
>
Yes, it's a bug when accessing not-so-new builds that have not-updated
build definition in DB.
I can fix it manually in DB and in any case, this will be fixed upon next
copr-frontend deploy
(might be more than week though). Let me know if you want fast fix. I can
do it immediately then.


> 1. go to https://copr.fedorainfracloud.org/coprs/g/python/pypy35/builds/
> 2. click a build ID -> https://copr.fedorainfracloud.
> org/coprs/g/python/pypy35/build/564097/
>
> Error 500 : Internal Server Error
> 'url'
>
> Note: This is a repository owned by a group.
>
> --
> Miro Hrončok
> --
> Phone: +420777974800
> IRC: mhroncok
> ___
> 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: Counters down

[Michal Novotny]

Hello,

On Wed, Aug 23, 2017 at 2:32 PM, Michal Novotny <cl...@redhat.com> wrote:

> Hello!
>
> On Wed, Aug 23, 2017 at 2:29 PM, Jean-Marc Liger <jean-marc.liger@
> parisdescartes.fr> wrote:
>
>>
>> Le 22/08/2017 à 11:55, Jean-Marc Liger a écrit :
>>
>> Le 21/08/2017 à 16:15, Michal Novotny a écrit :
>>
>> Hello Jean,
>>
>> On Mon, Aug 21, 2017 at 4:05 PM, Jean-Marc Liger <
>> jean-marc.li...@parisdescartes.fr> wrote:
>>
>>> Olders builds seem to be unvailable also.
>>>
>>
>> Can you, please, give me more information about the builds.
>>
>>
>> Packages I have tested from build 582295 or 544742 are available from
>> direct download but are unavailable from yum.
>>
>>
>> Sorry for this noise, it was a mistake of my own in yum's configuration
>> :-[
>>
>>
>> Thank you
>> clime
>>
>>>
>>> Le 21/08/2017 à 14:37, Jean-Marc Liger a écrit :
>>>
>>> Hi,
>>>
>>> My counters are down for some weeks now.
>>>
>>>
>>
>> But download counters are still stick to zero.
>>
>
> Yes, I will try to make counters work again.
>


Counters should work again now. Thanks for the notice!


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

[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

[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

Missing logs for "Attempt to build SRPM have failed." error

[Michal Novotny]

Hello,

If you encounter this error, you probably also won't get any easy access to
the logs about the error :(. We will fix that in the next release. For now,
you can access the logs in a slightly more difficult way:

They are placed at:

https://copr-be.cloud.fedoraproject.org/results/<
owner>//srpm-builds//

"srpm-builds" directory is placed next to the chroot directories.

Sorry for this inconvenience. We will fix this promptly for the next
release (i.e. make the link available directly from UI).

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

[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

[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

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

Re: CI-style package builds from a Git repository

[Michal Novotny]

Hello Florian,

yes, it should be possible. I would need to see the build to debug the
problem.

Thank you
clime

On Mon, Oct 2, 2017 at 3:28 PM, Florian Weimer  wrote:

> Is there a way to get Copr to build binary packages directly from a Git
> repository?  I do not need the SRPM, and I don't want to bother with
> revision and %changelog updates.
>
> I tried an SCM-1 style repository (I think), but the generated SRPM only
> had the spec file, which is not what I want.
>
> I used to have a private builder which did exactly that for Debian
> packages, and it was extremely helpful for distributing software.  And if
> Copr isn't the tool for that, what is?
>
> Thanks,
> Florian
> ___
> 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 deploy

[Michal Novotny]

Hello,

today, we have deployed new copr-frontend 1.120-1, copr-backend 1.103-1,
and copr-keygen 1.68-1.

Changes in keygen and backend are mainly cosmetic (i.e. spelling fixes) but
in frontend, there are quite a few:

- fix build stucking with srpm url/upload resubmitted builds
- .spec cleanup
- move DEFER_BUILD_SECONDS to config values and set default to 80
- show backend log for srpm builds
- fix url to import log
- Bug 1431035 - coprs should check credentials before uploading
  source rpm

Hopefully, this will serve well. Next update will finally fix repo/rpm
download counters.

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

fedora chroot updates

[Michal Novotny]

Hello,

fedora-24 chroots were removed from COPR and fedora-27 chroots were added.
For projects with "Follow Fedora branching" option enabled, the fedora-27
chroots were auto-created in their projects and existing builds from the
rawhide chroots were copied there.

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

Re: "No such command: builddep." with Fedora Rawhide chroot

[Michal Novotny]

The problem with rawhide dnf is described here:
https://bugzilla.redhat.com/show_bug.cgi?id=1483342


On Mon, Aug 21, 2017 at 11:14 AM, Pavel Raiskup <prais...@redhat.com> wrote:

> On Monday, August 21, 2017 10:14:55 AM CEST Michal Novotny wrote:
> > Hello, this might be a change in rawhide dnf-plugins-core (or dnf).
> Please,
> > if you don't need mock bootstrap feature enabled in your project
> settings,
> > then you can disable it.
>
> Is wide disabling (of this mistakenly enabled) feature considered too
> drastic?
>
> I would give it +1 as AFAIK, only dnf/rpm guys want to test this feature.
> So,
> while doing a global switch in frontend database the
> 'rpm-software-management'
> group could be blacklisted.
>
> Btw., it is tiring to go through all of my projects and disabling
> one-by-one...
>
> Pavel
>
> > That way, host system dnf and dnf-plugins-core
> > will be used. I'll look closely at what causes the problem in the rawhide
> > dnf/dnf-plugins-core.
> >
> > clime
> >
> > On Mon, Aug 21, 2017 at 6:41 AM, Jonathan Leroy <jonat...@harrycow.fr>
> > wrote:
> >
> > > Hi,
> > >
> > > I can't build my package for Fedora Rawhide. I'm getting the following
> > > error :
> > >
> > >  No such command: builddep. Please use /usr/bin/dnf --help
> > >
> > > Full log : https://copr-be.cloud.fedoraproject.org/results/
> > > jleroy/PlexMediaPlayer/fedora-rawhide-x86_64/00592100-
> > > plexmediaplayer/root.log.gz
> > > No issue with F25 and F26 chroots.
> > >
> > > Thanks,
> > >
> > > --
> > > Jonathan Leroy
> > > ___
> > > copr-devel mailing list -- copr-devel@lists.fedorahosted.org
> > > To unsubscribe send an email to copr-devel-leave@lists.
> fedorahosted.org
> > >
> >
>
>
>
___
copr-devel mailing list -- copr-devel@lists.fedorahosted.org
To unsubscribe send an email to copr-devel-le...@lists.fedorahosted.org

Re: "No such command: builddep." with Fedora Rawhide chroot

[Michal Novotny]

Hello, this might be a change in rawhide dnf-plugins-core (or dnf). Please,
if you don't need mock bootstrap feature enabled in your project settings,
then you can disable it. That way, host system dnf and dnf-plugins-core
will be used. I'll look closely at what causes the problem in the rawhide
dnf/dnf-plugins-core.

clime

On Mon, Aug 21, 2017 at 6:41 AM, Jonathan Leroy 
wrote:

> Hi,
>
> I can't build my package for Fedora Rawhide. I'm getting the following
> error :
>
>  No such command: builddep. Please use /usr/bin/dnf --help
>
> Full log : https://copr-be.cloud.fedoraproject.org/results/
> jleroy/PlexMediaPlayer/fedora-rawhide-x86_64/00592100-
> plexmediaplayer/root.log.gz
> No issue with F25 and F26 chroots.
>
> Thanks,
>
> --
> Jonathan Leroy
> ___
> 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: Counters down

[Michal Novotny]

Hello Jean,

do you mean download counters for your repositories?

clime

On Mon, Aug 21, 2017 at 2:37 PM, Jean-Marc Liger <
jean-marc.li...@parisdescartes.fr> wrote:

> Hi,
>
> My counters are down for some weeks now.
>
>
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: build process doesn't work for me

[Michal Novotny]

Hello Jean,

no problem at all. Glad you figured it out.

On Fri, Aug 25, 2017 at 7:06 PM, Jean-Marc Liger <
jean-marc.li...@parisdescartes.fr> wrote:

>
>
> Le 25/08/2017 à 17:03, Jean-Marc Liger a écrit :
>
> Le 25/08/2017 à 14:07, Jean-Marc Liger a écrit :
>
> Hello,
>
> All my builds have a dead end today.
>
>
> To be more precise, all my epel-[x86_64,ppc64le] have a dead end today,
> fedora-[25,26] build fine.
>
>
> I've finaly found it with on my local mock instance. It was a vicious xz
> circular dependancy that I introduce in my cross-building repository to
> compel with the new RHEL 7.4 multilib protection... Sorry for the noïse
> again !
>
> Regards,
>
> Jean-Marc
>
> ___
> copr-devel mailing list -- copr-devel@lists.fedorahosted.org
> To unsubscribe send an email to copr-devel-le...@lists.fedorahosted.org
>
>
> --
>
>
>
> * Jean-Marc LIGER Ingénieur Systèmes et Réseaux de Communication *
> FACULTÉ DE MÉDECINE
> Direction Technique, Informatique, Réseaux et Multimédia
> 15 rue de l’École de Médecine – 75270 Paris cedex 06
> Tél : +33 (0)1 53 10 46 17 <+33%201%2053%2010%2046%2017>
>
>
> ___
> 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: Getting error "Could not parse *.spec" on copr build

[Michal Novotny]

You can watch this branch
https://pagure.io/copr/copr/branch/rpmbuild-providers that should fix the
problem after merge
Otherwise, you can also report the bug here Enter Bug: Copr
<https://bugzilla.redhat.com/enter_bug.cgi?product=Copr> or
https://pagure.io/copr/copr/issues and watch the status there.

Thank you
clime

On Fri, Sep 1, 2017 at 11:31 PM, Robbi Nespu <robbine...@fedoraproject.org>
wrote:

> Thank you, Where I can see bug status regarding this issue? I can't find
> it on bugzilla.
>
> On Fri, Sep 1, 2017 at 3:42 AM, Michal Novotny <cl...@redhat.com> wrote:
>
>> This is a bug on our side.
>>
>> More concretely, the error is caused by:
>>
>> BuildRoot: %(mktemp -ud %{_tmppath}/%{namevr}-XX)
>>
>> directive in the spec file. We "disallow" calling external commands
>> currently from
>> the .spec preamble.
>>
>> This will be fixed in the next release. As a temporary solution I would
>> suggest putting
>> the mktemp call into %build section or avoid it completely.
>>
>> Sorry for the problems
>> clime
>>
>> On Thu, Aug 31, 2017 at 8:26 PM, Robbi Nespu <
>> robbine...@fedoraproject.org> wrote:
>>
>>> Hi there,
>>> I am new with packager, please teach me if I doing wrong. I fork some
>>> project to learn about packaging.
>>>
>>> I forked a copr project (riot) and try to build new version of riot but
>>> failed, source are stored on github https://github.com/RobbiNespu/
>>> riot-rpm
>>>
>>> Latest build and  log : https://copr.fedorainfracloud.
>>> org/coprs/robbinespu/Riot/build/596875/
>>>
>>> I keep getting the same error for each build, can anyone tell my why and
>>> what should I do
>>> ___
>>> 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
>>
>>
>
>
> --
>
> Best Regards,
> RN
>
> ___
> 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: ppc64le still in pending mode

[Michal Novotny]

Hello Jean!

On Thu, Oct 19, 2017 at 9:58 AM, Jean-Marc Liger <
jean-marc.li...@parisdescartes.fr> wrote:

> Hello,
>
> It seems that ppc64le builders are stuck in pending mode.
>
>
Thank you for the info! It should be fixed now.


> 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

New Deploy

[Michal Novotny]

Hello,

we have just deployed the latest COPR stack. Apart from a few bugfixes,
there is one important update: SCM source types were finally unified so now
there is only one "SCM" tab. You can also use copr command-line client
(copr-cli) to build for any Github/Gitlab/DistGit repo. See `copr-cli
buildscm` subcommand. You need the latest copr-cli (1.64) and python-copr
(1.82) for that. You should be able to find them in
https://copr.fedorainfracloud.org/coprs/g/copr/copr/. I'll be writing docs
for the new source type and all that can be done with it...wait for it ;).
Now this is just a quick update.

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

COPR: usage of http:// in python client

[Michal Novotny]

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 to revoke
user API tokens for which there have been accesses through the http
interface recently. You can find the list of the affected users in the
attachment and we apologize for this. Please, use
https://copr.fedorainfracloud.org/api/ to retrieve new tokens. If you know
you have been using CoprClient without specifying copr-frontend URL and you
won't find yourself in the attached list, please, go to
https://copr.fedorainfracloud.org/api/ and regenerate your tokens as well.

COPR team
jmontleon
hnakamur
user501254
sochotni
jkastner
bkabrda
james
khara
praiskup
lazka
madcat
che
openscapmaint
tartare
vishalv
jenslody
pvoborni
gozer
rholy
immanetize
msuchy
alebastr
mbaldessari
thm
___
copr-devel mailing list -- copr-devel@lists.fedorahosted.org
To unsubscribe send an email to copr-devel-le...@lists.fedorahosted.org

Re: long waiting times for COPR jobs

[Michal Novotny]

Hello Jean-Marc,

answer is below...

On Tue, Nov 28, 2017 at 11:20 AM, Jean-Marc Liger <
jean-marc.li...@parisdescartes.fr> wrote:

> Hi Clime,
> Le 03/11/2017 à 06:39, Michal Novotny a écrit :
>
> Hey,
>
> On Wed, Nov 1, 2017 at 3:42 PM, Michal Novotny <cl...@redhat.com> wrote:
>
>> 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.
>>
>
> as we have found out yesterday. One of the main issue was
> 'createrepo.lock.lock' file in @rubygems/rubygems/srpm-builds/ directory
> on copr-backend that caused 'createrepo' command to hand indefinitely after
> a srpm build and hence the builder that was allocated for rubygems srpm
> builds was never released afterwards. Together with #160 SRPM build may
> be allocated on multiple builders at once
> <https://pagure.io/copr/copr/issue/160>, this probably was causing the
> really long waiting times. Our queueing mechaism will still need to be (and
> will be) improved but this was the main issue very likely.
>
> Sorry for the waiting
> COPR team
>
>
> All ppc64le plateforms are in pending mode since yesterday, is it relative
> to the above ?
>

No, not really. This is an OpenStack problem as we are not able to spawn
any new ppc64le builder from COPR. We will try to build a new ppc64le image
based on Fedora27 and see if it helps and if not, we will give another try
to solve it together with OpenStack folks.

clime


> 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: is COPR down?

[Michal Novotny]

COPR is back now. Sorry for the problems. We get high load peaks at times.

clime

On Mon, Dec 4, 2017 at 7:05 PM, David Shea  wrote:

> Connection is timing out connecting to copr.fedorainfracloud.org. Is
> there an ETA on when it will come back?
> ___
> 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 outage at 1am UTC

[Michal Novotny]

Hello,

today there will be a COPR outage lasting approximately for 1 hour starting
at 1 a.m. UTC. We will be upgrading most of the machines to the latest
released Fedora version.

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

Re: COPR outage at 1am UTC

[Michal Novotny]

I am very sorry. I meant 1pm UTC today.

Best regrads
On behalf of COPR team
clime

On Mon, Dec 18, 2017 at 10:03 AM, Michal Novotny <cl...@redhat.com> wrote:

> Hello,
>
> today there will be a COPR outage lasting approximately for 1 hour
> starting at 1 a.m. UTC. We will be upgrading most of the machines to the
> latest released Fedora version.
>
> COPR Team
>
___
copr-devel mailing list -- copr-devel@lists.fedorahosted.org
To unsubscribe send an email to copr-devel-le...@lists.fedorahosted.org

long waiting times for COPR jobs

[Michal Novotny]

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