Re: Many packages unnecessarily link to libpython

[Gordon Messmer]

On 5/31/20 6:37 PM, Honggang LI wrote:

We have to compile/build the module before we can import it from a
python3 shell. The problem is how to compile the modules without pass
"-lpython3.9" or "-lpython3.9d" to the linker (/usr/bin/ld).



Do you have a link to a build log?
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

[Bug 1842176] perl-CPAN-Perl-Releases-5.20200530 is available

[bugzilla]

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

Jitka Plesnikova  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
   Doc Type|--- |If docs needed, set a value




-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-de...@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-de...@lists.fedoraproject.org

Re: unretiring llvm7.0

[Jens-Ulrik Petersen]

On Sun, May 31, 2020 at 12:44 AM Andy Mender 
wrote:

> If I understand correctly, the sudden disappearance of llvm7.0 means that
> now ghc is in danger as a package, because it's missing the toolchain
> needed to build & package it?
>

llvm is only a ghc requirement for arm archs.
Currently llvm7.0 missing in Rawhide only affects the ghc:8.8 module stream
for aarch64 and armv7hl


> However, https://apps.fedoraproject.org/packages lists only llvm9.0 and
> llvm10.0 builds.
>

I don't think that app has complete reliable information: your repoquery is
correct.

I think it's an interesting problem in general. Perhaps it would be good to
> have at least 1 extra version of GCC and LLVM other than the current
> mainline?
>

Yes that is why we have multiple llvmX.0 versions in Fedora: they can all
be parallel installed.
The problem is the people maintaining them are not always aware of what
packages need them etc.
Particularly for ghc it is easy to miss since only the arm packages have an
explicit dependency for llvm.

Jens
___
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: Packages that failed to build with Python 3.9

[Denis Arnaud]

Thanks for the follow up!

| airinv airrac airtsp rmol sevmgr trademgen

All those packages have been successfully rebuilt (after upstream upgrade):
* airinv: https://bodhi.fedoraproject.org/updates/FEDORA-2020-d6b3c81762
* airrac: https://bodhi.fedoraproject.org/updates/FEDORA-2020-bd268627aa
* airtsp: https://bodhi.fedoraproject.org/updates/FEDORA-2020-bf40bfa645
* rmol: https://bodhi.fedoraproject.org/updates/FEDORA-2020-5c004b8ae6
* sevmgr: https://bodhi.fedoraproject.org/updates/FEDORA-2020-1cd31866cb
* trademgen: https://bodhi.fedoraproject.org/updates/FEDORA-2020-1966482401

Kind regards

Denis
___
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: Many packages unnecessarily link to libpython

[Honggang LI]

On Sun, May 31, 2020 at 10:30:32AM -0700, Gordon Messmer wrote:
> On 5/31/20 1:24 AM, Honggang LI wrote:
> > As you see, "-lpython3.9" or "-lpython3.9d" library must be provided to
> > the linker. Otherwise, a lot of "undefined reference to xxx" error
> > messages show up.
> 
> 
> I'd guess that you're seeing "undefined reference" when you use ldd on the
> so, and that's expected.  That's the wrong way to test the object, though. 
> Instead, install that module and import it from a python3 shell.  Do you get

We have to compile/build the module before we can import it from a
python3 shell. The problem is how to compile the modules without pass
"-lpython3.9" or "-lpython3.9d" to the linker (/usr/bin/ld).

> errors?  You shouldn't.
> 
> ___
> 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
___
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: Packages that failed to build with Python 3.9

[Leigh Scott]

> On 31. 05. 20 17:09, Leigh Scott wrote:
> 
> That's up to the maintainer. Seems reasonable to me.

Thanks, patch forwarded to https://bugzilla.redhat.com/show_bug.cgi?id=1792059
___
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

CPE Weekly: 2020-05-31

[Aoife Moloney]

---
title: CPE Weekly status email
tags: CPE Weekly, email
---

# CPE Weekly: 2020-05-31

Background:
The Community Platform Engineering group is the Red Hat team combining
IT and release engineering from Fedora and CentOS. Our goal is to keep
core servers and services running and maintained, build releases, and
other strategic tasks that need more dedicated time than volunteers
can give.


See our wiki page here for more
information:https://docs.fedoraproject.org/en-US/cpe/


## General Project Updates

Please check out our updated initiative timetable for briefing in new
projects to our team
here:https://docs.fedoraproject.org/en-US/cpe/time_tables/
*Note: Initiatives are large pieces of work that require a team of
people and weeks/months to complete. Please continue to open tickets
in the normal way for bugs, issues, etc.

Don't forget to view our taiga board to see the projects we are
currently working on, what we have scoped and whats in our backlog
https://tree.taiga.io/project/amoloney1-cpe-team-projects/kanban?epic=null



I also currently have weekly IRC office hours on #fedora-meeting-1 @
1300 - 1400 UTC and I will have a bi-weekly office hours on
Centos-meeting @ 1500 - 1600 UTC beginning June 9th also, with Rich
Bowen helping me set it up, thanks Rich :)
There is (usually) no agenda for these meetings and is an open floor,
so please feel free to stop by and chat casually, or about any
projects the CPE team are working on/working on next. The choice of
topic is completely yours :)



### Gitforge
Just a quick note to say this project has not made any more notable
progress. Our team have some very time-intensive projects currently in
flight, so our focus has been and will be on the completion of these
projects over the next few months. We are still using the gitlab
project tracker https://gitlab.com/gitlab-org/gitlab/-/issues/217350
to record issues/technical requirements, and thank you again for your
patience during this slower period of the project, it is very much
appreciated.





## Fedora Updates




### Data Centre Move
* A reduced services offering of Fedora will be in effect from June
8th until July 28th, est.
* This is to complete the final shipment of hardware from Phoenix to
Washington, so please be patient and understanding during this
timeframe as some services will be off and the rest, much slower.
* Kevin Fenzi has sent some details on service validation and a call
to arms to help us meet the June 15th deadline to have the reduced
Fedora operational, please read:
https://lists.fedoraproject.org/archives/list/infrastruct...@lists.fedoraproject.org/thread/E7HJULW2S76FZCAICURWXX223N5ZXXD7/
* Details on what this move may mean for you can be found here
https://lists.fedoraproject.org/archives/list/devel-annou...@lists.fedoraproject.org/thread/27U6YT73556KYW2RIFJO6J2HYMYVP22U/


### AAA Replacement
* Adding the ability to sign user agreements
* Adding the blog/website attribute for users
* Client library migration to python-freeipa 1.0.0.





### Mbbox
* Project Dashboard here https://github.com/fedora-infra/mbbox/projects/1
* Sprint 3 is done:
* Refactor molecule test suit to share test-cases
* Koji-hub and koji-builder SSL issues solved
* Sprint 4 is in progress
* Kojira CRD
* MBS Backend CRD (MBS doesn’t support fedora messaging)
* Staging environment








## CentOS Updates

