Wiki - https://fedoraproject.org/wiki/Changes/NodejsAlternativesSystem
Discussion thread -
https://discussion.fedoraproject.org/t/f43-change-proposal-use-update-alter…
This is a proposed Change for Fedora Linux.
This document represents a proposed Change. As part of the Changes
process, proposals are publicly announced in order to receive
community feedback. This proposal will only be implemented if approved
by the Fedora Engineering Steering Committee.
== Summary ==
We aim to move away from manual management of
<code>/usr/bin/node</code>, <code>/usr/bin/npm</code>, and similar
symlinks to leveraging update-alternatives system.
== Owners ==
* Name: [[User:aradchen|Andrei Radchenko]]
* Email: aradchen(a)redhat.com
* Name: [[User:jstanek|Jan Stanek]]
* Email: jstanek(a)redhat.com
* Name: [[User:tjuhasz|Tomas Juhasz]]
* Email: tjuhasz(a)redhat.com
== Detailed Description ==
This is a part of a larger iteration in a way we package NodeJS for
Fedora and RHEL. The other parts are [[Changes/NodejsNodeModulesPath]]
and [[Changes/NodeJSMetapackages]].
This change deals specifically with the management of the
non-versioned symlinks in system paths.
Currently, the NodeJS packages (streams) provided in Fedora are all
installable in parallel,
by virtue of moving any potentially conflicting bits into versioned
equivalents and/or versioned directories.
For one example of many:
<pre>
%install
mv %{buildroot}%{_bindir}/node %{buildroot}%{_bindir}/node-%{node_version_major}
...
</pre>
One of the streams is designed as the "default" one, and that stream
then ships manually created non-versioned symlinks to the renamed
paths:
<pre>
%if 0%{nodejs_is_default}
ln -srf %{buildroot}%{_bindir}/node-%{node_version_major}
%{buildroot}%{_bindir}/node
...
%endif
</pre>
By using update-alternatives, we can iterate on this idea and gain
several benefits outlined below.
== Feedback ==
== Benefit to Fedora ==
# No matter which stream you install, you'll always have
<code>/usr/bin/node</code> and other non-versioned names available.
The versioned names will be also present, if you want to be specific
in your scripts.
# There is no "official Fedora endorsement" on which NodeJS stream
should be "best" or "default"; if you as a system administrator have
multiple streams installed, the decision of which should be the
default is up to you.
The second item will also give us the maintainers greater freedom in
introducing new streams and obsoleting the old ones without worrying
too much about how to switch the "default" in the middle of the
distribution life cycle.
This is not a big pain point for Fedora, where the length of the life
of a single version matches the length of upstream NodeJS LTO support
pretty closely,
but becomes much more important in longer-living downstream
distributions (e.g. RHEL).
== Scope ==
* Proposal owners:
** Port the manual symlink creation and management to update-alternatives.
** Ensure the streams behave consistently and no conflict is introduced.
== User Experience ==
* Users will be able to install any number of streams and switch
between default one rather easy by just running `update-alternatives
--config node'.
== Dependencies ==
* Should not cause any problems to dependant packages.
== Contingency Plan ==
* Contingency mechanism: Revert back to manual symlink management and
go back to the design phase.
* Contingency deadline: Beta Freeze.
* Blocks release? We aim to do the rebuilds in Koji side tag and merge
it atomically; so NO.
== Documentation ==
* This is a downstream change; this page is the initial documentation.
* [https://docs.fedoraproject.org/en-US/packaging-guidelines/Alternatives/
Fedora Alternatives]
== Release Notes ==
TODO
--
Aoife Moloney
Fedora Operations Architect
Fedora Project
Matrix: @amoloney:fedora.im
IRC: amoloney
--
_______________________________________________
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.fedorapr…
Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
[Bug 1988142] memtest boot entry on Fedora install media does not work
since Fedora-Rawhide-20210728.n.3
https://bugzilla.redhat.com/show_bug.cgi?id=1988142
This bug might be gcc, but also includes a note about the upstream
being kinda weak, possibly non-existent these days.
Neal Gompa mentioned pcmemtest earlier this year
https://github.com/martinwhitaker/pcmemtest
It would need a maintainer. Any takers?
Fedora doesn't have a release criterion covering the memory tester, or
really any option appearing in the install media's boot menu other
than the one that launches the installer. But I think it's better to
not ship a memory tester at all, than to ship a broken one (given the
options).
Memtest86+ is bios only, where pcmemtest can be compiled to run on
either firmware type. If we want it to work with UEFI Secure Boot
enabled, it'd need to be signed with Fedora's key (I think the same as
the one used for GRUB and/or the kernel?). This would be in scope for
Fedora 36, assuming the above bug can be easily fixed.
But if that bug is hard to fix, and pcmemtest could be a drop-in
replacement (i.e. bios only, just like now) maybe that's doable for
Fedora 35, and better than having no memory tester.
Chris Murphy
--
Chris Murphy
Hello list,
I want to let you know that I plan to retire the package monodevelop
from Rawhide.
Upstream has archived https://github.com/mono/monodevelop in October 2021.
Please let me know if there is a reason not to retire the package.
All the best,
Timotheus
Hi folks,
we have published a release criteria change proposal at Fedora Discussion:
https://discussion.fedoraproject.org/t/proposal-limit-release-blocking-stat…
This is a notification to make sure everybody can see it and post feedback,
even when not watching Fedora Discussion regularly.
When replying, **please**, reply to the Discussion topic. Logging in
through FAS is trivial. We want a unified discussion in one place, instead
of having it split between multiple places. Thank you.
Kamil Paral
Fedora Quality
Wiki - https://fedoraproject.org/wiki/Changes/DeprecateSTI
Discussion Thread -
https://discussion.fedoraproject.org/t/f42-change-proposal-deprecation-of-s…
This is a proposed Change for Fedora Linux.
This document represents a proposed Change. As part of the Changes
process, proposals are publicly announced in order to receive
community feedback. This proposal will only be implemented if approved
by the Fedora Engineering Steering Committee.
== Summary ==
Display a deprecation warning for Fedora 41 for all STI tests.
Deprecate execution of STI tests in all CI pipelines for Fedora 42.
* CI for bodhi updates
* CI for dist-git pull requests
All users of STI tests will need to
[https://tmt.readthedocs.io/en/stable/questions.html#how-do-i-migrate-sti-te…
migrate to the new tmt format].
'''The change will affect 281 components'''. The list of components
affected can be found via
[https://sourcegraph.com/search?q=context:global+repo:src.fedoraproject.org+…
this sourcegraph query].
All references to STI will be removed from the Fedora CI documentation.
== Owner ==
* Name: [[User:mvadkert| Miroslav Vadkerti]], [[User:lecris| Cristian Le]],
* Email: mvadkert(a)redhat.com, fedora(a)lecris.me
== Detailed Description ==
For some time CI testing in Fedora can be defined using two different formats:
* Standard Test Interface (STI)
* Test Management Tool (tmt)
As tmt has matured to a state it can fully replace the STI
functionality, we are proposing to drop STI as the supported format.
STI format is not actively developed and is causing us a maintenance
burden. More and more STI test failures are starting to appear as the
Fedora packages evolve out of sync with the test scripts.
Tmt provides various advantages over STI that would make it easier to
manage in the long term:
* Better organization of `tests` and test environments (referred to as
`plans` in tmt)
* Local reproducible environment thanks to testing-farm reproducer
script, allowing to thinker locally without pushing to dist-git
* Tests can be defined in the local dist-git repo, inside the srpm
archive, [https://src.fedoraproject.org/projects/tests/%2A `tests/*`]
dist-git namespace, or in the upstream repo, allowing it to be reused
more freely between packages and with upstream directly
* Tmt tests are integrated with packit allowing it to be executed with
upstream and better migrate to the new dist-git environment
Hopefully this list can help inspire some better ways of reorganizing
the tests during the migration.
== Feedback ==
== Benefit to Fedora ==
Having two formats for executing the tests is an unnecessary
duplication and causes confusion for the Fedora maintainers and
community.
STI tests have limited functionality and are harder to develop and
maintain, when compared to tmt.
== Scope ==
* Proposal owners: [[User:mvadkert| Miroslav Vadkerti]],
[[User:lecris| Cristian Le]]
* Other developers:
* Release engineering: [https://pagure.io/releng/issues #Releng issue number]
* Policies and guidelines: N/A (not needed for this Change)
* Trademark approval: N/A (not needed for this Change)
* Alignment with the Fedora Strategy:
== Upgrade/compatibility impact ==
This is a change to the development experience, no changes to Fedora
distribution are made.
== How To Migrate ==
To find out if you package has STI tests, check if `tests/tests*.yml`
files are present in your dist-git repository.
Follow the [https://tmt.readthedocs.io/en/stable/questions.html#how-do-i-migrate-sti-te…
sti to tmt migration guide]. For the majority of tests involve just
executing the already provided script you only need to:
1. Initialize `tmt` structure using `tmt init`
2. Create a minimal plan
<pre>
# /plan.fmf
# Boilerplate to indicate tmt to run any tests files it finds in the repo
discover:
how: fmf
execute:
how: tmt
# Prepare test environment, e.g. install packages
# Note: the current packages in the spec file will already be
installed by default
prepare:
how: install
packages:
- foo
- bar
</pre>
3. Migrate individual tests
<pre>
# /tests/foo.fmf
test: ./foo.sh
</pre>
For more complex needs feel free to discuss in the
[https://matrix.to/#/#fedora-ci:fedoraproject.org `#fedora-ci`] or
[https://matrix.to/#/#tmt:fedoraproject.org `#tmt`] matrix channels.
You can also explore
[https://sourcegraph.com/search?q=context:global+repo:src.fedoraproject.org/…
other project's tmt tests] (identified by having a `.fmf` folder)
using `tmt tests show` and `tmt plans show`
== User Experience ==
For Fedora 41 users will be presented with a deprecation warning in
the Testing Farm artifacts.
For Fedora 42 users who have setup gating on STI tests will be
obligated to migrate to be able to push their packages to stable
repositories.
== Dependencies ==
N/A
== Contingency Plan ==
* Contingency mechanism: N/A (not a System Wide Change)
* Contingency deadline: N/A (not a System Wide Change)
* Blocks release? No (not a System Wide Change)
We will keep the STI support until all references to STI tests are
gone in case all users have not migrated to tmt until Fedora 42. See
the description for the list of the affected components.
== Documentation ==
* [https://tmt.readthedocs.io/en/stable/questions.html#how-do-i-migrate-sti-te…
How to migrate STI tests to tmt]
* [https://src.fedoraproject.org/tests/python/tree/main Example test
repo implemented in both STI and tmt format] (see for example the
`smoke/venv.fmf` file and `smoke_default` test in `tests.yml` file)
* [https://tmt.readthedocs.io/en/stable/spec.html Tmt specs]
(reference for the available keys defining `plans` or `tests`)
* Example project with shared
[https://github.com/containers/aardvark-dnsupstream]+[https://src.fedoraproject.org/rpms/aardvark-dns downstream]
tests
== Release Notes ==
--
Aoife Moloney
Fedora Operations Architect
Fedora Project
Matrix: @amoloney:fedora.im
IRC: amoloney
--
_______________________________________________
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.fedorapr…
Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
I know that probably things aren't fully back up yet, but I
absent-mindedly did a git pull just now. Is this expected?
$ git pull
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@ WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED! @
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY!
Someone could be eavesdropping on you right now (man-in-the-middle attack)!
It is also possible that a host key has just been changed.
The fingerprint for the RSA key sent by the remote host is
SHA256:dJN0nFWBcWK7SFs2k0nnsO+XNA9+aEDY4FWO7uhxTN8.
Please contact your system administrator.
Add correct host key in /home/rjones/.ssh/known_hosts to get rid of this message.
Offending RSA key in /home/rjones/.ssh/known_hosts:43
Host key for pkgs.fedoraproject.org has changed and you have requested strict checking.
Host key verification failed.
fatal: Could not read from remote repository.
Please make sure you have the correct access rights
and the repository exists.
--
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,
per
https://fedoraproject.org/wiki/Changes/FoomaticRipRejectsUnknownValues
I've got feedback about turning RPM scriptlet into systemd service to
have the change applied even on immutable systems, like bootable
containers, Fedora CoreOS etc.
Does anyone use such systemd service for upgrade tasks in their packages?
Would you mind sharing the name of component which uses such service, so
I can check how it is supposed to look?
Thank you in advance!
Zdenek
--
Zdenek Dohnal
Senior Software Engineer
Red Hat, BRQ-TPBC
Greetings everyone.
I would like to provide a status update on the datacenter move.
On the plus side, we have all our data migrated to the new datacenter.
All the databases and storage are available in the new location.
Also, many of our services are back and functional.
However, the build system pipeline is not yet ready to come back up.
We are trying to debug/fix an authentication issue that is preventing
ssh git access and lookaside uploads. As soon as that issue is solved,
we can continue the build system bringup. That will consist of:
* Testing official build for signing, bodhi handling and gating testing
* opening koji and pkgs/src ssh.
* Testing updates composes
* Testing rawhide composes
I know packagers are eager to resume their work, hopefully
we will have things back up soon.
Issues we know about and are working on:
* The above dist git auth issues.
* mailman is sometimes hitting out of memory and needs to be restarted.
* Our meeting bot on matrix is unable to write log files to it's storage.
* a few smaller applications haven't yet been redeployed or need some fixes.
Unrelated, as we were moving, the AI scrapers started really hitting
pagure.io (which was not moving or changing due to the move) which made
things pretty difficult. We have blocked the 'blame' and 'history' web
enpoints. If you need those, you should be able to clone the git repo
and do them locally. This has moved the load back down to manageable.
If you are trying to use the new src.fedoraproject.org server, you may have
noticed it's ssh host keys changed. In the past we kept the old keys
but this time we made a clean break. You can verify the keys by getting:
https://admin.fedoraproject.org/ssh_known_hosts and adding it to
your local .ssh/known_hosts. This will allow ssh to see the new host
keys are signed with our CA. You can also use our sshfp records
if you are using a dnssec enabled resolver.
If you have noticed some other problem not mentioned above:
If the issue is minor, consider just waiting and letting us know/filing
a ticket on it next week if it's still happening.
If it's something major, do let us know:
https://docs.fedoraproject.org/en-US/infra/day_to_day_fedora/
and we will try and fix it as soon as we are able.
Keep in mind we are focused on the above issues and will need
to prioritze our time.
We will also be having a retrospective and sharing what we learned after
everything is back in a good state.
Thanks again for your patience.
kevin
--
_______________________________________________
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.fedorapr…
Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue