Re: gcc-12.0.0-0.4.fc36 in rawhide

[Zbigniew Jędrzejewski-Szmek]

On Sun, Jan 23, 2022 at 10:54:49AM +0100, Vitaly Zaitsev via devel wrote:
> On 22/01/2022 15:56, Kaleb Keithley wrote:
> >Which I presume is related to the failed rebuild of fmt[2] with gcc-12 and
> >thus I'm still getting a version of fmt compiled with gcc-11.
> 
> Fmt build failed on ppc64le due to another GCC 12 regression:
> 
> FAILED: libfmt.so.8.1.1
> : && /usr/bin/g++ -fPIC -O2 -flto=auto -ffat-lto-objects -fexceptions -g
> -grecord-gcc-switches -pipe -Wall -Werror=format-security
> -Wp,-D_FORTIFY_SOURCE=2 -Wp,-D_GLIBCXX_ASSERTIONS
> -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 -fstack-protector-strong
> -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1  -m64 -mcpu=power8
> -mtune=power8 -fasynchronous-unwind-tables -fstack-clash-protection -O2 -g
> -DNDEBUG  -Wl,-z,relro -Wl,--as-needed  -Wl,-z,now
> -specs=/usr/lib/rpm/redhat/redhat-hardened-ld
> -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1  -Wl,--build-id=sha1
> -Wl,-dT,/builddir/build/BUILD/.package_note-fmt-8.1.1-2.fc36.ppc64le.ld
> -shared -Wl,-soname,libfmt.so.8 -o libfmt.so.8.1.1
> CMakeFiles/fmt.dir/src/format.cc.o CMakeFiles/fmt.dir/src/os.cc.o
> -Wl,--as-needed && :
> {standard input}: Assembler messages:
> {standard input}:31583: Error: junk at end of line, first unrecognized
> character is `('
> {standard input}:31584: Error: expected comma after "operator"
> {standard input}:32352: Error: junk at end of line, first unrecognized
> character is `('
> {standard input}:32353: Error: expected comma after "operator"
> make: *** [/tmp/ccKWFwzK.mk:2: /tmp/ccqbVJLh.ltrans0.ltrans.o] Error 1
> lto-wrapper: fatal error: make returned 2 exit status
> compilation terminated.
> /usr/bin/ld: error: lto-wrapper failed
> collect2: error: ld returned 1 exit status

This looks similar to an issue I saw with dolfin, also only on ppc64le [1].
Disabling lto "solved" the issue.

Zbyszek

[1] https://kojipkgs.fedoraproject.org//work/tasks/2369/81482369/build.log
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Fedora-Cloud-35-20220124.0 compose check report

[Fedora compose checker]

No missing expected images.

Soft failed openQA tests: 1/8 (x86_64), 1/8 (aarch64)
(Tests completed, but using a workaround for a known bug)

Old soft failures (same test soft failed in Fedora-Cloud-35-20220123.0):

ID: 850 Test: x86_64 Cloud_Base-qcow2-qcow2 cloud_autocloud
URL: https://openqa.fedoraproject.org/tests/850
ID: 858 Test: aarch64 Cloud_Base-qcow2-qcow2 cloud_autocloud@uefi
URL: https://openqa.fedoraproject.org/tests/858

Passed openQA tests: 7/8 (x86_64), 7/8 (aarch64)
-- 
Mail generated by check-compose:
https://pagure.io/fedora-qa/check-compose
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: F36 Change: Package information on ELF objects (System-Wide Change proposal)

[Zbigniew Jędrzejewski-Szmek]

On Sat, Jan 22, 2022 at 08:54:02PM -0700, Jerry James wrote:
> On Fri, Jan 21, 2022 at 5:35 PM Robert-André Mauchin  
> wrote:
> > Sorry for the necro but there seems to be a problem with this change. It
> > broke multiple packages at the linking stage:
> > https://bugzilla.redhat.com/show_bug.cgi?id=2043178
> >
> > On the package-note repo https://github.com/systemd/package-notes
> > it is said that it requires binutils (>= 2.38) but it hasn't been
> > released yet.
> >
> > Can the owners of this change chime in?
> 
> I would appreciate any insights that can be offered into why the
> frama-c build is failing:
> 
> https://koji.fedoraproject.org/koji/taskinfo?taskID=81690392
> 
> It's got something to do with this change, since the linker is
> complaining that it cannot find the package-note file, but I am
> unclear how this change is supposed to interact with the OCaml
> ecosystem.

Hi,

the problem was that the %_package_note_file macro uses %buildsubdir,
and %buildsubdir is set during %prep, but it seems it only available
during %build and later. So the path was set wrong… I pushed a work-around
to set %_package_note_file directly before prep and started a new build.

(I wish we had something better for this. %buildsubdir is useful, but
very fragile.)

> I am unclear how this change is supposed to interact with the OCaml
> ecosystem.

I hope it'll "just work"…

$ readelf --notes /usr/bin/frama-c
...
Displaying notes found in: .note.package
  OwnerData sizeDescription
  FDO  0x0078   FDO_PACKAGING_METADATA
Packaging Metadata: 
{"type":"rpm","name":"frama-c","version":"24.0-3.fc36","architecture":"x86_64","osCpe":"cpe:/o:fedoraproject:fedora:36"}

Now to make waste this effort, the authors have to ensure that the
program crashes at least from time to time ;-]]]

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 on the list, report it: 
https://pagure.io/fedora-infrastructure

Fedora-Cloud-34-20220124.0 compose check report

[Fedora compose checker]

No missing expected images.

Soft failed openQA tests: 1/8 (x86_64), 1/8 (aarch64)
(Tests completed, but using a workaround for a known bug)

Old soft failures (same test soft failed in Fedora-Cloud-34-20220123.0):

ID: 867 Test: x86_64 Cloud_Base-qcow2-qcow2 cloud_autocloud
URL: https://openqa.fedoraproject.org/tests/867
ID: 875 Test: aarch64 Cloud_Base-qcow2-qcow2 cloud_autocloud@uefi
URL: https://openqa.fedoraproject.org/tests/875

Passed openQA tests: 7/8 (x86_64), 7/8 (aarch64)
-- 
Mail generated by check-compose:
https://pagure.io/fedora-qa/check-compose
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: gcc-12.0.0-0.4.fc36 in rawhide

[Fabio Valentini]

