Re: Packages with problematic license tag (for SPDX conversion)

[Miroslav Suchý]

Dne 31. 07. 24 v 11:14 dop. Vít Ondruch napsal(a):

warning: not valid neither as Callaway nor as SPDX, please check



How to reproduce this warning? 


These lines

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

My script put it there whenever both:

  $ license-validate --old LICENSE

  $ license-validate  LICENSE

fail.

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

Re: Packages with problematic license tag (for SPDX conversion)

[Vít Ondruch]

Dne 30. 07. 24 v 16:07 Miroslav Suchý napsal(a):


As the SPDX Change slowly finishes I focused on the license that I 
regularly report as:


  warning: not valid neither as Callaway nor as SPDX, please check



How to reproduce this warning?


Vít



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

Re: Packages with problematic license tag (for SPDX conversion)

[Petr Pisar]

V Tue, Jul 30, 2024 at 05:46:56PM -0400, Richard Fontana napsal(a):
> On Tue, Jul 30, 2024 at 1:24 PM Richard Shaw  wrote:
> >
> >> perl-RPC-XML hobbes1069 jplesnik ppisar
> >
> > This one I have no idea what to do with:
> > License:(Artistic 2.0 or Artistic or LGPLv2) and (Artistic 2.0 or 
> > LGPLv2)
>
> Just looked at this - it seemed to me that the author had intended to
> relicense from "Artistic" (not clear whether that referred to
> Artistic-1.0 or Artistic-1.0-Perl in SPDX parlance) to (again in SPDX
> parlance) Artistic-2.0 OR LGPL-2.1-only. I.e. I didn't see anything
> that seemed to obviously be licensed under Artistic-1.0* and the
> author seemed to (in later statements) use "Artistic License"
> specifically to mean Artistic-2.0. However, I only took a quick look.
> :)
> 
There are usefull comments in the spec file above the License tag. One of
the comments states that (Artistic 2.0 or Artistic or LGPLv2) is used by
etc/make_method file. That file reads:

# See "LICENSE AND COPYRIGHT" in the documentation for licensing and
# redistribution terms.
[...]
=head1 LICENSE AND COPYRIGHT

This module and the code within are released under the terms of the Artistic
License 2.0
(http://www.opensource.org/licenses/artistic-license-2.0.php). This code may
be redistributed under either the Artistic License or the GNU Lesser General
Public License (LGPL) version 2.1
(http://www.opensource.org/licenses/lgpl-2.1.php).

See how the author is not congruent when naming Artistic-like licenses.

The relicensing attempt, Richard mentioned, is documented in README.license:

Consider this confirmation that you may distribute it under the Artistic
License 2.0, as specified at
http://www.opensource.org/licenses/artistic-license-2.0.php

I am in the process of revising the licensing on all of my modules to be
dual-licensed under the above and also LGPL 2.1 as specified at
http://www.opensource.org/licenses/lgpl-2.1.php

However, because of other patches that have to be applied, integrated and
tested, it may be some time before a new RPC-XML release is made. Please 
take
this message as explicit permission to package and release under the 
licensing
terms you require. Thank you.

[...]
From: "Nick B" 
[...]
I can package it under 2.0, but I need your confirmation via e-mail
that this is okay.  Let me know your thoughts on this.

It's obvious that we are permitted to use Artistic-2.0. It's obvious that the
author intends to dual-license (Artistic-2.0 OR LGPL-2.1-only), but is not
yet clear whether he has already finished the relicensing. But going back to
etc/make_method, we are granted ("Artistic License" OR LGPL-2.1-only). Hence
I spelled the Callaway License tag as (Artistic 2.0 or Artistic or LGPLv2).
Simply naming all options, no effective licensing performed.

The problem with conversion to SPDX is that "Artistic" maps to multiple
Artistic-1.0-* license and we don't know which one it is. Also Fedora is not
willing to throw in free-standing for-Fedora-inapplicable Artistic-1.0-*
licenses into License tags.

So I agree with Richard, that the best option is remove the Artistic-1.0-*
options from the SPDX License tag. I.e. convert Callaway (Artistic 2.0 or
Artistic or LGPLv2) fragment into SPDX (Artistic-2.0 OR LGPL-2.1-only)
fragment.

I will convert the package for you.

-- Petr


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

Re: Packages with problematic license tag (for SPDX conversion)

[Miroslav Suchý]

Dne 30. 07. 24 v 11:54 odp. Kevin Fenzi napsal(a):

mxml is ASL-2.0 with a linking exception for "GPLv2 or LGPLv2"
(https://github.com/michaelrsweet/mxml/blob/master/NOTICE  )

Should that be:

apache-2.0 WITH GPL-Linking-Exception ?


GPL-Linking-Exception does not exists.
https://spdx.org/licenses/exceptions-index.html

Closest by name is|GPL-3.0-linking-exception:|

https://spdx.org/licenses/GPL-3.0-linking-exception.html

But the text does not match [1].

It almost matchhttps://spdx.org/licenses/LLVM-exception.html. But it miss one 
paragraph. So the exception will need either a markup change or it will be new 
exception. Please open issuehttps://gitlab.com/fedora/legal/fedora-license-data

So at the end it will be either "Apache-2.0 WITH LLVM-exception" or "Apache-2.0 WITH 
$BrandNewException".


[1] Great tool for the matching finding is this addon for FF or Chrome 
https://github.com/spdx/spdx-license-diff?tab=readme-ov-file#installation


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

Re: Packages with problematic license tag (for SPDX conversion)

[Kevin Fenzi]

On Tue, Jul 30, 2024 at 04:07:01PM GMT, Miroslav Suchý wrote:
...snip...
mxml kevin

mxml is ASL-2.0 with a linking exception for "GPLv2 or LGPLv2"
( https://github.com/michaelrsweet/mxml/blob/master/NOTICE )

Should that be: 

apache-2.0 WITH GPL-Linking-Exception ?

kevin


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

Re: Packages with problematic license tag (for SPDX conversion)

[Richard Fontana]

On Tue, Jul 30, 2024 at 1:24 PM Richard Shaw  wrote:
>
>> perl-RPC-XML hobbes1069 jplesnik ppisar
>
> This one I have no idea what to do with:
> License:(Artistic 2.0 or Artistic or LGPLv2) and (Artistic 2.0 or LGPLv2)

Just looked at this - it seemed to me that the author had intended to
relicense from "Artistic" (not clear whether that referred to
Artistic-1.0 or Artistic-1.0-Perl in SPDX parlance) to (again in SPDX
parlance) Artistic-2.0 OR LGPL-2.1-only. I.e. I didn't see anything
that seemed to obviously be licensed under Artistic-1.0* and the
author seemed to (in later statements) use "Artistic License"
specifically to mean Artistic-2.0. However, I only took a quick look.
:)

Richard

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

Re: Packages with problematic license tag (for SPDX conversion)

[Richard Fontana]

On Tue, Jul 30, 2024 at 11:22 AM Miroslav Suchý  wrote:
>
> Dne 30. 07. 24 v 4:40 odp. Miro Hrončok napsal(a):
>
> churchyard pypy pypy3.10 pypy3.9
>
>
> IMHO this uses a valid Callaway expression.
>
> It has UCD in it, which is not part of fedora-license-data, but it was listed 
> in the old wiki:
>
> There is https://fedoraproject.org/wiki/Licensing:UCD
>
> And it is listed in 
> https://fedoraproject.org/w/index.php?title=Licensing:Main=651191#Good_Licenses
>
> ---
>
> https://gitlab.com/fedora/legal/fedora-license-data/-/issues/30
>
> With last Richard comment from that issue I guess converting to Unicode-3.0 
> is the right step. Correct?

No, I think in context I was only commenting on the package
perl-Encode. Sorry, I see that is confusing in the issue comment
thread.

That issue does give some sense of the problem here, particularly this comment:
https://gitlab.com/fedora/legal/fedora-license-data/-/issues/30#note_1321684964

Still, Miro is correct, `UCD` is a valid Callaway abbreviation for a
license that was assumed to be "good" under the Callaway system. On
the other hand, any use of Callaway `UCD` is inherently problematic
because the Callaway classification doesn't really make any sense
under the principles underlying the Callaway system. I believe there
is another issue where I hypothesize that `UCD` was classified as
"good" because in possibly most cases where it seems to apply, the
license is bogus because the purportedly covered material is likely in
the public domain.

Richard

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

Re: Packages with problematic license tag (for SPDX conversion)

[Ben Beasley]

Thanks! The %{shrink: …} RPM macro is not extremely widespread, but I know 
there are other packages, especially but not exclusively Rust-based packages, 
that use it to break long license expressions. I’m not able to investigate 
right now, but I suspect you may be pleasantly surprised to find that this 
accounts for a number of the packages that are flagged as problematic or hard 
to parse.

On Tue, Jul 30, 2024, at 1:57 PM, Miroslav Suchý wrote:
> Dne 30. 07. 24 v 7:40 odp. Ben Beasley napsal(a):
>> Could you please take a look at rust-oxipng to see exactly what the tooling 
>> is complaining about? Everything in the spec file, 
>> https://src.fedoraproject.org/rpms/rust-oxipng/blob/rawhide/f/rust-oxipng.spec,
>>  looks like a valid SPDX expression to me. Thanks! 
> Ouch. My tooling things that second license in the spec is: {shrink:
>
> https://src.fedoraproject.org/rpms/rust-oxipng/blob/rawhide/f/rust-oxipng.spec#_33
>
> I see it is already in SPDX. I put your package on ignore list.
>
> Sorry for this false positive.
>
>
>
> -- 
> Miroslav Suchy, RHCA
> Red Hat, Manager, Packit and CPT, #brno, #fedora-buildsys
> -- 
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct: 
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: 
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
> Do not reply to spam, report it: 
> https://pagure.io/fedora-infrastructure/new_issue
-- 
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Packages with problematic license tag (for SPDX conversion)

[Miroslav Suchý]

Dne 30. 07. 24 v 7:40 odp. Ben Beasley napsal(a):

Could you please take a look at rust-oxipng to see exactly what the tooling is 
complaining about? Everything in the spec 
file,https://src.fedoraproject.org/rpms/rust-oxipng/blob/rawhide/f/rust-oxipng.spec,
 looks like a valid SPDX expression to me. Thanks!


Ouch. My tooling things that second license in the spec is: {shrink:

https://src.fedoraproject.org/rpms/rust-oxipng/blob/rawhide/f/rust-oxipng.spec#_33

I see it is already in SPDX. I put your package on ignore list.

Sorry for this false positive.


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

Re: Packages with problematic license tag (for SPDX conversion)

[Miroslav Suchý]

Dne 30. 07. 24 v 7:23 odp. Richard Shaw napsal(a):

Per upstream opencascade is "GNU Lesser General Public License (LGPL) version 2.1 
with additional exception"
https://dev.opencascade.org/resources/licensing

Does that translate to "LGPL-2.1-only with additional exception"?


No.

It should be:

   LGPL-2.1-only WITH $foo

WITH is SPDX operator. And $foo is one of the exception from this list

https://spdx.org/licenses/exceptions-index.html

I.e. the license must be precisely formulated. And has same matching guidelines 
as matchin license.

And importantly: the whole string must be listed as allowed for Fedora.

Check this example:

https://gitlab.com/fedora/legal/fedora-license-data/-/blob/main/data/Apache-2.0_WITH_Swift-exception.toml?ref_type=heads

   Apache-2.0 WITH Swift-exception

is allowed SPDX formula in Fedora. But

   Apache-2.0 WITH Bison-exception-2.2

is not allowed because no one reviewed for Fedora.




perl-RPC-XML hobbes1069 jplesnik ppisar

This one I have no idea what to do with:
License:    (Artistic 2.0 or Artistic or LGPLv2) and (Artistic 2.0 or LGPLv2)


$ license-fedora2spdx --verbose '(Artistic 2.0 or Artistic or LGPLv2) and 
(Artistic 2.0 or LGPLv2)'
Not a valid license string in legacy syntax. Pass '--verbose' to get full 
parser error.
No terminal matches 'A' in the current parser context, at line 1 col 18

(Artistic 2.0 or Artistic or LGPLv2) and (Artistic 2.0 or
 ^

This is because Artistic (legacy version of Artistic-1.0-Perl) is NOT allowed.

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

It is only allowed in combination with other license. Only approved combination 
are:

  GPL-1.0-or-later OR Artistic-1.0-Perl

  GPL-2.0-or-later OR Artistic-1.0-Perl

See https://docs.fedoraproject.org/en-US/legal/license-field/#perl-rules

If your case is different then please open issue against 
https://gitlab.com/fedora/legal/fedora-license-data



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

Re: Packages with problematic license tag (for SPDX conversion)

[Ben Beasley]

Could you please take a look at rust-oxipng to see exactly what the tooling is 
complaining about? Everything in the spec file, 
https://src.fedoraproject.org/rpms/rust-oxipng/blob/rawhide/f/rust-oxipng.spec, 
looks like a valid SPDX expression to me. Thanks!

On Tue, Jul 30, 2024, at 10:07 AM, Miroslav Suchý wrote:
> As the SPDX Change slowly finishes I focused on the license that I 
> regularly report as:
>
>   warning: not valid neither as Callaway nor as SPDX, please check
>
> These are license tags that are hard to automatically parse. It include 
> texts like "GPLv1 AND/OR GPLv2", free form description of exceptions, 
> licenses that were not listed in old Licensing wiki etc. And sometimes 
> just a typo. 
>
> If your package is listed below, I will be very glad if you check your 
> License tag and convert it to SPDX formula. 
>
> The general guidance for conversion is 
> https://docs.fedoraproject.org/en-US/legal/update-existing-packages/ 
> But if you still need a guidance, then please let me know. Either here 
> publicly or off-list.
>
> Maintainers by package: 
> Mayavi   chedi orion 
> OpenSceneGraph   smani 
> R-IRangesspot 
> R-lubridate  qulogic 
> ags  rathann 
> angelfishkkofler thunderbirdtr 
> avogadro2-libs   sagitter 
> bacula   slaanesh 
> bsh  didiksupriadi41 mizdebsk 
> clamav   gnat mstevens nb orion pwouters robert sergiomb steve 
> clementine   eclipseo 
> collectl kzak sharkcz 
> dcfldd   rebus 
> dumpasn1 fkooman 
> fcitx5-mozc  music yanqiyu 
> fedora-remix-logos   spot 
> fedora-workstation-backgrounds duffy luya ryanlerch 
> filebenchhushan 
> generic-release  bruno mohanboddu spot 
> ghc-control-monad-free mathstuf petersen 
> ghc-http-client  qulogic 
> golang-github-apache-arrow mikelo2 
> golang-gopkg-yaml-1  mikelo2 
> gstreamer1-doc   wtaymans 
> guayadeque   martinkg 
> hibernate-jpa-2.0-api jjelen 
> hydrarcallicotte rebus 
> icecat   kengert sagitter 
> innotop  echevemaster fale lbazan 
> jam  spot 
> jbosscache-support   orphan 
> julianalimilan 
> julius   spot 
> kclock   thunderbirdtr 
> khealthcertificate   ngompa thunderbirdtr 
> kmag aleasto rdieter than 
> konsole  rdieter than 
> kpublictransport ngompa thunderbirdtr 
> kscreen  rdieter 
> libcxx   nikic sergesanspaille spot tstellar tuliom 
> libkomparediff2  jgrulich kkofler rdieter than 
> libtimidity  aekoroglu jwrdegoede sagitter 
> libva-intel-hybrid-driver kwizart 
> lmms thm 
> lumina-desktop   tieugene 
> maatkit  slankes 
> man-pages-l10n   ljavorsk mfabian nforro 
> man2html orion patches sergiomb 
> mingw-wxWidgets  sailer 
> mingw-wxWidgets3 sailer 
> mxml kevin 
> niktohuzaifas rebus 
> ogre dtimms ignatenkobrain sergiomb 
> opencascade  hobbes1069 
> openjfx  deamn 
> openjfx8 deamn 
> perl-CDDB_getjplesnik ppisar 
> perl-Crypt-Blowfish  ixs 
> perl-Date-HolidayParser ppisar 
> perl-Devel-Caller-IgnoreNamespaces eseyman 
> perl-Lingua-Preferred eseyman xavierb 
> perl-LockFile-Simple ixs 
> perl-RPC-XML hobbes1069 jplesnik ppisar 
> perl-Statistics-CaseResampling jplesnik ppisar 
> perl-Test-Runjplesnik ppisar 
> perl-Tie-Hash-MultiValue ppisar 
> perl-Unicode-CheckUTF8 pghmcfc 
> perl-XML-Tinycicku eseyman 
> perl-forks   ppisar 
> perl-qooxdoo-compat  terjeros 
> php-pear-PHP-CodeSniffer cdamian remi 
> phpMyAdmin   remi robert 
> plasma-mobilefarchord 
> pokerth  pwalter 
> publican jfearn rlandmann 
> pypy churchyard thrnciar 
> pypy3.10 churchyard 
> pypy3.9  churchyard thrnciar 
> python-cclib sagitter 
> python-pyfacechedi ignatenkobrain orion 
> python-traitsui  chedi ignatenkobrain orion 
> python-utmp  jpopelka tuju 
> python-wxpython4 swt2c 
> qcad sagitter 
> qmmp kvolny 
> qt5-qtfeedback   jgrulich rdieter 
> rgbdsblowry 
> rubygem-rdoc vondruch 
> rubygem-xmlparserschwicke 
> rust-btrddcavalca 
> rust-dutree  kalev 
> rust-gmp-mpfr-sysdcavalca 
> rust-ifcfg-devname   jamacku 
> rust-nettle  decathorpe 
> rust-nettle-sys  decathorpe 
> rust-oxipng  music 
> rust-rav1e   decathorpe 
> rust-rpick   bowlofeggs 
> rust-ybaas   decathorpe 
> rust-yubibombdecathorpe 
> rust-zbase32 decathorpe 
> scantailor   xhorak 
> scummvm  chkr lucilanga 
> simple-scan  amigadave dodji 

Re: Packages with problematic license tag (for SPDX conversion)

[Tulio Magno Quites Machado Filho]

Miroslav Suchý  writes:

> The "BSD" is the problematic part. You should find which BSD it is. Usually 
> BSD-2-Clause or BSD-3-Clause.

I see... I'm proposing a fix here:
https://src.fedoraproject.org/rpms/libcxx/pull-request/51

Thanks!

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

Re: Packages with problematic license tag (for SPDX conversion)

[Richard Shaw]

On Tue, Jul 30, 2024 at 9:08 AM Miroslav Suchý  wrote:

> As the SPDX Change slowly finishes I focused on the license that I
> regularly report as:
>
>   warning: not valid neither as Callaway nor as SPDX, please check
>
> These are license tags that are hard to automatically parse. It include
> texts like "GPLv1 AND/OR GPLv2", free form description of exceptions,
> licenses that were not listed in old Licensing wiki etc. And sometimes just
> a typo.
>
> If your package is listed below, I will be very glad if you check your
> License tag and convert it to SPDX formula.
>
> The general guidance for conversion is
> https://docs.fedoraproject.org/en-US/legal/update-existing-packages/ But
> if you still need a guidance, then please let me know. Either here publicly
> or off-list.
>
> Maintainers by package:
> opencascade  hobbes1069
>
Per upstream opencascade is "GNU Lesser General Public License (LGPL)
version 2.1 with additional exception"
https://dev.opencascade.org/resources/licensing

Does that translate to "LGPL-2.1-only with additional exception"?

perl-RPC-XML hobbes1069 jplesnik ppisar
>
This one I have no idea what to do with:
License:(Artistic 2.0 or Artistic or LGPLv2) and (Artistic 2.0 or
LGPLv2)

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

Re: Packages with problematic license tag (for SPDX conversion)

[Miroslav Suchý]

Dne 30. 07. 24 v 5:05 odp. Tulio Magno Quites Machado Filho napsal(a):

Miroslav Suchý  writes:


libcxx   nikic sergesanspaille spot tstellar tuliom

I believe this project got listed by mistake.
Its current license is: Apache-2.0 WITH LLVM-exception OR MIT OR NCSA

Isn't this a valid SPDX expression?


This one is correct, but

https://src.fedoraproject.org/rpms/libcxx/blob/rawhide/f/libcxx.spec#_116

is not. The "BSD" is the problematic part. You should find which BSD it is. 
Usually BSD-2-Clause or BSD-3-Clause.

--
Miroslav Suchy, RHCA
Red Hat, Manager, Packit and CPT, #brno, #fedora-buildsys

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

Re: Packages with problematic license tag (for SPDX conversion)

[Miroslav Suchý]

Dne 30. 07. 24 v 4:40 odp. Miro Hrončok napsal(a):

churchyard pypy pypy3.10 pypy3.9


IMHO this uses a valid Callaway expression.

It has UCD in it, which is not part of fedora-license-data, but it was listed 
in the old wiki:

There is https://fedoraproject.org/wiki/Licensing:UCD

And it is listed in 
https://fedoraproject.org/w/index.php?title=Licensing:Main=651191#Good_Licenses

---

https://gitlab.com/fedora/legal/fedora-license-data/-/issues/30


With last Richard comment from that issue I guess converting to Unicode-3.0 is 
the right step. Correct?




I attempted to convert PyPy to SPDX license in 
https://src.fedoraproject.org/fork/churchyard/rpms/pypy3.9/commits/7.3.12-spdx


But there was some negative feedback to my conversion:

https://src.fedoraproject.org/rpms/pypy3.9/pull-request/38#comment-152929

Help is appreciated. PyPy has a lot of code taken here and there in it. 


The best start is to open issue against https://gitlab.com/fedora/legal/fedora-license-data/ and ask if it is 
significant change. (Usually) Richard check the license and recommends whether it should be submitted to SPDX as a new 
license or if we should ask to amend the markup of the definition of the license to allow the variance.


You can see such example in https://gitlab.com/fedora/legal/fedora-license-data/-/issues/485 and 
https://github.com/spdx/license-list-XML/issues/2406


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

Re: Packages with problematic license tag (for SPDX conversion)

[Tulio Magno Quites Machado Filho]

Miroslav Suchý  writes:

> libcxx   nikic sergesanspaille spot tstellar tuliom

I believe this project got listed by mistake.
Its current license is: Apache-2.0 WITH LLVM-exception OR MIT OR NCSA

Isn't this a valid SPDX expression?

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

Re: Packages with problematic license tag (for SPDX conversion)

[Miro Hrončok]

On 30. 07. 24 16:07, Miroslav Suchý wrote:

churchyard pypy pypy3.10 pypy3.9


IMHO this uses a valid Callaway expression.

It has UCD in it, which is not part of fedora-license-data, but it was listed 
in the old wiki:


There is https://fedoraproject.org/wiki/Licensing:UCD

And it is listed in 
https://fedoraproject.org/w/index.php?title=Licensing:Main=651191#Good_Licenses


---

https://gitlab.com/fedora/legal/fedora-license-data/-/issues/30

---

I attempted to convert PyPy to SPDX license in 
https://src.fedoraproject.org/fork/churchyard/rpms/pypy3.9/commits/7.3.12-spdx


But there was some negative feedback to my conversion:

https://src.fedoraproject.org/rpms/pypy3.9/pull-request/38#comment-152929

Help is appreciated. PyPy has a lot of code taken here and there in it.

--
Miro Hrončok
--
Phone: +420777974800
Fedora Matrix: mhroncok

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

[EPEL-devel] Re: Packages to be untagged from epel-next

[Tuomo Soini]

On Sat, 18 Nov 2023 14:40:19 +
Sérgio Basto  wrote:

> On Sat, 2023-11-18 at 09:35 +0200, Tuomo Soini wrote:
> > On Fri, 17 Nov 2023 21:31:37 +
> > Sérgio Basto  wrote:
> >   
> > > Hi, 
> > > Is not an negative feedback, is a side note but I realize some
> > > time ago that version with next is bigger than version without
> > > next [1] therefore we should find a way that the el8 version be
> > > greater than the el8.next version.
> > > 
> > > 
> > > [1] 
> > > 
> > > rpmdev-vercmp 1.el8.next 1.el8
> > > 
> > > 1.el8.next > 1.el8
> > >   
> > 
> > I already suggested adding requirement to do a release bump when
> > building from epel-next to epel.
> > 
> > https://pagure.io/epel/pull-request/259
> > 
> > I find it important that new, compatible with new rhel build has
> > bigger
> > version-release than epel-next build.
> >   
> 
> I just tested 
> 
> rpmdev-vercmp 1.el8.next 1.el8
> 1.el8.next > 1.el8
> 
> rpmdev-vercmp 1.el8.next 1.el8.1
> 1.el8.next < 1.el8.1
> 
> 
> so rpmdev-bumpspec --rightmost is enough 
> 

Yes. If that would be required for epel-next build, building for
epel later would automatically override .next release, even without any
change to release.

That is because:

rpmdev-vercmp 1.el8.next.1 1.el8.1
1.el8.next.1 < 1.el8.1

-- 
Tuomo Soini 
Foobar Linux services
+358 40 5240030
Foobar Oy 
--
___
epel-devel mailing list -- epel-devel@lists.fedoraproject.org
To unsubscribe send an email to epel-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/epel-devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

[EPEL-devel] Re: Packages to be untagged from epel-next

[Sérgio Basto]

On Sat, 2023-11-18 at 09:35 +0200, Tuomo Soini wrote:
> On Fri, 17 Nov 2023 21:31:37 +
> Sérgio Basto  wrote:
> 
> > Hi, 
> > Is not an negative feedback, is a side note but I realize some time
> > ago that version with next is bigger than version without next [1]
> > therefore we should find a way that the el8 version be greater than
> > the el8.next version.
> > 
> > 
> > [1] 
> > 
> > rpmdev-vercmp 1.el8.next 1.el8
> > 
> > 1.el8.next > 1.el8
> > 
> 
> I already suggested adding requirement to do a release bump when
> building from epel-next to epel.
> 
> https://pagure.io/epel/pull-request/259
> 
> I find it important that new, compatible with new rhel build has
> bigger
> version-release than epel-next build.
> 

I just tested 

rpmdev-vercmp 1.el8.next 1.el8
1.el8.next > 1.el8

rpmdev-vercmp 1.el8.next 1.el8.1
1.el8.next < 1.el8.1


so rpmdev-bumpspec --rightmost is enough 


> -- 
> Tuomo Soini 
> Foobar Linux services
> +358 40 5240030
> Foobar Oy 
> --
> ___
> epel-devel mailing list -- epel-devel@lists.fedoraproject.org
> To unsubscribe send an email to
> epel-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/epel-devel@lists.fedoraproject.org
> Do not reply to spam, report it:
> https://pagure.io/fedora-infrastructure/new_issue

-- 
Sérgio M. B.
--
___
epel-devel mailing list -- epel-devel@lists.fedoraproject.org
To unsubscribe send an email to epel-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/epel-devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

[EPEL-devel] Re: Packages to be untagged from epel-next

[Tuomo Soini]

On Fri, 17 Nov 2023 21:31:37 +
Sérgio Basto  wrote:

> Hi, 
> Is not an negative feedback, is a side note but I realize some time
> ago that version with next is bigger than version without next [1]
> therefore we should find a way that the el8 version be greater than
> the el8.next version.
> 
> 
> [1] 
> 
> rpmdev-vercmp 1.el8.next 1.el8
> 
> 1.el8.next > 1.el8
> 

I already suggested adding requirement to do a release bump when
building from epel-next to epel.

https://pagure.io/epel/pull-request/259

I find it important that new, compatible with new rhel build has bigger
version-release than epel-next build.

-- 
Tuomo Soini 
Foobar Linux services
+358 40 5240030
Foobar Oy 
--
___
epel-devel mailing list -- epel-devel@lists.fedoraproject.org
To unsubscribe send an email to epel-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/epel-devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

[EPEL-devel] Re: Packages to be untagged from epel-next

[Sérgio Basto]

Hi, 
Is not an negative feedback, is a side note but I realize some time
ago that version with next is bigger than version without next [1]
therefore we should find a way that the el8 version be greater than the
el8.next version.


[1] 

rpmdev-vercmp 1.el8.next 1.el8

1.el8.next > 1.el8



On Fri, 2023-11-17 at 09:24 -0800, Troy Dawson wrote:
> I haven't heard any negative feedback from these.
> I will untag these today.
> 
> On Wed, Nov 15, 2023 at 12:55 PM Troy Dawson 
> wrote:
> > The following packages have the same version in epel-next as in
> > epel.
> > I plan on untagging them from epel-next unless people tell me
> > otherwise.
> > 
> > epel8-next:
> > boinc-client-7.20.2-1.el8.next
> > darktable-3.8.1-2.el8.next
> > kimageannotator-0.6.1-1.el8.next
> > ksnip-1.10.1-1.el8.next
> > python3.11-dns-epel-2.2.1-2.el8.next
> > python3.11-jmespath-epel-1.0.1-1.el8.next
> > 
> > epel9-next:
> > cargo2rpm-0.1.13-1.el9.next
> > keepassxc-2.7.6-1.el9.next
> > python3.11-dns-epel-2.2.1-2.el9.next
> > python3.11-jmespath-epel-1.0.1-1.el9.next
> > python3.11-netaddr-epel-0.8.0-1.el9.next
> > python3.11-ntlm-auth-epel-1.5.0-1.el9.next
> > rust-addr2line-0.19.0-1.el9.next
> > rust-aho-corasick-1.1.2-1.el9.next
> > rust-ansiterm-0.12.2-1.el9.next
> > rust-arbitrary-1.3.0-1.el9.next
> > rust-automod-1.0.13-1.el9.next
> > rust-backtrace-0.3.67-2.el9.next
> > rust-bitflags-2.4.1-1.el9.next
> > rust-bstr0.2-0.2.17-1.el9.next
> > rust-bstr-1.7.0-1.el9.next
> > rust-bumpalo-3.14.0-1.el9.next
> > rust-bytesize-1.3.0-1.el9.next
> > rust-byte-unit-4.0.19-1.el9.next
> > rust-cargo-0.64.0-3.el9.next
> > rust-clap3-3.2.25-1.el9.next
> > rust-clap_complete3-3.2.5-1.el9.next
> > rust-clap_derive3-3.2.25-1.el9.next
> > rust-crossbeam-epoch-0.9.15-2.el9.next
> > rust-csv-1.3.0-1.el9.next
> > rust-csv-core-0.1.11-1.el9.next
> > rust-ctor-0.2.5-1.el9.next
> > rust-deranged-0.3.8-1.el9.next
> > rust-directories4-4.0.1-1.el9.next
> > rust-directories-5.0.1-1.el9.next
> > rust-env_logger-0.10.0-1.el9.next
> > rust-env_logger0.9-0.9.3-1.el9.next
> > rust-grep-cli-0.1.7-1.el9.next
> > rust-grep-printer-0.1.7-1.el9.next
> > rust-grep-regex-0.1.11-1.el9.next
> > rust-grep-searcher-0.1.11-1.el9.next
> > rust-half1-1.8.2-1.el9.next
> > rust-hashbrown-0.14.2-1.el9.next
> > rust-ignore-0.4.20-1.el9.next
> > rust-indexmap-2.0.2-1.el9.next
> > rust-is_executable-1.0.1-1.el9.next
> > rust-jobserver-0.1.27-1.el9.next
> > rust-lexopt-0.3.0-1.el9.next
> > rust-libc-0.2.149-1.el9.next
> > rust-libm-0.2.8-1.el9.next
> > rust-lock_api-0.4.11-1.el9.next
> > rust-memchr-2.6.4-1.el9.next
> > rust-miniz_oxide0.5-0.5.4-1.el9.next
> > rust-miniz_oxide-0.7.1-3.el9.next
> > rust-num_enum-0.5.11-1.el9.next
> > rust-num_enum_derive-0.5.11-1.el9.next
> > rust-num-traits-0.2.17-1.el9.next
> > rust-object-0.30.3-1.el9.next
> > rust-os_pipe0.9-0.9.2-3.el9.next
> > rust-os_str_bytes-6.6.1-1.el9.next
> > rust-packaging-25.2-1.el9.next
> > rust-parking_lot_core-0.9.9-1.el9.next
> > rust-predicates-core-1.0.6-1.el9.next
> > rust-print_bytes-1.2.0-1.el9.next
> > rust-proc-macro2-1.0.69-1.el9.next
> > rust-rayon-1.8.0-1.el9.next
> > rust-rayon-core-1.12.0-1.el9.next
> > rust-regex-1.10.2-1.el9.next
> > rust-regex-automata-0.4.3-1.el9.next
> > rust-regex-syntax0.7-0.7.5-1.el9.next
> > rust-regex-syntax-0.8.2-1.el9.next
> > rust-relative-path-1.9.0-1.el9.next
> > rust-roff0.1-0.1.0-1.el9.next
> > rust-roff-0.2.1-1.el9.next
> > rust-rpassword5-5.0.1-1.el9.next
> > rust-rpassword-7.2.0-1.el9.next
> > rust-rstest-0.18.2-1.el9.next
> > rust-rstest_macros-0.18.2-1.el9.next
> > rust-rstest_reuse-0.6.0-1.el9.next
> > rust-rtoolbox-0.0.1-1.el9.next
> > rust-rust_decimal-1.32.0-1.el9.next
> > rust-serde-1.0.189-1.el9.next
> > rust-serde_derive-1.0.189-1.el9.next
> > rust-serde_json-1.0.107-1.el9.next
> > rust-shared_child-1.0.0-3.el9.next
> > rust-smallvec-1.11.1-1.el9.next
> > rust-strip-ansi-escapes0.1-0.1.1-1.el9.next
> > rust-strip-ansi-escapes-0.2.0-1.el9.next
> > rust-syn-2.0.38-1.el9.next
> > rust-system-deps-6.1.2-1.el9.next
> > rust-tempfile-3.8.0-1.el9.next
> > rust-termcolor-1.3.0-1.el9.next
> > rust-terminal_size0.2-0.2.6-1.el9.next
> > rust-terminal_size-0.3.0-1.el9.next
> > rust-textwrap0.15-0.15.2-1.el9.next
> > rust-textwrap-0.16.0-1.el9.next
> > rust-thread-id-4.2.1-1.el9.next
> > rust-timeago-0.4.2-1.el9.next
> > rust-time-core-0.1.1-1.el9.next
> > rust-toml0.5-0.5.11-1.el9.next
> > rust-toml0.7-0.7.8-1.el9.next
> > rust-toml-0.8.2-1.el9.next
> > rust-toml_edit0.19-0.19.15-1.el9.next
> > rust-toml_edit-0.20.2-1.el9.next
> > rust-ucd-parse-0.1.10-1.el9.next
> > rust-winnow0.4-0.4.11-1.el9.next
> > rust-winnow-0.5.16-1.el9.next
> > rust-xml-rs-0.8.19-1.el9.next
> > 
> > 
> > Troy
> > 
> --
> ___
> epel-devel mailing list -- epel-devel@lists.fedoraproject.org
> To unsubscribe send an email to
> epel-devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/

[EPEL-devel] Re: Packages to be untagged from epel-next

[Troy Dawson]

I haven't heard any negative feedback from these.
I will untag these today.

On Wed, Nov 15, 2023 at 12:55 PM Troy Dawson  wrote:

> The following packages have the same version in epel-next as in epel.
> I plan on untagging them from epel-next unless people tell me otherwise.
>
> epel8-next:
> boinc-client-7.20.2-1.el8.next
> darktable-3.8.1-2.el8.next
> kimageannotator-0.6.1-1.el8.next
> ksnip-1.10.1-1.el8.next
> python3.11-dns-epel-2.2.1-2.el8.next
> python3.11-jmespath-epel-1.0.1-1.el8.next
>
> epel9-next:
> cargo2rpm-0.1.13-1.el9.next
> keepassxc-2.7.6-1.el9.next
> python3.11-dns-epel-2.2.1-2.el9.next
> python3.11-jmespath-epel-1.0.1-1.el9.next
> python3.11-netaddr-epel-0.8.0-1.el9.next
> python3.11-ntlm-auth-epel-1.5.0-1.el9.next
> rust-addr2line-0.19.0-1.el9.next
> rust-aho-corasick-1.1.2-1.el9.next
> rust-ansiterm-0.12.2-1.el9.next
> rust-arbitrary-1.3.0-1.el9.next
> rust-automod-1.0.13-1.el9.next
> rust-backtrace-0.3.67-2.el9.next
> rust-bitflags-2.4.1-1.el9.next
> rust-bstr0.2-0.2.17-1.el9.next
> rust-bstr-1.7.0-1.el9.next
> rust-bumpalo-3.14.0-1.el9.next
> rust-bytesize-1.3.0-1.el9.next
> rust-byte-unit-4.0.19-1.el9.next
> rust-cargo-0.64.0-3.el9.next
> rust-clap3-3.2.25-1.el9.next
> rust-clap_complete3-3.2.5-1.el9.next
> rust-clap_derive3-3.2.25-1.el9.next
> rust-crossbeam-epoch-0.9.15-2.el9.next
> rust-csv-1.3.0-1.el9.next
> rust-csv-core-0.1.11-1.el9.next
> rust-ctor-0.2.5-1.el9.next
> rust-deranged-0.3.8-1.el9.next
> rust-directories4-4.0.1-1.el9.next
> rust-directories-5.0.1-1.el9.next
> rust-env_logger-0.10.0-1.el9.next
> rust-env_logger0.9-0.9.3-1.el9.next
> rust-grep-cli-0.1.7-1.el9.next
> rust-grep-printer-0.1.7-1.el9.next
> rust-grep-regex-0.1.11-1.el9.next
> rust-grep-searcher-0.1.11-1.el9.next
> rust-half1-1.8.2-1.el9.next
> rust-hashbrown-0.14.2-1.el9.next
> rust-ignore-0.4.20-1.el9.next
> rust-indexmap-2.0.2-1.el9.next
> rust-is_executable-1.0.1-1.el9.next
> rust-jobserver-0.1.27-1.el9.next
> rust-lexopt-0.3.0-1.el9.next
> rust-libc-0.2.149-1.el9.next
> rust-libm-0.2.8-1.el9.next
> rust-lock_api-0.4.11-1.el9.next
> rust-memchr-2.6.4-1.el9.next
> rust-miniz_oxide0.5-0.5.4-1.el9.next
> rust-miniz_oxide-0.7.1-3.el9.next
> rust-num_enum-0.5.11-1.el9.next
> rust-num_enum_derive-0.5.11-1.el9.next
> rust-num-traits-0.2.17-1.el9.next
> rust-object-0.30.3-1.el9.next
> rust-os_pipe0.9-0.9.2-3.el9.next
> rust-os_str_bytes-6.6.1-1.el9.next
> rust-packaging-25.2-1.el9.next
> rust-parking_lot_core-0.9.9-1.el9.next
> rust-predicates-core-1.0.6-1.el9.next
> rust-print_bytes-1.2.0-1.el9.next
> rust-proc-macro2-1.0.69-1.el9.next
> rust-rayon-1.8.0-1.el9.next
> rust-rayon-core-1.12.0-1.el9.next
> rust-regex-1.10.2-1.el9.next
> rust-regex-automata-0.4.3-1.el9.next
> rust-regex-syntax0.7-0.7.5-1.el9.next
> rust-regex-syntax-0.8.2-1.el9.next
> rust-relative-path-1.9.0-1.el9.next
> rust-roff0.1-0.1.0-1.el9.next
> rust-roff-0.2.1-1.el9.next
> rust-rpassword5-5.0.1-1.el9.next
> rust-rpassword-7.2.0-1.el9.next
> rust-rstest-0.18.2-1.el9.next
> rust-rstest_macros-0.18.2-1.el9.next
> rust-rstest_reuse-0.6.0-1.el9.next
> rust-rtoolbox-0.0.1-1.el9.next
> rust-rust_decimal-1.32.0-1.el9.next
> rust-serde-1.0.189-1.el9.next
> rust-serde_derive-1.0.189-1.el9.next
> rust-serde_json-1.0.107-1.el9.next
> rust-shared_child-1.0.0-3.el9.next
> rust-smallvec-1.11.1-1.el9.next
> rust-strip-ansi-escapes0.1-0.1.1-1.el9.next
> rust-strip-ansi-escapes-0.2.0-1.el9.next
> rust-syn-2.0.38-1.el9.next
> rust-system-deps-6.1.2-1.el9.next
> rust-tempfile-3.8.0-1.el9.next
> rust-termcolor-1.3.0-1.el9.next
> rust-terminal_size0.2-0.2.6-1.el9.next
> rust-terminal_size-0.3.0-1.el9.next
> rust-textwrap0.15-0.15.2-1.el9.next
> rust-textwrap-0.16.0-1.el9.next
> rust-thread-id-4.2.1-1.el9.next
> rust-timeago-0.4.2-1.el9.next
> rust-time-core-0.1.1-1.el9.next
> rust-toml0.5-0.5.11-1.el9.next
> rust-toml0.7-0.7.8-1.el9.next
> rust-toml-0.8.2-1.el9.next
> rust-toml_edit0.19-0.19.15-1.el9.next
> rust-toml_edit-0.20.2-1.el9.next
> rust-ucd-parse-0.1.10-1.el9.next
> rust-winnow0.4-0.4.11-1.el9.next
> rust-winnow-0.5.16-1.el9.next
> rust-xml-rs-0.8.19-1.el9.next
>
>
> Troy
>
>
--
___
epel-devel mailing list -- epel-devel@lists.fedoraproject.org
To unsubscribe send an email to epel-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/epel-devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

[EPEL-devel] Re: Packages for PHP 8.1

[Stephen Smoogen]

On Tue, 21 Feb 2023 at 12:40, Joseph Christopher Sible 
wrote:

> Hello,
>
>
>
> I have a RHEL 9 system running PHP 8.1 from the Red Hat AppStream module.
> I tried to install php-sodium and php-pecl-imagick from EPEL 9 on it, but
> DNF gave an error that basically said those packages only work with PHP
> 8.0. Would it be possible to provide versions of those packages that are
> compatible with PHP 8.1 too?
>
>
>

It is not currently or in the near future possible. In order to build
against modules like PHP-8.1, the Fedora build system (koji, mbs, bodhi,
pdc, etc) needs to know about the modules it would 'pull' in to work with.
However a fundamental way the koji++ build system works requires that
Fedora also have built those modules. In order to have built a copy of the
AppStream 8.1 PHP, it would also need to compile the underlying OS. It
would also have to use those to build the packages versus using RHEL.



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


-- 
Stephen Smoogen, Red Hat Automotive
Let us be kind to one another, for most of us are fighting a hard battle.
-- Ian MacClaren
___
epel-devel mailing list -- epel-devel@lists.fedoraproject.org
To unsubscribe send an email to epel-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/epel-devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Packages with breaking APIs

[Tom Hughes via devel]

On 01/02/2023 11:51, Neal Gompa wrote:

On Wed, Feb 1, 2023 at 12:46 PM Benson Muite  wrote:


For Catch, there was an upgrade from 1 to 2. Similarly for FFTW, the
main package uses the name FFTW, but it was FFTW3 before hand. Maybe one
could use Catch3 or Catch2v3? Then change names later once more packages
use the v3 interface?


Normally older versions are broken out into versioned legacy packages
and the main package is upgraded. Then reverse dependencies are either
upgraded or pinned as needed.


Which is what we did for catch before - there is catch1 and catch now.

The slight complication/confusion is that the upstream repository is
actually called Catch2 now though it's on v3.x but version one is in
the same repository, just on a Catch1.x branch.

Tom

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

Re: Packages with breaking APIs

[Neal Gompa]

On Wed, Feb 1, 2023 at 12:46 PM Benson Muite  wrote:
>
> The review had gone through, and had created the package, then retired
> it, but as the APIs are different, and this also applies to another
> package I have under review, mbedTLS, wanted to know if there are
> general guidelines on this.
>
> For Catch, there was an upgrade from 1 to 2. Similarly for FFTW, the
> main package uses the name FFTW, but it was FFTW3 before hand. Maybe one
> could use Catch3 or Catch2v3? Then change names later once more packages
> use the v3 interface?
>

Normally older versions are broken out into versioned legacy packages
and the main package is upgraded. Then reverse dependencies are either
upgraded or pinned as needed.


-- 
真実はいつも一つ！/ Always, there's only one truth!
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Packages with breaking APIs

[Benson Muite]

The review had gone through, and had created the package, then retired
it, but as the APIs are different, and this also applies to another
package I have under review, mbedTLS, wanted to know if there are
general guidelines on this.

For Catch, there was an upgrade from 1 to 2. Similarly for FFTW, the
main package uses the name FFTW, but it was FFTW3 before hand. Maybe one
could use Catch3 or Catch2v3? Then change names later once more packages
use the v3 interface?

On 2/1/23 13:44, Tom Hughes wrote:
> There is already precedent for doing it with catch and I've said
> that I plan to do it again so I don't know what more you want.
> 
> Tom
> 
> On 01/02/2023 10:13, Benson Muite wrote:
>> Packages with breaking APIs between major version changes often keep
>> maintaining the older version for some time after the new version is
>> released.  An example is FFTW which has both FFTW (version 3) and FFTW2
>> (version 2) within Fedora:
>> https://packages.fedoraproject.org/search?query=fftw
>>
>> Is it reasonable to package versions with newer APIs separately? Of
>> particular interest are:
>> i) Catch
>> a) Existing v2.3.10 https://src.fedoraproject.org/rpms/catch
>> b) BZ for v3.3.0 https://bugzilla.redhat.com/show_bug.cgi?id=2165410
>> ii) MbedTLS
>> a) Existing v2.28.2 https://src.fedoraproject.org/rpms/mbedtls
>> b) BZ for v3.3.0 https://bugzilla.redhat.com/show_bug.cgi?id=2154347
>> ___
>> devel mailing list -- devel@lists.fedoraproject.org
>> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
>> Fedora Code of Conduct:
>> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
>> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
>> List Archives:
>> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
>> Do not reply to spam, report it:
>> https://pagure.io/fedora-infrastructure/new_issue
> 
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Packages with breaking APIs

