Re: annocheck: -D_FORTIFY_SOURCE=2 detected, expected -D_FORTIFY_SOURCE=3

[Tulio Magno Quites Machado Filho]

Miro Hrončok  writes:

> It first showed up in 
> https://src.fedoraproject.org/rpms/python3.13/pull-request/58
>
> The Ci has all the logs, e.g.
>
> https://kojipkgs.fedoraproject.org//work/tasks/8452/117468452/build.log

Thanks for these links.

It looks like this is happening because the tests are still using
annocheck 12.40.
I can't reproduce this issue locally with the current annocheck version
available in rawhide (v12.53).

annocheck 12.53 reports the following message:
skip: fortify test because LTO compilation discards preprocessor options

-- 
Tulio Magno
--
___
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: annocheck: -D_FORTIFY_SOURCE=2 detected, expected -D_FORTIFY_SOURCE=3

[Tulio Magno Quites Machado Filho]

Siddhesh Poyarekar  writes:

> _FORTIFY_SOURCE (any level) should work perfectly with -O (any level).

Is this new? Or do you mean any level where optimization is enabled?
i.e. -On, where n >= 1

Anyway, a warning should be printed when using -O0 unless -Wno-cpp is
also used.

annocheck's source code even mention that -O2 might be needed.

-- 
Tulio Magno
--
___
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: LLVM Packaging Ideas for Fedora 41

[Tulio Magno Quites Machado Filho]

Neal Gompa  writes:

> You also have to do new package
> reviews for each new version instead of using the compatibility
> package exception to branch older releases into compatibility
> packages.

I don't think this will be needed because it is one of the exceptions [1]:

The package is being created so that multiple versions of the same
package can coexist in the distribution (or coexist between EPEL and
RHEL). The package MUST be properly named according to the naming
guidelines and MUST NOT conflict with all other versions of the same
package. 

AFAIU, this proposal is following all the requirements mentioned in this
exception.

[1] 
https://docs.fedoraproject.org/en-US/packaging-guidelines/ReviewGuidelines/#_package_review_process

-- 
Tulio Magno
--
___
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: LLVM Packaging Ideas for Fedora 41

[Tulio Magno Quites Machado Filho]

Nico Kadel-Garcia  writes:

> On Sat, Apr 27, 2024 at 12:35 AM Tom Stellard  wrote:
>> * Invert the order of compat/main packages.  Instead of having the compat 
>> package be
>> the old version, and the main package be the new version, we would have the 
>> compat package
>> be newer and the main package be older.  This would allow us to introduce a 
>> new version of
>> llvm without impacting other packages that depend on the main version of 
>> LLVM.
>
> My first thought is "don't make me hurt you". So are my second and
> third thoughts. Please do not leave the nominally obsolete version as
> the default cnotemporary version, the "main" release should always be
> the defult.

I'm not sure I understood this part or if there was a miscommunication
somewhere.

Considering that LLVM releases usually happen very late in Fedora's
development cycle, if the default LLVM version is changed, packages may
start to FTBFS very late in the development cycle if they buildrequire
the default LLVM version.

Notice that, in this proposal, packages that would prefer to use the new
version may still update them by buildrequiring the new versioned package.

With that said: do you really think that it's better to let packages
FTBFS late in the Fedora development cycle? If that's still true, could
you elaborate it, please?

> New, pre-release versions should be as short-lived as
> possible.

AFAIU, there are no plans to increase the time pre-release version will
be kept.

-- 
Tulio Magno
--
___
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: F41 Change Proposal: Replace Redit with Valkey (system-wide)

[Tulio Magno Quites Machado Filho]

Aoife Moloney  writes:

> == Scope ==
> * Proposal owners: add a valkey-compat package which will port Redis
> configurations to Valkey.  Valkey 7.2.5 is 100% compatible with Redis.
> Add "Obsolete: redis" to valkey-compat package.

I suggest to also mention in the presence of `Conflicts: redis` in the
change proposal. Just for clarity.

-- 
Tulio Magno
--
___
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: F41 Change Proposal: Change Compose Settings (system-wide)

[Tulio Magno Quites Machado Filho]

Sirius via devel  writes:

> echo % of original
> echo Time to decompress the file, output to /dev/null
> time gzip -d -c ${INPUTFILE}.gz > /dev/null

Keep in mind that gzip has its own zlib implementation, while
createrepo_c uses the system-provided zlib.
That means, when creating a repository, results may very.

-- 
Tulio Magno
--
___
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: Obsoleted packages in F40

[Tulio Magno Quites Machado Filho]

Miroslav Suchý  writes:

> I just upgraded my workstation to F40 and it surprised how many packages were 
> reported by `remove-retired-packages`.
> There was lots of orphaned packages - there is nothing to do about them. But 
> there was lot of packages that were removed 
> intentionally. See the list at the end of my email.
>
> I want to highlight that we have policy for removing policy
> 
> https://docs.fedoraproject.org/en-US/package-maintainers/Package_Retirement_Process/#complete_removal
> which at the end mention adding the package to
> https://src.fedoraproject.org/rpms/fedora-obsolete-packages

Thanks for raising this. It was not clear to me these cases should be
completely removed.
I created a PR hoping to make it clear:
https://pagure.io/fedora-docs/package-maintainer-docs/pull-request/151

-- 
Tulio Magno
--
___
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: openclonk: undefined reference to `zmemcpy'

[Tulio Magno Quites Machado Filho]

"Martin Gansser"  writes:

> Hi,
>
> when compiling openclonk [1] on rawhide it fails with this error message [2]:
> /usr/bin/cmake -E cmake_link_script CMakeFiles/c4group.dir/link.txt 
> --verbose=1
> /usr/bin/g++ -O2 -flto=auto -ffat-lto-objects -fexceptions -g 
> -grecord-gcc-switches -pipe -Wall -Wno-complain-wrong-lang 
> -Wno-error=format-security -Wp,-U_FORTIFY_SOURCE,-D_FORTIFY_SOURCE=3 
> -Wp,-D_GLIBCXX_ASSERTIONS -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 
> -fstack-protector-strong -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1  -m64 
> -march=x86-64 -mtune=generic -fasynchronous-unwind-tables 
> -fstack-clash-protection -fcf-protection -fno-omit-frame-pointer 
> -mno-omit-leaf-frame-pointer -Wall -Wextra -Wredundant-decls -Wendif-labels 
> -Wpointer-arith -Wcast-qual -Wcast-align -Wwrite-strings -Winit-self 
> -Wsign-promo -Wno-reorder -Wno-unused-parameter -Wnon-virtual-dtor 
> -Woverloaded-virtual -Wformat-security -Werror=delete-incomplete -DNDEBUG 
> -flto=auto -fno-fat-lto-objects -Wl,-z,relro -Wl,--as-needed  
> -Wl,-z,pack-relative-relocs -Wl,-z,now 
> -specs=/usr/lib/rpm/redhat/redhat-hardened-ld-errors 
> -specs=/usr/lib/rpm/redhat/redhat-hardened-ld 
> -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1  
 -W
>  l,--build-id=sha1 -specs=/usr/lib/rpm/redhat/redhat-package-notes 
> CMakeFiles/c4group.dir/c4group_autogen/mocs_compilation.cpp.o 
> CMakeFiles/c4group.dir/src/c4group/C4GroupMain.cpp.o -o c4group  liblibmisc.a 
> /usr/lib64/libz.so -lpthread -lrt 
> make[2]: Leaving directory 
> '/builddir/build/BUILD/openclonk-701bcf38c9f3c4877e1b4a8651b9ce922b15969e/build'
> /usr/bin/ld: /tmp/ccgvFyfu.ltrans1.ltrans.o: in function `c4_gzread':
> /builddir/build/BUILD/openclonk-701bcf38c9f3c4877e1b4a8651b9ce922b15969e/src/zlib/gzio.c:450:(.text+0x3fd0):
>  undefined reference to `zmemcpy'
> collect2: error: ld returned 1 exit status
>
> How can this be fixed ??

The fastest way to work around this issue is by defining HAVE_MEMCPY
when building gzio.c.
You probably want to guarantee that other C macros are defined as well,
e.g. STDC.

In the long term, I suggest to work with upstream in order to stop using
zutil.h.  This is a zlib internal header that provides internal types
and functions and is strongly dependent on how zlib was built.
I also suggest to stop distributing their own gz* functions and reuse
the functions provided by the OS. This will guarantee that openclonk
will receive the latest fixes to that code.

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

Announcement: Retiring zlib and minizip-compat from Rawhide

[Tulio Magno Quites Machado Filho]

The zlib-ng-compat and minizip-ng-compat packages have been in Rawhide for
more than a month.
Considering things have been working well, we believe it's time to retire the
zlib and minizip-compat packages.

This step should not cause any changes, because zlib-ng-compat and
minizip-ng-compat already obsoleted them.
However, if you find any issues, please contact us.

[1] https://fedoraproject.org/wiki/Changes/ZlibNGTransition
[2] https://fedoraproject.org/wiki/Changes/MinizipNGTransition

-- 
Tulio Magno
--
___
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: Obsoleting zlib in Fedora Rawhide

[Tulio Magno Quites Machado Filho]

Tulio Magno Quites Machado Filho  writes:

> Following the recent approval from Fesco, I'm planning to distribute
> zlib-ng-compat packages for Rawhide later this week. 
> I hope this will give us enough time to work on the issues before
> Fedora 40 is released. 爛
>
> So, keep in mind this will *obsolete zlib in Rawhide*.
>
> This update is also known to trigger test failures in the following
> packages:
>
>  - binutils
>  - cpp-httplib
>  - git
>  - jose
>  - libpng
>  - openexr1
>  - openms
>  - python-3.12
>  - qpdf

With the help from upstream and downstream, all these packages already
have a solution available.
Some had fixes upstream and a few of them had changes applied only downstream.

With that said, I'm finally moving forward with the zlib-ng rebuilt that
will obsolete zlib.

Again, if you have any questions or find any issues, let me know.

Thanks to all maintainers upstream and downstream that helped with this!

-- 
Tulio Magno
--
___
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: Obsoleting zlib in Fedora Rawhide

[Tulio Magno Quites Machado Filho]

Yaakov Selkowitz  writes:

> Except that it's not 100% compatible, since all those packages aren't
> building/working with zlib-ng-compat.  At a minimum, you should be able
> to show that everything zlib-dependent successfully rebuilds with this,

I'm afraid I was not clear enough.
Packages built with zlib continue to work after replacing zlib with
zlib-ng-compat.

However, a small list of packages have tests that were written without
considering that one day we would have many different implementations of
zlib.
These tests need to be modified. In some cases, I believe they should be
disabled as they aim to test the zlib implementation instead of testing
their own code.

With that said, I haven't identified a compatibility issue with zlib-ng
yet. If you have, please let me know.

-- 
Tulio Magno
--
___
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: Obsoleting zlib in Fedora Rawhide

[Tulio Magno Quites Machado Filho]

Yaakov Selkowitz  writes:

> Also, since this is essentially an SONAME change wrt zlib, the initial
> build and mini-mass-rebuild of all dependents should occur in a side-
> tag.  You're announcement doesn't mention this occurring.

There are no SONAME changes.

With zlib we have:

$ rpm -qf /usr/lib64/libz.so.1
zlib-1.2.13-5.fc40.x86_64
$ readelf -a /usr/lib64/libz.so.1.2.13 | grep -i soname
 0x000e (SONAME) Library soname: [libz.so.1]

With zlib-ng-compat we have:

$ rpm -qf /usr/lib64/libz.so.1
zlib-ng-compat-2.1.3-7.fc40.x86_64
$ readelf -a /usr/lib64/libz.so.1  | grep soname
 0x000e (SONAME) Library soname: [libz.so.1]

No mass rebuilds are required. zlib-ng in compat mode aims to be API and
ABI compatible with zlib.

-- 
Tulio Magno
--
___
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: Obsoleting zlib in Fedora Rawhide

[Tulio Magno Quites Machado Filho]

Miro Hrončok  writes:

> Do you happen to have a build.log available for this?

I re-run the tests for all architectures here:
https://copr.fedorainfracloud.org/coprs/tuliom/zlib-ng-compat-mpb/build/6726758/

Keep in mind that zlib-ng defines the following:
#define ZLIB_VERSION "1.3.0.zlib-ng"

Source upstream: https://github.com/zlib-ng/zlib-ng/blob/develop/zlib.h.in#L61

> It's only python3.12 that fails and not the others?

I tested previous versions too, but I didn't analyse their results.
I can re-run them if you believe this is important.
Likewise for python3.13, which was not available when I started this test.

-- 
Tulio Magno
--
___
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: Obsoleting zlib in Fedora Rawhide

[Tulio Magno Quites Machado Filho]

Re-sending to binutils, openexr and python3.12 maintainers.
Sorry, I messed up your email aliases in my first message.

-- 
Tulio Magno


Tulio Magno Quites Machado Filho  writes:

> Following the recent approval from Fesco, I'm planning to distribute
> zlib-ng-compat packages for Rawhide later this week. 
> I hope this will give us enough time to work on the issues before
> Fedora 40 is released. 爛
>
> So, keep in mind this will *obsolete zlib in Rawhide*.
>
> This update is also known to trigger test failures in the following
> packages:
>
>  - binutils
>  - cpp-httplib
>  - git
>  - jose
>  - libpng
>  - openexr
>  - openms
>  - python3.12
>  - qpdf
>
> In general, the failing tests expect that libz will always have the same
> behavior, e.g.
>  - same output length
>  - identical output
>  - same version string format
>
> This will require changes in order to guarantee the tests do succeed.
>
> If you have any questions or need help with these issues, let me know.
>
> -- 
> Tulio Magno
> --
> ___
> 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

Obsoleting zlib in Fedora Rawhide

[Tulio Magno Quites Machado Filho]

Following the recent approval from Fesco, I'm planning to distribute
zlib-ng-compat packages for Rawhide later this week. 
I hope this will give us enough time to work on the issues before
Fedora 40 is released. 爛

So, keep in mind this will *obsolete zlib in Rawhide*.

This update is also known to trigger test failures in the following
packages:

 - binutils
 - cpp-httplib
 - git
 - jose
 - libpng
 - openexr1
 - openms
 - python-3.12
 - qpdf

In general, the failing tests expect that libz will always have the same
behavior, e.g.
 - same output length
 - identical output
 - same version string format

This will require changes in order to guarantee the tests do succeed.

If you have any questions or need help with these issues, let me know.

-- 
Tulio Magno
--
___
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: [Fedora Change draft] Zlib transition to zlib-ng

[Tulio Magno Quites Machado Filho]

"Richard W.M. Jones"  writes:

> However if we succeed in making zlib-ng be the default with the
> compatible zlib API then I'll remove that change.

Ideally, it's prefered to use the zlib-ng API
Any reasons for switching back?

-- 
Tulio Magno
___
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: Specify koji build machine mem req via. spec file

[Tulio Magno Quites Machado Filho]

Julian Sikorski  writes:

> Does a hammer smaller than -g1 also exist for issues like:
>
> relocation truncated to fit: R_X86_64_32 against `.debug_info'
> https://kojipkgs.fedoraproject.org//work/tasks/1615/107091615/build.log