On Fri, Jan 14, 2022 at 3:32 PM Jakub Jelinek  wrote:
>
> Hi!
>
> gcc 12 snapshot has landed as the system compiler into rawhide today.
> GCC 12 is going to enter its stage4 development phase (only regression
> and documentation bugfixes allowed) on Monday 17th, so there should be
> just those bugfixes and not new features etc. anymore.
> https://gcc.gnu.org/gcc-12/changes.html lists important changes,
> most important is probably that vectorization is enabled at -O2 now
> which is the option with most of the distribution is built with.
>
> https://gcc.gnu.org/gcc-12/porting_to.html is so far incomplete and lists
> some cases where people need to adjust their code.  Other things
> include the usual C++ header changes, where previously some standard
> header included some other header as an implementation detail but it doesn't
> any longer and so code that relied on such indirect include that isn't
> required by the standard needs to include the header that provides whatever
> it relies on.  Or e.g. packages using -Werror where new warnings are
> reported with the newer compiler and -Werror results in build failures.
>
> If there are bugs on the compiler side, please let me know immediately,
> so that those bugs can be fixed before the mass rebuild next week.
>
> Another important thing I wanted to say is that we'd like to switch
> ppc64le from the numerically problematic IBM extended long double to
> IEEE 754 quad long double.  This is an ABI change.  Some libraries
> are already built so that they support both ABIs at the same time,
> including glibc, libstdc++, libgcc, libgfortran etc.
> For other libraries and binaries, the compiler, assembler and linker
> will notice if they use long double and flag them as using either
> IBM or IEEE long double and linker (or I think dynamic linker too)
> might complain when things are mixed.
> Right now the rawhide gcc still defaults to -mabi=ibmlongdouble
> but the glibc/gcc libraries are built compatibly with both.
> We'd like to configure gcc shortly before the mass rebuild with
> --with-long-double-format=ieee so that it will default to
> -mabi=ieeelongdouble, probably on a side-tag build first, and it
> will be highly desirable to rebuild at least some of the most commonly
> used library packages in the order of dependencies there, otherwise
> I'd be afraid the mass rebuild could fail for way too many packages
> (as the mass rebuild doesn't do dependency order rebuilds but just
> goes through packages alphabetically or so).
> Any suggestions on which packages have commonly used library packages
> that use long double?
> readelf -A on libraries on ppc64le prints either nothing (either
> the library is thought not to use long double or supports both ABIs
> transparently or hasn't been rebuilt for some years), or
> Attribute Section: gnu
> File Attributes
>   Tag_GNU_Power_ABI_FP: hard float, 128-bit IBM long double
> for libraries (or binaries or object files) that use IBM long double
> only or
> Attribute Section: gnu
> File Attributes
>   Tag_GNU_Power_ABI_FP: hard float, 128-bit IEEE long double
> for IEEE long doubles.
> So I think we want to rebuild on a side-tag packages that
> provide shared libraries used by hundreds of other packages that
> are
>   Tag_GNU_Power_ABI_FP: hard float, 128-bit IBM long double
> right now.

Hi!

Have the command line arguments that are accepted by gcc?

The test suite of the "cc" crate (used for compiling and linking to C
code within Rust projects) started failing with GCC 12 with this
error:

gcc: error: unrecognized command-line option '-arbitrary'

I looked that the docs for gcc 12 (gcc-12/porting_to.html and
gcc-12/changes.html) but neither mention any change in accepted
command line arguments.

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 on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: gcc-12.0.0-0.4.fc36 in rawhide

[Jakub Jelinek]

On Mon, Jan 24, 2022 at 11:55:39AM +0100, Fabio Valentini wrote:
> Have the command line arguments that are accepted by gcc?
> 
> The test suite of the "cc" crate (used for compiling and linking to C
> code within Rust projects) started failing with GCC 12 with this
> error:
> 
> gcc: error: unrecognized command-line option '-arbitrary'

That was never a gcc command line option.

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

Re: ppc64le: SLOF failed to rebuild: error: unrecognized argument in option '-mtune=generic'

[Gerd Hoffmann]

  Hi,

> > However edk2 has other problems revealed probably by GCC 12, see:
> > https://kojipkgs.fedoraproject.org//work/tasks/4195/81484195/build.log
> 
> A valid warning, perhaps slightly overzealous depending on how Error is 
> defined:
> 
> GenSec.c:1065:5: error: pointer used after 'fclose' [-Werror=use-after-free]
>  1065 | Error(NULL, 0, 4001, "Resource", "memory cannot be allocated  of 
> %s", InFileHandle);
>   | 
> ^~~
> GenSec.c:1064:5: note: call to 'fclose' here
>  1064 | fclose (InFileHandle);
>   | ^
> 
> But it seems more likely that the bug is real.  Maybe that %s should be %p,
> or the function call is bogus in some other way.

Yep, it is.

> > openbios has a segfault somewhere during the FORTH bootstrap:
> > https://kojipkgs.fedoraproject.org//work/tasks/6090/81556090/build.log
> > I was not able to reproduce this one locally.
> 
> I would try reproducing with -O0 first.  It might be a dup of the QEMU bug
> https://gcc.gnu.org/PR104067, even.  It's a problem with loop optimizations,
> so it could be the kind of thing that can wreak havoc on a FORTH interpreter!
> Once the fix for PR104067 hits Fedora, if it's not fixed I can take a look.

A few errors later I get that one:

In function ‘SetDevicePathEndNode’,
inlined from ‘FileDevicePath’ at DevicePathUtilities.c:857:5:
DevicePathUtilities.c:321:3: error: writing 4 bytes into a region of size 1 
[-Werror=stringop-overflow=]
  321 |   memcpy (Node, &mUefiDevicePathLibEndDevicePath, sizeof 
(mUefiDevicePathLibEndDevicePath));
  |   
^
In file included from UefiDevicePathLib.h:22,
 from DevicePathUtilities.c:16:
../Include/Protocol/DevicePath.h: In function ‘FileDevicePath’:
../Include/Protocol/DevicePath.h:51:9: note: destination object ‘Type’ of size 1
   51 |   UINT8 Type;   ///< 0x01 Hardware Device Path.
  | ^~~~
cc1: all warnings being treated as errors

Hmm, mUefiDevicePathLibEndDevicePath is a 4-byte struct with 1-byte
"Type" being the first struct field.  Node is a void ptr.

So the code looks perfectly fine to me.  Did I miss something, or is
that another case of a gcc bug?

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

Re: gcc-12.0.0-0.4.fc36 in rawhide

[Fabio Valentini]

On Mon, Jan 24, 2022 at 12:01 PM Jakub Jelinek  wrote:
>
> On Mon, Jan 24, 2022 at 11:55:39AM +0100, Fabio Valentini wrote:
> > Have the command line arguments that are accepted by gcc?
> >
> > The test suite of the "cc" crate (used for compiling and linking to C
> > code within Rust projects) started failing with GCC 12 with this
> > error:
> >
> > gcc: error: unrecognized command-line option '-arbitrary'
>
> That was never a gcc command line option.

Ok, thanks for confirming ...

Upon further investigation, it looks like something very weird is
going on instead, because other tests that really *should* be working
(or at least, definitely passed until a few days ago) started breaking
in hilarious ways.
So I think the new problems might actually be caused by some broken
interaction between gcc 12, the new change to set CFLAGS / CXXFLAGS by
default, and the way the cc test suite works, and other recent
redhat-rpm-config changes. But I have no idea how this is so broken
all of a sudden.

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 on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: gcc-12.0.0-0.4.fc36 in rawhide

[Kaleb Keithley]

On Sun, Jan 23, 2022 at 4:58 AM Vitaly Zaitsev via devel <
devel@lists.fedoraproject.org> wrote:

> On 22/01/2022 17:22, Jakub Jelinek wrote:
> > The long double change is an ABI change, so this is kind of expected.
>
> abidiff automatic test found no ABI changes between 8.0 and 8.1.


 I think you might be missing the point.

The long double format changed (on ppc64le only?) between gcc-11 and gcc-12.

Compiling something that uses fmt (e.g. ceph) with gcc-12 now produces
references (calls) to:
  int fmt::v8::detail::format_float<__ieee128>(__ieee128, int,
fmt::v8::detail::float_specs, fmt::v8::detail::buffer&)
and
  int fmt::v8::detail::snprintf_float<__ieee128>(__ieee128, int,
fmt::v8::detail::float_specs, fmt::v8::detail::buffer&)

Those functions are not in the libfmt.so that was last successfully built
with gcc-11.

That's because when fmt was compiled with gcc-11, the symbols were:
  int fmt::v8::detail::format_float<__float128>(__float128, int,
fmt::v8::detail::float_specs, fmt::v8::detail::buffer&)
and
  int fmt::v8::detail::snprintf_float<__float128>(__float128, int,
fmt::v8::detail::float_specs, fmt::v8::detail::buffer&)

That is an ABI change, no matter what abidiff might be telling you. (It's a
change we knew was coming though.)

And going forward, anything (e.g. ceph) compiled with gcc-11 is not going
to work with fmt and libfmt.so compiled with gcc-12 because of the ABI
change.

If you already understood all this then I apologize for telling you
something you already know. ;-)

Regards

-- 

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

about abidiff Re: gcc-12.0.0-0.4.fc36 in rawhide

[Sérgio Basto]

On Sun, 2022-01-23 at 10:56 +0100, Vitaly Zaitsev via devel wrote:
> On 22/01/2022 17:22, Jakub Jelinek wrote:
> > The long double change is an ABI change, so this is kind of expected.
> 
> abidiff automatic test found no ABI changes between 8.0 and 8.1.

Since early 2021 at least
https://sourceware.org/bugzilla/show_bug.cgi?id=27275 I notice
fedabipkgdiff doesn't produce any results . 

But by reactions of the developers seems that all was working without
problems, yesterday finally found the problem
https://bugzilla.redhat.com/show_bug.cgi?id=1811602#c3

also wiki page is outdate ... 
https://fedoraproject.org/wiki/How_to_check_for_ABI_changes_with_abipkgdiff#Comparing_RPMs


Best regards, 
> -- 
> Sincerely,
>    Vitaly Zaitsev (vit...@easycoding.org)
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
> Do not reply to spam on the list, report it:
> https://pagure.io/fedora-infrastructure

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

Re: gcc-12.0.0-0.4.fc36 in rawhide

[Kaleb Keithley]

On Sat, Jan 22, 2022 at 2:28 PM Kaleb Keithley  wrote:

>
>> The long double change is an ABI change, so this is kind of expected.
>> Mass rebuild unfortunately doesn't go according to the dependency graph
>> (and
>> unfortunately it isn't a tree, there are cycles).
>>
>
> Indeed. fmt has not been rebuilt, or more accurately, it failed in the
> mass rebuild. Specifically the ppc64le build failed.  see
> https://koji.fedoraproject.org/koji/taskinfo?taskID=81489199
>

I may have missed the email about this. (Sorry if I have.)

Is there an action on someone's part to fix the assembler, or fix the
assembly that gcc-12 is emitting on ppc64le that the assembler is puking on?

Thanks,

-- 

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

Fedora rawhide compose report: 20220124.n.0 changes

[Fedora Rawhide Report]

OLD: Fedora-Rawhide-20220123.n.0
NEW: Fedora-Rawhide-20220124.n.0

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

Size of added packages:  26.63 MiB
Size of dropped packages:0 B
Size of upgraded packages:   501.54 MiB
Size of downgraded packages: 0 B

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

= ADDED IMAGES =
Image: Workstation live aarch64
Path: 
Workstation/aarch64/iso/Fedora-Workstation-Live-aarch64-Rawhide-20220124.n.0.iso
Image: Xfce raw-xz armhfp
Path: Spins/armhfp/images/Fedora-Xfce-Rawhide-20220124.n.0.armhfp.raw.xz

= DROPPED IMAGES =
Image: Silverblue dvd-ostree aarch64
Path: 
Silverblue/aarch64/iso/Fedora-Silverblue-ostree-aarch64-Rawhide-20220123.n.0.iso

= ADDED PACKAGES =
Package: cantera-2.6.0-0.7.a4.fc36
Summary: Chemical kinetics, thermodynamics, and transport tool suite
RPMs:cantera-common cantera-devel cantera-static python3-cantera
Size:26.44 MiB

Package: libi2cd-1.0.3-1.fc36
Summary: C library for interacting with linux I2C devices
RPMs:libi2cd libi2cd-devel
Size:191.28 KiB


= DROPPED PACKAGES =

= UPGRADED PACKAGES =
Package:  SoapySDR-0.8.1-3.fc36
Old package:  SoapySDR-0.8.1-1.fc36
Summary:  A Vendor Neutral and Platform Independent SDR Support Library
RPMs: SoapySDR SoapySDR-devel SoapySDR-doc python3-SoapySDR
Size: 3.24 MiB
Size change:  14.51 KiB
Changelog:
  * Wed Jan 19 2022 Fedora Release Engineering  - 
0.8.1-2
  - Rebuilt for https://fedoraproject.org/wiki/Fedora_36_Mass_Rebuild

  * Sun Jan 23 2022 Matt Domsch  - 0.8.1-3
  - Fix directory name of hardware support modules


Package:  audit-3.0.7-1.fc36
Old package:  audit-3.0.6-2.fc36
Summary:  User space tools for kernel auditing
RPMs: audispd-plugins audispd-plugins-zos audit audit-libs 
audit-libs-devel python3-audit
Size: 3.19 MiB
Size change:  35.06 KiB
Changelog:
  * Wed Jan 19 2022 Fedora Release Engineering  - 
3.0.6-3
  - Rebuilt for https://fedoraproject.org/wiki/Fedora_36_Mass_Rebuild

  * Sun Jan 23 2022 Steve Grubb  3.0.7-1
  - New upstream bugfix and feature release


Package:  bitlbee-3.6-7.fc36
Old package:  bitlbee-3.6-6.fc36
Summary:  IRC to other chat networks gateway
RPMs: bitlbee bitlbee-devel bitlbee-otr
Size: 2.02 MiB
Size change:  -998 B
Changelog:
  * Wed Jan 19 2022 Fedora Release Engineering  - 
3.6-7
  - Rebuilt for https://fedoraproject.org/wiki/Fedora_36_Mass_Rebuild


Package:  clawsker-1.3.5-1.fc36
Old package:  clawsker-1.3.4-2.fc35
Summary:  Dialog to edit Claws Mail's hidden preferences
RPMs: clawsker
Size: 142.30 KiB
Size change:  2.88 KiB
Changelog:
  * Wed Jan 19 2022 Fedora Release Engineering  - 
1.3.4-3
  - Rebuilt for https://fedoraproject.org/wiki/Fedora_36_Mass_Rebuild

  * Sun Jan 23 2022 Michael Schwendt  - 1.3.5-1
  - Update to 1.3.5.


Package:  cobbler-3.2.2-8.fc36
Old package:  cobbler-3.2.2-6.fc36
Summary:  Boot server configurator
RPMs: cobbler cobbler-tests cobbler-web
Size: 759.16 KiB
Size change:  1.08 KiB
Changelog:
  * Wed Jan 19 2022 Fedora Release Engineering  - 
3.2.2-7
  - Rebuilt for https://fedoraproject.org/wiki/Fedora_36_Mass_Rebuild

  * Mon Jan 24 2022 Orion Poplawski  - 3.2.2-8
  - Fix posttrans script


Package:  dummy-test-package-gloster-0-6858.fc36
Old package:  dummy-test-package-gloster-0-6837.fc36
Summary:  Dummy Test Package called Gloster
RPMs: dummy-test-package-gloster
Size: 417.07 KiB
Size change:  1.25 KiB
Changelog:
  * Sun Jan 23 2022 packagerbot  - 0-6838
  - rebuilt

  * Sun Jan 23 2022 packagerbot  - 0-6839
  - rebuilt

  * Sun Jan 23 2022 packagerbot  - 0-6840
  - rebuilt

  * Sun Jan 23 2022 packagerbot  - 0-6841
  - rebuilt

  * Sun Jan 23 2022 packagerbot  - 0-6842
  - rebuilt

  * Sun Jan 23 2022 packagerbot  - 0-6843
  - rebuilt

  * Sun Jan 23 2022 packagerbot  - 0-6844
  - rebuilt

  * Sun Jan 23 2022 packagerbot  - 0-6845
  - rebuilt

  * Sun Jan 23 2022 packagerbot  - 0-6846
  - rebuilt

  * Sun Jan 23 2022 packagerbot  - 0-6847
  - rebuilt

  * Sun Jan 23 2022 packagerbot  - 0-6848
  - rebuilt

  * Sun Jan 23 2022 packagerbot  - 0-6849
  - rebuilt

  * Sun Jan 23 2022 packagerbot  - 0-6850
  - rebuilt

  * Sun Jan 23 2022 packagerbot  - 0-6851
  - rebuilt

  * Sun Jan 23 2022 packagerbot  - 0-6852
  - rebuilt

  * Sun Jan 23 2022 packagerbot  - 0-6853
  - rebuilt

  * Mon Jan 24 2022 packagerbot  - 0-6854
  - rebuilt

  * Mon Jan 24 2022 packagerbot  - 0-6855
  - rebuilt

  * Mon Jan 24 2022 packagerbot  - 0-6856
  - rebuilt

  * Mon Jan 24 2022 packagerbot  - 0-6857
  - rebuilt

  * Mon Jan 24 2022 packagerbot  - 0-6858
  - rebuilt


Package:  fwupd-efi-1.2-1.fc36
Old package:  fwupd-efi-1.1-1.fc35
Summary:  Firmware update EFI binaries
RPMs: fwup

Re: gcc-12.0.0-0.4.fc36 in rawhide

[Tom Hughes via devel]

On 24/01/2022 12:15, Kaleb Keithley wrote:



On Sat, Jan 22, 2022 at 2:28 PM Kaleb Keithley > wrote:



The long double change is an ABI change, so this is kind of
expected.
Mass rebuild unfortunately doesn't go according to the
dependency graph (and
unfortunately it isn't a tree, there are cycles).


Indeed. fmt has not been rebuilt, or more accurately, it failed in
the mass rebuild. Specifically the ppc64le build failed.  see
https://koji.fedoraproject.org/koji/taskinfo?taskID=81489199



I may have missed the email about this. (Sorry if I have.)

Is there an action on someone's part to fix the assembler, or fix the 
assembly that gcc-12 is emitting on ppc64le that the assembler is puking on?


Yes as Jakub said yesterday morning that is https://gcc.gnu.org/PR104172 
and he's waiting for a decision from the powerpc backend maintainers on

the best fix.

Tom

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

Re: gcc-12.0.0-0.4.fc36 in rawhide

[Jakub Jelinek]

On Mon, Jan 24, 2022 at 07:15:19AM -0500, Kaleb Keithley wrote:
> On Sat, Jan 22, 2022 at 2:28 PM Kaleb Keithley  wrote:
> 
> >
> >> The long double change is an ABI change, so this is kind of expected.
> >> Mass rebuild unfortunately doesn't go according to the dependency graph
> >> (and
> >> unfortunately it isn't a tree, there are cycles).
> >>
> >
> > Indeed. fmt has not been rebuilt, or more accurately, it failed in the
> > mass rebuild. Specifically the ppc64le build failed.  see
> > https://koji.fedoraproject.org/koji/taskinfo?taskID=81489199
> >
> 
> I may have missed the email about this. (Sorry if I have.)
> 
> Is there an action on someone's part to fix the assembler, or fix the
> assembly that gcc-12 is emitting on ppc64le that the assembler is puking on?

It is https://gcc.gnu.org/PR104172 , I have done my part there, but I'm not
PowerPC backend maintainer, so the decision what to do isn't mine.

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

Help needed updating Lazarus to v2.2.0

[Artur Frenszek-Iwicki]

Hi all,

some time ago, Lazarus v2.2.0 came out. I tried to update the package
in Rawhide, but the build failed on ppc64le with a linking error.
Link to failed scratch build: 
https://koji.fedoraproject.org/koji/taskinfo?taskID=81313575

../units/powerpc64-linux/nogui/project.o: in function 
`WRPR_$PROJECT_$$_TPROJECT_$_IPROJPACK_$_1_$_CLASSES$_$TCOMPONENT_$__$$__ADDREF$$LONGINT':
/builddir/build/BUILD/lazarus-2.2.0/lazarus/ide//project.pp:1:(.text.n_WRPR_$PROJECT_$$_TPROJECT_$_IPROJPACK_$_1_$_CLASSES$_$TCOMPONENT_$__$$__ADDREF$$LONGINT+0x4):
 call to `CLASSES$_$TCOMPONENT_$__$$__ADDREF$$LONGINT' lacks nop, can't restore 
toc; (toc save/adjust stub)
/usr/bin/ld: final link failed: bad value

I was wondering if this was a Fedora-specific issue, or some upstream bug,
so I went to the bug tracker. As it turned out, this issue has already
been reported, as openSUSE had stumbled on the exact same error.
https://gitlab.com/freepascal.org/lazarus/lazarus/-/issues/39534

So, that was two weeks ago. Why bring it up now?
Because we're fresh after the F36 Mass Rebuild, and several packages
depending on Lazarus failed to build, with very similar errors:
a segmentation fault somewhere in "lazbuild", the CLI tool for
building Lazarus projects.

Affected packages:
- cqrlog: https://koji.fedoraproject.org/koji/taskinfo?taskID=81478836
- doublecmd: https://koji.fedoraproject.org/koji/taskinfo?taskID=81482400
- goverlay: https://koji.fedoraproject.org/koji/taskinfo?taskID=81517949
- lazpaint: https://koji.fedoraproject.org/koji/taskinfo?taskID=81530759
- pasdoc: https://koji.fedoraproject.org/koji/taskinfo?taskID=81557894

So I'm here thinking that maybe, if we were able to solve the pcc64le
issue and update Lazarus to v2.2.0, we can then try rebuilding the affected
packages and see if the segfault this occurs. Only problem is,
unfortunately, I know very little about compilers & linkers & assembly,
so the ppc64le issue is way outside my field of knowledge.
As such, any help regarding coming up with a patch will be greatly appreciated.

For the record, the Lazarus package ships with a couple patches,
and those needed to be updated from v2.0.12 for v2.2.0. I did not
commit those to the main repository yet, but you can grab them from this fork:
https://src.fedoraproject.org/fork/suve/rpms/lazarus

Thanks in advance.

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

Re: F36 Change: Package information on ELF objects (System-Wide Change proposal)

[Zbigniew Jędrzejewski-Szmek]

On Sat, Jan 22, 2022 at 05:56:40PM -0500, Neal Gompa wrote:
> On Sat, Jan 22, 2022 at 5:47 PM Kevin Kofler via devel
>  wrote:
> >
> > Kevin Kofler via devel wrote:
> > > It breaks ALL packages using gold to link, and the "fix" is to explicitly
> > > add a macro to generate gold-compatible output or to stop using gold. Also
> > > affects qt5-qtwebengine:
> > > https://bugzilla.redhat.com/show_bug.cgi?id=2043178#c10
> >
> > And worse, neither of the alleged "fixes" works for qt5-qtwebengine:
> > https://bugzilla.redhat.com/show_bug.cgi?id=2043178#c14
> > https://bugzilla.redhat.com/show_bug.cgi?id=2043178#c19
> >
> > This is a release-critical package: part of the critical path, required by
> > at least one default application (Kontact/KMail) on a release-blocking spin
> > (KDE Plasma). And the version that fails to build is a security update. Time
> > for the contingency plan on this Change!

Hi Kevin,

I know you applied an opt-out to the package. I think that's totally OK:
it is pretty clear at this point that not all packages will be built
with the note, but partial coverage is also useful.

In the longer term, we'll see if gold can be tweaked to support the
necessary features, or maybe qt5-webengine will switch to bfd. But
there should be no hurry with this. Right now we have a few thousand
packages with the note, so we'll be concentrating on improving the
support in tools using the note.

> We literally haven't branched Rawhide for F36, there's still time for
> the proposers to fix it.

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 on the list, report it: 
https://pagure.io/fedora-infrastructure

Planned Outage - bodhi.fedoraproject.org - 2022-01-26 12:00 UTC

[Adam Saleh]

Planned Outage - bodhi.fedoraproject.org - 2022-01-26 12:00 UTC

There will be a partial outage starting on wednesday at 2022-01-26 12:00 UTC
which will last approximately 2 hours.

To convert UTC to your local time, take a look at
http://fedoraproject.org/wiki/Infrastructure/UTCHowto
or run:

date -d '2022-01-26 12:00 UTC'

Reason for outage:

Bodhi will be properly upgraded to 5.7.4 - the code code changes are
reasonably small and shouldn't pose much impact. As part of this we
will be changing some of the deployment configuration to help with
problems like https://github.com/fedora-infra/bodhi/issues/4344

Affected Services:

bodhi / updates.fedoraproject.org may be down or unresponsive during
the upgrade window

Ticket Link:

https://pagure.io/fedora-infrastructure/issue/10494

Please join #fedora-admin or #fedora-noc on libera.chat
or add comments to the ticket for this outage above.
___
devel-announce mailing list -- devel-annou...@lists.fedoraproject.org
To unsubscribe send an email to devel-announce-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-annou...@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Announcing zimlib and kiwix-lib soversion bumps

[Vitaly Zaitsev via devel]

Hello all.

zimlib 7.2.0 will include soversion bump from .6 to .7.
libkiwix 10.0.0 (replaced kiwix-lib) will include soversion bump from .9 
to .10.


I will rebuild all dependent packages in Rawhide and F35.

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

Podman 4.0 rc2 is available in updates-testing.

[Daniel Walsh]

We would love to have people play with this and test it out.

Note: this release has breaking changes to it's API, so it will not be 
released to f35. Only to F36, but users will be able to download and use 
it on F35, we will not push it to stable though.


https://github.com/containers/podman/releases/

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

CPE Feedback Survey Q3-Q4 2021

[Ant Carroll]

Hey folks,

We have been doing the Community Platform Engineering feedback survey for a
while now, and we still use the feedback collected to adjust our
communications and processes.  We would like to hear your thoughts again
through a short survey we've put together to learn how your experiences
have been with us since July 2021.

If you could take the time (5mins max) to complete it, it would be hugely
valuable as we work on this continuous improvement -
https://fedoraproject.limequery.com/6

The survey will remain open until Feb 07th (23:59 UTC).

Know more about the team at: https://docs.fedoraproject.org/en-US/cpe/

Cheers,

Ant

-- 

Ant Carroll

Associate Manager, Software Engineering

Red Hat Waterford 

Communications House

Cork Road, Waterford City

ancar...@redhat.com
M: +353876213163 IM: ancarrol
@redhatjobs    redhatjobs
 @redhatjobs


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

Re: Podman 4.0 rc2 is available in updates-testing.

[Miro Hrončok]

On 24. 01. 22 15:16, Daniel Walsh wrote:

We would love to have people play with this and test it out.

Note: this release has breaking changes to it's API, so it will not be released 
to f35. Only to F36, but users will be able to download and use it on F35, we 
will not push it to stable though.


Please, don't use updates-testing this way.

See 
https://docs.fedoraproject.org/en-US/fesco/Updates_Policy/#consumable-updates

"""
Bodhi updates should only be created for builds which are expected to qualify 
for being pushed to stable. Maintainers should not use Bodhi’s testing states 
to test updates they never intend to push stable. This sort of testing should 
be done in Copr or other seperate public repositories. Consult with the QA team 
for further testing assistance.

"""

--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: F36 Change: Package information on ELF objects (System-Wide Change proposal)

[Jerry James]

On Mon, Jan 24, 2022 at 1:58 AM Zbigniew Jędrzejewski-Szmek
 wrote:
> the problem was that the %_package_note_file macro uses %buildsubdir,
> and %buildsubdir is set during %prep, but it seems it only available
> during %build and later. So the path was set wrong… I pushed a work-around
> to set %_package_note_file directly before prep and started a new build.
>
> (I wish we had something better for this. %buildsubdir is useful, but
> very fragile.)

Thank you for the fix!
-- 
Jerry James
http://www.jamezone.org/
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: F36 Change: Package information on ELF objects (System-Wide Change proposal)

[Mamoru TASAKA]

Zbigniew Jędrzejewski-Szmek wrote on 2022/01/24 17:55:

On Sat, Jan 22, 2022 at 08:54:02PM -0700, Jerry James wrote:

On Fri, Jan 21, 2022 at 5:35 PM Robert-André Mauchin  wrote:

Sorry for the necro but there seems to be a problem with this change. It
broke multiple packages at the linking stage:
https://bugzilla.redhat.com/show_bug.cgi?id=2043178

On the package-note repo https://github.com/systemd/package-notes
it is said that it requires binutils (>= 2.38) but it hasn't been
released yet.

Can the owners of this change chime in?


I would appreciate any insights that can be offered into why the
frama-c build is failing:

https://koji.fedoraproject.org/koji/taskinfo?taskID=81690392

It's got something to do with this change, since the linker is
complaining that it cannot find the package-note file, but I am
unclear how this change is supposed to interact with the OCaml
ecosystem.


Hi,

the problem was that the %_package_note_file macro uses %buildsubdir,
and %buildsubdir is set during %prep, but it seems it only available
during %build and later. So the path was set wrong… I pushed a work-around
to set %_package_note_file directly before prep and started a new build.

(I wish we had something better for this. %buildsubdir is useful, but
very fragile.)


Well, it turned up that this issue (that %buildsubdir is unusable in %prep)
also affects gabedit as:

/usr/bin/ld: cannot open linker script file 
/builddir/build/BUILD/.package_note-gabedit-2.5.1-11.fc36.x86_64.ld: No such 
file or directory

https://koschei.fedoraproject.org/package/gabedit?collection=f36
https://koji.fedoraproject.org/koji/taskinfo?taskID=81664083

Can't this issue be fixed in package-notes rpm side?

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

Fedora-Rawhide-20220124.n.0 compose check report

[Fedora compose checker]

No missing expected images.

Compose FAILS proposed Rawhide gating check!
6 of 43 required tests failed, 5 results missing
openQA tests matching unsatisfied gating requirements shown with **GATING** 
below

Failed openQA tests: 27/225 (x86_64), 23/157 (aarch64)

New failures (same test not failed in Fedora-Rawhide-20220123.n.0):

ID: 992 Test: x86_64 Silverblue-dvd_ostree-iso eog
URL: https://openqa.fedoraproject.org/tests/992
ID: 1112025 Test: aarch64 Server-dvd-iso server_remote_logging_server@uefi
URL: https://openqa.fedoraproject.org/tests/1112025
ID: 1112032 Test: aarch64 Server-dvd-iso modularity_tests@uefi
URL: https://openqa.fedoraproject.org/tests/1112032
ID: 1112056 Test: aarch64 Server-dvd-iso server_remote_logging_client@uefi
URL: https://openqa.fedoraproject.org/tests/1112056
ID: 1112059 Test: aarch64 Server-dvd-iso realmd_join_sssd@uefi
URL: https://openqa.fedoraproject.org/tests/1112059
ID: 1112112 Test: x86_64 Workstation-upgrade desktop_login
URL: https://openqa.fedoraproject.org/tests/1112112
ID: 1112459 Test: x86_64 Workstation-live-iso eog
URL: https://openqa.fedoraproject.org/tests/1112459

Old failures (same test failed in Fedora-Rawhide-20220123.n.0):

ID: 899 Test: x86_64 Server-dvd-iso server_cockpit_default **GATING**
URL: https://openqa.fedoraproject.org/tests/899
ID: 926 Test: x86_64 Server-dvd-iso server_realmd_join_kickstart 
**GATING**
URL: https://openqa.fedoraproject.org/tests/926
ID: 929 Test: x86_64 Server-dvd-iso realmd_join_sssd **GATING**
URL: https://openqa.fedoraproject.org/tests/929
ID: 960 Test: x86_64 Workstation-live-iso desktop_printing
URL: https://openqa.fedoraproject.org/tests/960
ID: 961 Test: x86_64 KDE-live-iso anaconda_help
URL: https://openqa.fedoraproject.org/tests/961
ID: 963 Test: x86_64 KDE-live-iso desktop_notifications_live
URL: https://openqa.fedoraproject.org/tests/963
ID: 982 Test: x86_64 Silverblue-dvd_ostree-iso anaconda_help
URL: https://openqa.fedoraproject.org/tests/982
ID: 993 Test: x86_64 Silverblue-dvd_ostree-iso release_identification
URL: https://openqa.fedoraproject.org/tests/993
ID: 1112012 Test: aarch64 Minimal-raw_xz-raw.xz base_services_start@uefi
URL: https://openqa.fedoraproject.org/tests/1112012
ID: 1112016 Test: aarch64 Server-dvd-iso anaconda_help@uefi
URL: https://openqa.fedoraproject.org/tests/1112016
ID: 1112024 Test: aarch64 Server-dvd-iso 
install_repository_hd_variation@uefi
URL: https://openqa.fedoraproject.org/tests/1112024
ID: 1112033 Test: aarch64 Server-dvd-iso server_cockpit_default@uefi
URL: https://openqa.fedoraproject.org/tests/1112033
ID: 1112055 Test: aarch64 Server-dvd-iso server_realmd_join_kickstart@uefi
URL: https://openqa.fedoraproject.org/tests/1112055
ID: 1112069 Test: aarch64 Server-raw_xz-raw.xz base_services_start@uefi
URL: https://openqa.fedoraproject.org/tests/1112069
ID: 1112075 Test: aarch64 Workstation-raw_xz-raw.xz desktop_printing@uefi
URL: https://openqa.fedoraproject.org/tests/1112075
ID: 1112088 Test: aarch64 Workstation-raw_xz-raw.xz 
desktop_update_graphical@uefi
URL: https://openqa.fedoraproject.org/tests/1112088
ID: 1112113 Test: x86_64 Workstation-upgrade desktop_fprint
URL: https://openqa.fedoraproject.org/tests/1112113
ID: 1112116 Test: x86_64 Workstation-upgrade desktop_printing
URL: https://openqa.fedoraproject.org/tests/1112116
ID: 1112128 Test: aarch64 Workstation-upgrade eog@uefi
URL: https://openqa.fedoraproject.org/tests/1112128
ID: 1112129 Test: aarch64 Workstation-upgrade desktop_update_graphical@uefi
URL: https://openqa.fedoraproject.org/tests/1112129
ID: 1112132 Test: aarch64 Workstation-upgrade desktop_browser@uefi
URL: https://openqa.fedoraproject.org/tests/1112132
ID: 1112133 Test: aarch64 Workstation-upgrade desktop_printing@uefi
URL: https://openqa.fedoraproject.org/tests/1112133
ID: 1112135 Test: x86_64 universal upgrade_kde_64bit
URL: https://openqa.fedoraproject.org/tests/1112135
ID: 1112142 Test: x86_64 universal upgrade_2_kde_64bit
URL: https://openqa.fedoraproject.org/tests/1112142
ID: 1112146 Test: x86_64 universal install_arabic_language
URL: https://openqa.fedoraproject.org/tests/1112146
ID: 1112147 Test: x86_64 universal install_asian_language
URL: https://openqa.fedoraproject.org/tests/1112147
ID: 1112150 Test: x86_64 universal install_package_set_kde
URL: https://openqa.fedoraproject.org/tests/1112150
ID: 1112154 Test: x86_64 universal upgrade_server_domain_controller
URL: https://openqa.fedoraproject.org/tests/1112154
ID: 1112167 Test: x86_64 universal install_iscsi
URL: https://openqa.fedoraproject.org/tests/1112167
ID: 1112201 Test: x86_64 universal upgrade_2_server_domain_controller
URL: https://openqa.fedoraproject.org/tests/1112201
ID: 1112208 Test: x86_64 universal upgrade_realmd_client
URL: https://openqa.fedoraproject.org/test

mass rebuild status - 2022-01-24

[Kevin Fenzi]

The mass rebuild finished early saturday morning. 

This resulted in 3448 failed builds.

This seems kind of high, so we are going to resubmit all the failed
builds in a short second round to reduce the chance of transitory issues
causing the build failures.

It's expected that should finish later today and we will tag f36 rebuild
into f36.

kevin


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 on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: mv is massively slower on the host rather than in a nspawn chroot, regression somewhere?

[Robert-André Mauchin]

On 1/24/22 05:14, Chris Murphy wrote:

On Sun, Jan 23, 2022 at 5:30 PM Robert-André Mauchin  wrote:


Hi,

So I have an annoying bug that started near the beginnings of F35.
My papirus-icon-theme became very slow to install:
https://bugzilla.redhat.com/show_bug.cgi?id=2029709#c18

During the installation, all the files are copied, then renamed by rpm
(no idea why it works like this).

It works fast in a Mock chroot but incredibly slow on bare metal.

I've done a small test of moving files:

[root@cassini icons]# mkdir test
[root@cassini icons]# for (( i = 0; i < 1; i++ )) do > test/file_$i;
done
[root@cassini icons]# cd test

On host:

time $(for f in *; do mv "$f" "${f%}.txt"; done)
real2m3,500s
user0m3,966s
sys 2m0,431s

In nspawn container:

 sh-5.1# time $(for f in *; do mv "$f" "${f%}.txt"; done)
real0m6.702s
user0m4.237s
sys 0m3.344s

Since papirus-icon-theme contains more than 100,000 (small) files, it is
a problem. One minute of waiting is ok, 20 mn is not.

What can cause this? I read that nspawn virtualizes the file system,
could it be file system related on the host? (I use btrfs btw)

Any input welcome!


What file system is being used in each case?



Everything is btrfs.


This is a bit obscure but... cp and mv use reflink=auto. On XFS and
Btrfs this means it'll make reflinks (copies metadata, doesn't
duplicate the data extents) if it can. Falling back to a full copy
(metadata and data extents).


But both the host and the nspawn container are using btrfs?


It might not be possible due to an obscure VFS rule that disallows
reflinks (for reasons I don't understand) when the copy or move
crosses mount point boundaries. This includes bind mounts of
directories. Bind mounts are also what are employed behind the scene
with 'mount -o subvol' mount option on Btrfs, which we use by default
in Fedora Workstation and Cloud Edition, and all the desktop spins.

The nspawn container, I'm not super familiar with how it works. I
think on Btrfs, it will create nested subvolumes, i.e. they are not
mounted with the subvol mount option, hence no mount point boundary.
But on other file systems, I think nspawn creates a loop mounted file
system?



I've got two subvol:

UUID=ee9eec69-8710-4503-b389-e16fcde8a0a5 /   btrfs 
  subvol=root,compress=zstd:1 0 0


UUID=d7e21336-6ac6-483a-b4f2-aaeecabd8f1f /home   btrfs 
  subvol=home,compress=zstd:1 0 0


but when I do my tests there is no subvol crossing, everything happens 
on the root subvol?


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

Re: mv is massively slower on the host rather than in a nspawn chroot, regression somewhere?

[Robert-André Mauchin]

On 1/24/22 01:30, Robert-André Mauchin wrote:

Hi,

So I have an annoying bug that started near the beginnings of F35.
My papirus-icon-theme became very slow to install:
https://bugzilla.redhat.com/show_bug.cgi?id=2029709#c18

During the installation, all the files are copied, then renamed by rpm 
(no idea why it works like this).


It works fast in a Mock chroot but incredibly slow on bare metal.

I've done a small test of moving files:

[root@cassini icons]# mkdir test
[root@cassini icons]# for (( i = 0; i < 1; i++ )) do > test/file_$i; 
done

[root@cassini icons]# cd test

On host:

time $(for f in *; do mv "$f" "${f%}.txt"; done)
real    2m3,500s
user    0m3,966s
sys 2m0,431s

In nspawn container:

 sh-5.1# time $(for f in *; do mv "$f" "${f%}.txt"; done)
real    0m6.702s
user    0m4.237s
sys 0m3.344s

Since papirus-icon-theme contains more than 100,000 (small) files, it is 
a problem. One minute of waiting is ok, 20 mn is not.


What can cause this? I read that nspawn virtualizes the file system, 
could it be file system related on the host? (I use btrfs btw)


Any input welcome!

Best regards,

Robert-André


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

Re: Help needed updating Lazarus to v2.2.0

[Dan Horák]

On Mon, 24 Jan 2022 12:49:27 -
"Artur Frenszek-Iwicki"  wrote:

> Hi all,
> 
> some time ago, Lazarus v2.2.0 came out. I tried to update the package
> in Rawhide, but the build failed on ppc64le with a linking error.
> Link to failed scratch build: 
> https://koji.fedoraproject.org/koji/taskinfo?taskID=81313575
> 
> ../units/powerpc64-linux/nogui/project.o: in function 
> `WRPR_$PROJECT_$$_TPROJECT_$_IPROJPACK_$_1_$_CLASSES$_$TCOMPONENT_$__$$__ADDREF$$LONGINT':
> /builddir/build/BUILD/lazarus-2.2.0/lazarus/ide//project.pp:1:(.text.n_WRPR_$PROJECT_$$_TPROJECT_$_IPROJPACK_$_1_$_CLASSES$_$TCOMPONENT_$__$$__ADDREF$$LONGINT+0x4):
>  call to `CLASSES$_$TCOMPONENT_$__$$__ADDREF$$LONGINT' lacks nop, can't 
> restore toc; (toc save/adjust stub)
> /usr/bin/ld: final link failed: bad value
> 
> I was wondering if this was a Fedora-specific issue, or some upstream bug,
> so I went to the bug tracker. As it turned out, this issue has already
> been reported, as openSUSE had stumbled on the exact same error.
> https://gitlab.com/freepascal.org/lazarus/lazarus/-/issues/39534

I have commented in the ticket, sounds like fpc issue on ppc64le. I
don't think I will able to help directly here.


Dan

> 
> So, that was two weeks ago. Why bring it up now?
> Because we're fresh after the F36 Mass Rebuild, and several packages
> depending on Lazarus failed to build, with very similar errors:
> a segmentation fault somewhere in "lazbuild", the CLI tool for
> building Lazarus projects.
> 
> Affected packages:
> - cqrlog: https://koji.fedoraproject.org/koji/taskinfo?taskID=81478836
> - doublecmd: https://koji.fedoraproject.org/koji/taskinfo?taskID=81482400
> - goverlay: https://koji.fedoraproject.org/koji/taskinfo?taskID=81517949
> - lazpaint: https://koji.fedoraproject.org/koji/taskinfo?taskID=81530759
> - pasdoc: https://koji.fedoraproject.org/koji/taskinfo?taskID=81557894
> 
> So I'm here thinking that maybe, if we were able to solve the pcc64le
> issue and update Lazarus to v2.2.0, we can then try rebuilding the affected
> packages and see if the segfault this occurs. Only problem is,
> unfortunately, I know very little about compilers & linkers & assembly,
> so the ppc64le issue is way outside my field of knowledge.
> As such, any help regarding coming up with a patch will be greatly 
> appreciated.
> 
> For the record, the Lazarus package ships with a couple patches,
> and those needed to be updated from v2.0.12 for v2.2.0. I did not
> commit those to the main repository yet, but you can grab them from this fork:
> https://src.fedoraproject.org/fork/suve/rpms/lazarus
> 
> Thanks in advance.
> 
> A.FI.
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct: 
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: 
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
> Do not reply to spam on the list, report it: 
> https://pagure.io/fedora-infrastructure
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Orphaned packages looking for new maintainers

[Miro Hrončok]

The following packages are orphaned and will be retired when they
are orphaned for six weeks, unless someone adopts them. If you know for sure
that the package should be retired, please do so now with a proper reason:
https://fedoraproject.org/wiki/How_to_remove_a_package_at_end_of_life

Note: If you received this mail directly you (co)maintain one of the affected
packages or a package that depends on one. Please adopt the affected package or
retire your depending package to avoid broken dependencies, otherwise your
package will fail to install and/or build when the affected package gets 
retired.

Request package ownership via the *Take* button in he left column on
https://src.fedoraproject.org/rpms/

Full report available at:
https://churchyard.fedorapeople.org/orphans-2022-01-24.txt
grep it for your FAS username and follow the dependency chain.

For human readable dependency chains,
see https://packager-dashboard.fedoraproject.org/
For all orphaned packages,
see https://packager-dashboard.fedoraproject.org/orphan

Package  (co)maintainers   Status Change

3proxyorphan   0 weeks ago
DivFix++  orphan   0 weeks ago
colorize  orphan   0 weeks ago
curlftpfs orphan   0 weeks ago
dans-gdal-scripts orphan   5 weeks ago
darkstat  orphan   0 weeks ago
elmon orphan   0 weeks ago
esniper   orphan   5 weeks ago
fkill-cli orphan   4 weeks ago
fotoxxlimb, orphan 0 weeks ago
fxorphan   4 weeks ago
fx-completion orphan   4 weeks ago
gloox cicku, davidsch, orphan  0 weeks ago
hans  orphan   0 weeks ago
httpd-itk orphan   0 weeks ago
iodinelystor, orphan   0 weeks ago
kea   fjanus, orphan, zdohnal  1 weeks ago
laby  orphan   2 weeks ago
mysqlreport   orphan, wolfy0 weeks ago
nodejs-svgo   nodejs-sig, orphan   4 weeks ago
npm-name-cli  orphan   4 weeks ago
pacmanagerngompa, orphan   0 weeks ago
percolorphan   0 weeks ago
perl-File-Finder  orphan   0 weeks ago
perl-File-Inplace orphan   0 weeks ago
perl-HTML-FormatText-WithLinks-   orphan   0 weeks ago
AndTables
perl-IO-Any   orphan   0 weeks ago
perl-JSON-Utilorphan   0 weeks ago
perl-Lingua-EN-Fathom jfearn, orphan   0 weeks ago
perl-Lingua-EN-Syllable   orphan   0 weeks ago
perl-Locale-Maketext-Gettext  orphan   0 weeks ago
perl-Net-HL7  orphan   4 weeks ago
perl-ParseLex orphan   0 weeks ago
perl-String-Similaritylcons, orphan0 weeks ago
perl-Sys-Path orphan   0 weeks ago
perl-Test-Fixme   orphan   0 weeks ago
pgcenter  orphan   0 weeks ago
pgdbf orphan   0 weeks ago
pgmodeler orphan   0 weeks ago
php-pecl-solr2orphan   2 weeks ago
plexus-i18n   mizdebsk, orphan 0 weeks ago
pmountkni, orphan  0 weeks ago
pstreams-develjwakely, orphan  0 weeks ago
publican  jfearn, orphan   0 weeks ago
python-ECPy   orphan   0 weeks ago
python-btchip jonny, orphan0 weeks ago
python-cmigemoorphan   0 weeks ago
python-jenkins-job-builderignatenkobrain, ktdreyer,5 weeks ago
 

Re: Podman 4.0 rc2 is available in updates-testing.

[Fabio Valentini]

On Mon, Jan 24, 2022 at 3:38 PM Miro Hrončok  wrote:
>
> On 24. 01. 22 15:16, Daniel Walsh wrote:
> > We would love to have people play with this and test it out.
> >
> > Note: this release has breaking changes to it's API, so it will not be 
> > released
> > to f35. Only to F36, but users will be able to download and use it on F35, 
> > we
> > will not push it to stable though.
>
> Please, don't use updates-testing this way.

Looks like there's multi-person confusion going on ...
The update has *not* been pushed to f35 updates-testing, even though
the announcement makes it sounds like it was.

In reality it is stuck in the rawhide "testing" state limbo in bodhi
(which is not composed into a real "updates-testing" repo!) due to
failed gating tests, so the package really is available *nowhere*
right now.

Except that 4.0.0-rc1 was already built and pushed to rawhide three
days ago, but it was not announced then.
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 on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: mass rebuild status - 2022-01-24

[Vitaly Zaitsev via devel]

On 24/01/2022 19:06, Kevin Fenzi wrote:

This seems kind of high, so we are going to resubmit all the failed
builds in a short second round to reduce the chance of transitory issues
causing the build failures.


I think the ppc64 GCC regressions should be fixed first.

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

Re: mass rebuild status - 2022-01-24

[Jakub Jelinek]

On Mon, Jan 24, 2022 at 08:00:31PM +0100, Vitaly Zaitsev via devel wrote:
> On 24/01/2022 19:06, Kevin Fenzi wrote:
> > This seems kind of high, so we are going to resubmit all the failed
> > builds in a short second round to reduce the chance of transitory issues
> > causing the build failures.
> 
> I think the ppc64 GCC regressions should be fixed first.

Yeah.
The current state is that both the ppc64le long double related bugs have
been discussed with IBM, I have patches for both, bootstrapping/regtesting
them now on GCCFarm and am also doing a scratch koji build:
https://koji.fedoraproject.org/koji/taskinfo?taskID=81773481
If the first testing looks ok, will submit them for upstream review,
if that is approved tonight or tomorrow will include those in tomorrow's
gcc rebuild (unlike the scratch build, that will include various other
fixes).  But ETA from the build start is ~ 20 or more hours, so Wednesday.

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

Schedule for Tuesday's FESCo Meeting (2022-01-25)

[Stephen Gallagher]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Following is the list of topics that will be discussed in the
FESCo meeting Tuesday at 18:00UTC in #fedora-meeting on
irc.libera.chat.

To convert UTC to your local time, take a look at
  http://fedoraproject.org/wiki/UTCHowto

or run:
  date -d '2022-01-25 18:00 UTC'


Links to all issues to be discussed can be found at:
https://pagure.io/fesco/report/meeting_agenda

= Discussed and Voted in the Ticket =

F36 Change: Django 4.0
https://pagure.io/fesco/issue/2733
APPROVED (+3,0,-0)


= Followups =

#2711 F36 Change: Enable fs-verity in RPM
https://pagure.io/fesco/issue/2711

#2721 F36 Change: DIGLIM
https://pagure.io/fesco/issue/2721


= New business =

#2732 F36 Change: No ifcfg by default
https://pagure.io/fesco/issue/2732


= Open Floor =

For more complete details, please visit each individual
issue.  The report of the agenda items can be found at
https://pagure.io/fesco/report/meeting_agenda

If you would like to add something to this agenda, you can
reply to this e-mail, file a new issue at
https://pagure.io/fesco, e-mail me directly, or bring it
up at the end of the meeting, during the open floor topic. Note
that added topics may be deferred until the following meeting.
-BEGIN PGP SIGNATURE-

iQGzBAEBCAAdFiEEhQqd0dvyrMxvxJSRRduFpWgobREFAmHu+48ACgkQRduFpWgo
bRHGqQwAlHLLezSdzfdj4XVrOEF0KyOItm9qxSI6aceJjj2vmB7Stz937gbuRjG0
ouWRPa3oK/e51xmvD7jTapfBbZwRLEfGrFrg3yOj7UefgNIZ6lzGEF3rWlC3gRCG
XmACXDd/kVQUSH4Fyl+Bb9OfKAIJ0VT2EKXMaReSC8nHN/udbk2qIs+F3HKkPs+e
xVdMYXiDVcq004RAkgOqGZ+YdQVVwd1wQcPn26VYll6iHHUki5Yctyh76Gp4bE1Z
mhTll6wEXVHhxeY2d+uqI9IFHEduCRD9089Rx3+FpH2OoIqzNh9FZuxbTZkpxFoP
/+1Gt53k7sCQ8vhq6esB/qCBVWUlPhF935mhiuJ1iJ7KhvoQNsmCpRjVemkWBNQi
1arT5kvtE9i7RUEQnQmcZaLTJJG9ynSRDBOhjeItWTKoJSiYa+RKSkhzqhHu9zAt
UhB+Bgf8sEDL7opKWKDgbWbLuk4WIV93PwVUpvG8mnmqcZIBLfYeoawZSNiHXokU
3tagTJiq
=QxlH
-END 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 on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: Help needed updating Lazarus to v2.2.0

[Mattia Verga via devel]

I've noticed that this change:
https://gitlab.com/freepascal.org/fpc/source/-/commit/b00fe0e4e42526afb7a11e9964f8cae49b10da44

which is supposed to fix:
https://gitlab.com/freepascal.org/fpc/source/-/issues/39295

has been applied only on ppc64. And the only arch which is now failing the 
build is ppc64...

Inviato da ProtonMail mobile

 Messaggio originale 
On 24 Gen 2022, 13:49, Artur Frenszek-Iwicki ha scritto:

> Hi all,
>
> some time ago, Lazarus v2.2.0 came out. I tried to update the package
> in Rawhide, but the build failed on ppc64le with a linking error.
> Link to failed scratch build: 
> https://koji.fedoraproject.org/koji/taskinfo?taskID=81313575
>
> ../units/powerpc64-linux/nogui/project.o: in function 
> `WRPR_$PROJECT_$$_TPROJECT_$_IPROJPACK_$_1_$_CLASSES$_$TCOMPONENT_$__$$__ADDREF$$LONGINT':
> /builddir/build/BUILD/lazarus-2.2.0/lazarus/ide//project.pp:1:(.text.n_WRPR_$PROJECT_$$_TPROJECT_$_IPROJPACK_$_1_$_CLASSES$_$TCOMPONENT_$__$$__ADDREF$$LONGINT+0x4):
>  call to `CLASSES$_$TCOMPONENT_$__$$__ADDREF$$LONGINT' lacks nop, can't 
> restore toc; (toc save/adjust stub)
> /usr/bin/ld: final link failed: bad value
>
> I was wondering if this was a Fedora-specific issue, or some upstream bug,
> so I went to the bug tracker. As it turned out, this issue has already
> been reported, as openSUSE had stumbled on the exact same error.
> https://gitlab.com/freepascal.org/lazarus/lazarus/-/issues/39534
>
> So, that was two weeks ago. Why bring it up now?
> Because we're fresh after the F36 Mass Rebuild, and several packages
> depending on Lazarus failed to build, with very similar errors:
> a segmentation fault somewhere in "lazbuild", the CLI tool for
> building Lazarus projects.
>
> Affected packages:
> - cqrlog: https://koji.fedoraproject.org/koji/taskinfo?taskID=81478836
> - doublecmd: https://koji.fedoraproject.org/koji/taskinfo?taskID=81482400
> - goverlay: https://koji.fedoraproject.org/koji/taskinfo?taskID=81517949
> - lazpaint: https://koji.fedoraproject.org/koji/taskinfo?taskID=81530759
> - pasdoc: https://koji.fedoraproject.org/koji/taskinfo?taskID=81557894
>
> So I'm here thinking that maybe, if we were able to solve the pcc64le
> issue and update Lazarus to v2.2.0, we can then try rebuilding the affected
> packages and see if the segfault this occurs. Only problem is,
> unfortunately, I know very little about compilers & linkers & assembly,
> so the ppc64le issue is way outside my field of knowledge.
> As such, any help regarding coming up with a patch will be greatly 
> appreciated.
>
> For the record, the Lazarus package ships with a couple patches,
> and those needed to be updated from v2.0.12 for v2.2.0. I did not
> commit those to the main repository yet, but you can grab them from this fork:
> https://src.fedoraproject.org/fork/suve/rpms/lazarus
>
> Thanks in advance.
>
> A.FI.
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct: 
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: 
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
> Do not reply to spam on the list, report it: 
> https://pagure.io/fedora-infrastructure___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: Help needed updating Lazarus to v2.2.0

[Dan Horák]

On Mon, 24 Jan 2022 19:51:26 +
Mattia Verga via devel  wrote:

> I've noticed that this change:
> https://gitlab.com/freepascal.org/fpc/source/-/commit/b00fe0e4e42526afb7a11e9964f8cae49b10da44
> 
> which is supposed to fix:
> https://gitlab.com/freepascal.org/fpc/source/-/issues/39295
> 
> has been applied only on ppc64. And the only arch which is now failing the 
> build is ppc64...

I don't think this is related at all to the current issue.


Dan
 
> Inviato da ProtonMail mobile
> 
>  Messaggio originale 
> On 24 Gen 2022, 13:49, Artur Frenszek-Iwicki ha scritto:
> 
> > Hi all,
> >
> > some time ago, Lazarus v2.2.0 came out. I tried to update the package
> > in Rawhide, but the build failed on ppc64le with a linking error.
> > Link to failed scratch build: 
> > https://koji.fedoraproject.org/koji/taskinfo?taskID=81313575
> >
> > ../units/powerpc64-linux/nogui/project.o: in function 
> > `WRPR_$PROJECT_$$_TPROJECT_$_IPROJPACK_$_1_$_CLASSES$_$TCOMPONENT_$__$$__ADDREF$$LONGINT':
> > /builddir/build/BUILD/lazarus-2.2.0/lazarus/ide//project.pp:1:(.text.n_WRPR_$PROJECT_$$_TPROJECT_$_IPROJPACK_$_1_$_CLASSES$_$TCOMPONENT_$__$$__ADDREF$$LONGINT+0x4):
> >  call to `CLASSES$_$TCOMPONENT_$__$$__ADDREF$$LONGINT' lacks nop, can't 
> > restore toc; (toc save/adjust stub)
> > /usr/bin/ld: final link failed: bad value
> >
> > I was wondering if this was a Fedora-specific issue, or some upstream bug,
> > so I went to the bug tracker. As it turned out, this issue has already
> > been reported, as openSUSE had stumbled on the exact same error.
> > https://gitlab.com/freepascal.org/lazarus/lazarus/-/issues/39534
> >
> > So, that was two weeks ago. Why bring it up now?
> > Because we're fresh after the F36 Mass Rebuild, and several packages
> > depending on Lazarus failed to build, with very similar errors:
> > a segmentation fault somewhere in "lazbuild", the CLI tool for
> > building Lazarus projects.
> >
> > Affected packages:
> > - cqrlog: https://koji.fedoraproject.org/koji/taskinfo?taskID=81478836
> > - doublecmd: https://koji.fedoraproject.org/koji/taskinfo?taskID=81482400
> > - goverlay: https://koji.fedoraproject.org/koji/taskinfo?taskID=81517949
> > - lazpaint: https://koji.fedoraproject.org/koji/taskinfo?taskID=81530759
> > - pasdoc: https://koji.fedoraproject.org/koji/taskinfo?taskID=81557894
> >
> > So I'm here thinking that maybe, if we were able to solve the pcc64le
> > issue and update Lazarus to v2.2.0, we can then try rebuilding the affected
> > packages and see if the segfault this occurs. Only problem is,
> > unfortunately, I know very little about compilers & linkers & assembly,
> > so the ppc64le issue is way outside my field of knowledge.
> > As such, any help regarding coming up with a patch will be greatly 
> > appreciated.
> >
> > For the record, the Lazarus package ships with a couple patches,
> > and those needed to be updated from v2.0.12 for v2.2.0. I did not
> > commit those to the main repository yet, but you can grab them from this 
> > fork:
> > https://src.fedoraproject.org/fork/suve/rpms/lazarus
> >
> > Thanks in advance.
> >
> > A.FI.
> > ___
> > devel mailing list -- devel@lists.fedoraproject.org
> > To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> > Fedora Code of Conduct: 
> > https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> > List Archives: 
> > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
> > Do not reply to spam on the list, report it: 
> > https://pagure.io/fedora-infrastructur  
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: mass rebuild status - 2022-01-24

[Kevin Fenzi]

On Mon, Jan 24, 2022 at 08:08:25PM +0100, Jakub Jelinek wrote:
> On Mon, Jan 24, 2022 at 08:00:31PM +0100, Vitaly Zaitsev via devel wrote:
> > On 24/01/2022 19:06, Kevin Fenzi wrote:
> > > This seems kind of high, so we are going to resubmit all the failed
> > > builds in a short second round to reduce the chance of transitory issues
> > > causing the build failures.
> > 
> > I think the ppc64 GCC regressions should be fixed first.
> 
> Yeah.
> The current state is that both the ppc64le long double related bugs have
> been discussed with IBM, I have patches for both, bootstrapping/regtesting
> them now on GCCFarm and am also doing a scratch koji build:
> https://koji.fedoraproject.org/koji/taskinfo?taskID=81773481
> If the first testing looks ok, will submit them for upstream review,
> if that is approved tonight or tomorrow will include those in tomorrow's
> gcc rebuild (unlike the scratch build, that will include various other
> fixes).  But ETA from the build start is ~ 20 or more hours, so Wednesday.

That seems long to wait for mass rebuild merging. I'd like to start
trying to get composes and get the rebuilt packages out so people can
start testing them/fixing fallout from the rebuild.

Perhaps we could merge today and then do another pass of failed builds
into f36-rebuild tag and merge that back on thursday or something?
Can we easily identify those builds that failed due to these ppc64le
issues?

kevin


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 on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: mass rebuild status - 2022-01-24

[Dan Horák]

On Mon, 24 Jan 2022 12:10:37 -0800
Kevin Fenzi  wrote:

> On Mon, Jan 24, 2022 at 08:08:25PM +0100, Jakub Jelinek wrote:
> > On Mon, Jan 24, 2022 at 08:00:31PM +0100, Vitaly Zaitsev via devel wrote:  
> > > On 24/01/2022 19:06, Kevin Fenzi wrote:  
> > > > This seems kind of high, so we are going to resubmit all the failed
> > > > builds in a short second round to reduce the chance of transitory issues
> > > > causing the build failures.  
> > > 
> > > I think the ppc64 GCC regressions should be fixed first.  
> > 
> > Yeah.
> > The current state is that both the ppc64le long double related bugs have
> > been discussed with IBM, I have patches for both, bootstrapping/regtesting
> > them now on GCCFarm and am also doing a scratch koji build:
> > https://koji.fedoraproject.org/koji/taskinfo?taskID=81773481
> > If the first testing looks ok, will submit them for upstream review,
> > if that is approved tonight or tomorrow will include those in tomorrow's
> > gcc rebuild (unlike the scratch build, that will include various other
> > fixes).  But ETA from the build start is ~ 20 or more hours, so Wednesday.  
> 
> That seems long to wait for mass rebuild merging. I'd like to start
> trying to get composes and get the rebuilt packages out so people can
> start testing them/fixing fallout from the rebuild.
> 
> Perhaps we could merge today and then do another pass of failed builds
> into f36-rebuild tag and merge that back on thursday or something?
> Can we easily identify those builds that failed due to these ppc64le
> issues?

it sounds like a good plan to me

regarding the list of builds to retry - I would rebuild everything that
has a failed buildArch task on ppc64le


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

Re: Orphaned packages looking for new maintainers

[Gwyn Ciesla via devel]

I took xmlgraphics-common for fotoxx, but if anyone with greater Java knowledge 
wants it, let me know.

-- 
Gwyn Ciesla
she/her/hers
 
in your fear, seek only peace 
in your fear, seek only love
-d. bowie

Sent with ProtonMail Secure Email.

‐‐‐ Original Message ‐‐‐

On Monday, January 24th, 2022 at 12:55 PM, Miro Hrončok  
wrote:

> The following packages are orphaned and will be retired when they
> 

> are orphaned for six weeks, unless someone adopts them. If you know for sure
> 

> that the package should be retired, please do so now with a proper reason:
> 

> https://fedoraproject.org/wiki/How_to_remove_a_package_at_end_of_life
> 

> Note: If you received this mail directly you (co)maintain one of the affected
> 

> packages or a package that depends on one. Please adopt the affected package 
> or
> 

> retire your depending package to avoid broken dependencies, otherwise your
> 

> package will fail to install and/or build when the affected package gets 
> retired.
> 

> Request package ownership via the Take button in he left column on
> 

> https://src.fedoraproject.org/rpms/
> 

> Full report available at:
> 

> https://churchyard.fedorapeople.org/orphans-2022-01-24.txt
> 

> grep it for your FAS username and follow the dependency chain.
> 

> For human readable dependency chains,
> 

> see https://packager-dashboard.fedoraproject.org/
> 

> For all orphaned packages,
> 

> see https://packager-dashboard.fedoraproject.org/orphan
> 

> Package (co)maintainers Status Change
> =
> 

> 3proxy orphan 0 weeks ago
> 

> DivFix++ orphan 0 weeks ago
> 

> colorize orphan 0 weeks ago
> 

> curlftpfs orphan 0 weeks ago
> 

> dans-gdal-scripts orphan 5 weeks ago
> 

> darkstat orphan 0 weeks ago
> 

> elmon orphan 0 weeks ago
> 

> esniper orphan 5 weeks ago
> 

> fkill-cli orphan 4 weeks ago
> 

> fotoxx limb, orphan 0 weeks ago
> 

> fx orphan 4 weeks ago
> 

> fx-completion orphan 4 weeks ago
> 

> gloox cicku, davidsch, orphan 0 weeks ago
> 

> hans orphan 0 weeks ago
> 

> httpd-itk orphan 0 weeks ago
> 

> iodine lystor, orphan 0 weeks ago
> 

> kea fjanus, orphan, zdohnal 1 weeks ago
> 

> laby orphan 2 weeks ago
> 

> mysqlreport orphan, wolfy 0 weeks ago
> 

> nodejs-svgo nodejs-sig, orphan 4 weeks ago
> 

> npm-name-cli orphan 4 weeks ago
> 

> pacmanager ngompa, orphan 0 weeks ago
> 

> percol orphan 0 weeks ago
> 

> perl-File-Finder orphan 0 weeks ago
> 

> perl-File-Inplace orphan 0 weeks ago
> 

> perl-HTML-FormatText-WithLinks- orphan 0 weeks ago
> 

> AndTables
> 

> perl-IO-Any orphan 0 weeks ago
> 

> perl-JSON-Util orphan 0 weeks ago
> 

> perl-Lingua-EN-Fathom jfearn, orphan 0 weeks ago
> 

> perl-Lingua-EN-Syllable orphan 0 weeks ago
> 

> perl-Locale-Maketext-Gettext orphan 0 weeks ago
> 

> perl-Net-HL7 orphan 4 weeks ago
> 

> perl-ParseLex orphan 0 weeks ago
> 

> perl-String-Similarity lcons, orphan 0 weeks ago
> 

> perl-Sys-Path orphan 0 weeks ago
> 

> perl-Test-Fixme orphan 0 weeks ago
> 

> pgcenter orphan 0 weeks ago
> 

> pgdbf orphan 0 weeks ago
> 

> pgmodeler orphan 0 weeks ago
> 

> php-pecl-solr2 orphan 2 weeks ago
> 

> plexus-i18n mizdebsk, orphan 0 weeks ago
> 

> pmount kni, orphan 0 weeks ago
> 

> pstreams-devel jwakely, orphan 0 weeks ago
> 

> publican jfearn, orphan 0 weeks ago
> 

> python-ECPy orphan 0 weeks ago
> 

> python-btchip jonny, orphan 0 weeks ago
> 

> python-cmigemo orphan 0 weeks ago
> 

> python-jenkins-job-builder ignatenkobrain, ktdreyer, 5 weeks ago
> 

> orphan, pabelanger
> 

> python-netssh2 orphan 2 weeks ago
> 

> python-pykwalify goldmann, orphan 0 weeks ago
> 

> python-wand orphan 2 weeks ago
> 

> rubygem-rsolr orphan 4 weeks ago
> 

> siril astro-sig, lkundrak, lupinix, 4 weeks ago
> 

> orphan
> 

> slim aarem, orphan 0 weeks ago
> 

> sqlite3-dbf orphan 0 weeks ago
> 

> teseq orphan 0 weeks ago
> 

> topojson-client orphan 4 weeks ago
> 

> topojson-server orphan 4 weeks ago
> 

> topojson-simplify orphan 4 weeks ago
> 

> trickle orphan, villadalmine, wolfy 0 weeks ago
> 

> uml_utilities chkr, orphan 3 weeks ago
> 

> vanessa_adt orphan 0 weeks ago
> 

> vanessa_socket orphan 0 weeks ago
> 

> xcf-pixbuf-loader orphan 6 weeks ago
> 

> xmlgraphics-commons orphan 0 weeks ago
> 

> The following packages require above mentioned packages:
> 

> Depending on: fx (1), status change: 2021-12-22 (4 weeks ago)
> 

> fx-completion (maintained by: orphan)
> 

> fx-completion-1.0.5-5.fc36.noarch requires npm(fx) = 20.0.2
> 

> fx-completion-1.0.5-5.fc36.src requires npm(fx) = 20.0.2
> 

> Depending on: gloox (1), status chang

Re: mass rebuild status - 2022-01-24

[Jakub Jelinek]

On Mon, Jan 24, 2022 at 09:15:42PM +0100, Dan Horák wrote:
> > Perhaps we could merge today and then do another pass of failed builds
> > into f36-rebuild tag and merge that back on thursday or something?
> > Can we easily identify those builds that failed due to these ppc64le
> > issues?
> 
> it sounds like a good plan to me
> 
> regarding the list of builds to retry - I would rebuild everything that
> has a failed buildArch task on ppc64le

Yeah.
Note, there will be other fixes in the upcoming gcc, like some libstdc++
changes, or -fsanitize-coverage=trace-cmp,trace-pc working again etc.,
but bet those are just a handful packages instead of lots of them.
So yes, retrying everything that failed on ppc64le looks like a good plan.

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

Incredible lag of koji notifications

[Ron Olson]

Hey all, I _just_ got an email for my failed job from koji 
(https://koji.fedoraproject.org/koji/taskinfo?taskID=81627145). The job 
started (and finished) on Friday the 21st and yet I just got the email 
about five minutes ago. Is something going on, or is this a normal 
amount of time?


Thanks!

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 on the list, report it: 
https://pagure.io/fedora-infrastructure

F36 Change: Podman 4.0 (Late Self-Contained Change)

[Ben Cotton]

(Process note: this proposal is well past the deadline, but after
consulting with FESCo members, I am announcing it anyway, since it is
a leaf package that should have no impact on other
developers/maintainers)

https://fedoraproject.org/wiki/Changes/Podman4.0

== Summary ==
Podman 4.0 will be released in Fedora 36 for the first time.

== Owner ==
* Name: Dan Walsh
* Email: dwa...@fedoraproject.org


== Detailed Description ==
Podman 4.0 will be fully released for the first time in Fedora 36. The
API has had breaking changes so it will not be released to stable in
Fedora 34 or Fedora 35. Podman 4.0 has a huge amount of changes and a
brand new network stack.


== Benefit to Fedora ==
Podman 4.0 has a huge list of new features, highlighted by a brand new
network stack. Lots of improvements and bug fixes.

See more here: https://github.com/containers/podman/releases/tag/v4.0.0-rc2


== Scope ==
* Proposal owners: It is in RC2, now, so just complete the release.

* Other developers: N/A
* Release engineering:
* Policies and guidelines: N/A (not needed for this Change)
* Trademark approval: N/A (not needed for this Change)
* Alignment with Objectives:


== Upgrade/compatibility impact ==
Podman 3.* release will not be able to connect to Podman 4.0 via
remote API, similarly Podman 4.0 will not be able to connect to Podman
3.* API.

Existing network stack will continue to run, on existing systems.  All
containers and images need to be removed to try out the new network
stack.


== How To Test ==
Just test on existing systems. All Podman containers and images should
continue to work. And all compatibility API (docker-compose,
docker.py) should continue to work.


== User Experience ==


== Dependencies ==


== Contingency Plan ==
* Contingency mechanism: (What to do?  Who will do it?) N/A (not a
System Wide Change)
* Contingency deadline: N/A (not a System Wide Change)
* Blocks release? N/A (not a System Wide Change)


== Documentation ==
N/A (not a System Wide Change)


-- 
Ben Cotton
He / Him / His
Fedora Program Manager
Red Hat
TZ=America/Indiana/Indianapolis
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: Incredible lag of koji notifications

[Kevin Fenzi]

On Mon, Jan 24, 2022 at 02:44:21PM -0600, Ron Olson wrote:
> Hey all, I _just_ got an email for my failed job from koji
> (https://koji.fedoraproject.org/koji/taskinfo?taskID=81627145). The job
> started (and finished) on Friday the 21st and yet I just got the email about
> five minutes ago. Is something going on, or is this a normal amount of time?

It's the mass rebuild. 

FMN can't handle the volume, it gets behind. Sometimes it stops
processing. ;( 

We have a number of ideas how to improve this situation and hopefully we
will get to doing some of that soon. 

kevin


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 on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: mv is massively slower on the host rather than in a nspawn chroot, regression somewhere?

[Chris Murphy]

On Mon, Jan 24, 2022 at 11:41 AM Robert-André Mauchin  wrote:
>
> On 1/24/22 05:14, Chris Murphy wrote:

> > What file system is being used in each case?
> >
>
> Everything is btrfs.
>
> > This is a bit obscure but... cp and mv use reflink=auto. On XFS and
> > Btrfs this means it'll make reflinks (copies metadata, doesn't
> > duplicate the data extents) if it can. Falling back to a full copy
> > (metadata and data extents).
> >
> But both the host and the nspawn container are using btrfs?

Should be true, and if this nspawn container is running on the host
then they should share the same btrfs file system. And even if nspawn
is creating separate subvolumes for the mock build (?not sure if it
does) then because it's a nested subvolume, not mounted, there's no
mount point boundary to cross so you *do* get reflink copies between
subvolumes.

> > It might not be possible due to an obscure VFS rule that disallows
> > reflinks (for reasons I don't understand) when the copy or move
> > crosses mount point boundaries. This includes bind mounts of
> > directories. Bind mounts are also what are employed behind the scene
> > with 'mount -o subvol' mount option on Btrfs, which we use by default
> > in Fedora Workstation and Cloud Edition, and all the desktop spins.
> >
> > The nspawn container, I'm not super familiar with how it works. I
> > think on Btrfs, it will create nested subvolumes, i.e. they are not
> > mounted with the subvol mount option, hence no mount point boundary.
> > But on other file systems, I think nspawn creates a loop mounted file
> > system?
> >
> >
> I've got two subvol:
>
> UUID=ee9eec69-8710-4503-b389-e16fcde8a0a5 /   btrfs
>subvol=root,compress=zstd:1 0 0
>
> UUID=d7e21336-6ac6-483a-b4f2-aaeecabd8f1f /home   btrfs
>subvol=home,compress=zstd:1 0 0
>
> but when I do my tests there is no subvol crossing, everything happens
> on the root subvol?

It might be there's a nested subvolume created by nspawn (I'm not
sure), so maybe part of it happens in some other subvolume. But there
should still be an efficient (reflink) copy.

If cp or mv aren't literally invoked, and the copy is done by some
library then we'd need to find out what ioctl is actually being
called. For example upstream coreutils only just recently cut a new
release v9.0 (only in rawhide) that has the enhancement for cp to use
reflink=auto. It was previously reflink=never which is what's used
most everywhere else other than Fedora.

$ strace cp --reflink=always A B
...
ioctl(4, BTRFS_IOC_CLONE or FICLONE, 3) = 0

$ strace cp --reflink=never A B
...
fadvise64(3, 0, 0, POSIX_FADV_SEQUENTIAL) = 0
mmap(NULL, 139264, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS,
-1, 0) = 0x7faf80f5e000
read(3, "2022/01/12 13:48:21 Starting Blu"..., 131072) = 1756
write(4, "2022/01/12 13:48:21 Starting Blu"..., 1756) = 1756


Sorry though if this is a goose chase. I can't tell if it's a factor
in what's going on. But maybe someone else will find this interesting
:D There is a mostly reliable way to determine if a file is a reflink
copy.

Before the copy, look at the file:

$ filefrag -v A
...
 ext: logical_offset:physical_offset: length:   expected: flags:
   0:0..  14:   10103641..  10103655: 15:
last,encoded,eof
...

The key take away is 10103641. Let's copy it within the same directory:

$ cp A B
$ filefrag -v B
...
   0:0..  14:   10103641..  10103655: 15:
last,encoded,shared,eof
...

Again 1013641. So the data extent location is the same, which is only
possible with a reflink copy, and hence how reflinks go by a more
technical name, shared extents. And you also see in the flags column
"shared". That flag is only there because both A and B exist. If I
remove A or B, such that there is only one file using those extents,
they're no longer shared, so the "shared" flag won't be there. Hence
my emphasis on the address. There *is* logical block address reuse in
Btrfs but due to COW, it's not going to be reused less than about a
minute.

$ cp --reflink=never A C
$ filefrag -v C
...
   0:0..  14:   10398358..  10398372: 15:
last,encoded,eof

Different location because the data extents were duplicated, not shared.

This is the same on XFS too. The subtle differences maybe don't matter
here much. A btrfs subvolume does have it's own st_dev, so things like
rsync -x and borg will not cross subvolume boundaries.


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

Re: mv is massively slower on the host rather than in a nspawn chroot, regression somewhere?

[Chris Murphy]

On Mon, Jan 24, 2022 at 11:44 AM Robert-André Mauchin  wrote:

> Apparently this happens also on ext4 filesystems.

:facepalm: haha! ok well then the previous email i just sent can be
ignored as it relates to this problem!


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

iodine (Re: Orphaned packages looking for new maintainers)

[Gabriel L. Somlo]

On Mon, Jan 24, 2022 at 19:55:17 +0100, Miro Hrončok wrote:
> [...]
> iodinelystor, orphan   0 weeks ago
> [...]

I'm using iodine as part of some training material I produce, so I've
picked it up.

Seems to be low maintenance (famous last words :D) and builds OK in
rawhide, so we'll see how it goes.

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

Re: mv is massively slower on the host rather than in a nspawn chroot, regression somewhere?

[Dominique Martinet]

Chris Murphy wrote on Mon, Jan 24, 2022 at 02:56:09PM -0700:
> Should be true, and if this nspawn container is running on the host
> then they should share the same btrfs file system. And even if nspawn
> is creating separate subvolumes for the mock build (?not sure if it
> does) then because it's a nested subvolume, not mounted, there's no
> mount point boundary to cross so you *do* get reflink copies between
> subvolumes.

For what it's worth the example given does renames in the same directory
(since that's what rpm does when installing things anyway), so there is
no reflink involved, just a plain rename call


I got curious so I tried reproducing but unfortunately I get similar
times whether it's in mock or native, but it varies from a run to
another.

Running with perf record -g, I get the following hog:

-   95.11% 0.01%  mv   [kernel.kallsyms] [k] 
entry_SYSCALL_64_after_hwframe
 95.10% entry_SYSCALL_64_after_hwframe
  - do_syscall_64
 - 92.40% __x64_sys_renameat2
- 92.40% do_renameat2
   - 92.36% vfs_rename
  - 92.34% btrfs_rename2
 - 92.09% btrfs_log_new_name
- btrfs_log_inode_parent
   - 53.42% log_new_dir_dentries
  - 47.27% btrfs_log_inode
 + 13.78% btrfs_log_all_xattrs
 + 11.60% copy_items.isra.0
 + 11.58% drop_objectid_items
 + 4.31% btrfs_search_forward
 + 2.39% btrfs_search_slot
   1.21% btrfs_release_path
 + 1.00% btrfs_commit_inode_delayed_inode
  + 2.26% btrfs_search_forward
  + 1.04% btrfs_iget
0.89% read_extent_buffer
   - 38.65% btrfs_log_inode
  - 38.41% log_directory_changes
 - log_dir_items
- 35.01% overwrite_item
   + 19.04% btrfs_search_slot
   + 3.59% btrfs_release_path
   + 3.32% kfree
 3.07% __kmalloc
 2.84% read_extent_buffer
 1.40% btrfs_get_32
 0.63% memcmp
  1.67% read_extent_buffer


So basically the directory modification is costly for each rename and it
doesn't seem to get batched, maybe that would give a hint as to
somewhere that could be improved.

(I wasn't able to reliably produce the slightly shorter times I got to
check with perf record, but I did get one run with ~20s when it's
usually much longer so there's probably something... Never went as far
down as sub-10s though)

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

Re: Orphaned packages looking for new maintainers

[Sandro Mani]

I took pgmodeler

Sandro

On 24.01.22 19:55, Miro Hrončok wrote:

The following packages are orphaned and will be retired when they
are orphaned for six weeks, unless someone adopts them. If you know 
for sure
that the package should be retired, please do so now with a proper 
reason:

https://fedoraproject.org/wiki/How_to_remove_a_package_at_end_of_life

Note: If you received this mail directly you (co)maintain one of the 
affected
packages or a package that depends on one. Please adopt the affected 
package or
retire your depending package to avoid broken dependencies, otherwise 
your
package will fail to install and/or build when the affected package 
gets retired.


Request package ownership via the *Take* button in he left column on
https://src.fedoraproject.org/rpms/

Full report available at:
https://churchyard.fedorapeople.org/orphans-2022-01-24.txt
grep it for your FAS username and follow the dependency chain.

For human readable dependency chains,
see https://packager-dashboard.fedoraproject.org/
For all orphaned packages,
see https://packager-dashboard.fedoraproject.org/orphan

    Package  (co)maintainers Status Change
 


3proxy    orphan 0 weeks ago
DivFix++  orphan 0 weeks ago
colorize  orphan 0 weeks ago
curlftpfs orphan 0 weeks ago
dans-gdal-scripts orphan 5 weeks ago
darkstat  orphan 0 weeks ago
elmon orphan 0 weeks ago
esniper   orphan 5 weeks ago
fkill-cli orphan 4 weeks ago
fotoxx    limb, orphan 0 weeks ago
fx    orphan 4 weeks ago
fx-completion orphan 4 weeks ago
gloox cicku, davidsch, orphan 0 weeks ago
hans  orphan 0 weeks ago
httpd-itk orphan 0 weeks ago
iodine    lystor, orphan 0 weeks ago
kea   fjanus, orphan, zdohnal 1 weeks ago
laby  orphan 2 weeks ago
mysqlreport   orphan, wolfy 0 weeks ago
nodejs-svgo   nodejs-sig, orphan 4 weeks ago
npm-name-cli  orphan 4 weeks ago
pacmanager    ngompa, orphan 0 weeks ago
percol    orphan 0 weeks ago
perl-File-Finder  orphan 0 weeks ago
perl-File-Inplace orphan 0 weeks ago
perl-HTML-FormatText-WithLinks-   orphan 0 weeks ago
AndTables
perl-IO-Any   orphan 0 weeks ago
perl-JSON-Util    orphan 0 weeks ago
perl-Lingua-EN-Fathom jfearn, orphan 0 weeks ago
perl-Lingua-EN-Syllable   orphan 0 weeks ago
perl-Locale-Maketext-Gettext  orphan 0 weeks ago
perl-Net-HL7  orphan 4 weeks ago
perl-ParseLex orphan 0 weeks ago
perl-String-Similarity    lcons, orphan 0 weeks ago
perl-Sys-Path orphan 0 weeks ago
perl-Test-Fixme   orphan 0 weeks ago
pgcenter  orphan 0 weeks ago
pgdbf orphan 0 weeks ago
pgmodeler orphan 0 weeks ago
php-pecl-solr2    orphan 2 weeks ago
plexus-i18n   mizdebsk, orphan 0 weeks ago
pmount    kni, orphan 0 weeks ago
pstreams-devel    jwakely, orphan 0 weeks ago
publican  jfearn, orphan 0 weeks ago
python-ECPy   orphan 0 weeks ago
python-btchip jonny, orphan 0 weeks ago
python-cmigemo    orphan 0 weeks ago
python-jenkins-job-builder    ignatenkobrain, ktdreyer, 5 weeks ago
  orphan, pabelanger
python-netssh2    orphan 2 weeks ago
python-pykwalify  goldmann, orphan 0 weeks ago
python-wand   orphan 2 weeks ago
rubygem-rsolr orphan 4 weeks ago
siril astro-sig, lkundrak, lupinix, 4 
weeks ago

  orphan
slim  aarem, orphan 0 weeks ago
sqlite3-dbf   orphan 0 weeks ago
teseq orphan 0 weeks ago
topojson-client   orphan 4 weeks ago
topojson-server   orphan 4 weeks ago
topojson-simplify orphan 4 weeks ago
trickle   orphan, villadalmine, wolfy 0 weeks ago
uml_utilities chkr, orphan 3 weeks ago
vanessa_adt   orphan 0 weeks ago
vanessa_socket    orphan 0 weeks ago
xcf-pixbuf-loader orphan 6 weeks ago
xmlgraphics-commons 

Re: gcc-12.0.0-0.4.fc36 in rawhide

[Adam Williamson]

On Mon, 2022-01-24 at 07:15 -0500, Kaleb Keithley wrote:
> On Sat, Jan 22, 2022 at 2:28 PM Kaleb Keithley  wrote:
> 
> > 
> > > The long double change is an ABI change, so this is kind of expected.
> > > Mass rebuild unfortunately doesn't go according to the dependency graph
> > > (and
> > > unfortunately it isn't a tree, there are cycles).
> > > 
> > 
> > Indeed. fmt has not been rebuilt, or more accurately, it failed in the
> > mass rebuild. Specifically the ppc64le build failed.  see
> > https://koji.fedoraproject.org/koji/taskinfo?taskID=81489199
> > 
> 
> I may have missed the email about this. (Sorry if I have.)
> 
> Is there an action on someone's part to fix the assembler, or fix the
> assembly that gcc-12 is emitting on ppc64le that the assembler is puking on?

So, it seems you rebuilt ceph with ppc64le disabled because of this?

That now means there are no ceph packages for ppc64le in Rawhide, which
means that anything that depends on them - which includes qemu - cannot
be installed, and nothing that hits that dep chain can be built.

I just ran into this trying to rebuild os-autoinst, which buildrequires
qemu. :(

I do hope this can be cleaned up soon. Dropping arches from packages is
a very big hammer and should be wielded extremely sparingly. Unless
ceph was unusable without a rebuild on the other arches, it would've
been better to wait until this issue was resolved before rebuilding
ceph.
-- 
Adam Williamson
Fedora QA
IRC: adamw | Twitter: adamw_ha
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 on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: ROCm-Device-Libs packaging question

[Jeremy Newton]

I created a new review request, hopefully that encourages some conversation on 
the topic :)

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

Re: Orphaned packages looking for new maintainers

[Paul Howarth]

I took perl-Test-Fixme.

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