Re: F38 proposal: Unified Kernel Support Phase 1 (System-Wide Change proposal)

[Björn Persson]

Lennart Poettering wrote:
> dracut uses fixed offsets for the sections to be placed in memory
> in. The values are simply hardcoded, literally specified address
> offsets, that worked for the original authors. This typically works –
> as long as your sections are not much larger than they were for the
> people wo came up with these offsets initially. But as it turns out
> this doesn't work for some cases. In such cases the sections will be
> loaded into memory overlapped and bad things happen.

Oh yuck! And the manpage is written as if dracut --uefi is expected to
work reliably. I see no big eye-catching warning that such-and-such
must be smaller than x bytes.

Björn Persson


pgpHBtrq05hJe.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

Rawhide with kernel-6.2 requires VBox SVGA video mode to boot in VirtualBox

[Ian Laurie]

I've not been able to boot Rawhide in VirtualBox with any 6.2 kernel. 
Last good kernel was kernel-6.1.0-65.fc38.x86_64.  My host is Fedora 37 
all updates applied.


Experimentation reveals that I can get my VMs to boot with a 6.2 kernel 
if I use the old "VBOX SVGA" display setting rather than the "correct" 
"VMSVGA" setting.


The old setting produces a configuration alert with Linux systems 
(although it does work).  This feels like a kernel problem to me rather 
than a VirtualBox problem at this point.


Anyone else seeing this, I can't be the only one?

Ian
--
Ian Laurie
FAS: nixuser | IRC: nixuser
TZ: Australia/Sydney
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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: certbot 2.1.0

[Jonathan Wright via devel]

I have a spec mostly ready to combine all of it back into a single spec
file.  Would you be open to discussing/reviewing that, merging it, then
pushing that to stable?

On Tue, Dec 27, 2022 at 9:17 PM Nick Bebout  wrote:

> I have built certbot 2.1.0 for all supported releases of Fedora and for
> EPEL.  It has been in testing for 2 weeks.  I am getting ready to push it
> to stable in the next few days.
>
> It is a "major" update, but is mostly backwards compatible.  2.0.0 had
> more incompatibilities, but in 2.1.0 they added changes to make most
> plugins still work with the new 2.x series.  The other main change is that
> it will use ECDSA keys by default instead of RSA.
>
> nb
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/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
>


-- 
Jonathan Wright
AlmaLinux Foundation
Mattermost: chat 
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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

certbot 2.1.0

[Nick Bebout]

I have built certbot 2.1.0 for all supported releases of Fedora and for
EPEL.  It has been in testing for 2 weeks.  I am getting ready to push it
to stable in the next few days.

It is a "major" update, but is mostly backwards compatible.  2.0.0 had more
incompatibilities, but in 2.1.0 they added changes to make most plugins
still work with the new 2.x series.  The other main change is that it will
use ECDSA keys by default instead of RSA.

nb
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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

[Bug 2144550] Please branch and build perl-Net-Domain-TLD in epel9

[bugzilla]

https://bugzilla.redhat.com/show_bug.cgi?id=2144550

Fedora Update System  changed:

   What|Removed |Added

 Resolution|--- |ERRATA
 Status|ON_QA   |CLOSED
   Fixed In Version||perl-Net-Domain-TLD-1.75-19
   ||.el9
Last Closed||2022-12-28 02:01:55



--- Comment #7 from Fedora Update System  ---
FEDORA-EPEL-2022-a89e1dedf1 has been pushed to the Fedora EPEL 9 stable
repository.
If problem still persists, please make note of it in this bug report.


-- 
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=2144550
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

[Bug 2154340] perl-File-Slurper-0.014 is available

[bugzilla]

https://bugzilla.redhat.com/show_bug.cgi?id=2154340

Fedora Update System  changed:

   What|Removed |Added

 Status|ON_QA   |CLOSED
 Resolution|--- |ERRATA
   Fixed In Version|perl-File-Slurper-0.014-1.f |perl-File-Slurper-0.014-1.f
   |c38 |c38
   ||perl-File-Slurper-0.014-1.f
   ||c37
Last Closed||2022-12-28 01:34:11



--- Comment #3 from Fedora Update System  ---
FEDORA-2022-94cd301784 has been pushed to the Fedora 37 stable repository.
If problem still persists, please make note of it in this bug report.


-- 
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=2154340
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Use of deprecated Berkeley DB in new package

[Neal Gompa]

On Tue, Dec 27, 2022 at 6:04 PM Frank Crawford  wrote:
>
> Folks,
>
> I'm currently reviewing a package (c-icap - BZ2119983) which uses
> Berkeley DB, a product that is now marked as deprecated.
>
> Currently the packager has decided to bundle BDB into the package, as
> it is the only way to get around the issue, but given that BDB looks
> like it will be around for sometime to come, would it be possible to
> request an exemption to allow linking against the currently distributed
> package, even though it is deprecated?  This will remove the issue of
> having to monitor for any security issue in BDB for this particular
> package.
>
> We have raised the issue upstream and they are willing to move to a
> replacement, but as it is not a fast moving development it may be a
> little while before it is done.
>

I think you can file an exception request with FESCo for this case.

https://pagure.io/fesco



-- 
真実はいつも一つ！/ 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

Use of deprecated Berkeley DB in new package

[Frank Crawford]

Folks,

I'm currently reviewing a package (c-icap - BZ2119983) which uses
Berkeley DB, a product that is now marked as deprecated.

