Fedora 31 System-Wide Change proposal (late): No i686 Repositories
by Miro Hrončok
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/Eve...
or
https://dl.fedoraproject.org/pub/fedora-secondary/development/rawhide/Mod...
* Confirm that there are no trees under
https://dl.fedoraproject.org/pub/fedora-secondary/updates/31/{Everything|...
or
https://dl.fedoraproject.org/pub/fedora-secondary/updates/testing/31/{Eve...
* 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
4 years, 7 months
swap on ZRAM, zswap, and Rust was: Better interactivity in low-memory situations
by Chris Murphy
Hi,
This is yet another follow-up for this thread:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.o...
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/Doc...
"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/Doc...
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
4 years, 7 months
plan to orphan cassandra
by Honza Horak
Cassandra has been originally packaged by folks in our team, in the time
we had some stakes there. Since then, priorities changed and also people
involved are not in our team any more. We tried to keep it packaged in
Fedora with reasonable effort, but turned to be too big burden recently
(depends on python2, missing java deps).
From that reason, with sadness in my heart, I'd like to announce a plan
to orphan the cassandra package in Fedora. So, this is obviously a call
for everybody who would like to take it over -- let me know. There is
also an idea to build it as a module, which could help us with missing
deps, but that would be done later and does not change the plan for
orphaning.
Cheers,
Honza
4 years, 7 months
getting below error in fedpkg clone
by Muneendra Kumar M
Hi ,
Iam getting the below error when I run fedpkg clone fctxpd
fedpkg clone fctxpd
Cloning into 'fctxpd'...
The authenticity of host 'pkgs.fedoraproject.org (209.132.181.4)' can't be
established.
RSA key fingerprint is SHA256:Q12OTyTeOHWlS54dTzy2BNu7wB8UKNf18+7WHIDsORc.
Are you sure you want to continue connecting (yes/no/[fingerprint])? yes
Warning: Permanently added 'pkgs.fedoraproject.org,209.132.181.4' (RSA) to
the list of known hosts.
muneendra(a)pkgs.fedoraproject.org: Permission denied (publickey).
fatal: Could not read from remote repository.
Please make sure you have the correct access rights
and the repository exists.
Could not execute clone: Failed to execute command.
I have added the ssh-key at
https://pagure.io/settings#nav-ssh-tab
But still iam getting the below error.
Can anyone help me where iam doing the mistake.
Regards,
Muneendra.
4 years, 7 months
Donate 1 minute of your time to test upgrades from F29 to F30
by Miroslav Suchý
Do you want to make Fedora 30 better? Please spend 1 minute of your time and try to run:
sudo dnf --releasever=30 --setopt=module_platform_id=platform:f30 --enablerepo=updates-testing distro-sync
If you get this prompt:
...
Total download size: XXX M
Is this ok [y/N]:
you can answer N and nothing happens, no need to test the real upgrade. Upgrades will be fine for you.
But very likely you get some dependency problem now. In that case please report it against appropriate package.
Thank you
Miroslav
4 years, 7 months
Better interactivity in low-memory situations
by Chris Murphy
This subject matches a Fedora Workstation Working Group issue of the
same name [1], and this post is intended to be an independent summary
of the findings so far, and call for additional testing and
discussion, in particular subject matter experts.
Problem and thesis statement:
Certain workloads, such as building webkitGTK from source, results in
heavy swap usage eventually leading to the system becoming totally
unresponsive. Look into switching from disk based swap, to swap on a
ZRAM device.
Summary of findings (restated, but basically the same as found at [2]):
Test system, Macbook Pro, Intel Core i7-2820QM (4/8 cores), 8GiB RAM,
Samsung SSD 840 EVO, Fedora Rawhide Workstation.
Test case, build WebKitGTK from source.
$ cmake -DPORT=GTK -DCMAKE_BUILD_TYPE=RelWithDebInfo -GNinja
$ ninja
Case 1: 8GiB swap on SSD plain partition (not encrypted, not on LVM)
Case 2: 8GiB swap on /dev/zram0
In each case, that swap is exclusive, there are no other swap devices.
Within ~30 minutes in the first case, and ~10 minutes in the second
case, the GUI is completely unresponsive, mouse pointer has frozen and
doesn't recover after more than 30 minutes of waiting. By remote ssh,
the first case is semi-responsive, updates should be every 5 seconds
but are instead received every 2-5 minutes but it wasn't possible to
compel recovery by cancelling the build process after another 30
minutes. By remote ssh, the second case is totally unresponsive, no
updates for 30 minutes.
The system was manually forced power off at that point, in both cases.
oom killer never triggered.
NOTE: ninja, by default on this system, sets N concurrent jobs to
nrcpus + 2, which is 10 on this system. If I reboot with nr_cpus=4,
ninja sets N jobs to 6.
Case 3: 2GiB swap on /dev/zram0
In one test this resulted in system hang (no pointer movement) within
5 minutes of executing ninja, and within another 6 minutes oom killer
is invoked on a cc1plus process, which is fatal to the build process,
remaining build related processes quit on their own, and the system
eventually recovers.
But in two subsequent tests in this same configuration, oom killer
wasn't invoked, and the system meandered between responsive for ~1
minute, totally frozen for 5-6 minutes, in a cycle lasting beyond 1
hour without ever triggering oom killer.
Screenshot taken during one of the moments the remote ssh session updated
https://drive.google.com/open?id=1IDboR1fzP4onu_tzyZxsx7M5cT_RJ7Iz
The state had not changed after 45 minutes following the above
screenshot so I forced power off on that system. But the point here is
this slightly different configuration has some non-determinism to it,
even though in the end it's a bad UX. The default, unprivileged build
command is effectively taking down the system all the same.
Case 4: 8GiB swap on SSD plain partition, `ninja -j 4`
This is the same setup as Case 1, except I manually set N jobs to 4.
Build succeeds, and except for a few mouse pointer stutters, the
system remains responsive, even Firefox with multiple tabs open, and
youtube video playing. Exactly the experience we'd like to see, albeit
not all CPU resources are used for the build, but clearly the limiting
factor is this particular package requires more than ~14GiB to build
successfully, and the system + shell + Firefox, just doesn't have
that.
Starter questions:
To what degree, and why, is this problem instigated by the build
application (ninja in this example) or its supporting configuration
files, including cmake? Or the kernel? Or the system configuration? Is
it a straightforward problem, or is this actually somewhat nuanced
with multiple components in suboptimal configuration coming together
as the cause? Is it expected that an unprivileged user can run a
command whose defaults eventually lead to a totally unrecoverable
system? From a security risk standpoint, the blame can't be entirely
on the user or the application configuration, but how should
application containment be enforced? Other than containerizing the
build programs, is there a practical way right now of enforcing CPU
and memory limits on unprivileged applications? Other alternatives? At
the very least it seems like getting to an oom killer sooner would
result in a better experience, fail the process before the GUI becomes
unresponsive and hangs out for 30+minutes (possibly many hours).
[1]
https://pagure.io/fedora-workstation/issue/98
[2]
https://pagure.io/fedora-workstation/issue/98#comment-588713
Thanks,
--
Chris Murphy
4 years, 7 months
Intention to retire Release Notes RPM
by Brian (bex) Exelbierd
Hi All,
Barring objection, I plan to retire the release notes package from
Fedora on or after August 9, 2019. The package has not been updated
since F28. Despite the fact that we have literally shipped a package
containing the F28 release notes in F29 and F30, there have been no
comments. This has been discussed with the docs team and is
supported. I am not aware of any dependencies and I believe it was
removed from release criteria in F29.
I will run `fedpkg retire` and further request removal via
https://bugzilla.redhat.com/enter_bug.cgi?product=Fedora&version=rawhide&...
Please reply on list if you have any questions or concerns.
regards,
bex
--
Brian "bex" Exelbierd (he/him/his)
Fedora Community Action & Impact Coordinator
@bexelbie | http://www.winglemeyer.org
bexelbie(a)redhat.com | bex(a)pobox.com
4 years, 7 months
Re: Possibly unresponsive maintainer: vakwetu
by Fabio Valentini
On Tue, Jul 9, 2019 at 3:26 PM Rob Crittenden <rcritten(a)redhat.com> wrote:
>
> Fabio Valentini wrote:
> > Hi everybody,
> >
> > While working on packages of the Stewardship SIG, I again came across
> > another package that is in dire need of attention, while its main
> > admin seems to be AWOL (even though the email address associated with
> > his FAS account is a Red Hat one):
> >
> > - no bodhi updates in 4 years [0]
> > - no bodhi comments in 2 years [0]
> > - no koji builds in 4 years [1]
> >
> > There's also been no response to security issues on bugzilla,
> > including CVE-2016-6346, CVE-2016-6347, CVE-2018-1051, CVE-2016-9606,
> > CVE-2016-6345, CVE-2016-6348 - all of which are filed against the
> > resteasy package, which is, entirely by coincidence (*sigh*), exactly
> > the package that we need fixed for some Stewardship SIG packages.
> >
> > Since it looks like he's not been contributing to fedora in about 2-4
> > years, I will initiate the non-responsive maintainer process with
> > FESCo if I don't get any negative feedback within a week.
> >
> > Fabio (decathorpe)
> >
> > [0]: https://bodhi.fedoraproject.org/users/vakwetu
> > [1]: https://koji.fedoraproject.org/koji/userinfo?userID=2030
>
> He's on PTO for a few weeks.
>
> rob
Good to know, thanks!
If it's necessary to fix the broken package (resteasy) before he's
back, I'll use my provenpackager powers.
Fabio
4 years, 7 months
Packit-as-a-Service is now live!
by Tomas Tomecek
We are happy to announce the availability of Packit-as-a-Service [1],
a GitHub App, which utilizes the Packit project [2].
Using the Packit service in your upstream projects helps you
continuously ensure that your projects work in Fedora OS. Just add one
config file [3] to your repository, along with the RPM spec file and
you're almost there. We have started publishing docs for the service
over here [4].
In the next couple of months, Packit Service will run in an
invite-only mode, where we need to manually approve every user of the
app. Our initial target is Fedora contributors.
Packit service validates your pull requests by building your software
in Fedora OS. Once the builds are done, Packit lets you know how to
install the RPM with the change inside your environment.
Packit service helps you test the changes before merging them to the
main developer branch and shipping them to your users.
Happy hacking!
The packit team
[1] https://github.com/apps/packit-as-a-service/
[2] https://packit.dev/
[3] https://github.com/packit-service/packit/blob/master/docs/configuration.md
[4] https://packit.dev/packit-as-a-service/
4 years, 7 months
Interest in doing Fedora CI with test subpackages
by Neil Horman
Hey all-
I was starting to setup CI for one of my packages in Fedora (cscope),
which requires that I have access to the sources to run my test (cscope uses its
own source tree to search for various symbols to confirm that its working
properly). Getting the sources in the CI environment is a bit of a pain, so I
started working on trying to do this by creating a test subpackage (specifically
named -citest) to package up the sources solely for the purpose of getting them
installed and available during CI runs. It occured to me that this offers
several advantages, among them:
1) the ability to codify dependencies within the ame spec file, rather than
having to copy them to the test.yml file, and keep them in sync
2) The ability to use a file format (rpm spec files) that I'm more familiar with
3) Easy access to tests that are embedded in the source tree
4) minimizing the test harness setup in test.yml
For anyone interested, I've got a pull request started here:
https://src.fedoraproject.org/rpms/cscope/pull-request/2
If anyone wants to take a look at the changes I had to make to do this (fair
warning, its still very rough).
That all said, I was wondering if perhaps there was general interest in making
this kind of test model somewhat more formal (i.e. creating an rpm macro library
to make test package generation a bit easier, creating a standard entry point to
run tests, etc).
Thoughts welcome
4 years, 7 months