Yesterday, we deployed a new version of Copr. Because the new version is quite major I'm re-sending it here as well.
First we migrated to new Fedora Cloud instance, which give us more reliable infrastructure.
Previously we used 12 builders, but due problems with old OpenStack we were forced to lower it to 6 builders.
Today we are back to 12 builders and we are ready to increase the limit .
We are monitoring the new instance and we will very likely increase the number of builders to 20 soon. This should be
enough for some time.
Second change is reuse of VM. If builder finishes building of your package and there is in queue some other task from
you, then it is picked up and build on the same VM without re-provisioning of that VM. The logic is that you probably do
not want to do cracking of your own packages, so we can reuse that VM for yours packages. Packages are still build in
different chroot, but the same machine. Of course - if there is only packages of another users in the queue, then the
builder VM is terminated and clean one VM is spin up.
Last change is limitation of users. If you send dozens of task to Copr, then you are limited to just 4 parallel builds.
Other builders are used for other users next in queue.
Because we have more resources available. I recall that there we some use case where you requested more memory or disk.
However I could not find the details. If you have such use case, now is right time to contact me as I can increase the
limits if there is good reason.
Oh and I forgot that we have new storage for your repositories. Previously we had just 800 GB and we were reaching the
roof. On new location we have 4TB and it can be extended if needed.
And the conclusion? You should expect less delay. Not being blocked by other users.
And I can finally say, what I wanted to say for long time: Please use Copr more! You can even set up builds in Copr
after each commit in your project and Copr should handle that. Hopefully this will allow you to set up Continuous
Integration on your project, or make it even better.
 During testing of new cloud we tried to spawn enormous numbers of builders and it seems that number 200 is our hard
