Error while trying to rebuild PCMANFM-Qt

[Robert-André Mauchin]

Hello guys,

So this week-end the project is to rebuild exiv2 to the latest version so I can see my 
brotli-compressed EXIF data from my JPEG-XL pictures in Gwenview.


As part of this task, I am rebuilding the dependent packages because of SONAME 
bump.

I am stuck on PCMANFM-Qt rebuilt :

CMake Error in pcmanfm/CMakeLists.txt:
  Imported target "fm-qt" includes non-existent path

"/usr/include/sysprof-4"

  in its INTERFACE_INCLUDE_DIRECTORIES.  Possible reasons include:

  * The path was deleted, renamed, or moved to another location.

  * An install or uninstall procedure did not complete successfully.

  * The installation package was faulty and references files it does not
  provide.


From what I gather, this is due to Kalev Lember update of sysprof to 45.0 2 
months ago:


https://src.fedoraproject.org/rpms/sysprof/c/628707353fe95954ad3ca003b0c891a1c73a6d1b?branch=rawhide

 %files devel
- %{_includedir}/sysprof-4/
- %{_includedir}/sysprof-ui-5/
- %{_libdir}/pkgconfig/sysprof-4.pc
+ %{_includedir}/sysprof-6/
+ %{_libdir}/libsysprof-6.so
+ %{_libdir}/pkgconfig/sysprof-6.pc

The issue is I can't find anything related to sysprof in PCMANFM-Qt or its dependencies/, so 
I can't find frpm where the issue comes from.


If I fedrq sysprof:

fedrq whatrequires-src sysprof

cjs-1:5.8.0-2.fc39.src
gjs-1.78.0-3.fc40.src
glib2-2.78.1-1.fc40.src
glib2-devel-2.78.1-1.fc40.i686
glib2-devel-2.78.1-1.fc40.x86_64
glib2-static-2.78.1-1.fc40.i686
glib2-static-2.78.1-1.fc40.x86_64
gnome-builder-45.0-1.fc40.src
gnome-software-45.1-3.fc40.src
gnome-software-devel-45.1-3.fc40.i686
gnome-software-devel-45.1-3.fc40.x86_64
gtk4-4.13.2-1.fc40.src
gtksourceview5-5.10.0-1.fc40.src
gtksourceview5-devel-5.10.0-1.fc40.i686
gtksourceview5-devel-5.10.0-1.fc40.x86_64
libdex-0.4.1-1.fc40.src
libshumate-devel-1.1.0-1.fc40.i686
libshumate-devel-1.1.0-1.fc40.x86_64
libsoup-2.74.3-3.fc39.src
libsoup-devel-2.74.3-3.fc39.i686
libsoup-devel-2.74.3-3.fc39.x86_64
libsoup3-3.4.4-1.fc40.src
libsoup3-devel-3.4.4-1.fc40.i686
libsoup3-devel-3.4.4-1.fc40.x86_64
magpie-0.9.2-1.fc40.src
mutter-45.1-1.fc40.src
sysprof-45.1-1.fc40.x86_64
sysprof-cli-45.1-1.fc40.x86_64
sysprof-devel-45.1-1.fc40.i686
sysprof-devel-45.1-1.fc40.x86_64

only glib2 seems to be in the dep tree but I don't see anything related to 
sysprof in it.

I am open to any input regarding this.

Thank you.

Have a great Sunday,

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

EXIV2 BMFF Patents situation

[Robert-André Mauchin]

Hello,

In order to update Exiv2, we need to know if this is okay to enable BMFF support. Patents 
have theoretically expired and it is enabled by default in the latest version.


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

https://github.com/Exiv2/exiv2/issues/1679

Upstream seems to think it is okay because it is over 20 years old. Also other packages in 
Fedora are already using it, av1, jpeg-xl, any mp4 decoding.


By Jon Sneyers, one of the author of JPEG-XL:

I think this caution is erring on the side of paranoia, and possibly based on a 
misunderstanding.


ISOBMFF is pretty old, old enough for it to be impossible to still have applicable 
patents (patents expire after 20 years). It is a simple box-based container format that is 
used by many formats, including MP4, JPEG 2000, and JPEG XL.


One particular use of ISOBMFF is HEIF, which is more recent, and for which there 
actually are known patent claims by Nokia. HEIF does use the generic ISOBMFF box structure 
and extends it by defining mechanisms to do cropping, layering, grids, rotation etc, which 
are described in the HEIF spec. HEIF can be used with various payloads: when used with HEVC 
it is called HEIC, when used with AV1 it is called AVIF.


While most people would consider patents on a container format ridiculous, it is a fact 
that, at least in theory, if you use HEIF, you might risk patent litigation. Note that it 
would not be the application implementor who could be sued, but the end-user who uses the 
implementation and thereby possibly needs a patent license from Nokia.


This is only true specifically for HEIF though, not for ISOBMFF in general. Parsing the 
MP4 or JPEG 2000 container (which do not use HEIF) carries absolutely no risk in terms of 
patents, since they only use ISOBMFF, not HEIF. The same is true for JPEG XL, which has 
explicitly avoided using the HEIF container exactly for this reason.


TL;DR: ISOBMFF is OK, HEIF might be risky.

So just to be clear: reading BMFF is not an issue, it is over 20 years old so even if 
it was an issue in the past (it wasn't) it now certainly isn't anymore.


Reading HEIF-specific boxes is something else, but as long as Exiv2 is not doing that, 
there obviously is no issue either. Note that other FOSS tools like libheif and libavif 
actually do read those boxes, and they do seem to get away with it (but I can understand why 
you wouldn't want to do that; those boxes are from 2015 and Nokia does claim patents on them 
so it will only really be 'safe' to use that functionality in 2035).


So while I appreciate the caution, I think it's OK to just enable the BMFF code by 
default (perhaps have an option to disable it, if someone is still for some reason worried, 
but imo that would be an unfounded worry). Otherwise most of the modern image codecs (jp2, 
jxl, avif and heic) end up being unsupported by default, for no good reason, which seems a 
suboptimal situation.



Could we come to a resolution of that situation quickly?

Thank you,

Have a great sunday.

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

[rpms/perl-Image-ExifTool] PR #1: Update to 12.69

[Robert-André Mauchin]

eclipseo opened a new pull-request against the project: `perl-Image-ExifTool` 
that you are following:
``
Update to 12.69
``

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

Re: SPDX Statistics - Miracle of the Sun edition

[Robert-André Mauchin]

On 10/13/23 08:15, Miroslav Suchý wrote:

Hot news:

There was new release of SPDX License list. If you want to see impact of Fedora work you can 
check number of new licenses in recent releases and compare


https://github.com/spdx/license-list-XML/releases

and compare it with content of the releases before we started migrating packages (~ Nov 
2022) i.e. version 3.19.


Reviewers wanted: Package review of scancode-toolkit still need 3 dependencies to be review 
https://bugzilla.redhat.com/show_bug.cgi?id=2235055


Now lets dive into numbers:

Two weeks ago we had:


* 23100 spec files in Fedora

* 29479license tags in all spec files

* 12870 tags have not been converted to SPDX yet

* 5817tags can be trivially converted using `license-fedora2spdx`

* Progress: 56.34% ░█ 100%

ELN subset:

913 out of 3957 packages are not converted yet



Today we have:

* 23188 spec files in Fedora

* 29635license tags in all spec files

* 12724 tags have not been converted to SPDX yet

* 5742tags can be trivially converted using `license-fedora2spdx`

* Progress: 57.06% ░█ 100%

ELN subset:

490 out of 3139 packages are not converted yet

Graph with the burndown chart:

https://docs.google.com/spreadsheets/d/1QVMEzXWML-6_Mrlln02axFAaRKCQ8zE807rpCjus-8s/edit?usp=sharing

The list of packages needed to be converted is here:

https://pagure.io/copr/license-validate/blob/main/f/packages-without-spdx-final.txt

List by package maintainers is here

https://pagure.io/copr/license-validate/blob/main/f/packages-without-spdx-final-maintainers.txt

List of packages from ELN subset that needs to be converted:

https://pagure.io/copr/license-validate/blob/main/f/eln-not-migrated.txt

New version of fedora-license-data has been released. With 15 new licenses (plus bunch of 
public domain declarations). 15 licenses are waiting to be review by SPDX.org (and then to 
be added to fedora-license-data) 
https://gitlab.com/fedora/legal/fedora-license-data/-/issues/?label_name%5B%5D=SPDX%3A%3Ablocked


Legal docs and especially

https://docs.fedoraproject.org/en-US/legal/allowed-licenses/

was updated too.


New projection when we will be finished is 2024-08-23.  Pure linear 
approximation.

If your package does not have neither git-log entry nor spec-changelog entry mentioning SPDX 
and you know your license tag matches SPDX formula, you can put your package on ignore list


https://pagure.io/copr/license-validate/blob/main/f/ignore-packages.txt

Either pull-request or direct email to me is fine.



I'm updating Clementine to SPDX, with full reanalysis of the project:

# Apache-2.0:
#   - ext/libclementine-common/core/latch.cpp
#   - ext/libclementine-common/core/latch.h
#   - ext/libclementine-remote/remotecontrolmessages.proto
#   - ext/libclementine-common/core/logging.cpp
#   - ext/libclementine-common/core/logging.h
#   - ext/libclementine-common/core/messagehandler.cpp
#   - ext/libclementine-common/core/messagehandler.h
#   - ext/libclementine-common/core/override.h
#   - ext/libclementine-common/core/timeconstants.h
# BSL-1.0: 3rdparty/utf8-cpp
# GPL-2.0-or-later:
#   - src/engines/gstengine.cpp
#   - src/engines/gstengine.h
#   - src/widgets/sliderwidget.cpp
#   - src/widgets/sliderwidget.h
# LGPL-2.0-or-later:
#   - gst/moodbar/gstfastspectrum.cpp
#   - gst/moodbar/gstfastspectrum.h
# LGPL-2.1-only:
#   - 3rdparty/taglib
#   - src/widgets/stylehelper:
# LGPL-2.1-only WITH Qt-LGPL-exception-1.1 OR GPL-3.0-only:
#   - 3rdparty/qsqlite/clementinesqlcachedresult.cpp
#   - 3rdparty/qsqlite/clementinesqlcachedresult.h
#   - 3rdparty/qsqlite/qsql_sqlite.cpp
#   - 3rdparty/qsqlite/qsql_sqlite.h
# LGPL-2.1-only WITH Qt-LGPL-exception-1.1 OR LGPL-3.0-only WITH 
Qt-LGPL-exception-1.1:
#   - 3rdparty/qsqlite/smain.cpp
#   - 3rdparty/qsqlite/smain.h
# MIT: 3rdparty/qocoa
License:GPL-3.0-or-later AND GPL-2.0-or-later AND BSL-1.0 AND LGPL-2.0-or-later AND 
LGPL-2.1-only AND Apache-2.0 AND (LGPL-2.1-only WITH Qt-LGPL-exception-1.1 OR GPL-3.0-only) 
AND (LGPL-2.1-only WITH Qt-LGPL-exception-1.1 OR LGPL-3.0-only WITH Qt-LGPL-exception-1.1) 
AND MIT

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

SPDX short name for "Redistributable, no modification permitted" (firmware)

[Robert-André Mauchin]

Hi,

I'm doing a MR on an old package that contains firmware data.

I wanna convert to SPDX, what is the equivalent to "Redistributable, no modification 
permitted" in SPDX.


The license is:

The files in the directory src/miniloader are provided pursuant to the
following license agreement:

   License For Customer Use of NVIDIA Software


IMPORTANT NOTICE -- READ CAREFULLY: This License For Customer Use of
NVIDIA Software ("LICENSE") is the agreement which governs use of
the software of NVIDIA Corporation and its subsidiaries ("NVIDIA")
downloadable herefrom, including computer software and associated
printed materials ("SOFTWARE").  By downloading, installing, copying,
or otherwise using the SOFTWARE, you agree to be bound by the terms
of this LICENSE.  If you do not agree to the terms of this LICENSE,
do not download the SOFTWARE.

RECITALS

Use of NVIDIA's products requires three elements: the SOFTWARE, the
hardware, and a personal computer. The SOFTWARE is protected by copyright
laws and international copyright treaties, as well as other intellectual
property laws and treaties.  The SOFTWARE may be protected by various
patents, and is not sold, and instead is only licensed for use, strictly
in accordance with this document.  The hardware is protected by various
patents, and is sold, but this agreement does not cover that sale, since
it may not necessarily be sold as a package with the SOFTWARE.  This
agreement sets forth the terms and conditions of the SOFTWARE LICENSE only.

1.  DEFINITIONS

1.1  Customer.  Customer means the entity or individual that
downloads or otherwise obtains the SOFTWARE.

2.  GRANT OF LICENSE

2.1  Rights and Limitations of Grant.  NVIDIA hereby grants Customer
the following non-exclusive, non-transferable right to use the
SOFTWARE, with the following limitations:

2.1.1  Rights.  Customer may install and use multiple copies of the
SOFTWARE on a shared computer or concurrently on different computers,
and make multiple back-up copies of the SOFTWARE, solely for Customer's
use within Customer's Enterprise. "Enterprise" shall mean individual use
by Customer or any legal entity (such as a corporation or university)
and the subsidiaries it owns by more than fifty percent (50%).

2.1.2  Open Source Exception.  Notwithstanding the foregoing terms
of Section 2.1.1, SOFTWARE may be copied and redistributed solely for
use on operating systems distributed under the terms of an OSI-approved
open source license as listed by the Open Source Initiative at
http://opensource.org, provided that the binary files thereof are not
modified, and Customer provides a copy of this license with the SOFTWARE.

2.1.3  Limitations.

No Reverse Engineering.  Customer may not reverse engineer,
decompile, or disassemble the SOFTWARE, nor attempt in any other
manner to obtain the source code.

Usage. SOFTWARE is licensed only for use with microprocessor(s) which have
been (i) designed by NVIDIA and (ii) either (a) sold by or (b) licensed by
NVIDIA. Customer shall not use SOFTWARE in conjunction with, nor cause
SOFTWARE to be executed by, any other microprocessor.

No Translation. Customer shall not translate SOFTWARE, nor cause or permit
SOFTWARE to be translated, from the architecture or language in which it is
originally provided by NVIDIA, into any other architecture or language.

No Rental.  Customer may not rent or lease the SOFTWARE to someone
else.

3.  TERMINATION

This LICENSE will automatically terminate if Customer fails to
comply with any of the terms and conditions hereof.  In such event,
Customer must destroy all copies of the SOFTWARE and all of its
component parts.

Defensive Suspension.  If Customer commences or participates in any legal
proceeding against NVIDIA, then NVIDIA may, in its sole discretion,
suspend or terminate all license grants and any other rights provided
under this LICENSE during the pendency of such legal proceedings.

4.  COPYRIGHT

All title and copyrights in and to the SOFTWARE (including but
not limited to all images, photographs, animations, video, audio,
music, text, and other information incorporated into the SOFTWARE),
the accompanying printed materials, and any copies of the SOFTWARE,
are owned by NVIDIA, or its suppliers.  The SOFTWARE is protected
by copyright laws and international treaty provisions.  Accordingly,
Customer is required to treat the SOFTWARE like any other copyrighted
material, except as otherwise allowed pursuant to this LICENSE
and that it may make one copy of the SOFTWARE solely for backup or
archive purposes.

5.  APPLICABLE LAW

This agreement shall be deemed to have been made in, and shall be
construed pursuant to, the laws of the State of California.

6.  DISCLAIMER OF WARRANTIES AND LIMITATION ON LIABILITY

6.1  No Warranties.  TO THE MAXIMUM EXTENT PERMITTED BY APPLICABLE
LAW, THE SOFTWARE IS PROVIDED "AS IS" AND NVIDIA AND ITS SUPPLIERS
DISCLAIM ALL WARRANTIES, EITHER EXPRESS OR IMPLIED, INCLUDING, BUT
NOT LIMITED TO, IMPLIED 

Lastpass-cli license correction

[Robert-André Mauchin]

Hello Fedoreans an others,

Lastpass-cli license will be corrected from GPL-2.0-only to:

GPL-2.0-only WITH cryptsetup-OpenSSL-exception AND OpenSSL

In the next 1.3.5 update. Which will hopefully makes the program functional 
again.

Best regards,

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

Re: Simple review swap: python-pygments-git

[Robert-André Mauchin]

On 8/29/23 13:40, Ankur Sinha wrote:

Hi folks,

Would someone like to swap reviews please? I'd like to get
python-pygments-git reviewed. They are pygments lexers for git output
and files. The review is here:

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

It should be a simple review, so unofficial reviews from folks looking
to get sponsored to the packager group are also most welcome.



Hi,

Taken.

I'd like you to use the Github archive to run the tests suite.


Best regards,

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

Re: Self Introduction: Adam Piasecki

[Robert-André Mauchin]

On 8/24/23 15:48, Adam Piasecki wrote:

Hello everyone,
I hope this message finds you all well!

My name is Adam Piasecki, and I've recently joined this mailing list to further 
immerse myself in such a vibrant open-source community ;)
I joined Red Hat in 2022 as an intern, and ever since one thing has been 
constant: my sincere belief in the transformative power of open source. It's 
not just the technology; it’s the ethos, the collaborative spirit, and the 
boundless opportunities for innovation that have always resonated deeply with 
me.

Recently I focused mostly on the CoreOS project, where I'm proudly working as 
an Associate Software Engineer (I find coreos-assembler quite intriguing).
I truly believe in the value that CoreOS brings to the container ecosystem and 
I am eager to contribute to its growth. I am here not only to learn from each 
and every one of you but also to share my knowledge, insights, and creativity 
when possible.

Please feel free to reach out if you have any questions or suggestions. I am 
always open to collaboration, brainstorming, and lending a hand wherever needed.

Here's to many fruitful discussions!

Warm regards,
Adamsky, aka. c4rt0


Welcome to the Fedora Community, Adam!


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

Re: Donate 1 minute of your time to test upgrades from F38 to F39

[Robert-André Mauchin]

On 8/23/23 20:22, Miroslav Suchý wrote:

Do you want to make Fedora 39 better? Please spend 1 minute of your time and 
try to run:

# Run this only if you use default Fedora modules
# next time you run any DNF command default modules will be enabled again
sudo dnf module reset '*'

dnf --releasever=39 --setopt=module_platform_id=platform:f39 \
--enablerepo=updates-testing \
$(rpm -q fedora-repos-modular >/dev/null && echo 
--enablerepo=updates-testing-modular) \
--assumeno distro-sync


