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
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
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,
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,
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
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
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
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
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
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
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
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
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:
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
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
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
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
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,
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
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:
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
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
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
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
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
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
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:
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
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
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
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ý
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
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
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
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:
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
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
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
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
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,
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
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 -- c
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
FYI:
This is thesis on topic how to verify rpm signatures using DNSsec:
https://www.vutbr.cz/en/students/final-thesis?zp_id=110044_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
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
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/
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
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
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
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
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
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
>
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
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
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
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
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
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??
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
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,
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
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 --
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
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
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
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
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
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
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,
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.
--
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
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
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
Dne 9.5.2016 v 09:44 Jason Woods napsal(a):
> Looks there might be an issue.
>
> https://copr.fedorainfracloud.org
>
> I've had builds queued for about 12+ hours now and it seems it's only running
> @copr builds. I've not seen more 6 run at any time too so maybe an issue with
> the limiting?
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 I am sending one task each 15 seconds. So it will
take 12 days
Hi,
today I released new version of Copr.
There is
* lot of bugfixes. Mainly related to group projects.
* fix related to generation of GPG keys (see email on fedora devel mailing
list).
* performance improvements for projects with 5+ builds
* copr-dist-git machine has been migrated to Fedora
Dne 26.4.2016 v 15:37 Pavel Raiskup napsal(a):
> I must give +1 to the feature which would allow us to trigger build by
> webhook against git repository having spec file (while downloading of the
> sources would have be done automatically, `spectool *.spec -S`). This
> should of course be
I am very sorry.
Today Lubos K. accidentally submitted 10k packages to Copr. I wanted to run one
simple SQL query to set all those builds
as failed. Unfortunately I made big mistake - I forgot to add one column to
'where' condition. As result of this error
*all* builds were marked as failed.
Dne 23.3.2016 v 14:06 Ting-Wei Lan napsal(a):
> I use 'copr-cli build -r' separate ppc64le builds and non-ppc64le
> builds now. Non-ppc64le builds are still submitted when new updates are
> released, but ppc64le builds are only submitted once a week. I hope it
> is much less possible for my
Dne 21.3.2016 v 16:22 Antonio Trande napsal(a):
> This does not happen on koji or in local.
> Copr project:
> http://copr-fe.cloud.fedoraproject.org/coprs/sagitter/Ipopt-EPEL/build/169990/
404 Not found.
If you want me to debug it, then please do not delete the build.
--
Miroslav Suchy, RHCA
Dne 12.3.2016 v 19:59 Benji Wiebe napsal(a):
> In my COPR project benjiwiebe/serverstuff, I have a build from 42 days ago
> that never shows pending/importing/running,
> it always shows "unknown". And I cannot delete it. The build number is
> 156906. I'd appreciate if someone could help me
>
Dne 9.2.2016 v 00:40 Jan Holčapek napsal(a):
> Hello there,
>
> since I'm new to Copr, and could not find answers in [1], particularly in
> section [2], I'm seeking help here.
>
> First things first: did I actually get it right it's possible to build SRPM
> and binary RPMs off git URL
Dne 19.2.2016 v 09:37 Jean-Marc LIGER napsal(a):
> I've tried to configure copr repositories directly with yum but there is no
> yum-plugin-copr in EPEL-7.
IIRC Valentina created and maintains this plugin. I guess that no one was
interested in. Please file bugzilla report
against
Hi,
based on discussion inside of the team I moved our git to github.
New location is:
https://github.com/fedora-copr/copr
All you need to do is to run:
git remote set-url origin g...@github.com:fedora-copr/copr.git
in your copr.git.
I gave all active members write right there. If I omitted
Dne 12.2.2016 v 18:14 Sérgio Basto napsal(a):
> Hello ,
>
> 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
Yes. This is main documentation
Dne 27.1.2016 v 09:55 Pavel Raiskup napsal(a):
> This is ipv6 issue.
Yes.
This is direct result of redirect of copr.fedoraproject.org to
copr.fedorainfracloud.org.
Because copr.fedoraproject.org is now CNAME for wildcard.fedoraproject.org,
which is reverse proxy and HAS IPv6 address.
However
Dne 14.1.2016 v 23:32 Pavel Raiskup napsal(a):
> Is it expected Copr services could (backend/frontend, I am aware dist-git
> machine already does) be run on CentOS 7? I was seriously thinking about
> it some time ago, I've done some downstream changes, but after some time
> those are not useful
Dne 7.1.2016 v 12:30 Pavel Raiskup napsal(a):
> 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
Fedora 21 is EOLed for one month. I plan to remove from Copr in 14 days too.
All builds will be preserved. You will not be able to submit new builds for F21.
Please update your scripts accordingly.
--
Miroslav Suchy, RHCA
Red Hat, Senior Software Engineer, #brno, #devexp, #fedora-buildsys
Fedora 21 is EOLed for one month. I plan to remove from Copr in 14 days too.
All builds will be preserved. You will not be able to submit new builds for F21.
Please update your scripts accordingly.
--
Miroslav Suchy, RHCA
Red Hat, Senior Software Engineer, #brno, #devexp, #fedora-buildsys
I just deployed in production new version of Copr.
It is mostly bugfix release.
It contains one new feature, but it has some performance issues so I'm not
going to announce it yet. If you discover it,
then feel free to test it, but do not use it too much :)
--
Miroslav Suchy, RHCA
Red Hat,
Dne 21.7.2015 v 12:45 Sérgio Basto napsal(a):
Just to alert you that some build are waiting for 2 days on ppc64le
https://copr.fedoraproject.org/status/waiting/
Best regards,
I poked it and it is running now.
--
Miroslav Suchy, RHCA
Red Hat, Senior Software Engineer, #brno, #devexp,
Hi,
we plan to do migration of Copr today and tomorrow. So there may be some
outages and the queue of builds may stop
processing. I kindly ask you with patience.
Detailed plan (may be subject to change):
1. Migrate Copr frontend today afternoon.
2. Migrate Copr backend and key signing machine
On 03/23/2015 04:51 PM, Greg Sheremeta wrote:
Is there a way to force a rebuild of a specific version?
I'm trying to rebuild this, but it's skipping because it was previously built.
However, that previous build was bad and I deleted it.
You must delete the successful build:
I just added F22 chroot to Copr.
--
Miroslav Suchy, RHCE, RHCDS
Red Hat, Senior Software Engineer, #brno, #devexp, #fedora-buildsys
___
copr-devel mailing list
copr-devel@lists.fedorahosted.org
https://lists.fedorahosted.org/mailman/listinfo/copr-devel
Hi,
Fedora 19 is EOLed. Therefore I plan to disable building for Fedora 19 in Copr
by end of this month.
If want to build something for F19, you have last chance.
By end of the month new builds for F19 will not be allowed. However existing
yum repos for F19 will be preserved.
--
Miroslav Suchy,
On 01/05/2015 03:31 PM, Valentin Gologuzov wrote:
New year with a new Copr release!
Visible changes:
- Now repository metadata generation can be disabled and executed upon
request (BZ 1150954). This feature primary
targets owners of big repositories.
- Repeat build button respects
97 matches
Mail list logo
