Re: %patchN deprecated?

2023-04-02 Thread Panu Matilainen 

On 3/31/23 18:49, Ron Olson wrote:
One thing to note is that the new format doesn’t work with EPEL 
releases; I had to revert to the %patchN style for them.




The following bit from 
https://rpm-software-management.github.io/rpm/manual/spec.html was 
already quoted in this thread, but:


%patch is used to apply patches on top of the just unpacked
pristine sources. Historically it supported multiple strange
syntaxes and buggy behaviors, which are no longer
maintained. To apply patch number 1, the following are
recognized:

%patch 1 (since rpm >= 4.18)
%patch -P1 (all rpm versions)
%patch1 (deprecated, do not use)

For new packages, the positional argument form 1) is
preferred. For maximal compatibility use 2). Both forms can
be used to apply several patches at once, in the order they
appear on the line. The third form where the number is a
part of the directive is deprecated and should not be used
anymore.

In other words, if you need to care about compatibility, use -PN.

- Panu -
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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: F39 proposal: RPM 4.19 (System-Wide Change proposal)

2023-04-02 Thread Mattia Verga via devel 
Il 02/04/23 18:42, Fabio Valentini ha scritto:
> On Sun, Apr 2, 2023 at 5:37 PM Mattia Verga via devel
>  wrote:
>> Il 31/03/23 17:27, Florian Festi ha scritto:
>>> On 3/31/23 15:40, Stephen Gallagher wrote:
 On Thu, Mar 30, 2023 at 3:42 PM Ben Cotton  wrote:
> https://fedoraproject.org/wiki/Changes/RPM-4.19
> == Detailed Description ==
> RPM 4.19 contains various improvements over previous versions. Many of
> them are internal in nature such as moving from automake to cmake,
> improvements to the test suite, stripping copies of system functions,
> splitting translations into a separate project and more. There are
> still several user facing changes:
>
> * New rpmsort(8) utility for sorting RPM versions
 Handy!

> * x86-64 architecture levels (v2-v4) as architectures
 Could you explain more what this means, exactly?
>>> No! But here is the commit:
>>>
>>>
>>> https://github.com/rpm-software-management/rpm/commit/cd46c1704ccd8eeb9b600729a0a1c8738b66b847
>>>
>>> It looks like it adds x86_64_v2, x86_64_v3 and x86_64_v4. Something
>>> about some x86_64 processors having additional capabilities.
>>>
>> Is there anyone who could provide some benchmarks to see if there are
>> significant performance improvements about using v2/v3/v3 versus plain
>> x86_64? If so, do you think we could drop building i686 by default (to
>> save some resources) and provide v2 (or v3, or v4) alongside x86_64?
> I don't think we can drop i686 as long as we need to support at least
> a subset of i686 for wine / steam / $your favourite 32-bit only
> third-party application.

Sure, I meant to change the current default of opting out i686 build
(ExcludeArch) to explicitly opting in only for required packages. I
think we're currently wasting resources by making needlessy builds on i686.

Those resources can possibly be spent on building v2/v3/v4 to enable
glibc-hwcaps as Dan pointed out OpenSuse is doing, but this is a
following step.

Mattia

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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: F39 proposal: RPM 4.19 (System-Wide Change proposal)

2023-04-02 Thread Florian Weimer 
* Florian Festi:

> On 3/31/23 15:40, Stephen Gallagher wrote:
>> On Thu, Mar 30, 2023 at 3:42 PM Ben Cotton  wrote:
>>>
>>> https://fedoraproject.org/wiki/Changes/RPM-4.19
>> 
>>> == Detailed Description ==
>>> RPM 4.19 contains various improvements over previous versions. Many of
>>> them are internal in nature such as moving from automake to cmake,
>>> improvements to the test suite, stripping copies of system functions,
>>> splitting translations into a separate project and more. There are
>>> still several user facing changes:
>>>
>>> * New rpmsort(8) utility for sorting RPM versions
>> Handy!
>> 
>>> * x86-64 architecture levels (v2-v4) as architectures
>> Could you explain more what this means, exactly?
>
> No! But here is the commit:
>
>  
> https://github.com/rpm-software-management/rpm/commit/cd46c1704ccd8eeb9b600729a0a1c8738b66b847
>
> It looks like it adds x86_64_v2, x86_64_v3 and x86_64_v4. Something
> about some x86_64 processors having additional capabilities.

Are these fully separate architectures, or can x86_64_v3 packages
fulfill dependencies on x86_64 packages?

It's not clear to me yet how this new feature is supposed to be used.