### CentOS
*  Post OCP4 cluster Installation tasks - storage, TLS cert/ IDP
configs, exploring operators that we can use.
* We have a public accessible ocp4 cluster
(https://console-openshift-console.apps.ocp.ci.centos.org/). We are on
the verge of figuring out subscriptions.
* Documentation: https://centosci.github.io/ocp4-docs/
* Linux 8.2 work is still with QA






### CentOS Stream
* The team are working on adding some 8.2 builds to Stream that failed
or did not make it into Stream for whatever reason.


















As always, feedback is welcome, and we will continue to look at ways
to improve the delivery and readability of this weekly report.


Have a great weekend!

Aoife


Source: https://hackmd.io/8iV7PilARSG68Tqv8CzKOQ?view


-- 
Aoife Moloney
Product Owner
Community Platform Engineering Team
Red Hat EMEA
Communications House
Cork Road
Waterford
___
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: Packages that failed to build with Python 3.9

[Miro Hrončok]

On 31. 05. 20 17:09, Leigh Scott wrote:

On 31. 05. 20 12:49, Leigh Scott wrote:

Note that python-setproctitle already failed to built with Python 3.8 and the
"fix" was to comment out the tests:

https://src.fedoraproject.org/rpms/python-setproctitle/c/d6d9620c3c4fa076...

Hence, it built with Python 3.9 even if it doesn't work at all.

Would it be acceptable to comment out the Py_GetArgcArgv code?

https://paste.centos.org/view/raw/779a12bd

Doing this enables cinnamon, blueberry, cinnamon-screensaver and 
lightdm-settings to function


That's up to the maintainer. Seems reasonable to me.

--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Schedule for Mondays's FESCo Meeting (2020-06-01)

[Zbigniew Jędrzejewski-Szmek]

Following is the list of topics that will be discussed in the
FESCo meeting Monday at 15:00UTC in #fedora-meeting-1 on
irc.freenode.net.

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

or run:
  date -d '2020-06-01 15:00 UTC'


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

= Discussed and Voted in the Ticket =

#2393 Nonresponsive maintainer: Martin Preisler mpreisle
https://pagure.io/fesco/issue/2393
ACCEPTED (+4, 0, 0)

#2392 Nonresponsive maintainer: Marek Mahut mmahut
https://pagure.io/fesco/issue/2392
ACCEPTED (+4, 0, 0)

#2389 Nonresponsive maintainer: Avesh Agarwal (avesh)
https://pagure.io/fesco/issue/2389
ACCEPTED (+4, 0, 0)

= Followups =

#2114 What is the scope of Modularity?
https://pagure.io/fesco/issue/2114

= New business =


= Open Floor = 

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

If you would like to add something to this agenda, you can
reply to this e-mail, file a new issue at
https://pagure.io/fesco, e-mail me directly, or bring it
up at the end of the meeting, during the open floor topic. Note
that added topics may be deferred until the following meeting. 
___
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: Supporting hibernation in Workstation ed., draft 1

[Chris Murphy]

On Sat, May 30, 2020 at 9:26 PM Tony Nelson
 wrote:
>
> On 20-05-30 21:02:11, Chris Murphy wrote:
>   ...
> > Full disk encryption doesn't adequately secure the hibernation image
> > either. Authenticated encryption (signing as well as encryption) is
> > needed to verify the image hasn't been tampered.
>
> What can an attacker do other than corrupt the data?  It is encrypted.

You don't know, and neither do I. That's the problem.

> With tamper detection, does a single bit changed deny the use of the
> hibernated image?

I expect so. Even at a far lesser level of integrity, e.g. non-crypto
crc32c used by dm-integrity and Btrfs by default, a single bit flip is
detected and you get EIO on reads.

> In either case, what can an attacker accomplish?

I have the same question, exposing me as (a) not a very good attacker,
and (b) not a cryptographer. Nevertheless I'm persuaded by the
argument that if I've signed up for signature verification of the
kernel and kernel modules at the start (UEFI Secure Boot), that it's a
bad idea to enable a loop hole where unauthenticated data is executed.
It doesn't matter if it's encrypted. It provides no error detection
mechanism. Such a loop hole in effect is an attack on the Secure Boot
paradigm.

And for now it's a difficult problem with limited resources committed
to resolving it. There are other ways to go about it, that also aren't
exactly easy but they might turn out to be more viable than AE
hibernation images.

> > The upstream work, cited in the document, gets into the details,
> > and what additional work is needed for the next revision.
>
> Which reference is that?  #5?  It seemed short.

I only provided a link to the most recent status. You need to click on
that link to get to the lkml email, and click on the link in there
too, and follow it to the patch set and ~18 email discussion. It's
short because it needs more work and the developer hasn't found enough
time to get back into it yet.

--
Chris Murphy
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Many packages unnecessarily link to libpython

[Gordon Messmer]

On 5/31/20 1:24 AM, Honggang LI wrote:

As you see, "-lpython3.9" or "-lpython3.9d" library must be provided to
the linker. Otherwise, a lot of "undefined reference to xxx" error
messages show up.



I'd guess that you're seeing "undefined reference" when you use ldd on 
the so, and that's expected.  That's the wrong way to test the object, 
though.  Instead, install that module and import it from a python3 
shell.  Do you get errors?  You shouldn't.


___
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: unretiring llvm7.0

[Gerald Henriksen]

On Sat, 30 May 2020 18:43:03 +0200, you wrote:

>If I understand correctly, the sudden disappearance of llvm7.0 means that
>now ghc is in danger as a package, because it's missing the toolchain
>needed to build & package it?

Don't know anything about ghc to comment on the difficulties, but ghc
8.10.1 was released 2 months ago and uses llvm 9

>However, https://apps.fedoraproject.org/packages lists only llvm9.0 and
>llvm10.0 builds.
>
>I think it's an interesting problem in general. Perhaps it would be good to
>have at least 1 extra version of GCC and LLVM other than the current
>mainline?

Isn't that already happening though with both llvm (10) and llvm9.0
being available in Fedora 32?
___
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: Packages that failed to build with Python 3.9

[Leigh Scott]

> On 31. 05. 20 12:49, Leigh Scott wrote:
> 
> Note that python-setproctitle already failed to built with Python 3.8 and the 
> "fix" was to comment out the tests:
> 
> https://src.fedoraproject.org/rpms/python-setproctitle/c/d6d9620c3c4fa076...
> 
> Hence, it built with Python 3.9 even if it doesn't work at all.
Would it be acceptable to comment out the Py_GetArgcArgv code?

https://paste.centos.org/view/raw/779a12bd

Doing this enables cinnamon, blueberry, cinnamon-screensaver and 
lightdm-settings to function
___
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: Lots of FailsToInstall on rawhide bugs

[Orion Poplawski]

On 5/30/20 12:46 PM, Orion Poplawski wrote:

Folks -

    I'm afraid the new FailsToInstall bugs may be a bit much for me. 
Often it seems:


- There is already a FTBFS bug against the package which is the root 
cause of the FTI.
- There was a soname bump in rawide and the builds didn't manage to 
complete before the next rawhide compose.  I know, people probably 
should be using side tags, but it's the maintainers of the dependent 
packages that are being harassed.  And can't we even have a bit more 
than a day to address these.


For released branches, sure go for it (although I would still argue 
about checking for a FTBFS bug first).  But can we back off a little bit 
on rawhide?


- Orion


I will however express thanks that the bugs are automatically closed 
when the packages can install.


--
Orion Poplawski
Manager of NWRA Technical Systems  720-772-5637
NWRA, Boulder/CoRA Office FAX: 303-415-9702
3380 Mitchell Lane   or...@nwra.com
Boulder, CO 80301 https://www.nwra.com/



smime.p7s
Description: S/MIME Cryptographic Signature
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: How to debug live CD image?

[Barry Scott]

> On 30 May 2020, at 14:12, Vitaly Zaitsev via devel 
>  wrote:
> 
> On 30.05.2020 15:04, Barry Scott wrote:
>> I use the KDE respin and it hangs at the same place.
>> I waited over an hour to see if will continue.
>> 
>> How can I help debug this?
> 
> I think that your problem is definitely related to this:
> https://bugzilla.redhat.com/show_bug.cgi?id=1830896
> 
> You can install Fedora and try one of the suggested workarounds.

I have Fedora installed on the HDD of this PC and it boots without any issues.

Its only the live CD that has the issue.

Given that my PC boots from HDD but not live USB image I'm not
so sure that that bug is the problem. Especically if its efivars that are
the root cause as that should be the same for my HDD and USB?

Barry


> 
> -- 
> Sincerely,
>  Vitaly Zaitsev (vit...@easycoding.org)
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct: 
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: 
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
___
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: Supporting hibernation in Workstation ed., draft 1

[Roberto Ragusa]

On 2020-05-30 12:59, Iñaki Ucar wrote:


If your swap is in a luks partition with a static passphrase (and
secureboot is disabled) then hibernate works just fine.


Actually, I can tell that a swap partition as an LVM volume living on a luks
encrypted PV works perfectly fine.

Regards.

--
   Roberto Ragusamail at robertoragusa.it
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: PSA: pytest 5 now finally available in rawhide

[Miro Hrončok]

On 31. 05. 20 14:06, Ian McInerney wrote:
On Fri, May 29, 2020 at 4:58 PM Miro Hrončok > wrote:


Hello,

the pytest package (python3-pytest) has been updated to 5.4.2.

In case it gives you trouble, you can pin an older version:

    BuildRrequires: %{py3_dist pytest} < 5

Or:

    BuildRrequires: python3dist(pytest) < 5

That will give you the python3-pytest4 package (4.6.10 now), not parallely
installable with python3-pytest.

Note that the python3-pytest4 package is deprecated, but no removal date has
been set. Likely, it will get orphaned or retired when no important packages
need it.

The pytest 4.6.x series is still being occasionally released, but:


https://docs.pytest.org/en/latest/py27-py34-deprecation.html#maintenance-of-4-6-x-versions

"From now on, the core team will no longer actively backport patches, but 
the
4.6.x branch will continue to exist so the community itself can contribute
patches."

Side note: The Fedora 31/32 python3-pytest package does not provide
python3-pytest4, hence I recommend not to BuildRequire python3-pytest4 
directly
by name, but using python3dist(pytest) or %py3_dist as in the examples 
above.

-- 
Miro Hrončok

--
Phone: +420777974800
IRC: mhroncok


  When running the fedora-review tool on a package that has "BuildRequires: 
  python3dist(pytest)" in it (note there is no version dependency on the pytest 
package), the review is complaining that:


- Package must not depend on deprecated() packages.
   Note: python3-pytest4 is deprecated, you must not depend on it.

Looking in the build log, it is actually using pytest5 though:

+ /usr/bin/python3 -m pytest
= test session starts ==
platform linux -- Python 3.9.0b1, pytest-5.4.2, py-1.8.0, pluggy-0.13.0

I have already cleaned my mock cache, and ran mock --scrub=all and this 
persists. Is there another cache that has to be cleaned, or a package that needs 
updating?


No, this is a bug in fedora-review.

https://pagure.io/FedoraReview/issue/392

--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: PSA: pytest 5 now finally available in rawhide

[Ian McInerney]

On Fri, May 29, 2020 at 4:58 PM Miro Hrončok  wrote:

> Hello,
>
> the pytest package (python3-pytest) has been updated to 5.4.2.
>
> In case it gives you trouble, you can pin an older version:
>
>BuildRrequires: %{py3_dist pytest} < 5
>
> Or:
>
>BuildRrequires: python3dist(pytest) < 5
>
> That will give you the python3-pytest4 package (4.6.10 now), not parallely
> installable with python3-pytest.
>
> Note that the python3-pytest4 package is deprecated, but no removal date
> has
> been set. Likely, it will get orphaned or retired when no important
> packages
> need it.
>
> The pytest 4.6.x series is still being occasionally released, but:
>
>
> https://docs.pytest.org/en/latest/py27-py34-deprecation.html#maintenance-of-4-6-x-versions
>
> "From now on, the core team will no longer actively backport patches, but
> the
> 4.6.x branch will continue to exist so the community itself can contribute
> patches."
>
> Side note: The Fedora 31/32 python3-pytest package does not provide
> python3-pytest4, hence I recommend not to BuildRequire python3-pytest4
> directly
> by name, but using python3dist(pytest) or %py3_dist as in the examples
> above.
>
> --
> Miro Hrončok
> --
> Phone: +420777974800
> IRC: mhroncok
>

 When running the fedora-review tool on a package that has "BuildRequires:
 python3dist(pytest)" in it (note there is no version dependency on the
pytest package), the review is complaining that:

- Package must not depend on deprecated() packages.
  Note: python3-pytest4 is deprecated, you must not depend on it.

Looking in the build log, it is actually using pytest5 though:

+ /usr/bin/python3 -m pytest
= test session starts
==
platform linux -- Python 3.9.0b1, pytest-5.4.2, py-1.8.0, pluggy-0.13.0

I have already cleaned my mock cache, and ran mock --scrub=all and this
persists. Is there another cache that has to be cleaned, or a package that
needs updating?

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

Fedora-Cloud-31-20200531.0 compose check report

[Fedora compose checker]

No missing expected images.

Passed openQA tests: 1/1 (x86_64)
-- 
Mail generated by check-compose:
https://pagure.io/fedora-qa/check-compose
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Packages that failed to build with Python 3.9

[Miro Hrončok]

On 29. 05. 20 21:59, Miro Hrončok wrote:

Hello.

As you might already know, we have recently merged in the Python 3.9 side tag, 
despite several builds have not succeeded. We always aim for some compromise 
between having the side tag open for too long and having too many failures.


...


cinch    greghellings
libtaskotron mkrizek
python-ansible-runner radez
python-peewee    cstratak mstuchli vkrizan
python-testinfra chedi ignatenkobrain wakko666
python-wtf-peewee    cstratak mstuchli


