Fedora-Cloud-32-20201222.0 compose check report
No missing expected images. Soft failed openQA tests: 1/7 (x86_64), 1/7 (aarch64) (Tests completed, but using a workaround for a known bug) Old soft failures (same test soft failed in Fedora-Cloud-32-20201220.0): ID: 745559 Test: x86_64 Cloud_Base-qcow2-qcow2 cloud_autocloud URL: https://openqa.fedoraproject.org/tests/745559 ID: 745566 Test: aarch64 Cloud_Base-qcow2-qcow2 cloud_autocloud@uefi URL: https://openqa.fedoraproject.org/tests/745566 Passed openQA tests: 6/7 (x86_64), 6/7 (aarch64) -- Mail generated by check-compose: https://pagure.io/fedora-qa/check-compose ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Orphaning nodeja-svgo
On 2020-12-21 10:49 p.m., Benson Muite wrote: On 12/22/20 9:25 AM, Luya Tshimbalanga wrote: Due to multiple missing nodejs dependencies needed for nodejs-svgo, I had to orphan it. That plugin was intended for Inkscape sgvo. Maintainers are welcome to grab it. https://src.fedoraproject.org/rpms/nodejs-svgo How does this compare to Scour ? It used to compress better. I haven't tried the new version of scour yet. Is this a better alternative: https://github.com/juanfran/svgo-inkscape svgo-inkscape depends of nodejs-svgo thus useless. In the long run, might https://github.com/svgpp/svgpp be a place to add SVG cleaning functionality? I never used svg++. ___ -- Luya Tshimbalanga Fedora Design Team Fedora Design Suite maintainer ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Fedora CoreOS rawhide stream
On 21. 12. 20 23:34, Jonathan Lebon wrote: We've recently started a rawhide "mechanical" stream of Fedora CoreOS (mechanical streams are streams that are meant for developers and that don't use RPM lockfiles). You can see the first build here: https://builds.coreos.fedoraproject.org/browser?stream=rawhide This will allow us to more easily track breaking changes in rawhide and work with maintainers and upstreams to resolve them earlier in the process. (Yes, this is long overdue -- better late than never!) Thank You, Jonathan! -- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Fedora 34 Change: Enable systemd-oomd by default for all variants (System-Wide Change)
Dne 21. 12. 20 v 23:20 Aleksei Bavshin napsal(a): On 12/21/20 1:53 PM, Neal Gompa wrote: On Mon, Dec 21, 2020 at 4:52 PM Aleksei Bavshin wrote: On 12/21/20 8:28 AM, Ben Cotton wrote: == Documentation == https://www.freedesktop.org/software/systemd/man/systemd-oomd.html/> https://www.freedesktop.org/software/systemd/man/oomctl.html https://www.freedesktop.org/software/systemd/man/oomd.conf.html Be aware that if you intend to enable monitoring and actions on user.slice, user-$UID.slice, or their ancestor cgroups, it is highly recommended that your programs be managed by the systemd user manager to prevent running too many processes under the same session scope (and thus avoid a situation where memory intensive tasks trigger systemd-oomd to kill everything under the cgroup). If you're using a desktop environment like GNOME, it already spawns many session components with the systemd user manager. This makes me slightly very concerned. According to cgls, I have most of the apps running directly under user-$UID.slice -> session-X.scope. That includes a compositor (sway) and a few applications that consume uncomfortably close to 100% of available memory (firefox, thunderbird, clangd, gcc, etc...). My understanding is that unless I configure all of the above to run under dedicated scopes, an attempt to run a memory-intensive task would make systemd-oomd terminate the whole user slice with all my apps. Is there anything that could be improved for that scenario? I don't expect that all our desktop users would start using `systemd-run --scope --user` to launch their applications. My understanding is that we intend to do exactly that for you automatically when you open an application through a desktop file. So it should be fine from that perspective. Should I mention that this is happening not in GNOME and neither make nor vim are using desktop files to start subprocesses? And there are dozens of application launchers in Fedora repositories that aren't aware of systemd or cgroups. And I wonder what will be the behavior for applications, which I start from my terminal? The most typical example for me is running GVim from gnome-terminal. Vít I'm raising that point because I'd like to have at least a set of recommendations for any alternative environments. So far it seems like the impact outside of major DEs and standard desktop workflows wasn't considered. Don't take this as an antagonism to the proposal, I see the benefits of systemd-oomd and will likely use it myself with a few shell aliases, patches and config changes. It's just that as a maintainer of one of those alternative desktop environments I have no idea how to make that work in default configuration. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org OpenPGP_0x0CE09EE79917B87C.asc Description: application/pgp-keys OpenPGP_signature Description: OpenPGP digital signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Disabling Python Dependency Generator Challenges
On 21. 12. 20 17:30, Georg Sauthoff wrote:
Hello,
I'm trying to build a fedora package for EPEL8 on Copr and I'm wondering
where its pikepdf dependency is coming from.
I conditionally disable the python dependency generator with a 0%{?epel}
guard
(cf.
https://github.com/gsauthof/copr-fedora/blob/c4bf0d2031b529e637d085a84837325dde36f1c2/python-img2pdf/python-img2pdf.spec#L62-L72
):
%if 0%{?epel} == 0
# this is basically equivalent to adding Requires: for
# pikepdf
# pillow
#
# the generator is enabled by default, since f30 or so
%{?python_enable_dependency_generator}
%else
%{?python_disable_dependency_generator}
Requires: python3-pillow
%endif
The guard seems to work (because e.g. the in the same way disabled tests
aren't executed, as I can see from the build.log.
However, the final rpm package still depends on pikepdf:
python3.6dist(pikepdf)
(cf. the end of
https://download.copr.fedorainfracloud.org/results/gsauthof/fedora/epel-8-x86_64/01843500-python-img2pdf/build.log.gz
)
Thus, it looks like disabling the dependency generator with the
python_disable_dependency_generator macro didn't work?
Hello Georg,
It seems that the macro is not defined in EPEL 8 at all.
Fedora:
$ grep -r -A2 python_disable_dependency_generator /usr/lib/rpm
/usr/lib/rpm/macros.d/macros.python:%python_disable_dependency_generator() \
/usr/lib/rpm/macros.d/macros.python-%undefine __pythondist_requires \
/usr/lib/rpm/macros.d/macros.python-%{nil}
EPEL 8 mock:
# grep -r -A2 python_disable_dependency_generator /usr/lib/rpm
(nada)
As a workaround, you could do what the macro does on Fedora:
%undefine __pythondist_requires
But we should get that macro introduced. The generators are owned by
epel-rpm-macros, not RHEL's python*-rpm-macros, so the fix needs to be done there.
---
As a side note, I wonder why do you need to resort to disabling the automatic
requires generator? If the dependency on pikepdf is bogus, work with upstream to
remove it. In the mean time, sed/patch it out form upstream metadata in %prep.
It is: https://gitlab.mister-muffin.de/josch/img2pdf/blob/master/setup.py#L8
--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Disabling Python Dependency Generator Challenges
On 22. 12. 20 10:48, Miro Hrončok wrote: On 21. 12. 20 17:30, Georg Sauthoff wrote: Thus, it looks like disabling the dependency generator with the python_disable_dependency_generator macro didn't work? Hello Georg, It seems that the macro is not defined in EPEL 8 at all. ...snip... But we should get that macro introduced. The generators are owned by epel-rpm-macros, not RHEL's python*-rpm-macros, so the fix needs to be done there. Here: https://src.fedoraproject.org/rpms/epel-rpm-macros/pull-request/28 -- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
libmemcached replacement
Hi, libmemcached exists in Fedora for years and is used by lot of projects to handle communication with a memcached server. Sadly this project is dead: https://launchpad.net/libmemcached/ Last version released in 2014 and nearly no git activity since this A fork now exists https://github.com/m6w6/libmemcached/ Version 1.1.0beta1 is released and is design to be a drop in replacement, with API and ABI compatibility I've start working on a package update and this will probably become the new upstream for the fedora libmemcached package Comment / idea ? Remi P.S. of course, I'm mostly interested by the the PHP extension which uses it https://pecl.php.net/package/memcached ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Should we retire ardour5 in rawhide?
Hi, ardour5 fails to build in rawhide and it has been obsoleted by ardour6. Should we retire it in rawhide? Nils, if you can give me commit access to ardour6 I can help build the new version as they are released. My FAS account: tartina Thanks Ciao Guido signature.asc Description: This is a digitally signed message part ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: What is the most time consuming task for you as packager?
On 21. 12. 20 19:36, Kevin Fenzi wrote: On Thu, Dec 17, 2020 at 09:21:15PM +0100, Fabio Valentini wrote: As Miro mentioned, I've also developed scripts to handle this "does this update break anything" for the Stewardship / Java SIG, because - at least at first - we didn't have big enough egos / enough confidence to just push updates to rawhide without testing excessively them first: https://github.com/fedora-stewardship/fedora-stewardship.github.io/blob/master/scripts/review_pr.py This first builds (one or more) packages from src.fpo dist-git forks that were prepared for PRs in COPR, recursively or non-recursively queries dependent packages for all of them, and rebuilds them in COPR. Assuming that there's a copr-cli command for querying build successes, they could be compared with the latest status of those packages in koschei, and have it print new build failures. Right now, I compare the results manually. Would something like this fit your definition of "does-it-blend" script? What format is '--from-git' in? Say I have a fork with a branch I want to test, what do I pass it? --from-git is a regex of package names that are built from dist git instead of from latest known SRPM. AFAIK The script only supports "the one package" (that is being tested) to be built from a custom branch, whoch is the purpose of the script: $ python scripts/review_pr.py foobar-2.0 kevin:foobar:branch-2.0 But you can later built another package in there (with or without depndents) in the same copr: $ python scripts/review_pr.py foobar-2.0 kevin:bazbaz:fix_deps [-nx'.*'] This is indeed the sort of thing I was thinking of (I think). -- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Chromium built in rawhide does not render most strings
Am 17.12.20 um 17:12 schrieb Tom Callaway: Okay, this one has me stumped. Any chromium package I build through rawhide refuses to render most of the strings. Any updates on this? Best regards, Marius Schwarz ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Fedora GNOME Shell rendering problem
On Mon, 21 Dec 2020 08:09:50 -0500, Owen Taylor wrote: > Most likely the GPU driver. This is a symptom of a corrupted Xft glyph > cache inside the Xwayland X server. > > (It's not impossible that the glyph was corrupted before upload by > some other component, but that's much less likely - especially if it > seems to be hardware dependent.) It's been observed on Nouveau driver based installations / with no Nvidia related packages from RPM Fusion as to test whether default installations of Fedora Workstation would work acceptably out of the box. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Fedora 34 Change: DNF/RPM Copy on Write enablement for all variants (System-Wide Change)
On Mon, Dec 21, 2020, 8:19 PM Davide Cavalca via devel < devel@lists.fedoraproject.org> wrote: > On Mon, 2020-12-21 at 12:54 -0400, Robert Marcano via devel wrote: > > On 12/21/20 12:28 PM, Ben Cotton wrote: > > > ... > > > > > > === New process === > > > > > > # Resolve packaging request into a list of packages and operations > > > # Download and '''decompress''' packages into a '''locally > > > optimized''' rpm file > > > # Install and/or upgrade packages sequentially using RPM files, > > > using > > > '''reference linking''' (reflinking) to reuse data already on disk. > > > > This sound great because free space requirements can be reduced, > > specially when installing new packages. > > > > I have experimented building very small appliances using btrfs > > compression on things like /usr/share. So I think this could disrupt > > this because if I am correct the extends will be first downloaded to > > a > > temporary directory without compression enabled. > > For CoW to be beneficial, the package cache should be on the same > filesystem used for the bulk of the system. In this scenario, > compression should work just fine, as long as it's enabled on the > appropriate subvolumes. > On btrfs there is a compression file flag so you can set compression on a directory without having compression on the DNF cache directory on the same volume > > > I am happy with an option to disable this behavior. > > To be clear, for this Change we do not plan to enable CoW by default. > If would be a user opt-in via the dnf-plugin-cow package. > Good, thanks > Cheers > Davide > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org > lol > ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Review Request: rubygem-asciidoctor-diagram - Asciidoctor diagramming extension
Hello, Would it be possible to get a review on this please? On Tue, 24 Nov 2020 at 22:58, Christopher Brown wrote: > Greetings, > > I'm the current maintainer for the asciidoctor-pdf package plus various > dependencies in Fedora and have spent some time putting together the > following review request for a diagramming extension for Asciidoctor. > > Appreciate any reviews. > > BZ: https://bugzilla.redhat.com/show_bug.cgi?id=1897619 > Spec: > https://raw.githubusercontent.com/snecklifter/rubygem-asciidoctor-diagram/master/rubygem-asciidoctor-diagram.spec > Copr: > https://copr.fedorainfracloud.org/coprs/snecker/rubygem-asciidoctor-diagram/ > > Thanks! > > Chris > -- Christopher Brown Senior Consultant Red Hat UK Ltd chris.br...@redhat.com ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Review Request: rubygem-asciidoctor-diagram - Asciidoctor diagramming extension
On 12/22/20 12:23 PM, Christopher Brown wrote: Hello, Would it be possible to get a review on this please? You can't provide precompiled jar files, they needs to be build from source: Issues: === - Bundled jar/class files should be removed before build Note: Jar files in source (see attachment) See: https://docs.fedoraproject.org/en-US/packaging- guidelines/Java/#_pre_built_dependencies Jar and class files in source - ./asciidoctor-diagram-2.0.5/lib/batik-all-1.10.jar ./asciidoctor-diagram-2.0.5/lib/ditaa-1.3.15.jar ./asciidoctor-diagram-2.0.5/lib/ditaamini-0.12.jar ./asciidoctor-diagram-2.0.5/lib/jlatexmath-minimal-1.0.5.jar ./asciidoctor-diagram-2.0.5/lib/plantuml-1.3.15.jar ./asciidoctor-diagram-2.0.5/lib/plantuml.jar ./asciidoctor-diagram-2.0.5/lib/server-1.3.15.jar ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Fedora 34 Change: Enable systemd-oomd by default for all variants (System-Wide Change)
On 21.12.2020 17:28, Ben Cotton wrote: Provide a better experience for Fedora users in out-of-memory (OOM) situations by enabling systemd-oomd by default. Earlyoom maintainer here. I think it's too early to switch to systemd-oomd, because it was just merged to the systemd codebase and is still an experimental feature. In earlyoom we have a list of processes that cannot be killed (eg. dnf/packagekit/etc.), so it is absolutely safe to use as a default userspace OOM solution. We currently don't know anything about the systemd-oomd safety for regular use on end user desktops. We can't even test it on the current stable Fedora release. That's why I think this change need to be postponed to Fedora 35 (opt-in in F34 and default in F35). -- Sincerely, Vitaly Zaitsev (vit...@easycoding.org) ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Orphaning rubygem-debug_inspector
Hi, rubygem-debug_inspector used to be dependency of rubygem-web-console, but it is not anymore. Since there is no other dependency have orphaned the package. BTW it seems the current version is not compatible with upcoming Ruby 3.0. Vít OpenPGP_0x0CE09EE79917B87C.asc Description: application/pgp-keys OpenPGP_signature Description: OpenPGP digital signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: our containers with alias vim=vi
I have just noticed in f33 container, this change was implemented:
[root@9c06602a8aa6 ~]# vim /etc/yum.repos.d/x.repo
No vim found, using vi, press ENTER to continue
It's much much better, thank you a lot to the maintainer (probably Zdenek)!
On Wed, 14 Oct 2020 at 13:29, Jonathan Wakely wrote:
>
> On 13/10/20 16:04 +0200, Zdenek Dohnal wrote:
> >On 10/13/20 12:34 PM, Jonathan Wakely wrote:
> >> On 13/10/20 07:45 +0200, Zdenek Dohnal wrote:
> >>>
> >>> On 10/12/20 5:15 PM, Joe Doss wrote:
> On 10/12/20 1:50 AM, Zdenek Dohnal wrote:
> > This would break using Vim when vim-minimal and vim-enhanced are
> > installed (it would start Vi instead of typed Vim). To make it work,
> > vim-minimal would have to conflict with vim-enhanced, which doesn't
> > make
> > sense - Vi and Vim binaries can exist together just fine.
>
> I have vim-enhanced and vim-minimal installed
>
> # rpm -qa |grep vim
> vim-common-8.2.1770-1.fc33.x86_64
> vim-filesystem-8.2.1770-1.fc33.noarch
> vim-minimal-8.2.1770-1.fc33.x86_64
> vim-enhanced-8.2.1770-1.fc33.x86_64
>
> and when I type vi it launches vim.
> >>> I'm sorry I forgot about this alias - yes, there is an alias which is
> >>> applied when both - vim-minimal and vim-enhanced - are installed so it
> >>> launches 'vim' when you type 'vi'. I would say less people will complain
> >>> if something has more features than if it has less, so I'm content with
> >>> this alias.
>
> # whereis vi
> vi: /usr/bin/vi /usr/share/man/man1p/vi.1p.gz
> /usr/share/man/man1/vi.1.gz
> # /usr/bin/vi --version
> VIM - Vi IMproved 8.2 (2019 Dec 12, compiled Sep 29 2020 00:00:00)
>
> It doesn't look like these are existing together just fine. It seems
> that vim takes over vi. Shouldn't these conflict and only one can be
> installed over the other?
> >>> 'Vi' as the original project is no longer (I'm not sure for how long)
> >>> shipped in Fedora. 'Vi' we ship is just 'VIM' compiled with 'small' set
> >>> of features (f.e. without syntax highlighting) to mimic the original
> >>> 'Vi'. So if you run 'vi --version' it always shows 'VIM'.
>
> > In the end I find it incorrect to mislead users by default by telling
> > them 'Vim works' but Vi is run instead - Vi and Vim don't have the
> > same
> > set of features, which may lead into bug reports caused by this
> > mistake.
>
> Isn't that the reverse behavior detailed above? I type vi on Fedora
> Workstation it launches vim? I assume this isn't causing bug reports.
> >>> You're right, as I wrote above - aliasing vi->vim doesn't seem as a
> >>> problem to me, but aliasing vim->vi as clime suggested can cause mislead
> >>> for users.
> >>
> >> I would also appreciate if "vim" ran the executable installed by
> >> vim-minimal. I frequently type "vim" on servers I don't own and then
> >> grumble that it fails and I have to run "vi" instead. It **is** vim,
> >> it's just not installed with that name. Insisting that users call it
> >> vi when we know it's vim and they know it's vim seems unnecessary.
> >
> >It's Vim but with a different set of features - VIM compiled as Vi
> >binary is trying to be small, kind of simulate Vi behavior without
> >setting 'compatible'.
> >
> >Since you know it has less features, good for you. But unfortunately,
> >not all users know - there was already a report about Vim missing
> >highlighting, and the reporter was running /usr/bin/vi. So my aim is to
> >prevent such a report.
> >
> >>
> >> $ rpm -qf /usr/bin/vi
> >> vim-minimal-8.2.1770-1.fc32.x86_64
> >>
> >> Could vim-minimal and vim-enhanced both install the same
> >> /etc/profile.d/vim.sh file that did something like this?
> >Installing the same file would mean to set conflicts between those two
> >package, wouldn't it? Or would you mind explaining how to achieve it?
>
> RPM allows a file to be owned by more than one package. Fedora has
> allowed this for eight years:
> https://pagure.io/packaging-committee/issue/138
> https://docs.fedoraproject.org/en-US/packaging-guidelines/#_file_and_directory_ownership
>
> The file would be owned by both packages, and only removed if both
> packages get removed. That means it would be present if at least one
> of them was installed.
>
> >>
> >> if [ -n "${BASH_VERSION-}" -o -n "${KSH_VERSION-}" -o -n
> >> "${ZSH_VERSION-}" ]; then
> >> Â [ "`/usr/bin/id -u 2>/dev/null || echo 0`" -le 200 ] && return
> >> Â # for bash and and ksh and zsh
> >> Â case "$(type -t vim)-$(type -t vi)" in
> >> Â Â Â file-file)
> >> Â Â Â Â Â # both vim and vi are present
> >> Â Â Â Â Â alias vi=vim
> >> Â Â Â Â Â alias view="vim -R"
> >> Â Â Â Â Â ;;
> >> Â Â Â -file)
> >> Â Â Â Â Â # only vim-minimal is installed, expose it as 'vim' too
> >> Â Â Â Â Â alias vim=vi
> >> Â Â Â Â Â ;;
> >> Â esac
> >> fi
> >>
> >Looks good, although it doesn't touch the problem mistaking Vi and Vim
> >as I sa
Re: Fedora 34 Change: DNF/RPM Copy on Write enablement for all variants (System-Wide Change)
Dne 21. 12. 20 v 17:39 Neal Gompa napsal(a): > On Mon, Dec 21, 2020 at 11:29 AM Ben Cotton wrote: >> # Decompression happens inline with download. This has a positive >> effect on resource usage: downloads are typically limited by >> bandwidth. Decompression and writing the full data into a single file >> per rpm is essentially free. Additionally: if there is more than one >> download at a time, a multi-CPU system can be better utilized. All >> compression types supported in RPM work because this uses the rpm I/O >> functions. >> # RPMs are cached on local storage between downloading and >> installation time as normal. This allows DNF to defer actual RPM >> installation to when all the RPM are available. This is unchanged. >> # The file format for RPMs is different with Copy on Write. The >> headers are identical, but the payload is different. There is also a >> footer. >> ## Files are converted (“transcoded”) locally during download using >> /usr/bin/rpm2extents (part of rpm codebase). The format I cannot find it anywhere in rpm codebase. >> # Disk space requirements are expected to be marginally higher than >> before: all new packages or updates will consume their installed size >> before installation instead of about half their size (regular rpms >> with payloads still cost space). The size is alreay an issue (for me) on small cloud images. But I do not use BTRFS there. So at the end I do not care :) >> >> Ballpark performance difference is about half the duration for file >> download+install time. A lot of rpms are very small, so it’s difficult >> to see/measure. Larger RPMs give much clearer signal. Hmm, I, personally, see much better perfomance (and storage) improvements in enabling %_minimize_writes however there is still https://bugzilla.redhat.com/show_bug.cgi?id=1872141 to be resolved before this got enabled by default. -- Miroslav Suchy, RHCA Red Hat, Associate Manager ABRT/Copr, #brno, #fedora-buildsys ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Fedora GNOME Shell rendering problem
On Tue, Dec 22, 2020 at 5:31 AM Michael Schwendt wrote: > > On Mon, 21 Dec 2020 08:09:50 -0500, Owen Taylor wrote: > > > Most likely the GPU driver. This is a symptom of a corrupted Xft glyph > > cache inside the Xwayland X server. > > > > (It's not impossible that the glyph was corrupted before upload by > > some other component, but that's much less likely - especially if it > > seems to be hardware dependent.) > > It's been observed on Nouveau driver based installations / with no Nvidia > related packages from RPM Fusion as to test whether default installations > of Fedora Workstation would work acceptably out of the box. I'd suggest filing an issue against: https://gitlab.freedesktop.org/xorg/xserver Even though the fix is more likely to be in Mesa - because it's not going to be possible to investigate this just in Mesa alone - the first step would be for a developer to figure out a working reproducer with the X server. Make sure, however, that your bug report includes the specific kernel and mesa versions, and the details of the video hardware (lspci -v) Owen ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Fedora 34 Change: Enable systemd-oomd by default for all variants (System-Wide Change)
On Tue, Dec 22, 2020 at 10:45 am, Vít Ondruch wrote: And I wonder what will be the behavior for applications, which I start from my terminal? The most typical example for me is running GVim from gnome-terminal. Each gnome-terminal tab runs in its own cgroup: │ │ │ ├─app-org.gnome.Terminal.slice │ │ │ │ ├─vte-spawn-1d1d5519-71d2-4035-929a-8a9ae5bc3822.scope │ │ │ │ │ ├─7848 bash │ │ │ │ │ └─7889 less /etc/hosts │ │ │ │ ├─vte-spawn-03fe4cc9-0400-4723-ac9b-e929b850ca02.scope │ │ │ │ │ ├─7892 bash │ │ │ │ │ ├─7927 systemd-cgls │ │ │ │ │ └─7928 less │ │ │ │ └─gnome-terminal-server.service │ │ │ │ └─7843 /usr/libexec/gnome-terminal-server Firefox does this too. WebKit doesn't, but it won't be hard to fix. Not sure about Chrome. Point is, apps have all the tools they need to use cgroups to ensure out-of-control subprocesses don't cause the main process to be killed, and our important default apps (Firefox and gnome-terminal) actually do this. Michael ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Disabling Python Dependency Generator Challenges
On Tue, Dec 22, 2020 at 10:48:22AM +0100, Miro Hrončok wrote: [..] > As a side note, I wonder why do you need to resort to disabling the > automatic requires generator? If the dependency on pikepdf is bogus, work > with upstream to remove it. In the mean time, sed/patch it out form upstream > metadata in %prep. [..] img2pdf is a bit special. On the one hand it prefers pikepdf for writing PDF files, but on the other hand it also support several PDF engines (including an internal one). Thus, pikedf really is optional. Since EPEL nor RHEL8 provide pikepdf it makes sense to don't depend on it then, when building for EPEL. Ok, I'll try to work-around this by either disabling the generator like you suggested or by patching the setup.py INSTALL_REQUIRES. Best regards Georg -- 'Read this manual carefully as bad input values may cause libcurl to behave badly!' curl_easy_setopt(3) ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: What is the most time consuming task for you as packager?
On Tue, Dec 22, 2020 at 11:16 AM Miro Hrončok wrote: > > On 21. 12. 20 19:36, Kevin Fenzi wrote: > > On Thu, Dec 17, 2020 at 09:21:15PM +0100, Fabio Valentini wrote: > >> As Miro mentioned, I've also developed scripts to handle this "does > >> this update break anything" for the Stewardship / Java SIG, because - > >> at least at first - we didn't have big enough egos / enough confidence > >> to just push updates to rawhide without testing excessively them > >> first: > >> https://github.com/fedora-stewardship/fedora-stewardship.github.io/blob/master/scripts/review_pr.py > >> > >> This first builds (one or more) packages from src.fpo dist-git forks > >> that were prepared for PRs in COPR, recursively or non-recursively > >> queries dependent packages for all of them, and rebuilds them in COPR. > >> Assuming that there's a copr-cli command for querying build successes, > >> they could be compared with the latest status of those packages in > >> koschei, and have it print new build failures. Right now, I compare > >> the results manually. > >> > >> Would something like this fit your definition of "does-it-blend" script? > > > > What format is '--from-git' in? Say I have a fork with a branch I want > > to test, what do I pass it? > > --from-git is a regex of package names that are built from dist git instead of > from latest known SRPM. > > AFAIK The script only supports "the one package" (that is being tested) to be > built from a custom branch, whoch is the purpose of the script: > > $ python scripts/review_pr.py foobar-2.0 kevin:foobar:branch-2.0 > > But you can later built another package in there (with or without depndents) > in > the same copr: > > $ python scripts/review_pr.py foobar-2.0 kevin:bazbaz:fix_deps [-nx'.*'] > > > This is indeed the sort of thing I was thinking of (I think). You should actually be able to build an arbitrary number of packages before any of their dependencies are rebuilt - just add more FORKUSERNAME:PKGNAME:BRANCHNAME values. The CLI script explicitly accepts at-least-one-or-maybe-more (nargs="+") such values. Side note: I actually did not want to let users specify a PR URL, since you actually want to test your changes before submitting a PR, so you can specify the username/package/branch directly without having to create a PR first. But I think I could add that as an option to the CLI. Fabio ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Fedora GNOME Shell rendering problem
Hi, On Tue, Dec 22, 2020 at 4:31 PM Owen Taylor wrote: > On Tue, Dec 22, 2020 at 5:31 AM Michael Schwendt > wrote: > > > > On Mon, 21 Dec 2020 08:09:50 -0500, Owen Taylor wrote: > > > > > Most likely the GPU driver. This is a symptom of a corrupted Xft glyph > > > cache inside the Xwayland X server. > > > > > > (It's not impossible that the glyph was corrupted before upload by > > > some other component, but that's much less likely - especially if it > > > seems to be hardware dependent.) > > > > It's been observed on Nouveau driver based installations / with no Nvidia > > related packages from RPM Fusion as to test whether default installations > > of Fedora Workstation would work acceptably out of the box. > > I'd suggest filing an issue against: > > https://gitlab.freedesktop.org/xorg/xserver > > Even though the fix is more likely to be in Mesa - because it's not > going to be possible to investigate this just in Mesa alone - the > first step would be for a developer to figure out a working reproducer > with the X server. Make sure, however, that your bug report includes > the specific kernel and mesa versions, and the details of the video > hardware (lspci -v) > Can you check and look for GL_OUT_OF_MEMORY messages in the journalctl logs for gnome-shell? (Xwayland being spawned by gnome-shell, the messages from Xwayland will be marked as gnome-shell in the logs) Xwayland uses glamor by default, and I can think of are a number of known nouveau issues which can eventually lead to GL_OUT_OF_MEMORY errors in glamor, with various effects, so it could possibly be the root cause of the issue. The same occurs with the modesettings driver on the same hardware, so trying to reproduce with Xorg + modesetting + glamor could be a test as well. You could also try disabling glamor support in Xwayland (by setting the environment variable XWAYLAND_NO_GLAMOR=1 typically in a script in /etc/profile.d/) for testing purposes, and see if that helps (rendering of all X11 applications will be slower, of course). HTH, Cheers Olivier ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Fedora 34 Change: Enable systemd-oomd by default for all variants (System-Wide Change)
Ben Cotton writes: > For swap based actions, systemd-oomd will monitor the system-wide swap > space and act when available swap falls below the configured > threshold, starting with the cgroups with the highest swap usage to > the least. Keeping some amount of swap (if enabled) available will > prevent the kernel OOM killer from killing processes unpredictably and > spending an unbounded amount of time afterwards. -1 from me. If the kernel behavior is a problem, fix it - don't kludge around it in userspace. Thanks, --Robbie signature.asc Description: PGP signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Fedora 34 Change: Enable systemd-oomd by default for all variants (System-Wide Change)
Robbie Harwood writes: > Ben Cotton writes: > >> For swap based actions, systemd-oomd will monitor the system-wide swap >> space and act when available swap falls below the configured >> threshold, starting with the cgroups with the highest swap usage to >> the least. Keeping some amount of swap (if enabled) available will >> prevent the kernel OOM killer from killing processes unpredictably and >> spending an unbounded amount of time afterwards. > > -1 from me. If the kernel behavior is a problem, fix it - don't kludge > around it in userspace. That is unlikely to happen. As far as I know, the kernel devs see the kernel oom killer as a kernel self protection measure and want it to fire as the last resort (and they are quite hesitant to touch userspace). That's the reason why there has been recently quite some development around various userspace oom killers, because it becomes more and more apparent, that the kernel is not going to fix this problem. Cheers, Dan signature.asc Description: PGP signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Pagure / src.fp.o page comments go "stale"
On Mon, Dec 21, 2020 at 12:37 PM Petr Pisar wrote: > > On Sun, Dec 20, 2020 at 08:49:13AM -0500, Neal Gompa wrote: > > On Sun, Dec 20, 2020 at 8:47 AM Richard Shaw wrote: > > > > > > I've noticed for a while now that if I leave one of the above pages open > > > for an extended period of time that I can no longer submit comments. I > > > just get the cursor circle of death and it just sits there indefinitely. > > > > > > I've resorted to copying my comments, refreshing the page, and then > > > submitting again which always works, but the question is: > > > > > > Why is this necessary to begin with? > > > > There are only two cases where this happens: > > > > 1. You are expiring your login sessions aggressively locally (purging > > cookies, etc.) > > 2. The browser is disconnecting and killing the memory processes > > aggressively > > > > Neither of which are from Pagure's side. > > But the failed AJAX request should return an error (after a timeout) and a > server-provided JavaScript client should handle the error gracefully. Instead > of falling into a does-not-halt state. I can confirm that this happens for me too lately - comments on pages for PRs and Issues get "stuck" - making newly submitted comments not show up and new comments are not getting committed, and the only way to fix this is to copy the comment text, reload the page, paste the comment again, and hit the submit button again. Fabio ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Fedora 34 Change: Use ibus-m17n as the default IME for Sinhala (System-Wide Change proposal)
https://fedoraproject.org/wiki/Changes/ibus-m17n_as_default_Sinhala_IME == Summary == The current default input method for Sinhala is ibus-sayura. This should change to the ibus-m17n input method “m17n:si:sayura - sayura (m17n)” == Owner == * Name: [[User:Mfabian| Mike Fabian]] * Email: == Detailed Description == The current Fedora default input method ibus-sayura seems to be not actively maintained. Fixing bugs like this one https://bugzilla.redhat.com/show_bug.cgi?id=1724759 is therefore difficult. The ibus-m17n input method si-sayura.mim does exactly the same (I developed this one to be an exact replacement for ibus-sayura). As ibus-sayura offers no additional benefit, it is probably better to use ibus-m17n with si-sayura as the default input method for Sinhala. ibus-m17n has to be maintained anyway. Therefore, this saves the effort of fixing the unmaintained ibus-sayura. == Benefit to Fedora == Save maintenance cost in maintaining ibus-sayura. si-sayura from m17n-db can be used both with ibus-m17n and with ibus-typing-booster, so actually it is more useful than ibus-sayura. == Scope == * Proposal owners: ** update default IME in comps @input methods ** update langpacks-vi to use ibus-m17n and m17n-db ** the langtable package has data about default input methods. Change this data. * Other developers: gnome-desktop3 for default si_LK input method * Policies and guidelines: N/A (not a System Wide Change) * Trademark approval: N/A (not needed for this Change) * Alignment with Objectives: == Upgrade/compatibility impact == The package installed by default will change from ibus-sayura to the packages ibus-m17n and m17n-db for an installation in Sinhala. == How To Test == Install Fedora in Sinhala and check that the default input method is si-sayura with ibus-m17n. == User Experience == * There should be very little difference in typing Vietnamese as ibus-sayura and ibus-m17n with si-sayura.mim behave the same. * The setup tool looks a little different. * Package sizes and dependent packages are different. * Memory usage is different. == Dependencies == ibus-m17n and m17n-db * comps has to be updated == Contingency Plan == Revert changes back to ibus-sayura * Contingency mechanism: Revert comps and gnome-desktop3 * Contingency deadline: Beta release * Blocks release? No * Blocks product? None == Documentation == https://github.com/ibus/ibus-m17n -- Ben Cotton He / Him / His Senior Program Manager, Fedora & CentOS Stream Red Hat TZ=America/Indiana/Indianapolis ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Fedora 34 Change: Enable systemd-oomd by default for all variants (System-Wide Change)
Dan Čermák writes: > Robbie Harwood writes: > >> Ben Cotton writes: >> >>> For swap based actions, systemd-oomd will monitor the system-wide swap >>> space and act when available swap falls below the configured >>> threshold, starting with the cgroups with the highest swap usage to >>> the least. Keeping some amount of swap (if enabled) available will >>> prevent the kernel OOM killer from killing processes unpredictably and >>> spending an unbounded amount of time afterwards. >> >> -1 from me. If the kernel behavior is a problem, fix it - don't kludge >> around it in userspace. > > That is unlikely to happen. As far as I know, the kernel devs see the > kernel oom killer as a kernel self protection measure and want it to > fire as the last resort (and they are quite hesitant to touch > userspace). I believe you are assuming the consequent when you suggest that kernel developers should be somehow fixing this in userspace. To back up: the described problem is the manifestation of an interaction between swap and the OOM condition. The OOM killer is a popularly-understood piece of what goes on in the system during OOM, but it's not like the rest of the kernel can be ignored. (I would argue that part of the reason it's well understood is their insistence that it remain simple, but that's getting off into the weeds.) So, several control points here: - OOM killer behavior. I think we're in agreement that this isn't the thing that needs changed. - Enabling swap. Swap is really slow (by virtue of not being RAM...) and we don't seem willing to acknowledge that. If we want the system to be snappy and responsive... we shouldn't be swapping. - Swap aggressiveness. Suggested by above, people want swap anyway. (Sometimes it's for hibernation (not supported, but that stops no one), sometimes it's for... historical reasons? Underprovisioning?) This could be tuned to the use cases we actually want. - Education. Get people to a point where admins don't deploy swap on systems that aren't going to hibernate. I'll readily admit this one might be hardest. And even possibly the (conceptually) simplest solution of all: - Swap usage monitoring as described for oomd... but in the kernel. This saves you on all the overhead of running in userspace, if nothing else. But what really bothers me here is that, to my knowledge, no one has tried to actually make any of these happen in the kernel. There's a vague perception of what "the kernel devs" want, as if they're some other, but... has anyone asked? If so, we should be able to quote what the response was, and a good design proposal should include it as an explanation of why that route wasn't taken. Thanks, --Robbie signature.asc Description: PGP signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Fedora 34 Change: Enable systemd-oomd by default for all variants (System-Wide Change)
> On Mon, Dec 21, 2020 at 1:51 pm, Aleksei Bavshin wrote: > > Hm good point. I think only GNOME and KDE create systemd scopes when > launching apps; systemd-oomd is not going to work well in other > desktops. Probably other desktop spins should opt-out of this change > for now. > > Michael Does this change apply to *all* Fedora releases? Overall I like the change for desktop use, but I'm not sure it currently is a good fit for non-Workstation/KDE spins of Fedora. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Fedora 34 Change: Enable systemd-oomd by default for all variants (System-Wide Change)
On Tue, Dec 22, 2020 at 1:41 pm, Robbie Harwood wrote: - OOM killer behavior. I think we're in agreement that this isn't the thing that needs changed. Let's back up. The choice is between earlyoom (status quo) or systemd-oomd (future). We're not going to get rid of our userspace OOM killer, because we've found a userspace killer is necessary to avoid locking up when under memory pressure. That ship sailed when we decided to ship earlyoom. (Well, in theory, we *could* change our minds about that... but we should not, because earlyoom has significantly improved our responsiveness under low memory conditions.) earlyoom was always recognized as a stopgap measure until systemd was ready to take over. - Enabling swap. Swap is really slow (by virtue of not being RAM...) and we don't seem willing to acknowledge that. If we want the system to be snappy and responsive... we shouldn't be swapping. - Swap aggressiveness. Suggested by above, people want swap anyway. (Sometimes it's for hibernation (not supported, but that stops no one), sometimes it's for... historical reasons? Underprovisioning?) This could be tuned to the use cases we actually want. - Education. Get people to a point where admins don't deploy swap on systems that aren't going to hibernate. I'll readily admit this one might be hardest. And even possibly the (conceptually) simplest solution of all: - Swap usage monitoring as described for oomd... but in the kernel. This saves you on all the overhead of running in userspace, if nothing else. I don't think we need to be discussing swap at all. Any amount of swap means you won't have good performance under memory pressure. We don't create a disk-based swap partition by default anymore, and swap on zram is relatively fast, so there's no reason to consider swap as part of this discussion. We are discussing defaults, after all. If you're going to use a non-default configuration, that's fine of course, but it shouldn't affect our decisions on how Fedora should work by default. Michael ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Fedora 34 Change: Enable systemd-oomd by default for all variants (System-Wide Change)
On Tue, Dec 22, 2020 at 6:55 pm, Tom Seewald wrote: Overall I like the change for desktop use, but I'm not sure it currently is a good fit for non-Workstation/KDE spins of Fedora. If your desktop doesn't segregate apps and services into cgroups, systemd-oomd will kill the entire desktop whenever anything uses too much memory, because the desktop is going to be running in the same cgroup as the apps that it launches. So I think desktop spins (other than KDE) ought to opt out of this. It should be good for all Fedora editions, though (including Workstation, Server, Atomic, CoreOS), and also for KDE spin. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Fedora 34 Change: Enable systemd-oomd by default for all variants (System-Wide Change)
On Tue, Dec 22, 2020 at 2:03 PM Michael Catanzaro wrote: > > On Tue, Dec 22, 2020 at 6:55 pm, Tom Seewald wrote: > > Overall I like the change for desktop use, but I'm not sure it > > currently is a good fit for non-Workstation/KDE spins of Fedora. > > If your desktop doesn't segregate apps and services into cgroups, > systemd-oomd will kill the entire desktop whenever anything uses too > much memory, because the desktop is going to be running in the same > cgroup as the apps that it launches. So I think desktop spins (other > than KDE) ought to opt out of this. It should be good for all Fedora > editions, though (including Workstation, Server, Atomic, CoreOS), and > also for KDE spin. > To be clear, the "opt-out", as it were, is just to not include systemd-oomd in the comps groups for those variants. -- 真実はいつも一つ！/ Always, there's only one truth! ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Fedora 34 Change: DNF/RPM Copy on Write enablement for all variants (System-Wide Change)
> I cannot find it anywhere in rpm codebase. The current status section of the proposal describes this as pending two PRs, and in the dependencies list, they're enumerated. Most of the code is in https://github.com/malmond77/rpm/tree/cow and enabled through work in https://github.com/malmond77/librepo/tree/transcode_cow > Hmm, I, personally, see much better perfomance (and storage) improvements in > enabling %_minimize_writes > however there is still https://bugzilla.redhat.com/show_bug.cgi?id=1872141 to > be resolved before this got enabled by default. I'm curious about this so I'll look at it, but at first glance it seems tangential to this proposal. Thanks, Matthew. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Fedora 34 Change: Enable systemd-oomd by default for all variants (System-Wide Change)
> If your desktop doesn't segregate apps and services into cgroups, > systemd-oomd will kill the entire desktop whenever anything uses too > much memory, because the desktop is going to be running in the same > cgroup as the apps that it launches. So I think desktop spins (other > than KDE) ought to opt out of this. It should be good for all Fedora > editions, though (including Workstation, Server, Atomic, CoreOS), and > also for KDE spin. How will this work on headless systems like Fedora Server, Atomic, and CoreOS? Will it be expected that users manually create their own cgroups? ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Fedora 34 Change: Enable systemd-oomd by default for all variants (System-Wide Change)
On Tue, Dec 22, 2020 at 11:42 AM Robbie Harwood wrote: > > > I believe you are assuming the consequent when you suggest that kernel > developers should be somehow fixing this in userspace. > > To back up: the described problem is the manifestation of an interaction > between swap and the OOM condition. The OOM killer is a > popularly-understood piece of what goes on in the system during OOM, but > it's not like the rest of the kernel can be ignored. (I would argue > that part of the reason it's well understood is their insistence that it > remain simple, but that's getting off into the weeds.) No the problem happens any time a resource becomes constrained: cpu, memory, io. It's not exclusively a swap problem. When swap pressure is part of the problem, it depends on how swap is being used. Heavy IO page out is a good thing. Heavy IO page-in and page-out of the same pages is a bad thing. > > So, several control points here: > > - OOM killer behavior. I think we're in agreement that this isn't the > thing that needs changed. If you mean the kernel oomkiller, yeah probably. That's generally considered to be working correctly. It keeps the kernel functioning, with forward progress being made without any respect whatsoever to user space priorities like system responsiveness. > - Enabling swap. Swap is really slow (by virtue of not being RAM...) > and we don't seem willing to acknowledge that. If we want the system > to be snappy and responsive... we shouldn't be swapping. This is not entirely correct. The chosen workload might be excessive compared to the allocated resources. That does happen, I see it from time to time, but it's not that common because it results in a lot of pain for the user. So they stop doing it. This is an underprovisioned system. If you aren't swapping at all, that means you have allocated more resources than the workload requires. You've over provisioned. This is apparently quite common in the Kubernetes workflow, because Kubernetes doesn't work properly with swap, somehow by design. So their view is, don't create a swap device, just overprovision. Swap is for evicting anonymous pages, pages that aren't backed by any kind of file. If inactive anonymous pages can't be swapped, they have to stay in memory. And when memory is under pressure, the kernel has no choice but to resort to reclaim, i.e. evict pages that are backed by files. This will end up looking a lot like swap thrashing. Another factor is there have been recent improvements in the swap code to make dirty page eviction much better and avoid swap thrashing. You'll need a 5.10 kernel for the most recent work on this. > > - Swap aggressiveness. Suggested by above, people want swap anyway. > (Sometimes it's for hibernation (not supported, but that stops no > one), sometimes it's for... historical reasons? Underprovisioning?) > This could be tuned to the use cases we actually want. The idea of proper resource control is to use swap more effectively, to reduce the heavy swap thrashing. It's not a problem to do dirty page eviction (page out). That frees memory and makes it less likely other processes will thrash. > > - Education. Get people to a point where admins don't deploy swap on > systems that aren't going to hibernate. I'll readily admit this one > might be hardest. That is bad advice. We do need swap. https://chrisdown.name/2018/01/02/in-defence-of-swap.html There's a nice tl;dr at the top and a summary at the bottom. And quite detailed explanation in the middle. > And even possibly the (conceptually) simplest solution of all: > > - Swap usage monitoring as described for oomd... but in the kernel. > This saves you on all the overhead of running in userspace, if nothing > else. This exists in the form of PSI, as well as cgroupsv2: https://www.kernel.org/doc/html/latest/admin-guide/cgroup-v2.html memory.swap.current memory.swap.events memory.swap.high memory.swap.max > But what really bothers me here is that, to my knowledge, no one has > tried to actually make any of these happen in the kernel. There's a > vague perception of what "the kernel devs" want, as if they're some > other, but... has anyone asked? If so, we should be able to quote what > the response was, and a good design proposal should include it as an > explanation of why that route wasn't taken. I'm not even sure what you're asking for. There is no such thing as a one size fits all set of policies for resource control. There are kernel-side components for this, as well as user space, to implement a policy. -- Chris Murphy ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/dev
Re: Fedora 34 Change: DNF/RPM Copy on Write enablement for all variants (System-Wide Change)
>> === New process === >> # Resolve packaging request into a list of packages and operations >> # Download and '''decompress''' packages into a '''locally optimized''' rpm >> file >> # Install and/or upgrade packages sequentially using RPM files, using >> ''reference linking''' (reflinking) to reuse data already on disk. > This sound great because free space requirements can be reduced, > specially when installing new packages. I need to re-word this: the "reuse" of data is between the locally downloaded rpm and the installed destination. I do have a plan to investigate making rpm2extents enumerate the dnf/rpm cache (if you enable it) and reflink any shared data between rpms, saving writes. Today this proposal explains that disk space requirements during updates are expected to be higher. See https://fedoraproject.org/wiki/Changes/RPMCoW#Notes item 3. > I have experimented building very small appliances using btrfs > compression on things like /usr/share. So I think this could disrupt > this because if I am correct the extends will be first downloaded to a > temporary directory without compression enabled. There is also some confusion between compressed data in the rpm and the transcoded one, and filesystem level compression. This proposal affects the former, but not the latter. I'd caution against using btrfs specific attributes to disable compression the dnf/rpm cache directory tree, because then the extents written/shared to the installed file locations will also not be compressed. (this is my interpretation of what I expect to see with FICLONERANGE ioctl etc: it'd be slower if it honored filesystem level compression because it'd need to re-write the data.) > I am happy with an option to disable this behavior. I'm unclear on which behavior you're referring to. This proposal is add support for Copy on Write in Fedora, but not make it default at this time. Thanks, Matthew. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Fedora 34 Change: DNF/RPM Copy on Write enablement for all variants (System-Wide Change)
On Tue, Dec 22, 2020 at 12:58 PM Matthew Almond via devel wrote: > > There is also some confusion between compressed data in the rpm and the > transcoded one, and filesystem level compression. This proposal affects the > former, but not the latter. I'd caution against using btrfs specific > attributes to disable compression the dnf/rpm cache directory tree, because > then the extents written/shared to the installed file locations will also not > be compressed. (this is my interpretation of what I expect to see with > FICLONERANGE ioctl etc: it'd be slower if it honored filesystem level > compression because it'd need to re-write the data.) It shouldn't need to rewrite the data. ficlonerange offset and length is based on the Btrfs logical address space, and this is uncompressed. That behind the scene it happens to be compressed is a sort of "last mile" detail, similar to where the file is actually located. Btrfs logical address for a file suggests there is exactly one copy of the file and one copy of its metadata, but via chunk tree lookup it may be that this file has two copies (raid1) or it may be located on any one of a number of devices. Yet ficlonerange still works as expected regardless of those details. -- Chris Murphy ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Fedora 34 Change: Enable systemd-oomd by default for all variants (System-Wide Change)
On Tue, Dec 22, 2020 at 7:45 pm, Tom Seewald wrote: How will this work on headless systems like Fedora Server, Atomic, and CoreOS? Will it be expected that users manually create their own cgroups? Either that, or don't use too much memory, yes. I assume SIGKILL is probably at least somewhat better than being unable to reboot your server because your terminal is no longer responsive, right? Well, I think you exposed the flaw in my argument. I say that on servers, it's OK to kill everything rather than freeze, but killing the entire desktop is pretty clearly not OK on desktops. So maybe it's not OK on servers, either. I have no strong opinion here. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Stale proven packagers
A propos of some discussion of the Solarwinds news, it occurred to me
to check how many proven packager accounts there are in FAS. There are
251, which seems like a lot. Then it occurred to me to check how many
of them are inactive, so I wrote a little script:
===
#!/usr/bin/python3
import getpass
from fedora.client.fas2 import AccountSystem
from koji import ClientSession
username = input("FAS user name: ")
password = getpass.getpass("FAS password: ")
acc = AccountSystem(username=username, password=password)
pps = acc.group_members("provenpackager")
ks = ClientSession("https://koji.fedoraproject.org/kojihub";)
for pp in pps:
user = ks.getUser(pp["username"])
if not user:
print(f"{pp['username']} NON-EXISTENT IN KOJI")
continue
uid = user["id"]
if ks.listBuilds(userID=uid, createdAfter="2019-01-01 00:00:00"):
continue
print(pp["username"])
===
Here is the list it produced:
alexl
alexlan
arg
athimm
atkac
bernie
bkabrda
bpepple
caillon
cebbert
chitlesh
cweyl
cwickert
davej
dbhole
dcbw
denis
dgregor
dsd
ecik
ensc
epienbro
fitzsim
gdk NON-EXISTENT IN KOJI
gemi
ianweller
iarnell
ilianaw
ishcherb
ivazquez
ixs
jcapik
jkeating
johnp
jpo
jreznik
jspaleta
jstanley
jsteffan
jwilson
kasal
katzj
kay
ke4qqq
kengert
kyle
kylev
laxathom
lennart
lmacken
lutter
markmc
mbarnes
mef
mjakubicek
mjg59
mmahut
mmaslano
mmcgrath
msrb
mstuchli
npmccallum
overholt
paragn
patches
pertusus
pjp
praveenp
pravins
rakesh
rkuska
rvokal
s4504kr
scop
sdake
sdz
skvidal
stahnma
steve
sundaram
thomasvs
toshio
tradej
tremble
tstclair
tuxbrewr
vakwetu
vicodan
willb
wolfy
that's 90 of the 251 who still have provenpackager privileges, but
haven't run any kind of Koji build since at least 2019-01-01 (if you
check, it turns out many of them haven't run a build since long before
then). Many of them, to my knowledge, don't work on Fedora at all any
more and haven't for years. At least one of them, to my and everyone
else's knowledge, is sadly dead and has been for some time. One account
- it's Greg Dekoenigsberg - somehow is in the FAS pp group but doesn't
exist in koji (any more?)
Perhaps we need a process for cleaning up membership of this extremely
powerful group? If the FAS password of *any one* of those user accounts
were somehow compromised (or if just one of them decided they had a
grudge against Fedora now and were going to have some fun), the results
could be...unfortunate.
--
Adam Williamson
Fedora QA
IRC: adamw | Twitter: adamw_ha
https://www.happyassassin.net
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Stale proven packagers
On Tue, Dec 22, 2020 at 2:40 PM Adam Williamson wrote: > > Perhaps we need a process for cleaning up membership of this extremely > powerful group? If the FAS password of *any one* of those user accounts > were somehow compromised (or if just one of them decided they had a > grudge against Fedora now and were going to have some fun), the results > could be...unfortunate. > I mentioned it once but got zero response... What about requiring a CLA (or something like it) annually instead of one time. This would help clean up inactive packagers as well. Thanks, Richard ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Stale proven packagers
On Tue, 22 Dec 2020 at 21:40, Adam Williamson wrote: > that's 90 of the 251 who still have provenpackager privileges, but > haven't run any kind of Koji build since at least 2019-01-01 (if you > check, it turns out many of them haven't run a build since long before > then). Many of them, to my knowledge, don't work on Fedora at all any > more and haven't for years. At least one of them, to my and everyone > else's knowledge, is sadly dead and has been for some time. One account > - it's Greg Dekoenigsberg - somehow is in the FAS pp group but doesn't > exist in koji (any more?) > > Perhaps we need a process for cleaning up membership of this extremely > powerful group? If the FAS password of *any one* of those user accounts > were somehow compromised (or if just one of them decided they had a > grudge against Fedora now and were going to have some fun), the results > could be...unfortunate. > Security implications are one thing, but it's also unfortunate that these accounts (and related packages) exist in limbo. Would it perhaps make sense to extend/improve your script, run it once every half a year and contact the packagers to check with them whether they're still interested in Fedora? Best, Andy ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Stale proven packagers
On 12/22/20 2:39 PM, Adam Williamson wrote: epienbro In this case this individual has passed away. :( His packages were reassigned, but I don't think we have a process for taking care of the rest of an individual's resources (accounts, groups, etc.). ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Stale proven packagers
On Tue, Dec 22, 2020 at 3:44 PM Adam Williamson wrote: > > Perhaps we need a process for cleaning up membership of this extremely > powerful group? Yes, please. I'll even go out on a limb and propose a process... > At a point (TBD) in each release cycle members of the provenpackager group > who have not submitted a koji build in the last six months will be contacted > via their @fedoraproject.org email address to verify that they should remain > in the provenpackager group. If they do not acknowledge within two weeks, > they will be removed from the provenpackager group. I'm not particularly tied to any of the values above, but it's a start. Arguably, it should be more than a "yes, please keep me in", but we can see how it goes for a few releases before tightening it down. I'd like to make it minimally annoying to start, but something more than we have now. I'm also open to other mechanisms other than email (and the list could also be shared to devel-announce to help make it more visible). I don't really care where in the cycle we do it. I don't think one spot is particularly better than another. I assume FESCo won't approve anything before mid-January, and it's probably good to start this sooner rather than later, so maybe around branch day (9 Feb for Fedora 34) is as good a place as any? -- Ben Cotton He / Him / His Senior Program Manager, Fedora & CentOS Stream Red Hat TZ=America/Indiana/Indianapolis ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Fedora 34 Change: i3 Spin (Self-Contained Change proposal)
https://fedoraproject.org/wiki/Changes/Fedora_i3_Spin == Summary == Create an official Fedora Spin shipping the popular i3 window manager. This Spin would be the first Fedora Spin to feature a tiling/window manager instead of a traditional desktop environment. == Owner == * Names: [[User:Nasirhm|Nasir Hussain]], [[User:Jflory7|Justin W. Flory]], [[User:X3mboy|Eduard Lucena]], [[User:Defolos|Dan Čermák]], == Detailed Description == The Fedora i3 SIG began in May 2020 with a goal of creating an official Fedora Spin featuring the i3 tiling window manager. Since then, a community of i3 enthusiasts around the Fedora community has collaborated to define what an official Fedora i3 Spin would include, how it might work, and how the Fedora community might differentiate this Spin from other ready-to-use i3 implementations already in the open source ecosystem. The SIG has outlined the following design goals to guide construction of the Spin (see [https://docs.fedoraproject.org/en-US/i3/design-goals/ i3 SIG Design Goals] for details): # Simple is better than complex. # Fast is better than features. # There should be one—and preferably only one—obvious way to do it. # Now is better than never. These Design Goals inform and guide decisions regarding the Kickstart. They are also the basis for the SIG's decisions about future changes to the i3 Spin. In summary, this Change is represents the realization of work that began in May 2020. The goal is to create an official Fedora Spin based on the i3 SIG's kickstart. == Benefit to Fedora == This Change benefits end-users who run Fedora on a desktop or laptop, particularly low-end consumer-grade hardware. An i3 Spin would provide a better initial installation experience for Fedora users installing i3 for the first time. Currently, end-users who wish to use i3 on Fedora must install another Edition or Spin of Fedora, then install the i3 window manager (and related packages) separately (a process often requiring use of an external guide or tutorial). Additionally, this "two-step" method adds unnecessary packages to the user's system, particularly if the end-user does not wish to use another desktop environment. Moreover, the i3 SIG hypothesizes an official i3 Spin will have the lightest footprint (memory and base install size) of any Fedora Edition or Spin, but testing this hypothesis requires more data. == Scope == * Proposal owners: ** '''Finalize kickstart composition'''. The i3 SIG is finalizing a list of packages for an integrated i3 desktop. ** '''Work with RelEng to build'''. The i3 SIG needs to work with Release Engineering to pick up the i3 Spin in regular composes. ** '''Test Day coordination'''. Work with the Fedora QA team to plan and run a series of Test Days to solicit early feedback. An excited group of users in our IRC/Telegram are ready to help. * Other developers: N/A (not a System Wide Change) * Release engineering: [https://pagure.io/releng/issue/9864 #9864] * Policies and guidelines: N/A (not a System Wide Change) * Trademark approval: [https://pagure.io/Fedora-Council/tickets/issue/343#comment-707009 #343] == Upgrade/compatibility impact == Since the Fedora i3 Spin is a Spin, it assumes new installations only. There is no upgrade/compatibility impact from the Spin. Eventually, the i3 SIG will also create a package group (composition) for `i3` and `i3-extended`. Fedora users can more easily switch from another desktop environment by installing the package group. == How To Test == 1. Boot the Fedora i3 Spin ISO image either on bare-metal or in a virtual machine (V.M.). 2. Confirm successful boot into a configured i3 environment with basic packages available. 3. Launch Anaconda installer. The Anaconda installer can be launched either from a terminal or via the application launcher `dmenu`. 4. Confirm no major issues with windows and display. The installed system uses `lightdm` as the login manager and comes preinstalled with i3 as the default desktop environment with default applications present for most uses cases. == User Experience == New Fedora users can install i3 from https://spins.fedoraproject.org instead of installing another desktop, and then manually installing i3 after the initial install. This reduces the number of steps needed to start using i3. Additionally, the i3 Spin intends to be a ready-to-use, integrated i3 configuration. Often a new i3 user must find or set up other system utilities for things like networking, profile management, and other common desktop functions. The Fedora i3 Spin offers a ready-to-go environment that aims to offer an integrated, lightweight environment without pulling in larger dependency stacks from other desktops. == Dependencies == See `%packages` [https://pagure.io/i3-sig/Fedora-i3-Spin/blob/master/f/fedora-i3-common.ks#_13 in fedora-i3-common.ks]. == Contingency Plan == * Contingency mechanism: If a blocker bug comes up that breaks composes of the i3 Spin in time for Fedor
Re: Fedora 34 Change: Enable systemd-oomd by default for all variants (System-Wide Change)
On Tue, Dec 22, 2020 at 12:45 PM Tom Seewald wrote: > > > If your desktop doesn't segregate apps and services into cgroups, > > systemd-oomd will kill the entire desktop whenever anything uses too > > much memory, because the desktop is going to be running in the same > > cgroup as the apps that it launches. So I think desktop spins (other > > than KDE) ought to opt out of this. It should be good for all Fedora > > editions, though (including Workstation, Server, Atomic, CoreOS), and > > also for KDE spin. > > How will this work on headless systems like Fedora Server, Atomic, and > CoreOS? Will it be expected that users manually create their own cgroups? This is intended to be a generic approach to user space oom management, but it does tie into resource control too. And the resource control organization of what processes are considered critical are different between a desktop and a server. The idea of "user wants to take control or see what's going on" is a generally important goal for all of this work, regardless of the Fedora edition or spin. On the desktop, this is mainly GUI responsiveness. On Server this is probably logging, the entire network stack, and sshd - at a minimum. So those critical components. Organizing such services so that they get the minimum resources they require, no matter what resource hog happens to come along, is something that'd work out of the box. Right now the program that has the highest "badness" score gets killed off. And the badness score doesn't take its relative hit to PSI into account. That is, the program that's actually causing the worse pressure may not be the one killed off today. And that's because badness score is pretty simplistic. All things being equal, the one with the highest badness is the most recently launched program. That may not be how you want it scored even by default, you'd probably want to kill the one that's contributing the most inefficiency overall due to its behavior with respect to memory, io, and cpu consumption. I posted this to the server list the other day, but it gives a general overview of how oomd2 works in server user cases and explains a lot of the basic concepts which I think are easier to grasp for the server use case than the more complex desktop case. https://www.youtube.com/watch?v=30i7SamZxRU -- Chris Murphy ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Stale proven packagers
On Tue, Dec 22, 2020 at 12:39:56PM -0800, Adam Williamson wrote: > A propos of some discussion of the Solarwinds news, it occurred to me > to check how many proven packager accounts there are in FAS. There are > 251, which seems like a lot. Then it occurred to me to check how many > of them are inactive, so I wrote a little script: ...snip... > > that's 90 of the 251 who still have provenpackager privileges, but > haven't run any kind of Koji build since at least 2019-01-01 (if you > check, it turns out many of them haven't run a build since long before > then). Many of them, to my knowledge, don't work on Fedora at all any > more and haven't for years. At least one of them, to my and everyone > else's knowledge, is sadly dead and has been for some time. One account > - it's Greg Dekoenigsberg - somehow is in the FAS pp group but doesn't > exist in koji (any more?) Do note that some of these people have accounts and group memebership, but their accounts in fas are disabled/inactive. > Perhaps we need a process for cleaning up membership of this extremely > powerful group? If the FAS password of *any one* of those user accounts > were somehow compromised (or if just one of them decided they had a > grudge against Fedora now and were going to have some fun), the results > could be...unfortunate. Oh look, flashback 13 years: https://fedoraproject.org/wiki/User:JesseKeating/AutomatedMIAProposal?rd=JesseKeating/AutomatedMIAProposal Anyhow, I was in favor of something then, but it got shouted down, and I am still in favor now of some kind of checkin process. I think it should be light weight tho... always being bothered is bad. On the other hand it's hard to know how to notify people. If you send email once a week for 4 weeks and get no answer does that mean they are missing? Or that your email is going to the spam folder? Or that they are on a long vacation not checking email? It's hard to balance. kevin signature.asc Description: PGP signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Stale proven packagers
On Tue, 2020-12-22 at 13:23 -0800, Kevin Fenzi wrote: > > > Perhaps we need a process for cleaning up membership of this extremely > > powerful group? If the FAS password of *any one* of those user accounts > > were somehow compromised (or if just one of them decided they had a > > grudge against Fedora now and were going to have some fun), the results > > could be...unfortunate. > > Oh look, flashback 13 years: > > https://fedoraproject.org/wiki/User:JesseKeating/AutomatedMIAProposal?rd=JesseKeating/AutomatedMIAProposal > > Anyhow, I was in favor of something then, but it got shouted down, and I > am still in favor now of some kind of checkin process. I think it should > be light weight tho... always being bothered is bad. On the other hand > it's hard to know how to notify people. If you send email once a week > for 4 weeks and get no answer does that mean they are missing? Or that > your email is going to the spam folder? Or that they are on a long > vacation not checking email? It's hard to balance. So that proposal was just for all packagers. I think it should at least be reasonable to set a relatively high bar for being a provenpackager. Proven packagers really should be people who are deeply involved in Fedora work on a daily basis, I think, and so should be able to respond to a regular check-in process like this or the one bcotton proposed. And the result would only be that they'd lose provenpackager privileges, which could quite easily be restored if it turned out they'd just gone on a yak farming retreat for a bit or something. -- Adam Williamson Fedora QA IRC: adamw | Twitter: adamw_ha https://www.happyassassin.net ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Fedora 34 Change: DNF/RPM Copy on Write enablement for all variants (System-Wide Change)
> On Mon, Dec 21, 2020, at 1:07 PM, Neal Gompa wrote: > > Yes it does. It avoids writing the compressed data and then copying it back > out > uncompressed, which is the same amount of savings as the reflink approach. > > (It's also equally incompatible with deltarpm) > > > No - static deltas exist, plus layered RPMs work on the wire the same. But > this isn't > really relevant here. > > > Adding a hardlink indeed requires updating inodes proportional to the number > of files, but > that's more an implementation of the transactional update approach, not of the > "download and unpack in parallel" part which is more what we're discussing > here. (Though they are entangled a bit) > > Anyways, I'd still stand by my summary that the much lower tech "files in > temporary directory that get rename()d" approach would be all of *more* > efficient on > disk, simpler to implement and much less disruptive than an RPM format > change. (The main > cost would be a new temporary directory path that would need cleanup as part > of e.g. `yum > clean` etc.) I'm replying to a bunch of topics in the same thread (via the web ui because I wasn't subscribed to the mailing list until today, yikes) On editions: I wrote fedora-workstation because that's the same one that has btrfs as root by default Zero byte files: I think reflinking is specifically fine here because reflinking is about contents, not inodes. A zero byte reflink should be a no-op (on the filesystem level, but I should check, if it's not, I can special case it easily enough). The process of installing files based on reflinks involves actually opening new files, then reflinking content. On small files and alignment/waste: I believe most mutable filesystems do "waste some space". I call it out here because it's explicitly in the file format, the same as in .tar (without compression) and it's because FICLONERANGE and the filesystems demand it. I account for it as (number of files) x (native block size) / 2 - i.e. assume 50% usage of the tail of every file. The block size of ppc64 is unfortunate, but I expect the same level of waste happens whether you're using reflinking or not. Talking about the topic more broadly: The hardlinking approach in rpm-ostree depends on either a completely read-only system, or the use of a layered filesystem like overlayfs. I think it's a completely valid approach, and to my understanding, is the technology that underpins Fedora CoreOS and Project Atomic. These are different distro builds and have specific use cases in mind. As I understand it, they also have very different management policies: they are intended to be managed in a specific way, and that updates seem to require a reboot. My hope for CoW for RPM is to bring a similar set of capabilities and benefits to Fedora, and eventually CentOS, RHEL without requiring any changes to how the system works or is managed. The new requirements are fairly simple: one filesystem for the rootfs and dnf cache, and that this filesystems supports reflinking. Today data deduplication is within a given rpm. Looking forwards, I would like to extend the rpm2extents processor to read and re-use other blocks from the dnf/rpm cache and then we get full system level de-duplication. I am really grateful for all this feedback, hopefully what I write makes sense - Matthew. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Fedora 34 Change: DNF/RPM Copy on Write enablement for all variants (System-Wide Change)
> I currently download once and upgrade three different systems by > rsync-ing the cache. > > Do I understand that this will no longer be supported or work? That's an interesting question. Is sharing the cache directory from a single host intended to be shared like this? I am guessing no, but it may still be common. It should still work, with two caveats: 1. The files in the cache will be bigger, so a simple rsync will involve more I/O, and the destination filesystem will also need more space and I/O time. 2. The systems must be the same endianness (The transcoded format doesn't bother with network order, because it's not intended to be shared) 3. The page size must be the same for reflinking to work: This is actually worked out when the filesystem is created, and defaults to the system page size, and if not the same as the current page size, the filesystem isn't even guaranteed to mount (see --sectorsize option in mkfs.btrfs man page). In reality you're quite unlikely to share packages unless the architecture were the same, which would steer both endianness and page size to the same value. That said, I'm aware that aarch64 can be flexible in both ways. I'm covering my bases with my statement: I have thought about it, and don't think I'm in any position to make promises. For this proposal: we're talking about shipping the code that would allow this to be turned on. We're not talking about enabling it by default. We can't until we have good answers to questions like this. Thanks, Matthew. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Stale proven packagers
On Tue, Dec 22, 2020 at 01:39:26PM -0800, Adam Williamson wrote: > > So that proposal was just for all packagers. I think it should at least > be reasonable to set a relatively high bar for being a provenpackager. That predates the existance of the provenpackager group, so yeah. ;) > Proven packagers really should be people who are deeply involved in > Fedora work on a daily basis, I think, and so should be able to respond > to a regular check-in process like this or the one bcotton proposed. > And the result would only be that they'd lose provenpackager > privileges, which could quite easily be restored if it turned out > they'd just gone on a yak farming retreat for a bit or something. Perhaps it could just be 'hey, go do a scratch build and you will drop off the list to be dropped'. Or possibly related to this, we could send everyone a email on their fas birthday, asking them to look at what groups they are involved with and adjust (a yearly bit of introspection we could all probibly do with). kevin signature.asc Description: PGP signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Should we retire ardour5 in rawhide?
On 12/22/20 1:55 AM, Guido Aulisi wrote: Hi, ardour5 fails to build in rawhide and it has been obsoleted by ardour6. Should we retire it in rawhide? Nils, if you can give me commit access to ardour6 I can help build the new version as they are released. My FAS account: tartina Thanks Ciao Guido Yes, Guido, I completely agree that ardour5 should be retired in rawhide for the reasons you mentioned. -- Erich Eickmeyer Maintainer Fedora Jam ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Fedora 34 Change: DNF/RPM Copy on Write enablement for all variants (System-Wide Change)
On Mon, Dec 21, 2020 at 07:14:08PM +0100, Marius Schwarz wrote: > Am 21.12.20 um 18:53 schrieb Kevin Fenzi: > > But in general perhaps we should decide how much value drpms provide > > these days and either make sure we are making more of them, or drop > > them. > delta rpms safe so much time in form of bandwidth on the client side. Well, it's tradeoffs. They save bandwith and download time on one side, but use lots of cpu cycles and disk space on the other. It just depends on what each person wants based on their situation and hardware. Right now we are not making very many drpms at all, due to the way the compose process has changed over the years. If we keep drpms around we should really look into making more of them... as they are now, they seldom matter. kevin signature.asc Description: PGP signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Stale proven packagers
On Tue, Dec 22, 2020, 2:39 PM Adam Williamson wrote: > So that proposal was just for all packagers. I think it should at least > be reasonable to set a relatively high bar for being a provenpackager. Agreed that there's a higher bar here. I think the privilege should be revoked if you've not built anything in Koji for one year. - Ken ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Fedora 34 Change: DNF/RPM Copy on Write enablement for all variants (System-Wide Change)
On Tue, Dec 22, 2020 at 02:02:13PM -0800, Kevin Fenzi wrote: > > delta rpms safe so much time in form of bandwidth on the client side. > Well, it's tradeoffs. They save bandwith and download time on one side, > but use lots of cpu cycles and disk space on the other. It just depends > on what each person wants based on their situation and hardware. They actually use a lot of cpu cycles on _both_ sides, really. -- Matthew Miller Fedora Project Leader ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Кредит онлайн на карту под 0% от Foxmoney
Быстрый онлайн кредит на карту от популярного бесплатного сервиса в Украине - Foxmoney. Деньги в кредит на карту за считанные минуты без справок и залогов в день обращения. Только проверенные онлайн займы на карту https://foxmoney.com.ua/kredit-pod-0/ под 0% в Украине. Список проверенных кредитных компаний в одном месте. Отзывы, рейтинги МФО и банков страны. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Stale proven packagers
On Tue, Dec 22, 2020 at 9:23 PM Kevin Fenzi wrote: > > On Tue, Dec 22, 2020 at 12:39:56PM -0800, Adam Williamson wrote: > > A propos of some discussion of the Solarwinds news, it occurred to me > > to check how many proven packager accounts there are in FAS. There are > > 251, which seems like a lot. Then it occurred to me to check how many > > of them are inactive, so I wrote a little script: > > ...snip... > > > > > that's 90 of the 251 who still have provenpackager privileges, but > > haven't run any kind of Koji build since at least 2019-01-01 (if you > > check, it turns out many of them haven't run a build since long before > > then). Many of them, to my knowledge, don't work on Fedora at all any > > more and haven't for years. At least one of them, to my and everyone > > else's knowledge, is sadly dead and has been for some time. One account > > - it's Greg Dekoenigsberg - somehow is in the FAS pp group but doesn't > > exist in koji (any more?) > > Do note that some of these people have accounts and group memebership, > but their accounts in fas are disabled/inactive. I think what ever process is run at the point their account is disabled should revoke all privileges, that's a fairly standard IT security procedure. > > Perhaps we need a process for cleaning up membership of this extremely > > powerful group? If the FAS password of *any one* of those user accounts > > were somehow compromised (or if just one of them decided they had a > > grudge against Fedora now and were going to have some fun), the results > > could be...unfortunate. > > Oh look, flashback 13 years: > > https://fedoraproject.org/wiki/User:JesseKeating/AutomatedMIAProposal?rd=JesseKeating/AutomatedMIAProposal > > Anyhow, I was in favor of something then, but it got shouted down, and I > am still in favor now of some kind of checkin process. I think it should > be light weight tho... always being bothered is bad. On the other hand > it's hard to know how to notify people. If you send email once a week > for 4 weeks and get no answer does that mean they are missing? Or that > your email is going to the spam folder? Or that they are on a long > vacation not checking email? It's hard to balance. > > kevin > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Stale proven packagers
On Tue, Dec 22, 2020 at 9:58 PM Kevin Fenzi wrote: > > On Tue, Dec 22, 2020 at 01:39:26PM -0800, Adam Williamson wrote: > > > > So that proposal was just for all packagers. I think it should at least > > be reasonable to set a relatively high bar for being a provenpackager. > > That predates the existance of the provenpackager group, so yeah. ;) > > > Proven packagers really should be people who are deeply involved in > > Fedora work on a daily basis, I think, and so should be able to respond > > to a regular check-in process like this or the one bcotton proposed. > > And the result would only be that they'd lose provenpackager > > privileges, which could quite easily be restored if it turned out > > they'd just gone on a yak farming retreat for a bit or something. > > Perhaps it could just be 'hey, go do a scratch build and you will drop > off the list to be dropped'. I personally don't think that's a high enough bar to retain proven packager, I think people should be actively involved in the project. > Or possibly related to this, we could send everyone a email on their fas > birthday, asking them to look at what groups they are involved with and > adjust (a yearly bit of introspection we could all probibly do with). That doesn't work TBH, people don't actively drop privs "just in case", we should have some real stats behind this, we're better off being active in the adjustment of things like this rather than attempting to bold the gate shut long after the horses have bolted! ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Fedora 34 Change: DNF/RPM Copy on Write enablement for all variants (System-Wide Change)
On Tuesday, December 22, 2020 4:54:34 PM EST Matthew Almond via devel wrote: > > I currently download once and upgrade three different systems by > > rsync-ing the cache. > > > > Do I understand that this will no longer be supported or work? > > That's an interesting question. Is sharing the cache directory from > a single host intended to be shared like this? I am guessing no, but > it may still be common. > > It should still work, with two caveats: > 1. The files in the cache will be bigger, so a simple rsync will > involve more I/O, and the destination filesystem will also need more > space and I/O time. > 2. The systems must be the same endianness (The transcoded format > doesn't bother with network order, because it's not intended to be > shared) > 3. The page size must be the same for reflinking to work: This is > actually worked out when the filesystem is created, and defaults to > the system page size, and if not the same as the current page size, > the filesystem isn't even guaranteed to mount (see --sectorsize > option in mkfs.btrfs man page). > > In reality you're quite unlikely to share packages unless the > architecture were the same, which would steer both endianness and > page size to the same value. That said, I'm aware that aarch64 can > be flexible in both ways. I'm covering my bases with my statement: I > have thought about it, and don't think I'm in any position to make > promises. > > For this proposal: we're talking about shipping the code that would > allow this to be turned on. We're not talking about enabling it by > default. We can't until we have good answers to questions like this. Understood. To be clear, all three systems are x86_64, identical endianness, architecture, and page size (as far as I know). Also, this isn't a big deal, really. I just wanted to reduce network bandwidth without operating a local mirror. ___ sudo rsync -a --password-file=/etc/rsync.password --delete rsync://rsync@vfr/dnf /var/cache/dnf;sudo dnf --enablerepo=updates-testing upgrade -- Garry T. Williams ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Fedora CoreOS rawhide stream
On Mon, Dec 21, 2020 at 05:34:01PM -0500, Jonathan Lebon wrote: > We've recently started a rawhide "mechanical" stream of Fedora CoreOS > (mechanical streams are streams that are meant for developers and that > don't use RPM lockfiles). You can see the first build here: > > https://builds.coreos.fedoraproject.org/browser?stream=rawhide > > This will allow us to more easily track breaking changes in rawhide > and work with maintainers and upstreams to resolve them earlier in the > process. (Yes, this is long overdue -- better late than never!) Awesome! Thanks for all the work from the Fedora CoreOS team! kevin signature.asc Description: PGP signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Fedora 34 Change: Enable systemd-oomd by default for all variants (System-Wide Change)
> This is intended to be a generic approach to user space oom > management, but it does tie into resource control too. And the > resource control organization of what processes are considered > critical are different between a desktop and a server. The idea of > "user wants to take control or see what's going on" is a generally > important goal for all of this work, regardless of the Fedora edition > or spin. So are you confirming that users are now going to need to place things in their own cgroup if they do not want systemd-oomd to potentially kill the single cgroup containing all of their running applications? I think this should at the very least be clearly documented in the change proposal, as this user experience is in stark contrast to what Gnome and KDE users will encounter. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: How to troubleshoot aarch64 and s390x?
Michael Catanzaro left as an exercise for the reader: > On Thu, Dec 17, 2020 at 4:35 pm, Richard Shaw wrote: > > I'll take a look at the IBM community stuff while I'm on holiday after > > this week which may also be a stop gap. > > It's probably limited to a short trial period or something. You'll probably > find it lot easier to work with Dan Horak instead. ;) can confirm that Dan's s390x machine is a fast path to fixing s390x breakage. -- nick black -=- https://www.nick-black.com to make an apple pie from scratch, you need first invent a universe. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Fedora 34 Change: Enable systemd-oomd by default for all variants (System-Wide Change)
On Tue, Dec 22, 2020, at 2:45 PM, Tom Seewald wrote: > > If your desktop doesn't segregate apps and services into cgroups, > > systemd-oomd will kill the entire desktop whenever anything uses too > > much memory, because the desktop is going to be running in the same > > cgroup as the apps that it launches. So I think desktop spins (other > > than KDE) ought to opt out of this. It should be good for all Fedora > > editions, though (including Workstation, Server, Atomic, CoreOS), and > > also for KDE spin. > > How will this work on headless systems like Fedora Server, Atomic, and > CoreOS? Will it be expected that users manually create their own > cgroups? This should really be called out in the change. There's a lot of profound things going on here. First, just speaking for Fedora CoreOS I am skeptical of us just turning this on by default. It's tricky because I can see this potentially being beneficial for "self managed containers" (i.e. a few FCOS nodes with manually set up containers) but a major use case of FCOS is Kubernetes (e.g. OKD, Typhoon, upstream kubeadm etc.) and I don't see any mention about integration with kubelet. Today requests/limits are strongly emphasized: https://kubernetes.io/docs/concepts/configuration/manage-resources-containers/#requests-and-limits Now from experience it's definitely common for people to deploy pods without any limits, and that can benefit from better low-memory/OOM handling. Kubelet already has some of that code: https://kubernetes.io/docs/tasks/administer-cluster/out-of-resource/#node-oom-behavior There's an even more obvious stumbling block that FCOS doesn't set up swap by default, and kubelet explicitly fails if it's enabled. Though it looks like there's recent movement in that area: https://github.com/kubernetes/kubernetes/issues/53533 But basically unless someone does groundwork on what swap looks like for FCOS (particularly in cloud instances) and has at least links to kubelet integration I'd expect this to be off on FCOS. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Stale proven packagers
On Tue, Dec 22, 2020 at 10:29:11PM +, Peter Robinson wrote: > > I think what ever process is run at the point their account is > disabled should revoke all privileges, that's a fairly standard IT > security procedure. There's no process for packages/provenpackagers. We do have a process for infrastructure/sysadmins: https://docs.pagure.org/infra-docs/sysadmin-guide/sops/departing-admin.html But it only triggers when we _know_ someone isn't contributing anymore (they tell us, etc). kevin signature.asc Description: PGP signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: What is the most time consuming task for you as packager?
On Tue, Dec 22, 2020 at 11:15:53AM +0100, Miro Hrončok wrote: > On 21. 12. 20 19:36, Kevin Fenzi wrote: > > On Thu, Dec 17, 2020 at 09:21:15PM +0100, Fabio Valentini wrote: > > > As Miro mentioned, I've also developed scripts to handle this "does > > > this update break anything" for the Stewardship / Java SIG, because - > > > at least at first - we didn't have big enough egos / enough confidence > > > to just push updates to rawhide without testing excessively them > > > first: > > > https://github.com/fedora-stewardship/fedora-stewardship.github.io/blob/master/scripts/review_pr.py > > > > > > This first builds (one or more) packages from src.fpo dist-git forks > > > that were prepared for PRs in COPR, recursively or non-recursively > > > queries dependent packages for all of them, and rebuilds them in COPR. > > > Assuming that there's a copr-cli command for querying build successes, > > > they could be compared with the latest status of those packages in > > > koschei, and have it print new build failures. Right now, I compare > > > the results manually. > > > > > > Would something like this fit your definition of "does-it-blend" script? > > > > What format is '--from-git' in? Say I have a fork with a branch I want > > to test, what do I pass it? > > --from-git is a regex of package names that are built from dist git instead > of from latest known SRPM. > > AFAIK The script only supports "the one package" (that is being tested) to > be built from a custom branch, whoch is the purpose of the script: > > $ python scripts/review_pr.py foobar-2.0 kevin:foobar:branch-2.0 > > But you can later built another package in there (with or without depndents) > in the same copr: > > $ python scripts/review_pr.py foobar-2.0 kevin:bazbaz:fix_deps [-nx'.*'] Cool. The help didn't get me this at all. ;) --from-git FROM_GIT regexes for packages to build from git Perhaps that should be "copr-name packager-name:packagename:branchname" ? Anyhow, after that I ran it on python-dogpile-cache 1.1.1 upgrade: https://copr.fedorainfracloud.org/coprs/kevin/python-dogpile-cache-1.1.1/packages/ Cool. Of course there's still stuff to figure out, like: * Since this is a python-package, how many of those actually change on building against the newer package? I mean, can we tell in a scripted way how many packages just keep working fine with the new package and how many need to actually be rebuilt? * as you noted it would be nice to have some way to say 'package X failed to build against your change, but it's already failing to build and this isn't your fault/problem' It would be nice to modernize the fedora-packager package to include scripts like this and docs and make them nice. :) In any case thanks much for the script and pointers! kevin signature.asc Description: PGP signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Fedora 34 Change: Enable systemd-oomd by default for all variants (System-Wide Change)
On Tue, Dec 22, 2020 at 10:41 pm, Tom Seewald wrote: So are you confirming that users are now going to need to place things in their own cgroup if they do not want systemd-oomd to potentially kill the single cgroup containing all of their running applications? If this change is approved: yes! ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Stale proven packagers
On Tue, Dec 22, 2020 at 11:02 PM Kevin Fenzi wrote: > > On Tue, Dec 22, 2020 at 10:29:11PM +, Peter Robinson wrote: > > > > I think what ever process is run at the point their account is > > disabled should revoke all privileges, that's a fairly standard IT > > security procedure. > > There's no process for packages/provenpackagers. > > We do have a process for infrastructure/sysadmins: > https://docs.pagure.org/infra-docs/sysadmin-guide/sops/departing-admin.html > > But it only triggers when we _know_ someone isn't contributing anymore > (they tell us, etc). How were the accounts disabled though? Is there a process for that or how did that happen in this context? ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Fedora CoreOS rawhide stream
On Mon, 2020-12-21 at 17:34 -0500, Jonathan Lebon wrote: > We've recently started a rawhide "mechanical" stream of Fedora CoreOS > (mechanical streams are streams that are meant for developers and that > don't use RPM lockfiles). You can see the first build here: > > https://builds.coreos.fedoraproject.org/browser?stream=rawhide > > This will allow us to more easily track breaking changes in rawhide > and work with maintainers and upstreams to resolve them earlier in the > process. (Yes, this is long overdue -- better late than never!) Cool, I'll set openQA up to test this stream too. -- Adam Williamson Fedora QA IRC: adamw | Twitter: adamw_ha https://www.happyassassin.net ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Fedora CoreOS rawhide stream
On Tue, 2020-12-22 at 15:22 -0800, Adam Williamson wrote: > On Mon, 2020-12-21 at 17:34 -0500, Jonathan Lebon wrote: > > We've recently started a rawhide "mechanical" stream of Fedora CoreOS > > (mechanical streams are streams that are meant for developers and that > > don't use RPM lockfiles). You can see the first build here: > > > > https://builds.coreos.fedoraproject.org/browser?stream=rawhide > > > > This will allow us to more easily track breaking changes in rawhide > > and work with maintainers and upstreams to resolve them earlier in the > > process. (Yes, this is long overdue -- better late than never!) > > Cool, I'll set openQA up to test this stream too. ...well, I will as soon as https://builds.coreos.fedoraproject.org/streams/rawhide.json isn't 403 any more :D -- Adam Williamson Fedora QA IRC: adamw | Twitter: adamw_ha https://www.happyassassin.net ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Stale proven packagers
On Tue, Dec 22, 2020 at 11:22:17PM +, Peter Robinson wrote: > On Tue, Dec 22, 2020 at 11:02 PM Kevin Fenzi wrote: > > > > On Tue, Dec 22, 2020 at 10:29:11PM +, Peter Robinson wrote: > > > > > > I think what ever process is run at the point their account is > > > disabled should revoke all privileges, that's a fairly standard IT > > > security procedure. > > > > There's no process for packages/provenpackagers. > > > > We do have a process for infrastructure/sysadmins: > > https://docs.pagure.org/infra-docs/sysadmin-guide/sops/departing-admin.html > > > > But it only triggers when we _know_ someone isn't contributing anymore > > (they tell us, etc). > > How were the accounts disabled though? Is there a process for that or > how did that happen in this context? Accounts can be disabled two ways: 1. The user logs in and marks the account 'inactive'. To change this back to active they have to reset their password and login again and change it back. 2. An admin can change users to 'disabled' where they cannot change that without intervention. Of course all this may be different in the new account system coming soon. :) kevin signature.asc Description: PGP signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Stale proven packagers
On Wed, Dec 23, 2020 at 12:20 AM Kevin Fenzi wrote: > > On Tue, Dec 22, 2020 at 11:22:17PM +, Peter Robinson wrote: > > On Tue, Dec 22, 2020 at 11:02 PM Kevin Fenzi wrote: > > > > > > On Tue, Dec 22, 2020 at 10:29:11PM +, Peter Robinson wrote: > > > > > > > > I think what ever process is run at the point their account is > > > > disabled should revoke all privileges, that's a fairly standard IT > > > > security procedure. > > > > > > There's no process for packages/provenpackagers. > > > > > > We do have a process for infrastructure/sysadmins: > > > https://docs.pagure.org/infra-docs/sysadmin-guide/sops/departing-admin.html > > > > > > But it only triggers when we _know_ someone isn't contributing anymore > > > (they tell us, etc). > > > > How were the accounts disabled though? Is there a process for that or > > how did that happen in this context? > > Accounts can be disabled two ways: > > 1. The user logs in and marks the account 'inactive'. To change this > back to active they have to reset their password and login again and > change it back. > > 2. An admin can change users to 'disabled' where they cannot change that > without intervention. In both cases all ACLs should be removed, if in the former they wish to have what ever access back there can be a documented process to file a ticket for it. > Of course all this may be different in the new account system coming > soon. :) Let's hope there's some hooks to provide that functionality :) ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Fedora 34 Change: Enable systemd-oomd by default for all variants (System-Wide Change)
On Tue, Dec 22, 2020 at 3:42 PM Tom Seewald wrote: > > > This is intended to be a generic approach to user space oom > > management, but it does tie into resource control too. And the > > resource control organization of what processes are considered > > critical are different between a desktop and a server. The idea of > > "user wants to take control or see what's going on" is a generally > > important goal for all of this work, regardless of the Fedora edition > > or spin. > > So are you confirming that users are now going to need to place things in > their own cgroup if they do not want systemd-oomd to potentially kill the > single cgroup containing all of their running applications? I'm not saying that. I don't mind user configuration for special cases, but that is not a general solution. Today earlyoom will SIGTERM a specific Firefox process, i.e. a tab can be clobbered and it just looks like it crashed, there's no other notification. It doesn't kill off the whole program with all of your tabs. But if it's true that all of my programs in the shell could be subject to being clobbered at once? Is that any better than just hitting the power button or pulling the power cable? The answer is, yes. But only incrementally. And it's not better than what we have today with earlyoom. Also, sd-oomd should be able to send SIGTERM so that there is a chance that process can save state before a SIGKILL is issued. Earlyoom also does that today. > I think this should at the very least be clearly documented in the change > proposal, as this user experience is in stark contrast to what Gnome and KDE > users will encounter. Yeah I'm not sure to what degree these knobs are even user facing. If we're talking about developers and packagers, then yes there should be documentation for them if there's things they need to consider. -- Chris Murphy ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Stale proven packagers
On Wed, Dec 23, 2020 at 12:37 AM Peter Robinson wrote: > > On Wed, Dec 23, 2020 at 12:20 AM Kevin Fenzi wrote: > > > > On Tue, Dec 22, 2020 at 11:22:17PM +, Peter Robinson wrote: > > > On Tue, Dec 22, 2020 at 11:02 PM Kevin Fenzi wrote: > > > > > > > > On Tue, Dec 22, 2020 at 10:29:11PM +, Peter Robinson wrote: > > > > > > > > > > I think what ever process is run at the point their account is > > > > > disabled should revoke all privileges, that's a fairly standard IT > > > > > security procedure. > > > > > > > > There's no process for packages/provenpackagers. > > > > > > > > We do have a process for infrastructure/sysadmins: > > > > https://docs.pagure.org/infra-docs/sysadmin-guide/sops/departing-admin.html > > > > > > > > But it only triggers when we _know_ someone isn't contributing anymore > > > > (they tell us, etc). > > > > > > How were the accounts disabled though? Is there a process for that or > > > how did that happen in this context? > > > > Accounts can be disabled two ways: > > > > 1. The user logs in and marks the account 'inactive'. To change this > > back to active they have to reset their password and login again and > > change it back. > > > > 2. An admin can change users to 'disabled' where they cannot change that > > without intervention. > > In both cases all ACLs should be removed, if in the former they wish > to have what ever access back there can be a documented process to > file a ticket for it. Just to expand on this a little. Removing access from people that have left the project either because they've decided they're able to continue to contribute (option 1) or because something has triggered an admin process (option 2) isn't a slight on the person involved in any of this process and removing a well earned ACL doesn't remove any of the contributions or the value they provided in the past. But we have to realise than inactive accounts may mean associated inactive email addresses or other things associated with a person which may be open to compromise as well and we need to protect the project as a whole as after-all if a fellow contributor has moved on to better things account is used to comprise everything where does that leave us? Group membership is easily re-instated, trust after a security compromise not so much! Peter ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
eclipse-photran builds failed/not included since F32
I'm not quite sure where else to direct this - I intermittently do some Fortran work and the Eclipse plugin (eclipse-photran) appears to have disappeared from the repos since F32. Looking at Koji, releng was previously doing the builds for it . Does anyone know anymore about this including whether eclipse-photran is being (intentionally) dropped and alternatives? Thanks all -- Mark E. Fuller, Ph.D. Robensstraße 57 52070 Aachen +49 (0)1577-1848188 +1 401-366-2771 mark.e.ful...@gmail.com mark.e.ful...@gmx.de @mefuller:matrix.org https://mefuller.github.io/ ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Fedora 34 Change: Enable systemd-oomd by default for all variants (System-Wide Change)
> Earlyoom maintainer here. I think it's too early to switch to > systemd-oomd, because it was just merged to the systemd codebase and is > still an experimental feature. Hi! I authored the PR for systemd-oomd. It was merged as a feature for "preview" rather than "release", but that was so the interface could be improved based on feedback. The feature itself was tested against a subset of Facebook's servers and it behaves the same as the stand alone oomd that we've been running for years (minus the knobs that were not implemented in systemd-oomd). > In earlyoom we have a list of processes that cannot be killed (eg. > dnf/packagekit/etc.), so it is absolutely safe to use as a default > userspace OOM solution. We currently don't know anything about the > systemd-oomd safety for regular use on end user desktops. We can't even > test it on the current stable Fedora release. PSI takes into account cgroup memory protections so you can bias away from cgroups with critical apps by setting MemoryLow= to the appropriate values to prevent reclaim. > That's why I think this change need to be postponed to Fedora 35 (opt-in > in F34 and default in F35). I'm actually not opposed to that. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: What is the most time consuming task for you as packager?
On Mon, Dec 21, 2020 at 11:03:36AM +0100, Vít Ondruch wrote: > > Dne 17. 12. 20 v 21:17 Kevin Fenzi napsal(a): > > > > After 1 day the rpms are removed. > > After 7 days the logs are removed. > > > > Non koschei scratch builds (both logs and rpms) are kept for 14 days. > > > > Would keeping the logs for 14 days help? > > > That would be definitely appreciated. Done. kevin signature.asc Description: PGP signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Stale proven packagers
On Tue, Dec 22, 2020 at 3:47 PM Richard Shaw wrote: > On Tue, Dec 22, 2020 at 2:40 PM Adam Williamson < > adamw...@fedoraproject.org> wrote: > >> >> Perhaps we need a process for cleaning up membership of this extremely >> powerful group? If the FAS password of *any one* of those user accounts >> were somehow compromised (or if just one of them decided they had a >> grudge against Fedora now and were going to have some fun), the results >> could be...unfortunate. >> > > I mentioned it once but got zero response... What about requiring a CLA > (or something like it) annually instead of one time. This would help clean > up inactive packagers as well. > > This seems like a reasonable solution to me. > Thanks, > Richard > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org > ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Review swaps
I need a handful of package reviews to finish reviving the scala package: jline2: https://bugzilla.redhat.com/show_bug.cgi?id=1908038 This is a re-review, as we have had a jline2 package before. This is basically just the existing jline spec file with a new name, so that the jline package can move on to version 3.x. java-diff-utils: https://bugzilla.redhat.com/show_bug.cgi?id=1908039 jol: https://bugzilla.redhat.com/show_bug.cgi?id=1908040 material-icon-fonts: https://bugzilla.redhat.com/show_bug.cgi?id=1908042 I'm happy to review in exchange. Thank you, -- Jerry James http://www.jamezone.org/ ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Fedora 34 Change: Enable systemd-oomd by default for all variants (System-Wide Change)
On Tue, Dec 22, 2020 at 6:17 PM Anita Zhang wrote: > > That's why I think this change need to be postponed to Fedora 35 (opt-in > > in F34 and default in F35). > > I'm actually not opposed to that. Another variation on this theme: enable by default in Fedora 34 Server edition. And more broadly rolled out for Fedora 35. If it's broadly ready for Fedora 34, great. Otherwise, it seems like a good fit for Fedora Server edition, given sd-oomd's server origin and oomd2 been used in production for a number of years. It'd be a significant headline feature for Server edition, especially fitting for the in-progress reboot of that project. Any thoughts from Server WG folks? -- Chris Murphy ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Fedora-Cloud-33-20201223.0 compose check report
No missing expected images. Soft failed openQA tests: 1/7 (x86_64), 1/7 (aarch64) (Tests completed, but using a workaround for a known bug) ID: 745677 Test: x86_64 Cloud_Base-qcow2-qcow2 cloud_autocloud URL: https://openqa.fedoraproject.org/tests/745677 ID: 745684 Test: aarch64 Cloud_Base-qcow2-qcow2 cloud_autocloud@uefi URL: https://openqa.fedoraproject.org/tests/745684 Passed openQA tests: 6/7 (x86_64), 6/7 (aarch64) -- Mail generated by check-compose: https://pagure.io/fedora-qa/check-compose ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
