Re: Idea: Use the latest version of openjdk
On 3/6/21 5:55 PM, Reon Beon via devel wrote: What are the disavatages besides minecraft? Could someone retest with the latest openjdk with minecraft and see if that is still an issue? It has been about 7-8 years since that was an issue. Is there some context to this question? I have openjdk 15 installed on my system. Is there something newer? ___ 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 Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: fedora SRPM auto building
On 1/24/21 10:34 PM, Billa Surendra wrote: I am trying to install RPM on riscv target (QEMU), but its throwing error. Even Though gzip/bzip2/xz are installed in target. Error: */home # uname -a Linux C-DAC 5.4.1 #1 SMP Wed Dec 30 17:01:02 IST 2020 riscv64 GNU/Linux Is this Fedora? The kernel version doesn't look like it. /home # rpm -i calendar-1.28-4.20140613cvs.fc33.riscv64.rpm rpm: no gzip/bzip2/xz magic That's saying something about the file, not whether or not you have those programs. What does "file calendar-1.28-4.20140613cvs.fc33.riscv64.rpm" say? Also "which rpm" and "rpm --version". ___ 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: live respin archive
On 1/24/21 5:40 PM, Sérgio Basto wrote: On Sun, 2021-01-24 at 16:42 -0800, Samuel Sieb wrote: On 1/23/21 1:09 PM, Sérgio Basto wrote: Have we a FedoraRespin-32 ? we might want install a Fedora 32 . Live respins are unofficial and only for the latest release: https://dl.fedoraproject.org/pub/alt/live-respins/ Sorry, about archive of live respins ? and that is my point, instead have only the last release, shouldn't we archive the 3 or 4 previous versions of the live respins ? And about archive , shouldn't we archive 3 or 4 versions ? if last one have a problem, we can check the previous versions ... Not sure what you're referring to here. Maybe: https://dl.fedoraproject.org/pub/archive/fedora/linux/releases/ Also, btw, I think, is not a bad idea archive live spins of old releases Did you look at that link? All the released ISOs are in there. The respins aren't official and aren't archived. But you can start with a released image and add the latest updates for that release. ___ 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: live respin archive
On 1/23/21 1:09 PM, Sérgio Basto wrote: Have we a FedoraRespin-32 ? we might want install a Fedora 32 . Live respins are unofficial and only for the latest release: https://dl.fedoraproject.org/pub/alt/live-respins/ And about archive , shouldn't we archive 3 or 4 versions ? if last one have a problem, we can check the previous versions ... Not sure what you're referring to here. Maybe: https://dl.fedoraproject.org/pub/archive/fedora/linux/releases/ ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Fedora 34 Change: Scale ZRAM to Full Memory Size (Self-Contained Change proposal)
On 1/20/21 8:14 AM, Matthew Miller wrote: On Sun, Jan 17, 2021 at 05:58:45PM +, Zbigniew Jędrzejewski-Szmek wrote: Someone on Fedora Discussion¹ noticed this number and wonders if it's meant to be 8192. Not that it probably matters very much, but, you know, nice round numbers and all. Yep, it was. I'll fix the wiki. On another note, someone asked what "(Note that the device is destroyed and recreated during restart. This means that all pages will be "swapped in", i.e. decompressed. On machines with low memory, rebooting might be a better option.)" means, and I realized I actually have no idea. Does this mean that low memory machines should reboot often? Or is this just about testing after changing settings? That's about changing settings. When restarting the zram service, it has to remove the swap device which forces all the swapped pages back into RAM. This might not be successful if you don't have enough RAM, so if you are using a low memory device, you should reboot instead. Although if you see that you aren't using too much swap, then it could be ok. ___ 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: ShotCut: dependency problems
On 1/10/21 5:47 PM, Jerry James wrote: On Sun, Jan 10, 2021 at 4:41 PM Samuel Sieb wrote: I have no problem with it on F33 or F32. I suspect the actual problem is in one of those other packages that are mentioned. The dnf messages are really hard to figure out, but it looks like there's a long dependency chain possibly ending up with scala. Do you have any blocking of modules? Yes, scala does not install on F33 and was orphaned. I have picked it up and am in the process of getting it to build in Rawhide. Once I've got it working there, I'll work on F33. You'll have to be patient with me, as I am needing to wait for other people to make some changes in their packages, and it is taking a little while to work through those changes. Is it broken on F32 as well? Maybe he could try removing scala for now and see if it will also remove anything important to him. ___ 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: ShotCut: dependency problems
On 1/10/21 2:38 PM, Marius Schwarz wrote: it's impossible to install Shotcut, not as 20.11.28 nor 20.04.12 : I have no problem with it on F33 or F32. I suspect the actual problem is in one of those other packages that are mentioned. The dnf messages are really hard to figure out, but it looks like there's a long dependency chain possibly ending up with scala. Do you have any blocking of modules? - package scala-2.10.6-17.fc32.noarch is filtered out by modular filtering What happens if you add "--allowerasing" to the dnf command? ___ 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: can't install package pipewire-jack-audio-connection-kit
On 1/2/21 1:26 AM, Guido Aulisi wrote: Jack is still in use for professional audio and it cannot be replaced by pipewire, and it is still actively developed. Pipewire just provides another implementation and you can choose which one to use. My understanding from the rest of the discussion is that pipewire *is* replacing both jack and pulseaudio and that all sides are happy about 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: F34 Change proposal: Wayland by Default for KDE Plasma Desktop (System-Wide Change)
On 12/29/20 4:25 PM, przemek klosowski via devel wrote: On 12/29/20 5:20 PM, Michael Catanzaro wrote: I don't think this GNOME bug is in any way related to the topic of whether KDE should default to Wayland So I am confused---I thought it is a problem in Wayland, perhaps in its X11 emulation but still Wayland. Yes, the app is misbehaving, but Wayland should be resistant to this 'fuzzing'. More likely what you're really confused about is something that a lot of people are not aware of. Wayland is a protocol, not a program. I believe there's a library, but the final implementation is done in each window manager. The X11 "emulation" is a program called XWayland that provides an interface layer between the X11 calls and whatever Wayland implementation is currently running. ___ 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: Serial Console with Fedora 33
On 12/13/20 1:58 PM, Steve Dickson wrote: How does one set up a serial console with F33? In the past I would edit kernelopts with grub2-editenv and set "console=tty0 console=ttyS0,115200n8". As well as set the following in /etc/grub2.conf terminal_output console #set timeout=5 serial --unit=0 --speed=115200 --word=8 --parity=no --stop=1 terminal_input serial terminal_output serial But in Fedora 33 there is no kernelopts in the grub2 env, so does one create a serial console in f33? There's a boot loader snippet for each boot entry in /boot/loader/entries/. I think the default kernel cmdline is in /etc/default/grub. ___ 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: Pre-made live image with actual functioning persistent storage?
On 12/11/20 10:57 AM, Adam Williamson wrote: "To include a persistent filesystem for /home, use the --home-size-mb parameter. For example: su -c "livecd-iso-to-disk --home-size-mb 2048 Fedora-Workstation-Live-x86_64-34-1.1.iso /dev/sdX" This will create a 2 GiB filesystem that will be mounted as /home each time the stick is booted, allowing you to preserve data in /home across boots. If it's something you're giving away, you will probably want the "--unencrypted-home" option as well. To enable 'data persistence' support - so changes you make to the entire live environment will persist across boots - add the --overlay- size-mb parameter to add a persistent data storage area to the target stick. For example: su -c "livecd-iso-to-disk --overlay-size-mb 2048 Fedora-Workstation-Live-x86_64-34-1.1.iso /dev/sdX" where 2048 is the desired size (in megabytes) of the overlay. The livecd-iso-to-disk tool will not accept an overlay size value greater than 4095 for VFAT, but for ext[234] filesystems it is only limited by the available space." I have no idea when is the last time anyone tested this. I use this regularly, at least once per release. ___ 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: Future of Fedora Server Edition [was: Re: Fedora 34 Change: Make Fedora CoreOS a Fedora Edition (System-Wide Change)]
On 12/3/20 1:01 PM, Miroslav Suchý wrote: Dne 03. 12. 20 v 20:02 Matthew Miller napsal(a): Mostly the latter. I don't even really care if they end up keeping the distinct os-release and etc. Is this backed by some numbers and analysis? My personal usage is that I create **hundred thousands** VM from Fedora cloud image per year. And I use one or two netinstall images to deploy new home server for me or friend. And one or two runnable images when I persuade someone to try Fedora. Cloud image clearly wins the number by orders of magnitude. But without the later we do not get the penetration and new users. And no one willing to use cloud images. I think you snipped too much and misunderstood the meaning. My understanding is that Matthew is suggesting to merge the cloud and server editions into one thing and there doesn't need to be a distinct os-release for both of them. e.g. the "cloud" has the "server" os-release and is just a differently packaged version of the server edition. He's not saying that one or the other will go away. There just needs to be different marketing of the cloud packaged server edition. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Should the default editor be changed from vi to nano on upgrades to Fedora 33+
On 12/3/20 10:52 PM, Dridi Boukelmoune wrote: puts setting EDITOR environment variable into a file (vim-default-editor.sh for bash, ksh, sh and zsh, vim-default-editor.csh for tcsh and vim-default-editor.fish for fish), which is installed under a specific directory (/etc/profile.d for bash, tcsh, sh, ksh and zsh, /usr/share/fish/vendor_conf.d for fish). It sets EDITOR for all users. Maybe I need to reboot my system for vim to take over again? You will at least need to logout and log back in. ___ 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: Unable to disable SysRq
On 11/16/20 4:25 PM, Robert Marcano via devel wrote: My Fedora 33 kernel.sysrq value is 80, the default at /usr/lib/sysctl.d/50-default.conf say that it should be 16. Created /etc/sysctl.d/99-local.conf with kernel.sysrq=0, but after boot the value is 64, only after a single user mode boot the value stays at 0. Some other thing is enabling the 64 bit, Asked on IRC and another user has 80 on Fedora Workstation and 16 on Server. How can I log what process is changing values on the sysctl variables? or anyone has aon idea of what is happening here? This is a very curious issue. I checked on various computers I have around. All the F32 systems have 16. My one laptop that was installed with the Gnome desktop, but not directly Workstation and has now been upgraded to F33 is still 16. However, two other computers that were installed with F32 Workstation switched to 80 when upgraded to F33. I have not been able to figure out what is causing that, but it does seem to be related to the Workstation config somehow. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Fedora 34 Change proposal: Remove and deprecate nscd in favour of sssd and systemd-resolved (Self-Contained Change)
On 11/15/20 7:31 AM, Lennart Poettering wrote: Implementing this does not come without drawbacks though: right now resolved tries hard to use the same server if at all possible, since we want to use newer DNS features if possible, but many DNS servers (wifi routers, yuck) tend to support them quite badly. This means resolved has an elaborate scheme to learn about the feature set of the DNS servers it contacts. And that can be slow, in particular on servers where we step-by-step have to downgrade to the most minimal of DNS protocols. This learning phase is run only when first contacting some server (and after some grace period). If we'd switch servers all the time, for every single lookup, then we'd start from zero every time, not knowing what the server supports, and thus having to learn about it over and over again. This would hence make all, *every*single* transaction pretty slow. And that sucks. Wouldn't you just need to do it once for each server and cache that info? And why do you need to re-do the learning phase for a server you've already checked? DoT becomes efficient when we can reuse the established TCP/TLS connection for multiple lookups. But if we'd switch servers all the time, then of course there's no reuse of TCP/TLS connections possible. Same thing here. Would it be a problem to keep a connection open for each server? ___ 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: Boot/Install from iso file
On 11/14/20 7:44 PM, Sergio Belkin wrote: Isn't there anyone that tried to do that? :-) Taking into account that Fedora is a distro that is always searching to be on the cutting edge: Don't you think that is somewhat annoying and a thing of the past to install from a usb stick (and not to mention from CD)? It could be nice to download the Fedora ISO to local drive and to install from it in a straightforward fashion... and to rely on some grub alchemy, I really don't see how this is useful, but I did spend some time trying it. The kernel and initrd loaded fine from the iso, but I haven't been able to figure out how to get it to start the installer from there. ___ 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: AVC denied to rpm for rpmdb.sqlite after Fedora 33 upgrade
On 11/1/20 6:55 PM, John Doe wrote:
After Fedora 33 upgrade, I am getting /var/log/audit/audit.log flooded with:
type=AVC msg=audit(1604285139.996:14767): avc: denied { read } for pid=5304 comm="rpm"
name="rpmdb.sqlite" dev="dm-1" ino=4194322
scontext=system_u:system_r:setroubleshootd_t:s0 tcontext=system_u:object_r:var_lib_t:s0 tclass=file
permissive=0
Possibly https://bugzilla.redhat.com/show_bug.cgi?id=1461313
___
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: Where is python3.9-debuginfo?
On 10/20/20 7:19 PM, Orion Poplawski wrote: What am I doing wrong? This is on my rawhide VM. $ sudo dnf --enablerepo=*-debuginfo install python3.9-debuginfo Last metadata expiration check: 0:06:06 ago on Tue 20 Oct 2020 08:08:20 PM MDT. No match for argument: python3.9-debuginfo Error: Unable to find a match: python3.9-debuginfo The simpler method is "dnf debuginfo-install python3.9". (I don't know if the end result will be more successful 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: delta-rpm: -3.1% wasted (3 MB)
On 10/16/20 1:48 AM, Marius Schwarz wrote: while updating for the 5.8.15 kernel with dnf, this message appeared: Gesamt 6.2 MB/s | 93 MB 00:14 Fehlgeschlagen: Delta-RPMs erhöhten die Größe für Updates von 89.6 MB auf 92.7 MB (-3.1% verschwendet)* [ Fail: Delta-RPMs have increased the size of updates from 89.6 MB to 92.7 MB ( -3.1% wasted ) ] means: the delta-rpms increased the downloadsize by 3 MB. I'm pretty sure, this is not intended :) I'm pretty sure that it doesn't use the deltarpms in that case. Did you run the transaction and see any drpms get downloaded? Here are the update packages in question, maybe someone finds this helpful: Not likely to be useful. It's an automated process and in some rare cases the deltarpms aren't helpful. ___ 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: 389ds making a local dns server for local web app.
On 10/15/20 9:36 PM, rodents...@gmail.com wrote: Still the same sir, installing it on Ubuntu 18.04 desktop (Oracle Virtual Box). Following these simple steps. Then why are you emailing this list? It's very much the wrong one. This is the Fedora development list, nothing to do with Ubuntu or 389ds or FreeIPA. If you're wanting to install it on Fedora, then the Fedora users mailing list would be a good option, but not if you're using Ubuntu. https://computingforgeeks.com/install-and-configure-freeipa-server-on-ubuntu/ One thing I noticed with that guide is that they tell you to disable the bind integration which completely defeats the purpose you had for doing this in the first place. Btw, I tried installing it both my non-root and root account sir. I have no idea what you mean by this. https://www.freeipa.org/page/Main_Page is the FreeIPA site. ___ 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: 389ds making a local dns server for local web app.
On 10/15/20 4:45 PM, rodents...@gmail.com wrote: During installation, I encountered these errors. I don't know. I've installed it several times with no problems. I just noticed that in your original email you said you were installing 389ds on Ubuntu. What are you trying to install freeipa on? ___ 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: 389ds making a local dns server for local web app.
On 10/14/20 11:43 PM, rodents...@gmail.com wrote: Hi sir, I installed and configured successfully freeipa. The problem now is I can't login my admin account. No error when running "kinit admin", but when logging in through the web UI, it will return an error message saying "Login failed due to an unknown reason. ". Maybe the browser isn't setup correctly for kerberos. Can you use the username and password instead? ___ 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: 389ds making a local dns server for local web app.
On 10/13/20 10:55 PM, rodents...@gmail.com wrote: Btw sir, if I use freeipa. I won't be needing 389ds anymore? I freeipa is made using 389ds. Am I correct? Yes, freeipa uses 389ds as its backend database. ___ 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: 389ds making a local dns server for local web app.
On 10/13/20 7:57 PM, rodents...@gmail.com wrote: Thanks sir. Actually I have done a project which a came up with a local DNS example.com using bind9 in ubuntu. Now my head requires me to do the same using 389ds. If you're really wanting to use 389ds for this, why don't you just go all the way and use freeipa? That would be easier. ___ 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: Could Bodhi create some temporary repositories before composes are ready?
On 10/6/20 7:26 AM, Pavel Raiskup wrote: On Tuesday, October 6, 2020 10:35:04 AM CEST Mattia Verga via devel wrote: You can let Bodhi client download the builds for you: bodhi updates download --updateid FEDORA-2020-15d324f87c Then dnf install the downloaded builds. Awesome, I didn't know this! Thank you, it would be awesome if each of the update mentioned that command (at least till it is in updates-testing). I wrapped that + createrepo + dnf update into a simple script, if anyone else finds it useful: https://github.com/praiskup/fedora-early-testing/blob/master/fedora-early-testing You don't need that script. Just run "dnf upgrade *" in the directory with the downloaded rpms. dnf will only use the ones that are needed, it won't install everything. ___ 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/33 livedisks do not boot on M$ system(s)
On 10/5/20 11:21 AM, Marius Schwarz wrote: Am 04.10.20 um 21:01 schrieb Samuel Sieb: On 10/4/20 9:36 AM, Marius Schwarz wrote: And still,we do not know why the f33 livedisc does not boot at all when inserted early AND why grub-install /dev/USBDRIVE (correct devicename ofcourse ) is overwriting the ssd boot setup, instead of the usbdrive bootconfig. You can't use "grub2-install /dev/USBDRIVE", that's for non-EFI systems. And as Chris explained, you can't use "grub2-install" either or it will mess things up badly. So, this is a loose-loose-situation. Still, how the heck could the system be installed in the first place, because it was booted with secure-boot enabled? :) I don't understand why you think that would be a problem. You left out the following line. If you have the usb drive EFI partition mounted at /boot/efi, then re-installing "grub2-efi" should fix the grub install on your usb drive. When Fedora is installed on a UEFI system, the "grub2-efi" package is installed which puts grub on the EFI partition where it should be. If you want to fix the grub install, then you need to reinstall that package with the right EFI partition mounted at /boot/efi. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: What package provide qmake?
On 10/5/20 12:55 AM, Robbi Nespu wrote: Unable to find qmake. This program is absolutely essential for building Please ensure the development packages for Qt are installed by using your distribution's package manager. This is actually a tricky program to find, although this line provides a good hint. The name of the program is actually "qmake-qt5" and it's provided by the "qt5-qtbase-devel" which should have been brought in if you've installed any of the other qt5 devel packages you'll be needing as well. ___ 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/33 livedisks do not boot on M$ system(s)
On 10/4/20 9:36 AM, Marius Schwarz wrote: And still,we do not know why the f33 livedisc does not boot at all when inserted early AND why grub-install /dev/USBDRIVE (correct devicename ofcourse ) is overwriting the ssd boot setup, instead of the usbdrive bootconfig. You can't use "grub2-install /dev/USBDRIVE", that's for non-EFI systems. And as Chris explained, you can't use "grub2-install" either or it will mess things up badly. If you have the usb drive EFI partition mounted at /boot/efi, then re-installing "grub2-efi" should fix the grub install on your usb drive. As for why the live image isn't booting, that really seems like a BIOS problem. ___ 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/33 livedisks do not boot on M$ system(s)
On 10/1/20 5:52 AM, Marius Schwarz wrote: Is it possible to boot from the stick and then perform a grub-install with an old grub? This attempt failed too: # grub2-install /dev/sda grub2-install: Fehler: /usr/lib/grub/x86_64-efi/modinfo.sh existiert nicht. Bitte geben Sie --target oder --directory an. and that file seems not to be part of any package. There is only one for "i386-pc". You can't (and must not!) use grub2-install on an EFI system. ___ 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/33 livedisks do not boot on M$ system(s)
On 9/30/20 10:28 PM, Elliott Sales de Andrade wrote: On Wed, 30 Sep 2020 at 18:27, Marius Schwarz wrote: The working/non-working procedure is: Power on ... inserting the stick OK, but why insert the USB stick after power on? Wouldn't it be less trouble to insert beforehand so that the firmware will always see it? He was saying that if he puts the stick in earlier, it's less likely to be able to boot. It's not about the firmware seeing 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: init 5 does not restart NetworkManager
On 9/28/20 6:52 AM, qmail wrote: at an init 3 stance, which has NetworkManager active, i start an init 5. when all is said and done, NetworkManager has been deactivated, IE not restarted bec of the settings in NetworkManager.service . So I have to manually restart NetworkManager. Why is this so? Changing init levels doesn't restart the services. It only starts or stops them to get to the new state. If NetworkManager is stopped, then for some reason it has been specified to be stopped in that run level. Nnumeric levels are deprecated though, you should be using "systemctl isolate" instead. I don't know how the numbers are matched to targets now. # systemctl list-dependencies --reverse NetworkManager NetworkManager.service ● ├─NetworkManager-wait-online.service ● └─multi-user.target ● └─graphical.target ___ 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: F34 Change: Reduce installation media size by improving the compression ratio of SquashFS filesystem (Self-Contained Change)
On 9/15/20 4:46 PM, Kevin Kofler wrote: There still exist connections as slow as 33 kbps. At that speed, 142 MB take at least 10 hours to download (probably more because 1 data byte takes more than 8 raw bits to transfer and because the theoretical speed cannot always be sustained). Depending on when you started the download (which takes a few days overall), that can mean you lose an entire day (if you are not lucky enough that those 10+ extra hours are overnight). I'm curious who would be trying to download a 4GB iso at that speed, considering that would involve tying up their internet connection for at least two weeks. ___ 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: F32 -> F33 upgrade
On 9/13/20 5:10 AM, Marcin Juszkiewicz wrote: On my system it looks like deja-dup/duply/duplicity have a problem with dependencies: [root@puchatek ~]# LANGUAGE=C dnf distrosync --releasever 33 The officially recommended method is "dnf system-upgrade". I often need to add "--allowerasing" to that as well. However, that won't fix this issue. The build history for python-google-api-core appears to be a little messed up: https://koji.fedoraproject.org/koji/packageinfo?packageID=31409 ___ 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: Switching package to fragmented default configuration
On 8/28/20 9:40 PM, John M. Harris Jr wrote: Please don't invent a new logic, especially the one that systemd does. This makes it very difficult to figure out where in the world the configuration file for a given program is. With systemd, sure, it's not so bad, as the System defaults go in /usr/share/. Admin overrides go in /etc. command will tell you where the unit file is. There's no such command for, for example, chronyd, httpd or any other program that itself isn't using such a convoluted configuration system. Even systemd wouldn't work if you blew away / etc. It should. If not, that's where they want to get to. ___ 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: Media key support in F32 / Gnome / systemd
On 8/17/20 2:54 AM, Benjamin Berg wrote: Note that you can also change the power button action in gnome-control- center, power, "Suspend & Power Button", "Power Button Action". This wasn't the power button though. It's the suspend/sleep button. ___ 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: EarlyOOM +ZRAM Only
On 8/15/20 1:32 PM, Sergio Belkin wrote: Nice, my only doubt is why smem and tools alike cannot show those processes using anon pages in swap... I posted a bash command line in an earlier email that will give you that information. ___ 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: calculating process memory usage
On 8/14/20 4:34 PM, Samuel Sieb wrote:
On 8/14/20 1:52 PM, Chris Murphy wrote:
/proc/pid/status
VmHWM or VmRSS + VmSwap
Yes, thank you!
VmHWM is not so useful for this case, but certainly for others.
Comparing with the "top" numbers, the VmRSS total looks slightly high,
depending on how zswap factors in to the numbers.
The VmSwap total is short by about 2GB (out of 12GB).
But that's the information I was looking for. Now I can do some
analysis to figure out what's hogging my (virtual) memory.
And it gave a very unexpected result. The top two offenders are:
/usr/libexec/gnome-shell-calendar-server 3167256 (3GB)
/usr/libexec/evolution-calendar-factory 2006908 (2GB)
They have almost no RSS.
For anyone curious, this is how I did it:
grep VmSwap /proc/*/status | sort -r -n -k 2 | while read name size kb;
do echo "$(readlink /proc/$(echo ${name} | cut -d/ -f 3)/exe) $size";
done | less
That's all one line.
___
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: calculating process memory usage
On 8/14/20 1:52 PM, Chris Murphy wrote: /proc/pid/status VmHWM or VmRSS + VmSwap Yes, thank you! VmHWM is not so useful for this case, but certainly for others. Comparing with the "top" numbers, the VmRSS total looks slightly high, depending on how zswap factors in to the numbers. The VmSwap total is short by about 2GB (out of 12GB). But that's the information I was looking for. Now I can do some analysis to figure out what's hogging my (virtual) memory. ___ 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: calculating process memory usage
On 8/14/20 11:41 AM, Sergio Belkin wrote: Perhaps this ps_mem snippet is useful: 294.8 MiB + 4.7 MiB = 299.4 MiB telegram-desktop.bin 290.3 MiB + 22.1 MiB = 312.4 MiB rocketchat-desktop (5) 323.8 MiB + 9.5 MiB = 333.2 MiB kwin_x11 (9) 344.5 MiB + 1.4 MiB = 345.8 MiB nextcloud 373.2 MiB + 21.2 MiB = 394.4 MiB spotify (5) 416.6 MiB + 1.3 MiB = 417.9 MiB plasma-discover 448.5 MiB + 16.6 MiB = 465.2 MiB MainThread 892.8 MiB + 444.5 KiB = 893.2 MiB packagekitd 1.0 GiB + 8.6 MiB = 1.0 GiB plasmashell 1.9 GiB + 81.0 MiB = 1.9 GiB Web Content (9) - 9.7 GiB = Since you've brought this up, this is a question I've had for a long time. How do you get real memory+swap usage information for processes or is that even possible? Looking in ps or top, the RES is way too small and the VIRT/VSIZE is way too big. ps_mem is also way too small, or at least the total is less than half of the real memory usage. Is there something else using that much memory that isn't processes? buffers and cache don't account for the difference either. ___ 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: EarlyOOM +ZRAM Only
On 8/12/20 12:06 PM, John M. Harris Jr wrote: On Wednesday, August 12, 2020 11:27:37 AM MST Sergio Belkin wrote: mem avail: 337 of 15887 MiB ( 2.13%), swap free:0 of 4095 MiB ( 0.00%) low memory! at or below SIGTERM limits: mem 2.52%, swap 10.00% sending SIGTERM to process 1898342 uid 1000 "zoom": badness 36, VmRSS 721 MiB process exited after 0.0 seconds So I wonder if is advisable using EarlyOOM + ZRAM Only, what do you think? Thanks in advance! Please keep this in mind going forward, and take a moment to consider enabling EarlyOOM in Fedora. As it turns out, EarlyOOM does exactly what it says it does: It kills your programs when you've still got plenty of free memory. Where do you see any evidence of "plenty of free memory". There was nothing left. Maybe there is a bug in the reporting, but it definitely wasn't doing what you say it was. ___ 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: EarlyOOM +ZRAM Only
On 8/12/20 11:27 AM, Sergio Belkin wrote: I 've just had a problem using EarlyOOM + ZRAM. I haven't a disk-based swap partition. I was using mainly Zoom (desktop app) + Firefox + VirtualBox (Debian with 4GB of RAM), and EarlyOOM killed Zoom in the middle of a call :( This is the log: The log of what? Are there no timestamps? mem avail: 399 of 15887 MiB ( 2.51%), swap free: 0 of 4095 MiB ( 0.00%) low memory! at or below SIGTERM limits: mem 2.52%, swap 10.00% sending SIGTERM to process 1899361 uid 1000 "Web Content": badness 315, VmRSS 313 MiB process exited after 2.2 seconds mem avail: 397 of 15887 MiB ( 2.50%), swap free: 0 of 4095 MiB ( 0.00%) low memory! at or below SIGTERM limits: mem 2.52%, swap 10.00% sending SIGTERM to process 1899726 uid 1000 "Web Content": badness 304, VmRSS 80 MiB process exited after 3.7 seconds mem avail: 379 of 15887 MiB ( 2.39%), swap free: 0 of 4095 MiB ( 0.00%) low memory! at or below SIGTERM limits: mem 2.52%, swap 10.00% sending SIGTERM to process 1896099 uid 1000 "Web Content": badness 303, VmRSS 74 MiB process exited after 3.6 seconds mem avail: 335 of 15887 MiB ( 2.11%), swap free: 0 of 4095 MiB ( 0.00%) low memory! at or below SIGTERM limits: mem 2.52%, swap 10.00% sending SIGTERM to process 1899195 uid 1000 "Web Content": badness 303, VmRSS 70 MiB process exited after 3.6 seconds mem avail: 315 of 15887 MiB ( 1.98%), swap free: 0 of 4095 MiB ( 0.00%) low memory! at or below SIGTERM limits: mem 2.52%, swap 10.00% sending SIGTERM to process 1899907 uid 1000 "Web Content": badness 301, VmRSS 27 MiB kill failed: Timer expired mem avail: 288 of 15887 MiB ( 1.81%), swap free: 0 of 4095 MiB ( 0.00%) low memory! at or below SIGTERM limits: mem 2.52%, swap 10.00% sending SIGTERM to process 1898928 uid 1000 "VirtualBoxVM": badness 212, VmRSS 4244 MiB process exited after 0.0 seconds mem avail: 337 of 15887 MiB ( 2.13%), swap free: 0 of 4095 MiB ( 0.00%) low memory! at or below SIGTERM limits: mem 2.52%, swap 10.00% sending SIGTERM to process 1898342 uid 1000 "zoom": badness 36, VmRSS 721 MiB process exited after 0.0 seconds According to this, you were completely out of memory. zoom was the last resort. I wonder what was taking up the memory that even killing the VM didn't free up enough. ___ 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: Media key support in F32 / Gnome / systemd
On 8/8/20 11:30 AM, Christopher wrote: Thanks for the sanity check and for setting me on the right path. This isn't a great user experience, but at least it is *possible* to configure things the way I want. Well, for most users, it's a great experience because the keys do what they say they do. I'm very happy that my suspend key works. :-) And I don't expect to be able to easily map any random key on my keyboard to something else. ___ 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: Media key support in F32 / Gnome / systemd
On 8/8/20 3:52 AM, Christopher wrote: Does anybody know what the current state of media key support is in F32 / Gnome / systemd? Is it currently broken? It works great. I recently bought a Logitech MK270 wireless mouse/keyboard (pretty common), which has a "power" media key, which seems to put my Fedora 32 system to sleep, and it doesn't seem to be possible to disable it in Gnome or in systemd-logind settings. It's possible I'm doing something wrong, but I'm now questioning whether this is just broken in Fedora right now, since nothing I've tried works. That sounds to me like it's doing exactly what it should. What are you expecting it to do? If you go into the Gnome settings Power panel, you could try changing the power key action, but that might only affect the hard power button on the case. An alternative is to use dconf-editor and change the suspend key setting in /org/gnome/settings-daemon/plugins/media-keys/. ___ 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: Btrfs by default, the compression option
On 7/10/20 1:56 AM, Nicolas Mailhot via devel wrote: Le jeudi 09 juillet 2020 à 23:47 +, Zachary Lym a écrit : Yes, it's completely reasonable to not do it. It might seem like a big change on its own, but Btrfs has had native compression for 10+ years, and at least three years for most all of the workloads at Facebook. So it's quite safe. But it has been eating data as recently as 2018 [1] and the Debian wiki warns strongly against using compression that is dated for 2020 [2]. The project will already see a large number of new bugs thanks to the wider breadth of hardware, why throw in an additional variable when you can flip it on in six months anyway? Compression will increase the risk of data loss, because compression removes data duplication that could be used to reconstruct data in case of corruption. If you add duplication over compression to make it recovery-safe, the wins are not so good. How does that increase the risk? What data duplication is it removing? If your hard drive flips a bit in just about any file, you're not likely to fix it. System files can be replaced easily. Most user important files are already compressed anyway. .jpg, .ogg (.mp3), .odt, etc. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Query on upgrading the Fedora package
On 7/28/20 9:56 PM, Muneendra Kumar M via devel wrote: Can anyone provide the info for the below one. Jonathan Wakely already replied with a detailed explanation. If you still have questions, you should reply to that email with some more details about what you're trying to do and what the problem is. ___ 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: Serial port sniffing?
On 7/19/20 2:23 PM, Richard Shaw wrote: I would like to monitor serial port communications read only, but I haven't found a tool that makes that easy in the Fedora repos. Are you just wanting to listen to what's coming in or do you want to intercept communication between a process and the serial port? ___ 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: Heads up: changing the subject format of change proposal announcements
On 7/16/20 2:37 PM, Ben Cotton wrote: On Thu, Jul 16, 2020 at 4:20 PM Jonathan Wakely wrote: FCP33 seems a bit cryptic. F33 CHANGE is self-explanatory. Agreed. No need to invent initialisms unnecessarily. I could go with something like: F$version Change proposal: $title - $type For example: F33 Change proposal: Replace Linux kernel with BSD kernel - System-Wide The main thing that needs to stand out, from what I've read here, is that it is a change proposal. The version and type are less important from a "looking at the subject quickly" perspective. No, the bigger thing is having the proposal title visible. So this last suggestion is now a big regression nearly back to what it was originally. ___ 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: Heads up: changing the subject format of change proposal announcements
On 7/16/20 1:19 PM, Jonathan Wakely wrote: On 16/07/20 08:39 +, Zbigniew Jędrzejewski-Szmek wrote: On Wed, Jul 15, 2020 at 11:49:13AM -0700, Samuel Sieb wrote: On 7/15/20 3:30 AM, Daniel P. Berrangé wrote: >FCP33: Support PARSEC [Self-Contained] >FCP33: PostgreSQL 31 [Self-Contained] >FCP33: Policy for Modules in Fedora and Fedora ELN [Self-Contained] >FCP33: Golang 1.15 [Late, System-Wide] >FCP33: X.org Utility Deaggregation [Self-Contained] "F33: ..." would be even better. Or "F33 CHANGE: ..." FCP33 seems a bit cryptic. F33 CHANGE is self-explanatory. I think the idea is that most people would know what it is or would find out pretty quickly. The objective is to have sufficient information in the visible subject area of an email client to be able to identify the threads. ___ 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: Heads up: changing the subject format of change proposal announcements
On 7/15/20 3:30 AM, Daniel P. Berrangé wrote: FCP33: Support PARSEC [Self-Contained] FCP33: PostgreSQL 31 [Self-Contained] FCP33: Policy for Modules in Fedora and Fedora ELN [Self-Contained] FCP33: Golang 1.15 [Late, System-Wide] FCP33: X.org Utility Deaggregation [Self-Contained] Yes! ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Enable EarlyOOM on Fedora KDE - Fedora 33 Self-Contained Change proposal
On 7/13/20 8:21 AM, John M. Harris Jr wrote: On Monday, July 13, 2020 1:58:30 AM MST Benjamin Berg wrote: But, I also think that the people proposing this have done quite a lot of testing to find reasonable values for various scenarios. If they have done their job correctly, then EarlyOOM will *not* prevent you from fully utilizing your system memory in most scenarios. By the very nature of the configuration, that's not the case. For example, on my system, for example, it will start sending SIGTERM where I have over 600 MiB free, and will begin to simply kill software when I have over a quarter of a gigabyte left. You keep making this claim as if you actually know. Have you tested it? Have you even heard of someone else testing it that ran into that? ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Fedora 33 Self-Contained Change proposal: Drop mod_php
On 7/11/20 1:09 AM, John M. Harris Jr wrote: It's demonstrably false that php-fpm "saves hundreds" of milliseconds, unless you're counting up every single saved ms over the course of a server's runtime. It's not really faster than mod_php, except in cases where opcache is used, and you can configure opcache with mod_php as well for similar performance gains, Again, did you even look at the linked page? They did performance testing that completely contradicts what you're saying. What proof do you have that php-fpm is not faster than mod_php? You keep claiming that, but haven't provided any evidence. ___ 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 Self-Contained Change proposal: Drop mod_php
On 7/10/20 10:55 PM, John M. Harris Jr wrote: I demonstrated how it adds ~1ms to requests. That's one of the major downsides to using FastCGI, and it's unavoidable. You didn't demonstrate anything, you made an unsubstantiated claim. Did you even look at the link that was given? Regardless of whether or not fastcgi adds 1ms to requests, it saves hundreds more elsewhere. Have you even tried 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: Fedora 33 System-Wide Change proposal: Make nano the default editor
On 7/7/20 12:39 PM, Michael Catanzaro wrote: On Tue, Jul 7, 2020 at 11:26 am, Samuel Sieb wrote: Why do you think it's gone? It's in the "standard" group, so I think it should be installed on anything other than base minimal. I find that it's installed on everything. Warning: @standard is not included at all in Workstation That's good to know for the change proposal then. I never use the Workstation install. I net install either with a kickstart or selecting the options I want, so that would explain why I always end up with nano installed. ___ 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: Make nano the default editor
On 7/7/20 7:56 AM, Michal Schorm wrote: What I miss is the presence of nano in the default installations and images. I strongly believe it was there just a few Fedora releases back, but now, it's gone. Why do you think it's gone? It's in the "standard" group, so I think it should be installed on anything other than base minimal. I find that it's installed on everything. ___ 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: Make btrfs the default file system for desktop variants
On 7/6/20 4:24 PM, Adam Williamson wrote: If you mean the EFI boot manager entry, just renaming the existing one something other than "Fedora" ought to do the trick, I think. So far as /boot/efi goes...well, you have two choices. You can have the two installs share one, or have two separate ones. I *think* both options at least in theory ought to work, I'm not sure if anyone's tested... Adding another EFI partition should work, but I don't see how they could share one. There's a single Fedora directory in there, so each install would overwrite the files of the other. The grub.cfg can only point to one set of boot loader entries. ___ 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: swap on zram
On 7/6/20 1:48 PM, Sergio Belkin wrote: At https://fedoraproject.org/wiki/Changes/SwapOnZRAM#Why_systemd_zram-generator.3F it says: "Do not create swap partition/LV with default installations." I don't understand if it is a description or a prescription :)I mean, can coexist swap partition/LV and zram? Yes, zram is just a compressed block device in RAM and it's being used here as swap. You can have multiple swap devices active at the same time. That's what I'm currently using. I have a zram swap device and a disk swap partition as overflow. But the plan is to avoid having any swap on disk by default. ___ 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: User experience issue on btrfs
On 7/3/20 9:37 AM, Chris Murphy wrote: To give the nodatacow suggestion a try: ## shutdown the database # mkdir /var/lib/mysql2 # chattr +C /var/lib/mysql2 # cp /var/lib/mysql/* /var/lib/mysql2/ # rm /var/lib/mysql/ # mv /var/lib/mysql2/ /var/lib/mysql/ ## resume operation To avoid possible issues, I would suggest this order: # mv /var/lib/mysql/ /var/lib/mysql2/ # mkdir /var/lib/mysql # chattr +C /var/lib/mysql # cp -a /var/lib/mysql2/* /var/lib/mysql/ # rm -rf /var/lib/mysql2/ ___ 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: [Test-Announce] [Test Day] F33 SwapOnZRAM 2020-07-06
On 7/4/20 11:54 AM, Chris Murphy wrote: On Sat, Jul 4, 2020 at 12:28 PM Samuel Sieb wrote: It is available on F31, I have it installed. When I checked the version, I found that it's a module, so you wouldn't see it in that location. You can just dnf install it and it will work. # rpm -q zram-generator zram-generator-0.1.2-1.module_f31+6778+c4fd1ff5.x86_64 My recommendation is to uninstall that one, and install the latest version in koji, including the new 'zram-generator-defaults' package if you want it enabled by default. So the main difference: the permanent/default configuration file is provided by the defaults package which puts a config in a /usr location, and it can be overridden by creating a configuration in /etc. To disable it, either create an empty config in /etc or remove defaults package. If anyone else has trouble finding it in koji like I did, note that the source package is actually "rust-zram-generator": https://koji.fedoraproject.org/koji/packageinfo?packageID=27449 ___ 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: [Test-Announce] [Test Day] F33 SwapOnZRAM 2020-07-06
On 7/4/20 1:35 AM, Mauro Carvalho Chehab wrote: Em Wed, 1 Jul 2020 09:34:18 +0530 Sumantro Mukherjee escreveu: [0] https://fedoraproject.org/wiki/Test_Day:F33_SwapOnZRAM Hmm... it mentions that Fedora 31 would be ok for the tests, but the zram-generator package is not available on Fedora 31: https://dl.fedoraproject.org/pub/fedora/linux/updates/31/Everything/x86_64/Packages/z/ Assuming that CONFIG_ZRAM is enabled on Fedora 31, you should either backport zram-generator packages to Fedora 31 or update the test day page accordingly. It is available on F31, I have it installed. When I checked the version, I found that it's a module, so you wouldn't see it in that location. You can just dnf install it and it will work. # rpm -q zram-generator zram-generator-0.1.2-1.module_f31+6778+c4fd1ff5.x86_64 ___ 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: Remove device-mapper-multipath from the Fedora workstation livecd - Fedora 33 System-Wide Change proposal
On 6/29/20 4:13 PM, John M. Harris Jr wrote: On Monday, June 29, 2020 4:03:06 PM MST Neal Gompa wrote: Actually, multipath is used outside of datacenters and enterprise setups. A better solution would be to use Anaconda to include it when configured, and leave it out otherwise.. Anaconda live install architecture does not support post-installation package installs based on user requests or configuration selected at install time. So this would not be possible. Would it be possible to write a plugin to support that, or does Anaconda live install just install every package the live image has? If that wouldn't be trivial, it may be best to just disable it if it's unused, which would leave the functionality for those who use it, without affecting the boot times of those who don't use it. My understanding is that the live install basically copies the live install image onto the hard drive as is and then makes a few configuration tweaks. ___ 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: Disable dmraid.service on first run if no dmraid sets are found - Fedora 33 System-Wide Change proposal
On 6/29/20 3:59 PM, Michael Catanzaro wrote: On Mon, Jun 29, 2020 at 3:37 pm, Samuel Sieb wrote: But that should be running concurrently. Does the plot show anything important waiting for it? Your desktop should be able to load before that service is finished starting. Well notably: plymouth-quit-wait.service. Surely plymouth keeps running until everything else has finished, right? I would hope that gdm tells plymouth to go away or starts a new console anyway, but that would be good to find out. There's no reason for anything to be waiting for abrt to finish loading. ___ 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: Disable dmraid.service on first run if no dmraid sets are found - Fedora 33 System-Wide Change proposal
On 6/29/20 1:57 PM, Michael Catanzaro wrote: On Mon, Jun 29, 2020 at 3:45 pm, Michael Catanzaro wrote: We might need to explicitly disable systemd-udev-settle.service during the system upgrade to turn it off? Doesn't work... I tried 'systemctl disable systemd-udev-settle.service' and rebooted again, and it's still running. I tried 'systemd-analyze plot' and I see it takes 11 seconds during boot! I think the culprit is dmraid-activation.service (not dmraid.service). Did you get the name of the service wrong in the change proposal, or have I misunderstood? Unrelated: looking at my systemd-analyze plot, other startup time offenders are NetworkManager-wait-online.service (9.5 seconds, seems egregious, I wonder why this is necessary?) and grand prize winner abrtd.service (requiring an amazing 30 seconds!) But that should be running concurrently. Does the plot show anything important waiting for it? Your desktop should be able to load before that service is finished starting. ___ 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: NetworkManager keyfile instead of ifcfg-rh - Fedora 33 System-Wide Change proposal
On 6/29/20 11:44 AM, John M. Harris Jr wrote: On Monday, June 29, 2020 11:35:55 AM MST Samuel Sieb wrote: Is there any easy way to convert profiles from ifcfg-rh to keyfile? I don't think that'd be a good idea. The Change shows that ifcfg-rh formatted files will continue to be supported, so it's not required, and there are many people that only know the ifcfg-rh formatted configuration, such as myself. Additionally, there's a lot that could go wrong in yanking config files from one format to the other. I wasn't suggesting this to happen by default. I'm just wondering for my own use if it is possible. ___ 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: NetworkManager keyfile instead of ifcfg-rh - Fedora 33 System-Wide Change proposal
On 6/29/20 9:40 AM, Ben Cotton wrote: https://fedoraproject.org/wiki/Changes/NetworkManager_keyfile_instead_of_ifcfg_rh == Summary == Change the default settings plugin of NetworkManager so that new profiles will be created in keyfile format instead of ifcfg-rh format. Is there any easy way to convert profiles from ifcfg-rh to keyfile? ___ 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: Heads up: changing the subject format of change proposal announcements
On 6/29/20 8:22 AM, Ben Cotton wrote: I will replace "Fedora Change proposal: " with " - Fedora Change proposal" As noted by Milan Crha, the existing format can result in threads that are hard to distinguish when the subject is truncated by the width of the mail client window. Screens are often pretty wide these days, but ~40 characters is still a lot to use. Thank you! This has definitely been a problem on my laptop and even more so on my phone. ___ 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: Make btrfs the default file system for desktop variants
On 6/29/20 12:27 AM, John M. Harris Jr wrote: On Monday, June 29, 2020 12:18:28 AM MST Samuel Sieb wrote: On 6/28/20 11:35 PM, John M. Harris Jr wrote: For the best filesystem ever created, ZFS, I can't say that I agree with your assessment of that value. Having ZFS in Fedora would throw Fedora over the top as being the best Linux distro, hands down. I can count the number of times that having root on ZFS has led to me waiting on kernel updates over the past three years on one hand, and could still do so if I had half as many fingers! How many times are you going to keep mentioning ZFS? It's completely off the table, not allowed, never happening. (I consider the chance of Oracle doing something reasonable to be immeasurably small.) See the relevant section of Mark's email. I also don't see how it'd require Oracle to change anything in order to get OpenZFS into Fedora. You were mentioning ZFS, not OpenZFS. However, it's still the same problem. OpenZFS is CDDL which won't be accepted. The only way that can be changed is if Oracle does something. And as long as OpenZFS is an out-of-tree module, it won't be in Fedora. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Fedora 33 System-Wide Change proposal: Make btrfs the default file system for desktop variants
On 6/28/20 11:35 PM, John M. Harris Jr wrote: For the best filesystem ever created, ZFS, I can't say that I agree with your assessment of that value. Having ZFS in Fedora would throw Fedora over the top as being the best Linux distro, hands down. I can count the number of times that having root on ZFS has led to me waiting on kernel updates over the past three years on one hand, and could still do so if I had half as many fingers! How many times are you going to keep mentioning ZFS? It's completely off the table, not allowed, never happening. (I consider the chance of Oracle doing something reasonable to be immeasurably small.) ___ 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: Make btrfs the default file system for desktop variants
On 6/26/20 2:22 PM, Przemek Klosowski via devel wrote: Even though technically dnf system-upgrade can --download-dir to a location off / it doesn't seem to work with the actual upgrade, so the only way I know is to delete largest packages (flightGear*, piglit*, KiCAD*, ...) and reinstall them after update. Somewhat off-topic, but you can symlink /var/lib/dnf/system-upgrade to somewhere else and all the downloaded packages will be stored there and the upgrade will still work. (As long as the linked storage is automatically mounted at boot.) I've even used a USB flash drive for this. ___ 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: Make nano the default editor
On 6/28/20 10:03 AM, John M. Harris Jr wrote: On Saturday, June 27, 2020 1:06:01 PM MST Igor Raits wrote: On Sat, 2020-06-27 at 09:58 -0700, John M. Harris Jr wrote: I definitely agree on taking out "rhgb quiet", that's annoying as all hell, not knowing what's going on during the boot process. Why does the user need to know what's happening when system boots? So that they know what goes wrong, when something goes wrong. I don't know what users you have, but 95% of the people I've setup with Fedora would be confused or disturbed by the kernel spew during boot and wouldn't have any idea what to do with it if something went wrong. The other 5% (including me) would not want it by default and would be able to enable it if necessary. ___ 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: Make nano the default editor
On 6/26/20 1:13 AM, Jan Kratochvil wrote: On Fri, 26 Jun 2020 09:40:32 +0200, Samuel Sieb wrote: That's only if you start vi without a file. Otherwise, you just get the text of the file on the screen and the bottom line with the filename and cursor position. No info at all about what just happened. OK, I agree. So what about instead of nano to do: cat >>~/.vimrc <:x\'\ to\ save\ file,\ \':q!\'\ to\ quit. EOH It is the most user friendly solution (plus the system still remains to be a UNIX!). If you're going to say that you have to use vim for it to be unix, you're going to start another war with the emacs users. :-) The most user friendly solution is to have nano by default with a very easy way to revert to vim for anyone that knows what they are doing. ___ 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: Make nano the default editor
On 6/26/20 12:44 AM, Jan Kratochvil wrote: On Fri, 26 Jun 2020 09:38:06 +0200, Samuel Sieb wrote: On 6/26/20 12:27 AM, Jan Kratochvil wrote: Some replies also do not like this change, I am not alone. Still it looks like there area really more votes for this change than against it. Fine with me. From all the replies here, yours is the only one I've seen that's really against it. https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/6OPZA57OBV3FPJPGNRYWBROL3WR2B4NG/ That was a pretty mild one, but yes, I see there was another much stronger one against it. But still, there are far more that approve of this change, even the vim users. ___ 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: Make nano the default editor
On 6/26/20 12:42 AM, Jan Kratochvil wrote: On Fri, 26 Jun 2020 03:31:10 +0200, Samuel Sieb wrote: But regardless, that's something to fix in the dnf bash completion scripts, not a reason to completely disable completion as the earlier poster said. TL;DR it regresses the original bash completion feature. This will be always a catch up play. To make it working each completion script would need to be part of the package it is implementing completion for. Additionally it would need to be integrated into the program's commandline parsing as otherwise it will never be 100% matching. There were efforts to I have no idea what you're talking about. The bash completion scripts are generally supplied by the package that they are for: # rpm -qf /usr/share/bash-completion/completions/dnf dnf-4.2.21-1.fc31.noarch I have shown just 'dnf' but if you really want I can find arbitrary number of other such programs and bugs where the completion script implements things differently than the program itself. The dnf one works fine. But if you don't like how specific ones work, then file bugs. This is why IMHO bash-completion is only an experimental unfinished feature and it should not be the default. It's a very useful feature for most people. If you don't like it, then uninstall it. Btw, in the case of dnf or similar situations, you can force file completion by pressing ALT-/ ___ 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: Make nano the default editor
On 6/26/20 12:20 AM, Jan Kratochvil wrote: On Fri, 26 Jun 2020 03:48:56 +0200, Adam Williamson wrote: 3. provides a handy reference of key combos you can use to get help, save the file, and exit. Yes, you have to know that ^O means "ctrl+O", but figuring that out is a lot easier than working out how to drive vi from scratch. After starting 'vi' there is: ~type :help orfor on-line help That's only if you start vi without a file. Otherwise, you just get the text of the file on the screen and the bottom line with the filename and cursor position. No info at all about what just happened. ___ 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: Make nano the default editor
On 6/26/20 12:27 AM, Jan Kratochvil wrote: On Fri, 26 Jun 2020 02:25:24 +0200, Matthew Miller wrote: But, if you don't like our offerings that are targetted that way, I suggest you make a spin or remix that has all of defaults _you_ want. So FESCo has decided and there is no point of discussing this Change, that is how it will be and any resistance is futile? The subject even says it is a "Change _proposal_". Some replies also do not like this change, I am not alone. Still it looks like there area really more votes for this change than against it. Fine with me. From all the replies here, yours is the only one I've seen that's really against it. BTW this change (contrary to other ones I mentioned) is not such a problem as it is overridable in $HOME/.bashrc so it does not really need a distro spin. It's even easier than that. If you read the details, there will be a specific package that you can uninstall to remove the config. ___ 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: Make nano the default editor
On 6/26/20 12:30 AM, Jan Kratochvil wrote: On Fri, 26 Jun 2020 01:34:19 +0200, Samuel Sieb wrote: I agree with your points, but pressing ESC only reverses the "rhgb" part, the kernel output is still "quiet". If the kernel really locks up it is locked up and no keys work anymore. Without "rhgb quiet" one can make a photo of the screen. Is this something that happens to you often? The only very rare times that I've had to deal with this, it's been a consistent lockup, so I just need to remove the "quiet" on the next boot. No need to be spammed for the 99.999% of boots that have no problem. That's a terrible thing for users to see. ___ 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: Make nano the default editor
On 6/25/20 6:48 PM, Adam Williamson wrote: Nothing in vi's default view (if launched with a file, which is what happens in this case) tells you you need to press 'insert' in order to actually edit anything. Nothing in vi's default view tells you you have to type the entirely cryptic sequence ":wq" to save and exit (or gives you any clue how to exit at all). Nothing in vi's default view even *tells you that what you're looking at is a text editor called vi*. vi's intro page tells you a lot of this stuff, but in this scenario you don't *see* its intro page. As much as I personally love using vim, I dread having someone accidentally end up in it. And if I'm trying to help someone remotely, there's no way I want that to happen. I always tell them to use nano because they can figure out how to do simple editing in it. If someone wants to do more advanced editing, then I will introduce them to vim. At work we have these big vim keyboard charts on our walls. ___ 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: Make nano the default editor
On 6/25/20 4:48 PM, Alexander Ploumistos wrote: On Fri, Jun 26, 2020 at 1:40 AM Peter Hutterer wrote: disclaimer: I'm using zsh, not bash but it has the same issue. But IMO you can't really blame it - how is the completion to know that you want to install an RPM in the current directory? The correct way would be dnf install ./some and that completes immediately (on zsh). Does that work on bash? It does. However, if you're trying to avoid typing a path for dnf, you always get a space right after the folder name when you hit and you need to delete it if you want to move further down the tree. For me that's one of the most annoying things with bash completion for dnf. But regardless, that's something to fix in the dnf bash completion scripts, not a reason to completely disable completion as the earlier poster said. ___ 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: Make nano the default editor
On 6/25/20 4:11 PM, Chris Murphy wrote: On Thu, Jun 25, 2020 at 3:38 PM Jan Kratochvil wrote: On Thu, 25 Jun 2020 21:21:37 +0200, Chris Adams wrote: Unless you are doing kernel development, why do you care what the kernel messages say? On my systems, they go by too fast to read anyway. When it locks up (during updating firmware on my Athlon machine) I see just a black screen. When I reboot without rhgb/quiet the problem is not reproducible as it happens only rarely. There are many reasons why kernels sometimes fail to boot, why to give up on troubleshooting? I think we need more complete bug reports about these kinds of problems, and fix them, rather than default to showing startup scroll. I don't have this problem very often and I use rawhide kernels. And where I run stable kernels I can't even remember the last time I needed to see the startup scroll for troubleshooting. It's easy to get it unhidden though - hit Esc. I agree with your points, but pressing ESC only reverses the "rhgb" part, the kernel output is still "quiet". ___ 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: Make nano the default editor
On 6/25/20 10:18 AM, Ben Cotton wrote: ** Modify comps to include nano Fedora wide. "nano" is already included by default. Did you mean this to say you'll include the new "nano-editor" package by default? ** Create a new subpackage of nano, called nano-editor. ** nano-editor to include /usr/lib/environment.d/10-nano.conf, which sets $EDITOR to nano. With this approach, if nano is uninstalled, the configuration will be removed with it. At the same time, installing nano on its own won't install the conf. I understand that lots of people prefer a simple editor, so I'm fine with this change given that I can revert it by removing that one extra package. ___ 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: SELinux question
On 6/24/20 12:03 PM, Iñaki Ucar wrote: Thanks. I found another tutorial (from RedHat) which basically says: 1. Implement your service, give it a new SELinux type and run it. 2. Collect all the complaints from SELinux. 3. Use audit2allow to convert them to rules. 4. Repeat until you don't get any more complaints. And I cannot believe my eyes. Is this *really* the way to implement SELinux policies? It seems like a joke to me. Isn't there any notion of inheritance or something like that? Like, I want my type to have I suppose that's the "easy" way. The better way would be to figure out what permissions and transitions your service needs and write the rules for that. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Regarding behaviour of Gnome and Fedora members
On 6/12/20 3:50 AM, Ty Young wrote: Gnome recently has stirred up controversy lately and aren't taking other people's opinions very well, to say the least. So far they've locked three threads: It doesn't look to me like it's Gnome stirring up the controversy and they've been responding very civilly to horrible comments. They have engaged in racism and censorship in their subreddit's comment sections and, just recently, banned me for posting this article, which I've made: https://medium.com/@youngty1997/gnome-needs-to-be-better-2151965fd663 And have since deleted. I don't know what your userid is on reddit, but I certainly don't see anyone from Gnome doing anything wrong. I was planning on fileing a Code of Conduct violation, but GNOME refused to turn over the requested moderation logs, so I couldn't do so and, Gnome's Code of Conduct hints as what the result will be anyway. I have zero confidence that anything will be done, so here I am sending an email. So, could anything be done about any of this? How is this related to Fedora? This is not the place for this. ___ 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: swap-on-ZRAM by default
On 6/9/20 1:57 PM, Dridi Boukelmoune wrote: On Tue, Jun 9, 2020 at 5:43 PM Samuel Sieb wrote: On 6/9/20 6:49 AM, Dridi Boukelmoune wrote: Well, that's really the point. The one you're using is one of the (4? 5?) other zram implementations. It seems a bit more straightforward than the systemd one for sure. The zram-generator is probably more straightforward (with literally less layers of indirection) than what the zram package provides. I would assume that a generator is also the more idiomatic (and efficient) solution as far as systemd is concerned and I wouldn't mind migrating to that if it looked feature-complete and had decent documentation. There is no manual page[1], only a slightly confusing README that hints at simplicity and incompleteness. There's also an example conf file included that has a lot of explanation in it. I'm aware, but the explanation doesn't tell me anything I couldn't infer from the README. Ok, but I don't understand what other documentation there could possibly be. There are only two options to configure and they're both well explained. ___ 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: swap on zram
On 6/9/20 1:43 AM, Marius Schwarz wrote: And ZRAM is one of the tools, that should not be enabled by default anyway. In a best case scenario it extends memory, but in most cases it slows it down. With 16GB there isn't even a use-case for it. It doesn't slow anything down. If you don't use it, it's only taking up a few KB of RAM. If you do end up needing it, it's there and it saves you from slow disk swapping. ___ 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: swap-on-ZRAM by default
On 6/9/20 6:49 AM, Dridi Boukelmoune wrote: Well, that's really the point. The one you're using is one of the (4? 5?) other zram implementations. It seems a bit more straightforward than the systemd one for sure. The zram-generator is probably more straightforward (with literally less layers of indirection) than what the zram package provides. I would assume that a generator is also the more idiomatic (and efficient) solution as far as systemd is concerned and I wouldn't mind migrating to that if it looked feature-complete and had decent documentation. There is no manual page[1], only a slightly confusing README that hints at simplicity and incompleteness. There's also an example conf file included that has a lot of explanation in 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: Fedora 33 System-Wide Change proposal: swap on zram
On 6/6/20 4:55 PM, John M. Harris Jr wrote: On Saturday, June 6, 2020 3:16:02 PM MST Samuel Sieb wrote: Great, then it probably wouldn't benefit you, but it also would not harm you at all either. In my case, my laptop was constantly thrashing the swap and now it isn't, so I'm very happy about it. What was causing it to be constantly thrashing? Instead of breaking traditional systems even further, and ignoring the users' choice during upgrade, why don't we address the actual cause of the problem that some seem to have which led to the suggestion of using zram? There you go with the "breaking" thing again. Nothing is getting broken! If you don't need to use the swap, then you won't even notice it. The only "problem" zram is solving is that disk swap is very slow so if you can keep the swap in ram, everything stays much faster. The cause of thrashing in my case is running several memory heavy applications. I have almost 50 Firefox windows with multiple tabs in each one, so likely 300 tabs open. Multi-process Firefox is very nice but it makes it difficult to get a good memory usage number, but it's probably over 6GB. I have a very large Inbox and many folders which probably contributes to Thunderbird often going to 2 or 3GB. I'm running Discord and various other applications. Did you read the article that Chris posted earlier? You're always going to want swap, so why not start with the very effective zram swap. It's probably all you'll need, but you can add some disk swap as well for any overflow. ___ 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: swap on zram
On 6/6/20 9:27 AM, Richard W.M. Jones wrote: On Sat, Jun 06, 2020 at 01:15:35AM -0700, Samuel Sieb wrote: See, this is a clear indication that you don't understand what it is doing and weren't listening to the various people trying to explain it. Not sure this is needed. The conversation so far has talked about many interesting topics which aren't covered in the proposal, and I value the opinions of people running server / other desktop loads. Sure, but the problem is that he keeps making incorrect claims about it and saying how bad it is and that it shouldn't be used even though multiple people have repeatedly explained that it doesn't work the way he thinks it does. Overall, this has been a great thread. I've now learned how zram works, I've tried it out, and I won't be turning it off. :-) ___ 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: swap on zram
On 6/6/20 10:41 AM, John M. Harris Jr wrote: On Saturday, June 6, 2020 1:15:35 AM MST Samuel Sieb wrote: On 6/6/20 12:42 AM, John M. Harris Jr wrote: On my laptop, a Lenovo X200T with Core(TM)2 Duo CPU U9300; 6 GiB RAM, enabling swap on zram led to increased CPU usage (Always above 13% where normally idling at 6%!), and my entire system freezing after about 30 minutes. In all fairness, I don't know why my system froze, as I couldn't get anything over netconsole and sysrq wasn't working, but I think I'm going to leave it disabled. Swap on disk is more than fast enough for buffer/cache and hibernation/resume on my system. I don't know why you had problems with it, but it's working on fine on every system I've tried it on. It's not increasing my CPU usage. It's probably actually lower due to less swap thrashing. There wasn't any thrashing to begin with. I'm currently using 8.0Mi of my 8 GiB of swap. This is most likely the case for most casual users, those not compiling complex software on their system. This is with Firefox, Konversation, KMail, virt-manager and a few Konsole sessions open. Great, then it probably wouldn't benefit you, but it also would not harm you at all either. In my case, my laptop was constantly thrashing the swap and now it isn't, so I'm very happy about 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: Fedora 33 System-Wide Change proposal: swap on zram
On 6/6/20 9:04 AM, Richard W.M. Jones wrote: On Fri, Jun 05, 2020 at 04:07:44PM -0600, Chris Murphy wrote: This laptop with 8GiB RAM is running two VMs at the same time: Windows 10 and Fedora Workstation 32. The host is Fedora Workstation 32. So this suggests another interesting question: If I have Fedora virtual machines running on a Fedora host, and both are using zram, could there be some negative interaction? ie. With the pages not being compressible twice. I suppose (without looking at the source) that zram will skip compressing a page if the compressed page is not any smaller? I considered this as well. But that would only be a concern if the live memory of the VM is getting swapped out. Is that something that could happen? ___ 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: swap on zram
On 6/6/20 12:42 AM, John M. Harris Jr wrote: On my laptop, a Lenovo X200T with Core(TM)2 Duo CPU U9300; 6 GiB RAM, enabling swap on zram led to increased CPU usage (Always above 13% where normally idling at 6%!), and my entire system freezing after about 30 minutes. In all fairness, I don't know why my system froze, as I couldn't get anything over netconsole and sysrq wasn't working, but I think I'm going to leave it disabled. Swap on disk is more than fast enough for buffer/cache and hibernation/resume on my system. I don't know why you had problems with it, but it's working on fine on every system I've tried it on. It's not increasing my CPU usage. It's probably actually lower due to less swap thrashing. I don't know why people seem to be repeating what seems to be the result of a placebo, saying that their system "feels more responsive" with swap on zram. People seem to be forgetting why swap on zram came up to begin with, it has nothing to do with system "responsiveness", which wasn't an issue. It had to do with dealing with OOM. Swap on zram isn't even a solution to that, it just changes how specifically it affects systems. See, this is a clear indication that you don't understand what it is doing and weren't listening to the various people trying to explain it. It is definitely not a placebo. I gave zram 5G out of the 12G I have and my laptop is performing way better now. It's not thrashing the disk (SSD) every time I switch desktops or windows. Due to the number and size of applications I'm running, I normally have to close Thunderbird when I want to run Chrome. But now I can start Chrome up with no problem. I converted my running system with no reboots and I didn't change anything else about how I'm using the laptop. # zramctl NAME ALGORITHM DISKSIZE DATA COMPR TOTAL STREAMS MOUNTPOINT /dev/zram0 lz4 5G 5G 1.7G 1.8G 4 5GB of swap space that normally would be on disk is now taking less than 2G of RAM. Instead of the usual 6G in the disk swap, now I have less than 2. For servers, swap is useful regardless of the amount of RAM. Swap is very nice for use as buffer/cache, and leaves space in RAM for whatever the server is running. For example, I always configure a 4 GiB swap partition on servers with 8-24 GiB of RAM, and 8 GiB swap for servers with 64-128 GiB, 16 GiB on servers with 128-256 GiB, etc. Beyond that, tuning is a bit different depending on the workload, but it sets a very nice starting point. Swap is never used as buffer or cache, that doesn't even make sense. Buffer is storing data before writing it to disk and cache is keeping hot data somewhere with fast access. Why do you use so much swap on your servers? The linear correlation with RAM is an obsolete idea and was only somewhat valid when memory sizes were smaller. If you're using any significant fraction of that swap space, your server is in trouble. ___ 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: swap on zram
On 6/5/20 11:43 PM, John M. Harris Jr wrote: Completely agreed, going about it this way would also address most of my concerns with this change, as it would mean it's easy for people like myself to opt out. If you don't want it, then disable the generator or uninstall it. I don't understand why you're so against this. It's not even really new. Is it because you don't understand it? Try it, you'll like it. It made such a big difference on my laptop. I'm going to be activating it on my other computers and servers as I get time. Most of the servers have enough RAM to not need swap, but it makes a nice safety net with virtually no overhead. ___ 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: swap on zram
On 6/5/20 7:33 PM, Chris Murphy wrote: On Fri, Jun 5, 2020 at 8:12 PM Samuel Sieb wrote: All three of those listed provide competing configurations for swap on zram. Just to make a fine point, zram is generic, it is not swap specific. It's just a compressed ram disk. Zswap is a different thing, it is swap specific, providing a memory based writeback cache to a disk based swap. Ok, that makes sense about zram. It's a lot simpler than I was thinking it was. The generator does require a reboot to change configurations. You could absolutely say, but Chris, the other ones you can just systemctl restart! That is true, but except for testing, I don't see that as an advantage compared to the overall simplisticity of zram-generator and reusing the existing infrastructure in systemd that's already well tested and maintained. Sure, I'll set that up for the next time I reboot. But that is likely to still be a long time from now. Although really any value higher than the disk based swap is sufficient. The systemd-swap service appears to set the priority of zram to the maximum possible. No, it was quite clear that I was modifying the right config. It's the /etc/systemd/swap.conf as described in the man page and it was affecting the result. OK that is not for zram-generator. That's for one of the others. Off hand I don't know which one it's for, this is way too confusing because of all the competing implementations, which is part of the motivation of the feature -> buh bye, thank you for your service! Sorry, I guess that wasn't clear. That's the config file for systemd-swap which is what I was testing. Part of my concern is that if it's not actually full, then why is it using so much of the disk swap? Not sure. What should be true is if you swapoff on /dev/sda3 it'll move any referenced anon pages to /dev/zram0. And then if you swapon /dev/sda3 it will use 0 bytes until /dev/zram0 is full. What kernel version are you using? That is what I did do. kernel 5.5.17-200.fc31.x86_64 For upstream, do you mean the kernel? Yes. bugzilla.kernel.org - this goes to the linux-mm folks (memory management) but you can search for a zram bug and just see what component they use and post the bug here and I'll pick it up. I reset everything and now I can't reproduce it. I wonder if it was because I had zswap enabled as well. When I was going to file the bug report, I came across a comment that it's not beneficial to use them both at the same time. # swapon NAME TYPE SIZE USED PRIO /dev/sda3 partition 16G 0B-2 /zram0partition 5G 4.6G 32767 # zramctl NAME ALGORITHM DISKSIZE DATA COMPR TOTAL STREAMS MOUNTPOINT /dev/zram0 lz4 5G 4.6G 1.5G 1.5G 4 It looks like it's working properly now. So it seems likely that it was user error. And for the little it matters, I approve of the change proposal. I will have to test it out on my other systems as well 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
Re: Fedora 33 System-Wide Change proposal: swap on zram
On 6/5/20 6:59 PM, Chris Murphy wrote: On Fri, Jun 5, 2020 at 6:47 PM Samuel Sieb wrote: I installed the zram package and noticed the systemd-swap package, so installed that also. There are conflicting implementations: anaconda package provides zram.service zram package provides zram-swap.service systemd-swap package provides Did you leave something out? Are you saying that zram and systemd-swap both provide configuration for zram? I've only casually tested systemd-swap package. Note this isn't an upstream systemd project. Where as the proposed rust zram-generator is "upstream" in that it's maintained by the same folks, but is not provided by systemd package I think because it's in rust. Ok, I was thinking the generator might require rebooting to get it to work. And I saw the systemd-swap package and thought that sounded useful to try. There shouldn't be any weird/bad interactions between them, but it is possible for the user to become very confused which one is working. It *should* be zram-generator because it runs much earlier during boot than the others. But I have not thoroughly tested for conflicting interactions, mainly just sanity testing to make sure things don't blow up. I only started the one service, so I don't think there are any conflicts. I adjusted the zram setting to 4G and reduced zswap a bit. I have no idea what that is doing, it doesn't seem to affect anything I can measure. The overall improvement in responsiveness is very nice. It might be you're modifying the configuration of a different implementation from the one that's actually setting up swaponzram. No, it was quite clear that I was modifying the right config. It's the /etc/systemd/swap.conf as described in the man page and it was affecting the result. I don't understand the numbers I'm getting for these. I disabled my swap partition to force as much to go to zram as possible and then turned it back on. # swapon NAME TYPE SIZE USED PRIO /dev/sda3 partition 16G 1.9G-2 /zram0partition 4G 4G 32767 This looks like I'm using all 4G of allocated space in the zram swap, but: # zramctl NAME ALGORITHM DISKSIZE DATA COMPR TOTAL STREAMS MOUNTPOINT /dev/zram0 lz4 4G 1.8G 658.5M 679.6M 4 This suggests that it's only using 1.8G. Can you explain what this means? Yeah that's confusing. zramctl just gets info from sysfs, but you could double check it by cat /sys/block/zram0/mm_stat The first value should match "DATA" column in zramctl (which reports in MiB). While the kernel has long had support for using up to 32 swap devices at the same time, this is seldom used in practice so it could be an artifact of this? Indicating that all of this swap is "in use" from the swap perspective, where zramctl is telling you the truth about what the zram kernel module is actually using. Is it a cosmetic reporting bug or intentional? Good question. I'll try to reproduce and report it upstream and see what they say. But if you beat me to it that would be great, and then I can just write the email for linux-mm and cite your bug report. :D Part of my concern is that if it's not actually full, then why is it using so much of the disk swap? For upstream, do you mean the kernel? ___ 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: swap on zram
I installed the zram package and noticed the systemd-swap package, so installed that also. I adjusted the zram setting to 4G and reduced zswap a bit. I have no idea what that is doing, it doesn't seem to affect anything I can measure. The overall improvement in responsiveness is very nice. On 6/5/20 3:07 PM, Chris Murphy wrote: $ swapon NAME TYPE SIZE USED PRIO /dev/zram0 partition 3.9G 778M -2 $ zramctl NAME ALGORITHM DISKSIZE DATA COMPR TOTAL STREAMS MOUNTPOINT /dev/zram0 lzo-rle 3.9G 777M 240.4M 249.6M 8 [SWAP] $ In this example, the system evicts 777M, at a cost of 250M, for a total gain of ~527M. I don't understand the numbers I'm getting for these. I disabled my swap partition to force as much to go to zram as possible and then turned it back on. # swapon NAME TYPE SIZE USED PRIO /dev/sda3 partition 16G 1.9G-2 /zram0partition 4G 4G 32767 This looks like I'm using all 4G of allocated space in the zram swap, but: # zramctl NAME ALGORITHM DISKSIZE DATA COMPR TOTAL STREAMS MOUNTPOINT /dev/zram0 lz4 4G 1.8G 658.5M 679.6M 4 This suggests that it's only using 1.8G. Can you explain what this means? ___ 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: broken threads
On 6/5/20 2:14 PM, Zbigniew Jędrzejewski-Szmek wrote: This has been bothering me for a while, it occurs quite often for certain posters to the list, and since Jeff's replies reproduce this issue, let me ask: Why is the threading broken with Jeff's replies to this thread? Looking at the headers, there is no In-reply-to: header. Is this caused by the agent: User-Agent: Evolution 3.36.2 (3.36.2-1.fc32) ? Yes, this was explained earlier. He's getting the list in digest form and Evolution isn't able to break it up properly to set the correct subjects and in-reply-to headers. ___ 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: swap on zram
On 6/5/20 12:18 PM, John M. Harris Jr wrote: Well, that's for the GNOME stuff. This is a system-wide change proposal, is it not? Additionally, you could still be meeting that requirement here, as a new install with the same options selected, that is, to have a swap partition, would disable the zram device. That'd be a nice middleground for users like myself that don't have enough RAM to waste on a zram device. I'm writing this email on a Lenovo ThinkPad X200 Tablet with 6 GiB of RAM, where giving half of my RAM to zram would kill my system's performance, if not quickly cause OOM. I think you've completely missed the technical description of how this works. It does not take more than a tiny bit of RAM when it's not being used. It definitely does not take half your RAM right away. It only starts using RAM when you would otherwise be going into swap. Then it takes those pages that would be going to disk and compresses them so they use less RAM. So no it will not kill your system's performance and will help avoid the OOM condition. ___ 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: Proposal: Install gparted to Live installers
On 6/4/20 9:52 AM, Michael Catanzaro wrote: I don't think we actually have the technical capability to ship it in live media without also installing it by default on the installed system. It currently has to run as root, which is not acceptable, so would require some work to split out privileged operations into a separate backend process and use polkit for authentication. I think it would make more sense to focus on improving Disks to do what you need rather than rewriting GParted. As far as I can tell, it's already using polkit. It asks for authentication before running. On the live image, the user doesn't have a password, so you might not see the dialog. (There was a bug with that previously.) ___ 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: Supporting hibernation in Workstation ed., draft 1
On 6/3/20 12:06 PM, Simo Sorce wrote: On Tue, 2020-06-02 at 21:58 -0700, John M. Harris Jr wrote: Why? Evil maid attacks. Because without a signature you could replace the whole image with a completely functional one that you fully control. Boot the system with a hybernation image generated on identical hardware but with your own data, give your own decryption key, presto, as soon as the hybernation image is restored the system is running your image. From there you could be able to use, for example, keys stored in the TPM or simply you capture the real password for the real image as soon as the user returns to the machine to unlock it and transmit it, and now you have access to the original disk image and all its contents... Again, possibilities abound. Thank you, that is a very clear explanation. ___ 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: Supporting hibernation in Workstation ed., draft 1
On 6/2/20 9:25 PM, Chris Murphy wrote: On Tue, Jun 2, 2020 at 8:33 PM John M. Harris Jr wrote: On Sunday, May 31, 2020 11:45:40 AM MST Chris Murphy wrote: On Sat, May 30, 2020 at 9:26 PM Tony Nelson wrote: On 20-05-30 21:02:11, Chris Murphy wrote: ... Full disk encryption doesn't adequately secure the hibernation image either. Authenticated encryption (signing as well as encryption) is needed to verify the image hasn't been tampered. What can an attacker do other than corrupt the data? It is encrypted. You don't know, and neither do I. That's the problem. We do know. Nothing, really. You do not know the attacker, when possession was lost, what the attacker knows, or how long they have access to ciphertext. And that's because the attack hasn't happened yet. Yet you assert omniscience. Gotcha. I don't understand this concern either. How is it different than any encrypted filesystem? If you don't trust the encryption, then what's the point? What's the difference between an encrypted filesystem and an encrypted hibernation image that makes the image so insecure? ___ 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: Supporting hibernation in Workstation ed., draft 1
On 6/2/20 7:41 PM, John M. Harris Jr wrote: In what way is it incompatible with UEFI Secure Boot? If the kernel and initramfs are signed, and the resume image is for that kernel, how is this an issue? What if swap is on LUKS? Do you understand how hibernation works? It doesn't matter if the booting kernel is signed, everything will be replaced by what's on the disk. The kernel you boot with does not even have to be the same one the hibernated image was booted with. Someone could modify the in-memory image of the kernel on the disk or change some process to be running as root when it's resumed. So it completely bypasses any protection that secure boot provides. I'm inclined to say let me have that insecurity if I want, but I think there are rules about what's allowed if secure boot is enabled. I would expect that using an encrypted partition for swap should be sufficient to allow it 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: F30 security update submitted for stable "marked obsolete" instead of being pushed
On 5/26/20 8:13 PM, John M. Harris Jr wrote: On Tuesday, May 26, 2020 4:08:52 PM MST Miro Hrončok wrote: On 27. 05. 20 0:56, Dominik 'Rathann' Mierzejewski wrote: Can someone explain why my update[1] which was submitted for F30 stable was not pushed but "marked obsolete"? It was a security update, too. Regards, Dominik [1] https://bodhi.fedoraproject.org/updates/FEDORA-2020-2d381e061b Fedora 30 went EOL before the update was pushed to stable. And that killed a *security update*? Seriously? That's what EOL means. Once the switch is flipped, there are no more updates. ___ 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
