[Bug 1785649] perl-Filesys-Df needed in EPEL 8
https://bugzilla.redhat.com/show_bug.cgi?id=1785649 Petr Pisar changed: What|Removed |Added Fixed In Version||perl-Filesys-Df-0.92-36.el8 ||perl-Filesys-Df-0.92-36.epe ||l8.playground -- You are receiving this mail because: You are on the CC list for the bug. ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-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/perl-devel@lists.fedoraproject.org
[Bug 1785649] perl-Filesys-Df needed in EPEL 8
https://bugzilla.redhat.com/show_bug.cgi?id=1785649 Fedora Update System changed: What|Removed |Added Status|ASSIGNED|MODIFIED --- Comment #2 from Fedora Update System --- FEDORA-EPEL-2020-4fd9eb3b45 has been submitted as an update to Fedora EPEL 8. https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2020-4fd9eb3b45 -- You are receiving this mail because: You are on the CC list for the bug. ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-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/perl-devel@lists.fedoraproject.org
[Bug 1788333] perl-Verilog-Perl-3.470 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1788333 Jitka Plesnikova changed: What|Removed |Added Status|NEW |ASSIGNED Doc Type|--- |If docs needed, set a value -- You are receiving this mail because: You are on the CC list for the bug. ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-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/perl-devel@lists.fedoraproject.org
[Bug 1788183] perl-POSIX-AtFork-0.04 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1788183 --- Comment #4 from Fedora Update System --- FEDORA-2020-1b51ef234c has been submitted as an update to Fedora 30. https://bodhi.fedoraproject.org/updates/FEDORA-2020-1b51ef234c -- You are receiving this mail because: You are on the CC list for the bug. ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-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/perl-devel@lists.fedoraproject.org
[Bug 1788183] perl-POSIX-AtFork-0.04 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1788183 --- Comment #3 from Fedora Update System --- FEDORA-2020-38f936b5eb has been submitted as an update to Fedora 31. https://bodhi.fedoraproject.org/updates/FEDORA-2020-38f936b5eb -- You are receiving this mail because: You are on the CC list for the bug. ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-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/perl-devel@lists.fedoraproject.org
[Bug 1788183] perl-POSIX-AtFork-0.04 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1788183 Petr Pisar changed: What|Removed |Added Status|ASSIGNED|MODIFIED Fixed In Version||perl-POSIX-AtFork-0.04-1.fc ||32 --- Comment #2 from Petr Pisar --- A bug-fix release suitable for all Fedoras. -- You are receiving this mail because: You are on the CC list for the bug. ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-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/perl-devel@lists.fedoraproject.org
Re: List of long term FTBFS packages to be retired in February
On Mon, Jan 06, 2020 at 05:41:53PM -0500, Peter Jones wrote: > On Mon, Jan 06, 2020 at 02:48:22PM -0500, Robbie Harwood wrote: > > > If you don't have the time to make a new build once every year, you > > shouldn't be a packager, full stop. > > I think that's a fair point, but not at all the issue here. I > specifically want not to rebuild this, which is why I *have* rebuilt all > the other packages I own that were earlier on this and similar lists. > > [skipping ahead just a little...] > > > We are talking about crypto-related packages here; being able to > > rebuild them and be confident in their contents is arguably more > > important than any other kind of package. > > I see your point in general, though I don't agree in this case. The > build is reproducible from source with the earlier gnu-efi-devel, we > know exactly what's in it, and (as you know) if there are any serious > issues like a CVE for the OpenSSL build involved which would effect it, > I don't think there's going to be difficulty remaining aware. There's > no reason not to be confident regarding the contents. > That said, the current build issue in this case is my fault, and fairly > trivial, all said and done. In other words, the amount of time spent arguing on this list is more time than fixing the issue would require. This is why I find your complaints disingenuous: there were multiple options that could be taken *within* the existing rules (like simply fixing the FTBFS and rebuilding, or closing the bug with a message that you fixed it locally but will not rebuild in koji 'cause of reasons, or requesting a fesco exception which would almost certainly be granted). Instead, we are all supposed to treat this one package as a special snowflake, with a maintainer who is above policy and can't be expected to reply on bugzilla, i.e. the standard communication channel in Fedora. Please try to understand that people working on Fedora at scale (i.e. people doing mass rebuilds, or implementing system-wide changes, or simply people who try to fix bugs in others' packages) don't have infinite time to handle each package as a special snowflake and *need* automation to do things in reasonable time. And yes, every FTBFS package and every FTBFS bug is an issue that drains the time of other packagers, because it breaks mass rebuilds and mass package changes and bug zapping campaigns. Zbyszek ___ 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
[Bug 1788181] perl-Inline-0.85 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1788181 Petr Pisar changed: What|Removed |Added Status|ASSIGNED|CLOSED Fixed In Version||perl-Inline-0.85-1.fc32 Resolution|--- |RAWHIDE Last Closed||2020-01-07 07:16:42 --- Comment #2 from Petr Pisar --- An enhancement release safer for Rawhide only. -- You are receiving this mail because: You are on the CC list for the bug. ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-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/perl-devel@lists.fedoraproject.org
[Bug 1788183] perl-POSIX-AtFork-0.04 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1788183 Petr Pisar changed: What|Removed |Added Status|NEW |ASSIGNED CC|ppi...@redhat.com | Doc Type|--- |If docs needed, set a value -- You are receiving this mail because: You are on the CC list for the bug. ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-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/perl-devel@lists.fedoraproject.org
Re: Fedora 32 System-Wide Change proposal (late): Enable EarlyOOM
On Mon, 6 Jan 2020, 18:32 Kamil Paral, wrote: > On Sun, Jan 5, 2020 at 12:43 PM Aleksandra Fedorova > wrote: > >> I wonder, how I as a user going to be informed about the >> earlyoom-event? I assume abrt will recognize the crash? Will it be >> easily visible from the abrt report that it was the OOM? >> >> The concern is: if we enable such a service, will we get large amount >> of vague bug reports from users who don't understand what has >> happened. Can we make it somehow easier to debug? >> > > FWIW, the behavior on Android is very close to what is proposed here. If > your application exceeds the amount of available memory, it simply closes > right in front of your eyes. No explanation, nothing, it's just gone (might > be different on latest Android versions). The same thing would happen with > EarlyOOM - some application would disappear. > > I agree it would be nice to inform the user before or at least after. > Windows can do it - they show a notification roughly saying "Your system is > running out of memory and some application might get closed". (At least > they used to in the old days, I haven't run out of memory for a long time, > and I don't know whether Windows 10 behaves the same way). But I think it > should not be a stopper for the proposal as it is. Even without the > notification the user experience is improved over the default behavior. > I am not convinced that it is an improvement to be honest. UX before: system works, I run heavy application, system starts to hang, i understand that there is an issue, i can kill the app or reboot, which gives me clean and working system. UX after: system works, no visible problems. Suddenly random app disappears, no errors or crashes reported to me. It might be that my active app is killed, then I know that smth happened, but what if background process is killed? Maybe my messenger app? I am going to keep working in my main app without noticing that I lost something, not knowing that I need to take action. And my system now runs in a weird state, and can stay there for days, which will lead to more weird and nonreproducible errors later. The "hang" of a system was the feedback user got from the system that there is something wrong. Not ideal, but at least there was something. With this feature we don't solve the issue, we remove the "bad" feedback, and we don't provide any replacement for it making memory problem completely invisible. Is it really a good UX? ___ > 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: Fedora 32 System-Wide Change proposal (late): Enable EarlyOOM
I am not using a swap partition at all, the system always hangs when OOM but sometimes also at just less than 20% On Tue, Jan 7, 2020 at 8:43 AM Peter Hutterer wrote: > > On Sat, Jan 04, 2020 at 12:15:20PM -0600, Michael Catanzaro wrote: > > Let's keep this desktop-focused, since the proposal does not affect Server > > edition. > > > > On Sat, Jan 4, 2020 at 12:48 pm, drago01 wrote: > > > As for the desktop case the running web browers in a cgroup to keep them > > > in check would solve most real world problems - other common desktop > > > apps don't use enough memory to cause such issues (unless your system is > > > really memory constrained but then the "buy more memory" solution is the > > > better fix). > > > > The last time I saw my desktop hang due to a web browser using too much > > memory was 2015. > > just FTR, this happens relatively frequently for me. Some websites seem to > cause Firefox to swap itself into nirvana. Sometimes within a short time > but sometimes it takes longer. I've come back from a lunch break a few times > to a desktop swapping itself to death. > > Not yet fully identified but it does happen. > > Cheers, >Peter > > > > > The freezes I've encountered in the past five years were all related to > > software development: > > > > * When compiling large software projects, it's possible to run out of RAM > > either when building lots of files in parallel, or when linking > > * GNOME Builder runs ctags, and ctags likes to use dozens of GB of RAM to > > index large software projects. I think it sometimes gets into a loop where > > it just allocates more and more RAM until the desktop dies > > > > ___ > > 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 ___ 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 32 System-Wide Change proposal (late): Enable EarlyOOM
On Sat, Jan 04, 2020 at 12:15:20PM -0600, Michael Catanzaro wrote: > Let's keep this desktop-focused, since the proposal does not affect Server > edition. > > On Sat, Jan 4, 2020 at 12:48 pm, drago01 wrote: > > As for the desktop case the running web browers in a cgroup to keep them > > in check would solve most real world problems - other common desktop > > apps don't use enough memory to cause such issues (unless your system is > > really memory constrained but then the "buy more memory" solution is the > > better fix). > > The last time I saw my desktop hang due to a web browser using too much > memory was 2015. just FTR, this happens relatively frequently for me. Some websites seem to cause Firefox to swap itself into nirvana. Sometimes within a short time but sometimes it takes longer. I've come back from a lunch break a few times to a desktop swapping itself to death. Not yet fully identified but it does happen. Cheers, Peter > > The freezes I've encountered in the past five years were all related to > software development: > > * When compiling large software projects, it's possible to run out of RAM > either when building lots of files in parallel, or when linking > * GNOME Builder runs ctags, and ctags likes to use dozens of GB of RAM to > index large software projects. I think it sometimes gets into a loop where > it just allocates more and more RAM until the desktop dies > > ___ > 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
[Bug 1788181] perl-Inline-0.85 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1788181 Petr Pisar changed: What|Removed |Added Status|NEW |ASSIGNED CC|jples...@redhat.com,| |ppi...@redhat.com | Doc Type|--- |If docs needed, set a value -- You are receiving this mail because: You are on the CC list for the bug. ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-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/perl-devel@lists.fedoraproject.org
Re: Fedora 32 System-Wide Change proposal (late): Enable EarlyOOM
> For now, kernel developers have made it clear they do not care about > user space responsiveness. At all. Their concern with kernel > oom-killer is strictly with keeping the kernel functioning. This is false. The stated purpose of the OOM killer is not only to keep the kernel alive. Nor does the fact the kernel has not solved userspace responsiveness yet imply that kernel folks do not care. Rather, it means that they will not solve it on their own because the kernel does not have all the information it needs. Kernel folks do care, or we wouldn’t have PSI or cgroups. A userspace solution is needed, but does not need to replace the OOM killer; cgroups are also a userspace solution. If earlyoom breaks them, it can make things worse than the status quo. > Can it be done with cgroupv2 and PSI alone? Unclear. Of course it can. Just run 100 instances of every stress-ng memory worker in a podman container with a cgroup memory limit. The system will not hang. Do the same without the memory limit. The system will hang within seconds and never recover. Thus demonstrating that cgroups work and do the things they were intended to do. Try it. With a memory limit, podman run --rm -it --memory=1G fedora bash -c 'dnf install -y stress-ng && stress-ng --malloc 100 --memcpy 100 --mmap 100 --vm 100' will use CPU but keep your system responsive. Without the memory limit (this will hang your system), podman run --rm -it fedora bash -c 'dnf install -y stress-ng && stress-ng --malloc 100 --memcpy 100 --mmap 100 --vm 100' the system hangs and doesn’t recover after 15 minutes. Same thing with `tail /dev/zero`: podman run --rm -it --memory=1G fedora tail /dev/zero activates the OOM killer after three seconds, with kernel: Memory cgroup out of memory: Killed process 8814 (tail) total-vm:3141408kB, anon-rss:1042028kB, file-rss:4kB, shmem-rss:0kB, UID:1000 pgtables:6336512kB oom_score_adj:0 systemd[943]: libpod-e061e1cb57dde204632531a556d37efbd51c9ab67346a8bc4d5e26c7301c165b.scope: A process of this unit has been killed by the OOM killer.kernel: oom_reaper: reaped process 8814 (tail), now anon-rss:0kB, file-rss:0kB, shmem-rss:0kB logged in the system journal. You were saying the OOM killer activates too late and rarely kills the right process? Well, here it activates early enough and knows exactly what to stop. It is worth trying with ninja and WebKit too. ___ 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 32 System-Wide Change proposal (late): Enable EarlyOOM
Seems like this bug: **Kills multiple processes at once** https://github.com/rfjakob/earlyoom/issues/121 but according to github it's fixed now. ___ 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
Trouble creating modular metadata for local repo
Hi all, I'm trying to create a local repo of an offline collection of systems. When I try to install, I get: No available modular metadata for modular package 'foo.arch', it cannot be installed on the system Googling leads me to: https://docs.fedoraproject.org/en-US/modularity/hosting-modules/ Which tells me to run: # createrepo_c /path/to/rpms/x86_64/os/ # modifyrepo_c --mdtype=modules modules.yaml /path/to/rpms/x86_64/os/ However, the 'modifyrepo_c' call returns: File "modules.yaml" is not regular file or doesn't exists I'm wondering how to fix this? The repo is simply a collection of RPMs, created specifically using the command: /usr/bin/createrepo_c -g /path/to/rpms/x86_64/os/comps.xml /path/to/rpms/x86_64/os Any help or guidance is much appreciated. :) -- Digimer Papers and Projects: https://alteeve.com/w/ "I am, somehow, less interested in the weight and convolutions of Einstein’s brain than in the near certainty that people of equal talent have lived and died in cotton fields and sweatshops." - Stephen Jay Gould ___ 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: Upgrading libffi
On Mon, Jan 6, 2020 at 11:02 PM Anthony Green wrote: > > Guido Aulisi writes: > > If you know all depending packages will get updated in an acceptable > > time to the new ABI, you can wait for this to happen, and then rebuild > > all in rawhide. > > The API is mostly the same. Virtually everything should already build > with the new version (Debian has tested this already). But the upgrade > just isn't that simple. A number of key packages (eg. RPM) depend on > libffi. My understanding is that we'll have to make a 'compat' version > of libffi using the current version, then build/deploy the new version, > and then go back and rebuild all of the dependent packages before > deleting the compat package. > RPM does not use libffi at all. That said, it's quite easy to do a rebuild of libffi's reverse dependencies in a side-tag and then merge it back in. You can always ask for help from releng or other folks around here to help get it done. -- 真実はいつも一つ！/ 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: Upgrading libffi
Guido Aulisi writes: > If you know all depending packages will get updated in an acceptable > time to the new ABI, you can wait for this to happen, and then rebuild > all in rawhide. The API is mostly the same. Virtually everything should already build with the new version (Debian has tested this already). But the upgrade just isn't that simple. A number of key packages (eg. RPM) depend on libffi. My understanding is that we'll have to make a 'compat' version of libffi using the current version, then build/deploy the new version, and then go back and rebuild all of the dependent packages before deleting the compat package. I just don't have time to do this and am looking for help. AG -- Anthony Green ___ 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: Orphaned packages looking for new maintainers
On Mon, Jan 6, 2020 at 5:26 AM Dan Čermák wrote: > That is correct, however I will probably orphan ocaml-deriving and > ocaml-sexplib very soon because we only need ocaml-bin-prot for infer > and I have no need for the other two packages. Sorry, I was on the road and my memory played tricks on me. Yes, we do not need ocaml-deriving or ocaml-sexplib. I would advocate for retiring them altogether, rather than orphaning them again. > However, ocaml-bin-prot was also rewritten and went through 2 versioning > changes in the meantime resulting in the current latest version being > smaller than the current version in Fedora. This will probably cause all > kinds of funny problems if I try to submit an update with a smaller > NEVRA :( As Richard said, the Epoch will have to be bumped. -- 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
[Fedocal] Reminder meeting : Modularity Team (weekly)
Dear all, You are kindly invited to the meeting: Modularity Team (weekly) on 2020-01-07 from 15:00:00 to 16:00:00 UTC At fedora-meetin...@irc.freenode.net The meeting will be about: Meeting of the Modularity Team. More information available at: [Modularity Team Docs](https://docs.pagure.org/modularity/) The agenda for the meeting is available as flagged tickets [in the Modularity repository](https://pagure.io/modularity/issues?status=Open=Meeting). Source: https://apps.fedoraproject.org/calendar/meeting/9480/ ___ 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
[Bug 1787958] perl-DB_File-1.853 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1787958 --- Comment #5 from Fedora Update System --- perl-DB_File-1.853-1.fc30 has been pushed to the Fedora 30 testing repository. If problems still persist, please make note of it in this bug report. See https://fedoraproject.org/wiki/QA:Updates_Testing for instructions on how to install test updates. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2020-e2f3cb0259 -- You are receiving this mail because: You are on the CC list for the bug. ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-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/perl-devel@lists.fedoraproject.org
Re: List of long term FTBFS packages to be retired in February
On Mon, 2020-01-06 at 17:27 -0500, Ben Cotton wrote: > On Mon, Jan 6, 2020 at 4:58 PM Peter Jones wrote: > > On Mon, Jan 06, 2020 at 12:54:58PM +0100, Miro Hrončok wrote: > > > > > Regardless of different opinions about aggressiveness, having policies > > > and no enforcement makes no sense. Either the polices are too > > > aggressive and we need to change them, or they are not and we need to > > > enforce them. > > > > That seems like a rather poor way to think about policy in general, and > > I have some disagreements with it in this specific case as well. In > > general, you're not considering that it may be worth having policies > > reflect our *ideal* situation, and acknowledge that they don't always > > fit the real world precisely. > > > I agree with both of you here. I'm a big believer in the "don't have > rules you're not willing to enforce" philosophy, but I also think > "zero tolerance" is a bad approach to things. > > The challenge we face here in particular is how to strike the right > balance. Strict enforcement is the easiest to scale because it can be > largely automated. The problem is that we run into these non-ideal > cases and don't have a good way to handle them. I mean, I kind of disagree? Miro has already said multiple times he's perfectly willing to have exceptions to the policy, they just need to be decided on and justified. The enforcement tools and processes can handle exceptions, that's not the issue: the issue (at least as Miro describes it) is that until today, the maintainer did not actually show up and say "hey, shim* should be excepted from this policy, for these reasons" in response to all the prompts about this process. > A more hands-on > approach would be better, if we had a person whose full time job was > to go through the output and identify what is and is not appropriate > to remove. It seems reasonable to require packagers who want exceptions to at least _ask for them and justify them themselves_. That really doesn't seem like an onerous burden. It's a one-time effort. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://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: Let's talk about Fedora in the '20s!
On Mon, Jan 6, 2020 at 7:43 PM Matthew Miller wrote: > > On Mon, Jan 06, 2020 at 04:38:51PM -0800, Brian C. Lane wrote: > > > In support of that, I'd like to also have that page steer people into > > > tooling for creating new spins —- and I'd like to see us invest in and > > > rebuild the spin creation processes. (Particularly, I'd like spin releases > > > to be decoupled from the main OS release, and for those to be self-service > > > by their SIGs with minimal rel-eng involvement needed.) > > One of the primary goals of the osbuild project is to be able to build > > different releases from the same host system: > > https://github.com/osbuild/osbuild > > https://github.com/osbuild/osbuild-composer > > That sounds like at least a component of what I'm interested in! > While probably not *quite* flashy and new, this is something I do regularly with KIWI[1] and livecd-tools[2]. For the past few years, I've been working in the KIWI project upstream to make Fedora a first-class citizen, and today that is pretty much the case. It's actually quite easy to produce a wide variety of outputs (ISOs, disk images for OEM preload, VM disks, container images, etc.). And of course, I'm the maintainer of the livecd-tools suite that is still partially used to build our Fedora images. Unfortunately, I have no flashy frontends to go with either. The main web frontend for KIWI is OBS[3] and the revisor[4] project that was the frontend for livecd-creator has been dead for a while... I'd personally like to see Koji democratized more like COPR, where people can have projects with all their inputs and have builds/integrations set up. Of course my holy grail would be that everything would come together and we'd have one unified system to serve all our needs... At the minimum, democratizing Koji would make it easier for Teams to build their own stuff using any of the tools supported by Koji... Then it's a question of documentation of how to make custom media and describing things like how to do branding. [1]: https://github.com/OSInside/kiwi [2]: https://github.com/livecd-tools/livecd-tools [3]: http://openbuildservice.org/ [4]: https://pagure.io/revisor -- 真実はいつも一つ！/ 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
[Bug 1787958] perl-DB_File-1.853 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1787958 Fedora Update System changed: What|Removed |Added Status|MODIFIED|ON_QA --- Comment #4 from Fedora Update System --- perl-DB_File-1.853-1.fc31 has been pushed to the Fedora 31 testing repository. If problems still persist, please make note of it in this bug report. See https://fedoraproject.org/wiki/QA:Updates_Testing for instructions on how to install test updates. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2020-5d47a0dbd3 -- You are receiving this mail because: You are on the CC list for the bug. ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-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/perl-devel@lists.fedoraproject.org
Re: Let's talk about Fedora in the '20s!
On Mon, Jan 06, 2020 at 04:38:51PM -0800, Brian C. Lane wrote: > > In support of that, I'd like to also have that page steer people into > > tooling for creating new spins —- and I'd like to see us invest in and > > rebuild the spin creation processes. (Particularly, I'd like spin releases > > to be decoupled from the main OS release, and for those to be self-service > > by their SIGs with minimal rel-eng involvement needed.) > One of the primary goals of the osbuild project is to be able to build > different releases from the same host system: > https://github.com/osbuild/osbuild > https://github.com/osbuild/osbuild-composer That sounds like at least a component of what I'm interested in! -- 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
Re: Let's talk about Fedora in the '20s!
On Mon, Jan 06, 2020 at 12:19:30PM -0500, Matthew Miller wrote: > In support of that, I'd like to also have that page steer people into > tooling for creating new spins —- and I'd like to see us invest in and > rebuild the spin creation processes. (Particularly, I'd like spin releases > to be decoupled from the main OS release, and for those to be self-service > by their SIGs with minimal rel-eng involvement needed.) One of the primary goals of the osbuild project is to be able to build different releases from the same host system: https://github.com/osbuild/osbuild https://github.com/osbuild/osbuild-composer -- Brian C. Lane (PST8PDT) - weldr.io - lorax - parted - pykickstart ___ 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 32 system-wide change proposal: reduce installation media size by improving the compression ratio of SquashFS filesystem
On Sun, Jan 05, 2020 at 10:08:07AM -0700, Chris Murphy wrote: > I've pretty much concluded Fedora is best off dropping the nested ext4 > in favor of plain squashfs, and using zstd. It's not required to do > both, but the benefit is additive and significant. The work in dracut > and lorax to support plain squashfs, assembling it using overlayfs > instead of device-mapper is already done, and tested. I agree with Chris here, I think we should make the switch to plain squashfs unless someone can come up something dramatic that it will break :) Tweaking the current settings would be fine if we didn't have a better, simpler, solution. A side note about the xz bcj compression -- in some experiments I noticed that enabling x86 and armthumb resulted in further reduction (about 400k with the default block size). My guess was due to use of ARM instructions in the firmware blobs. -- Brian C. Lane (PST8PDT) - weldr.io - lorax - parted - pykickstart ___ 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
[Bug 1781826] Please build perl-Lchown for EPEL 6, 7 and 8
https://bugzilla.redhat.com/show_bug.cgi?id=1781826 Fedora Update System changed: What|Removed |Added Fixed In Version|perl-Lchown-1.01-14.el8 |perl-Lchown-1.01-14.el8 |perl-Lchown-1.01-14.el7 |perl-Lchown-1.01-14.el7 ||perl-Lchown-1.01-14.el6_10 --- Comment #10 from Fedora Update System --- perl-Lchown-1.01-14.el6_10 has been pushed to the Fedora EPEL 6 stable repository. If problems still persist, please make note of it in this bug report. -- You are receiving this mail because: You are on the CC list for the bug. ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-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/perl-devel@lists.fedoraproject.org
Re: ssl3_get_record:wrong version number
On Mon, 6 Jan 2020 15:19:28 -0800 Kevin Fenzi wrote: > On Mon, Jan 06, 2020 at 05:53:53PM -0500, David Muse wrote: > > I keep getting "ssl3_get_record:wrong version number" errors when I try to > > run "fedpkg build", usually during checkout. Searching the archives, it > > looks like the last time someone reported this, it was during a planned > > outage, but I don't see anything down on the fedora infrastructure status > > page. Is this error expected at the moment, or am I doing something wrong? > > > > Since I guess no good deed goes unpunished, I am trying to reinstall > some proxy servers and apparently they didn't properly remove from dns. > :( > > I think it should be all back to normal now, but if not, it should > definitely be back in a bit once I am done with this provisioning. Looks like it's working now. Thanks! > > Sorry again for instability. ;( > > 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
Re: Upgrading libffi
Il giorno lun, 06/01/2020 alle 18.11 -0500, Anthony Green ha scritto: > I released a new version of libffi a month or so ago, the first one > in 5 > years. There's an ABI change that was unavoidable in order to > accommodate the aarch64 port, and the sonumber was bumped. > > I am also the Fedora package maintainer for libffi, but admit that I > don't have the time or expertise required to manage an ABI-breaking > libffi upgrade in Fedora (assuming the temporary requirement of a > 'compat' package, etc), as there are many packages that depend on > this > library. If you know all depending packages will get updated in an acceptable time to the new ABI, you can wait for this to happen, and then rebuild all in rawhide. > Should I simply orphan libffi and hope that somebody picks it > up? I'm > looking for the best path forward. I don't think this would be the best solution! And you are surely the best packager of your own software. > Thanks! > > AG > > -- > Anthony Green Ciao Guido ___ 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: List of long term FTBFS packages to be retired in February
On 06. 01. 20 23:27, Ben Cotton wrote: On Mon, Jan 6, 2020 at 4:58 PM Peter Jones wrote: On Mon, Jan 06, 2020 at 12:54:58PM +0100, Miro Hrončok wrote: Regardless of different opinions about aggressiveness, having policies and no enforcement makes no sense. Either the polices are too aggressive and we need to change them, or they are not and we need to enforce them. That seems like a rather poor way to think about policy in general, and I have some disagreements with it in this specific case as well. In general, you're not considering that it may be worth having policies reflect our *ideal* situation, and acknowledge that they don't always fit the real world precisely. I agree with both of you here. I'm a big believer in the "don't have rules you're not willing to enforce" philosophy, but I also think "zero tolerance" is a bad approach to things. The challenge we face here in particular is how to strike the right balance. Strict enforcement is the easiest to scale because it can be largely automated. The problem is that we run into these non-ideal cases and don't have a good way to handle them. A more hands-on approach would be better, if we had a person whose full time job was to go through the output and identify what is and is not appropriate to remove. In fact, the reason I've decided to have the "at least 5 devel e-mails" part of the policy is exactly this: So we can identify "important packages" early and either rebuild them in time, like Tom did for most of the listed packages (thank you!), or exempt some packages from the policy, if good reasons exist. And here we come, working on exactly that. I do understand that some maintainers might see the policy as a threat, but that was never the intention. This is part of the policy to prevent maintainers form simply ASSIGNING bugs forever without fixing anything. How much of this is a response to an actual problem versus a preemptive prevention of an anticipated problem? If we were to allow maintainers to set bugs to ASSIGNED forever, is the actual end result something we could live with? (Perhaps with an exception for security bugs) Partly, this was a compromise designed as a preemptive prevention. But OTOH it also works around quirks like packages never being actually attempted to be rebuilt etc. Whether or not this is an actual problem: I've seen a lot of cases where the bugzillas were ASSIGNED to prevent orphaning, but nothing has changed. Whether or not this would repeat for 3 cycles is unknown to me, but I am happy that there is a deadline. It practically says: No, you don't need to fix this right now, you can do an explcit action to postpone the problem, but you cannot procrastinate it forever (or forget about it). So rather than an actual problem response, I see it as a "driven by deadines" kind of thing. In this thread we see that some maintainers would actually want a way to simply get red if the the problem by assigning the bugzillas - and I prefer very much an explicit policy exception if that is ever needed. I believe FESCo would grant in in both the following cases: - there is a good reason why we don't want this policy to apply on X, ever - due to unforeseen circumstances, X isto be retired sooner than we can fix it Similarly, to Peter: how would you suggest we special-case these three packages (and others like them) so that we know to always exclude them from the mass rebuild (except when explicitly requested) and exempt them from the automated FTBFS queries? I suggest we discuss this exception on devel list and FESCo rubber stamps it. We can document such packages on the policy page. If the list would be so long that it would make the policy page unreadable, it would send a signal that the policy needs to be changed anyway. -- 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: List of long term FTBFS packages to be retired in February
On 06. 01. 20 22:57, Peter Jones wrote: On Mon, Jan 06, 2020 at 12:54:58PM +0100, Miro Hrončok wrote: Regardless of different opinions about aggressiveness, having policies and no enforcement makes no sense. Either the polices are too aggressive and we need to change them, or they are not and we need to enforce them. That seems like a rather poor way to think about policy in general, and I have some disagreements with it in this specific case as well. In general, you're not considering that it may be worth having policies reflect our *ideal* situation, and acknowledge that they don't always fit the real world precisely. I'd rather have our polices fit the reality we want and agree on, rather than have polices that we know are contradicting it. In this particular case, you have presented arguments elsewhere in this thread for why those packages should be exempted from it. I will not go into detail whether those argument are or are not good enough (not here), but I think that this is a way to go - if we don't want a package to be part of the process, we should document why and exclude it. That way we can avoid unnecessary notifications, dead bugzillas and well... this discussion. What you seem to prefer is that we simply do consider the enforcement on case by case basis every time this happens, which is almost impossible. (Sorry if that is not what you actually would prefer.) I think that's a thing we need to consider, because both the mass rebuild policy, and the crusade you're on to use it to drive your use of the FTBFS policy. In both cases the intent of the policy is clearly good, but the way you're trying to handle enforcement has aggravated quite a few people - I think I've witnessed at least 3 people tell you this in general, and two of us have (more than once) about this specific case. As always, I invite those people (and specially you two) to discuss the necessary changes in the policy itself. Should there be specific changes in the policy? Do tell. What you seem to ask is to stop enforcing policies, and I must disagree with that. I don't think this is in any way a reasonable conclusion *or* a reasonable response. Nobody said "we should never enforce any policies", or even anything you might reasonably confuse for that. There aren't very many things that are good "one size fits all" policies with something as complex as a linux distro, and those are mostly very, very core things, like "the stuff in your package has got to be open source". Most things, we can only make the policy fit everything so well, and try to make it fit better when we can, and enforce it to the appropriate extent. The enforcing part is part of the policy itself. What is the appropriate extent here? We have recently made it so that it is possible to keep a package that fails to build for a reasonable time. Now we are only enforcing it after several releases. Is it too little time? Should it be more releases instead? Or forever? But instead, you're talking about policy enforcement as if we should send people to jail if they accidentally drop a candy wrapper when they're putting it in their pocket to throw away later. We are not sending anybody to jail. We are simply saying: Fedora package maintainers have responsibilities: https://docs.fedoraproject.org/en-US/fesco/Package_maintainer_responsibilities/ And if you don't take those responsibilities, something happens and possibly somebody else will. In my experience, in many cases it is the enforcing that drives fixes. Packages get adopted by people who have the time to maintain them, "dead" packages get removed, broken dependencies get fixed. Note that IMHO it's mostly Red Hat employees that are "forced" to fix their packages by enforcing the polcies, not community members. The community packagers either care about their packages and they fix them in timely manner, or they are already gone. But I have no data to back this up, so feel free to disagree there. The insinuation that Red Hat employees, including me, don't care about what we're working on is pretty seriously insulting. I do sincerely apologize if I have insulted you or any other Red hat employee. All I presented is my personal experience. Probably too generalized, and I am sorry for that. There are excellent Red Hat employees Fedora packagers who care deeply and are standing by the responsibilities linked above and it is a pleasure to work with them. Also said in the e-mail, if you think those packages need to be exempted from the process, we can deal with that to, however there must be a valid reason. I don't think "the maintainer didn't actually maintain their Fedora packages for almost 2 years because they have real stuff to do" is a valid reason, yet other FESCo members might disagree with that statement. Well the FTB from people pushing builds would be directly due to the fact they're not on the ACL for the secure-boot, there is a handful of
Re: List of long term FTBFS packages to be retired in February
On Mon, Jan 06, 2020 at 05:41:53PM -0500, Peter Jones wrote: > On Mon, Jan 06, 2020 at 02:48:22PM -0500, Robbie Harwood wrote: > > > If you don't have the time to make a new build once every year, you > > shouldn't be a packager, full stop. > > I think that's a fair point, but not at all the issue here. I > specifically want not to rebuild this, which is why I *have* rebuilt all > the other packages I own that were earlier on this and similar lists. > > [skipping ahead just a little...] > > > We are talking about crypto-related packages here; being able to > > rebuild them and be confident in their contents is arguably more > > important than any other kind of package. > > I see your point in general, though I don't agree in this case. The > build is reproducible from source with the earlier gnu-efi-devel, we > know exactly what's in it, and (as you know) if there are any serious > issues like a CVE for the OpenSSL build involved which would effect it, > I don't think there's going to be difficulty remaining aware. There's > no reason not to be confident regarding the contents. > > That said, the current build issue in this case is my fault, and fairly > trivial, all said and done. I specifically want not to rebuild it - I > very strongly prefer to wait until we're done with the upstream release > and use that instead. There are a couple of reasons for that, and they > overlap significantly with why this shouldn't be part of the mass > rebuilds: > > - We literally get nothing out of rebuilding it unless something goes > wrong. Nothing. Aside from some datestamps and the like that are in > this version, you should get the exact same binary. (The next version > will actually be fully debian-style reproducible, but that's assuming > the same compiler, etc.) ...snip... This is not exactly true, since we switched rpm binary payload to zstd, we get... a miniscule amount of time less building images as it unpacks? :) In any case, perhaps we should just do what we do with many of our policies: Just have an exception process and record those packages that should be excepted? 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: ssl3_get_record:wrong version number
On Mon, Jan 06, 2020 at 05:53:53PM -0500, David Muse wrote: > I keep getting "ssl3_get_record:wrong version number" errors when I try to > run "fedpkg build", usually during checkout. Searching the archives, it > looks like the last time someone reported this, it was during a planned > outage, but I don't see anything down on the fedora infrastructure status > page. Is this error expected at the moment, or am I doing something wrong? > Since I guess no good deed goes unpunished, I am trying to reinstall some proxy servers and apparently they didn't properly remove from dns. :( I think it should be all back to normal now, but if not, it should definitely be back in a bit once I am done with this provisioning. Sorry again for instability. ;( 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
[Bug 1788333] New: perl-Verilog-Perl-3.470 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1788333 Bug ID: 1788333 Summary: perl-Verilog-Perl-3.470 is available Product: Fedora Version: rawhide Status: NEW Component: perl-Verilog-Perl Keywords: FutureFeature, Triaged Assignee: jples...@redhat.com Reporter: upstream-release-monitor...@fedoraproject.org QA Contact: extras...@fedoraproject.org CC: chitl...@gmail.com, jples...@redhat.com, perl-devel@lists.fedoraproject.org Target Milestone: --- Classification: Fedora Latest upstream release: 3.470 Current version/release in rawhide: 3.468-1.fc32 URL: http://search.cpan.org/dist/Verilog-Perl/ Please consult the package updates policy before you issue an update to a stable branch: https://fedoraproject.org/wiki/Updates_Policy More information about the service that created this bug can be found at: https://fedoraproject.org/wiki/Upstream_release_monitoring Please keep in mind that with any upstream change, there may also be packaging changes that need to be made. Specifically, please remember that it is your responsibility to review the new version to ensure that the licensing is still correct and that no non-free or legally problematic items have been added upstream. Based on the information from anitya: https://release-monitoring.org/project/3494/ -- You are receiving this mail because: You are on the CC list for the bug. ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-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/perl-devel@lists.fedoraproject.org
Upgrading libffi
I released a new version of libffi a month or so ago, the first one in 5 years. There's an ABI change that was unavoidable in order to accommodate the aarch64 port, and the sonumber was bumped. I am also the Fedora package maintainer for libffi, but admit that I don't have the time or expertise required to manage an ABI-breaking libffi upgrade in Fedora (assuming the temporary requirement of a 'compat' package, etc), as there are many packages that depend on this library. Should I simply orphan libffi and hope that somebody picks it up? I'm looking for the best path forward. Thanks! AG -- Anthony Green ___ 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: ssl3_get_record:wrong version number
I'm seeing this running fedscm-admin as well. Sometimes. -- Gwyn Ciesla she/her/hers in your fear, seek only peace in your fear, seek only love -d. bowie Sent with ProtonMail Secure Email. ‐‐‐ Original Message ‐‐‐ On Monday, January 6, 2020 4:53 PM, David Muse wrote: > I keep getting "ssl3_get_record:wrong version number" errors when I try to > run "fedpkg build", usually during checkout. Searching the archives, it looks > like the last time someone reported this, it was during a planned outage, but > I don't see anything down on the fedora infrastructure status page. Is this > error expected at the moment, or am I doing something wrong? > > Thanks, > > David > david.m...@firstworks.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 signature.asc 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
ssl3_get_record:wrong version number
I keep getting "ssl3_get_record:wrong version number" errors when I try to run "fedpkg build", usually during checkout. Searching the archives, it looks like the last time someone reported this, it was during a planned outage, but I don't see anything down on the fedora infrastructure status page. Is this error expected at the moment, or am I doing something wrong? Thanks, David david.m...@firstworks.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: List of long term FTBFS packages to be retired in February
On Mon, Jan 06, 2020 at 02:48:22PM -0500, Robbie Harwood wrote: > If you don't have the time to make a new build once every year, you > shouldn't be a packager, full stop. I think that's a fair point, but not at all the issue here. I specifically want not to rebuild this, which is why I *have* rebuilt all the other packages I own that were earlier on this and similar lists. [skipping ahead just a little...] > We are talking about crypto-related packages here; being able to > rebuild them and be confident in their contents is arguably more > important than any other kind of package. I see your point in general, though I don't agree in this case. The build is reproducible from source with the earlier gnu-efi-devel, we know exactly what's in it, and (as you know) if there are any serious issues like a CVE for the OpenSSL build involved which would effect it, I don't think there's going to be difficulty remaining aware. There's no reason not to be confident regarding the contents. That said, the current build issue in this case is my fault, and fairly trivial, all said and done. I specifically want not to rebuild it - I very strongly prefer to wait until we're done with the upstream release and use that instead. There are a couple of reasons for that, and they overlap significantly with why this shouldn't be part of the mass rebuilds: - We literally get nothing out of rebuilding it unless something goes wrong. Nothing. Aside from some datestamps and the like that are in this version, you should get the exact same binary. (The next version will actually be fully debian-style reproducible, but that's assuming the same compiler, etc.) - If they're not the same, even if it is merely timestamps in headers differing, then just rebuilding the two "unsigned" packages without going through the process to get the third package signed makes our reproducibility worse, not better. - Because there aren't enough people participating in the broader ecosystem (i.e. reviewing other distro's builds to make sure they haven't messed it up or created a back door, accidentally or on purpose), getting it signed has the effect of adding hard deadlines for quite a bit of ancillary work that will require scheduling and time. - The worst-case support burden is *extraordinarily* high, in dollars, and more builds of the same source tree makes it higher in surprisingly large increments. I can go into detail if you like, but I think you and many others have heard me explain it several times before. - I'm doing most of the upstream work, and doing the rebuilds, getting them signed, and all the work that comes along with that all take time away from actually getting the next version out the door, thus making us farther from the actual desired outcome, rather than closer. Doing an almost-exactly-the-same rebuild is not merely pointless, it is actively harmful. > >> Well the FTB from people pushing builds would be directly due to the > >> fact they're not on the ACL for the secure-boot, there is a handful > >> of packages like that. > > > > So the people who has the rights should start actually doing it, > > shouldn't they. This particular maintainer ignores all bugzilla > > e-mail. > > If I'm reading the policy correctly, the reason it's being considered > for retirement is that the bug was ASSIGNED. If it were still in NEW, > it would be merely orphaned. Three mutually painful policies being applied as a method of *not* listening to a maintainer is not my idea of a good time. It's pretty much the opposite of motivating. -- 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
Re: List of long term FTBFS packages to be retired in February
On Mon, Jan 6, 2020 at 4:58 PM Peter Jones wrote: > > On Mon, Jan 06, 2020 at 12:54:58PM +0100, Miro Hrončok wrote: > > > Regardless of different opinions about aggressiveness, having policies > > and no enforcement makes no sense. Either the polices are too > > aggressive and we need to change them, or they are not and we need to > > enforce them. > > That seems like a rather poor way to think about policy in general, and > I have some disagreements with it in this specific case as well. In > general, you're not considering that it may be worth having policies > reflect our *ideal* situation, and acknowledge that they don't always > fit the real world precisely. > I agree with both of you here. I'm a big believer in the "don't have rules you're not willing to enforce" philosophy, but I also think "zero tolerance" is a bad approach to things. The challenge we face here in particular is how to strike the right balance. Strict enforcement is the easiest to scale because it can be largely automated. The problem is that we run into these non-ideal cases and don't have a good way to handle them. A more hands-on approach would be better, if we had a person whose full time job was to go through the output and identify what is and is not appropriate to remove. Everyone here is acting in what they see as the best interests of the community. On Mon, Jan 6, 2020 at 6:34 AM Miro Hrončok wrote: > > This is part of the policy to prevent maintainers form simply ASSIGNING bugs > forever without fixing anything. > How much of this is a response to an actual problem versus a preemptive prevention of an anticipated problem? If we were to allow maintainers to set bugs to ASSIGNED forever, is the actual end result something we could live with? (Perhaps with an exception for security bugs) Similarly, to Peter: how would you suggest we special-case these three packages (and others like them) so that we know to always exclude them from the mass rebuild (except when explicitly requested) and exempt them from the automated FTBFS queries? -- Ben Cotton He / Him / His Fedora Program Manager 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: List of long term FTBFS packages to be retired in February
On Mon, Jan 06, 2020 at 04:57:16PM -0500, Peter Jones wrote: > > Regardless of different opinions about aggressiveness, having policies > > and no enforcement makes no sense. Either the polices are too > > aggressive and we need to change them, or they are not and we need to > > enforce them. > That seems like a rather poor way to think about policy in general, and > I have some disagreements with it in this specific case as well. In > general, you're not considering that it may be worth having policies > reflect our *ideal* situation, and acknowledge that they don't always > fit the real world precisely. That last thing seems _very_ "Fedora" to me. Be human-driven rather than rules-driven. But I also do understand the desire for clarity and enforcement. Keeping quality high by sticking to the rules is also very much in the Fedora Project nature. Especially because we have a lot of people from different cultures, backgrounds, languages, and ways of thinking, a universal balance is impossible and just expecting people to understand one seems like a recipe for this kind of conflict. So, I think perhaps explicitly changing the policy to be a little more humane _is_ the best course. I got a complaint about a notice sent on Christmas -- I know not everyone celebrates that (and for some of us, hey, time off to do Fedora stuff!), but I think it wouldn't hurt to have some wording requesting people enforcing the policy to remember the humans on the other end. -- 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
Re: List of long term FTBFS packages to be retired in February
Am 06.01.20 um 20:48 schrieb Robbie Harwood: To actually get removed from your package in Fedora typically takes at least three months during which you have to be mostly non-responsive. I only package a few things in Fedora, but it's far more frustrating to me as a maintainer when a non-responsive maintainer (of a dependent/depending package) won't fix their bugs than when I occasionally have to do a build. +1 I did vent my frustration about non-reacting maintainers and out-of-date packages last year. We should not try to papering over problems with too few maintainers and too complicated contribution processes by just pretending ancient builds will "just work". Felix ___ 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: List of long term FTBFS packages to be retired in February
On Mon, Jan 06, 2020 at 12:54:58PM +0100, Miro Hrončok wrote: > Regardless of different opinions about aggressiveness, having policies > and no enforcement makes no sense. Either the polices are too > aggressive and we need to change them, or they are not and we need to > enforce them. That seems like a rather poor way to think about policy in general, and I have some disagreements with it in this specific case as well. In general, you're not considering that it may be worth having policies reflect our *ideal* situation, and acknowledge that they don't always fit the real world precisely. I think that's a thing we need to consider, because both the mass rebuild policy, and the crusade you're on to use it to drive your use of the FTBFS policy. In both cases the intent of the policy is clearly good, but the way you're trying to handle enforcement has aggravated quite a few people - I think I've witnessed at least 3 people tell you this in general, and two of us have (more than once) about this specific case. > What you seem to ask is to stop enforcing policies, and I must > disagree with that. I don't think this is in any way a reasonable conclusion *or* a reasonable response. Nobody said "we should never enforce any policies", or even anything you might reasonably confuse for that. There aren't very many things that are good "one size fits all" policies with something as complex as a linux distro, and those are mostly very, very core things, like "the stuff in your package has got to be open source". Most things, we can only make the policy fit everything so well, and try to make it fit better when we can, and enforce it to the appropriate extent. But instead, you're talking about policy enforcement as if we should send people to jail if they accidentally drop a candy wrapper when they're putting it in their pocket to throw away later. > Note that IMHO it's mostly Red Hat employees that are "forced" to fix their > packages by enforcing the polcies, not community members. The community > packagers either care about their packages and they fix them in timely > manner, or they are already gone. But I have no data to back this up, so > feel free to disagree there. The insinuation that Red Hat employees, including me, don't care about what we're working on is pretty seriously insulting. > > > Also said in the e-mail, if you think those packages need to be > > > exempted from the process, we can deal with that to, however there > > > must be a valid reason. I don't think "the maintainer didn't > > > actually maintain their Fedora packages for almost 2 years because > > > they have real stuff to do" is a valid reason, yet other FESCo > > > members might disagree with that statement. > > > > Well the FTB from people pushing builds would be directly due to the > > fact they're not on the ACL for the secure-boot, there is a handful > > of packages like that. > > So the people who has the rights should start actually doing it, > shouldn't they. Again with the insulting insinuations. Have you at all considered that *not* rebuilding a package might be the correct action? Have you considered that when I say not to include shim-unsigned-aarch64, shim-unsigned-x64, and shim in the mass rebuilds, since that will not and *can not* ever produce the desired result, and in fact can *only* result in more work that's *completely pointless*, I'm actually not just being hopelessly lazy? > This particular maintainer ignores all bugzilla e-mail. You appear to believe bugzilla is a good way to have any conversation with any maintainer. It isn't. It's an archive for reporting bugs, and treating it as a notification queue won't ever be a good interaction for everyone. From my perspective, you are abusing bugzilla in an overzealous attempt to enforce a policy that you hold as absolute, but which does not fit the situation at hand well *at all*, and mostly just generates extra work *on top of* the noise the mass rebuild generated, and you're insulting people when they tell you that. Please stop. > > Well FESCo might agree that they want booting x86 images with > > secure-boot so ¯\_(ツ)_/¯ > > Sure, let's build our policies around that. What about the following: > > "If you maintain a critpath package, you don't need to to do anything, > because it will never be removed so ¯\_(ツ)_/¯" I realize Peter was sarcastic in his response to you, but replying with *ridicule* when others disagree with you is not respectful or considerate, which are the two main requirements of Fedora's code of conduct. If you want to talk even more about the actual details of what the plan going forward for these two packages (really three, but whatever) is, and try to understand why I want you to stop, we can. You don't seem to want to, though. -- Peter ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code
Big change to free maxmind GeoLite2 databases, limiting distribution
I see that currently Fedora rawhide gets new geolite2-*-YYYMMDD packages (e.g. geolite2-city-20191217) each month in order to distribute the free maxmind geo IP databases. Unfortunately, Maxmind just greatly tightened down on the license for these data distributions and I think that Fedora will no longer be able to distribute them. The databases may still be downloaded for free, and they may be freely redistributed, but anybody who does so must ensure that everybody that they distribute to updates their database within 30 days after Maxmind updates them, and destroys all old copies. Here's the blog entry where they announced the change, late in December, effective the end of 2019, saying that they had to do it because of privacy laws: https://blog.maxmind.com/2019/12/18/significant-changes-to-accessing-and-using-geolite2-databases/ Anybody may sign up for an account and free license key, but they have to agree to The new End User License Agreement with the new stipulations. https://www.maxmind.com/en/geolite2/eula I welcome any suggestions for good alternative sources of geo IP data that doesn't have these kinds of restrictions and also believes they can adhere to the privacy laws without requiring a license key. Dave ___ 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: Self Introduction: Breno B. Fernandes
On Mon, Jan 06, 2020 at 04:22:57PM -0500, Breno Brand Fernandes wrote: > I expect to consistently contribute to the Fedora community. > It is very nice to get to know such a community with so many brilliant > people. Hi Breno! Welcome to Fedora! -- 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
Self Introduction: Breno B. Fernandes
Hi all, I am ~33 years old and I've been using (and working with?) Linux since I was 16-ish. I've been using Centos/RedHat/Fedora for a while and am now interested in getting more involved. I talk to some of you at #epel@freenode. People are always very helpful and friendly. I expect to consistently contribute to the Fedora community. It is very nice to get to know such a community with so many brilliant people. - Breno ___ 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 32 System-Wide Change proposal (late): Enable EarlyOOM
On Mon, Jan 6, 2020 at 7:09 pm, Lennart Poettering
wrote:
- facebook is working on making oomd something that just works for
everyone, they are in the final rounds of canonicalizing the
configuration so that it can just work for all workloads without
tuning. The last bits for this to be deployable are currently being
done on the kernel side ("iocost"), when that's in, they'll submit
oomd (or simplified parts of it) to systemd, so that it's just there
and works. It's their expressive intention to make this something
that also works for desktop stuff and requires no further
tuning. they also will do the systemd work necessary. time frame:
half a year, maybe one year, but no guarantees.
Asking around, I understand oomd only operates at the cgroup level,
i.e. it kills an entire cgroup at once, not individual processes. So I
understand this would also depend on GNOME-level work to ensure
individual applications get launched in their own systemd scopes, yes?
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 32 System-Wide Change proposal (late): Enable EarlyOOM
On Mon, Jan 6, 2020 at 1:14 PM Robbie Harwood wrote: > > Chris Murphy writes: > > As for swap size options including no swap, and maybe swap-on-ZRAM: > > https://pagure.io/fedora-workstation/issue/120 > > https://bugzilla.redhat.com/show_bug.cgi?id=1731978 > > > > There are all kinds of useful and necessary discussions to have there > > (rather than here). > > The links are appreciated; I was not aware of these discussions and will > follow them. However, since we're discussing behavior of the system > under heavy load, I think how we handle swap (the thing that makes it > slow down when you're low on memory...) is extremely relevant. It's perhaps the most relevant thing, it's what's to be avoided because it causes the responsiveness problem in the first place. I just meant in terms of this feature proposal, there are no swap changes. And what to change is elsewhere, and elsewhen. :D -- 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 32 System-Wide Change proposal (late): Enable EarlyOOM
Chris Murphy writes: > Robbie Harwood wrote: >> "John M. Harris Jr" writes: >>> On Friday, January 3, 2020 1:51:00 PM MST Robbie Harwood wrote: Robbie Harwood writes: > Ben Cotton writes: > >> https://fedoraproject.org/wiki/Changes/EnableEarlyoom >> >> == Summary == >> Install earlyoom package, and enable it by default. This will cause >> the kernel oomkiller to trigger sooner, but will not affect which >> process it chooses to kill off. The idea is to recover from out of >> memory situations sooner, rather than the typical complete system hang >> in which the user has no other choice but to force power off. >> >> # enable earlyoom by default on workstation >> enable earlyoom.service >> > > The OOM killer is a kernel function. I have no opinion on this proposal > as it stands, but I would like it to include an explanation of why this > requires a service in userspace to fix. Another thought. Wouldn't some of the pain here be alleviated by setting vm.swappiness=0? Currently it seems to be 60, which results in somewhat aggressive swap use; 1 seems better (minimal swapping without disabling), while 0 will disable it for general use (while preserving it for hibernation). This would at least improve the disk thrashing during OOM situations. >>> >>> To clarify, according to the Workstation group, hibernation isn't even >>> supported. >> >> If that's true - and I don't know how I'd check it, so I didn't - we >> should revisit enabling swap in the default install, and *definitely* >> should remove the warning for not having it from anaconda. > > It's not correct that the Workstation working group doesn't want to > see it supported, it's a question of whether and to what degree it can > be supported, and making sure users have expectations proper set. I > wouldn't want users thinking it'll work by advertising that it does, > and then it eats their data. I think enabling it by default very strongly suggests it's supported, regardless of what the intentions are. I have no quarrel with the kernel team in either direction they wish to decide (supported or non), but if it's non-supported, it shouldn't look like it's supported. > As for swap size options including no swap, and maybe swap-on-ZRAM: > https://pagure.io/fedora-workstation/issue/120 > https://bugzilla.redhat.com/show_bug.cgi?id=1731978 > > There are all kinds of useful and necessary discussions to have there > (rather than here). The links are appreciated; I was not aware of these discussions and will follow them. However, since we're discussing behavior of the system under heavy load, I think how we handle swap (the thing that makes it slow down when you're low on memory...) is extremely relevant. 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: List of long term FTBFS packages to be retired in February
On Mon, 2020-01-06 at 14:48 -0500, Robbie Harwood wrote: > Miro Hrončok writes: > > > On 06. 01. 20 12:44, Peter Robinson wrote: > > > > > > As said in the e-mail, if you think the policy needs to be adapted, > > > > please discuss - I have made sure the recent changes in the policy > > > > are discussed with the community, especially since you were so angry > > > > when I followed the previous one. Unfortunately, there was no input > > > > from you when the policy was discussed, despite me repeatedly asking > > > > you to stop being angry at me and participate in the policy > > > > discussion instead. > > > > > > What recent discussions, I've not actually looked at a lot of Fedora > > > related stuff much since August because of constant travel and things > > > related directly to my $dayjob so I likely missed any of the > > > discussion if it's happened since then. > > > > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/thread/NKFYAWL4GWYR37C6XA63JMNBZYEM6BI3/ > > > > > Angry, I wasn't angry, annoyed certainly. It does annoy me that we're > > > driving away packagers that have a little time here and there with > > > these policies, I feel we have too few contributors already and > > > aggressive policies and enforcement only make it worse. > > > > That's exactly why I want the policies less aggressive. A year + long > > FTBFS isn't aggressive in my POV. > > If you don't have the time to make a new build once every year, you > shouldn't be a packager, full stop. If this is too arduous a > requirement, I recommend getting involved with the efforts to improve > the packaging workflow. We are talking about crypto-related packages > here; being able to rebuild them and be confident in their contents is > arguably more important than any other kind of package. Anecdotally, > I've sent two non-responsive maintainer emails (both involving CVEs > which were fixed as a result). We're kind of litigating a Red Hat staffing issue as a Fedora policy argument here, aren't we? I mean, yes, obviously, we can't realistically remove shim from the distro (for a start it would mean we'd be violating our own release criteria, as those require boot on Secure Boot-enabled systems to work). But at the same time, it's pretty hard to argue that pjones is a sufficiently active maintainer of the things he's supposed to be maintaining. This is for perfectly good reasons, but that doesn't stop it being a problem. For me the obvious solution to this is: RH needs to hire someone to deal with the dull stuff pjones doesn't have time for. (That person needs to be trusted by all relevant entities for Secure Boot purposes too, I guess, which might make it slightly trickier, but still doesn't seem like an insuperable problem). -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://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 32 System-Wide Change proposal (late): Enable EarlyOOM
On Mon, Jan 6, 2020 at 12:11 PM Robbie Harwood wrote: > > "John M. Harris Jr" writes: > > > On Friday, January 3, 2020 1:51:00 PM MST Robbie Harwood wrote: > >> Robbie Harwood writes: > >>> Ben Cotton writes: > >>> > https://fedoraproject.org/wiki/Changes/EnableEarlyoom > > == Summary == > Install earlyoom package, and enable it by default. This will cause > the kernel oomkiller to trigger sooner, but will not affect which > process it chooses to kill off. The idea is to recover from out of > memory situations sooner, rather than the typical complete system hang > in which the user has no other choice but to force power off. > > # enable earlyoom by default on workstation > enable earlyoom.service > > >>> > >>> The OOM killer is a kernel function. I have no opinion on this proposal > >>> as it stands, but I would like it to include an explanation of why this > >>> requires a service in userspace to fix. > >> > >> Another thought. Wouldn't some of the pain here be alleviated by > >> setting vm.swappiness=0? Currently it seems to be 60, which results > >> in somewhat aggressive swap use; 1 seems better (minimal swapping > >> without disabling), while 0 will disable it for general use (while > >> preserving it for hibernation). This would at least improve the disk > >> thrashing during OOM situations. > > > > To clarify, according to the Workstation group, hibernation isn't even > > supported. > > If that's true - and I don't know how I'd check it, so I didn't - we > should revisit enabling swap in the default install, and *definitely* > should remove the warning for not having it from anaconda. It's not correct that the Workstation working group doesn't want to see it supported, it's a question of whether and to what degree it can be supported, and making sure users have expectations proper set. I wouldn't want users thinking it'll work by advertising that it does, and then it eats their data. Does the hardware support it? Does the hardware properly advertise what it does support? What mechanisms are needed in the kernel and systemd to support it, and what to do when there are bugs that break it? It's not practical for the Fedora kernel team to become responsible for supporting it when it breaks, nor is it practical to block the release on such bugs. The most recent topic I found on this: Disabling kernel's hibernate support by default, allow re-enabling it with a kernel cmdline option https://lists.fedoraproject.org/archives/list/ker...@lists.fedoraproject.org/message/TLTA6HAYJWQYHV3ZHFXUIXM4IJVWBEJJ/ As for swap size options including no swap, and maybe swap-on-ZRAM: https://pagure.io/fedora-workstation/issue/120 https://bugzilla.redhat.com/show_bug.cgi?id=1731978 There are all kinds of useful and necessary discussions to have there (rather than here). -- 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 32 System-Wide Change proposal (late): Enable EarlyOOM
On 2020-01-06 18:31, Kamil Paral wrote: FWIW, the behavior on Android is very close to what is proposed here. If your application exceeds the amount of available memory, it simply closes right in front of your eyes. No explanation, nothing, it's just gone (might be different on latest Android versions). The same thing would happen with EarlyOOM - some application would disappear. The analogy is not completely fair. On Android applications are designed to be Started and Stopped by the system, and they are supposed to save their entire state so that when restarted nothing has apparently happened, from the point of view of the user. (many applications are badly written, but that's another story...) And we are talking about background applications, on a system where only one application is in foreground (only very recently you can have two applications in foreground). Finally, it is the applications that are stopped (by asking them nicely trough an event), not general system processes; Android would never kill a wpa_supplicant process, for example. Android has a concept of "cache" of background applications, they are there, if possible, just to have them back very quickly; it is similar to how Linux keeps dirty disk content in RAM and pushes it to disk when RAM must be freed. Regards. -- Roberto Ragusamail at robertoragusa.it ___ 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: List of long term FTBFS packages to be retired in February
Miro Hrončok writes: > On 06. 01. 20 12:44, Peter Robinson wrote: > >>> As said in the e-mail, if you think the policy needs to be adapted, >>> please discuss - I have made sure the recent changes in the policy >>> are discussed with the community, especially since you were so angry >>> when I followed the previous one. Unfortunately, there was no input >>> from you when the policy was discussed, despite me repeatedly asking >>> you to stop being angry at me and participate in the policy >>> discussion instead. >> >> What recent discussions, I've not actually looked at a lot of Fedora >> related stuff much since August because of constant travel and things >> related directly to my $dayjob so I likely missed any of the >> discussion if it's happened since then. > > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/thread/NKFYAWL4GWYR37C6XA63JMNBZYEM6BI3/ > >> Angry, I wasn't angry, annoyed certainly. It does annoy me that we're >> driving away packagers that have a little time here and there with >> these policies, I feel we have too few contributors already and >> aggressive policies and enforcement only make it worse. > > That's exactly why I want the policies less aggressive. A year + long > FTBFS isn't aggressive in my POV. If you don't have the time to make a new build once every year, you shouldn't be a packager, full stop. If this is too arduous a requirement, I recommend getting involved with the efforts to improve the packaging workflow. We are talking about crypto-related packages here; being able to rebuild them and be confident in their contents is arguably more important than any other kind of package. Anecdotally, I've sent two non-responsive maintainer emails (both involving CVEs which were fixed as a result). To actually get removed from your package in Fedora typically takes at least three months during which you have to be mostly non-responsive. I only package a few things in Fedora, but it's far more frustrating to me as a maintainer when a non-responsive maintainer (of a dependent/depending package) won't fix their bugs than when I occasionally have to do a build. >>> Also said in the e-mail, if you think those packages need to be >>> exempted from the process, we can deal with that to, however there >>> must be a valid reason. I don't think "the maintainer didn't >>> actually maintain their Fedora packages for almost 2 years because >>> they have real stuff to do" is a valid reason, yet other FESCo >>> members might disagree with that statement. >> >> Well the FTB from people pushing builds would be directly due to the >> fact they're not on the ACL for the secure-boot, there is a handful >> of packages like that. > > So the people who has the rights should start actually doing it, > shouldn't they. This particular maintainer ignores all bugzilla > e-mail. If I'm reading the policy correctly, the reason it's being considered for retirement is that the bug was ASSIGNED. If it were still in NEW, it would be merely orphaned. I'm sure we have people who could step in and fix this if all indications didn't point to the maintainers wanting to fix it themselves (and the ACL didn't prevent them from doing so, though I'm not against the ACL). >> Well FESCo might agree that they want booting x86 images with >> secure-boot so ¯\_(ツ)_/¯ Let's try to keep the conversation civil, please. That said: if policy says we need to retire this package now, and it will break the world, perhaps fesco *ought* to be involved? 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 32 System-Wide Change proposal (late): Enable EarlyOOM
On Mon, Jan 6, 2020 at 11:53 am, Chris Murphy wrote: And yes the idea is to go a little faster. Earlyoom is easy to take out. And I have no problem with it coming out in fc33 if oomd or (more likely) lmm are ready by then. Brainstorming: if a systemd-level solution were to be ready in the F33 or F34 timeframe, I'd be OK with just waiting for that. We've had 31 Fedora releases without earlyoom and one or two more isn't the end of the world. Seems easier than installing earlyoom on everybody's computers and then calling "backsies!" a year later. Of course we would need to monitor progress at the systemd level to make sure this solution is advancing as desired, and fall back to plans for earlyoom if things get off track. 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
Fedora 33 Self-Contained Change proposal: retire python34
https://fedoraproject.org/wiki/Changes/RetirePython34
== Summary ==
The {{package|python34}} package will be retired without replacement
from [[Releases/33|Fedora 33]]. Python 3.4 has been End of Life since
March 2019 and was kept around only to test software targeting EPEL 6
and Debian 8 “Jessie”. The removal is aligned with EPEL 6 EOL and
happens after the EOL of Debian 8.
== Owner ==
* Name: [[User:Churchyard|Miro Hrončok]]
* Email: mhron...@redhat.com
== Detailed Description ==
The {{package|python34}} package with the Python interpreter in
version 3.4 is kept in Fedora only to make it possible for Fedora
users to test their software against the Python version shipped in
EPEL 6 and EPEL 7. RHEL 7 now contains Python 3.6.
[https://wiki.debian.org/LTS Debian 8 “Jessie” is End of Life in
2020-06]. [[EPEL|The EPEL 6 End of Life is planned for 2020-11]]. This
roughly corresponds with the
[https://fedorapeople.org/groups/schedule/f-33/f-33-key-tasks.html
Fedora 33 release date]. Hence, we decided to retire (completely
remove) {{package|python34}} from Fedora 33, before it gets released.
== Benefit to Fedora ==
The maintenance of Python 3.4 was getting harder and harder every
year. The support for Python 3.4 has disappeared from pip and an older
version of pip has to be bundled in {{package|python34}}, while pip
bundles even more old libraries. Support from tox and virtualenv will
eventually disappear as well.
There is no direct benefit here, except that we don't want to maintain
it anymore and we don't think it's a good idea either.
Consider this change proposal a louder orphaning, except that we will
continue to maintain the package in older released and supported
Fedoras (31 and 32). If you wish to continue maintaining Python 3.4 in
Fedora, please [[SIGs/Python|speak to us]] first.
== Scope ==
* Proposal owners: Retire {{package|python34}}. Obsolete it from
{{package|fedora-obsolete-packages}} if it causes troubles on
upgrades. Make sure no Fedora package depends on it in any way (incl.
weak dependencies).
* Other developers: N/A (not a System Wide Change)
* Release engineering: N/A (not a System Wide Change)
* Policies and guidelines: N/A (not a System Wide Change)
* Trademark approval: N/A (not needed for this Change)
== Upgrade/compatibility impact ==
The package will no longer be available from the repositories, but it
may remain on existing installations. If it causes troubles on
upgrade, it needs to be obsoleted.
== How To Test ==
N/A (not a System Wide Change)
== User Experience ==
No more Python 3.4 to test user software on.
== Dependencies ==
N/A (not a System Wide Change)
== Contingency Plan ==
* Contingency mechanism: (What to do? Who will do it?) N/A (not a
System Wide Change)
* Contingency deadline: N/A (not a System Wide Change)
* Blocks release? N/A (not a System Wide Change)
== Documentation ==
N/A (not a System Wide Change)
--
Ben Cotton
He / Him / His
Fedora Program Manager
Red Hat
TZ=America/Indiana/Indianapolis
___
devel-announce mailing list -- devel-announce@lists.fedoraproject.org
To unsubscribe send an email to devel-announce-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-announce@lists.fedoraproject.org
Fedora 33 Self-Contained Change proposal: retire python34
https://fedoraproject.org/wiki/Changes/RetirePython34
== Summary ==
The {{package|python34}} package will be retired without replacement
from [[Releases/33|Fedora 33]]. Python 3.4 has been End of Life since
March 2019 and was kept around only to test software targeting EPEL 6
and Debian 8 “Jessie”. The removal is aligned with EPEL 6 EOL and
happens after the EOL of Debian 8.
== Owner ==
* Name: [[User:Churchyard|Miro Hrončok]]
* Email: mhron...@redhat.com
== Detailed Description ==
The {{package|python34}} package with the Python interpreter in
version 3.4 is kept in Fedora only to make it possible for Fedora
users to test their software against the Python version shipped in
EPEL 6 and EPEL 7. RHEL 7 now contains Python 3.6.
[https://wiki.debian.org/LTS Debian 8 “Jessie” is End of Life in
2020-06]. [[EPEL|The EPEL 6 End of Life is planned for 2020-11]]. This
roughly corresponds with the
[https://fedorapeople.org/groups/schedule/f-33/f-33-key-tasks.html
Fedora 33 release date]. Hence, we decided to retire (completely
remove) {{package|python34}} from Fedora 33, before it gets released.
== Benefit to Fedora ==
The maintenance of Python 3.4 was getting harder and harder every
year. The support for Python 3.4 has disappeared from pip and an older
version of pip has to be bundled in {{package|python34}}, while pip
bundles even more old libraries. Support from tox and virtualenv will
eventually disappear as well.
There is no direct benefit here, except that we don't want to maintain
it anymore and we don't think it's a good idea either.
Consider this change proposal a louder orphaning, except that we will
continue to maintain the package in older released and supported
Fedoras (31 and 32). If you wish to continue maintaining Python 3.4 in
Fedora, please [[SIGs/Python|speak to us]] first.
== Scope ==
* Proposal owners: Retire {{package|python34}}. Obsolete it from
{{package|fedora-obsolete-packages}} if it causes troubles on
upgrades. Make sure no Fedora package depends on it in any way (incl.
weak dependencies).
* Other developers: N/A (not a System Wide Change)
* Release engineering: N/A (not a System Wide Change)
* Policies and guidelines: N/A (not a System Wide Change)
* Trademark approval: N/A (not needed for this Change)
== Upgrade/compatibility impact ==
The package will no longer be available from the repositories, but it
may remain on existing installations. If it causes troubles on
upgrade, it needs to be obsoleted.
== How To Test ==
N/A (not a System Wide Change)
== User Experience ==
No more Python 3.4 to test user software on.
== Dependencies ==
N/A (not a System Wide Change)
== Contingency Plan ==
* Contingency mechanism: (What to do? Who will do it?) N/A (not a
System Wide Change)
* Contingency deadline: N/A (not a System Wide Change)
* Blocks release? N/A (not a System Wide Change)
== Documentation ==
N/A (not a System Wide Change)
--
Ben Cotton
He / Him / His
Fedora Program Manager
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 33 Self-Contained Change proposal: retire python26
https://fedoraproject.org/wiki/Changes/RetirePython26
== Summary ==
The {{package|python26}} package will be retired without replacement
from [[Releases/33|Fedora 33]]. Python 2.6 has been End of Life since
October 2013 and was kept around only to test software targeting
RHEL/EPEL 6. The removal is aligned with EPEL 6 EOL.
== Owner ==
* Name: [[User:Churchyard|Miro Hrončok]]
* Email: mhron...@redhat.com
== Detailed Description ==
The {{package|python26}} package with the Python interpreter in
version 2.6 is kept in Fedora only to make it possible for Fedora
users to test their software against the Python version shipped in
RHEL 6.
[[EPEL|The EPEL 6 End of Life is planned for 2020-11]]. This roughly
corresponds with the
[https://fedorapeople.org/groups/schedule/f-33/f-33-key-tasks.html
Fedora 33 release date]. Hence, we decided to retire (completely
remove) {{package|python26}} from Fedora 33, before it gets released.
== Benefit to Fedora ==
The maintenance of Python 2.6 was getting harder and harder every
year. The support for Python 2.6 has disappeared from virtualenv, tox.
{{package|python26}} cannot be built against the new OpenSSL versions,
etc.
There is no direct benefit here, except that we don't want to maintain
it anymore and we don't think it's a good idea either.
Consider this change proposal a louder orphaning, except that we will
continue to maintain the package in older released and supported
Fedoras (31 and 32). If you wish to continue maintaining Python 2.6 in
Fedora, please [[SIGs/Python|speak to us]] first.
== Scope ==
* Proposal owners: Retire {{package|python26}}. Obsolete it from
{{package|fedora-obsolete-packages}} if it causes troubles on
upgrades. Make sure no Fedora package depends on it in any way (incl.
weak dependencies).
* Other developers: N/A (not a System Wide Change)
* Release engineering: N/A (not a System Wide Change)
* Policies and guidelines: N/A (not a System Wide Change)
* Trademark approval: N/A (not needed for this Change)
== Upgrade/compatibility impact ==
The package will no longer be available from the repositories, but it
may remain on existing installations. If it causes troubles on
upgrade, it needs to be obsoleted.
== How To Test ==
N/A (not a System Wide Change)
== User Experience ==
No more Python 2.6 to test user software on.
== Dependencies ==
N/A (not a System Wide Change)
== Contingency Plan ==
* Contingency mechanism: (What to do? Who will do it?) N/A (not a
System Wide Change)
* Contingency deadline: N/A (not a System Wide Change)
* Blocks release? N/A (not a System Wide Change)
== Documentation ==
N/A
--
Ben Cotton
He / Him / His
Fedora Program Manager
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 32 System-Wide Change proposal (late): Enable EarlyOOM
"John M. Harris Jr" writes: > On Friday, January 3, 2020 1:51:00 PM MST Robbie Harwood wrote: >> Robbie Harwood writes: >>> Ben Cotton writes: >>> https://fedoraproject.org/wiki/Changes/EnableEarlyoom == Summary == Install earlyoom package, and enable it by default. This will cause the kernel oomkiller to trigger sooner, but will not affect which process it chooses to kill off. The idea is to recover from out of memory situations sooner, rather than the typical complete system hang in which the user has no other choice but to force power off. # enable earlyoom by default on workstation enable earlyoom.service >>> >>> The OOM killer is a kernel function. I have no opinion on this proposal >>> as it stands, but I would like it to include an explanation of why this >>> requires a service in userspace to fix. >> >> Another thought. Wouldn't some of the pain here be alleviated by >> setting vm.swappiness=0? Currently it seems to be 60, which results >> in somewhat aggressive swap use; 1 seems better (minimal swapping >> without disabling), while 0 will disable it for general use (while >> preserving it for hibernation). This would at least improve the disk >> thrashing during OOM situations. > > To clarify, according to the Workstation group, hibernation isn't even > supported. If that's true - and I don't know how I'd check it, so I didn't - we should revisit enabling swap in the default install, and *definitely* should remove the warning for not having it from anaconda. 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 32 System-Wide Change proposal (late): Enable EarlyOOM
On Mon, Jan 6, 2020 at 11:09 AM Lennart Poettering wrote:
>
> On Mo, 06.01.20 11:22, Michael Catanzaro (mcatanz...@gnome.org) wrote:
>
> So I talked to Tejun Heo about this (kernel cgroups maintainer,
> working for facebook with the people who did the PSI stuff, kernel mm
> guy). Here's the gist:
>
> - earlyoom might be OK as short time stopgap if people really want to
> hurry something, as long as it watches only swap depletion (which it
> pretty much does already). But it should then also determine what
> to kill taking the swap use into account and little else (which it
> apparently does not). This doesn't make any sense to have though if
> there is no swap.
>
> - Don't bother with the OOM score the kernel calculates for processes,
> it doesn't take the swap use into account. That said, do take the
> configurable OOM score *adjustment* into account, so that processes
> which set that are respected, i.e. journald, udevd, and such. (or in
> otherwords, ignore /proc/$PID/oom_score, but respect
> /proc/PID/oom_score_adj).
>
> - going down to 100ms poll intervals is a bad idea, 1s is sufficient,
> maybe higher.
>
> - facebook is working on making oomd something that just works for
> everyone, they are in the final rounds of canonicalizing the
> configuration so that it can just work for all workloads without
> tuning. The last bits for this to be deployable are currently being
> done on the kernel side ("iocost"), when that's in, they'll submit
> oomd (or simplified parts of it) to systemd, so that it's just there
> and works. It's their expressive intention to make this something
> that also works for desktop stuff and requires no further
> tuning. they also will do the systemd work necessary. time frame:
> half a year, maybe one year, but no guarantees.
>
> - oomd currently polls some parameters in time intervals too,
> still. They are working on getting rid of that too, so that
> everything is event based via PSI. Given their own focus on servers
> it's not a primary goal, but still a goal.
>
> Or in other words: oomd is the way to go in the long run, developed
> alongside the kernel features backing it. You can use it already if
> you like, but there are still too many knobs for generic
> deployment. earlyoom might be a valid temporary stopgap if you want to
> hurry this.
>
> (And now I hope I paraphrased everything he said more or less
> correctly...)
Thanks for all of that, and it's consistent with the research and
discussion the working group have done in the past 6 months on this
subject. What I can't estimate is whether oomd or lmm will be better
long term for Fedora Workstation, or if there's an advantage of them
co-existing.
And yes the idea is to go a little faster. Earlyoom is easy to take
out. And I have no problem with it coming out in fc33 if oomd or (more
likely) lmm are ready by then.
--
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 32 system-wide change proposal: reduce installation media size by improving the compression ratio of SquashFS filesystem
On Sun, Jan 5, 2020 at 1:24 PM Bohdan Khomutskyi wrote: > Summary > > Improve compression ratio of SquashFS filesystem on the installation media. > Hi Bohdan, as a member of QA, I'll happily support any proposal that improves the installation speed (the image size is not that important from my POV). Chris found that dropping the nested ext4 filesystem can get us substantial gains in this area, as well as changing xz to zstd. I see he already provided you with links to the respective tickets. Perhaps you can work with him to make this change a reality (and benefit in both areas - speed and size)? QA would really appreciate it :-) Thanks! Kamil ___ 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 32 System-Wide Change proposal (late): Enable EarlyOOM
On Mon, Jan 6, 2020 at 7:10 PM Lennart Poettering wrote: > - going down to 100ms poll intervals is a bad idea, 1s is sufficient, > maybe higher. > According to the project readme, the query interval is 100ms only if the lack or free RAM starts to get severe. Otherwise the interval is claimed to be longer. I haven't checked the code, though. ___ 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 32 System-Wide Change proposal (late): Enable EarlyOOM
On Mo, 06.01.20 11:22, Michael Catanzaro (mcatanz...@gnome.org) wrote:
So I talked to Tejun Heo about this (kernel cgroups maintainer,
working for facebook with the people who did the PSI stuff, kernel mm
guy). Here's the gist:
- earlyoom might be OK as short time stopgap if people really want to
hurry something, as long as it watches only swap depletion (which it
pretty much does already). But it should then also determine what
to kill taking the swap use into account and little else (which it
apparently does not). This doesn't make any sense to have though if
there is no swap.
- Don't bother with the OOM score the kernel calculates for processes,
it doesn't take the swap use into account. That said, do take the
configurable OOM score *adjustment* into account, so that processes
which set that are respected, i.e. journald, udevd, and such. (or in
otherwords, ignore /proc/$PID/oom_score, but respect
/proc/PID/oom_score_adj).
- going down to 100ms poll intervals is a bad idea, 1s is sufficient,
maybe higher.
- facebook is working on making oomd something that just works for
everyone, they are in the final rounds of canonicalizing the
configuration so that it can just work for all workloads without
tuning. The last bits for this to be deployable are currently being
done on the kernel side ("iocost"), when that's in, they'll submit
oomd (or simplified parts of it) to systemd, so that it's just there
and works. It's their expressive intention to make this something
that also works for desktop stuff and requires no further
tuning. they also will do the systemd work necessary. time frame:
half a year, maybe one year, but no guarantees.
- oomd currently polls some parameters in time intervals too,
still. They are working on getting rid of that too, so that
everything is event based via PSI. Given their own focus on servers
it's not a primary goal, but still a goal.
Or in other words: oomd is the way to go in the long run, developed
alongside the kernel features backing it. You can use it already if
you like, but there are still too many knobs for generic
deployment. earlyoom might be a valid temporary stopgap if you want to
hurry this.
(And now I hope I paraphrased everything he said more or less
correctly...)
if you want to know more about fb's oomd:
https://cfp.all-systems-go.io/ASG2019/talk/DQX3DH/
(but before this will enter systemd it's gonna be dumbed down, i.e,
less configuration, more "just works")
Lennart
--
Lennart Poettering, Berlin
___
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: Let's talk about Fedora in the '20s!
Le 2020-01-06 19:05, Nicolas Mailhot a écrit : Handling those checks is where the packaging toil is (that is, as long as Fedora is a deployment project). It is not something the packaging format makes harder. However, because our packaging format streamlines those checks, and forces to apply them, it is blamed by devs for the impedance mismatch between dev and deployment requirements. But, this mismatch is not caused by our packaging format. It is caused by devs taking shortcuts because their language packaging format lets them. -- Nicolas Mailhot ___ 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
poppler soname bump in rawhide
Hi, I'm going to rebase poppler in rawhide to poppler-0.84.0 at the beginning of next week. There are several API changes and soname bump of the base library libpoppler.so.*. Here is scratch-build of poppler-0.84.0: https://koji.fedoraproject.org/koji/taskinfo?taskID=40194709 Btw, if your package uses the unstable API (headers from poppler-devel), could you consider to change it to use a stable API (glib, qt, C++)? Also, if your package still uses qt4 frontend, try to use another one since this was removed in upstream and we have it just as a backup solution for the time being (and its maintaining costs time). I'll backport/fix simple issues in the dependent packages and rebuild them together with the rebase (e.g. the one with GlobalParams being unique ptr now). Regards Marek ___ 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: Let's talk about Fedora in the '20s!
Le 2020-01-06 18:19, Matthew Miller a écrit : Hi, Second, we need to figure out how to work with language-native packaging formats and more directly with code that's distributed in git repos rather than as tarball releases. We're not adding meaningful end-user value by manually repackaging these in our own format. It would be nice if it were the case but that’s a completely false assertion. Re-packaging in our own format is not an horrible toil because our own format is horrible. It’s an horrible toil because our own format is old and mature, and language native formats are not. They lack all kinds of checks. Checks that do not matter in a dev context, but definitely matter in a deployment context. Handling those checks is where the packaging toil is (that is, as long as Fedora is a deployment project). It is not something the packaging format makes harder. However, because out packa -- Nicolas Mailhot ___ 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
Summary/Minutes from today's FESCo Meeting (2020-01-06)
= #fedora-meeting-1: FESCO (2020-01-06) = Meeting started by contyk at 15:00:16 UTC. The full logs are available at https://meetbot.fedoraproject.org/fedora-meeting-1/2020-01-06/fesco.2020-01-06-15.00.log.html Meeting summary --- * init process (contyk, 15:00:34) * #2303 F32 System-Wide Change: Drop Optical Media Release Criterion (contyk, 15:02:22) * LINK: https://pagure.io/fesco/issue/2303#comment-617872 (nirik, 15:04:04) * AGREED: Blocking status remains unchanged, however FESCo no longer requires QA to test and report on physical media as part of the formal release criteria. (+6, 2, -0) (contyk, 15:19:56) * LINK: https://fedoraproject.org/wiki/Releases/31/ReleaseBlocking has the limits (zbyszek, 15:22:10) * Next week's chair (contyk, 15:22:52) * ACTION: contyk will chair the next meeting. (contyk, 15:24:18) * Open Floor (contyk, 15:24:23) * #2310 F32 System-Wide Change: Use update-alternatives for /usr/bin/cc and /usr/bin/c++ (contyk, 15:27:04) * LINK: https://docs.fedoraproject.org/en-US/packaging-guidelines/Alternatives/ (mhroncok, 15:32:08) * AGREED: FESCo will discuss #2310 next week (+8, 0, -0) (contyk, 15:39:02) Meeting ended at 15:47:36 UTC. Action Items * contyk will chair the next meeting. Action Items, by person --- * contyk * contyk will chair the next meeting. People Present (lines said) --- * contyk (59) * mhroncok (44) * sgallagh (39) * dcantrell (28) * zbyszek (25) * nirik (19) * zodbot (18) * frantisekz (10) * ignatenkobrain (9) * smooge (6) * decathorpe (3) * bcotton (2) * bookwar (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: Fedora 32 System-Wide Change proposal (late): Enable EarlyOOM
On Fri, Jan 3, 2020 at 8:20 PM Ben Cotton wrote: > https://fedoraproject.org/wiki/Changes/EnableEarlyoom > > == Summary == > Install earlyoom package, and enable it by default. This will cause > the kernel oomkiller to trigger sooner, but will not affect which > process it chooses to kill off. The idea is to recover from out of > memory situations sooner, rather than the typical complete system hang > in which the user has no other choice but to force power off. > I've read the whole thread (phew!) and I support the proposal. The user experience is improved and I don't see any substantial disadvantages (power management etc can hopefully be fine-tuned). Of course the code should be well inspected by someone knowledgeable, if it's going to run with high privileges. And if there are serious candidates with a better approach (e.g. something from systemd), it might make sense to delay this and wait a while. OTOH, if verifying the code and setting it up is not that much work, those candidates can *replace* early-oom in the future, and no delay is necessary. Overall +1 from me. ___ 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 32 System-Wide Change proposal (late): Enable EarlyOOM
On Sun, Jan 5, 2020 at 12:43 PM Aleksandra Fedorova wrote: > I wonder, how I as a user going to be informed about the > earlyoom-event? I assume abrt will recognize the crash? Will it be > easily visible from the abrt report that it was the OOM? > > The concern is: if we enable such a service, will we get large amount > of vague bug reports from users who don't understand what has > happened. Can we make it somehow easier to debug? > FWIW, the behavior on Android is very close to what is proposed here. If your application exceeds the amount of available memory, it simply closes right in front of your eyes. No explanation, nothing, it's just gone (might be different on latest Android versions). The same thing would happen with EarlyOOM - some application would disappear. I agree it would be nice to inform the user before or at least after. Windows can do it - they show a notification roughly saying "Your system is running out of memory and some application might get closed". (At least they used to in the old days, I haven't run out of memory for a long time, and I don't know whether Windows 10 behaves the same way). But I think it should not be a stopper for the proposal as it is. Even without the notification the user experience is improved over the default behavior. ___ 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 32 System-Wide Change proposal (late): Enable EarlyOOM
On Mon, Jan 6, 2020 at 5:47 pm, Lennart Poettering wrote: Yes, l-m-m is great. If we can deploy l-m-m today already, why isn't it good enoug for earlyoom? GMemoryMonitor is the GLib API that's implemented using low-memory-monitor's D-Bus API. In practice, using it for OOM killing is not that great, though. We've rejected this approach because the OOM killing is causing serious problems and there are no plans to fix it: https://gitlab.freedesktop.org/hadess/low-memory-monitor/issues/8. Therefore most likely we'll use l-m-m only for advisory memory pressure notifications. On Mon, Jan 6, 2020 at 5:47 pm, Lennart Poettering wrote: Sounds like someone needs to do their homework, if this is "unclear"? I mean, you basically admit here that this isn't really figured out to the end. Maybe let's give this a bit more time and figure things out a bit more, instead of rushing earlyoom in? Adopting something now, at a point we already clearly know that PSI is how this should be done sounds very wrong to me. I think it would absolutely be reasonable to defer from F32 -> F33 if we have concrete plans to use that delay to implement an OOM solution. E.g. if you or someone else wanted to throw together a systemd-level solution: Sounds like something that is relatively easily implementable in systemd though, in a much better way, i.e. hooked to PSI... I mean, wouldn't this all be solved much nicer, much more future proof, if someone would just do what l-m-m does as part of systemd service management, i.e. let's say an option StopOnMemoryPressure= that watches PSI and terminates services *cleanly* when needed, i.e. goes through ExecStop= and such? And you know what, PSI is precisely defined to be used for purposes like this, we already have experience with it (see l-m-m) and a patch adding this to systemd isn#t really that hard either... So again, the problem with PSI so far is that we haven't gotten it to work well. If systemd can make it work well, that would be super lovely. Sounds like that would also avoid continuous wakeups, which would be very nice. I don't think anybody would object to a systemd-level solution. If it's part of systemd, there would no longer be concerns about architecture or code quality, and it'd feel much less hackish. We would want to test it to ensure responsiveness is comparable to what earlyoom would offer, of course. 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
Let's talk about Fedora in the '20s!
Hi everyone! Since it's a new year and a new decade [*], it seems like a good time to look forward and talk about what we want the Fedora Project to be in the next five and even ten years. How do we take the awesome foundation we have now and build and grow and make something that continues to thrive and be useful, valuable, and fun? [My thoughts below. Feel free to respond to those, or cut here and start your own!] I see three big themes I think we need to tackle. First, I'd like to see Fedora become more of an "operating system factory". The direction we took with the Fedora Editions has been a success — Fedora's general growth and popularity bears that out. But now it's a good time to re-examine the positioning. The Editions were meant to fit big, broad use-cases defined by (at the time) the Fedora Board and FESCo. Since then, everything's become more complicated, with Atomic and then CoreOS, and IoT, and Silverblue — and we never really found a satisfying way to present the work of our other desktop SIGs. So, I think we should revisit the top-level design for Get Fedora. I'm not a designer and I don't have a particular answer in mind, but I think we should try an approach which showcases all of our different outputs in some way which also makes it easy for new users to find the right solution quickly (and to understand the support options and expecations for their choice). In support of that, I'd like to also have that page steer people into tooling for creating new spins —- and I'd like to see us invest in and rebuild the spin creation processes. (Particularly, I'd like spin releases to be decoupled from the main OS release, and for those to be self-service by their SIGs with minimal rel-eng involvement needed.) Second, we need to figure out how to work with language-native packaging formats and more directly with code that's distributed in git repos rather than as tarball releases. We're not adding meaningful end-user value by manually repackaging these in our own format. We _do_ add value by vetting licenses and insuring availability and consistency, but I think we can find better ways to do that. I think the "source git" project is an interesting step here. These two things are linked. I want application developers to find Fedora a convenient and easy way to get their software to users. Pulling from the Fedora container and flatpak registries should give the same feeling of trust and safety that installing and RPM from our repos does today. We're not going to get either of those things with the system we have now. Our value is unclear to both developers and end users, so we just get left out. If we don't address this, we're ultimately going to be reduced to a barely-differentiated implementation of a base OS that no one really cares about, not the rich software ecosystem we've always aspired to build. Third, we really need to continue to grow the project as more than coding and packaging. Obviously that engineering work is the core of the project (and we should grow that too!), but it doesn't matter what we build if no one can find it or find how to use it. We need to feed and grow our documentation and support communities around the world. Marie (our new FCAIC, in case you missed that!) and I have been talking about this, and we hope to really expand the $150-mini-event Mindshare program in the next year, and hopefully build on that further in the coming ones. Those are my thoughts. What other challenges and opportunities do you see, and what would you like us to focus on? [*] https://www.xkcd.com/2249/ (Also, on a more personal note: I've been SUPER swamped with email. If you sent me something over the holiday break and I didn't answer, it's not you, it's me. If I dropped something important, please send again. I'm declaring email bankrupcy and starting the year fresh.) -- 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
Re: Fedora 32 System-Wide Change proposal (late): Enable EarlyOOM
On Mo, 06.01.20 10:09, Michael Catanzaro (mcatanz...@gnome.org) wrote: > Is there a way to check memory usage without periodic wakeups? PSI. It measures latency though. Which is the right thing to measure here... You can configure thresholds there and it wakes you up when those are hit. Thus userspace doesn't have to poll at all... > In WebKit we wake up every 5s to check memory usage if we saw low memory > usage on the last wakeup, or every 1s if it was high, with a scale in > between. Would be good to experiment with the timings and see how long we > can get away with before the polling interval is too large to prevent system > lockups. (The WebKit timings are designed for cache clearing, not for > maintaining system responsiveness, so I wouldn't trust those.) Watch things with PSI. > > 2. New code using system() in the year 2020? Really? > > > > 3. Fixed size buffers and implicit, undetected, truncation of strings > >at various places (for example, when formatting the shell string to > >pass to system()). > > Thanks. The code review is much appreciated. If we're going to be running a > superuser deamon, then we need to be confident that it doesn't do these > dangerous things. And these choices do raise quality concerns about what > might be lurking in the rest of the code, as well. BTW, this should not be a root daemon anyway. It only needs one cap: CAP_SYS_KILL. Hence, drop privs to some user of its own, and keep that one cap. Use AmbientCapabilities= in the unit file. > My understanding is that experiments with PSI have indicated that it's hard > to make it work well in practice. Alexey (hakavlad) has investigated this > topic extensively, and his conclusion was: > > "PSI-based process killing should not be used by default, because this topic > is still poorly understood and we don’t know what thresholds are desirable > for most users: it’s hard to find good default values." If things are poorly understood, then understand them better... Don't just adopt some stuff that isn't much better understood either... > > But even if we'd ignore that in order fight latencies one should watch > > latencies: OOM killing per process is just not appropriate on a > > systemd system: all our system services (and a good chunk of our user > > services too) are sorted neatly into cgroups, and we really should > > kill them as a whole and not just individual processes inside > > them. systemd manages that today, and makes exceptions configurable > > via OOMPolicy=, and with your earlyoom stuff you break that. > > > > This looks like second guessing the kernel memory management folks at > > a place where one can only lose, and at the time breaking correct OOM > > reporting by the kernel via cgroups and stuff. > > I think it's very clear at this point that this is extremely unlikely to be > fixed at the kernel level. If that changes, great, but in the meantime we > need a userspace solution to prevent Fedora from locking up. The Workstation > WG doesn't have much (any?) kernel development experience, and we're aware > that historical discussions on fixing this issue at the kernel level have > concluded negatively, so we're limiting our interest to userspace > solutions. Well, it's not that the kernel folks wouldn't provide you with some tools to improve the situation, see PSI... > > Also: what precisely is this even supposed to do? Replace the > > algorithm for detecting *when* to go on a kill rampage? Or actually > > replace the algorithm selecting *what* to kill during a kill rampage? > > earlyoom is restricted to the former, although in the future we might be > interested in doing the later as well, either by enhancing earlyoom or > switching to another tool, e.g. to prevent sshd or journald from being > killed. These services should set the OOMScoreAdjust= value to something sensible. journald and udevd do that. maybe ssh should do too... (it's a bit harder for ssh, since it needs to undo the setting for its sessions again, since oom scores are propagated down the process tree) > > If it's the former (which the name of the project suggests, > > _early_oom)), then at the most basic the tool should let the kernel do > > the killing, i.e. "echo f > /proc/sysrq-trigger". That way the > > reporting via cgroups isn't fucked, and systemd can still do its > > thing, and the kernel can kill per cgroup rather than per process... > > Problem is that letting the kernel do the work can cause data loss. earlyoom > needs to handle process termination itself so that it can send SIGTERM > first, instead of jumping straight to SIGKILL and corrupting who knows what. Well, then tell systemd to do it for you... Use the D-Bus call GetUnitByPID() and then issue StopUnit(). Lennart -- Lennart Poettering, Berlin ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct:
Review requests: various perl modules (for licensecheck and perl-Regexp-Pattern-License update)
Hi To update licensecheck and perl-Regexp-Pattern-License, I need a number of new dependencies packaged: For updating perl-Regexp-Pattern-License (dependency chain in this order, leaf first): * perl-String-Trim-More - https://bugzilla.redhat.com/show_bug.cgi?id=1788157 * perl-Hash-DefHash - https://bugzilla.redhat.com/show_bug.cgi?id=1788170 * perl-Test-Regexp-Pattern - https://bugzilla.redhat.com/show_bug.cgi?id=1788178 For updating licensecheck: * perl-MooX-Role-Logger - https://bugzilla.redhat.com/show_bug.cgi?id=1787673 Test builds: https://copr.fedorainfracloud.org/coprs/smani/licensecheck/builds/ Happy to review in exchange. Thanks Sandro ___ 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 32 System-Wide Change proposal: iptables-nft-default
Hi Kevin, I just noticed we didn't finish discussing the package rename proposal in related releng issue[1]: On Wed, Oct 30, 2019 at 05:02:08PM -0400, Ben Cotton wrote: [...] > To change the status quo, two measures are planned: > > === Raise priority of nft-variants in alternatives === > > Currently, legacy variants are installed with priority 10 and nft > variants with priority 5. This must be changed as otherwise installing > iptables-legacy in a system with > iptables-nft installed would change the active > alternative (since they are in automatic mode by default). > > On the other hand, existing systems using legacy variants should not > be changed by a system update. Therefore nft variants' priorities > should be chosen to match legacy ones. > > === Rename iptables package === > > New name should be iptables-legacy which aligns with > ebtables and arptables and reflects upstream status. To resolve > dependencies, Provides: iptables statement will be added > to iptables-nft package. This should automatically change > the default variant to nft. My motivation for the rename is to abstract 'iptables' keyword other packages depend upon if they need (an implementation of) iptables. With matching Alternatives priorities, the first installed variant package wins and with given lexical ordering, if both legacy and nft variants are installed by default Alternatives will point at legacy. I want to avoid this (and also avoid legacy being installed if not used) by making sure a 'Requires: iptables' in any package may be satisfied by iptables-nft package as well. If adding 'Provides: iptables' to the latter is sufficient, that's fine with me. If my assumptions are correct, I assume there is still a 'Suggests: iptables-nft' required in an always installed package like fedora-release, right? Also, which package would that be? I don't see fedora-release package being used for these things. Cheers, Phil [1] https://pagure.io/releng/issue/8934 ___ 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 32 System-Wide Change proposal (late): Enable EarlyOOM
On Mo, 06.01.20 17:47, Lennart Poettering (mzerq...@0pointer.de) wrote: > On Mo, 06.01.20 08:51, Chris Murphy (li...@colorremedies.com) wrote: > > > On Mon, Jan 6, 2020 at 3:08 AM Lennart Poettering > > wrote: > > >> > > > Looking at the sources very superficially I see a couple of problems: > > > > > > 1. Waking up all the time in 100ms intervals? We generally try to > > >avoid waking the CPU up all the time if nothing happens. Saving > > >power and things. > > > > I agree. What do you think is a reasonable interval? Given that > > earlyoom won't SIGTERM until both 10% memory free and 10% swap free, > > and that will take at least some seconds, what about an interval of 3 > > seconds? > > None. Use PSI. It wakes you up only when pressure stalls reach > threshold you declare. Which basically means you never steal the CPUs > on an idle system, you never cause a wakeup whatsoever. > > > > But more importantly: are we sure this actually operates the way we > > > should? i.e. PSI is really what should be watched. It is not > > > interesting who uses how much memory and triggering kills on > > > that. What matters is to detect when the system becomes slow due to > > > that, i.e. *latencies* introduced due to memory pressure and that's > > > what PSI is about, and hence what should be used. > > > > Earlyoom is a short term stop gap while a more sophisticated solution > > is still maturing. That being low-memory-monitor, which does leverage > > PSI. > > Yes, l-m-m is great. If we can deploy l-m-m today already, why isn't > it good enoug for earlyoom? Oops, sorry. I mean GMemoryMonitor. I assumed l-m-m and GMemoryMonitor was the same thing, but they aren't. I am not sure about l-m-m, haven't looked at it in detail. GMemoryMonitor = great l-m-m = no idea Lennart -- Lennart Poettering, Berlin ___ 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 32 System-Wide Change proposal: Enable fstrim.timer by default
On Mon, Jan 6, 2020 at 4:22 PM drago01 wrote: > What does windows do? Is it the equivalent of the discard mount option or is > it more like fstrim? Well, as I understand it(*), it's complicated, and there are a lot of various tuning knobs one can use to change behavior. But typically, with volume shadow copy enabled (used for such things as system rollback), which is typically enabled, there is a monthly defrag(**) that will run and do a trim as appropriate. Windows will also do the equivalent of the mount discard option, queuing requests at file deletion for later processing, but the queue is length limited (to limit resource usage and performance impacts), so if the number of requests is too long, new requests are thrown away (apparently with the expectation that the monthly defrag will clean it up). There are also cli commands to perform the activities. (*) This is based on some information from quite some time ago, so it may be somewhat stale. (**) While defrag is often stated as not being needed for SSDs, there are cases where in fact it can make a difference in performance or internal data structure layouts or limitations. ___ 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 32 System-Wide Change proposal (late): Enable EarlyOOM
On Mo, 06.01.20 08:51, Chris Murphy (li...@colorremedies.com) wrote: > On Mon, Jan 6, 2020 at 3:08 AM Lennart Poettering > wrote: > >> > > Looking at the sources very superficially I see a couple of problems: > > > > 1. Waking up all the time in 100ms intervals? We generally try to > >avoid waking the CPU up all the time if nothing happens. Saving > >power and things. > > I agree. What do you think is a reasonable interval? Given that > earlyoom won't SIGTERM until both 10% memory free and 10% swap free, > and that will take at least some seconds, what about an interval of 3 > seconds? None. Use PSI. It wakes you up only when pressure stalls reach threshold you declare. Which basically means you never steal the CPUs on an idle system, you never cause a wakeup whatsoever. > > But more importantly: are we sure this actually operates the way we > > should? i.e. PSI is really what should be watched. It is not > > interesting who uses how much memory and triggering kills on > > that. What matters is to detect when the system becomes slow due to > > that, i.e. *latencies* introduced due to memory pressure and that's > > what PSI is about, and hence what should be used. > > Earlyoom is a short term stop gap while a more sophisticated solution > is still maturing. That being low-memory-monitor, which does leverage > PSI. Yes, l-m-m is great. If we can deploy l-m-m today already, why isn't it good enoug for earlyoom? > > But even if we'd ignore that in order fight latencies one should watch > > latencies: OOM killing per process is just not appropriate on a > > systemd system: all our system services (and a good chunk of our user > > services too) are sorted neatly into cgroups, and we really should > > kill them as a whole and not just individual processes inside > > them. systemd manages that today, and makes exceptions configurable > > via OOMPolicy=, and with your earlyoom stuff you break that. > > OOMPolicy= depends on the kernel oom-killer, which is extremely > reluctant to trigger at all. Consistently in my testing, the vast > majority of the time, kernel oom-killer takes > 30 minutes to trigger. > And it may not even kill the worst offender, but rather something like > sshd. A couple of times, I've seen it kill systemd-journald. That's > not a small problem. Well, that sounds as if OOMScoreAdjust= of these services should be tweaked. In journald we us OOMScoreAdjust=-250 and in udevd OOMScoreAdjust=-1000. If journald is still killed too likely, we can certainly bump it to -900 or so, please file a bug. > earlyoom first sends SIGTERM. It's not different from the user saying, > enough of this, let's just gracefully quit the offending process. Only > if the problem continues to get worse is SIGKILL sent. This sounds as if you want low-memory-monitor, but for all services, right? Sounds like something that is relatively easily implementable in systemd though, in a much better way, i.e. hooked to PSI... > For now, kernel developers have made it clear they do not care about > user space responsiveness. At all. Their concern with kernel References to this? I mean, the kernel developers are not a single person, they tend to have different opinions... > > Also: what precisely is this even supposed to do? Replace the > > algorithm for detecting *when* to go on a kill rampage? Or actually > > replace the algorithm selecting *what* to kill during a kill rampage? > > a. It's never a kill rampage. it calls kill(), which I call a "kill rampage"... > It isn't replacing anything. It's acting as a user advocate by > approximating what a reasonable user would do, SIGTERM. The user can't > do this themselves because during heavy swap system responsivity is > already lost, before we're even close to OOM. > > You're right, someone should absolutely solve the responsivity > problem. Kernel folks have clearly ceded this. Can it be done with > cgroupv2 and PSI alone? Unclear. Sounds like someone needs to do their homework, if this is "unclear"? I mean, you basically admit here that this isn't really figured out to the end. Maybe let's give this a bit more time and figure things out a bit more, instead of rushing earlyoom in? Adopting something now, at a point we already clearly know that PSI is how this should be done sounds very wrong to me. > That would be a killing rampage. sysrq+f issues SIGKILL and definitely > results in data loss, always. Earlyoom uses SIGTERM as a first step, > which is a much more conservative first attempt. But it sends SIGKILL next? Why? Why not sysrq+f trggred from userspace for that? I must say the idea that there are effectively multiple process babysitters now, which both want to decide when to terminate services sounds very wrong to me... I mean, wouldn't this all be solved much nicer, much more future proof, if someone would just do what l-m-m does as part of systemd service management, i.e. let's say an option StopOnMemoryPressure= that watches PSI and terminates
Re: Fedora 32 System-Wide Change proposal: Enable fstrim.timer by default
On Monday, January 6, 2020, Kamil Paral wrote: > On Thu, Dec 19, 2019 at 10:43 PM Ben Cotton wrote: > >> https://fedoraproject.org/wiki/Changes/EnableFSTrimTimer >> >> == Summary == >> Enabling fstrim.timer will cause fstrim.service to execute weekly, >> which in turn executes `/usr/sbin/fstrim --fstab --verbose --quiet` >> >> >> == Owner == >> * Name: [[User:chrismurphy| Chris Murphy]] >> > > A bit late, but I just want to say thank you, Chris, for pushing this > forward. TRIM by default is long overdue in Fedora, I think. It has a big > impact on SSDs speed and longevity. I'd love to see mounting with "discard" > by default, but I understand there are various issues with poor TRIM > implementations. Weekly discard of empty space is the next best alternative. > > What does windows do? Is it the equivalent of the discard mount option or is it more like fstrim? If it is the former then we should do the same given that most hardware out there are used that way if that's the case. ___ 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 32 System-Wide Change proposal (late): Enable EarlyOOM
On Mon, Jan 6, 2020 at 11:07 am, Lennart Poettering wrote: Hmm, are we sure this is something we want to have in the default install? Is the code really good enough for that? Looking at the sources very superficially I see a couple of problems: 1. Waking up all the time in 100ms intervals? We generally try to avoid waking the CPU up all the time if nothing happens. Saving power and things. Is there a way to check memory usage without periodic wakeups? In WebKit we wake up every 5s to check memory usage if we saw low memory usage on the last wakeup, or every 1s if it was high, with a scale in between. Would be good to experiment with the timings and see how long we can get away with before the polling interval is too large to prevent system lockups. (The WebKit timings are designed for cache clearing, not for maintaining system responsiveness, so I wouldn't trust those.) 2. New code using system() in the year 2020? Really? 3. Fixed size buffers and implicit, undetected, truncation of strings at various places (for example, when formatting the shell string to pass to system()). Thanks. The code review is much appreciated. If we're going to be running a superuser deamon, then we need to be confident that it doesn't do these dangerous things. And these choices do raise quality concerns about what might be lurking in the rest of the code, as well. But more importantly: are we sure this actually operates the way we should? i.e. PSI is really what should be watched. It is not interesting who uses how much memory and triggering kills on that. What matters is to detect when the system becomes slow due to that, i.e. *latencies* introduced due to memory pressure and that's what PSI is about, and hence what should be used. My understanding is that experiments with PSI have indicated that it's hard to make it work well in practice. Alexey (hakavlad) has investigated this topic extensively, and his conclusion was: "PSI-based process killing should not be used by default, because this topic is still poorly understood and we don’t know what thresholds are desirable for most users: it’s hard to find good default values." https://pagure.io/fedora-workstation/issue/98#comment-615425 Details at: https://github.com/rfjakob/earlyoom/issues/100 So: already considered, but rejected for now. But even if we'd ignore that in order fight latencies one should watch latencies: OOM killing per process is just not appropriate on a systemd system: all our system services (and a good chunk of our user services too) are sorted neatly into cgroups, and we really should kill them as a whole and not just individual processes inside them. systemd manages that today, and makes exceptions configurable via OOMPolicy=, and with your earlyoom stuff you break that. This looks like second guessing the kernel memory management folks at a place where one can only lose, and at the time breaking correct OOM reporting by the kernel via cgroups and stuff. I think it's very clear at this point that this is extremely unlikely to be fixed at the kernel level. If that changes, great, but in the meantime we need a userspace solution to prevent Fedora from locking up. The Workstation WG doesn't have much (any?) kernel development experience, and we're aware that historical discussions on fixing this issue at the kernel level have concluded negatively, so we're limiting our interest to userspace solutions. I think everybody would be happy to hold off on userspace solutions if a kernel solution is in the works. I'd love to see kernel devs acknowledge the issue, using the same test cases that we're using (either 'ninja build' WebKit or simply 'tail /dev/zero'), and propose a real concrete solution. But I'm not going to hold my breath for that. My understanding is that previous discussions have concluded that the kernel OOM is designed to ensure enough memory remains available to the kernel, and that userspace is responsible for determining how to keep userspace responsive. Also: what precisely is this even supposed to do? Replace the algorithm for detecting *when* to go on a kill rampage? Or actually replace the algorithm selecting *what* to kill during a kill rampage? earlyoom is restricted to the former, although in the future we might be interested in doing the later as well, either by enhancing earlyoom or switching to another tool, e.g. to prevent sshd or journald from being killed. If it's the former (which the name of the project suggests, _early_oom)), then at the most basic the tool should let the kernel do the killing, i.e. "echo f > /proc/sysrq-trigger". That way the reporting via cgroups isn't fucked, and systemd can still do its thing, and the kernel can kill per cgroup rather than per process... Problem is that letting the kernel do the work can cause data loss. earlyoom needs to handle process termination itself so that it can send SIGTERM first, instead of
Re: koji / bodhi issues status update
On Mon, Jan 06, 2020 at 11:57:21AM +0100, Marius Schwarz wrote:
>
> Hi Kevin,
>
> Koji is misbehaving ("again"|"still?").
>
> If you search for a package, the search result is available fast.
> If you searched for a build around 8-9 am CET (~3h ago) today, the
> search did not return in a reasonable timeframe, to be exact: it did not
> return at all.
Did you get any kind of error? What time was that UTC?
What was the exact url you were hitting?
> Now, the same search returns in a timely manner again. If you or
> someoneelse did not change anything yet, there may be still a hidden
> problem with the build db.
>
> The searchterm was "sync-server" , a test to find out if fed has the
> mozilla sync-server prebuild, without sitting infront of a fedora pc ;)
There is still an issue with database backups. When it's doing a
database dump the db slows down a lot. :(
That backup starts sometime after 00:00 (a random time) and runs until
usually 06-07UTC.
I fear the only way to fix those db dumps causing slowness is to take a
day or two downtime and partition the offending table. ;(
But that backup should have been over by a few hours ago... so not sure
if thats what you were seeing or not.
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
[Bug 1788183] perl-POSIX-AtFork-0.04 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1788183 --- Comment #1 from Upstream Release Monitoring --- An HTTP error occurred downloading the package's new Source URLs: Getting https://cpan.metacpan.org/authors/id/G/GF/GFUJI/POSIX-AtFork-0.04.tar.gz to ./POSIX-AtFork-0.04.tar.gz -- You are receiving this mail because: You are on the CC list for the bug. ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-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/perl-devel@lists.fedoraproject.org
[Bug 1788183] New: perl-POSIX-AtFork-0.04 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1788183 Bug ID: 1788183 Summary: perl-POSIX-AtFork-0.04 is available Product: Fedora Version: rawhide Status: NEW Component: perl-POSIX-AtFork Keywords: FutureFeature, Triaged Assignee: ppi...@redhat.com Reporter: upstream-release-monitor...@fedoraproject.org QA Contact: extras...@fedoraproject.org CC: perl-devel@lists.fedoraproject.org, ppi...@redhat.com Target Milestone: --- Classification: Fedora Latest upstream release: 0.04 Current version/release in rawhide: 0.02-19.fc31 URL: http://search.cpan.org/dist/POSIX-AtFork/ Please consult the package updates policy before you issue an update to a stable branch: https://fedoraproject.org/wiki/Updates_Policy More information about the service that created this bug can be found at: https://fedoraproject.org/wiki/Upstream_release_monitoring Please keep in mind that with any upstream change, there may also be packaging changes that need to be made. Specifically, please remember that it is your responsibility to review the new version to ensure that the licensing is still correct and that no non-free or legally problematic items have been added upstream. Based on the information from anitya: https://release-monitoring.org/project/3283/ -- You are receiving this mail because: You are on the CC list for the bug. ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-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/perl-devel@lists.fedoraproject.org
[Bug 1788181] perl-Inline-0.85 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1788181 --- Comment #1 from Upstream Release Monitoring --- An HTTP error occurred downloading the package's new Source URLs: Getting https://cpan.metacpan.org/authors/id/T/TI/TINITA/Inline-0.85.tar.gz to ./Inline-0.85.tar.gz -- You are receiving this mail because: You are on the CC list for the bug. ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-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/perl-devel@lists.fedoraproject.org
[Bug 1788181] New: perl-Inline-0.85 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1788181 Bug ID: 1788181 Summary: perl-Inline-0.85 is available Product: Fedora Version: rawhide Status: NEW Component: perl-Inline Keywords: FutureFeature, Triaged Assignee: ppi...@redhat.com Reporter: upstream-release-monitor...@fedoraproject.org QA Contact: extras...@fedoraproject.org CC: caillon+fedoraproj...@gmail.com, jples...@redhat.com, ka...@ucw.cz, perl-devel@lists.fedoraproject.org, ppi...@redhat.com, rhug...@redhat.com, rstr...@redhat.com, sandm...@redhat.com Target Milestone: --- Classification: Fedora Latest upstream release: 0.85 Current version/release in rawhide: 0.83-3.fc31 URL: http://search.cpan.org/dist/Inline/ Please consult the package updates policy before you issue an update to a stable branch: https://fedoraproject.org/wiki/Updates_Policy More information about the service that created this bug can be found at: https://fedoraproject.org/wiki/Upstream_release_monitoring Please keep in mind that with any upstream change, there may also be packaging changes that need to be made. Specifically, please remember that it is your responsibility to review the new version to ensure that the licensing is still correct and that no non-free or legally problematic items have been added upstream. Based on the information from anitya: https://release-monitoring.org/project/2984/ -- You are receiving this mail because: You are on the CC list for the bug. ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-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/perl-devel@lists.fedoraproject.org
Re: Fedora 32 System-Wide Change proposal (late): Enable EarlyOOM
On Mon, Jan 6, 2020 at 4:57 AM Roberto Ragusa wrote: > > On 1/5/20 12:38 AM, Chris Murphy wrote: > > On Sat, Jan 4, 2020 at 2:51 AM Aleksandra Fedorova > > wrote: > > > >> Since in the Change we are not introducing just the earlyoom tool but > >> enable it with a specific profile I would add those details here. Smth > >> like: > >> > >> "earlyoom service will choose the offending process based on the same > >> oom_score as kernel uses. It will send a SIGTERM signal on 10% of RAM > >> left, and SIGKILL on 5%" > > > > I add this information to the summary. Also, I think these numbers may > > need to change to avoid prematurely sending SIGTERM when the system > > has no swap device. > I read that sentence in a different way: > "earlyoom will make only 90% of your RAM available, > so it is effectively using 10% of your RAM". > > On my 32GB laptop that means 3.2GB of RAM gets unusable. > And on my 64GB machine I'm being robbed of 6.4GB. Wow. > > How low can these numbers be pushed? Even 3% would be 1GB out of 32GB. What you say is only true in the case of systems with no swap. That's mentioned in the proposal. If swap is being used, for sure essentially all of your RAM is being used, so it's swap that's the determining factor. If you don't have swap, yes RAM becomes the determining factor and I agree that on systems with a lot of RAM, 10% is too high. The ideal scenario is to not run earlyoom at all on systems that do not have a swap device. They're not going to run into the responsivity problem anyway, which is a direct consequence of heavy swapping. -- 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 32 System-Wide Change proposal (late): Enable EarlyOOM
On Mon, Jan 6, 2020 at 3:08 AM Lennart Poettering wrote: >> > Looking at the sources very superficially I see a couple of problems: > > 1. Waking up all the time in 100ms intervals? We generally try to >avoid waking the CPU up all the time if nothing happens. Saving >power and things. I agree. What do you think is a reasonable interval? Given that earlyoom won't SIGTERM until both 10% memory free and 10% swap free, and that will take at least some seconds, what about an interval of 3 seconds? > But more importantly: are we sure this actually operates the way we > should? i.e. PSI is really what should be watched. It is not > interesting who uses how much memory and triggering kills on > that. What matters is to detect when the system becomes slow due to > that, i.e. *latencies* introduced due to memory pressure and that's > what PSI is about, and hence what should be used. Earlyoom is a short term stop gap while a more sophisticated solution is still maturing. That being low-memory-monitor, which does leverage PSI. > But even if we'd ignore that in order fight latencies one should watch > latencies: OOM killing per process is just not appropriate on a > systemd system: all our system services (and a good chunk of our user > services too) are sorted neatly into cgroups, and we really should > kill them as a whole and not just individual processes inside > them. systemd manages that today, and makes exceptions configurable > via OOMPolicy=, and with your earlyoom stuff you break that. OOMPolicy= depends on the kernel oom-killer, which is extremely reluctant to trigger at all. Consistently in my testing, the vast majority of the time, kernel oom-killer takes > 30 minutes to trigger. And it may not even kill the worst offender, but rather something like sshd. A couple of times, I've seen it kill systemd-journald. That's not a small problem. earlyoom first sends SIGTERM. It's not different from the user saying, enough of this, let's just gracefully quit the offending process. Only if the problem continues to get worse is SIGKILL sent. > This looks like second guessing the kernel memory management folks at > a place where one can only lose, and at the time breaking correct OOM > reporting by the kernel via cgroups and stuff. It is intended to be a substitute for the user hitting the power button. It's not intended as a substitute for the OS, as a whole, improving its user advocacy to do the right thing in the first place, which currently it isn't. For now, kernel developers have made it clear they do not care about user space responsiveness. At all. Their concern with kernel oom-killer is strictly with keeping the kernel functioning. And the congestion that results from heavy simultaneous page-in and page-out also appears to not be a concern for kernel developers, it's a well known problem, and they haven't made any break through in this area. So it's really going to need to be user space managed, leveraging PSI and cgroupv2. And that's the next step. > Also: what precisely is this even supposed to do? Replace the > algorithm for detecting *when* to go on a kill rampage? Or actually > replace the algorithm selecting *what* to kill during a kill rampage? a. It's never a kill rampage. b. When: It first uses SIGTERM at 10% remaining for both memory and swap; and SIGKILL at 5%. In hundreds of tests I've never seen earlyoom use SIGKILL, so far everything responds fairly immediately to SIGTERM. But I'm also testing with well behaved programs, nothing malicious. And that's intentional. This problem is actually far worse if it were malicious. c. What: Same as kernel oom-killer. It uses oom_score. It isn't replacing anything. It's acting as a user advocate by approximating what a reasonable user would do, SIGTERM. The user can't do this themselves because during heavy swap system responsivity is already lost, before we're even close to OOM. You're right, someone should absolutely solve the responsivity problem. Kernel folks have clearly ceded this. Can it be done with cgroupv2 and PSI alone? Unclear. > If it's the former (which the name of the project suggests, > _early_oom)), then at the most basic the tool should let the kernel do > the killing, i.e. "echo f > /proc/sysrq-trigger". That way the > reporting via cgroups isn't fucked, and systemd can still do its > thing, and the kernel can kill per cgroup rather than per process... That would be a killing rampage. sysrq+f issues SIGKILL and definitely results in data loss, always. Earlyoom uses SIGTERM as a first step, which is a much more conservative first attempt. > Anyway, this all sounds very very fishy to me. Not thought to the end, > and I am pretty sure this is something the kernel memory management > folks should give a blessing to. Second guessing the kernel like that > is just a bad idea if you ask me. There's no first or second guessing. The kernel oom-killer is strictly responsible for maintaining enough resources for the
Re: Fedora 32 System-Wide Change proposal: Golang 1.14
On Thursday, 2 January 2020 16:24:44 CET Igor Gnatenko wrote: > Do we really need to rebuild all thousand of packages given that most > of them are providing only noarch devel packages with sources? Don't > we need to rebuild only those which provide binaries? > We need rebuild to re-run the tests to see if the new Golang has broken some packages. Best regards, Robert-André ___ 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 32 System-Wide Change proposal (late): Enable EarlyOOM
On Mon, Jan 6, 2020 at 5:08 AM Lennart Poettering wrote: > > I mean, yes, the OOM killer might not be that great currently, but > this sounds like something to fix in kernel land, and if that doesn't > work out for some reason because kernel devs can't agree, then do it > as fallback in userspace, but with sound input from the kernel folks, > and the blessing of at least some of the kernel folks. > > I agree that the implementation may need some work, but one thing should be clear: it is not a winning strategy to wait for the kernel folks to fix this. They have for all practical purposes given up on this problem, and are not going to solve the issue for us. ___ 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: wdune/white is available for fedora 32
On Sunday, 5 January 2020 02:54:54 CET J. Scheurich wrote: > Hi, > > After 13 months, wdune/white_dune is avaliable for fedora 32 8-) > > I want to say thanks for anyońe, who gave tips, especially Petr Menšík > (the reviewer) and > Robert-André Mauchin (the sponsor). > > > so long > MUFTI > > Hello, I told you to build vcglib first, why don't you listen to me? Are you not receiving my mails?? 1. Request vcglib fedpkg request-repo vcglib 1677989 fedpkg request-branch --repo vcglib f31 2. Wait until https://pagure.io/releng/fedora-scm-requests/issues has approved these requests 3. When approved clone and import: fedpkg clone vcglib fedpkg import vcglib-1.0.1-1.fc29.src.rpm git commit -m "Initial import (#1677989)" 4. Build in rawhide fedpkg push fedpkg build 5. Build in F31 fedpkg switch-branch f31 git merge master fedpkg push fedpkg build 6. Request a Buildroot Override to build wdune in F31 later fedpkg override create --duration 15 --notes "Buildroot override for wdune" 7. Now change your wdune SPEC to build without vcglib bundled Please get back to me with your progress! ___ 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 32 System-Wide Change proposal: Enable fstrim.timer by default
On Thu, Dec 19, 2019 at 10:43 PM Ben Cotton wrote: > https://fedoraproject.org/wiki/Changes/EnableFSTrimTimer > > == Summary == > Enabling fstrim.timer will cause fstrim.service to execute weekly, > which in turn executes `/usr/sbin/fstrim --fstab --verbose --quiet` > > > == Owner == > * Name: [[User:chrismurphy| Chris Murphy]] > A bit late, but I just want to say thank you, Chris, for pushing this forward. TRIM by default is long overdue in Fedora, I think. It has a big impact on SSDs speed and longevity. I'd love to see mounting with "discard" by default, but I understand there are various issues with poor TRIM implementations. Weekly discard of empty space is the next best alternative. ___ 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: Self Introduction: Michael Hrechyn
On Tue, Dec 31, 2019 at 01:00:42PM -, Michael Hrechyn wrote: > Hi! I'm Michael Hrechyn, 17 years old school boy, who lives in Belarus. > In addition to studying at school, I study programming in Rust and > administration of Linux systems because I like it. > I have few simple open-source projects writen in Rust and they are also > available in Copr. > Also I maintain few other packages, which also available in Copr. For > instance, it's a libinput-gestures and MultiMC. Hi! Welcome to Fedora! -- 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
Re: Fedora 32 system-wide change proposal: reduce installation media size by improving the compression ratio of SquashFS filesystem
On Sun, Jan 5, 2020 at 7:24 AM Bohdan Khomutskyi wrote: > > I was unable to create an article in Fedora wiki system. > Since you don't have any non-CLA groups in FAS, I have added you to the wikiedit group. Please add this to the wiki ASAP. This proposal is past the deadline for Fedora 32 System-Wide Change proposals, but since it is only a few days late, I'll continue shepherding it and FESCo can decide if it's worth granting an exception. -- Ben Cotton He / Him / His Fedora Program Manager 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: Orphaned packages looking for new maintainers
On Mon, Jan 06, 2020 at 01:25:19PM +0100, Dan Čermák wrote: > "Richard W.M. Jones" writes: > > > On Tue, Dec 24, 2019 at 09:09:26AM -0800, Jerry James wrote: > >> Pardon the top posting. I am on the road with only my phone, no Fedora > >> devices anywhere. I have been thinking about trying to get Facebook's Infer > >> tool into Fedora. Several of its dependencies are on this list, but I won't > >> be able to take them until I get home, after they are retired. The ocaml > >> packages, at least, have some serious dependency issues, as I recall, but I > >> would like to see if they can be fixed. Can someone please assign the > >> following packages to me? After I return I will fix them if I can & retire > >> them if I cannot. > >> > >> jackson > > > > For these packages: > > > >> ocaml-bin-prot > >> ocaml-deriving > >> ocaml-sexplib > > > > I orphaned them because the upstream versions we were using depended > > on camlp4. There are newer upstream versions but they had quite > > different requirements (being basically rewritten in at least the case > > of Deriving). > > > > Anyway in the meantime all 3 packages were taken by Dan Čermák > > (https://src.fedoraproject.org/user/defolos/projects). > > That is correct, however I will probably orphan ocaml-deriving and > ocaml-sexplib very soon because we only need ocaml-bin-prot for infer > and I have no need for the other two packages. > > However, ocaml-bin-prot was also rewritten and went through 2 versioning > changes in the meantime resulting in the current latest version being > smaller than the current version in Fedora. This will probably cause all > kinds of funny problems if I try to submit an update with a smaller > NEVRA :( Welcome to the world of Epoch: headers :-/ Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones Read my programming and virtualization blog: http://rwmj.wordpress.com libguestfs lets you edit virtual machines. Supports shell scripting, bindings from many languages. http://libguestfs.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 32 System-Wide Change proposal: Firewalld Default to nftables
On Mon, Jan 6, 2020 at 8:45 AM Eric Garver wrote: > > On Sat, Dec 28, 2019 at 09:58:50AM -0500, Neal Gompa wrote: > > On Mon, Sep 9, 2019 at 3:32 PM Ben Cotton wrote: > > > > > > https://fedoraproject.org/wiki/Changes/firewalld_default_to_nftables > > > > > > == Summary == > > > This change will toggle the default firewalld backend from iptables to > > > nftables. All of firewalld's primitives will use nftables while direct > > > rules continue to use iptables/ebtables. > > > > > > == Owner == > > > * Name: [[User:erig0| Eric Garver]] > > > * Email: egar...@redhat.com > > > > > > > > > == Detailed Description == > > > Firewalld upstream has used nftables as the default backend for the > > > past two minor releases. It is also the default in other distributions > > > (e.g. RHEL-8). This change will bring Fedora in line with upstream. > > > > > > Using nftables bring many advantages. See firewalld's upstream > > > [https://firewalld.org/2018/07/nftables-backend blog post]. It also > > > highlights a few behavioral changes. > > > > > > == Benefit to Fedora == > > > * Fewer firewall rules (rule consolidation) > > > All of firewalld's primitives will use the same underlying firewall > > > (nftables) instead of duplicating rules both in iptables and > > > ip6tables. In nftables rules can match both IPv4 and IPv6 packets. > > > This reduces the number of firewall rules by half. > > > * firewalld's rules are namespaced > > > With nftables firewalld's rules are isolated to a "firewalld" table. A > > > separate firewall (or user) can create its own independent ruleset and > > > firewalld will never touch it. > > > * Netfilter upstream is focusing on nftables, not iptables > > > > > > == Scope == > > > * Proposal owners: firewalld (erig0, Eric Garver) > > > Currently the firewalld package has a Fedora downstream patch to hide > > > the nftables backend. The only firewalld change required is to remove > > > that patch from the package and rebuild. > > > > > > * Other developers: libvirt, podman, docker > > > ** libvirt > > > *** libvirt already cooperates with the firewalld nftables backend. > > > The only thing needed is to test/verify. > > > ** podman > > > *** libvirt already cooperates with the firewalld nftables backend. > > > The only thing needed is to test/verify. > > > ** docker > > > *** Docker currently does not cooperate with the nftables backend. It > > > currently side-steps firewalld by injecting its own rules in iptables > > > ahead of firewalld's rules. However, with the nftables backend > > > firewalld's rule will still be evaluated. Netfilter in the kernel will > > > call iptables, then nftables for the same packet. This means > > > firewalld/nftables is likely to drop the packet even if docker has > > > iptables rules to ACCEPT. > > > *** Proposed fix 1: Docker package should provide a firewalld zone > > > definition that includes the docker interfaces (e.g. docker0). The > > > zone should use the "ACCEPT" policy (firewalld --set-target). This > > > will allow docker's traffic to pass through firewalld/nftables. > > > Issue 1: If a user has configured a different docker bridge name, > > > then they'll have to manually add the bridge to the docker zone (or > > > firewalld's trusted zone). > > > *** Proposed fix 2: Just like "Proposed fix 1", but instead of adding > > > the zone definition to docker we created a "docker-firewalld" (or > > > firewalld-docker?) package that has the zone definition. This could be > > > installed by default when docker is installed. > > > * Policies and guidelines: No updated needed. > > > * Trademark approval: N/A (not needed for this Change) > > > > > > > > > == Upgrade/compatibility impact == > > > When users are upgraded to firewalld with nftables enabled (f32) all > > > their firewall rules will exist in nftables instead of iptables. All > > > of firewalld's primitives (zones, services, ports, rich rules, etc.) > > > are 100% compatible between backends. > > > > > > Users of direct rules may need to consider the > > > [https://firewalld.org/2018/07/nftables-backend behavioral changes] > > > that were announced upstream. Some are also highlighted here: > > > > > > * direct rules execute before _all_ firewalld rules > > > ** This has been requested by users > > > * packets dropped in iptables (or direct rules) will never be seen by > > > firewalld > > > * packets accepted in iptables (or direct rules) are still subject to > > > firewalld's rules > > > > > > == How To Test == > > > Testing should mostly be integration based. Firewalld upstream has a > > > fairly comprehensive testsuite that covers functional testing. > > > > > > The following are packages known to integrate with firewalld. They > > > should be tested with the nftables backend. > > > > > > * libvirt > > > ** verify VMs with different network types (bridged, routed) have > > > working network access > > > ** newer version of libvirt should create and use a "libvirt" > > > firewalld zone.
Re: Fedora 32 System-Wide Change proposal: Firewalld Default to nftables
On Sat, Dec 28, 2019 at 09:58:50AM -0500, Neal Gompa wrote: > On Mon, Sep 9, 2019 at 3:32 PM Ben Cotton wrote: > > > > https://fedoraproject.org/wiki/Changes/firewalld_default_to_nftables > > > > == Summary == > > This change will toggle the default firewalld backend from iptables to > > nftables. All of firewalld's primitives will use nftables while direct > > rules continue to use iptables/ebtables. > > > > == Owner == > > * Name: [[User:erig0| Eric Garver]] > > * Email: egar...@redhat.com > > > > > > == Detailed Description == > > Firewalld upstream has used nftables as the default backend for the > > past two minor releases. It is also the default in other distributions > > (e.g. RHEL-8). This change will bring Fedora in line with upstream. > > > > Using nftables bring many advantages. See firewalld's upstream > > [https://firewalld.org/2018/07/nftables-backend blog post]. It also > > highlights a few behavioral changes. > > > > == Benefit to Fedora == > > * Fewer firewall rules (rule consolidation) > > All of firewalld's primitives will use the same underlying firewall > > (nftables) instead of duplicating rules both in iptables and > > ip6tables. In nftables rules can match both IPv4 and IPv6 packets. > > This reduces the number of firewall rules by half. > > * firewalld's rules are namespaced > > With nftables firewalld's rules are isolated to a "firewalld" table. A > > separate firewall (or user) can create its own independent ruleset and > > firewalld will never touch it. > > * Netfilter upstream is focusing on nftables, not iptables > > > > == Scope == > > * Proposal owners: firewalld (erig0, Eric Garver) > > Currently the firewalld package has a Fedora downstream patch to hide > > the nftables backend. The only firewalld change required is to remove > > that patch from the package and rebuild. > > > > * Other developers: libvirt, podman, docker > > ** libvirt > > *** libvirt already cooperates with the firewalld nftables backend. > > The only thing needed is to test/verify. > > ** podman > > *** libvirt already cooperates with the firewalld nftables backend. > > The only thing needed is to test/verify. > > ** docker > > *** Docker currently does not cooperate with the nftables backend. It > > currently side-steps firewalld by injecting its own rules in iptables > > ahead of firewalld's rules. However, with the nftables backend > > firewalld's rule will still be evaluated. Netfilter in the kernel will > > call iptables, then nftables for the same packet. This means > > firewalld/nftables is likely to drop the packet even if docker has > > iptables rules to ACCEPT. > > *** Proposed fix 1: Docker package should provide a firewalld zone > > definition that includes the docker interfaces (e.g. docker0). The > > zone should use the "ACCEPT" policy (firewalld --set-target). This > > will allow docker's traffic to pass through firewalld/nftables. > > Issue 1: If a user has configured a different docker bridge name, > > then they'll have to manually add the bridge to the docker zone (or > > firewalld's trusted zone). > > *** Proposed fix 2: Just like "Proposed fix 1", but instead of adding > > the zone definition to docker we created a "docker-firewalld" (or > > firewalld-docker?) package that has the zone definition. This could be > > installed by default when docker is installed. > > * Policies and guidelines: No updated needed. > > * Trademark approval: N/A (not needed for this Change) > > > > > > == Upgrade/compatibility impact == > > When users are upgraded to firewalld with nftables enabled (f32) all > > their firewall rules will exist in nftables instead of iptables. All > > of firewalld's primitives (zones, services, ports, rich rules, etc.) > > are 100% compatible between backends. > > > > Users of direct rules may need to consider the > > [https://firewalld.org/2018/07/nftables-backend behavioral changes] > > that were announced upstream. Some are also highlighted here: > > > > * direct rules execute before _all_ firewalld rules > > ** This has been requested by users > > * packets dropped in iptables (or direct rules) will never be seen by > > firewalld > > * packets accepted in iptables (or direct rules) are still subject to > > firewalld's rules > > > > == How To Test == > > Testing should mostly be integration based. Firewalld upstream has a > > fairly comprehensive testsuite that covers functional testing. > > > > The following are packages known to integrate with firewalld. They > > should be tested with the nftables backend. > > > > * libvirt > > ** verify VMs with different network types (bridged, routed) have > > working network access > > ** newer version of libvirt should create and use a "libvirt" > > firewalld zone. Interfaces should be dynamically added to the zone. > > * podman > > ** verify podman adds container bridge interface to the "trusted" zone > > ** verify container still has network access > > * docker > > ** known to not work with the firewalld nftables backend
Re: Orphaned packages looking for new maintainers
Le lun. 23 déc. 2019 à 11:03, Miro Hrončok a écrit : > > The following packages are orphaned and will be retired when they > are orphaned for six weeks, unless someone adopts them. If you know for sure > that the package should be retired, please do so now with a proper reason: > https://fedoraproject.org/wiki/How_to_remove_a_package_at_end_of_life > > Note: If you received this mail directly you (co)maintain one of the affected > packages or a package that depends on one. Please adopt the affected package > or > retire your depending package to avoid broken dependencies, otherwise your > package will be retired when the affected package gets retired. > > Request package ownership via the *Take* button in he left column on > https://src.fedoraproject.org/rpms/ > > Full report available at: > https://churchyard.fedorapeople.org/orphans-2019-12-23.txt ... > gns3-gui orphan 5 weeks ago > gns3-net-converterorphan 5 weeks ago > gns3-server orphan 5 weeks ago I'd like to pick theses gns3* packages. https://pagure.io/releng/issue/9149 Thx -- - Nicolas (kwizart) ___ 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
Schedule for Mondays's FESCo Meeting (2020-01-06)
Following is the list of topics that will be discussed in the FESCo meeting Monday at 15:00UTC in #fedora-meeting-1 on irc.freenode.net. To convert UTC to your local time, take a look at http://fedoraproject.org/wiki/UTCHowto or run: date -d '2020-01-06 15:00 UTC' Links to all issues to be discussed can be found at: https://pagure.io/fesco/report/meeting_agenda = Discussed and Voted in the Ticket = F32 System-Wide Change: Ruby 2.7 https://pagure.io/fesco/issue/2308 APPROVED (+7, 0, -0) F33 System-Wide Change: Python 3.9 https://pagure.io/fesco/issue/2299 APPROVED (+5, 0, -0) Nonresponsive maintainer: Clément David (davidcl) https://pagure.io/fesco/issue/2306 APPROVED (+0, 0, -0) Acked by davidcl in the ticket. F32 System-Wide Change: Stop shipping individual component libraries in clang-libs package https://pagure.io/fesco/issue/2305 APPROVED (+4, 0, -0) F32 System-Wide Change: LLVM 10 https://pagure.io/fesco/issue/2304 APPROVED (+5, 0, -0) Nonresponsive maintainer: Moez Roy (moezroy) https://pagure.io/fesco/issue/2302 APPROVED (+5, 0, -0) Nonresponsive maintainer: Anuj More (anujmore) https://pagure.io/fesco/issue/2301 APPROVED (+4, 0, -0) Packages and account for automated testing of the packager workflow with gating https://pagure.io/fesco/issue/2300 APPROVED (+3, 0, -0) = New business = #topic #2303 F32 System-Wide Change: Drop Optical Media Release Criterion https://pagure.io/fesco/issue/2303 = Open Floor = For more complete details, please visit each individual issue. The report of the agenda items can be found at https://pagure.io/fesco/report/meeting_agenda If you would like to add something to this agenda, you can reply to this e-mail, file a new issue at https://pagure.io/fesco, e-mail me directly, or bring it up at the end of the meeting, during the open floor topic. Note that added topics may be deferred until the following meeting. ___ 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-Rawhide-20200106.n.0 compose check report
No missing expected images. Compose FAILS proposed Rawhide gating check! 2 of 43 required tests failed openQA tests matching unsatisfied gating requirements shown with **GATING** below Failed openQA tests: 20/155 (x86_64), 1/2 (arm) New failures (same test not failed in Fedora-Rawhide-20200105.n.0): ID: 507287 Test: x86_64 Workstation-live-iso apps_startstop URL: https://openqa.fedoraproject.org/tests/507287 ID: 507288 Test: x86_64 Workstation-live-iso desktop_background URL: https://openqa.fedoraproject.org/tests/507288 ID: 507289 Test: x86_64 Workstation-live-iso desktop_update_graphical URL: https://openqa.fedoraproject.org/tests/507289 ID: 507292 Test: x86_64 Workstation-live-iso desktop_terminal **GATING** URL: https://openqa.fedoraproject.org/tests/507292 ID: 507293 Test: x86_64 Workstation-live-iso desktop_browser **GATING** URL: https://openqa.fedoraproject.org/tests/507293 ID: 507294 Test: x86_64 Workstation-live-iso desktop_printing URL: https://openqa.fedoraproject.org/tests/507294 ID: 507296 Test: x86_64 Workstation-live-iso desktop_notifications_postinstall URL: https://openqa.fedoraproject.org/tests/507296 ID: 507303 Test: x86_64 KDE-live-iso base_services_start URL: https://openqa.fedoraproject.org/tests/507303 ID: 507305 Test: x86_64 KDE-live-iso apps_startstop URL: https://openqa.fedoraproject.org/tests/507305 ID: 507322 Test: x86_64 universal install_cyrillic_language URL: https://openqa.fedoraproject.org/tests/507322 ID: 507329 Test: x86_64 universal install_european_language URL: https://openqa.fedoraproject.org/tests/507329 ID: 507339 Test: x86_64 universal upgrade_desktop_encrypted_64bit URL: https://openqa.fedoraproject.org/tests/507339 ID: 507358 Test: x86_64 universal upgrade_desktop_64bit URL: https://openqa.fedoraproject.org/tests/507358 ID: 507361 Test: x86_64 universal install_asian_language URL: https://openqa.fedoraproject.org/tests/507361 ID: 507380 Test: x86_64 universal upgrade_2_desktop_encrypted_64bit URL: https://openqa.fedoraproject.org/tests/507380 ID: 507384 Test: x86_64 universal upgrade_2_desktop_64bit URL: https://openqa.fedoraproject.org/tests/507384 Old failures (same test failed in Fedora-Rawhide-20200105.n.0): ID: 507260 Test: x86_64 Server-dvd-iso modularity_tests URL: https://openqa.fedoraproject.org/tests/507260 ID: 507262 Test: x86_64 Server-dvd-iso base_services_start URL: https://openqa.fedoraproject.org/tests/507262 ID: 507315 Test: arm Minimal-raw_xz-raw.xz install_arm_image_deployment_upload URL: https://openqa.fedoraproject.org/tests/507315 ID: 507323 Test: x86_64 universal install_arabic_language URL: https://openqa.fedoraproject.org/tests/507323 ID: 507393 Test: x86_64 universal install_iscsi URL: https://openqa.fedoraproject.org/tests/507393 Soft failed openQA tests: 85/155 (x86_64) (Tests completed, but using a workaround for a known bug) New soft failures (same test not soft failed in Fedora-Rawhide-20200105.n.0): ID: 507246 Test: x86_64 Server-dvd-iso install_repository_nfs_variation URL: https://openqa.fedoraproject.org/tests/507246 ID: 507307 Test: x86_64 KDE-live-iso desktop_update_graphical URL: https://openqa.fedoraproject.org/tests/507307 ID: 507312 Test: x86_64 KDE-live-iso desktop_printing URL: https://openqa.fedoraproject.org/tests/507312 ID: 507378 Test: x86_64 universal upgrade_2_server_domain_controller URL: https://openqa.fedoraproject.org/tests/507378 Old soft failures (same test soft failed in Fedora-Rawhide-20200105.n.0): ID: 507241 Test: x86_64 Server-boot-iso install_default URL: https://openqa.fedoraproject.org/tests/507241 ID: 507242 Test: x86_64 Server-boot-iso install_default@uefi URL: https://openqa.fedoraproject.org/tests/507242 ID: 507247 Test: x86_64 Server-dvd-iso install_repository_nfs_graphical URL: https://openqa.fedoraproject.org/tests/507247 ID: 507248 Test: x86_64 Server-dvd-iso install_repository_nfsiso_variation URL: https://openqa.fedoraproject.org/tests/507248 ID: 507249 Test: x86_64 Server-dvd-iso install_default_upload URL: https://openqa.fedoraproject.org/tests/507249 ID: 507250 Test: x86_64 Server-dvd-iso install_repository_hd_variation URL: https://openqa.fedoraproject.org/tests/507250 ID: 507251 Test: x86_64 Server-dvd-iso install_vnc_server URL: https://openqa.fedoraproject.org/tests/507251 ID: 507252 Test: x86_64 Server-dvd-iso install_default@uefi URL: https://openqa.fedoraproject.org/tests/507252 ID: 507254 Test: x86_64 Server-dvd-iso install_vnc_client URL: https://openqa.fedoraproject.org/tests/507254 ID: 507255 Test: x86_64 Server-dvd-iso install_vncconnect_client URL: https://openqa.fedoraproject.org/tests/507255 ID: 507266 Test: x86_64 Server-dvd-iso install_updates_nfs URL: https://openqa.fedoraproject.org/tests/507266 ID: 507271 Test: x86_64 Server-dvd-iso server_realmd_join_kickstart URL:
Orphaned packages looking for new maintainers
The following packages are orphaned and will be retired when they are orphaned for six weeks, unless someone adopts them. If you know for sure that the package should be retired, please do so now with a proper reason: https://fedoraproject.org/wiki/How_to_remove_a_package_at_end_of_life Note: If you received this mail directly you (co)maintain one of the affected packages or a package that depends on one. Please adopt the affected package or retire your depending package to avoid broken dependencies, otherwise your package will be retired when the affected package gets retired. Request package ownership via the *Take* button in he left column on https://src.fedoraproject.org/rpms/ Full report available at: https://churchyard.fedorapeople.org/orphans-2020-01-06.txt grep it for your FAS username and follow the dependency chain. Package (co)maintainers Status Change MochiKit orphan 3 weeks ago dzen2 bstinson, dcantrel, fale,5 weeks ago lupinix, orphan golang-github-codahale- go-sig, orphan 2 weeks ago aesnicheck i3-ipccicku, fale, gchamoul, 5 weeks ago lupinix, mpreisle, orphan ike-scan orphan, pwouters 3 weeks ago infinispangil, orphan 6 weeks ago maven-ant-plugin mizdebsk, orphan 4 weeks ago maven-docck-pluginmizdebsk, orphan 4 weeks ago maven-ear-plugin orphan 4 weeks ago mcollective-qpid-plugin orphan, tdawson 3 weeks ago multithreadedtc orphan 4 weeks ago nbtscan orphan 3 weeks ago nesc cicku, orphan4 weeks ago ninvaders orphan 3 weeks ago oyranos orphan 3 weeks ago pscan orphan 3 weeks ago pykka orphan 0 weeks ago python-dockerpty lsm5, orphan, ttomecek 3 weeks ago python-flask-classy orphan 5 weeks ago python-flask-debugtoolbar orphan 5 weeks ago python-fsmonitor orphan 5 weeks ago python-mongoenginebowlofeggs, echevemaster,5 weeks ago orphan python-virtkeyorphan 3 weeks ago qpid-proton orphan 2 weeks ago rubygem-awesome_spawn jstribny, orphan 4 weeks ago rubygem-bootstrap-sassorphan 4 weeks ago rubygem-charlock_holmes orphan 4 weeks ago rubygem-faker orphan 1 weeks ago rubygem-omniauth orphan 3 weeks ago rubygem-orm_adapter orphan 4 weeks ago saxon dbhole, dchen, jjohnstn, 5 weeks ago mbooth, orphan shed orphan 3 weeks ago sound-theme-acoustic orphan 1 weeks ago swingxorphan 0 weeks ago tmuxinatororphan 3 weeks ago tudu orphan 1 weeks ago vttestcicku, orphan3 weeks ago xml-stylebook mizdebsk, orphan 5 weeks ago The following packages require above mentioned packages: See https://churchyard.fedorapeople.org/orphans-2020-01-06.txt Grep it for your username and follow the dependency chain. Affected (co)maintainers abompard: qpid-proton arobinso: multithreadedtc ausil: qpid-proton bkabrda: qpid-proton bowlofeggs: python-mongoengine, qpid-proton bstinson: dzen2 cicku: i3-ipc, nesc, vttest cqi: qpid-proton cverna: qpid-proton dbhole: saxon dcantrel: dzen2 dchen: saxon dgoodwin: qpid-proton dmach: qpid-proton dodji: qpid-proton dridi: vttest echevemaster: python-mongoengine ellert: maven-docck-plugin error: python-dockerpty fab: vttest fale: i3-ipc, dzen2 frixxon: qpid-proton frostyx: qpid-proton fujiwara: qpid-proton gchamoul: i3-ipc gil: infinispan go-sig:
Fedora rawhide compose report: 20200106.n.0 changes
OLD: Fedora-Rawhide-20200105.n.0 NEW: Fedora-Rawhide-20200106.n.0 = SUMMARY = Added images:0 Dropped images: 0 Added packages: 0 Dropped packages:0 Upgraded packages: 60 Downgraded packages: 0 Size of added packages: 0 B Size of dropped packages:0 B Size of upgraded packages: 2.67 GiB Size of downgraded packages: 0 B Size change of upgraded packages: -13.26 MiB Size change of downgraded packages: 0 B = ADDED IMAGES = = DROPPED IMAGES = = ADDED PACKAGES = = DROPPED PACKAGES = = UPGRADED PACKAGES = Package: ViTables-3.0.2-1.fc32 Old package: ViTables-3.0.0-11.fc32 Summary: Viewer for Hierarchical Datafiles (HDF5) RPMs: vitables vitables-doc Size: 1.80 MiB Size change: 145.08 KiB Changelog: * Sun Jan 05 2020 Zbigniew J??drzejewski-Szmek - 3.0.2-1 - Update to latest bugfix version (#1787834) Package: ccnet-6.1.8-4.fc32 Old package: ccnet-6.1.8-3.fc31 Summary: A framework for writing networked applications in C RPMs: ccnet ccnet-devel Size: 1.12 MiB Size change: -2.71 KiB Changelog: * Sun Nov 03 2019 Julien Enselme - 6.1.8-4 - Make this package compatible with Python 3 Package: coin-or-Ipopt-3.12.13-6.fc32 Old package: coin-or-Ipopt-3.12.13-5.fc32 Summary: Interior Point OPTimizer RPMs: coin-or-Ipopt coin-or-Ipopt-common coin-or-Ipopt-devel coin-or-Ipopt-mpich coin-or-Ipopt-mpich-devel coin-or-Ipopt-openmpi coin-or-Ipopt-openmpi-devel Size: 23.67 MiB Size change: 2.30 KiB Changelog: * Sun Jan 05 2020 Antonio Trande - 3.12.13-6 - New rebuild - Explicit references to mpiblacs are needed on EPEL 7 Package: cross-binutils-2.33.1-2.fc32 Old package: cross-binutils-2.33.1-1.fc32 Summary: A GNU collection of cross-compilation binary utilities RPMs: binutils-aarch64-linux-gnu binutils-alpha-linux-gnu binutils-arc-linux-gnu binutils-arm-linux-gnu binutils-avr32-linux-gnu binutils-bfin-linux-gnu binutils-c6x-linux-gnu binutils-cris-linux-gnu binutils-frv-linux-gnu binutils-h8300-linux-gnu binutils-hppa-linux-gnu binutils-hppa64-linux-gnu binutils-ia64-linux-gnu binutils-m32r-linux-gnu binutils-m68k-linux-gnu binutils-metag-linux-gnu binutils-microblaze-linux-gnu binutils-mips64-linux-gnu binutils-mn10300-linux-gnu binutils-nios2-linux-gnu binutils-openrisc-linux-gnu binutils-powerpc64-linux-gnu binutils-powerpc64le-linux-gnu binutils-ppc64-linux-gnu binutils-ppc64le-linux-gnu binutils-riscv64-linux-gnu binutils-s390x-linux-gnu binutils-score-linux-gnu binutils-sh-linux-gnu binutils-sparc64-linux-gnu binutils-tile-linux-gnu binutils-x86_64-linux-gnu binutils-xtensa-linux-gnu cross-binutils-common Size: 320.20 MiB Size change: -4.53 MiB Changelog: * Mon Jan 06 2020 Peter Robinson - 2.33.1-2 - sync with binutils 2.33.1-11 Package: desktopfolder-1.1.2-1.fc32 Old package: desktopfolder-1.1.1-4.20190925git68fb542.fc32 Summary: Bring your desktop back to life RPMs: desktopfolder Size: 2.75 MiB Size change: -4.59 KiB Changelog: * Thu Jan 02 2020 Artem Polishchuk - 1.1.2-1 - Update to 1.1.2 Package: fdupes-1:2.0.0-1.fc32 Old package: fdupes-1:1.6.1-7.fc31 Summary: Finds duplicate files in a given set of directories RPMs: fdupes Size: 257.29 KiB Size change: 105.74 KiB Changelog: * Sun Jan 05 2020 Bj??rn Esser - 1:2.0.0-1 - Update to 2.0.0 (#1787848) Package: glfw-1:3.3.1-3.fc32 Old package: glfw-1:3.3-2.fc31 Summary: A cross-platform multimedia library RPMs: glfw glfw-devel glfw-doc Added RPMs: glfw-doc Size: 1.09 MiB Size change: 274.58 KiB Changelog: * Sun Jan 05 2020 Till Hofmann - 1:3.3.1-1 - Update to 3.3.1 * Sun Jan 05 2020 Till Hofmann - 1:3.3.1-2 - Switch to pkgconfig(*)-style build dependencies - Add missing dependencies of the devel sub-package * Sun Jan 05 2020 Till Hofmann - 1:3.3.1-3 - Add doc sub-package Package: gnome-shell-3.35.3-1.fc32 Old package: gnome-shell-3.35.2-1.fc32 Summary: Window management and application launching for GNOME RPMs: gnome-shell Size: 7.69 MiB Size change: 42.46 KiB Changelog: * Sun Jan 05 2020 Florian M??llner - 3.35.3-2 - Update to 3.35.3 Package: gnome-shell-extensions-3.35.3-1.fc32 Old package: gnome-shell-extensions-3.35.2-1.fc32 Summary: Modify and extend GNOME Shell functionality and behavior RPMs: gnome-classic-session gnome-shell-extension-apps-menu gnome-shell-extension-auto-move-windows gnome-shell-extension-common gnome-shell-extension-drive-menu gnome-shell-extension-horizontal-workspaces gnome-shell-extension-launch-new-instance gnome-shell-extension-native-window-placement gnome-shell-extension-places-menu gnome-shell-extension-screenshot-window-sizer gnome-shell-extension-user-theme gnome-shell-extension-window-list gnome-shell-extension
Re: koji / bodhi issues status update
On Sun, Jan 05, 2020 at 05:27:19PM +0100, Clement Verna wrote: > On Fri, 3 Jan 2020 at 22:41, Kevin Fenzi wrote: > > > As some of you may know, we have been having issues with koji and bodhi > > over the holidays. :( koji would sometimes not tag builds or error them > > with odd error messages and bodhi wasn't pushing updates. > > > > I'm happy to report that the underlying issue seems to be fixed now. > > We hopefully will have a more detailed root cause next week. > > > > However, due to the koji issues builds were in a state where bodhi > > ejected many of them from updates pushes. We are working on cleaning > > up the state of those updates and there's no need for maintainers to do > > anything with those updates at this time. > > > > Once we get the ejected builds cleaned up we should be able to resume > > normal bodhi updates pushes. > > > > Hi all, > > I think that we now have dealt with most of the ejected updates. It seems > that there are still a few rawhide updates stuck in pending so I ll be > looking at unblocking these. > > Please let us know if you believed that we have missed something. Additionally there were a number of builds in koji in "BUILDING" state, even though they had failed/had no active tasks building them. I went ahead and canceled them all, so now maintainers should be able to resubmit or just do a new build. List of those by maintainer is: cabal-rpm-1.0.3-1.fc32 petersen BUILDING cobbler-2.8.5-1.el7 orion BUILDING desktopfolder-1.1.2-1.fc31 atim BUILDING efl-1.23.1-1.fc32spot BUILDING fleet-commander-admin-0.15.0-1.fc30 ogutierrez BUILDING gstreamer1-plugins-bad-free-1.16.2-1.fc32wtaymans BUILDING gstreamer1-plugins-base-1.16.2-2.fc31wtaymans BUILDING heimdal-7.7.0-2.epel8.playground abo BUILDING im-chooser-1.7.3-1.epel8.playground tagoh BUILDING imsettings-1.8.2-1.fc32 tagoh BUILDING js8call-2.1.1-1.fc32 hobbes1069 BUILDING libbpf-0.0.6-1.fc32 jolsa BUILDING libwacom-1.2-2.fc32 whot BUILDING mellowplayer-3.5.8-1.20191227git9fd6cee.fc32 martinkg BUILDING module-build-macros-0.1-1.module_f32+7264+508b1e07 mbs/mbs.fedoraproject.org BUILDING module-build-macros-0.1-1.module_f32+7272+cab9d0cd mbs/mbs.fedoraproject.org BUILDING musique-1.7-1.fc32 lbazan BUILDING mypaint-2.0.0-0.4.beta.0.fc32avsej BUILDING osc-source_validator-0.19-2.fc31 ngompa BUILDING pdf-stapler-1.0.0-1.fc32 aarem BUILDING perl-Config-Model-2.138-1.fc32 eseyman BUILDING python-avocado-74.0-1.module_f31+7253+5196ffdf mbs/mbs.fedoraproject.org BUILDING python-chaospy-3.0.17-1.fc30 lbazan BUILDING python-django-threadedcomments-1.2-8.fc30lbazan BUILDING python-lz4-3.0.2-1.fc30 jgu BUILDING python-lz4-3.0.2-1.fc31 jgu BUILDING python-lz4-3.0.2-1.fc32 jgu BUILDING python-mypy_extensions-0.4.1-5.fc32 ignatenkobrain BUILDING python-paho-mqtt-1.5.0-2.fc31fab BUILDING python-pycares-3.1.0-fix3.1.fc31 fantom BUILDING python-pyelectro-0.1.10-1.fc32 major BUILDING python-versioneer-0.18-2.fc32nonamedotc BUILDING rubygem-pg-1.2.0-1.fc32 jaruga BUILDING ucblogo-6.1-1.fc31 jrincayc BUILDING vertica-python-0.10.1-1.el7 kubo BUILDING I don't want to blindly resubmit in case folks already bumped release and make newer builds. If thats the case, you have nothing to do here. kevin signature.asc Description: PGP signature ___ devel-announce mailing list -- devel-announce@lists.fedoraproject.org To unsubscribe send an email to devel-announce-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:
