Re: Users with commit rights in src.fp.o but no more in packager group

[David Tardon]

Hi,

On Thu, 2022-08-25 at 11:04 +0300, Alexander Bokovoy wrote:
> On to, 25 elo 2022, Miro Hrončok wrote:
> > We use the python-maint pseudo-account to be the default Bugzilla 
> > assignee for Pythons, e.g. 
> > https://src.fedoraproject.org/rpms/python3.11
> > 
> > Note that it does *not* require the account to be listed in 
> > maintainers or to have commit rights.
> 
> Same for ipa-maint account.

Same for systemd-maint and dracut-maint.

D.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an 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

More Ansible license changes

[Maxwell G via devel]

Hi Fedorians,

I'm back with more ansible license updates. Upstream, some of the community 
Ansible Collections have adopted the REUSE specification, which makes it much 
easier to determine the overall license. For collections that have adopted 
this, the license texts are all stored as files in one directory, instead of 
being spread out throughout the source tree as file headers. I would like to 
thank the upstream developers for working with me on this.

The License tag of ansible-collection-community-general has changed from 
"GPLv3+ and BSD and Python" to "GPL-3.0-or-later AND BSD-2-Clause AND PSF-2.0 
AND MIT". See 
https://src.fedoraproject.org/rpms/ansible-collection-community-general/pull-request/8.

The License tag of ansible has changed from "GPLv3+" to "GPL-3.0-or-later AND 
Apache-2.0 AND BSD-2-Clause AND BSD-3-Clause AND MIT AND MPL-2.0 AND PSF-2.0". 
I cannot claim this to be 100% accurate, but I have done my best to determine 
the overall license. Note that ansible is a curated bundle of 103 Ansible 
collections, so this task is a bit difficult. See 
https://src.fedoraproject.org/rpms/ansible/pull-request/32.

-- 
Thanks,

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


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: Planning to start unifying native and mingw packages

[Michael Cronenworth]

On 8/25/22 11:42 AM, Sandro Mani wrote:
You might also want to add the mingw debuginfo packages to those. 


Ah, thanks. I'm used to the debuginfo packages being automatically added thanks to 
%{mingw_package_header}.


I wonder if we could have the install macros updated to handle this in a native 
package scenario.

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an 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: Let's enable Koschei for all packages automatically

[Gary Buhrmaster]

On Thu, Aug 25, 2022 at 7:57 AM Miro Hrončok  wrote:
>
> Hello folks,
>
> during our Nest FESCo session, we've talked about enabling Koschei [1] for all
> packages automatically.

I am not anywhere near the deciders group, but this
(enabling Koschei by default) just makes too much
sense not to do for the vast majority of cases (I have
no doubt there are edge cases (there are always
edge cases) where disabling Koschei is the right
choice, too).

And while I am a small time packager, I enable Koschei
for all my packages (CI is not a panacea, of course,
no matter what some advocates might try to assert).
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an 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: Sympy 1.11 (review swaps)

[Jerry James]

On Thu, Aug 25, 2022 at 7:46 PM Jonathan Wright via devel
 wrote:
> I'll start on yours if you'll start on mine, I have a pile of my own :)

It's a deal.  I'll get started on yours.  Thank you!
-- 
Jerry James
http://www.jamezone.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: sqlcipher soname change in rawhide

[Maxwell G via devel]

On Thursday, August 25, 2022 Carl George wrote:
> [root@f38-container:~]# repoquery --repo
> rawhide-source,rawhide-modular-source \
> > --quiet --queryformat '%{name}' --archlist src --whatrequires
> > sqlcipher-devel
> libgda
> python-peewee
> sqlitebrowser
> [root@f38-container:~]# repoquery --repo
> rawhide-source,rawhide-modular-source \
> > --quiet --queryformat '%{name}' --archlist src --whatrequires
> > 'pkgconfig(sqlcipher)'
> kmymoney
> rust-libsqlite3-sys
> skrooge

You do not need to separately query for the Provides like this. If you
keep the regular repository enabled and filter out the src packages
after, the Provides are queried, as well.

$ sudo dnf repoquery --repo=rawhide{,-source} -q --whatrequires sqlcipher-devel 
| grep '\.src$' | pkgname | sort -u

kmymoney
libgda
python-peewee
rust-libsqlite3-sys
skrooge
sqlitebrowser


-- 
Thanks,

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


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: Sympy 1.11 (review swaps)

[Jonathan Wright via devel]

I'll start on yours if you'll start on mine, I have a pile of my own :)

https://bugzilla.redhat.com/buglist.cgi?bug_status=NEW=Package%20Review=jonathan%40almalinux.org=1=equals_name=My%20review%20requests_id=12864886=Fedora_based_on=My%20review%20requests_format=advanced

On Thu, Aug 25, 2022 at 8:38 PM Jerry James  wrote:

> I'm working on an update to sympy, to version 1.11.  This version has
> several backwards incompatible changes.  I inspected the consuming
> packages for use of the backwards incompatible APIs and found none.
> Just in case, I did local mock builds of each one, and the builds were
> all successful, including runs of their test suites.  The consuming
> packages are:
>
> - python-boutdata
> - python-brian2
> - python-fiat
> - python-nipy
> - python-pysb
> - python-trimesh
> - sagemath
>
> It is no longer possible to build the sympy documentation, due to
> missing dependencies.  However, I have already noted other packages I
> maintain that need each of these.  That tells me it is time to get
> them into Fedora.  I would like to swap reviews for the following:
>
> - python-sphinx-basic-ng:
> https://bugzilla.redhat.com/show_bug.cgi?id=2121593
> - python-furo: https://bugzilla.redhat.com/show_bug.cgi?id=2121594,
> needs python-sphinx-basic-ng
> - python-uc-micro-py: https://bugzilla.redhat.com/show_bug.cgi?id=2121595
> - python-linkify-it-py:
> https://bugzilla.redhat.com/show_bug.cgi?id=2121596, needs
> python-uc-micro-py
> - python-sphinx-documatt-theme:
> https://bugzilla.redhat.com/show_bug.cgi?id=2121597
> - python-sphinx-reredirects:
> https://bugzilla.redhat.com/show_bug.cgi?id=2121598, needs
> python-sphinx-documatt-theme
>
> Let me know what I can review for you.
> --
> Jerry James
> http://www.jamezone.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
>


-- 
Jonathan Wright
AlmaLinux Foundation
Mattermost: chat 
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an 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

Sympy 1.11 (review swaps)

[Jerry James]

I'm working on an update to sympy, to version 1.11.  This version has
several backwards incompatible changes.  I inspected the consuming
packages for use of the backwards incompatible APIs and found none.
Just in case, I did local mock builds of each one, and the builds were
all successful, including runs of their test suites.  The consuming
packages are:

- python-boutdata
- python-brian2
- python-fiat
- python-nipy
- python-pysb
- python-trimesh
- sagemath

It is no longer possible to build the sympy documentation, due to
missing dependencies.  However, I have already noted other packages I
maintain that need each of these.  That tells me it is time to get
them into Fedora.  I would like to swap reviews for the following:

- python-sphinx-basic-ng: https://bugzilla.redhat.com/show_bug.cgi?id=2121593
- python-furo: https://bugzilla.redhat.com/show_bug.cgi?id=2121594,
needs python-sphinx-basic-ng
- python-uc-micro-py: https://bugzilla.redhat.com/show_bug.cgi?id=2121595
- python-linkify-it-py:
https://bugzilla.redhat.com/show_bug.cgi?id=2121596, needs
python-uc-micro-py
- python-sphinx-documatt-theme:
https://bugzilla.redhat.com/show_bug.cgi?id=2121597
- python-sphinx-reredirects:
https://bugzilla.redhat.com/show_bug.cgi?id=2121598, needs
python-sphinx-documatt-theme

Let me know what I can review for you.
-- 
Jerry James
http://www.jamezone.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: how to update rpms/vile?

[Lyes Saadi]

Hello,

mmckinst seems to have been marked as an Inactive Packager looking at 
the recently introduced Inactive Packager Policy:

https://pagure.io/find-inactive-packagers/issue/230

As such, he will loose packager status in two months in case he doesn't 
answer.


If you don't want to wait for two months, you can follow the 
Non-responsive Maintainer Policy:

https://docs.fedoraproject.org/en-US/fesco/Policy_for_nonresponsive_package_maintainers/

If the request is granted, his packages will be orphaned, and any 
packager will be able to pick it up, including you.


He last logged into the Fedora Account System on the 18th of August 2020.

Greetings,
Lyes Saadi

Le 26/08/2022 à 00:46, Thomas Dickey a écrit :

I'm the upstream developer/maintainer for vile (vi like emacs) and a few other 
programs packaged in Fedora.
The vile rpm is a couple of years out of date, now, and I don't see recent 
activity by the package maintainer.

What can I do to get it moving again?

(Earlier this year, I restored a couple that had been orphaned, but that isn't 
the current state for vile).
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an 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

sqlcipher soname change in rawhide

[Carl George]

sqlcipher has been requested to be built in epel9 [0].  Rather than
branching it from the current rawhide version, I plan to update
rawhide to the latest upstream version first [1].  This involves an
soname change from libsqlcipher-3.34.1.so.0 to
libsqlcipher-3.39.2.so.0.  This will require six packages to be
rebuilt.

[root@f38-container:~]# repoquery --repo rawhide-source,rawhide-modular-source \
> --quiet --queryformat '%{name}' --archlist src --whatrequires sqlcipher-devel
libgda
python-peewee
sqlitebrowser
[root@f38-container:~]# repoquery --repo rawhide-source,rawhide-modular-source \
> --quiet --queryformat '%{name}' --archlist src --whatrequires 
> 'pkgconfig(sqlcipher)'
kmymoney
rust-libsqlite3-sys
skrooge

I've worked with Jonathan to do a test run of rebuilding these
packages in copr [2], and everything was successful.  I will build the
new sqlcipher in a side tag and then complete the rebuilds in the side
tag myself via proven packager permissions.

[0] https://bugzilla.redhat.com/show_bug.cgi?id=2120882
[1] https://src.fedoraproject.org/rpms/sqlcipher/pull-request/3
[2] https://copr.fedorainfracloud.org/coprs/jonathanspw/sqlcipher/builds/

-- 
Carl George
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an 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

how to update rpms/vile?

[Thomas Dickey]

I'm the upstream developer/maintainer for vile (vi like emacs) and a few other 
programs packaged in Fedora.
The vile rpm is a couple of years out of date, now, and I don't see recent 
activity by the package maintainer.

What can I do to get it moving again?

(Earlier this year, I restored a couple that had been orphaned, but that isn't 
the current state for vile). 
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an 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

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

[Christopher Klooz]

I just tried an update (`dnf update`, F36).

Three packages that are to be updated are from the fedora-cisco-openh264 
repository.


In all three cases, I get the dnf output that these packages have not 
been signed, which finally makes the GPG verification to fail.


The packages are:

 gstreamer1-plugin-openh264-1.20.3-1.fc36.x86_64.rpm
 mozilla-openh264-2.3.0-1.fc36.x86_64.rpm
 openh264-2.3.0-1.fc36.x86_64.rpm

I tried `dnf clean packages` and then tried update again. The error is 
the same.


If I exclude the three packages, the remaining updates work fine. The 
error seems to be in the fedora-cisco-openh264 repo.


DNF output (this system is unfortunately German; tomorrow, I can try on 
my other system and add it's English output if you cannot reproduce the 
issue for some reason):


---
...
...
Gesamt 467 kB/s | 3.6 MB 00:07
Delta-RPMs reduzierten 8.2 MB an Aktualisierungen auf 3.6 MB (56.6% gespart)
Paket gstreamer1-plugin-openh264-1.20.3-1.fc36.x86_64.rpm ist nicht signiert
Paket mozilla-openh264-2.3.0-1.fc36.x86_64.rpm ist nicht signiert
Paket openh264-2.3.0-1.fc36.x86_64.rpm ist nicht signiert
Die heruntergeladenen Pakete wurden bis zur nchsten erfolgreichen 
Transaktion im Zwischenspeicher abgelegt.
Sie knnen zwischengespeicherte Pakete mit dem Befehl dnf clean packages 
entfernen.

Fehler: GPG-berprfung fehlgeschlagen

---

"nicht signiert" = transl. "not signed"
"Fehler: GPG-Überprüfung fehlgeschlagen" = transl. "Error: GPG 
verification failed"


Chris

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an 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

[Bug 2115572] Please build perl-Number-Bytes-Human for EPEL 9

[bugzilla]

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



--- Comment #5 from Andrew Bauer  ---
It seems strange that EPEL would have a different procedure than Fedora:
https://docs.fedoraproject.org/en-US/fesco/Policy_for_nonresponsive_package_maintainers/

As the packager for ZoneMinder in RPMFusion, I am willing to maintain
perl-Number-Bytes-Human since it is a dependent package.
I am not in the epel-packagers-sig group, though.


-- 
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=2115572
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Retiring: python-sendgrid

[Otto Liljalaakso]

Fabio Valentini kirjoitti 25.8.2022 klo 16.01:

On Thu, Aug 25, 2022 at 2:49 PM Chris Adams  wrote:


Once upon a time, Ali Erdinc Koroglu  said:

Dear maintainers,
Python-sendgrid [1] will be retiring after F37, because since v6.4.1
it depends to starkbank-ecdsa [2] which we can't add to Fedora
due to secp256k1 elliptic curve support.


What's wrong with secp256k1?  Fedora already has libsecp256k1, so it
doesn't appear that curve is blocked.


I seem to remember that there was a Fedora Legal Wiki page that listed
the elliptic curves that Fedora was not allowed to ship, but I can't
find it anywhere, so maybe it fell victim to the move to GitLab and
Fedora Docs (as did some other useful docs ...).


Do you mean this page, that lists ones that *are* allowed?
secp256k1 is on the list.

https://fedoraproject.org/wiki/Legal:ECC
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an 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

[Bug 2115572] Please build perl-Number-Bytes-Human for EPEL 9

[bugzilla]

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



--- Comment #4 from Robert Scheck  ---
I've now filed https://pagure.io/releng/issue/10992 according to
https://docs.fedoraproject.org/en-US/epel/epel-package-request/#epel_packagers_sig_members,
because there was no response by the maintainer after three weeks and three
attempts.


-- 
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=2115572
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: percona-xtrabackup bundling the kitchen sink in static libs

[Sven Lankes]

On Tue, Aug 23, 2022 at 11:27:55AM -0400, Paul Wouters wrote:

> >[1]: https://docs.fedoraproject.org/en-US/fesco/Bundled_Software_policy/
 
> Thanks for the link. Sadly, the justification would be "because upstream
> hardcoded this an errors on any other version", which in itself is
> pretty weak. And since it includes boost, which can't easilly be
> upgraded between fedora releases, all the older stuff lingers forever.

There is a little more to it: percona-xtrabackup also comes with
mysql (because it is basically running a copy of it's own mysql/innodb
to do it's job - just like the other comparable versions around). And
this mysql is what is "bound" to that boost version. xtrabackup just
inherits this bundling.

If you look at the percona-xtrabackup versioning you'll see that the
current upstream release is:

  * percona-xtrabackup-8.0.29-22

and that refers to it's bundling of mysql 8.0.29

> >Non-responsive maintainer policy [2]. This package has CVE bugs
> >open [3],

There was _one_ CVE bug and that was for the old version of xtrabackup
that is not shipped for fedora. I have just closed that bug.

The other CVEs are for EPEL builds - while I am in theory interested in
fixing epel as well I won't touch it until the fedora branch is in a
better state.

> Miro started the non-responsive maintainer process and woke up the
> maintainer, but they themselves are also thinking it might be better
> to kick it out of fedora.
> https://bugzilla.redhat.com/show_bug.cgi?id=1989019

Yes - the build process is cumbersome and it is a bad fit for fedora on
that alone. Yet for me it still scratches an itch and being able to do a
'dnf install percona-xtrabackup' is still useful.

-- 
sven
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an 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: Why install rsyslog by default?

[Chris Adams]

Once upon a time, Peter Robinson  said:
> On Thu, Aug 25, 2022 at 8:07 PM Michael Catanzaro  
> wrote:
> > On Thu, Aug 25 2022 at 02:45:31 PM -0400, Neal Gompa
> >  wrote:
> > > We should remove rsyslog from @standard.
> >
> > Packages in @standard but not in @workstation-product:
> >
> > at
> > crontabs
> > dbus
> > ed (no, really)
> > fprintd-pam
> > irqbalance
> > rsyslog
> > smartmontools
> > util-linux-user
> >
> > Seems like if we remove a few things from @standard, we could have
> > Workstation use @standard and then @workstation-product would just need
> > to include extra stuff instead of duplicating most of @standard.
> 
> Yes please, I think this is a useful reduction across all desktop 
> environments.

I don't run @workstation, so maybe there are replacements, but a few are
commonly useful:

- fprintd-pam: used for fingerprint login
- smartmontools: monitors hard disk health
- util-linux-user: chsh (used to change shell) and chfn

I'm not sure why those last two utilities merit a separate package; it's
not a size thing (the installed size is 61kB), it doesn't look like they
add any dependencies over the util-linux package.

dbus is a virtual package now for dbus-broker, so don't know if it is
needed in any setup directly.

IIRC ed was in default installs for a long time because it's part of the
POSIX spec.

I thought that irqbalance was obsoleted at some point by in-kernel
tuning, but I haven't dug deeply.  If not, it should probably be
installed just about everywhere (at least on physical systems), since
almost all CPUs are multi-core now.

I personally like rsyslog for traditional logs for some things, as its
easier to portion out limited access (for example, on some servers I
might make DHCP or mail logs readable by non-root users in a particular
group), but that's a niche usage and I don't care whether it is in
default installs.

-- 
Chris Adams 
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an 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: Why install rsyslog by default?

[Peter Robinson]

On Thu, Aug 25, 2022 at 8:07 PM Michael Catanzaro  wrote:
>
> On Thu, Aug 25 2022 at 02:45:31 PM -0400, Neal Gompa
>  wrote:
> > We should remove rsyslog from @standard.
>
> Packages in @standard but not in @workstation-product:
>
> at
> crontabs
> dbus
> ed (no, really)
> fprintd-pam
> irqbalance
> rsyslog
> smartmontools
> util-linux-user
>
> Seems like if we remove a few things from @standard, we could have
> Workstation use @standard and then @workstation-product would just need
> to include extra stuff instead of duplicating most of @standard.

Yes please, I think this is a useful reduction across all desktop environments.

P
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an 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: Orphaned packages looking for new maintainers

[Jonathan Wright via devel]

I'm working on some of the deps for mailman3/hyperkitty.

I should have the python-flufl-lock dep solved for you.

On Mon, Aug 22, 2022 at 12:04 PM Michel Alexandre Salim <
sali...@fedoraproject.org> wrote:

> On Mon, Aug 22, 2022 at 01:07:26PM +0200, Miro Hrončok wrote:
> > The following packages are orphaned and will be retired when they
> > are orphaned for six weeks, unless someone adopts them. If you know for
> sure
> > that the package should be retired, please do so now with a proper
> reason:
> > https://fedoraproject.org/wiki/How_to_remove_a_package_at_end_of_life
> >
> > mailman3   infra-sig, orphan, salimma  0
> weeks ago
> > monkeytype orphan  0
> weeks ago
>
> Picked these back up - will try and address the issues this week, sorry
> for the delay.
>
> > rubygem-asciidoctor-pdfabradshaw, ckyriakidou, evgeni, 0
> weeks ago
> >fale, orphan, snecker
> > rubygem-chunky_png mmorsi, orphan, snecker 0
> weeks ago
> > rubygem-css_parser abradshaw, ckyriakidou, evgeni, 0
> weeks ago
> >fale, orphan, snecker
> > rubygem-font-awesome-rails abradshaw, ckyriakidou, evgeni, 0
> weeks ago
> >fale, orphan, snecker
> > rubygem-prawn-icon abradshaw, ckyriakidou, evgeni, 0
> weeks ago
> >fale, orphan, snecker
> > rubygem-prawn-manual_builder   abradshaw, ckyriakidou, evgeni, 0
> weeks ago
> >fale, orphan, snecker
> > rubygem-prawn-svg  abradshaw, ckyriakidou, evgeni, 0
> weeks ago
> >fale, orphan, snecker
> > rubygem-prawn-templatesabradshaw, ckyriakidou, evgeni, 0
> weeks ago
> >fale, orphan, snecker
> ^ these will probably break a lot of documentation builds - one of my
> package (nickle) is affected. Not sure I have the bandwith to help fix
> this though.
>
> Best regards,
>
> --
> Michel Alexandre Salim
> identities: https://keyoxide.org/5dce2e7e9c3b1cffd335c1d78b229d2f7ccc04f2
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an 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
>


-- 
Jonathan Wright
AlmaLinux Foundation
Mattermost: chat 
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an 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: Why install rsyslog by default?

[Kalev Lember]

On Thu, Aug 25, 2022 at 9:07 PM Michael Catanzaro 
wrote:

> On Thu, Aug 25 2022 at 02:45:31 PM -0400, Neal Gompa
>  wrote:
> > We should remove rsyslog from @standard.
>
> Packages in @standard but not in @workstation-product:
>
> at
> crontabs
> dbus
> ed (no, really)
> fprintd-pam
> irqbalance
> rsyslog
> smartmontools
> util-linux-user
>
> Seems like if we remove a few things from @standard, we could have
> Workstation use @standard and then @workstation-product would just need
> to include extra stuff instead of duplicating most of @standard.
>

Yes, I agree that it would be nice if we could do that.

When I did the initial Workstation comps groups years ago I based them on
the idea that the Workstation WG had back then that all of the comps groups
that go into Workstation should be under the control of the Workstation WG
so originally it was by design that @standard didn't get used in
@workstation-product.

I don't share that view any more though and I think it would be nice to
share the maintenance burden for the low level packages that are in
@standard :) We've already got rid of the @gnome-desktop split so I think
it would make sense to do it with @standard as well.

-- 
Kalev
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an 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: Why install rsyslog by default?

[Michael Catanzaro]

On Thu, Aug 25 2022 at 02:45:31 PM -0400, Neal Gompa 
 wrote:

We should remove rsyslog from @standard.


Packages in @standard but not in @workstation-product:

at
crontabs
dbus
ed (no, really)
fprintd-pam
irqbalance
rsyslog
smartmontools
util-linux-user

Seems like if we remove a few things from @standard, we could have 
Workstation use @standard and then @workstation-product would just need 
to include extra stuff instead of duplicating most of @standard.


___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an 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: Why install rsyslog by default?

[Neal Gompa]

On Thu, Aug 25, 2022 at 2:34 PM Samuel Sieb  wrote:
>
> On 2022-08-25 08:22, Barry Scott wrote:
> >> On 25 Aug 2022, at 16:05, Robert Marcano via devel
> >> mailto:devel@lists.fedoraproject.org>>
> >> wrote:
> >>
> >> On 8/25/22 11:02 AM, Barry Scott wrote:
> >>> I just found that rsyslog is installed and by default creating legacy
> >>> log files in /var/log like messages and secure.
> >>> Now that journald has been in Fedora for so long this is useful
> >>> default to install rsyslog?
> >>
> >> I don't have it installed. I think it is usually Chrome RPM (not
> >> Chromium) that bring a lot of awful dependencies because it requires
> >> some legacy lsb packages.
> >>
> >
> > Its in the dnf history info 1 so in the Fedora KDE base install, not
> > what you suggest,
> > no chrome stuff installed.
> >
> > Also dnf remove does not try to pull out any thing by a few deps of rsyslog.
>
> Then it's a kde spin issue.  The workstation install doesn't include it
> and I doubt the server one does.  Maybe better to ask on the kde list.

We should remove rsyslog from @standard.



-- 
真実はいつも一つ！/ 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: Why install rsyslog by default?

[Samuel Sieb]

On 2022-08-25 08:22, Barry Scott wrote:
On 25 Aug 2022, at 16:05, Robert Marcano via devel 
mailto:devel@lists.fedoraproject.org>> 
wrote:


On 8/25/22 11:02 AM, Barry Scott wrote:

I just found that rsyslog is installed and by default creating legacy
log files in /var/log like messages and secure.
Now that journald has been in Fedora for so long this is useful
default to install rsyslog?


I don't have it installed. I think it is usually Chrome RPM (not 
Chromium) that bring a lot of awful dependencies because it requires 
some legacy lsb packages.




Its in the dnf history info 1 so in the Fedora KDE base install, not 
what you suggest,

no chrome stuff installed.

Also dnf remove does not try to pull out any thing by a few deps of rsyslog.


Then it's a kde spin issue.  The workstation install doesn't include it 
and I doubt the server one does.  Maybe better to ask on the kde list.

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an 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: Planning to start unifying native and mingw packages

[Daniel P . Berrangé]

On Thu, Aug 25, 2022 at 06:42:52PM +0200, Sandro Mani wrote:
> 
> On 25.08.22 18:40, Michael Cronenworth wrote:
> > On 8/25/22 1:33 AM, Marián Konček wrote:
> > > I could however open a PR to add them to the native packages. Do we
> > > have some libraries where this unification is already finished so
> > > that I could take inspiration?
> > 
> > FAudio
> > vkd3d
> 
> You might also want to add the mingw debuginfo packages to those.

Also if the package is used in RHEL, it may be desirable to make the
mingw sub-packages conditional, so that they don't get enabled when
the Fedora spec is later rebuilt in a RHEL build root.

I've got an example here which is fairly simple, for an app using
meson:

  
https://src.fedoraproject.org/rpms/libosinfo/c/c567145568cb401ce5143e5829f1d60ca45f77dc?branch=rawhide

If the app uses autotools still it is a little more complex, as you'll
need to make the native build use builddir != srcdir before adding
the mingw bits. Unfortunately %configure doesn't do this by default,
while meson does (and cmake does too iirc). To adapt autotools based
app native build use something approximately like this:

  %define _configure ../configure

  mkdir build_native
  cd build_native

  %configure ...args...
  %make_build

  cd ..

and similar during install phase

  cd build_native
  %make_install
  cd ..

With regards,
Daniel
-- 
|: https://berrange.com  -o-https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org -o-https://fstop138.berrange.com :|
|: https://entangle-photo.org-o-https://www.instagram.com/dberrange :|
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an 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: Planning to start unifying native and mingw packages

[Sandro Mani]

On 25.08.22 18:40, Michael Cronenworth wrote:

On 8/25/22 1:33 AM, Marián Konček wrote:
I could however open a PR to add them to the native packages. Do we 
have some libraries where this unification is already finished so 
that I could take inspiration?


FAudio
vkd3d


You might also want to add the mingw debuginfo packages to those.

Sandro
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an 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: Planning to start unifying native and mingw packages

[Michael Cronenworth]

On 8/25/22 1:33 AM, Marián Konček wrote:
I could however open a PR to add them to the native packages. Do we have some 
libraries where this unification is already finished so that I could take inspiration?


FAudio
vkd3d
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an 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

[Bug 2116269] Add perl-Set-Object to EPEL 9

[bugzilla]

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

Fedora Update System  changed:

   What|Removed |Added

 Resolution|--- |ERRATA
   Fixed In Version||perl-Set-Object-1.42-3.el9
 Status|ON_QA   |CLOSED
Last Closed||2022-08-25 16:32:57



--- Comment #7 from Fedora Update System  ---
FEDORA-EPEL-2022-4c9e20a609 has been pushed to the Fedora EPEL 9 stable
repository.
If problem still persists, please make note of it in this bug report.


-- 
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=2116269
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

[Bug 2116587] perl-Bencode-1.502 is available

[bugzilla]

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

Fedora Update System  changed:

   What|Removed |Added

   Fixed In Version|perl-Bencode-1.502-1.fc38   |perl-Bencode-1.502-1.fc38
   |perl-Bencode-1.502-1.fc36   |perl-Bencode-1.502-1.fc36
   |perl-Bencode-1.502-1.fc35   |perl-Bencode-1.502-1.fc35
   ||perl-Bencode-1.502-1.el9



--- Comment #14 from Fedora Update System  ---
FEDORA-EPEL-2022-1c69554f1e has been pushed to the Fedora EPEL 9 stable
repository.
If problem still persists, please make note of it in this bug report.


-- 
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=2116587
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

[Bug 2102685] Add perl-Graph to EPEL 9

[bugzilla]

https://bugzilla.redhat.com/show_bug.cgi?id=2102685
Bug 2102685 depends on bug 2116269, which changed state.

Bug 2116269 Summary: Add perl-Set-Object to EPEL 9
https://bugzilla.redhat.com/show_bug.cgi?id=2116269

   What|Removed |Added

 Status|ON_QA   |CLOSED
 Resolution|--- |ERRATA




-- 
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=2102685
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: 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: Let's enable Koschei for all packages automatically

[Adam Williamson]

On Thu, 2022-08-25 at 09:53 +0200, Miro Hrončok wrote:
> Hello folks,
> 
> during our Nest FESCo session, we've talked about enabling Koschei [1] for 
> all 
> packages automatically.
> 
> There seem to be a consensus by FESCo members, that it would be a good thing.
> 
> What would it take?
> 
> 1) Koji resources
> 
> I think we can try to enable this and see if it burns. I think ti won't.
> 
> 
> 2) One-time enablement of all existing packages
> 
> That should be doable. Right?
> 
> 
> 3) Automatic enablement of all new packages
> 
> That should be just a matter of changing the defaults. Correct?
> 
> 
> Can we do this? How can I help?

Big +1. Even for 1), if it turns out things burn, we now have a great
case to ask for more resources - we're not just theoretically trying to
bump things up against possible capacity requirements, we need to fix
something that's a problem right now! ;)
-- 
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, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Why install rsyslog by default?

[Barry Scott]

> On 25 Aug 2022, at 16:05, Robert Marcano via devel 
>  wrote:
> 
> On 8/25/22 11:02 AM, Barry Scott wrote:
>> I just found that rsyslog is installed and by default creating legacy
>> log files in /var/log like messages and secure.
>> Now that journald has been in Fedora for so long this is useful
>> default to install rsyslog?
> 
> I don't have it installed. I think it is usually Chrome RPM (not Chromium) 
> that bring a lot of awful dependencies because it requires some legacy lsb 
> packages.
> 

Its in the dnf history info 1 so in the Fedora KDE base install, not what you 
suggest,
no chrome stuff installed.

Also dnf remove does not try to pull out any thing by a few deps of rsyslog.

Barry

> Last time I installed it even pulled perl packages.
> 
>> Barry
>> ___
>> devel mailing list -- devel@lists.fedoraproject.org
>> To unsubscribe send an 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

Re: Why install rsyslog by default?

[Michael Catanzaro]

On Thu, Aug 25 2022 at 04:02:25 PM +0100, Barry Scott 
 wrote:

I just found that rsyslog is installed and by default


Depends on what install media you use. It's part of the @standard comps 
group. Workstation does not use @standard for exactly this reason: it 
has extra stuff like this that's not wanted in Workstation. It would be 
nice to slim down @standard and use it everywhere.


Michael

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an 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: Why install rsyslog by default?

[Robert Marcano via devel]

On 8/25/22 11:02 AM, Barry Scott wrote:

I just found that rsyslog is installed and by default creating legacy
log files in /var/log like messages and secure.

Now that journald has been in Fedora for so long this is useful
default to install rsyslog?



I don't have it installed. I think it is usually Chrome RPM (not 
Chromium) that bring a lot of awful dependencies because it requires 
some legacy lsb packages.


Last time I installed it even pulled perl packages.


Barry
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an 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

Why install rsyslog by default?

[Barry Scott]

I just found that rsyslog is installed and by default creating legacy
log files in /var/log like messages and secure.

Now that journald has been in Fedora for so long this is useful
default to install rsyslog?

Barry
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an 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: Let's enable Koschei for all packages automatically

[Fabio Valentini]

On Thu, Aug 25, 2022 at 4:34 PM Ankur Sinha  wrote:
>
> On Thu, Aug 25, 2022 15:58:12 +0200, Fabio Valentini wrote:
> > Yeah that should be pretty simple. Get list of source packages in
> > $release, paste it into the "Add packages" page, set release combobox
> > to $release, submit.
> > I do that regularly for all Rust packages.
>
> The rust-sig packages are also set to automatically be tracked by
> Koschei from the looks of it and I expect this can then be done for all
> packages instead of for individual SIGs:
>
> https://pagure.io/fedora-infra/ansible/blob/main/f/roles/openshift-apps/koschei/vars/production.yml#_45

As far as I understand, this only automatically adds packages that are
associated with the  "@rust-sig" group on dist-git to the "rust-sig"
group on koschei.
We still need to manually enable tracking for new packages, but
syncing group membership is automatic.

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

[Bug 2110771] rt-5.0.3 is available

[bugzilla]

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

Ralf Corsepius  changed:

   What|Removed |Added

 Resolution|--- |RAWHIDE
 Status|NEW |CLOSED
   Doc Type|--- |If docs needed, set a value
Last Closed||2022-08-25 14:37:29




-- 
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=2110771
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Let's enable Koschei for all packages automatically

[Michael Catanzaro]

On Thu, Aug 25 2022 at 09:53:49 AM +0200, Miro Hrončok 
 wrote:
during our Nest FESCo session, we've talked about enabling Koschei 
[1] for all

packages automatically.


Yay, this should have been done long ago. ;)

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an 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: Let's enable Koschei for all packages automatically

[Ankur Sinha]

On Thu, Aug 25, 2022 15:58:12 +0200, Fabio Valentini wrote:
> Yeah that should be pretty simple. Get list of source packages in
> $release, paste it into the "Add packages" page, set release combobox
> to $release, submit.
> I do that regularly for all Rust packages.

The rust-sig packages are also set to automatically be tracked by
Koschei from the looks of it and I expect this can then be done for all
packages instead of for individual SIGs:

https://pagure.io/fedora-infra/ansible/blob/main/f/roles/openshift-apps/koschei/vars/production.yml#_45

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

Re: Security Problem with "PackageKit-command-not-found" package

[Michael Catanzaro]

On Thu, Aug 25 2022 at 11:20:46 AM -, Sandipan Roy 
 wrote:
By this vulnerability any wheel user can install any packages without 
root access or sudo.


Hi, this is actually by design and not a vulnerability. The wheel user 
is definitionally an administrator user, and can escalate from wheel to 
root without abusing any vulnerability. It might be more intuitive if 
you consider that wheel users have unrestricted access to sudo. So 
yeah, you can use PackageKit to install sqliteODBC or Sympa and abuse 
them to elevate privileges... or you could just run sudo and not 
bother, right?


The JavaScript rule in question here actually has nothing to do with 
authorization, only with *authentication*. It disables the password 
prompt that forces the human sitting at the computer to authenticate. 
This means a local attacker with physical access to the computer -- 
e.g. a secret agent from the FBI or KGB or Mossad -- can install 
packages on your computer if you leave your desktop unlocked and walk 
away, or if they attack you with a hammer. But this has no effect on 
authorization. Notably, if the password prompt were required, it would 
be asking you for the password *to your wheel account*. Fedora's root 
account is locked by default anyway, with no root password and no way 
to authenticate as root.


Since most Fedora users are not too worried about secret agents, the 
extra password prompt is annoying rather than useful. It's totally 
reasonable to skip authentication for users who *already* authenticated 
when logging into the desktop, right? Users who don't have wheel still 
have to authenticate as a user who does, or they won't be able to 
install anything.


That said, there is a bug here, just not where you thought. Look at 
this comment:


   

If that were true, then unprivileged users really could install 
vulnerable packages like sqliteODBC or Sympa and thereby elevate 
privileges. Fortunately, the comment is totally wrong as it doesn't 
match the actual security policy. Looking at the history of this file, 
it looks like this comment was correct when it was written on August 
21, 2007, but the policy was changed to be more restrictive later the 
same day. Here is a pull request to fix it:


https://github.com/PackageKit/PackageKit/pull/568

Michael

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an 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: Security Problem with "PackageKit-command-not-found" package

[Vitaly Zaitsev via devel]

On 25/08/2022 13:20, Sandipan Roy wrote:

I'm Sandipan Roy [FAS: ByteHackr], I wanted to share a serious system wide 
problem with PackageKit-command-not-found [1] package.


Not a bug, but a feature. Members of the wheel group, also known as 
"admin users", can install any packages using PackageKit without 
entering their password.


--
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: Retiring: python-sendgrid

[Vitaly Zaitsev via devel]

On 25/08/2022 14:42, Ali Erdinc Koroglu wrote:

which we can't add to Fedora due to secp256k1 elliptic curve support


Fedora already has secp256k1:

$ openssl ecparam -list_curves | grep 256k1
  secp256k1 : SECG curve over a 256 bit prime field

--
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: Let's enable Koschei for all packages automatically

[Vitaly Zaitsev via devel]

On 25/08/2022 09:53, Miro Hrončok wrote:

Can we do this? How can I help?


+1. Already enabled for all my packages.

--
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: Let's enable Koschei for all packages automatically

[Fabio Valentini]

On Thu, Aug 25, 2022 at 9:58 AM Miro Hrončok  wrote:
>
> Hello folks,
>
> during our Nest FESCo session, we've talked about enabling Koschei [1] for all
> packages automatically.
>
> There seem to be a consensus by FESCo members, that it would be a good thing.
>
> What would it take?
>
> 1) Koji resources
>
> I think we can try to enable this and see if it burns. I think ti won't.

Doesn't koschei have some built-in rate-limiting?
If necessary, we could probably just adjust the priority threshold
above which scratch builds are triggered.

> 2) One-time enablement of all existing packages
>
> That should be doable. Right?

Yeah that should be pretty simple. Get list of source packages in
$release, paste it into the "Add packages" page, set release combobox
to $release, submit.
I do that regularly for all Rust packages.

> 3) Automatic enablement of all new packages
>
> That should be just a matter of changing the defaults. Correct?

I think so. koschei already knows about all packages - I think it
syncs with PDC. So that process could possibly be adapted to not only
add the package to the koschei database, but also set the "tracked"
boolean to "true" by default instead of "false" by default.

> Can we do this? How can I help?

I think we can, and I think we should.
Even though scratch builds only run on x86_64, ppc64le, and aarch64
(and don't expose s390x and i686 build failures), it's still a very
valuable service.
I use it extensively to monitor the Rust stack for new build failures
(because I'm pushing dozens of updates every week and I want to know
about unintended breakage ASAP).

If there's something that I can do to help make "koschei tracking for
all packages on all branches by default" happen, I'll help too :)

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: Ruby FTBFS due to "SHA-1 jump scare"

[Daniel P . Berrangé]

On Thu, Aug 25, 2022 at 02:47:53PM +0100, Richard W.M. Jones wrote:
> On Wed, Aug 24, 2022 at 12:31:29PM -0700, Adam Williamson wrote:
> > so, from this we learn that the change would prevent PackageKit (and
> > presumably other tools) from being able to read old Fedora signing
> > keys; I'm not sure if that's a problem or not.
> 
> YES - virt-v2v, libguestfs etc relies on being able to inspect old RPM
> databases.

This inspection takes place inside the libguestfs appliance VM
though, right ? IOW can libguestfs ensure that its appliance
filesystem sets up crypto-policies in LEGACY mode, regardless
of what policy the host launching libguestfs is using.

With regards,
Daniel
-- 
|: https://berrange.com  -o-https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org -o-https://fstop138.berrange.com :|
|: https://entangle-photo.org-o-https://www.instagram.com/dberrange :|
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an 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: Ruby FTBFS due to "SHA-1 jump scare"

[Richard W.M. Jones]

On Wed, Aug 24, 2022 at 12:31:29PM -0700, Adam Williamson wrote:
> so, from this we learn that the change would prevent PackageKit (and
> presumably other tools) from being able to read old Fedora signing
> keys; I'm not sure if that's a problem or not.

YES - virt-v2v, libguestfs etc relies on being able to inspect old RPM
databases.

Please do not remove or cripple SHA-1 support.

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
nbdkit - Flexible, fast NBD server with plugins
https://gitlab.com/nbdkit/nbdkit
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an 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

[Bug 1934532] EPEL8 Request: perl-Astro-FITS-CFITSIO

[bugzilla]

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



--- Comment #4 from Fedora Update System  ---
FEDORA-EPEL-2022-d4d0379152 has been submitted as an update to Fedora EPEL 8.
https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2022-d4d0379152


-- 
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=1934532
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

[Bug 1934532] EPEL8 Request: perl-Astro-FITS-CFITSIO

[bugzilla]

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

Fedora Update System  changed:

   What|Removed |Added

 Status|ASSIGNED|MODIFIED



--- Comment #3 from Fedora Update System  ---
FEDORA-EPEL-2022-d6bb4559c9 has been submitted as an update to Fedora EPEL 9.
https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2022-d6bb4559c9


-- 
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=1934532
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

[EPEL-devel] Re: [new / help wanted] fence-agents-epel package

[Alex Talaran]

wouldnt think make split packages vs all the agents just in the -epel 
package as i originally submitted? im fine either way just not clear.
do i need to make other changes or does the rest seem ok since i am not 
tied to requiring man pages?


On 2022-08-25 08:29, Troy Dawson wrote:
For the names, the source rpm needs to have the -epel suffice 
(fence-agents-epel) but then all the "missing" packages have the same 
name they would have if they were in RHEL or Fedora.  So in this case 
they would be


fence-agents-pve
fence-agents-raritan
fence-agents-rcd-serial
fence-agents-virsh

If you look at my attachment in my previous email I have them set that way.
Troy

On Wed, Aug 24, 2022 at 3:38 PM Alex Talaran > wrote:


i dont need them but wasnt sure if required for epel to keep things
complete and similar to the base package. how did you want me to change
the names? i left it the same as in the original spec file, and named
this one -epel after previous discussion on list

On 2022-08-24 17:13, Troy Dawson wrote:
 > I'm sure having all the fence agents in one package is nice for
you, but
 > if someone has both Fedora and RHEL based machines, they would
 > appreciate the packages having the same naming conventions.
 > This is looking pretty good.
 > I'll do some poking about for the man pages.  How badly do you
want the
 > man pages?
 >
 > Troy
 >
 >
 > On Tue, Aug 23, 2022 at 6:40 AM Alex Talaran mailto:atala...@gmail.com>
 > >> wrote:
 >
 >     attached a new spec using 4.10 which should match el9
(desired distro
 >     version) as you noted.
 >     srpm and rpm still seem to build fine without man pages,
still not sure
 >     how to generate them.
 >
 >     On 2022-08-08 17:22, Troy Dawson wrote:
 >      > Hi Alex,
 >      > I've been looking into this some.
 >      >
 >      > What distribution do you want this for?
 >      > I haven't seen anywhere in your emails saying if this is
for RHEL
 >     8 or
 >      > RHEL 9?
 >      > The spec file you have attached is for fence-agents-4.11,
which
 >     is only
 >      > in Fedora, so that doesn't let me know either.
 >      >
 >      > The major problem is that the fence-agents-pve version has to
 >     match the
 >      > fence-agents that is in your version of RHEL.
 >      > So for RHEL8 (or compatible) it needs to be version
4.2.1.  For
 >     RHEL 9
 >      > it needs to be 4.10.0
 >      >
 >      > We need to start with the correct version of fence-agents and
 >     work from
 >      > there.
 >      >
 >      > Troy
 >      >
 >      > On Wed, Jul 27, 2022 at 10:03 AM Alex Talaran
mailto:atala...@gmail.com>
 >     >
 >      > 
      >
 >      >     i was able to get this built and installable if anyone
wants
 >     to help
 >      >     test or maintain it.
 >      >     an issue exists with the man pages not being built
still but
 >     im not
 >      >     sure
 >      >     how the makefile target works for these so they are
excluded
 >     for now.
 >      >
 >      >     maybe some other small tweaks are still needed too
since its
 >     just a
 >      >     (first for me) stripped down and modified upstream
spec file.
 >      >
 >      >     On 2022-07-20 08:47, Andrew C Aitchison wrote:
 >      >      > On Wed, 20 Jul 2022, Alex Talaran wrote:
 >      >      >
 >      >      >> i ended up with the same error with that change.
 >      >      >
 >      >      > I am sorry my suggestion did not help.
 >      >      > I don't have a Red Hat compatible machine newer
that RHEL6
 >      >      > (I moved to Ubuntu for work-related reasons)
 >      >      > so I am unable to test things myself.
 >      >      >
 >      >      >> is it possible its getting confused because the
dirname
 >     in the
 >      >     tarball
 >      >      >> is different than the package name and looking in the
 >     wrong spot?
 >      >      >
 >      >      > The -n fence-agents-%{version} in
 >      >      >  %prep
 >      >      >  %setup -q -n fence-agents-%{version}
 >      >      > is supposed to resolve that, but that setup line might
 >     need tweaking
 >      >      > to match the contents of the tarball.
 >      >      >
 >      >      > It is old and may be somewhat dated, but my bible for
 >     rewriting
 >      >     .spec
 >      >      > files was the book
 >      > 

[EPEL-devel] Re: [new / help wanted] fence-agents-epel package

[Troy Dawson]

For the names, the source rpm needs to have the -epel suffice
(fence-agents-epel) but then all the "missing" packages have the same name
they would have if they were in RHEL or Fedora.  So in this case they would
be

fence-agents-pve
fence-agents-raritan
fence-agents-rcd-serial
fence-agents-virsh

If you look at my attachment in my previous email I have them set that way.
Troy

On Wed, Aug 24, 2022 at 3:38 PM Alex Talaran  wrote:

> i dont need them but wasnt sure if required for epel to keep things
> complete and similar to the base package. how did you want me to change
> the names? i left it the same as in the original spec file, and named
> this one -epel after previous discussion on list
>
> On 2022-08-24 17:13, Troy Dawson wrote:
> > I'm sure having all the fence agents in one package is nice for you, but
> > if someone has both Fedora and RHEL based machines, they would
> > appreciate the packages having the same naming conventions.
> > This is looking pretty good.
> > I'll do some poking about for the man pages.  How badly do you want the
> > man pages?
> >
> > Troy
> >
> >
> > On Tue, Aug 23, 2022 at 6:40 AM Alex Talaran  > > wrote:
> >
> > attached a new spec using 4.10 which should match el9 (desired distro
> > version) as you noted.
> > srpm and rpm still seem to build fine without man pages, still not
> sure
> > how to generate them.
> >
> > On 2022-08-08 17:22, Troy Dawson wrote:
> >  > Hi Alex,
> >  > I've been looking into this some.
> >  >
> >  > What distribution do you want this for?
> >  > I haven't seen anywhere in your emails saying if this is for RHEL
> > 8 or
> >  > RHEL 9?
> >  > The spec file you have attached is for fence-agents-4.11, which
> > is only
> >  > in Fedora, so that doesn't let me know either.
> >  >
> >  > The major problem is that the fence-agents-pve version has to
> > match the
> >  > fence-agents that is in your version of RHEL.
> >  > So for RHEL8 (or compatible) it needs to be version 4.2.1.  For
> > RHEL 9
> >  > it needs to be 4.10.0
> >  >
> >  > We need to start with the correct version of fence-agents and
> > work from
> >  > there.
> >  >
> >  > Troy
> >  >
> >  > On Wed, Jul 27, 2022 at 10:03 AM Alex Talaran  > 
> >  > >> wrote:
> >  >
> >  > i was able to get this built and installable if anyone wants
> > to help
> >  > test or maintain it.
> >  > an issue exists with the man pages not being built still but
> > im not
> >  > sure
> >  > how the makefile target works for these so they are excluded
> > for now.
> >  >
> >  > maybe some other small tweaks are still needed too since its
> > just a
> >  > (first for me) stripped down and modified upstream spec file.
> >  >
> >  > On 2022-07-20 08:47, Andrew C Aitchison wrote:
> >  >  > On Wed, 20 Jul 2022, Alex Talaran wrote:
> >  >  >
> >  >  >> i ended up with the same error with that change.
> >  >  >
> >  >  > I am sorry my suggestion did not help.
> >  >  > I don't have a Red Hat compatible machine newer that RHEL6
> >  >  > (I moved to Ubuntu for work-related reasons)
> >  >  > so I am unable to test things myself.
> >  >  >
> >  >  >> is it possible its getting confused because the dirname
> > in the
> >  > tarball
> >  >  >> is different than the package name and looking in the
> > wrong spot?
> >  >  >
> >  >  > The -n fence-agents-%{version} in
> >  >  >  %prep
> >  >  >  %setup -q -n fence-agents-%{version}
> >  >  > is supposed to resolve that, but that setup line might
> > need tweaking
> >  >  > to match the contents of the tarball.
> >  >  >
> >  >  > It is old and may be somewhat dated, but my bible for
> > rewriting
> >  > .spec
> >  >  > files was the book
> >  >  > Maximum RPM - Taking the Red Hat Package Manager to
> > the Limit
> >  >  > a version of which is available at
> >  >  > http://ftp.rpm.org/max-rpm/index.html
> > 
> >  >  > >
> >  >  >
> >  >  >> On 2022-07-19 23:32, Andrew C Aitchison wrote:
> >  >  >>> On Tue, 19 Jul 2022, Alex Talaran wrote:
> >  >  >>>
> >  >   per a previous thread i took a shot at cleaning up the
> >  > fence-agents
> >  >   rpm to only include the missing agents and make a new
> > package.
> >  > i am
> >  >   having some issues with the source url and getting it to
> >  > 

Re: Retiring: python-sendgrid

[Fabio Valentini]

On Thu, Aug 25, 2022 at 2:49 PM Chris Adams  wrote:
>
> Once upon a time, Ali Erdinc Koroglu  said:
> > Dear maintainers,
> > Python-sendgrid [1] will be retiring after F37, because since v6.4.1
> > it depends to starkbank-ecdsa [2] which we can't add to Fedora
> > due to secp256k1 elliptic curve support.
>
> What's wrong with secp256k1?  Fedora already has libsecp256k1, so it
> doesn't appear that curve is blocked.

I seem to remember that there was a Fedora Legal Wiki page that listed
the elliptic curves that Fedora was not allowed to ship, but I can't
find it anywhere, so maybe it fell victim to the move to GitLab and
Fedora Docs (as did some other useful docs ...).

But secp256k1 in particular seems to be OK, it is shipped by both
nettle and OpenSSL:

$ openssl ecparam -list_curves
  secp224r1 : NIST/SECG curve over a 224 bit prime field
  secp256k1 : SECG curve over a 256 bit prime field
  secp384r1 : NIST/SECG curve over a 384 bit prime field
  secp521r1 : NIST/SECG curve over a 521 bit prime field
  prime256v1: X9.62/SECG curve over a 256 bit prime field

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

Fedora 37 compose report: 20220825.n.0 changes

[Fedora Rawhide Report]

OLD: Fedora-37-20220824.n.2
NEW: Fedora-37-20220825.n.0

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

Size of added packages:  0 B
Size of dropped packages:103.46 KiB
Size of upgraded packages:   0 B
Size of downgraded packages: 0 B

Size change of upgraded packages:   0 B
Size change of downgraded packages: 0 B

= ADDED IMAGES =
Image: Container_Base docker aarch64
Path: 
Container/aarch64/images/Fedora-Container-Base-37-20220825.n.0.aarch64.tar.xz

= DROPPED IMAGES =

= ADDED PACKAGES =

= DROPPED PACKAGES =
Package: python-sphinx-panels-0.6.0-3.fc37
Summary: Sphinx extension for creating panels in a grid layout
RPMs:python3-sphinx-panels
Size:103.46 KiB


= UPGRADED PACKAGES =

= DOWNGRADED PACKAGES =
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an 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

Check out the Fedora Packager Dashboard!

[Miro Hrončok]

Hello folks,

this is just a reminder that there is a Fedora Packager Dashboard that you 
might not know about:


Go to https://packager-dashboard.fedoraproject.org/

Enter your FAS username, (sit down and relax for a while if coming for the 
first time) and enjoy aggregated information about your Fedora and EPEL 
packages from:


 - Bugzilla
 - Bodhi
 - ABRT
 - Koschei
 - src.fedoraproject.org PRs
 - orphans reports
 - non-installability reports
 - Fedora release schedule
 - Package calendars (currently GNOME and Python, but extensible)
 - and possibly more in the future

With various filtering options.

Also works for FAS groups or custom views of multiple users that can be used 
for triages, e.g.:


https://packager-dashboard.fedoraproject.org/dashboard?users=churchyard,pviktori,cstratak,torsava,lbalhar,thrnciar,ksurma,vstinner

See the help page for more:

https://packager-dashboard.fedoraproject.org/helpmepls

--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
___
devel-announce mailing list -- devel-announce@lists.fedoraproject.org
To unsubscribe send an email to devel-announce-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.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-announce@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Security Problem with "PackageKit-command-not-found" package

[Sandipan Roy]

Some CVEs are appeared because of this issue,
Details + Analysis found at:
https://sysdream.com/abusing-packagekit-fedora-centos-for/
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an 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: Retiring: python-sendgrid

[Chris Adams]

Once upon a time, Ali Erdinc Koroglu  said:
> Dear maintainers,
> Python-sendgrid [1] will be retiring after F37, because since v6.4.1
> it depends to starkbank-ecdsa [2] which we can't add to Fedora
> due to secp256k1 elliptic curve support.

What's wrong with secp256k1?  Fedora already has libsecp256k1, so it
doesn't appear that curve is blocked.

-- 
Chris Adams 
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an 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: Retiring: python-sendgrid

[Miro Hrončok]

On 25. 08. 22 14:42, Ali Erdinc Koroglu wrote:

Dear maintainers,
Python-sendgrid [1] will be retiring after F37, because since v6.4.1 it depends 
to starkbank-ecdsa [2] which we can't add to Fedora

due to secp256k1 elliptic curve support.


Clarification: We don't *know* if we can include it :(

https://lists.fedoraproject.org/archives/list/le...@lists.fedoraproject.org/thread/IQELSXUUNQFYYQ2JU3NOWLF2TOI7DEYZ/

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

Retiring: python-sendgrid

[Ali Erdinc Koroglu]

Dear maintainers,
Python-sendgrid [1] will be retiring after F37, because since v6.4.1 it 
depends to starkbank-ecdsa [2] which we can't add to Fedora

due to secp256k1 elliptic curve support.

1 : https://github.com/sendgrid/sendgrid-python
2 : https://github.com/starkbank/ecdsa-python

BR,
Ali
-
Intel Finland Oy
Registered Address: PL 281, 00181 Helsinki 
Business Identity Code: 0357606 - 4 
Domiciled in Helsinki 


This e-mail and any attachments may contain confidential material for
the sole use of the intended recipient(s). Any review or distribution
by others is strictly prohibited. If you are not the intended
recipient, please contact the sender and delete all copies.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an 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: Security Problem with "PackageKit-command-not-found" package

[Sandipan Roy]

Wheel user rule for packagekit

$ sudo cat /usr/share/polkit-1/rules.d/org.freedesktop.packagekit.rules
[sudo] password for sandipan: 
polkit.addRule(function(action, subject) {
if ((action.id == "org.freedesktop.packagekit.package-install" ||
 action.id == "org.freedesktop.packagekit.package-remove") &&
subject.active == true && subject.local == true &&
subject.isInGroup("wheel")) {
return polkit.Result.YES;
}
});
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an 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

Security Problem with "PackageKit-command-not-found" package

[Sandipan Roy]

Hello World,

I'm Sandipan Roy [FAS: ByteHackr], I wanted to share a serious system wide 
problem with PackageKit-command-not-found [1] package. 
Can you guys give some feedback if I can submit a system wide change proposal 
to remove this because its a poor system design.
By this vulnerability any wheel user can install any packages without root 
access or sudo.

Reproducer: 

Open up any bash terminal. Type in the name of a package that doesn't installed 
already (eg. nemo, irssi), I can reproduce in F36-KDE.
In workstation not reproducible.

Analysis:

$ rpm -qf /etc/profile.d/PackageKit.sh
PackageKit-command-not-found-1.2.5-1.fc36.x86_64

$ rpm -ql PackageKit-command-not-found-1.2.5-1.fc36.x86_64
/etc/PackageKit/CommandNotFound.conf
/etc/profile.d/PackageKit.sh
/usr/lib/.build-id
/usr/lib/.build-id/86
/usr/lib/.build-id/86/7d08bc388e2cd2dbb8523e0a4662e19045bf4d
/usr/libexec/pk-command-not-found

$ which command_not_found_handle
command_not_found_handle ()
{ 
local runcnf=1;
local retval=127;
[[ $- == *"i"* ]] || runcnf=0;
[[ ! -S /run/dbus/system_bus_socket ]] && runcnf=0;
[[ ! -x '/usr/libexec/packagekitd' ]] && runcnf=0;
[[ -n ${COMP_CWORD-} ]] && runcnf=0;
[[ ! -x '/usr/libexec/pk-command-not-found' ]] && runcnf=0;
if [ $runcnf -eq 1 ]; then
'/usr/libexec/pk-command-not-found' "$@";
retval=$?;
else
if [[ -n "${BASH_VERSION-}" ]]; then
printf 'bash: %s%s\n' "${1:+$1: }" "$(gettext PackageKit 'command 
not found')" 1>&2;
fi;
fi;
return $retval
}

[1] 
https://fedoraproject.org/wiki/Features/PackageKitCommandNotFound#PackageKit_Command_Not_Found


Thanks,
Sandipan Roy
Associate Product Security Engineer
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an 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

Packages silently dropping approved changes

[Iñaki Ucar]

Hi all,

Many of you know that proposing, discussing, and implementing a change
proposal is quite an effort, especially if you do this in your spare
time. I did this some releases ago in [1] to try to improve the
situation regarding BLAS/LAPACK management in Fedora. It wasn't easy,
but it was a success, and now we have specific packaging guidelines
[2] and one of the best BLAS/LAPACK stacks out there IMHO.

Given that this is not so common, I routinely (every now and then, not
very often) check for new packages that may not be aware of this
guideline, so that they may need adaptation. What I didn't expect was
to find already adapted packages silently dropping this change, and
going back to linking specific libraries instead of FlexiBLAS. :(

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.

I opened the corresponding BZ [3-4], but it would be great if these
checks and BZ could be automated somewhere. If so, please let me know
where the proper place for this is and I'll open an issue.

[1] https://fedoraproject.org/wiki/Changes/FlexiBLAS_as_BLAS/LAPACK_manager
[2] https://docs.fedoraproject.org/en-US/packaging-guidelines/BLAS_LAPACK/
[3] https://bugzilla.redhat.com/show_bug.cgi?id=2121388
[4] https://bugzilla.redhat.com/show_bug.cgi?id=2121389

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

Fedora rawhide compose report: 20220825.n.0 changes

[Fedora Rawhide Report]

OLD: Fedora-Rawhide-20220824.n.0
NEW: Fedora-Rawhide-20220825.n.0

= SUMMARY =
Added images:6
Dropped images:  0
Added packages:  35
Dropped packages:1
Upgraded packages:   71
Downgraded packages: 0

Size of added packages:  334.55 MiB
Size of dropped packages:111.89 KiB
Size of upgraded packages:   5.62 GiB
Size of downgraded packages: 0 B

Size change of upgraded packages:   3.34 MiB
Size change of downgraded packages: 0 B

= ADDED IMAGES =
Image: Silverblue dvd-ostree aarch64
Path: 
Silverblue/aarch64/iso/Fedora-Silverblue-ostree-aarch64-Rawhide-20220825.n.0.iso
Image: Silverblue dvd-ostree x86_64
Path: 
Silverblue/x86_64/iso/Fedora-Silverblue-ostree-x86_64-Rawhide-20220825.n.0.iso
Image: Kinoite dvd-ostree ppc64le
Path: Kinoite/ppc64le/iso/Fedora-Kinoite-ostree-ppc64le-Rawhide-20220825.n.0.iso
Image: Kinoite dvd-ostree x86_64
Path: Kinoite/x86_64/iso/Fedora-Kinoite-ostree-x86_64-Rawhide-20220825.n.0.iso
Image: Kinoite dvd-ostree aarch64
Path: Kinoite/aarch64/iso/Fedora-Kinoite-ostree-aarch64-Rawhide-20220825.n.0.iso
Image: Silverblue dvd-ostree ppc64le
Path: 
Silverblue/ppc64le/iso/Fedora-Silverblue-ostree-ppc64le-Rawhide-20220825.n.0.iso

= DROPPED IMAGES =

= ADDED PACKAGES =
Package: perl-Clone-0.45-9.module_f38+15215+1523eae4
Summary: Recursively copy perl data types
RPMs:perl-Clone
Size:88.65 KiB

Package: perl-DBD-MySQL-4.050-13.module_f38+15175+af2365e9
Summary: A MySQL interface for Perl
RPMs:perl-DBD-MySQL
Size:1.14 MiB

Package: perl-DBD-Pg-3.16.0-1.module_f38+15198+ceb45b9a
Summary: A PostgreSQL interface for Perl
RPMs:perl-DBD-Pg
Size:1.73 MiB

Package: perl-DBD-SQLite-1.70-5.module_f38+15190+426d2bcb
Summary: SQLite DBI Driver
RPMs:perl-DBD-SQLite
Size:1.55 MiB

Package: perl-DBI-1.643-11.module_f38+15134+b58b8fa9
Summary: A database access API for perl
RPMs:perl-DBI
Size:5.48 MiB

Package: perl-Data-Dump-1.25-5.module_f38+15215+1523eae4
Summary: Pretty printing of data structures
RPMs:perl-Data-Dump
Size:33.64 KiB

Package: perl-Digest-HMAC-1.04-6.module_f38+15215+1523eae4
Summary: Keyed-Hashing for Message Authentication
RPMs:perl-Digest-HMAC perl-Digest-HMAC-tests
Size:35.61 KiB

Package: perl-Encode-Locale-1.05-24.module_f38+15215+1523eae4
Summary: Determine the locale encoding
RPMs:perl-Encode-Locale
Size:18.92 KiB

Package: perl-File-Listing-6.15-3.module_f38+15215+1523eae4
Summary: Parse directory listing
RPMs:perl-File-Listing perl-File-Listing-tests
Size:58.57 KiB

Package: perl-HTML-Parser-3.78-3.module_f38+15215+1523eae4
Summary: Perl module for parsing HTML
RPMs:perl-HTML-Parser
Size:482.11 KiB

Package: perl-HTML-Tagset-3.20-52.module_f38+15215+1523eae4
Summary: HTML::Tagset - data tables useful in parsing HTML
RPMs:perl-HTML-Tagset
Size:18.61 KiB

Package: perl-HTTP-Cookies-6.10-7.module_f38+15215+1523eae4
Summary: HTTP cookie jars
RPMs:perl-HTTP-Cookies
Size:37.67 KiB

Package: perl-HTTP-Date-6.05-10.module_f38+15215+1523eae4
Summary: Date conversion routines
RPMs:perl-HTTP-Date
Size:23.90 KiB

Package: perl-HTTP-Message-6.37-1.module_f38+15215+1523eae4
Summary: HTTP style message
RPMs:perl-HTTP-Message
Size:97.32 KiB

Package: perl-HTTP-Negotiate-6.01-33.module_f38+15215+1523eae4
Summary: Choose a variant to serve
RPMs:perl-HTTP-Negotiate
Size:19.77 KiB

Package: perl-IO-HTML-1.004-7.module_f38+15215+1523eae4
Summary: Open an HTML file with automatic character set detection
RPMs:perl-IO-HTML
Size:27.93 KiB

Package: perl-IO-Socket-SSL-2.074-2.module_f38+15150+6af675f5
Summary: Perl library for transparent SSL
RPMs:perl-IO-Socket-SSL
Size:436.45 KiB

Package: perl-LWP-MediaTypes-6.04-12.module_f38+15215+1523eae4
Summary: Guess media type for a file or a URL
RPMs:perl-LWP-MediaTypes
Size:33.17 KiB

Package: perl-LWP-Protocol-https-6.10-7.module_f38+15215+1523eae4
Summary: Provide HTTPS support for LWP::UserAgent
RPMs:perl-LWP-Protocol-https
Size:21.31 KiB

Package: perl-Mozilla-CA-20211001-4.module_f38+15215+1523eae4
Summary: Mozilla's CA certificate bundle in PEM format
RPMs:perl-Mozilla-CA
Size:12.39 KiB

Package: perl-NTLM-1.09-33.module_f38+15215+1523eae4
Summary: NTLM Perl module
RPMs:perl-NTLM
Size:21.96 KiB

Package: perl-Net-HTTP-6.22-3.module_f38+15215+1523eae4
Summary: Low-level HTTP connection (client)
RPMs:perl-Net-HTTP
Size:40.16 KiB

Package: perl-Net-SSLeay-1.92-2.module_f38+15150+2fb78af2
Summary: Perl extension for using OpenSSL
RPMs:perl-Net-SSLeay
Size:2.77 MiB

Package: perl-TimeDate-1:2.33-9.module_f38+15215+1523eae4
Summary: A Perl module for time and date manipulation
RPMs:perl-TimeDate
Size:50.90 KiB

Package: perl-Try-Tiny-0.31-4.module_f38+15215+1523eae4
Summary: Minimal try/catch with proper localization of $@
RPMs:perl-Try-Tiny
Size:37.68 KiB

Package: perl-WWW-RobotRules-6.02-33.module_f38

Re: Check out the Fedora Packager Dashboard!

[Artur Frenszek-Iwicki]

> Sounds like you need to clear your browser cache or something
Yeah, looks like it. I refreshed the page via F5 and it didn't help.
Doing a full page reload via Ctrl+R helped.

> According to your description, your browser might be broken,
> perhaps due to some content blocking?
> See this screenshot, there are symbolic icons everywhere
The icons are loaded from fontawesome's domain,
not fedoraproject's, which made NoScript block them.

So oops, I done goofed. But hey, at least I got
to see the improvements immediately! :-)

A.FI.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an 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: Check out the Fedora Packager Dashboard!

[Fabio Valentini]

On Thu, Aug 25, 2022 at 11:43 AM Artur Frenszek-Iwicki
 wrote:
>
> While I really like the idea, I find the interface to be... how do I put it?
> Non-obvious and not very discoverable.
>
> For example, at the top of the page, there's a bunch of numbers. I have no 
> idea what they mean.
> Hovering over each of these displays a tooltip - which is nice - but five 
> seconds after that tooltip disappears,
> I'll forget the meaning and the numbers will go back to being visual clutter. 
> It would be immensely helpful
> to have some symbolic icons next to the numbers, which would allow to easily 
> guess what each of them means.
> Right now I pretty much have to memorize the layout.

Sounds like you need to clear your browser cache or something, because
there *are* symbols next to these numbers:
https://decathorpe.fedorapeople.org/packager-dashboard.png

> The same goes for the comment/karma numbers and priority markings on the list 
> of bugs.
> Although here it's actually a bit worse, since my browser doesn't display the 
> tooltips
> and I had to use the dev tools to take a look at the underlying HTML to make 
> sense of it.
>
> Similarly, at the top of the page, I get a banner that informs me about FAS 
> integration and says:
> > After linking the dashboard with your FAS through the settings menu...
> Which is all nice and dandy, but doing a Ctrl+F on the page for "settings" 
> gives exactly one match -
> that being the text in the banner. So there's no visible link to said 
> "settings menu" anywhere.
> How do I access it?

The big "gear" icon (the almost universal symbol for "Settings") in
the top panel should be what you're looking for.

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: Check out the Fedora Packager Dashboard!

[Iñaki Ucar]

On Thu, 25 Aug 2022 at 11:49, Artur Frenszek-Iwicki
 wrote:
>
> While I really like the idea, I find the interface to be... how do I put it?
> Non-obvious and not very discoverable.
>
> For example, at the top of the page, there's a bunch of numbers. I have no 
> idea what they mean.
> Hovering over each of these displays a tooltip - which is nice - but five 
> seconds after that tooltip disappears,
> I'll forget the meaning and the numbers will go back to being visual clutter. 
> It would be immensely helpful
> to have some symbolic icons next to the numbers, which would allow to easily 
> guess what each of them means.
> Right now I pretty much have to memorize the layout.

Which browser are you using? There *are* icons, and the tooltips do
not disappear for me.

Iñaki

>
> The same goes for the comment/karma numbers and priority markings on the list 
> of bugs.
> Although here it's actually a bit worse, since my browser doesn't display the 
> tooltips
> and I had to use the dev tools to take a look at the underlying HTML to make 
> sense of it.
>
> Similarly, at the top of the page, I get a banner that informs me about FAS 
> integration and says:
> > After linking the dashboard with your FAS through the settings menu...
> Which is all nice and dandy, but doing a Ctrl+F on the page for "settings" 
> gives exactly one match -
> that being the text in the banner. So there's no visible link to said 
> "settings menu" anywhere.
> How do I access it?
>
> All in all, while this is a very useful project, the current UI makes it hard 
> to make the best of it.
>
> A.FI.
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an 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
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an 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: Check out the Fedora Packager Dashboard!

[Kamil Paral]

On Thu, Aug 25, 2022 at 11:43 AM Artur Frenszek-Iwicki <
s...@fedoraproject.org> wrote:

> For example, at the top of the page, there's a bunch of numbers. I have no
> idea what they mean.
> Hovering over each of these displays a tooltip - which is nice - but five
> seconds after that tooltip disappears,
> I'll forget the meaning and the numbers will go back to being visual
> clutter. It would be immensely helpful
> to have some symbolic icons next to the numbers, which would allow to
> easily guess what each of them means.
>

According to your description, your browser might be broken, perhaps due to
some content blocking?
See this screenshot, there are symbolic icons everywhere, there's a
Settings cog in upper right, etc:
https://i.imgur.com/gFKDUT2.png

File a bug, if the missing icons are not caused by your customized browser
configuration.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an 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: Check out the Fedora Packager Dashboard!

[Artur Frenszek-Iwicki]

While I really like the idea, I find the interface to be... how do I put it?
Non-obvious and not very discoverable.

For example, at the top of the page, there's a bunch of numbers. I have no idea 
what they mean.
Hovering over each of these displays a tooltip - which is nice - but five 
seconds after that tooltip disappears,
I'll forget the meaning and the numbers will go back to being visual clutter. 
It would be immensely helpful
to have some symbolic icons next to the numbers, which would allow to easily 
guess what each of them means.
Right now I pretty much have to memorize the layout.

The same goes for the comment/karma numbers and priority markings on the list 
of bugs.
Although here it's actually a bit worse, since my browser doesn't display the 
tooltips
and I had to use the dev tools to take a look at the underlying HTML to make 
sense of it.

Similarly, at the top of the page, I get a banner that informs me about FAS 
integration and says:
> After linking the dashboard with your FAS through the settings menu...
Which is all nice and dandy, but doing a Ctrl+F on the page for "settings" 
gives exactly one match -
that being the text in the banner. So there's no visible link to said "settings 
menu" anywhere.
How do I access it?

All in all, while this is a very useful project, the current UI makes it hard 
to make the best of it.

A.FI.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an 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: [Dev] Check out the Fedora Packager Dashboard!

[Miro Hrončok]

On 25. 08. 22 11:14, Gerd Hoffmann wrote:

   Hi,


With various filtering options.


Is it also possible to sort packages?  For example to have my own
packages listed first and any group packages later?


The current sorting options are:

 - Package name
 - Issue count
 - FTI, FTBFS and orphans first
 - Packages with the most recent item first

If you wan more options, file an RFE ticket at
https://pagure.io/fedora-qa/packager_dashboard/issues

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

Re: [Dev] Check out the Fedora Packager Dashboard!

[Gerd Hoffmann]

  Hi,

> With various filtering options.

Is it also possible to sort packages?  For example to have my own
packages listed first and any group packages later?

take care,
  Gerd
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an 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

Check out the Fedora Packager Dashboard!

[Miro Hrončok]

Hello folks,

this is just a reminder that there is a Fedora Packager Dashboard that you 
might not know about:


Go to https://packager-dashboard.fedoraproject.org/

Enter your FAS username, (sit down and relax for a while if coming for the 
first time) and enjoy aggregated information about your Fedora and EPEL 
packages from:


 - Bugzilla
 - Bodhi
 - ABRT
 - Koschei
 - src.fedoraproject.org PRs
 - orphans reports
 - non-installability reports
 - Fedora release schedule
 - Package calendars (currently GNOME and Python, but extensible)
 - and possibly more in the future

With various filtering options.

Also works for FAS groups or custom views of multiple users that can be used 
for triages, e.g.:


https://packager-dashboard.fedoraproject.org/dashboard?users=churchyard,pviktori,cstratak,torsava,lbalhar,thrnciar,ksurma,vstinner

See the help page for more:

https://packager-dashboard.fedoraproject.org/helpmepls

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

Re: Users with commit rights in src.fp.o but no more in packager group

[Alexander Bokovoy]

On to, 25 elo 2022, Miro Hrončok wrote:

On 24. 08. 22 22:53, Alasdair G Kergon wrote:

On Wed, Aug 24, 2022 at 09:50:59PM +0200, Fabio Valentini wrote:

I think some of those *-team / *-sig / *-maint pseudo-group users are
outdated. Most of them probably pre-date the existence of actual
groups, so they are probably all ancient. For example, we removed the
xgl-maint pseudo-group a while ago, because it was actually unused,
and its associated bugzilla account was disabled.
I wonder for how many of these groups the same is true, and whether we
should actually remove them from all packages where that's the case.

lvm-team is still in use as a package owner and default bugzilla
assignee.  To do anything of any significance using the account, we were
instructed to open a ticket to ask for the change to be made for us.

It has never been a member of the packager group because it was
decided that accounts that are not individuals cannot sign the
legal agreement that is a pre-requisite to being able to join that
group.


We use the python-maint pseudo-account to be the default Bugzilla 
assignee for Pythons, e.g. 
https://src.fedoraproject.org/rpms/python3.11


Note that it does *not* require the account to be listed in 
maintainers or to have commit rights.


Same for ipa-maint account.

--
/ Alexander Bokovoy
Sr. Principal Software Engineer
Security / Identity Management Engineering
Red Hat Limited, Finland
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an 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

Let's enable Koschei for all packages automatically

[Miro Hrončok]

Hello folks,

during our Nest FESCo session, we've talked about enabling Koschei [1] for all 
packages automatically.


There seem to be a consensus by FESCo members, that it would be a good thing.

What would it take?

1) Koji resources