This is saying that mame is too large to fit in the default code model
(-mcmodel=small).

You may need to build with -mcmodel=medium or -mcmodel=large in order to
get relocations that can deal with this kind of large binaries.

Linking agains shared libraries could also help in this case, but it may
be more difficult if upstream does not support it.

-- 
Tulio Magno
___
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: spec file with aarch64 specific Fortran build flags

[Tulio Magno Quites Machado Filho]

Sébastien Le Roux  writes:

> Dear all,
> in the past weeks the updates of GCC for both Fedora and Debian have 
> introduce few identical Fortran modifications:
>
> fortran/108961
> fortran/109684
> fortran/110825
>
> As a result my I cannot build the RPM package (nor the Debian package) 
> for my program 'atomes' anymore,
> because the ARM 64 build failed with the same error related to an OpenMP 
> instruction in a Fortran file.

I reproduced this error and it looks like a compiler bug:

fortran/spherical.F90: In function ‘plegendre_’:
fortran/spherical.F90:345:12: warning: ‘pll’ may be used uninitialized 
[-Wmaybe-uninitialized]
  345 | END FUNCTION
  |^
fortran/spherical.F90:307:40: note: ‘pll’ was declared here
  307 |   DOUBLE PRECISION :: fact, oldfact, pll, pmm, pmmp1, omx2
  |^
