EPEL 7 and EPEL 6 in Copr

[Miroslav Suchý]

With EOL of RHEL 7 and EPEL 7 we recently got several questions how long we 
will keep epel-7-* chroots in Copr?

It will stay in Copr as long as people will need it. I may start asking around this time next year. But for next 12 
months do not expect a change.



On the other hand we still have epel-6 enabled. And I checked several former users and it seems that no one is using it. 
Therefore we will disable epel-6 soon.


--
Miroslav Suchy, RHCA
Red Hat, Manager, Packit and CPT, #brno, #fedora-buildsys

--
___
copr-devel mailing list -- copr-devel@lists.fedorahosted.org
To unsubscribe send an email to copr-devel-le...@lists.fedorahosted.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedorahosted.org/archives/list/copr-devel@lists.fedorahosted.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Fedora Copr Outage - Updating to a March 2024 Version

[Miroslav Suchý]

Dne 09. 03. 24 v 11:13 Pavel Raiskup napsal(a):

Would it make sense to have the "rebuild with ssh access" call mock
with "--no-clean-after"? Without that, there is not that much more to
inspect than the chroot itself, is there? Or is the idea that we run
mock again?


The idea, is that you will be able to execute the command in the chroot.

So instead of building packages in mode "try this" and "try that", you will be able to run e.g. gcc in that chroot. 
Maybe put there some print() for debugging. To find the culprit of failure faster. Especially on non-intel architectures.



--
Miroslav Suchy, RHCA
Red Hat, Manager, Packit and CPT, #brno, #fedora-buildsys
--
___
copr-devel mailing list -- copr-devel@lists.fedorahosted.org
To unsubscribe send an email to copr-devel-le...@lists.fedorahosted.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedorahosted.org/archives/list/copr-devel@lists.fedorahosted.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: What are batches good for?

[Miroslav Suchý]

Dne 01. 12. 23 v 18:00 Vít Ondruch napsal(a):

With MPB, trying to rebuild all Ruby related packages, I'd hoped I'll get the 
results much faster.

The problem (to me) seems to be that packages are build in batches (as can be seen in attached screenshot). If there 
is some build which takes ages (this time it seems to be qt5-qtwebkit) in some batch, nothing else is processed unless 
that build finishes. But to me, the slow package has probably the lowest importance. I'd rather see the biggest chunk 
done than to endlessly wait for some package.



See this blog post:

https://pavel.raiskup.cz/blog/build-ordering-by-batches-in-copr.html

and this documentation

https://docs.pagure.org/copr.copr/user_documentation.html#build-batches

> Can this behavior be modified? E.g. the batches could overlap slightly or rebatched with low number of tasks still 
running. Dunno. But this makes MPB / Copr useless for this task.


Likely no. It does its job for most of the people. I.e. when you run two consequent 'copr build' then lots of users told 
us that they expect that the second starts only when the first one finish. Therefore I think that most people likes this 
behavior.


If you submit lots of builds at once, I recomend to utilize batches with --with-build-id and --after-build-id. With 
these option you can easily divide hundreds build into several batches and be sure they will be built in right order. 
IIRC KDE folks are utilizing this.


--
Miroslav Suchy, RHCA
Red Hat, Manager, Packit and CPT, #brno, #fedora-buildsys
--
___
copr-devel mailing list -- copr-devel@lists.fedorahosted.org
To unsubscribe send an email to copr-devel-le...@lists.fedorahosted.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedorahosted.org/archives/list/copr-devel@lists.fedorahosted.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

srpm builds can be built on aarch64 too

[Miroslav Suchý]

Previously we built src.rpm on intel machines.

This morning I changed our configuration that src.rpm can be build on aarch64.

I do not expect any issue as Koji is doing that for ages. Reporting just in 
case you see something odd.

--
Miroslav Suchy, RHCA
Red Hat, Manager, Packit and CPT, #brno, #fedora-buildsys
___
copr-devel mailing list -- copr-devel@lists.fedorahosted.org
To unsubscribe send an email to copr-devel-le...@lists.fedorahosted.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedorahosted.org/archives/list/copr-devel@lists.fedorahosted.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

chroot fedora-35-i686 removed

[Miroslav Suchý]

Because of this the chroot fedora-35-i686 is not usefull anymore. I disabled 
this chroot.

Just after the Christmas break we are going to remove all other Fedora 35 
chroots.

Miroslav



 Přeposlaná zpráva 
Předmět:Re: COPR Build Failures for fedora-35-i686
Datum:  Mon, 19 Dec 2022 18:32:45 +1100
Od: Frank Crawford 
Adresa pro odpověď: Development discussions related to Fedora 

Komu:   Development discussions related to Fedora 

Kopie:  Vitaly Zaitsev 



On Sun, 2022-12-18 at 16:07 +0100, Vitaly Zaitsev via devel wrote:

On 18/12/2022 12:20, Frank Crawford wrote:
> Can anyone explain what is going on?

Fedora no longer has i686 mirrors, so COPR or mock use Koji's
buildroot. It was recently removed due to F35 EOL so you can no longer build F35
i686 packages.


Thank you Vitaly, that is understandable.

Regards
Frank
___
devel mailing list -- de...@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/de...@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue___
copr-devel mailing list -- copr-devel@lists.fedorahosted.org
To unsubscribe send an email to copr-devel-le...@lists.fedorahosted.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedorahosted.org/archives/list/copr-devel@lists.fedorahosted.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: reporting a a very old bug

[Miroslav Suchý]

Dne 23. 10. 22 v 5:55 Sérgio Basto napsal(a):

The bug is after web page of results show the firsts results, the web
page is cached and is never updated again. While new files of log are


Ctrl+Shift+R

https://answersdb.com/browser/what-is-difference-between-ctrl-r-and-ctrl-shift-r.html

Should the trick.

We are using AWS CloudFront as a CDN. And it should honor the browser http header to invalidate headers. But anything in 
the chain browser-CDN-Copr can break it.

___
copr-devel mailing list -- copr-devel@lists.fedorahosted.org
To unsubscribe send an email to copr-devel-le...@lists.fedorahosted.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedorahosted.org/archives/list/copr-devel@lists.fedorahosted.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Outage: Upgrading the Fedora Copr backend storage, 2022-10-28 -- 2022-10-30

[Miroslav Suchý]

Dne 21. 10. 22 v 18:30 Miro Hrončok napsal(a):
FWIW it seems the alert-danger banner at top of https://copr.fedorainfracloud.org added bootstrap css and changed 
(broke?) the design of the web interface slightly.


That was mistake. Link to css removed.

Miroslav
___
copr-devel mailing list -- copr-devel@lists.fedorahosted.org
To unsubscribe send an email to copr-devel-le...@lists.fedorahosted.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedorahosted.org/archives/list/copr-devel@lists.fedorahosted.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: [EPEL-devel] Mock/Copr default epel-8-* configuration to be changed

[Miroslav Suchý]

Dne 22. 11. 21 v 15:00 Pavel Raiskup napsal(a):

Hello Fedora EPEL maintainers!

First I don't feel comfortable announcing this, I'm not happy about the
situation and so I don't want to be the lightning rod :-).  But I believe
that we can come to acceptable Copr/Mock solution and this needs to be
discussed...  so here we are.

By the end of the year 2021 we have to fix our default EPEL 8 Mock
configuration (mock-core-configs.rpm, /etc/mock/epel-8-*.cfg) as CentOS 8
goes EOL by then.



I wrote down the possible options and their pros and cons and I done my best to 
catch all the feedback here.

https://docs.google.com/document/d/1wF7-7_y6Ac_oB-kCFdE6VBWPW8o8zjXd2Z0SGy4VxUA/edit?usp=sharing

Miroslav
___
copr-devel mailing list -- copr-devel@lists.fedorahosted.org
To unsubscribe send an email to copr-devel-le...@lists.fedorahosted.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedorahosted.org/archives/list/copr-devel@lists.fedorahosted.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: Mock/Copr default epel-8-* configuration to be changed

[Miroslav Suchý]

Dne 22. 11. 21 v 17:57 Nico Kadel-Garcia napsal(a):

Which is precisely why pointing it to the 'stream' release seems the
only workable solution.


That is EPEL-next

https://fedoraproject.org/wiki/EPEL_Next#Introduction

Miroslav
___
copr-devel mailing list -- copr-devel@lists.fedorahosted.org
To unsubscribe send an email to copr-devel-le...@lists.fedorahosted.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedorahosted.org/archives/list/copr-devel@lists.fedorahosted.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: [EPEL-devel] Mock/Copr default epel-8-* configuration to be changed

[Miroslav Suchý]

Dne 22. 11. 21 v 15:10 Miro Hrončok napsal(a):


However, enough of my personal views. Since we have not used RHEL for copr/mock EPEL buidlroots until now, but we used 
a downstream freely-available RHEL-copy (CentOS Linux), could we not continue doing so by using e.g. AlmaLinux?


For day to day work I would suggest to move to centos-stream + epel-next (hmm, 
we do not have a config for that).

But EPEL is built against RHEL (not Alma, not Rocky). So we either use default config which will differ from Koji or we 
have to fiddle with entitlements:


https://rpm-software-management.github.io/mock/Feature-rhelchroots

https://developers.redhat.com/blog/2021/02/10/how-to-activate-your-no-cost-red-hat-enterprise-linux-subscription#step_2__download_no_cost_rhel

Miroslav
___
copr-devel mailing list -- copr-devel@lists.fedorahosted.org
To unsubscribe send an email to copr-devel-le...@lists.fedorahosted.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedorahosted.org/archives/list/copr-devel@lists.fedorahosted.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: Excluding older builds of packages from Fedora when testing new ones in Copr

[Miroslav Suchý]

Dne 08. 07. 21 v 15:47 Miro Hrončok napsal(a):
However, this procedure has a flaw. Let's say I'm working on upgrading python-click from 7.x to 8.x. And let's say a 
package (even transitively) BuildRequires:


    python3dist(click) < 8

The way that dnf dependency resolution works, that package will be built with Rawhide's python3-click 7.x and it will 
be marked as successful. However, I'd like to see a failure here to be notified that such package cannot be build and 
will be negatively impacted by the update.



Is there a way to solve this? 