I've rebuilt those.

--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Packages that failed to build with Python 3.9

[Miro Hrončok]

On 31. 05. 20 13:13, Zbigniew Jędrzejewski-Szmek wrote:

On Sun, May 31, 2020 at 01:09:31PM +0200, Miro Hrončok wrote:

On 31. 05. 20 13:04, Zbigniew Jędrzejewski-Szmek wrote:

On Sun, May 31, 2020 at 10:49:28AM -, Leigh Scott wrote:

Even if the package builds it doesn't mean it's functional.

$ cinnamon-settings
Traceback (most recent call last):
File "/usr/share/cinnamon/cinnamon-settings/cinnamon-settings.py", line 16, in 

  from setproctitle import setproctitle
ImportError: 
/usr/lib64/python3.9/site-packages/setproctitle.cpython-39-x86_64-linux-gnu.so: 
undefined symbol: Py_GetArgcArgv


Idea for a global gating test for packages:
for rpm in $rpms; do
  python3 -c "$(rpm -qP $rpm | sed -n -r 's/python3dist\((.*)\).*/import 
\1/p')"
done


Unfortunately, this has a wrong assumption: python3dist(xxx) doesn't mean
there is an xxx module to import. See for example:

python3-beautifulsoup4 provides python3.9dist(beautifulsoup4) but is
imported as bs4. (I have plenty more examples like this... including
python-fedora.)

A better thing might be to query for .py files, .so files and directories
with such in %{python_sitelib}/%{python_sitearch}.


I always thought python3dist(foo) means that the package provides the
foo module, so that if I want to install foo module, I can rely on this
provides.


This is a very common misconception. That's why we want to explain this better 
in the new Python guidelines:


https://lists.fedoraproject.org/archives/list/python-de...@lists.fedoraproject.org/message/ZCNUQBJLDUJUJXK2EOPP2MWL6FJKLBPS/

Particularly:

---

Python packages have several different names, which should be kept in sync but 
will sometimes differ for historical or practical reasons. They are:

* the Fedora *source package name* (or *component name*, %{name}),
* the Fedora *built RPM name*,
* the *project name* used on *PyPI* or by *pip*, and
* the *importable module name* used in Python (a single package may have 
multiple importable modules).


Some examples (both good and worse):

| Fedora component  | Built RPM  | Project name  | Importable module   |
| - | -- | - | --- |
| `python-requests` | `python3-requests` | `requests`| `requests`  |
| `PyYAML`  | `python3-pyyaml`   | `pyyaml`  | `yaml`  |
| `python-ldap` | `python3-ldap` | `python-ldap` | `ldap`, `ldif`, etc.|
| `python-pillow`   | `python3-pillow`   | `pillow`  | `PIL`   |

---

python3dist() holds the "project name" (more specifically, the canonical form).

We use upstream metadata to generate python3.Xdist() requires. Upstreams specify 
dependencies in project names, not importable module names.



--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Packages that failed to build with Python 3.9

[Zbigniew Jędrzejewski-Szmek]

On Sun, May 31, 2020 at 01:09:31PM +0200, Miro Hrončok wrote:
> On 31. 05. 20 13:04, Zbigniew Jędrzejewski-Szmek wrote:
> > On Sun, May 31, 2020 at 10:49:28AM -, Leigh Scott wrote:
> > > Even if the package builds it doesn't mean it's functional.
> > > 
> > > $ cinnamon-settings
> > > Traceback (most recent call last):
> > >File "/usr/share/cinnamon/cinnamon-settings/cinnamon-settings.py", 
> > > line 16, in 
> > >  from setproctitle import setproctitle
> > > ImportError: 
> > > /usr/lib64/python3.9/site-packages/setproctitle.cpython-39-x86_64-linux-gnu.so:
> > >  undefined symbol: Py_GetArgcArgv
> > 
> > Idea for a global gating test for packages:
> > for rpm in $rpms; do
> >  python3 -c "$(rpm -qP $rpm | sed -n -r 's/python3dist\((.*)\).*/import 
> > \1/p')"
> > done
> 
> Unfortunately, this has a wrong assumption: python3dist(xxx) doesn't mean
> there is an xxx module to import. See for example:
> 
> python3-beautifulsoup4 provides python3.9dist(beautifulsoup4) but is
> imported as bs4. (I have plenty more examples like this... including
> python-fedora.)
> 
> A better thing might be to query for .py files, .so files and directories
> with such in %{python_sitelib}/%{python_sitearch}.

I always thought python3dist(foo) means that the package provides the
foo module, so that if I want to install foo module, I can rely on this
provides.

Zbyszek
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Packages that failed to build with Python 3.9

[Miro Hrončok]

On 31. 05. 20 13:04, Zbigniew Jędrzejewski-Szmek wrote:

On Sun, May 31, 2020 at 10:49:28AM -, Leigh Scott wrote:

Even if the package builds it doesn't mean it's functional.

$ cinnamon-settings
Traceback (most recent call last):
   File "/usr/share/cinnamon/cinnamon-settings/cinnamon-settings.py", line 16, in 

 from setproctitle import setproctitle
ImportError: 
/usr/lib64/python3.9/site-packages/setproctitle.cpython-39-x86_64-linux-gnu.so: 
undefined symbol: Py_GetArgcArgv


Idea for a global gating test for packages:
for rpm in $rpms; do
 python3 -c "$(rpm -qP $rpm | sed -n -r 's/python3dist\((.*)\).*/import 
\1/p')"
done


Unfortunately, this has a wrong assumption: python3dist(xxx) doesn't mean there 
is an xxx module to import. See for example:


python3-beautifulsoup4 provides python3.9dist(beautifulsoup4) but is imported as 
bs4. (I have plenty more examples like this... including python-fedora.)


A better thing might be to query for .py files, .so files and directories with 
such in %{python_sitelib}/%{python_sitearch}.



--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Packages that failed to build with Python 3.9

[Zbigniew Jędrzejewski-Szmek]

On Sun, May 31, 2020 at 10:49:28AM -, Leigh Scott wrote:
> Even if the package builds it doesn't mean it's functional.
> 
> $ cinnamon-settings
> Traceback (most recent call last):
>   File "/usr/share/cinnamon/cinnamon-settings/cinnamon-settings.py", line 16, 
> in 
> from setproctitle import setproctitle
> ImportError: 
> /usr/lib64/python3.9/site-packages/setproctitle.cpython-39-x86_64-linux-gnu.so:
>  undefined symbol: Py_GetArgcArgv

Idea for a global gating test for packages:
for rpm in $rpms; do
python3 -c "$(rpm -qP $rpm | sed -n -r 's/python3dist\((.*)\).*/import 
\1/p')"
done

;)

Zbyszek
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Packages that failed to build with Python 3.9

[Miro Hrončok]

On 31. 05. 20 12:49, Leigh Scott wrote:

Hello.

As you might already know, we have recently merged in the Python 3.9 side tag,
despite several builds have not succeeded. We always aim for some compromise
between having the side tag open for too long and having too many failures.

The packages, when not rebuilt, are not installable in rawhide, hence fixing
them should be our top priority. If you need help with Python related issues, we
(the Python Maintenance team at Red Hat) are happy to help. Unfortunately,
several packages fail to build for Python-unrelated reasons.

Some of the actual build failures already have a bugzilla open from our copr
rebuilds. Others don't have it yet because the error only manifested on some
architecture other than x86_64. I'll get back to this next week and open the
remaining bugzillas.

Most of the packages only fail to build because their dependencies were not yet
rebuilt. Chances are, you already got an automated bugzilla from Igor, that your
package fails to install. It would be really helpful if you could find the
missing dependency and mark the bugzilla for your package dependent on the
bugzilla for the missing dep. I slowly progress to do that as well, but your
help is crucial here.

Let me know if you have questions.


Even if the package builds it doesn't mean it's functional.

$ cinnamon-settings
Traceback (most recent call last):
   File "/usr/share/cinnamon/cinnamon-settings/cinnamon-settings.py", line 16, in 

 from setproctitle import setproctitle
ImportError: 
/usr/lib64/python3.9/site-packages/setproctitle.cpython-39-x86_64-linux-gnu.so: 
undefined symbol: Py_GetArgcArgv
[leigh@leigh ~]$ python
Python 3.9.0b1 (default, May 29 2020, 00:00:00)
[GCC 10.1.1 20200507 (Red Hat 10.1.1-1)] on linux
Type "help", "copyright", "credits" or "license" for more information.

from setproctitle import setproctitle

Traceback (most recent call last):
   File "", line 1, in 
ImportError: 
/usr/lib64/python3.9/site-packages/setproctitle.cpython-39-x86_64-linux-gnu.so: 
undefined symbol: Py_GetArgcArgv

import setproctitle

Traceback (most recent call last):
   File "", line 1, in 
ImportError: 
/usr/lib64/python3.9/site-packages/setproctitle.cpython-39-x86_64-linux-gnu.so: 
undefined symbol: Py_GetArgcArgv




Note that python-setproctitle already failed to built with Python 3.8 and the 
"fix" was to comment out the tests:


https://src.fedoraproject.org/rpms/python-setproctitle/c/d6d9620c3c4fa076b62ddfa7fdc39b0f70597dd6?branch=master

Hence, it built with Python 3.9 even if it doesn't work at all.

--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Packages that failed to build with Python 3.9

[Leigh Scott]

> Hello.
> 
> As you might already know, we have recently merged in the Python 3.9 side 
> tag, 
> despite several builds have not succeeded. We always aim for some compromise 
> between having the side tag open for too long and having too many failures.
> 
> The packages, when not rebuilt, are not installable in rawhide, hence fixing 
> them should be our top priority. If you need help with Python related issues, 
> we 
> (the Python Maintenance team at Red Hat) are happy to help. Unfortunately, 
> several packages fail to build for Python-unrelated reasons.
> 
> Some of the actual build failures already have a bugzilla open from our copr 
> rebuilds. Others don't have it yet because the error only manifested on some 
> architecture other than x86_64. I'll get back to this next week and open the 
> remaining bugzillas.
> 
> Most of the packages only fail to build because their dependencies were not 
> yet 
> rebuilt. Chances are, you already got an automated bugzilla from Igor, that 
> your 
> package fails to install. It would be really helpful if you could find the 
> missing dependency and mark the bugzilla for your package dependent on the 
> bugzilla for the missing dep. I slowly progress to do that as well, but your 
> help is crucial here.
> 
> Let me know if you have questions.
> 
Even if the package builds it doesn't mean it's functional.

