Hello,
recently (on Aug 1, 2019) a new major Copr release landed production.
Here is the list of visible/important changes:
- copr-rpmbuild was simplified, which though brings some incompatible
changes for external users:
http://frostyx.cz/posts/dropping-copr-rpmbuild-scm-support
- added
On Monday, July 22, 2019 4:03:55 PM CEST 藍挺瑋 wrote:
> It seems that Copr API v3 no longer sorts the result array. For example, I
> expect
> https://copr.fedorainfracloud.org/api_3/build/list/?ownername=lantw44=chromium=chromium=id_type=DESC
> to return an array of 'items' sorted by 'id', but
On Tuesday, June 18, 2019 12:05:58 AM CEST Miro Hrončok wrote:
> Hey,
>
> I have coupe dozens (or hundreds?) builds like this:
>
> https://copr.fedorainfracloud.org/coprs/g/python/python3.8/build/936777/
>
> Any idea what went wrong?
Thanks for the report. Long story short, there were IO
Hi all,
On Monday, June 10, 2019 4:20:56 PM CEST Pavel Raiskup wrote:
> [snip] we temporarily disabled ppc64le architecture in copr [snip]
> [1] https://pagure.io/fedora-infrastructure/issue/7868
the issue is over, at least seems to be. We enabled ppc64le architecture
in Copr
On Tuesday, June 11, 2019 8:22:03 AM CEST Miro Hrončok wrote:
> I just got this weird failure when building SRPM:
>
> https://copr.fedorainfracloud.org/coprs/g/python/python3.8/build/934036/
> https://copr-be.cloud.fedoraproject.org/results/@python/python3.8/srpm-builds/00934036/builder-live.log
Hi all,
for some reason (not yet known, tracked in fedora infra [1]) ppc64le
builders fail to spawn, and what is even worse this issue also affects x86
builders. So because of this, we temporarily disabled ppc64le
architecture in copr. It means that the ppc64le builds will be processed
later
On Thursday, June 6, 2019 7:26:01 PM CEST Miro Hrončok wrote:
> I get failures in SRPM builds:
>
> FileNotFoundError: [Errno 2] No usable temporary directory found in ['/tmp',
> '/var/tmp', '/usr/tmp', '/home/mockbuilder']
Looks like "no space left on device" again; too many builds you
On Monday, June 3, 2019 2:14:44 PM CEST Miro Hrončok wrote:
> It seem that individuals can requests permissions in individual coprs, but
> not
> in group coprs. Is that correct?
>
> I for example don't see the settings tab at @copr/copr (group) but I see it
> at
>
Hello, fyi,
Fedora Copr builders were recently upgraded to Fedora 30 (from F28).
The major change is that `yum` package is not working ideally on F30
anymore, and soon (on F31) there will be no `yum` at all [1].
Mock (which is used on builders) though uses /usr/bin/yum-deprecated (yum)
by
On Tuesday, May 28, 2019 10:22:34 PM CEST Pavel Raiskup wrote:
> On Tuesday, May 28, 2019 8:07:54 PM CEST Miro Hrončok wrote:
> > What happens when 2 or more PRs to different repos have the same number?
> > ..
> > Does the second build "see" the previous one?
>
On Tuesday, May 28, 2019 8:07:54 PM CEST Miro Hrončok wrote:
> On 28. 05. 19 6:11, Pavel Raiskup wrote:
> > On Monday, May 27, 2019 5:42:01 PM CEST Miro Hrončok wrote:
> >> It seems that the package is not available in the copr repo.
> > It is not in the main copr repo (dir
On Tuesday, May 28, 2019 11:58:20 AM CEST Miro Hrončok wrote:
> On 28. 05. 19 6:11, Pavel Raiskup wrote:
> > On Monday, May 27, 2019 5:42:01 PM CEST Miro Hrončok wrote:
> >> It seems that the package is not available in the copr repo.
> >
> > It is not in
On Wednesday, May 22, 2019 12:29:16 PM CEST Miro Hrončok wrote:
> Not sure if this is severe enough to file a bug report
No problem to close issue if it was not:
https://pagure.io/copr/copr/issue/757
Pavel
___
copr-devel mailing list --
On Tuesday, May 21, 2019 12:18:34 PM CEST Miro Hrončok wrote:
> It happens to me often that my browser displays the builder-live.log like
> this:
>
> /usr/include/bits/string_fortified.h:106:10: warning: ‘__builtin_strncpy’
> specified bound depends on the length of the source argument
>
On Friday, May 10, 2019 1:47:46 AM CEST Miro Hrončok wrote:
> I have some trouble with copr dist git:
>
> Traceback (most recent call last):
>File "/usr/lib/python3.6/site-packages/copr_rpmbuild/providers/scm.py",
> line
> 145, in clone_and_checkout
> helpers.run_cmd(clone_cmd)
>
On Wednesday, May 1, 2019 10:50:21 AM CEST Miro Hrončok wrote:
> I found this in several builder-live.logs:
>
> Start: rpmbuild -bs
> warning: Downloading
> http://downloads.tryton.org/4.0/trytond-analytic-account-4.0.1.tar.gz to
> /builddir/build/SOURCES/trytond-analytic-account-4.0.1.tar.gz
>
Thanks for the report.
On Monday, April 29, 2019 12:54:13 AM CEST Miro Hrončok wrote:
> What can it be?
My interpretation is that (a) for some reason copr-rpmbuild was not
updated on the builder, and even though (b) for some reason backend kept
that (broken) builder machine without allocating a
Hi Antonio,
> This [1] is a forked project of python3.8 [2]; inside there are all
> forked packages previously built but, if i require a new build for
> testing Python 3.8, are not used the packages from the project [3] (i
> see Python 3.7.3 as dependency).
>
> What am I doing wrong?
This seems
Hi Miro,
On Wednesday, April 3, 2019 12:01:43 AM CEST Miro Hrončok wrote:
> On 02. 04. 19 19:52, Miro Hrončok wrote:
> > Hi. My build has been pending for hours:
> >
> > https://copr.fedorainfracloud.org/coprs/g/python/python3.8/build/876568/
> >
> > But it is not listed in
On Friday, March 8, 2019 10:21:06 AM CET Miroslav Suchý wrote:
> 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.
In the 'rm -rf' is one star sign more...
> It i
On Friday, March 8, 2019 12:47:29 AM CET Miroslav Suchý wrote:
> 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
On Monday, November 12, 2018 10:19:44 AM CET Jiri Kastner wrote:
> as user and small contributor of one project, which is using gerrit for
> change review, i would like to made that reviewing as simple as possible.
>
> today i realized that there is 'copr dir' which is used for building pull
>
Hi Antonio,
On Sunday, October 14, 2018 11:59:17 AM CEST Antonio Trande wrote:
> My running builds look inaccessible:
> https://copr.fedorainfracloud.org/coprs/sagitter/ForTesting/build/809221/
>
> What's going on?
seems like that build is canceled now (nothing special). If you canceled
it the
Hi Sérgio,
On Saturday, October 13, 2018 7:12:04 PM CEST Sérgio Basto wrote:
> If we could set copr to do ccached builds ? , sometimes I prefer use local
> builds which use ccache , and after cache gcc compilation , I can improve
> build times in 10 times more or less ...
the design of copr
On Monday, August 20, 2018 7:03:46 AM CEST Miroslav Suchý wrote:
> 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.
Not really PEBKAC, I'd say. Some of those branches really were in origin,
and
Hi, there was an idea to turn on the "Follow Fedora branching" feature in Copr
by default (for newly created copr projects). That feature automatically
creates new fedora-NN-* chroots from fedora-rawhide-* chroots (at Fedora
branching time), and "forks" the related builds (so the packages don't
hod
instead where you can request the list of needed packages (to generate sources)
and do non-root scripting.
Pavel
> On 28.05.2018 18:04, Pavel Raiskup wrote:
> > On Saturday, May 26, 2018 1:12:17 AM CEST Dmytro Zagashev wrote:
> >> hi,
> >>
> >> I have the fol
On Saturday, May 26, 2018 1:12:17 AM CEST Dmytro Zagashev wrote:
> hi,
>
> I have the following command at the top of spec file:
>
> %define version %(git ls-remote --tags --refs
> https://gitlab.com/libidn/libidn2.git | tail -n 1 | awk -F'-' '{print $2}')
>
> When I build rpm in copr, using
On Tuesday, May 15, 2018 3:27:38 PM CEST Pavel Raiskup wrote:
> On Monday, May 14, 2018 2:20:28 PM CEST Michal Novotny wrote:
> > Can we cover it just by providing "with" and "without" fields for
> > chroots/builds which would then basically translate to --with/-
On Monday, May 14, 2018 2:20:28 PM CEST Michal Novotny wrote:
> Can we cover it just by providing "with" and "without" fields for
> chroots/builds which would then basically translate to --with/--without
> options for mock, rpkg, and similar tools?
You could add any other mock option that way,
On Wednesday, March 21, 2018 10:32:08 AM CET Miroslav Suchý wrote:
> https://docs.google.com/forms/d/e/1FAIpQLSckxxUeAWKwUzjju6ftDjPeNWVWT_2_Y7mdpOrc8vMqRg_yxg/viewform?usp=sf_link
Do you plan to share this on fedora devel list?
Pavel
___
copr-devel
On Thursday, March 22, 2018 6:53:15 PM CET Andrew Walsh wrote:
> Minor change to the header that I noticed while reading up on the topic for
> Custom Sources.
Applied, thanks!
https://pagure.io/copr/copr/c/04e2dcac9632626cba9ac2f814af18ceebeda180?branch=master
Pavel
On Wednesday, March 21, 2018 12:36:25 PM CET Miroslav Suchý wrote:
> 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 Git
On Wednesday, March 21, 2018 10:32:08 AM CET Miroslav Suchý wrote:
> 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
On Tuesday, February 13, 2018 10:15:42 PM CET Michal Novotny wrote:
> On Tue, Feb 13, 2018 at 9:51 PM, Michal Novotny <cl...@redhat.com> wrote:
>
> > Hello,
> >
> > On Tue, Feb 13, 2018 at 12:54 PM, Michael Šimáček <msima...@redhat.com>
> > wrote:
> &g
Sorry, I wanted to CC fedora devel before, forwarding.
Pavel
On Tuesday, February 13, 2018 10:54:55 AM CET Pavel Raiskup wrote:
> Because we are unable to find a consensus on implementation details, it's
> likely we'll drop this feature from copr API and it will be probably a bit
Because we are unable to find a consensus on implementation details, it's
likely we'll drop this feature from copr API and it will be probably a bit
more complicated to setup mock chroot for local tests in future (you'll
need to have builder machine with copr-rpmbuild installed, which brings a
lot
Forwarding to Fedora devel. User perspective (API v1 vs. v2) is important.
Pavel
On Monday, February 12, 2018 11:17:26 PM CET Jakub Kadlcik wrote:
> Hello,
> we are currently discussing how to deal with the current situation of
> inconsistent Copr API.
>
> If you are interested in this topic
Hi Adrian,
On Thursday, February 1, 2018 10:43:37 PM CET Adrian Sevcenco wrote:
> Traceback (most recent call last):
>File "/usr/bin/copr-rpmbuild", line 96, in main
> action(args, config)
>File "/usr/bin/copr-rpmbuild", line 126, in build_srpm
> provider.produce_srpm()
>
On Thursday, February 1, 2018 9:51:37 AM CET Richard W.M. Jones wrote:
> https://copr-be.cloud.fedoraproject.org/results/rjones/riscv/fedora-rawhide-x86_64/00707817-riscv-qemu/root.log.gz
>
> Something to do with boost:
>
> DEBUG util.py:479: Error:
> DEBUG util.py:479: Problem: package
On Monday, September 11, 2017 2:07:43 PM CEST Jean-Marc Liger wrote:
> To avoid space consumming, an optional feature to switch before build should
> be the best option for me.
This would be possible too, if such builds have been imported into
temporary ("soon" to be garbage collected) namespace
On Friday, September 8, 2017 11:07:41 AM CEST Michal Novotny wrote:
> On Fri, Sep 8, 2017 at 9:50 AM, Jean-Marc Liger
> jean-marc.li...@parisdescartes.fr> wrote:
> > Great, so DistGit won't be update if build fails ?
>
> Right now, srpm is imported into DistGit before the actual rpm build.
Just
On Monday, August 21, 2017 1:18:46 PM CEST Michal Novotny wrote:
> Hello,
>
> On Mon, Aug 21, 2017 at 11:14 AM, Pavel Raiskup <prais...@redhat.com> wrote:
>
> > On Monday, August 21, 2017 10:14:55 AM CEST Michal Novotny wrote:
> > > Hello, this might be a c
On Monday, August 21, 2017 10:14:55 AM CEST Michal Novotny wrote:
> Hello, this might be a change in rawhide dnf-plugins-core (or dnf). Please,
> if you don't need mock bootstrap feature enabled in your project settings,
> then you can disable it.
Is wide disabling (of this mistakenly enabled)
On Wednesday, June 14, 2017 11:52:35 AM CEST Michal Novotny wrote:
> Actually, this is a bug. systemd-nspawn "chroots" are now used for building
> and there is a different config option for network-enabling them. Now it's
> rpmbuild_networking, before it was use_host_resolv.
I would suggest to
On Saturday, May 27, 2017 12:15:07 AM CEST Marcin Dulak wrote:
> I've encountered this problem:
> https://bugzilla.redhat.com/show_bug.cgi?id=1450950
> Anyone else using tito with git-annex on copr?
I tried to play with the tito && git-annex a bit now, but I suspect there's some
bug in
On Tuesday, February 21, 2017 1:45:38 PM CET Michal Novotny wrote:
> On Tue, Feb 21, 2017 at 12:03 PM, Pavel Raiskup <prais...@redhat.com> wrote:
>
> > On Tuesday, February 21, 2017 9:31:33 AM CET Michal Novotny wrote:
> > > I plan to allow rebuilding all packages in a
On Tuesday, February 21, 2017 7:18:51 AM CET Igor Gnatenko wrote:
> it depends. if you are planning to do mass-rebuild after branching in
> all copr repos, then I prefer rawhide. If not, I prefer fXY.
We had some off-list discussion with Michal and he was talking about something
like "Settings ->
On Monday, February 20, 2017 1:17:06 PM CET Adam Samalik wrote:
> Hey guys!
>
> Just in case you run out of ideas about making Copr even better, I just saw
> this feedback on the Fedora Telegram channel comparing Fedora Copr and Arch
> Linux AUR:
>
> "...
>
> Justing W. Flory: Fedora has a
On Monday, February 20, 2017 4:16:38 PM CET Michal Novotny wrote:
> as soon as branching is done and f26 repo links become available, we will
> switch the current fedora-26-* chroots from rawhide to use the f26
> repositories.
Thanks for the update!
Regarding the future fedora-27-x86_64 rpm
On Tuesday, January 31, 2017 2:52:59 PM CET Martin Juhl wrote:
> Sound right... hmm
>
> By adding the following, the dist-git import seems to work, but now the
> rpkg-copr fails..
Well, this is (probably) where pull-request [1] could help. I was unable
to re-iterate so far, but that's
On Tuesday, January 31, 2017 11:22:18 AM CET Martin Juhl wrote:
>
> > 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.
>
> Sooo.. where exactly should I put it??
>
> I'm
On Tuesday, January 24, 2017 12:58:00 PM CET Michal Novotny wrote:
> Hello, I will deploy fedmsg hotfix tomorrow at 7:30am UTC. I am very sorry
> for the inconvenience.
I'm very sorry too. I failed with testing this against fedmsg because I was
even unable to connect to fedmsg. And I did not
On Monday, December 5, 2016 1:49:22 PM CET Martin Juhl wrote:
> Hi
>
> Manually:
>
> ansible-playbook -i inventory -c ssh
> /usr/share/doc/copr-backend-1.94/playbooks/spawn_local.yml/usr/lib/python2.7/site-packages/novaclient/v1_1/__init__.py:30:
> UserWarning: Module novaclient.v1_1 is
On Monday, December 5, 2016 11:47:59 AM CET Martin Juhl wrote:
> Ok... Might have fixed that myself...
>
> Using the /centos/7.2.1511/cloud/x86_64/openstack-kilo/ it seems to work...
>
> Now i'm getting:
>
> ==> /var/log/copr-backend/vmm.log <==
> [2016-12-05 11:15:37,384][
>
On Friday, December 2, 2016 11:13:20 AM CET Michal Novotny wrote:
> fedora-rawhide chroots were some residue of the yesterday's release. They
> should have been already disabled as fedora-26 chroots replaced them.
Ah, when I saw rawhide chroots available this morning I was very happy (after
your
On Tuesday, November 22, 2016 2:05:01 PM CET Pavel Raiskup wrote:
> Maybe I could help to have it fixed for next-release?
I've pushed this commit:
https://pagure.io/copr/copr/c/e084d2826723b27
When running 'manage.py create_db', the database seems to be OK WRT
status_to_order and order_to_sta
On Wednesday, November 16, 2016 4:06:46 PM CET Michal Novotny wrote:
> You need to run:
>
> [skip] alembic downgrade 3ec22e1db75a
> [skip] alembic upgrade head
>
> "./manage.py create_db --alembic alembic.ini" installation instruction from
> copr-setup.txt is creating db according to COPR
On Wednesday, November 16, 2016 12:04:34 PM CET Martin Juhl wrote:
> When doing the kerberos implementation.. do you have the commands for
> generating the keytab file??
Unfortunately, I've never generated "serious" keytab. That's usually matter of
requesting it from your authentication
On Friday, October 21, 2016 1:00:05 PM CEST Michal Novotny wrote:
> Hello folks,
>
> codebase will be now hosted on pagure.io (https://pagure.io/copr/copr). We
> would like to start working on this platform. Not that Github is bad but I
> think that pagure.io will be good place as well.
>
> COPR
On Tuesday, October 11, 2016 8:21:15 AM CEST Miroslav Suchý wrote:
> 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.
I guess I understand;
On Tuesday, October 11, 2016 8:11:16 AM CEST Mikolaj Izdebski wrote:
> Since there are no scratch builds in Copr, "testing builds" need to be
> simulated by building in separate Copr project, with appropriate repos
> added and createrepo disabled. Doing "real builds" is almost the same
> thing.
Re-citing Mikolaj's comment:
| Sounds like you are asking for Koschei for Copr.
| We are working on first bits of integration right now.
| See: https://github.com/msimacek/koschei/issues/113
On Friday, October 7, 2016 5:29:21 PM CEST cl...@redhat.com wrote:
> I am very much asking for that.
On Monday, October 10, 2016 11:55:48 PM CEST Michal Novotny wrote:
> The lighttpd aliases/redirects will be good to keep copr project's baseurls
> with *rawhide* in it working. You might want to use those.
I still don't get it, even the resolution of the bugzilla from this
thread...
The question
Hi Michal,
On Monday, October 10, 2016 4:39:11 PM CEST Michal Novotny wrote:
> The current state is that 'rawhide' is going to be renamed to f26.
>
> I'll additionally setup aliases (or redirects) from
>
> /results/*/*/fedora-rawhide-$basearch/ *to* /results/*/*/fedora-26-$basearch/
>
> so that
SSIA, WDYT?
___
copr-devel mailing list -- copr-devel@lists.fedorahosted.org
To unsubscribe send an email to copr-devel-le...@lists.fedorahosted.org
On Thursday, October 6, 2016 6:34:02 PM CEST Mikolaj Izdebski wrote:
> On 10/06/2016 06:30 PM, Pavel Raiskup wrote:
> > On Thursday, October 6, 2016 8:55:29 AM CEST Miroslav Suchý wrote:
> > RFE2: It would be nice to have a possibility (opt-in) to do package
> > rebuilds a
On Friday, September 23, 2016 1:30:41 PM CEST Miroslav Suchý wrote:
> Dne 23.9.2016 v 12:44 Pavel Raiskup napsal(a):
> > Why can't we differ?
>
> Because it adds more maintenance overhead.
ATM there is maintenance overhad on our side same as on your side, IIUC. While
simple pa
On Friday, September 23, 2016 11:03:27 AM CEST Miroslav Suchý wrote:
> 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 gi
On Thursday, September 22, 2016 7:40:08 AM CEST Michal Novotny wrote:
> On Wed, Sep 21, 2016 at 3:32 PM, Pavel Raiskup <prais...@redhat.com> wrote:
> > :) Consider that others consume Copr sources ...
> >
> > > What is important for me is not important for you a
On Thursday, September 22, 2016 9:39:34 AM CEST Jean-Marc Liger wrote:
> > 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.
>
> To be completeness, you have both centos and epel
t'
>
> This was very likely Rawhide to F24 conversion. That's how F24
> directories got created on backend. That's why branches in dist-git
> are not present because their creation was not part of the conversion.
>
> clime
>
>
> On Wed, Sep 21, 2016 at 3:07 PM, Pavel R
Top-post did not help anybody here .. I don't think I called about restrictions.
I have a feeling that there will be new branches in future and even now it is
not really tidy. But to be honest, I don't understand your answer, are we able
to change the branch naming? And mock naming?
Pavel
On
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
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
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]
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
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
On Tuesday, August 30, 2016 7:39:14 AM CEST Pavel Raiskup wrote:
> Currently it looks like such error-handling is not implemented anyway,
> we drop the build and it is re-submitted after some deadline.
By "drop" here I mean that the build simply fails on BE, while it is still
in
On Friday, August 26, 2016 4:15:50 PM CEST Michal Novotny wrote:
> On Fri, Aug 26, 2016 at 3:46 PM, Pavel Raiskup <prais...@redhat.com> wrote:
> > Because in instance I maintain, we have currently like 7 builders
> > preallocated and booted, and thus backend does
On Thursday, August 25, 2016 9:43:53 PM CEST Michal Novotny wrote:
> the queue is now maintained only in frontend and backend is served with tasks
> one by one. Workers are being spawned "on demand". Their maximum count is
> determined by configured maximum number of virtual machines that can be
>
On Thursday, August 18, 2016 1:30:57 PM CEST Michal Novotny wrote:
> 2) Waiting-queue logic has been rewritten. I believe there will be not much
> of a perceived performance improvement but we managed to cut the relevant
> code length almost by half and simplify some bits.
Hms, thanks for the
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.
>
>
On Friday 06 of May 2016 14:22:28 Miroslav Suchý wrote:
> I am just sending more than 70 000 tasks to production instance of Copr. Why?
> Because of:
>
> http://miroslav.suchy.cz/blog/archives/2016/04/21/wip_rebuilding_all_pypi_modules_as_rpm_packages/index.html
> I'm throttling the speed and
On Tuesday 22 of March 2016 14:36:57 Antonio Trande wrote:
> tarball is downloaded from upstream directly
> http://mumps.enseeiht.fr/MUMPS_5.0.1.tar.gz
>
> However, it's correctly extracted with 'rpmbuild' and in 'koji'.
So you claim all those [1] MUMPS_5.0.1.tar.gz files (all having different
On Friday 12 of February 2016 17:14:47 Sérgio Basto wrote:
> Have we any simple copr setup and configuration ? , I thought that have
> some simple documents on internet but can't find it .
>
> only https://git.fedorahosted.org/cgit/copr.git/tree/copr-setup.txt
Based on this document I have been
On Wednesday 27 of January 2016 11:04:43 Pierre-Yves Chibon wrote:
> > This is ipv6 issue. I was told that "Happy Eyeballs" could help here;
> > that is:
> > https://github.com/python/asyncio/issues/86
> >
> > Or switch to PyCURL (this should be more robust solution).
>
> But this is an asyncio
Previously, if backend started a bit faster than job-grabber, it
was fine, but the other way around (because job-grabber is
prerequisite for backend in service file):
1. Job Grabber started
2. JobGrabber took the list of tasks
3. JobGrabber filled the redis task queue && and filled its
---
backend/backend/daemons/backend.py | 11 ++-
backend/backend/daemons/job_grab.py | 7 ---
backend/backend/frontend.py | 9 ++---
backend/run/copr_run_job_grab.py| 4 +---
4 files changed, 17 insertions(+), 14 deletions(-)
diff --git
[PATCH 1/2] [python] fix wrong check for list instance
Left untouched.
[PATCH 2/2] [cli] add --config option
This fixes a bit the copr wrapper and the manual page.
Pavel
___
copr-devel mailing list
copr-devel@lists.fedorahosted.org
---
python/copr/client/client.py | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/python/copr/client/client.py b/python/copr/client/client.py
index 79f233f..846017b 100644
--- a/python/copr/client/client.py
+++ b/python/copr/client/client.py
@@ -475,7 +475,7 @@ class
---
cli/copr | 25 +
cli/copr_cli/main.py | 9 ++---
2 files changed, 31 insertions(+), 3 deletions(-)
create mode 100755 cli/copr
diff --git a/cli/copr b/cli/copr
new file mode 100755
index 000..a119b23
--- /dev/null
+++ b/cli/copr
@@ -0,0 +1,25 @@
Users are always able to turn the internet connection ON, but only
when *necessary*. This should be good default safety belt for
unintentional downloads during package-build which could
compromise build results. This should affect only newly created
projects.
---
---
backend/copr-backend.spec | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/backend/copr-backend.spec b/backend/copr-backend.spec
index 559a97b..e5e1b92 100644
--- a/backend/copr-backend.spec
+++ b/backend/copr-backend.spec
@@ -171,7 +171,7 @@ cp -a
---
backend/copr-backend.spec | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/backend/copr-backend.spec b/backend/copr-backend.spec
index 50f350f..559a97b 100644
--- a/backend/copr-backend.spec
+++ b/backend/copr-backend.spec
@@ -1,4 +1,4 @@
-%if 0%{?rhel} < 7 && 0%{?rhel} > 0
On Monday 16 of February 2015 11:00:29 Rex Dieter wrote:
Miroslav Suchy wrote:
Technically dist tag *is* part of release number.
I, for one, much appreciate this new feature of showing the release tag
/me appreciates it too! But do you find useful also the %dist tag part of
release tag?
201 - 296 of 296 matches
Mail list logo