fortran/spherical.F90: In function ‘sphericals_._omp_fn.1’:
fortran/spherical.F90:179:36: error: unrecognizable insn:
  179 |   !$OMP DO SCHEDULE(STATIC,NS/NUMTH)
  |^
(insn 1295 924 926 20 (parallel [
(set (reg:DI 24 x24)
(zero_extend:DI (mem/c:SI (plus:DI (reg/f:DI 29 x29)
(const_int -260 [0xfefc])) [29 
%sfp+-260 S4 A32])))
(set (reg:DI 7 x7)
(zero_extend:DI (mem/c:SI (plus:DI (reg/f:DI 29 x29)
(const_int -256 [0xff00])) [29 
%sfp+-256 S4 A32])))
]) "fortran/spherical.F90":184:35 -1
 (nil))
*** WARNING *** there are active plugins, do not report this as a bug unless 
you can reproduce it without enabling any plugins.
Event| Plugins
PLUGIN_FINISH_UNIT   | annobin: Generate final annotations
PLUGIN_START_UNIT| annobin: Generate global annotations
PLUGIN_ALL_PASSES_START  | annobin: Generate per-function annotations
PLUGIN_ALL_PASSES_END| annobin: Register per-function end symbols
during RTL pass: cprop_hardreg
fortran/spherical.F90:179:36: internal compiler error: in extract_insn, at 
recog.cc:2791
Please submit a full bug report, with preprocessed source.
See  for instructions.
make[2]: *** [Makefile:1230: fortran/spherical.o] Error 1
make[2]: Leaving directory '/builddir/build/BUILD/Atomes-GNU-1.1.12/src'
make[2]: *** Waiting for unfinished jobs
make[2]: Entering directory
'/builddir/build/BUILD/Atomes-GNU-1.1.12/src'


