GitLab AMA Topic: Message Bus
by Aoife Moloney
Hi everyone,
I hope you enjoyed the F33 release party this weekend! Getting back to
the GitLab topic mail threads, this weeks topic from the GitLab AMA
session on September 10th is on Message Bus. As always, here are some
links to the resources I have been pulling content from as well:
* Questions and Answers hackmd link https://hackmd.io/RW8HahOeR7OJPON1dwuo3w
* Chat log from session
https://meetbot.fedoraproject.org/fedora-meeting-1/2020-09-10/ama_session...
* AMA Blog post
https://communityblog.fedoraproject.org/gitlab-ama-follow-up/#more-9346
* Here is this email in hackmd if you wish to view it there:
https://hackmd.io/tfOqCXNEQtqsGNLAEfZ2zg?view
## Topic: Message Bus
- Question: Fedora uses a message bus to integrate different parts of
its infrastructure. How should we onboard GitLab into this message
bus?
- Answer: Currently we would need to have a service that proxies
GitLab’s events to fedora-messaging something similar to
github2fedmsg.
There were some concerns raised about the order of events sent by
GitLab’s webhooks, these will need to be looked after during a Proof
of Concept stage.
- Question: How would git push over http work with GitLab? (assuming
gitlab does not have Fedora's password since they are stored in FAS)
- Answer: GitLab has a good number of authentication options and
integrations where the "best" solution usually depends on a team's
specific needs and use case. As such, the best way to know and meet
Fedora's needs and use cases is to have a conversation and discuss the
options with GitLab. How does git push over HTTP work with FAS right
now, and what git push (over HTTP) auth requirements/flow would you
like to have for your projects in GitLab?
These are the only two questions and answers I could gather relating
to message bus from the AMA question sheet, however I know there was a
lot of discussion regarding this topic during the AMA session itself,
so if you would like to resume/kick off that conversation again,
please feel free to use this email to discuss.
A personal note and for full transparency: the weeks seem to be
passing in the blink of an eye lately, I assume it's because I'm
busy(?) but it might be just the weird 2020 vibe the world is on
nowadays. I really don't know. Whatever the reason, there has been no
further discussion with GitLab since early October-ish, but we will be
returning to the conversation of how this migration could be
technically possible soon, so sincerely thank you all again for
engaging with us/me here as I found reading the discussion on
permission and access much easier to follow and have been taking notes
on your expectations to use that feedback in conversations with GitLab
when we pick the discussion back up.
I hope you all had a good weekend and will talk to you all next week
when the topic of Namespace & Issue Tracking is sent!
Kindest regards,
Aoife
--
Aoife Moloney
Product Owner
Community Platform Engineering Team
Red Hat EMEA
Communications House
Cork Road
Waterford
_______________________________________________
devel-announce mailing list -- devel-announce(a)lists.fedoraproject.org
To unsubscribe send an email to devel-announce-leave(a)lists.fedoraproject.org
Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: https://lists.fedoraproject.org/archives/list/devel-announce@lists.fedora...
3 years, 6 months
Fedora 34 Change: GNU Toolchain update (gcc 11, glibc 2.33)
(System-Wide Change)
by Ben Cotton
https://fedoraproject.org/wiki/Changes/GNUToolchain
== Summary ==
Switch the Fedora 33 GNU Toolchain to gcc 11, binutils 2.35, and glibc 2.33.
The binutils 2.35 change is being tracked here:
https://fedoraproject.org/wiki/Changes/BINUTILS235
The gcc 11 and glibc 2.33 change will be tracked in this top-level GNU
Toolchain system-wide update.
== Owner ==
* Name: [[User:codonell|Carlos O'Donell]], [[User:law|Jeff Law]]
* Email: carlos(a)redhat.com, law(a)redhat.com
== Detailed Description ==
The GNU Compiler Collection, GNU C Library, and GNU Binary Utilities
make up the core part of the GNU Toolchain and it is useful to
transition these components as a complete implementation when making a
new release of Fedora.
The GNU Compiler Collection will be releasing version 11 containing
many new features documented here:
https://gcc.gnu.org/gcc-11/changes.html. Historically pre-releases of
GCC drop into Fedora in Jan/Feb just prior to the mass rebuild. The
major process change this year is the desire to drop in snapshots of
GCC 11 into rawhide starting in November with updates throughout the
Fedora 34 release process as needed.
The GNU C Library version 2.33 will be released at the beginning of
February 2020; we have started closely tracking the glibc 2.33
development code in Fedora Rawhide and are addressing any issues as
they arise. Given the present schedule Fedora 34 will branch after the
glibc 2.33 upstream release. However, the mass rebuild schedule means
Fedora 34 will mass rebuild (if required) after glibc 2.33 upstream
freezes ABI for release, but before the actual release, so careful
attention must be paid to any last minute ABI changes.
== Benefit to Fedora ==
Stays up to date with latest features, improvements security and bug
fixes from gcc and glibc upstream.
The change to drop GCC 11 snapshots into rawhide earlier is meant to
start more wide scale testing of GCC earlier. This means that package
maintainers will not be faced with a onslaught on FTBFS issues in
Feb/Mar and the GCC maintainers will not be as stressed trying to fix
all Fedora related issues in a short time frame as well.
== Scope ==
The gcc and glibc teams will need to move their respective upstream
projects to a releasable state. For GCC this includes correctly
building Fedora rawhide.
* Other developers: Developers need to ensure that gcc, binutils, and
glibc in rawhide is stable and ready for the Fedora 34 branch. Given
that glibc is backwards compatible and we have been testing the new
glibc in rawhide it should make very little impact when updated,
except for the occasional deprecation warnings and removal of legacy
interfaces from public header files. GCC is currently being tested
weekly against Fedora rawhide and fixes for issues discovered are
continually dropping into rawhide to minimize the impact on package
maintainers. However, we fully expect some issues to arise,
particularly as the GCC team's tests are limited to x86_64.
* Release engineering: [https://pagure.io/releng/issue/9858 9858] A
mass rebuild is strongly encouraged.
* Policies and guidelines: The policies and guidelines do not need to
be updated.
* Trademark approval: N/A (not needed for this Change)
== Upgrade/compatibility impact ==
<!-- What happens to systems that have had a previous versions of
Fedora installed and are updated to the version containing this
change? Will anything require manual configuration or data migration?
Will any existing functionality be no longer supported? -->
The compiler, and the the library are backwards compatible with the
previous version of Fedora.
Some packaging changes may be required for the glibc 2.33 rebase:
https://sourceware.org/glibc/wiki/Release/2.33#Packaging_Changes
Some source changes may be required for gcc 11 rebase:
https://gcc.gnu.org/gcc-11/changes.html
We fully expect to fix all packaging changes in Fedora Rawhide without
impact to the release.
== How To Test ==
The GNU C compiler collection has its own testsuite which is run
during the package build and examined by the gcc developers before
being uploaded. The GCC team also is also doing continuous testing of
GCC 11 snapshots against Fedora rawhide to identify and resolve issues
prior to new versions of GCC landing in rawhide. This work will
continue, particularly in Nov, Dec, Jan and Feb and we will use it to
help guide decisions about snapshots are stable enough to not cause
major Fedora rawhide disruptions. We expect that by March the pace of
updates will reduce significantly.
The GCC team will likely need some help addressing some of the new
diagnostics that require package specific knowledge to determine if
the code is valid or not. This is not new, but the timing will shift
to earlier points in the Fedora release cycle.
The GNU C Library has its own testsuite, which is run during the
package build and examined by the glibc developers before being
uploaded. This test suite has over 6200 tests that run to verify the
correct operation of the library. In the future may also run the
microbenchmark to look for performance regressions.
== User Experience ==
Users will see improved performance, many bugfixes and improvements to
POSIX compliance, additional locales, etc.
== Dependencies ==
All packages do not need to be rebuilt due to backwards compatibility.
However, it is advantageous if a mass rebuild is performed during the
Fedora 34 cycle.
== Contingency Plan ==
* Contingency mechanism: If gcc 11 proves too disruptive to compiling
the distribution, which is not expected, we could revert to gcc 10 for
the release. If glibc 2.33 provides too disruptive to compiling the
distribution we could revert to 2.32, but given that Rawhide has
started tracking glibc 2.33, no show-stopper problems are expected.
At this point, we can still revert to upstream version 2.32 if
insurmountable problems appear, but to do so may require a mass
rebuild to remove new symbols from the ABI/API.
* Contingency deadline: Upstream glibc ABI freeze deadline of 2021-02-01.
* Blocks release? Yes, upgrading to gcc 11 blocks the release. Yes,
upgrading glibc does block the release. We should not ship without a
newer gcc and glibc, there will be gcc and language features that
depend on glibc being upgraded. Thus without the upgrade some features
will be disabled or fall back to less optimal implementations.
== Documentation ==
The gcc manual contains the documentation for the release and doesn't
need any more additional work.
The glibc manual contains the documentation for the release and
doesn't need any more additional work.
== Release Notes ==
The GNU Compiler Collection version 11 will be released shortly. See
https://gcc.gnu.org/gcc-11/changes.html.
The GNU C Library version 2.32 will be released at the beginning of
August 2020. The current NEWS notes can be seen here as they are
added: https://sourceware.org/git/?p=glibc.git;a=blob;f=NEWS;hb=HEAD
--
Ben Cotton
He / Him / His
Senior Program Manager, Fedora & CentOS Stream
Red Hat
TZ=America/Indiana/Indianapolis
3 years, 6 months
CPE Weekly: 2020-11-22
by Aoife Moloney
Hi Everyone,
Below is this week's CPE weekly for week ending 2020-11-22 for both
Fedora & CentOS, and if you want to visit the hackmd link
https://hackmd.io/8iV7PilARSG68Tqv8CzKOQ?view you can then use the
header bar on your left to skip to Fedora or CentOS updates that
interest you.
## General Project Updates
Final project submission date for consideration in Q1 is Friday 27th
November. If you have an initiative that may take weeks/months and
multiple people to work on and want to request it to CPE, please
follow the steps outlined in our initiatives repo and create your
issue before 27th November https://pagure.io/cpe/initiatives-proposal
Our updated initative timetable can be viewed here for 2021
https://docs.fedoraproject.org/en-US/cpe/time_tables/
Below are the projects the CPE team are currently working on for the
months of October, November & December:
* CentOS Stream Phase 4 - Build system services
* Noggin Phase 4 - Data Migration of Fedora & CentOS Accounts, Community testing
* OSBS for aarch64 - this will begin in November
* Fedora Messaging Schemas - this work is continuing from Q3 and is
being worked on part-time
### Misc
#### GitLab
New GitLab topic sent to devel-announce(a)lists.fedoraproject.org &
centos-devel(a)centos.org on Message Bus is out. See email in hackmd
here
https://hackmd.io/oZrDwbSeSWO-l_X65A1ndg?view
## Project Updates
*The below updates are pulled directly from our CPE team call we have
every week.*
### Fedora
### Staging Environment
* Completed - any issues you find please report them in fedora infra
https://pagure.io/fedora-infrastructure/issues
### Noggin/AAA
* Testing team owned apps in staging with Noggin
* We will be requesting community member testing before December so
keep an eye out for an announcement!
* The teams kanban board where they track their work can be found here
https://github.com/orgs/fedora-infra/projects/6
* And we have a project tracker available to be viewed here
https://github.com/fedora-infra/aaa-tracker
### OSBS for aarch64
* Basic OKD 3.11 working on aarm64 with F31
* Working on repeating that install with F33
* Next step will be to
### Fedora Messaging Schemas
* This project is worked on on a part time basis as we are
prioritizing completing Noggin first before fully committing to its
completion
* There is a list of applications that require messaging schemas can
be found here https://hackmd.io/@nilsph/H1i8CAbkP/edit
* There is a readme which contains documentation on messaging schemas,
a cookie-cutter template to create the schema and a definition of Done
for writing a schemas
https://github.com/fedora-infra/fedora-messaging-schemas-issues
* The board they are working from can be viewed here
https://github.com/orgs/fedora-infra/projects/7
## CentOS Updates
### CentOS
* CentOS 6 is EOL 30th November
* CFP for FOSDEM Dojo - https://wiki.centos.org/Events/Dojo/FOSDEM2021
* Updated CentOS CI Openshift staging cluster to latest 4.6.4, Waiting
for stable release in the 4.6 branch before rolling out to production.
* CentOS 7.9.2009 is released! (for x86_64, i386, ppc64, ppc64le,
armhfp and aarch64 architectures)
* Lot of work done for Noggin/AAA
### CentOS Stream
* Use centos-stream-release package to convert from CentOS 6 to CentOS
Stream before 30th November
* Working on integrating ODCS in Stream
* Curating out t_functional suite
https://github.com/centos/sig-core-t_functional
* Refining our testing for finding issues at distro-level
## Team Info
### CPE Product Owner Office Hours
IRC office hours are now once per month.Below are the logs from the
most recent meetings and dates for the next ones.
#### #fedora-meeting-1
* Next Meeting: 2020-12-17 @ 1300 UTC on #fedora-meeting-1
#### #centos-meeting
* Next Meeting: 2020-12-15 @ 1500 UTC on #centos-meeting
## Background:
The Community Platform Engineering group, or CPE for short, 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.
See our wiki page here for more
information:https://docs.fedoraproject.org/en-US/cpe/
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 week!
Aoife
Source: https://hackmd.io/8iV7PilARSG68Tqv8CzKOQ?view
--
Aoife Moloney
Product Owner
Community Platform Engineering Team
Red Hat EMEA
Communications House
Cork Road
Waterford
3 years, 6 months
finding recursive builddeps
by Jason Edgecombe
Hi everyone,
I want to rebuild some of the fedora 33 packages for EL8 (vagrant, for
example), but I'm having trouble getting all of the build dependencies
right. I ran dnf to download the SRPMS with the --resolve option, but I'm
still missing dependencies when I submit the builds to copr.
My current workflow is to download an RPM from Fedora 33, then submit it to
copr to build on the EPEL8 image in my personal COPR projects, waiting for
any library errors, then download those and build, repeat as needed.
That workflow is tedious and I feel like there must be a better way, but I
don't know what that is. How can I recursively find all of the builddeps
for packages?
Ideally, I would like some type of (semi-)automated way to track packages
on Fedora and automatically build them on EL8, but I'm at a loss for how to
do so.
Thanks,
Jason
3 years, 6 months
