Attention Gmail users, please turn off HTML mail
by Dominik 'Rathann' Mierzejewski
Dear developers,
sorry for a slightly off-topic post, but I've noticed that a significant
number of posters is sending HTML e-mail to this list (not to mention
top-replying), which generates unnecessary network traffic. Some people
pay for every bit downloaded, so they're paying for the same information
twice, because the e-mails are sent with multipart/alternative format,
which contains BOTH text/plain and text/html. One thing I noticed those
senders have in common is that they use Gmail.
So, a plea to Gmail users: please stop sending HTML e-mail to Fedora
mailing lists.
Regards,
Dominik (who still reads e-mail in text mode in a terminal)
--
Fedora https://getfedora.org | RPMFusion http://rpmfusion.org
There should be a science of discontent. People need hard times and
oppression to develop psychic muscles.
-- from "Collected Sayings of Muad'Dib" by the Princess Irulan
2 days, 20 hours
Blocking criteria proposal for F30+: Printing
by Stephen Gallagher
There was a bug[1] filed recently that indicated that printing was
broken on certain printers. As a result of that discussion, it became
apparent that there was no criteria for printing to work at all, which
seems like an oversight.
I discussed this briefly with Matthias Clasen this morning and he
agreed that this should be treated as blocking for Workstation.
I'd like to propose that we add the following criteria to Beta for Fedora 30+:
* Printing must work on at least one printer available to Fedora QA.
"Work" is defined as the output from the device matching a preview
shown on the GNOME print preview display. (Note that differences in
color reproduction are not considered "non-working".)
and this to Final for Fedora 30+:
* Printing must work on at least one printer using each of the
following drivers:
(I don't know which ones to specify here, but we ought to try to
figure out a cross-section that covers a large swath of our expected
user base).
[1] https://bugzilla.redhat.com/show_bug.cgi?id=1628255
2 weeks, 2 days
Proposal: Abandon v8 package
by Tom Callaway
Background:
I made the original v8 Fedora package many moons ago, when I was more
optimistic about the possibility of separating the useful components
inside of chromium. Since that point, it has become clear that while v8
is useful software, the following facts are also true:
1. The v8 upstream is entirely disinterested in the concept of
maintaining any sort of ABI/API consistency between releases.
2. The v8 that is used in chromium is not necessarily compatible with
the upstream v8, as they have a history of picking and choosing code
changes (and even applying chromium specific changes locally).
3. Virtually all consumers of v8 (including chromium) take a git
checkout (not a specific one, just whatever they decided to code to) and
use that revision, often creating a local fork of v8 from that revision,
as they are either unwilling or unable to track v8 upstream.
4. Since v8 has no concept of a "stable" release that I can see, they
simply do security fixes to the master branch, which, combined with the
code changing violently, makes it very difficult to backport security fixes.
This means that other than plv8 (which is currently unable to build
against the current v8 package in Fedora), I do not see any consumers of
the Fedora v8 package (chromium has long since abandoned any possibility
of using it). It does contain a "d8" binary, which is a javascript CLI
debugger, but it is not clear to me that this is widely used, or that
the benefit of its inclusion in Fedora outweighs the pain of maintaining
this package.
Thus, I propose that the v8 package be abandoned/orphaned/taken to the
farm upstate to run and play with the other dogs.
If you disagree, or are crazy enough to want to take it over, speak now.
~tom
P.S. I'll still maintain v8-314 as best I can, since there are actually
users of that. The irony of that really ancient version being considered
stable (and thus, used by other software) as a result of Fedora sticking
on that version of v8 for so many releases is not lost on me.
1 month, 1 week
F29 System Wide Change: OpenLDAP without Non-threaded Libraries
by Jan Kurik
= Proposed System Wide Change: OpenLDAP without Non-threaded Libraries =
https://fedoraproject.org/wiki/Changes/OpenLDAPwithoutNonthreadedLibraries
Owner(s):
* Matus Honek <mhonek at redhat dot com>
OpenLDAP will not ship non-threaded version of libldap. Instead,
libldap will be built with the same threading support as libldap_r.
== Detailed description ==
After this change the non-threaded version of libldap will not be
shipped any more. Instead, this library will rather be built the same
way as the threaded libldap_r. This has been previously discussed in
Bugzilla [https://bugzilla.redhat.com/show_bug.cgi?id=1370065] and
other distributions where this change already happened. Upstream still
supports non-threaded version of their library as it might be used on
processors where threads are not supported. However, when these two
versions happen to be loaded at the same time (as discussed about Curl
in the Bugzilla) symbol names overlap which may result in
unpredictable behaviour. Immediate solution would be to symlink
libldap to libldap_r, however SONAME of the library would be the same,
hence breaking dependencies of other packages. For that reason the
solution hereby proposed should be the most convenient one.
== Scope ==
* Proposal owners:
update SPEC file so that non-threaded libldap is replaced with threaded one.
* Other developers:
None. Issues should not occur.
* Release engineering:
[https://pagure.io/releng/issue/7253]
** List of deliverables:
N/A
* Policies and guidelines:
None.
* Trademark approval:
(not needed for this Change)
--
Jan Kuřík
JBoss EAP Program Manager
Red Hat Czech s.r.o., Purkynova 99/71, 612 45 Brno, Czech Republic
1 month, 2 weeks
F29 System Wide Change: Remove Excessive Linking
by Jan Kurik
Note from Change Wrangler: This Change Proposal requires mass rebuild.
However, two weeks ago (June 19th), we have already passed the
deadline for Change proposals requiring mass rebuild. I will leave the
decision whether this Change proposal is accepted or not to RelEng and
FESCo teams.
= Proposed System Wide Change: Remove Excessive Linking =
https://fedoraproject.org/wiki/Changes/RemoveExcessiveLinking
Owner(s):
* Igor Gnatenko <ignatenkobrain at fedoraproject dot org>
* Neal Gompa <ngompa13 at gmail dot com>
Pass "--as-needed" flag the linker through default system-wide LDFLAGS.
== Detailed description ==
The flag ("--as-needed") tells the linker to link in the produced
binary only the libraries containing symbols actually used by the
binary itself. This binary can be either a final executale or another
library.
The use of the "--as-needed" flag allows the linker to avoid linking
extra libraries in a binary. This not only improves startup times (as
the loader does not have to load all the libraries for every step) but
might avoid the full initialization of big frameworks.
== Scope ==
* Proposal owners:
Add "-Wl,--as-needed" into RPM_LD_FLAGS (in redhat-rpm-config).
* Other developers:
Nothing should break, but immediate work-around would be to disable
this flag (will be provided in redhat-rpm-config) and fix real issue
later.
* Release engineering:
#7604 [https://pagure.io/releng/issue/7604] (mass rebuild is desired
after this change).
** List of deliverables:
N/A (not a System Wide Change)
* Policies and guidelines:
Add information how to turn it off (TODO link to FPC ticket).
* Trademark approval:
N/A (not needed for this Change)
--
Jan Kuřík
JBoss EAP Program Manager
Red Hat Czech s.r.o., Purkynova 99/71, 612 45 Brno, Czech Republic
1 month, 4 weeks
Orphan/retire gogoc
by J. Randall Owens
Hello,
gogoc is dead to the world upstream (the gogo6.com site is now a
nutritional supplement pusher!), and without gogo6's servers, gogoc is
fairly useless. It's still possible it could be used to TSP tunnel
through one's own servers to get IPv6, but as far as I know, there
aren't any more tunnel services out there that use it.
So, if someone would find it worthwhile to keep it around for their own
tunnelling needs, feel free to pick it up. Otherwise, I'll retire it in
two weeks.
--
J. Randall Owens | http://www.GhiaPet.net/
2 months
Fedora 30 System-Wide Change proposal: Mass Python 2 Package Removal
by Ben Cotton
https://fedoraproject.org/wiki/Changes/Mass_Python_2_Package_Removal
== Summary ==
(Sub-)packages only providing python2 importable modules without
additional functionality will be removed from Fedora unless some other
package(s) depends on them.
Python 2 will be deprecated in Fedora. Packagers can mark any other
Python 2 packages as deprecated as well.
== Owner ==
* Miro Hrončok (Churchyard)
* Petr Viktorin (Pviktori)
* Charalampos Stratakis (Cstratak)
* Zbigniew Jędrzejewski-Szmek (Zbyszek)
* Igor Gantenko (Ignatenkobrain)
* Neal Gompa (Ngompa)
== Detailed Description ==
Python 2 reaches End of Life on 2020-01-01. Its current maintainers
would like to orphan it before that date, and so far no one else has
stepped up to maintain Python 2 (with the full ecosystem) past 2020.
Since thousands of packages still depend on python2, we need a more
careful approach than normal orphaning.
Some of those packages are abandoned and/or the Python 2 version is
unnecessary. Others are useful and just need more time to port to
Python 3.
Hence we set up criteria for python2 packages that can remain in the
distribution and we remove everything else. This should allow us to
keep python2 for limited use, not break everything, but should also
send a strong message that it is no longer a first class citizen, and
filter packages we need to focus Python 3 porting efforts on.
(Sub-)packages that only provide a python2 importable module, and are
not required for other packages, will be removed.
Examples of situations where a (sub-)package does not provide only the
importable module:
* A package also provides an application, mostly likely in /usr/bin,
/usr/libexec...
** (Note that according to current guidelines, if the Python 3 version
of a package provides the same functionality, the Python 3 package
should provide the application.)
** (In certain situations the provided application is only useful to
boostrap or manage projects using the module. Such applications don't
count.)
* A package provides a plugin for another application, most likely
trough a setuptools entrypoint interface or some custom location on
disk.
Our process will be:
* File bugs for all packages that look like they only provide a Python
2 importable module. (This includes those needed by other packages we
plan to remove.)
* Leave at least a week for packagers to respond to the bugs.
* If the packager approves or there is no response for a week, we will
remove the package.
There are currently ~3000 source packages that generate python2 dependent RPMs.
Automation is being created to be able to provide us a rough list of
packages to remove.
=== Packages to remove ===
The list is at https://fedoraproject.org/wiki/Changes/Mass_Python_2_Package_Removal/List
not to disturb the reading experience of this page.
Packagers can block some packages from removal by responding on
Bugzilla and providing reasons. If no general consensus is reached,
FESCo will decide (as Python SIG does not have a formal process for
such decisions).
We'll also actively try to remove unused or optional dependencies to
reduce the number of packages that need to be kept because other
packages depend on them.
As dependencies evolve over time, we will regularly repeat this proces
on rawhide from now on even on future releases.
Packagers are strongly encouraged to help port their applications to
Python 3. Removing old Python 2 only applications from Fedora is also
encouraged, especially if the upstream is dead. Python SIG is
available to help with porting.
Packaging guidelines will be updated to reflect that packaging for
Python 3 only is the default. Instructions for Python 2 and
dual-support will be moved to the Appendix.
Python 2 will be marked deprecated (see
https://fedoraproject.org/wiki/Packaging:Deprecating_Packages).
Any package that only provides a Python 2 importable module may be
marked as deprecated as well if the maintainer(s) want to.
== Benefit to Fedora ==
A giant pile of unneeded software running on a legacy interperter will
be removed from Fedora before the interpreter stops being supported
upstream.
While we would very much like to remove Python 2 entirely, this way we
are not breaking Fedora, and we can accomodate some exceptions.
== Scope ==
* Proposal owners:
** Provide a list of packages to remove
** Collect feedback from affected packagers
** Retire the python2 only packages
** Remove python2 subpackages from dual-python packages
* Other developers:
** Ask for packages to be removed from the list if needed (with reasons).
** Remove python2 subpackages from dual-python packages (not needed,
but helpful)
** Optionaly mark remainign python2 packages deprecated
* Policies and guidelines:
** Python packaging guidelines will be changed to only describe Python 3
** Python 2 and dual-support packaging will be moved to the appendix
** Only packages providing additional features different than
importable modules will be allowed to be added in Fedora (with
exception for dependenecies of other packages)
** Python 2 will be marked deprecated
https://fedoraproject.org/wiki/Packaging:Deprecating_Packages
* Trademark approval: not needed for this Change
== Upgrade/compatibility impact ==
Packages removed form Fedora repos will remain on the installed OS
until explicitly removed by the user or obsoleted by the packagers.
We'll only obsolete packages that would break upgrade (from
fedora-obsolete-packages).
== How To Test ==
Any program written in Python and any program that has Python plugins
could potentially be influenced by this change. Testing is different
for software that is still using Python 2 and for software that has
been switched to Python 3.
For any ''python2'' programs, make sure those programs are still
functional after the package removal. Since various packages that are
no longer built will not be removed from an existing system, just
upgrading and checking packages is not enough. Either a new
installation should be used, or after a branching point, any packages
which haven't been rebuilt for F30, so any packages with .fc29 or
lower release suffix should be removed from the system before testing.
For the ''python3'' programs, install all upgrades and check if the
software works.
Upgrade failures because of missing dependencies should be treated as
bugs. Any removed python2 subpackages which break upgrades need to be
added to Obsoletes in fedora-obsolete-packages.
== User Experience ==
There will be less Python 2 RPMs in Fedora repos. Users are encouraged
to switch to Python 3 and/or use Python 2 virtual environments and pip
for development.
== Dependencies ==
Ideally, all programs that use python2 would be switched to use
python3. Although we don't expect everything to be switched over, as
much as possible should be, so that the set of remaining python2
subpackages is as small as possible.
== Contingency Plan ==
* Contingency mechanism:
** If for some reason not everything is removed, nothing happens, it
can be removed later. If for some reason something breaks, some
packages can be unretired or restored.
** If someone steps up to maintain Python 2 (including the full
ecosystem of packages now in Fedora), they can decide to discontinue
removing packages, revert the Change, or come up with another plan.
(Note that in this case, current maintainers will most likely orphan
many fundamental python2 packages.)
== Documentation ==
This page is the main documentation.
Also see: https://pythonclock.org/
--
Ben Cotton
Fedora Program Manager
TZ=America/Indiana/Indianapolis
2 months
Intel's Clear Linux optimizations
by František Zatloukal
Hi,
Phoronix recently release article[1] about Intel's Clear Linux with some
cool graphs showing nice performance gain compared to Xubuntu.
I didn't have time to dig in and look how it's performing against Fedora,
but I'd assume Fedora can be compared to Xubuntu in terms of compiler
settings.
I think i'll be interesting to look into it and find out if Fedora can't
tweak compiler settings (eg use LTO for critical things like Mesa, Kernel,
...). I think it could be interesting fo Fedora users to have this enabled
if there are not any disadvantages other than compile time, compile memory
usage and so on.
What do you think?
[1]
http://www.phoronix.com/scan.php?page=article&item=intel-clr-opengl&num=1
--
Best regards / S pozdravem,
František Zatloukal
Project Coordinator
Red Hat
2 months, 1 week
Installation image layout
by Marek Marczykowski-Górecki
Hi all!
I'm new on this list. I work on Qubes OS, where Fedora is used as a base
distribution.
While trying to build the installation image in reproducible manner[1],
I found the current installation image have unusual layout. Quoting
dracut.cmdline manual page:
squashfs.img | Squashfs from LiveCD .iso downloaded via network
!(mount)
/LiveOS
|- rootfs.img | Filesystem image to mount read-only
!(mount)
/bin | Live filesystem
/boot |
/dev |
... |
This rootfs.img layer makes the image build very much unreproducible.
Why is it even there? Bare squashfs.img layer should be enough. Then,
mount overlayfs over it (I see there is even some partial support for it
in dmsquash-live). Most other Live systems I've seen use just squashfs +
overlayfs (or aufs if kernel is older), so it's commonly tested
configuration. I *guess* it's there for historical reason, from before
aufs/overlayfs being available. Is there any other reason for that?
If there is no other reason, I propose to drop this and have
installer/live filesystem directly in squashfs.img. This have multiple
benefits:
- it's much easier to make the image build process reproducible (see
below)
- less complexity, both in the build and in the boot (the whole
dmsquash-live dracut module can be replaced with <20 line
function[2]
- smaller initramfs (which is extremely important if needed to be
included in efiboot.img, which can't be larger than 32MB)
- slightly faster boot time (device-mapper is slow)
What do you think?
As for the reproducibility, I've made changes to lorax (including
dropping rootfs.img layer), anaconda, pungi and createrepo and this all
allows to build bit-by-bit identical image, given the same input (rpm
packages, pungi configuration, $SOURCE_DATE_EPOCH variable[3]). Well,
almost - there is an issue with efiboot.img, but I already have a
solution, just not pushed it yet.
You can find all the pull requests collected here:
https://github.com/QubesOS/qubes-installer-qubes-os/pull/26
I'll work further to make the changes merged upstream.
[1] https://reproducible-builds.org/
[2] https://github.com/QubesOS/qubes-installer-qubes-os/pull/26/commits/332be...
[3] https://reproducible-builds.org/specs/source-date-epoch/
--
Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
3 months
Automating Package Review (Was: fedora-review -- do we have a maintainer?)
by Stephen Gallagher
On Thu, Aug 16, 2018 at 8:30 AM Michal Novotny <clime(a)redhat.com> wrote:
> On Thu, Aug 16, 2018 at 10:49 AM Zbigniew Jędrzejewski-Szmek <
> zbyszek(a)in.waw.pl> wrote:
>
>> f-r currently fails to build (#1603956), it has a bunch of bugs open [1]
>> and many issues and unhandled pull requests in the upstream repo [2, 3].
>> The last upstream commit was 2 years ago.
>>
>> f-r has is annoyingly outdated and gives often outright bad advice
>> (for example about BR:gcc or BR:g++). The situation would be
>> significantly
>> improved if the outstanding PRs were merged.
>>
>> f-r is also python2-only now, which will be a problem soon since
>> support for python2 is waning [4].
>>
>> Is there any hope of upstream and downstream activity on f-r?
>>
>
> I was thinking about getting the fedora-review checks rewritten into the
> standard Test interface
> (
> https://qa.fedoraproject.org/docs/libtaskotron/latest/standard-test-inter...)
> so that they
> can be run in Taskotron. We can also just probably run one big
> fedora-review check from
> a taskotron test, well, this just came to my mind recently, getting the
> actual solution ready
> might take a little bit of time.
> '
>
I'd *really* like to see us get to a point where package review is
fully-automated. Basically we could just have a web-service that you pass a
URL to an SRPM plus authenticate with your FAS account and it will perform
all of the validity checks and if they all pass would go ahead and request
the branches for you and import the SRPM.
Once this is fully automated, we can then *also* add the same checks to CI
(taskotron, OSCI or whatever) so that on each build it gets rerun, which
will allow us to help reduce the rate of packages falling out of compliance
(as well as being updated whenever the checks get made more comprehensive).
Historically, we've had human review mainly to protect against two things,
bundling and unacceptable licenses. In both of these cases, I'd like for us
to move towards a culture of assuming goodwill on behalf of our packagers.
Most of the packagers in Fedora have been doing it for a long time and know
what is and is not acceptable. Optimizing for the minority case is
wasteful, especially when it adds hurdles and delays to getting software
delivered.
I think what we should instead do is allow things through immediately
following automated review and just assume that those few cases that slip
through that should not will get handled after the fact as soon as they are
noticed (either by someone noticing or an improvement in the automated tool
discovering the problem).
I feel strongly that automated, continuous review would be of far greater
value to Fedora than front-loading the review process the way we have been
doing (which serves mostly to discourage people from even starting).
4 months
