Fedora rawhide compose report: 20250223.n.0 changes

[Fedora Rawhide Report]

OLD: Fedora-Rawhide-20250222.n.0
NEW: Fedora-Rawhide-20250223.n.0

= SUMMARY =
Added images:1
Dropped images:  9
Added packages:  1
Dropped packages:3
Upgraded packages:   33
Downgraded packages: 0

Size of added packages:  114.77 KiB
Size of dropped packages:189.01 KiB
Size of upgraded packages:   899.99 MiB
Size of downgraded packages: 0 B

Size change of upgraded packages:   923.64 KiB
Size change of downgraded packages: 0 B

= ADDED IMAGES =
Image: i3 live aarch64
Path: Spins/aarch64/iso/Fedora-i3-Live-aarch64-Rawhide-20250223.n.0.iso

= DROPPED IMAGES =
Image: Cloud_Base qcow2 s390x
Path: 
Cloud/s390x/images/Fedora-Cloud-Base-Generic-Rawhide-20250222.n.0.s390x.qcow2
Image: Container_Minimal_Base container s390x
Path: 
Container/s390x/images/Fedora-Container-Base-Generic-Minimal-Rawhide-20250222.n.0.s390x.oci.tar.xz
Image: Container_Toolbox container s390x
Path: 
Container/s390x/images/Fedora-Container-Toolbox-Rawhide-20250222.n.0.s390x.oci.tar.xz
Image: Container_Base container s390x
Path: 
Container/s390x/images/Fedora-Container-Base-Generic-Rawhide-20250222.n.0.s390x.oci.tar.xz
Image: Server_KVM qcow2 s390x
Path: 
Server/s390x/images/Fedora-Server-Guest-Generic-Rawhide-20250222.n.0.s390x.qcow2
Image: Cinnamon live x86_64
Path: Spins/x86_64/iso/Fedora-Cinnamon-Live-x86_64-Rawhide-20250222.n.0.iso
Image: KDE_Mobile live aarch64
Path: Spins/aarch64/iso/Fedora-KDE-Mobile-Live-Rawhide-20250222.n.0.aarch64.iso
Image: Mate live x86_64
Path: Spins/x86_64/iso/Fedora-MATE_Compiz-Live-x86_64-Rawhide-20250222.n.0.iso
Image: LXDE live x86_64
Path: Spins/x86_64/iso/Fedora-LXDE-Live-x86_64-Rawhide-20250222.n.0.iso

= ADDED PACKAGES =
Package: rust-mp4parse-0.17.0-1.fc43
Summary: Parser for ISO base media file format (mp4)
RPMs:rust-mp4parse+3gpp-devel rust-mp4parse+default-devel 
rust-mp4parse+meta-xml-devel rust-mp4parse+missing-pixi-permitted-devel 
rust-mp4parse+mp4v-devel rust-mp4parse-devel
Size:114.77 KiB


= DROPPED PACKAGES =
Package: rust-ansi_term0.11-0.11.0-19.fc42
Summary: Library for ANSI terminal colours and styles (bold, underline)
RPMs:rust-ansi_term0.11+default-devel rust-ansi_term0.11-devel
Size:31.03 KiB

Package: rust-block-modes-0.8.1-9.fc42
Summary: Block cipher modes of operation
RPMs:rust-block-modes+alloc-devel rust-block-modes+default-devel 
rust-block-modes+std-devel rust-block-modes-devel
Size:57.71 KiB

Package: rust-deflate-1.0.0-6.fc42
Summary: DEFLATE, zlib and gzip encoder written in Rust
RPMs:rust-deflate+benchmarks-devel rust-deflate+default-devel 
rust-deflate+gzip-devel rust-deflate+gzip-header-devel rust-deflate-devel
Size:100.26 KiB


= UPGRADED PACKAGES =
Package:  canl-c-3.0.0-22.20250222git233ebac.fc43
Old package:  canl-c-3.0.0-20.fc41
Summary:  Common Authentication library - bindings for C
RPMs: canl-c canl-c-devel canl-c-doc canl-c-examples
Size: 581.32 KiB
Size change:  -4.73 KiB
Changelog:
  * Thu Jan 16 2025 Fedora Release Engineering  - 
3.0.0-21
  - Rebuilt for https://fedoraproject.org/wiki/Fedora_42_Mass_Rebuild

  * Sat Feb 22 2025 Franti??ek Dvok  - 
