What's up with koschei?
by Fabio Valentini
Hi everybody,
I've noticed that koschei doesn't seem to have scheduled any scratch
builds since around the fedora 32 mass rebuild, and it also hasn't
picked up the f32 branch yet.
Is there a known "outage" or is it just sitting there idle for some
reason? I really like to know when my packages start to FTBFS ...
Fabio
4 years, 2 months
Change proposal discussion - Optimize SquashFS Size
by David Cantrell
https://fedoraproject.org/wiki/Category:Changes/OptimizeSquashFS
In today's FESCo meeting (03-Feb-2020), we discussed this change proposal.
Being the engineering steering committee, we all had our own ideas and
opinions about what the problem is and how best to approach it. After
discussion, we agreed there are different goals related to this change
proposal and we as a community should agree on the goals and their priorities
before moving on to the implementation details.
The goals identified:
1) Reduce the ISO image size.
2) Improve installation time.
3) Improve image composition time.
We want input from the community on what the main goal should be and
prioritize the rest. For example, is ISO reduction size more important than
improving installation time, for instance? If so, why?
Thanks,
--
David Cantrell <dcantrell(a)redhat.com>
Red Hat, Inc. | Boston, MA | EST5EDT
4 years, 2 months
copr builds for rawhide 64-bit arches failing
by Alexander Ploumistos
Hello,
I am trying to build a package in copr, but rawhide builds for
aarch64, ppc64le and x86_64 fail with the following message in
root.log:
DEBUG util.py:689: Executing command: ['btrfs', 'subv', 'list',
'/var/lib/mock'] with env {'TERM': 'vt100', 'SHELL': '/bin/sh',
'HOME': '/builddir', 'HOSTNAME': 'mock', 'PATH':
'/usr/bin:/bin:/usr/sbin:/sbin', 'LANG': 'en_US.UTF-8'} and shell
False
DEBUG util.py:596: ERROR: not a btrfs filesystem: /var/lib/mock
DEBUG util.py:596: ERROR: can't access '/var/lib/mock'
DEBUG util.py:744: Child return code was: 1
DEBUG util.py:1580: Please ignore the error above above about btrfs.
I've already resubmitted the builds a couple of times, but they fail
in the exact same way. All other fedora versions and architectures
have no such problem.
Any ideas?
Best regards,
Alex
4 years, 2 months
CPE Weekly: 2020-02-14
by Aoife Moloney
# CPE Weekly: 2020-02-14
Background:
The Community Platform Engineering group is the Red Hat team combining
IT and release engineering from Fedora and CentOS. Our goal is to keep
core servers and services running and maintained, build releases, and
other strategic tasks that need more dedicated time than volunteers
can give.
For better communication, we will be giving weekly reports to the
CentOS and Fedora communities about the general tasks and work being
done. Also for better communication between our groups we have
created #redhat-cpe on Freenode IRC! Please feel free to catch us
there, a mail has landed on both the CentOS and Fedora devel lists
with context here.
## Fedora Updates
### Data Centre Move
By June 15th 2020, dedicated Fedora servers will have moved to a new
data centre in Northern Virginia.
If you want to read more, check out our post on hackmd:
https://hackmd.io/@Ap8CkTlpSfmjb44UGV-kWA/rJsk7A-QL
Here are some key dates and actions we need you to know:
* On 28th Feb, the old OpenStack instance in Fedora Cloud will be retired.
* Please reach out to Kevin before 25th Feb if you need to take action
for your instance if you are an instance owner. Here is the link to
the current status: https://pagure.io/fedora-infrastructure/issue/8614
* On 13th April, the CPE team will begin to ship servers to our new
data centre - this does not affect F32 distribution or release
* From March 1st, the CPE team will begin to build the Minimum Viable
Fedora infrastructure in the new datacenter
* Between May 20th - July 1st, we will be redirecting Fedora services
to run on the 'MVF' offering to facilitate the final part of the move
and allow for re-racking and testing
* By July 1st we hope to have BAU (business as usual) for Fedora infra
### AAA Replacement
This project is replacing our old existing fas (fedora account system)
with a new freeipa based system.
* Check out our blog on the teams progress to date!
* You can also see our jira board for tickets we are working on
* And we have an IRC channel - #fedora-AAA
* We are currently working on the FreeIPA API integration and the
folks at FreeIPA have been really helpful so far to work with
### CI/CD
* The team have been trying to get a local instance of Koji running this week
* They are investigating different algorithms that could help generate
the next release if a package based on its git history.
* Monitoring-gating is being deployed in OpenShift in staging
### Sustaining Team
* The team meets daily @ 1900 UTC in #fedora-admin on IRC
* The priority work is:
** Fedora 32
** Assisting with technical debt to facilitate the colo move
** mbbox upgrading
** CentOS CI OpenShift upgrading
* The team also have a public thread on knowledge sharing,
https://lists.fedoraproject.org/archives/list/infrastructure@lists.fedora...
so take a look!
## Docs
* Merged https://pagure.io/fedora-docs/quick-docs/pull-request/175
* Merged https://pagure.io/fedora-docs/quick-docs/pull-request/174
* Merged https://pagure.io/fedora-docs/quick-docs/pull-request/173
* Merged https://pagure.io/fedora-docs/quick-docs/pull-request/167
* Reviewed https://pagure.io/fedora-docs/install-guide/pull-request/40
* Also work underway on CentOS 8.1 docs
### Misc Updates
* The team are also working on creating Fedora infra application map -
stay tuned for the publication soon!
* keys.fedoraproject.org has been turned off
* boot.fedoraproject.org will be retired this week
* Certs have been changed to letsencrypt for fedorahosted/fedoracommunity
* Moved Koji calls to a backend task worker in Bodhi:
https://github.com/fedora-infra/bodhi/issues/3061
* kdreyer's playbook repo has been integrated:
https://pagure.io/koji-vagrant/pull-request/1
* Testing dist-git repo as a submodule has been added:
https://pagure.io/koji-vagrant/pull-request/2
* Ticket in Monitor-Gating has been reviewed:
https://pagure.io/fedora-ci/monitor-gating/pull-request/8
## CentOS Updates
### CentOS
* Tuning/adding more mirrorlist servers due to EC2/AWS change from last week
* Updates are really faster now for CentOS users in AWS/EC2 (more
than 100TiB of updated packages served internally with a 98.33% ratio
served from cache, so faster than ever)
* Moving data from CentOs Infra and switching to a new solution for
backup for infra:
* https://github.com/CentOS/ansible-role-centos-backup/
* https://github.com/CentOS/ansible-role-restic
* VDO (https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/7/...)
* Investigating how to incorporate CentOS auth into the new AAA solution
* We'll need proper communication plan to ask everybody to get a
FAS account when we'll migrate
### CentOS Stream
* The CPE team are collaborating with the Packit team internally to
develop a workflow for contributor patches
* We are working towards demoing a contributor patch from submission
to end for Red Hat Summit in April!
As always, feedback is welcome, and we will continue to look at ways
to improve the delivery and readability of this weekly report.
Have a great weekend!
Aoife
--
Aoife Moloney
Product Owner
Community Platform Engineering Team
Red Hat EMEA
Communications House
Cork Road
Waterford
4 years, 2 months
RFC: Security policy adjustments to make it easier to implement and
more friendly to maintainers
by Miro Hrončok
Hello, Fedora has an approved security policy since September 2018 [0]:
> If a CRITICAL or IMPORTANT security issue is currently open
> against a package, or a security issue of lower severity has been
> open for at least 6 months, four weeks before the branch point a
> procedure similar to long-standing FTBFS will be triggered
> immediately, with 8 weeks of weekly notifications to maintainers and
> subsequent orphaning and then subsequent removal from distribution.
> This applies to all packages, not just leaf.
I have decided to have a look into this, since this has been approved more than
a year ago and nothing ever happened since. Fedora has a very big pile of open
CVE bugzillas [2].
There are several things I'd like us to consider based on the experience from
the FTBFS policy adjustments [1] before I go implement stuff:
A. It's easier to **orphan** packages soon, retire later -- this allows the
dependent package owners to notice the breakage and possibly adopt the packages
themselves if needed while gives very little room for "cheating".
B. Getting this done on a certain point in the release schedule is complicated
and requires a lot of planning and focus -- if we miss the window, nothing can
change until the next release. We have missed the window 3 times already.
C. Also because of the fixed date, the CRITICAL or IMPORTANT security issues
have no response time, if you get a new one at a certain point, the package is
immediately treated as problematic, while getting it 1 day later, there is a 6
month period where no action is required.
I'd like to adjust the policy before I go implement some tooling around this.
This is vague proposal of what I think would work easier for both "the
executioner" and the affected maintainers:
1. We automatically send reminders to NEW security bugzillas (as with FTBFS)
2. BZs that remain in NEW state for X reminders: pkg is orphaned
3. BZs that remain not CLOSED for Y months: pkg is retired (with notifications)
Point 2 makes it so that only a couple remaining packages actually need to
survive unfixed to point 3. Hence, point 3 can happen at a certain point in the
schedule with less severe impact of points B and C -- and if we miss the window,
we still have point 1 happening.
The bugzilla reminders are sent every third calendar week (every week is too
disturbing).
Here is an initial (albeit randomly generated) proposal of X and Y:
severity CRITICAL/HIGH MEDIUM LOW
X 2 4 6
Y 2 4 6
Note that X=1 effectively means anything from 1 second to 3 weeks, X=2 means
anything from 3 weeks (+1 second) to 6 weeks. Hence, we cannot orphan packages
after just 1 reminder.
I've made it so that X always equals to Y and every lower level is +2, to make
it easier to document, understand and remember, however this is not required.
For this example a critical/high CVE would get a reminder every third calendar
week. After two reminders (that is after 3-6 weeks), if still in NEW state,
package is orphaned. The maintainer (and others) still have extra 6 weeks to
claim it.
If the bug is ASSIGNED, MODIFIED, etc., the package may be retired after 2
months, but that only happens regularly at a certain point in the schedule.
Similarly, a package with a medium CVE NEW bugzilla would be orphaned after 4
reminders (after 9-12 weeks), retired at a point if still not CLOSED after 4 months.
With low severity, that is 6 reminders (after 15-18 weeks), retired at a point
if still not CLOSED after 6 months (similarly to the current policy).
Please share your feedback, before I proceed with this to FESCo.
If somebody would be interested in maintaining this procedure, I'd be happy to
hand over that responsibility to anybody who is willing to help.
The idea is to start with semi-automation and have something -- currently we had
hoped for fully automated and we have nothing.
[0] https://pagure.io/fesco/issue/1935
[1] https://pagure.io/fesco/issue/2244
[2] https://mivehind.net/2020/01/28/Fedora-has-too-many-security-bugs/
--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
4 years, 2 months
How to write License field for packages bundling mutliple others
by Igor Gnatenko
In Rust world we package all crates as source code in -devel packages.
Then we use them to build the real applications.
Some time ago, someone noticed that we don't put licenses of those
-devel packages into a resulting RPM with app which is fair.
However, I'm not entirely sure how to properly write the License tag.
What should be there if -devel packages have:
* ASL 2.0
* ASL 2.0 or Boost
* ASL 2.0 or MIT
* ISC
* MIT
* (MIT or ASL 2.0) and BSD
* Unlicense or MIT
Is it correct to put License: ISC and MIT and ASL 2.0 and BSD?
4 years, 2 months