upgrading RH 9 system->Fedora with iso files and apt only
by Didier Casse
I have the yarrow's iso files on my HD in a RH9 system. Let's say I want
to upgrade selected packages using an "apt-get install" pointing to my
iso-mounted files, how do I do it?
i.e I mount the iso into some /mnt/yarrow1, /mnt/yarrow 2 etc..
Then what is the complete procedure to make my apt look into my own HD to
upgrade packages. Can anybody redirect me to the correct
resource or some literature hanging on the web? Thanks.
Assume also that I do not wish to burn CDs! I do not want to use
apt-cdrom. Thanks.
With kind regards,
Didier.
---
PhD student
Singapore Synchrotron Light Source (SSLS)
5 Research Link,
Singapore 117603
Email: slsbdfc at nus dot edu dot sg \or\
didierbe at sps dot nus dot edu dot sg
Website: http://ssls.nus.edu.sg
2 years, 3 months
Fedora 32 System-Wide Change proposal: iptables-nft-default
by Ben Cotton
https://fedoraproject.org/wiki/Changes/iptables-nft-default
== Summary ==
Make iptables-nft the preferred iptables variant.
== Owner ==
* Name: [[User:psutter| Phil Sutter]]
* Email: psutter(a)redhat.com
== Detailed Description ==
<code>iptables-nft</code> package provides alternative implementations of
iptables, ip6tables, ebtables and arptables and associated save and restore
commands. These use nftables internally while providing the same look'n'feel as
the original tools. Users may choose between both implementations using
<code>alternatives</code> tool.
Upstream considers the traditional implementations legacy and therefore renamed
the binaries adding '-legacy' suffix. In Fedora, same has been done to
<code>arptables</code> and <code>ebtables</code> packages, namely renaming them
to <code>arptables-legacy</code> and <code>ebtables-legacy</code>. Legacy
<code>iptables</code> and <code>ip6tables</code> remain in
<code>iptables</code> package, which in fact is the only one other packages
depend upon.
To change the status quo, two measures are planned:
=== Raise priority of nft-variants in <code>alternatives</code> ===
Currently, legacy variants are installed with priority 10 and nft
variants with priority 5. This must be changed as otherwise installing
<code>iptables-legacy</code> in a system with
<code>iptables-nft</code> installed would change the active
alternative (since they are in automatic mode by default).
On the other hand, existing systems using legacy variants should not
be changed by a system update. Therefore nft variants' priorities
should be chosen to match legacy ones.
=== Rename <code>iptables</code> package ===
New name should be <code>iptables-legacy</code> which aligns with
ebtables and arptables and reflects upstream status. To resolve
dependencies, <code>Provides: iptables</code> statement will be added
to <code>iptables-nft</code> package. This should automatically change
the default variant to nft.
== Benefit to Fedora ==
* RHEL8 ships nft-variants exclusively, make Fedora align with that by
default while still providing the option to fall back to legacy tools.
* New features and improvements are likely to hit nft-variants due to
the possibility nftables backend allows for. Although at this point
some legacy features (e.g. ebtables among match) are still missing,
others are already there (like, e.g. xtables-monitor tool) or are
being upstreamed right now (improved tool performance when dealing
with large rulesets).
== Scope ==
* Proposal owners:
Changes are rather simple: Rename <code>iptables</code> package, add
<code>Provides:</code> line to <code>iptables-nft</code> package,
change priorities used when calling <code>alternatives</code>.
* Other developers: N/A
The changed tools may cause regressions among packages using them and
it affects only new installations (or those manually switched over).
So while no explicit effort is required from them, they should be made
aware of the change so they take a possible regression in iptables
into account, quickly test against legacy variant and file a ticket
(or complain to the right person) if that fixes the problem.
* Release engineering: [https://pagure.io/releng/issue/8934 #8934]
* Policies and guidelines: No change required
* Trademark approval: N/A (not needed for this Change)
== Upgrade/compatibility impact ==
Due to the package rename and <code>Provides:</code> line, upgrades will pull
in <code>iptables-nft</code> package. But due to the equal alternatives
priorities, existing choices won't be changed and so existing installations
shouldn't be harmed (apart from forced installation of
<code>iptables-nft</code> package).
Sadly, there are a few known issues, like e.g. missing support for ebtables
broute table or among match and a few iptables targets/matches. Users depending
on such features are advised to install <code>iptables-legacy</code> package
and switch variants using <code>alternatives</code>.
== How To Test ==
Any users of iptables/ebtables/arptables should switch to nft-variants using
alternatives tool (if necessary) and check that everything works as before. Any
issues should be reported despite the known compatibility issues described
above since knowledge about who uses the missing features is valuable
information for both up- and downstream.
== User Experience ==
Ideally look'n'feel shouldn't change. Since iptables-nft does not need a lock
file anymore, no problems with stale xtables-lock or parallel iptables calls in
different mount namespaces are expected anymore. Given the changes currently
being upstreamed, users dealing with large rulesets should see a performance
increase when manipulating the ruleset (lower run-times of iptables or
iptables-restore, packet processing speed should not really change).
== Dependencies ==
Other packages depending on iptables:
* NFStest
* clatd
* ctdb
* fail2ban-server
* firewalld
* fwsnort
* iptstate
* libvirt-daemon-driver-network
* libvirt-daemon-driver-nwfilter
* moby-engine
* nfacct
* origin
* podman
* psad
* python3-ipatests
* ravada
* rkt
* shorewall
* shorewall-init
* shorewall-lite
* shorewall6
* shorewall6-lite
* sshuttle
* sslsplit
* ufw
Since nft-variants are supposed to be drop-in replacements, no outside
contribution is needed in order to perform this change.
== Contingency Plan ==
* Contingency mechanism: Nothing needs to be done, the change should
be atomic.
* Contingency deadline: N/A
* Blocks release? No
== Documentation ==
* https://wiki.nftables.org/wiki-nftables/index.php/Legacy_xtables_tools
* Man pages:
** [http://man7.org/linux/man-pages/man8/xtables-nft.8.html xtables-nft.8]
** [http://man7.org/linux/man-pages/man8/xtables-legacy.8.html xtables-legacy.8]
** [http://man7.org/linux/man-pages/man8/xtables-monitor.8.html
xtables-monitor.8]
--
Ben Cotton
He / Him / His
Fedora Program Manager
Red Hat
TZ=America/Indiana/Indianapolis
2 years, 5 months
Fedora 35 Change: Add Fedora Kinoite as a variant (Self-Contained
Change proposal)
by Ben Cotton
https://fedoraproject.org/wiki/Changes/Fedora_Kinoite
== Summary ==
Introduce Fedora Kinoite as a variant of Fedora alongside Fedora Silverblue.
== Owner ==
* Name: [[User:siosm| Timothée Ravier]] (travier AT redhat DOT com)
* FESCo shepherd: [[User:Ngompa| Neal Gompa]] (ngompa13 A gmail D com)
* SIG: [[SIGs/KDE|KDE SIG]]
== Detailed Description ==
Fedora Kinoite is an immutable desktop operating system featuring the
KDE Plasma desktop. It is based on the same technologies as Fedora
Silverblue (rpm-ostree, Flatpak, podman). Fedora Kinoite is to the
Fedora KDE Spin what Fedora Silverblue is to Fedora Workstation.
We chose the Kinoite name for the following reasons:
* KDE based projects traditionally start with a 'K'
* Kinoite is a blue mineral (https://en.wikipedia.org/wiki/Kinoite),
thus referring to both the 'silver' and 'blue' part of Silverblue and
the blue color of the KDE logo.
* "Kinoite" means "There is a tree" in Japanese
(https://translate.google.com/?sl=auto&tl=en&text=kinoite&op=translate),
thus referring to the 'tree' in 'ostree'.
== Benefit to Fedora ==
This will make Fedora more attractive to users that are interested in
immutable OSes and underlying technologies but would prefer to use the
KDE desktop environment. This should also strengthen Silverblue as
more effort may be put into fixing the issues in the shared
technologies.
== Scope ==
* Proposal owners:
** The KDE SIG will submit the [https://pagure.io/pungi-fedora Pungi
changes] needed to add this new variant to the compose.
** The KDE SIG will submit the changes to add a new sub-package to
[https://src.fedoraproject.org/rpms/fedora-release fedora-release].
** The KDE SIG will maintain the Kinoite specific rpm-ostree config in
the [https://pagure.io/workstation-ostree-config
workstation-ostree-config repo].
* Other developers: N/A (not a System Wide Change)
* Release engineering: Submitted as [https://pagure.io/releng/issue/9952 #9952].
* Policies and guidelines: N/A (not a System Wide Change)
* Trademark approval: The "Fedora Kinoite" trademark has been
[https://pagure.io/Fedora-Council/tickets/issue/344 approved]
* Alignment with Objectives: N/A
== Upgrade/compatibility impact ==
N/A (not a System Wide Change)
== How To Test ==
This edition has been built and made available as an unofficial
preview and can be tested with the instructions from this
[https://fedoramagazine.org/discover-fedora-kinoite/ Fedora Magazine
article].
== User Experience ==
Current limitations (last updated 2021-01-18):
* No rpm-ostree support in Discover (graphical package and update
manager). A Season of KDE is in progress to work on that.
* Partial Flatpak support in Discover.
* [https://pagure.io/fedora-kde/SIG/issue/13 KDE applications are not
yet available as Flatpak from the Fedora registry].
== Dependencies ==
N/A (not a System Wide Change)
== Contingency Plan ==
Report to the next release.
* Contingency mechanism: N/A (not a System Wide Change)
* Contingency deadline: N/A (not a System Wide Change)
* Blocks release? N/A (not a System Wide Change)
* Blocks product? N/A
== Documentation ==
A lot of the known issues impacting Fedora Kinoite are shared with
Silverblue and their resolution is the same:
https://docs.fedoraproject.org/en-US/fedora-silverblue/troubleshooting/.
It is not clear for now if Kinoite specific documentation is needed
but a landing page with pointer to known issues might be good.
== Release Notes ==
Fedora Kinoite has been introduced as a new variant of Fedora Linux
featuring the KDE desktop environment and the same technologies as
Silverblue (rpm-ostree, Flatpak, podman).
--
Ben Cotton
He / Him / His
Senior Program Manager, Fedora & CentOS Stream
Red Hat
TZ=America/Indiana/Indianapolis
2 years, 6 months
Fedora 33 network configuration (ifcfg*) migration guide available?
by Peter Boy
With Fedora 33 network configuration is by default persisted in /etc/NetworkManager/system-connections/*.nmconnection files. The old /etc/sysconfig/network-scripts/ifcfg* files are „legacy“. They are still being processed for the time being, but obviously it is time to migrate.
(cf https://fedoraproject.org/wiki/Changes/NetworkManager_keyfile_instead_of_...).
Is there a kind of „mapping“ ifcfg-* —> *-nmconnection. ?
Most items are simple to migrate, but servers in particular sometimes have unusual configurations, e.g.
- for p2p Connections: SCOPE="peer xxx.yyy.zzz.aaa"
- and corresponding a lot of (ADDRESSx / NETMASKx / GATEWAYx ) entries in route-{ifname} file
How do I handle that kind of config items in *.nmconnection ? The "search engine I trust" couldn't answer that for me (or I couldn’t ask the right question).
Thanks
Peter
2 years, 7 months
libvirt and systemd-resolved integration?
by Juan Orti Alcaine
Hello,
In the network bridges that libvirt creates there's a dnsmasq daemon to
resolve the VM's IPs. Is there any way to signal systemd-resolved from
libvirt to say that in the bridge interface there is a DNS server and a
domain?
Thank you.
2 years, 7 months
Re-Launching the Java SIG
by Fabio Valentini
This past weekend I finally decided to jump off the cliff and attempt
to re-launch the Java SIG. It seems there's some interest in keeping
the Java stack maintained, it's just not focused or organized right
now.
What we did when starting the Stewardship SIG seems to have worked out
pretty well, so I'm trying to follow in those footsteps here:
- new proper FAS / pkgdb group: java-maint-sig ("java-sig" is occupied
by an old, unused bot account)
- new private mailing list: java-maint-sig (for RHBZ bugs - so,
possibly, also CVEs - hence, private)
- tracking project on pagure: https://pagure.io/java-maint-sig (for
maintenance scripts, tracking tickets, awesome package dashboards,
etc.)
There's already a public fedora mailing list for Java (java-devel),
and and IRC channel (#fedora-java on freenode.net), which we will
continue to use. Sadly, the existing wiki page for the Java SIG is
hopelessly outdated, so I'm tempted to just scrap it and point readers
to the pagure tracking project once it's set up beyond a basic README
file.
Major upcoming projects for the "new" Java Package Maintainers group include:
- managing OpenJDK 11 / Java 11 transition for hundreds of Java
packages in fedora 33
- starting to transition well-maintained Java packages from the
Stewardship SIG back into Java SIG
- possibly porting packages from gradle to maven to fix build issues
and broken dependencies
- transitioning from old java.net / JavaEE projects to the new ones
now under the eclipse-ee4j umbrella
I know that - among others - the PKI team, Neuro SIG, and Eclipse
maintainers depend on parts of the java stack for their packages, so I
hope that we can work together with them on these things, as well.
So, if you're interested, please consider joining this group effort.
I'll get new members set up with the FAS group / pagure project / mailing list.
Let's make this happen.
Fabio
2 years, 7 months
pdftk retired?
by Michael J Gruber
I just git a "broken dependencies" notice for a package that I maintain.
The reason is that "pdftk" got retired just the other day.
I may have missed a corresponding post on fedora-devel, but I think a
heads up notice to maintainers of depending packages may be in order
before you retire a package, as a general idea.
You see, unretiring a package is so much more work than changing
maintainership.
As for pdftk: I see 2 failed builds for version 1.45 and none for the
current version 2.02 (which probably breaks the api anyways). What are
the plans? Retire pdftk completely? Start fresh with pdftk2?
pdflabs, the maker of pdftk, provide binary as well as source rpms for
pdftk 2.02, by the way. I might even look into packaging it but don't
want to duplicate any existing efforts.
Michael
2 years, 7 months
Fedora 34 Change: LTO Build Improvements (System-Wide Change proposal)
by Ben Cotton
https://fedoraproject.org/wiki/Changes/LTOBuildImprovements
== Summary ==
Currently all packages that are not opted out of LTO include
-ffat-lto-objects in their build flags. This proposal would remove
-ffat-lto-objects from the default LTO flags and only use it for
packages that actually need it.
== Owner ==
* Name: [[User:law | Jeff Law]]
* Email: law(a)redhat.com
== Detailed Description ==
-ffat-lto-objects was added to the default LTO flags to ensure that
any installed .o/.a files included actual compiled code rather than
just LTO bytecodes (which are stripped after the install phase).
However, that is wasteful from a compile-time standpoint as few
packages actually install any .o/.a files.
This proposal would remove -ffat-lto-objects from the default LTO
flags and packages that actually need the option would have to opt-in
via an RPM macro in their .spec file. This should significantly
improve build times for most packages in Fedora.
To ensure that we can identify packages that need the opt-in now and
in the future, the plan is to pass to brp-strip-lto a flag indicating
whether or not the package has opted into -ffat-lto-objects. If
brp-strip-lto finds .o/.a files, but the package has not opted into
-ffat-lto-objects, then brp-strip-lto would signal an error.
== Benefit to Fedora ==
The key benefit to Fedora is improved package build times and lower
load on the builders.
== Scope ==
* Proposal owners: The feature owner (Jeff Law) will need to settle on
a suitable RPM macro to indicate an opt-in to -ffat-lto-objects,
implement the necessary tests in brp-strip-lto and opt-in the initial
set of packages. This will be accomplished by doing the prototype
implementation locally, building all the Fedora packages to generate
the opt-in set. Committing the necessary opt-ins, then committing the
necessary changes to the RPM macros.
* Other developers: There should be minimal work for other
developers. The most likely scenarios where other developers will
need to get involved would include:
# Packages which are excluded from x86_64 builds and which need the
opt-in will need the appropriate package owners to add the opt-in.
# Packages which are FTBFS when the builds are run to find the set of
packages that need to opt-in and which need to opt-in will need
packager attention.
# It is possible that the faster builds may trigger build failures in
packages that have missing dependencies in their Makefiles. We saw a
few of these during the initial LTO work and those packages were
either fixed or -j parallelism removed. This work may expose more of
these problems.
I expect these all to be relatively rare occurences, but with 9000+
packages in Fedora I wouldn't be surprised if we see a few of each of
these issues.
* Release engineering: [https://pagure.io/releng/issues #Releng issue
number] (a check of an impact with Release Engineering is needed) This
should have no release engineering impacts.
* Policies and guidelines: The packaging guidelines will need to be
updated to document the new macro.
* Trademark approval: N/A (not needed for this Change)
* Alignment with Objectives: This proposal does not align with any
current Fedora Objectives.
== Upgrade/compatibility impact ==
This change should have zero impact on upgrade/compatibility. In
fact, the change should have no user visible impacts.
== How To Test ==
No special testing is needed. Any issues with this proposal will show
up as FTBFS issues.
== User Experience ==
Users should see no changes to the user experience.
== Dependencies ==
Packages which need to opt-in to -ffat-lto-objects will need their
.spec files updated to include the
new macro.
== Contingency Plan ==
If this can not be completed by final development freeze, then the RPM
macro changes would not be installed and the change could defer to
Fedora 35.
* Contingency mechanism: Proposal owner will only commit the RPM macro
changes once the opt-in package set has been identified and opt-ins
added to those package's spec files. So no special contingency
mechanism should be needed
* Contingency deadline: It is most beneficial to have this completed
before the mass rebuild; however, the drop dead date should be beta
freeze.
* Blocks release? No
* Blocks product? No
== Documentation ==
No upstream documentation. Packaging guidelines will need a minor update.
== Release Notes ==
I do not expect this change to require any release notes.
--
Ben Cotton
He / Him / His
Senior Program Manager, Fedora & CentOS Stream
Red Hat
TZ=America/Indiana/Indianapolis
2 years, 8 months
Assimp soname bump
by Rich Mattes
Hi,
I plan to update assimp from 3.3.1 to the latest release (5.0.1) in
rawhide this week. The following packages will be affected:
fawkes-0:1.3.0-11.fc33.src
mrpt-0:1.4.0-17.fc33.src
pioneer-0:20200203-1.fc33.src
vkmark-0:2017.08-0.8.20180123git68b6f23.fc32.src
I will take care of the rebuilds and any fallout/updates that need to
happen.
Rich
2 years, 8 months