3.0.0-22.20250222git233ebac
  - Update project and source URL
  - Fix build with gcc 15 (#2339956)


Package:  cflow-1.7-12.fc43
Old package:  cflow-1.7-8.fc41
Summary:  Analyzes C files charting control flow within the program
RPMs: cflow
Size: 695.79 KiB
Size change:  834 B
Changelog:
  * Thu Jul 25 2024 Miroslav Such??  - 1.7-9
  - convert license to SPDX

  * Thu Jan 16 2025 Fedora Release Engineering  - 
1.7-10
  - Rebuilt for https://fedoraproject.org/wiki/Fedora_42_Mass_Rebuild

  * Thu Feb 20 2025 Terje Rosten  - 1.7-11
  - Fix build

  * Sat Feb 22 2025 Terje Rosten  - 1.7-12
  - Rebuild


Package:  chromium-133.0.6943.126-1.fc43
Old package:  chromium-133.0.6943.98-1.fc43
Summary:  A WebKit (Blink) powered web browser that Google doesn't want you 
to use
RPMs: chromedriver chromium chromium-common chromium-headless 
chromium-qt5-ui chromium-qt6-ui
Size: 427.27 MiB
Size change:  -45.63 KiB
Changelog:
  * Wed Feb 19 2025 Than Ngo  - 133.0.6943.126-1
  - Update to 133.0.6943.126
* CVE-2025-0999: Heap buffer overflow in V8
* CVE-2025-1426: Heap buffer overflow in GPU
* CVE-2025-1006: Use after free in Network


Package:  dkms-3.1.5-6.fc43
Old package:  dkms-3.1.5-1.fc42
Summary:  Dynamic Kernel Module Support Framework
RPMs: dkms
Size: 83.43 KiB
Size change:  194 B
Changelog:
  * Sat Feb 22 2025 Simone Caronni  - 3.1.5-2
  - Adjust systemd requirements for containers without systemd (ex. Fedora 42+).


Package:  endless-sky-0.10.12-1.fc43
Old package:  endless-sky-0.10.11-1.fc42
Summary:  Space exploration, trading, and combat game
RPMs: endless-sky endless-sky-data
Size: 333.74 MiB
Size change:  89.33 KiB
Changelog:
  * Sun Feb 23 2025 Gwyn Ciesla  - 0.10

python-progressbar2 v4.5.0 coming to F42 and rawhide

[Ankur Sinha]

Hi all,

Just a quick heads up. I'm looking to update python-progressbar2 to
v4.5.0 in F42 and rawhide.

I have a PR ready here:
https://src.fedoraproject.org/rpms/python-progressbar2/pull-request/7

The following packages depend on it:

*** osc-1.12.1-432.1.1.fc43.noarch ***
python3-progressbar2

*** osc-1.12.1-432.1.1.fc43.src ***
python3-progressbar2

*** python-xnat-0.7.0-6.fc43.src ***
python3dist(progressbar2)

*** python3-kiwi-boxed-plugin-0.2.38-2.fc42.noarch ***
python3.13dist(progressbar2)

*** python3-xnat-0.7.0-6.fc43.noarch ***
python3.13dist(progressbar2)

*** rpmdevtools-9.6-9.fc42.noarch ***
python3dist(progressbar2)

*** rpmdevtools-9.6-9.fc42.src ***
python3dist(progressbar2)


I've run an impact check in COPR here.  All the above apart from
rpmdevtools seem to be fine with the new version:

https://copr.fedorainfracloud.org/coprs/ankursinha/progressbar2-4.5.0/monitor/

rpmdevtools fails because of an unrelated error:

+ autoreconf
/var/tmp/rpm-tmp.zeSIxe: line 47: autoreconf: command not found
error: Bad exit status from /var/tmp/rpm-tmp.zeSIxe (%build)

https://download.copr.fedorainfracloud.org/results/ankursinha/progressbar2-4.5.0/fedora-rawhide-x86_64/08692127-rpmdevtools/builder-live.log.gz

Please let me know if there are any concerns, otherwise I'll merge the
PR and build (and push updates to F42) in a week, on 01 March.

-- 
Thanks,
Regards,
Ankur Sinha "FranciscoD" (He / Him / His) | 
https://fedoraproject.org/wiki/User:Ankursinha
Time zone: Europe/London


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

Re: Multiple kernels

[Benson Muite]

On Sun, Feb 23, 2025, at 9:55 AM, Samuel Sieb wrote:
> On 2/22/25 6:50 PM, Benson Muite wrote:
>> 
>> Fedora has a policy to support only one kernel.  Projects such as 
>> OpenHarmony support multiple kernels to enable reuse of components on 
>> devices with a wide range of compute capabilities - in particular mobile and 
>> edge devices.  Is this something Fedora would consider doing?  This would 
>> potentially benefit spins aimed for mobile and desktop use.
>
> What do you mean by multiple kernels?

Envisage some of the following options:
a) Enabling use of the mainline linux kernel but tuned for different operating 
expectations - desktop, mobile or server
b) Options for integrating other existing kernels such as GNU/Hurd or LinuxLibre


-- 
___
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: Multiple kernels

[Mateus Rodrigues Costa]

Em dom., 23 de fev. de 2025, 16:15, Richard W.M. Jones 
escreveu:

> On Sun, Feb 23, 2025 at 09:14:21PM +0300, Benson Muite wrote:
> >
> >
> > On Sun, Feb 23, 2025, at 9:55 AM, Samuel Sieb wrote:
> > > On 2/22/25 6:50 PM, Benson Muite wrote:
> > >>
> > >> Fedora has a policy to support only one kernel.  Projects such as
> OpenHarmony support multiple kernels to enable reuse of components on
> devices with a wide range of compute capabilities - in particular mobile
> and edge devices.  Is this something Fedora would consider doing?  This
> would potentially benefit spins aimed for mobile and desktop use.
> > >
> > > What do you mean by multiple kernels?
> >
> > Envisage some of the following options:
> >
> > a) Enabling use of the mainline linux kernel but tuned for different
> > operating expectations - desktop, mobile or server
>
> Can you be (much, much) more precise?  Mainline Linux can easily be
> tuned for different deployments already.  See Fedora spins, or more
> specifically, Fedora power profiles.
>
> Is there something (again, be very specific) that requires a different
> kernel package?
>
> > b) Options for integrating other existing kernels such as GNU/Hurd or
> LinuxLibre
>
> The experience with Debian is this is a lot of work, with a negligible
> userbase.  People can already run a Fedora userspace on top of other
> Linux and other kernels.  For RISC-V, I sometimes have to run Fedora
> on top of vendor kernels with lots of weird non-upstream nonsense in
> them, but I don't expect Fedora to support me in this endeavour.
>
> Rich.
>
> --
> Richard Jones, Virtualization Group, Red Hat
> http://people.redhat.com/~rjones
> Read my programming and virtualization blog: http://rwmj.wordpress.com
> Fedora Windows cross-compiler. Compile Windows programs, test, and
> build Windows installers. Over 100 libraries supported.
> http://fedoraproject.org/wiki/MinGW
>
> --
> ___
> 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