Miroslav Suchy, RHCA
Red Hat, Senior Software Engineer, #brno, #devexp, #fedora-buildsys
Today at Fedora 22 Final Go/No-Go meeting it was decided that Fedora 22
Final is No-Go. More details in meeting minutes .
As both bugs we accepted as blocker bugs today are already fixed and RC3
compose is requested, we will try to sign-off the final release tomorrow.
If you are willing to help with release validation, follow standard
channels for RC3 announcement.
The next Go/No-Go meeting is on Friday, May 22 17:00 UTC #fedora-meeting-2
test-announce mailing list
Following is the list of topics that will be discussed in the FPC
meeting Thursday at 2015-05-21 16:00 UTC in #fedora-meeting-1 on
Local time information (via. rktime):
2015-05-21 09:00 Thu US/Pacific PDT
2015-05-21 12:00 Thu US/Eastern EDT
2015-05-21 16:00 Thu UTC <-
2015-05-21 17:00 Thu Europe/London BST
2015-05-21 18:00 Thu Europe/Paris CEST
2015-05-21 18:00 Thu Europe/Berlin CEST
2015-05-21 21:30 Thu Asia/Calcutta IST
2015-05-22 00:00 Fri Asia/Singapore SGT
2015-05-22 00:00 Fri Asia/Hong_Kong HKT
2015-05-22 01:00 Fri Asia/Tokyo JST
2015-05-22 02:00 Fri Australia/Brisbane EST
Links to all tickets below can be found at:
= Followups =
#topic #281 New Python Macros for Easier Packaging
#topic #508 New GID for openstack-neutron
#topic #513 Use python -Es in shbang
= New business =
#topic #531 Discuss guidelines for use of weak dependencies
= Open Floor =
For more complete details, please visit each individual ticket. The
report of the agenda items can be found at:
If you would like to add something to this agenda, you can reply to
this e-mail, file a new ticket at https://fedorahosted.org/fpc,
e-mail me directly, or bring it up at the end of the meeting, during
the open floor topic. Note that added topics may be deferred until
the following meeting.
#fedora-meeting: FESCO (2015-05-20)
Meeting started by ajax at 18:00:11 UTC. The full logs are available at
* init process (ajax, 18:00:15)
* #1441 Packaging: Practices for Migration of cron jobs to systemd
timer units (ajax, 18:05:10)
* AGREED: packages in fedora have their default timer unit settings
managed by system presets and not by their providing package (+6,
-0) (ajax, 18:28:53)
* timer unit settings recommendation to be double-checked with fpc
* LINK: https://fedoraproject.org/wiki/Starting_services_by_default
also should be updated to reflect new reality. Apart from the
obvious s/systemd/fedora-release/, both services and timers which
require or not FESCo exception need to go through the global
file. (zbyszek, 18:29:47)
* sgallagh to bring timer unit issue to fpc (ajax, 18:30:13)
* ACTION: sgallagh to work with FPC on updating
* Open Floor (ajax, 18:30:48)
* ACTION: nirik to chair next week (ajax, 18:33:08)
* Please test RC2! (ajax, 18:41:13)
Meeting ended at 18:41:28 UTC.
* sgallagh to work with FPC on updating
* nirik to chair next week
Action Items, by person
* nirik to chair next week
* sgallagh to work with FPC on updating
People Present (lines said)
* sgallagh (45)
* ajax (37)
* nirik (25)
* thozza (25)
* lnykryn (13)
* dgilmore (8)
* zodbot (6)
* mattdm (6)
* paragan (4)
* jwb (4)
* zbyszek (2)
* rishi (0)
* mitr (0)
Generated by `MeetBot`_ 0.1.4
.. _`MeetBot`: http://wiki.debian.org/MeetBot
18:00:11 <ajax> #startmeeting FESCO (2015-05-20)
18:00:11 <zodbot> Meeting started Wed May 20 18:00:11 2015 UTC. The
chair is ajax. Information about MeetBot at
18:00:11 <zodbot> Useful Commands: #action #agreed #halp #info #idea
18:00:11 <ajax> #meetingname fesco
18:00:11 <zodbot> The meeting name has been set to 'fesco'
18:00:11 <ajax> #chair ajax dgilmore jwb mitr nirik paragan rishi
18:00:11 <zodbot> Current chairs: ajax dgilmore jwb mitr nirik paragan
rishi sgallagh thozza
18:00:15 <ajax> #topic init process
18:00:20 <nirik> morning
18:00:34 <sgallagh> .hello sgallagh
18:00:35 <zodbot> sgallagh: sgallagh 'Stephen Gallagher' <
18:00:42 <ajax> (waiting a moment for people to join)
18:01:16 <paragan> Hi
18:02:05 <thozza> hi all
18:03:16 <mattdm> hi!
18:03:18 * mattdm lurks
18:03:54 <ajax> i count five, which is a majority, but perhaps not
18:04:22 <sgallagh> ajax: five is quorum
18:04:29 <ajax> oh indeed
18:04:39 <sgallagh> Though it means that any decision made has to be
18:04:42 <mattdm> it just becomes concensus :)
18:04:54 <sgallagh> Which we always strive for anyway
18:05:06 <ajax> well, let's start and people can catch up
18:05:10 <ajax> #topic #1441 Packaging: Practices for Migration of
cron jobs to systemd timer units
18:05:17 <ajax> .fesco 1441
18:05:18 <zodbot> ajax: #1441 (Packaging: Practices for Migration of
cron jobs to systemd timer units) – FESCo -
18:05:36 <dgilmore> hey
18:05:39 <jwb> hi
18:06:09 <thozza> The bottom line is if we want to handle timer units
any different from other types of units
18:06:36 <thozza> it makes migration from cron jobs more painful, but
it keeps the defaults more consistent
18:06:36 <nirik> I guess the conclusion we came to was... no?
18:06:41 <sgallagh> So, the only problem with the centrally-managed
presets is third-party software. Are such packages just expected to
manage themselves in %post?
18:07:23 <thozza> I think as long as they are not included in Fedora
repos, do we care?
18:07:30 <lnykryn> they should ship their own preset file
18:07:37 <sgallagh> thozza: Well, COPR makes the question fuzzy
18:08:18 <sgallagh> lnykryn:
18:08:19 <thozza> sgallagh: right, but those packages can do stuff that
does not completely comply to packaging guidelines
18:08:42 <sgallagh> thozza: Right, but I'd still like to have
recommendations exist on how to behave
18:09:13 <thozza> ok, I'm not opposed to that, however I was more
concerned about the packages included in Fedora repos
18:09:14 <sgallagh> lnykryn: Short version: a package shipping its own
preset is fundamentally identical to managing itself in %post
18:09:21 <nirik> I'd say they handle it in %post yeah
18:09:25 <lnykryn> sgallagh: it is not
18:09:27 <sgallagh> Because the admin can't configure it before the
package is installed
18:09:57 <lnykryn> admin can still deny for all unit files to enable
18:10:16 <sgallagh> lnykryn: No, because %post can just call 'systemctl
18:10:26 <sgallagh> It's running as root
18:10:39 <thozza> sgallagh: I think lnykryn means the situation with
18:10:43 <lnykryn> I was speaking about the case where package ship its
own unit file and calls preset
18:10:57 <sgallagh> lnykryn: Can that be restricted?
18:11:15 <lnykryn> sgallagh: sure we are looking for the first match
18:11:27 <lnykryn> so you can ship conf with lower number and some glob
18:11:35 <thozza> lnykryn: the package can install preset that will be
18:11:45 <lnykryn> sure it can
18:12:05 <lnykryn> but that is a corner case
18:12:12 <nirik> I'm not sure that helps too much really.
18:12:24 <thozza> so in the end it depends how the preset file is named
18:12:33 <lnykryn> yes they are numbered
18:12:37 <sgallagh> Also, putting a glob early in the process will
likely break everything else :(
18:12:51 <lnykryn> if you know what you are doing ...
18:13:45 <nirik> well, if we are talking about packages not in fedora,
who knows... they can do anything at all.
18:13:48 <thozza> so to make use of own presets in comparison to %post,
the admin would have to do things, that would most probably break his
18:13:50 <sgallagh> Yeah
18:14:20 <thozza> I think that his is kind of out of scope to decide
18:14:21 <lnykryn> no there is still the use-case that admin wants to
have every new service disabled by default
18:14:38 <thozza> lnykryn: which we just discussed
18:15:00 <sgallagh> lnykryn: Right, but I don't think it's actually
possible to do that (reliably) just with presets.
18:15:02 <nirik> unless everyone agrees to some convention there, it's
not likely to work
18:15:10 <sgallagh> I think that would need to be a different systemd
18:15:29 <ajax> i mean, systemd controls the world, it could shove rpm
into a cgroup where systemctl enable didn't work.
18:15:36 <ajax> right?
18:15:54 <ajax> but failing that i think some spec convention and qa
assurances are the best we can do
18:15:57 <nirik> or you could install your new stuff with --noscripts.
18:16:09 <nirik> but I think we are going far afield
18:16:11 <sgallagh> nirik: No one would do that.
18:16:16 <thozza> so back to timer units ;)
18:16:17 <sgallagh> I like ajax's idea though
18:16:37 <ajax> right. is there a concrete proposal we should be
debating for timer units?
18:17:16 <thozza> personally I don't think that it would be that bad to
allow to ship own preset for timer unit in some cases is bad thing...
however since we moved presets to fedora-release things may work better
18:18:01 <sgallagh> OK, so first proposal:
18:18:05 * thozza reading what I wrote... I think I changed the idea in
the middle of sentence
18:18:06 <thozza> :)
18:18:17 <sgallagh> Proposal: Timer units' default state should be
managed by the system presets
18:18:26 <sgallagh> (Not by the packages installing them)
18:18:51 <nirik> ok. +1ish
18:19:17 <sgallagh> +1
18:19:17 <thozza> I agree to some extent
18:19:29 <sgallagh> Let me rephrase
18:19:59 <sgallagh> Proposal: For packages in the Fedora collection,
the default state of their timer units should be managed by the system
presets and not by the packages that contain them.
18:20:40 <nirik> sure. +1
18:20:49 <thozza> in case it will not take a month to get unit into
18:20:57 * nirik is hoping adding to presets will be reasonably
18:20:57 <ajax> +1
18:20:59 <nirik> yeah.
18:21:36 <paragan> sorry if I missed in above discussion but can
someone tell what is problem if individual packages allowed to change
18:21:49 <sgallagh> dgilmore: Did you end up making that its own
repository or as part of fedora-release/generic-release?
18:22:03 <ajax> paragan: consistency of expectations for the admin,
18:22:07 <sgallagh> paragan:
18:22:36 <paragan> ah okay
18:23:05 <paragan> +1 to sgallagh proposal
18:23:37 <sgallagh> dgilmore: s/that/presets/ and s/repository/package/
18:24:18 <sgallagh> I think that we may want to have that be its own
package with multiple maintainers rather than fedora-release which is
painful to keep updated.
18:24:31 <sgallagh> (Also, probably a dist-git hosted package rather
than an upstream)
18:24:37 <thozza> sgallagh: I think that would speed up the process
18:24:54 <lnykryn> (by the way we already have this process in rhel and
18:25:31 <thozza> lnykryn: I think we are talking about completely
18:25:45 <ajax> i count 4 votes (me, nirik, paragan, sgallagh
implicitly transferring his +1 to his clarification)
18:25:53 <dgilmore> sgallagh: its just in fedora-release
18:25:58 <lnykryn> thozza: that was just a mention
18:26:10 <dgilmore> sgallagh: I am going to duplicate into generic
18:26:26 <thozza> I will be +1 if we make the process reasonably easy
18:26:27 * nirik notes we should get anything we decide
codified/approved by FPC too.
18:26:38 <sgallagh> nirik: Agreed
18:26:43 <thozza> moving presets to fedora-release is a good step
18:27:15 <ajax> well, i'm not a fortune teller, but i expect products
to actively participate
18:27:15 <dgilmore> I am +1 to having timers default state in system
wide preset files
18:27:17 <sgallagh> dgilmore: My recommendation is that we split it out
of fedora-release and make it into fedora-presets where we can have a
number of maintainers with access (without risking the stability of
18:27:55 <sgallagh> Maybe give commit privilege to fedora-presets to
FESCo and WG liasons
18:28:01 <dgilmore> sgallagh: honestly do not really care. as is I
think it is fine, it should be very manageable upstream will pull
18:28:12 <sgallagh> ok
18:28:30 <nirik> we can split it if it turns out to be better long
18:28:35 <sgallagh> Sure, I'm okay with leaving it as-is and revisiting
if the process becomes bogged down
18:28:53 <ajax> #agreed packages in fedora have their default timer
unit settings managed by system presets and not by their providing
package (+6, -0)
18:29:07 <thozza> I'm also OK with revisiting if needed and keeping it
as is for now ~ in fedora-release
18:29:25 <ajax> #info timer unit settings recommendation to be double
-checked with fpc
18:29:31 <ajax> someone want to handle taking this to fpc?
18:29:41 <sgallagh> /me volunteers
also should be updated to reflect new reality. Apart from the obvious
s/systemd/fedora-release/, both services and timers which require or
not FESCo exception need to go through the global presets file.
18:30:04 <sgallagh> zbyszek: Yes, thanks. I'll open an FPC ticket for
that as well
18:30:13 <ajax> #info sgallagh to bring timer unit issue to fpc
18:30:16 <ajax> sgallagh: thanks
18:30:17 <sgallagh> #action sgallagh to work with FPC on updating
18:30:29 * nirik has a timer to submit too. ;)
18:30:38 <thozza> zbyszek: I think we could generalize to any type of
18:30:39 <sgallagh> nirik: Is it the end-of-meeting-timer?
18:30:44 <ajax> just about!
18:30:48 <ajax> #topic Open Floor
18:30:59 <nirik> ha. :) spamassassin's sa-update... but sure. ;)
18:31:26 <ajax> there were a couple of other fesco tickets more recent
18:31:35 <zbyszek> thozza: yes, it applies to .sockets and anything
else which can activate services...
18:31:47 <ajax> which mostly look like they can be handled in the
18:31:52 <thozza> zbyszek: lnykryn mentioned e.g. path units and so
18:32:01 <nirik> ajax: we need a next weeks chair selection too.
18:32:09 <ajax> so, if'n people can take a look at the fesco trac,
that'd be super
18:32:16 <ajax> nirik: indeed. volunteers?
18:32:54 <nirik> I've not done it for a bit, I can.
18:33:08 <ajax> #action nirik to chair next week
18:33:13 <ajax> nirik: thanks
18:33:33 <ajax> if there are no other open issues i'll close out in a
18:34:13 <sgallagh> Just a general note: RC1 looked quite good, but we
had one blocker necessitating a respin tonight.
18:34:29 <nirik> hopefully RC2 will be a keeper.
18:34:40 <sgallagh> So this is a general request for people to help
test RC2; we expect it to be Go tomorrow at the meeting.
18:34:44 <sgallagh> Here's hoping.
18:36:46 * mattdm hopes that the ext4 issue making the blog rounds
turns out to be not a serious thing
18:37:14 <nirik> yeah. Infomation on it is so sketchy.
18:37:28 <sgallagh> I have trouble caring. I run XFS :-D
18:37:52 <sgallagh> (I'm kidding of course; I hope this doesn't bite
us, but the timing is suboptimal)
18:38:08 <sgallagh> We probably won't know for certain how bad this is
until it's too late to stop the machinery.
18:38:42 <nirik> yeah
18:39:05 <nirik> it's not super common or we would have seen more
reports... or... well, almost any
18:39:18 <dgilmore> RC2 is well underway
18:39:28 <dgilmore> it should be out this evening US time
18:39:39 <mattdm> afaik it affects mdadm raid — that just might not
have been common enough, or in the right triggering config — to get
18:40:16 <jwb> or people who are testing f22 are already running 4.0.4
from updates-testing and it's already fixed
18:40:19 <jwb> WHO KNOWS
18:40:20 <nirik> mattdm: I have a machine using raid with the
'affected' kernel with 0 problems
18:40:29 <jwb> talking about it more isn't going to result in anything
useful at this point
18:40:36 * nirik nods. stops
18:40:42 <ajax> hey, we're running off the rails!
18:40:55 * mattdm is sorry
18:41:00 <nirik> does that make this a crazy train? ;)
18:41:01 <dgilmore> so please be testing RC2 when it is out
18:41:03 <ajax> if you want #fedora-devel you know where to find it ;)
18:41:13 <ajax> #info Please test RC2!
18:41:26 <ajax> thanks all
18:41:28 <ajax> #endmeeting