Re: Error while trying to rebuild PCMANFM-Qt

[zebob . m]

On 11/12/23 4:19 PM, Robert-André Mauchin  wrote:

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é





Well rebuilding libfm-qt and buidling against the rebuild di the trick/

Thanks anyway.

Have a good one,

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: SPDX Statistics - Miracle of the Sun edition

[zebob . m]

On 10/13/23 2:46 PM, Michael Catanzaro  wrote:

On Fri, Oct 13 2023 at 08:15:39 AM +0200, Miroslav Suchý  
wrote:
> Scancode-toolkit is not yet in Fedora, but you can instal it form PyPI:
>
>     $ pip install scancode-toolkit
>  $  ~/.local/bin/scancode --license --html /tmp/spdx.html .
>

I attempted this, but unfortunately it depedns on intbitset which is incompatible with 
python 3.12, so it won't work if you've upgraded to Fedora 39. Example errors:


  intbitset/intbitset.c: In function ‘__Pyx_Raise’:
  intbitset/intbitset.c:15725:34: error: ‘PyThreadState’ {aka ‘struct _ts’} has no 
member named ‘curexc_traceback’

  15725 | PyObject* tmp_tb = tstate->curexc_traceback;
    | ^~
  intbitset/intbitset.c:15728:19: error: ‘PyThreadState’ {aka ‘struct _ts’} has no 
member named ‘curexc_traceback’

  15728 | tstate->curexc_traceback = tb;
    | ^~


___
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


It's on my COPR and review requests are up

https://copr.fedorainfracloud.org/coprs/eclipseo/scancode-toolkit/
___
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: Making sense of golang packaging guidelines

[zebob . m]

On 7/20/23 8:20 PM, Carlos Rodriguez Fernandez  
wrote:

Hi all,

I am interested in packaging some golang programs for Fedora (and EPEL), and I read through 
the guidelines:
https://docs.fedoraproject.org/en-US/packaging-guidelines/Golang/ 



My question is more about the reasoning for the recommended handling of 
dependencies.

Other language platforms have shared runtime objects, and devel packages provide the 
interface to link to them when necessary; however golang compiles it all statically. It is 
very easy to bring all the dependencies locally for compilation directly from git repos and 
then nothing is necessary at runtime.


Creating rpm packages for each golang dependency seems counterproductive as it adds an 
additional burden to maintain without the benefits of shared runtime objects.


I have the feeling I am missing something. What is the benefit of having each golang build 
dependency as rpms?
Is it a requirement for golang programs rpm contributions or it is optional? (e.g. 
prometheus in EPEL9 does not follow the deps handling guidelines but not sure if it is a 
tech debt or an option).



Thank you,
Carlos



We need to build into Koji, there is no "local build". As such we have two 
options :
- bundle the dependencies in the package
- package all the libraries separately

The Fedora guidelines is to package library separately, per 
https://docs.fedoraproject.org/en-US/fesco/Bundled_Software_policy/ :



All packages whose upstreams allow them to be built against system libraries 
must be built against system libraries.

All packages whose upstreams have no mechanism to build against system 
libraries must be contacted publicly about a path to supporting system 
libraries. If upstream refuses, this must be recorded in the spec file using a 
persistent mechanism to be clarified in the packaging guidelines.

All packages whose upstreams have no mechanism to build against system 
libraries may opt to carry bundled libraries, but if they do, they must include 
Provides: bundled() = in their RPM spec file.


This policy only applies to Fedora. In EPEL we bundle because we don't have our 
macros and the Go ecosystem is not bootstrapped.

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: Non-responsive maintainer check for golang-github-prometheus-common-devel

[zebob . m]

On 9/17/22 4:18 AM, Maxwell G via devel  wrote:

Hi Tobias,

On Fri Sep 16, 2022, Tobias Zellner wrote:
> some weeks ago I opened the bug 
https://bugzilla.redhat.com/show_bug.cgi?id=2109630

I commented on your bug and submitted a fix.

> Since there is no response to this bug, and following your guide lines 
(https://docs.fedoraproject.org/en-US/fesco/Policy_for_nonresponsive_package_maintainers/),
 I opend Non-responsive maintainer check f a for this package

For the record, the maintainer is fpokorny.

Indeed, it seems that maintainer is unresponsive. They haven't had any
recent activity in distgit. Other Go SIG members have been maintaining
their packages for some time. They are also slated to be removed[1] from the
packager group as part of the new Inactive Packager process[2]. This
won't actually happen until the end of October, so feel free to continue
with the standard Nonresponsive Maintainer process.

[1]: https://pagure.io/find-inactive-packagers/issue/222
[2]: https://docs.fedoraproject.org/en-US/fesco/Policy_for_inactive_packagers/


--
Best,

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


___
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



I haven't seen fpokorny active even when I started working on Go packages. Is 
there a way to reallocate all is Go packages to either the go-sig group or 
myself?

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] Sphinx 5 and docutils 0.18.1 coming to Rawhide on July 11th

[zebob . m]

On 6/30/22 5:34 PM, Karolina Surma  wrote:

eclipseo   python-graphviz python-h2 python-priority


python-h2 and python-priority are fixed in Rawhide.
A fix was pushed for python-graphviz, it just needs Sphinx 5 in Rawhide to 
build.

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: Stalled EPEL Request Policy (was Unresponsive maintainer: Alex Chernyakhovsky)

[zebob . m]

On 6/29/22 8:45 PM, Vitaly Zaitsev via devel  
wrote:

On 29/06/2022 20:24, Maxwell G wrote:
> I'm a bit confused. You say this sounds like a "package hijack attempt," but
> then you also say you don't like that it only allows access to epel* branches.

It is not possible to restrict access to only selected branches. EPEL maintainers can commit 
to Fedora branches and vice versa.


Thus, the newly added EPEL maintainers can do Fedora updates, and Fedora package maintainer 
can't prevent this. That's why I called this a "package hijack attempt".





What do you mean it is not possible? Isn't the new "collaborator" role exactly 
for this?

Best regards,

Ribert-André Mauchin
___
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