IIRC the two cases that make the most sense are installing a mainline
kernel and a LTS kernel. The LTS kernel usually being useful if the main
Fedora kernel has issues.

AFAIK both can be easily installed via COPRs though. So, I don't know how
much it would benefit from official support.

Thanks for your time,
Mateus Rodrigues Costa
-- 
___
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: Proposal: Allow all packagers to push empty commits to any package

[Fabio Valentini]

On Sun, Feb 23, 2025 at 11:17 PM Zbigniew Jędrzejewski-Szmek
 wrote:
>
> I still think we should always require a changelog entry, so that that
> the reason for the rebuild is always explicit.
>
> (In the normal case, there should never be a need for "trivial"
> rebuilds, and rebuilds should be for cases when there really is an
> imporant change. If your API or ABI changes all the time in a way that
> is backward incompatible and no-change rebuilds are required, then
> _that_ is the problem and something to reconsider. We shouldn't build
> a system to make such cases silent.)

It's a tradeoff. I'd very much like all spec file changes to be
accompanied by a changelog entry.
But for no-spec-change rebuilds? I'm not sure it's worth it to
*require* changelog entries for those, when it costs us free
nothing-to-do-at-all rebuilds.
(Yes, I did change my mind on this since the rpmautospec stuff was discussed.)

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: Need help with "cannot open display" error when %pyproject_check_import is run

[Ben Beasley]

On 2/23/25 7:14 PM, Alexander Ploumistos wrote:

That is what I ended up doing and it is indeed unfortunate, we don't
have that many packages with so thorough testing. I will get in touch
with upstream about a couple of regressions and I will bring up the
issues with the tests when I do. Do you want me to cc you in the
discussion?
Either way is OK with me. I am willing to put a reasonable effort into 
helping out, but I don’t have much interest in the package *per se*. I 
think I originally got involved with running more tests in 
input-remapper while I was impact-checking 
https://fedoraproject.org/wiki/Changes/Update_To_Pydantic_Version_2.



Best regards,
A.


P.S.: the source file for the update was already in the lookaside
cache when I tried to upload it. Is there a way to see how it got
there?
Not that I know of, but you will only get that message if the SHA-512 
checksum (not just the name) matches what you’re trying to upload, so 
you needn’t worry that the tarball has different contents. It’s possible 
that I might have uploaded it while experimenting with the tests – I 
don’t really remember.

--
___
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: Follow-up on Fedora Aide Project Bug Report

[Jian Peng]

Thank you for your response.

I still have some questions regarding the issue with the patch
*aide-verbose.patch*. You mentioned that it is easy to verify if the patch
gets applied and that it is a revert. However, I am unsure why the
following issues are not causing any errors during compilation:

   1.

   *Scope Issue with num Variable*: The num variable is defined in the
   set_database_attr_option function, but it is used in the
   eval_config_statement function. As per my understanding of C language,
   variables are only accessible within the scope in which they are defined.
   Therefore, I would expect a compilation error when trying to use num in
   a different function. Could you please clarify why this scope issue does
   not prevent the code from compiling successfully?
   2.

   *Illogical Condition (if (num < 0 && num > 255))*: The condition if (num
   < 0 && num > 255) seems logically incorrect because num cannot
   simultaneously be less than 0 and greater than 255. In most cases, such a
   condition would either be flagged as an error or at least a warning by the
   compiler. However, the code compiles without any issues. Is it possible
   that the compiler optimizes this out, or is there something else I'm
   missing?

I would appreciate your insights on these issues and any clarification
regarding how they do not interfere with the patch's application or
compilation process.

Thank you once again for your time and attention.

 Peng


Ian Kent  于2025年2月24日周一 11:59写道：