Have you already reported this issue upstream?

> It was pointed out to me that the build succeed changing the -'O2' 
> option of the Fortran FLAGS by '-O1'.
>
> Following this :
>
> https://fedoraproject.org/wiki/Changes/RPMMacrosForBuildFlags

After a discussion in this mailing list there was an agreement to
restrict the scope of this change and use different names.
Now, the packages can't use _pkg_extra_* anymore.


-- 
Tulio Magno
___
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: Build does not finish

[Tulio Magno Quites Machado Filho]

"Kai A. Hiller"  writes:

> Hello,
>
> I started a build with `fedpkg build`, but after 43h and counting I 
> don‘t think it will finish anymore. Is there a way to terminate the 
> build? The build is 
> https://koji.fedoraproject.org/koji/taskinfo?taskID=106154761

Look for this command:

dnf install koji
koji cancel [options]  [ ...]

More information with:

koji cancel --help

-- 
Tulio Magno
___
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: The new Change discussion process is painful

[Tulio Magno Quites Machado Filho]

Matthew Miller  writes:

> Everything is a balance.
>
> Even if you don't want to follow Fedora Discussion in general, to follow
> changes, you can go subscribe to just those by email. 
>
> 1. Sign in you with your Fedora account
>
> 2. Complete creating a Discussion account if you haven't already
>
> 3. Go to https://discussion.fedoraproject.org/my/preferences/tracking
>
> 4. Remove everything from all of the Categores and Teams & Tags dropdowns
>that you don't want. (A few things are populated as defaults.)
>
> 5. Under Categories, add "Change Proposals" to either Watched (which will
>send a notification for every post) or Watching First Post (which does
>what it says).
>
> 6. Go to https://discussion.fedoraproject.org/my/preferences/emails
>
> 7. Change "Send me email when I have a notification" to "always", if it
>isn't already.
>
> 8. Optional: notification messages will set a List-Id corresponding to the
>Change Proposals category. You can set up your mail filters to do what
>you like with those.
>
> 9. To interact, you can either come to the Discussion web interface, or
>just reply to the email notifications.

I've been trying this, but Discourse reverted part of my settings without
any warnings after a few months.

I raised the issue here:
https://discussion.fedoraproject.org/t/discourse-dropped-an-email-address-from-my-preferences-today/89614

I still do not understand what happened 2 days ago.

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

RFC: Pull request for zlib-ng compat Was: zlib-ng as a compat replacement for zlib

[Tulio Magno Quites Machado Filho]

I went ahead and started to modify Jacek's initial proposal [1] in order
to integrate the feedback from this thread as well as some changes I had
in mind.

I have created a RFC pull request [2]. Hopefully this will help answer
some of the questions we've seen here. Feedback is appreciated.

I have also created packages in a Copr project [3], but I haven't tested
this yet.

Future work:
 - Run tests using these packages.
 - Write the F40 change request based on the RFC pull request.

[1] https://bugzilla.redhat.com/show_bug.cgi?id=2145239
[2] https://src.fedoraproject.org/rpms/zlib-ng/pull-request/3
[3] https://copr.fedorainfracloud.org/coprs/tuliom/zlib-ng/

-- 
Tulio Magno
___
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: zlib-ng as a compat replacement for zlib

[Tulio Magno Quites Machado Filho]

Sorry, resending because the original message was rejected by the
mailing list.

Hi Lukas,

Lukas Javorsky  writes:
> Hi,
>
> I'm currently maintaining the zlib package across Fedora and Red Hat products.
>
> I like the proposal for the zlib-ng package, there are just a few questions 
> for @Tulio Magno Quites Machado Filho <mailto:tmach...@redhat.com> :
> 1) Just to clarify, do you want to have two separate packages (zlib-ng and 
> e.g. zlib-ng-compat) in Fedora? One with the `-DZLIB_COMPAT=ON` option 
> enabled and one without it?

Yes. While I do not have a personal preference, I believe it's important to 
provide the zlib-ng API for projects willing to use it instead of the zlib API.
I'm open to other suggestions too, including building zlib-ng twice and 
distributing them in different sub-packages as suggested by Michel.
Would you have any preferences?

> 2) What is your point of view on maintaining these packages? You will be the 
> main contact and I could be the secondary one?

LGTM.
Ali (in Cc.) has also demonstrated interest in this package too. I'd be happy 
to share this with both of you.

> 3) Same as 2) but for CentOS Stream and RHEL products?

Sorry, I'm afraid the decision on supporting RHEL products is beyond my pay 
grade.

> Next, I have a few scary scenarios in my head, which I'm not sure how would 
> be handled:

Please share all of them!
My experience maintaining long term libraries downstream is limited.

> 1) When we decide to migrate from zlib to zlib-ng and zlib-ng-compat, the 
> packages would still need to rewrite their code so they can use the pure (no 
> compat) zlib-ng functions and libraries. How many of the packages will be 
> able (and most importantly willing) to do that?

I disagree that packages "need to rewrite their code".
IMHO, most packages will probably keep using the zlib API and should magically 
link against the zlib-ng-compat package.

> 2) There are 271 RPMs dependent on zlib in ELN repo (there will be more in 
> the Fedora repo). It would mean that we would have to side-tag rebuild all of 
> them when switching to the zlib-ng-compat package. It may be challenging.

I'm planning to use the mass-prebuild tool on Copr first [1].

> If I understood something incorrectly please let me know, I'm trying to 
> understand it completely, what is the plan here. It will be needed to be 
> thoroughly documented in the Fedora Change.

Agreed.

> Overall, I think performance-wise this is a great idea. We just need to be 
> cautious about the compatibility.

Ack.

[1] https://gitlab.com/fedora/packager-tools/mass-prebuild

-- 
Tulio Magno
___
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: zlib-ng as a compat replacement for zlib

[Tulio Magno Quites Machado Filho]

"Richard W.M. Jones"  writes:

> The background to this is I've spent far too long trying to optimize
> the conversion of qcow2 files to raw files.  Most existing qcow2 files
> that you can find online are zlib compressed, including the qcow2
> images provided by Fedora.  Each cluster in the file is separately
> compressed as a zlib stream, and qemu uses zlib library functions to
> decompress them.  When downloading and decompressing these files, I
> measured 40%+ of the total CPU time is doing zlib decompression.

This number may go even higher on s390x [1] because zlib-ng supports
hardware acceleration.

qatzip [2] and libnxz [3] should provide performance on the same order of
magnitude for Intel and Power9 processors, with the negative side of not
using a single library.

> We already package zlib-ng in Fedora:
>
>   https://src.fedoraproject.org/rpms/zlib-ng/blob/rawhide/f/zlib-ng.spec
>   https://github.com/zlib-ng/zlib-ng
>
> In my test zlib-ng is about 40% faster.
>
> Sadly zlib-ng is not compiled with the ZLIB_COMPAT option.  What this
> means in practice is that the zlib functions have different names
> (eg. zng_inflateInit instead of inflateInit).  It is not a drop-in
> replacement for zlib and software would need to be adjusted to use it.
>
> However there is this bug / RFE to package the compat library.
>
>   https://bugzilla.redhat.com/show_bug.cgi?id=2145239
>
> It literally replaces /usr/lib64/libz.so.1, so pretty high stakes.  It
> has the appropriate Provides/Conflicts.
>
> Anyway, 40% (or whatever, but significant) performance improvement
> sounds good for a very widely used operation.
>
> So I'd like to ask Fedora ...
>
> What do we think about the opt in approach of adding a patch similar
> to the one proposed in bug 2145239, where I think you could "simply"
> install zlib-ng to get better performance with existing software?
> ("simply" because it seems high risk of going wrong)

Wearing my zlib-ng fedora maintainer hat:
I like the idea of this patch, although I think it needs a few changes.
I'd like to merge it and add another package with the same source code,
but different value for compat, i.e. package zlib-ng would still
distribute the zlib-ng API while the new package would distribute the
zlib-compatible API.

That way, if there are any projects using the zlib-ng API, they could
still be supported.

[1] https://github.com/rust-lang/libz-sys/pull/72#issuecomment-904020105
[2] https://src.fedoraproject.org/rpms/qatzip
[3] https://src.fedoraproject.org/rpms/libnxz

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

Tracker bug for approved change proposals

[Tulio Magno Quites Machado Filho]

I noticed that a few change proposals that have been approved still did
not get a bug tracker, e.g.: https://fedoraproject.org/wiki/Changes/LLVM-17

As things have changed this release, I'm wondering if the process
changed.
Is the bug creation still in plan?

-- 
Tulio Magno
___
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: redhat-rpm-config build flags updatesin rawhide

[Tulio Magno Quites Machado Filho]

Florian Weimer  writes:

> Today, I pushed a redhat-rpm-config update to rawhide,
> redhat-rpm-config-260-1.fc39.  The only expected change is that
> -Wno-complain-wrong-lang now shows up in %optflags (but not
> %build_cflags etc.).  It should prevent Fortran compilers from warning
> on -Werror=format-security (and failing to build with -Werror).  That
> bogus -Werror=format-security is also gone from %build_fflags.  I think
> I found a relatively concise way to express this in the macros language
> (using non-lexical macro bindings).
>
> There's some code in there for more -Werror= options, but it's disabled
> by default pending Fesco approval.
>
> I tested this change and it seems to work as expected, but I thought I
> should send this note nevertheless.

I'm seeing warnings when building with the new redhat-rpm-config with
clang:

warning: unknown warning option '-Wno-complain-wrong-lang'; did you
mean '-Wno-c++11-long-long'? [-Wunknown-warning-option] 

I'm also seeing other warnings that appear to be related:

/builddir/build/SPECS/llvm.spec: line 259: Macro %__build_for_lang_any 
defined but not used within scope
/builddir/build/SPECS/llvm.spec: line 259: Macro %__build_for_lang_cxx 
defined but not used within scope
/builddir/build/SPECS/llvm.spec: line 259: Macro %__build_for_lang_any 
defined but not used within scope
/builddir/build/SPECS/llvm.spec: line 259: Macro %__build_for_lang_c 
defined but not used within scope
/builddir/build/SPECS/llvm.spec: line 259: Macro %__build_for_lang_any 
defined but not used within scope
/builddir/build/SPECS/llvm.spec: line 259: Macro %__build_for_lang_c 
defined but not used within scope
/builddir/build/SPECS/llvm.spec: line 259: Macro %__build_for_lang_cxx 
defined but not used within scope
/builddir/build/SPECS/llvm.spec: line 259: Macro %__build_for_lang_any 
defined but not used within scope
/builddir/build/SPECS/llvm.spec: line 259: Macro %__build_for_lang_c 
defined but not used within scope
/builddir/build/SPECS/llvm.spec: line 259: Macro %__build_for_lang_cxx 
defined but not used within scope

All of this is happening on s390x.

Source: https://kojipkgs.fedoraproject.org//work/tasks/7633/103007633/build.log

-- 
Tulio Magno
___
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: Is there a chance to phase out `/lib64` directory?

[Tulio Magno Quites Machado Filho]

Kevin Kofler via devel  writes:

> Carlos O'Donell wrote:
>> And assembling those sysroots is not straight forward.
>
> The easiest way is to unpack a live image. If you are targeting an Arch-
> based or similar distro, you will probably get away with just unpacking the 
> image, because it installs development files by default. But if you are 
> targeting Fedora or a similar distro, you will probably want to compose a 
> custom live image with a bunch of -devel packages. (You can also try to 
> install packages within the sysroot, but if you are cross-compiling to a 
> different architecture, that is not straightforward, you either need to use 
> host tools and point them to the sysroot, or to use CPU emulation to run the 
> tools within the sysroot, or as a last resort to unpack package contents 
> manually.)

Containers might also help, e.g.:

podman run -it --rm \
  --mount=type=image,source=fedora:38-ppc64le,destination=/sysroot \
  fedora:38-x86_64 bash

The user still needs to compose both images with the required packages,
but it might be easier to keep them up-to-date.

-- 
Tulio Magno
___
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: Radeon with 64k page size (ppc64 and others)

[Tulio Magno Quites Machado Filho]

> On 06/01/2021  Daniel Pocock wrote:
> 
> Most packages compiled on one type of kernel will run on the other type
> but there could be a very small number that have to be recompiled if the
> Fedora kernel changes down to 4k.

I'm afraid changing the page size would be more complicated than that.
The same way that some projects assume everyone has a 4K page size, there are 
projects that assume ppc64le has a 64K page size [1].
One could argue that both types of projects have to change their code and be 
independent of the page size and I'd agree with that. But there are projects 
whose storage format depend on the page size, e.g. PMDK.

Other projects may assume ppc64le has a 64K page size in order to improve 
performance, e.g. gperftools/tcmalloc.
For this particular case, the current code works well on 4K page size, without 
any downgrade in performance. If modified to use 4K page size, it would have a 
negative impact on users with 64K page size.

[1] https://lists.ozlabs.org/pipermail/linuxppc-dev/2021-January/222993.html

> Regardless of the packages above, I still think the Btrfs issue is the
> biggest surprise for people and it is worse because it is the default
> filesystem now.  People can reboot into a new kernel but they may not be
> able to easily reformat their disks after mkfs at 64k.

Likewise for PMDK. I wouldn't be surprised if it works without any code 
changes, but I don't think anyone has tested it.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org