https://fedoraproject.org/wiki/Changes/AArch64_Xfce_Desktop_image
== Summary ==
Add an AArch64 Xfce Desktop image to deliverables in Fedora 31.
== Owner ==
* Name: [[User:pwhalen| Paul Whalen]]
* Email: pwhalen(a)fedoraproject.org
* Responsible WG: ARM SIG
== Detailed Description ==
We currently offer Workstation, Minimal and Server images for use with
AArch64 Single Board Computer's (SBC's). We would like to add a
lighter weight desktop image for hardware that lacks the ability to
run accelerated desktops.
An initial set of supported devices:
* Pine64
* Raspberry Pi 3/4
* 96boards HiKey
* 96boards Dragonboard 410c
== Benefit to Fedora ==
Better user experience and an additional desktop choice for AArch64 SBC's.
== Scope ==
* Proposal owners: The ARM SIG will make the kickstart changes needed
to add the desktop images to the compose.
* Other developers: N/A
* Release engineering: Enable building of the AArch64 XFCE desktop
image. Small tweaks may be required to the pungi configs or fedora
kickstarts but those will be completed by the SIG and sent as pull
requests. Issue[https://pagure.io/releng/issue/8556 #8556]
* Policies and guidelines: N/A (not needed for this Change)
* Trademark approval: N/A (not needed for this Change)
== Upgrade/compatibility impact ==
No upgrade compatibility required, this is a new image variant.
== How To Test ==
Testing can be completed on any supported AArch64 SBC using the
existing arm-image-installer. Any additional instructions will be
added to the ARM installation documentation.
== User Experience ==
Users will have increased choice in desktop offerings for AArch64
SBC's. Those looking to install a desktop on hardware that lacks an
accelerated graphics driver or lower system specifications will have a
useable option.
== Dependencies ==
N/A (not a System Wide Change)
== Contingency Plan ==
* Contingency mechanism: N/A
* Contingency deadline: N/A
* Blocks release? No
* Blocks product? No
== Documentation ==
All documentation will be added or updated via the ARM Landing Page.
--
Ben Cotton
He / Him / His
Fedora Program Manager
Red Hat
TZ=America/Indiana/Indianapolis
Hello.
Recently, a couple hundred packages were retired from rawhide (Fedora 31 at that
time) based on the Fedora Failed to Build From Source Policy [1]. From various
reactions over several threads it seems this policy is not ideal. This is an
attempt to collect feedback and make the policy better serve Fedora's needs.
Fedora has a policy for a long time that can be simplified as:
1. Mass rebuild for Fedora N happens by releng
2. Packages that fail to build get open bugzillas by releng
3. Packages with NEW bugizllas are orphaned after 8 weeks with weekly
reminders by releng
4. A week before Fedora N+1 branching any packages which still have open
Fedora N FTBFS bug are retired by releng
However, 3 or 4 haven't happened since Fedora ~26, because the automation was
not working any more for various reasons I don't understand.
The policy was then updated by FESCo to allow anybody to step up and do 3. manually.
However it needs 2 e-mails to devel directed at the package owners and that may
be understood as a personal attack by some.
So nobody ever did that but me (twice) IIRC (and I got my share of shame for that).
Currently, the FTBFS retirement is problematic due to various things:
1) Bugzilla spam: Maintainers are spammed weekly by releng, some of them find
that annoying and simply switch the bug to ASSIGNED to make it stop.
The problem is, how do we both keep notifying the maintainers that action is
needed and not spam them with stuff that will make them filter all Fedora
e-mails to /dev/null.
2) Retirement out of the blue. When releng executes 4., packagers that stopped
the bugzilla spam by setting the bug to ASSIGNED are suddenly surprised the
package was retired. OTOH arguably they made a deliberate action to stop the
notifications. However, most importantly, any dependent packages were not
notified at all, which is **not fair**.
This state is broken mostly because there is no automatic orphaning of packages
that have NEW bugzillas and there is no orphaning at all for packages where the
bugzillas are ASSIGNED for months. For the second bit, everything indicates that
packagers are aware of the problem and will fix the bug in time before 4., but
they don't and things blow up.
3) Questionable importance of the FTBFS bug.
Repeatedly, it has been stated by some, the FTBFS bug is not important and we
should not retire packages at all based on the fact that they "simply" fail to
build. I personally don't agree with this for various reasons, but I can imagine
a situation, where it is reasonable to say so and delay the problem. Obvious
argument is: Better to have 1 package nonbuildable than have 100 packages
nonisntallable. So we need a way to opt-out from the retirement, however simply
setting the bugzilla to ASSIGNED is not it, because we will end up with packages
last built 6 years ago (and I believe this is not what we want).
I'm starting this thread to collect the ideas about how to make this better.
If you see more problems, share them. I promise I'll do my best to make the
policy work better for both Fedora and the people who make Fedora.
[1]
https://docs.fedoraproject.org/en-US/fesco/Fails_to_build_from_source_Fails…
--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
Is anything happening with introducing MPFR 4 into Fedora? I found these:
https://fedoraproject.org/wiki/Changes/mpfr-4.0.0https://bugzilla.redhat.com/show_bug.cgi?id=1537252
but they indicate that efforts to update have come to a halt. I ask
because I have had to patch 2 of my packages to keep them working with
MPFR 3, and I've got more that are said to work with either version 3
or version 4.
I am willing to put some effort into making the update happen. I
agree with the previous assessments that we will probably have to make
the two versions parallel installable for awhile, possibly for quite
awhile, until everything can be migrated to version 4.
This is the list of source packages in Fedora 30 that depend on
libmpfr, with asterisks by the ones I maintain, comaintain, or just
tend to meddle with:
R-Rmpfr
Singular (*)
apron (*)
arb (*)
arm-none-eabi-gcc-cs
avr-gcc
cross-gcc
fawkes
flint (*)
gap-pkg-float (*)
gappa (*)
gawk
gcc
gdb
genius
ghdl
giac
gnome-calculator
gretl
ledger
libbytesize
libfplll (*)
libmpc
libqalculate
libscs
mingw-gcc
mpfi (*)
nacl-gcc
ocaml-mlgmpidl
ocaml-tplib (*)
octave-interval
openscad
polymake (*)
pynac (*)
python-fpylll (*)
python-gmpy2 (*)
rasqal
sagemath (*)
sirocco (*)
texlive-base
why (*)
Wow, I didn't realize how many packages I work with that consume mpfr.
That makes 16 out of 41, so I can manage moving 40% of the mpfr-using
packages over to version 4 all by myself. And, truth be told, there
are 4 more on that list that I've committed changes to at one point or
another, so I've had my fingers on 50% of them. Good grief.
Is somebody working on this already, and if so, what have you
accomplished so far, and what are your future plans? How can I help?
--
Jerry James
http://www.jamezone.org/
We're just over a month away from Hacktoberfest[1], a month-long event
where people can earn a t-shirt by contributing to open source
projects (or at least ones hosted on GitHub). It occurs to me that we
could have a post on the Community Blog (or maybe Fedora Magazine)
that directs folks toward Fedora or Fedora-adjacent projects on
GitHub. This is a good opportunity to get meaningful drive-by
contributions and perhaps add a few consistent contributors.
So if you were going to point the Fedora community at a GitHub-hosted
project, what would you choose?
[1] https://hacktoberfest.digitalocean.com/
--
Ben Cotton
He / Him / His
Fedora Program Manager
Red Hat
TZ=America/Indiana/Indianapolis
Hello devel,
The NeuroFedora SIG is working to create a Comp-Neuro Fedora Labs
<https://labs.fedoraproject.org/> live image/installer. We would also
like group our packages into an easier-to-install format for our target
audience, which may include researchers who are new to Fedora.
To this end we would like to respectfully request the addition of two
new groups in Comps.XML
<https://fedoraproject.org/wiki/How_to_use_and_edit_comps.xml_for_package_gr…>.
The first group would be "neuro-simulators" which would include several
simulation packages as mandatory installs and a dozen or so python
packages as default installs.
The second group would be "comp-neuro-tools" and would include many of
the packages found on the Neuro-SIG group's page on src.fp.o
<https://src.fedoraproject.org/group/neuro-sig> as well as the software
being packaged on the NeuroFedora pagure
<https://pagure.io/neuro-sig/NeuroFedora/issues>.
More information on the Comp-Neuro Lab image and NeuroFedora in general:
*
comps group discussion:https://pagure.io/neuro-sig/NeuroFedora/issue/198
*
NeuroFedora team:https://pagure.io/group/neuro-sig
*
NeuroFedora documentation:https://neuro.fedoraproject.org
<https://neuro.fedoraproject.org/>
*
NeuroFedora blog:https://neuroblog.fedoraproject.org
<https://neuroblog.fedoraproject.org/>
*
NeuroFedora packages:https://src.fedoraproject.org/group/neuro-sig
*
The logo/stickers etc for NeuroFedora were created by the Fedora
design team and reside
here:https://pagure.io/neuro-sig/NeuroFedora/blob/master/f/Artwork
*
We've already presented NeuroFedora to the neuroscience community at
this year's annual conference,
CNS*2019:https://www.cnsorg.org/cns-2019-quick. Our poster is
here:https://pagure.io/neuro-sig/2019-NeuroFedora-poster-CNS/blob/master/f/2019-CNS-NeuroFedora.pdf
--
Danny Lee <dreamer(a)panix.com> I have been impressed with the urgency of
doing. Knowing is not enough; we must apply. Being willing is not
enough; we must do. ~ Leonardo da Vinci
https://fedoraproject.org/wiki/Changes/Noi686Repositories
(Ben is on vacation, so I announcing this on his behalf.)
== Summary ==
Stop producing and distributing the Modular and Everything i686 repositories.
== Owner ==
* Name: Kevin Fenzi
* Email: kevin(a)scrye.com
== Current status ==
* Targeted release: [[Releases/31| Fedora 31 ]]
* Last updated: <!-- this is an automatic macro — you don't need to change this
line --> {{REVISIONYEAR}}-{{REVISIONMONTH}}-{{REVISIONDAY2}}
* Tracker bug: <will be assigned by the Wrangler>
* Release notes tracker: <will be assigned by the Wrangler>
== Detailed Description ==
With the dropping of the i686 kernel package it's no longer possible to directly
install Fedora 31 or later on i686 hardware, however, it is still possibly to
upgrade older releases as long as we continue to provide a repository. This will
leave those users with an old possibly vulnerable kernel installed.
The only other use/need for the repostories is to allow maintainers to debug and
test fixes for multilib shipped packages, but the koji buildroot repo can be
used for this use case.
== Benefit to Fedora ==
* users won't try and upgrade old i686 installs with insecure kernels.
* compose times will be decreased (no more gathering i686 packages up and
running createrepo on them).
* Updates push times will be reduced.
* disk size on mirrors will be reduced.
== Scope ==
* Proposal owners:
** modify pungi-fedora to no longer produce i386 repo for Everything and
Modular, modify bodhi config for f31+ to not make i386 repos for
updates/updates-testing.
** modify mock to use the koji buildroot for i686 for f31+ for those few users
that need to build i686 packages locally.
* Other developers: n/a
* Release engineering: [https://pagure.io/releng/issues 8529]
== Upgrade/compatibility impact ==
i686 users will not be able to upgrade, and will have to move to another
supported arch.
== How To Test ==
* Confirm that there are no trees under
https://dl.fedoraproject.org/pub/fedora-secondary/development/rawhide/Every…
or
https://dl.fedoraproject.org/pub/fedora-secondary/development/rawhide/Modul…
* Confirm that there are no trees under
https://dl.fedoraproject.org/pub/fedora-secondary/updates/31/{Everything|Mo…
or
https://dl.fedoraproject.org/pub/fedora-secondary/updates/testing/31/{Every…
* Confirm that mock can init a chroot for fedora-i386-31 using the koji
buildroot repository.
== User Experience ==
* Users will get updates and rawhide and rc composes faster.
* Users will not be able to upgrade to a insecure Fedora configuration.
== Contingency Plan ==
i686 trees will just continue to be composed and published. Users can upgrade to
them (with an old kernel from f30).
--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
Hi,
This is yet another follow-up for this thread:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org…
Basics:
"zswap" compresses swap and uses a defined memory pool as a cache,
with spill over (still compressed) going into a conventional swap
partition. The memory pool doesn't appear as a separate block device.
A conventional swap partition on a drive is required.
https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/tree/Docum…
"swap on ZRAM" A ZRAM device appears as a block device, and is
effectively a compressed RAM disk. It's common for this to be the
exclusive swap device, of course it is volatile so in that
configuration your system can't hibernate. But it's also possible to
use swap priority in fstab to cause the ZRAM device to be used with
higher priority, and a conventional swap partition on a drive with a
lower priority.
https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/tree/Docum…
What they do:
Either strategy can help avoid swap thrashing, by moderating the
transition from exclusively RAM based work, to heavy swapping on disk.
In my testing, the most aggressive memory starved workloads still
result in an unresponsive system. Neither are a complete solution,
they really seem to just be moderators that kick the can down the
road. But I do think it's an improvement especially in the incidental
swap use case, where transition from memory to swap isn't noticeable.
Which is better?
I don't know. Seriously, that's what all of my testing as come down
to. A user won't likely notice the difference. Both dynamically
allocate memory to their "memory pools" on demand. But otherwise, they
really are two very different implementations. Regardless, Fedora
Workstation and probably even Fedora Server, should use one of them by
default out of the box.
IoT folks are already using swap on ZRAM by default, in lieu of a disk
based swap partition. And Anaconda folks are doing the same for low
memory devices when the installer is launched. I've been using zswap
on Fedora Workstation edition on my laptop, and Fedora Server on an
Intel NUC, for maybe two years (earlier this summer I switched both of
them swap on ZRAM to compare).
How are they different?
There are several "swap on ZRAM" implementations. The zram package in
Fedora right now is what IoT folks are using which installs a systemd
service unit to setup the ZRAM block device, mkswap on it, and then
swapon, during system startup. Simple.
The ideal scenario is to get everyone on the same page, and so far it
looks like systemd's zram-generator, built in Rust, meets all the
requirements. That needs to be confirmed, but also right now there's a
small problem, it's not working. So we kinda need a someone familiar
with Rust and systemd to take this on, if we want to use the same
thing everywhere.
https://github.com/systemd/zram-generator/issues/4
Whereas zswap is setup by using boot parameters, which we could have
the installer set, contingent on a conventional swap partition being
created.
zswap.enabled=1 zswap.compressor=lz4 zswap.max_pool_percent=20 zswap.zpool=zbud
Zswap upstream tells me they're close to dropping the experimental
status, hopefully by the end of the summer. It might be a bit longer
before they're as confident with zpool type z3fold.
Hackfest anyone?
--
Chris Murphy