> On 24/2/25 11:07, Jian Peng wrote:
> > Dear Fedora Development Team,
> > I hope this email finds you well.
> > I have submitted a bug report on Fedora's Bugzilla regarding an issue
> > with the Aide project (ID: 2346091
> > ), which involves
> > a patch fix and modification for the project.
> > As I have not received a response yet, I would like to follow up
> > through this mailing list. I am seeking further assistance or guidance
> > regarding the progress of the patch and the steps for handling it.
> > If replying to Bugzilla is not convenient for you, I’ll briefly
> > summarize the issue here:
>
> What is it you are asking to be done?
>
>
> It's easy enough to verify the patch gets applied and it is a revert.
>
> The package builds fine as it is.
>
> So I don't know what you are asking.
>
>
> Ian
>
> >
> > ``` diff -up ./src/conf_eval.c.fix ./src/conf_eval.c ---
> > ./src/conf_eval.c.fix 2023-12-22 12:12:22.961141634 +0100 +++
> > ./src/conf_eval.c 2023-12-22 14:09:21.217786675 +0100 @@ -166,6 +166,7
> > @@ static DB_ATTR_TYPE eval_attribute_expre static void
> > set_database_attr_option(DB_ATTR_TYPE attr, int linenumber, char
> > *filename, char* linebuf) { char *str; +long num;
> > DB_ATTR_TYPE hashes = get_hashes(true); if
> > (attr&(~hashes)) { @@ -298,8 +299,20 @@ static void
> > eval_config_statement(config
> > LOG_CONFIG_FORMAT_LINE(LOG_LEVEL_CONFIG, "set 'config_version' option
> > to '%s'", str) break; case VERBOSE_OPTION: -
> >  log_msg(LOG_LEVEL_ERROR, "%s:%d: 'verbose' option is no longer
> > supported, use 'log_level' and 'report_level' options instead (see man
> > aide.conf for details) (line: '%s')", conf_filename, conf_linenumber,
> > conf_linebuf); -exit(INVALID_CONFIGURELINE_ERROR); +
> >  log_msg(LOG_LEVEL_CONFIG, "%s:%d: 'verbose' option is deprecated,
> > use 'log_level' and 'report_level' options instead (see man aide.conf
> > for details) (line: '%s')", conf_filename, conf_linenumber,
> > conf_linebuf); +str = eval_string_expression(statement.e,
> > linenumber, filename, linebuf); +num = strtol(str, NULL,
> > 10); + +if (num < 0 && num > 255) { +
> >  LOG_CONFIG_FORMAT_LINE(LOG_LEVEL_ERROR, "invalid verbose level:
> > '%s'", str); +exit(INVALID_CONFIGURELINE_ERROR); +
> >} + +if (num >= 10) { +
> >  set_log_level(LOG_LEVEL_DEBUG); +} + +
> >  free(str); break; case LIMIT_CMDLINE_OPTION:
> > /* command-line options are ignored here */ ```
> > The patch 'aide-verbose.patch' contains a scoping issue with the `num`
> > variable, which is defined in one function
> > (`set_database_attr_option`) but used in another
> > (`eval_config_statement`), causing a compilation error. Additionally,
> > the condition `if (num < 0 && num > 255)` is logically incorrect as
> > `num` cannot simultaneously be less than 0 and greater than 255.
> > Thank you for your time and attention. Looking forward to your response.
> > Thank you!
> > penny
> > Student
> >
> --
> ___
> 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_guidel

Re: Follow-up on Fedora Aide Project Bug Report

[Adam Williamson]

On Mon, 2025-02-24 at 11:59 +0800, Ian Kent wrote:
> On 24/2/25 11:07, Jian Peng wrote:
> > Dear Fedora Development Team,
> > I hope this email finds you well.
> > I have submitted a bug report on Fedora's Bugzilla regarding an issue 
> > with the Aide project (ID: 2346091 
> > ), which involves 
> > a patch fix and modification for the project.
> > As I have not received a response yet, I would like to follow up 
> > through this mailing list. I am seeking further assistance or guidance 
> > regarding the progress of the patch and the steps for handling it.
> > If replying to Bugzilla is not convenient for you, I’ll briefly 
> > summarize the issue here:
> 
> What is it you are asking to be done?
> 
> 
> It's easy enough to verify the patch gets applied and it is a revert.
> 
> The package builds fine as it is.
> 
> So I don't know what you are asking.

I don't think it's that simple, in fact it's pretty weird. There is no
'reversion' going on. The patch does not change anything.

https://bugzilla.redhat.com/show_bug.cgi?id=2346091#c3

I suspect what's going on is that patch -R -b does something a bit odd
in this case - it applies the patch *to the 'backup' file* not the
original. But that's just my guess as to how this can possibly be
happening, it definitely seems strange.

The patch isn't *breaking* anything, but it's not fixing anything
either, and it's very weird, so it probably should just get taken out.
-- 
Adam Williamson (he/him/his)
Fedora QA
Fedora Chat: @adamwill:fedora.im | Mastodon: @ad...@fosstodon.org
https://www.happyassassin.net




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

Fedora 42 compose report: 20250223.n.0 changes

[Fedora Branched Report]

OLD: Fedora-42-20250222.n.0
NEW: Fedora-42-20250223.n.0

= SUMMARY =
Added images:0
Dropped images:  1
Added packages:  0
Dropped packages:0
Upgraded packages:   0
Downgraded packages: 0

Size of added packages:  0 B
Size of dropped packages:0 B
Size of upgraded packages:   0 B
Size of downgraded packages: 0 B

Size change of upgraded packages:   0 B
Size change of downgraded packages: 0 B

= ADDED IMAGES =

= DROPPED IMAGES =
Image: i3 live aarch64
Path: Spins/aarch64/iso/Fedora-i3-Live-aarch64-42-20250222.n.0.iso

= ADDED PACKAGES =

= DROPPED PACKAGES =

= UPGRADED PACKAGES =

= DOWNGRADED PACKAGES =
-- 
___
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: Multiple kernels

[Richard W.M. Jones]

On Sun, Feb 23, 2025 at 09:14:21PM +0300, Benson Muite wrote:
> 
> 
> On Sun, Feb 23, 2025, at 9:55 AM, Samuel Sieb wrote:
> > On 2/22/25 6:50 PM, Benson Muite wrote:
> >> 
> >> Fedora has a policy to support only one kernel.  Projects such as 
> >> OpenHarmony support multiple kernels to enable reuse of components on 
> >> devices with a wide range of compute capabilities - in particular mobile 
> >> and edge devices.  Is this something Fedora would consider doing?  This 
> >> would potentially benefit spins aimed for mobile and desktop use.
> >
> > What do you mean by multiple kernels?
> 
> Envisage some of the following options:
>
> a) Enabling use of the mainline linux kernel but tuned for different
> operating expectations - desktop, mobile or server

Can you be (much, much) more precise?  Mainline Linux can easily be
tuned for different deployments already.  See Fedora spins, or more
specifically, Fedora power profiles.

Is there something (again, be very specific) that requires a different
kernel package?

> b) Options for integrating other existing kernels such as GNU/Hurd or 
> LinuxLibre

The experience with Debian is this is a lot of work, with a negligible
userbase.  People can already run a Fedora userspace on top of other
Linux and other kernels.  For RISC-V, I sometimes have to run Fedora
on top of vendor kernels with lots of weird non-upstream nonsense in
them, but I don't expect Fedora to support me in this endeavour.

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
Fedora Windows cross-compiler. Compile Windows programs, test, and
build Windows installers. Over 100 libraries supported.
http://fedoraproject.org/wiki/MinGW

-- 
___
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: Proposal: Allow all packagers to push empty commits to any package

[Zbigniew Jędrzejewski-Szmek]

On Fri, Feb 21, 2025 at 06:27:42PM +0100, Fabio Valentini wrote:
> On Fri, Feb 21, 2025 at 5:13 PM Miro Hrončok  wrote:
> >
> > On 21. 02. 25 12:41, Fabio Valentini wrote:
> > > On Thu, Feb 20, 2025 at 1:17 PM Miro Hrončok  wrote:
> > >>
> > >> Hello.
> > >>
> > >> With the recent discussions about provenpackagers in Fedora, I recently 
> > >> got an
> > >> idea.
> > >>
> > >> One of the common needs for provenpackagers is to simply "bump and 
> > >> rebuild" a
> > >> set of dependencies.
> > >>
> > >> All packagers are already able to build anything (except a very specific 
> > >> and
> > >> small set of specially-signed packages). However, to bump the package, 
> > >> they
> > >> need commit rights. For that reason, provenpackager rights are often 
> > >> required.
> > >>
> > >> With the wide adoption of %autorelease, such bump commits are empty, 
> > >> which
> > >> should be easy to verify.
> > >>
> > >> What if we allowed all packagers to push empty commit to any package? 
> > >> That
> > >> should eliminate *some* need for provenpackager access. We would also
> > >> communicate in our policies that such bumps do not require prior 
> > >> agreement with
> > >> the maintainers to avoid confusion about "what are we allowed to do".
> > >
> > > This sounds a bit more complicated than it needs to be ...
> > > I would much rather explore not having to push empty commits *at all*,
> > > and have koji auto-increment the build number if it would cause an NVR
> > > conflict ... (yes, this should be possible with minor changes to the
> > > %dist macro and some small additions to koji).
> >
> > IIRC this is the direction we explicitly decided not to go with 
> > %autorelease.
> > We wanted the rebuild reason committed.
> 
> Those are kind of two orthogonal issues. You could still use an empty
> commit if you *want* a changelog entry :)

I still think we should always require a changelog entry, so that that
the reason for the rebuild is always explicit.

(In the normal case, there should never be a need for "trivial"
rebuilds, and rebuilds should be for cases when there really is an
imporant change. If your API or ABI changes all the time in a way that
is backward incompatible and no-change rebuilds are required, then
_that_ is the problem and something to reconsider. We shouldn't build
a system to make such cases silent.)

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

Re: Proposal: Allow all packagers to push empty commits to any package

[Zbigniew Jędrzejewski-Szmek]

On Thu, Feb 20, 2025 at 09:06:15AM -0500, Ben Beasley wrote:
> I would also point out that incompatible updates are still supposed to be
> announced a week in advance, with all impacted packages’ maintainers CC’ed
> or BCC’ed. This allows a week for someone to read their email and speak up
> about any special circumstances.
> 
> For updates with more than a handful of packages that need to be rebuilt,
> making affirmative contact with a maintainer of each package is *much*
> harder than just making an announcement and saying “I’ll rebuild all of
> these packages unless I hear otherwise.” I’ve never had someone ask me not
> to rebuild a package, but the opportunity is there.

Right. You are an experienced packager and you have never heard of
anyone say "no". I have been a packager for a long time too, and
I also don't recall any such cases. Does it then make sense to go
through those extra steps if this has no actual result except slowing
things down?

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

Re: Proposal: Allow all packagers to push empty commits to any package

[Neal Gompa]

On Sun, Feb 23, 2025 at 5:22 PM Zbigniew Jędrzejewski-Szmek
 wrote:
>
> On Thu, Feb 20, 2025 at 09:06:15AM -0500, Ben Beasley wrote:
> > I would also point out that incompatible updates are still supposed to be
> > announced a week in advance, with all impacted packages’ maintainers CC’ed
> > or BCC’ed. This allows a week for someone to read their email and speak up
> > about any special circumstances.
> >
> > For updates with more than a handful of packages that need to be rebuilt,
> > making affirmative contact with a maintainer of each package is *much*
> > harder than just making an announcement and saying “I’ll rebuild all of
> > these packages unless I hear otherwise.” I’ve never had someone ask me not
> > to rebuild a package, but the opportunity is there.
>
> Right. You are an experienced packager and you have never heard of
> anyone say "no". I have been a packager for a long time too, and
> I also don't recall any such cases. Does it then make sense to go
> through those extra steps if this has no actual result except slowing
> things down?
>

I have asked people not to before, because I'm already doing something
with one of my packages and them doing a build would create
unnecessary conflicts and complications.

