Sorry for the delay.
On Monday, September 19, 2016 3:59:57 PM CEST Miroslav Suchý wrote:
> 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.
> >
>
On Monday, September 19, 2016 1:53:08 PM CEST Miroslav Suchý wrote:
> 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.
Agreed. That said, I do
Hello all,
we have just enabled Mageia-6 and Mageia-x86_64 chroots for i586 + x86_64
archs. So if you want to build something for Mageia (https://www.mageia.org/),
please, feel free to try.
Best Regards
COPR team
___
copr-devel mailing list -- copr-deve
Correction: Mageia-6 and *Mageia-cauldron chroots. Sorry for that!
On Wed, Sep 21, 2016 at 1:31 PM, Michal Novotny wrote:
> Hello all,
>
> we have just enabled Mageia-6 and Mageia-x86_64 chroots for i586 + x86_64
> archs. So if you want to build something for Mageia (
> https://www.mageia.org/),
On Wed, Sep 21, 2016 at 7:31 PM, Michal Novotny wrote:
> Hello all,
>
> we have just enabled Mageia-6 and Mageia-x86_64 chroots for i586 + x86_64
> archs. So if you want to build something for Mageia
> (https://www.mageia.org/), please, feel free to try.
Really useful, thanks!
--
Yours sincerel
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 chang
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] ht
On Wednesday, September 21, 2016 2:57:03 PM CEST Miroslav Suchý wrote:
> 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.
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
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 downst
On Wed, Sep 21, 2016 at 5:56 PM, Pavel Raiskup wrote:
> 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-
Look into build.log for build 00108334-autotools-git in the F24 x86_64
chroot (
https://copr-be.cloud.fedoraproject.org/results/praiskup/autotools/fedora-24-x86_64/00108334-autotools-git/build.log.gz)
and you will find out that the build was done with:
chrootPath='/var/lib/mock/fedora-rawhide-x86_
The idea of configurable template paths sounds nice. What you can do now is
to pass
template_folder="xyz" as named param to flask.Flask constructor in
coprs_frontend/coprs/__init__.py.
In theory, we could keep that param value in db, so that no patching is
needed.
clime
On Wed, Sep 21, 2016 at 5:
On Wed, Sep 21, 2016 at 3:32 PM, Pavel Raiskup wrote:
>
> :) Consider that others consume Copr sources ...
>
> > What is important for me is not important for you and vice versa.
>
I would say that every commit is important.
>
> ... and have Copr working, want to have it as stable as possible,
I think that only real restriction on branch naming is in fedpkg/fedpk-copr
(load_rpmdefines function).
I think that's the heart of the issue. If you could provide a sane default
case for parsing branch_merge variable,
then we could adjust everything else (e.g. mock_chroot_name -> branch,
branch ->
15 matches
Mail list logo