$ cinnamon-settings
Traceback (most recent call last):
  File "/usr/share/cinnamon/cinnamon-settings/cinnamon-settings.py", line 16, 
in 
from setproctitle import setproctitle
ImportError: 
/usr/lib64/python3.9/site-packages/setproctitle.cpython-39-x86_64-linux-gnu.so: 
undefined symbol: Py_GetArgcArgv
[leigh@leigh ~]$ python
Python 3.9.0b1 (default, May 29 2020, 00:00:00) 
[GCC 10.1.1 20200507 (Red Hat 10.1.1-1)] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> from setproctitle import setproctitle
Traceback (most recent call last):
  File "", line 1, in 
ImportError: 
/usr/lib64/python3.9/site-packages/setproctitle.cpython-39-x86_64-linux-gnu.so: 
undefined symbol: Py_GetArgcArgv
>>> import setproctitle
Traceback (most recent call last):
  File "", line 1, in 
ImportError: 
/usr/lib64/python3.9/site-packages/setproctitle.cpython-39-x86_64-linux-gnu.so: 
undefined symbol: Py_GetArgcArgv
>>> 
___
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: [External] Re: Supporting hibernation in Workstation ed., draft 1

[Mark Pearson]

Hi

> -Original Message-
> From: Zbigniew Jędrzejewski-Szmek 
> Sent: Sunday, May 31, 2020 6:01 AM
> 
> On Sat, May 30, 2020 at 12:31:26AM +, Mark Pearson wrote:
> > > I've just taken a Lenovo T500, installed GNOME Workstation and gone into
> > > hibernation. It took about 30 seconds to boot back in, but I was right
> where I
> > > left off. What exactly is broken, and for what portion of users?
> > >
> > I can vouch that hibernate doesn't work on a bunch of platforms (including
> > the three that are part of the Lenovo+Fedora release). This is with secure
> > boot disabled, big enough swap etc. On my X1C7 the device just shuts down
> > and then it's as if you power cycled it when you power on again.
> >
> > I started poking at it a bit (we even have a RH bug somewhere) but in the
> > end have gone with "hibernate isn't supported" as the way forward.
> 
> Can you post the bugzilla number? (Even if it is not public, at least
> RH people can look at it.)
> 
Sure:
https://bugzilla.redhat.com/show_bug.cgi?id=1768623
Should be public - it's origins were around a trackpad issue during hibernate.
It's possible the problem is still there - we haven't reproduced it yet though.

Mark 
___
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: Soname bump gloox libgloox.so.13 -> 17

[David Schwörer]

On 5/31/20 12:31 PM, Björn 'besser82' Esser wrote:
> Am Sonntag, den 31.05.2020, 11:49 +0200 schrieb Björn 'besser82' Esser:
>> Am Sonntag, den 31.05.2020, 11:29 +0200 schrieb David Schwörer:
>>> If a proven packager could rebuild 0ad and uwsgi and submit an
>>> update,
>>> that would be great.
>>
>> Done so.  Waiting for the builds to finish.  Updates will be pushed
>> asap then.
> 
> 
> Updates have been submitted.
> 
>   * fRH:  https://bodhi.fedoraproject.org/updates/FEDORA-2020-ad6b1fe937
>   * f32:  https://bodhi.fedoraproject.org/updates/FEDORA-2020-167b67cb12
>   * f31:  https://bodhi.fedoraproject.org/updates/FEDORA-2020-b068f5ebc9
> 
> Cheers
> Björn
> 

Thanks a lot 👍
___
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: Soname bump gloox libgloox.so.13 -> 17

[Björn 'besser82' Esser]

Am Sonntag, den 31.05.2020, 11:49 +0200 schrieb Björn 'besser82' Esser:
> Am Sonntag, den 31.05.2020, 11:29 +0200 schrieb David Schwörer:
> > If a proven packager could rebuild 0ad and uwsgi and submit an
> > update,
> > that would be great.
> 
> Done so.  Waiting for the builds to finish.  Updates will be pushed
> asap then.


Updates have been submitted.

  * fRH:  https://bodhi.fedoraproject.org/updates/FEDORA-2020-ad6b1fe937
  * f32:  https://bodhi.fedoraproject.org/updates/FEDORA-2020-167b67cb12
  * f31:  https://bodhi.fedoraproject.org/updates/FEDORA-2020-b068f5ebc9

Cheers
Björn


signature.asc
Description: This is a digitally signed message part
___
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: Packaging problem

[Vascom]

This flag added by default for security reason. So if you don't want
support previous release or have no request to support it you can skip.

Or wait answer from upstream.

вс, 31 мая 2020 г., 13:27 :

> And is applying the workaround just for Fedora 31 tolerated ?
>
> - Mail original -
> De: "Vascom" 
> À: "Development discussions related to Fedora" <
> devel@lists.fedoraproject.org>
> Envoyé: Dimanche 31 Mai 2020 12:13:58
> Objet: Re: Packaging problem
>
>
>
> I think Qt will not be upgraded in F31.
>
>
> You can just skip build for F31 and make package for F32 and rawhide only.
>
>
> вс, 31 мая 2020 г., 13:08 < ycollette.nos...@free.fr >:
>
>
> I tested with Fedora 31 and, it hangs.
> I works fine with Fedora 32.
>
> I report this problem to Jamulus or to Qt ? I think this problem is
> already fixed on Fedora 32.
>
> Does a Qt5 update is programmed for Fedora 31 ?
>
> - Mail original -
> De: "Vascom" < vasc...@gmail.com >
> À: "Development discussions related to Fedora" <
> devel@lists.fedoraproject.org >
> Envoyé: Dimanche 31 Mai 2020 11:50:49
> Objet: Re: Packaging problem
>
>
>
> You should report upstream about the problem and fix code.
>
>
> вс, 31 мая 2020 г., 12:49 < ycollette.nos...@free.fr >:
>
>
> Hello again !
>
> I've got a new problem: a gcc flags trigger a problem during generation of
> an object file.
> The application is based on Qt5. The problematic file is produced from a
> moc generated file.
> The flag in question: -fcf-protection
>
> The solution I found is to send a custom set of flags to qmake.
>
> What is the best approach to remove a flags from a rpm macro variable ?
>
>
> # optflags %{__global_compiler_flags} -m64 -mtune=generic
> -fasynchronous-unwind-tables -fstack-clash-protection -fcf-protection
> # -fcf-protection produce an error in an object generatoin ...
>
> qmake-qt5 Jamulus.pro \
> QMAKE_CFLAGS_DEBUG="%{__global_compiler_flags} -m64 -mtune=generic
> -fasynchronous-unwind-tables -fstack-clash-protection" \
> QMAKE_CFLAGS_RELEASE="%{__global_compiler_flags} -m64 -mtune=generic
> -fasynchronous-unwind-tables -fstack-clash-protection" \
> QMAKE_CXXFLAGS_DEBUG="%{__global_compiler_flags} -m64 -mtune=generic
> -fasynchronous-unwind-tables -fstack-clash-protection" \
> QMAKE_CXXFLAGS_RELEASE="%{__global_compiler_flags} -m64 -mtune=generic
> -fasynchronous-unwind-tables -fstack-clash-protection" \
> CONFIG+=opus_shared_lib
>
> %make_build VERBOSE=1
>
>
>
> - Mail original -
> De: "ycollette nospam" < ycollette.nos...@free.fr >
> À: "Development discussions related to Fedora" <
> devel@lists.fedoraproject.org >
> Envoyé: Samedi 30 Mai 2020 21:58:55
> Objet: Re: Packaging problem
>
> OK, thanks, it works with %{qmake_qt5} but not with %_qt5_qmake ...
>
> Thanks a lot
>
> I see that qmake_qt5 macro call _qt5_qmake with some flags ...
> I found the macro via rpm --showrc | grep qmake and I choose the wrong
> result.
>
>
> - Mail original -
> De: "Vascom" < vasc...@gmail.com >
> À: "Development discussions related to Fedora" <
> devel@lists.fedoraproject.org >
> Envoyé: Samedi 30 Mai 2020 21:49:46
> Objet: Re: Packaging problem
>
> First you should use this macro %{qmake_qt5} and remove
> %{set_build_flags}.
>
> And show your spec or give srpm.
>
> сб, 30 мая 2020 г. в 22:21, < ycollette.nos...@free.fr >:
> >
> > Hello,
> >
> > I've got a problem with a package.
> > I am trying to clean up a spec file before sending it to review and I've
> got an error:
> >
> > erreur : Empty %files file
> /home/artelys/rpmbuild/BUILD/jamulus-c6b6e3ab02d7ec1e93edeeb8042a89a561924826/debugsourcefiles.list
>
> >
> > The code is Qt-5 / c++. It's an application which allows to perform live
> rehearsale via an internet connection.
> >
> > On the gcc / c++ command line, I can see the -g flags.
> >
> > The build section:
> >
> > %{set_build_flags}
> >
> > %_qt5_qmake Jamulus.pro CONFIG+=opus_shared_lib
> >
> > %make_build VERBOSE=1
> >
> > The install section (the qmake file defines no install rule so I must
> install everything manually):
> >
> > %__install -m 755 -d %{buildroot}/%{_bindir}/
> > %__install -m 755 Jamulus %{buildroot}%{_bindir}/jamulus
> >
> > %__install -m 755 -d %{buildroot}/%{_datadir}/applications/
> > %__install -m 644 distributions/jamulus.desktop
> %{buildroot}%{_datadir}/applications/
> >
> > %__install -m 755 -d %{buildroot}/%{_datadir}/pixmaps/
> > %__install -m 644 distributions/jamulus.png
> %{buildroot}%{_datadir}/pixmaps/
> >
> > How can I build the debug part of the package ?
> >
> > The only solution I've found is to add:
> >
> > %global debug_package %{nil}
> >
> > At the beginning of the spec file ...
> >
> > Best regards,
> >
> > YC
> > ___
> > 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://fedorapr

Re: Packaging problem

[ycollette . nospam]

And is applying the workaround just for Fedora 31 tolerated ?

- Mail original -
De: "Vascom" 
À: "Development discussions related to Fedora" 
Envoyé: Dimanche 31 Mai 2020 12:13:58
Objet: Re: Packaging problem



I think Qt will not be upgraded in F31. 