It definitely happens at times that a packager says "don't do it" when
something else is already going on.



-- 
真実はいつも一つ！/ 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: Need help with "cannot open display" error when %pyproject_check_import is run

[Alexander Ploumistos]

Thank you very much for taking the time to look into this Ben.

On Tue, Feb 18, 2025 at 1:08 PM Ben Beasley  wrote:
>
> I gather that you have already found that this will work for the
> import-only "smoke test":
>
>  # Make sure everything is at least importable. Skip
>  # inputremapper.bin.input_remapper_gtk because it requires a display.
>  %pyproject_check_import -e inputremapper.bin.input_remapper_gtk

I did, thanks to Karolina.

>
> I spent a little time attempting an update to input-remapper 2.1.1
> locally. I think that errors like
>
>  _ ERROR at setup of test_setup
> _
>  file
> /builddir/build/BUILD/input-remapper-2.1.1-build/input-remapper-2.1.1/tests/lib/test_setup.py,
> line 33
>def test_setup(cls):
>  E   fixture 'cls' not found
>  >   available fixtures: cache, capfd, capfdbinary, caplog,
> capsys, capsysbinary, doctest_namespace, monkeypatch, pytestconfig,
> record_property, record_testsuite_property, record_xml_attribute, recwarn,
> tmp_path, tmp_path_factory, tmpdir, tmpdir_factory
>  >   use 'pytest --fixtures [testpath]' for help on them.
>
> /builddir/build/BUILD/input-remapper-2.1.1-build/input-remapper-2.1.1/tests/lib/test_setup.py:33
>
> suggest upstream has accidentally made the tests incompatible with
> pytest as a runner, because test_setup looks like pytest's "magic
> syntax" for a test with a fixture. That’s unfortunate, because using
> pytest as the test runner allowed us to skip known failing tests easily
> by adding command-line options, while skipping an individual test with
> unittest requires patching the test source to add a decorator.

That is really a lot of work, I'm curious to see what other distros
will do about it (I strongly suspect they will just disable testing).