[Tom Hughes via devel]

There is already precedent for doing it with catch and I've said
that I plan to do it again so I don't know what more you want.

Tom

On 01/02/2023 10:13, Benson Muite wrote:

Packages with breaking APIs between major version changes often keep
maintaining the older version for some time after the new version is
released.  An example is FFTW which has both FFTW (version 3) and FFTW2
(version 2) within Fedora:
https://packages.fedoraproject.org/search?query=fftw

Is it reasonable to package versions with newer APIs separately? Of
particular interest are:
i) Catch
a) Existing v2.3.10 https://src.fedoraproject.org/rpms/catch
b) BZ for v3.3.0 https://bugzilla.redhat.com/show_bug.cgi?id=2165410
ii) MbedTLS
a) Existing v2.28.2 https://src.fedoraproject.org/rpms/mbedtls
b) BZ for v3.3.0 https://bugzilla.redhat.com/show_bug.cgi?id=2154347
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue


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

Re: Packages silently dropping approved changes

[Iñaki Ucar]

The current status is:

- opentoonz: was adapted in
https://src.fedoraproject.org/rpms/opentoonz/pull-request/1, built and
updated
- openmeeg: was re-adapted in
https://src.fedoraproject.org/rpms/openmeeg/pull-request/2, built and
updated

Thanks Diego and Antonio for your quick response.

- freefem++: a re-adaptation was proposed in
https://src.fedoraproject.org/rpms/freefem++/pull-request/2

I would also like to note that freefem's current configuration has
many issues, as can be seen in the linking result:

$ ldd /usr/bin/FreeFem++
   [snip]
   liblapack.so.3 => /lib64/liblapack.so.3 (0x7f4969c0)
   libopenblas.so.0 => /lib64/libopenblas.so.0 (0x7f4967828000)
   [snip]
   libflexiblas.so.3 => /lib64/libflexiblas.so.3 (0x7f496680)
   [snip]
   libblas.so.3 => /lib64/libblas.so.3 (0x7f4967626000)
   [snip]

The final binary links to 4 different libraries with an overlapping
set of symbols. At the same time, other libraries used by freefem
(such as arpack, suitesparse, etc.) are using libflexiblas. So this
situation is far from ideal, because mixing them is not a good idea.
The patch linked above solves this and produces a clean list of
dependencies.

Iñaki


On Fri, 26 Aug 2022 at 15:44, Ben Beasley  wrote:
>
> The policies specifying use of FlexiBLAS[1] are full of MUSTs; you can’t just 
> opt out and reject all prospective PRs out of hand. If someone can get the 
> package working with FlexiBLAS, you should accept a PR. If you think 
> freefem++ needs to be exempt from the requirement, you should open an FPC 
> ticket[2] explaining why and requesting an explicit exception.
>
> [1] 
> https://docs.fedoraproject.org/en-US/packaging-guidelines/BLAS_LAPACK/#_packaging_blaslapack_dependent_packages
> [2] https://pagure.io/packaging-committee/issues
>
> On Thu, Aug 25, 2022, at 6:36 PM, Ralf Corsépius wrote:
> > Am 25.08.22 um 23:00 schrieb Iñaki Ucar:
> >> On Thu, 25 Aug 2022 at 19:15, Iñaki Ucar  wrote:
> >>>
> >>> On Thu, 25 Aug 2022 at 18:34, Ralf Corsépius  wrote:
> 
>  Am 25.08.22 um 13:19 schrieb Iñaki Ucar:
> 
> > I assume their maintainers didn't do it on purpose, maybe it was
> > easier for a certain update, didn't have time to look into it and
> > weren't aware of the guideline. But this is very frustrating. Seeing
> > many hours of work just wiped out without any notice or explanation is
> > very frustrating.
> 
>  In my case (freefem++), it was actually was a mixture of all.
> 
>  To cut a long story short: This flexblas stuff doesn't "harmonize well"
>  with freefem++, rsp. more bluntly speaking, flexblas breaks freefem++.
> 
>  Because of this, when going after freefem++'s regressions, years after
>  the flexiblas changes had been introduced, I inadvertedly and
>  accidentally reverted the flexblas related changes, because these
>  apparently do not work out with freefem++.
> >>>
> >>> How exactly does flexiblas break freefem++? I see v4.10 was built just
> >>> fine. Then v4.11 reverted to openblas. If it works with openblas, I
> >>> see no reason to break with flexiblas, among other things because
> >>> openblas is the default backend. Moreover, arpack, superlu,
> >>> suitesparse and other BuildRequires link against flexiblas.
> >>
> >> In fact, freefem++ was one of the easiest packages to adapt: you just
> >> set the library, and it does nothing fancy nor too-clever to try to
> >> discover anything.
> > Then you haven't looked into details (build.log rsp. config.status).
> >
> > flexiblas causes freefem's configure script to produce bogus results.
> >
> >
> > Here's a simple patch [1] and a successful scratch
> >> build [2], with all checks passing. Please let me know if I'm missing
> >> anything, but otherwise, I'll open a PR.
> > Please don't and also abstain from submitting pull requests.
> >
> > ___
> > devel mailing list -- devel@lists.fedoraproject.org
> > To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> > Fedora Code of Conduct:
> > https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> > List Archives:
> > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
> > Do not reply to spam, report it:
> > https://pagure.io/fedora-infrastructure/new_issue
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct: 
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: 
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
> Do not reply to spam, report it: 
> https://pagure.io/fedora-infrastructure/new_issue



--
Iñaki Úcar

Re: Packages in repo not signed: fedora-cisco-openh264 repository

[Kevin]

On Thu, Aug 25, 2022 at 08:43:38PM -0500, Martin Jackson wrote:
> On Thu, 2022-08-25 at 16:28 -0700, Kevin Fenzi wrote:
> > Everything should be back to working. Try a 'dnf --refresh...' or a 
> > 'dnf clean all'.
> > 
> Having just
> downloaded 
> https://codecs.fedoraproject.org/openh264/36/x86_64/os/Packages/m/mozilla-openh264-2.3.0-1.fc36.x86_64.rpm

Yes, that unsigned package it still there, but the repodata no longer
has anything about it, so dnf won't try and download it. 

New, fixed versions have been sent... 

kevin


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

Re: Packages silently dropping approved changes

[Ben Beasley]

The policies specifying use of FlexiBLAS[1] are full of MUSTs; you can’t just 
opt out and reject all prospective PRs out of hand. If someone can get the 
package working with FlexiBLAS, you should accept a PR. If you think freefem++ 
needs to be exempt from the requirement, you should open an FPC ticket[2] 
explaining why and requesting an explicit exception.

[1] 
https://docs.fedoraproject.org/en-US/packaging-guidelines/BLAS_LAPACK/#_packaging_blaslapack_dependent_packages
[2] https://pagure.io/packaging-committee/issues

On Thu, Aug 25, 2022, at 6:36 PM, Ralf Corsépius wrote:
> Am 25.08.22 um 23:00 schrieb Iñaki Ucar:
>> On Thu, 25 Aug 2022 at 19:15, Iñaki Ucar  wrote:
>>>
>>> On Thu, 25 Aug 2022 at 18:34, Ralf Corsépius  wrote:

 Am 25.08.22 um 13:19 schrieb Iñaki Ucar:

> I assume their maintainers didn't do it on purpose, maybe it was
> easier for a certain update, didn't have time to look into it and
> weren't aware of the guideline. But this is very frustrating. Seeing
> many hours of work just wiped out without any notice or explanation is
> very frustrating.

 In my case (freefem++), it was actually was a mixture of all.

 To cut a long story short: This flexblas stuff doesn't "harmonize well"
 with freefem++, rsp. more bluntly speaking, flexblas breaks freefem++.

 Because of this, when going after freefem++'s regressions, years after
 the flexiblas changes had been introduced, I inadvertedly and
 accidentally reverted the flexblas related changes, because these
 apparently do not work out with freefem++.
>>>
>>> How exactly does flexiblas break freefem++? I see v4.10 was built just
>>> fine. Then v4.11 reverted to openblas. If it works with openblas, I
>>> see no reason to break with flexiblas, among other things because
>>> openblas is the default backend. Moreover, arpack, superlu,
>>> suitesparse and other BuildRequires link against flexiblas.
>> 
>> In fact, freefem++ was one of the easiest packages to adapt: you just
>> set the library, and it does nothing fancy nor too-clever to try to
>> discover anything. 
> Then you haven't looked into details (build.log rsp. config.status).
>
> flexiblas causes freefem's configure script to produce bogus results.
>
>
> Here's a simple patch [1] and a successful scratch
>> build [2], with all checks passing. Please let me know if I'm missing
>> anything, but otherwise, I'll open a PR.
> Please don't and also abstain from submitting pull requests.
>
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct: 
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: 
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
> Do not reply to spam, report it: 
> https://pagure.io/fedora-infrastructure/new_issue
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Packages in repo not signed: fedora-cisco-openh264 repository

[Christopher Klooz]

On 26/08/2022 01:28, Kevin Fenzi wrote:

Everything should be back to working. Try a 'dnf --refresh...' or a
'dnf clean all'.
Yes, the packages are no longer in the update list. So the errors are 
gone for now. Thanks!


It's not fully clear yet some of the events. ;(

 The person who used to update this has moved to another group.
 The SOP (standard operating procedure) for doing this update was 
incorrect/out of date/wrong.
 Current update used the wrong process in the SOP and unsigned rpms were 
sent instead of signed ones.
 Something caused a zchunk error (the first one you saw, but perhaps this 
was just out of date repodata?)
 Something caused mirrormanager to not update for the new repodata.
 When updated, it started seeing the new unsigned rpms and gave an error 
about that.

I've pushed repodata that just points to the older h264 version thats signed 
(in f36/f37) and empty repodata (rawhide/f38).

In my testing everything is back to working.

I've submitted a PR to update the SOP.

Sorry for the trouble.

kevin

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

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

Re: Packages silently dropping approved changes

[Iñaki Ucar]

On Fri, 26 Aug 2022 at 00:44, Ralf Corsépius  wrote:
>
>
>
> Am 25.08.22 um 23:00 schrieb Iñaki Ucar:
> > On Thu, 25 Aug 2022 at 19:15, Iñaki Ucar  wrote:
> >>
> >> On Thu, 25 Aug 2022 at 18:34, Ralf Corsépius  wrote:
> >>>
> >>> Am 25.08.22 um 13:19 schrieb Iñaki Ucar:
> >>>
>  I assume their maintainers didn't do it on purpose, maybe it was
>  easier for a certain update, didn't have time to look into it and
>  weren't aware of the guideline. But this is very frustrating. Seeing
>  many hours of work just wiped out without any notice or explanation is
>  very frustrating.
> >>>
> >>> In my case (freefem++), it was actually was a mixture of all.
> >>>
> >>> To cut a long story short: This flexblas stuff doesn't "harmonize well"
> >>> with freefem++, rsp. more bluntly speaking, flexblas breaks freefem++.
> >>>
> >>> Because of this, when going after freefem++'s regressions, years after
> >>> the flexiblas changes had been introduced, I inadvertedly and
> >>> accidentally reverted the flexblas related changes, because these
> >>> apparently do not work out with freefem++.
> >>
> >> How exactly does flexiblas break freefem++? I see v4.10 was built just
> >> fine. Then v4.11 reverted to openblas. If it works with openblas, I
> >> see no reason to break with flexiblas, among other things because
> >> openblas is the default backend. Moreover, arpack, superlu,
> >> suitesparse and other BuildRequires link against flexiblas.
> >
> > In fact, freefem++ was one of the easiest packages to adapt: you just
> > set the library, and it does nothing fancy nor too-clever to try to
> > discover anything.
> Then you haven't looked into details (build.log rsp. config.status).

Could you please describe the issues?

> flexiblas causes freefem's configure script to produce bogus results.

If you are referring to this line

configure: -- NO ARPACK --  enable_download : no , wget: yes

then I have good news. I think we can agree that the configure script
is a mess. It just needed a simple fix to make that test successful,
namely, to substitute -llapack with -lflexiblas. Please take a look at
https://koji.fedoraproject.org/koji/taskinfo?taskID=91264332. I see no
differences in the list of "configure: ++ " that the script
produces

> Here's a simple patch [1] and a successful scratch
> > build [2], with all checks passing. Please let me know if I'm missing
> > anything, but otherwise, I'll open a PR.
> Please don't and also abstain from submitting pull requests.

I'm sorry, I'm trying to help here. But it's difficult if I don't know
the specific trouble you run into.

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

Re: Packages in repo not signed: fedora-cisco-openh264 repository

[Martin Jackson]

On Thu, 2022-08-25 at 16:28 -0700, Kevin Fenzi wrote:
> Everything should be back to working. Try a 'dnf --refresh...' or a 
> 'dnf clean all'.
> 
Having just
downloaded 
https://codecs.fedoraproject.org/openh264/36/x86_64/os/Packages/m/mozilla-openh264-2.3.0-1.fc36.x86_64.rpm
 I get:

Name : mozilla-openh264
Version : 2.3.0
Release : 1.fc36
Architecture: x86_64
Install Date: (not installed)
Group : Unspecified
Size : 1153495
License : BSD
Signature : (none)
Source RPM : openh264-2.3.0-1.fc36.src.rpm
Build Date : Mon 01 Aug 2022 10:47:57 AM CDT
Build Host : buildvm-x86-06.iad2.fedoraproject.org
Packager : Fedora Project
Vendor : Fedora Project
URL : https://www.openh264.org/
Bug URL : https://bugz.fedoraproject.org/openh264
Summary : H.264 codec support for Mozilla browsers
Description :
The mozilla-openh264 package contains a H.264 codec plugin for Mozilla
browsers.

Am I seeing something old on the CDN?

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

Re: Packages in repo not signed: fedora-cisco-openh264 repository

[Kevin Fenzi]

Everything should be back to working. Try a 'dnf --refresh...' or a 
'dnf clean all'.

It's not fully clear yet some of the events. ;(

The person who used to update this has moved to another group.
The SOP (standard operating procedure) for doing this update was 
incorrect/out of date/wrong.
Current update used the wrong process in the SOP and unsigned rpms were 
sent instead of signed ones.
Something caused a zchunk error (the first one you saw, but perhaps this 
was just out of date repodata?)
Something caused mirrormanager to not update for the new repodata.
When updated, it started seeing the new unsigned rpms and gave an error 
about that.

I've pushed repodata that just points to the older h264 version thats signed 
(in f36/f37) and empty repodata (rawhide/f38).

In my testing everything is back to working.

I've submitted a PR to update the SOP.

Sorry for the trouble.

kevin


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

Re: Packages silently dropping approved changes

[Ralf Corsépius]

Am 25.08.22 um 23:00 schrieb Iñaki Ucar:

On Thu, 25 Aug 2022 at 19:15, Iñaki Ucar  wrote:


On Thu, 25 Aug 2022 at 18:34, Ralf Corsépius  wrote:


Am 25.08.22 um 13:19 schrieb Iñaki Ucar:


I assume their maintainers didn't do it on purpose, maybe it was
easier for a certain update, didn't have time to look into it and
weren't aware of the guideline. But this is very frustrating. Seeing
many hours of work just wiped out without any notice or explanation is
very frustrating.


In my case (freefem++), it was actually was a mixture of all.

To cut a long story short: This flexblas stuff doesn't "harmonize well"
with freefem++, rsp. more bluntly speaking, flexblas breaks freefem++.

Because of this, when going after freefem++'s regressions, years after
the flexiblas changes had been introduced, I inadvertedly and
accidentally reverted the flexblas related changes, because these
apparently do not work out with freefem++.


How exactly does flexiblas break freefem++? I see v4.10 was built just
fine. Then v4.11 reverted to openblas. If it works with openblas, I
see no reason to break with flexiblas, among other things because
openblas is the default backend. Moreover, arpack, superlu,
suitesparse and other BuildRequires link against flexiblas.


In fact, freefem++ was one of the easiest packages to adapt: you just
set the library, and it does nothing fancy nor too-clever to try to
discover anything. 

Then you haven't looked into details (build.log rsp. config.status).

flexiblas causes freefem's configure script to produce bogus results.


Here's a simple patch [1] and a successful scratch

build [2], with all checks passing. Please let me know if I'm missing
anything, but otherwise, I'll open a PR.

Please don't and also abstain from submitting pull requests.

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

Re: Packages silently dropping approved changes

[Iñaki Ucar]

On Thu, 25 Aug 2022 at 19:15, Iñaki Ucar  wrote:
>
> On Thu, 25 Aug 2022 at 18:34, Ralf Corsépius  wrote:
> >
> > Am 25.08.22 um 13:19 schrieb Iñaki Ucar:
> >
> > > I assume their maintainers didn't do it on purpose, maybe it was
> > > easier for a certain update, didn't have time to look into it and
> > > weren't aware of the guideline. But this is very frustrating. Seeing
> > > many hours of work just wiped out without any notice or explanation is
> > > very frustrating.
> >
> > In my case (freefem++), it was actually was a mixture of all.
> >
> > To cut a long story short: This flexblas stuff doesn't "harmonize well"
> > with freefem++, rsp. more bluntly speaking, flexblas breaks freefem++.
> >
> > Because of this, when going after freefem++'s regressions, years after
> > the flexiblas changes had been introduced, I inadvertedly and
> > accidentally reverted the flexblas related changes, because these
> > apparently do not work out with freefem++.
>
> How exactly does flexiblas break freefem++? I see v4.10 was built just
> fine. Then v4.11 reverted to openblas. If it works with openblas, I
> see no reason to break with flexiblas, among other things because
> openblas is the default backend. Moreover, arpack, superlu,
> suitesparse and other BuildRequires link against flexiblas.

In fact, freefem++ was one of the easiest packages to adapt: you just
set the library, and it does nothing fancy nor too-clever to try to
discover anything. Here's a simple patch [1] and a successful scratch
build [2], with all checks passing. Please let me know if I'm missing
anything, but otherwise, I'll open a PR.

