[HEADS UP] -Wl,--as-needed is added in rawhide
by Igor Gnatenko
It's in redhat-rpm-config-118-1.fc30.
If it causes any problems for you - let me know. In the meantime, you can
use `%undefine _ld_as_needed` to disable it.
Thanks for attention!
--
-Igor Gnatenko
11 months, 2 weeks
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
1 year, 4 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
1 year, 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
1 year, 9 months
Upstream tip wanted: CI service for Big Endian acrhes
by Miro Hrončok
Recently I've reported some Big Endian related test failures to an
upstream project [0].
I was asked by an upstream project maintainer, whether I know some free
Continuous Integration services where they can easily run their
testsuite on Big Endian.
Any tips?
* Upstream uses Travis CI to test on x86_64 Linux (Ubuntu)
* Upstream uses AppVeyor to test on Microsoft Windows
* It's a pure Python project, noarch, but some changes need to be done
when loading/saving binary data (LE) with NumPy on BE system.
What I've considered:
* COPR (but there is no big endian arch)
* (Ab)using Koji (I guess that would be considered a bad practice?)
* using QUEMU on Travis CI [1]
Any better tips? Thanks
[0] https://github.com/mikedh/trimesh/issues/249
[1]
https://developer.ibm.com/linuxonpower/2017/07/28/travis-multi-architectu...
--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
2 years, 2 months
Server Side Public License (SSPL) v1
by Tom Callaway
After review, Fedora has determined that the Server Side Public License
v1 (SSPL) is not a Free Software License.
It is the belief of Fedora that the SSPL is intentionally crafted to be
aggressively discriminatory towards a specific class of users.
Additionally, it seems clear that the intent of the license author is to
cause Fear, Uncertainty, and Doubt towards commercial users of software
under that license. To consider the SSPL to be "Free" or "Open Source"
causes that shadow to be cast across all other licenses in the FOSS
ecosystem, even though none of them carry that risk.
It is also worth nothing that while there is a draft for a "v2" of the SSPL:
A) It is not final.
B) It is not in use anywhere at this time (as far as we know).
C) The intent of the v2 draft text is not changed from the v1 license
currently in use.
We have updated our "Bad License" list to include SSPLv1. No software
under that license may be included in Fedora (including EPEL and COPRs).
Thanks,
Tom Callaway
Fedora Legal
2 years, 4 months
Re: NeuroFedora review swaps
by Ankur Sinha
On Mon, Jan 28, 2019 15:47:00 +0100, J. Scheurich wrote:
>
> > I'd like to get this package reviewed please:
> >
> > - python-pyscaffold: https://bugzilla.redhat.com/show_bug.cgi?id=1669913#
> >
> > Would anyone like to swap reviews?
>
> I would review it for wdune sponsoring.
Sorry---I'm not current with the wdune scenario. I assumed you meant
that you'd review it unofficially as part of the work to get sponsored
to the packagers group:
https://fedoraproject.org/wiki/How_to_get_sponsored_into_the_packager_gro...
I'm not a sponsor yet so I cannot sponsor you to the group myself, but
once you've done a few reviews, a sponsor will be happy to take a look
at them and guide you through the sponsorship process.
If you've submitted a review ticket for wdune already, I will be happy
to review it and provide comments.
--
Thanks,
Regards,
Ankur Sinha
https://ankursinha.in
Time zone: Europe/London
2 years, 4 months