> Still, I thought it was worth trying to run the tests closer to the way
> upstream does in .github/workflows/test.yml.
>
>  %{py3_test_envvars} %{python3} -m unittest discover tests/unit
>
> Unfortunately, I still see a wall of errors like
>
> ==
>  ERROR: test_autoload (test_config.TestConfig.test_autoload)
> --
>  Traceback (most recent call last):
>File
> "/builddir/build/BUILD/input-remapper-2.1.1-build/input-remapper-2.1.1/tests/lib/test_setup.py",
> line 79, in setUp
>  patch.start()
>  ~~~^^
>File "/usr/lib64/python3.13/unittest/mock.py", line 1652, in start
>  result = self.__enter__()
>File "/usr/lib64/python3.13/unittest/mock.py", line 1474, in
> __enter__
>  raise RuntimeError("Patch is already started")
>  RuntimeError: Patch is already started
>
> I really don’t have any immediate insight into why that is happening.
>
> It’s a shame to disable the tests altogether, because this package has
> extensive test coverage and they serve as a very useful early warning of
> incompatibilities with new Python interpreter versions, system
> libraries, and so on. However, running tests is a "should," not a "must"
> (https://docs.fedoraproject.org/en-US/packaging-guidelines/Python/#_tests),
> and it looks like the difficulty of getting them working in the current
> release is high enough that simply omitting the tests would be
> justifiable. You’ll want to maintain the %pyproject_check_import "smoke
> test," of course.

That is what I ended up doing and it is indeed unfortunate, we don't
have that many packages with so thorough testing. I will get in touch
with upstream about a couple of regressions and I will bring up the
issues with the tests when I do. Do you want me to cc you in the
discussion?


Best regards,
A.


P.S.: the source file for the update was already in the lookaside
cache when I tried to upload it. Is there a way to see how it got
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
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Follow-up on Fedora Aide Project Bug Report

[Jian Peng]

Dear Fedora Development Team,
I hope this email finds you well.
I have submitted a bug report on Fedora's Bugzilla regarding an issue with
the Aide project (ID: 2346091
), which involves a
patch fix and modification for the project.
As I have not received a response yet, I would like to follow up through
this mailing list. I am seeking further assistance or guidance regarding
the progress of the patch and the steps for handling it.
If replying to Bugzilla is not convenient for you, I’ll briefly summarize
the issue here:

```

diff -up ./src/conf_eval.c.fix ./src/conf_eval.c
--- ./src/conf_eval.c.fix   2023-12-22 12:12:22.961141634 +0100
+++ ./src/conf_eval.c   2023-12-22 14:09:21.217786675 +0100
@@ -166,6 +166,7 @@ static DB_ATTR_TYPE eval_attribute_expre

 static void set_database_attr_option(DB_ATTR_TYPE attr, int
linenumber, char *filename, char* linebuf) {
 char *str;
+long num;

 DB_ATTR_TYPE hashes = get_hashes(true);
 if (attr&(~hashes)) {
@@ -298,8 +299,20 @@ static void eval_config_statement(config
 LOG_CONFIG_FORMAT_LINE(LOG_LEVEL_CONFIG, "set
'config_version' option to '%s'", str)
 break;
 case VERBOSE_OPTION:
-log_msg(LOG_LEVEL_ERROR, "%s:%d: 'verbose' option is no
longer supported, use 'log_level' and 'report_level' options instead
(see man aide.conf for details) (line: '%s')", conf_filename,
conf_linenumber, conf_linebuf);
-exit(INVALID_CONFIGURELINE_ERROR);
+log_msg(LOG_LEVEL_CONFIG, "%s:%d: 'verbose' option is
deprecated, use 'log_level' and 'report_level' options instead (see
man aide.conf for details) (line: '%s')", conf_filename,
conf_linenumber, conf_linebuf);
+str = eval_string_expression(statement.e, linenumber,
filename, linebuf);
+num = strtol(str, NULL, 10);
+
+if (num < 0 && num > 255) {
+LOG_CONFIG_FORMAT_LINE(LOG_LEVEL_ERROR, "invalid
verbose level: '%s'", str);
+exit(INVALID_CONFIGURELINE_ERROR);
+}
+
+if (num >= 10) {
+set_log_level(LOG_LEVEL_DEBUG);
+}
+
+free(str);
 break;
 case LIMIT_CMDLINE_OPTION:
 /* command-line options are ignored here */
```

The patch  'aide-verbose.patch' contains a scoping issue with the
`num` variable, which is defined in one function
(`set_database_attr_option`) but used in another
(`eval_config_statement`), causing a compilation error. Additionally,
the condition `if (num < 0 && num > 255)` is logically incorrect as
`num` cannot simultaneously be less than 0 and greater than 255.

Thank you for your time and attention. Looking forward to your response.
Thank you!
penny
Student
-- 
___
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 eln compose report: 20250224.n.0 changes

[Fedora ELN Report]

OLD: Fedora-eln-20250223.n.0
NEW: Fedora-eln-20250224.n.0

= SUMMARY =
Added images:2
Dropped images:  0
Added packages:  0
Dropped packages:0
Upgraded packages:   11
Downgraded packages: 0

Size of added packages:  0 B
Size of dropped packages:0 B
Size of upgraded packages:   82.86 MiB
Size of downgraded packages: 0 B

Size change of upgraded packages:   266.62 KiB
Size change of downgraded packages: 0 B

= ADDED IMAGES =
Image: BaseOS qcow2 s390x
Path: 
BaseOS/s390x/images/Fedora-ELN-Cloud-Base-Generic-11-20250224.n.0.s390x.qcow2
Image: BaseOS container s390x
Path: 
BaseOS/s390x/images/Fedora-ELN-Container-Base-Generic-11-20250224.n.0.s390x.oci.tar.xz

= DROPPED IMAGES =

= ADDED PACKAGES =

= DROPPED PACKAGES =

= UPGRADED PACKAGES =
Package:  ImageMagick-1:7.1.1.44-1.eln146
Old package:  ImageMagick-1:7.1.1.43-3.eln146
Summary:  An X application for displaying and manipulating images
RPMs: ImageMagick ImageMagick-c++ ImageMagick-libs
Size: 10.83 MiB
Size change:  22.79 KiB
Changelog:
  * Sun Feb 23 2025 Packit  - 1:7.1.1.44-1
  - Update to version 7.1.1.44
  - Resolves: rhbz#2347163


Package:  cppcheck-2.17.0-1.eln146
Old package:  cppcheck-2.16.2-2.eln145
Summary:  Tool for static C/C++ code analysis
RPMs: cppcheck
Size: 5.45 MiB
Size change:  49.12 KiB
Changelog:
  * Sun Feb 23 2025 Gwyn Ciesla  - 2.17.0-1
  - 2.17.0


Package:  kitinerary-24.12.2-4.eln146
Old package:  kitinerary-24.12.2-3.eln146
Summary:  A library containing itinerary data model and itinerary 
extraction code
RPMs: kitinerary
Size: 6.65 MiB
Size change:  894 B
Changelog:
  * Sun Feb 23 2025 Neal Gompa  - 24.12.2-4
  - Rebuild for poppler 25.02.0 again


Package:  lutris-0.5.19-1.eln146
Old package:  lutris-0.5.18-4.eln146
Summary:  Install and play any video game easily
RPMs: lutris
Size: 8.42 MiB
Size change:  319.03 KiB
Changelog:
  * Sun Feb 23 2025 Steve Cossette  - 0.5.19-1
  - Update to v0.5.19


Package:  meson-1.7.0-2.eln146
Old package:  meson-1.7.0-1.eln145
Summary:  High productivity build system
RPMs: meson
Size: 2.22 MiB
Size change:  -1.65 KiB
Changelog:
  * Sun Feb 23 2025 Antonio Trande  - 1.7.0-2
  - Rebuild for gnustep-base 1.31.0


Package:  munge-0.5.16-5.eln146
Old package:  munge-0.5.16-4.eln145
Summary:  Enables uid & gid authentication across a host cluster
RPMs: munge munge-devel munge-libs
Size: 712.94 KiB
Size change:  -1.87 KiB
Changelog:
  * Tue Feb 11 2025 Zbigniew J??drzejewski-Szmek  - 0.5.16-5
  - Drop call to %sysusers_create_compat


Package:  plasma-nm-6.3.1-2.eln146
Old package:  plasma-nm-6.3.1-1.eln146
Summary:  Plasma for managing network connections
RPMs: plasma-nm plasma-nm-fortisslvpn plasma-nm-l2tp 
plasma-nm-openconnect plasma-nm-openswan plasma-nm-openvpn plasma-nm-pptp 
plasma-nm-sstp plasma-nm-strongswan
Size: 8.33 MiB
Size change:  -11.71 KiB
Changelog:
  * Sun Feb 23 2025 Neal Gompa  - 6.3.1-2
  - Temporarily disable GNU compiler extensions
+ workaround for rhbz#2342065


Package:  python-beautifulsoup4-4.13.3-2.eln146
Old package:  python-beautifulsoup4-4.12.3-9.eln145
Summary:  HTML/XML parser for quick-turnaround applications like 
screen-scraping
RPMs: python3-beautifulsoup4
Size: 407.40 KiB
Size change:  82.38 KiB
Changelog:
  * Sat Feb 22 2025 Terje Rosten  - 4.13.3-1
  - 4.13.3

  * Sun Feb 23 2025 Terje Rosten  - 4.13.3-2
  - Update soupsieve disablement patch for 4.13
(Yaakov Selkowitz )


Package:  python-cwcwidth-0.1.10-1.eln146
Old package:  python-cwcwidth-0.1.9-7.eln145
Summary:  Python bindings for wc(s)width
RPMs: python3-cwcwidth
Size: 126.30 KiB
Size change:  -249 B
Changelog:
  * Sat Feb 22 2025 Terje Rosten  - 0.1.10-1
  - 0.1.10


Package:  signon-ui-0.15^20240205.eef943f-4.eln146
Old package:  signon-ui-0.15^20240205.eef943f-3.eln145
Summary:  Online Accounts Sign-on Ui
RPMs: signon-ui
Size: 242.59 KiB
Size change:  212 B
Changelog:
  * Sun Feb 23 2025 Neal Gompa  - 
0.15^20240205.eef943f-4
  - Rebuild for ppc64le enablement


Package:  uv-0.6.2-1.eln146
Old package:  uv-0.5.31-1.eln146
Summary:  An extremely fast Python package installer and resolver, written 
in Rust
RPMs: uv
Size: 39.50 MiB
Size change:  -192.29 KiB
Changelog:
  * Tue Feb 18 2025 Benjamin A. Beasley  - 0.6.0-1
  - Update to 0.6.0

  * Thu Feb 20 2025 Benjamin A. Beasley  - 0.6.1-1
  - Update to 0.6.1

  * Thu Feb 20 2025 Benjamin A. Beasley  - 0.6.2-1
  - Update to 0.6.2 (close RHBZ#2345851)



= DOWNGRADED PACKAGES =
-- 
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
h

Re: Follow-up on Fedora Aide Project Bug Report

[Ian Kent]

On 24/2/25 11:07, Jian Peng wrote:

Dear Fedora Development Team,
I hope this email finds you well.
I have submitted a bug report on Fedora's Bugzilla regarding an issue 
with the Aide project (ID: 2346091 
), which involves 
a patch fix and modification for the project.
As I have not received a response yet, I would like to follow up 
through this mailing list. I am seeking further assistance or guidance 
regarding the progress of the patch and the steps for handling it.
If replying to Bugzilla is not convenient for you, I’ll briefly 
summarize the issue here:


What is it you are asking to be done?


It's easy enough to verify the patch gets applied and it is a revert.

The package builds fine as it is.

So I don't know what you are asking.


Ian



``` diff -up ./src/conf_eval.c.fix ./src/conf_eval.c --- 
./src/conf_eval.c.fix 2023-12-22 12:12:22.961141634 +0100 +++ 
./src/conf_eval.c 2023-12-22 14:09:21.217786675 +0100 @@ -166,6 +166,7 
@@ static DB_ATTR_TYPE eval_attribute_expre static void 
set_database_attr_option(DB_ATTR_TYPE attr, int linenumber, char 
*filename, char* linebuf) {         char *str; +        long num;     
    DB_ATTR_TYPE hashes = get_hashes(true);         if 
(attr&(~hashes)) { @@ -298,8 +299,20 @@ static void 
eval_config_statement(config             
LOG_CONFIG_FORMAT_LINE(LOG_LEVEL_CONFIG, "set 'config_version' option 
to '%s'", str)             break;         case VERBOSE_OPTION: -       
     log_msg(LOG_LEVEL_ERROR, "%s:%d: 'verbose' option is no longer 
supported, use 'log_level' and 'report_level' options instead (see man 
aide.conf for details) (line: '%s')", conf_filename, conf_linenumber, 
conf_linebuf); -            exit(INVALID_CONFIGURELINE_ERROR); +       
     log_msg(LOG_LEVEL_CONFIG, "%s:%d: 'verbose' option is deprecated, 
use 'log_level' and 'report_level' options instead (see man aide.conf 
for details) (line: '%s')", conf_filename, conf_linenumber, 
conf_linebuf); +            str = eval_string_expression(statement.e, 
linenumber, filename, linebuf); +            num = strtol(str, NULL, 
10); + +            if (num < 0 && num > 255) { +               
 LOG_CONFIG_FORMAT_LINE(LOG_LEVEL_ERROR, "invalid verbose level: 
'%s'", str); +                exit(INVALID_CONFIGURELINE_ERROR); +     
       } + +            if (num >= 10) { +               
 set_log_level(LOG_LEVEL_DEBUG); +            } + +           
 free(str);             break;         case LIMIT_CMDLINE_OPTION:     
        /* command-line options are ignored here */ ```
The patch 'aide-verbose.patch' contains a scoping issue with the `num` 
variable, which is defined in one function 
(`set_database_attr_option`) but used in another 
(`eval_config_statement`), causing a compilation error. Additionally, 
the condition `if (num < 0 && num > 255)` is logically incorrect as 
`num` cannot simultaneously be less than 0 and greater than 255.

Thank you for your time and attention. Looking forward to your response.
Thank you!
penny
Student


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