[1] 
https://src.fedoraproject.org/fork/iucar/rpms/freefem++/c/a9da37dfd71508b4bad124fdbfd190b417f0afb2
[2] https://koji.fedoraproject.org/koji/taskinfo?taskID=91253729

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

Re: Packages silently dropping approved changes

[Iñaki Ucar]

On Thu, 25 Aug 2022 at 18:34, Ralf Corsépius  wrote:
>
> Am 25.08.22 um 13:19 schrieb Iñaki Ucar:
>
> > I assume their maintainers didn't do it on purpose, maybe it was
> > easier for a certain update, didn't have time to look into it and
> > weren't aware of the guideline. But this is very frustrating. Seeing
> > many hours of work just wiped out without any notice or explanation is
> > very frustrating.
>
> In my case (freefem++), it was actually was a mixture of all.
>
> To cut a long story short: This flexblas stuff doesn't "harmonize well"
> with freefem++, rsp. more bluntly speaking, flexblas breaks freefem++.
>
> Because of this, when going after freefem++'s regressions, years after
> the flexiblas changes had been introduced, I inadvertedly and
> accidentally reverted the flexblas related changes, because these
> apparently do not work out with freefem++.

How exactly does flexiblas break freefem++? I see v4.10 was built just
fine. Then v4.11 reverted to openblas. If it works with openblas, I
see no reason to break with flexiblas, among other things because
openblas is the default backend. Moreover, arpack, superlu,
suitesparse and other BuildRequires link against flexiblas.

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

Re: Packages silently dropping approved changes

[Ralf Corsépius]

Am 25.08.22 um 13:19 schrieb Iñaki Ucar:


I assume their maintainers didn't do it on purpose, maybe it was
easier for a certain update, didn't have time to look into it and
weren't aware of the guideline. But this is very frustrating. Seeing
many hours of work just wiped out without any notice or explanation is
very frustrating.


In my case (freefem++), it was actually was a mixture of all.

To cut a long story short: This flexblas stuff doesn't "harmonize well" 
with freefem++, rsp. more bluntly speaking, flexblas breaks freefem++.


Because of this, when going after freefem++'s regressions, years after 
the flexiblas changes had been introduced, I inadvertedly and 
accidentally reverted the flexblas related changes, because these 
apparently do not work out with freefem++.


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

Re: Packages that failed to build with Python 3.11 (and what to do)

[David Cantrell]