Hmm, the root.log contains list of package actually installed. But the decision what you are looking for is on you and 
will not be easy. :(


Miroslav
___
copr-devel mailing list -- copr-devel@lists.fedorahosted.org
To unsubscribe send an email to copr-devel-le...@lists.fedorahosted.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedorahosted.org/archives/list/copr-devel@lists.fedorahosted.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Move to libra.chat

[Miroslav Suchý]

Hi.

I want to announce that Copr developers have moved from Freenode to Libra.chat. 
Still #fedora-buildsys there.

For more details see:

https://fedoramagazine.org/irc-announcement-fedora-moving-to-libera-chat/

Miroslav
___
copr-devel mailing list -- copr-devel@lists.fedorahosted.org
To unsubscribe send an email to copr-devel-le...@lists.fedorahosted.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedorahosted.org/archives/list/copr-devel@lists.fedorahosted.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: What's the best way to compile Fedora's kernel rpms on copr?

[Miroslav Suchý]

Dne 20. 05. 21 v 22:30 Daniel Farina napsal(a):

What's the right way to do that? I mostly want to slowly bisect this bug on my 
laptop:https://bugzilla.redhat.com/show_bug.cgi?id=1921242. It may seem a bit 
weird to do this through COPR, but for various reasons I thought that would be 
useful to me, and a handy skill to have.


I am afraid there is no right way. There is many way and none of them is better or worse. What suits you better is the 
right way. :)


Miroslav
___
copr-devel mailing list -- copr-devel@lists.fedorahosted.org
To unsubscribe send an email to copr-devel-le...@lists.fedorahosted.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedorahosted.org/archives/list/copr-devel@lists.fedorahosted.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

master -> main on github.com

[Miroslav Suchý]

I have changed default branch for our github.com projects:

https://github.com/fedora-copr

(all but copr which already used main)

To change it it your local checkout please do:

git branch -m master main
git fetch origin
git branch -u origin/main main

It mainly affects:
  https://github.com/fedora-copr/fedora-copr.github.io
And, yes, I changed the default branch for github pages generator too. So the 
blog should work correctly.


--
Miroslav Suchy, RHCA
Red Hat, Associate Manager, Community Packaging Tools, #brno, #fedora-buildsys
___
copr-devel mailing list -- copr-devel@lists.fedorahosted.org
To unsubscribe send an email to copr-devel-le...@lists.fedorahosted.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedorahosted.org/archives/list/copr-devel@lists.fedorahosted.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: Please raise build time limit for Chromium again

[Miroslav Suchý]

Dne 02. 03. 21 v 17:26 Sérgio Basto napsal(a):

hum IMHO should be available on general settings . for example when we want 
build kernels


This is question of balance. Nearly all knobs can be sometimes useful in Project settings, chroot settings, package 
settings, build settings.
Having them on all places would be UI nightmare. I am open to discussion, but we have to consider other projects and 
other users as well. Moving settings here and there is dead way.


--
Miroslav Suchy, RHCA
Red Hat, Associate Manager, Community Packaging Tools, #brno, #fedora-buildsys
___
copr-devel mailing list -- copr-devel@lists.fedorahosted.org
To unsubscribe send an email to copr-devel-le...@lists.fedorahosted.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedorahosted.org/archives/list/copr-devel@lists.fedorahosted.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Removing old tar-balls

[Miroslav Suchý]

We are running low on copr-dist-git storage.

I run `remove_unused_sources`, which removes all tar-balls from lookaside-cache but the latest ones referenced in 
`sources` (in any branch).


The script is running now. And is going to run for several hours.

The consequence is that hitting "resubmit" button for some olders builds may fail. In this case, please resubmit the 
whole src.rpm again.


--
Miroslav Suchy, RHCA
Red Hat, Associate Manager, Community Packaging Tools, #brno, #fedora-buildsys
___
copr-devel mailing list -- copr-devel@lists.fedorahosted.org
To unsubscribe send an email to copr-devel-le...@lists.fedorahosted.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedorahosted.org/archives/list/copr-devel@lists.fedorahosted.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: Order of External Repositories matters?

[Miroslav Suchý]

Dne 11. 02. 21 v 16:59 Miro Hrončok napsal(a):

I guess this has to do with either mock or dnf directly:

$ mock -r fedora-rawhide-x86_64 -a 
'https://copr-be.cloud.fedoraproject.org/results/@python/python3.10/fedora-rawhide-$basearch/' -a 
'http://kojipkgs.fedoraproject.org/repos/rawhide/latest/$basearch/' install python3-setuptools


$ mock -r fedora-rawhide-x86_64 -a 'http://kojipkgs.fedoraproject.org/repos/rawhide/latest/$basearch/' -a 
'https://copr-be.cloud.fedoraproject.org/results/@python/python3.10/fedora-rawhide-$basearch/' install python3-setuptools



Yes, this is what Copr do. And Mock just write it down to .repo file. So it stems down to: does order of repositories 
matter for DNF?


--
Miroslav Suchy, RHCA
Red Hat, Associate Manager, Community Packaging Tools, #brno, #fedora-buildsys
___
copr-devel mailing list -- copr-devel@lists.fedorahosted.org
To unsubscribe send an email to copr-devel-le...@lists.fedorahosted.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedorahosted.org/archives/list/copr-devel@lists.fedorahosted.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: Flooding COPR with "useless" builds, how big of a problem it is?

[Miroslav Suchý]

Dne 08. 12. 20 v 15:09 Pavel Raiskup napsal(a):
> Historically, but currently Fedora Copr scales pretty well.  The major
> concern is storage, so preferably all the projects should be removed
> after some time, not stored indefinitely.

Copr project has a field:
  Delete after days:
This would be nice to set to some value.  Otherwise it will hang there for cca 
400 day.

-- 
Miroslav Suchy, RHCA
Red Hat, Associate Manager ABRT/Copr, #brno, #fedora-buildsys
___
copr-devel mailing list -- copr-devel@lists.fedorahosted.org
To unsubscribe send an email to copr-devel-le...@lists.fedorahosted.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedorahosted.org/archives/list/copr-devel@lists.fedorahosted.org

copr-fe.cloud.f.o dns removed

[Miroslav Suchý]

FYI
I just removed the DNS entry
  copr-fe.cloud.fedoraproject.org
This should not be used for long time. The SSL was not even configured for this 
domain.

If you used that by any chance, please change your bookmark to
  https://copr.fedorainfracloud.org/

-- 
Miroslav Suchy, RHCA
Red Hat, Associate Manager ABRT/Copr, #brno, #fedora-buildsys
___
copr-devel mailing list -- copr-devel@lists.fedorahosted.org
To unsubscribe send an email to copr-devel-le...@lists.fedorahosted.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedorahosted.org/archives/list/copr-devel@lists.fedorahosted.org

Fwd: Legal flag raised on fdk-aac

[Miroslav Suchý]

Hi Cykerway,
see the explanation below.
Your repo has been deleted (by some other admin).

Kind Regards
Miroslav Suchy


 Přeposlaná zpráva 
Předmět: Re: Legal flag raised on fdk-aac
Datum: Thu, 28 May 2020 21:24:44 +0200
Od: Nicolas Chauvet 
Komu: Miroslav Suchý 
Kopie: copr-devel@lists.fedorahosted.org

Le jeu. 28 mai 2020 à 20:06, Miroslav Suchý  a écrit :
>
> Dne 28. 05. 20 v 9:42 r...@copr-fe.aws.fedoraproject.org napsal(a):
> >
> > Navigate to https://copr.fedorainfracloud.org/admin/legal-flag/
> > Contact on owner is: cykerway 
> > Reported by kwizart 
> >
>
> I believe that fdk-aac is OK. I already discussed about this on:
> https://unix.stackexchange.com/questions/588443/use-copr-with-rpmfusion-nonfree-packages/588543?noredirect=1#comment1098456_588543
>
> And see the last comment which points:
> https://lists.fedoraproject.org/archives/list/de...@lists.fedoraproject.org/thread/F64JBJI2IZFT2A5QDXGHNMPALCQIVJAX/

Hello Miroslav,

This is the modified version (I would defined as "less patented") that
was accepted in fedora. Here is the full unmodified (full of patents)
version.
Also both  modified (fdk-aac-free) and unmodified version are known to
remain GPL incompatible. (so cannot be used with GPL built FFmpeg).
This is also mentioned in the FSF
https://www.gnu.org/licenses/license-list.en.html#fdk

There is an internal AAC encoder(/decoder) is FFMpeg, so many users
believe they need it. But in most use-case they can use the internal
one instead.

Thanks


-- 
-

Nicolas (kwizart)
___
copr-devel mailing list -- copr-devel@lists.fedorahosted.org
To unsubscribe send an email to copr-devel-le...@lists.fedorahosted.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedorahosted.org/archives/list/copr-devel@lists.fedorahosted.org

Re: Legal flag raised on fdk-aac

[Miroslav Suchý]

Dne 28. 05. 20 v 9:42 r...@copr-fe.aws.fedoraproject.org napsal(a):
> 
> Navigate to https://copr.fedorainfracloud.org/admin/legal-flag/
> Contact on owner is: cykerway 
> Reported by kwizart 
> 

I believe that fdk-aac is OK. I already discussed about this on:
https://unix.stackexchange.com/questions/588443/use-copr-with-rpmfusion-nonfree-packages/588543?noredirect=1#comment1098456_588543

And see the last comment which points:
https://lists.fedoraproject.org/archives/list/de...@lists.fedoraproject.org/thread/F64JBJI2IZFT2A5QDXGHNMPALCQIVJAX/

-- 
Miroslav Suchy, RHCA
Red Hat, Associate Manager ABRT/Copr, #brno, #fedora-buildsys
___
copr-devel mailing list -- copr-devel@lists.fedorahosted.org
To unsubscribe send an email to copr-devel-le...@lists.fedorahosted.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedorahosted.org/archives/list/copr-devel@lists.fedorahosted.org

Fwd: Bulk deleting builds - RFC

[Miroslav Suchý]

FYI
I sent this email to several users, who has most build in Copr.
Anyone else is free to comment as well.
M.


 Přeposlaná zpráva 
Předmět: Bulk deleting builds - RFC

Hi,
I am writing you because you are submitting a lot of builds to Copr and I would 
like to get your opinion about one feature.

Deleting a build.
As you probably already know, when you delete a build, we have to run 
createrepo_c, which can take a lot of time when
you run it after each deleted build.
When you delete builds in webUI, backend deletes a build in one bulk and run 
createrepo_c in one step and runs
createrepo_c only once. But... this will not work when you delete builds one by 
one in webUI. And the bulk delete cannot
be done using copr-cli or API. So...