(Detection for x86-64-v3 and x86-64-v4 is not correct because it does
not examine XCR0.  I'm going to file an upstream bug for that.)

Thanks,
Florian
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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: Need help to build Blender 3.5.0

2023-04-02 Thread Luya Tshimbalanga 


On 2023-03-31 23:30, Mamoru TASAKA wrote:

Luya Tshimbalanga wrote on 2023/03/30 13:04:

Hello team,
Blender 3.5.0 got released today at this time of writing. 
Unfortunately, failure occurred with the following link possibly 
related to cycles:


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

Can someone investigate the problem?

Thanks


gcc is ICEing. Reported against gcc for now:
https://bugzilla.redhat.com/show_bug.cgi?id=2183692

Regards,
Mamoru


Thank you for filing the report.

--
Luya Tshimbalanga
Fedora Design Team
Fedora Design Suite maintainer
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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

[Review request] gnome-shell-extension-screen-autorotate

2023-04-02 Thread Luya Tshimbalanga 

Hello team,

I packaged gnome-shell-extension-screen-autorotate needed for 2-in-1 
device running on GNOME Shell.
The spec file should adhere to the new guideline recommending the use of 
%autorelease and %autochangelog.


Without delay, here is the link for 
reviewhttps://bugzilla.redhat.com/show_bug.cgi?id=2183901


Thanks in advance

--
Luya Tshimbalanga
Fedora Design Team
Fedora Design Suite maintainer
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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

Fedora 38 compose report: 20230402.n.0 changes

2023-04-02 Thread Fedora Rawhide Report 
OLD: Fedora-38-20230401.n.1
NEW: Fedora-38-20230402.n.0

= SUMMARY =
Added images:0
Dropped images:  3
Added packages:  3
Dropped packages:0
Upgraded packages:   59
Downgraded packages: 0

Size of added packages:  370.54 KiB
Size of dropped packages:0 B
Size of upgraded packages:   9.10 GiB
Size of downgraded packages: 0 B

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

= ADDED IMAGES =

= DROPPED IMAGES =
Image: Python_Classroom vagrant-libvirt x86_64
Path: 
Labs/x86_64/images/Fedora-Python-Classroom-Vagrant-38-20230401.n.1.x86_64.vagrant-libvirt.box
Image: Kinoite dvd-ostree ppc64le
Path: Kinoite/ppc64le/iso/Fedora-Kinoite-ostree-ppc64le-38-20230401.n.1.iso
Image: Python_Classroom vagrant-virtualbox x86_64
Path: 
Labs/x86_64/images/Fedora-Python-Classroom-Vagrant-38-20230401.n.1.x86_64.vagrant-virtualbox.box

= ADDED PACKAGES =
Package: python-papermill-2.4.0-4.fc38
Summary: Parameterize and run Jupyter and nteract Notebooks
RPMs:python3-papermill python3-papermill+all python3-papermill+azure 
python3-papermill+black python3-papermill+gcs python3-papermill+github 
python3-papermill+hdfs python3-papermill+s3
Size:162.74 KiB

Package: python-scikit-build-core-0.2.2-2.fc38
Summary: Build backend for CMake based projects
RPMs:python3-scikit-build-core
Size:189.87 KiB

Package: rust-phf_codegen0.8-0.8.0-1.fc38
Summary: Codegen library for PHF types
RPMs:rust-phf_codegen0.8+default-devel rust-phf_codegen0.8-devel
Size:17.93 KiB


= DROPPED PACKAGES =

= UPGRADED PACKAGES =
Package:  ImageMagick-1:7.1.1.4-3.fc38
Old package:  ImageMagick-1:7.1.1.4-2.fc38
Summary:  An X application for displaying and manipulating images
RPMs: ImageMagick ImageMagick-c++ ImageMagick-c++-devel 
ImageMagick-devel ImageMagick-djvu ImageMagick-doc ImageMagick-heic 
ImageMagick-libs ImageMagick-perl
Size: 38.56 MiB
Size change:  3.33 KiB
Changelog:
  * Mon Mar 27 2023 Luya Tshimbalanga  - 1:7.1.1.4-3
  - Stop requiring ghostcripts-x11 upon request for security issue


Package:  alt-ergo-2.3.3-6.fc38
Old package:  alt-ergo-2.3.3-5.fc38
Summary:  Automated theorem prover including linear arithmetic
RPMs: alt-ergo alt-ergo-gui ocaml-alt-ergo-lib ocaml-alt-ergo-lib-devel 
ocaml-alt-ergo-parsers ocaml-alt-ergo-parsers-devel
Size: 93.53 MiB
Size change:  -61.36 KiB
Changelog:
  * Fri Mar 24 2023 Jerry James  - 2.3.3-6
  - Dune 3.7.0 changed the install location of mli files


Package:  amanda-3.5.3-1.fc38
Old package:  amanda-3.5.2-2.fc38
Summary:  A network-capable tape backup solution
RPMs: amanda amanda-client amanda-libs amanda-server
Size: 8.43 MiB
Size change:  610.29 KiB
Changelog:
  * Thu Mar 16 2023 Orion Poplawski  - 3.5.3-1
  - Update to 3.5.3
  - Fixes CVE-2022-37703 (bz#2126849) CVE-2022-37704 (bz#2168789) 
CVE-2022-37705 (bz#2168797)


Package:  archlinux-keyring-20230320-1.fc38
Old package:  archlinux-keyring-20230225-1.fc38
Summary:  GPG keys used by Arch distribution to sign packages
RPMs: archlinux-keyring
Size: 1.14 MiB
Size change:  604 B
Changelog:
  * Fri Mar 24 2023 Frantisek Sumsal  - 20230320-1
  - Version 20230320 (#2180086)


Package:  aspell-sk-2.4.7-1.fc38
Old package:  aspell-sk-2.02-10.fc38
Summary:  Slovak dictionaries for Aspell
RPMs: aspell-sk
Size: 4.93 MiB
Size change:  -2.26 MiB
Changelog:
  * Thu Mar 16 2023 J??n ONDREJ (SAL)  - 2.4.7-1
  - Update to upstream.


Package:  borgbackup-1.2.4-1.fc38
Old package:  borgbackup-1.2.3-2.fc38
Summary:  A deduplicating backup program with compression and authenticated 
encryption
RPMs: borgbackup
Size: 6.19 MiB
Size change:  59.53 KiB
Changelog:
  * Fri Mar 24 2023 Felix Schwarz  - 1.2.4-1
  - update to 1.2.4


Package:  chromium-111.0.5563.146-1.fc38
Old package:  chromium-111.0.5563.64-2.fc38
Summary:  A WebKit (Blink) powered web browser that Google doesn't want you 
to use
RPMs: chromedriver chromium chromium-common chromium-headless
Size: 252.35 MiB
Size change:  26.60 KiB
Changelog:
  * Wed Mar 22 2023 Than Ngo  - 111.0.5563.110-1
  - update to 111.0.5563.110

  * Sat Mar 25 2023 Neal Gompa  - 111.0.5563.110-2
  - Fix ffmpeg note in README.fedora

  * Tue Mar 28 2023 Than Ngo  - 111.0.5563.146-1
  - update to 111.0.5563.146


Package:  deja-dup-44.1-1.fc38
Old package:  deja-dup-44.0-2.fc38
Summary:  Simple backup tool and frontend for duplicity
RPMs: deja-dup
Size: 3.65 MiB
Size change:  96.84 KiB
Changelog:
  * Wed Mar 01 2023 Gwyn Ciesla  - 44.0-3
  - migrated to SPDX license

  * Fri Mar 24 2023 Gwyn Ciesla  - 44.1-1
  - 44.1


Package:  dl-fedora-0.9.4-1.fc38
Old package:  dl-fedora-0.9.3-4.fc38
Summary:  Fedora image download tool
RPMs: dl-fedora
Size: 26.54 MiB
Size change:  -2.83 KiB
Chan

Re: F39 proposal: RPM 4.19 (System-Wide Change proposal)

2023-04-02 Thread Dan Čermák 
Hi,

Mattia Verga via devel  writes:

> Il 31/03/23 17:27, Florian Festi ha scritto:
>> On 3/31/23 15:40, Stephen Gallagher wrote:
>>> On Thu, Mar 30, 2023 at 3:42 PM Ben Cotton  wrote:
 https://fedoraproject.org/wiki/Changes/RPM-4.19
 == Detailed Description ==
 RPM 4.19 contains various improvements over previous versions. Many of
 them are internal in nature such as moving from automake to cmake,
 improvements to the test suite, stripping copies of system functions,
 splitting translations into a separate project and more. There are
 still several user facing changes:

 * New rpmsort(8) utility for sorting RPM versions
>>> Handy!
>>>
 * x86-64 architecture levels (v2-v4) as architectures
>>> Could you explain more what this means, exactly?
>> No! But here is the commit:
>>
>>   
>> https://github.com/rpm-software-management/rpm/commit/cd46c1704ccd8eeb9b600729a0a1c8738b66b847
>>
>> It looks like it adds x86_64_v2, x86_64_v3 and x86_64_v4. Something
>> about some x86_64 processors having additional capabilities.
>>
> Is there anyone who could provide some benchmarks to see if there are
> significant performance improvements about using v2/v3/v3 versus plain
> x86_64? If so, do you think we could drop building i686 by default (to
> save some resources) and provide v2 (or v3, or v4) alongside x86_64?

The only benchmark that *I* am aware of is this one done by Martin
Jambor: https://jamborm.github.io/spec-2022-07-29-levels/

tl;dr; v2 does not really bring notable improvements, only v3 but also
only in some selected synthetic benchmarks.


openSUSE Tumbleweed went a different route and chose to utilize
glibc-hwcaps instead:
https://en.opensuse.org/openSUSE:X86-64-Architecture-Levels
https://lists.opensuse.org/archives/list/fact...@lists.opensuse.org/thread/ZOHLT4CQ7TDOJJ2VV7HKMN5G2MR2CTMD/


Cheers,

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

Re: F39 proposal: RPM 4.19 (System-Wide Change proposal)

2023-04-02 Thread Vitaly Zaitsev via devel 

On 02/04/2023 17:36, Mattia Verga via devel wrote:

Is there anyone who could provide some benchmarks to see if there are
significant performance improvements about using v2/v3/v3 versus plain
x86_64?


AVX2 can bring a huge performance boost.

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

Re: F39 proposal: RPM 4.19 (System-Wide Change proposal)

2023-04-02 Thread Fabio Valentini 
On Sun, Apr 2, 2023 at 5:37 PM Mattia Verga via devel
 wrote:
>
> Il 31/03/23 17:27, Florian Festi ha scritto:
> > On 3/31/23 15:40, Stephen Gallagher wrote:
> >> On Thu, Mar 30, 2023 at 3:42 PM Ben Cotton  wrote:
> >>> https://fedoraproject.org/wiki/Changes/RPM-4.19
> >>> == Detailed Description ==
> >>> RPM 4.19 contains various improvements over previous versions. Many of
> >>> them are internal in nature such as moving from automake to cmake,
> >>> improvements to the test suite, stripping copies of system functions,
> >>> splitting translations into a separate project and more. There are
> >>> still several user facing changes:
> >>>
> >>> * New rpmsort(8) utility for sorting RPM versions
> >> Handy!
> >>
> >>> * x86-64 architecture levels (v2-v4) as architectures
> >> Could you explain more what this means, exactly?
> > No! But here is the commit:
> >
> >   
> > https://github.com/rpm-software-management/rpm/commit/cd46c1704ccd8eeb9b600729a0a1c8738b66b847
> >
> > It looks like it adds x86_64_v2, x86_64_v3 and x86_64_v4. Something
> > about some x86_64 processors having additional capabilities.
> >
> Is there anyone who could provide some benchmarks to see if there are
> significant performance improvements about using v2/v3/v3 versus plain
> x86_64? If so, do you think we could drop building i686 by default (to
> save some resources) and provide v2 (or v3, or v4) alongside x86_64?

I don't think we can drop i686 as long as we need to support at least
a subset of i686 for wine / steam / $your favourite 32-bit only
third-party application.
Additionally, I don't think building x86_64-v2 / x86_64-v3 / x86_64-v4
variants of *all* packages that are built on x86_64 makes sense.
Some packages already have runtime detection of available CPU features
and will choose the fastest path without having to be compiled for it
explicitly. Other libraries will not really benefit from newer x86_64
instructions.
But there are some libraries that *would* benefit quite a bit, and we
could look into whether it's possible to optionally build additional
versions of these select packages.
As far as I know, this is also the approach that OpenSUSE has chosen.

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

Re: F39 proposal: RPM 4.19 (System-Wide Change proposal)

2023-04-02 Thread Mattia Verga via devel 
Il 31/03/23 17:27, Florian Festi ha scritto:
> On 3/31/23 15:40, Stephen Gallagher wrote:
>> On Thu, Mar 30, 2023 at 3:42 PM Ben Cotton  wrote:
>>> https://fedoraproject.org/wiki/Changes/RPM-4.19
>>> == Detailed Description ==
>>> RPM 4.19 contains various improvements over previous versions. Many of
>>> them are internal in nature such as moving from automake to cmake,
>>> improvements to the test suite, stripping copies of system functions,
>>> splitting translations into a separate project and more. There are
>>> still several user facing changes:
>>>
>>> * New rpmsort(8) utility for sorting RPM versions
>> Handy!
>>
>>> * x86-64 architecture levels (v2-v4) as architectures
>> Could you explain more what this means, exactly?
> No! But here is the commit:
>
>   
> https://github.com/rpm-software-management/rpm/commit/cd46c1704ccd8eeb9b600729a0a1c8738b66b847
>
> It looks like it adds x86_64_v2, x86_64_v3 and x86_64_v4. Something
> about some x86_64 processors having additional capabilities.
>
Is there anyone who could provide some benchmarks to see if there are
significant performance improvements about using v2/v3/v3 versus plain
x86_64? If so, do you think we could drop building i686 by default (to
save some resources) and provide v2 (or v3, or v4) alongside x86_64?

Mattia

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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: Auto-assign packager sponsors to tickets?

2023-04-02 Thread Jakub Kadlcik 
I tried to get some numbers to see how many packagers we sponsor each
year but FAS tells me only group members but not when they joined the
group. Do any of you at least have a rough estimate of what number are
we talking about? I wouldn't propose any auto-assign system for
package reviews because there is thousand of them each year. That
would be insane. But how many new contributors that need to be
sponsored do we have each year? My guess is that not even every
sponsor would get a ticket within the year.

Jakub

On Sun, Apr 2, 2023 at 5:07 PM Jakub Kadlcik  wrote:
>
> > If they wait for months, I think they don't want to be sponsored.
>
> I respectfully disagree here, IMHO we communicate a message that a
> sponsor will find the contributor, not the other way around. Just so I
> don't repeat the same message in my own words, everything that
> Miroslav said, sounds true to me.
>
> > Please exclude me from such spam.
>
> Sure, no problem with me. As I said in my initial proposal, I'd
> provide an easy way to opt out (probably multiple ways, so it is
> convenient for everybody).
>
> > I don't think it's fair to expect that all sponsors are available to do 
> > this at any time.
>
> Well sure, I agree. Mentoring somebody is a time commitment and nobody
> has sponsoring people as the #1 priority. But as I said in the
> proposal "If a sponsor is not able or willing to work on a ticket,
> they could either set NEEDINFO on another sponsor or just drop
> themselves. The ticket would then get a new sponsor next week" - to me
> this sounds very reasonable.
>
> Jakub
>
> On Sun, Apr 2, 2023 at 4:12 PM Miroslav Suchý  wrote:
> >
> > Dne 02. 04. 23 v 11:54 Vitaly Zaitsev via devel napsal(a):
> >
> > I'm always willing to review and sponsor new maintainers, but they need to 
> > show explicit consent by posting on IRC/Matrix/ML or direct email.
> >
> > Let me check the history of
> >
> >   
> > https://docs.fedoraproject.org/en-US/package-maintainers/How_to_Get_Sponsored_into_the_Packager_Group/#how_to_find_a_sponsor
> >
> > Right now we tell users to:
> >
> > Usually, a sponsor finds you through your sponsorship request in Bugzilla 
> > or the packager sponsors pagure instance. In case you are waiting to be 
> > sponsored for longer than desirable, take a look at Sponsors page. It will 
> > help you find the right sponsor for you based on programming language 
> > preference, domains of interest, native language, and other criteria.
> >
> > This is not there for long time. Actually since 2021 when Jakub wrote that 
> > "Sponsor page". Previously there was:
> >
> > If you are submitting a new package for review in Bugzilla,
> > you can make the review request block the
> > https://bugzilla.redhat.com/show_bug.cgi?id=FE-NEEDSPONSOR[FE-NEEDSPONSOR] 
> > tracking bug.
> >
> > Otherwise, you can file a ticket in the
> > https://pagure.io/packager-sponsors/[sponsors ticketing system].
> >
> > So previously - and even now - we tell newcomers to to block FE-NEEDSPONSOR 
> > and wait. And only if they wait too long (whatever it means) to start 
> > looking for sponsors directly.
> >
> > I personally think that Jakub's proposal is great and I welcome it. Not 
> > everyone is brave to initiate a conversation and asks for being sponsored. 
> > We have to realize it often means that junior developer has to reach senior 
> > developer and juniors often hesitate to do this step. This proposal remove 
> > one road blocks for juniors.
> >
> > If other people does not find it useful, then I propose to at least alter 
> > our documentation and tell users to start looking for sponsor immediately 
> > after blocking FE-NEEDSPONSOR.
> >
> > Miroslav
> >
> >
> > ___
> > devel mailing list -- devel@lists.fedoraproject.org
> > To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> > Fedora Code of Conduct: 
> > https://docs.fedoraproject.org/en-US/project/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: Auto-assign packager sponsors to tickets?

2023-04-02 Thread Jakub Kadlcik 
> If they wait for months, I think they don't want to be sponsored.

I respectfully disagree here, IMHO we communicate a message that a
sponsor will find the contributor, not the other way around. Just so I
don't repeat the same message in my own words, everything that
Miroslav said, sounds true to me.

> Please exclude me from such spam.

Sure, no problem with me. As I said in my initial proposal, I'd
provide an easy way to opt out (probably multiple ways, so it is
convenient for everybody).

> I don't think it's fair to expect that all sponsors are available to do this 
> at any time.

Well sure, I agree. Mentoring somebody is a time commitment and nobody
has sponsoring people as the #1 priority. But as I said in the
proposal "If a sponsor is not able or willing to work on a ticket,
they could either set NEEDINFO on another sponsor or just drop
themselves. The ticket would then get a new sponsor next week" - to me
this sounds very reasonable.

Jakub

On Sun, Apr 2, 2023 at 4:12 PM Miroslav Suchý  wrote:
>
> Dne 02. 04. 23 v 11:54 Vitaly Zaitsev via devel napsal(a):
>
> I'm always willing to review and sponsor new maintainers, but they need to 
> show explicit consent by posting on IRC/Matrix/ML or direct email.
>
> Let me check the history of
>
>   
> https://docs.fedoraproject.org/en-US/package-maintainers/How_to_Get_Sponsored_into_the_Packager_Group/#how_to_find_a_sponsor
>
> Right now we tell users to:
>
> Usually, a sponsor finds you through your sponsorship request in Bugzilla or 
> the packager sponsors pagure instance. In case you are waiting to be 
> sponsored for longer than desirable, take a look at Sponsors page. It will 
> help you find the right sponsor for you based on programming language 
> preference, domains of interest, native language, and other criteria.
>
> This is not there for long time. Actually since 2021 when Jakub wrote that 
> "Sponsor page". Previously there was:
>
> If you are submitting a new package for review in Bugzilla,
> you can make the review request block the
> https://bugzilla.redhat.com/show_bug.cgi?id=FE-NEEDSPONSOR[FE-NEEDSPONSOR] 
> tracking bug.
>
> Otherwise, you can file a ticket in the
> https://pagure.io/packager-sponsors/[sponsors ticketing system].
>
> So previously - and even now - we tell newcomers to to block FE-NEEDSPONSOR 
> and wait. And only if they wait too long (whatever it means) to start looking 
> for sponsors directly.
>
> I personally think that Jakub's proposal is great and I welcome it. Not 
> everyone is brave to initiate a conversation and asks for being sponsored. We 
> have to realize it often means that junior developer has to reach senior 
> developer and juniors often hesitate to do this step. This proposal remove 
> one road blocks for juniors.
>
> If other people does not find it useful, then I propose to at least alter our 
> documentation and tell users to start looking for sponsor immediately after 
> blocking FE-NEEDSPONSOR.
>
> Miroslav
>
>
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct: 
> https://docs.fedoraproject.org/en-US/project/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

Any interest in maintaining spyder (python IDE)?

2023-04-02 Thread Mukundan Ragavan 


I have been maintaining spyder in Fedora for sometime now. Since the 
time I took up maintaining spyder, the dependencies have expanded 
considerably (I have packaged several of these dependencies in the 
past). Unfortunately, I am not able to devote as much as time as needed 
to maintain this package (at least in working condition) anymore.


I should point out that there are specific version dependencies  for 
certain packages (e.g. ipython) that are not in sync with Fedora. I have 
relaxed the dependencies in the Fedora package (so that spyder continues 
to work, albeit with some issues). I did start updating spyder to 5.4.x 
series. Two more packages need to be packaged. See COPR -


https://copr.fedorainfracloud.org/coprs/nonamedotc/spyder/builds/


Is anyone interested in maintaining spyder and potentially its 
dependencies? Some of these dependencies are being maintained by 
python-sig already. I will be happy to continue on as co-maintainer and 
try to help out when I can.


Thanks.

Mukundan.

--
GPG Key: E5C8BC67


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

Re: Auto-assign packager sponsors to tickets?

2023-04-02 Thread Miroslav Suchý 

Dne 02. 04. 23 v 11:54 Vitaly Zaitsev via devel napsal(a):
I'm always willing to review and sponsor new maintainers, but they need to show explicit consent by posting on 
IRC/Matrix/ML or direct email. 


Let me check the history of

https://docs.fedoraproject.org/en-US/package-maintainers/How_to_Get_Sponsored_into_the_Packager_Group/#how_to_find_a_sponsor

Right now we tell users to:

Usually, a sponsor finds you through your sponsorship request in Bugzilla or the packager sponsors pagure instance. In 
case you are waiting to be sponsored for longer than desirable, take a look at Sponsors page 
. It will help you find the right sponsor for you based on programming 
language preference, domains of interest, native language, and other criteria.

This is not there for long time. Actually since 2021 when Jakub wrote that "Sponsor 
page". Previously there was:


If you are submitting a new package for review in Bugzilla,
you can make the review request block the
https://bugzilla.redhat.com/show_bug.cgi?id=FE-NEEDSPONSOR[FE-NEEDSPONSOR] 
tracking bug.

Otherwise, you can file a ticket in the
https://pagure.io/packager-sponsors/[sponsors ticketing system].


So previously - and even now - we tell newcomers to to block FE-NEEDSPONSOR and wait. And only if they wait too long 
(whatever it means) to start looking for sponsors directly.


I personally think that Jakub's proposal is great and I welcome it. Not everyone is brave to initiate a conversation and 
asks for being sponsored. We have to realize it often means that junior developer has to reach senior developer and 
juniors often hesitate to do this step. This proposal remove one road blocks for juniors.


If other people does not find it useful, then I propose to at least alter our documentation and tell users to start 
looking for sponsor immediately after blocking FE-NEEDSPONSOR.


Miroslav

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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

Fedora rawhide compose report: 20230402.n.0 changes

2023-04-02 Thread Fedora Rawhide Report 
OLD: Fedora-Rawhide-20230401.n.0
NEW: Fedora-Rawhide-20230402.n.0

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

Size of added packages:  1.58 MiB
Size of dropped packages:1.53 MiB
Size of upgraded packages:   5.90 GiB
Size of downgraded packages: 0 B

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

= ADDED IMAGES =

= DROPPED IMAGES =
Image: Silverblue dvd-ostree ppc64le
Path: 
Silverblue/ppc64le/iso/Fedora-Silverblue-ostree-ppc64le-Rawhide-20230401.n.0.iso
Image: Container_Base docker s390x
Path: 
Container/s390x/images/Fedora-Container-Base-Rawhide-20230401.n.0.s390x.tar.xz
Image: Kinoite dvd-ostree ppc64le
Path: Kinoite/ppc64le/iso/Fedora-Kinoite-ostree-ppc64le-Rawhide-20230401.n.0.iso

= ADDED PACKAGES =
Package: R-gpx-1.1.0-1.fc39
Summary: Process GPX Files into R Data Structures
RPMs:R-gpx
Size:30.79 KiB

Package: libzim-8.1.1-1.fc39
Summary: Reference implementation of the ZIM specification
RPMs:libzim libzim-devel
Size:1.53 MiB

Package: rust-roff0.1-0.1.0-1.fc39
Summary: ROFF (man page format) generation library
RPMs:rust-roff0.1+default-devel rust-roff0.1-devel
Size:22.17 KiB


= DROPPED PACKAGES =
Package: zimlib-8.1.0-4.fc38
Summary: Reference implementation of the ZIM specification
RPMs:zimlib zimlib-devel
Size:1.53 MiB


= UPGRADED PACKAGES =
Package:  Lmod-8.7.23-1.fc39
Old package:  Lmod-8.7.22-1.fc39
Summary:  Environmental Modules System in Lua
RPMs: Lmod
Size: 1.02 MiB
Size change:  700 B
Changelog:
  * Fri Mar 31 2023 Orion Poplawski  - 8.7.23-1
  - Update to 8.7.23


Package:  astrometry-0.91-3.fc39
Old package:  astrometry-0.91-2.fc38
Summary:  Blind astrometric calibration of arbitrary astronomical images
RPMs: astrometry astrometry-data astrometry-data-4204 
astrometry-data-4205 astrometry-data-4206 astrometry-data-4207 astrometry-devel 
astrometry-libs python3-astrometry
Size: 1.77 GiB
Size change:  265.46 KiB
Changelog:
  * Wed Jan 18 2023 Fedora Release Engineering  - 
0.91-3
  - Rebuilt for https://fedoraproject.org/wiki/Fedora_38_Mass_Rebuild


Package:  coq-8.17.0-1.fc39
Old package:  coq-8.16.1-3.fc38
Summary:  Proof management system
RPMs: coq coq-coqide coq-coqide-server coq-core
Size: 791.76 MiB
Size change:  -83.93 MiB
Changelog:
  * Sat Apr 01 2023 Jerry James  - 8.17.0-1
  - Version 8.17.0
  - Drop upstreamed patch for Sphinx 5 support


Package:  ddnet-16.9-1.fc39
Old package:  ddnet-16.8-1.fc39
Summary:  DDraceNetwork, a cooperative racing mod of Teeworlds
RPMs: ddnet ddnet-data ddnet-server
Size: 35.89 MiB
Size change:  75.35 KiB
Changelog:
  * Sat Apr 01 2023 Fedora Release Monitoring 
 - 16.9-1
  - Update to 16.9 (#2181915)


Package:  espresso-4.2.0-8.fc39
Old package:  espresso-4.2.0-7.fc39
Summary:  Extensible Simulation Package for Research on Soft matter
RPMs: espresso-common python3-espresso-mpich python3-espresso-openmpi
Size: 14.84 MiB
Size change:  23.70 KiB
Changelog:
  * Sat Apr 01 2023 Jean-No??l Grad  - 4.2.0-8
  - Skip fragile ICC python interface test


Package:  f38-backgrounds-38.1.0-1.fc39
Old package:  f38-backgrounds-38.0.2-1.fc39
Summary:  Fedora 38 default desktop background
RPMs: f38-backgrounds f38-backgrounds-base f38-backgrounds-budgie 
f38-backgrounds-extras-base f38-backgrounds-extras-gnome 
f38-backgrounds-extras-kde f38-backgrounds-extras-mate 
f38-backgrounds-extras-xfce f38-backgrounds-gnome f38-backgrounds-kde 
f38-backgrounds-mate f38-backgrounds-xfce
Added RPMs:   f38-backgrounds-budgie
Size: 11.48 MiB
Size change:  -14.84 MiB
Changelog:
  * Sat Apr 01 2023 Luya Tshimbalanga  - 38.1.0-1
  - Update to 38.1.0


Package:  fail2ban-1.0.2-3.fc39
Old package:  fail2ban-1.0.2-2.fc38
Summary:  Daemon to ban hosts that cause multiple authentication errors
RPMs: fail2ban fail2ban-all fail2ban-firewalld fail2ban-hostsdeny 
fail2ban-mail fail2ban-selinux fail2ban-sendmail fail2ban-server 
fail2ban-shorewall fail2ban-shorewall-lite fail2ban-systemd fail2ban-tests
Size: 1.12 MiB
Size change:  -2.79 KiB
Changelog:
  * Thu Mar 30 2023 Orion Poplawski  - 1.0.2-3
  - Add upstream patch to remove warning about allowipv6 (bz#2160781)


Package:  flocq-4.1.1-1.fc39
Old package:  flocq-4.1.0-5.fc38
Summary:  Formalization of floating point numbers for Coq
RPMs: flocq flocq-source
Size: 19.77 MiB
Size change:  -20.07 KiB
Changelog:
  * Sat Apr 01 2023 Jerry James  - 4.1.1-1
  - Version 4.1.1


Package:  gappalib-coq-1.5.3-1.fc39
Old package:  gappalib-coq-1.5.2-7.fc38
Summary:  Coq support library for gappa
RPMs: gappalib-coq gappalib-coq-source
Size: 8.24 MiB
Size change:  174.76 KiB
Changelog:
  * Sat Apr 01

Re: Auto-assign packager sponsors to tickets?

2023-04-02 Thread Fabio Valentini 
On Sun, Apr 2, 2023 at 1:09 AM Jakub Kadlcik  wrote:
>
> Oh, and I forgot one important thing. Any sponsor that would disagree
> with being assigned tickets this way would be able to opt out by
> adding something like `auto_assign: false` to their sponsor.yaml
> https://github.com/FrostyX/fedora-sponsors#b-your-personal-config-on-fedorapeopleorg

I'm not sure a "technical" solution is the best idea here.
Sponsoring someone into the "packager" group comes with a set of
responsibilities, and requires at least some amount of time to be
allocated to mentoring.
I don't think it's fair to expect that all sponsors are available to
do this at any time.

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

Re: Auto-assign packager sponsors to tickets?

2023-04-02 Thread Vitaly Zaitsev via devel 

On 01/04/2023 23:14, Jakub Kadlčík wrote:

Currently, we have 31 people waiting to be sponsored
https://fedoraproject.org/PackageReviewStatus/needsponsor.html
many of them waiting for months.


If they wait for months, I think they don't want to be sponsored. I 
sponsored everyone who emailed me or asked in #fedora-devel.



I believe there is a technical solution to this problem


I doubt.


What do you think? Would you be okay with a system like this?


Please exclude me from such spam. I'm always willing to review and 
sponsor new maintainers, but they need to show explicit consent by 
posting on IRC/Matrix/ML or direct email.


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

Re: Heads-up: fast_float 4.0.0 coming to Rawhide

2023-04-02 Thread Luna Jernberg 
Thanks for the clarification

On 4/1/23, Ben Beasley  wrote:
> Thanks; you’re correct. At least I got the year right!
>
> On Sat, Apr 1, 2023, at 8:47 AM, Luna Jernberg wrote:
>> Should this be 2023-04-07? 2023-03-07 has been weeks ago ?
>>
>> On 3/31/23, Ben Beasley  wrote:
>>> In one week (2023-03-07), or slightly later, I plant to update
>>> fast_float to 4.0.0[1] in Rawhide. This new major release contains one
>>> small but technically incompatible change: errc::result_out_of_range is
>>> now set on over/underflow. A PR[2] is ready, and I have already verified
>>> (by local mock builds) that dependent packages c4core and libscn remain
>>> compatible.
>>>
>>> [1] https://github.com/fastfloat/fast_float/releases/tag/v4.0.0
>>>
>>> [2] https://src.fedoraproject.org/rpms/fast_float/pull-request/4
>>> ___
>>> devel mailing list -- devel@lists.fedoraproject.org
>>> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
>>> Fedora Code of Conduct:
>>> https://docs.fedoraproject.org/en-US/project/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
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/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