You can just skip build for F31 and make package for F32 and rawhide only. 


вс, 31 мая 2020 г., 13:08 < ycollette.nos...@free.fr >: 


I tested with Fedora 31 and, it hangs. 
I works fine with Fedora 32. 

I report this problem to Jamulus or to Qt ? I think this problem is already 
fixed on Fedora 32. 

Does a Qt5 update is programmed for Fedora 31 ? 

- Mail original - 
De: "Vascom" < vasc...@gmail.com > 
À: "Development discussions related to Fedora" < devel@lists.fedoraproject.org 
> 
Envoyé: Dimanche 31 Mai 2020 11:50:49 
Objet: Re: Packaging problem 



You should report upstream about the problem and fix code. 


вс, 31 мая 2020 г., 12:49 < ycollette.nos...@free.fr >: 


Hello again ! 

I've got a new problem: a gcc flags trigger a problem during generation of an 
object file. 
The application is based on Qt5. The problematic file is produced from a moc 
generated file. 
The flag in question: -fcf-protection 

The solution I found is to send a custom set of flags to qmake. 

What is the best approach to remove a flags from a rpm macro variable ? 


# optflags %{__global_compiler_flags} -m64 -mtune=generic 
-fasynchronous-unwind-tables -fstack-clash-protection -fcf-protection 
# -fcf-protection produce an error in an object generatoin ... 

qmake-qt5 Jamulus.pro \ 
QMAKE_CFLAGS_DEBUG="%{__global_compiler_flags} -m64 -mtune=generic 
-fasynchronous-unwind-tables -fstack-clash-protection" \ 
QMAKE_CFLAGS_RELEASE="%{__global_compiler_flags} -m64 -mtune=generic 
-fasynchronous-unwind-tables -fstack-clash-protection" \ 
QMAKE_CXXFLAGS_DEBUG="%{__global_compiler_flags} -m64 -mtune=generic 
-fasynchronous-unwind-tables -fstack-clash-protection" \ 
QMAKE_CXXFLAGS_RELEASE="%{__global_compiler_flags} -m64 -mtune=generic 
-fasynchronous-unwind-tables -fstack-clash-protection" \ 
CONFIG+=opus_shared_lib 

%make_build VERBOSE=1 



- Mail original - 
De: "ycollette nospam" < ycollette.nos...@free.fr > 
À: "Development discussions related to Fedora" < devel@lists.fedoraproject.org 
> 
Envoyé: Samedi 30 Mai 2020 21:58:55 
Objet: Re: Packaging problem 

OK, thanks, it works with %{qmake_qt5} but not with %_qt5_qmake ... 

Thanks a lot 

I see that qmake_qt5 macro call _qt5_qmake with some flags ... 
I found the macro via rpm --showrc | grep qmake and I choose the wrong result. 


- Mail original - 
De: "Vascom" < vasc...@gmail.com > 
À: "Development discussions related to Fedora" < devel@lists.fedoraproject.org 
> 
Envoyé: Samedi 30 Mai 2020 21:49:46 
Objet: Re: Packaging problem 

First you should use this macro %{qmake_qt5} and remove %{set_build_flags}. 

And show your spec or give srpm. 

сб, 30 мая 2020 г. в 22:21, < ycollette.nos...@free.fr >: 
> 
> Hello, 
> 
> I've got a problem with a package. 
> I am trying to clean up a spec file before sending it to review and I've got 
> an error: 
> 
> erreur : Empty %files file 
> /home/artelys/rpmbuild/BUILD/jamulus-c6b6e3ab02d7ec1e93edeeb8042a89a561924826/debugsourcefiles.list
>  
> 
> The code is Qt-5 / c++. It's an application which allows to perform live 
> rehearsale via an internet connection. 
> 
> On the gcc / c++ command line, I can see the -g flags. 
> 
> The build section: 
> 
> %{set_build_flags} 
> 
> %_qt5_qmake Jamulus.pro CONFIG+=opus_shared_lib 
> 
> %make_build VERBOSE=1 
> 
> The install section (the qmake file defines no install rule so I must install 
> everything manually): 
> 
> %__install -m 755 -d %{buildroot}/%{_bindir}/ 
> %__install -m 755 Jamulus %{buildroot}%{_bindir}/jamulus 
> 
> %__install -m 755 -d %{buildroot}/%{_datadir}/applications/ 
> %__install -m 644 distributions/jamulus.desktop 
> %{buildroot}%{_datadir}/applications/ 
> 
> %__install -m 755 -d %{buildroot}/%{_datadir}/pixmaps/ 
> %__install -m 644 distributions/jamulus.png %{buildroot}%{_datadir}/pixmaps/ 
> 
> How can I build the debug part of the package ? 
> 
> The only solution I've found is to add: 
> 
> %global debug_package %{nil} 
> 
> At the beginning of the spec file ... 
> 
> Best regards, 
> 
> YC 
> ___ 
> 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 
___ 
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-cond

Re: Packaging problem

[Vascom]

I think Qt will not be upgraded in F31.

You can just skip build for F31 and make package for F32 and rawhide only.

вс, 31 мая 2020 г., 13:08 :

> I tested with Fedora 31 and, it hangs.
> I works fine with Fedora 32.
>
> I report this problem to Jamulus or to Qt ? I think this problem is
> already fixed on Fedora 32.
>
> Does a Qt5 update is programmed for Fedora 31 ?
>
> - Mail original -
> De: "Vascom" 
> À: "Development discussions related to Fedora" <
> devel@lists.fedoraproject.org>
> Envoyé: Dimanche 31 Mai 2020 11:50:49
> Objet: Re: Packaging problem
>
>
>
> You should report upstream about the problem and fix code.
>
>
> вс, 31 мая 2020 г., 12:49 < ycollette.nos...@free.fr >:
>
>
> Hello again !
>
> I've got a new problem: a gcc flags trigger a problem during generation of
> an object file.
> The application is based on Qt5. The problematic file is produced from a
> moc generated file.
> The flag in question: -fcf-protection
>
> The solution I found is to send a custom set of flags to qmake.
>
> What is the best approach to remove a flags from a rpm macro variable ?
>
>
> # optflags %{__global_compiler_flags} -m64 -mtune=generic
> -fasynchronous-unwind-tables -fstack-clash-protection -fcf-protection
> # -fcf-protection produce an error in an object generatoin ...
>
> qmake-qt5 Jamulus.pro \
> QMAKE_CFLAGS_DEBUG="%{__global_compiler_flags} -m64 -mtune=generic
> -fasynchronous-unwind-tables -fstack-clash-protection" \
> QMAKE_CFLAGS_RELEASE="%{__global_compiler_flags} -m64 -mtune=generic
> -fasynchronous-unwind-tables -fstack-clash-protection" \
> QMAKE_CXXFLAGS_DEBUG="%{__global_compiler_flags} -m64 -mtune=generic
> -fasynchronous-unwind-tables -fstack-clash-protection" \
> QMAKE_CXXFLAGS_RELEASE="%{__global_compiler_flags} -m64 -mtune=generic
> -fasynchronous-unwind-tables -fstack-clash-protection" \
> CONFIG+=opus_shared_lib
>
> %make_build VERBOSE=1
>
>
>
> - Mail original -
> De: "ycollette nospam" < ycollette.nos...@free.fr >
> À: "Development discussions related to Fedora" <
> devel@lists.fedoraproject.org >
> Envoyé: Samedi 30 Mai 2020 21:58:55
> Objet: Re: Packaging problem
>
> OK, thanks, it works with %{qmake_qt5} but not with %_qt5_qmake ...
>
> Thanks a lot
>
> I see that qmake_qt5 macro call _qt5_qmake with some flags ...
> I found the macro via rpm --showrc | grep qmake and I choose the wrong
> result.
>
>
> - Mail original -
> De: "Vascom" < vasc...@gmail.com >
> À: "Development discussions related to Fedora" <
> devel@lists.fedoraproject.org >
> Envoyé: Samedi 30 Mai 2020 21:49:46
> Objet: Re: Packaging problem
>
> First you should use this macro %{qmake_qt5} and remove
> %{set_build_flags}.
>
> And show your spec or give srpm.
>
> сб, 30 мая 2020 г. в 22:21, < ycollette.nos...@free.fr >:
> >
> > Hello,
> >
> > I've got a problem with a package.
> > I am trying to clean up a spec file before sending it to review and I've
> got an error:
> >
> > erreur : Empty %files file
> /home/artelys/rpmbuild/BUILD/jamulus-c6b6e3ab02d7ec1e93edeeb8042a89a561924826/debugsourcefiles.list
>
> >
> > The code is Qt-5 / c++. It's an application which allows to perform live
> rehearsale via an internet connection.
> >
> > On the gcc / c++ command line, I can see the -g flags.
> >
> > The build section:
> >
> > %{set_build_flags}
> >
> > %_qt5_qmake Jamulus.pro CONFIG+=opus_shared_lib
> >
> > %make_build VERBOSE=1
> >
> > The install section (the qmake file defines no install rule so I must
> install everything manually):
> >
> > %__install -m 755 -d %{buildroot}/%{_bindir}/
> > %__install -m 755 Jamulus %{buildroot}%{_bindir}/jamulus
> >
> > %__install -m 755 -d %{buildroot}/%{_datadir}/applications/
> > %__install -m 644 distributions/jamulus.desktop
> %{buildroot}%{_datadir}/applications/
> >
> > %__install -m 755 -d %{buildroot}/%{_datadir}/pixmaps/
> > %__install -m 644 distributions/jamulus.png
> %{buildroot}%{_datadir}/pixmaps/
> >
> > How can I build the debug part of the package ?
> >
> > The only solution I've found is to add:
> >
> > %global debug_package %{nil}
> >
> > At the beginning of the spec file ...
> >
> > Best regards,
> >
> > YC
> > ___
> > 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
> ___
> 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

Fedora rawhide compose report: 20200530.n.0 changes

[Fedora Rawhide Report]

OLD: Fedora-Rawhide-20200529.n.2
NEW: Fedora-Rawhide-20200530.n.0

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

Size of added packages:  101.94 MiB
Size of dropped packages:233.84 KiB
Size of upgraded packages:   2.20 GiB
Size of downgraded packages: 0 B

Size change of upgraded packages:   -25.53 MiB
Size change of downgraded packages: 0 B

= ADDED IMAGES =
Image: LXQt raw-xz armhfp
Path: Spins/armhfp/images/Fedora-LXQt-armhfp-Rawhide-20200530.n.0-sda.raw.xz
Image: LXQt live x86_64
Path: Spins/x86_64/iso/Fedora-LXQt-Live-x86_64-Rawhide-20200530.n.0.iso

= DROPPED IMAGES =
Image: Workstation live ppc64le
Path: 
Workstation/ppc64le/iso/Fedora-Workstation-Live-ppc64le-Rawhide-20200529.n.2.iso

= ADDED PACKAGES =
Package: mudita24-1.1.0-1.20160218gite38b1a3.fc33
Summary: ALSA GUI control tool for Envy24 (ice1712) soundcards
RPMs:mudita24
Size:404.16 KiB

Package: python-pyvex-8.20.5.27-2.fc33
Summary: A Python interface to libVEX and the VEX intermediate representation
RPMs:python3-pyvex
Size:8.20 MiB

Package: python3.8-3.8.3-3.fc33
Summary: Version 3.8 of the Python interpreter
RPMs:python3.8
Size:93.34 MiB


= DROPPED PACKAGES =
Package: driftnet-0.1.6-42.20040426cvs.fc32
Summary: Network image sniffer
RPMs:driftnet
Size:233.84 KiB


= UPGRADED PACKAGES =
Package:  389-ds-base-1.4.4.3-1.fc33
Old package:  389-ds-base-1.4.4.2-1.fc33.2
Summary:  389 Directory Server (base)
RPMs: 389-ds-base 389-ds-base-devel 389-ds-base-legacy-tools 
389-ds-base-libs 389-ds-base-snmp cockpit-389-ds python3-lib389
Size: 20.43 MiB
Size change:  1.84 MiB
Changelog:
  * Fri May 29 2020 Mark Reynolds  - 1.4.4.3-1
  - Bump version to 1.4.4.3
  - Issue 50931 - RFE AD filter rewriter for ObjectCategory
  - Issue 50860 - Port Password Policy test cases from TET to python3 part1
  - Issue 51113 - Allow using uid for replication manager entry
  - Issue 51095 - abort operation if CSN can not be generated
  - Issue 51110 - Fix ASAN ODR warnings
  - Issue 49850 - ldbm_get_nonleaf_ids() painfully slow for databases with many 
non-leaf entries
  - Issue 51102 - RFE - ds-replcheck - make online timeout configurable
  - Issue 51076 - remove unnecessary slapi entry dups
  - Issue 51086 - Improve dscreate instance name validation
  - Issue:51070 - Port Import TET module to python3 part1
  - Issue 51037 - compiler warning
  - Issue 50989 - ignore pid when it is ourself in protect_db
  - Issue 51037 - RFE AD filter rewriter for ObjectSID
  - Issue 50499 - Fix some npm audit issues
  - Issue 51091 - healthcheck json report fails when mapping tree is deleted
  - Issue 51079 - container pid start and stop issues
  - Issue 49761 - Fix CI tests
  - Issue 50610 - Fix return code when it's nothing to free
  - Issue 50610 - memory leaks in dbscan and changelog encryption
  - Issue 51076 - prevent unnecessarily duplication of the target entry
  - Issue 50940 - Permissions of some shipped directories may change over time
  - Issue 50873 - Fix issues with healthcheck tool
  - Issue 51082 - abort when a empty valueset is freed
  - Issue 50201 - nsIndexIDListScanLimit accepts any value


Package:  ProDy-1.10.10-7.fc33
Old package:  ProDy-1.10.10-6.fc32
Summary:  Application for protein structure, dynamics and sequence analysis
RPMs: python3-ProDy
Size: 6.80 MiB
Size change:  -6.73 KiB
Changelog:
  * Tue May 26 2020 Miro Hron??ok  - 1.10.10-7
  - Rebuilt for Python 3.9


Package:  ansible-2.9.9-3.fc33
Old package:  ansible-2.9.9-1.fc33
Summary:  SSH-based configuration management, deployment, and task 
execution system
RPMs: ansible ansible-doc
Size: 25.64 MiB
Size change:  -9.55 KiB
Changelog:
  * Tue May 26 2020 Miro Hron??ok  - 2.9.9-2
  - Rebuilt for Python 3.9

  * Fri May 29 2020 Charalampos Stratakis  - 2.9.9-3
  - Fix Python 3.9 compatibility (#1808674)
  - Pin Pytest to version 4 for now


Package:  ansible-inventory-grapher-2.5.0-3.fc33
Old package:  ansible-inventory-grapher-2.5.0-2.fc32
Summary:  Creates graphs representing ansible inventory
RPMs: python3-ansible-inventory-grapher
Size: 33.29 KiB
Size change:  142 B
Changelog:
  * Tue May 26 2020 Miro Hron??ok  - 2.5.0-3
  - Rebuilt for Python 3.9


Package:  ansible-lint-4.2.0-4.fc33
Old package:  ansible-lint-4.2.0-3.fc33
Summary:  Best practices checker for Ansible
RPMs: python3-ansible-lint
Size: 91.03 KiB
Size change:  924 B
Changelog:
  * Tue May 26 2020 Miro Hron??ok  - 4.2.0-4
  - Rebuilt for Python 3.9


Package:  bpftrace-0.10.0-2.fc33
Old package:  bpftrace-0.10.0-1.fc33
Summary:  High-level tracing language for Linux eBPF
RPMs: bpftrace
Size: 3.55 MiB
Size change:  87.44 KiB
Changelog:
  * Tue May 19 2020 Augusto Caringi  - 0.10.0-2
  - Rebuilt for new 

Re: Packaging problem

[ycollette . nospam]

I tested with Fedora 31 and, it hangs.
I works fine with Fedora 32.

I report this problem to Jamulus or to Qt ? I think this problem is already 
fixed on Fedora 32.

Does a Qt5 update is programmed for Fedora 31 ?

- Mail original -
De: "Vascom" 
À: "Development discussions related to Fedora" 
Envoyé: Dimanche 31 Mai 2020 11:50:49
Objet: Re: Packaging problem



You should report upstream about the problem and fix code. 


вс, 31 мая 2020 г., 12:49 < ycollette.nos...@free.fr >: 


Hello again ! 

I've got a new problem: a gcc flags trigger a problem during generation of an 
object file. 
The application is based on Qt5. The problematic file is produced from a moc 
generated file. 
The flag in question: -fcf-protection 

The solution I found is to send a custom set of flags to qmake. 

What is the best approach to remove a flags from a rpm macro variable ? 


# optflags %{__global_compiler_flags} -m64 -mtune=generic 
-fasynchronous-unwind-tables -fstack-clash-protection -fcf-protection 
# -fcf-protection produce an error in an object generatoin ... 

qmake-qt5 Jamulus.pro \ 
QMAKE_CFLAGS_DEBUG="%{__global_compiler_flags} -m64 -mtune=generic 
-fasynchronous-unwind-tables -fstack-clash-protection" \ 
QMAKE_CFLAGS_RELEASE="%{__global_compiler_flags} -m64 -mtune=generic 
-fasynchronous-unwind-tables -fstack-clash-protection" \ 
QMAKE_CXXFLAGS_DEBUG="%{__global_compiler_flags} -m64 -mtune=generic 
-fasynchronous-unwind-tables -fstack-clash-protection" \ 
QMAKE_CXXFLAGS_RELEASE="%{__global_compiler_flags} -m64 -mtune=generic 
-fasynchronous-unwind-tables -fstack-clash-protection" \ 
CONFIG+=opus_shared_lib 

%make_build VERBOSE=1 



- Mail original - 
De: "ycollette nospam" < ycollette.nos...@free.fr > 
À: "Development discussions related to Fedora" < devel@lists.fedoraproject.org 
> 
Envoyé: Samedi 30 Mai 2020 21:58:55 
Objet: Re: Packaging problem 

OK, thanks, it works with %{qmake_qt5} but not with %_qt5_qmake ... 

Thanks a lot 

I see that qmake_qt5 macro call _qt5_qmake with some flags ... 
I found the macro via rpm --showrc | grep qmake and I choose the wrong result. 


- Mail original - 
De: "Vascom" < vasc...@gmail.com > 
À: "Development discussions related to Fedora" < devel@lists.fedoraproject.org 
> 
Envoyé: Samedi 30 Mai 2020 21:49:46 
Objet: Re: Packaging problem 

First you should use this macro %{qmake_qt5} and remove %{set_build_flags}. 

And show your spec or give srpm. 

сб, 30 мая 2020 г. в 22:21, < ycollette.nos...@free.fr >: 
> 
> Hello, 
> 
> I've got a problem with a package. 
> I am trying to clean up a spec file before sending it to review and I've got 
> an error: 
> 
> erreur : Empty %files file 
> /home/artelys/rpmbuild/BUILD/jamulus-c6b6e3ab02d7ec1e93edeeb8042a89a561924826/debugsourcefiles.list
>  
> 
> The code is Qt-5 / c++. It's an application which allows to perform live 
> rehearsale via an internet connection. 
> 
> On the gcc / c++ command line, I can see the -g flags. 
> 
> The build section: 
> 
> %{set_build_flags} 
> 
> %_qt5_qmake Jamulus.pro CONFIG+=opus_shared_lib 
> 
> %make_build VERBOSE=1 
> 
> The install section (the qmake file defines no install rule so I must install 
> everything manually): 
> 
> %__install -m 755 -d %{buildroot}/%{_bindir}/ 
> %__install -m 755 Jamulus %{buildroot}%{_bindir}/jamulus 
> 
> %__install -m 755 -d %{buildroot}/%{_datadir}/applications/ 
> %__install -m 644 distributions/jamulus.desktop 
> %{buildroot}%{_datadir}/applications/ 
> 
> %__install -m 755 -d %{buildroot}/%{_datadir}/pixmaps/ 
> %__install -m 644 distributions/jamulus.png %{buildroot}%{_datadir}/pixmaps/ 
> 
> How can I build the debug part of the package ? 
> 
> The only solution I've found is to add: 
> 
> %global debug_package %{nil} 
> 
> At the beginning of the spec file ... 
> 
> Best regards, 
> 
> YC 
> ___ 
> 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 
___ 
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 
___ 
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://fedorapro

Re: [External] Re: Supporting hibernation in Workstation ed., draft 1

[Zbigniew Jędrzejewski-Szmek]

On Sat, May 30, 2020 at 12:31:26AM +, Mark Pearson wrote:
> > I've just taken a Lenovo T500, installed GNOME Workstation and gone into
> > hibernation. It took about 30 seconds to boot back in, but I was right 
> > where I
> > left off. What exactly is broken, and for what portion of users?
> > 
> I can vouch that hibernate doesn't work on a bunch of platforms (including
> the three that are part of the Lenovo+Fedora release). This is with secure 
> boot disabled, big enough swap etc. On my X1C7 the device just shuts down 
> and then it's as if you power cycled it when you power on again.
> 
> I started poking at it a bit (we even have a RH bug somewhere) but in the 
> end have gone with "hibernate isn't supported" as the way forward.

Can you post the bugzilla number? (Even if it is not public, at least
RH people can look at it.)

> Happy to help with the exercise if there are any pointers or data needed, 
> guineau pig for testing etc. I didn't make much progress the last time I 
> looked at it 😊 I haven't seen much customer demand for it to be 
> honest - but I appreciate the reasons why some would like it.

Zbyszek
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Supporting hibernation in Workstation ed., draft 1

[Zbigniew Jędrzejewski-Szmek]

On Sat, May 30, 2020 at 11:34:38AM +0200, Jan Kratochvil wrote:
> Also I had to do 'echo freeze >/sys/power/state' for s2idle as systemctl has
> no such option (nor there is any GUI option for s3idle AFAIK).

SuspendState=freeze can be set through a configuration file.
See systemd-sleep.conf(5).

Zbyszek
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Packaging problem

[Vascom]

You should report upstream about the problem and fix code.

вс, 31 мая 2020 г., 12:49 :

> Hello again !
>
> I've got a new problem: a gcc flags trigger a problem during generation of
> an object file.
> The application is based on Qt5. The problematic file is produced from a
> moc generated file.
> The flag in question: -fcf-protection
>
> The solution I found is to send a custom set of flags to qmake.
>
> What is the best approach to remove a flags from a rpm macro variable ?
>
>
> # optflags   %{__global_compiler_flags} -m64 -mtune=generic
> -fasynchronous-unwind-tables -fstack-clash-protection -fcf-protection
> #  -fcf-protection produce an error in an object generatoin ...
>
> qmake-qt5 Jamulus.pro \
>   QMAKE_CFLAGS_DEBUG="%{__global_compiler_flags} -m64
> -mtune=generic -fasynchronous-unwind-tables -fstack-clash-protection" \
>   QMAKE_CFLAGS_RELEASE="%{__global_compiler_flags} -m64
> -mtune=generic -fasynchronous-unwind-tables -fstack-clash-protection" \
>   QMAKE_CXXFLAGS_DEBUG="%{__global_compiler_flags} -m64
> -mtune=generic -fasynchronous-unwind-tables -fstack-clash-protection" \
>   QMAKE_CXXFLAGS_RELEASE="%{__global_compiler_flags} -m64
> -mtune=generic -fasynchronous-unwind-tables -fstack-clash-protection" \
>   CONFIG+=opus_shared_lib
>
> %make_build VERBOSE=1
>
>
>
> - Mail original -
> De: "ycollette nospam" 
> À: "Development discussions related to Fedora" <
> devel@lists.fedoraproject.org>
> Envoyé: Samedi 30 Mai 2020 21:58:55
> Objet: Re: Packaging problem
>
> OK, thanks, it works with %{qmake_qt5} but not with %_qt5_qmake ...
>
> Thanks a lot
>
> I see that qmake_qt5  macro call _qt5_qmake with some flags ...
> I found the macro via rpm --showrc | grep qmake and I choose the wrong
> result.
>
>
> - Mail original -
> De: "Vascom" 
> À: "Development discussions related to Fedora" <
> devel@lists.fedoraproject.org>
> Envoyé: Samedi 30 Mai 2020 21:49:46
> Objet: Re: Packaging problem
>
> First you should use this macro %{qmake_qt5} and remove %{set_build_flags}.
>
> And show your spec or give srpm.
>
> сб, 30 мая 2020 г. в 22:21, :
> >
> > Hello,
> >
> > I've got a problem with a package.
> > I am trying to clean up a spec file before sending it to review and I've
> got an error:
> >
> > erreur : Empty %files file
> /home/artelys/rpmbuild/BUILD/jamulus-c6b6e3ab02d7ec1e93edeeb8042a89a561924826/debugsourcefiles.list
> >
> > The code is Qt-5 / c++. It's an application which allows to perform live
> rehearsale via an internet connection.
> >
> > On the gcc / c++ command line, I can see the -g flags.
> >
> > The build section:
> >
> > %{set_build_flags}
> >
> > %_qt5_qmake Jamulus.pro CONFIG+=opus_shared_lib
> >
> > %make_build VERBOSE=1
> >
> > The install section (the qmake file defines no install rule so I must
> install everything manually):
> >
> > %__install -m 755 -d %{buildroot}/%{_bindir}/
> > %__install -m 755 Jamulus %{buildroot}%{_bindir}/jamulus
> >
> > %__install -m 755 -d %{buildroot}/%{_datadir}/applications/
> > %__install -m 644 distributions/jamulus.desktop
> %{buildroot}%{_datadir}/applications/
> >
> > %__install -m 755 -d %{buildroot}/%{_datadir}/pixmaps/
> > %__install -m 644 distributions/jamulus.png
> %{buildroot}%{_datadir}/pixmaps/
> >
> > How can I build the debug part of the package ?
> >
> > The only solution I've found is to add:
> >
> > %global debug_package %{nil}
> >
> > At the beginning of the spec file ...
> >
> > Best regards,
> >
> > YC
> > ___
> > 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
> ___
> 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
> ___
> 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
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora

Re: Soname bump gloox libgloox.so.13 -> 17

[Björn 'besser82' Esser]

Am Sonntag, den 31.05.2020, 11:29 +0200 schrieb David Schwörer:
> If a proven packager could rebuild 0ad and uwsgi and submit an update,
> that would be great.


Done so.  Waiting for the builds to finish.  Updates will be pushed asap
then.

Cheers
Björn


signature.asc
Description: This is a digitally signed message part
___
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: Packaging problem

[ycollette . nospam]

Hello again !

I've got a new problem: a gcc flags trigger a problem during generation of an 
object file.
The application is based on Qt5. The problematic file is produced from a moc 
generated file.
The flag in question: -fcf-protection

The solution I found is to send a custom set of flags to qmake.

What is the best approach to remove a flags from a rpm macro variable ?


# optflags   %{__global_compiler_flags} -m64 -mtune=generic 
-fasynchronous-unwind-tables -fstack-clash-protection -fcf-protection
#  -fcf-protection produce an error in an object generatoin ...

qmake-qt5 Jamulus.pro \
  QMAKE_CFLAGS_DEBUG="%{__global_compiler_flags} -m64 -mtune=generic 
-fasynchronous-unwind-tables -fstack-clash-protection" \
  QMAKE_CFLAGS_RELEASE="%{__global_compiler_flags} -m64 -mtune=generic 
-fasynchronous-unwind-tables -fstack-clash-protection" \
  QMAKE_CXXFLAGS_DEBUG="%{__global_compiler_flags} -m64 -mtune=generic 
-fasynchronous-unwind-tables -fstack-clash-protection" \
  QMAKE_CXXFLAGS_RELEASE="%{__global_compiler_flags} -m64 
-mtune=generic -fasynchronous-unwind-tables -fstack-clash-protection" \
  CONFIG+=opus_shared_lib 

%make_build VERBOSE=1



- Mail original -
De: "ycollette nospam" 
À: "Development discussions related to Fedora" 
Envoyé: Samedi 30 Mai 2020 21:58:55
Objet: Re: Packaging problem

OK, thanks, it works with %{qmake_qt5} but not with %_qt5_qmake ...

Thanks a lot 

I see that qmake_qt5  macro call _qt5_qmake with some flags ...
I found the macro via rpm --showrc | grep qmake and I choose the wrong result.


- Mail original -
De: "Vascom" 
À: "Development discussions related to Fedora" 
Envoyé: Samedi 30 Mai 2020 21:49:46
Objet: Re: Packaging problem

First you should use this macro %{qmake_qt5} and remove %{set_build_flags}.

And show your spec or give srpm.

сб, 30 мая 2020 г. в 22:21, :
>
> Hello,
>
> I've got a problem with a package.
> I am trying to clean up a spec file before sending it to review and I've got 
> an error:
>
> erreur : Empty %files file 
> /home/artelys/rpmbuild/BUILD/jamulus-c6b6e3ab02d7ec1e93edeeb8042a89a561924826/debugsourcefiles.list
>
> The code is Qt-5 / c++. It's an application which allows to perform live 
> rehearsale via an internet connection.
>
> On the gcc / c++ command line, I can see the -g flags.
>
> The build section:
>
> %{set_build_flags}
>
> %_qt5_qmake Jamulus.pro CONFIG+=opus_shared_lib
>
> %make_build VERBOSE=1
>
> The install section (the qmake file defines no install rule so I must install 
> everything manually):
>
> %__install -m 755 -d %{buildroot}/%{_bindir}/
> %__install -m 755 Jamulus %{buildroot}%{_bindir}/jamulus
>
> %__install -m 755 -d %{buildroot}/%{_datadir}/applications/
> %__install -m 644 distributions/jamulus.desktop 
> %{buildroot}%{_datadir}/applications/
>
> %__install -m 755 -d %{buildroot}/%{_datadir}/pixmaps/
> %__install -m 644 distributions/jamulus.png %{buildroot}%{_datadir}/pixmaps/
>
> How can I build the debug part of the package ?
>
> The only solution I've found is to add:
>
> %global debug_package %{nil}
>
> At the beginning of the spec file ...
>
> Best regards,
>
> YC
> ___
> 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
___
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
___
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
___
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: Soname bump gloox libgloox.so.13 -> 17

[David Schwörer]

On 5/17/20 12:00 AM, David Schwörer wrote:
> Hi,
> 
> I am going to update gloox to the newest version.
> 
> I am going to build in the side tag f33-build-side-23466
> 
> 0ad and uwsgi need to be rebuild.
> 
> $ dnf repoquery --whatrequires gloox-devel --repo=rawhide-source
> 0ad-0:0.0.23b-13.fc33.src
> uwsgi-0:2.0.18-8.fc33.src
> 
> Cheers,
> David

