Re: F38 proposal: Shorter Shutdown Timer (System-Wide Change proposal)
Fabio Valentini wrote: > Even if systemd prints nice diagnostic messages, they're useless if > nobody is going to see them. > And I doubt that many people know that pressing the Esc key makes > plymouth go away. Quite. Troubleshooting information as an Easter egg! Seriously people, is there some competition to produce the most textless user interface? Björn Persson pgpAmFa7dbrFg.pgp Description: OpenPGP digital signatur ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/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, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: F38 proposal: X Server Prohibits Byte-swapped Clients (System-Wide Change proposal)
On Wed, Dec 28, 2022 at 10:16:45PM -0500, Neal Gompa wrote: > On Wed, Dec 28, 2022 at 10:13 PM Peter Hutterer > wrote: > > > > On Thu, Dec 22, 2022 at 05:41:06AM -0500, Neal Gompa wrote: > > > On Thu, Dec 22, 2022 at 5:30 AM Niklas Schnelle > > > wrote: > > > > > > > > Hi All, > > > > > > > > This might not be as niche as you might think. I'm one of the > > > > Linux kernel maintainers for s390. Many of us do the vast majority of > > > > their development work natively on s390 systems via SSH from Fedora > > > > laptops. After all mainframes are pretty damn fast at compiling with > > > > plenty of memory and dog fooding is part of quality control. And I'm > > > > sure it's not just the teams working on the Linux kernel but also > > > > plenty of other people working with s390 Linux machines. These s390 > > > > machines mostly only host X servers via VNC and usually just for the > > > > installation but they do that too. There is also a hand full of X > > > > clients I run on s390 which are essential for my and many of my > > > > colleagues daily workflows. The most important one is defintely > > > > xsel/xclip to copy from the (neo-)vim/tmux I use for coding to my local > > > > system. Some people also use x3270 via SSH X forwarding from jumphosts, > > > > others use XEmacs. I also know essential internal tools that are run on > > > > s390 hosts via X forwarding. Sure people using X forwarding are capable > > > > of changing configuration defaults but if at all possible I would > > > > suggest to rethink this, as it will create significant hassle for > > > > anyone using their Fedora systems to SSH + X forward to s390 Linux > > > > hosts and it definitely sees more use and thus testing than the > > > > proposal makes it sound. > > > > > > > > > > How bad would it be to force little-endian for the X protocol > > > regardless of architecture? > > > > simply said - not realistic. It's a lot of effort, with zero visible > > benefit beyond the *potential* that we're slightly safer now. Which you > > won't know until you tested it all. > > > > The code works, at least for the bits that are executed. Swapped clients > > run on different hosts by definition so there are probably whole > > extensions that are never used at all and likely completely untested. > > And it's not a matter of "working" but "safe against a malicious client > > sending bad messages". That's a completely different ballpark. > > e.g. the code for CVE-2022-46340 has been there since ~2008 but no-one > > ever noticed the issue - because it works as long as the client is nice. > > > > Forcing the server to little endian only means you'd need to do the > > swapping client-side. There is nothing in place right now to do this and > > while it's probably possible to automate this somewhat with xcb, you're > > still looking at a huge project. And once it all works, you need to > > ensure it works against malicious input data. You could *possibly* MITM > > the whole protocol-swapping into a separate process but, well, goto 10 > > :) > > > > Please tell me the Wayland protocol doesn't do this? the wayland protocol doesn't to this :) Wayland integers must be encoded in the host's (read: compositor) byte order. Somewhat of an exception are the wl_shm image formats which are (apparently) always in little-endian [1]. Cheers, Peter [1] https://wayland.freedesktop.org/docs/html/apa.html ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/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, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: F38 proposal: X Server Prohibits Byte-swapped Clients (System-Wide Change proposal)
On Wed, Dec 28, 2022 at 10:13 PM Peter Hutterer wrote: > > On Thu, Dec 22, 2022 at 05:41:06AM -0500, Neal Gompa wrote: > > On Thu, Dec 22, 2022 at 5:30 AM Niklas Schnelle > > wrote: > > > > > > Hi All, > > > > > > This might not be as niche as you might think. I'm one of the > > > Linux kernel maintainers for s390. Many of us do the vast majority of > > > their development work natively on s390 systems via SSH from Fedora > > > laptops. After all mainframes are pretty damn fast at compiling with > > > plenty of memory and dog fooding is part of quality control. And I'm > > > sure it's not just the teams working on the Linux kernel but also > > > plenty of other people working with s390 Linux machines. These s390 > > > machines mostly only host X servers via VNC and usually just for the > > > installation but they do that too. There is also a hand full of X > > > clients I run on s390 which are essential for my and many of my > > > colleagues daily workflows. The most important one is defintely > > > xsel/xclip to copy from the (neo-)vim/tmux I use for coding to my local > > > system. Some people also use x3270 via SSH X forwarding from jumphosts, > > > others use XEmacs. I also know essential internal tools that are run on > > > s390 hosts via X forwarding. Sure people using X forwarding are capable > > > of changing configuration defaults but if at all possible I would > > > suggest to rethink this, as it will create significant hassle for > > > anyone using their Fedora systems to SSH + X forward to s390 Linux > > > hosts and it definitely sees more use and thus testing than the > > > proposal makes it sound. > > > > > > > How bad would it be to force little-endian for the X protocol > > regardless of architecture? > > simply said - not realistic. It's a lot of effort, with zero visible > benefit beyond the *potential* that we're slightly safer now. Which you > won't know until you tested it all. > > The code works, at least for the bits that are executed. Swapped clients > run on different hosts by definition so there are probably whole > extensions that are never used at all and likely completely untested. > And it's not a matter of "working" but "safe against a malicious client > sending bad messages". That's a completely different ballpark. > e.g. the code for CVE-2022-46340 has been there since ~2008 but no-one > ever noticed the issue - because it works as long as the client is nice. > > Forcing the server to little endian only means you'd need to do the > swapping client-side. There is nothing in place right now to do this and > while it's probably possible to automate this somewhat with xcb, you're > still looking at a huge project. And once it all works, you need to > ensure it works against malicious input data. You could *possibly* MITM > the whole protocol-swapping into a separate process but, well, goto 10 > :) > Please tell me the Wayland protocol doesn't do this? -- 真実はいつも一つ！/ Always, there's only one truth! ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: F38 proposal: X Server Prohibits Byte-swapped Clients (System-Wide Change proposal)
On Thu, Dec 22, 2022 at 05:41:06AM -0500, Neal Gompa wrote: > On Thu, Dec 22, 2022 at 5:30 AM Niklas Schnelle > wrote: > > > > Hi All, > > > > This might not be as niche as you might think. I'm one of the > > Linux kernel maintainers for s390. Many of us do the vast majority of > > their development work natively on s390 systems via SSH from Fedora > > laptops. After all mainframes are pretty damn fast at compiling with > > plenty of memory and dog fooding is part of quality control. And I'm > > sure it's not just the teams working on the Linux kernel but also > > plenty of other people working with s390 Linux machines. These s390 > > machines mostly only host X servers via VNC and usually just for the > > installation but they do that too. There is also a hand full of X > > clients I run on s390 which are essential for my and many of my > > colleagues daily workflows. The most important one is defintely > > xsel/xclip to copy from the (neo-)vim/tmux I use for coding to my local > > system. Some people also use x3270 via SSH X forwarding from jumphosts, > > others use XEmacs. I also know essential internal tools that are run on > > s390 hosts via X forwarding. Sure people using X forwarding are capable > > of changing configuration defaults but if at all possible I would > > suggest to rethink this, as it will create significant hassle for > > anyone using their Fedora systems to SSH + X forward to s390 Linux > > hosts and it definitely sees more use and thus testing than the > > proposal makes it sound. > > > > How bad would it be to force little-endian for the X protocol > regardless of architecture? simply said - not realistic. It's a lot of effort, with zero visible benefit beyond the *potential* that we're slightly safer now. Which you won't know until you tested it all. The code works, at least for the bits that are executed. Swapped clients run on different hosts by definition so there are probably whole extensions that are never used at all and likely completely untested. And it's not a matter of "working" but "safe against a malicious client sending bad messages". That's a completely different ballpark. e.g. the code for CVE-2022-46340 has been there since ~2008 but no-one ever noticed the issue - because it works as long as the client is nice. Forcing the server to little endian only means you'd need to do the swapping client-side. There is nothing in place right now to do this and while it's probably possible to automate this somewhat with xcb, you're still looking at a huge project. And once it all works, you need to ensure it works against malicious input data. You could *possibly* MITM the whole protocol-swapping into a separate process but, well, goto 10 :) Cheers, Peter ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: F38 proposal: X Server Prohibits Byte-swapped Clients (System-Wide Change proposal)
On Thu, Dec 22, 2022 at 09:17:28PM +0100, Björn Persson wrote: > Vít Ondruch wrote: > > Dne 22. 12. 22 v 9:56 Olivier Fourdan napsal(a): > > > When the connection fails, the Xserver returns a reason in plain text. > > > In that case, the reason for the connection being rejected would be > > > „Swapped clients prohibited“. > > > > Appreciate that there is at least some explanation, but if I saw this > > error, I would not be much smarter what is going on and how should I > > proceed > > Yes, that's a really bad error message. My reaction would be "What > nonsense is that? I haven't swapped any clients." If it had at least > said "byte-swapped" it would probably have gotten me searching in the > right direction, but if the X server wants to be helpful it should say > "big/little-endian mismatch; the option AllowSwappedClients is off". Thanks, I've changed the error message to say `byte-swapped`, it hasn't been merged upstream yet after all. This particular message is handled in the DDX-independent bits though (shared code for Xorg, Xwayland, etc.), the option AllowSwappedClients only exists for Xorg since the other X server don't have an xorg.conf. Cheers, Peter ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Source download behind login?
On Wed, Dec 28, 2022 at 2:57 PM Richard Shaw wrote:
> On Wed, Dec 28, 2022 at 12:38 PM Ian McInerney via devel <
> devel@lists.fedoraproject.org> wrote:
>
>>
>> On Wed, Dec 28, 2022 at 5:42 PM Richard Shaw
>> wrote:
>>
>>> I'm working on updating the opencasecade package[1] but the main
>>> downloads require a login.
>>>
>>>
>> Is there a specific reason it needs to be their premade tarballs? If not,
>> it looks like you should be able to pull the tarball from the tag in their
>> git repo, which appears to be public.
>>
>> The git repo is here: https://git.dev.opencascade.org/gitweb/?p=occt.git
>> The link to pull the tarballs should be something like: "https://git.dev.
>> opencascade.org/gitweb/?p=occt.git;a=snapshot;h=refs/tags/V7_7_0;sf=tgz"
>> (where you can replace the tag as needed with the one for the version
>> required)
>>
>
> That works for a browser, but I need a direct link with an archive name,
> no redirects. I tried appending #/%{name}-%{version}.tar.gz to the end like
> I used to have to do with github but it doesn't work...
>
>
> https://git.dev.opencascade.org/gitweb/?p=occt.git;a=snapshot;h=refs/tags/V7_7_0;sf=tgz#/opencascade-7.7.0.tgz
>
> I tried looking for documentation for git-scm for what url options are
> available but didn't have any luck.
>
Scratch that... I'm on an iffy SSH connection and didn't notice it hang, it
did download.
Thanks,
Richard
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it:
https://pagure.io/fedora-infrastructure/new_issue
Re: Source download behind login?
On Wed, Dec 28, 2022 at 12:38 PM Ian McInerney via devel <
devel@lists.fedoraproject.org> wrote:
>
> On Wed, Dec 28, 2022 at 5:42 PM Richard Shaw wrote:
>
>> I'm working on updating the opencasecade package[1] but the main
>> downloads require a login.
>>
>>
> Is there a specific reason it needs to be their premade tarballs? If not,
> it looks like you should be able to pull the tarball from the tag in their
> git repo, which appears to be public.
>
> The git repo is here: https://git.dev.opencascade.org/gitweb/?p=occt.git
> The link to pull the tarballs should be something like: "https://git.dev.
> opencascade.org/gitweb/?p=occt.git;a=snapshot;h=refs/tags/V7_7_0;sf=tgz"
> (where you can replace the tag as needed with the one for the version
> required)
>
That works for a browser, but I need a direct link with an archive name, no
redirects. I tried appending #/%{name}-%{version}.tar.gz to the end like I
used to have to do with github but it doesn't work...
https://git.dev.opencascade.org/gitweb/?p=occt.git;a=snapshot;h=refs/tags/V7_7_0;sf=tgz#/opencascade-7.7.0.tgz
I tried looking for documentation for git-scm for what url options are
available but didn't have any luck.
Thanks,
Richard
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it:
https://pagure.io/fedora-infrastructure/new_issue
Re: Source download behind login?
On Wed, Dec 28, 2022 at 5:42 PM Richard Shaw wrote: > I'm working on updating the opencasecade package[1] but the main downloads > require a login. > > Is there a specific reason it needs to be their premade tarballs? If not, it looks like you should be able to pull the tarball from the tag in their git repo, which appears to be public. The git repo is here: https://git.dev.opencascade.org/gitweb/?p=occt.git The link to pull the tarballs should be something like: "https://git.dev. opencascade.org/gitweb/?p=occt.git;a=snapshot;h=refs/tags/V7_7_0;sf=tgz" (where you can replace the tag as needed with the one for the version required) > I tried moving to a mirror (or what I thought was a mirror) on github but > discovered that the releases are not in sync. > > I guess I could download the source and then reupload to fedorapeople.org > but that seems less than ideal. > > Ideas? > > Thanks, > Richard > > [1] https://bugzilla.redhat.com/show_bug.cgi?id=2137719 > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/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, report it: > https://pagure.io/fedora-infrastructure/new_issue > ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/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, report it: https://pagure.io/fedora-infrastructure/new_issue
Source download behind login?
I'm working on updating the opencasecade package[1] but the main downloads require a login. I tried moving to a mirror (or what I thought was a mirror) on github but discovered that the releases are not in sync. I guess I could download the source and then reupload to fedorapeople.org but that seems less than ideal. Ideas? Thanks, Richard [1] https://bugzilla.redhat.com/show_bug.cgi?id=2137719 ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/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, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Macro expanded on comment?
On Tue, 27 Dec 2022 12:29:21 -0600 Ron Olson wrote: > Hey all- > > I commented out a SOURCES line in a spec file to test something and > got an interesting warning: “Macro expanded in comment on line …”. I > assume it’s just that, a warning, but was kinda surprised to see a > commented-out line being evaluated at all. I did some searching and > came across this BZ from 2015: > https://bugzilla.redhat.com/show_bug.cgi?id=1224660 that seems to > suggest there’s a better way (%dnl), so if I want to comment > something out instead of putting a # in front of the line, I should > use %dnl? Thank you for asking this question. When I got this error, I just replaced the percent with a hash. Now I can do it properly and just put %dnl at the start of the 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 Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Issue with configuration of nested virtualization
I have just checked current Docs of libvirt (which I consider most representative/relevant) about host-passthrough and host-model (and a related SuSE page for comparison with RHEL concerning host-passthrough): host-passthrough/-model are still different and both are what they used to be. Concerning host-passthrough etc. see: https://libvirt.org/formatdomain.html https://documentation.suse.com/sles/15-SP3/html/SLES-all/cha-libvirt-config-virsh.html -> concerning host-passthrough, both can be transferred to your Quick Docs article about nested virt -> the considerations about host-passthrough/-model are the same. Be aware that host-passsthrough is not a real hardware passthrough like pci-passthrough. It only imitates the exact host CPU. Therefore, it is a passthrough of "hardware properties/behavior", not of hardware itself. You could also argue that host-passthrough = "imitation". This has positive performance outcomes: better CPU performance for the guest, and less emulation overhead for the host. The general performance advantages are the reason why I disagree with the second sentence of the current Note box (see my last mail). Concerning the migration issue: the issue applies mostly to environments that contain extraordinary CPUs, and are critical, complex and/or automated and need to provide constant predictable hardware behavior (which therefore, has to be officially supported and explicitly tested). Fedora is not intended for critical infra anyway. Additionally, the issue is increasingly likely to apply to those who further customize the host-passthrough in the configuration file. Maybe you can add a Note box that makes somehow aware of the following: generally, you can say with host-passthrough, the migration issue for the guest is mostly equal to the migration issue of the host: the CPU has changed, so everything that runs on top of that CPU has to adjust correspondingly. Mainstream guests possibly do not even care and are able to tailor automatically at boot (but I guess a paused VM should not be migrated while at pause, including snapshots of running systems :). ADDITION: depending on the host-passthrough configuration, it might be possible that it becomes necessary to adjust the xml config file when the host CPU changes (might apply mostly to those who customized the configuration file). Adjustments, if necessary, should be easy and are not "nested virtualization" specific. The point of libvirt's bug warning is: host-passthrough imitates exactly what the host CPU does/contains, not what has been explicitly tested/integrated in the software. This means that the user can enter formally untested grounds. You can make the user aware that host-passthrough-based "testing" of VM that has been conducted on one CPU cannot be automatically transferred to another CPU. On mainstream hardware, I have never experienced or seen an issue since libvirt/kvm have reached "maturity", but formally, the point might be noted for cases where the hardware is not fully known by the virt software. But be careful to not "threaten" users, since in most cases, host-passthrough should work properly... Since the "audience level" might be comparable, feel free to let yourself inspire by the RHEL and SuSE Docs when it comes to what to mention and what not. My arguments about host-passthrough/-model are valid. But I cannot help with modprobe <-> nested virtualization: for that, I suggest to search for topics on ask.fedora and if necessary, open a topic there. We had nested virtualization topics in the past, so maybe someone there can help you with that. Cheers, Chris On 28/12/2022 09:34, Peter Boy wrote: Hi Chris, Am 27.12.2022 um 23:01 schrieb Christopher Klooz: ... The Red Hat Docs you refer to differ to the Quick Docs page: see 1. II. of the procedures of both Intel and AMD at the RHEL link (as you indicated, it seems that RHEL 9 has not yet anything online about the topic, at least not on the publicly available pages). Yes, the RHEL documentation is more specific. However, there remains the inconsistency regarding the information in the /etc/modprobe.d/kvm.conf file in Fedora (don’t know if it exist in RHEL, too). Is this a remnant of old ways of configuration or some kind of fallback? It would be helpful to get some information about this. The RHEL8 Docs page makes use only of "host-passthrough", whereas the Quick Docs article seems to assume that "host-passthrough" and "host-model" are equal and thus, the user can use any of the two without a difference. At least as I was working with that the last time (maybe something has changed? * ), these were two different things (host passthrough <-> host model), and for performance reasons, I suggest to stick with "host-passthrough" and not "host-model" in the nested use case, except there is clear indication towards the other (see the openstack link below for an example). At least, the quick docs article should
Re: F38 proposal: Shorter Shutdown Timer (System-Wide Change proposal)
On Wed, 28 Dec 2022 at 08:45, Peter Boy wrote: > > > > Am 28.12.2022 um 13:00 schrieb Ralf Corsépius : > > > > > > > > Am 28.12.22 um 11:49 schrieb Peter Boy: > >> It is a good idea to make the timeout configurable. But the default > timeout for servers must remain unchanged. > > > > My problem is not "defined timeouts" it is systemd delaying shutdowns > for no obvious reasons. > > Yes, but instead of just „pulling the plug“ wouldn’t it be better to hunt > for the reasons? > > Most of the time, system administrators don't have time to hunt for the reasons because something else is going to happen (like a UPS dropping power) or a dozen other things. And once that is fixed the server is going to stay up until the next major crap I need to have everything rebooted/off in an outage window. Theoretically this testing should be done in in a staging environment, but I have only seen 3 places in 40 years with any time or ability to do so. Most of the places I have worked have had 'staging' environments which are really spare parts for production or actually in some level of production for other departments to 'stage' their code. I think 30 seconds is going to be a better fit for most services. Ones which need a longer time can override it in their service files and those will be easier to find. > > > And as you asked: On my (bare metal) servers, Im am occasionally > experiencing delayed shutdowns in the order of several minutes. > > > > This is simply inacceptable! > > Yes, but then always simply pulling the plug is not acceptable either, I > think. > > > > -- > Peter Boy > https://fedoraproject.org/wiki/User:Pboy > p...@fedoraproject.org > > Timezone: CET (UTC+1) / CEST (UTC+2) > > > Fedora Server Edition Working Group member > Fedora docs team contributor > Java developer and enthusiast > > > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/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, report it: > https://pagure.io/fedora-infrastructure/new_issue > -- Stephen Smoogen, Red Hat Automotive Let us be kind to one another, for most of us are fighting a hard battle. -- Ian MacClaren ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/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, report it: https://pagure.io/fedora-infrastructure/new_issue
HEADS UP: icu 72 coming to rawhide
Hi,I am in the process of updating icu from 71.1 to 72.1 in rawhide. This comes with a soname bump, but as usual, I'm including a compat package providing the old soname to not break the world while the rebuilds are in progress, so no rawhide breakage is expected. I'll work on the rebuilds over the weekend.Have a good day!Pete___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/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, report it: https://pagure.io/fedora-infrastructure/new_issue
[EPEL-devel] findbugs retired from EPEL 7
Hi all, Following on from my previous email to epel-devel [1], findbugs has now been retired from EPEL 7 [2]. Regards, Richard [1] https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject.org/thread/PMRI7YLN43CMO5RZLPYOTDS4BUKRLPIG/ [2] https://src.fedoraproject.org/rpms/findbugs/c/9d215c5e632bfdeb47b9a89a67e1b00efffacae2?branch=epel7 -- Richard Fearn richardfe...@gmail.com ___ epel-devel mailing list -- epel-devel@lists.fedoraproject.org To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: F38 proposal: Shorter Shutdown Timer (System-Wide Change proposal)
> Am 28.12.2022 um 15:23 schrieb Neal Gompa : > > On Wed, Dec 28, 2022 at 9:13 AM Peter Boy wrote: >> >> >> >>> Am 28.12.2022 um 13:34 schrieb Neal Gompa : >>> >>> On Wed, Dec 28, 2022 at 7:25 AM Frank Crawford >>> wrote: ... I'd also note that this has always been configurable, it is just now suggesting a different value from the default. >>> >>> I would also suggest that if you're shutting down/rebooting a server, >>> then you really want that to be done sooner rather than later, so >>> stuff getting killed as it shuts down if it doesn't do it normally >>> after SIGTERM is probably fine, because they're likely hung. >>> >>> Waiting a half hour for a system to reboot is not acceptable. >> >> Indeed, but it is not acceptable because the configuration of the timeout is >> too long, but because there is probably something earnestly going wrong. And >> as a server admin, I would like to decide myself to wait patiently and hope, >> to evaluate the issue, or to pull the plug. I don't want to leave that to a >> stupid timeout. >> >> >>> 15 or 30 seconds is probably fine, even for servers, because of the >>> nature of how systemd processes this timeout. It's per service being >>> shut down, rather than a global timeout. >> >> Yeah, *probably* fine, maybe not. We don’t know, just guess. And as the >> saying goes: better safe than sorry. >> >> And the 2 mins are empirically obviously a safe solution. >> > > Is it? If the end result is the same, it doesn't matter whether it's > 30 seconds or 2 minutes. Yes indeed. But it’s the sysadmin who decides to reset after those "15 or 30" secs. And that makes a difference. And mind you, it is not the common case that a standalone server with maybe a few VMs and a moderate workload needs those 10 minutes quoted here for shutdown. It is the exception and an urgent reason to take a serious look not at the 10 mins but at the server. For desktops, it's probably a different tradeoff. -- Peter Boy https://fedoraproject.org/wiki/User:Pboy p...@fedoraproject.org Timezone: CET (UTC+1) / CEST (UTC+2) Fedora Server Edition Working Group member Fedora docs team contributor Java developer and enthusiast ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/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, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: F38 proposal: Shorter Shutdown Timer (System-Wide Change proposal)
On Wed, Dec 28, 2022 at 9:13 AM Peter Boy wrote: > > > > > Am 28.12.2022 um 13:34 schrieb Neal Gompa : > > > > On Wed, Dec 28, 2022 at 7:25 AM Frank Crawford > > wrote: > >> > >> ... > >> > >> I'd also note that this has always been configurable, it is just now > >> suggesting a different value from the default. > > > > I would also suggest that if you're shutting down/rebooting a server, > > then you really want that to be done sooner rather than later, so > > stuff getting killed as it shuts down if it doesn't do it normally > > after SIGTERM is probably fine, because they're likely hung. > > > > Waiting a half hour for a system to reboot is not acceptable. > > Indeed, but it is not acceptable because the configuration of the timeout is > too long, but because there is probably something earnestly going wrong. And > as a server admin, I would like to decide myself to wait patiently and hope, > to evaluate the issue, or to pull the plug. I don't want to leave that to a > stupid timeout. > > > > 15 or 30 seconds is probably fine, even for servers, because of the > > nature of how systemd processes this timeout. It's per service being > > shut down, rather than a global timeout. > > Yeah, *probably* fine, maybe not. We don’t know, just guess. And as the > saying goes: better safe than sorry. > > And the 2 mins are empirically obviously a safe solution. > Is it? If the end result is the same, it doesn't matter whether it's 30 seconds or 2 minutes. -- 真実はいつも一つ！/ Always, there's only one truth! ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: F38 proposal: Shorter Shutdown Timer (System-Wide Change proposal)
> Am 28.12.2022 um 13:34 schrieb Neal Gompa : > > On Wed, Dec 28, 2022 at 7:25 AM Frank Crawford > wrote: >> >> ... >> >> I'd also note that this has always been configurable, it is just now >> suggesting a different value from the default. > > I would also suggest that if you're shutting down/rebooting a server, > then you really want that to be done sooner rather than later, so > stuff getting killed as it shuts down if it doesn't do it normally > after SIGTERM is probably fine, because they're likely hung. > > Waiting a half hour for a system to reboot is not acceptable. Indeed, but it is not acceptable because the configuration of the timeout is too long, but because there is probably something earnestly going wrong. And as a server admin, I would like to decide myself to wait patiently and hope, to evaluate the issue, or to pull the plug. I don't want to leave that to a stupid timeout. > 15 or 30 seconds is probably fine, even for servers, because of the > nature of how systemd processes this timeout. It's per service being > shut down, rather than a global timeout. Yeah, *probably* fine, maybe not. We don’t know, just guess. And as the saying goes: better safe than sorry. And the 2 mins are empirically obviously a safe solution. -- Peter Boy https://fedoraproject.org/wiki/User:Pboy p...@fedoraproject.org Timezone: CET (UTC+1) / CEST (UTC+2) Fedora Server Edition Working Group member Fedora docs team contributor Java developer and enthusiast ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/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, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: F38 proposal: Shorter Shutdown Timer (System-Wide Change proposal)
On Wed, Dec 28, 2022 at 8:45 AM Peter Boy wrote: > > > > > Am 28.12.2022 um 13:00 schrieb Ralf Corsépius : > > > > > > > > Am 28.12.22 um 11:49 schrieb Peter Boy: > >> It is a good idea to make the timeout configurable. But the default > >> timeout for servers must remain unchanged. > > > > My problem is not "defined timeouts" it is systemd delaying shutdowns for > > no obvious reasons. > > Yes, but instead of just „pulling the plug“ wouldn’t it be better to hunt for > the reasons? > > > > And as you asked: On my (bare metal) servers, Im am occasionally > > experiencing delayed shutdowns in the order of several minutes. > > > > This is simply inacceptable! > > Yes, but then always simply pulling the plug is not acceptable either, I > think. > Actually, in most server environments I've operated in, it probably is something people can deal with better because there's a plan for it. -- 真実はいつも一つ！/ Always, there's only one truth! ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Cfitsio soname bump, side tag created
Hello again, as stated before [1], I'm updating cfitsio to 4.2. I have created a side tag f38-build-side-61457 I have already built cfitsio, CCfits and wcslib. Affected packages are: astrometry bes CCfits cpl elements-alexandria gdal healpix indi-3rdparty-gphoto kstars kst LabPlot libindi luminance-hdr perl-Astro-FITS-CFITSIO phd2 python-astropy python-fitsio python-healpy root siril skyviewer sourcextractor++ ufraw vips wcslib Best regards, Sergio [1] https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/SRAVHMZMCH7AUX5ZAEYAZ6MSQIY475YJ/ ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/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, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: F38 proposal: Shorter Shutdown Timer (System-Wide Change proposal)
> Am 28.12.2022 um 13:00 schrieb Ralf Corsépius : > > > > Am 28.12.22 um 11:49 schrieb Peter Boy: >> It is a good idea to make the timeout configurable. But the default timeout >> for servers must remain unchanged. > > My problem is not "defined timeouts" it is systemd delaying shutdowns for no > obvious reasons. Yes, but instead of just „pulling the plug“ wouldn’t it be better to hunt for the reasons? > And as you asked: On my (bare metal) servers, Im am occasionally experiencing > delayed shutdowns in the order of several minutes. > > This is simply inacceptable! Yes, but then always simply pulling the plug is not acceptable either, I think. -- Peter Boy https://fedoraproject.org/wiki/User:Pboy p...@fedoraproject.org Timezone: CET (UTC+1) / CEST (UTC+2) Fedora Server Edition Working Group member Fedora docs team contributor Java developer and enthusiast ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/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, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: F38 proposal: Shorter Shutdown Timer (System-Wide Change proposal)
On Sat, Dec 24, 2022 at 4:38 AM Steve Grubb wrote: > > On Friday, December 23, 2022 1:34:48 PM EST Alexander Ploumistos wrote: > > On Fri, Dec 23, 2022 at 7:21 PM Steve Grubb wrote: > > > This is nice, but all I ever seen is a black screen and a spinning > > > circle. No text of any kind. If something were written to the console, > > > how do you see it? > > > > Have you tried hitting "Esc" when that happens? > > No. Why would I? There is no text on that screen that even mentions that is a > possible option. If that is possible, advertise it. Or better, kill the > graphical shutdown and explain why it's delayed. Even if systemd prints nice diagnostic messages, they're useless if nobody is going to see them. And I doubt that many people know that pressing the Esc key makes plymouth go away. Would it be possible to print an informative message in Plymouth instead? Something like "Shutdown is taking longer than expected, please do not force off the computer". Other parts of the system already use Plymouth for communicating other things to the user (asking for LUKS decryption password, showing system upgrade process, etc.) so I think that would make sense. It would also be far more obvious than "you need to press the Esc key to see what's going on - but don't ask me why it is that way or how I know that" ... Fabio ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: F38 proposal: Shorter Shutdown Timer (System-Wide Change proposal)
On Wed, Dec 28, 2022 at 7:25 AM Frank Crawford wrote: > > On Wed, 2022-12-28 at 13:00 +0100, Ralf Corsépius wrote: > > > > > > Am 28.12.22 um 11:49 schrieb Peter Boy: > > > > > > It is a good idea to make the timeout configurable. But the > > > default timeout for servers must remain unchanged. > > > > My problem is not "defined timeouts" it is systemd delaying shutdowns > > for no obvious reasons. > > > > And as you asked: On my (bare metal) servers, Im am occasionally > > experiencing delayed shutdowns in the order of several minutes. > > > > This is simply inacceptable! > > At one stage I timed this for an NFS failure and it took 30-40mins to > finally timeout and reboot. In some cases, especially related to > filesystems and umounts it will try a number of time, eventually give > up after 3 * 90s, and then come back to it again later, going through > the whole process again. Worse still it had already had issues with > stopping executable on that filesystem, as not everything is run in > parallel. > > However, given some of the arguments raised, it may be worth looking a > different values for workstations/laptops against real servers. If a > workstation or laptop doesn't reboot in a minute or so, they will > usually get hit with a force reset. Real server installations are very > different, they will almost always be left to reboot "eventually". > > I'd also note that this has always been configurable, it is just now > suggesting a different value from the default. I would also suggest that if you're shutting down/rebooting a server, then you really want that to be done sooner rather than later, so stuff getting killed as it shuts down if it doesn't do it normally after SIGTERM is probably fine, because they're likely hung. Waiting a half hour for a system to reboot is not acceptable. 15 or 30 seconds is probably fine, even for servers, because of the nature of how systemd processes this timeout. It's per service being shut down, rather than a global timeout. -- 真実はいつも一つ！/ Always, there's only one truth! ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: F38 proposal: Shorter Shutdown Timer (System-Wide Change proposal)
On Wed, 2022-12-28 at 13:00 +0100, Ralf Corsépius wrote: > > > Am 28.12.22 um 11:49 schrieb Peter Boy: > > > > It is a good idea to make the timeout configurable. But the > > default timeout for servers must remain unchanged. > > My problem is not "defined timeouts" it is systemd delaying shutdowns > for no obvious reasons. > > And as you asked: On my (bare metal) servers, Im am occasionally > experiencing delayed shutdowns in the order of several minutes. > > This is simply inacceptable! At one stage I timed this for an NFS failure and it took 30-40mins to finally timeout and reboot. In some cases, especially related to filesystems and umounts it will try a number of time, eventually give up after 3 * 90s, and then come back to it again later, going through the whole process again. Worse still it had already had issues with stopping executable on that filesystem, as not everything is run in parallel. However, given some of the arguments raised, it may be worth looking a different values for workstations/laptops against real servers. If a workstation or laptop doesn't reboot in a minute or so, they will usually get hit with a force reset. Real server installations are very different, they will almost always be left to reboot "eventually". I'd also note that this has always been configurable, it is just now suggesting a different value from the default. > > Ralf Regards Frank ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/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, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: F38 proposal: Shorter Shutdown Timer (System-Wide Change proposal)
Am 28.12.22 um 11:49 schrieb Peter Boy: It is a good idea to make the timeout configurable. But the default timeout for servers must remain unchanged. My problem is not "defined timeouts" it is systemd delaying shutdowns for no obvious reasons. And as you asked: On my (bare metal) servers, Im am occasionally experiencing delayed shutdowns in the order of several minutes. This is simply inacceptable! Ralf ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/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, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Macro expanded on comment?
Ron Olson writes: > Hey all- > > I commented out a SOURCES line in a spec file to test something and got an > interesting warning: “Macro expanded in comment on line …”. I assume it’s > just that, a warning, but was kinda surprised to see a commented-out line > being evaluated at all. I did some searching and came across this BZ from > 2015: https://bugzilla.redhat.com/show_bug.cgi?id=1224660 that seems to > suggest there’s a better way (%dnl), so if I want to comment something out > instead of putting a # in front of the line, I should use %dnl? Yes, # does not prevent macro expansion, all it does is that # is prepended to the expanded macro before it is being fed to the shell. For single line macros, that is equivalent to commenting it out, but for macros that expand to multiple lines, you'll get *very* interesting errors. And macros which have side effects will still have that side effect. %dnl on the other hand will (iirc) instruct RPM to not expand anything after it on this line. Cheers, Dan ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/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, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: F38 proposal: Shorter Shutdown Timer (System-Wide Change proposal)
> Am 22.12.2022 um 19:29 schrieb Adam Williamson : > > On Thu, 2022-12-22 at 18:44 +0100, Tomasz Torcz wrote: >> On Thu, Dec 22, 2022 at 12:35:54PM -0500, Ben Cotton wrote: >>> https://fedoraproject.org/wiki/Changes/Shorter_Shutdown_Timer >>> >>> This document represents a proposed Change. As part of the Changes >>> process, proposals are publicly announced in order to receive >>> community feedback. This proposal will only be implemented if approved >>> by the Fedora Engineering Steering Committee. >>> >>> == Summary == >>> A downstream configuration change to reduce the systemd unit timeout >>> from 2 minutes to 15 seconds. >> >> Great change, please do it! >> Also, sometimes after reaching the timeout, systemd extends wait by >> another 2 minutes (or 1m30). I wasn't able to find in the sources or >> documentation why this happens, but this behaviour should be blocked. >> Otherwise some services after 15s will get another 15, and then another… > > 15 seconds feels very aggressive to me. I can think of some cases, like > libvirtd automatically suspending or cleanly shutting down running VMs, > that might well take longer than that. Could we not go for 30 seconds? > Going all the way from 90/120 down to 15 seems pretty radical. Even though I am a bit late due to seasonal commitments, I would like to affirm a strong rejection of this change for the server variant on behalf of the server WG. The proposed limit of 15 secs is much to aggressiv, also the proposal of 30 seconds. Unfortunately, we do not have data on how long on average it takes for a productive server shutdown to terminate all VMs (with their own delays), all open database transactions, all service sessions, etc. But obviously the current time interval does not cause any striking problems. and is therefore OK for server. For a production server, a shutdown is a rare event and the main problem is not a period of 30 sec or 2 min, but the shutdown itself. And server admins are terribly conservative (and cautious) people, never change a working system unless there is a clear advantage. And this proposal brings no advantage at all for servers, only potential problems. It is a good idea to make the timeout configurable. But the default timeout for servers must remain unchanged. -- Peter Boy https://fedoraproject.org/wiki/User:Pboy p...@fedoraproject.org Timezone: CET (UTC+1) / CEST (UTC+2) Fedora Server Edition Working Group member Fedora docs team contributor and board member Java developer and enthusiast ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/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, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: SPDX Statistics - Christmas edition
On Wed, Dec 28, 2022 at 9:29 AM Miroslav Suchý wrote: > > I want to point one - if you are maintainer of package with license > "Copyright only" or "Redistributable" then please read: > > > https://docs.fedoraproject.org/en-US/legal/update-existing-packages/#_freely_redistributable_without_restrictions > > Because in your case you will likely have to submit the license for review. > And that takes some time. Same thing for "Public Domain" license tags. Happy New Year to you too, Miroslav! ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/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, report it: https://pagure.io/fedora-infrastructure/new_issue
Fedora rawhide compose report: 20221228.n.0 changes
OLD: Fedora-Rawhide-20221227.n.0 NEW: Fedora-Rawhide-20221228.n.0 = SUMMARY = Added images:0 Dropped images: 0 Added packages: 1 Dropped packages:0 Upgraded packages: 39 Downgraded packages: 0 Size of added packages: 21.82 KiB Size of dropped packages:0 B Size of upgraded packages: 373.44 MiB Size of downgraded packages: 0 B Size change of upgraded packages: 89.30 MiB Size change of downgraded packages: 0 B = ADDED IMAGES = = DROPPED IMAGES = = ADDED PACKAGES = Package: rust-progpool-0.2.1-1.fc38 Summary: Job pool with terminal progress bar RPMs:rust-progpool+default-devel rust-progpool-devel Size:21.82 KiB = DROPPED PACKAGES = = UPGRADED PACKAGES = Package: amsynth-1.13.0-1.fc38 Old package: amsynth-1.12.4-2.fc36 Summary: A classic synthesizer with dual oscillators RPMs: amsynth amsynth-data dssi-amsynth-plugin lv2-amsynth-plugin vst-amsynth-plugin Size: 3.05 MiB Size change: -225.52 KiB Changelog: * Wed Jul 20 2022 Fedora Release Engineering - 1.12.4-3 - Rebuilt for https://fedoraproject.org/wiki/Fedora_37_Mass_Rebuild * Tue Dec 27 2022 Guido Aulisi - 1.13.0-1 - Update to 1.13.0 Package: archlinux-keyring-20221220-1.fc38 Old package: archlinux-keyring-20221213-1.fc38 Summary: GPG keys used by Arch distribution to sign packages RPMs: archlinux-keyring Size: 1.13 MiB Size change: 5.34 KiB Changelog: * Tue Dec 27 2022 Frantisek Sumsal 20221220-1 - Version 20221220 (#2154797) Package: binwalk-2.3.3-1.fc38 Old package: binwalk-2.3.2-4.fc37 Summary: Firmware analysis tool RPMs: binwalk Size: 246.29 KiB Size change: 2.29 KiB Changelog: * Tue Dec 27 2022 Scott Talbert - 2.3.3-1 - Update to new upstream release 2.3.3 (#2003337 #2156566) Package: borgbackup-1.2.3-1.fc38 Old package: borgbackup-1.2.2-1.fc38 Summary: A deduplicating backup program with compression and authenticated encryption RPMs: borgbackup Size: 6.10 MiB Size change: 3.62 KiB Changelog: * Tue Dec 27 2022 Felix Schwarz - 1.2.3-1 - update to 1.2.3 Package: checkpolicy-3.5-0.rc1.1.fc38 Old package: checkpolicy-3.4-4.fc38 Summary: SELinux policy compiler RPMs: checkpolicy Size: 1.36 MiB Size change: 1.41 KiB Changelog: * Tue Dec 27 2022 Petr Lautrbach - 3.5-0.rc1.1 - SELinux userspace 3.5-rc1 release Package: ddgr-2.1-1.fc38 Old package: ddgr-2.0-2.fc37 Summary: DuckDuckGo from the terminal RPMs: ddgr Size: 47.75 KiB Size change: 21 B Changelog: * Tue Dec 27 2022 Robert-Andr?? Mauchin 2.1-1 - Update to 2.1 Package: dosbox-staging-0.80.0-2.fc38 Old package: dosbox-staging-0.80.0-1.fc38 Summary: DOS/x86 emulator focusing on ease of use RPMs: dosbox-staging Size: 7.55 MiB Size change: 991 B Package: flatpak-builder-1.2.3-2.fc38 Old package: flatpak-builder-1.2.3-1.fc38 Summary: Tool to build flatpaks from source RPMs: flatpak-builder Size: 900.91 KiB Size change: 913 B Changelog: * Mon Dec 26 2022 msuchy - 1.2.3-2 - migrate to SPDX license Package: highway-1.0.2-1.fc38 Old package: highway-1.0.1-2.fc38 Summary: Efficient and performance-portable SIMD RPMs: highway highway-devel highway-doc Size: 3.35 MiB Size change: -260.71 KiB Changelog: * Tue Dec 27 2022 Robert-Andr?? Mauchin 1.0.2-1 - Update to 1.0.2 Package: jitterentropy-3.4.1-3.fc38 Old package: jitterentropy-3.4.1-1.fc38 Summary: Library implementing the jitter entropy source RPMs: jitterentropy jitterentropy-devel Size: 281.83 KiB Size change: 3.61 KiB Changelog: * Tue Dec 27 2022 Vladis Dronov - 3.4.1-3 - Update to the upstream v3.4.1 @ 7bf9f85d - Fix a stack corruption on s390x Package: jkmeter-0.9.0-1.fc38 Old package: jkmeter-0.8.0-3.fc37 Summary: Horizontal or vertical bar-graph audio levels meter RPMs: jkmeter Size: 263.29 KiB Size change: 975 B Changelog: * Tue Dec 27 2022 Guido Aulisi - 0.9.0-1 - Update to 0.9.0 Package: jpegxl-1:0.7.0-5.fc38 Old package: jpegxl-1:0.7.0-3.fc38 Summary: JPEG XL image format reference implementation RPMs: gimp-jxl-plugin jpegxl-doc jxl-pixbuf-loader libjxl libjxl-devel libjxl-devtools libjxl-utils Size: 13.08 MiB Size change: -395.35 KiB Changelog: * Sat Nov 19 2022 Robert-Andr?? Mauchin - Convert to SPDX * Tue Dec 27 2022 Miroslav Such?? 1:0.7.0-5 - add epoch back Package: kvantum-1.0.7-1.fc38 Old package: kvantum-1.0.5-1.fc38 Summary: SVG-based theme engine for Qt5, KDE and LXQt RPMs: kvantum kvantum-data Size: 4.29 MiB Size change: 9.58 KiB Changelog: * Tue Dec 27 2022 Robert-Andr?? Mauchin 1.0.7-1 - Update to 1.0.7 Package: lastpass-cli-1.3.4-1.fc38 Old package: lastpass-cli-1.3.3-10
Re: Issue with configuration of nested virtualization
Hi Chris,
> Am 27.12.2022 um 23:01 schrieb Christopher Klooz :
> ...
> The Red Hat Docs you refer to differ to the Quick Docs page: see 1. II. of
> the procedures of both Intel and AMD at the RHEL link (as you indicated, it
> seems that RHEL 9 has not yet anything online about the topic, at least not
> on the publicly available pages).
Yes, the RHEL documentation is more specific. However, there remains the
inconsistency regarding the information in the /etc/modprobe.d/kvm.conf file in
Fedora (don’t know if it exist in RHEL, too). Is this a remnant of old ways of
configuration or some kind of fallback? It would be helpful to get some
information about this.
> The RHEL8 Docs page makes use only of "host-passthrough", whereas the Quick
> Docs article seems to assume that "host-passthrough" and "host-model" are
> equal and thus, the user can use any of the two without a difference. At
> least as I was working with that the last time (maybe something has changed?
> * ), these were two different things (host passthrough <-> host model), and
> for performance reasons, I suggest to stick with "host-passthrough" and not
> "host-model" in the nested use case, except there is clear indication towards
> the other (see the openstack link below for an example). At least, the quick
> docs article should make clear the difference if it also notes "host-model".
> Or alternatively, duplicate the RHEL8 Docs page approach and refer only to
> "host-passthrough", which makes most sense for that use case imho.
>
> Additionally, I disagree a bit with the "Note" box in
> https://docs.fedoraproject.org/en-US/quick-docs/using-nested-virtualization-in-kvm/#proc_configuring-nested-virtualization-in-virt-manager
>
> " Using host-passthrough is not recommended for general usage. It should only
> be used for nested virtualization purposes. "
>
> I am not sure if nested virtualization is the only reason to enable
> host-passthrough. So at least the second sentence ("It should only be used
> for nested virtualization purposes") should be removed imho. I think implicit
> assumptions should be avoided at all.
>
> Concerning the difference of host-passthrough and host-model, the following
> link contains some information about the two that corresponds to what I know:
> https://wiki.openstack.org/wiki/LibvirtXMLCPUModel (just search on that page
> for "host-passthrough" and "host-model"). If you search on the Internet for
> further information, be aware that the terms "host-passthrough" and
> "pci-passthrough" are not synonymous (you will maybe get many pages about
> both when querying a search machine about one of them).
Question is, what are the disadvantages of passthrough?
The OpenStack article only mentions that migration to other hardware is limited
to the exact processor model. I haven't worked on this topic for a long time,
but "in the past" the hardware proximity of the VMs led to general performance
losses of the overall system. But that may no longer be true today, both in
general and for this particular case.
Again, it would be helpful to get valid information.
Thanks
Peter
> On 27/12/2022 12:59, Peter Boy wrote:
>> In order to use nested virtualization, Fedora Quick Docs[1] advises to
>> activate that feature in the host kernel using modprobe and editing the file
>> /etc/modprobe.d/kvm.conf. The comment in this file provides the same
>> information. Additionally, you are to configure the processor of the VM
>> hosting a nested VM as passthrough. The RHEL 8 documentation [2] provides
>> the same information as various articles on other Web pages. In RHEL 9
>> documentation I couldn’t find anything about this. Additionally, you are to
>> configure the processor of the VM hosting a nested VM as passthrough.
>>
>> According to my findings these informations seem to be obsolete or in need
>> of supplementation. At least everything works fine without any additional
>> configuration at all (at least if the host processor as well as the
>> processor configured in the VM support virtualization).
>>
>> The Fedora docs team is in the process to check and update Fedora
>> documentation.
>>
>> It would be really helpful if someone with more technical knowledge about
>> that matter than me would provide me with more detailed information und
>> maybe links to current information. Even better if someone familiar with the
>> matter would be willing to review an updated article.
>>
>>
>>
>>
>> [1]
>> https://docs.fedoraproject.org/en-US/quick-docs/using-nested-virtualization-in-kvm/
>> [2]
>> https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/8/html/configuring_and_managing_virtualization/creating-nested-virtual-machines_configuring-and-managing-virtualization
--
Peter Boy
https://fedoraproject.org/wiki/User:Pboy
p...@fedoraproject.org
Timezone: CET (UTC+1) / CEST (UTC+2)
Fedora Server Edition Working Group member
Fedora docs team contributor
SPDX Statistics - Christmas edition
2 weeks ago we had: 23148 spec files in Fedora > 29121 license tags in all spec files > 24483 tags have not been converted to SPDX yet > 10099 tags can be trivially converted using `license-fedora2spdx` Today we have * 23184 spec files in Fedora * 29200 license tags in all spec files * 23682 tags have not been converted to SPDX yet * 9377 tags can be trivially converted using `license-fedora2spdx` The list of packages needed to be converted is again here: https://pagure.io/copr/license-validate/blob/main/f/packages-without-spdx-final.txt New version of fedora-license-data has been released - big kudos to Jilayne and Richards for the license reviews. I gathered the progress in this spreadsheet: https://docs.google.com/spreadsheets/d/1QVMEzXWML-6_Mrlln02axFAaRKCQ8zE807rpCjus-8s/edit?usp=sharing It includes burn-down chart. I should rather call it burn up chart. Because we will be done when the blue part will be up to 100 %. It is too early to make any predictions as we have only 3 records. But anyway - with this speed of progress we will be done in 20 months. I want to point one - if you are maintainer of package with license "Copyright only" or "Redistributable" then please read: https://docs.fedoraproject.org/en-US/legal/update-existing-packages/#_freely_redistributable_without_restrictions Because in your case you will likely have to submit the license for review. And that takes some time. Happy Christmas and New Year to everyone. Miroslav ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/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, report it: https://pagure.io/fedora-infrastructure/new_issue
