Re: wdune/white is available for fedora 32
Why ignore the reviewer and use bundled vcglib? you were asked not to do that. https://bugzilla.redhat.com/show_bug.cgi?id=1658153 You did the vcglib review and never built it https://bugzilla.redhat.com/show_bug.cgi?id=1677989 I have removed the useless unpacked source files, don't abuse fedora git again https://src.fedoraproject.org/rpms/wdune/c/7587b1655b6fa69dd5f6875b85907b067af2e118?branch=master ___ 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
wdune/white is available for fedora 32
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 ___ 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
Michael Catanzaro wrote: > nohang has experimented with PSI, but it actually isn't using PSI > metrics by default because they've proven to be less effective than > hoped for. In theory, using an interactivity measure like PSI should > provide for the best results, but in practice it just hasn't worked out > well. I think this really needs to be handled entirely in the kernel to be effective, because if the interactivity is already down the drain, your userspace PSI monitor will not get to run at all in a reasonable timeframe. I think that to ensure interactivity, the kernel needs to synchronously check the interactivity metrics each and every time it gets a swap-in request, and fail the request (and kill the process, most likely) if the requesting process is known to hurt interactivity too much with its previous requests. Anything asynchronous will just not work, because asynchronous event handlers stop working when the interactivity is too poor. Kevin Kofler ___ 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 wrote: > This is simply not the case. It may be for GNOME, but I haven't tested > that. It definitely is not the case for Plasma. … unless you want to run KMail/Akonadi on it. :-) But yes, Plasma itself works fine with 2 GiB (I haven't actually tested with less than 4 GiB, but you wrote you did and I believe you there), most applications should work too, and if you need an e-mail client, you can run a lightweight one such as Trojitá (Qt-based, fast, and requires less than 50 MiB exclusive memory here, with over 5 mails in my IMAP inbox – if I start scrolling through the inbox, it loads old metadata on demand, growing the memory usage to still less than 100 MiB). And my Core 2 Duo with 4 GiB RAM definitely works fine with Plasma (desktop environment), Falkon (web browser), Trojitá (e-mail client), Krusader (file manager), etc. Kevin Kofler ___ 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: Why does gdb dlopen() librpm instead of linking to it?
On Sat, Jan 4, 2020 at 6:22 PM John Reiser wrote: > > On 1/3/20 22:35 UTC, Neal Gompa wrote: > > On Fri, Jan 3, 2020 at 5:25 PM Jan Kratochvil > > wrote: > >> > >> On Fri, 03 Jan 2020 22:45:52 +0100, Neal Gompa wrote: > >>> Can someone please explain why gdb dlopen()'s librpm instead of just > >>> doing proper compile-time linking? > >[[snip]] > > >> gdb.spec could auto-detect the current librpm version. > > > I think it'd be nice if it auto-detected this stuff. It's weird having > > to go and fix that manually. > > Please do not predict the environment at run time by detecting the environment > at compile time. That is generally safe only for the simplest properties > such as base-level hardware architecture. Detecting the version of some other > package is particularly problematic if the ultimate result is to be > distributed > beyond the datacenter where it was built. Even when the result works, > it facilitates "version creep" of dependencies: requiring version N+1 > (because because a Fedora builder tends to have newest versions) when > version N would suffice. I'm not sure where you got the idea that GDB was somehow special, but it's not. GDB is *inside* the buildroot, and the version of the package being used is *always* inside the chroot. So the compile-time detection *would* always equal what it is used with at runtime. -- 真実はいつも一つ！/ Always, there's only one truth! ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Fedora 32 System-Wide Change proposal (late): Enable EarlyOOM
On Saturday, January 4, 2020 2:29:11 PM MST drago01 wrote: > A modern desktop with apps on top will not run well enough on 2GB, > lets stop pretending it does. This is simply not the case. It may be for GNOME, but I haven't tested that. It definitely is not the case for Plasma. -- John M. Harris, Jr. Splentity ___ 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 1781750] Co-maintainer request (to maintain EPEL8 branch)
https://bugzilla.redhat.com/show_bug.cgi?id=1781750 Fedora Update System changed: What|Removed |Added Status|ON_QA |CLOSED Fixed In Version||perl-MooseX-NonMoose-0.26-1 ||5.el8 Resolution|--- |ERRATA Last Closed||2020-01-04 23:51:13 --- Comment #4 from Fedora Update System --- perl-MooseX-NonMoose-0.26-15.el8 has been pushed to the Fedora EPEL 8 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-de...@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-de...@lists.fedoraproject.org
[Bug 1785501] please build perl-Cairo-GObject for epel 8
https://bugzilla.redhat.com/show_bug.cgi?id=1785501 Bug 1785501 depends on bug 1780871, which changed state. Bug 1780871 Summary: please build perl-Cairo for epel 8 https://bugzilla.redhat.com/show_bug.cgi?id=1780871 What|Removed |Added Status|ON_QA |CLOSED Resolution|--- |ERRATA -- You are receiving this mail because: You are on the CC list for the bug. ___ perl-devel mailing list -- perl-de...@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-de...@lists.fedoraproject.org
[Bug 1780702] Please support an EPEL 8 branch
https://bugzilla.redhat.com/show_bug.cgi?id=1780702 Fedora Update System changed: What|Removed |Added Status|ON_QA |CLOSED Resolution|--- |ERRATA Last Closed||2020-01-04 23:50:48 --- Comment #5 from Fedora Update System --- perl-Net-FTP-AutoReconnect-0.3-28.el8 has been pushed to the Fedora EPEL 8 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-de...@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-de...@lists.fedoraproject.org
[Bug 1781742] Co-maintainer request (to maintain EPEL8 branch)
https://bugzilla.redhat.com/show_bug.cgi?id=1781742 Fedora Update System changed: What|Removed |Added Status|ON_QA |CLOSED Fixed In Version||perl-Exception-Class-TryCat ||ch-1.13-16.el8 Resolution|--- |ERRATA Last Closed||2020-01-04 23:50:58 --- Comment #5 from Fedora Update System --- perl-Exception-Class-TryCatch-1.13-16.el8 has been pushed to the Fedora EPEL 8 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-de...@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-de...@lists.fedoraproject.org
Re: Fedora 32 System-Wide Change proposal (late): Enable EarlyOOM
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. > As I understand in the current setup we are looking more for a controlled > failure scenario rather than for a solution. Yes, it's fair to say this proposal is to make things "less bad". It doesn't improve system responsiveness. Once heavy swap starts, the system is sluggish, stutters, and briefly stalls. This proposal doesn't fix that. There is a lot of room for improvement. > Can we get a specific manual, what users supposed to do, once they trigger > the earlyoom? Does earlyoom help in reporting? Which logs we need to look at? > > Maybe add a section in UX part of the change, or setup a dedicated wiki page? The user shouldn't need to do anything differently than if the kernel oom-killer had triggered. The system journal will contain messages showing what was killed and why: Jan 04 16:05:42 fmac.local earlyoom[4896]: low memory! at or below SIGTERM limits: mem 10 %, swap 10 % Jan 04 16:05:42 fmac.local earlyoom[4896]: sending SIGTERM to process 27421 "chrome": badness 305, VmRSS 42 MiB > Additionally, there was a question during the chat discussion: how the > earlyoom setup will work together with OOMPolicy and any other related > options of systemd units? Will systemd recognize the OOM event? My understanding of systemd OOMPolicy= behavior, is it looks for the kernel's oom-killer messages and acts upon those. Whereas earlyoom uses the same metric (oom_score) as the oom-killer, it does not invoke the oom-killer. Therefore systemd probably does not get the proper hint to implement OOMPolicy= Fedora need to discuss how big of a problem that is, if there's anyway to mitigate it, or tolerate it, weighing the pros of earlyoom for a short period, versus the cons of punting this problem for another release. This proposal does not intend to step on other superseding work in this area, but if it does, it'll be withdrawn. -- 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: Why does gdb dlopen() librpm instead of linking to it?
On 1/3/20 22:35 UTC, Neal Gompa wrote: On Fri, Jan 3, 2020 at 5:25 PM Jan Kratochvil wrote: On Fri, 03 Jan 2020 22:45:52 +0100, Neal Gompa wrote: Can someone please explain why gdb dlopen()'s librpm instead of just doing proper compile-time linking? [[snip]] gdb.spec could auto-detect the current librpm version. I think it'd be nice if it auto-detected this stuff. It's weird having to go and fix that manually. Please do not predict the environment at run time by detecting the environment at compile time. That is generally safe only for the simplest properties such as base-level hardware architecture. Detecting the version of some other package is particularly problematic if the ultimate result is to be distributed beyond the datacenter where it was built. Even when the result works, it facilitates "version creep" of dependencies: requiring version N+1 (because because a Fedora builder tends to have newest versions) when version N would suffice. ___ 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 4, 2020 at 2:30 PM drago01 wrote: > > On Sat, Jan 4, 2020 at 7:32 PM Chris Murphy wrote: > > > > It might be. And it might need to be tweaked. Perhaps 6% for SIGTERM > > and 3% for SIGKILL. Or even 5% and 2.5%. For sure using a percentage > > of RAM and swap is too simplistic. But it's easy for users to > > understand. Something more sophisticated, based on kernel pressure > > stall information would likely be better, and folks are working on > > that. > > Yes that would be a way better metric than a percent value which is > either to close to full ram or to early if you have lots of ram. > 6% of 4GB is 254MB while for 32GB its almost 2GB - killing processes > while you have 2GB left is just wasteful. If there's a swap device, that won't happen. The case where SIGTERM really happens at 10% RAM free, is when there's no swap device. And even though the no swap device configuration is not a default, and explicitly not recommended, right now, by the installer (as in, if you try to do such an installation, it warns you) - it is a configuration we allow, and I happen to know it's somewhat common among developers with systems with lots of RAM expressly because swap thrashing even to SSD results in such poor UX. Consider the following 'vmstat 10' while doing a compile: procs ---memory-- ---swap-- -io -system-- --cpu- r b swpd free buff cache si sobibo in cs us sy id wa st 6 11 4168060 1821580 40 736604 30234 10841 46533 13805 19230 29799 74 12 1 13 0 At this time, the GUI was completely unresponsive, not even the mouse arrow moves, for about 1 minute. Seemingly plenty of RAM and swap, and idle CPU. But rather heavy swap in and out. 10 9 4459648 200912 40 569260 11218 18856 28846 19997 15164 35256 28 9 9 53 0 6 8 4207328 807092 40 636156 26205 16744 35472 18287 20179 34087 62 12 3 23 0 At these two lines, the mouse arrow is stuttering, the GUI is very sluggish, even unresponsive much of the time. Jan 04 15:37:18 fmac.local earlyoom[4896]: mem avail: 1212 of 7865 MiB (15 %), swap free: 4807 of 8195 MiB (58 %) Near the same time. The system is no where near either RAM or swap exhaustion. But swap si/so are high. This is an SSD BTW. Can I get to the compile and force quit? Eventually, it would take a couple minutes. But good progress is being made with the compile during this whole time. earlyoom doesn't SIGTERM this compile until 20 minutes of this behavior. With default settings. So it really isn't solving the sluggish, stuttering problem. But what does happen, is it SIGTERMs the compile before the system gets to a state where essentially all of the work is only swap in and swap out, and no other work is being done. Here is the output (2 week expiration) https://pastebin.com/0iZHNjg7 Retest with no swap at all, and yes, compile gets a SIGTERM when free memory gets to 10% (because swap is already considered to be 0% free, since it doesn't exist). But also? The system isn't under any swap io duress. The system is completely responsive throughout. This is why we see developers giving up on swap partitions entirely. swap-on-ZRAM might be a compromise. That's related issue #120. > > That's not a fix either, it's a work around that papers over the > > problem. Same as earlyoom, except RAM costs money, and may not be an > > option due to hardware limitations. A modern operating system needs to > > know better than to allow unprivileged processes to take down the > > whole system. > > I think you misunderstood me. Yes the OS should behave better than > this but if you are running a server you don't want your DB, web > server to not be reachable because the system run out of memory - the > only way to "fix" that > is to provide enough resources. No amount of OOM killing would help > you here. The system may be up but not the server process the machine > is running for ... Perhaps, but two points: a. this feature is for Workstation. If the Server working group wants to give it a go, that's up to them. But they may prefer experimenting with more server oriented user space oom daemons like recent versions of oomd. And for that use case, Facebook (and others) have investigated this and find that avoiding OOM even by process killing, is far less bad than the system hanging itself. As in better for recovery and better for limited sysadmin resources. There's a video about it from the recent All Systems Go conference. b. earlyoom does SIGTERM first, I have yet to see a single process (hundreds of tests, but that's really nothing, and also not a scientific sample) that doesn't respond to SIGTERM, where SIGKILL is needed. > > > And btw we should really update the minimum memory requirements in our > > > documentation, the current ones have nothing to do with reality (if you > > > want a pleasant user experience). > > > > Can you be more specific? > > > > On getfedora.org it reads: > > Fedora requires a minimum of 20
Re: Fedora 32 System-Wide Change proposal (late): Enable EarlyOOM
On Sat, Jan 4, 2020 at 7:32 PM Chris Murphy wrote: > > On Sat, Jan 4, 2020 at 4:48 AM drago01 wrote: > > > > > > > > On Saturday, January 4, 2020, Neal Gompa wrote: > >> > >> On Sat, Jan 4, 2020 at 2:33 AM Vitaly Zaitsev via devel > >> wrote: > >> > > >> > On 03.01.2020 22:27, Neal Gompa wrote: > >> > > and servers... > >> > > >> > Admins will be very happy when such user-space killer will kill for > >> > example PgSQL database server and cause DB corruption or loss of banking > >> > transactions. > >> > > >> > >> This is already happening anyway. The idea is that earlyoom will just > >> do it slightly earlier so we have a responsive system when the > >> failures happen. Unlike a lot of the other options, earlyoom is just > >> doing what the kernel does, just slightly earlier so that the system > >> doesn't become unresponsive. > >> > >> > >> > >> That is *hugely* valuable for sysadmins > >> to be able to recover the systems without power cycling. As a sysadmin > >> myself, I *hate* power cycling servers because it takes forever and > >> its a lot bigger loss of productivity (and potentially money! > > > > > > Except that slightly earlier is way to early on systems which have lots of > > memory (see mails from before). > > It might be. And it might need to be tweaked. Perhaps 6% for SIGTERM > and 3% for SIGKILL. Or even 5% and 2.5%. For sure using a percentage > of RAM and swap is too simplistic. But it's easy for users to > understand. Something more sophisticated, based on kernel pressure > stall information would likely be better, and folks are working on > that. Yes that would be a way better metric than a percent value which is either to close to full ram or to early if you have lots of ram. 6% of 4GB is 254MB while for 32GB its almost 2GB - killing processes while you have 2GB left is just wasteful. > > > > And if a server runs into a oom situation your software is either broken > > (leaking) or you didn't allocate enough resources for your use case. > > > > So the fix is not oom killing nor power cycling but to either allocate more > > memory of it is a VM or buy more if it is a hardware server (or fix the > > memory leak in your software). > > That's not a fix either, it's a work around that papers over the > problem. Same as earlyoom, except RAM costs money, and may not be an > option due to hardware limitations. A modern operating system needs to > know better than to allow unprivileged processes to take down the > whole system. I think you misunderstood me. Yes the OS should behave better than this but if you are running a server you don't want your DB, web server to not be reachable because the system run out of memory - the only way to "fix" that is to provide enough resources. No amount of OOM killing would help you here. The system may be up but not the server process the machine is running for ... > > > And btw we should really update the minimum memory requirements in our > > documentation, the current ones have nothing to do with reality (if you > > want a pleasant user experience). > > Can you be more specific? > > On getfedora.org it reads: > Fedora requires a minimum of 20GB disk, 2GB RAM, to install and run > successfully. Double those amounts is recommended. I simply do not think 2GB is sufficient, the "recommended double" i.e 4GB should be the "required" and drop the double part all together. A modern desktop with apps on top will not run well enough on 2GB, lets stop pretending it does. But anyways that's off topic as it is not part of the proposal. ___ 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: koji / bodhi issues status update
On Sat, Jan 4, 2020 at 2:37 AM Mattia Verga via devel wrote: > There are also a bunch of broken updates in Bodhi which were created without > any build. Here it is a list of aliases: [snip] > FEDORA-2019-98ef2a04fc created by jjames > FEDORA-2019-f57b34f7a0 created by jjames Both of these appear to have been updates for gap-pkg-crypting 0.10, one for Fedora 30 and one for Fedora 31. I have no idea how they were created without builds, but that version of the package went stable quite awhile ago. -- Jerry James http://www.jamezone.org/ ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Fedora 32 System-Wide Change proposal (late): Enable EarlyOOM
On Sat, Jan 4, 2020 at 11:20 AM John M. Harris Jr wrote: > > On Saturday, January 4, 2020 11:16:24 AM MST Michael Catanzaro wrote: > > On Fri, Jan 3, 2020 at 5:52 pm, John M. Harris Jr > > wrote: > > > > > In that case, I'd suggest waiting the 15 minutes, and then not > > > bogging down > > > your system that badly the next time. This is, really, the best > > > option. > > > > > > I'm going to suggest you stop replying in this thread if you're not > > interested in responding with productive comments. > > > > The user experience requirement here is "desktop should not hang for 15 > > minutes when under memory pressure." Your comment indicates that it > > *should* hang, presumably to punish users for using too much memory. > > This is so absurd that I don't think you're engaging in good-faith > > discussion anymore. > > Whether or not it should or should not is irrelevant. I don't see much of an > alternative than what seems to be a "hang", honestly. It has nothing to do > with something to "punish" users, it's to get the system to a state where you > can `sync` and reboot. The point of this feature proposal is precisely to get the system into a state where they can save their work and do a proper reboot. It's safer, less esoteric, and more reliable than sysrq+b. It cannot become a user's burden to know the kernel is still doing something, when there's zero feedback and zero control. When will the system recover on its own? An hour? A day? A week? I can tell you for sure in my test case, it was consistently stuck for > 30 minutes. I let it go that long, many times, only to demonstrate it's not a temporary hang, and users are acting rationally to force power off. -- 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 Saturday, January 4, 2020 11:31:49 AM MST Chris Murphy wrote: > A modern operating system needs to > know better than to allow unprivileged processes to take down the > whole system. Well, you can configure quotas if you really want, but the idea is that it's YOUR COMPUTER, and you should be able to use it however you like. If you want to run software that requires more RAM than your system has, you can do that, and it will run, just not well. -- John M. Harris, Jr. Splentity ___ 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 4, 2020 at 4:48 AM drago01 wrote: > > > > On Saturday, January 4, 2020, Neal Gompa wrote: >> >> On Sat, Jan 4, 2020 at 2:33 AM Vitaly Zaitsev via devel >> wrote: >> > >> > On 03.01.2020 22:27, Neal Gompa wrote: >> > > and servers... >> > >> > Admins will be very happy when such user-space killer will kill for >> > example PgSQL database server and cause DB corruption or loss of banking >> > transactions. >> > >> >> This is already happening anyway. The idea is that earlyoom will just >> do it slightly earlier so we have a responsive system when the >> failures happen. Unlike a lot of the other options, earlyoom is just >> doing what the kernel does, just slightly earlier so that the system >> doesn't become unresponsive. >> >> >> >> That is *hugely* valuable for sysadmins >> to be able to recover the systems without power cycling. As a sysadmin >> myself, I *hate* power cycling servers because it takes forever and >> its a lot bigger loss of productivity (and potentially money! > > > Except that slightly earlier is way to early on systems which have lots of > memory (see mails from before). It might be. And it might need to be tweaked. Perhaps 6% for SIGTERM and 3% for SIGKILL. Or even 5% and 2.5%. For sure using a percentage of RAM and swap is too simplistic. But it's easy for users to understand. Something more sophisticated, based on kernel pressure stall information would likely be better, and folks are working on that. > > And if a server runs into a oom situation your software is either broken > (leaking) or you didn't allocate enough resources for your use case. > > So the fix is not oom killing nor power cycling but to either allocate more > memory of it is a VM or buy more if it is a hardware server (or fix the > memory leak in your software). That's not a fix either, it's a work around that papers over the problem. Same as earlyoom, except RAM costs money, and may not be an option due to hardware limitations. A modern operating system needs to know better than to allow unprivileged processes to take down the whole system. > And btw we should really update the minimum memory requirements in our > documentation, the current ones have nothing to do with reality (if you want > a pleasant user experience). Can you be more specific? On getfedora.org it reads: Fedora requires a minimum of 20GB disk, 2GB RAM, to install and run successfully. Double those amounts is recommended. -- 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 Saturday, January 4, 2020 4:48:04 AM MST drago01 wrote: > And btw we should really update the minimum memory requirements in our > documentation, the current ones have nothing to do with reality (if you > want a pleasant user experience). That is not necessary, at all. I'm running Fedora on a 2009 Core 2 Duo system with 2 GiB of RAM, and have not had any issues, after disabling the compositor in Plasma. My daily driver is an X200 Tablet with 4 GiB of RAM, similarly. These amounts are more than sufficient for most users, and Firefox has never led my system to an OOM event. The only time I've ever run into an OOM on this system was while compiling some poorly written software (that I wrote, years ago). -- John M. Harris, Jr. Splentity ___ 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 Saturday, January 4, 2020 11:16:24 AM MST Michael Catanzaro wrote: > On Fri, Jan 3, 2020 at 5:52 pm, John M. Harris Jr > wrote: > > > In that case, I'd suggest waiting the 15 minutes, and then not > > bogging down > > your system that badly the next time. This is, really, the best > > option. > > > I'm going to suggest you stop replying in this thread if you're not > interested in responding with productive comments. > > The user experience requirement here is "desktop should not hang for 15 > minutes when under memory pressure." Your comment indicates that it > *should* hang, presumably to punish users for using too much memory. > This is so absurd that I don't think you're engaging in good-faith > discussion anymore. Whether or not it should or should not is irrelevant. I don't see much of an alternative than what seems to be a "hang", honestly. It has nothing to do with something to "punish" users, it's to get the system to a state where you can `sync` and reboot. -- John M. Harris, Jr. Splentity ___ 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 4, 2020 at 12:45 AM wrote: > > В Суб, 04/01/2020 в 08:27 +0100, Vitaly Zaitsev via devel пишет: > > > I'm strongly against adding of any user-space OOM killers to Fedora > > default images. Users should explicitly enable them only when needed. > > Just my 2 cents: i tested early versions of earlyoom and have weird > experience with it: it killing not Chromium or Chromium processes, > instead it killing tiny processes which it shouldn't, probably. I guess > it could kill dnf process as well easily. > > I am skeptically too about enabling such things by default, but in same > time would be nice to massively test this. earlyoom uses oom_score to determine the victim process to SIGTERM and SIGKILL. The same metric used by the kernel oom-killer. I too have seen inexplicable kernel oom-killer invoked on processes that should not be targets: sssd, sshd, and even once systemd-journald. This is very weird and I don't have an explanation why any process with a score of 0 is getting killed before the dozens of processes with a score much higher, and yet I've seen it. It's suspicious. The nice thing about earlyoom, even though it's a hammer? It's a small hammer. It's not going to go on a wrecking ball spree. It can, and likely will, be backed out as other solutions become more useful. And the documentation reflects its oversimplification of a complex problem. -- 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 Friday, January 3, 2020 11:34:13 PM MST Andreas Tunek wrote: > Den lör 4 jan. 2020 kl 01:53 skrev John M. Harris Jr : > > On Friday, January 3, 2020 4:25:20 PM MST Chris Murphy wrote: > > > in the cases were I could issue syrq+b, responsiveness was so bad > > > it'd take upwards of 15 minutes just to type out the command > > > > In that case, I'd suggest waiting the 15 minutes, and then not bogging > > down > > your system that badly the next time. This is, really, the best option. > > *Remembers to be excellent to each other.* > Or maybe we should try to make operating systems that actually work under > heavy load. If we had something that would "actually work under heavy load" (we do, but it doesn't work for some people), then my advice wouldn't be necessary. However, what I've said is for the safety of your installed system. It should only be followed if the integrity of your data is important to you. -- John M. Harris, Jr. Splentity ___ 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 4, 2020 at 11:38 am, Zbigniew Jędrzejewski-Szmek wrote: What about using the memory controller for user units to allocate memory resources between the processes in the user session? Thanks to recent developments, the gnome session uses separate systemd units (and thus separate cgroups) for various services. We could set attributes like memory.low for "the basic components of the user session", and on the other hand, memory.swap.max for "the payload", i.e. various user processes on top. This looks interesting. I'd love to see more serious discussion of this proposal. Carving out dedicated memory for essential desktop processes seems like something we should be able to do in 2020. 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 Fri, Jan 3, 2020 at 5:52 pm, John M. Harris Jr wrote: In that case, I'd suggest waiting the 15 minutes, and then not bogging down your system that badly the next time. This is, really, the best option. I'm going to suggest you stop replying in this thread if you're not interested in responding with productive comments. The user experience requirement here is "desktop should not hang for 15 minutes when under memory pressure." Your comment indicates that it *should* hang, presumably to punish users for using too much memory. This is so absurd that I don't think you're engaging in good-faith discussion anymore. ___ 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 11:12 pm, Tom Seewald wrote: I think this would be a really big improvement for workstation and other desktop spins, the handling of out of memory situations have been a consistent paint point on Linux. However, may I ask why EarlyOOM was chosen over something like NoHang [1]? I am a bit concerned that EarlyOOM's heuristics may be too coarse, as it does not take into account the newly-added PSI metrics [2][3] that other projects like NoHang, oomd, and low-memory-monitor utilize. For example, if the system is thrashing, but swap is not full, to my knowledge EarlyOOM will not see a problem, however it would be visible via PSI. We've been working closely with Alexey, the maintainer of nohang, on this proposal. He has recommended using either earlyoom or nohang as the two best choices over other available options (e.g. oomd, or low-memory-monitor). I'm not completely certain why earlyoom was chosen over nohang, but I think simplicity and code maturity were likely important considerations in the final choice. nohang has experimented with PSI, but it actually isn't using PSI metrics by default because they've proven to be less effective than hoped for. In theory, using an interactivity measure like PSI should provide for the best results, but in practice it just hasn't worked out well. In our experiments, low-memory-monitor is currently significantly worse at handling OOM conditions (as has been noted elsewhere in this thread). Although we're likely to enable low-memory-monitor in Workstation, we would use it only for advisory memory pressure notifications (GMemoryMonitor). 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
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. 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
ntl soname bump
ntl 11.4.2 has been released. Upstream has a policy of bumping the soname on every release, so all dependent packages must be rebuilt. I will take care of all the rebuilds. I do not anticipate any problems as it looks like the only API change is the addition of 2 functions. Packages to be rebuilt: Macaulay2 Singular eclib flint giac latte-integrale linbox pynac sagemath Although sagemath cannot currently be rebuilt because it depends on jmol, which depends on icedtea-web, which depends on tagsoup, which has been retired due to being orphaned for more than 6 weeks. -- 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
Fedora rawhide compose report: 20200104.n.1 changes
OLD: Fedora-Rawhide-20200103.n.0 NEW: Fedora-Rawhide-20200104.n.1 = SUMMARY = Added images:11 Dropped images: 0 Added packages: 3 Dropped packages:3 Upgraded packages: 86 Downgraded packages: 0 Size of added packages: 110.19 MiB Size of dropped packages:1.52 MiB Size of upgraded packages: 2.12 GiB Size of downgraded packages: 0 B Size change of upgraded packages: 175.47 MiB Size change of downgraded packages: 0 B = ADDED IMAGES = Image: Games live x86_64 Path: Labs/x86_64/iso/Fedora-Games-Live-x86_64-Rawhide-20200104.n.1.iso Image: Cloud_Base raw-xz s390x Path: Cloud/s390x/images/Fedora-Cloud-Base-Rawhide-20200104.n.1.s390x.raw.xz Image: Container_Base docker s390x Path: Container/s390x/images/Fedora-Container-Base-Rawhide-20200104.n.1.s390x.tar.xz Image: Cloud_Base qcow2 s390x Path: Cloud/s390x/images/Fedora-Cloud-Base-Rawhide-20200104.n.1.s390x.qcow2 Image: Cloud_Base vmdk s390x Path: Cloud/s390x/images/Fedora-Cloud-Base-Rawhide-20200104.n.1.s390x.vmdk Image: Container_Minimal_Base docker s390x Path: Container/s390x/images/Fedora-Container-Minimal-Base-Rawhide-20200104.n.1.s390x.tar.xz Image: Server dvd s390x Path: Server/s390x/iso/Fedora-Server-dvd-s390x-Rawhide-20200104.n.1.iso Image: Server boot s390x Path: Server/s390x/iso/Fedora-Server-netinst-s390x-Rawhide-20200104.n.1.iso Image: Everything boot s390x Path: Everything/s390x/iso/Fedora-Everything-netinst-s390x-Rawhide-20200104.n.1.iso Image: Xfce live x86_64 Path: Spins/x86_64/iso/Fedora-Xfce-Live-x86_64-Rawhide-20200104.n.1.iso Image: SoaS live x86_64 Path: Spins/x86_64/iso/Fedora-SoaS-Live-x86_64-Rawhide-20200104.n.1.iso = DROPPED IMAGES = = ADDED PACKAGES = Package: python-flask-socketio-4.2.1-2.fc32 Summary: Socket.IO integration for Flask applications RPMs:python3-flask-socketio Size:31.92 KiB Package: python-versioneer-0.18-3.fc32 Summary: Easy VCS-based management of project version strings RPMs:python3-versioneer Size:44.22 KiB Package: wdune-1.654-3.fc32 Summary: A graphical X3D/VRML97 editor, simple 3D modeler and animation tool RPMs:wdune wdune-devel wdune-docs wdune-opengl-examples Size:110.12 MiB = DROPPED PACKAGES = Package: audit-viewer-0.7.4-17.fc31 Summary: Audit event viewer RPMs:audit-viewer Size:1.06 MiB Package: ohc-0.6.1-6.fc30 Summary: Java large off heap cache RPMs:ohc ohc-benchmark ohc-core-j8 ohc-javadoc ohc-jmh ohc-parent Size:457.70 KiB Package: python-nose-ignore-docstring-0.2-7.fc32 Summary: Ignore docstring to name tests in nose RPMs:python3-nose-ignore-docstring Size:11.98 KiB = UPGRADED PACKAGES = Package: atoum-3.4.0-2.fc32 Old package: atoum-3.3.0-4.fc31 Summary: PHP Unit Testing framework RPMs: atoum Size: 373.91 KiB Size change: -204 B Changelog: * Thu Jan 02 2020 Remi Collet - 3.4.0-2 - update to 3.4.0 - fix reported version - ignore test suite results with 7.4 for now Package: buildah-1.14.0-0.3.dev.gitc42f440.fc32 Old package: buildah-1.13.0-0.10.dev.git6941254.fc32 Summary: A command line tool used for creating OCI Images RPMs: buildah buildah-tests Size: 89.24 MiB Size change: -19.63 KiB Changelog: * Tue Dec 31 2019 RH Container Bot - 1.14.0-0.1.dev.git726e24d - bump to 1.14.0 - autobuilt 726e24d * Fri Jan 03 2020 RH Container Bot - 1.14.0-0.2.dev.git8d41b83 - autobuilt 8d41b83 * Sat Jan 04 2020 RH Container Bot - 1.14.0-0.3.dev.gitc42f440 - autobuilt c42f440 Package: criu-3.13-5.fc32 Old package: criu-3.13-1.fc32 Summary: Tool for Checkpoint/Restore in User-space RPMs: crit criu criu-devel criu-libs python3-criu Size: 3.35 MiB Size change: -102 B Changelog: * Mon Sep 16 2019 Adrian Reber - 3.13-5 - Update to 3.13 (#1751146) - Drop upstreamed patches - Drop static library - Add compel man-page Package: diffoscope-134-1.fc32 Old package: diffoscope-133-1.fc32 Summary: In-depth comparison of files, archives, and directories RPMs: diffoscope Size: 296.90 KiB Size change: 517 B Changelog: * Mon Dec 30 2019 Zbigniew J??drzejewski-Szmek - 134-1 - Update to latest version (bugfix changes only according to debian changelog) Package: digikam-7.0.0-0.1.beta1.fc32 Old package: digikam-6.4.0-2.fc32 Summary: A digital camera accessing & photo management application RPMs: digikam digikam-devel digikam-doc digikam-libs Size: 584.33 MiB Size change: 164.96 MiB Changelog: * Tue Dec 31 2019 Rex Dieter - 7.0.0-0.1.beta1 - digkam-7.0.0-beta1 - use ninja - (re)enable s390x arch Package: evolution-3.35.3-1.fc32 Old package: evolution-3.35.2-1.fc32 Summary: Mail and calendar client for GNOME RPMs: evolution evolution-bogofilter evolution-devel evolution-devel-docs evolution-help evolution-langpacks evolution-pst evolution-spamassassin Size: 2
Fedora-Rawhide-20200104.n.1 compose check report
No missing expected images. Failed openQA tests: 6/155 (x86_64), 1/2 (arm) Old failures (same test failed in Fedora-Rawhide-20200103.n.0): ID: 506900 Test: x86_64 Server-dvd-iso modularity_tests URL: https://openqa.fedoraproject.org/tests/506900 ID: 506902 Test: x86_64 Server-dvd-iso base_services_start URL: https://openqa.fedoraproject.org/tests/506902 ID: 506915 Test: x86_64 Server-dvd-iso server_cockpit_basic URL: https://openqa.fedoraproject.org/tests/506915 ID: 506943 Test: x86_64 KDE-live-iso base_services_start URL: https://openqa.fedoraproject.org/tests/506943 ID: 506955 Test: arm Minimal-raw_xz-raw.xz install_arm_image_deployment_upload URL: https://openqa.fedoraproject.org/tests/506955 ID: 506963 Test: x86_64 universal install_arabic_language URL: https://openqa.fedoraproject.org/tests/506963 ID: 507033 Test: x86_64 universal install_iscsi URL: https://openqa.fedoraproject.org/tests/507033 Soft failed openQA tests: 87/155 (x86_64) (Tests completed, but using a workaround for a known bug) Old soft failures (same test soft failed in Fedora-Rawhide-20200103.n.0): ID: 506881 Test: x86_64 Server-boot-iso install_default URL: https://openqa.fedoraproject.org/tests/506881 ID: 506882 Test: x86_64 Server-boot-iso install_default@uefi URL: https://openqa.fedoraproject.org/tests/506882 ID: 506886 Test: x86_64 Server-dvd-iso install_repository_nfs_variation URL: https://openqa.fedoraproject.org/tests/506886 ID: 506887 Test: x86_64 Server-dvd-iso install_repository_nfs_graphical URL: https://openqa.fedoraproject.org/tests/506887 ID: 506888 Test: x86_64 Server-dvd-iso install_repository_nfsiso_variation URL: https://openqa.fedoraproject.org/tests/506888 ID: 506889 Test: x86_64 Server-dvd-iso install_default_upload URL: https://openqa.fedoraproject.org/tests/506889 ID: 506890 Test: x86_64 Server-dvd-iso install_repository_hd_variation URL: https://openqa.fedoraproject.org/tests/506890 ID: 506891 Test: x86_64 Server-dvd-iso install_vnc_server URL: https://openqa.fedoraproject.org/tests/506891 ID: 506892 Test: x86_64 Server-dvd-iso install_default@uefi URL: https://openqa.fedoraproject.org/tests/506892 ID: 506894 Test: x86_64 Server-dvd-iso install_vnc_client URL: https://openqa.fedoraproject.org/tests/506894 ID: 506895 Test: x86_64 Server-dvd-iso install_vncconnect_client URL: https://openqa.fedoraproject.org/tests/506895 ID: 506906 Test: x86_64 Server-dvd-iso install_updates_nfs URL: https://openqa.fedoraproject.org/tests/506906 ID: 506911 Test: x86_64 Server-dvd-iso server_realmd_join_kickstart URL: https://openqa.fedoraproject.org/tests/506911 ID: 506914 Test: x86_64 Server-dvd-iso install_vncconnect_server URL: https://openqa.fedoraproject.org/tests/506914 ID: 506920 Test: x86_64 Everything-boot-iso install_default URL: https://openqa.fedoraproject.org/tests/506920 ID: 506921 Test: x86_64 Everything-boot-iso install_default@uefi URL: https://openqa.fedoraproject.org/tests/506921 ID: 506929 Test: x86_64 Workstation-live-iso desktop_update_graphical URL: https://openqa.fedoraproject.org/tests/506929 ID: 506934 Test: x86_64 Workstation-live-iso desktop_printing URL: https://openqa.fedoraproject.org/tests/506934 ID: 506947 Test: x86_64 KDE-live-iso desktop_update_graphical URL: https://openqa.fedoraproject.org/tests/506947 ID: 506952 Test: x86_64 KDE-live-iso desktop_printing URL: https://openqa.fedoraproject.org/tests/506952 ID: 506957 Test: x86_64 Cloud_Base-qcow2-qcow2 cloud_autocloud URL: https://openqa.fedoraproject.org/tests/506957 ID: 506958 Test: x86_64 universal install_ext3 URL: https://openqa.fedoraproject.org/tests/506958 ID: 506959 Test: x86_64 universal install_no_swap URL: https://openqa.fedoraproject.org/tests/506959 ID: 506960 Test: x86_64 universal install_updates_img_local URL: https://openqa.fedoraproject.org/tests/506960 ID: 506961 Test: x86_64 universal install_shrink_ext4 URL: https://openqa.fedoraproject.org/tests/506961 ID: 506964 Test: x86_64 universal install_kickstart_firewall_disabled URL: https://openqa.fedoraproject.org/tests/506964 ID: 506965 Test: x86_64 universal install_anaconda_text URL: https://openqa.fedoraproject.org/tests/506965 ID: 506966 Test: x86_64 universal install_sata@uefi URL: https://openqa.fedoraproject.org/tests/506966 ID: 506967 Test: x86_64 universal upgrade_2_minimal_64bit URL: https://openqa.fedoraproject.org/tests/506967 ID: 506968 Test: x86_64 universal install_shrink_ntfs URL: https://openqa.fedoraproject.org/tests/506968 ID: 506970 Test: x86_64 universal install_xfs URL: https://openqa.fedoraproject.org/tests/506970 ID: 506971 Test: x86_64 universal install_blivet_ext3 URL: https://openqa.fedoraproject.org/tests/506971 ID: 506972 Test: x86_64 universal install_delete_partial@uefi URL: https://openqa.fedoraproject.org/tests/506972 ID: 506974 Test:
Re: glusterfs-7.1 update stuck in pending->testing for 10 days
And now it's just "pending". On Thu, Jan 2, 2020 at 7:40 PM Kevin Fenzi wrote: > On Thu, Jan 02, 2020 at 09:14:30AM -0500, Kaleb Keithley wrote: > > related to bodhi having gone down? > > > > Can someone kick it please? > > I would if I could. This is due to the ongoing koji issues. > > Hopefully bodhi folks are going to look at it tomorrow morning and we > can at least get updates flowing again. > > I'd like to thank everyone for their patience on this, it's been very > frustrating for me personally. ;( I'm sure we will find a fix as more > folks come back from holidays and dig into this issue. > > kevin > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org > ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: peek package
On Sat, 4 Jan 2020 08:36:07 +0100, Vitaly Zaitsev via devel wrote: > > Which is something you can only fix with an RPM Fusion package, > > if you "control" (= build) all depending packages. > > RPM Fusion will need to copy and rebuild all such packages and this is a > huge headache for maintainers and currently forbidden by repo's policy. And yet it would be the only way to do it for some applications and/or libraries. That said, as an ex-livna packager I'm aware of the project goals, so it isn't necessary to refer to the current "policy". ___ 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 Saturday, January 4, 2020, Neal Gompa wrote: > On Sat, Jan 4, 2020 at 2:33 AM Vitaly Zaitsev via devel > wrote: > > > > On 03.01.2020 22:27, Neal Gompa wrote: > > > and servers... > > > > Admins will be very happy when such user-space killer will kill for > > example PgSQL database server and cause DB corruption or loss of banking > > transactions. > > > > This is already happening anyway. The idea is that earlyoom will just > do it slightly earlier so we have a responsive system when the > failures happen. Unlike a lot of the other options, earlyoom is just > doing what the kernel does, just slightly earlier so that the system > doesn't become unresponsive. > > That is *hugely* valuable for sysadmins > to be able to recover the systems without power cycling. As a sysadmin > myself, I *hate* power cycling servers because it takes forever and > its a lot bigger loss of productivity (and potentially money! > Except that slightly earlier is way to early on systems which have lots of memory (see mails from before). And if a server runs into a oom situation your software is either broken (leaking) or you didn't allocate enough resources for your use case. So the fix is not oom killing nor power cycling but to either allocate more memory of it is a VM or buy more if it is a hardware server (or fix the memory leak in your software). 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). And btw we should really update the minimum memory requirements in our documentation, the current ones have nothing to do with reality (if you want a pleasant user experience). ___ 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 03, 2020 at 02:18:40PM -0500, 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. Hi, I'll throw out another idea out here, in hope that people can provide insight. It's something I wanted to look into for a while, but I admit to not having done any research myself, so the approach might be totally useless... What about using the memory controller for user units to allocate memory resources between the processes in the user session? Thanks to recent developments, the gnome session uses separate systemd units (and thus separate cgroups) for various services. We could set attributes like memory.low for "the basic components of the user session", and on the other hand, memory.swap.max for "the payload", i.e. various user processes on top. Doing something like this effectively would most likely require some changes to how we assign processes to cgroups. I still get some processes in "wrong" cgroups: │ ├─gnome-shell-wayland.service │ │ ├─1501571 /usr/bin/gnome-shell │ │ ├─1501606 /usr/bin/Xwayland :0 -rootless -noreset -accessx -core -auth /run/user/1000/.mutter-Xwaylandauth.SCXID0 -listen 4 -listen 5 -displayfd 6 │ │ ├─1501713 ibus-daemon --panel disable -r --xim │ │ ├─1501718 /usr/libexec/ibus-dconf │ │ ├─1501719 /usr/libexec/ibus-extension-gtk3 │ │ ├─1501724 /usr/libexec/ibus-x11 --kill-daemon │ │ ├─1501980 /usr/libexec/ibus-engine-simple │ │ ├─1503586 /usr/lib64/firefox/firefox │ │ ├─1503691 /usr/lib64/firefox/firefox -contentproc -childID 2 -isForBrowser ... │ │ ├─1503701 /usr/lib64/firefox/firefox -contentproc -childID 3 -isForBrowser ... │ │ ├─1503747 /usr/lib64/firefox/firefox -contentproc -childID 4 -isForBrowser ... │ │ ├─1520219 bwrap --args 35 telegram-desktop -- │ │ ├─1520229 bwrap --args 35 xdg-dbus-proxy --args=37 │ │ ├─1520230 xdg-dbus-proxy --args=37 │ │ ├─1520232 bwrap --args 35 telegram-desktop -- │ │ ├─1520233 /app/bin/Telegram -- │ │ ├─1540753 pavucontrol ... (and firefox and anything-running-as-flatpak would be the prime candidates to split out into their own cgroups and build resource limits around...) The cgroup hierarchy is mostly flat (most user services get cgroups directly in the root of the user tree under /sys/fs/cgroup/user.slice/user-nnn.slice/user@nnn.service/). To make resource assignment effective, I would like to see a "basic.slice" (name TBD) that would gather various "core" stuff like gnome-shell-wayland.service, dbus-broker.service, and whatever other services that the graphical session depends on. This would get mimimum memory protections and such. Then there should be "payload.slice", and underneath that all the non-essential services and everything that the user starts from the terminal. What I *don't know* is: how much of an overhead enabling the memory controller has, and whether those resource limits would actually have the desired effect (and more generally, how they should be best set). 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
Re: Fedora 32 System-Wide Change proposal (late): Enable EarlyOOM
On Sat, Jan 4, 2020 at 2:33 AM Vitaly Zaitsev via devel wrote: > > On 03.01.2020 22:27, Neal Gompa wrote: > > and servers... > > Admins will be very happy when such user-space killer will kill for > example PgSQL database server and cause DB corruption or loss of banking > transactions. > This is already happening anyway. The idea is that earlyoom will just do it slightly earlier so we have a responsive system when the failures happen. Unlike a lot of the other options, earlyoom is just doing what the kernel does, just slightly earlier so that the system doesn't become unresponsive. That is *hugely* valuable for sysadmins to be able to recover the systems without power cycling. As a sysadmin myself, I *hate* power cycling servers because it takes forever and its a lot bigger loss of productivity (and potentially money!). -- 真実はいつも一つ！/ Always, there's only one truth! ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Fedora 33 System-Wide Change proposal: binutils 2.34
On Fri, Jan 03, 2020 at 02:28:29PM -0500, Ben Cotton wrote: > https://fedoraproject.org/wiki/Changes/BINUTILS234 > > == Summary == > Rebase the binutils package from version 2.33 to version 2.34. > > == Owner == > * Name: Nick Clifton [https://fedoraproject.org/wiki/User:Nickc] > * Email: ni...@redhat.com > == Contingency Plan == > * Contingency mechanism: (What to do? Who will do it?) Revert to the > 2.33 binutils as currently used in rawhide. This work can be done by > me, should it prove necessary. > > * Contingency deadline: Beta freeze. I think that is too late. I don't expect us to use the contingency plan, but if we have to, e.g. because we discover that there's some issue with the linker output, most likely we'd need to do a partial mass rebuild for binary packages. If we start that at beta freeze, the freeze would be meaningless. Maybe set the contingency deadline at "Change Checkpoint: 100% Code Complete Deadline Tue 2020-02-25", and after that date we commit to ship with the new binutils no matter what. 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
Re: Fedora 32 System-Wide Change proposal (late): Enable EarlyOOM
On Fri, 3 Jan 2020, 20:19 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.
>
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%"
> == Owner ==
> * Name: [[User:chrismurphy| Chris Murphy]]
> * Email: bugzi...@colorremedies.com
>
> == Detailed Description ==
> Workstation working group has discussed "better interactivity in
> low-memory situations" for some months. In certain use cases,
> typically compiling, if all RAM and swap are completely consumed,
> system responsiveness becomes so abysmal that a reasonable user can
> consider the system "lost", and resorts to forcing a power off. This
> is objective a very bad UX. The broad discussion of this problem, and
> some ideas for near term and long term solutions, is located here:
>
> Recent long discussions on "Better interactivity in low-memory
> situations"
> https://pagure.io/fedora-workstation/issue/98
>
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/XUZLHJ5O32OX24LG44R7UZ2TMN6NY47N/
>
>
> Fedora editions and spins, have the in-kernel OOM (out-of-memory)
> manager enabled. The manager's concern is keeping the kernel itself
> functioning. It has no concern about user space function or
> interactivity. This proposed change attempts to improve the user
> experience, in the short term, by triggering the in-kernel process
> killing mechanism, sooner. Instead of the system becoming completely
> unresponsive for tens of minutes, hours or days, the expectation is an
> offending process (determined by oom_score, same as now) will be
> killed off within seconds or a few minutes. This is an incremental
> improvement in user experience, but admittedly still suboptimal. There
> is additional work on-going to improve the user experience further.
>
> Workstation working group discussion specific to enabling earlyoom by
> default
> https://pagure.io/fedora-workstation/issue/119
>
> Other in-progress solutions:
> https://gitlab.freedesktop.org/hadess/low-memory-monitor
>
> Background information on this complicated problem:
> https://www.kernel.org/doc/gorman/html/understand/understand016.html
> https://lwn.net/Articles/317814/
>
> == Benefit to Fedora ==
>
> There are two major benefits to Fedora:
>
> * improved user experience by more quickly regaining control over
> one's system, rather than having to force power off in low-memory
> situations where there's aggressive swapping. Once a system becomes
> unresponsive, it's completely reasonable for the user to assume the
> system is lost, but that includes high potential for data loss.
>
> * reducing forced poweroff as the main work around will increase data
> collection, improving understanding of low memory situations and how
> to handle them better
>
As I understand in the current setup we are looking more for a controlled
failure scenario rather than for a solution.
Can we get a specific manual, what users supposed to do, once they trigger
the earlyoom? Does earlyoom help in reporting? Which logs we need to look
at?
Maybe add a section in UX part of the change, or setup a dedicated wiki
page?
>
> == Scope ==
> * Proposal owners:
> a. Modify {{code|
> https://pagure.io/fedora-comps/blob/master/f/comps-f32.xml.in}}
> to include earlyoom package for Workstation.
> b. Modify {{code|
> https://src.fedoraproject.org/rpms/fedora-release/blob/master/f/80-workstation.preset
> }}
> to include:
>
> # enable earlyoom by default on workstation
> enable earlyoom.service
>
>
> * Other developers:
> Restricted to Workstation edition, unless other editions/spins want to
> opt-in.
>
> * Release engineering: [https://pagure.io/releng/issues #9141] (a
> check of an impact with Release Engineering is needed)
>
> * Policies and guidelines: N/A
> * Trademark approval: N/A
>
> == Upgrade/compatibility impact ==
> earlyoom.service will be enabled on upgrade. An upgraded system should
> exhibit the same behaviors as a clean installed system.
>
> == How To Test ==
> * Fedora 30/31 users can test today, any edition or spin:
> {{code|sudo dnf install earlyoom}}
> {{code|sudo systemctl enable --now earlyoom}}
>
> And then attempt to cause an out of memory situation. Examples:
> {{code|tail /dev/zero}}
> {{code|https://lkml.org/lkml/2019/8/4/15}}
>
> * Fedora Workstation 32 (and Rawhide) users will see this service is
> already enabled. It can be toggled wit
Re: Second attempt: Maintainer contact check for Chris Grau (cgrau)
On Fri, 03 Jan 2020 19:35:36 - "Frank R Dana Jr." wrote: > Paul Howarth wrote, > > > > perl-Time-Piece was obsoleted by the base perl package way back in> > >5.10.0. > > > > perl-Time-Piece-MySQL is an extension to perl-Time-Piece. > > Thanks for the info, Paul! > > ...Does that mean it no longer has any usefulness without > perl-Time-Piece,and should be similarly orphaned/retired? No, when I said that "perl-Time-Piece was obsoleted by the base perl package", I meant that its functionality was absorbed by the main perl package, i.e. the module is now built from the perl SRPM rather than its own SRPM. So perl-Time-Piece still exists, but is not built independently of the perl interpreter itself. So perl-Time-Piece-MySQL is still useful. Paul. ___ 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: koji / bodhi issues status update
> On Fri, Jan 03, 2020 at 11:55:27PM +0100, Kevin Kofler wrote:
>
> Yes, they are all because bodhi started composing them, moved their tags
> and then failed (because koji wasn't tagging things in a timely manner).
>
> So, they need to be retagged back and resubmitted, or bodhi tweaked to
> see that it's already moved tags and continue processing them.
>
> In any case, we plan to do this, so if maintainers could please avoid
> editing/pushing/unpushing/tweaking or moving these around while we try
> and fix it that would be great.
>
> kevin
There are also a bunch of broken updates in Bodhi which were created without
any build. Here it is a list of aliases:
>>> updates = m.Update.query.filter(m.Update.builds==None).all()
>>> len(updates)
36
>>> for update in updates:
... print(f'{update.alias} created by {update.user.name}')
...
FEDORA-2015-13799 created by jgrulich
FEDORA-2015-f7d2f6b77c created by plfiorini
FEDORA-2015-fde9b8aa65 created by plfiorini
FEDORA-2015-084442a526 created by spot
FEDORA-2015-3933d6e71b created by spot
FEDORA-EPEL-2015-56f1789544 created by raveit65
FEDORA-2015-8312a1422c created by sergiomb
FEDORA-EPEL-2015-2d0e7de56f created by orion
FEDORA-2016-52e09c8358 created by raphgro
FEDORA-EPEL-2016-0bc504f81d created by nb
FEDORA-2016-3745a3404a created by mrnuke
FEDORA-2016-9683e48c38 created by mrnuke
FEDORA-2016-19d7f3d798 created by mrnuke
FEDORA-2016-2f3052d543 created by mrnuke
FEDORA-2016-796de36de3 created by raphgro
FEDORA-2016-3122ec6414 created by adelton
FEDORA-2017-37b618a185 created by wtaymans
FEDORA-2019-48c30c6663 created by jhli
FEDORA-2019-1cfe355806 created by jhli
FEDORA-2019-2268266d31 created by ellert
FEDORA-EPEL-2019-d119182890 created by ellert
FEDORA-2019-bef5c0c3c8 created by ellert
FEDORA-EPEL-2019-0a394e5d23 created by ellert
FEDORA-EPEL-2019-e6890f4861 created by ellert
FEDORA-2019-1a9f460ddf created by ellert
FEDORA-2019-0afb6633c8 created by atim
FEDORA-2019-39027b3336 created by remi
FEDORA-2019-240ae9127c created by jgrulich
FEDORA-2019-521db81bfa created by jgrulich
FEDORA-2019-3b596e447b created by jgrulich
FEDORA-2019-e89227ba40 created by jgrulich
FEDORA-2019-12ed3b8473 created by remi
FEDORA-2019-98ef2a04fc created by jjames
FEDORA-2019-f57b34f7a0 created by jjames
FEDORA-2019-110533d946 created by panovotn
FEDORA-2019-3875c36a14 created by eclipseo
___
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