I think we can try to enable this and see if it burns. I think ti won't.


2) One-time enablement of all existing packages

That should be doable. Right?


3) Automatic enablement of all new packages

That should be just a matter of changing the defaults. Correct?


Can we do this? How can I help?


[1] https://fedoraproject.org/wiki/Koschei
--
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, report it: 
https://pagure.io/fedora-infrastructure/new_issue

[Bug 2116479] perl-Alien-pkgconf-0.18 is available

[bugzilla]

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

Fedora Update System  changed:

   What|Removed |Added

   Fixed In Version|perl-Alien-pkgconf-0.18-1.f |perl-Alien-pkgconf-0.18-1.f
   |c38 |c38
   |perl-Alien-pkgconf-0.18-1.f |perl-Alien-pkgconf-0.18-1.f
   |c36 |c36
   ||perl-Alien-pkgconf-0.18-1.f
   ||c35



--- Comment #7 from Fedora Update System  ---
FEDORA-2022-7c7be9285d has been pushed to the Fedora 35 stable repository.
If problem still persists, please make note of it in this bug report.


-- 
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=2116479
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

[Bug 2116587] perl-Bencode-1.502 is available

[bugzilla]

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

Fedora Update System  changed:

   What|Removed |Added

   Fixed In Version|perl-Bencode-1.502-1.fc38   |perl-Bencode-1.502-1.fc38
   |perl-Bencode-1.502-1.fc36   |perl-Bencode-1.502-1.fc36
   ||perl-Bencode-1.502-1.fc35



--- Comment #13 from Fedora Update System  ---
FEDORA-2022-a1febc45d3 has been pushed to the Fedora 35 stable repository.
If problem still persists, please make note of it in this bug report.


-- 
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=2116587
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

[Bug 2116190] perl-DateTimeX-Easy-0.090 is available

[bugzilla]

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

Fedora Update System  changed:

   What|Removed |Added

   Fixed In Version|perl-DateTimeX-Easy-0.090-1 |perl-DateTimeX-Easy-0.090-1
   |.fc38   |.fc38
   |perl-DateTimeX-Easy-0.090-1 |perl-DateTimeX-Easy-0.090-1
   |.fc36   |.fc36
   |perl-DateTimeX-Easy-0.090-1 |perl-DateTimeX-Easy-0.090-1
   |.el8|.el8
   |perl-DateTimeX-Easy-0.090-1 |perl-DateTimeX-Easy-0.090-1
   |.el7|.el7
   ||perl-DateTimeX-Easy-0.090-1
   ||.fc35



--- Comment #14 from Fedora Update System  ---
FEDORA-2022-385dd3d5e4 has been pushed to the Fedora 35 stable repository.
If problem still persists, please make note of it in this bug report.


-- 
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=2116190
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

[Bug 2118082] perl-DateTime-TimeZone-2.53 is available