We are thinking about two options:

1) Implement copr-cli bulk-delete-build. Technically it can be either:
   a) copr-cli delete-build $build-id $build-id $build-id
   or
   b) copr-cli bulk-delete-build $build-id $build-id $build-id
   But
 copr-cli delete-build $build-id
 copr-cli delete-build $build-id
   will still create two independent actions.
   Pros:
   * You have control over the delete process. You know when bulk-delete will 
be used.
   Cons:
   * It will not work when you do something like:
 for build in *; do 
copr-cli delete-build $build
 done
   * You have to remember yet another option/command.

2) Group build delete on frontend
   When backend asks frontend for pending task and the task is "delete a 
build", frontend will check if there are some
other builds to be deleted from the same project and create bulk-delete action 
on the fly from those pending deletes.
   Pros:
   * No need to change API or copr-cli.
   * It will work even when you delete build in webUI one by one.
   Cons:
   * You have no control when batch-delete is used. Hmm, is this a problem at 
all? Is there any use-case when you really
want to delete build one-by-one?
   * It is not optimal. E.g. when you run:
 for build in *; do 
copr-cli delete-build $build
 done
 and request to delete 10 000 builds, it can take e.g. 10 minutes to submit 
those action. And backend query frontend
every minute. So backend will pick-up first 100 builds as bulk-delete. Then it 
will take 2 minutes to proceed. In the
mean time another 2000 deleted-builds accrue. So backend will delete 2000 
builds. It will take 8 minutes to proceed. And
then backend pick up the remaining 7900 builds.
 So instead of one action, it will be splitted into several actions.
 Still better than 10k individual action, but worse than one action.

I will appreciate your feedback.


-- 
Miroslav Suchy, RHCA
Red Hat, Associate Manager ABRT/Copr, #brno, #fedora-buildsys
___
copr-devel mailing list -- copr-devel@lists.fedorahosted.org
To unsubscribe send an email to copr-devel-le...@lists.fedorahosted.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedorahosted.org/archives/list/copr-devel@lists.fedorahosted.org

Copr outage - details

[Miroslav Suchý]

tl;dr: On Sunday 23rd February, there will be Copr outage. It will last the 
whole day.
PPC64LE builder and chroots will be deactivated. The PPC64LE builders should be 
back in a matter of weeks.

Hi.
As previously announced, Fedora's infrastructure is moving to a different 
datacenter. For some servers, the move is
trivial. Copr servers are different. Copr build system consists of four 
servers, plus four staging servers. Eight TB of
repos, four TB of dist-git, and several small volumes.

The original plan was to move to Washington D.C. to IAD2 datacenter by June.  
Copr is running in Fedora OpenStack, and
this cloud has to be evacuated by the beginning of March to free an IP range.
The plan was to move Copr to new hardware (thanks to Red Hat) and later move 
this HW to the new datacenter.  That would
mean two outages, where the second one lasted at least 15 days (!).

We were looking for another option and we found it. We are going to move Copr 
to Amazon AWS, shutdown old VM on Fedora
Cloud. Move the new HW to IAD2 datacenter and then move Copr from AWS to new HW 
in IAD2 - FYI, the final destination is
still subject to change. This still means two outages, but they should be just 
a few hours. And web server with DNF
repositories should be available all the time.
The second outage, will happen in May or June.

Here is a detailed schedule. We are going to update this table during 
migration. You can watch the progress during
migration:

https://docs.google.com/spreadsheets/d/1jrCgdhseZwi91CTRlo9Y5DNwfl9VHoZfjHPK_pocuf4/edit?usp=sharing

Here is a short abstract:

 * we are doing constant rsync to the new location
 * we spin up staging and production instances in the new location
 * on Sunday morning we stop frontend and therefore accepting new jobs. The 
backend with DNF repos will still be
operational.
 * we do final rsync (~6 hours)
 * around 13:00 UTC we switch DNS to the new location
 * we then enable all services
 * once we confirm that everything is operational, the outage will be over

There are several caveats:

 * After we enable services on Sunday 13:00 UTC you may see some failures. Be 
asured that we will swiftly address them.
 * Once we get out of Fedora Cloud, we lost access to PPC64LE builders. We are 
going to deactivate those chroots just
before the migration. After a few weeks, we should get it back. ETA is unknown. 
The worst-case scenario is in June 2020.
We will be aiming to bring it back as soon as possible.
 * Any small issue can easily change the schedule by hours. E.g., just simple 
'chown -R' on backend runs ~4 hours.

There are going to be three Copr engineers and one fedora-infrastructure member 
available whole Sunday. If you
experienced a problem, do not hesitate to contact us. We are on 
#fedora-buildsys on Freenode.

The link to the outage ticket is:
https://pagure.io/fedora-infrastructure/issue/8668

-- 
Miroslav Suchy, RHCARed Hat, Associate Manager ABRT/Copr, #brno, 
#fedora-buildsys
___
copr-devel mailing list -- copr-devel@lists.fedorahosted.org
To unsubscribe send an email to copr-devel-le...@lists.fedorahosted.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedorahosted.org/archives/list/copr-devel@lists.fedorahosted.org

Copr outage - moving to new datacenter

[Miroslav Suchý]

FYI, the Copr servers have to move to the new data center by the end of this 
month. That will include a physical move.
In a truck.

In the worst-case scenario, it will mean at least 15 days outage.

Right now, the whole Copr team + some fedora-infrastructure guys are working on 
this task. We are trying several
approaches on how to handle the migration. I would love to see as small outage 
as possible. But it seems that at least
one-day outage is inevitable.

To get you the picture, the migration includes copying 8TB of repositories and 
more than one TB of dist-git data - which
is all in small files. Painfull to copy using a standard method.

As soon as we have an exact date and a precise duration of the outage, I will 
let you know.
-- 
Miroslav Suchy, RHCA
Red Hat, Associate Manager ABRT/Copr, #brno, #fedora-buildsys
___
copr-devel mailing list -- copr-devel@lists.fedorahosted.org
To unsubscribe send an email to copr-devel-le...@lists.fedorahosted.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedorahosted.org/archives/list/copr-devel@lists.fedorahosted.org

Re: Proxies for Copr repositories

[Miroslav Suchý]

Dne 09. 02. 20 v 22:17 Iñaki Ucar napsal(a):
> On Tue, 4 Feb 2020 at 10:03, Miroslav Suchý  wrote:
>>
>> Hi,
>> I just enabled the content delivery network (CDN) for Copr repositories.
>> It is provided by CloudFront from AWS. And it is provided for free by Amazon 
>> to Fedora.
>>
>> Technically the original URL
>>   copr-be.cloud.fedoraproject.org
>> is now accessible using
>>   download.copr.fedorainfracloud.org
>>
>> The original URL is and will be available. You can still use it. The second 
>> one is CNAME for the CDN and should be much
>> faster for you.
> 
> Awesome. Do the "packages downloaded" and "repo download" counters in
> the overview page reflect the numbers from the CDN too?

Repos - yes, it will work without a change.

Packages - hmm, no.
Well. It will show some numbers. But all access to the same package per day 
will be counted as one access.

I will track it as
  https://pagure.io/copr/copr/issue/1263
but it will has lower priority.

-- 
Miroslav Suchy, RHCA
Red Hat, Associate Manager ABRT/Copr, #brno, #fedora-buildsys
___
copr-devel mailing list -- copr-devel@lists.fedorahosted.org
To unsubscribe send an email to copr-devel-le...@lists.fedorahosted.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedorahosted.org/archives/list/copr-devel@lists.fedorahosted.org

Proxies for Copr repositories

[Miroslav Suchý]

Hi,
I just enabled the content delivery network (CDN) for Copr repositories.
It is provided by CloudFront from AWS. And it is provided for free by Amazon to 
Fedora.

Technically the original URL
  copr-be.cloud.fedoraproject.org
is now accessible using
  download.copr.fedorainfracloud.org

The original URL is and will be available. You can still use it. The second one 
is CNAME for the CDN and should be much
faster for you.

The CDN is automatically enabled for new projects. Thou, if you already have 
enabled some copr repository on your
workstation/server, it will still use the old URL.
It is fine; it will continue to work.
If you want to enable CDN for your repos you have to run:
  dnf copr remove some/project
  dnf copr enable some/project
or manually change the URL in the repo file.

If you experience any problem with CDN, please let me know.

-- 
Miroslav Suchy, RHCA
Red Hat, Associate Manager ABRT/Copr, #brno, #fedora-buildsys
___
copr-devel mailing list -- copr-devel@lists.fedorahosted.org
To unsubscribe send an email to copr-devel-le...@lists.fedorahosted.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedorahosted.org/archives/list/copr-devel@lists.fedorahosted.org

Re: Automated builds possible?

[Miroslav Suchý]

Dne 09. 01. 20 v 16:17 Richard Shaw napsal(a):
> I just had a thought and wondered if it were possible.
> 
> I have an upstream that posts alpha and beta releases to a specific URL.
> 
> What I'd like copr (or something) to do is:
> 1. Monitor those URLs so it knows when a new alpha is pushed
> 2. Pull the spec file from fedora rawhide (master)
> 3. Run rpmdev-bumpspec -n  -c "Update to ." 
> 4. Create a build in my COPR project using the new source.
> 
> Is this possible?

You are descibing rebase-helper:
  https://developer.fedoraproject.org/deployment/maintain/rebase-helper.html
integrated with upstream-monitoring:
  
https://developer.fedoraproject.org/deployment/maintain/rebase-helper-integration.html

This works right now. When you register to release-monitoring.org and new 
release is out, then you will get BZ report
stating that new release is out and there is linked build with bumped version 
and with new sources.


-- 
Miroslav Suchy, RHCA
Red Hat, Associate Manager ABRT/Copr, #brno, #fedora-buildsys
___
copr-devel mailing list -- copr-devel@lists.fedorahosted.org
To unsubscribe send an email to copr-devel-le...@lists.fedorahosted.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedorahosted.org/archives/list/copr-devel@lists.fedorahosted.org

Fwd: ** PROBLEM alert - copr-fe.cloud.fedoraproject.org/Disk Space /boot is WARNING **

[Miroslav Suchý]

Pavel or Jakub,
can you please check this up?

M.


 Přeposlaná zpráva 
Předmět: ** PROBLEM alert - copr-fe.cloud.fedoraproject.org/Disk Space /boot is 
WARNING **
Datum: Mon, 06 Jan 2020 05:20:39 +

