Does anyone know how to contact Pete Travis a.k.a. immanetize?
https://bugzilla.redhat.com/show_bug.cgi?id=2112660
Here is the activity report from fedora-active-user:
Last login in FAS:
immanetize 2021-01-21
Last action on koji:
Tue, 28 Jun 2022 tag_package_owners entry created by bodhi [still active]
Last package update on bodhi:
2020-01-08 23:53:41 on package holland-1.1.21-1.el6
Last actions performed according to fedmsg:
- org.fedoraproject.prod.bugzilla.bug.update on 2021-12-08 08:10:09
- org.fedoraproject.prod.bugzilla.bug.update on 2021-12-07 15:57:58
- org.fedoraproject.prod.bugzilla.bug.update on 2021-12-03 12:43:38
- org.fedoraproject.prod.bugzilla.bug.update on 2021-12-03 12:31:33
- org.fedoraproject.prod.bugzilla.bug.update on 2021-12-03 12:06:20
- org.fedoraproject.prod.bugzilla.bug.update on 2021-12-03 03:49:33
- org.fedoraproject.prod.bugzilla.bug.update on 2021-12-02 14:40:52
- org.fedoraproject.prod.bugzilla.bug.update on 2021-12-02 14:40:52
- org.fedoraproject.prod.bugzilla.bug.update on 2021-12-02 13:35:27
- org.fedoraproject.prod.bugzilla.bug.update on 2021-12-02 04:53:46
I am preparing to update python-ezdxf from 0.17.2 to 0.18[1]. Since
there are some small API changes, the update will be for Rawhide only,
and I will wait one week (2022-08-06) to merge and build the PR.
However, this should not affect any other packages, since the sole
dependent package is python-trimesh and I have already confirmed it is
not affected by the API changes.
In python-ezdxf 0.18, a few new Python modules are included that are
derived from other software. The License is therefore no longer simply
“MIT.” Of the new modules in question, one is a fork of its original
upstream. I have treated it as a bundled dependency, adding the
appropriate virtual Provides. The others are full rewrites from
different languages; the licenses of the original projects still affect
the ezdxf License, but I have not treated them as bundled dependencies
since no code is copied from the original projects. See the comments in
the spec file above the License field if the details matter to you.
In classic “Calloway” notation, the new License field would become:
MIT and (ISC and MIT) and (AGPLv3 and MIT)
However, I am taking the opportunity to convert the package to SPDX, and
so the License will become:
(MIT AND (ISC AND MIT) AND (AGPL-3.0-only AND MIT))
In accordance with the updated requirements for license changes, I have
directed this message to both the devel list and the legal list.
– Ben Beasley
[1] https://src.fedoraproject.org/rpms/python-ezdxf/pull-request/1
Hi everyone,
This is a weekly report from the CPE (Community Platform Engineering)
Team. If you have any questions or feedback, please respond to this
report or contact us on #redhat-cpe channel on libera.chat
(https://libera.chat/)
Week: 25th July - 29th July 2022
If you wish to read this in form of a blog post, check the post on
Fedora community blog:
https://communityblog.fedoraproject.org/cpe-weekly-update-week-30-2022/
# Highlights of the week
## Infrastructure & Release Engineering
Goal of this Initiative
-----------------------
Purpose of this team is to take care of day to day business regarding
CentOS and Fedora Infrastructure and Fedora release engineering work.
It’s responsible for services running in Fedora and CentOS
infrastructure and preparing things for the new Fedora release (mirrors,
mass branching, new namespaces etc.).
The ARC (which is a subset of the team) investigates possible
initiatives that CPE might take on.
Link to planning board: https://zlopez.fedorapeople.org/I&R-2022-07-27.pdf
Link to docs: https://docs.fedoraproject.org/en-US/infra/
Update
------
### Fedora Infra
* New Fedora Media Writer release (mostly translation fixes) 5.0.2
* Rabbitmq cluster instability last week due to both ocp3 and ocp4
clusters running monitor-gating and them obsoleting each other over and
over. ;(
* Worked around redhat.com SPF issue by accepting email from redhat.com,
expanding fedoraproject.org alias and sending it right back out through
redhat.com mx to deliver.
### CentOS Infra including CentOS CI
* Preparing duffy.ci migration ([now announced for next
week](https://lists.centos.org/pipermail/ci-users/2022-July/004582.html))
### Release Engineering
* F37 Mass rebuild finished
## CentOS Stream
Goal of this Initiative
-----------------------
This initiative is working on CentOS Stream/Emerging RHEL to make this
new distribution a reality. The goal of this initiative is to prepare
the ecosystem for the new CentOS Stream.
Updates
-------
* Imported c8s modules into the new mbs.
* CentOS Linux 7.9 ISOs are respun
## EPEL
Goal of this initiative
-----------------------
Extra Packages for Enterprise Linux (or EPEL) is a Fedora Special
Interest Group that creates, maintains, and manages a high quality set
of additional packages for Enterprise Linux, including, but not limited
to, Red Hat Enterprise Linux (RHEL), CentOS and Scientific Linux (SL),
Oracle Linux (OL).
EPEL packages are usually based on their Fedora counterparts and will
never conflict with or replace packages in the base Enterprise Linux
distributions. EPEL uses much of the same infrastructure as Fedora,
including buildsystem, bugzilla instance, updates manager, mirror
manager and more.
Updates
-------
* EPEL9 is up to 6986 (+378) packages from 3137 (+54) source packages
* Backported fix for CVE-2021-21419 to EPEL8's
[python-eventlet](https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2022-0…
* Retired several rawhide branches of EPEL-only packages
* Updated KDE (5.24.6) is available in epel9-next and epel8-next testing.
* Will not go out to regular epel until RHEL 8.7 and 9.1
* Working on an EPEL survey that will go out in August
## FMN replacement
Goal of this initiative
-----------------------
FMN (Fedora-Messaging-Notification) is a web application allowing users
to create filters on messages sent to (currently) fedmsg and forward
these as notifications on to email or IRC.
The goal of the initiative is mainly to add fedora-messaging schemas,
create a new UI for a better user experience and create a new service to
triage incoming messages to reduce the current message delivery lag
problem. Community will profit from speedier notifications based on own
preferences (IRC, Matrix, Email), unified fedora project to one message
service and human-readable results in Datagrepper.
Also, CPE tech debt will be significantly reduced by dropping the
maintenance of fedmsg altogether.
Updates
-------
* Basic repo structure in place (Python + JS side), more boilerplate
work ongoing
* Fedora-messaging schemas checkup commenced
Kindest regards,
CPE Team
[ As I've asked you on many occasions before, please send your
questions to the Fedora development mailing list and not to me,
I'm not your personal helper. ]
On Fri, Jul 29, 2022 at 05:49:04PM +0530, Billa Surendra wrote:
> Dear Jones,
>
> After a few months of struggle, I could able to build RISC-V Linux distribution
> for RV64IMAFD. Now I am trying to install Fedora packages with the help of
> rpmbuild.
>
> Here as a first trail, I have downloaded banner-1.3.5-5.fc36.src.rpm SRPM and
> followed steps mentioned below.
>
> Steps:
>
> 1. rpmbuild -ba banner.spec (SUCCESS)
>
> step-1 was successful and it has generated banner-1.3.5-5.fc36.riscv64.rpm
> binary file.
>
> 2.rpm -i banner-1.3.5-5.fc36.riscv64.rpm
>
> Error:
>
> error: Failed dependencies:
> libc.so.6()(64bit) is needed by banner-1.3.5-5.fc36.riscv64
> libc.so.6(GLIBC_2.27)(64bit) is needed by banner-1.3.5-5.fc36.riscv64
>
> Not only banner pckage, many other pckages I could rebuild it in my Linux
> distro but I can not install it. I did checked in my Linux, glibc-2.27 package
> installed already still it is prompting libc.so.6 needed error.
>
> I am eagerly expecting help form you. Can you please help me to solve the above
> error.
>
> Thanks
> Billa
--
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
nbdkit - Flexible, fast NBD server with plugins
https://gitlab.com/nbdkit/nbdkit
Hi folks,
While updating this quick-doc, I came across the last section where
`/etc/sysconfig/desktop` is mentioned as a config file to change default
desktop environment etc.
https://docs.fedoraproject.org/en-US/quick-docs/switching-desktop-environme…
I haven't been able to find any documentation on it, and no package in
Fedora owns this file either. Would someone please be able to note if
this file is still in use, and point to some documentation we could
refer to?
I've also got a PR updating the page here. Reviews most most welcome:
https://pagure.io/fedora-docs/quick-docs/pull-request/474
--
Thanks,
Regards,
Ankur Sinha "FranciscoD" (He / Him / His) | https://fedoraproject.org/wiki/User:Ankursinha
Time zone: Europe/London
Hi folks!
We've had openQA testing of updates for stable and branched releases,
and gating based on those tests, enabled for a while now. I believe
this is going quite well, and I think we addressed the issues reported
when we first enabled gating - Bodhi's gating status updates work more
smoothly now, and openQA respects Bodhi's "re-run tests" button so
failed tests can be re-triggered.
A few weeks ago, I enabled testing of Rawhide updates in the openQA
lab/stg instance. This was to see how smoothly the tests run, how often
we run into unexpected failures or problems, and whether the hardware
resources we have are sufficient for the extra load.
So far this has been going more smoothly than I anticipated, if
anything. The workers seem to keep up with the test load, even though
one out of three worker systems for the stg instance is currently out
of commission (we're using it to investigate a bug). We do get
occasional failures which seem to be related to Rawhide kernel slowness
(e.g. operations timing out that usually don't otherwise time out), but
on the whole, the level of false failures is (I would say) acceptably
low, enough that my current regime of checking the test results daily
and restarting failed ones that don't seem to indicate a real bug
should be sufficient.
So, I'd like to propose that we enable Rawhide update testing on the
production openQA instance also. This would cause results to appear on
the Automated Tests tab in Bodhi, but they would be only informational
(and unless the update was gated by a CI test, or somehow otherwise
configured not to be pushed automatically, updates would continue to be
pushed 'stable' almost immediately on creation, regardless of the
openQA results).
More significantly, I'd also propose that we turn on gating on openQA
results for Rawhide updates. This would mean Rawhide updates would be
held from going 'stable' (and included in the next compose) until the
gating openQA tests had run and passed. We may want to do this a bit
after turning on the tests; perhaps Fedora 37 branch point would be a
natural time to do it.
Currently this would usually mean a wait from update submission to
'stable push' (which really means that the build goes into the
buildroot, and will go into the next Rawhide compose when it happens)
of somewhere between 45 minutes and a couple of hours. It would also
mean that if Rawhide updates for inter-dependent packages are not
correctly grouped, the dependent update(s) will fail testing and be
gated until the update they depend on has passed testing and been
pushed. The tests for the dependent update(s) would then need to be re-
run, either by someone hitting the button in Bodhi or an openQA admin
noticing and restarting them, before the dependent update(s) could be
pushed.
In the worst case, if updated packages A and B both need the other to
work correctly but the updates are submitted separately, both updates
may fail tests and be blocked. This could only be resolved by waiving
the failures, or replacing the separate updates with an update
containing both packages.
All of those considerations are already true for stable and branched
releases, but people are probably more used to grouping updates for
stable and branched than doing it for Rawhide, and the typical flow of
going from a build to an update provides more opportunity to create
grouped updates for branched/stable. For Rawhide the easiest way to do
it if you need to do it is to do the builds in a side tag and use
Bodhi's ability to create updates from a side tag.
As with branched/stable, only critical path updates would have the
tests run and be gated on the results. Non-critpath updates would be
unaffected. (There's a small allowlist of non-critpath packages for
which the tests are also run, but they are not currently gated on the
results).
I think doing this could really help us keep Rawhide solid and avoid
introducing major compose-breaking bugs, at minimal cost. But it's a
significant change and I wanted to see what folks think. In particular,
if you find the existing gating of updates for stable/branched releases
to cause problems in any way, I'd love to hear about it.
Thanks folks!
--
Adam Williamson
Fedora QA
IRC: adamw | Twitter: adamw_ha
https://www.happyassassin.net
I don't know where to report this, so I'm doing it here.
The backend server that is hosting admin.fedoraproject.org/accounts/ is throwing an HTTP 500 SSL handshake error.
This prevents us from using fedora_active_user.py