[bugzilla]

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

Fedora Update System  changed:

   What|Removed |Added

   Fixed In Version|perl-DateTime-TimeZone-2.53 |perl-DateTime-TimeZone-2.53
   |-1.fc38 |-1.fc38
   |perl-DateTime-TimeZone-2.53 |perl-DateTime-TimeZone-2.53
   |-1.fc37 |-1.fc37
   |perl-DateTime-TimeZone-2.53 |perl-DateTime-TimeZone-2.53
   |-1.fc36 |-1.fc36
   ||perl-DateTime-TimeZone-2.53
   ||-1.fc35



--- Comment #6 from Fedora Update System  ---
FEDORA-2022-fe3af9cc3f has been pushed to the Fedora 35 stable repository.
If problem still persists, please make note of it in this bug report.


-- 
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=2118082
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Planning to start unifying native and mingw packages

[Sandro Mani]

On 25.08.22 08:33, Marián Konček wrote:
I noticed this thread, I develop a personal project where I use about 
10 C libraries, I noticed that "glfw", "libsodium" and "libevent" do 
not have their corresponding mingw packages. I was considering trying 
to package them but unifying them with the native packages would be 
better. Of course, this would put more pressure on the maintainers.


I could however open a PR to add them to the native packages. Do we 
have some libraries where this unification is already finished so that 
I could take inspiration?


Yes, quite a few actually, to list the ones I adapted:

eigen3
enchant2
freeimage
gdal
GeographicLib
geos
giflib
gtkspell3
gtkspellmm30
jxrlib
leptonica
libgeotiff
libimagequant
libkml
librttopo
libspatialite
libwebp
openjpeg2
OpenSceneGraph
osgearth
podofo
proj
python-pillow
qtspell
shapelib
svg2svgt
tesseract
uriparser

Sandro

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an 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: Planning to start unifying native and mingw packages

[Marián Konček]

I noticed this thread, I develop a personal project where I use about 10 
C libraries, I noticed that "glfw", "libsodium" and "libevent" do not 
have their corresponding mingw packages. I was considering trying to 
package them but unifying them with the native packages would be better. 
Of course, this would put more pressure on the maintainers.


I could however open a PR to add them to the native packages. Do we have 
some libraries where this unification is already finished so that I 
could take inspiration?


On 24. 8. 2022 16:00, Daniel P. Berrangé wrote:

On Wed, Aug 24, 2022 at 03:57:37PM +0200, Fabio Valentini wrote:

On Wed, Aug 24, 2022 at 3:49 PM Daniel P. Berrangé  wrote:

On Sun, Feb 20, 2022 at 10:13:18PM +0100, Sandro Mani wrote:

Hi

Following recent discussions and to reduce the maintenance burden, I'm
planning to start merging native and mingw packages. Initially, I'll be
looking at these packages where I maintain both variants:

I've done the same with all the mingw packages I maintained just
before Fedora 37 branched. So the following native packages now
just contain mingw sub-RPMs:

  libvirt, libvirt-glib, libosinfo, osinfo-db, osinfo-db-tools, gtk-vnc

I'm so happy to have reduced this maint burden. I see a few new mingw
packages pending in package review and think it'd be nice to first ask
the native maintainer to consider unified package, before we approve
any new separate mingw packages.

Our Mingw packaging guidelines, however, exclusively describe fully
separated mingw packages.  So if I suggest this to a native package
maintainer who is not already familiar with mingw, they would be
right to question whether this is a desirable thing.

IOW, I think we need to look at getting the mingw packaging docs
updated to promote unified packaging as an officially supported
(and even preferred) option, alongside separate packaging.

Sounds great.
The Packaging Committee is looking forward to your PR ;)

I don't want to rush into doing that myself in case someone else reading
along is very enthusiastic to do the work themselves ;-P

With regards,
Daniel


--
Marián Konček
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an 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