This command does not replace `dnf system-upgrade`, but it will reveal 
potential problems.

You may also run `dnf upgrade` before running this command.


The `--assumeno` will just test the transaction, but does not make the actual 
upgrade.


In case you hit dependency issues, please report it against the appropriate 
package.

Or against fedora-obsolete-packages if that package should be removed in Fedora 39. Please 
check existing reports against fedora-obsolete-packages first:


https://red.ht/2kuBDPu

and also there is already bunch of "Fails to install" (F39FailsToInstall) 
reports:

https://bugzilla.redhat.com/buglist.cgi?bug_id=2168845_id_type=anddependson=tvp_id=12486533


Two notes:

* you may want to run the same command with dnf5 to help test new dnf.

* this command found zero issues on my personal system - great work all 
everybody!


Thank you

Miroslav




sudo dnf --releasever=39 --setopt=module_platform_id=platform:f39 \
 --enablerepo=updates-testing \
 $(rpm -q fedora-repos-modular >/dev/null && echo 
--enablerepo=updates-testing-modular) \

 --assumeno distro-sync


 Problem 1: problem with installed package mangohud-0.6.9.1-1.fc38.i686
  - package mangohud-0.6.9-1.fc39.i686 from fedora requires libfmt.so.9, but none of the 
providers can be installed
  - package mangohud-0.6.9-1.fc39.i686 from updates-testing-modular requires libfmt.so.9, 
but none of the providers can be installed

  - mangohud-0.6.9.1-1.fc38.i686 from @System  does not belong to a distupgrade 
repository
  - fmt-9.1.0-2.fc38.i686 from @System  does not belong to a distupgrade 
repository





 Problem 2: problem with installed package 
mesa-va-drivers-freeworld-23.1.5-1.fc38.x86_64
  - package mesa-va-drivers-freeworld-23.1.5-1.fc39.x86_64 from rpmfusion-free requires 
mesa-filesystem(x86-64) = 23.1.5, but none of the providers can be installed
  - mesa-va-drivers-freeworld-23.1.5-1.fc38.x86_64 from @System  does not belong to a 
distupgrade repository
  - mesa-filesystem-23.1.5-1.fc38.x86_64 from @System  does not belong to a distupgrade 
repository


-> RPMFusion issue probably




 Problem 3: problem with installed package mangohud-0.6.9.1-1.fc38.x86_64
  - package mangohud-0.6.9.1-1.fc38.x86_64 from @System requires 
libspdlog.so.1.11()(64bit), but none of the providers can be installed
  - package mangohud-0.6.9-1.fc39.x86_64 from fedora requires libspdlog.so.1.11()(64bit), 
but none of the providers can be installed
  - package mangohud-0.6.9-1.fc39.x86_64 from updates-testing-modular requires 
libspdlog.so.1.11()(64bit), but none of the providers can be installed

  - spdlog-1.11.0-5.fc38.x86_64 from @System  does not belong to a distupgrade 
repository





 Problem 4: problem with installed package mesa-dri-drivers-23.1.5-1.fc38.x86_64
  - package mesa-dri-drivers-23.2.0~rc2-3.fc39.x86_64 from fedora requires 
mesa-filesystem(x86-64) = 23.2.0~rc2-3.fc39, but none of the providers can be installed
  - package mesa-dri-drivers-23.2.0~rc2-3.fc39.x86_64 from updates-testing-modular requires 
mesa-filesystem(x86-64) = 23.2.0~rc2-3.fc39, but none of the providers can be installed
  - cannot install both mesa-filesystem-23.2.0~rc2-3.fc39.x86_64 from fedora and 
mesa-filesystem-23.1.5-1.fc38.x86_64 from @System
  - cannot install both mesa-filesystem-23.2.0~rc2-3.fc39.x86_64 from 
updates-testing-modular and mesa-filesystem-23.1.5-1.fc38.x86_64 from @System
  - package mesa-vdpau-drivers-freeworld-23.1.5-1.fc39.x86_64 from rpmfusion-free requires 
mesa-filesystem(x86-64) = 23.1.5, but none of the providers can be installed

  - problem with installed package 
mesa-vdpau-drivers-freeworld-23.1.5-1.fc38.x86_64
  - mesa-vdpau-drivers-freeworld-23.1.5-1.fc38.x86_64 from @System  does not belong to a 
distupgrade repository
  - mesa-dri-drivers-23.1.5-1.fc38.x86_64 from @System  does not belong to a distupgrade 
repository






 Problem 5: package steam-1.0.0.78-2.fc39.i686 from rpmfusion-nonfree requires 
mesa-dri-drivers(x86-32), but none of the providers can be installed
  - mesa-dri-drivers-23.2.0~rc2-3.fc39.i686 from updates-testing-modular  does not belong 
to a distupgrade repository
  - mesa-dri-drivers-23.2.0~rc2-3.fc39.i686 from fedora  does not belong to a distupgrade 
repository
  - package mesa-dri-drivers-23.2.0~rc2-3.fc39.x86_64 from fedora requires 
mesa-filesystem(x86-64) = 23.2.0~rc2-3.fc39, but none of the providers can be installed
  - package mesa-dri-drivers-23.2.0~rc2-3.fc39.x86_64 from 

Warning: DNF is unprotected

[Robert-André Mauchin]

Hello,

Just a heads-up: for the upgrade to DNF5 in F39, we unprotected the DNF package, which 
leaves all of our users vulnerable to a removal of DNF.


And since the delaying of DNF5, we haven't re-protected it.

https://github.com/rpm-software-management/dnf/commit/352b174a0b4ce2048ef1a25b785f20449e2addc2

On a F38 system:
$ cat /etc/dnf/protected.d/dnf.conf
# DNF is obsoleted in Fedora 39 by DNF 5 and should no longer be marked as 
protected.

# dnf

We have one affected user here: https://bsd.network/@claudiom/110944941506724767


I've filed:

https://github.com/rpm-software-management/dnf/issues/1982

If anyone can fix this quickly, that would be neat. I'm not sure if the config(noreplace) 
should be brought back in the SPEC so I leave this to the specialists.


Thanks.

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

Re: RPM packaging help

[Robert-André Mauchin]

On 8/13/23 17:30, Andrew Heath wrote:

Robert,
Thank you,  this is very helpful, so I guess the questions I have is if I'm reading 
your email correctly


1. Is for now we need to deal with the vendor directory, but should start working to 
packaging some of the go-lang dependencies as rpms?




You should make review requests with the SPEC I provided in my Fedorapeople 
space.

I don't have an ETA on the K8S situation.

2. With the bundled vendor directory we have a "functional" build of the rpm that should 
work in theory?




Currently the executable would work cause Golang is statically built. The library is 
disabled cause it probably wouldn't work without unbundling for other projects using it.


Note that I haven't tested none of the executable, I don't know if it needs special config 
or anything else.


Cheers,

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

Re: RPM packaging help

[Robert-André Mauchin]

On 8/10/23 15:43, Andrew Heath wrote:

All,
My name is Andrew, and I have been working with the Fedora Infra team and we are trying to 
create some RPMs for some projects that we are working on, one of the RPMs we need to create 
is for the Ansible receptor[1 ]. I have a copy of the 
spec file from downstream Red Hat that gives some guidance but where its a mix of python and 
go-lang I was wondering if I could have some guidance from more experienced packers on how 
to package up the application correctly so that we can get the package in use for the Fedora 
Infra.


Links:
[1]: https://github.com/ansible/receptor 

--
Sincerely,
Andrew Heath
aheath1...@gmail.com 



Ok, let's roll, you will end up with a Frankstein SPEC, be warned. Here is the 
process:

Let's start with:

$ go2rpm github.com/ansible/receptor --name receptor


We clean up a bit the description, the docs and we got:

# receptor.spec
# Generated by go2rpm 1.9.0
%bcond_without check

# https://github.com/ansible/receptor
%global goipath github.com/ansible/receptor
Version:1.4.1

%gometa -f

%global goname receptor

%global common_description %{expand:
Receptor is an overlay network intended to ease the distribution of work across
a large and dispersed collection of workers. Receptor nodes establish
peer-to-peer connections with each other via existing networks. Once connected,
the Receptor mesh provides datagram (UDP-like) and stream (TCP-like)
capabilities to applications, as well as robust unit-of-work handling with
resiliency against transient network failures.

See the readthedocs page for Receptor at:

https://receptor.readthedocs.io/en/latest}

%global golicenses  LICENSE.md
%global godocs  docs tools README.md

Name:   %{goname}
Release:%autorelease
Summary:Multi-service relayer with remote execution and orchestration 
capabilities

License:Apache-2.0
URL:%{gourl}
Source: %{gosource}

%description %{common_description}

%gopkg

%prep
%goprep
%autopatch -p1
mv receptor-python-worker/README.md README-receptor-python-worker.md
mv receptorctl/README.md README-receptorctl.md


%generate_buildrequires
%go_generate_buildrequires

%build
%gobuild -o %{gobuilddir}/bin/receptor %{goipath}/cmd/receptor-cl

%install
%gopkginstall
install -m 0755 -vd %{buildroot}%{_bindir}
install -m 0755 -vp %{gobuilddir}/bin/* %{buildroot}%{_bindir}/

%if %{with check}
%check
%gocheck
%endif

%files
%license LICENSE.md
%doc docs tools README.md
%{_bindir}/receptor

%gopkgfiles

%changelog
%autochangelog


Let's do a mockbuild on this and see what deps are needed for the Go binary:

$ spectool -g *.spec
$ fedpkg --release f40 mockbuild --mock-config /home/bob/packaging/mock2.cfg -N


Ok I had to make a small detour and send a patch upstream to work with Go 1.21 
with is in F40:

# https://github.com/ansible/receptor/pull/816
Patch:  0001-Bump-quic-go-to-0.37.4.patch


Ok now we have our missing dependencies:

No matching package to install: 'golang(github.com/ghjm/cmdline)'
No matching package to install: 'golang(github.com/jupp0r/go-priority-queue)'
No matching package to install: 'golang(github.com/pbnjay/memory)'
No matching package to install: 'golang(github.com/prep/socketpair)'

rpmname.py github.com/ghjm/cmdline \
   github.com/jupp0r/go-priority-queue \
   github.com/pbnjay/memory \
   github.com/prep/socketpair

We thus need to package these new packages:

golang-github-ghjm-cmdline
golang-github-jupp0r-priority-queue
golang-github-pbnjay-memory
golang-github-prep-socketpair

You need to run go2rpm for each package. I've build them, there is no dependency hell, they 
scratch build ok against Rawhide.


So now, we hit a snag during the build:

# github.com/ansible/receptor/pkg/workceptor
_build/src/github.com/ansible/receptor/pkg/workceptor/kubernetes.go:682:16: 
exec.StreamWithContext undefined (type "k8s.io/client-go/tools/remotecommand".Executor has 
no field or method StreamWithContext)



Our Kubernetes in Fedora is outdated. So we'll need to update it before being able to build 
receptor.


For now we'll take the bundled route, we add a bundled condition, add an archive with 
vendored deps and stuff.


# Generated by go2rpm 1.9.0
%bcond_without check
%bcond_without bundled
%if %{defined rhel}
%bcond_without bundled
%endif

# https://github.com/ansible/receptor
%global goipath github.com/ansible/receptor
Version:1.4.1

%gometa -f

%global goname receptor

%global common_description %{expand:
Receptor is an overlay network intended to ease the distribution of work across
a large and dispersed collection of workers. Receptor nodes establish
peer-to-peer connections with each other via existing networks. Once connected,
the Receptor mesh provides datagram (UDP-like) and stream (TCP-like)

Re: RPM packaging help

[Robert-André Mauchin]

On 8/10/23 15:43, Andrew Heath wrote:

All,
My name is Andrew, and I have been working with the Fedora Infra team and we are trying to 
create some RPMs for some projects that we are working on, one of the RPMs we need to create 
is for the Ansible receptor[1 ]. I have a copy of the 
spec file from downstream Red Hat that gives some guidance but where its a mix of python and 
go-lang I was wondering if I could have some guidance from more experienced packers on how 
to package up the application correctly so that we can get the package in use for the Fedora 
Infra.


Links:
[1]: https://github.com/ansible/receptor 

--
Sincerely,
Andrew Heath
aheath1...@gmail.com 


Hello,

Is the final package for RHEL or Fedora? There are different guidelines regarding bundling I 
believe.


The first issue I see is that there are two separate Python project in two subdirectories. 
Not sure how to handle that.


Could you share the dowstream?

I will look at it tonight/this week-end.

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

Re: List of long term FTBFS packages to be retired this week

[Robert-André Mauchin]

On 8/5/23 12:47, Miro Hrončok wrote:

On 01. 08. 23 23:48, Robert-André Mauchin wrote:

On 7/31/23 12:13, Miro Hrončok wrote:

Dear maintainers.

Based on the current fail to build from source policy, the following packages
should be retired from Fedora 39 approximately one week before branching.

5 weekly reminders are required, hence the retirement will happen
this week.

Policy: 
https://docs.fedoraproject.org/en-US/fesco/Fails_to_build_from_source_Fails_to_install/


The packages in rawhide were not successfully built at least since Fedora 36.

This report is based on dist tags.

Packages collected via:
https://github.com/hroncok/fedora-report-ftbfs-retirements/blob/master/ftbfs-retirements.ipynb

If you see a package that was built, please let me know.
If you see a package that should be exempted from the process,
please let me know and we can work together to get a FESCo approval for that.

If you see a package that can be rebuilt, please do so.

 Package   (co)maintainers



Can you exempt the golang packages for a while more? I'm working on them...


The current list is:

golang-github-burntsushi-xgbutil
golang-github-docker-slim
golang-github-facebookarchive-inject
golang-github-facebookarchive-structtag
golang-github-facebookgo-ensure
golang-github-facebookgo-stack
golang-github-haproxytech-models
golang-gopkg-seborama-govcr-2
golang-gvisor
golang-rsc-qr
golang-sigs-k8s-kustomize
golang-vitess

Branching is in couple days. Should I exempt them still?



The following can be nuked:

golang-github-burntsushi-xgbutil  to retire and then update deepin zhich does 
not use it anymore

golang-github-docker-slim  renamed to https://github.com/slimtoolkit/slim/  Retire then 
rebuild under the new name


golang-github-facebookarchive-inject  Was potentially used for unbundling Grafana but 
not used upstream anymore


golang-github-facebookarchive-structtag   Was potentially used for unbundling Grafana but 
not used upstream anymore


golang-github-facebookgo-ensure   Needed by golang-github-facebookincubator-dhcplb 
which we can update to get rid of it, then leaf to drop


golang-github-facebookgo-stackNeeded by 
golang-github-facebookgo-ensure, to drop

golang-github-haproxytech-models  To retire, was merged into 
github.com/haproxytech/client-native, which is not packaged yet


golang-gopkg-seborama-govcr-2 To retire, we update to 4.5.0 through a new 
package https://pagure.io/releng/fedora-scm-requests/issue/55265



This one is fixed:

golang-rsc-qr

So TL:DR: these still need exemption if possible:

golang-gvisor: I'm currently updating it, but I need to update containerd for it and it's a 
hell of a job


golang-sigs-k8s-kustomize: new deps are needed to fix it

golang-vitess: new deps are needed to fix it

Thank you!

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

Re: List of long term FTBFS packages to be retired this week

[Robert-André Mauchin]

On 7/31/23 12:13, Miro Hrončok wrote:

Dear maintainers.

Based on the current fail to build from source policy, the following packages
should be retired from Fedora 39 approximately one week before branching.

5 weekly reminders are required, hence the retirement will happen
this week.

Policy: 
https://docs.fedoraproject.org/en-US/fesco/Fails_to_build_from_source_Fails_to_install/

The packages in rawhide were not successfully built at least since Fedora 36.

This report is based on dist tags.

Packages collected via:
https://github.com/hroncok/fedora-report-ftbfs-retirements/blob/master/ftbfs-retirements.ipynb

If you see a package that was built, please let me know.
If you see a package that should be exempted from the process,
please let me know and we can work together to get a FESCo approval for that.

If you see a package that can be rebuilt, please do so.

     Package   (co)maintainers



Can you exempt the golang packages for a while more? I'm working on them :


golang-github-burntsushi-xgbutil  eclipseo, go-sig to retire and update 
deepin
golang-github-chifflier-nfqueue   fab, go-sig FIXED
golang-github-cupcake-rdb eclipseo, go-sig FIXED
golang-github-d5-tengo-2  fab, go-sig FIXED
golang-github-docker-slim eclipseo, go-sig renamed to 
https://github.com/slimtoolkit/slim/  Retire then rebuild
golang-github-facebookarchive-inject  agerstmayr, go-sig, mgoodwin, nathans We do not 
need it, leaf, was potentially used for unbundling Grafana but not used upstream anymore
golang-github-facebookarchive-structtag   agerstmayr, go-sig, mgoodwin, nathans We do not 
need it, leaf, was potentially used for unbundling Grafana but not used upstream anymore
golang-github-facebookgo-clockeclipseo, go-sig FIXED Needed by 
golang-github-lestrrat-apache-logformat, needed by golang-github-haproxytech-dataplaneapi. 
Used only for test in golang-github-lestrrat-apache-logformat, could be dropped
golang-github-facebookgo-ensure   dcavalca, go-sig Needed by 
golang-github-facebookincubator-dhcplb which we can update to get rid of it, then leaf to drop
golang-github-facebookgo-stackdcavalca, go-sig Needed by 
golang-github-facebookgo-ensure, drop


TODO

golang-github-ghemawat-stream eclipseo, go-sig
golang-github-gorp-3  dcavalca, go-sig
golang-github-haproxytech-models  bdperkin, go-sig
golang-github-jackc-pgproto3  eclipseo, go-sig
golang-github-jackc-pgservicefile eclipseo, go-sig
golang-github-nkovacs-streamquote eclipseo, go-sig
golang-github-powerman-check  eclipseo, go-sig
golang-github-quay-clair-3eclipseo, go-sig
golang-github-remind101-migrate   eclipseo, go-sig
golang-github-vmware-vmw-guestinfoeclipseo, go-sig
golang-github-zmap-zlint  eclipseo, go-sig
golang-go4eclipseo, go-sig, jchaloup
golang-gopkg-retry-1  eclipseo, go-sig
golang-gopkg-seborama-govcr-2 go-sig, qulogic
golang-gopkg-sourcemap-1  eclipseo, go-sig, jchaloup
golang-gvisor eclipseo, elmarco, go-sig
golang-rsc-qr go-sig, qulogic
golang-sigs-k8s-kustomize dcavalca, go-sig
golang-vitess eclipseo, go-sig
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: JPEGXL SONAME Bump

[Robert-André Mauchin]

On 3/19/23 12:56, Sérgio Basto wrote:

BTW add me (sergiomb) as co-maintainer (admin) for built libjxl for
EPEL 8

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




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

JPEGXL SONAME Bump

[Robert-André Mauchin]

Hello everyone,

I am planning a soname bump of jpegxl to 0.8.1 next week Saturday the 25th.

Some of you will be affected by these changes.

Fedora side we have:

geeqie
gthumb
seamonkey
vips

I can take care of these one as a PP  in a side tag

RPMFusion side, the following packages are affected:

libheif
xine-lib

I would like to have RPMFusion maintainers help to be able to update them in a RPMFusion 
side tag too. I will specify to you when the Fedora side tag has been merged.


Hopefully, with your cooperation, everything will go smoothly.

Please send any question you may have regarding this change.

Thanks to everyone!

Best regards,

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

(Golang) Reviews swap pretty please

[Robert-André Mauchin]

Hello,

I need help to review the ORAS stack needed for Ariga and others:

https://bugzilla.redhat.com/show_bug.cgi?id=2140707 Review Request: 
golang-github-need-being-tree - Pretty print trees in Go
https://bugzilla.redhat.com/show_bug.cgi?id=2140708 Review Request: golang-oras - Work with 
OCI registries, but for secure supply chain
https://bugzilla.redhat.com/show_bug.cgi?id=2140709 Review Request: golang-oras-2 - ORAS Go 
library
https://bugzilla.redhat.com/show_bug.cgi?id=2140710 Review Request: 
golang-github-oras-project-artifacts-spec - ORAS Artifacts Specification
https://bugzilla.redhat.com/show_bug.cgi?id=2140712 Review Request: golang-oras-1 - ORAS Go 
library



They've been built on COPR: 
https://copr.fedorainfracloud.org/coprs/eclipseo/gotests2/builds/

Feel free to send reviews my way in exchange.

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

Re: Non-responsive maintainer check for olem

[Robert-André Mauchin]

On 9/22/22 01:10, Maxwell G wrote:

On Fri Sep 2, 2022, Maxwell G via devel wrote:


Sep 2, 2022 5:36:41 AM Fabio Valentini :


Does anybody know whether olem still wants to maintain their Fedora
packages?

I'm fairly sure that they no longer wish to maintain Fedora packages. I
reached out to them about moby-engine and containerd at the end of May,
and they said they no longer have time to maintain them. I have been
maintaining those packages myself for a while.

Side note: I have asked for co-maintainers for those packages a couple
times, but so far, I have not found any. Perhaps one of the CoreOS people
would be interested? It seems those packages are used a lot there based
on the bug reports we've gotten.


It looks like the nonresponsive maintainer process is going to proceed.
I've done some analysis of the Go packages that will be orphaned so the
Go SIG can figured out how to handle this. This was done by hand, so
please excuse any errors.

The following packages are dependencies of golang-github-docker{,-cli} and/or
containerd:

1. golang-github-hanwen-fuse
2. golang-github-fvbommel-sortorder
3. golang-github-containerd-nri
4. golang-github-moby-locker
5. golang-github-moby-term
6. golang-github-tonistiigi-rosetta
7. golang-github-google-containerregistry
8. golang-github-containerd-stargz-snapshotter (FTBFS)

9. golang-github-kyokomi-emoji is a dependency of hugo

olem also maintained open-policy-agent and some of its
dependencies:

- open-policy-agent
- golang-github-yashtewari-glob-intersection (open-policy-agent is the only 
dependent)
- golang-uber-automaxprocs (dependency of both open-policy-agent and
   clash)

This maintainer also maintained golang-github-jsonnet-bundler and
golang-github-containerd-cni. These packages are leaves. I sent a
separate message to the golang list about retiring these. I suppose we
could just wait for it to happen automatically.

Many of these libraries are out of date, but only one of them FTBFS
(according to Koschei), which I'd consider pretty good. Updating these
packages will likely require packaging a bunch of new dependencies. I
think eclipseo has been doing some work on the docker side of things,
though. Thanks for that!

I have been keeping containerd and moby-engine up to date. moby-engine
could use a cleanup. Currently, docker-proxy
(github.com/moby/libnetwork), docker-init (bundled tini-static), dockerd
(github.com/moby/moby), and the docker cli (github.com/docker/cli) are
all part of the moby-engine package. This makes the specfile rather
cumbersome. Ideally, it should be split up. I just haven't had the time
to do so. docker cli should be straightforward.
github.com/moby/libnetwork will soon be merged into
github.com/moby/moby, so docker-proxy doesn't make sense to split out
right now. For docker-init, we should investigate whether we could
configure docker to look for the existing tini-static binary or at least
create a symlink. It expects the binary to be installed to
%{_libexecdir}/docker/docker-init. I am really not a fan of the bundled
tini-static.

--
Best,

Maxwell G (@gotmax23)
Pronouns: He/Him/His


Hi,

I can take care of all the Docker deps since I am in the process of updating 
them.

Best regards,

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

Re: Donate 1 minute of your time to test upgrades from F36 to F37

[Robert-André Mauchin]

On 9/12/22 14:59, Miroslav Suchý wrote:

Do you want to make Fedora 37 better? Please spend 1 minute of your time and 
try to run:

# Run this only if you use default Fedora modules
# next time you run any DNF command default modules will be enabled again
sudo dnf module reset '*'

dnf --releasever=37 --setopt=module_platform_id=platform:f37 \
--enablerepo=updates-testing \
$(rpm -q fedora-repos-modular >/dev/null && echo 
--enablerepo=updates-testing-modular) \
--assumeno distro-sync


This command does not replace `dnf system-upgrade`, but it will reveal 
potential problems.

You may also run `dnf upgrade` before running this command.


The `--assumeno` will just test the transaction, but does not make the actual 
upgrade.


In case you hit dependency issues, please report it against the appropriate 
package.

Or against fedora-obsolete-packages if that package should be removed in Fedora 37. Please 
check existing reports against


fedora-obsolete-packages first:

https://red.ht/2kuBDPu

and also there is already bunch of "Fails to install" (F37FailsToInstall) 
reports:

https://bugzilla.redhat.com/buglist.cgi?bug_id=2045109_id_type=anddependson=tvp_id=12486533

Thank you

Miroslav


Hello,

I've got no issue running this command, but when I try to do the actual update, 
I get

Error: Transaction test error:
  file /usr/bin/WebKitWebDriver from install of webkit2gtk4.1-2.37.91-1.fc37.x86_64 
conflicts with file from package webkit2gtk3-2.38.0-2.fc36.x86_64


Has anyone encountered the same issue?

Best regards,

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

Re: Heads-up: ODE soname bump

[Robert-André Mauchin]

On 7/24/22 16:40, Hedayat Vatankhah wrote:

Hi all,

As part of building ODE 0.16, ode's soname has been bumped from 
libode.so.4/libode-double.so.4  to libode.so.8/libode-double.so.8.


This package is now built as part of Fedora 37 Mass Rebuild, so we expect all dependent 
packages to be automatically built again during this process.


We do not expect to see compilation failures because of this update.


Regards,

Hedayat



Use (Close: rhbz#1438205) instead of (rhbz#1438205)
or Closes: rhbz#1438205, Fix: rhbz#1438205, Fixes: rhbz#1438205
to automatically close the related nug

On 7/24/22 19:14, Maxwell G via devel wrote:
> On 22/07/24 06:05PM, Kalev Lember wrote:
>> If ODE 0.16 was only built as part of the mass rebuild and wasn't
>> available in the buildroot during the mass rebuild (and I don't think
>> it was), then all the other packages that depend on it were still
>> built against the older ODE 0.14 version as part of the mass rebuild.
>> Once the mass rebuild is merged back into f37 then all other packages
>> that depend on ODE are going to have broken dependencies.
>
> That indeed appears to be the case. The f37-rebuild build target[1]
> builds against f37-build but tags completed builds into f37-rebuild.
> ode-0.16.2-2.fc37[2] is only tagged into f37-rebuild.
>
> [1]: https://koji.fedoraproject.org/koji/buildtargetinfo?targetID=24581
> [2]: https://koji.fedoraproject.org/koji/buildinfo?buildID=2016899
>
> Also, looking at ompl, one of ode's dependents, you can see that it was
> rebuilt against the old version of ode:
>
>> DEBUG util.py:445:   ode-devel  x86_64  0.14-15.fc36 
   build   66 k

>
> -- 
https://kojipkgs.fedoraproject.org//packages/ompl/1.5.0/11.fc37/data/logs/x86_64/root.log and
> 
https://koji.fedoraproject.org/koji/buildinfo?buildID=2016925https://koji.fedoraproject.org/koji/buildinfo?buildID=2016925

>
> In order to fix this, a provenpackager will need to build all of the
> dependents in a sidetag like normal. Preferably, this could happen
> before the mass rebuild tag is merged back into f37. I am a bit busy
> today, but I suppose I could do this later if nobody beats me to it.
>

It is done: https://bodhi.fedoraproject.org/updates/FEDORA-2022-26df2fedba

Had to fixup freewrl though, the java thing on i686.

Best regards,

Robert-André
___
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 SCM requests on the weekend

[Robert-André Mauchin]

Hello,

I know a lot of you are working on Fedora during the week days, but for some of us, the 
weekend is the only time we can spend time on it. The problem is, SCM requests are rarely 
processed during that time, most of them get stuck from Friday afternoon to Monday afternoon 
(CEST), so it really hampers my work. Would it be possible for a volunteer to agree to do it 
on the weekend.


Best regards,

Robert-André
___
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

Looking for 2 review swaps

[Robert-André Mauchin]

Hi,

I'm looking to get review of these two packages:

#2103380 NEW- nob...@fedoraproject.org - Review Request: rust-cradle - Execute child 
processes with ease https://bugzilla.redhat.com/show_bug.cgi?id=2103380


which depends on:

#2103367 NEW- nob...@fedoraproject.org - Review Request: rust-gag - Redirect, or 
hold stdout/stderr output https://bugzilla.redhat.com/show_bug.cgi?id=2103367


Can do anything in exchange.

Best regards,

Robert-André
___
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: Meld directory compare still broken in f36

[Robert-André Mauchin]

On 6/24/22 10:49, Andrea Musuruane wrote:

Hi,
     meld directory compare in f36 is broken.

I opened a bug report last month:
https://bugzilla.redhat.com/show_bug.cgi?id=2091377 



Some days later, kiilerix provided a PR to fix this issue:
https://src.fedoraproject.org/rpms/meld/pull-request/6 



The PR has been accepted but a new package hasn't been build.

Can the packager or a proven packager please do this?

Thanks,

Andrea




Hi,
I've built it for you: 
https://bodhi.fedoraproject.org/updates/FEDORA-2022-8dc172c1f4

Best regards,

Robert-André
___
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: release-monitoring.org 1.4.0 is now live

[Robert-André Mauchin]

On 6/22/22 17:36, Michal Konecny wrote:

Hi everyone,

today was deployed 1.4.0 version of https://release-monitoring.org.
Here is a highlight of some of the changes:

*Features*
* Add link to AlmaLinux package to distribution mapping
* Add sourceforge (git) backend to retrieve git tags
* Add Python (PEP 440) versioning scheme

*Bug fixes*
* Only include unyanked PyPI versions
* Version Filter not applied on Test Check
* Intermediate versions are skipped while update checking

For full changelog please visit 
https://github.com/fedora-infra/anitya/releases/tag/1.4.0

Regards,
Michal


Thanks a lot for your work Michal!
___
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: Media codecs big SONAME bump

[Robert-André Mauchin]

On 6/20/22 13:08, Robert-André Mauchin wrote:

Hello everyone,

I am planning a soname bump of various media codecs I take care of. In order to minimize the 
rebuilds, all are going through in a single update.


The codecs I plan to bump are the following:

  - AOM
  - libavif
  - dav1d
  - rav1e
  - svt-av1
  - jpegxl

Many of you will be affected by these changes.

Fedora side we have:

gd <- priority because of graphviz/doxygen connection (libavif bump)
baresip (aom bump)
darktable (libavif bump)
efl (libavif bump)
ffmpeg (aom, dav1d, rav1e, svt-av1 bump)
geeqie (jpegxl bump)
gstreamer1-plugins-bad-free (aom bump)
gthumb (jpegxl bump)
kf5-kimageformats (libavif bump)
plasma-wallpapers-dynamic (libavif bump)
seamonkey  (aom, dav1d, jpegxl bump)
vips (jpegxl bump)

I can take care of these one as a PP, but since the whole thing is happening in a side tag 
(f37-build-side-54562), I would ask you to please refrain to update these packages until the 
side tag is merged.


So the packages have been rebuilt in a side tag, and I'm about to merge that side tag 
(f37-build-side-54562).


–> https://bodhi.fedoraproject.org/updates/FEDORA-2022-a778fab5d7



RPMFusion side, the following packages are affected:

HandBrake (dav1d bump)
avidemux (aom bump)
cinelerra-gg (aom, libavif bump)
compat-ffmpeg4 (aom, dav1d, rav1e, svt-av1 bump)
ffmpeg (aom, dav1d, rav1e, svt-av1 bump)
kodi (dav1d bump)
libheif (dav1d, rav1e, jpegxl bump)
vlc (aom, dav1d bump)
xine-lib (aom, dav1d, jpegxl bump)

I would like to have RPMFusion maintainers help to be able to update them in a RPMFusion 
side tag too. I will specify to you when the Fedora side tag has been merged.




*** RPMFusion Team: ***

Once the Fedora side tag is merged, the following builds should be buildroot overrided in 
RPMFusion:


libavif-0.10.1-1.fc37
dav1d-1.0.0-1.fc37
svt-av1-1.1.0-1.fc37
rust-rav1e-0.5.1-1.fc37
aom-3.4.0-1.fc37
jpegxl-0.7.0~pre1-0.1.0~sonamebump.fc37
highway-0.17.0-1.fc37

I don't think I can create a side tag by myself on RPMFusion, so I'd like to 
ask for one please.

I have already prepared the bumpspec, all I need is to push them as a PP, then use the 
provided side-tag to rebuild them.


Thank you for your help.

Best regards,

Robert-André (eclipseo)
___
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: Self Introduction: Kate Hsuan

[Robert-André Mauchin]

On 6/21/22 07:42, Kate Hsuan wrote:

Hi Folks,

My name is Kate Hsuan. I'm a software engineer from Red Hat.

Currently, I'm working on integration with fwupd, gnome-shell, and
gnome settings. They can be used to show the firmware security details
and warnings to the user to reduce the risk of the security event.
Before joining Red Hat, I'm working on ONAP DCAE project. ONAP is an
open-source network automation framework for the telecom industry. We
had developed a microservice to collect every message from the message
bus for analysis to find the abnormal events.

Now, I am going to work on package maintenance for libusb, libusb1,
and libusb-compat.

Thank you :)



Welcome! Glad to have you on board!

Best regards,

Robert-André (eclipseo)
___
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

Media codecs big SONAME bump

[Robert-André Mauchin]

Hello everyone,

I am planning a soname bump of various media codecs I take care of. In order to minimize the 
rebuilds, all are going through in a single update.


The codecs I plan to bump are the following:

 - AOM
 - libavif
 - dav1d
 - rav1e
 - svt-av1
 - jpegxl

Many of you will be affected by these changes.

Fedora side we have:

gd <- priority because of graphviz/doxygen connection (libavif bump)
baresip (aom bump)
cinelerra-gg (aom, libavif bump)
darktable (libavif bump)
efl (libavif bump)
ffmpeg (aom, dav1d, rav1e, svt-av1 bump)
geeqie (jpegxl bump)
gstreamer1-plugins-bad-free (aom bump)
gthumb (jpegxl bump)
kf5-kimageformats (libavif bump)
plasma-wallpapers-dynamic (libavif bump)
seamonkey  (aom, dav1d, jpegxl bump)
vips (jpegxl bump)

I can take care of these one as a PP, but since the whole thing is happening in a side tag 
(f37-build-side-54562), I would ask you to please refrain to update these packages until the 
side tag is merged.


RPMFusion side, the following packages are affected:

HandBrake (dav1d bump)
avidemux (aom bump)
compat-ffmpeg4 (aom, dav1d, rav1e, svt-av1 bump)
ffmpeg (aom, dav1d, rav1e, svt-av1 bump)
kodi (dav1d bump)
libheif (dav1d, rav1e, jpegxl bump)
vlc (aom, dav1d bump)
xine-lib (aom, dav1d, jpegxl bump)

I would like to have RPMFusion maintainers help to be able to update them in a RPMFusion 
side tag too. I will specify to you when the Fedora side tag has been merged.


Hopefully, with your cooperation, everything will go smoothly.

Please send any question you may have regarding this change.

Thanks to everyone!

Best regards,

Robert-André (eclipseo)
___
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: List of long term FTBFS packages to be retired in March

[Robert-André Mauchin]

On 2/3/22 17:39, Miro Hrončok wrote:

On 02. 02. 22 17:36, Michael J Gruber wrote:

Still the same fallout from that rage quit ...


Do we have @nim on record saying they are no longer interested in 
maintaining their Fedora packages? If so, I'd like to get them orphaned, 
so we know where are the problematic packages before we have problems.




I haven't been able to contact him for over a year for Golang related 
activities. I don't think he is interested in this anymore or he doesn't 
have the time to do so.

___
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: Why was node_exporter.service renamed to prometheus-node-exporter.service?

[Robert-André Mauchin]

On 1/28/22 14:18, Barry Scott wrote:




On 28 Jan 2022, at 12:28, Tomasz Torcz  wrote:

On Fri, Jan 28, 2022 at 12:01:43PM +, Barry Scott wrote:

I just had to fix a number of my servers that use node exporter.

The service name has been changed. Why was this done and did no one
think about the impact on users?


  This was done here:
  
https://src.fedoraproject.org/rpms/golang-github-prometheus-node-exporter/c/5ad49dd6ed767d44070866d996d844dec4b5f07b?branch=f35

  as part of the fix for
  https://bugzilla.redhat.com/show_bug.cgi?id=2039257
  (golang-github-prometheus-node-exporter installs service unit in /etc)

  Moving the unit is fine, but rename should not happen stable release.
At least some compat symlinks/Alias= should be provided.


In the worst case I had a server fail to reboot because I had
Requires=node_exporter.service in the default target.


  It is unfortunate. It is also unfortunate no-one cared enough about
node-exporter to have it tested during 2 weeks time
(https://bodhi.fedoraproject.org/updates/FEDORA-2022-e52d3d8db2)
before it was submitted to stable.


I guess what is surprising me is that it's a breaking change and that was not
noticed in review or dev testing.

I have now updated golong-github-prometheus that has more breaking changes to 
handle.

The change in the way that .service file handles arguments is welcome.
But its not compatible with the previous .service files handling.

Barry


Hello,

I'm sorry, this is entirely my fault. I provided symlinks for the 
binaries, but didn't think of the systemd unit files symlinks. The 
services files were added or modified to take into account environment 
files which were requested multiple times, and without which the package 
were basically unusable. The binary were renamed to provide 
commonalities with other distro.
Alert manager service was added, Node exporter and Prometheus were 
fixed. There should not be any breaking change for Prometheus though, 
the only thing added was the Environment file.
I will seek co-maintainers for these packages as I initially packaged 
them to be used as dependency for other projects but I never intended to 
be maintainer of the services, which are a bit out of my depth.
I will be pushing an update for node-exporter with a service symlink for 
the old name.

___
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

Selinux slow / How to disable selinux labeling from SPEC Was: 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é



Thanks to Panu, it has been determined that the install process of 
papirus-icon-theme spends most of its time labeling the 100,000 files.
Installing the rpm with rpm -i --nocontexts makes it happen in a 
reasonable time.

Is there a way to bypass this step from within the SPEC itself?
It started to happen around F35, do you think I should try to raise a 
bug with SELinux? I don't know how to diagnose this better.


Any input appreciated.

Best regards,

Robert-André
___
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: 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:52, Tom Hughes wrote:


Do you have the nosync plugin enabled in your mock? That
will shim system calls that try and sync to disk and suppress
the actual sync in the name of greater performance.

Tom



I don't think so, my config is

config_opts['chroothome'] = '/builddir'
config_opts['basedir'] = '/var/lib/mock'
config_opts['rpmbuild_timeout'] = 86400
config_opts['chroot_setup_cmd'] = 'install @buildsys-build pigz lbzip2'
config_opts['target_arch'] = 'x86_64'
config_opts['legal_host_arches'] = ('x86_64',)
config_opts['root'] = 'f36-candidate-x86_64'
config_opts['extra_chroot_dirs'] = [ '/run/lock', ]
config_opts['package_manager'] = 'dnf'
config_opts['use_bootstrap'] = True
config_opts['environment']['LANG'] = 'C.UTF-8'
config_opts['releasever'] = '36'
config_opts['rpmbuild_networking'] = False
config_opts['use_host_resolv'] = False
config_opts['dynamic_buildrequires'] = True
config_opts['dynamic_buildrequires_max_loops'] = 10

config_opts['plugin_conf']['root_cache_enable'] = True
config_opts['plugin_conf']['yum_cache_enable'] = True
config_opts['plugin_conf']['ccache_enable'] = True

config_opts['macros']['%_host'] = 'x86_64-koji-linux-gnu'
config_opts['macros']['%_host_cpu'] = 'x86_64'
config_opts['macros']['%vendor'] = 'Koji'
config_opts['macros']['%distribution'] = 'fc36'
config_opts['macros']['%_topdir'] = '/builddir/build'
config_opts['macros']['%_rpmfilename'] = 
'%%{NAME}-%%{VERSION}-%%{RELEASE}.%%{ARCH}.rpm'

config_opts['macros']['%packager'] = 'Koji'

config_opts['plugin_conf']['package_state_enable'] = False
config_opts['plugin_conf']['ccache_opts']['compress'] = True
config_opts['plugin_conf']['root_cache_opts']['compress_program'] = "pigz"
config_opts['macros']['%__gzip'] = '/usr/bin/pigz'
config_opts['macros']['%__bzip2'] = '/usr/bin/lbzip2'


config_opts['yum.conf'] = """
[main]
keepcache=1
debuglevel=2
reposdir=/dev/null
logfile=/var/log/yum.log
retries=20
obsoletes=1
gpgcheck=0
assumeyes=1
syslog_ident=mock
syslog_device=
install_weak_deps=0
metadata_timer_sync=8
metadata_expire=8
mdpolicy=group:primary
best=1
module_platform_id=platform:f36
fastestmirror=1
max_parallel_downloads=8
___
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

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

[Robert-André Mauchin]

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!

Best regards,

Robert-André
___
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: Failure on the koji f36-rebuild target: /usr/bin/ld: cannot open linker script file /builddir/build/BUILD/.package_note...: No such file or directory

[Robert-André Mauchin]

On 1/22/22 15:50, Marcin Dulak wrote:
> /usr/bin/ld: cannot open linker script file 
/builddir/build/BUILD/.package_note-ga-5.7.2-8.fc36.x86_64.ld: No such


This is a widespread known issue. Aledgedly fixed but I don't think it is.
Refer to this bug https://bugzilla.redhat.com/show_bug.cgi?id=2043178 
for more information.


Best regards,

Robert-André
___
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: Build failure in Clementine due to GCC 12

[Robert-André Mauchin]

On 1/21/22 22:55, Jonathan Wakely wrote:

On Fri, 21 Jan 2022 at 17:42, Jonathan Wakely  wrote:


On Fri, 21 Jan 2022 at 16:37, Robert-André Mauchin  wrote:


On 1/21/22 14:46, Robert-André Mauchin wrote:

Hello,

So I built Clementine last week with no issue, but it failed during
the mass rebuild with the folloing error:

In file included from 
/builddir/build/BUILD/Clementine-0be314337d5bbd6fc7f5c76c31d7b87e37ba3a04/src/core/tagreaderclient.h:29,
from 
/builddir/build/BUILD/Clementine-0be314337d5bbd6fc7f5c76c31d7b87e37ba3a04/src/core/tagreaderclient.cpp:21:
/builddir/build/BUILD/Clementine-0be314337d5bbd6fc7f5c76c31d7b87e37ba3a04/ext/libclementine-common/core/workerpool.h:
 In instantiation of 'WorkerPool::WorkerPool(QObject*) [with HandlerType 
= AbstractMessageHandler]':
/builddir/build/BUILD/Clementine-0be314337d5bbd6fc7f5c76c31d7b87e37ba3a04/src/core/tagreaderclient.cpp:40:52:
required from here
/builddir/build/BUILD/Clementine-0be314337d5bbd6fc7f5c76c31d7b87e37ba3a04/ext/libclementine-common/core/workerpool.h:168:55:
 error: passing 'QString' as 'this' argument discards qualifiers [-fpermissive]
 168 |   local_server_name_ = qApp->applicationName().toLower();
 |   ^
In file included from /usr/include/qt5/QtCore/qhashfunctions.h:44,
from /usr/include/qt5/QtCore/qlist.h:47,
from /usr/include/qt5/QtCore/qstringlist.h:41,
from /usr/include/qt5/QtCore/QStringList:1,
from 
/builddir/build/BUILD/Clementine-0be314337d5bbd6fc7f5c76c31d7b87e37ba3a04/src/core/tagreaderclient.h:26:
/usr/include/qt5/QtCore/qstring.h:510:31: note:   in call to 'QString 
QString::toLower() &&'
 510 | Q_REQUIRED_RESULT QString toLower() &&
 |   ^~~


Nothing stands up to me in the linked code:

template 
WorkerPool::WorkerPool(QObject* parent)
  : _WorkerPoolBase(parent), next_worker_(0), next_id_(0) {
worker_count_ = qBound(1, QThread::idealThreadCount() / 2, 2);
local_server_name_ = qApp->applicationName().toLower();

if (local_server_name_.isEmpty()) local_server_name_ = "workerpool";
}


Anyone knows if a flag, or compiler, has changed since last week? Or have any 
input at all?

Best regards,

Robert-André


So the problem is specific to GCC 12 but I can't find anything in the changelog 
related to this.
It seems toLower() takes a const as input and qApp->applicationName() is not a 
const.


No, you have it backwards.

QString::toLower() && can only be called on a non-const rvalue, and
applicationName() is apparently returning a const object.



I solved by replacing
local_server_name_ = qApp->applicationName().toLower();
to
local_server_name_ = QString(qApp->applicationName()).toLower();


This creates an rvalue, which allows the call to toLower().


Still I would love for a GCC specialist to point me to the relevant change in 
GCC 12 so I can
send a patch upstream with explanation for the change.


The Qt code has two overloads:

 Q_REQUIRED_RESULT QString toLower() const &
 { return toLower_helper(*this); }
 Q_REQUIRED_RESULT QString toLower() &&
 { return toLower_helper(*this); }

For some reason, the second one is being used when it should be the first.

I don't think this is a GCC change though.


I was wrong, this is a weird GCC overload resolution bug:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104173



Thanks so much for looking it up!
___
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)

[Robert-André Mauchin]

On 10/25/21 21:09, Ben Cotton wrote:

https://fedoraproject.org/wiki/Changes/Package_information_on_ELF_objects

== Summary ==
All binaries (executables and shared libraries) are annotated with an
ELF note that identifies the rpm for which this file was built. This
allows binaries to be identified when they are distributed without any
of the rpm metadata. `systemd-coredump` uses this to log package
versions when reporting crashes.

== Owner ==
* Name: [[User:Zbyszek|Zbigniew Jędrzejewski-Szmek]]
* Email: zbys...@in.waw.pl
* Name: Lennart Poettering
* Email: mzsrq...@0pointer.net


== Detailed Description ==
People mix binaries (programs and libraries) from different
distributions (for example using Fedora containers on Debian or vice
versa), and distribute binaries without packaging metadata (for
example by stripping everything except the binary from a container
image, also removing `/usr/lib/.build-id/*`), compile their own rpm
packages (for internal distribution and installation), and compile and
distribute their own binaries. Sometimes we need to introspect a
binary and figure out its provenance, for example when a program
crashes and we are looking at a core dump, but also when we have a
binary without the packaging metadata. When the need to introspect a
binary arises, we have some very good mechanisms to show the
provenance: when a file is installed through the package manager we
can directly list the providing package, but even without this we can
use build-ids embedded in the binary to uniquely identify the
originating build. But those mechanisms work best when we're in the
realm of a single distribution. In particular, build-ids can be easily
tied to a source rpm, but only when we have the source rpm is part of
the distribution and the build-id was registered in the appropriate
database which maps build-ids to real package names. When we move
outside of the realm of a single distribution, it can be hard to
figure out where a given binary originates from. If we know that a
binary is from a given distribution, we may be able to use some
distro-specific mechanism to figure out this information. But those
mechanisms will be different for different distributions and will
often require network access. With this change we aim to provide a
mechanism that is is very simple, provides a "human-readable" origin
information without further processing, is portable across distros,
and works without network access.

The directly motivating use case is display of core dumps. Right now
we have build-ids, but those are just opaque hexadecimal numbers that
are not meaningful to users. We would like to immediately list
versions of packages involved in the crash (including both the program
and any libraries it links to). It is not enough to query the rpm
database to do the equivalent of `rpm -qf …`: very often programs
crash after some packages have been upgraded and the binaries loaded
into memory are not the binaries that are currently present on disk,
or when through some mishap, the binaries on disk do not match the
installed rpms.  A mechanism that works without rpm database lookup or
network access allows this information to be showed immediately in
`coredumpctl` listings and journal entries about the crash. This
includes crashes that happen in the initrd and sandboxed containers.

A second motivating use case is when users distribute their own
binaries and would like to collect crash information. Build-ids are a
solution that is technically possible, but easy to get wrong in
practice: users would need to immediately record the build-id after
the build and store the mapping to program names, versions, and build
number in some database. It's much easier to be able to record
something during the build in the build product itself.

A third motivating use case is the general mixing of Fedora binaries
with programs and libraries from different distributions, both with
our binaries being used as the base for foreign binaries, and the
other way around. Whilst most distributions provide some mechanism to
figure out the source build information, those mechanisms vary by
distribution and may not be easy to access from a "foreign" system.
Such mixing is expected with containers, flatpaks, snaps, Python
binary wheels, anaconda packages, and quite often when somebody
compiles a binary and puts it up on the web for other people to
download.

We propose a new mechanism which is designed to be very simple but
extensible: a small JSON document is embedded in an section in the ELF
binary. This document can be easily read by a human if necessary, but
it is also well-defined and can be processed programatically. For
example, `systemd-coredump` will immediately make use of this to
display package ''nevra'' information for crashes. The format is also
easy to generate, so it can be added to any build system, either using
the helpers that we provide or even reimplemented from scratch.

For the case where we mix binaries from different 

Re: Build failure in Clementine due to GCC 12

[Robert-André Mauchin]

On 1/21/22 14:46, Robert-André Mauchin wrote:

Hello,

So I built Clementine last week with no issue, but it failed during
the mass rebuild with the folloing error:

In file included from 
/builddir/build/BUILD/Clementine-0be314337d5bbd6fc7f5c76c31d7b87e37ba3a04/src/core/tagreaderclient.h:29,
   from 
/builddir/build/BUILD/Clementine-0be314337d5bbd6fc7f5c76c31d7b87e37ba3a04/src/core/tagreaderclient.cpp:21:
/builddir/build/BUILD/Clementine-0be314337d5bbd6fc7f5c76c31d7b87e37ba3a04/ext/libclementine-common/core/workerpool.h:
 In instantiation of 'WorkerPool::WorkerPool(QObject*) [with HandlerType 
= AbstractMessageHandler]':
/builddir/build/BUILD/Clementine-0be314337d5bbd6fc7f5c76c31d7b87e37ba3a04/src/core/tagreaderclient.cpp:40:52:
    required from here
/builddir/build/BUILD/Clementine-0be314337d5bbd6fc7f5c76c31d7b87e37ba3a04/ext/libclementine-common/core/workerpool.h:168:55:
 error: passing 'QString' as 'this' argument discards qualifiers [-fpermissive]
    168 |   local_server_name_ = qApp->applicationName().toLower();
    |   ^
In file included from /usr/include/qt5/QtCore/qhashfunctions.h:44,
   from /usr/include/qt5/QtCore/qlist.h:47,
   from /usr/include/qt5/QtCore/qstringlist.h:41,
   from /usr/include/qt5/QtCore/QStringList:1,
   from 
/builddir/build/BUILD/Clementine-0be314337d5bbd6fc7f5c76c31d7b87e37ba3a04/src/core/tagreaderclient.h:26:
/usr/include/qt5/QtCore/qstring.h:510:31: note:   in call to 'QString 
QString::toLower() &&'
    510 | Q_REQUIRED_RESULT QString toLower() &&
    |   ^~~


Nothing stands up to me in the linked code:

template 
WorkerPool::WorkerPool(QObject* parent)
     : _WorkerPoolBase(parent), next_worker_(0), next_id_(0) {
   worker_count_ = qBound(1, QThread::idealThreadCount() / 2, 2);
   local_server_name_ = qApp->applicationName().toLower();

   if (local_server_name_.isEmpty()) local_server_name_ = "workerpool";
}


Anyone knows if a flag, or compiler, has changed since last week? Or have any 
input at all?

Best regards,

Robert-André


So the problem is specific to GCC 12 but I can't find anything in the changelog 
related to this.
It seems toLower() takes a const as input and qApp->applicationName() is not a 
const.

I solved by replacing
local_server_name_ = qApp->applicationName().toLower();
to
local_server_name_ = QString(qApp->applicationName()).toLower();

Still I would love for a GCC specialist to point me to the relevant change in 
GCC 12 so I can
send a patch upstream with explanation for the change.

Thank you.

Robert-André
___
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

Build failure in Clementine: I need help

[Robert-André Mauchin]

Hello,

So I built Clementine last week with no issue, but it failed during
the mass rebuild with the folloing error:

In file included from 
/builddir/build/BUILD/Clementine-0be314337d5bbd6fc7f5c76c31d7b87e37ba3a04/src/core/tagreaderclient.h:29,
  from 
/builddir/build/BUILD/Clementine-0be314337d5bbd6fc7f5c76c31d7b87e37ba3a04/src/core/tagreaderclient.cpp:21:
/builddir/build/BUILD/Clementine-0be314337d5bbd6fc7f5c76c31d7b87e37ba3a04/ext/libclementine-common/core/workerpool.h:
 In instantiation of 'WorkerPool::WorkerPool(QObject*) [with HandlerType 
= AbstractMessageHandler]':
/builddir/build/BUILD/Clementine-0be314337d5bbd6fc7f5c76c31d7b87e37ba3a04/src/core/tagreaderclient.cpp:40:52:
required from here
/builddir/build/BUILD/Clementine-0be314337d5bbd6fc7f5c76c31d7b87e37ba3a04/ext/libclementine-common/core/workerpool.h:168:55:
 error: passing 'QString' as 'this' argument discards qualifiers [-fpermissive]
   168 |   local_server_name_ = qApp->applicationName().toLower();
   |   ^
In file included from /usr/include/qt5/QtCore/qhashfunctions.h:44,
  from /usr/include/qt5/QtCore/qlist.h:47,
  from /usr/include/qt5/QtCore/qstringlist.h:41,
  from /usr/include/qt5/QtCore/QStringList:1,
  from 
/builddir/build/BUILD/Clementine-0be314337d5bbd6fc7f5c76c31d7b87e37ba3a04/src/core/tagreaderclient.h:26:
/usr/include/qt5/QtCore/qstring.h:510:31: note:   in call to 'QString 
QString::toLower() &&'
   510 | Q_REQUIRED_RESULT QString toLower() &&
   |   ^~~


Nothing stands up to me in the linked code:

template 
WorkerPool::WorkerPool(QObject* parent)
: _WorkerPoolBase(parent), next_worker_(0), next_id_(0) {
  worker_count_ = qBound(1, QThread::idealThreadCount() / 2, 2);
  local_server_name_ = qApp->applicationName().toLower();

  if (local_server_name_.isEmpty()) local_server_name_ = "workerpool";
}


Anyone knows if a flag, or compiler, has changed since last week? Or have any 
input at all?

Best regards,

Robert-André
___
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: Unannounced soname bump of libre2

[Robert-André Mauchin]

On 1/9/22 03:29, Kevin Fenzi wrote:

On Sat, Jan 08, 2022 at 11:56:04PM +0900, Mamoru TASAKA wrote:

Miro Hrončok wrote on 2022/01/08 20:05:

On 08. 01. 22 11:39, Miro Hrončok wrote:

The re2 package was updated today in Rawhide and bumped soname from 
libre2.so.0a to libre2.so.9.

https://src.fedoraproject.org/rpms/re2/c/dafa514

Seven packages are broken:

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

fails to build, not sure if re2 related


There is at least a fault on new re2, filed:
https://bugzilla.redhat.com/show_bug.cgi?id=2038572


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

depends on grpc


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

fails to build due to another unrelated fails to install bug


qt5-qtwebengine: https://bugzilla.redhat.com/show_bug.cgi?id=2038551

fails to build, re2 related


Just FYI, the qt5-qtwebengine breakage is breaking rawhide composes
starting today. ;(

kevin



The qt5-qtwebengine does not rebuild with the new libre2. The re2 in the 
chromium source code is from 2019-10-15, but we copy headers file from 
the system version:


%if 0%{?use_system_re2}
# http://bugzilla.redhat.com/1337585
# can't just delete, but we'll overwrite with system headers to be on 
the safe side

cp -bv /usr/include/re2/*.h src/3rdparty/chromium/third_party/re2/src/re2/
%endif

so it breaks with the new version.

The qt5-qtwebengine build does not seem to detect system re2 too:

Running configuration tests...
...
Checking for re2... no
...
Done running configuration tests.
___
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

Are the new guidelines mandatory for new packages?

[Robert-André Mauchin]

Hello,

Are the new Python guidelines mandatory or optional? I mean the whole:

%build
%pyproject_wheel

%install
%pyproject_install
%pyproject_save_files

Or can packagers still use py3_build and py3_install?

Best regards,

Robert-André
___
python-devel mailing list -- python-devel@lists.fedoraproject.org
To unsubscribe send an email to python-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/python-devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: debug_package when using go_generate_buildrequires

[Robert-André Mauchin]

On 12/6/21 12:42, Mikel Olasagasti wrote:

Hi all,

I was updating some golang specs I've and switching them to use
go_generate_buildrequires.

I realized that some specs that are using it fail to build if `%global
debug_package %{nil}` is not set. Same spec with all BuildRequires
defined works just fine.

Example:

- Full spec (go2rpm):
https://mikel.olasagasti.info/tmp/fedora/golang-github-alecaivazis-survey-2.spec
- go_generate_buildrequires spec:
https://raw.githubusercontent.com/mikelolasagasti/github-cli/main/golang-github-alecaivazis-survey-2.spec

- Full spec build: https://koji.fedoraproject.org/koji/taskinfo?taskID=79642572
- go_generate_buildrequires build:
https://koji.fedoraproject.org/koji/taskinfo?taskID=79642147

Is this expected?
Is adding `%global debug_package %{nil}` correct or good practice for
this scenario?

Kind regards,
Mikel Olasagasti (mikelo2)


Hello,

Yes this is an issue I have noticed but I don't know where/what causes it.

I know that if we have a %build section it will cause the debug info to 
be looked for. It does it too with %generate_buildrequires and I think 
it shouldn't, but I don't know if this is a behavior triggered by rpm 
itself or is it triggered somewhere else during the build process?


CC Panu and Devel to weigh in.

In the meantime, as long as you don't have a %build section and thus do 
not produce a binaries, you can use %global debug_package %{nil}


Best regards,

Robert-André
___
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: F35 Change: Switch to WirePlumber as the PipeWire session manage (late Self-Contained Change proposal)

[Robert-André Mauchin]

On 7/19/21 18:17, Ben Cotton wrote:

https://fedoraproject.org/wiki/Changes/WirePlumber

== Summary == PipeWire currently uses a simple example session
manager. This proposal is to move to the more powerful WirePlumber
session manager.

== Owner == * Name: [[User:Wtaymans| Wim Taymans]] * Email:
wim.taym...@gmail.com

== Detailed Description == PipeWire requires a session manager that
at least needs to implements the following features:

* create and configure detected devices in the system. This includes 
audio cards, video and bluetooth devices. * configure applications

and route audio/video to/from them to the devices and filters. * keep
track of prefered devices and volumes. * move audio/video streams
when devices appear and disappear.

PipeWire uses a simple example session manager with limited features 
and configuration options. The proposal is to move to WirePlumber.


WirePlumber is built on GNOME (GObject) technologies and has
bindings for most languages using GObject introspection.

WirePlumber allows one to implement many of the rules for setup and 
configuration using small LUA scripts, which are easier to maintain

and customize. These are some of the functions that are scriptable in
LUA:

* setup and configuration of the devices and streams. This includes 
deciding if devices and streams need to operate in 5.1 or stereo

mode, depending on the available devices. * routing of the streams
based on metadata of the streams (Roles) and overall state of the
system. * volume/mute restore of devices and streams


== Benefit to Fedora ==

PipeWire currently uses a simple example session manager with mostly 
hardcoded logic and rules. This proposal wants to replace the

session manager with a more advanced session manager, called
WirePlumber.

WirePlumber brings to following improvements

* Drop-in replacement session manager for PipeWire, implements the 
exact same features as the example session manager * built with

GObject, which provides a richer development experience and adds
bindings for most languages * extensible with loadable modules *
scriptable policy using small lua scripts * better integration with
desktop settings

The main benefits will be that this session manager would allow for 
more customization of the policy and rules. Initially we aim for

feature parity with the current solution and work on more features in
the next releases.

== Scope == * Proposal owners: This is a rather isolated changed.
Instead of starting the pipewire-media-session executable we would
need to package and start WirePlumber instead.

WirePlumber has been kept up to data with the features in the
example session manager and would need testing.

* Other developers: None. This is an isolated PipeWire change. *
Release engineering: A new systemd service will need to be activated 
in the default install. * 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 == Should not cause any change.

== How To Test ==

Experience should be the same as before. Retest all audio testcases.


== User Experience == Should not cause any visible change.


== Dependencies == None.

== Contingency Plan == * Contingency mechanism: (What to do?  Who
will do it?): If the feature can not be completed we continue using
the existing pipewire-media-session. * Contingency deadline: N/A (not
a System Wide Change) * Blocks release? N/A (not a System Wide
Change)


== Documentation == 
[WirePlumber](https://gitlab.freedesktop.org/pipewire/wireplumber)





Just switched to F35 beta, no sound card was detected, I had to get back
to pipewire-media-session to get sound again.
___
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: Package downgrades from F34 -> F35 (categorized list included)

[Robert-André Mauchin]

On 9/20/21 14:43, Fabio Valentini wrote:

- golang-github-docker-libkv-devel-0:0.2.1-5.fc34 >
golang-github-docker-libkv-devel-0:0.2.1-2.fc35


Might be a bug in rpmautospec, it has reset the Release to 1 when it did 
a build with the bootstrap flag.

___
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: Donate 1 minute of your time to test upgrades from F34 to F35

[Robert-André Mauchin]

On 9/7/21 6:14 PM, Miroslav Suchý wrote:
Do you want to make Fedora 35 better? Please spend 1 minute of your time 
and try to run:


# Run this only if you use default Fedora modules
# next time you run any DNF command default modules will be enabled again
sudo dnf module reset '*'

sudo dnf --releasever=35 --setopt=module_platform_id=platform:f35 \

--enablerepo=updates-testing --enablerepo=updates-testing-modular \

distro-sync

This command does not replace `dnf system-upgrade`, but it will reveal 
potential problems.


You may also run `dnf upgrade` before running this command.


If you get this prompt:

...
Total download size: XXX M
Is this ok [y/N]:

you can answer N and nothing happens, no need to test the actual upgrade.

But very likely you get some dependency problem now. In that case, 
please report it against the appropriate package.




I guess I'm lucky, I didn't get any error except a couple of COPR in 
need of an update.


Best regards,

Robert-André
___
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

JPEG XL license change

[Robert-André Mauchin]

Hi,

JPEG XL license changed from ASL 2.0 to BSD with version 0.5.0.
It will be reflected in the next release.

Best regards,

Robert-André
___
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: After branching F36, under Rawhide I can not build packages for F35 for i386 arch, instead of it mock builded packages for F36.

[Robert-André Mauchin]

On 8/14/21 7:48 PM, Mikhail Gavrilov wrote:

After branching F36, under Rawhide I can not build packages for F35 for i386 
arch, instead of it mock builded packages for F36.
Mock rebuild output: https://pastebin.com/LmQxFBUN



From your log it seems the mock config file "fedora-35-i386.cfg" is 
still symlinked to /etc/mock/fedora-rawhide-i386.cfg. I've checked mine 
and it is the same, it looks like it was not branched yet in 
mock-core-configs.


Sergio opened a bug report yesterday regarding this:
https://github.com/rpm-software-management/mock/issues/762

I've sent a PR:
https://github.com/rpm-software-management/mock/pull/763

Either you wait until all of this is merged and built or you do the 
modifications manually if this is urgent.


Best regards,

Robert-André
___
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: requesting help to update spyder

[Robert-André Mauchin]

On 8/14/21 6:06 PM, Mukundan Ragavan wrote:

Hi,

I am trying to update spyder on rawhide and F35. The main issue I have 
is that pyqt requirements are strict. From the setup file,


'pyqt5<5.13',
'pyqtwebengine<5.13',

Fedora has 5.15.x. If I relax QT versions, built and launch spyder, I 
get this error and spyder fails to launch.


scaled(self, int, int, aspectRatioMode: Qt.AspectRatioMode = 
Qt.IgnoreAspectRatio, transformMode: Qt.TransformationMode = 
Qt.FastTransformation): argument 1 has unexpected type 'float'


scaled(self, QSize, aspectRatioMode: Qt.AspectRatioMode = 
Qt.IgnoreAspectRatio, transformMode: Qt.TransformationMode = 
Qt.FastTransformation): argument 1 has unexpected type 'float'



Spec and patches can be seen here -

https://copr-dist-git.fedorainfracloud.org/cgit/nonamedotc/spyder5dev/spyder.git/tree/ 




Any help to get this sorted out will be greatly appreciated.

Thanks,
Mukundan.


It doesn't seem to be possible until upstream dedicate the time to 
migrate to 5.15: https://github.com/spyder-ide/spyder/issues/12829

___
python-devel mailing list -- python-devel@lists.fedoraproject.org
To unsubscribe send an email to python-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/python-devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: Weird error output when using "git push"

[Robert-André Mauchin]

On 8/12/21 2:36 PM, Richard Shaw wrote:
Now that vigra went stable in f35 I'm trying to build hugin.The git 
merge from rawhide worked fine as usual but when I tried 'git push' I 
get this:


$ git merge rawhide
Updating 88d7c81..69827ac
Fast-forward
  hugin-openexr3.patch | 17 -
  hugin.spec           | 11 ++-
  2 files changed, 26 insertions(+), 2 deletions(-)
[build@hobbes hugin]$ git push
Total 0 (delta 0), reused 0 (delta 0), pack-reused 0
remote: Traceback (most recent call last):
remote:   File 
"/usr/lib64/python3.6/site-packages/sqlalchemy/engine/base.py", line 
2262, in _wrap_pool_connect

remote:     return fn()
remote:   File 
"/usr/lib64/python3.6/site-packages/sqlalchemy/pool/base.py", line 354, 
in connect

remote:     return _ConnectionFairy._checkout(self)
remote:   File 
"/usr/lib64/python3.6/site-packages/sqlalchemy/pool/base.py", line 751, 
in _checkout

remote:     fairy = _ConnectionRecord.checkout(pool)
remote:   File 
"/usr/lib64/python3.6/site-packages/sqlalchemy/pool/base.py", line 483, 
in checkout

remote:     rec = pool._do_get()
remote:   File 
"/usr/lib64/python3.6/site-packages/sqlalchemy/pool/impl.py", line 138, 
in _do_get

remote:     self._dec_overflow()
remote:   File 
"/usr/lib64/python3.6/site-packages/sqlalchemy/util/langhelpers.py", 
line 68, in __exit__

remote:     compat.reraise(exc_type, exc_value, exc_tb)
remote:   File 
"/usr/lib64/python3.6/site-packages/sqlalchemy/util/compat.py", line 
129, in reraise

remote:     raise value
remote:   File 
"/usr/lib64/python3.6/site-packages/sqlalchemy/pool/impl.py", line 135, 
in _do_get

remote:     return self._create_connection()
remote:   File 
"/usr/lib64/python3.6/site-packages/sqlalchemy/pool/base.py", line 299, 
in _create_connection

remote:     return _ConnectionRecord(self)
remote:   File 
"/usr/lib64/python3.6/site-packages/sqlalchemy/pool/base.py", line 428, 
in __init__

remote:     self.__connect(first_connect_check=True)
remote:   File 
"/usr/lib64/python3.6/site-packages/sqlalchemy/pool/base.py", line 630, 
in __connect

remote:     connection = pool._invoke_creator(self)
remote:   File 
"/usr/lib64/python3.6/site-packages/sqlalchemy/engine/strategies.py", 
line 114, in connect

remote:     return dialect.connect(*cargs, **cparams)
remote:   File 
"/usr/lib64/python3.6/site-packages/sqlalchemy/engine/default.py", line 
453, in connect

remote:     return self.dbapi.connect(*cargs, **cparams)
remote:   File 
"/usr/lib64/python3.6/site-packages/psycopg2/__init__.py", line 130, in 
connect
remote:     conn = _connect(dsn, connection_factory=connection_factory, 
**kwasync)
remote: psycopg2.OperationalError: FATAL:  remaining connection slots 
are reserved for non-replication superuser connections

remote:
remote:
remote: The above exception was the direct cause of the following exception:
remote:
remote: Traceback (most recent call last):
remote:   File "hooks/pre-receive", line 48, in 
remote:     run_hook_file(hooktype)
remote:   File 
"/usr/lib/python3.6/site-packages/pagure/hooks/__init__.py", line 531, 
in run_hook_file

remote:     session, repo, user=username, namespace=namespace
remote:   File "/usr/lib/python3.6/site-packages/pagure/lib/query.py", 
line 2865, in _get_project

remote:     return query.one()
remote:   File 
"/usr/lib64/python3.6/site-packages/sqlalchemy/orm/query.py", line 3275, 
in one

remote:     ret = self.one_or_none()
remote:   File 
"/usr/lib64/python3.6/site-packages/sqlalchemy/orm/query.py", line 3244, 
in one_or_none

remote:     ret = list(self)
remote:   File 
"/usr/lib64/python3.6/site-packages/sqlalchemy/orm/query.py", line 3317, 
in __iter__

remote:     return self._execute_and_instances(context)
remote:   File 
"/usr/lib64/python3.6/site-packages/sqlalchemy/orm/query.py", line 3339, 
in _execute_and_instances
remote:     querycontext, self._connection_from_session, 
close_with_result=True
remote:   File 
"/usr/lib64/python3.6/site-packages/sqlalchemy/orm/query.py", line 3354, 
in _get_bind_args

remote:     mapper=self._bind_mapper(), clause=querycontext.statement, **kw
remote:   File 
"/usr/lib64/python3.6/site-packages/sqlalchemy/orm/query.py", line 3332, 
in _connection_from_session

remote:     conn = self.session.connection(**kw)
remote:   File 
"/usr/lib64/python3.6/site-packages/sqlalchemy/orm/session.py", line 
1123, in connection

remote:     execution_options=execution_options,
remote:   File 
"/usr/lib64/python3.6/site-packages/sqlalchemy/orm/session.py", line 
1129, in _connection_for_bind

remote:     engine, execution_options
remote:   File 
"/usr/lib64/python3.6/site-packages/sqlalchemy/orm/session.py", line 
430, in _connection_for_bind

remote:     conn = bind._contextual_connect()
remote:   File 
"/usr/lib64/python3.6/site-packages/sqlalchemy/engine/base.py", line 
2226, in _contextual_connect

remote:     self._wrap_pool_connect(self.pool.connect, None),
remote:   File 

Re: rpmautospec deployment into production

[Robert-André Mauchin]

On 6/16/21 6:03 PM, Nils Philippsen wrote:

Hi everybody,

we've scheduled the rpmautospec plugin to be deployed into production
for tomorrow, from 14:00 UTC on.

This means installing the relevant packages and restarting kojid
processes on the builders, which will restart any tasks which are being
processed at that time, i.e. expect delays for builds in-flight at the
time.

We'll announce when the deployment is done.

Cheers,
Nils



Maybe I'm doing something wrong but the autochangelog does not seem to 
work for me:


The latest commit I pushed:
https://src.fedoraproject.org/rpms/buku/c/dd2d84f9ac02ff6357e239f62e6c4af4da1fdfcf?branch=rawhide

The bodhi update does not pick up that last commit and only show the 
latest entry in the changelog file:


https://bodhi.fedoraproject.org/updates/FEDORA-2021-83bf7dfa10

And the bug number is not picked up and thus not closed.

Am I doing something wrong somewhere?

Best regards,

Robert-André
___
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

A FTBFS on s390x I'd like some advices for

[Robert-André Mauchin]

Hi,

Following the mass rebuild, the package utox stopped building on s390x.
The following test is failing, with a message regarding a memory leak:


+ /usr/bin/ctest --output-on-failure --force-new-ctest-process -j3
Test project /builddir/build/BUILD/uTox-0.18.1/redhat-linux-build
Start 1: test_chatlog
Start 2: test_chrono
1/2 Test #1: test_chatlog .   Passed0.01 sec
2/2 Test #2: test_chrono ..***Failed0.15 sec
Running suite(s): Chrono
=
==2406587==ERROR: LeakSanitizer: detected memory leaks
Direct leak of 24 byte(s) in 1 object(s) allocated from:
#0 0x3ff9e73034d in __interceptor_malloc (/lib64/libasan.so.6+0xb034d)
#1 0x3ff9e584945 in emalloc (/lib64/libcheck.so.0+0x4945)
Indirect leak of 8 byte(s) in 1 object(s) allocated from:
#0 0x3ff9e73034d in __interceptor_malloc (/lib64/libasan.so.6+0xb034d)
#1 0x3ff9e584945 in emalloc (/lib64/libcheck.so.0+0x4945)
SUMMARY: AddressSanitizer: 32 byte(s) leaked in 2 allocation(s).
=
==2406590==ERROR: LeakSanitizer: detected memory leaks
Direct leak of 24 byte(s) in 1 object(s) allocated from:
#0 0x3ff9e73034d in __interceptor_malloc (/lib64/libasan.so.6+0xb034d)
#1 0x3ff9e584945 in emalloc (/lib64/libcheck.so.0+0x4945)
Indirect leak of 8 byte(s) in 1 object(s) allocated from:
#0 0x3ff9e73034d in __interceptor_malloc (/lib64/libasan.so.6+0xb034d)
#1 0x3ff9e584945 in emalloc (/lib64/libcheck.so.0+0x4945)
SUMMARY: AddressSanitizer: 32 byte(s) leaked in 2 allocation(s).
0%: Checks: 2, Failures: 0, Errors: 2

What I am not sure about is if the problem comes from utox itself, or if this
is an issue with libcheck or libasan?
Can someone provide me with some input?

Thanks,

Robert-André
___
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: rpmautospec deployment into production

[Robert-André Mauchin]

On 6/16/21 6:03 PM, Nils Philippsen wrote:

Hi everybody,

we've scheduled the rpmautospec plugin to be deployed into production
for tomorrow, from 14:00 UTC on.

This means installing the relevant packages and restarting kojid
processes on the builders, which will restart any tasks which are being
processed at that time, i.e. expect delays for builds in-flight at the
time.

We'll announce when the deployment is done.

Cheers,
Nils



What is the situation wrt new packages? Should we enforce the use of 
rpmautospec during reviews or is it completely optional?


Best regards,

Robert-André
___
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: rpmautospec deployment into production

[Robert-André Mauchin]

On 6/16/21 6:03 PM, Nils Philippsen wrote:

Hi everybody,

we've scheduled the rpmautospec plugin to be deployed into production
for tomorrow, from 14:00 UTC on.

This means installing the relevant packages and restarting kojid
processes on the builders, which will restart any tasks which are being
processed at that time, i.e. expect delays for builds in-flight at the
time.

We'll announce when the deployment is done.

Cheers,
Nils



I haven't followed the dev of this project closely, is there a guide for 
packagers to explain how it works and how to integrate it to our workflow?


Best regards,

Robert-André
___
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

libavif soname bump

[Robert-André Mauchin]

Hello everyone,

I'm planning a soname bump from 11 to 12 in libavif for version 0.9.2.
The affected packages are:

darktable-3.4.1-3.fc35.x86_64  libavif.so.11()(64bit)
gd-2.3.2-5.fc35.x86_64 libavif.so.11()(64bit)
kf5-kimageformats-5.83.0-1.fc35.x86_64 libavif.so.11()(64bit)

I will rebuild them using my PP.

If anyone has a question regarding this, feel free to leave any input.

Best regards,

Robert-André
___
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: [ELN] Rebuild ordering and side-tag support

[Robert-André Mauchin]

On 6/30/21 2:38 PM, Stephen Gallagher wrote:


In the scenario I'm discussing, we would take those final PackageA and
PackageB from Fedora and have them in the buildroot for the ELN
builds. That would mean that the bootstrap step wouldn't be needed. If
there's a case you know of that this won't work for, I'd really like
to hear it (preferably with real package names).



Ah ok, I didn't know that ELN had already the Fedora packages as a base. 
I thought everything was rebuilt from scratch.


Best regards,

Robert-André
___
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: F35 Change: Golang 1.17 (System-Wide Change proposal)

[Robert-André Mauchin]

On 6/28/21 6:57 PM, Ben Cotton wrote:

https://fedoraproject.org/wiki/Changes/golang1.17

== Summary ==
Rebase of Golang package to upcoming version 1.17 in Fedora 35,
including the rebuild of all dependent packages(the pre-release
version of Go will be used for the rebuild if released version will
not be available at the time of the mass rebuild).

== Owner ==
* Name: [[User:alexsaezm| Alejandro Sáez Morollón]], [[User:Jcajka|
Jakub Čajka]]
* Email: a...@redhat.com, jca...@redhat.com



Won't we have a problem since 1.17 is deprecating the gopath way to use 
Go modules instead. We didn't manage to port our macros to Go modules 
due to Nicolas Mailhot being MIA since last year, and even if we manage 
that, I personally won't have the time to rebuild the entire ecosystem. 
I'm already have problems dealing with all the updates, while taking 
care of the Package Reviews too.

Won't this break our entire Go ecosystem?

Best regards,

Robert-André
___
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: [ELN] Rebuild ordering and side-tag support

[Robert-André Mauchin]

On 6/28/21 5:55 PM, Stephen Gallagher wrote:

Summary: I think we can fix the ELN side-tag rebuild problems and make
the composes more reliable if we change the mechanism for kicking off
rebuilds. I'm soliciting feedback to help identify potential issues
with this proposed approach.



How do you handle packages that need bootstrapping? Several Go packages 
must be built in a certain order with bootstrapping on, on a virgin 
branch. It takes auite a lot of time.


Best regards,

Robert-André
___
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

"The fedora 34 iso/installer still hasn't been updated/is broken since November 2020 to install to MD raid arrays"

[Robert-André Mauchin]

Hello,

Some popular tech youtuber is encountering problems to install Fedora on 
MD raid arrays:


https://twitter.com/tekwendell/status/1408255117506326529

The related bug is https://bugzilla.redhat.com/show_bug.cgi?id=1897350

Is there any thing that can be done to alleviate this issue faster?

Best regards,

Robert-André
___
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: Azure CLI + SDK, side tags, and metapackages

[Robert-André Mauchin]

On 6/18/21 8:19 PM, Major Hayden wrote:

On 6/18/21 1:14 PM, Robert-André Mauchin wrote:

I've started some but more help to review them all would be appreciated.


I am in your debt, Robert-André. Thanks so much!

>
>

It should be all done now.

Best regards,

Robert-André
___
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: Azure CLI + SDK, side tags, and metapackages

[Robert-André Mauchin]

On 6/15/21 10:15 PM, Major Hayden wrote:

On 6/14/21 7:40 AM, Major Hayden wrote:

   3) How should I go about getting these smaller packages reviewed?
  The majority of them are almost identical.


All of the Azure SDK components are up for review[0].

It's a lot to review (about 83 packages), but almost all of them are 
identical except for some differently-formatted READMEs and LICENSE files.


Thanks for any review help that anyone can provide!

[0] 
https://bugzilla.redhat.com/buglist.cgi?list_id=11947658=Python%20Azure%20SDK%20Reviews 




I've started some but more help to review them all would be appreciated.
___
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: RFP: Just

[Robert-André Mauchin]

On 6/17/21 12:50 AM, Casey Rodarmor wrote:

Hi there,

I maintain a command runner, written in Rust:

https://github.com/casey/just

It's very much like make, except a lot nicer, and doesn't have a build
system, so it's just for saving and running commands. It's reasonably
popular, and I wanted to request that it be packaged Fedora, since
although I'm not a Fedora user, there are some users of Just who are.

Just wanted to put the request out there, and note that I'm super
happy to make changes on my end that might make packaging Just easier.

Thanks!

Best,
Casey


So for anyone interested in helping with this, most of the dependencies 
are already packaged in Fedora:


 - two needs to be bumped, rust-strum and rust-strum_macros to 0.21
   I have taken care of that part on F34 and rawhide. Might take a 
while to hit stable on F34.


 - the only remaining dep beside "just" itself is "target" v1.0.0
   https://crates.io/crates/target


This should be super simple to package, any takers?

Best regards,

Robert-André
___
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: Introduction: Trevor McKay

[Robert-André Mauchin]

On 6/16/21 5:11 AM, Trevor McKay wrote:

Hello everyone,

My name is Trevor and I was hoping to contribute to the Fedora project
in the form of packaging. I was told the first step would be to
introduce myself here. I have a few years of Linux experience as well as
Rust, Python and C/C++ development. I am, however, completely new to
packaging and contributing to open-source, so any advice is very much
welcome.

I am interested in packing `bottom`, a package for system monitoring
that I find fairly useful. I'd also be cool with picking up an abandoned
package, if anything is desperately needed. Come to think of it, I would
also like to do some development work, but I figured packaging was a
good start. Anyway, just looking to contribute where I can.

Cheers,
Trevor mcKay


Welcome Trevor, don't hesitate to ask for help o/
___
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: go-rpm-integration and symlinks

[Robert-André Mauchin]

On 6/14/21 7:22 PM, Link Dupont wrote:

I'm attempting to package github.com/rjeczalik/notify[1] as an RPM. This 
package includes a utility function[2] that determines whether a path is a 
symlink, and resolves it to an absolute path. This function clearly has merit, 
as the package is an abstraction wrapper around inotify. There are tests around 
this function that set up symlinks and test whether or not the function 
correctly resolves the symlink redirections. These test functions fail when I 
build the package[3]. It turns out the abstractions created by %goprep that set 
up the _build/src directory hierarchy (including the final symlink in the tree) 
are tripping up the tests that are attempting to resolve symlinks. I replaced 
the symlink at _build/src/github.com/rjeczalik/notify with a properly unpacked 
source directory and ran go-rpm-integration check by hand, and the tests pass. 
If _build/src/github.com/rjeczalik/notify is a symlink, however, the tests are 
failing.

Is there a proper way to manipulate the %goprep macro or tell it to not create 
symlinks? Or, what's the appropriate Fedora RPM go macro way of handling cases 
like this?




You can redefine the goprep macro in your spec by replacing the linking with 
copying:

%define gomkdir(z:i:b:s:kv) %{expand:
%goenv %{-z} %{?-i} %{?-v}
%define mybuilddir  %{?-b*}%{!-b:%{gobuilddir}}
%define mygoipath   %{?-i*}%{!-i:%{currentgoipath}}
%define mysourcedir %{?-s*}%{!-s:%{currentgosourcedir}}
%{!?-k:rm -fr "%{mysourcedir}/vendor"}
if [[ ! -e"%{mybuilddir}/bin" ]] ; then
  install -m 0755 -vd "%{mybuilddir}/bin"
  export GOPATH="%{mybuilddir}:${GOPATH:+${GOPATH}:}%{?gopath}"
fi
if [[ ! -e  "%{mybuilddir}/src/%{mygoipath}" ]] ; then
  install -m 0755 -vd   "%{mybuilddir}/src/%{mygoipath}"
  find "%{mysourcedir}" -not \\( -path "%{mysourcedir}" \\) -and -not \\( -path 
"%{mysourcedir}/_build" -prune \\) -exec cp -a "{}" "%{mybuilddir}/src/%{mygoipath}/" \\;
fi
cd  "%{mybuilddir}/src/%{mygoipath}"
}

Add a comment explaining why you need to do that though.


You will also find that the test "TestRecreated" is flaky, it is sometimes 
successful, sometimes it timeouts:

Testingin: 
/builddir/build/BUILD/notify-135d4685afb9d0fb32e23a065b95cd797cb8a4ee/_build/src
 PATH: 
/builddir/build/BUILD/notify-135d4685afb9d0fb32e23a065b95cd797cb8a4ee/_build/bin:/usr/bin:/bin:/usr/sbin:/sbin:/usr/local/sbin
   GOPATH: 
/builddir/build/BUILD/notify-135d4685afb9d0fb32e23a065b95cd797cb8a4ee/_build:/usr/share/gocode
  GO111MODULE: off
  command: go test -buildmode pie -compiler gc -ldflags " -X github.com/rjeczalik/notify/version.commit=135d4685afb9d0fb32e23a065b95cd797cb8a4ee -X github.com/rjeczalik/notify/version=0.9.2 -extldflags '-Wl,-z,relro -Wl,--as-needed  -Wl,-z,now 
-specs=/usr/lib/rpm/redhat/redhat-hardened-ld  '"

  testing: github.com/rjeczalik/notify
github.com/rjeczalik/notify
--- FAIL: TestRecreated (5.00s)
notify_test.go:192:  First 
notify_test.go:179: /tmp/notify_test-447166328/folder notify.Create
notify_test.go:179: /tmp/notify_test-447166328/folder/file notify.Write
notify_test.go:179: /tmp/notify_test-447166328/folder/file notify.Create
notify_test.go:199:  Second 
notify_test.go:179: /tmp/notify_test-447166328/folder/file notify.Remove
notify_test.go:179: /tmp/notify_test-447166328/folder notify.Remove
notify_test.go:179: /tmp/notify_test-447166328/folder notify.Remove
notify_test.go:179: /tmp/notify_test-447166328/folder notify.Create
notify_test.go:179: /tmp/notify_test-447166328/folder/file notify.Write
notify_test.go:179: /tmp/notify_test-447166328/folder/file notify.Create
notify_test.go:207:  Third 
notify_test.go:179: /tmp/notify_test-447166328/folder notify.Create
notify_test.go:179: /tmp/notify_test-447166328/folder/file notify.Remove
notify_test.go:179: /tmp/notify_test-447166328/folder notify.Remove
notify_test.go:179: /tmp/notify_test-447166328/folder notify.Remove
notify_test.go:184: timed out before receiving event
FAIL
exit status 1
FAILgithub.com/rjeczalik/notify 21.392s


Report it upstream and use this workaround in the meantime:

%if %{with check}
%check
for test in "TestRecreated" \
; do
awk -i inplace '/^func.*'"$test"'\(/ { print; print "\tt.Skip(\"disabled failing 
test\")"; next}1' $(grep -rl $test)
done
%gocheck
%endif


Best regards,

Robert-André
___
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 

Re: aom soname bump

[Robert-André Mauchin]

On 5/18/21 8:25 PM, Robert-André Mauchin wrote:

Hi,

AOM AV1 version 3 has been published a while ago and I am planning to 
update it in Fedora. Due to a CVE affecting versions prior to 2021-04-07 
(CVE-2021-30473), I plan to push this update to ALL STABLE RELEASES:


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

I intend to wait until 3.1.1 which fix a few compilation bugs, and wait 
  for jpeg-xl to be packaged to benefit from the new butteraugli tuning.


Affected packages as follows:

avidemux rpmfusion-free
cinelerra-gg rpmfusion-free
ffmpeg rpmfusion-free
go-avif fedora (should be retired)
gstreamer1-plugins-bad-free fedora
libavif fedora
libheif rpmfusion-free
rust-aom-sys fedora
seamonkey fedora
vlc rpmfusion-free
xine-lib rpmfusion-free


I will rebuild the affected packages using my PP.

Best regards,

Robert-André

p.s.: Leigh, I might need your help not to fuck up the repo in rpmfusion 
like last time (if you explain me your process to keep the branches in 
sync it would be nice).





This process has started on Rawhide / Fedora side.
___
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

Can a package ship with JS code preminified?

[Robert-André Mauchin]

Hi,

I remember the guidelines changed recently regarding js code in 
packages. Should the code be minified in the spec? Even if the minifier 
is not packaged in Fedora (webpack)?


Best regards,

Robert-André
___
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: Seeking advice with rust packing guidelines

[Robert-André Mauchin]

On 6/11/21 6:27 AM, Fabio M. Di Nitto wrote:

Hey everyone,

I have been reading the current guideline here:

https://docs.fedoraproject.org/en-US/packaging-guidelines/Rust/

and for the most it´s pretty clear when packaging a standalone crate / 
rust generated binaries (given this is my very first step into 
understanding rust).


I am currently facing a slightly different challenge as my upstream 
project, a bunch of C shared libraries (also available in Fedora), will 
soon grow rust bindings.


The rust code will be part of the normal upstream tarball / etc. that 
will include at that point a mix of different languages.


The upstream build system already takes care to call into cargo for 
example and I am wondering how the current rust rpm macros are going to 
work with it (or viceversa).


Does anyone have experience in packaging mixed sources?
Could you share your spec file please (or just the srpm name ;))

Thanks
Fabio


I can't really help you, but it would be helpful to link the upstream 
project your are trying to build.

Also CCing the other Fabio who is most up to date with Rust packages.

Best regards,

Robert-André
___
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

Where is system-config-users?

[Robert-André Mauchin]

Hello,

System-config-users
https://src.fedoraproject.org/rpms/system-config-users has been retired 
due to FTBFS and lack of mainteance. I would like to revive it but I 
can't find the source code anywhere. It was previously hosted on 
fedorahosted but has not been moved to Pagure.


Anyone knows if there is still an official repo for it?

Best regards,

Robert-André
___
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: Review Request: icemon - A GUI monitor for Icecream

[Robert-André Mauchin]

On 5/29/21 1:15 PM, Jan Kratochvil wrote:

Hi,

Review Request: icemon - A GUI monitor for Icecream
https://bugzilla.redhat.com/show_bug.cgi?id=1965529
Spec URL: http://people.redhat.com/jkratoch/icemon.spec
SRPM URL: http://people.redhat.com/jkratoch/icemon-3.3-6.fc34.src.rpm

It should be very simple IMO, it is an unretirement.


Thanks,
Jan


I have taken this. It's in need of a coat of fresh paint.

Best regards,

Robert-André
___
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: Package review #1961174

[Robert-André Mauchin]

On 5/18/21 3:19 PM, Antonio T. sagitter wrote:

Hi all.

I have a new package in review (rhbz#1961174) that will obsolete 'mld2p4'

Please, take a look if you can; i'll review one in exchange.

Thanks.


I have started the review. In exchange could you review jpegxl:
https://bugzilla.redhat.com/show_bug.cgi?id=1922638
The dependency highway has just been pushed to Rawhide, maybe use Koji,s 
local repo for review.


Thanks.

Robert-André
___
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

aom soname bump

[Robert-André Mauchin]

Hi,

AOM AV1 version 3 has been published a while ago and I am planning to 
update it in Fedora. Due to a CVE affecting versions prior to 2021-04-07 
(CVE-2021-30473), I plan to push this update to ALL STABLE RELEASES:


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

I intend to wait until 3.1.1 which fix a few compilation bugs, and wait 
 for jpeg-xl to be packaged to benefit from the new butteraugli tuning.


Affected packages as follows:

avidemux rpmfusion-free
cinelerra-gg rpmfusion-free
ffmpeg rpmfusion-free
go-avif fedora (should be retired)
gstreamer1-plugins-bad-free fedora
libavif fedora
libheif rpmfusion-free
rust-aom-sys fedora
seamonkey fedora
vlc rpmfusion-free
xine-lib rpmfusion-free


I will rebuild the affected packages using my PP.

Best regards,

Robert-André

p.s.: Leigh, I might need your help not to fuck up the repo in rpmfusion 
like last time (if you explain me your process to keep the branches in 
sync it would be nice).


___
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: Self Introduction: Rémi Lauzier

[Robert-André Mauchin]

On 5/2/21 11:21 PM, remilauzier via devel wrote:

Hello fellow fedoreans,

My name is Rémi Lauzier. He, Him. I am 29 years old. I am passionate 
about computer and video games.


I am the developer of a rust program call 
Rudo.<https://github.com/remilauzier/rudo 
<https://github.com/remilauzier/rudo>>
As the name implied, it's a clone of Sudo written in rust. I have been 
approve to be the packager of Rudo and some of it's dependency. Thanks 
Robert-André Mauchin(eclipseo).


If you want to try it, you can use this copr 
<https://copr.fedorainfracloud.org/coprs/remilauzier/rudo/ 
<https://copr.fedorainfracloud.org/coprs/remilauzier/rudo/>> until i 
manage to push all the necessary package in fedora. Don't hesitate to 
comment the code or finds some bugs!


My introduction to linux was ten years ago when i buy my first 
laptop(Gateway) and try a few linux distro like ubuntu when windows 7 
was to buggy on it. Gnome 2 and ubuntu wasn't my taste so opensuse with 
KDE manage to get me onboard of the linux train. Once the tumbleweed 
repo die and i need the most recent package for my radeon evergreen, i 
jump on cinnarch. Cinnamon was the perfect balance between kde and 
gnome. Then once cinnarch die, i jump on manjaro with gnome 3. It take 
me a few years to appreciate the gnome 3 ways. I have always hop between 
distro and desktop until i find a few that i love but fedora with gnome 
3 was the best between stability and up to date software.


My coding introduction was not a success until a few months ago when 
everything click. I tries a few language over the years, like c(hate 
that one), c++(too complicated and huge), python(never like it's 
syntax), ruby(was perfect until they abandon desktop application), 
java(Was the first i make an entire demo program), coffeescript(Fun for 
a coding game on the web) but rust 2018 edition finally got me in. i was 
always interested with the functionality of rust. So i first tried 
before 1.0 and after and it was not really operational at that time. 
After not having thoughts about coding in a few years, i finnaly decide 
to retry with rust when some Sudo vulnerability was announced this 
years. And contrary to what I believe, i manage to produce something 
functional.


So i am really happy to play my little part in the vast fedora and rust 
community. Thanks everyone! Don't hesitate if you have question!





Welcome Rémy!
___
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: Let's retire original glib and gtk+

[Robert-André Mauchin]

On 5/7/21 4:45 PM, Michael Catanzaro wrote:
Hi, I'd like to retire the original glib, GLib 1 from the GNOME 1 era. 
This is would take out the gtk+ package (GTK 1) along with it. (I'm not 
proposing to remove GTK 2.) GLib 1 has been obsolete for 19 years now, 
since GLib 2 was released in March 2002. That's a real long time to 
maintain a compatibility package, so I'm not sympathetic to anything 
that still requires it.


GLib 2 has been API and ABI stable for 19 years now, so it's not moving 
too fast for your package to depend on. :) The full list of packages 
still depending on GLib 1 is below. If you own one of the below 
packages, please consider upgrading to GLib 2. The only one that I 
recognize is Sagemath.


$ sudo dnf repoquery --recursive --whatrequires glib
golang-github-mattn-gtk-devel-0:0-0.7.20200729gitaf2e013.fc34.noarch


This is a packaging mistake, it should depend on glib2.
I will be fixing this ASAP.

Best regards,

Robert-André
___
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

Questions regarding the new account system

[Robert-André Mauchin]

Hello,

On the old account system, when I sponsored someone into the "packager" 
group, they were automatically added to the "fedorabugs" group. This is 
not the case anymore, is it a bug or a feature?


Globally I don't really like the new system. On a big group like:
https://accounts.fedoraproject.org/group/packager/
We can only see 100 members and we have lost many infos like email, date 
of membership, who sponsored them, or sorting by sponsor, compared to

https://admin.fedoraproject.org/accounts/group/members/packager
The Add user is hidden after the sponsor list, is not very explicit and 
does not provide a "confirmation" step like the old system. The 
information density is also way lower than before.


Does anyone know where can I report bugs for this?

Best regards,

Robert-André
___
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

Poetry/Pyproject expert: how to deal with extra files

[Robert-André Mauchin]

Hi,

I'm trying to help someone package a GUI in Python that is using
Pyproject. The project needs to add a desktop file, an appdata file
and also a "binary" to launch the GUI.

So far I have managed to drop the library files in %python3_sitelib.
But how should upstream deal with the extra files needed? Is there a
way provided by Poetry from the pyproject.toml? Or should upstream
write a separate Makefile?

Best regards,

Robert-André
___
python-devel mailing list -- python-devel@lists.fedoraproject.org
To unsubscribe send an email to python-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/python-devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: Next for ARC - researching how to replace PDC

[Robert-André Mauchin]

On 4/19/21 11:13 AM, Adam Saleh wrote:

Hi everyone,

ARC team - that is me, Vipul and Mark, are looking to figure out
possible ways how we could replace our current PDC [0] whose project
has gone unmaintained for years [1].

We plan to share what we find out in our
https://fedora-arc.readthedocs.io/en/latest/pdc/index.html

It would be really helpful if any other users of PDC would reach out,
so that we don't leave anybody behind.

First, is there anybody using the PDC UI? So far we have identified,
only api/cli usage.

Second, based on a cursory search through our infrastructure
configuration far we identified usage in:

- Release Engineering scripts - https://pagure.io/releng/
- fedpkg - https://pagure.io/fedpkg
- pungi - https://pagure.io/pungi/
- fedfind - https://pagure.io/fedora-qa/fedfind
- bodhi - https://github.com/fedora-infra/bodhi/
- pagure - https://pagure.io/pagure/
- MBS - https://pagure.io/fm-orchestrator/
- mirrormanager scripts - https://pagure.io/Fedora-Infra/ansible
- ODCS - https://pagure.io/odcs
- the new hotness - https://github.com/fedora-infra/the-new-hotness
- fedora messaging - https://github.com/fedora-infra/fedora-messaging
- osbs client - https://github.com/containerbuildsystem/osbs-client

Is there anything we are forgetting about?


fedscm-admin?

https://pagure.io/fedscm-admin/blob/main/f/fedscm_admin/pdc.py
___
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: SIMD-related package amd minimum supported instructions

[Robert-André Mauchin]

On 4/16/21 7:10 PM, Fabio Valentini wrote:

On Fri, Apr 16, 2021 at 6:29 PM Robert-André Mauchin  wrote:


Hello,

I have a dependency that is a C++ library for SIMD (called highway).
This library requires SSE4 as its minimum required instruction set
("Supported targets: SSE4, AVX2, AVX-512, NEON (ARMv7 and v8), WASM
SIMD."). However the minimum for Fedora is SSE2. Am I still allowed to
package this despite the requirement being above what's minimum for
Fedora? It won't compile on old systems but building works fine in Koji.

Best regards,

Robert-André


Relevant FESCo discussion and decision:
https://pagure.io/fesco/issue/2569#comment-713002

The text that was voted on:

 Libraries packaged in Fedora may require ISA extensions, however
any packaged application must not crash on any officially supported
architecture, either by providing a generic fallback implementation OR
by cleanly exiting when the requisite hardware support is unavailable.

It is still stuck in the pipeline to get the packaging guidelines
changed, though:
https://pagure.io/packaging-committee/issue/1044

Hope that helps.
Fabio



What if the problematic binary is just a test program used during build 
and not shipped in the final package? It works on Koji and don't cause 
any problem there and won't be a problem at all since the resulting 
package is a headers only library.


Thanks,

Robert-André
___
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

SIMD-related package amd minimum supported instructions

[Robert-André Mauchin]

Hello,

I have a dependency that is a C++ library for SIMD (called highway). 
This library requires SSE4 as its minimum required instruction set 
("Supported targets: SSE4, AVX2, AVX-512, NEON (ARMv7 and v8), WASM 
SIMD."). However the minimum for Fedora is SSE2. Am I still allowed to 
package this despite the requirement being above what's minimum for 
Fedora? It won't compile on old systems but building works fine in Koji.


Best regards,

Robert-André
___
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: How to handle pull request with git?

[Robert-André Mauchin]

On 4/15/21 1:24 PM, Mark Wielaard wrote:

On Wed, Apr 14, 2021 at 04:04:21PM +0200, Robert-André Mauchin wrote:

On 4/14/21 3:28 PM, Mark Wielaard wrote:

I got a "pull request" for one of my packages and wanted to make some
changes to discuss with the submitter and see if we could merge it
back with those changes to the rawhide branch. But somehow I did
something wrong and I am not sure what or how to fix it.

So I saw this webpage with the suggested change:
https://src.fedoraproject.org/rpms/valgrind/pull-request/4

I added the following line to my .git/config at the end of the [remote
"origin"] section to be able to pull it:

fetch = +refs/pull/*/head:refs/remotes/origin/pr/*

Then git pulled and checkout pr/4, made the changes, committed them
and pushed them back, hoping that would update the pr.

But it didn't, apparently I created a new origin/pr/4 branch, which I
am now unable to delete because:

$ git push origin --delete pr/4
remote: Branch deletion is not allowed
remote: Denied push for ref 'refs/heads/pr/4' for user 'mjw'
remote: All changes have been rejected
To ssh://pkgs.fedoraproject.org/rpms/valgrind
   ! [remote rejected] pr/4 (pre-receive hook declined)
error: failed to push some refs to 'ssh://pkgs.fedoraproject.org/rpms/valgrind'

What did I do wrong and how do I fix this?



1. You clone the forked repository
2. You checkout the branch where the modification has been made
3. You edit the files you want to change
4. You commit (or amend) the new changes
5. You push (or force push) the commit
6. Your commit will appear in the Pull Request ar "Rebased blah blah"
7. Merge your changes


Thanks. So I believed I was doing the above, but apparently not.
Would you mind explaining steps 1, 2 and 5 a bit more.

So what I did to clone the prs was to add that extra fetch line in my
.git/config. Which seemed to allow me to pull and work on the branch
remote pull/4 as pr/4 locally. Then I though I pushed it back, but
apparently that created a new branch in the origin called pr/4 instead
of getting my changes back into the remote pull/4.

Apparently the fetch line doesn't work like I expected.

Thanks,

Mark


So you have this PR: 
https://src.fedoraproject.org/rpms/valgrind/pull-request/4


- You see it is coming from rpms/ahajkova/valgrind
So you go to 
https://src.fedoraproject.org/fork/ahajkova/rpms/valgrind/tree/rawhide 
(by clicking on the first "rawhide")


- and get the clone url and clone that repository:

git clone ssh://m...@pkgs.fedoraproject.org/forks/ahajkova/rpms/valgrind.git

 - You checkout the branch where the changes have been made. Here it's 
already rawhide so you don't need to change.


 - Here you might need to rebase:

git remote add upstream ssh://m...@pkgs.fedoraproject.org/rpms/valgrind.git

git fetch upstream

git rebase upstream/rawhide

(Fix the eventual conflicts)

 - Then make the PR changes you want

 - Commit the changes by amending the previous commit

 - git push --force to force the edit of the commit to the remote

It will update your PR directly.
___
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: How to handle pull request with git?

[Robert-André Mauchin]

On 4/14/21 3:28 PM, Mark Wielaard wrote:

Hi,

I got a "pull request" for one of my packages and wanted to make some
changes to discuss with the submitter and see if we could merge it
back with those changes to the rawhide branch. But somehow I did
something wrong and I am not sure what or how to fix it.

So I saw this webpage with the suggested change:
https://src.fedoraproject.org/rpms/valgrind/pull-request/4

I added the following line to my .git/config at the end of the [remote
"origin"] section to be able to pull it:

fetch = +refs/pull/*/head:refs/remotes/origin/pr/*

Then git pulled and checkout pr/4, made the changes, committed them
and pushed them back, hoping that would update the pr.

But it didn't, apparently I created a new origin/pr/4 branch, which I
am now unable to delete because:

$ git push origin --delete pr/4
remote: Branch deletion is not allowed
remote: Denied push for ref 'refs/heads/pr/4' for user 'mjw'
remote: All changes have been rejected
To ssh://pkgs.fedoraproject.org/rpms/valgrind
  ! [remote rejected] pr/4 (pre-receive hook declined)
error: failed to push some refs to 'ssh://pkgs.fedoraproject.org/rpms/valgrind'

What did I do wrong and how do I fix this?

Thanks,

Mark


1. You clone the forked repository
2. You checkout the branch where the modification has been made
3. You edit the files you want to change
4. You commit (or amend) the new changes
5. You push (or force push) the commit
6. Your commit will appear in the Pull Request ar "Rebased blah blah"
7. Merge your changes
___
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: F35 Change proposal: RPM 4.17 (System-Wide Change proposal)

[Robert-André Mauchin]

On 4/1/21 12:33 AM, Kalev Lember wrote:
On Thu, Apr 1, 2021 at 12:18 AM Zbigniew Jędrzejewski-Szmek 
mailto:zbys...@in.waw.pl>> wrote:


On Wed, Mar 31, 2021 at 11:45:54PM +0200, Miro Hrončok wrote:
 > On 31. 03. 21 21:52, Ben Cotton wrote:
 > >* Strict checking for unpackaged content in builds
 > > ...
 > >* Many existing packages will fail to build due to the stricter
 > >buildroot content checking. Fixing this in the packaging is always
 > >backwards compatible. We could temporarily set
 > >`%_unpackaged_files_terminate_build 0` in rawhide to alleviate
initial
 > >impact if necessary.
 >
 > This is my main concern with this update.
 >
 > tl;dr If you %exclude something and there is no other subpackage to
 > own the files, the build fails:

Whaaat? What is the point of %exclude if not to exclude files from the
list? Why would rpm upstream want to break this? Seems like a completely
backwards change that will make packaging harder instead of easier.


%exclude can be used for splitting up packages, so you can do

%files foo
%exclude bar.so
*.so

%files bar
bar.so


If my understanding is right, the above is what rpm upstream considers 
correct use for %exclude.


For just not packaging some files, rm at the end of %install usually 
works just fine (but people have also been using %exclude for that and 
this change would break a bunch of packages that do this. I'm unsure if 
it's a good thing or not).




This is what I have enforced when reviewing packages, except for 
Rubygems where the problem is endemic.

___
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

Display a message on the console while upgrading a package

[Robert-André Mauchin]

Hello,

Following a change in the config file of a program, I'd like to display 
a message to my users to indicate they need to update the config file 
with the new one. I try "echo" in the update scriptlet:


%postun
if [ "$1" -ge "1" ] ; then # Upgrade
  dnscrypt-proxy -service install --config 
%{_sysconfdir}/dnscrypt-proxy/dnscrypt-proxy.toml
  echo 'Since version 2.0.45, some of the configuration files have been 
renamed.
  Please merge your config to 
/etc/dnscrypt-proxy/dnscrypt-proxy.toml.rpmnew then

  replace dnscrypt-proxy.toml with that file.
  Read /usr/share/doc/dnscrypt-proxy/ChangeLog to merge files accordingly.'
fi

But it doesn't work as expected. Is there a way to transmit that message 
to my users?


Best regards,

Robert-André
___
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: Libavif SONAME bump

[Robert-André Mauchin]

On 3/29/21 11:35 PM, Kalev Lember wrote:



On Mon, Mar 29, 2021 at 11:11 PM Robert-André Mauchin <mailto:zebo...@gmail.com>> wrote:


On 3/29/21 10:56 PM, Kalev Lember wrote:
 > Can you do it now instead of waiting until next week? Next week
starts
 > the F34 Final Freeze which means the soname bump is going to
linger in
 > updates-testing for weeks until the freeze is lifted and likely
to cause
 > confusion if any of the dependent packages gets rebuilt (possibly
 > against the older soname) during that time.
 >
 > Or alternatively, wait until the freeze is over (although my
suggestion
 > would be to do it now).
 >
 > Kalev
 >

I didn't intend to target F34, only Rawhide, but I can do it now if
needed.


Ah, OK, I assumed you'd target F34 because the previous attempt 
(https://bodhi.fedoraproject.org/updates/FEDORA-2021-9d7783af8a 
<https://bodhi.fedoraproject.org/updates/FEDORA-2021-9d7783af8a>) did. I 
don't think it matters much when to do the rawhide update :)


Kalev



I have updated on both then:
https://bodhi.fedoraproject.org/updates/FEDORA-2021-12976f6ca7
https://bodhi.fedoraproject.org/updates/FEDORA-2021-6beeb909ba

Best regards,

Robert-André
___
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: Libavif SONAME bump

[Robert-André Mauchin]

On 3/29/21 10:56 PM, Kalev Lember wrote:
On Mon, Mar 29, 2021 at 10:48 PM Robert-André Mauchin <mailto:zebo...@gmail.com>> wrote:


Hi,

Following the yanking due to an unannounced SONAME bump by my
comaintainer, I intend to bump libavif soname next week to 10.

The affected packages are the following:

PACKAGE                                DEPENDENT   
           DEPENDENCIES
libavif-0.8.4-5.fc35.x86_64   
darktable-3.4.1-1.fc35.x86_64          libavif.so.9()(64bit)
                                         gd-2.3.2-3.fc35.x86_64 
            libavif.so.9()(64bit)

kf5-kimageformats-5.80.0-1.fc35.x86_64 libavif.so.9()(64bit)


I intend to bump them myself next week using my PP privileges.


Can you do it now instead of waiting until next week? Next week starts 
the F34 Final Freeze which means the soname bump is going to linger in 
updates-testing for weeks until the freeze is lifted and likely to cause 
confusion if any of the dependent packages gets rebuilt (possibly 
against the older soname) during that time.


Or alternatively, wait until the freeze is over (although my suggestion 
would be to do it now).


Kalev



I didn't intend to target F34, only Rawhide, but I can do it now if needed.

Robert-André
___
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

Libavif SONAME bump

[Robert-André Mauchin]

Hi,

Following the yanking due to an unannounced SONAME bump by my
comaintainer, I intend to bump libavif soname next week to 10.

The affected packages are the following:

PACKAGEDEPENDENT  
DEPENDENCIES
libavif-0.8.4-5.fc35.x86_64darktable-3.4.1-1.fc35.x86_64  
libavif.so.9()(64bit)
   gd-2.3.2-3.fc35.x86_64 
libavif.so.9()(64bit)
   kf5-kimageformats-5.80.0-1.fc35.x86_64 
libavif.so.9()(64bit)

I intend to bump them myself next week using my PP privileges.

Best regards,

Robert-André
___
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

Review swaps

[Robert-André Mauchin]

Hello!

I have a dozen or more packages waiting to be reviewed and I'm looking for 
someone to
help in exchange of some of yours.

Silver is cross-shell customizable powerline-like prompt heavily inspired by 
Agnoster.
It needs to be updated to 2.0.0.

- [ ] rust-silver update

  - [ ] rust-confy
https://bugzilla.redhat.com/show_bug.cgi?id=rust-confy

  - [ ] rust-humantime-serde
https://bugzilla.redhat.com/show_bug.cgi?id=rust-humantime-serde


wormhole-william is a Go (golang) implementation of magic wormhole. It provides
secure end-to-end encrypted file transfers between computers. The endpoints are
connected using the same "wormhole code".

- [ ] wormhole-william
  https://bugzilla.redhat.com/show_bug.cgi?id=wormhole-william

  - [x] golang-github-cheggaaa-pb-3
https://bugzilla.redhat.com/show_bug.cgi?id=1910860

  - [ ] golang-salsa-debian-vasudev-gospake2

https://bugzilla.redhat.com/show_bug.cgi?id=golang-salsa-debian-vasudev-gospake2


Wormhole-gui is a cross-platform graphical interface for magic-wormhole that
lets you easily share files, folders and text between devices. It uses the Go
implementation of magic-wormhole, called wormhole-william, and compiles
statically into a single binary. Wormhole-gui is compatible with the cli
applications from both wormhole-william and magic-wormhole.

- [ ] wormhole-gui
  https://bugzilla.redhat.com/show_bug.cgi?id=wormhole-gui

  - [ ] golang-fyne
https://bugzilla.redhat.com/show_bug.cgi?id=golang-fyne

- [ ] golang-github-kodeworks-image-ico
  
https://bugzilla.redhat.com/show_bug.cgi?id=golang-github-kodeworks-image-ico

- [ ] golang-github-fyne-io-mobile
  
https://bugzilla.redhat.com/show_bug.cgi?id=golang-github-fyne-io-mobile

- [ ] golang-github-gl
  https://bugzilla.redhat.com/show_bug.cgi?id=golang-github-gl

- [ ] golang-github-fyne-io-glfw
  
https://bugzilla.redhat.com/show_bug.cgi?id=golang-github-fyne-io-glfw

- [ ] golang-github-goki-freetype
  
https://bugzilla.redhat.com/show_bug.cgi?id=golang-github-goki-freetype

- [ ] golang-github-jackmordaunt-icns
  
https://bugzilla.redhat.com/show_bug.cgi?id=golang-github-jackmordaunt-icns

- [ ] golang-github-josephspurrier-goversioninfo
  
https://bugzilla.redhat.com/show_bug.cgi?id=golang-github-josephspurrier-goversionin

  - [ ] golang-github-akavel-rsrc

https://bugzilla.redhat.com/show_bug.cgi?id=golang-github-akavel-rsrc

- [ ] golang-github-lucor-goinfo
  
https://bugzilla.redhat.com/show_bug.cgi?id=golang-github-lucor-goinfo

- [ ] golang-github-srwiley-oksvg
  
https://bugzilla.redhat.com/show_bug.cgi?id=golang-github-srwiley-oksvg

  - [ ] golang-github-srwiley-rasterx

https://bugzilla.redhat.com/show_bug.cgi?id=golang-github-srwiley-rasterx

Thanks to all for taking a look,

Robert-André
___
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

[Robert-André Mauchin]

On 3/8/21 11:52 AM, 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-2021-03-08.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

golang-gvisor eclipseo, elmarco, orphan    5 weeks ago


I don't understand why this was orphaned, I've updated it at the end of January 
so it wasn't unmaintained.

___
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

How to backup and then replace a config(noreplace) config file?

[Robert-André Mauchin]

Hello,

Upstream has added breaking changes to their config file so I need to 
introduce this new config file as a breaking change in Rawhide. What is 
the best option to do so while backuping the previous config file?


Best regards,

Robert-André
___
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

Re: Help for FTBFS packages: apcupsd and firefox-pkcs11-loader

[Robert-André Mauchin]

On 1/30/21 7:37 PM, Germano Massullo wrote:
I tried fixing apcupsd and firefox-pkcs11-loader that started to fail 
after introduction of "CMake to do out-of-source builds", but I got some 
errors about missing files, that is strange since package structure has 
not changed, it's the same that built successfully on older Fedora 
branches problems. So I am writing this message to ask for your help. 
Details at following bugzilla comments


firefox-pkcs11-loader
https://bugzilla.redhat.com/show_bug.cgi?id=1863558#c7


It seems out of tree builds are not supported by the build script.
Just copy the xpi to the build directory to make it work:

cp -a *.xpi %{_vpath_builddir}/

(after the %cmake call)
___
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

Re: can't build the package

[Robert-André Mauchin]

On 1/11/21 8:25 PM, Alexander Vasilenko wrote:

Fedora rawhide, last updates.

Package: https://src.fedoraproject.org/rpms/dnscrypt-proxy-gui
Pushed new version to master, f33, f32.

$ kinit f1...@fedoraproject.org -- sussecc,

but
$ fedpkg build
Kerberos authentication fails: unable to obtain a session
Could not execute build: Could not login to 
https://koji.fedoraproject.org/kojihub
$

and simple scratch from local src.rpm file
$ koji build --scratch f33 ./dnscrypt-proxy-gui-1.24.17-1.fc34.src.rpm
2021-01-11 22:24:09,616 [ERROR] koji: AuthError: unable to obtain a session
$

Any suggestion, pls.
___
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



What does:

env KRB5_TRACE=/dev/stdout kinit f1...@fedoraproject.org

give you?
___
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

Re: How to handle a config(noreplace) file that needs to be updated

[Robert-André Mauchin]

On 1/4/21 2:44 AM, Kevin Kofler via devel wrote:

Robert-André Mauchin wrote:

I have a project for which the config file (toml) has been significantly
changed, notably renamed sections. As such some older config parameters
won't work anymore.


Tools like sed, ed, awk etc. in %post scriptlets can do wonders.



I would do that but the cange are too extensive. And some config file 
got renamede I'm not sure how to handle that yet.

___
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

How to handle a config(noreplace) file that needs to be updated

[Robert-André Mauchin]

Hello,

I have a project for which the config file (toml) has been significantly 
changed, notably renamed sections. As such some older config parameters 
won't work anymore.
However the current config file can't be overwritten because of 
config(noreplace) directive. How do I recommend my users to move to the 
new config format?


Best regards,

Robert-André
___
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

Re: HEADS UP: libgit 1.1.0 update with SONAME bump (in Rawhide)

[Robert-André Mauchin]

On 12/29/20 4:12 PM, Igor Raits wrote:
All packages were rebuilt successfully except julia. It is FTBFS due to 
the GCC 11.0 upgrade (so it is FTBFS for quite some time already).


The update is on the way to Rawhide and I don't plan to push this update 
to stable releases (unless somebody asks for it).


Have fun during these holidays!



Just receive this:

Your package (git-time-metric) Fails To Install in Fedora 34:

can't install git-time-metric:
  - nothing provides libgit2.so.1.0()(64bit) needed by
git-time-metric-1.3.5-8.fc33.x86_64

It doesn't appear with your whatrequires.c anymore but it does indeed 
requires libgit:


rpm -q --requires -p git-time-metric-1.3.5-8.fc33.x86_64.rpm | sort -f | 
uniq -c

  1 libc.so.6()(64bit)
  1 libc.so.6(GLIBC_2.14)(64bit)
  1 libc.so.6(GLIBC_2.2.5)(64bit)
  1 libc.so.6(GLIBC_2.32)(64bit)
  1 libgit2.so.1.0()(64bit)
  1 libpthread.so.0()(64bit)
  1 libpthread.so.0(GLIBC_2.2.5)(64bit)
  1 libpthread.so.0(GLIBC_2.3.2)(64bit)
  1 rpmlib(CompressedFileNames) <= 3.0.4-1
  1 rpmlib(FileDigests) <= 4.6.0-1
  1 rpmlib(PayloadFilesHavePrefix) <= 4.0-1
  1 rpmlib(PayloadIsZstd) <= 5.4.18-1
  1 rtld(GNU_HASH)

I will update it later when dist-git is not down but it is strange that 
it is not detected as a require anymore.


Best regards and happy new year to you,

Robert-André
___
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

Re: Review Request: rubygem-asciidoctor-diagram - Asciidoctor diagramming extension

[Robert-André Mauchin]

On 12/22/20 12:23 PM, Christopher Brown wrote:

Hello,

Would it be possible to get a review on this please?



You can't provide precompiled jar files, they needs to be build from source:

Issues:
===
- Bundled jar/class files should be removed before build
  Note: Jar files in source (see attachment)
  See: https://docs.fedoraproject.org/en-US/packaging-
  guidelines/Java/#_pre_built_dependencies

Jar and class files in source
-
./asciidoctor-diagram-2.0.5/lib/batik-all-1.10.jar
./asciidoctor-diagram-2.0.5/lib/ditaa-1.3.15.jar
./asciidoctor-diagram-2.0.5/lib/ditaamini-0.12.jar
./asciidoctor-diagram-2.0.5/lib/jlatexmath-minimal-1.0.5.jar
./asciidoctor-diagram-2.0.5/lib/plantuml-1.3.15.jar
./asciidoctor-diagram-2.0.5/lib/plantuml.jar
./asciidoctor-diagram-2.0.5/lib/server-1.3.15.jar
___
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

Re: Fedora 34 Change: Enable spec file preprocessing (System-Wide Change proposal)

[Robert-André Mauchin]

On 12/18/20 3:52 PM, James Szinger wrote:


No.  One can also download the sources from upstream using spectool or
similar, even wget or curl.  My local work flow is typically get or
create spec file and patches, spectool -g, rpmbuild -bs, mock.



Unrelated to the topic at hand, but why do people still use rpmbuild -bs 
instead of using a fedpkg mockbuild? You get a clean environment to 
build and you don't have to install tons of devel packages on your system.

___
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

Re: GCC 11 related build failure

[Robert-André Mauchin]

On 12/15/20 1:12 AM, Neal Gompa wrote:


Just for reference, we *do* have a relatively up to date build of
googletest for things to use in our gtest[1] package that is supposed
to work with gcc11 already...

[1]: https://src.fedoraproject.org/rpms/gtest



It was bundled, I ended up disabling building the tests that were not 
needed anyway. It was only useful for AOM hackers.


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

GCC 11 related build failure

[Robert-André Mauchin]

Hello,

While building Googletest, I've encourtered this failure:



/builddir/build/BUILD/aom-2.0.1/third_party/googletest/src/googletest/include/gtest/gtest-printers.h:
 In instantiation of 'void testing_internal::DefaultPrintNonContainerTo(const T&, 
std::ostream*) [with T = {anonymous}::Y4mTestParam; std::ostream = 
std::basic_ostream]':
/builddir/build/BUILD/aom-2.0.1/third_party/googletest/src/googletest/include/gtest/gtest-printers.h:465:49:
   required from 'void 
testing::internal::DefaultPrintTo(testing::internal::WrapPrinterType,
 const T&, std::ostream*) [with T = {anonymous}::Y4mTestParam; std::ostream = 
std::basic_ostream]'
/builddir/build/BUILD/aom-2.0.1/third_party/googletest/src/googletest/include/gtest/gtest-printers.h:500:17:
   required from 'void testing::internal::PrintTo(const T&, std::ostream*) [with T = 
{anonymous}::Y4mTestParam; std::ostream = std::basic_ostream]'
/builddir/build/BUILD/aom-2.0.1/third_party/googletest/src/googletest/include/gtest/gtest-printers.h:676:12:
   required from 'static void testing::internal::UniversalPrinter::Print(const T&, 
std::ostream*) [with T = {anonymous}::Y4mTestParam; std::ostream = 
std::basic_ostream]'
/builddir/build/BUILD/aom-2.0.1/third_party/googletest/src/googletest/include/gtest/gtest-printers.h:866:30:
   required from 'void testing::internal::UniversalPrint(const T&, std::ostream*) 
[with T = {anonymous}::Y4mTestParam; std::ostream = std::basic_ostream]'
/builddir/build/BUILD/aom-2.0.1/third_party/googletest/src/googletest/include/gtest/gtest-printers.h:794:19:
   required from 'static void testing::internal::UniversalTersePrinter::Print(const 
T&, std::ostream*) [with T = {anonymous}::Y4mTestParam; std::ostream = 
std::basic_ostream]'
/builddir/build/BUILD/aom-2.0.1/third_party/googletest/src/googletest/include/gtest/gtest-printers.h:914:44:
   required from 'std::string testing::PrintToString(const T&) [with T = 
{anonymous}::Y4mTestParam; std::string = std::__cxx11::basic_string]'
/builddir/build/BUILD/aom-2.0.1/third_party/googletest/src/googletest/include/gtest/internal/gtest-param-util.h:585:28:
   required from 'void 
testing::internal::ParameterizedTestSuiteInfo::RegisterTests() [with 
TestSuite = {anonymous}::Y4mVideoWriteTest]'
/builddir/build/BUILD/aom-2.0.1/third_party/googletest/src/googletest/include/gtest/internal/gtest-param-util.h:536:8:
   required from here
/builddir/build/BUILD/aom-2.0.1/third_party/googletest/src/googletest/include/gtest/gtest-printers.h:283:7:
 error: no match for 'operator<<' (operand types are 'std::ostream' {aka 
'std::basic_ostream'} and 'const {anonymous}::Y4mTestParam')
  283 |   *os << value;
  |   ^~~~



Any input regarding itwould be appreciated: I haven't seen anything 
related in https://www.gnu.org/software/gcc/gcc-11/porting_to.html


Best regards,

Robert-André
___
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

Re: Fedora 34 Change: GitRepos-master-to-main (Self-Contained Change)

[Robert-André Mauchin]

On 12/14/20 4:29 PM, Christopher wrote:
Even if people don't agree that "main" is better for other reasons, 
surely people can agree that "rawhide" is much better than "master" for 
our dist-git branch names for our RPMs, simply because it follows our 
naming conventions and makes things easier from that perspective. The 
only reason they were ever named "master" in the first place is because 
it was git's default name. Nobody chose it to be "master" for Fedora... 
we just accepted the tyranny of the default. We should have always had 
it named "rawhide". I'm not in favor of changing it to "main", because 
if we're interested in changing it, we should take the opportunity to 
use a better name... one that is meaningful to us... rather than just 
accept a new default naming convention that doesn't mean anything to us. 
"rawhide" has a special meaning in Fedora, but "main" doesn't. Let's use 
"rawhide".


On Sat, Dec 12, 2020 at 3:49 PM Kevin Fenzi > wrote:


On Sat, Dec 12, 2020 at 12:01:32PM -0700, stan via devel wrote:
 > On Sat, 12 Dec 2020 09:09:46 -0700
 > stan mailto:upai...@zoho.com>> wrote:
 > > Is this really the best use of resources to combat
 > > that?
 >
...snip...
 >
 > Just an alternative idea.

I think it's easy for people to misunderstand what we are trying to do
here. I would encourage you to watch Rich Bowens nest talk:
https://www.youtube.com/watch?v=o0shU2g4IoI


To answer some of the points: This isn't about what the dictionary
definitions of the words mean, or that you personally don't find them
unwelcoming. It's about doing the right thing and showing that our
community is welcoming and we are willing to do some work to make it
so.

If we had a pile of money could we find better ways to spend it? Sure!
But we don't. We have time and some adjustments to our workflows that we
can do right now to show we care and are not jerks. So, instead of doing
nothing, lets do this!

kevin
___



I am lazy, main is easier to type than rawhide
___
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

Re: dav1d SONAME bump

[Robert-André Mauchin]

On 12/5/20 12:21 PM, Robert-André Mauchin wrote:

Hello,

I plan on updating dav1d to 0.8.0 next week. This triggers a soname bump 
(libdav1d.so.5).


Affected packages are:

libdav1d-0.7.1-2.fc33.x86_64   
libavif-0.8.2-1.fc34.x86_64   libdav1d.so.4()(64bit)

seamonkey-2.53.5-2.fc34.x86_64    libdav1d.so.4()(64bit)

cinelerra-gg-5.1.2020.07-2.fc33.x86_64    libdav1d.so.4()(64bit)

ffmpeg-libs-4.3.1-12.fc34.x86_64  libdav1d.so.4()(64bit)

HandBrake-1.3.3-6.fc34.x86_64 libdav1d.so.4()(64bit)

HandBrake-gui-1.3.3-6.fc34.x86_64 libdav1d.so.4()(64bit)

libheif-1.9.1-1.fc34.x86_64   libdav1d.so.4()(64bit)

vlc-core-1:3.0.12-0.3.fc34.x86_64 libdav1d.so.4()(64bit)

xine-lib-1.2.10-12.fc34.x86_64    libdav1d.so.4()(64bit)



Best regards,

Robert-André


I have rebuild most of these except:

 - Seamonkey: the build fails with Rust 1.48  as documented here:
https://bugzilla.mozilla.org/show_bug.cgi?id=1667736
I've CC the Seamonkey maintainer.

 - VLC: Fails with error: 'numeric_limits' is not a member of 'std'
Reported upstream:
https://trac.videolan.org/vlc/ticket/25325
I have a patch to try for this.
I have CC RPMFusion.


FeRD, I haven't touched your package, you should be able to rebuild 
cinelerra-gg now.


Best regards,

Robert-André
___
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

Re: Fedora 34 Change: GitRepos-master-to-main (Self-Contained Change)

[Robert-André Mauchin]

On 12/3/20 4:02 PM, Ben Cotton wrote:

https://fedoraproject.org/wiki/Changes/GitRepos-master-to-main

== Summary ==

This Change will move Fedora git repositories to use "main" as the
default git branch instead of "master". Specific repositories will be
manually moved and default git branch for new projects will be set to
use "main".

The Fedora Community strives to be open and welcoming. Some language
around our git repositories is dated and could be more inclusive. Many
git repositories currently use "master" as the default branch. This
Change will move many repositories (see below) to use a "main" branch
as default. This small bit of naming adjustment is in-line with
Fedora's vision for free and open source software built by inclusive,
welcoming, and open-minded communities.




How does it work for the enduser? I have thousand of git repos locally 
with the master branch, will it rename automatically master to main when 
I git pull or do I need to run a special command?

___
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