I have also rebuild gloox also for f32 (f32-build-side-23743) and f31
(f31-build-side-23745).

If a proven packager could rebuild 0ad and uwsgi and submit an update,
that would be great.

Thanks,
David
___
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: new packages review tickets

[Mattia Verga via devel]

Thanks for all the comments and ideas you posted.

I have opened a pull request [1] to automate some of the processes 
against review-stats. If accepted it will:

- Set NEEDINFO against submitter on tickets not assigned and not updated 
for more than one year
- Set NEEDINFO against reviewer on tickets assigned and not updated for 
more than one year
- Reset ticket status and assignee on tickets where the assignee has not 
replied to the NEEDINFO for more than 1 month
- Close tickets where the submitter has not replied to the NEEDINFO for 
more than 1 month

If it had to be run now, it would set the NEEDINFO flag on 465 tickets 
and it would close as DEADREVIEW 30 tickets. I've uploaded the logfile 
[2] if you want to check the correctness. That means that nearly the 50% 
of all opened review tickets are stale by more than one year...

Mattia

[1] https://pagure.io/fedora-infra/review_stats/pull-request/6
[2] https://mattia.fedorapeople.org/review_stats/log.txt

___
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: Packages that failed to build with Python 3.9

[Miro Hrončok]

On 30. 05. 20 11:56, Ján ONDREJ (SAL) wrote:

Ahoj,


Hey. I'll try to answer.


   som trocha zmateny z tych hlaseni. Je skoda, ze bugzilla priamo neobsahuje
link na failed build.


The bugzillas don't contain the failed build link, because they are primarily 
"fails to install" and not "fails to build" bugzillas. In this particular case, 
the first is caused by the latter, but Igor's automation cannot know that.



Musim si ho pohladat sam. Skusal som rebuildnut tak
ako si mi vravel, teda cez mock s konfiguraciou copr repo, ale neviem preco,
tak ten build zbehne teraz bez problemov. Ale ked dam build priamo cez
fedpkg build, tak to nezbehne. To este nie je mergnute?
Ale divne je, ze preco mi mock -r fedora-rawhide-python39 ... zbehne.


The Python 3.9 copr is debugging tool only. It contains builds of genshi and 
chameleon done with Python 3.9.0a1, a2... etc. In Koji, we have started with b1 
and chameleon and genshi didn't build there. That's the reason why your packages 
build with copr-mock, but not in regular mock.



   Upravil som tie bugy a doplnil pozadovane depends. Hadam je to vsetko,
pretoze ani z koji build logov mi nie je uplne jasne, co z toho naozaj treba
a mozno ani nie. Pridal som aj pull-request pre chameleon, ale mam pocit,
ze ten maintainer je unresponsible.


I suggest you change the bugzillas to ASSIGNED, becasue you are clearly looking 
into it -- that way, others know you are on top of this and Igor's automation 
won't bother you.


Indeed, the chameleon bug received no maintainer response for a very long time. 
This way, the automation may as well render the package orphan and you can take it.


--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: F30 security update submitted for stable "marked obsolete" instead of being pushed

[Michael Schwendt]

On Fri, 29 May 2020 16:55:37 +0200, Kevin Kofler wrote:

> Miro Hrončok wrote:
> > AFAIK this was never the case, but I'm not sure. I remember in the past
> > the updates just kinda stuck in limbo (being pushed to stable for
> > eternity). At least now they are marked as obsolete.  
> 
> I think there really ought to be a guarantee that everything queued before 
> the deadline actually gets pushed in one last push, as opposed to saying 
> "sorry, the last push was actually hours earlier than the official deadline, 
> you're screwed forever because we will never do a push again for that 
> release".

With a properly implemented deadline, the Updates System would close its
doors at a well-defined time prior to a last push. Anything that has entered
the "pending -> stable" queue early enough, would be pushed. Everything else
would be locked and would not be able to change state from testing to stable,
for example.
___
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: Many packages unnecessarily link to libpython

[Honggang LI]

On Fri, May 29, 2020 at 06:47:35PM +0200, Petr Viktorin wrote:
> 
> 
> On 2020-05-18 03:53, Honggang LI wrote:
> > On Fri, May 15, 2020 at 02:12:00PM -0400, Charalampos Stratakis wrote:
> > > rdma-coredledford honli jwilson
> > 
> > rdma-core pyverbs must be linked with libpython38. For example,
> > 
> > build]$ nm ./python/pyverbs/mem_alloc.cpython-38-x86_64-linux-gnu.so | grep 
> > -w U |  grep  PyInterpreterState_GetID
> > U PyInterpreterState_GetID
> > 
> > Python-3.8.3]$ nm -a ./build/debug/libpython3.8d.so | grep 
> > PyInterpreterState_GetID
> > 000c6a82 T PyInterpreterState_GetID
> 
> This is exactly the case where the module should *not* be linked to
> /usr/lib64/libpython3.8.so.
> mem_alloc.cpython-38-x86_64-linux-gnu.so is a Python module, so it is loaded
> from Python when imported. The import will link link it to the particular
> Python interpreter it's imported into, which could be using a different
> libpython3.8.so (such as the debug version).

OK, I see the problem now. But I don't know how to handle this.

Let's take ../python/pyverbs/srq.cpython-39-x86_64-linux-gnu.so as
example.

1) Link with debug version.
[honli@localhost pyverbs (master)]$ gcc  -fPIC  -Wall -Wextra -Wno-sign-compare 
-Wno-unused-parameter -Wmissing-prototypes -Wmissing-declarations 
-Wwrite-strings -Wformat=2 -Wcast-function-type -Wformat-nonliteral -Wdate-time 
-Wnested-externs -Wshadow -Wstrict-prototypes -Wold-style-definition 
-Wredundant-decls -O2 -g -DNDEBUG  -Wl,--as-needed -Wl,--no-undefined -shared 
-Wl,-soname,srq.cpython-39-x86_64-linux-gnu.so -o 
../python/pyverbs/srq.cpython-39-x86_64-linux-gnu.so 
CMakeFiles/srq.cpython-39-x86_64-linux-gnu.dir/srq.c.o  
-Wl,-rpath,/home/honli/upstream/rdma-core/build/lib:  
../lib/librdmacm.so.1.2.30.0 ../lib/libibverbs.so.1.9.30.0 -lpython3.9d

[honli@localhost pyverbs (master)]$ ldd 
../python/pyverbs/srq.cpython-39-x86_64-linux-gnu.so
linux-vdso.so.1 (0x7fff2fbe4000)
libibverbs.so.1 => 
/home/honli/upstream/rdma-core/build/lib/libibverbs.so.1 (0x7feed22c3000)
libpython3.9d.so.1.0 => /lib64/libpython3.9d.so.1.0 (0x7feed1e6e000)
libc.so.6 => /lib64/libc.so.6 (0x7feed1ca3000)
libnl-route-3.so.200 => /lib64/libnl-route-3.so.200 (0x7feed1c1b000)
libnl-3.so.200 => /lib64/libnl-3.so.200 (0x7feed1bf7000)
libpthread.so.0 => /lib64/libpthread.so.0 (0x7feed1bd5000)
libdl.so.2 => /lib64/libdl.so.2 (0x7feed1bcc000)
libutil.so.1 => /lib64/libutil.so.1 (0x7feed1bc7000)
libm.so.6 => /lib64/libm.so.6 (0x7feed1a81000)
/lib64/ld-linux-x86-64.so.2 (0x7feed22f7000)

[honli@localhost pyverbs (master)]$ ldd 
../python/pyverbs/srq.cpython-39-x86_64-linux-gnu.so | grep libpython3.9d.so.1.0
libpython3.9d.so.1.0 => /lib64/libpython3.9d.so.1.0 (0x7f32570ac000)

[honli@localhost pyverbs (master)]$ rpm -qf /lib64/libpython3.9d.so.1.0
python3-debug-3.9.0~b1-3.fc33.x86_64

2) link with normal version
[honli@localhost pyverbs (master)]$ gcc  -fPIC  -Wall -Wextra -Wno-sign-compare 
-Wno-unused-parameter -Wmissing-prototypes -Wmissing-declarations 
-Wwrite-strings -Wformat=2 -Wcast-function-type -Wformat-nonliteral -Wdate-time 
-Wnested-externs -Wshadow -Wstrict-prototypes -Wold-style-definition 
-Wredundant-decls -O2 -g -DNDEBUG  -Wl,--as-needed -Wl,--no-undefined -shared 
-Wl,-soname,srq.cpython-39-x86_64-linux-gnu.so -o 
../python/pyverbs/srq.cpython-39-x86_64-linux-gnu.so 
CMakeFiles/srq.cpython-39-x86_64-linux-gnu.dir/srq.c.o  
-Wl,-rpath,/home/honli/upstream/rdma-core/build/lib:  
../lib/librdmacm.so.1.2.30.0 ../lib/libibverbs.so.1.9.30.0 -lpython3.9

[honli@localhost pyverbs (master)]$ ldd 
../python/pyverbs/srq.cpython-39-x86_64-linux-gnu.so | grep libpython3.9
libpython3.9.so.1.0 => /lib64/libpython3.9.so.1.0 (0x7f7f8a7c7000)

[honli@localhost pyverbs (master)]$ rpm -qf /lib64/libpython3.9.so.1.0
python3-libs-3.9.0~b1-3.fc33.x86_64

As you see, "-lpython3.9" or "-lpython3.9d" library must be provided to
the linker. Otherwise, a lot of "undefined reference to xxx" error
messages show up.

/home/honli/upstream/rdma-core/build/pyverbs/srq.c:10425: undefined reference 
to `PyErr_GivenExceptionMatches'
/home/honli/upstream/rdma-core/build/pyverbs/srq.c:8987: undefined reference to 
`_PyObject_GenericGetAttrWithDict'
/home/honli/upstream/rdma-core/build/pyverbs/srq.c:7786: undefined reference to 
`PyModuleDef_Init'

[honli@localhost pyverbs (master)]$ grep undefined error.txt |wc -l
876

Any hits how to handle this?

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.fedo

Fedora-Cloud-32-20200531.0 compose check report

[Fedora compose checker]

No missing expected images.

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

ID: 608243  Test: x86_64 Cloud_Base-qcow2-qcow2 cloud_autocloud
URL: https://openqa.fedoraproject.org/tests/608243
-- 
Mail generated by check-compose:
https://pagure.io/fedora-qa/check-compose
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org