Currently the packager has decided to bundle BDB into the package, as
it is the only way to get around the issue, but given that BDB looks
like it will be around for sometime to come, would it be possible to
request an exemption to allow linking against the currently distributed
package, even though it is deprecated?  This will remove the issue of
having to monitor for any security issue in BDB for this particular
package.

We have raised the issue upstream and they are willing to move to a
replacement, but as it is not a fast moving development it may be a
little while before it is done.

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: Issue with configuration of nested virtualization

[Christopher Klooz]

Hi Peter,

I have not much experience with nested virtualization in particular. But 
although I am quite sure that it will not fail without host-passthrough, 
I cannot imagine it to be sufficiently efficient without making use of 
host-passthrough in production (and also not effective in many use 
cases). So concerning enabling the host-passthrough, I assume that makes 
sense.


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).


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).


To avoid misunderstandings: I have not reviewed/tested the remaining 
article. Maybe someone else has the capabilities for that.


* I cannot exclude that there have been some developments in this area 
since I was using that the last time, but given the age of the Quick 
Docs article, I expect the "host-passthrough = host-model" assumption 
was wrong at the time of writing (being no indication for what is 
currently correct), and therefore, unless someone knows it better, I 
guess it makes sense to assume that there is still a difference between 
the two...


Hope that helps a bit.

Regards & stay safe,

Chris


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.




--
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




[1] 
https://docs.fedoraproject.org/en-US/quick-docs/using-nested-virtualization-in-kvm/
[2] 

Re: Macro expanded on comment?

[Fabio Valentini]

On Tue, Dec 27, 2022 at 7:30 PM 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?

I think it should be fine in most cases, but I'm not sure what happens
if the macro expands to multiple lines. Unless RPM does some magic
trick and marks *all* lines from macros expanded inside a comment as
comments, all but the first line of the expanded macro would end up
being ... not comments.

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

Macro expanded on comment?

[Ron Olson]

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?


Thanks for any info!

Ron
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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: Self Introduction: Dale Turner

[Joe Doss]

On 12/26/22 12:18 PM, Dale Turner via devel wrote:
Hello everyone. My name is Dale Turner, and I am new to the list. I live 
in Nova Scotia, Canada.


I have been using Fedora Linux since 2008 (version 9). At that time, I 
decided Microsoft Windows was not really for me, so I began looking 
elsewhere. I considered several Linux distributions before finally 
choosing Fedora. I like that Fedora is always pushing forward and is 
very up-to-date. I really like that Fedora works so closely with 
upstream, so that when Fedora solves a problem, it benefits everyone, 
not just the Fedora users. The community also seems excellent.


My professional background is healthcare. I have no formal computer 
training, so I am best considered a hobbyist/enthusiast/user. Although 
new to the list, I have viewed the archives many times.


I have been building packages for some time, both locally on my machine 
and COPR (https://copr.fedorainfracloud.org/coprs/dturner/ 
).


I have also filed a few bugs over the years.

The main reason for me finally posting to this list is that I noticed 
xaos is now unmaintained. I am not in the Packager group, but I think I 
would be able to maintain this package, or at least assist. It is not 
critical to any system, but is interesting to me, and hopefully would 
not be too daunting a task. I do have a successful build in my COPR.


Thanks for everything, and your consideration.


Welcome Dale. I am glad you joined us! :)

--
Joe Doss
j...@solidadmin.com
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

[Bug 2053165] perl-XML-LibXML: Validation succeeds even though the DTD could not be loaded

[bugzilla]

https://bugzilla.redhat.com/show_bug.cgi?id=2053165

Sandipan Roy  changed:

   What|Removed |Added

 Status|NEW |CLOSED
 Resolution|--- |NOTABUG
Last Closed||2022-12-27 16:52:33




-- 
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=2053165
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

[EPEL-devel] [Fedocal] Reminder meeting : EPEL Steering Committee

[tdawson]

Dear all,

You are kindly invited to the meeting:
   EPEL Steering Committee on 2022-12-28 from 16:00:00 to 17:00:00 US/Eastern
   At fedora-meet...@irc.libera.chat

The meeting will be about:
This is the weekly EPEL Steering Committee Meeting.

A general agenda is the following:

#topic aloha

#topic EPEL Issues https://pagure.io/epel/issues
* https://pagure.io/epel/issues?tags=meeting=Open

#topic Old Business (if needed)

#topic General Issues / Open Floor




Source: https://calendar.fedoraproject.org//meeting/9854/

___
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

Issue with configuration of nested virtualization

[Peter Boy]

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.




--
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




[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
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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: dnf system-upgrade f36->f37: mlocate / plocate conflict

[Zbigniew Jędrzejewski-Szmek]

On Sun, Dec 25, 2022 at 01:26:07PM -0600, Richard Shaw wrote:
> On my laptop when I tried to do a dnf system-upgrade from f36->37 I ended
> up getting a conflict with mlocate and plocate.
> 
> Since I remember the thread I just did a "dnf swap" which solved the issue
> but it could be confusing to users not aware.
> 
> Was this supposed to happen automagically?

Back in https://bugzilla.redhat.com/show_bug.cgi?id=2052433 we decided to
add Obsoletes only for F<=36. The plan was to retire mlocate in F37. But that
never happened. I updated the Obsoletes in F37 and rawhide to cover F37 and F38
and started a build now. I think we should do the retirement of mlocate in
rawhide now. There doesn't seem to be a good reason to keep it around.

Zbyszek
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue