copr-devel September 2016

copr-devel@lists.fedorahosted.org

9 participants
14 discussions

Copr badge for your pages
by Miroslav Suchý 29 Sep '16

29 Sep '16

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

1 0

copr-dist-git branch naming and mock names
by Pavel Raiskup 23 Sep '16

23 Sep '16

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

4 8

Having FE design/templates "pluggable"
by Pavel Raiskup 23 Sep '16

23 Sep '16

For better orientation, internally we have "red color" design for copr frontend (so users immediately know where they are). It would be really useful if paths to template files were configurable via FE configuration file .. so non-Fedora instances could simply "just" edit config, instead of downstream-patch many template files. Ideally, even the alternative design(s) should be "upstreamable" .. so we could e.g. submit patch adding alternative design. But admin's should be able to provide alternative 'copr-frontend-design-XXX' packages. WDYT? Would be patches implementing this idea accepted? Pavel

4 3

Fwd: [Bug 1376844] New: Please start using processes like code-review, etc.
by Miroslav Suchý 22 Sep '16

22 Sep '16

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.… 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 +0000 Od: bugzilla(a)redhat.com Komu: msuchy(a)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: msuchy(a)redhat.com Reporter: praiskup(a)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.

4 6

database corruption?
by Pavel Raiskup 22 Sep '16

22 Sep '16

Looks weird, because I believe I built complete copr repo [1] for F24, but seems like some of the builds are not in database anymore (while results are still there on backend). Also dist-git doesn't report f24 branch for some of the packages. Do we remember accident that could cause this? [1] https://copr.fedorainfracloud.org/coprs/praiskup/autotools/monitor/ Thanks, Pavel

2 2

Mageia chroots enabled
by Michal Novotny 21 Sep '16

21 Sep '16

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

2 2

Docker requirement
by Pavel Raiskup 21 Sep '16

21 Sep '16

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? Do you plan to have anything Docker-related optional? Or are other ways to deploy things planned to be obsoleted? Thanks, Pavel

2 2

Clime as primary maintainer of Copr service
by Miroslav Suchý 20 Sep '16

20 Sep '16

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

2 1

New COPR version deployed
by Michal Novotny 20 Sep '16

20 Sep '16

Hello, a new version of COPR packages were deployed to their respective machines. The most prominent changes are: - pyp2rpm, tito, gem2rpm tools now generate their SRPMs in isolation from the host system (security and in-future perhaps resource limiting measurement) - sketch of modularity introduced (please, see https://www.youtube.com/watch?v=uNW8QEzsdDg about how to use it) - mock build configs are now available in the result directories (under ./configs) - few bugfixes Enjoy COPR team

2 1

New release
by Michal Novotny 09 Sep '16

09 Sep '16

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

1 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

copr-devel September 2016