* Nagios  *

Notification Type: PROBLEM

Service: Disk Space /boot
Host: copr-fe.cloud.fedoraproject.org
Address: copr-fe.cloud.fedoraproject.org
State: WARNING
Source: noc01.phx2.fedoraproject.org

Date/Time: Mon Jan 6 05:20:39 UTC 2020

Additional Info:

DISK WARNING - free space: / 7614 MB (19.74% inode=97%):
___
copr-devel mailing list -- copr-devel@lists.fedorahosted.org
To unsubscribe send an email to copr-devel-le...@lists.fedorahosted.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedorahosted.org/archives/list/copr-devel@lists.fedorahosted.org

Re: COPR specific macros?

[Miroslav Suchý]

Dne 04. 12. 19 v 15:23 Richard Shaw napsal(a):
> Is there a macro available that evaluates to TRUE/1 when building in COPR?

There are defined:
  %copr_username
  %copr_projectname
macros. They are set to user name and to project name.


-- 
Miroslav Suchy, RHCA
Red Hat, Associate Manager ABRT/Copr, #brno, #fedora-buildsys
___
copr-devel mailing list -- copr-devel@lists.fedorahosted.org
To unsubscribe send an email to copr-devel-le...@lists.fedorahosted.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedorahosted.org/archives/list/copr-devel@lists.fedorahosted.org

Re: copr builders moved to F31, with more builders

[Miroslav Suchý]

Dne 04. 12. 19 v 11:03 Pavel Raiskup napsal(a):
> multiple createrepo_c processes concurrently on single project, and thus
> all of the builders are waiting..  there is possible to do several
> improvements.  This issue has our priority now.

To be specific: we identified two ways how to improve speed of createrepo_c for 
large project. And we are working on
contributing directly to createrepo_c upstream.

One PR has been already sent, the other is on the way. Preliminary discussed 
with upstream maintainer.

-- 
Miroslav Suchy, RHCA
Red Hat, Associate Manager ABRT/Copr, #brno, #fedora-buildsys
___
copr-devel mailing list -- copr-devel@lists.fedorahosted.org
To unsubscribe send an email to copr-devel-le...@lists.fedorahosted.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedorahosted.org/archives/list/copr-devel@lists.fedorahosted.org

Fwd: [CentOS-devel] CentOS Stream enabled in Copr

[Miroslav Suchý]

 Přeposlaná zpráva 
Předmět: [CentOS-devel] CentOS Stream enabled in Copr
Datum: Tue, 15 Oct 2019 14:33:34 +0200
Od: Miroslav Suchý 
Komu: The CentOS developers mailing list. 

Hi.
FYI - I just added
  centos-stream-x86_64
  centos-stream-aarch64
  centos-stream-ppc64le
to https://copr.fedorainfracloud.org/
You can build your packages for these chroots now.
--
Miroslav Suchy, RHCA
Red Hat, Associate Manager ABRT/Copr, #brno, #fedora-buildsys
___
CentOS-devel mailing list
centos-de...@centos.org
https://lists.centos.org/mailman/listinfo/centos-devel
___
copr-devel mailing list -- copr-devel@lists.fedorahosted.org
To unsubscribe send an email to copr-devel-le...@lists.fedorahosted.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedorahosted.org/archives/list/copr-devel@lists.fedorahosted.org

Re: Does copr git support lfs?

[Miroslav Suchý]

Dne 13. 10. 19 v 23:18 z...@softvisio.net napsal(a):

I have git repo, that contains .spec file and .tar.gz archive with the
sources. .tar.gz commited to git as lfs object.

Seems, that currently copr build system can't clone git with lfs files
correctly?


Right. But you can use:
  https://docs.pagure.org/copr.copr/user_documentation.html#custom-script

--
Miroslav Suchy, RHCA
Red Hat, Associate Manager ABRT/Copr, #brno, #fedora-buildsys
___
copr-devel mailing list -- copr-devel@lists.fedorahosted.org
To unsubscribe send an email to copr-devel-le...@lists.fedorahosted.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedorahosted.org/archives/list/copr-devel@lists.fedorahosted.org

Re: Hardlinked files

[Miroslav Suchý]

Dne 05. 09. 19 v 17:09 Pavel Raiskup napsal(a):
> Hm, this is weird.  From what I can tell, there should be only 3 (log) files 
> in
> that directories (or Nx3 files).  What exactly is linkable there?


Hmm, this was just mistake cause by formating of output. My fault.

>> 2) srpm_build/ - it has the same tar ball for resubmits
> Weird as well, there shouldn't be tarballs but source RPMs, and since we don't
> have reproducible builds - those files shouldn't be linkable.

# pwd
/var/lib/copr/public_html/results/@python/python3.8/srpm-builds
[root@copr-be srpm-builds][PROD]# find -name astrometry-data-4206.tar.xz |head
./00953171/astrometry-data-4206.tar.xz
./00955002/astrometry-data-4206.tar.xz
./00953380/astrometry-data-4206.tar.xz
./00963734/astrometry-data-4206.tar.xz
./00951719/astrometry-data-4206.tar.xz
./00951765/astrometry-data-4206.tar.xz
./00951697/astrometry-data-4206.tar.xz
./00951952/astrometry-data-4206.tar.xz
./00951709/astrometry-data-4206.tar.xz
./00952065/astrometry-data-4206.tar.xz


-- 
Miroslav Suchy, RHCA
Red Hat, Associate Manager ABRT/Copr, #brno, #fedora-buildsys
___
copr-devel mailing list -- copr-devel@lists.fedorahosted.org
To unsubscribe send an email to copr-devel-le...@lists.fedorahosted.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedorahosted.org/archives/list/copr-devel@lists.fedorahosted.org

Hardlinked files

[Miroslav Suchý]

Hi.
The hardlink task finished. For the record, this is what I run:

cd /var/lib/copr/public_html/results
for i in *; do pushd "$i" && for ii in *; do hardlink -vv "$ii"; done; popd 
>/dev/null; done

It run for more than two days. :)

As I watched the build most saved space come from:
1) chroot_scan/ - same libsolv and dnf logs for the same build in the same day
2) srpm_build/ - it has the same tar ball for resubmits

FYI we are now at
Filesystem  Size  Used Avail Use% Mounted on
/dev/vdc1   7.5T  5.7T  1.9T  76% /var/lib/copr/public_html

-- 
Miroslav Suchy, RHCA
Red Hat, Associate Manager ABRT/Copr, #brno, #fedora-buildsys
___
copr-devel mailing list -- copr-devel@lists.fedorahosted.org
To unsubscribe send an email to copr-devel-le...@lists.fedorahosted.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedorahosted.org/archives/list/copr-devel@lists.fedorahosted.org

Re: Legal flag raised on rpm-gitoverlay-1556488700.270103

[Miroslav Suchý]

Dne 29. 04. 19 v 0:39 r...@copr-fe.cloud.fedoraproject.org napsal(a):
> rpmsoftwaremanagement generates dozens of empty projects.
> It doesn't seem normal, more like some bot goes crazy.
> Contact on owner is: rpmsoftwaremanagement 
> Reported by zawertun 
> 

It is fine. They are creating new project for every pull request and as far I 
can see, they really build something into
those projects.
I spoke to them some time ago and I asked them to tick the "Hide from front 
page". They promised to do, but it will need
some time.

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

Re: IOError: Failed to write to /tmp/numpy_test_big_arrays....npy: [Errno 28] No space left on device

[Miroslav Suchý]

Dne 21. 03. 19 v 11:09 Miro Hrončok napsal(a):
> I just got this error in Copr.
> 
> Should I skip big_arrays tests, or is this some quota on /tmp that can be 
> enlarged?
> 
> Thanks.


On our builders the chroot directory (including /tmp in that chroot) is created 
as tmpfs:
 mock_chroot_tmpfs   81G  637M   80G   1% 
/var/lib/mock/881782-fedora-30-x86_64-bootstrap-1554975485.024796/root

It is 80 GB . Usually less than 2GB is used by Fedora distribution files. Rest 
can be used by builders. While it can
technically be enlarged (swap files is 100GB), I think 78 GB should be enough 
for anybody :) You are the first one who
reached the limits.

Are you really creating sooo big files?

Can the culprit be that you do not remove those files so conseqentive build can 
get the same VM (not reprovisioned if
previous build was yours as well) and there are leftovers from your previous 
build in /tmp so you reach the limit?


Miroslav

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

Re: pruning srpm-builds

[Miroslav Suchý]

For the record - I executed:

# cat /tmp/p
set -e
cd /var/lib/copr/public_html/results
for i in  */*/srpm-builds/; do
  pushd "$i" >/dev/null
  echo "Purging $PWD"
  find ./  -mtime +14 -type f| xargs --no-run-if-empty rm
  cd ..
  find srpm-builds/ -empty -type d |xargs --no-run-if-empty rmdir
  popd >/dev/null
done

Free disk space went up from
  225G
to
  909G
.

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

Fwd: RHEL8 and Mageia7 available in Copr

[Miroslav Suchý]

FYI:
I run:
bash-4.4$ copr-frontend create_chroot mageia-7-i586 mageia-7-x86_64
bash-4.4$ copr-frontend create_chroot rhelbeta-8-x86_64
on copr-fe.

Miroslav


 Přeposlaná zpráva 
Předmět: RHEL8 and Mageia7 available in Copr
Datum: Mon, 11 Mar 2019 12:04:30 +0100
Od: Miroslav Suchý 
Společnost: Red Hat, Registered Address: Red Hat Czech s.r.o., Purkynova 99/71, 
612 45 Brno, Czech Republic, Registered
in Brno under identification number CZ27690016
Komu: Development discussions related to Fedora 

Hi,
I just added those chroots to Copr:
  rhelbeta-8-x86_64
  mageia-7-i586
  mageia-7-x86_64

Please be aware that there is no available EPEL for rhelbeta-8-x86_64 yet. This 
chroot is intended for some initial
bootstraping and testing prior RHEL 8 release and it will be removed from Copr 
once RHEL 8 - or to be precise CentOS 8 -
will be released.

Before you ask - the F30 will be added in upcoming hours.

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

Re: Rawhide buildroot broken: GPG problem

[Miroslav Suchý]

Dne 08. 03. 19 v 13:11 Miro Hrončok napsal(a):
> https://copr.fedorainfracloud.org/coprs/g/python/python3.8/build/865744/
> 
> DEBUG util.py:554:  BUILDSTDERR: warning:
> /var/lib/mock/865744-fedora-rawhide-x86_64-1552046861.342034/root/var/cache/dnf/fedora-2d95c80a1fa0a67d/packages/shadow-utils-4.6-8.fc30.x86_64.rpm:
> Header V3 RSA/SHA256 Signature, key ID 3c3359c4: NOKEY
> DEBUG util.py:554:  BUILDSTDERR: Importing GPG key 0xCFC659B9:
> DEBUG util.py:554:  BUILDSTDERR:  Userid : "Fedora (30) 
> "
> DEBUG util.py:554:  BUILDSTDERR:  Fingerprint: F1D8 EC98 F241 AAF2 0DF6 9420 
> EF3C 111F CFC6 59B9
> DEBUG util.py:554:  BUILDSTDERR:  From   : 
> /usr/share/distribution-gpg-keys/fedora/RPM-GPG-KEY-fedora-30-primary
> DEBUG util.py:556:  Key imported successfully
> DEBUG util.py:554:  BUILDSTDERR: Importing GPG key 0x429476B4:
> DEBUG util.py:554:  BUILDSTDERR:  Userid : "Fedora 29 (29) 
> "
> DEBUG util.py:554:  BUILDSTDERR:  Fingerprint: 5A03 B4DD 8254 ECA0 2FDA 1637 
> A20A A56B 4294 76B4
> DEBUG util.py:554:  BUILDSTDERR:  From   : 
> /usr/share/distribution-gpg-keys/fedora/RPM-GPG-KEY-fedora-29-primary
> DEBUG util.py:556:  Key imported successfully
> DEBUG util.py:556:  Import of key(s) didn't help, wrong key(s)?
> DEBUG util.py:554:  BUILDSTDERR: Public key for 
> shadow-utils-4.6-8.fc30.x86_64.rpm is not installed. Failing package is:
> shadow-utils-2:4.6-8.fc30.x86_64
> DEBUG util.py:554:  BUILDSTDERR:  GPG Keys are configured as:
> file:///usr/share/distribution-gpg-keys/fedora/RPM-GPG-KEY-fedora-30-primary,
> file:///usr/share/distribution-gpg-keys/fedora/RPM-GPG-KEY-fedora-29-primary
> DEBUG util.py:554:  BUILDSTDERR: Public key for 
> diffutils-3.7-2.fc30.x86_64.rpm is not installed. Failing package is:
> diffutils-3.7-2.fc30.x86_64
> 
> ...snip...
> 
> DEBUG util.py:554:  BUILDSTDERR:  GPG Keys are configured as:
> file:///usr/share/distribution-gpg-keys/fedora/RPM-GPG-KEY-fedora-30-primary,
> file:///usr/share/distribution-gpg-keys/fedora/RPM-GPG-KEY-fedora-29-primary
> DEBUG util.py:554:  BUILDSTDERR: Error: GPG check FAILED
> 

Should be fixed by:

https://infrastructure.fedoraproject.org/cgit/ansible.git/commit/?id=4659d4ae7d4d0716de832a86027ab96ff5ec4d6b

It may take some time to propagate to builders as it is AFAIK applied to only 
newly spin-up builders.

Thank you for reporting.

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

Re: pruning srpm-builds

[Miroslav Suchý]

Dne 08. 03. 19 v 9:21 Pavel Raiskup napsal(a):
>  
> Will the limit for command-line lenght suffice (execve)? :-)

It worked for 'du' - yes, it will be sufficient.

>> The only cons I see is that links from build page to builder-live.log
>> will be broken. ... hmm, they are already broken - likely some other
>> bug. So I see no cons :)
> This is actually not truth, at least not for builds I tried.  Worth
> submitting a bug report...

It is broken for build from October.
Hmm. I can only limit the deletion to build older than few weeks.

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

pruning srpm-builds

[Miroslav Suchý]

I was thinking where to reclaim storage space so we can add Fedora 30 and I 
checked the srpm-builds directory, which
Dominik mentioned during last meeting and the total sum is:

[root@copr-be results][PROD]# du -shc */*/srpm-builds
697Gtotal

and it contains very old build - so current prunerepo definitely skips it.

Unless you raise your voice by end of week, I will run on Monday:

rm -rf /var/lib/copr/public_html/results/*/*/srpm-builds/*

The only cons I see is that links from build page to builder-live.log will be 
broken. ... hmm, they are already broken -
likely some other bug. So I see no cons :)

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

Fwd: python3-configparser is going away, update packages please

[Miroslav Suchý]

FYI
I have prepared commit, but I am waiting untill 
https://pagure.io/copr/copr/pull-request/526 is merged, because it has
conflicts.
Miroslav


 Přeposlaná zpráva 
Předmět:python3-configparser is going away, update packages please
Datum:  Fri, 8 Feb 2019 06:05:08 -0500
Od: Avram Lubkin 
Komu:   copr-backend-ow...@fedoraproject.org, 
copr-rpmbuild-ow...@fedoraproject.org,
graphite-web-ow...@fedoraproject.org, python3-carbon-ow...@fedoraproject.org, 
python3-copr-ow...@fedoraproject.org,
python3-libtaskotron-ow...@fedoraproject.org, 
python3-x2go-ow...@fedoraproject.org, rpkg-ow...@fedoraproject.org
Kopie:  jama...@fc.up.pt, ita...@ispbrasil.com.br




The following packages currently require python3-configparser. Since 
configparser is included in the standard library it
really shouldn't exist. python-configparser will go away completely once no 
python2 packages depend on it, but we'll
likely drop the python3-configparser package with the next update which should 
be coming out relatively soon.

The following packages currently have a dependency on pthon3-configparser. 
Please update your package to remove this
dependency.

copr-backend (F29, Rawhide)
copr-rpmbuild(F29, Rawhide)
graphite-web(F29, Rawhide)
python3-carbon(F29, Rawhide)
python3-copr(F29, Rawhide)
python3-libtaskotron(F29, Rawhide)
python3-x2go(F29, Rawhide)
rpkg(F29, Rawhide)
sagemath(Rawhide)

Thanks,

Avram

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

EOL Fedora 27

[Miroslav Suchý]

Hi,
I just EOLed fedora-27-* in Fedora's Copr instance.

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

Re: Long jobs/big queues

[Miroslav Suchý]

Dne 30. 01. 19 v 12:22 harbottle napsal(a):
> Is there a way that long-running jobs (I'm thinking kernel, gcc etc) can be 
> assigned to their own dedicated build
> servers? The packages I build are usually quick (a few minutes) but they 
> sometimes have to wait a long time for these
> longer jobs to finish.

Currently one user can build only 6 concurent builds at the same time. So 
someone submit 60 kernels it will not eat
whole pool and you should build your small packages.
If *you* submit 60 kernel and at the same time you want to build some small 
package in mean time, then you can lowe
priority of those long running jobs (before you submit them):

  copr build --background kernel.src.rpm

> Failing that, is there a way to spin-up a private build server tied to my 
> project?

Nope. There are some talk around this idea, but it was never implemented.

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

Re: ccached builds

[Miroslav Suchý]

Dne 15.10.2018 v 12:46 Pavel Raiskup napsal(a):
> the design of copr build system isn't really ready to have this
> implemented, namely for storing the caches.  The builder machines (which
> do the mock build) are freshly started VMs.

+1
Additionally using ccache on shared system is security problem as you can 
easily alter the cache for some other user.

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

Fwd: copr-be's storage

[Miroslav Suchý]

FYI, I just added 1TB to copr-be storage using this old receipt.
This mean that we consumed 2TB in less than one year!
Miroslav

 Přeposlaná zpráva 
Předmět: copr-be's storage
Datum: Wed, 20 Dec 2017 08:55:38 +0100
Od: Miroslav Suchý 
Adresa pro odpověď: Community Projects 
Společnost: Red Hat, Registered Address: Red Hat Czech s.r.o., Purkynova 99/71, 
612 45 Brno, Czech Republic, Registered
in Brno under identification number CZ27690016
Komu: copr-devel@lists.fedorahosted.org

FYI
I just resized copr-be storage for DNF repos from 4TB to 6TB.

It was as easy as:

umount /var/lib/copr/public_html
systemctl stop var-lib-copr-public_html.mount
copr-backend-service stop
systemctls stop lighttpd.service

in openstack dashboard, detach the volume, click "enlarge volume", set it to 
6000GB.
attach it back.

Again:
umount /var/lib/copr/public_html
systemctl stop var-lib-copr-public_html.mount
parted
  (parted) print free
  Number  Start   End SizeFile system  Name  Flags
  17.4kB  1049kB  1031kB  Free Space
   1  1049kB  4398GB  4398GB  ext4
  4398GB  6442GB  2044GB  Free Space
  (parted) resizepart
  Partition number? 1
  End?  [4398GB]? 6442GB
resize2fs /dev/vdc1
systemctl start var-lib-copr-public_html.mount
systemctls start lighttpd.service
copr-backend-service start

# df -H /var/lib/copr/public_html
Filesystem  Size  Used Avail Use% Mounted on
/dev/vdc1   6.4T  4.2T  2.3T  65% /var/lib/copr/public_html

Mirek
___
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
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedorahosted.org/archives/list/copr-devel@lists.fedorahosted.org

feedback about new messaging

[Miroslav Suchý]

I just got a feedback about upcoming rewrite of our fedmsg.
MKluson come in person and stated that he need a message about successful build 
and he need:

  build.id
  chroot_name

I am posting here just as note for whoever will work on this in near future.

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

ACL clean up

[Miroslav Suchý]

FYI:

I added praiskup to Copr pagure group.

I contacted asamlik about his intentions with Copr and based on that I removed 
him from pagure group, fedora infra
playbooks, and FAS group.

I wrote to all members of FAS group (gitcopr) and based on their intentions I 
removed so far: mizdebski, msrb.
I may remove other people as I get the reply from them in upcoming days.

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

Added F29 to @copr/copr

[Miroslav Suchý]

FYI
I added fedora-29 chroot to 
https://copr.fedorainfracloud.org/coprs/g/copr/copr/ and enabled 
follow-branching.
Miroslav
___
copr-devel mailing list -- copr-devel@lists.fedorahosted.org
To unsubscribe send an email to copr-devel-le...@lists.fedorahosted.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedorahosted.org/archives/list/copr-devel@lists.fedorahosted.org

Re: branches cleanup

[Miroslav Suchý]

Dne 17.8.2018 v 11:24 Miroslav Suchý napsal(a):
> We have lots of old branches. Here is the list:

PEBKAC. The branches are not there any more.

This:
  git fetch -p
will update branch list pruning the old ones.

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

branches cleanup

[Miroslav Suchý]

We have lots of old branches. Here is the list:


  origin/GDPR
  origin/ansible-2.x
  origin/api-mem-hotfix
  origin/api_search
  origin/arch-builder-groups
  origin/backend-appstream-fix
  origin/bkabrda-workspace
  origin/bootstrap-without-additional
  origin/build_chroot_with_started_on
  origin/builder_agent
  origin/bz1455249
  origin/chain-builds
  origin/check-root
  origin/copr-dist-git-python3
  origin/copr_rpmbuild_dump_configs
  origin/detect-ssh-issues
  origin/dist-git
  origin/dnf
  origin/enter_the_matrix
  origin/fedora-21
  origin/fix-python-docs
  origin/fork-1.96-hotfix
  origin/frontend-1.95-2
  origin/frontend-python3
  origin/gnupg-2.1
  origin/hotfix
  origin/hotfix_1188874
  origin/hotfix_1195867
  origin/hotfix_1203753
  origin/hotfixes-ruby
  origin/hotfixes-w29
  origin/hotfixes-w30
  origin/jkadlcik-devel
  origin/matrix
  origin/modularity
  origin/new
  origin/pagure_integration
  origin/pagure_integration_new
  origin/paralel-distgit
  origin/pkg-hotfix
  origin/python-client
  origin/python_copr_apiv2
  origin/queue_next
  origin/remove_logstash_conf
  origin/rest_api_2
  origin/rhbug_1194522
  origin/rpm-sign
  origin/rpmbuild-providers
  origin/search
  origin/search-by-package-name
  origin/skvidal-backend
  origin/source_status_added
  origin/unified-scm-method
  origin/unlisted-on-hp-copr_attr
  origin/unsign-function
  origin/wip/targets-for-builds

If you still need some of them, then please raise your voice. Otherwise I will 
delete them next week.

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

Automatic verification of software packages with help of DNS

[Miroslav Suchý]

FYI:
This is thesis on topic how to verify rpm signatures using DNSsec:
https://www.vutbr.cz/en/students/final-thesis?zp_id=110044&aid_redir=1

This is something I would love to pilot in Copr one day.

Despite few initial mandatory pages in Czech, the paper itself is in English.

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

Re: GitHub Apps

[Miroslav Suchý]

Dne 21.3.2018 v 12:28 Pavel Raiskup napsal(a):
> 4. store **only** the **app** credentials into copr

 Yes. Only one app for all projects and all githubs and individual permission 
for each specific Github is granted via OAuth.

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

GitHub Apps

[Miroslav Suchý]

During yesterday meeting I forgot to bring up the topic of GitHub apps.
During the preparation of
https://docs.google.com/forms/d/e/1FAIpQLSckxxUeAWKwUzjju6ftDjPeNWVWT_2_Y7mdpOrc8vMqRg_yxg/viewform?usp=sf_link

I stumbled upon

 https://developer.github.com/apps/getting-started-with-building-apps/

and according the graph, it is straightforward that we likely want to use 
GitHub App with OAuthApp, which is IMHO best
from security POV and both from developer and user perspective.

Comments?

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

Re: aarch64 copr?

[Miroslav Suchý]

Dne 7.2.2018 v 12:18 Avi Kivity napsal(a):
> Are there plans to add aarch64 copr support? If so, when can we expect it to 
> be live?

As soon as we get some builders. Which will be as soon as we get money for the 
builders.
I applied for some money for this year. I will know in 1-2 months whether we 
will get the money.
Otherwise I will try again next year and next year...

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

dm-vdo

[Miroslav Suchý]

I found this in Cockpit release notes. I did not knew about DM-VDO previously. 
Might be useful for us for hosting all
those repositories.



Configure data deduplication with VDO devices
-

The "Virtual Data Optimizer" is a new feature to eliminate duplication and add
compression to block devices. This is mostly aimed at providing storage for
virtual machines or object storage systems like Ceph.

This is being developed upstream by the dm-vdo GitHub project
(https://github.com/dm-vdo). It is currently available in RHEL 7.5 alpha
(https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/7/html/storage_administration_guide/vdo)
and expected to land in other distributions eventually.

Cockpit's Storage page can now create and configure VDO devices.

Video: https://www.youtube.com/watch?v=_iOYN4Y24aY


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

copr-be's storage

[Miroslav Suchý]

FYI
I just resized copr-be storage for DNF repos from 4TB to 6TB.

It was as easy as:

umount /var/lib/copr/public_html
systemctl stop var-lib-copr-public_html.mount
copr-backend-service stop
systemctls stop lighttpd.service

in openstack dashboard, detach the volume, click "enlarge volume", set it to 
6000GB.
attach it back.

Again:
umount /var/lib/copr/public_html
systemctl stop var-lib-copr-public_html.mount
parted
  (parted) print free
  Number  Start   End SizeFile system  Name  Flags
  17.4kB  1049kB  1031kB  Free Space
   1  1049kB  4398GB  4398GB  ext4
  4398GB  6442GB  2044GB  Free Space
  (parted) resizepart
  Partition number? 1
  End?  [4398GB]? 6442GB
resize2fs /dev/vdc1
systemctl start var-lib-copr-public_html.mount
systemctls start lighttpd.service
copr-backend-service start

# df -H /var/lib/copr/public_html
Filesystem  Size  Used Avail Use% Mounted on
/dev/vdc1   6.4T  4.2T  2.3T  65% /var/lib/copr/public_html

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

Re: duplicated lines

[Miroslav Suchý]

Dne 7.10.2017 v 16:55 Sérgio Basto napsal(a):
> All build.log.gz have all lines duplicated, since some time , can youfix it 
> please ?  thanks 
> 
> 

https://github.com/rpm-software-management/mock/issues/73

Patches are welcome.

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

CI projects in Copr

[Miroslav Suchý]

Hi,
I am gathering informations about various use of CI with Copr. Do you use Copr for building packages for nightlies? For 
building packages before pull request is merged? Do you have your set up described somewhere? What is the name of your 
project?


Please let me know. Either here or via private reply.
It will help me to understand your use of Copr and to make Copr better.

Thanks in advance.

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

Some Copr statistics

[Miroslav Suchý]

Copr popularity: Google search for string - number of results:
* OBS repository - 1 610 000
* Copr repository - 1 180 000
* DNF repository - 700 000
* yum repository - 471 000
* Koji repository - 466 000

Projects and repositories:
* 4,1 TB packages in repositories
* 1 788 194 rpm packages hosted (note that if there is newer package of the same name and architecture the old is 
deleted within 14 days)

* 10 592 projects created so far
* 6 411 projects created in last 12 months
* 97 097 builds submitted in last 12 months (this aggregate all chroots for one 
src.rpm)
* 263 414 builds done in last 12 months (for one chroot)

Traffic (per month)
* 77 GB/day downloads from hosted repositories
* 3,5k visits/day (the same IP requested data within 30 minutes timeout) 
-backend
* 7,4k visits/day - frontend


Clients (during last month)
32% - yum 3.4.3 (urlgrabber 3.10)
12% - libdnf 0.7.0
11% - libdnf 1.1.0
10% - dnf 1.1.0

1.7% - PackageKit (last year it has 9%)

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

Re: user adrian, send same build many times to copr and copr looks like is stucked

[Miroslav Suchý]

Dne 6.5.2017 v 15:08 Sérgio Basto napsal(a):
> Hi, 
> https://copr.fedorainfracloud.org/status/waiting/
> 
> 107 minutes   adrian/ohpc-gcc7-ppc64le548276  mpi
> ch-gnu7-ohpc  3.2-1.ohpc.1.3.1.1  epel-7-ppc64le
> 
> 97 minutesadrian/ohpc-gcc7-ppc64le548336  mpic
> h-gnu7-ohpc   3.2-1.ohpc.1.3.1.1  epel-7-ppc64le
> 
> 49 minutesadrian/ohpc-gcc7-ppc64le548384  ocr-
> gnu7-ohpc 1.0.1-1.ohpc.1.3.1.1epel-7-ppc64le
> 
> 49 minutesadrian/ohpc-gcc7-ppc64le548385  ocr-
> gnu7-ohpc 1.0.1-1.ohpc.1.3.1.1epel-7-ppc64le
> 
> 49 minutesadrian/ohpc-gcc7-ppc64le548386  ocr-
> gnu7-ohpc 1.0.1-1.ohpc.1.3.1.1epel-7-ppc64le
> 
> this kind of use should be limited , seems that is one broken script
> not monitored , and other users like me have to wait a long time for
> his builds ...
> 
> Thnaks 
> 

Other users should not be limited by this. We have this setting:

group0_max_workers=40
group0_max_vm_per_user=8
group0_max_vm_total=35
group0_vm_spawn_min_interval=5
group0_max_spawn_processes=5

So one user should occuppy max 8 builders, but there are 32 others available 
for other users.

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

Re: About Removle of A Project

[Miroslav Suchý]

Dne 2.4.2017 v 16:42 M.Hanny Sabbagh napsal(a):

Hello.

I am the developer behind "Green Recorder", a software to record the Linux 
desktop: https://github.com/green-project/green-recorder

The project (and the repository) was deleted completely from Copr with no 
warning suddenly. Now away from the discussion about why it was deleted, the 
real question is why I didn't receive any email notification about it? I just 
saw it was deleted, with no notice or warning.


When resolving legal issues, I (personally) am sending emails to owner 
of those projects and I give them few days to delete it on their own or 
give them chance to explain why they think we are wrong (it happened few 
times already).
However I am not only one admin. And some others delete those projects 
without warning. I disagree with this practice, but I cannot really do 
anything about it.



The second question is why it was deleted? Some friends on IRC channels 
suggested because of ffmpeg patents. But the software itself (and the repo) 
doesn't contain any copy of ffmpeg. It depends on the free repository of 
rpmfusion to install it as a dependency. Isn't allowed to install / use ffmpeg 
in Fedora? Even If the user was the one who chose to install the software?


Yes. Even runtime dependencies on rpmfusion are not permitted. :(


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

Re: Copr and flatpaks

[Miroslav Suchý]

Dne 21.3.2017 v 17:41 David Haltinner napsal(a):
> As you don't actually need to use rpms to make flatpaks, an entirely new mock 
> plugin could be made for that purpose, if one doesn't already exist that I am 
> unaware of. Would help to bring it into Koji as well in the future. There may 
> be another way to just install a built rpm into a chroot and turn around and 
> add the metadata and build-export into a flatpak repo and ignore mock 
> altogether.

The Flatpack build is entirely different process. And it does not need chroots 
as mock has. So writing mock plugins will
make little or no benefit.

But yeah, having one command to build it in one step would be nice. Right now 
you have to call several `flatpack`
commands. And I will put aside the fact that if you try the steps in:
  http://flatpak.org/hello-world.html
it simply does not work.

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

Re: Random feedback from Telegram: Copr vs. AUR

[Miroslav Suchý]

Dne 21.2.2017 v 07:10 Pavel Raiskup napsal(a):
> Adding voting mechanism would be the easiest part, but I would vote against
> re-implementing forum, maybe just re-using some trivial flask chat?

+1

> Having completely separate forum would be much wiser, because that would
> be much, much more complicated database program than whole copr frontend
> is.  And copr frontend should be as fast as possible; it not only serves
> as users' interface.

See the archives:
https://lists.fedorahosted.org/archives/list/copr-devel@lists.fedorahosted.org/thread/YMCRAQWVNH2BQBLH6J4E6EYDQQHEH6R6/

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

Re: mockremote with RHEL??

[Miroslav Suchý]

Dne 24.1.2017 v 11:31 Martin Juhl napsal(a):
> Does anyone know howto use this with copr and mockremote???
> 
> Right now I have created a /etc/mock/rhel-7-x86_64.cfg, and added the profile 
> with the manage.py script...

Add it with manage.py to copr db is one step, but you must make sure the config 
exist on builders VMs. So put it in
ansible playbook, which spawns the builder.


> [2017-01-24 09:56:59,846][ 
> DEBUG][vmm.event_handler][event_handle.py:on_health_check_result:106] 
> recording check fail: {u'vm_ip': u'127.0.0.1', u'vm_name': u'Copr builder 
> 596711858', 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 to open session: (1, 
> \'Administratively prohibited\')", \'failed\': True}}, \'contacted\': {}}'}

Ok. this is another issue. It seems that ansible is not able to ssh connect to 
your localhost. Are you sure you have
there ssh keys for copr user?


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

[Miroslav Suchý]

Hi,
today we experienced Copr failure and outage.

First we got reports that builds are failing due failure to sign resulting 
packages.
We had similar problem before Christmas, but investigation of logs shown that 
this was different issue.

It took us a moment to find that we run out of inodes on storage where GPG keys 
are stored.
The storage is only 1GB big, and default size of inodes was just 65k. Although 
we use only 40% of storage, we used all
inodes.

So we moved the data, formatted the partition with high -N option and moved 
data back.

Right now the Copr and package signing is operational again.

Thank to Clime, who helped me to restore the service.
-- 
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

Re: Waiting tasks

[Miroslav Suchý]

Dne 12.12.2016 v 01:38 Clinton Work napsal(a):
> copr has 106 waiting tasks and no running tasks right now.   It looks
> like just i386/x86_64 tasks are stuck in the wait queue.

It was already fixed.

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

Re: Some projects fails to signed rpm

[Miroslav Suchý]

Dne 8.12.2016 v 23:02 Miroslav Suchy napsal(a):
> But we discovered that ~30 projects still have problems. It seems that it is 
> project either tried to build or created
> project during the incident.
> 
> I will try to resolve it tomorrow.

Should be resolved now.

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

Re: COPR chroots additions/deletions

[Miroslav Suchý]

Dne 2.12.2016 v 11:13 Michal Novotny napsal(a):
> It was somehow missed when epel-7 chroots were added so finally we have it.

They were not missed. RHEL7 was released only for x86_64 and so was only CentOS 
later. Only some time after the release
was added i386 for CentOS. And it was never released for RHEL7.

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

| Re: Kerberos authentication example

[Miroslav Suchý]

Dne 16.11.2016 v 12:04 Martin Juhl napsal(a):
> When doing the kerberos implementation.. do you have the commands for 
> generating the keytab file??

https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/System-Level_Authentication_Guide/Configuring_a_Kerberos_5_Server.html

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

| Re: move to pagure

[Miroslav Suchý]

Dne 7.11.2016 v 15:07 Pavel Raiskup napsal(a):
> It would be nice to have that github repo synced automatically as an
> mirror, for marketing purposes (for both Copr and Pagure).

Why? I am really curious. IMHO it may just confuse developers where is the 
correct upstream.

I would love to see the github repo wiped and just put there the readme.txt as 
we done when we went away from
fedorahosted.org:
  https://git.fedorahosted.org/cgit/copr.git/tree/README.txt

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

| Re: codebase moved to pagure.io

[Miroslav Suchý]

Dne 1.11.2016 v 10:46 Pierre-Yves Chibon napsal(a):
> Well there is https://docs.pagure.org/pagure/usage/using_webhooks.html no 'did
> not seen any documentation about it' seems either a little strong, that you
> didn't look very far or that for some reasons the doc is unused.

Nice. Thank you.
So the problem was that I was unable to find it.
The problem may be that google search "pagure webhook" does not find this page.
It may be because you use "web-hook" instead of "webhook". I am not native 
speaker, but google fight suggest that
"webhook" is the correct form.

> The documentation can however always be improved, but, and I'm sure you will
> agree, it's kinda hard when you develop something to know what users will
> struggle with. So I'm up for improving the docs if I'm told which aspects 
> should
> be.

Even with the documentation, I had hard time to find the setting. I had to use 
Ctrl+F.

There is a box about web-hook, but it contains just the private key. The actual 
webhook is buried in project options:

I would recommend you to:
  * Rename the box "Private web-hook key" to "Webhooks"
  * move "Activate Web-hooks :" to top of "Webhooks" box
  * Put in that "Webhook" box link to
https://docs.pagure.org/pagure/usage/using_webhooks.html
so developers can easily discover this page.

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

| Re: codebase moved to pagure.io

[Miroslav Suchý]

Dne 27.10.2016 v 19:56 Pierre-Yves Chibon napsal(a):
> Pagure supports web-hook

I still did not seen any documentation about it. And my common sense is 
failing. I really do not know how to use those
web-hooks.

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

| Re: codebase moved to pagure.io

[Miroslav Suchý]

Dne 31.10.2016 v 13:22 Michal Novotny napsal(a):
> >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 :).

Not exactly true. Yes Copr git repository is quite flat and we have everything 
just in one level.
But there are projects, which have much deeper structure (e.g. Spacewalk).

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

Yes, the repository can be hundreds MB large. And we cannot keep it and cache 
it. So checking it out after every commit
just to determine the information is overkill.

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

| Re: codebase moved to pagure.io

[Miroslav Suchý]

Dne 21.10.2016 v 13:00 Michal Novotny napsal(a):
> 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.

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

| Re: Fork "from" or "to" rawhide?

[Miroslav Suchý]

Dne 10.10.2016 v 18:45 Sérgio Basto napsal(a):
> Could we have copr for F25 ?  and in the future for other branched
> repos ? Please .

There is fedora-25-* in Copr for more than month already.

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

| Re: Could we allow issue tracker in github?

[Miroslav Suchý]

Dne 7.10.2016 v 17:17 Igor Gnatenko napsal(a):
> I'm ++, /me hates all that struggling with RHBZ.

I'm --, I hate github's issue tracker when it is longer than one page. It is 
useful for small project. But for bigger
projects no.
BZ allows us to track which issues were modified, and which are part of which 
release. We can change several reports at
once. I am using the reporting charts...

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

| Re: Could we allow issue tracker in github?

[Miroslav Suchý]

Dne 7.10.2016 v 18:17 Pavel Raiskup napsal(a):
> While we discuss bugzilla -- it would be fine to have direct link to list
> of (all) bugs currently filled against Copr, somewhere.  That's imo the
> major benefit of github issues for newcommers (no need to search how the
> component or project is named .. the list is there).

Great idea. Done.
https://github.com/fedora-copr/copr/commit/f55f3a959646d82640fbb7fa613b5001e20cc8a4

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

| Fork "from" or "to" rawhide?

[Miroslav Suchý]

Hi,
I want to highlight
  https://bugzilla.redhat.com/show_bug.cgi?id=1381790

Right now we have rawhide target and when new chroot (e.g. F26) we copy 
everything from rawhide to F26.

This RFE as for the reverse. I.e. there is no rawhide at all. Rawhide is named 
F26 and when there is branching of F26 we
add new chroot named F27.

I would love to hear your comments.
-- 
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 badge for your pages

[Miroslav Suchý]

I just documented one feature we have in Copr for some time:
  https://fedorahosted.org/copr/wiki/UserDocs#StatusBadges
It allows you to put small button on your page, which reflect status of your 
package. I.e. success/fail/building.
-- 
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

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

[Miroslav Suchý]

Dne 23.9.2016 v 12:44 Pavel Raiskup napsal(a):
> Why can't we differ? 

Because it adds more maintenance overhead.

> Is fedora dist-git ever going support all the repos
> Copr will support?

Ideally this should be config driven. And Fedora and Copr should have the same 
code, just different configs.

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

Re: Having FE design/templates "pluggable"

[Miroslav Suchý]

Dne 21.9.2016 v 17:56 Pavel Raiskup napsal(a):
> WDYT?  Would be patches implementing this idea accepted?

Sure.

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

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

[Miroslav Suchý]

Dne 21.9.2016 v 16:59 Pavel Raiskup napsal(a):
> 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.

Patches against what? This originate in fedpkg and fedora dist-git.
Copr-dist-git and copr-fedpkg already has some difference, but I do not want to 
differ even more.
Imho this should be discussed with Fedora-infra and maintainer of fedpkg.

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

??? Epel chroot does not mean RHEL. It means EPEL, which is "high quality set 
of additional packages for Enterprise
Linux, including, but not limited to, Red Hat Enterprise Linux (RHEL), CentOS 
and Scientific Linux (SL), Oracle Linux
(OL). "

On the other hand, the name "centos-*" would imply that it is just CentOS, 
without additional repos. Which is not true.
It may have sense if we add "centos-*" beside the "epel-*", but there is no 
demand for that. And it will likely just
confuse people.


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

Re: Fwd: [Bug 1376844] New: Please start using processes like code-review, etc.

[Miroslav Suchý]

Dne 21.9.2016 v 12:52 Pavel Raiskup napsal(a):
> Thanks, I'll subscribe there.  Let's hope I'll be able to find good
> heuristic to pick important changes for review -- but unfortunately, I can
> not review everything.  Is there possibility to highlight important
> changes?

Define "important changes" :)

What is important for me is not important for you and vice versa.
-- 
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

Clime as primary maintainer of Copr service

[Miroslav Suchý]

Hi,
I want to announce that Clime (Michal N.) is now primary maintainer of Copr 
service.
I will focus on gathering requirements from other teams around Fedora and 
introducing new features.
And Clime will manage day-to-day operations - making sure that Copr is up and 
running.
He is doing that job already better than me.

I am still around, but do not hesitate to contact Clime with any issue of Copr.
-- 
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

Re: Docker requirement

[Miroslav Suchý]

Dne 16.9.2016 v 17:00 Pavel Raiskup napsal(a):
> Hi all,
> 
> this is probably proper place for such discussions -- I am curious what is the
> plan with Docker stuff within Copr project.
> 
> Do you plan to make Fedora's copr hardly dependant on Docker images?

You mean the commit 25c7d91bfdc895bb0d63f3b06fa1399b507fff14 ?

Previous week we worked on Mock security issue. This is fixed now. However it 
raised the question: is it smart to run
mock-scm, pyp2rpm, gem2spec... directly on copr-dist-git machine? It is run 
under non-privileged user, but still...
I can think about some attack vectors. For obvious reasons I will not disclose 
them publicly.

So we wanted to build SRPM in environment, which will be discarded after SRPM 
build and hard to escape.
There are several ways how to implement it. But we chosen builds in Docker 
container. It will be used just for SRPM
build. Nothing more. Is it problem for you?

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

Fwd: [Bug 1376844] New: Please start using processes like code-review, etc.

[Miroslav Suchý]

This is not really bug. So I will close it in BZ. But I'm happy to discuss it 
here.

I disagree that we need code review before push. This is quite small project, 
with only few active developers.
Although you can find some commits which can be discussed, most of them are 
straight.

If you want to do review, then you can subscribe to:
  
https://lists.fedorahosted.org/admin/lists/copr-commits.lists.fedorahosted.org/
And comment the commit here on this mailing list. If needed, it can be rejected.

Mirek


 Přeposlaná zpráva 
Předmět: [Bug 1376844] New: Please start using processes like code-review, etc.
Datum: Fri, 16 Sep 2016 14:53:30 +
Od: bugzi...@redhat.com
Komu: msu...@redhat.com

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

Bug ID: 1376844
   Summary: Please start using processes like code-review, etc.
   Product: Copr
 Component: backend
  Assignee: msu...@redhat.com
  Reporter: prais...@redhat.com



Copr is starting to be very popular and key part of Fedora's and Red Hat's
infrastructure, and it deserves proper processes.  I'm not talking about hard
bureaucracy, but some clear 'Pull-request -> code-review -> push' is enough.
If there is done something like that in background (I strongly believe there
is) please open that process.

I'd be glad to be part of the review process if there is something really
design breaking.

Copr really needs new consumer, that is important point, so please:

- let's not hard-wire anything specific to Fedora instance copr
- if there is something Fedora-instance specific, make it optional, pluggable
  thing

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
copr-devel mailing list -- copr-devel@lists.fedorahosted.org
To unsubscribe send an email to copr-devel-le...@lists.fedorahosted.org

Re: Child pid '4787' is dead

[Miroslav Suchý]

Dne 6.9.2016 v 23:22 Miro Hrončok napsal(a):
> My builds in [python26], IDs 450012 and 450019 end weird on F23, while 
> succeeding on other Fedoras.
> 
> The last lines of build.log.gz are:
> + exit 0
> Child pid '4787' is dead
> Child dead, killing orphans
> Child return code was: 0
> 
> While on other Fedoras:
> + exit 0
> Child return code was: 0
> 
> The [koji] build is fine (at least for non-arm now).
> 
> The RPM files are there in the output directory, but not installable from the 
> repo.
> 
> Is that some problem in Copr?

Not Copr problem. May be a mock problem. Lookin in mock code:

i_rdy, o_rdy, e_rdy = select.select(fds, [], [], 1)

if not i_rdy and not o_rdy and not e_rdy:
if child and child.poll() is not None:
logger.info("Child pid '%s' is dead", child.pid)

To me is looks like a race condition: select() waited 1 second and returned 
empty list and exactly at the same time the
process ended so pool() returned "not None". The strange is that it happened 
twice in row for you.

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

Re: Builds Failing :(

[Miroslav Suchý]

Dne 17.8.2016 v 17:05 Richard Brantley napsal(a):
> My builds are failing with empty logs. Please halp! Is this the right place 
> to contact?

It is right place to contact. But we need some information. At least your build 
id. Name of your project.
Providing direct links will make our life easier.

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

Re: Recover my lantw44/chromium project on Copr

[Miroslav Suchý]

Dne 9.8.2016 v 20:22 Ting-Wei Lan napsal(a):

Hello,

Is it possible to recover my lantw44/chromium project on Copr? I never
delete it, but it has become inaccessible since 2016-08-03 13:00 UTC.
The web page https://copr.fedorainfracloud.org/coprs/lantw44/chromium/
shows "Error 404: Not Found. Project lantw44/chromium does not exist."
and dnf prints "Failed to synchronize cache for repo 'lantw44-chromium',
disabling."


Your project has been deleted because it contained ffmpeg, which is 
prohibited in Copr. See:


https://fedorahosted.org/copr/wiki/UserDocs#WhatIcanbuildinCopr

I personally wrote to owners and give them some time for reaction.

But some others admins remove it without warning. And it is their right 
to do that.


--
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-cli use python3 now

[Miroslav Suchý]

I just built new copr-cli for fedora-rawhide. It will now use python3.

There should be no regression as we have python3-copr for some time. But if you 
spot something bad, please report it.
-- 
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

Disk issue

[Miroslav Suchý]

FYI:
There was issue with storage this night:
  https://fedorahosted.org/fedora-infrastructure/ticket/5397#comment:1
Patrick already resolved it.
-- 
Miroslav Suchy, RHCA
Red Hat, Senior Software Engineer, #brno, #devexp, #fedora-buildsys
___
copr-devel mailing list
copr-devel@lists.fedorahosted.org
https://lists.fedorahosted.org/admin/lists/copr-devel@lists.fedorahosted.org

Re: wiki edit

[Miroslav Suchý]

Dne 12.7.2016 v 09:44 Benjamin Lefoul napsal(a):
> Hello,
> 
> According to https://fedorahosted.org/copr/wiki it is possible to
> contribute to the wiki via git patches (and probably now through the
> regular GitHub pull-request process). But I cannot find the wiki in the
> GitHub repo... Am I missing something?

Actually the opposite. You do *not* need to send patches to edit the wiki.
However the wording was confusing. I edited it.

If you have FAS account, you should be able to edit the wiki (after you log in).

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

Re: Disabled copr-dist-git webui

[Miroslav Suchý]

Dne 12.7.2016 v 07:18 Vít Ondruch napsal(a):
> This does not work anymore as far as I can tell 

There was typo in flavour type definition and the dist-git instance had small 
swap space and OOM killed the machine.
This is fixed now.

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

Re: Disabled copr-dist-git webui

[Miroslav Suchý]

Dne 7.7.2016 v 16:07 Miroslav Suchý napsal(a):
> I disabled copr-dist-git WebUI. That one with /cgit/ prefix.
> This was necessary due performance issue. Once resolved I will enable it 
> again and I will inform you.

The issue has been resolved and I enabled the cgit WebUI again.

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

Disabled copr-dist-git webui

[Miroslav Suchý]

I disabled copr-dist-git WebUI. That one with /cgit/ prefix.
This was necessary due performance issue. Once resolved I will enable it again 
and I will inform you.
-- 
Miroslav Suchy, RHCA
Red Hat, Senior Software Engineer, #brno, #devexp, #fedora-buildsys
___
copr-devel mailing list
copr-devel@lists.fedorahosted.org
https://lists.fedorahosted.org/admin/lists/copr-devel@lists.fedorahosted.org

Re: New release of Copr

[Miroslav Suchý]

Dne 20.6.2016 v 13:49 Pavel Raiskup napsal(a):
> On Thursday, June 16, 2016 3:10:04 PM CEST Miroslav Suchy wrote:
>> Hi,
>> I just upgraded Copr instance to new version.
>>
>> There is one big change. You can now lower priority of your build.
>> It was introduced to easy rebuild of rubygems and pypi. But it can be 
>> used by CI systems later.
>>
>> Copr-cli from our git, has --background option already. It lowers the 
>> priority. But due compatibility reason we will not push the package into 
>> main Fedora and we will wait one or two weeks.
>>
>> If you want to give it try, then you can install it from our copr project.
> 
> Sorry I haven't posted earlier, I'm writing while I'm facing one bugreport.
> 
> Note that new python-copr library breaks the compatibility with older servers.
> While trying to submit new build (or request for new copr) from command line,
> frontend replies with (and copr-cli fails with):
> 
> Unknown arguments passed (non-existing chroot probably)"
> 
> That's because the new client library sends useless content in POST to
> frontend.  The older frontend was guarded against this.  Possibly we should
> be more careful to not break client/server protocol like that in future :).
> 
> Ugly "hot-fix" is attached.

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


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

Re: new 24hr timeout

[Miroslav Suchý]

Dne 1.6.2016 v 02:25 David Haltinner napsal(a):
> I'm wondering if the 24 hr timeout change is too long. I tossed a bunch of 
> builds in, and it decided to stall out with no log messages on four of them, 
> filling the build machines up so others builds are stuck waiting now.  These 
> were three 10 minute builds and one two hour build on a normal decent quad 
> core VM. Perhaps 24 hrs is too long to timeout? Or limit the number of build 
> machines one user can utilize at a time?

Our backend was stuck this night and morning. It should be ok now.

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

Re: New Release !

[Miroslav Suchý]

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

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

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

Re: 70k+ tasks sent to Copr

[Miroslav Suchý]

Dne 9.5.2016 v 10:52 Jason Woods napsal(a):
> Looks like things might be back to normal though - as the queue is looking 
> much healthier. Though seems the @copr builds seem to have stopped.

Yes. I find the culprit and I issued temporary fix for that.

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