On Mon, Jun 20, 2022 at 01:45:07PM +0200, Tomas Hrnciar wrote:
> Hello.
> 
> As you might already know, we have recently merged in the Python 3.11 side
> tag to Rawhide, despite several builds not succeeding. We always aim for
> some compromise between having the side tag open for too long and having
> too many failures.
> 
> https://fedoraproject.org/wiki/Changes/Python3.1
> 1
> 
> 
> 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.
> 
> Most of the packages only fail to build because their dependencies were not
> yet rebuilt. Chances are, you already got an automated F37FailsToInstall
> bugzilla from Miro, 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 depending on the bugzilla for the missing dep. We slowly
> progress to do that as well, but your help is crucial here.
> 
> If your package fails because there is a non-dependency problem, you might
> have already received a bugzilla from us in the past. If the build failure
> is related to changes in Python 3.11, it should contain some hints about
> the problem.
> 
> # What to do?
> 
> General advice: If you are aware of the problem and working towards fixing
> it, set your bugzilla to ASSIGNED to avoid further automated reminders.
> 
> If blocked by dependencies, do not close the bugzillas as NOTABUG or
> DUPLICATE just because it is "not a problem in your package". The
> automation will file new ones anyway.
> 
> ## My package fails to build because it has test failures in %check
> 
> Please, try to resolve the failures. If you are confident that the package
> works fine, but the tests are wrong, skip some failing tests, ideally with
> a link to an upstream issue. Do not disable (e.g. comment out) all tests
> just to unblock the rebuild of your package, it usually only hides the
> problem.
> 
> ## My package fails to build because it has broken build dependencies
> 
> Please try to track the missing build dependencies in Bugzilla. If
> possible, help the maintainers of your dependencies to get them rebuilt.
> When in need of escalation, ask us for provenpackager help (ideally with
> pull requests to be merged). Once possible, rebuild your package. When you
> do, the bugzilla will eventually get automatically closed, but you can do
> that manually as well.
> 
> ## My package was rebuilt with Python 3.11 but it has broken runtime
> dependencies
> 
> Please try to track the missing runtime dependencies in Bugzilla. If
> possible, help the maintainers of your dependencies to get them rebuilt.
> When in need of escalation, ask us for provenpackager help (ideally with
> pull requests to be merged). When the dependencies are rebuilt, your
> package will install successfully once again and the bugzilla will
> eventually get automatically closed, but you can do that manually as well.
> 
> ## My package failed to build but installs just fine
> 
> Some packages that only require libpython3.10.so.1.0 will successfully pull
> in the python3.10 package as a dependency and hence they don't have
> installation issues. They need to be rebuilt with Python 3.11 anyway, we
> don't want Fedora users to pull in two Python versions unless they need
> them for development purposes.
> 
> ## How to run things locally?
> 
> You can use mock. Make sure to:
> 1. Clear all caches first: $ mock -r fedora-rawhide-x86_64--scrub=all
> 2. Use the Koji repo: $ mock -r fedora-rawhide-x86_64
> --enablerepo=local ...
> 
> ## Where to get help
> 
> Reply to this thread or find us (thrnciar, mhroncok) on #fedora-python IRC
> channel (libera.chat)or Matrix (#python:fedoraproject.org).
> 
> ---
> 
> Let us know if you have other questions.
> 
> Maintainers by package:
> 5minute  pmoravco
> APLpysergiopr skytux
> HepMC3   ellert
> NiaAML-GUI   iztokf music
> OpenColorIO  hobbes1069
> OpenImageIO  hobbes1069
> PyMcazbyszek
> PyQt4sagitter than
> Zim  cheeselee ohaessler
> arborankursinha
> atomic-reactor   cverna kevin maxamillion twaugh vrutkovs
> awscli   davdunc fale limb
> azure-climhayden
> blender  design-sw ignatenkobrain kwizart luya music roma
> s4504kr slaanesh
> bodhi-server abompard humaton lenkaseg
> bout++   davidsch
> buildbot besser82 giallu ignatenkobrain ngompa radez smilner
> buildstream  atim bochecha
> calibre  chkr heliocastro kevin nushio zbyszek
> cantera  fuller sic
> cfn-lint 

Re: python-migen (Re: Packages that failed to build with Python 3.11)

[Miro Hrončok]

On 21. 06. 22 17:28, Gabriel L. Somlo wrote:

Otherwise, what's the avilable timeframe I have to try and figure
it out in time for F37 (assuming upstream doesn't start caring about
Python 3.11*before*  then)?


Assuming this is a leaf package (which it appears to be) and assuming you want 
it present at Fedora 37 release, you have time until the Final freeze:


https://fedorapeople.org/groups/schedule/f-37/f-37-key-tasks.html

Final Freeze (starts at 1400 UTC)   Tue 2022-10-04

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

Re: python-migen (Re: Packages that failed to build with Python 3.11)

[Miro Hrončok]

On 21. 06. 22 17:28, Gabriel L. Somlo wrote:

Otherwise, what's the avilable timeframe I have to try and figure
it out in time for F37 (assuming upstream doesn't start caring about
Python 3.11*before*  then)?


Assuming this is a leaf package (which it appears to be) and assuming you want 
it present at Fedora 37 release, you have time until the Final freeze:


https://fedorapeople.org/groups/schedule/f-37/f-37-key-tasks.html

Final Freeze (starts at 1400 UTC)   Tue 2022-10-04

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

python-migen (Re: Packages that failed to build with Python 3.11)

[Gabriel L. Somlo]

Hi,

On Mon, Jun 20, 2022 at 01:45:07PM +0200, Tomas Hrnciar wrote:
> [...]
> If your package fails because there is a non-dependency problem, you
> might have already received a bugzilla from us in the past. If the build
> failure is related to changes in Python 3.11, it should contain some
> hints about the problem.
> 
> [...]
> 
> ## My package fails to build because it has test failures in %check
> 
> Please, try to resolve the failures. If you are confident that the package
> works fine, but the tests are wrong, skip some failing tests, ideally with a
> link to an upstream issue. Do not disable (e.g. comment out) all tests just to
> unblock the rebuild of your package, it usually only hides the problem.
> 
> [...]
>
> ## Where to get help
> 
> Reply to this thread or find us (thrnciar, mhroncok) on #fedora-python IRC
> channel (libera.chat)or Matrix (#python:fedoraproject.org).
> 
> --- 
> 
> Let us know if you have other questions.
> 
> Maintainers by package:
> [...]
> python-migen somlo
> [...]

There's currently https://bugzilla.redhat.com/show_bug.cgi?id=2069537
(about the failing test), and https://github.com/m-labs/migen/issues/259
for the upstream issue I filed.

Some preliminary analysis (thanks to @music) indicates the problem
is due to the restructuring of CPython bytecode w.r.t. CALL_*
instructions.

If anyone reading this is deeply familiar with CPython and willing to
take a quick look, that'd be much appreciated!

Otherwise, what's the avilable timeframe I have to try and figure
it out in time for F37 (assuming upstream doesn't start caring about
Python 3.11 *before* then)?

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

python-migen (Re: Packages that failed to build with Python 3.11)

[Gabriel L. Somlo]

Hi,

On Mon, Jun 20, 2022 at 01:45:07PM +0200, Tomas Hrnciar wrote:
> [...]
> If your package fails because there is a non-dependency problem, you
> might have already received a bugzilla from us in the past. If the build
> failure is related to changes in Python 3.11, it should contain some
> hints about the problem.
> 
> [...]
> 
> ## My package fails to build because it has test failures in %check
> 
> Please, try to resolve the failures. If you are confident that the package
> works fine, but the tests are wrong, skip some failing tests, ideally with a
> link to an upstream issue. Do not disable (e.g. comment out) all tests just to
> unblock the rebuild of your package, it usually only hides the problem.
> 
> [...]
>
> ## Where to get help
> 
> Reply to this thread or find us (thrnciar, mhroncok) on #fedora-python IRC
> channel (libera.chat)or Matrix (#python:fedoraproject.org).
> 
> --- 
> 
> Let us know if you have other questions.
> 
> Maintainers by package:
> [...]
> python-migen somlo
> [...]

There's currently https://bugzilla.redhat.com/show_bug.cgi?id=2069537
(about the failing test), and https://github.com/m-labs/migen/issues/259
for the upstream issue I filed.

Some preliminary analysis (thanks to @music) indicates the problem
is due to the restructuring of CPython bytecode w.r.t. CALL_*
instructions.

If anyone reading this is deeply familiar with CPython and willing to
take a quick look, that'd be much appreciated!

Otherwise, what's the avilable timeframe I have to try and figure
it out in time for F37 (assuming upstream doesn't start caring about
Python 3.11 *before* then)?

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

Re: Packages that failed to build with Python 3.11 (and what to do)

[Steven A. Falco]

On 6/21/22 10:34 AM, Miro Hrončok wrote:

On 21. 06. 22 16:27, Steven A. Falco wrote:

On 6/20/22 07:45 AM, Tomas Hrnciar wrote:

Hello.

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


I'm working on fixing the problems in KiCad.  There hasn't been a successful 
compose of Rawhide just yet - how can I update my Rawhide VM to include the new 
version of Python so I can test my changes?  Is there a flag to dnf that would 
take into account the koji packages that are waiting for the compose?



$ cat /etc/yum.repos.d/koji.repo
[koji]
name=koji
baseurl=http://kojipkgs.fedoraproject.org/repos/rawhide/latest/$basearch/
enabled=0

[koji-source]
name=koji-source
baseurl=http://kojipkgs.fedoraproject.org/repos/rawhide/latest/src/
enabled=0

$ sudo dnf --enablerepo=koji upgrade



Perfect - thanks!

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

Re: Packages that failed to build with Python 3.11 (and what to do)

[Miro Hrončok]

On 21. 06. 22 16:27, Steven A. Falco wrote:

On 6/20/22 07:45 AM, Tomas Hrnciar wrote:

Hello.

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


I'm working on fixing the problems in KiCad.  There hasn't been a successful 
compose of Rawhide just yet - how can I update my Rawhide VM to include the new 
version of Python so I can test my changes?  Is there a flag to dnf that would 
take into account the koji packages that are waiting for the compose?



$ cat /etc/yum.repos.d/koji.repo
[koji]
name=koji
baseurl=http://kojipkgs.fedoraproject.org/repos/rawhide/latest/$basearch/
enabled=0

[koji-source]
name=koji-source
baseurl=http://kojipkgs.fedoraproject.org/repos/rawhide/latest/src/
enabled=0

$ sudo dnf --enablerepo=koji upgrade

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

Re: Packages that failed to build with Python 3.11 (and what to do)

[Miro Hrončok]

On 21. 06. 22 16:27, Steven A. Falco wrote:

On 6/20/22 07:45 AM, Tomas Hrnciar wrote:

Hello.

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


I'm working on fixing the problems in KiCad.  There hasn't been a successful 
compose of Rawhide just yet - how can I update my Rawhide VM to include the new 
version of Python so I can test my changes?  Is there a flag to dnf that would 
take into account the koji packages that are waiting for the compose?



$ cat /etc/yum.repos.d/koji.repo
[koji]
name=koji
baseurl=http://kojipkgs.fedoraproject.org/repos/rawhide/latest/$basearch/
enabled=0

[koji-source]
name=koji-source
baseurl=http://kojipkgs.fedoraproject.org/repos/rawhide/latest/src/
enabled=0

$ sudo dnf --enablerepo=koji upgrade

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

Re: Packages that failed to build with Python 3.11 (and what to do)

[Dan Horák]

On Tue, 21 Jun 2022 10:27:12 -0400
"Steven A. Falco"  wrote:

> On 6/20/22 07:45 AM, Tomas Hrnciar wrote:
> > Hello.
> > 
> > As you might already know, we have recently merged in the Python 3.11side 
> > tag to Rawhide, despite several builds not succeeding. We always aim for 
> > some compromise between having the side tag open for too long and having 
> > too many failures.
> 
> I'm working on fixing the problems in KiCad.  There hasn't been a successful 
> compose of Rawhide just yet - how can I update my Rawhide VM to include the 
> new version of Python so I can test my changes?  Is there a flag to dnf that 
> would take into account the koji packages that are waiting for the compose?

add https://paste.centos.org/view/d362701e as
eg. /etc/yum.repos.d/koji.repo and the use --enablerepo=koji for dnf


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

Re: Packages that failed to build with Python 3.11 (and what to do)

[Miro Hrončok]

On 21. 06. 22 12:51, Miro Hrončok wrote:

On 20. 06. 22 22:11, Mark E. Fuller wrote:

On 20/06/2022 14:45, Tomas Hrnciar wrote:

 >
 > ## Where to get help
 >
 > Reply to this thread or find us (thrnciar, mhroncok) on #fedora-python IRC 
channel (libera.chat)or Matrix (#python:fedoraproject.org 
).

 >
 > ---
 >
 > Let us know if you have other questions.
 >


Question: my error appears to be in a Python header.
Can someone take a look at this and giver me some quick feedback as to 
whether this is a problem for my package or a bug I should report?

It doesn't seem to fall into one of the neat categories described by Tomas

```
/usr/bin/python3 -c "import Cython.Build; 
Cython.Build.cythonize('build/python/cantera/_cantera.pyx')"

Compiling build/python/cantera/_cantera.pyx because it changed.
[1/1] Cythonizing build/python/cantera/_cantera.pyx
g++ -o build/temp-py/_cantera.os -c -std=c++11 -pthread -O3 -Wno-inline -g 
-fPIC -DNDEBUG -Iinclude -I/usr/include/python3.11 
-I/usr/lib64/python3.11/site-packages/numpy/core/include 
-I/usr/include/eigen3 build/python/cantera/_cantera.cpp
In file included from 
/usr/lib64/python3.11/site-packages/numpy/core/include/numpy/ndarraytypes.h:1960, 

  from 
/usr/lib64/python3.11/site-packages/numpy/core/include/numpy/ndarrayobject.h:12,
  from 
/usr/lib64/python3.11/site-packages/numpy/core/include/numpy/arrayobject.h:5,

  from build/python/cantera/_cantera.cpp:749:
/usr/lib64/python3.11/site-packages/numpy/core/include/numpy/npy_1_7_deprecated_api.h:17:2: 
warning: #warning "Using deprecated NumPy API, disable it with " "#define 
NPY_NO_DEPRECATED_API NPY_1_7_API_VERSION" [-Wcpp]

    17 | #warning "Using deprecated NumPy API, disable it with " \
   |  ^~~
In file included from /usr/include/python3.11/Python.h:38,
  from build/python/cantera/_cantera.cpp:20:
/usr/include/python3.11/pyport.h: In instantiation of 'type 
{anonymous}::_Py_CAST_impl(const expr_type&) [with type = _object*; expr_type 
= int]':

build/python/cantera/_cantera.cpp:193144:9:   required from here
/usr/include/python3.11/pyport.h:47:24: error: invalid 'static_cast' from 
type 'int' to type '_object*'
    47 | return static_cast(const_cast&>(expr));

   | ^~~~
scons: *** [build/temp-py/_cantera.os] Error 1
scons: building terminated because of errors.
```

See: https://github.com/Cantera/cantera/issues/1325
Also: https://kojipkgs.fedoraproject.org/work/tasks/2453/88502453/build.log


I believe this shall fix it:

https://src.fedoraproject.org/rpms/python3.11/pull-request/56


This is now built and available in the buildroot.

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

Re: Packages that failed to build with Python 3.11 (and what to do)

[Miro Hrončok]

On 21. 06. 22 12:51, Miro Hrončok wrote:

On 20. 06. 22 22:11, Mark E. Fuller wrote:

On 20/06/2022 14:45, Tomas Hrnciar wrote:

 >
 > ## Where to get help
 >
 > Reply to this thread or find us (thrnciar, mhroncok) on #fedora-python IRC 
channel (libera.chat)or Matrix (#python:fedoraproject.org 
).

 >
 > ---
 >
 > Let us know if you have other questions.
 >


Question: my error appears to be in a Python header.
Can someone take a look at this and giver me some quick feedback as to 
whether this is a problem for my package or a bug I should report?

It doesn't seem to fall into one of the neat categories described by Tomas

```
/usr/bin/python3 -c "import Cython.Build; 
Cython.Build.cythonize('build/python/cantera/_cantera.pyx')"

Compiling build/python/cantera/_cantera.pyx because it changed.
[1/1] Cythonizing build/python/cantera/_cantera.pyx
g++ -o build/temp-py/_cantera.os -c -std=c++11 -pthread -O3 -Wno-inline -g 
-fPIC -DNDEBUG -Iinclude -I/usr/include/python3.11 
-I/usr/lib64/python3.11/site-packages/numpy/core/include 
-I/usr/include/eigen3 build/python/cantera/_cantera.cpp
In file included from 
/usr/lib64/python3.11/site-packages/numpy/core/include/numpy/ndarraytypes.h:1960, 

  from 
/usr/lib64/python3.11/site-packages/numpy/core/include/numpy/ndarrayobject.h:12,
  from 
/usr/lib64/python3.11/site-packages/numpy/core/include/numpy/arrayobject.h:5,

  from build/python/cantera/_cantera.cpp:749:
/usr/lib64/python3.11/site-packages/numpy/core/include/numpy/npy_1_7_deprecated_api.h:17:2: 
warning: #warning "Using deprecated NumPy API, disable it with " "#define 
NPY_NO_DEPRECATED_API NPY_1_7_API_VERSION" [-Wcpp]

    17 | #warning "Using deprecated NumPy API, disable it with " \
   |  ^~~
In file included from /usr/include/python3.11/Python.h:38,
  from build/python/cantera/_cantera.cpp:20:
/usr/include/python3.11/pyport.h: In instantiation of 'type 
{anonymous}::_Py_CAST_impl(const expr_type&) [with type = _object*; expr_type 
= int]':

build/python/cantera/_cantera.cpp:193144:9:   required from here
/usr/include/python3.11/pyport.h:47:24: error: invalid 'static_cast' from 
type 'int' to type '_object*'
    47 | return static_cast(const_cast&>(expr));

   | ^~~~
scons: *** [build/temp-py/_cantera.os] Error 1
scons: building terminated because of errors.
```

See: https://github.com/Cantera/cantera/issues/1325
Also: https://kojipkgs.fedoraproject.org/work/tasks/2453/88502453/build.log


I believe this shall fix it:

https://src.fedoraproject.org/rpms/python3.11/pull-request/56


This is now built and available in the buildroot.

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

Re: Packages that failed to build with Python 3.11 (and what to do)

[Steven A. Falco]

On 6/20/22 07:45 AM, Tomas Hrnciar wrote:

Hello.

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


I'm working on fixing the problems in KiCad.  There hasn't been a successful 
compose of Rawhide just yet - how can I update my Rawhide VM to include the new 
version of Python so I can test my changes?  Is there a flag to dnf that would 
take into account the koji packages that are waiting for the compose?

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

Re: Packages that failed to build with Python 3.11 (and what to do)

[Miro Hrončok]

On 20. 06. 22 22:11, Mark E. Fuller wrote:

On 20/06/2022 14:45, Tomas Hrnciar wrote:

 >
 > ## Where to get help
 >
 > Reply to this thread or find us (thrnciar, mhroncok) on #fedora-python IRC 
channel (libera.chat)or Matrix (#python:fedoraproject.org 
).

 >
 > ---
 >
 > Let us know if you have other questions.
 >


Question: my error appears to be in a Python header.
Can someone take a look at this and giver me some quick feedback as to whether 
this is a problem for my package or a bug I should report?

It doesn't seem to fall into one of the neat categories described by Tomas

```
/usr/bin/python3 -c "import Cython.Build; 
Cython.Build.cythonize('build/python/cantera/_cantera.pyx')"

Compiling build/python/cantera/_cantera.pyx because it changed.
[1/1] Cythonizing build/python/cantera/_cantera.pyx
g++ -o build/temp-py/_cantera.os -c -std=c++11 -pthread -O3 -Wno-inline -g 
-fPIC -DNDEBUG -Iinclude -I/usr/include/python3.11 
-I/usr/lib64/python3.11/site-packages/numpy/core/include -I/usr/include/eigen3 
build/python/cantera/_cantera.cpp
In file included from 
/usr/lib64/python3.11/site-packages/numpy/core/include/numpy/ndarraytypes.h:1960,
  from 
/usr/lib64/python3.11/site-packages/numpy/core/include/numpy/ndarrayobject.h:12,
  from 
/usr/lib64/python3.11/site-packages/numpy/core/include/numpy/arrayobject.h:5,

  from build/python/cantera/_cantera.cpp:749:
/usr/lib64/python3.11/site-packages/numpy/core/include/numpy/npy_1_7_deprecated_api.h:17:2: 
warning: #warning "Using deprecated NumPy API, disable it with " "#define 
NPY_NO_DEPRECATED_API NPY_1_7_API_VERSION" [-Wcpp]

    17 | #warning "Using deprecated NumPy API, disable it with " \
   |  ^~~
In file included from /usr/include/python3.11/Python.h:38,
  from build/python/cantera/_cantera.cpp:20:
/usr/include/python3.11/pyport.h: In instantiation of 'type 
{anonymous}::_Py_CAST_impl(const expr_type&) [with type = _object*; expr_type = 
int]':

build/python/cantera/_cantera.cpp:193144:9:   required from here
/usr/include/python3.11/pyport.h:47:24: error: invalid 'static_cast' from type 
'int' to type '_object*'

    47 | return static_cast(const_cast(expr));
   | ^~~~
scons: *** [build/temp-py/_cantera.os] Error 1
scons: building terminated because of errors.
```

See: https://github.com/Cantera/cantera/issues/1325
Also: https://kojipkgs.fedoraproject.org/work/tasks/2453/88502453/build.log


I believe this shall fix it:

https://src.fedoraproject.org/rpms/python3.11/pull-request/56

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

Re: Packages that failed to build with Python 3.11 (and what to do)

[Miro Hrončok]

On 20. 06. 22 22:11, Mark E. Fuller wrote:

On 20/06/2022 14:45, Tomas Hrnciar wrote:

 >
 > ## Where to get help
 >
 > Reply to this thread or find us (thrnciar, mhroncok) on #fedora-python IRC 
channel (libera.chat)or Matrix (#python:fedoraproject.org 
).

 >
 > ---
 >
 > Let us know if you have other questions.
 >


Question: my error appears to be in a Python header.
Can someone take a look at this and giver me some quick feedback as to whether 
this is a problem for my package or a bug I should report?

It doesn't seem to fall into one of the neat categories described by Tomas

```
/usr/bin/python3 -c "import Cython.Build; 
Cython.Build.cythonize('build/python/cantera/_cantera.pyx')"

Compiling build/python/cantera/_cantera.pyx because it changed.
[1/1] Cythonizing build/python/cantera/_cantera.pyx
g++ -o build/temp-py/_cantera.os -c -std=c++11 -pthread -O3 -Wno-inline -g 
-fPIC -DNDEBUG -Iinclude -I/usr/include/python3.11 
-I/usr/lib64/python3.11/site-packages/numpy/core/include -I/usr/include/eigen3 
build/python/cantera/_cantera.cpp
In file included from 
/usr/lib64/python3.11/site-packages/numpy/core/include/numpy/ndarraytypes.h:1960,
  from 
/usr/lib64/python3.11/site-packages/numpy/core/include/numpy/ndarrayobject.h:12,
  from 
/usr/lib64/python3.11/site-packages/numpy/core/include/numpy/arrayobject.h:5,

  from build/python/cantera/_cantera.cpp:749:
/usr/lib64/python3.11/site-packages/numpy/core/include/numpy/npy_1_7_deprecated_api.h:17:2: 
warning: #warning "Using deprecated NumPy API, disable it with " "#define 
NPY_NO_DEPRECATED_API NPY_1_7_API_VERSION" [-Wcpp]

    17 | #warning "Using deprecated NumPy API, disable it with " \
   |  ^~~
In file included from /usr/include/python3.11/Python.h:38,
  from build/python/cantera/_cantera.cpp:20:
/usr/include/python3.11/pyport.h: In instantiation of 'type 
{anonymous}::_Py_CAST_impl(const expr_type&) [with type = _object*; expr_type = 
int]':

build/python/cantera/_cantera.cpp:193144:9:   required from here
/usr/include/python3.11/pyport.h:47:24: error: invalid 'static_cast' from type 
'int' to type '_object*'

    47 | return static_cast(const_cast(expr));
   | ^~~~
scons: *** [build/temp-py/_cantera.os] Error 1
scons: building terminated because of errors.
```

See: https://github.com/Cantera/cantera/issues/1325
Also: https://kojipkgs.fedoraproject.org/work/tasks/2453/88502453/build.log


I believe this shall fix it:

https://src.fedoraproject.org/rpms/python3.11/pull-request/56

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

Re: Packages that failed to build with Python 3.11 (and what to do)

[Tomas Hrnciar]

Hello Mark,

I replied in the upstream issue. I also think that this error looks like a
problem in Cython. Could you please open an upstream report?

Have a nice day.
Tomas

On Mon, Jun 20, 2022 at 10:11 PM Mark E. Fuller 
wrote:

> On 20/06/2022 14:45, Tomas Hrnciar wrote:
> 
>  >
>  > ## Where to get help
>  >
>  > Reply to this thread or find us (thrnciar, mhroncok) on
> #fedora-python IRC channel (libera.chat)or Matrix
> (#python:fedoraproject.org ).
>  >
>  > ---
>  >
>  > Let us know if you have other questions.
>  >
> 
>
> Question: my error appears to be in a Python header.
> Can someone take a look at this and giver me some quick feedback as to
> whether this is a problem for my package or a bug I should report?
> It doesn't seem to fall into one of the neat categories described by Tomas
>
> ```
> /usr/bin/python3 -c "import Cython.Build;
> Cython.Build.cythonize('build/python/cantera/_cantera.pyx')"
> Compiling build/python/cantera/_cantera.pyx because it changed.
> [1/1] Cythonizing build/python/cantera/_cantera.pyx
> g++ -o build/temp-py/_cantera.os -c -std=c++11 -pthread -O3 -Wno-inline
> -g -fPIC -DNDEBUG -Iinclude -I/usr/include/python3.11
> -I/usr/lib64/python3.11/site-packages/numpy/core/include
> -I/usr/include/eigen3 build/python/cantera/_cantera.cpp
> In file included from
>
> /usr/lib64/python3.11/site-packages/numpy/core/include/numpy/ndarraytypes.h:1960,
>   from
>
> /usr/lib64/python3.11/site-packages/numpy/core/include/numpy/ndarrayobject.h:12,
>   from
>
> /usr/lib64/python3.11/site-packages/numpy/core/include/numpy/arrayobject.h:5,
>   from build/python/cantera/_cantera.cpp:749:
> /usr/lib64/python3.11/site-packages/numpy/core/include/numpy/npy_1_7_deprecated_api.h:17:2:
>
> warning: #warning "Using deprecated NumPy API, disable it with "
> "#define NPY_NO_DEPRECATED_API NPY_1_7_API_VERSION" [-Wcpp]
> 17 | #warning "Using deprecated NumPy API, disable it with " \
>|  ^~~
> In file included from /usr/include/python3.11/Python.h:38,
>   from build/python/cantera/_cantera.cpp:20:
> /usr/include/python3.11/pyport.h: In instantiation of 'type
> {anonymous}::_Py_CAST_impl(const expr_type&) [with type = _object*;
> expr_type = int]':
> build/python/cantera/_cantera.cpp:193144:9:   required from here
> /usr/include/python3.11/pyport.h:47:24: error: invalid 'static_cast'
> from type 'int' to type '_object*'
> 47 | return static_cast(const_cast &>(expr));
>| ^~~~
> scons: *** [build/temp-py/_cantera.os] Error 1
> scons: building terminated because of errors.
> ```
>
> See: https://github.com/Cantera/cantera/issues/1325
> Also:
> https://kojipkgs.fedoraproject.org/work/tasks/2453/88502453/build.log
>
> Best,
> -fuller
>
> --
> Mark E. Fuller, Ph.D.
> HaShikma 19, Apt. 24
> Nesher 3681219, Israel
> +972 (0)53-872-6579
> +49 (0)1577 1848188
> +1 401-214-4266
> mark.e.ful...@gmail.com
> mark.e.ful...@gmx.de
> ful...@stossrohr.net
> @fuller:one.ems.host
> https://www.stossrohr.net
> PGP Fingerprint: 73F1 A30C BDF4 DB4B C75F FD0F D599 E76C FFCA BF60
>
>
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: Packages that failed to build with Python 3.11 (and what to do)

[Tomas Hrnciar]

Hello Mark,

I replied in the upstream issue. I also think that this error looks like a
problem in Cython. Could you please open an upstream report?

Have a nice day.
Tomas

On Mon, Jun 20, 2022 at 10:11 PM Mark E. Fuller 
wrote:

> On 20/06/2022 14:45, Tomas Hrnciar wrote:
> 
>  >
>  > ## Where to get help
>  >
>  > Reply to this thread or find us (thrnciar, mhroncok) on
> #fedora-python IRC channel (libera.chat)or Matrix
> (#python:fedoraproject.org ).
>  >
>  > ---
>  >
>  > Let us know if you have other questions.
>  >
> 
>
> Question: my error appears to be in a Python header.
> Can someone take a look at this and giver me some quick feedback as to
> whether this is a problem for my package or a bug I should report?
> It doesn't seem to fall into one of the neat categories described by Tomas
>
> ```
> /usr/bin/python3 -c "import Cython.Build;
> Cython.Build.cythonize('build/python/cantera/_cantera.pyx')"
> Compiling build/python/cantera/_cantera.pyx because it changed.
> [1/1] Cythonizing build/python/cantera/_cantera.pyx
> g++ -o build/temp-py/_cantera.os -c -std=c++11 -pthread -O3 -Wno-inline
> -g -fPIC -DNDEBUG -Iinclude -I/usr/include/python3.11
> -I/usr/lib64/python3.11/site-packages/numpy/core/include
> -I/usr/include/eigen3 build/python/cantera/_cantera.cpp
> In file included from
>
> /usr/lib64/python3.11/site-packages/numpy/core/include/numpy/ndarraytypes.h:1960,
>   from
>
> /usr/lib64/python3.11/site-packages/numpy/core/include/numpy/ndarrayobject.h:12,
>   from
>
> /usr/lib64/python3.11/site-packages/numpy/core/include/numpy/arrayobject.h:5,
>   from build/python/cantera/_cantera.cpp:749:
> /usr/lib64/python3.11/site-packages/numpy/core/include/numpy/npy_1_7_deprecated_api.h:17:2:
>
> warning: #warning "Using deprecated NumPy API, disable it with "
> "#define NPY_NO_DEPRECATED_API NPY_1_7_API_VERSION" [-Wcpp]
> 17 | #warning "Using deprecated NumPy API, disable it with " \
>|  ^~~
> In file included from /usr/include/python3.11/Python.h:38,
>   from build/python/cantera/_cantera.cpp:20:
> /usr/include/python3.11/pyport.h: In instantiation of 'type
> {anonymous}::_Py_CAST_impl(const expr_type&) [with type = _object*;
> expr_type = int]':
> build/python/cantera/_cantera.cpp:193144:9:   required from here
> /usr/include/python3.11/pyport.h:47:24: error: invalid 'static_cast'
> from type 'int' to type '_object*'
> 47 | return static_cast(const_cast &>(expr));
>| ^~~~
> scons: *** [build/temp-py/_cantera.os] Error 1
> scons: building terminated because of errors.
> ```
>
> See: https://github.com/Cantera/cantera/issues/1325
> Also:
> https://kojipkgs.fedoraproject.org/work/tasks/2453/88502453/build.log
>
> Best,
> -fuller
>
> --
> Mark E. Fuller, Ph.D.
> HaShikma 19, Apt. 24
> Nesher 3681219, Israel
> +972 (0)53-872-6579
> +49 (0)1577 1848188
> +1 401-214-4266
> mark.e.ful...@gmail.com
> mark.e.ful...@gmx.de
> ful...@stossrohr.net
> @fuller:one.ems.host
> https://www.stossrohr.net
> PGP Fingerprint: 73F1 A30C BDF4 DB4B C75F FD0F D599 E76C FFCA BF60
>
>
___
python-devel mailing list -- python-devel@lists.fedoraproject.org
To unsubscribe send an email to python-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/python-devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: Packages that failed to build with Python 3.11 (and what to do)

[Mark E. Fuller]

On 20/06/2022 14:45, Tomas Hrnciar wrote:

>
> ## Where to get help
>
> Reply to this thread or find us (thrnciar, mhroncok) on 
#fedora-python IRC channel (libera.chat)or Matrix 
(#python:fedoraproject.org ).

>
> ---
>
> Let us know if you have other questions.
>


Question: my error appears to be in a Python header.
Can someone take a look at this and giver me some quick feedback as to 
whether this is a problem for my package or a bug I should report?

It doesn't seem to fall into one of the neat categories described by Tomas

```
/usr/bin/python3 -c "import Cython.Build; 
Cython.Build.cythonize('build/python/cantera/_cantera.pyx')"

Compiling build/python/cantera/_cantera.pyx because it changed.
[1/1] Cythonizing build/python/cantera/_cantera.pyx
g++ -o build/temp-py/_cantera.os -c -std=c++11 -pthread -O3 -Wno-inline 
-g -fPIC -DNDEBUG -Iinclude -I/usr/include/python3.11 
-I/usr/lib64/python3.11/site-packages/numpy/core/include 
-I/usr/include/eigen3 build/python/cantera/_cantera.cpp
In file included from 
/usr/lib64/python3.11/site-packages/numpy/core/include/numpy/ndarraytypes.h:1960,
 from 
/usr/lib64/python3.11/site-packages/numpy/core/include/numpy/ndarrayobject.h:12,
 from 
/usr/lib64/python3.11/site-packages/numpy/core/include/numpy/arrayobject.h:5,

 from build/python/cantera/_cantera.cpp:749:
/usr/lib64/python3.11/site-packages/numpy/core/include/numpy/npy_1_7_deprecated_api.h:17:2: 
warning: #warning "Using deprecated NumPy API, disable it with " 
"#define NPY_NO_DEPRECATED_API NPY_1_7_API_VERSION" [-Wcpp]

   17 | #warning "Using deprecated NumPy API, disable it with " \
  |  ^~~
In file included from /usr/include/python3.11/Python.h:38,
 from build/python/cantera/_cantera.cpp:20:
/usr/include/python3.11/pyport.h: In instantiation of 'type 
{anonymous}::_Py_CAST_impl(const expr_type&) [with type = _object*; 
expr_type = int]':

build/python/cantera/_cantera.cpp:193144:9:   required from here
/usr/include/python3.11/pyport.h:47:24: error: invalid 'static_cast' 
from type 'int' to type '_object*'
   47 | return static_cast(const_cast&>(expr));

  | ^~~~
scons: *** [build/temp-py/_cantera.os] Error 1
scons: building terminated because of errors.
```

See: https://github.com/Cantera/cantera/issues/1325
Also: https://kojipkgs.fedoraproject.org/work/tasks/2453/88502453/build.log

Best,
-fuller

--
Mark E. Fuller, Ph.D.
HaShikma 19, Apt. 24
Nesher 3681219, Israel
+972 (0)53-872-6579
+49 (0)1577 1848188
+1 401-214-4266
mark.e.ful...@gmail.com
mark.e.ful...@gmx.de
ful...@stossrohr.net
@fuller:one.ems.host
https://www.stossrohr.net
PGP Fingerprint: 73F1 A30C BDF4 DB4B C75F FD0F D599 E76C FFCA BF60
___
python-devel mailing list -- python-devel@lists.fedoraproject.org
To unsubscribe send an email to python-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/python-devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: Packages that failed to build with Python 3.11 (and what to do)

[Mark E. Fuller]

On 20/06/2022 14:45, Tomas Hrnciar wrote:

>
> ## Where to get help
>
> Reply to this thread or find us (thrnciar, mhroncok) on 
#fedora-python IRC channel (libera.chat)or Matrix 
(#python:fedoraproject.org ).

>
> ---
>
> Let us know if you have other questions.
>


Question: my error appears to be in a Python header.
Can someone take a look at this and giver me some quick feedback as to 
whether this is a problem for my package or a bug I should report?

It doesn't seem to fall into one of the neat categories described by Tomas

```
/usr/bin/python3 -c "import Cython.Build; 
Cython.Build.cythonize('build/python/cantera/_cantera.pyx')"

Compiling build/python/cantera/_cantera.pyx because it changed.
[1/1] Cythonizing build/python/cantera/_cantera.pyx
g++ -o build/temp-py/_cantera.os -c -std=c++11 -pthread -O3 -Wno-inline 
-g -fPIC -DNDEBUG -Iinclude -I/usr/include/python3.11 
-I/usr/lib64/python3.11/site-packages/numpy/core/include 
-I/usr/include/eigen3 build/python/cantera/_cantera.cpp
In file included from 
/usr/lib64/python3.11/site-packages/numpy/core/include/numpy/ndarraytypes.h:1960,
 from 
/usr/lib64/python3.11/site-packages/numpy/core/include/numpy/ndarrayobject.h:12,
 from 
/usr/lib64/python3.11/site-packages/numpy/core/include/numpy/arrayobject.h:5,

 from build/python/cantera/_cantera.cpp:749:
/usr/lib64/python3.11/site-packages/numpy/core/include/numpy/npy_1_7_deprecated_api.h:17:2: 
warning: #warning "Using deprecated NumPy API, disable it with " 
"#define NPY_NO_DEPRECATED_API NPY_1_7_API_VERSION" [-Wcpp]

   17 | #warning "Using deprecated NumPy API, disable it with " \
  |  ^~~
In file included from /usr/include/python3.11/Python.h:38,
 from build/python/cantera/_cantera.cpp:20:
/usr/include/python3.11/pyport.h: In instantiation of 'type 
{anonymous}::_Py_CAST_impl(const expr_type&) [with type = _object*; 
expr_type = int]':

build/python/cantera/_cantera.cpp:193144:9:   required from here
/usr/include/python3.11/pyport.h:47:24: error: invalid 'static_cast' 
from type 'int' to type '_object*'
   47 | return static_cast(const_cast&>(expr));

  | ^~~~
scons: *** [build/temp-py/_cantera.os] Error 1
scons: building terminated because of errors.
```

See: https://github.com/Cantera/cantera/issues/1325
Also: https://kojipkgs.fedoraproject.org/work/tasks/2453/88502453/build.log

Best,
-fuller

--
Mark E. Fuller, Ph.D.
HaShikma 19, Apt. 24
Nesher 3681219, Israel
+972 (0)53-872-6579
+49 (0)1577 1848188
+1 401-214-4266
mark.e.ful...@gmail.com
mark.e.ful...@gmx.de
ful...@stossrohr.net
@fuller:one.ems.host
https://www.stossrohr.net
PGP Fingerprint: 73F1 A30C BDF4 DB4B C75F FD0F D599 E76C FFCA BF60
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: Packages that failed to build with Python 3.11 (and what to do)

[Miro Hrončok]

On 20. 06. 22 15:30, José Abílio Matos wrote:

On Monday, 20 June 2022 12.45.07 WEST Tomas Hrnciar wrote:

 > python-doit  immanetize jamatos


Looking in to src I search for the build to understand why did it failed:

https://koji.fedoraproject.org/koji/buildinfo?buildID=1989134 




as far as I can see it built without any issue.


Does that means that this is fixed and there is no need for an action by me?


Yes.

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

Re: Packages that failed to build with Python 3.11 (and what to do)

[José Abílio Matos]

On Monday, 20 June 2022 12.45.07 WEST Tomas Hrnciar wrote:
> python-doit  immanetize jamatos

Looking in to src I search for the build to understand why did it failed:
https://koji.fedoraproject.org/koji/buildinfo?buildID=1989134

as far as I can see it built without any issue.

Does that means that this is fixed and there is no need for an action by me?

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

Re: Packages that failed to build with Python 3.11 (and what to do)

[Miro Hrončok]

On 20. 06. 22 13:45, Tomas Hrnciar wrote:

## My package fails to build because it has broken build dependencies

Please try to track the missing build dependencies in Bugzilla. If possible, 
help the maintainers of your dependencies to get them rebuilt. When in need of 
escalation, ask us for provenpackager help (ideally with pull requests to be 
merged). Once possible, rebuild your package. When you do, the bugzilla will 
eventually get automatically closed, but you can do that manually as well.


Some raw data for this -- packages that have not been build because they are 
still waiting for other packages:


5minute:
- python-heatclient
- python-neutronclient
- python-openstacksdk
- python-os-client-config
- python-osc-lib
NiaAML-GUI:
- python-joblib
- python-niaaml
- python-scikit-learn
- python-threadpoolctl
blender:
- OpenColorIO
- usd
bodhi-server:
- python-arrow
- python-celery
- python-kombu
buildbot:
- python-autobahn
- python-txaio
calibre:
- python-cchardet
- python-mechanize
cfn-lint:
- python-jschema-to-python
- python-jsonpickle
- python-sarif-om
cobbler:
- python-cheetah
- python-contextlib2
copr-backend:
- fedmsg
- python-arrow
datagrepper:
- fedmsg
- python-arrow
- python-fedmsg-meta-fedora-infrastructure
datanommer:
- datanommer-commands
- fedmsg
- python-arrow
- python-datanommer-consumer
- python-fedmsg-meta-fedora-infrastructure
datanommer-commands:
- fedmsg
- python-arrow
- python-fedmsg-meta-fedora-infrastructure
gajim:
- python-nbxmpp
- python-precis_i18n
gr-air-modes:
- PyQt4
- gnuradio
- uhd
gr-funcube:
- gnuradio
- uhd
gr-hpsdr:
- gnuradio
- uhd
gr-iqbal:
- gnuradio
- uhd
gr-osmosdr:
- gnuradio
- gr-funcube
- gr-iqbal
- uhd
gr-rds:
- gnuradio
- uhd
luxcorerender:
- OpenColorIO
- python-pyside2
mirrormanager2:
- fedmsg
- python-arrow
module-build-service:
- fedmsg
- m2crypto
- python-arrow
- python-celery
- python-kombu
odcs:
- python-celery
- python-kombu
oraculum:
- python-celery
- python-kombu
paperwork:
- python-joblib
- python-paperwork-backend
- python-pycountry
- python-scikit-learn
- python-threadpoolctl
paraview:
- python-autobahn
- python-txaio
psi4:
- python-deepdiff
- python-jsonpickle
- python-qcelemental
pygrib:
- pyproj
- python-cartopy
python-EvoPreprocess:
- python-imbalanced-learn
- python-joblib
- python-scikit-learn
- python-threadpoolctl
python-SALib:
- python-multiprocess
- python-pathos
python-ZEO:
- python-BTrees
- python-ZODB
- python-manuel
- python-persistent
- python-zdaemon
- python-zodbpickle
python-ZODB:
- python-BTrees
- python-manuel
- python-persistent
- python-zodbpickle
python-ZODB3:
- python-BTrees
- python-ZEO
- python-ZODB
- python-persistent
- python-zdaemon
- python-zodbpickle
python-astroML:
- python-joblib
- python-scikit-learn
- python-threadpoolctl
python-astropy:
- python-pywt
- python-scikit-image
python-cartopy:
- pyproj
- python-OWSLib
python-ccdproc:
- python-pywt
- python-scikit-image
python-certbot-dns-digitalocean:
- python-digitalocean
- python-jsonpickle
python-chaospy:
- python-joblib
- python-scikit-learn
- python-threadpoolctl
python-contextualbandits:
- python-joblib
- python-scikit-learn
- python-threadpoolctl
python-cookiecutter:
- python-arrow
- python-jinja2-time
python-cro:
- python-joblib
- python-scikit-learn
- python-threadpoolctl
python-csvkit:
- python-agate
- python-agate-dbf
- python-agate-excel
- python-agate-sql
python-daphne:
- python-autobahn
- python-txaio
python-dask:
- pre-commit
- python-fsspec
- python-zarr
python-datanommer-consumer:
- fedmsg
- python-arrow
python-designateclient:
- python-openstacksdk
- python-osc-lib
python-earthpy:
- pyproj
- python-geopandas
- python-pywt
- python-rasterio
- python-scikit-image
python-elephant:
- python-joblib
- python-neo
- python-scikit-learn
- python-statsmodels
- python-threadpoolctl
python-envisage:
- python-pyface
- python-traitsui
python-fastapi:
- pre-commit
- python-peewee
- python-uvicorn
- python-watchgod
python-fedmsg-meta-fedora-infrastructure:
- fedmsg
- python-arrow
python-fixit:
- python-diff-cover
- python-libcst
python-flask-socketio:
- python-engineio
- python-socketio
python-fsleyes:
- python-fsleyes-props
- python-fslpy
- python-trimesh
python-fsleyes-props:
- python-fslpy
- python-trimesh
python-gatspy:
- python-astroML
- python-joblib
- python-scikit-learn
- python-threadpoolctl
python-glymur:
- python-pywt
- python-scikit-image
python-gnocchiclient:
- python-futurist
- python-openstacksdk
- python-osc-lib
python-google-cloud-asset:
- python-google-cloud-org-policy
- python-google-cloud-os-config
- python-proto-plus
python-google-cloud-containeranalysis:
- python-grafeas
- python-proto-plus
python-google-cloud-debugger-client:
- python-google-cloud-source-context
- python-proto-plus
python-google-cloud-filestore:
- python-google-cloud-common
- python-proto-plus
python-heatclient:
- python-openstacksdk
- python-osc-lib
python-imbalanced-learn:
- python-joblib
- python-scikit-learn
- python-threadpoolctl
python-libpysal:
- pyproj
- 

Re: Packages that failed to build with Python 3.11 (and what to do)

[Miro Hrončok]

On 20. 06. 22 13:45, Tomas Hrnciar wrote:

## My package fails to build because it has broken build dependencies

Please try to track the missing build dependencies in Bugzilla. If possible, 
help the maintainers of your dependencies to get them rebuilt. When in need of 
escalation, ask us for provenpackager help (ideally with pull requests to be 
merged). Once possible, rebuild your package. When you do, the bugzilla will 
eventually get automatically closed, but you can do that manually as well.


Some raw data for this -- packages that have not been build because they are 
still waiting for other packages:


5minute:
- python-heatclient
- python-neutronclient
- python-openstacksdk
- python-os-client-config
- python-osc-lib
NiaAML-GUI:
- python-joblib
- python-niaaml
- python-scikit-learn
- python-threadpoolctl
blender:
- OpenColorIO
- usd
bodhi-server:
- python-arrow
- python-celery
- python-kombu
buildbot:
- python-autobahn
- python-txaio
calibre:
- python-cchardet
- python-mechanize
cfn-lint:
- python-jschema-to-python
- python-jsonpickle
- python-sarif-om
cobbler:
- python-cheetah
- python-contextlib2
copr-backend:
- fedmsg
- python-arrow
datagrepper:
- fedmsg
- python-arrow
- python-fedmsg-meta-fedora-infrastructure
datanommer:
- datanommer-commands
- fedmsg
- python-arrow
- python-datanommer-consumer
- python-fedmsg-meta-fedora-infrastructure
datanommer-commands:
- fedmsg
- python-arrow
- python-fedmsg-meta-fedora-infrastructure
gajim:
- python-nbxmpp
- python-precis_i18n
gr-air-modes:
- PyQt4
- gnuradio
- uhd
gr-funcube:
- gnuradio
- uhd
gr-hpsdr:
- gnuradio
- uhd
gr-iqbal:
- gnuradio
- uhd
gr-osmosdr:
- gnuradio
- gr-funcube
- gr-iqbal
- uhd
gr-rds:
- gnuradio
- uhd
luxcorerender:
- OpenColorIO
- python-pyside2
mirrormanager2:
- fedmsg
- python-arrow
module-build-service:
- fedmsg
- m2crypto
- python-arrow
- python-celery
- python-kombu
odcs:
- python-celery
- python-kombu
oraculum:
- python-celery
- python-kombu
paperwork:
- python-joblib
- python-paperwork-backend
- python-pycountry
- python-scikit-learn
- python-threadpoolctl
paraview:
- python-autobahn
- python-txaio
psi4:
- python-deepdiff
- python-jsonpickle
- python-qcelemental
pygrib:
- pyproj
- python-cartopy
python-EvoPreprocess:
- python-imbalanced-learn
- python-joblib
- python-scikit-learn
- python-threadpoolctl
python-SALib:
- python-multiprocess
- python-pathos
python-ZEO:
- python-BTrees
- python-ZODB
- python-manuel
- python-persistent
- python-zdaemon
- python-zodbpickle
python-ZODB:
- python-BTrees
- python-manuel
- python-persistent
- python-zodbpickle
python-ZODB3:
- python-BTrees
- python-ZEO
- python-ZODB
- python-persistent
- python-zdaemon
- python-zodbpickle
python-astroML:
- python-joblib
- python-scikit-learn
- python-threadpoolctl
python-astropy:
- python-pywt
- python-scikit-image
python-cartopy:
- pyproj
- python-OWSLib
python-ccdproc:
- python-pywt
- python-scikit-image
python-certbot-dns-digitalocean:
- python-digitalocean
- python-jsonpickle
python-chaospy:
- python-joblib
- python-scikit-learn
- python-threadpoolctl
python-contextualbandits:
- python-joblib
- python-scikit-learn
- python-threadpoolctl
python-cookiecutter:
- python-arrow
- python-jinja2-time
python-cro:
- python-joblib
- python-scikit-learn
- python-threadpoolctl
python-csvkit:
- python-agate
- python-agate-dbf
- python-agate-excel
- python-agate-sql
python-daphne:
- python-autobahn
- python-txaio
python-dask:
- pre-commit
- python-fsspec
- python-zarr
python-datanommer-consumer:
- fedmsg
- python-arrow
python-designateclient:
- python-openstacksdk
- python-osc-lib
python-earthpy:
- pyproj
- python-geopandas
- python-pywt
- python-rasterio
- python-scikit-image
python-elephant:
- python-joblib
- python-neo
- python-scikit-learn
- python-statsmodels
- python-threadpoolctl
python-envisage:
- python-pyface
- python-traitsui
python-fastapi:
- pre-commit
- python-peewee
- python-uvicorn
- python-watchgod
python-fedmsg-meta-fedora-infrastructure:
- fedmsg
- python-arrow
python-fixit:
- python-diff-cover
- python-libcst
python-flask-socketio:
- python-engineio
- python-socketio
python-fsleyes:
- python-fsleyes-props
- python-fslpy
- python-trimesh
python-fsleyes-props:
- python-fslpy
- python-trimesh
python-gatspy:
- python-astroML
- python-joblib
- python-scikit-learn
- python-threadpoolctl
python-glymur:
- python-pywt
- python-scikit-image
python-gnocchiclient:
- python-futurist
- python-openstacksdk
- python-osc-lib
python-google-cloud-asset:
- python-google-cloud-org-policy
- python-google-cloud-os-config
- python-proto-plus
python-google-cloud-containeranalysis:
- python-grafeas
- python-proto-plus
python-google-cloud-debugger-client:
- python-google-cloud-source-context
- python-proto-plus
python-google-cloud-filestore:
- python-google-cloud-common
- python-proto-plus
python-heatclient:
- python-openstacksdk
- python-osc-lib
python-imbalanced-learn:
- python-joblib
- python-scikit-learn
- python-threadpoolctl
python-libpysal:
- pyproj
- 

Re: Packages that failed to build with Python 3.11 (and what to do)

[Vitaly Zaitsev via devel]

On 20/06/2022 13:45, Tomas Hrnciar wrote:

xvitaly    piper


meson.build:89: WARNING: Project targeting '>= 0.42.0' but tried to use 
feature introduced in '0.46.0': Python Module.

Program python3 (lxml, evdev, cairo, gi) found: NO modules: lxml, cairo, gi
meson.build:91:8: ERROR: python is missing modules: evdev

I don't know why meson can't find python3-evdev:
BuildRequires: python3-evdev

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

[EPEL-devel] Re: Packages disappearing from the EPEL 9 buildroot

[Troy Dawson]

On Wed, Dec 29, 2021 at 7:15 AM Stephen John Smoogen 
wrote:

>
>
> On Wed, 29 Dec 2021 at 06:29, Mattias Ellert 
> wrote:
>
>> Hi!
>>
>> Two packages I built for EPEL 9 are now reported by koschei as having
>> missing build dependencies.
>>
>> https://koschei.fedoraproject.org/package/davix?collection=epel9
>>
>> https://koschei.fedoraproject.org/package/uglify-js?collection=epel9
>>
>> The EPEL 9 builds were built using the following build dependencies
>> according to the root.log files:
>>
>> rapidjson-devel-1.1.0-19.el9
>>
> Looks like this is a RHEL buildroot only package, thus can just be built
in EPEL9.
 https://docs.fedoraproject.org/en-US/epel/epel-package-request/


>> web-assets-devel-5-15.el9
>>
> Although web-assets is built in RHEL9, they are only releasing
web-assets-filesystem
Thus, we are missing web-assets-devel and web-assets-httpd
https://docs.fedoraproject.org/en-US/epel/epel-faq/#rhel_8_has_binaries_in_the_release_but_is_missing_some_corresponding__devel_package._how_do_i_build_a_package_that_needs_that_missing__devel_package


> nodejs-packaging-2021.01-5.el9
>>
> Looks like this is a buildroot only package, thus can just be built in
EPEL9.
Definitely something we need.  I believe I can take that.


>> These can no longer be found in the koji buildroot. There are no
>> expired buildroot overrides for these builds, which could explain the
>> disappearance.
>>
>> I can't find these builds in EPEL's koji, so I guess they where
>> provided by RHEL, but now are no longer? Did RHEL dop these?
>>
>>
> OK there was a period in the EPEL-9 startup where the buildroot was
> pointing to a copy of the CentOS Stream-9 koji build root. This was done to
> help kickstart things, but it had the issue that packages that RHEL is not
> going to ship to customers were available also. About 2-3 weeks ago, the
> EPEL steering committee decided to move the buildroot to the properly
> shipped chain of packages in CentOS Stream versus the buildroot. This
> removed a bunch of packages that were 'available' but not going to be
> shipped. These packages will need to be made into epel-only packages or
> some other solution. I am fuzzy on this myself as I am from a different
> philosophy school of building and shipping packages.
>
___
epel-devel mailing list -- epel-devel@lists.fedoraproject.org
To unsubscribe send an email to epel-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/epel-devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

[EPEL-devel] Re: Packages disappearing from the EPEL 9 buildroot

[Stephen John Smoogen]

On Wed, 29 Dec 2021 at 06:29, Mattias Ellert 
wrote:

> Hi!
>
> Two packages I built for EPEL 9 are now reported by koschei as having
> missing build dependencies.
>
> https://koschei.fedoraproject.org/package/davix?collection=epel9
>
> https://koschei.fedoraproject.org/package/uglify-js?collection=epel9
>
> The EPEL 9 builds were built using the following build dependencies
> according to the root.log files:
>
> rapidjson-devel-1.1.0-19.el9
>
> web-assets-devel-5-15.el9
> nodejs-packaging-2021.01-5.el9
>
> These can no longer be found in the koji buildroot. There are no
> expired buildroot overrides for these builds, which could explain the
> disappearance.
>
> I can't find these builds in EPEL's koji, so I guess they where
> provided by RHEL, but now are no longer? Did RHEL dop these?
>
>
OK there was a period in the EPEL-9 startup where the buildroot was
pointing to a copy of the CentOS Stream-9 koji build root. This was done to
help kickstart things, but it had the issue that packages that RHEL is not
going to ship to customers were available also. About 2-3 weeks ago, the
EPEL steering committee decided to move the buildroot to the properly
shipped chain of packages in CentOS Stream versus the buildroot. This
removed a bunch of packages that were 'available' but not going to be
shipped. These packages will need to be made into epel-only packages or
some other solution. I am fuzzy on this myself as I am from a different
philosophy school of building and shipping packages.



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


-- 
Stephen J Smoogen.
Let us be kind to one another, for most of us are fighting a hard battle.
-- Ian MacClaren
___
epel-devel mailing list -- epel-devel@lists.fedoraproject.org
To unsubscribe send an email to epel-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/epel-devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: Packages that fail to install in Fedora 35 and might be retired one week before the beta freeze

[Thomas Andrejak]

Hi,

Sorry for the noise, I didn't notice that the job on libprelude was already
done. I checked all the Prelude packages and everything is good.

Let me know if I miss something to do.

Regards

Thomas

Le lun. 9 août 2021 à 13:29, Thomas Andrejak  a
écrit :

> Hi all,
>
> Sorry for the delay and the issues linked to *libprelude*. I will fix it
> before the end of this week.
>
> If someone wants to help me to fix it quickly, I'm OK :)
>
> Regards
>
> Thomas
>
> Le lun. 9 août 2021 à 08:10, Milan Crha  a écrit :
>
>> On Thu, 2021-08-05 at 14:20 -0400, Yaakov Selkowitz wrote:
>> > at least in the meantime, do you want to take it now that it's
>> > building again?
>>
>> Hi,
>> I took it for the time being, thus the package does not vanish from
>> Fedora. I'll pass the ownership to the original owners once they let me
>> know.
>>
>> Thank you for your help with patching the package.
>> Bye,
>> Milan
>> ___
>> devel mailing list -- devel@lists.fedoraproject.org
>> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
>> Fedora Code of Conduct:
>> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
>> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
>> List Archives:
>> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
>> Do not reply to spam on the list, report it:
>> https://pagure.io/fedora-infrastructure
>>
>
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: Packages that fail to install in Fedora 35 and might be retired one week before the beta freeze

[Thomas Andrejak]

Hi all,

Sorry for the delay and the issues linked to *libprelude*. I will fix it
before the end of this week.

If someone wants to help me to fix it quickly, I'm OK :)

Regards

Thomas

Le lun. 9 août 2021 à 08:10, Milan Crha  a écrit :

> On Thu, 2021-08-05 at 14:20 -0400, Yaakov Selkowitz wrote:
> > at least in the meantime, do you want to take it now that it's
> > building again?
>
> Hi,
> I took it for the time being, thus the package does not vanish from
> Fedora. I'll pass the ownership to the original owners once they let me
> know.
>
> Thank you for your help with patching the package.
> Bye,
> Milan
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
> Do not reply to spam on the list, report it:
> https://pagure.io/fedora-infrastructure
>
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: Packages that fail to install in Fedora 35 and might be retired one week before the beta freeze

[Milan Crha]

On Thu, 2021-08-05 at 14:20 -0400, Yaakov Selkowitz wrote:
> at least in the meantime, do you want to take it now that it's
> building again?

Hi,
I took it for the time being, thus the package does not vanish from
Fedora. I'll pass the ownership to the original owners once they let me
know.

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

Re: Packages that fail to install in Fedora 35 and might be retired one week before the beta freeze

[Miro Hrončok]

On 06. 08. 21 12:31, Felix Schwarz wrote:


Am 05.08.21 um 14:00 schrieb Miro Hrončok:

eclipse akurtakov, dbhole, eclipse-sig,    11 weeks
 jerboaa, jjohnstn, lef, mbooth,
 oliver, rgrunber


What is the idea here? Is that a fallout of the Javapocalypse/the state of Java 
in Fedora? Will users be able to get Eclipse from Fedora for F35+?


Yes, this is a fallout of the broken Java in Fedora.

At this point no. Eclipse is not installable on Fedora 35, hence Fedora 35 user 
will not be able to use 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
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: Packages that fail to install in Fedora 35 and might be retired one week before the beta freeze

[Felix Schwarz]

Am 05.08.21 um 14:00 schrieb Miro Hrončok:

eclipse akurtakov, dbhole, eclipse-sig,    11 weeks
     jerboaa, jjohnstn, lef, mbooth,
     oliver, rgrunber


What is the idea here? Is that a fallout of the Javapocalypse/the state of Java 
in Fedora? Will users be able to get Eclipse from Fedora for F35+?


(I'm using Eclipse + pydev a lot so I'm interested in having these packages 
available. However I can't take any more packages.)


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

Re: Packages that fail to install in Fedora 35 and might be retired one week before the beta freeze

[Miro Hrončok]

On 06. 08. 21 7:44, Milan Crha wrote:

On Thu, 2021-08-05 at 14:20 -0400, Yaakov Selkowitz wrote:

The former owner appears to also be the upstream, so they might be
back, but at least in the meantime, do you want to take it now that
it's building again?


Hi,
I'm not sure I'm the best person, I do not follow the development of
the libpst at all, neither I've any idea about its internals. A simple
revert of the orphan would be the best choice, from my point of view,
because the orphan was kind of mistake, due to no problem with the
package itself. I do not know why it had been missed earlier. It
happens. If there's no other choice, I can take it temporarily.


The orphaning was no mistake, the maintainer was not responding to installation 
failure for many weeks.


If they wish to take the package back, they can do that.

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

Re: Packages that fail to install in Fedora 35 and might be retired one week before the beta freeze

[Milan Crha]

On Thu, 2021-08-05 at 09:41 -0700, Adam Williamson wrote:
> I don't think autoconf-archive is usually actually used in builds, the
> package sources generally contain the macros.

Hi,
that's why I mentioned the libpst runs autoreconf [1]. I can be wrong
though, I thought the autoreconf updates also the m4 macros. I left
autotools usage years ago.

I think adding the python-unversioned-command into the BuildRequires
can avoid similar issues in the future. Whether it's correct or not I
do not know.
Bye,
Milan

[1] in specific, it runs:

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

Re: Packages that fail to install in Fedora 35 and might be retired one week before the beta freeze

[Milan Crha]

On Thu, 2021-08-05 at 14:20 -0400, Yaakov Selkowitz wrote:
> The former owner appears to also be the upstream, so they might be
> back, but at least in the meantime, do you want to take it now that
> it's building again?

Hi,
I'm not sure I'm the best person, I do not follow the development of
the libpst at all, neither I've any idea about its internals. A simple
revert of the orphan would be the best choice, from my point of view,
because the orphan was kind of mistake, due to no problem with the
package itself. I do not know why it had been missed earlier. It
happens. If there's no other choice, I can take it temporarily.
Bye,
Milan
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: Packages that fail to install in Fedora 35 and might be retired one week before the beta freeze

[Yaakov Selkowitz]

On Thu, 2021-08-05 at 17:41 +0200, Milan Crha wrote:
> On Thu, 2021-08-05 at 14:00 +0200, Miro Hrončok wrote:
> > libpst
> 
> Hi,
> I do not own the package, only one from my pool depends on it,

The package was orphaned yesterday as part of this progress.  The former owner
appears to also be the upstream, so they might be back, but at least in the
meantime, do you want to take it now that it's building again?

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

Re: Packages that fail to install in Fedora 35 and might be retired one week before the beta freeze

[Björn 'besser82' Esser]

Am Donnerstag, dem 05.08.2021 um 13:39 -0400 schrieb Yaakov Selkowitz:
> On Thu, 2021-08-05 at 18:39 +0200, Björn 'besser82' Esser wrote:
> > Am Donnerstag, dem 05.08.2021 um 17:41 +0200 schrieb Milan Crha:
> > > On Thu, 2021-08-05 at 14:00 +0200, Miro Hrončok wrote:
> > > > libpst
> > > 
> > > Hi,
> > > I do not own the package, only one from my pool depends on it, but
> > > looking into the build failure, the autoconf failed to find python
> > > binary. Digging deeper, in the autoconf-archive-2021.02.19-2.fc35,
> > > the
> > > ax_python.m4 still  references only up to version 3.9 (and there's
> > > no
> > > `python` binary during the libpst build, because not installing
> > > also
> > > python-unversioned-command). Note the libpst does run autoreconf.
> > > Maybe
> > > more packages using autoconf are affected by this.
> > > 
> > > Should anyone update the autoconf-archive and then rebuild the
> > > affected
> > > packages? I cannot do it myself, I do not have enough powers.
> > > Thanks and bye,
> > > Milan
> > 
> > I've added a patch to autoconf-archive for Python 3.10.  Build for
> > Rawhide is running:
> > 
> > https://koji.fedoraproject.org/koji/taskinfo?taskID=73342788
> 
> Another fix is needed for AX_PYTHON_DEVEL, already filed upstream:
> 
> https://github.com/autoconf-archive/autoconf-archive/pull/235


I've updated the patch in the autoconf-archive package with your patch.
Thanks!


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

Re: Packages that fail to install in Fedora 35 and might be retired one week before the beta freeze

[Yaakov Selkowitz]

On Thu, 2021-08-05 at 18:39 +0200, Björn 'besser82' Esser wrote:
> Am Donnerstag, dem 05.08.2021 um 17:41 +0200 schrieb Milan Crha:
> > On Thu, 2021-08-05 at 14:00 +0200, Miro Hrončok wrote:
> > > libpst
> > 
> > Hi,
> > I do not own the package, only one from my pool depends on it, but
> > looking into the build failure, the autoconf failed to find python
> > binary. Digging deeper, in the autoconf-archive-2021.02.19-2.fc35, the
> > ax_python.m4 still  references only up to version 3.9 (and there's no
> > `python` binary during the libpst build, because not installing also
> > python-unversioned-command). Note the libpst does run autoreconf. Maybe
> > more packages using autoconf are affected by this.
> > 
> > Should anyone update the autoconf-archive and then rebuild the affected
> > packages? I cannot do it myself, I do not have enough powers.
> > Thanks and bye,
> > Milan
> 
> I've added a patch to autoconf-archive for Python 3.10.  Build for
> Rawhide is running:
> 
> https://koji.fedoraproject.org/koji/taskinfo?taskID=73342788

Another fix is needed for AX_PYTHON_DEVEL, already filed upstream:

https://github.com/autoconf-archive/autoconf-archive/pull/235

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

Re: Packages that fail to install in Fedora 35 and might be retired one week before the beta freeze

[Adam Williamson]

On Thu, 2021-08-05 at 17:41 +0200, Milan Crha wrote:
> On Thu, 2021-08-05 at 14:00 +0200, Miro Hrončok wrote:
> > libpst
> 
>   Hi,
> I do not own the package, only one from my pool depends on it, but
> looking into the build failure, the autoconf failed to find python
> binary. Digging deeper, in the autoconf-archive-2021.02.19-2.fc35, the
> ax_python.m4 still  references only up to version 3.9 (and there's no
> `python` binary during the libpst build, because not installing also
> python-unversioned-command). Note the libpst does run autoreconf. Maybe
> more packages using autoconf are affected by this.
> 
> Should anyone update the autoconf-archive and then rebuild the affected
> packages? I cannot do it myself, I do not have enough powers.

I don't think autoconf-archive is usually actually used in builds, the
package sources generally contain the macros. It looks like yselkowitz
already patched Python 3.10 support into libpst's copies of the macros
and rebuilt it just now:

https://koji.fedoraproject.org/koji/buildinfo?buildID=1814151
-- 
Adam Williamson
Fedora QA
IRC: adamw | Twitter: adamw_ha
https://www.happyassassin.net

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

Re: Packages that fail to install in Fedora 35 and might be retired one week before the beta freeze

[Björn 'besser82' Esser]

Am Donnerstag, dem 05.08.2021 um 17:41 +0200 schrieb Milan Crha:
> On Thu, 2021-08-05 at 14:00 +0200, Miro Hrončok wrote:
> > libpst
> 
> Hi,
> I do not own the package, only one from my pool depends on it, but
> looking into the build failure, the autoconf failed to find python
> binary. Digging deeper, in the autoconf-archive-2021.02.19-2.fc35, the
> ax_python.m4 still  references only up to version 3.9 (and there's no
> `python` binary during the libpst build, because not installing also
> python-unversioned-command). Note the libpst does run autoreconf. Maybe
> more packages using autoconf are affected by this.
> 
> Should anyone update the autoconf-archive and then rebuild the affected
> packages? I cannot do it myself, I do not have enough powers.
> Thanks and bye,
> Milan

I've added a patch to autoconf-archive for Python 3.10.  Build for
Rawhide is running:

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

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

Re: Packages that fail to install in Fedora 35 and might be retired one week before the beta freeze

[Milan Crha]

On Thu, 2021-08-05 at 14:00 +0200, Miro Hrončok wrote:
> libpst

Hi,
I do not own the package, only one from my pool depends on it, but
looking into the build failure, the autoconf failed to find python
binary. Digging deeper, in the autoconf-archive-2021.02.19-2.fc35, the
ax_python.m4 still  references only up to version 3.9 (and there's no
`python` binary during the libpst build, because not installing also
python-unversioned-command). Note the libpst does run autoreconf. Maybe
more packages using autoconf are affected by this.

Should anyone update the autoconf-archive and then rebuild the affected
packages? I cannot do it myself, I do not have enough powers.
Thanks and bye,
Milan
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: Packages that fail to install in Fedora 35 and might be retired one week before the beta freeze

[Gwyn Ciesla via devel]

I've taken and am fixing libprelude.

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

Sent with ProtonMail Secure Email.

‐‐‐ Original Message ‐‐‐

On Thursday, August 5th, 2021 at 7:00 AM, Miro Hrončok  
wrote:

> Hello,
> 

> here are the packages that should be retired according to the policy one week
> 

> before the beta freeze, that is on 2021-08-17.
> 

> If you see a pacakge that you would rather fix than retire, please assign the
> 

> bugzilla (move it to ASSIGNED or higher) and start working on the fix.
> 

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

> (point 9)
> 

> Criterion:
> 

> -   fails to install for 8+ weeks (estimated as of 2021-08-17)
> -   bugzilla in NEW
> -   at least two reminders in the bugzilla
> 

> Bugzilla link:
> 

> 
> https://bugzilla.redhat.com/buglist.cgi?bug_id=1897089,1897607,1899122,1900756,1907450,1926069,1926086,1926209,1926211,1926215,1926222,1926350,1926357,1926613,1926616,1935721,1957797,1958156,1959330,1962230,1962449,1964630,1964642,1965616,1965617,1965623,1967196,1968780,1968843,1968948,1968957,1968976,1968977,1969083,1969084,1969130,1969814,1969815,1969818,1969822,1969823
> 

> Package (co)maintainers Est. BZ age
> 

> 
> ==
> 

> autoarchive orphan 27 weeks
> 

> bugzilla2fedmsg orphan 10 weeks
> 

> eclipse akurtakov, dbhole, eclipse-sig, 11 weeks
> 

> jerboaa, jjohnstn, lef, mbooth,
> 

> oliver, rgrunber
> 

> eclipse-m2e-core akurtakov, eclipse-sig, galileo, 11 weeks
> 

> mbooth, mizdebsk
> 

> eclipse-mpc akurtakov, eclipse-sig, kdaniel, 11 weeks
> 

> mbooth, rgrunber
> 

> gnome-gmail orphan 14 weeks
> 

> jboss-jsp-2.2-api cerberus 9 weeks
> 

> kawa moceap 9 weeks
> 

> libprelude fab, orphan 10 weeks
> 

> libpst orphan 39 weeks
> 

> maven-license-plugin orphan 11 weeks
> 

> module-build-service breilly, orphan 10 weeks
> 

> msv filiperosset, mizdebsk 9 weeks
> 

> python-aenum orphan 38 weeks
> 

> python-aiostream orphan 14 weeks
> 

> python-compreffor orphan 26 weeks
> 

> python-databay orphan 10 weeks
> 

> python-diskcache orphan 12 weeks
> 

> python-django-post_office orphan 10 weeks
> 

> python-docx orphan 27 weeks
> 

> python-flask-autoindex orphan 10 weeks
> 

> python-flask-silk orphan 10 weeks
> 

> python-furl orphan 27 weeks
> 

> python-jsonfield orphan 12 weeks
> 

> python-jsons orphan 35 weeks
> 

> python-losant-rest orphan 26 weeks
> 

> python-lzo orphan 39 weeks
> 

> python-minibelt orphan 27 weeks
> 

> python-mtg orphan 27 weeks
> 

> python-orderedmultidict orphan 27 weeks
> 

> python-praw fale, orphan 10 weeks
> 

> python-prawcore orphan 10 weeks
> 

> python-schedule orphan 27 weeks
> 

> python-siosocks orphan 10 weeks
> 

> python-soco orphan 23 weeks
> 

> python-stompest orphan 27 weeks
> 

> python-testfixtures orphan 38 weeks
> 

> python-twilio orphan 13 weeks
> 

> sunflow michalvala 9 weeks
> 

> xmms-pulse orphan 11 weeks
> 

> xstream dchen, mizdebsk, msimacek 9 weeks
> 

> The following packages require above mentioned packages:
> 

> Depending on: eclipse (33)
> 

> eclipse (maintained by: akurtakov, dbhole, eclipse-sig, jerboaa, jjohnstn,
> 

> lef, mbooth, oliver, rgrunber)
> 

> eclipse-1:4.19-5.fc35.src requires eclipse-ecf-core = 3.14.19-2.fc34,
> 

> eclipse-emf-core = 1:2.25.0-1.fc35, eclipse-pde = 1:4.19-5.fc35, tycho =
> 

> 2.2.0-4.fc34, tycho-extras = 2.2.0-4.fc34
> 

> eclipse-ecf (maintained by: akurtakov, eclipse-sig, kdaniel, mbooth, 
> rgrunber)
> 

> eclipse-ecf-core-3.14.19-2.fc34.noarch requires 
> osgi(org.eclipse.core.jobs) =
> 

> 3.10.1100, osgi(org.eclipse.core.net) = 1.3.1000, osgi(org.eclipse.osgi) 
> = 3.16.200
> 

> eclipse-egit (maintained by: akurtakov, eclipse-sig, jerboaa, jjohnstn,
> 

> mbooth, rgrunber)
> 

> eclipse-egit-5.11.0-1.fc35.noarch requires eclipse-platform = 
> 1:4.19-5.fc35,
> 

> osgi(org.eclipse.jdt.core) = 3.25.0.v20210304.1735, 
> osgi(org.eclipse.jdt.ui) =
> 

> 3.22.100.v20210304.1735
> 

> eclipse-egit-5.11.0-1.fc35.src requires eclipse-jdt = 1:4.19-5.fc35,
> 

> eclipse-platform = 1:4.19-5.fc35
> 

> eclipse-emf (maintained by: akurtakov, eclipse-sig, jjohnstn, mbooth, 
> rgrunber)
> 

> eclipse-emf-1:2.25.0-1.fc35.src requires eclipse-pde = 1:4.19-5.fc35
> 

> 

Re: Packages that failed to build with Python 3.10 (and what to do)

[Miro Hrončok]

On 08. 06. 21 15:58, Tomas Hrnciar wrote:
Chances are, you already got an automated F35FailsToInstall bugzilla from Miro, 
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 dependingon 
the bugzilla for the missing dep. Weslowly progress to do that as well, but 
your help is crucial here.


Hello Pythonistas.

A week has passed and many of the bugzillas received a first automatic 
reminder. I realize that one week might have been too soon for many of them.


If you got a needinfo from me today and thought "What the hell, Miro, I cannot 
do anything, this is waiting for another package to build first", I feel you 
and I am sorry for the spam. Just set the bugzilla to ASSIGNED to acknowledge 
you know about the situation and no more automated reminders like this will 
bother you. I recommend having a look at the dependency that blocks you and 
offering help to move things forward.


OTOH If you are blocked on another package not building, the reminder might get 
things moving: Some of the "Fails to build from source with Python 3.10" 
bugzillas are open with no response for many months and there was no policy to 
escalate them until we merged the side tag.



Anyway,
sorry for the noise and thanks for you help so far!

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

Re: Packages that failed to build with Python 3.10 (and what to do)

[Miro Hrončok]

On 08. 06. 21 15:58, Tomas Hrnciar wrote:
Chances are, you already got an automated F35FailsToInstall bugzilla from Miro, 
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 dependingon 
the bugzilla for the missing dep. Weslowly progress to do that as well, but 
your help is crucial here.


Hello Pythonistas.

A week has passed and many of the bugzillas received a first automatic 
reminder. I realize that one week might have been too soon for many of them.


If you got a needinfo from me today and thought "What the hell, Miro, I cannot 
do anything, this is waiting for another package to build first", I feel you 
and I am sorry for the spam. Just set the bugzilla to ASSIGNED to acknowledge 
you know about the situation and no more automated reminders like this will 
bother you. I recommend having a look at the dependency that blocks you and 
offering help to move things forward.


OTOH If you are blocked on another package not building, the reminder might get 
things moving: Some of the "Fails to build from source with Python 3.10" 
bugzillas are open with no response for many months and there was no policy to 
escalate them until we merged the side tag.



Anyway,
sorry for the noise and thanks for you help so far!

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

Re: Packages that failed to build with Python 3.10 (and what to do)

[Miro Hrončok]

On 09. 06. 21 2:44, Michel Alexandre Salim via devel wrote:

On Tue, Jun 08, 2021 at 05:38:27PM -0700, Michel Alexandre Salim via devel 
wrote:

Hi,

On Tue, Jun 08, 2021 at 03:58:04PM +0200, Tomas Hrnciar wrote:

Hello.

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

https://fedoraproject.org/wiki/Changes/Python3.10



For some reason, `mock -r fedora-rawhide-x86_64 install python3` is
still pulling in python3-3.9.5-2.fc35.x86_64

This makes testing any fix rather difficult, as it will pass locally and
then fail when doing a Koji (scratch) build.

e.g. https://src.fedoraproject.org/rpms/python-typeguard/pull-request/2


For future reference, `mock --enablerepo=local` does the trick.


Yes, as written in the original email:


## How to run things locally?

You can use mock. Make sure to:

 1. Clear all caches first: $ mock -r fedora-rawhide-x86_64--scrub=all
 2. Use the Koji repo: $ mock -r fedora-rawhide-x86_64 --enablerepo=local ...




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

Re: Packages that failed to build with Python 3.10 (and what to do)

[Kevin Fenzi]

On Tue, Jun 08, 2021 at 05:44:20PM -0700, Michel Alexandre Salim via devel 
wrote:
> On Tue, Jun 08, 2021 at 05:38:27PM -0700, Michel Alexandre Salim via devel 
> wrote:
> > Hi,
> > 
> > On Tue, Jun 08, 2021 at 03:58:04PM +0200, Tomas Hrnciar wrote:
> > > Hello.
> > > 
> > > As you might already know, we have recently merged in the Python 3.10 side
> > > tag to Rawhide, despite several builds not succeeding. We always aim for
> > > some compromise between having the side tag open for too long and having
> > > too many failures.
> > > 
> > > https://fedoraproject.org/wiki/Changes/Python3.10
> > > 
> > 
> > For some reason, `mock -r fedora-rawhide-x86_64 install python3` is
> > still pulling in python3-3.9.5-2.fc35.x86_64
> > 
> > This makes testing any fix rather difficult, as it will pass locally and
> > then fail when doing a Koji (scratch) build.
> > 
> > e.g. https://src.fedoraproject.org/rpms/python-typeguard/pull-request/2
> > 
> For future reference, `mock --enablerepo=local` does the trick.

This is because rawhide composes are (still) broken. 
:(

Hopefully things will get fixed up soon...

kevin


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

Re: Packages that failed to build with Python 3.10 (and what to do)

[Michel Alexandre Salim via devel]

On Tue, Jun 08, 2021 at 05:38:27PM -0700, Michel Alexandre Salim via devel 
wrote:
> Hi,
> 
> On Tue, Jun 08, 2021 at 03:58:04PM +0200, Tomas Hrnciar wrote:
> > Hello.
> > 
> > As you might already know, we have recently merged in the Python 3.10 side
> > tag to Rawhide, despite several builds not succeeding. We always aim for
> > some compromise between having the side tag open for too long and having
> > too many failures.
> > 
> > https://fedoraproject.org/wiki/Changes/Python3.10
> > 
> 
> For some reason, `mock -r fedora-rawhide-x86_64 install python3` is
> still pulling in python3-3.9.5-2.fc35.x86_64
> 
> This makes testing any fix rather difficult, as it will pass locally and
> then fail when doing a Koji (scratch) build.
> 
> e.g. https://src.fedoraproject.org/rpms/python-typeguard/pull-request/2
> 
For future reference, `mock --enablerepo=local` does the trick.

Best regards,

-- 
Michel Alexandre Salim
profile: https://keyoxide.org/mic...@michel-slm.name


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

Re: Packages that failed to build with Python 3.10 (and what to do)

[Michel Alexandre Salim via devel]

Hi,

On Tue, Jun 08, 2021 at 03:58:04PM +0200, Tomas Hrnciar wrote:
> Hello.
> 
> As you might already know, we have recently merged in the Python 3.10 side
> tag to Rawhide, despite several builds not succeeding. We always aim for
> some compromise between having the side tag open for too long and having
> too many failures.
> 
> https://fedoraproject.org/wiki/Changes/Python3.10
> 

For some reason, `mock -r fedora-rawhide-x86_64 install python3` is
still pulling in python3-3.9.5-2.fc35.x86_64

This makes testing any fix rather difficult, as it will pass locally and
then fail when doing a Koji (scratch) build.

e.g. https://src.fedoraproject.org/rpms/python-typeguard/pull-request/2

Best regards,

-- 
Michel Alexandre Salim
profile: https://keyoxide.org/mic...@michel-slm.name


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

Re: Packages that failed to build with Python 3.10 (and what to do)

[Miro Hrončok]

On 08. 06. 21 21:52, Jos de Kloe wrote:

I am seeing this error when trying to build locally using mock:

Error:
  Problem: package python3-xarray-0.17.0-1.fc35.noarch requires python(abi) = 
3.9, but none of the providers can be installed
   - package python3-devel-3.10.0~b2-3.fc35.x86_64 conflicts with python3 < 
3.10.0~b2-3.fc35 provided by python3-3.9.5-2.fc35.i686
   - package python3-devel-3.10.0~b2-3.fc35.x86_64 conflicts with python3 < 
3.10.0~b2-3.fc35 provided by python3-3.9.5-2.fc35.x86_64

   - cannot install the best candidate for the job
(try to add '--skip-broken' to skip uninstallable packages or '--nobest' to use 
not only best candidate packages)


So I get that python3-xarray has not yet been rebuild.
I'll add that pyproj dependency to bugzilla in a moment.

But what about this conflict between i686 and x86_64 python3-devel versions? 
That should not happen I think with a mock rebuild command like this:


mock -r fedora-rawhide-x86_64 --enablerepo=local --rebuild 
pyproj-3.1.0-1.fc34.src.rpm


Any idea what to do to solve that?


The conflict between i686 and x86_64 is just dnf resolver desperately trying to 
resolve somehow. When python3-xarray is rebuilt, you will not get that error.


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

Re: Packages that failed to build with Python 3.10 (and what to do)

[Miro Hrončok]

On 08. 06. 21 21:52, Jos de Kloe wrote:

I am seeing this error when trying to build locally using mock:

Error:
  Problem: package python3-xarray-0.17.0-1.fc35.noarch requires python(abi) = 
3.9, but none of the providers can be installed
   - package python3-devel-3.10.0~b2-3.fc35.x86_64 conflicts with python3 < 
3.10.0~b2-3.fc35 provided by python3-3.9.5-2.fc35.i686
   - package python3-devel-3.10.0~b2-3.fc35.x86_64 conflicts with python3 < 
3.10.0~b2-3.fc35 provided by python3-3.9.5-2.fc35.x86_64

   - cannot install the best candidate for the job
(try to add '--skip-broken' to skip uninstallable packages or '--nobest' to use 
not only best candidate packages)


So I get that python3-xarray has not yet been rebuild.
I'll add that pyproj dependency to bugzilla in a moment.

But what about this conflict between i686 and x86_64 python3-devel versions? 
That should not happen I think with a mock rebuild command like this:


mock -r fedora-rawhide-x86_64 --enablerepo=local --rebuild 
pyproj-3.1.0-1.fc34.src.rpm


Any idea what to do to solve that?


The conflict between i686 and x86_64 is just dnf resolver desperately trying to 
resolve somehow. When python3-xarray is rebuilt, you will not get that error.


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

Re: Packages that failed to build with Python 3.10 (and what to do)

[Jos de Kloe]

I am seeing this error when trying to build locally using mock:

Error:
 Problem: package python3-xarray-0.17.0-1.fc35.noarch requires 
python(abi) = 3.9, but none of the providers can be installed
  - package python3-devel-3.10.0~b2-3.fc35.x86_64 conflicts with 
python3 < 3.10.0~b2-3.fc35 provided by python3-3.9.5-2.fc35.i686
  - package python3-devel-3.10.0~b2-3.fc35.x86_64 conflicts with 
python3 < 3.10.0~b2-3.fc35 provided by python3-3.9.5-2.fc35.x86_64

  - cannot install the best candidate for the job
(try to add '--skip-broken' to skip uninstallable packages or '--nobest' 
to use not only best candidate packages)


So I get that python3-xarray has not yet been rebuild.
I'll add that pyproj dependency to bugzilla in a moment.

But what about this conflict between i686 and x86_64 python3-devel 
versions? That should not happen I think with a mock rebuild command 
like this:


mock -r fedora-rawhide-x86_64 --enablerepo=local --rebuild 
pyproj-3.1.0-1.fc34.src.rpm


Any idea what to do to solve that?

Jos

On 6/8/21 3:58 PM, Tomas Hrnciar wrote:

Hello.

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


https://fedoraproject.org/wiki/Changes/Python3.10 



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.


Most of the packages only fail to build because their dependencies were 
not yet rebuilt. Chances are, you already got an automated 
F35FailsToInstall bugzilla from Miro, 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 dependingon the 
bugzilla for the missing dep. Weslowly progress to do that as well, but 
your help is crucial here.


If your package fails because there isanon-dependency problem, you might 
have already received a bugzilla from us in the past. If the build 
failure is related to changes in Python 3.10, it should contain some 
hints about the problem.


# What to do?

General advice: If you are aware of the problem and working towards 
fixing it, set your bugzilla to ASSIGNED to avoid further automated 
reminders.


If blocked by dependencies, do not close the bugzillas as NOTABUG or 
DUPLICATE just because it is "not a problem in your package". The 
automation will file new ones anyway.


## My package fails to build because it has test failures in %check

Please, try to resolve the failures. If you are confident that the 
package works fine, but the tests are wrong, skip some failing tests, 
ideally with a link to an upstream issue. Do not disable (e.g. comment 
out) all tests just to unblock the rebuild of your package, it usually 
only hides the problem.


## My package fails to build because it has broken build dependencies

Please try to track the missing build dependencies in Bugzilla. If 
possible, help the maintainers of your dependencies to get them rebuilt. 
When in need of escalation, ask us for provenpackager help (ideally with 
pull requests to be merged). Once possible, rebuild your package (no 
need to bump the release, we already did that). When you do, the 
bugzilla will eventually get automatically closed, but you can do that 
manually as well.


## My package was rebuilt with Python 3.10 but it has broken runtime 
dependencies


Please try to track the missing runtime dependencies in Bugzilla. If 
possible, help the maintainers of your dependencies to get them rebuilt. 
When in need of escalation, ask us for provenpackager help (ideally with 
pull requests to be merged). When the dependencies are rebuilt, your 
package will install successfully once again and the bugzilla will 
eventually get automatically closed, but you can do that manually as well.


## My package failed to build but installs just fine

Some packages that only require libpython3.9.so.1.0 will successfully 
pull in the python3.9 package as a dependency and hence they don't have 
installation issues. They need to be rebuilt with Python 3.10 anyway, we 
don't want Fedora users to pull in two Python versions unless they need 
them for development purposes.


## How to run things locally?

You can use mock. Make sure to:

  1. Clear all caches first: $ mock -r fedora-rawhide-x86_64--scrub=all
  2. Use the Koji repo: $ mock -r fedora-rawhide-x86_64 
--enablerepo=local ...


## Where to get help

Reply to this thread or find us (thrnciar, mhroncok) on #fedora-python 
IRC channel (libera.chat).


---

Let usknow if you have other questions.

Maintainers by package:
5minute  pmoravco
APLpy    sergiopr 

Re: Packages that failed to build with Python 3.10 (and what to do)

[Jos de Kloe]

I am seeing this error when trying to build locally using mock:

Error:
 Problem: package python3-xarray-0.17.0-1.fc35.noarch requires 
python(abi) = 3.9, but none of the providers can be installed
  - package python3-devel-3.10.0~b2-3.fc35.x86_64 conflicts with 
python3 < 3.10.0~b2-3.fc35 provided by python3-3.9.5-2.fc35.i686
  - package python3-devel-3.10.0~b2-3.fc35.x86_64 conflicts with 
python3 < 3.10.0~b2-3.fc35 provided by python3-3.9.5-2.fc35.x86_64

  - cannot install the best candidate for the job
(try to add '--skip-broken' to skip uninstallable packages or '--nobest' 
to use not only best candidate packages)


So I get that python3-xarray has not yet been rebuild.
I'll add that pyproj dependency to bugzilla in a moment.

But what about this conflict between i686 and x86_64 python3-devel 
versions? That should not happen I think with a mock rebuild command 
like this:


mock -r fedora-rawhide-x86_64 --enablerepo=local --rebuild 
pyproj-3.1.0-1.fc34.src.rpm


Any idea what to do to solve that?

Jos

On 6/8/21 3:58 PM, Tomas Hrnciar wrote:

Hello.

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


https://fedoraproject.org/wiki/Changes/Python3.10 



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.


Most of the packages only fail to build because their dependencies were 
not yet rebuilt. Chances are, you already got an automated 
F35FailsToInstall bugzilla from Miro, 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 dependingon the 
bugzilla for the missing dep. Weslowly progress to do that as well, but 
your help is crucial here.


If your package fails because there isanon-dependency problem, you might 
have already received a bugzilla from us in the past. If the build 
failure is related to changes in Python 3.10, it should contain some 
hints about the problem.


# What to do?

General advice: If you are aware of the problem and working towards 
fixing it, set your bugzilla to ASSIGNED to avoid further automated 
reminders.


If blocked by dependencies, do not close the bugzillas as NOTABUG or 
DUPLICATE just because it is "not a problem in your package". The 
automation will file new ones anyway.


## My package fails to build because it has test failures in %check

Please, try to resolve the failures. If you are confident that the 
package works fine, but the tests are wrong, skip some failing tests, 
ideally with a link to an upstream issue. Do not disable (e.g. comment 
out) all tests just to unblock the rebuild of your package, it usually 
only hides the problem.


## My package fails to build because it has broken build dependencies

Please try to track the missing build dependencies in Bugzilla. If 
possible, help the maintainers of your dependencies to get them rebuilt. 
When in need of escalation, ask us for provenpackager help (ideally with 
pull requests to be merged). Once possible, rebuild your package (no 
need to bump the release, we already did that). When you do, the 
bugzilla will eventually get automatically closed, but you can do that 
manually as well.


## My package was rebuilt with Python 3.10 but it has broken runtime 
dependencies


Please try to track the missing runtime dependencies in Bugzilla. If 
possible, help the maintainers of your dependencies to get them rebuilt. 
When in need of escalation, ask us for provenpackager help (ideally with 
pull requests to be merged). When the dependencies are rebuilt, your 
package will install successfully once again and the bugzilla will 
eventually get automatically closed, but you can do that manually as well.


## My package failed to build but installs just fine

Some packages that only require libpython3.9.so.1.0 will successfully 
pull in the python3.9 package as a dependency and hence they don't have 
installation issues. They need to be rebuilt with Python 3.10 anyway, we 
don't want Fedora users to pull in two Python versions unless they need 
them for development purposes.


## How to run things locally?

You can use mock. Make sure to:

  1. Clear all caches first: $ mock -r fedora-rawhide-x86_64--scrub=all
  2. Use the Koji repo: $ mock -r fedora-rawhide-x86_64 
--enablerepo=local ...


## Where to get help

Reply to this thread or find us (thrnciar, mhroncok) on #fedora-python 
IRC channel (libera.chat).


---

Let usknow if you have other questions.

Maintainers by package:
5minute  pmoravco
APLpy    sergiopr 

Re: Packages that failed to build with Python 3.10 (and what to do)

[Ankur Sinha]

On Tue, Jun 08, 2021 15:58:04 +0200, Tomas Hrnciar wrote:
> ankursinha MUSIC python-SALib python-brian2 python-dipy python-duecredit
> python-fastavro python-fsleyes-props python-fslpy python-hdfs python-klusta
> python-matrix-nio python-nilearn python-nitime python-nixio python-pingouin
> python-pybids python-pymatreader python-pypet python-pyphi python-pyriemann
> python-pyscaffold python-sklearn-nature-inspired-algorithms python-trimesh

Woah! :D

I'll start looking into these now. Hopefully they're all simple fixes.

Thanks again for all your work.

-- 
Thanks,
Regards,
Ankur Sinha "FranciscoD" (He / Him / His) | 
https://fedoraproject.org/wiki/User:Ankursinha
Time zone: Europe/London


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

Re: Packages that failed to build with Python 3.10 (and what to do)

[Miro Hrončok]

On 08. 06. 21 19:19, Antonio T. sagitter wrote:

I need help for PETSC, please.

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


I took a look and reported https://bugs.python.org/issue44351

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

Re: Packages that failed to build with Python 3.10 (and what to do)

[Miro Hrončok]

On 08. 06. 21 19:19, Antonio T. sagitter wrote:

I need help for PETSC, please.

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


I took a look and reported https://bugs.python.org/issue44351

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

Re: Packages that failed to build with Python 3.10 (and what to do)

[Antonio T. sagitter]

On 6/8/21 3:58 PM, Tomas Hrnciar wrote:

Hello.

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


https://fedoraproject.org/wiki/Changes/Python3.10 



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.


Most of the packages only fail to build because their dependencies were 
not yet rebuilt. Chances are, you already got an automated 
F35FailsToInstall bugzilla from Miro, 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 dependingon the 
bugzilla for the missing dep. Weslowly progress to do that as well, but 
your help is crucial here.


If your package fails because there isanon-dependency problem, you might 
have already received a bugzilla from us in the past. If the build 
failure is related to changes in Python 3.10, it should contain some 
hints about the problem.


# What to do?

General advice: If you are aware of the problem and working towards 
fixing it, set your bugzilla to ASSIGNED to avoid further automated 
reminders.


If blocked by dependencies, do not close the bugzillas as NOTABUG or 
DUPLICATE just because it is "not a problem in your package". The 
automation will file new ones anyway.


## My package fails to build because it has test failures in %check

Please, try to resolve the failures. If you are confident that the 
package works fine, but the tests are wrong, skip some failing tests, 
ideally with a link to an upstream issue. Do not disable (e.g. comment 
out) all tests just to unblock the rebuild of your package, it usually 
only hides the problem.


## My package fails to build because it has broken build dependencies

Please try to track the missing build dependencies in Bugzilla. If 
possible, help the maintainers of your dependencies to get them rebuilt. 
When in need of escalation, ask us for provenpackager help (ideally with 
pull requests to be merged). Once possible, rebuild your package (no 
need to bump the release, we already did that). When you do, the 
bugzilla will eventually get automatically closed, but you can do that 
manually as well.


## My package was rebuilt with Python 3.10 but it has broken runtime 
dependencies


Please try to track the missing runtime dependencies in Bugzilla. If 
possible, help the maintainers of your dependencies to get them rebuilt. 
When in need of escalation, ask us for provenpackager help (ideally with 
pull requests to be merged). When the dependencies are rebuilt, your 
package will install successfully once again and the bugzilla will 
eventually get automatically closed, but you can do that manually as well.


## My package failed to build but installs just fine

Some packages that only require libpython3.9.so.1.0 will successfully 
pull in the python3.9 package as a dependency and hence they don't have 
installation issues. They need to be rebuilt with Python 3.10 anyway, we 
don't want Fedora users to pull in two Python versions unless they need 
them for development purposes.


## How to run things locally?

You can use mock. Make sure to:

  1. Clear all caches first: $ mock -r fedora-rawhide-x86_64--scrub=all
  2. Use the Koji repo: $ mock -r fedora-rawhide-x86_64 
--enablerepo=local ...


## Where to get help

Reply to this thread or find us (thrnciar, mhroncok) on #fedora-python 
IRC channel (libera.chat).


---

Let usknow if you have other questions.


> ...

petsc sagitter


I need help for PETSC, please.

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

--
---
Antonio Trande
Fedora Project
mailto: sagit...@fedoraproject.org
GPG key: 0x29FBC85D7A51CC2F
GPG key server: https://keys.gnupg.net/


OpenPGP_0x29FBC85D7A51CC2F.asc
Description: OpenPGP public key


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

Re: Packages that failed to build with Python 3.10 (and what to do)

[Antonio T. sagitter]

On 6/8/21 3:58 PM, Tomas Hrnciar wrote:

Hello.

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


https://fedoraproject.org/wiki/Changes/Python3.10 



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.


Most of the packages only fail to build because their dependencies were 
not yet rebuilt. Chances are, you already got an automated 
F35FailsToInstall bugzilla from Miro, 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 dependingon the 
bugzilla for the missing dep. Weslowly progress to do that as well, but 
your help is crucial here.


If your package fails because there isanon-dependency problem, you might 
have already received a bugzilla from us in the past. If the build 
failure is related to changes in Python 3.10, it should contain some 
hints about the problem.


# What to do?

General advice: If you are aware of the problem and working towards 
fixing it, set your bugzilla to ASSIGNED to avoid further automated 
reminders.


If blocked by dependencies, do not close the bugzillas as NOTABUG or 
DUPLICATE just because it is "not a problem in your package". The 
automation will file new ones anyway.


## My package fails to build because it has test failures in %check

Please, try to resolve the failures. If you are confident that the 
package works fine, but the tests are wrong, skip some failing tests, 
ideally with a link to an upstream issue. Do not disable (e.g. comment 
out) all tests just to unblock the rebuild of your package, it usually 
only hides the problem.


## My package fails to build because it has broken build dependencies

Please try to track the missing build dependencies in Bugzilla. If 
possible, help the maintainers of your dependencies to get them rebuilt. 
When in need of escalation, ask us for provenpackager help (ideally with 
pull requests to be merged). Once possible, rebuild your package (no 
need to bump the release, we already did that). When you do, the 
bugzilla will eventually get automatically closed, but you can do that 
manually as well.


## My package was rebuilt with Python 3.10 but it has broken runtime 
dependencies


Please try to track the missing runtime dependencies in Bugzilla. If 
possible, help the maintainers of your dependencies to get them rebuilt. 
When in need of escalation, ask us for provenpackager help (ideally with 
pull requests to be merged). When the dependencies are rebuilt, your 
package will install successfully once again and the bugzilla will 
eventually get automatically closed, but you can do that manually as well.


## My package failed to build but installs just fine

Some packages that only require libpython3.9.so.1.0 will successfully 
pull in the python3.9 package as a dependency and hence they don't have 
installation issues. They need to be rebuilt with Python 3.10 anyway, we 
don't want Fedora users to pull in two Python versions unless they need 
them for development purposes.


## How to run things locally?

You can use mock. Make sure to:

  1. Clear all caches first: $ mock -r fedora-rawhide-x86_64--scrub=all
  2. Use the Koji repo: $ mock -r fedora-rawhide-x86_64 
--enablerepo=local ...


## Where to get help

Reply to this thread or find us (thrnciar, mhroncok) on #fedora-python 
IRC channel (libera.chat).


---

Let usknow if you have other questions.


> ...

petsc sagitter


I need help for PETSC, please.

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

--
---
Antonio Trande
Fedora Project
mailto: sagit...@fedoraproject.org
GPG key: 0x29FBC85D7A51CC2F
GPG key server: https://keys.gnupg.net/


OpenPGP_0x29FBC85D7A51CC2F.asc
Description: OpenPGP public key


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

Re: Packages that failed to build with Python 3.10 (and what to do)

[Michel Alexandre Salim via devel]

On Tue, Jun 08, 2021 at 03:58:04PM +0200, Tomas Hrnciar wrote:
> Hello.
> 
> As you might already know, we have recently merged in the Python 3.10 side
> tag to Rawhide, despite several builds not succeeding. We always aim for
> some compromise between having the side tag open for too long and having
> too many failures.
> 
> https://fedoraproject.org/wiki/Changes/Python3.10
> 
...
> fbthrift dcavalca filbranden salimma
> follydcavalca filbranden salimma
> watchman dcavalca filbranden salimma
> 
These are all related; I'll try to get them fixed. There's a known issue with 
fbthrift's use of Cython that has been affecting rebuilds for the past few 
weeks, so now is as good a time as any.

Best regards,

-- 
Michel Alexandre Salim
profile: https://keyoxide.org/mic...@michel-slm.name


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

Re: Packages in need of a new maintainer

[Johannes Lips]

> On Sun, May 2, 2021 at 8:28 AM Johannes Lips  wrote:
> 
> maintainer.
> My fas is imcinerney.
Thanks, just added you.
> 
> -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
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: Packages in need of a new maintainer

[Ian McInerney]

On Sun, May 2, 2021 at 8:28 AM Johannes Lips 
wrote:

> Dear all,
>
> after quite some years, I would like to hand over the following packages
> to new maintainers. I will not orphan them if no one picks them up, but it
> would be great if someone with an interest in these packages could take
> them over.
>
> backintime - backintime backup tool
> elementary-icon-theme - Icons from the Elementary Project
> elementary-xfce-icon-theme - Icons for Xfce based on the elementary
> Project Icon Theme
> texstudio - A feature-rich editor for LaTeX documents
>
> I am an active user of texstudio, so I would be willing to take over as
maintainer. My fas is imcinerney.

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

Re: Packages in need of a new maintainer

[Johannes Lips]

> On Sun, May 2, 2021 at 9:28 AM Johannes Lips  wrote:
> 
> Hello Johannes,
> 
> Feel free to assign elementary-icon-theme to me. I'm already the
> maintainer of all other elementary / Pantheon packages in Fedora.
> Thank you for your work with maintaining those packages!
Done, thanks. You should be admin of both icon themes now, if necessary you can 
also become the main admin.
> 
> Fabio
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: Packages in need of a new maintainer

[Fabio Valentini]

On Sun, May 2, 2021 at 9:28 AM Johannes Lips  wrote:
>
> Dear all,
>
> after quite some years, I would like to hand over the following packages to 
> new maintainers. I will not orphan them if no one picks them up, but it would 
> be great if someone with an interest in these packages could take them over.
>
> backintime - backintime backup tool
> elementary-icon-theme - Icons from the Elementary Project
> elementary-xfce-icon-theme - Icons for Xfce based on the elementary Project 
> Icon Theme
> texstudio - A feature-rich editor for LaTeX documents

Hello Johannes,

Feel free to assign elementary-icon-theme to me. I'm already the
maintainer of all other elementary / Pantheon packages in Fedora.
Thank you for your work with maintaining those packages!

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

Re: Packages in need of a new maintainer

[Johannes Lips]

> I could help with the elementary stuff, but I don't think I can take over
> fully.
> 
> If anyone can help me maintain that'd be great.
I could probably help you out, if you give me your fas account name, I'll grant 
you the co-maintainer privileges.
Johannes
> 
> On Sun, 2 May, 2021, 12:59 pm Johannes Lips,  wrote:
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: Packages in need of a new maintainer

[Abhiram Kuchibhotla]

I could help with the elementary stuff, but I don't think I can take over
fully.

If anyone can help me maintain that'd be great.

On Sun, 2 May, 2021, 12:59 pm Johannes Lips, 
wrote:

> Dear all,
>
> after quite some years, I would like to hand over the following packages
> to new maintainers. I will not orphan them if no one picks them up, but it
> would be great if someone with an interest in these packages could take
> them over.
>
> backintime - backintime backup tool
> elementary-icon-theme - Icons from the Elementary Project
> elementary-xfce-icon-theme - Icons for Xfce based on the elementary
> Project Icon Theme
> texstudio - A feature-rich editor for LaTeX documents
>
> I am still using these, but the burden of doing package maintenance
> besides my day job and personal stuff is too high.
>
> Thanks in advance for any volunteers
>
> johannes
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
> Do not reply to spam on the list, report it:
> https://pagure.io/fedora-infrastructure
>
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure