[EPEL-devel] Fedora EPEL 7 updates-testing report

[updates]

The following Fedora EPEL 7 Security updates need testing:
 Age  URL
   3  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2023-d2e65a75f1   
wordpress-5.1.17-1.el7


The following builds have been pushed to Fedora EPEL 7 updates-testing

netdata-1.43.0-1.el7

Details about builds:



 netdata-1.43.0-1.el7 (FEDORA-EPEL-2023-460444dc01)
 Real-time performance monitoring

Update Information:

Update to upstream release 1.43.0

ChangeLog:

* Tue Oct 17 2023 Didier Fabert  1.43.0-1
- Update from upstream


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

Re: F40 Change Proposal: F40 MariaDB MySQL repackaging (Self-Contained)

[pgnd]

i understand the release-it-from-distro argument, but my $0.02,

MDB @ Fedora has version-lagged for so long, with no response to requests to 
update, either official distro, or modules, that I switched to upstream.

  https://mariadb.com/kb/en/mariadb-package-repository-setup-and-usage/
  https://mariadb.com/kb/en/yum/#installing-mariadb-packages-with-yum

with,

 cat mariadb.repo
  [mariadb]
  enabled=1
  name = MariaDB
  baseurl = 
https://ftp.osuosl.org/pub/mariadb/yum/10.11/fedora/$releasever/$basearch
  gpgkey=https://ftp.osuosl.org/pub/mariadb/yum/RPM-GPG-KEY-MariaDB
  gpgcheck=1
 
sure, it has its occasional problems.  but it gets timely support from upstream devs, and a very large active community


 rpm -qa | grep -i  maria | sort
  MariaDB-backup-10.11.5-1.fc38.x86_64
  MariaDB-client-10.11.5-1.fc38.x86_64
  MariaDB-common-10.11.5-1.fc38.x86_64
  MariaDB-cracklib-password-check-10.11.5-1.fc38.x86_64
  MariaDB-gssapi-server-10.11.5-1.fc38.x86_64
  mariadb-java-client-3.1.2-1.fc38.noarch
  MariaDB-server-10.11.5-1.fc38.x86_64
  MariaDB-shared-10.11.5-1.fc38.x86_64
  perl-DBD-MariaDB-1.22-4.fc38.x86_64

 Original Message 
From: devel@lists.fedoraproject.org
Sent:  at Thursday, Oct 19, 2023, 19:11 PM EDT
To: devel@lists.fedoraproject.org Cc: kevin.kof...@chello.at
Subject: Re: F40 Change Proposal: F40 MariaDB MySQL repackaging (Self-Contained)


* Rename package 'community-mysql' to 'mysql' and Stop providing
'mysql' symbols by package 'mariadb'


Why not just drop community-mysql (and keep mariadb as the provider of
mysql*) instead? I really do not see why we need to ship 2 competing forks
of the same database in Fedora. Applications typically do not even notice
the difference.


When MariaDB was introduced to Fedora, it seemed like it eventually
replaces MySQL


Is that not what has happened? Who still uses the Oracle crippleware?

As I understand it, most distros are shipping only MariaDB.


In Fedora, it is currently possible, on the packaging level, to cross
install server of one DB with client of another.
Specifically, you can install MariaDB server with MySQL client or
MySQL server with MariaDB client.


If you insist on shipping both implementations, I am not sure what can be
gained from disallowing this combination. But the easiest solution would of
course be to just drop the Oracle MySQL client and server altogether, then
by definition there is only one remaining combination (MariaDB client and
server).


Sadly, the drawbacks out-weights the positives. This behavior became a
generator of elusive bugs I was never able to resolve.
E.g.: https://bugzilla.redhat.com/show_bug.cgi?id=2026933


This is really a conflict between the MariaDB and Oracle MySQL packages, not
an issue with mixed ("cross") installations, and the only way to completely
get rid of such issues is to drop Oracle MySQL.


I want to change the packaging structure so the result will look as
follows: * The unversioned name ('mariadb') will become a meta-package
** It will point to the one versioned variant which I choose to be the
default one for the given Fedora release
** It will provide all of the unversioned names for the versioned
variant that is default for the given Fedora release, to minimize the
changes visible to the users
* All other versions will have their own versioned package (e.g
"mariadb10.5" "mariadb10.11") and will conflict with each other

This will allow for:
* users to keep using the unversioned names they are used to
* maintainer to change the default version for a given Fedora release
on a single, centralized place
* users to enjoy all of the features of the modularity I offered them,
in a simpler way
* maintainer to add new versions quickly, without any need of changing
the default version (other than adding new conflicts)


There is a major issue with this approach: Users installing Fedora 40 will
get the mariadb metapackages dragging in mariadb10.11. Then they upgrade to
Fedora 41 or 42 or whatever that will ship mariadb10.whatever. So then
mariadb will want to drag in mariadb10.whatever, but mariadb10.11 will also
want to get upgraded, leading to a conflict that DNF will not be able to
resolve in a satisfactory way. (Most likely, it will upgrade mariadb10.11,
keep the old Fedora n-1 version of the mariadb metapackage, and never
install the new mariadb10.whatever.)

The default version should just be unversioned, instead of having the
unversioned package be a metapackage.


   Note:
   I specifically don't want the packages to be parallel installable. I
only want them to be parallel available.


That makes it a lot less useful to use versioned package names.

I suggest you ship one set of MariaDB packages in Fedora, and then use Copr
to distribute different versions (which would also be named mariadb, not
e.g. mariadb10.5 or mariadb10.11, and just have, say, Version: 10.5 and,
since that is a downgrade compared to the official packages, Epoch: n+1,
where n is the Epoch of the 

Re: F40 Change Proposal: F40 MariaDB MySQL repackaging (Self-Contained)

[Kevin Kofler via devel]

> * Rename package 'community-mysql' to 'mysql' and Stop providing
> 'mysql' symbols by package 'mariadb'

Why not just drop community-mysql (and keep mariadb as the provider of 
mysql*) instead? I really do not see why we need to ship 2 competing forks 
of the same database in Fedora. Applications typically do not even notice 
the difference.

> When MariaDB was introduced to Fedora, it seemed like it eventually
> replaces MySQL

Is that not what has happened? Who still uses the Oracle crippleware?

As I understand it, most distros are shipping only MariaDB.

> In Fedora, it is currently possible, on the packaging level, to cross
> install server of one DB with client of another.
> Specifically, you can install MariaDB server with MySQL client or
> MySQL server with MariaDB client.

If you insist on shipping both implementations, I am not sure what can be 
gained from disallowing this combination. But the easiest solution would of 
course be to just drop the Oracle MySQL client and server altogether, then 
by definition there is only one remaining combination (MariaDB client and 
server).

> Sadly, the drawbacks out-weights the positives. This behavior became a
> generator of elusive bugs I was never able to resolve.
> E.g.: https://bugzilla.redhat.com/show_bug.cgi?id=2026933

This is really a conflict between the MariaDB and Oracle MySQL packages, not 
an issue with mixed ("cross") installations, and the only way to completely 
get rid of such issues is to drop Oracle MySQL.

> I want to change the packaging structure so the result will look as
> follows: * The unversioned name ('mariadb') will become a meta-package
> ** It will point to the one versioned variant which I choose to be the
> default one for the given Fedora release
> ** It will provide all of the unversioned names for the versioned
> variant that is default for the given Fedora release, to minimize the
> changes visible to the users
> * All other versions will have their own versioned package (e.g
> "mariadb10.5" "mariadb10.11") and will conflict with each other
> 
> This will allow for:
> * users to keep using the unversioned names they are used to
> * maintainer to change the default version for a given Fedora release
> on a single, centralized place
> * users to enjoy all of the features of the modularity I offered them,
> in a simpler way
> * maintainer to add new versions quickly, without any need of changing
> the default version (other than adding new conflicts)

There is a major issue with this approach: Users installing Fedora 40 will 
get the mariadb metapackages dragging in mariadb10.11. Then they upgrade to 
Fedora 41 or 42 or whatever that will ship mariadb10.whatever. So then 
mariadb will want to drag in mariadb10.whatever, but mariadb10.11 will also 
want to get upgraded, leading to a conflict that DNF will not be able to 
resolve in a satisfactory way. (Most likely, it will upgrade mariadb10.11, 
keep the old Fedora n-1 version of the mariadb metapackage, and never 
install the new mariadb10.whatever.)

The default version should just be unversioned, instead of having the 
unversioned package be a metapackage.

>   Note:
>   I specifically don't want the packages to be parallel installable. I
> only want them to be parallel available.

That makes it a lot less useful to use versioned package names.

I suggest you ship one set of MariaDB packages in Fedora, and then use Copr 
to distribute different versions (which would also be named mariadb, not 
e.g. mariadb10.5 or mariadb10.11, and just have, say, Version: 10.5 and, 
since that is a downgrade compared to the official packages, Epoch: n+1, 
where n is the Epoch of the official packages). To switch to a non-default 
version, one would just dnf copr enable @mariadb-sig/mariadb-10.5 && dnf 
upgrade (or distro-sync, but since it would be an "upgrade" at RPM level, 
distro-sync is not needed here), and to switch back to the default version, 
dnf copr disable @mariadb-sig/mariadb-10.5 && dnf distro-sync (to 
"downgrade" to the official packages' lower EVR).

Kevin Kofler
___
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 Linux 39 Final is NO-GO (#2)

[Adam Williamson]

Due to outstanding blocker bugs[1], we do not have a release candidate
for Fedora Linux 39 Final. Today's Go/No-Go meeting is cancelled.

The next Fedora Linux 39 Final Go/No-Go meeting[2] will be held at
1700 UTC on Thursday 26 October in #fedora-meeting-1. We will aim for
the "target date #2" milestone of 31 October. The release schedule[3]
will be updated accordingly soon.

[1] https://qa.fedoraproject.org/blockerbugs/milestone/39/final/buglist
[2] https://calendar.fedoraproject.org/meeting/10627
[2] https://fedorapeople.org/groups/schedule/f-39/f-39-key-tasks.html
-- 
Adam Williamson (he/him/his)
Fedora QA
Fedora Chat: @adamwill:fedora.im | Mastodon: @ad...@fosstodon.org
https://www.happyassassin.net



___
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

Summary/Minutes from Thursday's FESCo Meeting (2023-10-19)

[Major Hayden]

=
#fedora-meeting-2: FESCO (2023-10-19)
=


Meeting started by mhayden at 17:00:00 UTC. The full logs are available
at
https://meetbot.fedoraproject.org/fedora-meeting-2/2023-10-19/fesco.2023-10-19-17.00.log.html.

Meeting summary
---
* init process  (mhayden, 17:00:15)

* #3059 F39 incomplete changes: 100% complete deadline  (mhayden,
  17:03:32)
  * LINK:

https://bugzilla.redhat.com/buglist.cgi?bug_status=NEW_status=ASSIGNED_status=POST_status=MODIFIED=product%2Ccomponent%2Cassigned_to%2Cbug_status%2Cshort_desc%2Cchangeddate%2Cbug_severity=blocked_id=13304012=substring=id%2C%20_format=advanced=F39Changes
(mhayden, 17:06:58)
  * LINK: https://bugzilla.redhat.com/show_bug.cgi?id=2216764
(mhayden, 17:08:26)
  * LINK: https://bugzilla.redhat.com/show_bug.cgi?id=2233234
(mhayden, 17:09:19)
  * LINK: https://bugzilla.redhat.com/show_bug.cgi?id=2234638
(mhayden, 17:11:18)

* #3074 Change: SQLAlchemy 2  (mhayden, 17:20:09)
  * LINK:

https://fedoraproject.org/w/index.php?title=Changes%2FSQLAlchemy_2=revision=690656=689626
(mhroncok_web, 17:23:39)
  * AGREED: Approved change 3074 for SQLAlchemy 2 (+5, 0, -0)  (mhayden,
17:31:36)

* Next week's chair 晴  (mhayden, 17:32:10)
  * ACTION: mhroncok_web to chair next week's meeting and have tstellar
as a backup if something comes up  (mhayden, 17:35:16)

* Open Floor  (mhayden, 17:35:33)
  * LINK: https://fedoraproject.org/wiki/Changes/fno-omit-frame-pointer
(mhayden, 17:37:29)
  * LINK: https://pagure.io/fesco/issue/2923   (mhayden, 17:37:40)
  * LINK: https://pagure.io/fesco/issue/3084   (mhayden, 17:40:16)
  * LINK: https://pagure.io/packaging-committee/issue/1312
(decathorpe, 17:41:55)

Meeting ended at 17:48:57 UTC.




Action Items

* mhroncok_web to chair next week's meeting and have tstellar as a
  backup if something comes up




Action Items, by person
---
* mhroncok
  * mhroncok_web to chair next week's meeting and have tstellar as a
backup if something comes up
* mhroncok_web
  * mhroncok_web to chair next week's meeting and have tstellar as a
backup if something comes up
* tstellar
  * mhroncok_web to chair next week's meeting and have tstellar as a
backup if something comes up
* **UNASSIGNED**
  * (none)




People Present (lines said)
---
* mhayden (76)
* mhroncok_web (37)
* decathorpe (27)
* zodbot (15)
* zodbot_ (14)
* Son_Goku (10)
* zbyszek (7)
* tstellar (6)
* Sir_Gallantmon (0)
* Conan_Kudo (0)
* Eighth_Doctor (0)
* nirik (0)
* dcantrell (0)
* mhroncok (0)
* King_InuYasha (0)
* Pharaoh_Atem (0)
* sgallagh (0)




Generated by `MeetBot`_ 0.1.4

.. _`MeetBot`: http://wiki.debian.org/MeetBot
___
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: Looking for a volunteer to automate the orphaned packages process

[Adam Williamson]

On Thu, 2023-10-19 at 18:43 +0200, Frantisek Zatloukal wrote:
> On Thu, Oct 19, 2023 at 6:24 PM Adam Williamson 
> wrote:
> 
> > I'm not sure I have time to take this, but glancing over it, I have a
> > suggestion on how to further automate the release stuff.
> > 
> > You can use Bodhi release date to determine the extant EPEL releases
> > and the current Branched release. If you query
> > https://bodhi.fedoraproject.org/releases/ with content-type JSON, you
> > get a bunch of data on releases (paginated, so either handle the pages
> > or use https://bodhi.fedoraproject.org/releases/?rows_per_page=500
> > instead).
> > 
> > To get all current EPEL releases you'd do something like this:
> > 
> > epels = {int(rel['version']) for rel in releases if
> >  rel['state'] == 'current' and rel['id_prefix'] ==
> > 'FEDORA-EPEL'}
> > 
> > To find current Branched, you can do something like this:
> > 
> > devrels = {int(rel['version']) for rel in releases if
> >rel['state'] == 'pending' and rel['id_prefix'] == 'FEDORA'}
> > if len(devrels) > 1:
> > branched = min(devrels)
> > else:
> > branched = None
> > 
> > that logic should be safe as long as we don't change the release
> > process. There is always one "pending" Fedora release - Rawhide. If
> > there's more than one, there will be two, and the other one will be
> > Branched.
> > 
> 
> Or, the "lazier" to implement alternative for this would be
> https://packager-dashboard.fedoraproject.org/api/v1/releases :)

how/where is that data sourced?

if it's from fedfind, it ultimately relies on me manually updating a
JSON file, which isn't awesome. if it's from bodhi, great. :D

fedfind unfortunately can't use bodhi data because of the problem that
releases are marked stable too early in bodhi, but that shouldn't be a
problem for this script's use case.
-- 
Adam Williamson (he/him/his)
Fedora QA
Fedora Chat: @adamwill:fedora.im | Mastodon: @ad...@fosstodon.org
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

[Bug 2245094] New: perl-HTTP-BrowserDetect-3.40 is available

[bugzilla]

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

Bug ID: 2245094
   Summary: perl-HTTP-BrowserDetect-3.40 is available
   Product: Fedora
   Version: rawhide
Status: NEW
 Component: perl-HTTP-BrowserDetect
  Keywords: FutureFeature, Triaged
  Assignee: emman...@seyman.fr
  Reporter: upstream-release-monitor...@fedoraproject.org
QA Contact: extras...@fedoraproject.org
CC: emman...@seyman.fr,
perl-devel@lists.fedoraproject.org, st...@silug.org
  Target Milestone: ---
Classification: Fedora



Releases retrieved: 3.40
Upstream release that is considered latest: 3.40
Current version/release in rawhide: 3.39-1.fc40
URL: https://metacpan.org/release/HTTP-BrowserDetect

Please consult the package updates policy before you issue an update to a
stable branch: https://docs.fedoraproject.org/en-US/fesco/Updates_Policy/


More information about the service that created this bug can be found at:
https://docs.fedoraproject.org/en-US/package-maintainers/Upstream_Release_Monitoring


Please keep in mind that with any upstream change, there may also be packaging
changes that need to be made. Specifically, please remember that it is your
responsibility to review the new version to ensure that the licensing is still
correct and that no non-free or legally problematic items have been added
upstream.


Based on the information from Anitya:
https://release-monitoring.org/project/5936/


To change the monitoring settings for the project, please visit:
https://src.fedoraproject.org/rpms/perl-HTTP-BrowserDetect


-- 
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=2245094

Report this comment as SPAM: 
https://bugzilla.redhat.com/enter_bug.cgi?product=Bugzilla=report-spam_desc=Report%20of%20Bug%202245094%23c0
___
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

[Test-Announce] Fedora Linux 39 Final is NO-GO (#2)

[Adam Williamson]

Due to outstanding blocker bugs[1], we do not have a release candidate
for Fedora Linux 39 Final. Today's Go/No-Go meeting is cancelled.

The next Fedora Linux 39 Final Go/No-Go meeting[2] will be held at
1700 UTC on Thursday 26 October in #fedora-meeting-1. We will aim for
the "target date #2" milestone of 31 October. The release schedule[3]
will be updated accordingly soon.

[1] https://qa.fedoraproject.org/blockerbugs/milestone/39/final/buglist
[2] https://calendar.fedoraproject.org/meeting/10627
[2] https://fedorapeople.org/groups/schedule/f-39/f-39-key-tasks.html
-- 
Adam Williamson (he/him/his)
Fedora QA
Fedora Chat: @adamwill:fedora.im | Mastodon: @ad...@fosstodon.org
https://www.happyassassin.net



___
test-announce mailing list -- test-annou...@lists.fedoraproject.org
To unsubscribe send an email to test-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/test-annou...@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: Looking for a volunteer to automate the orphaned packages process

[Frantisek Zatloukal]

On Thu, Oct 19, 2023 at 6:24 PM Adam Williamson 
wrote:

> I'm not sure I have time to take this, but glancing over it, I have a
> suggestion on how to further automate the release stuff.
>
> You can use Bodhi release date to determine the extant EPEL releases
> and the current Branched release. If you query
> https://bodhi.fedoraproject.org/releases/ with content-type JSON, you
> get a bunch of data on releases (paginated, so either handle the pages
> or use https://bodhi.fedoraproject.org/releases/?rows_per_page=500
> instead).
>
> To get all current EPEL releases you'd do something like this:
>
> epels = {int(rel['version']) for rel in releases if
>  rel['state'] == 'current' and rel['id_prefix'] ==
> 'FEDORA-EPEL'}
>
> To find current Branched, you can do something like this:
>
> devrels = {int(rel['version']) for rel in releases if
>rel['state'] == 'pending' and rel['id_prefix'] == 'FEDORA'}
> if len(devrels) > 1:
> branched = min(devrels)
> else:
> branched = None
>
> that logic should be safe as long as we don't change the release
> process. There is always one "pending" Fedora release - Rawhide. If
> there's more than one, there will be two, and the other one will be
> Branched.
>

Or, the "lazier" to implement alternative for this would be
https://packager-dashboard.fedoraproject.org/api/v1/releases :)

-- 

Best regards / S pozdravem,

František Zatloukal
Senior Quality Engineer
Red Hat
___
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: Looking for a volunteer to automate the orphaned packages process

[Adam Williamson]

On Thu, 2023-10-19 at 11:06 +0200, Miro Hrončok wrote:
> Hello folks,
> 
> you might know I run a script that generates
> 
> https://churchyard.fedorapeople.org/orphans.txt
> https://churchyard.fedorapeople.org/orphans.json
> 
> The script is located at
> https://pagure.io/releng/blob/main/f/scripts/find_unblocked_orphans.py
> 
> I try to monitor the output and whenever it is stuck, I restart it.
> 
> Every 2 weeks I try to save a copy of the generated file and send it to the 
> devel list, devel announce list and the affected maintainers.
> 
> Every branching, the script needs (trivial) changes.
> 
> When I see packages orphaned for 6+ weeks, I retire them.
> 
> 
> I took this task a coupe years back because I was not satisfied with the 
> status 
> quo at that time (packages orphaned for year+ lingering in the distro).
> 
> The task is semi-automated but not fully. After almost 5 years, I think it's 
> time to pass this to somebody else. Preferably to somebody who would enjoy 
> automating it entirely.
> 
> I can provide all the details about the operation if you want to become the 
> reaper's apprentice.
> 
> Please do let me know. I believe this process is essential for the health of 
> Fedora but I'd like to be relieved of this task.

I'm not sure I have time to take this, but glancing over it, I have a
suggestion on how to further automate the release stuff.

You can use Bodhi release date to determine the extant EPEL releases
and the current Branched release. If you query
https://bodhi.fedoraproject.org/releases/ with content-type JSON, you
get a bunch of data on releases (paginated, so either handle the pages
or use https://bodhi.fedoraproject.org/releases/?rows_per_page=500
instead).

To get all current EPEL releases you'd do something like this:

epels = {int(rel['version']) for rel in releases if
 rel['state'] == 'current' and rel['id_prefix'] == 'FEDORA-EPEL'}

To find current Branched, you can do something like this:

devrels = {int(rel['version']) for rel in releases if
   rel['state'] == 'pending' and rel['id_prefix'] == 'FEDORA'}
if len(devrels) > 1:
branched = min(devrels)
else:
branched = None

that logic should be safe as long as we don't change the release
process. There is always one "pending" Fedora release - Rawhide. If
there's more than one, there will be two, and the other one will be
Branched.
-- 
Adam Williamson (he/him/his)
Fedora QA
Fedora Chat: @adamwill:fedora.im | Mastodon: @ad...@fosstodon.org
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: Self Introduction: Nils Koenig

[Priscila Gutierres]

Hello,

What issue are you referring to?
I have been working on PRs without being a maintainer, I just can't upload
the sources but
everytime I needed someone else did it for me.

To delete your fork, go to the Settings tab and click on delete project.

Priscila.

On Thu, Oct 19, 2023 at 1:11 PM Nils Koenig  wrote:

> Hi @all,
>
> a quick hello from my side as I would like to join the Fedora Package
> Maintainers by taking over responsibility for the vhostmd package.
>
> I've created a fork and added my change:
>
>
> https://src.fedoraproject.org/fork/nilskoenig/rpms/vhostmd/c/697e947272969f56f3f892a93e7d37c0babe6d5a?branch=rawhide
>
> But it seems I can't create a PR from there. Anyhow - I would like to take
> over maintainer ship from Richard Jones regarding this package.
> How is that possible?
>
> Another question, is it possible to fast-forward personal forks?
> Or delete/recreate forks?
>
> Thank you,
> Nils
> ___
> 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

Self Introduction: Nils Koenig

[Nils Koenig]

Hi @all,

a quick hello from my side as I would like to join the Fedora Package 
Maintainers by taking over responsibility for the vhostmd package.


I've created a fork and added my change:

https://src.fedoraproject.org/fork/nilskoenig/rpms/vhostmd/c/697e947272969f56f3f892a93e7d37c0babe6d5a?branch=rawhide

But it seems I can't create a PR from there. Anyhow - I would like to 
take over maintainer ship from Richard Jones regarding this package.

How is that possible?

Another question, is it possible to fast-forward personal forks?
Or delete/recreate forks?

Thank you,
Nils
___
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: Libcmis solib bump

[Gwyn Ciesla via devel]

Looks like you're correct. I used an improper reqoquery, and warmed the 
datacenter unnecessarily. Apologies. :)


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


Sent with Proton Mail secure email.

--- Original Message ---
On Thursday, October 19th, 2023 at 7:59 AM, David Tardon  
wrote:


> Hi,
> 

> On Thu, 2023-10-12 at 05:38 +, Gwyn Ciesla via devel wrote:
> 

> > Libcmis 0.6.0 is coming to rawhide, and libreoffice-TexMaths,
> > openoffice.org-diafilter, python-paperwork-backend, and libreoffice
> > are being rebuild against it.
> 

> 

> FTR, I sincerely doubt either openoffice.org-diafilter or
> libreoffice-TexMaths does actually depend on libcmis. I just don't see
> why a DIA import filter or a LaTeX equations editor would need to
> access document storage services such as Alfresco or Google Drive.
> 

> 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

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

Re: argyllcms orphaned

[Gwyn Ciesla via devel]

I was going to take it since I've done a little work on it but I see someone's 
beaten me to it. I'll remain a co-maintainer.


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


Sent with Proton Mail secure email.

--- Original Message ---
On Thursday, October 19th, 2023 at 3:20 AM, Richard Hughes 
 wrote:


> Hi all,
> 

> I've orphaned argyllcms -- I'm no longer using the package, and
> haven't worked on color management for some time. If anyone wants to
> take on the package the upstream source is chucked over the wall (no
> source control) every few months, and it sometimes needs patches to
> fix the Linux support. Ohh and it uses jam as the build system
> upstream, which in honesty is going to be easier to rewrite with
> automake or meson before building. I'm happy to give advice to the new
> maintainer. Apologies,
> 

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

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

Re: argyllcms orphaned

[Stephen Smoogen]

On Thu, 19 Oct 2023 at 06:02, Andreas Schneider  wrote:

> On Thursday, 19 October 2023 10:20:52 CEST Richard Hughes wrote:
> > Hi all,
>
> Hi,
>
> > I've orphaned argyllcms -- I'm no longer using the package, and
> > haven't worked on color management for some time. If anyone wants to
> > take on the package the upstream source is chucked over the wall (no
> > source control) every few months, and it sometimes needs patches to
> > fix the Linux support. Ohh and it uses jam as the build system
> > upstream, which in honesty is going to be easier to rewrite with
> > automake or meson before building. I'm happy to give advice to the new
> > maintainer. Apologies,
>
> we don't have displaycal in the distribution anymore? :-(
>
> https://github.com/eoyilmaz/displaycal-py3
>
>
> This required it, it sounds like nobody uses Fedora for color work
> anymore.
> That would be sad.
>
>
Very few people were doing it before. Color work is a 'niche' field in any
distribution so unless people are paying for it, it is probably going to
come and go as people get interested in it, work on it for a while, and
then go do something else. That is the sadness of life.


> Best regards
>
>
> Andreas
>
> ___
> 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
>


-- 
Stephen Smoogen, Red Hat Automotive
Let us be kind to one another, for most of us are fighting a hard battle.
-- Ian MacClaren
___
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: Looking for a volunteer to automate the orphaned packages process

[Fabio Valentini]

On Thu, Oct 19, 2023 at 11:06 AM Miro Hrončok  wrote:
>
> Hello folks,
>
> you might know I run a script that generates
>
> https://churchyard.fedorapeople.org/orphans.txt
> https://churchyard.fedorapeople.org/orphans.json
>
> The script is located at
> https://pagure.io/releng/blob/main/f/scripts/find_unblocked_orphans.py
>
> I try to monitor the output and whenever it is stuck, I restart it.
>
> Every 2 weeks I try to save a copy of the generated file and send it to the
> devel list, devel announce list and the affected maintainers.
>
> Every branching, the script needs (trivial) changes.
>
> When I see packages orphaned for 6+ weeks, I retire them.
>
>
> I took this task a coupe years back because I was not satisfied with the 
> status
> quo at that time (packages orphaned for year+ lingering in the distro).
>
> The task is semi-automated but not fully. After almost 5 years, I think it's
> time to pass this to somebody else. Preferably to somebody who would enjoy
> automating it entirely.
>
> I can provide all the details about the operation if you want to become the
> reaper's apprentice.
>
> Please do let me know. I believe this process is essential for the health of
> Fedora but I'd like to be relieved of this task.

I think it might be possible to migrate this task to be a releng
toddler? In that case there wouldn't even need to be a "volunteer" to
run it, exactly :)
For example, the recent implementation of the "SIG Policy" (which does
some repoqueries and then modifies dist-git settings) isn't *that*
different (it's just much less long-running), and it works fine as a
toddler.

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 39 compose report: 20231019.n.0 changes

[Fedora Branched Report]

OLD: Fedora-39-20231018.n.0
NEW: Fedora-39-20231019.n.0

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

Size of added packages:  0 B
Size of dropped packages:0 B
Size of upgraded packages:   24.61 MiB
Size of downgraded packages: 0 B

Size change of upgraded packages:   -74.20 KiB
Size change of downgraded packages: 0 B

= ADDED IMAGES =
Image: Silverblue dvd-ostree x86_64
Path: Silverblue/x86_64/iso/Fedora-Silverblue-ostree-x86_64-39-20231019.n.0.iso
Image: Workstation live aarch64
Path: 
Workstation/aarch64/iso/Fedora-Workstation-Live-aarch64-39-20231019.n.0.iso
Image: Kinoite dvd-ostree x86_64
Path: Kinoite/x86_64/iso/Fedora-Kinoite-ostree-x86_64-39-20231019.n.0.iso

= DROPPED IMAGES =
Image: Sericea dvd-ostree x86_64
Path: Sericea/x86_64/iso/Fedora-Sericea-ostree-x86_64-39-20231018.n.0.iso

= ADDED PACKAGES =

= DROPPED PACKAGES =

= UPGRADED PACKAGES =
Package:  anaconda-39.32.6-1.fc39
Old package:  anaconda-39.32.4-1.fc39
Summary:  Graphical system installer
RPMs: anaconda anaconda-core anaconda-dracut anaconda-gui 
anaconda-install-env-deps anaconda-install-img-deps anaconda-live anaconda-tui 
anaconda-webui anaconda-widgets anaconda-widgets-devel
Size: 23.84 MiB
Size change:  -76.83 KiB
Changelog:
  * Tue Oct 17 2023 Packit  - 39.32.5-1
  - Update translations from Weblate for fedora-39 (github-actions)
  - storage: Handle BTRFS with systemd-boot (jeremy.linton)

  * Tue Oct 17 2023 Packit  - 39.32.6-1
  - Revert "Disable geolocation on the Fedora Workstation live image" (kkoukiou)


Package:  fedora-obsolete-packages-39-19
Old package:  fedora-obsolete-packages-39-18
Summary:  A package to obsolete retired packages
RPMs: fedora-obsolete-packages
Size: 29.07 KiB
Size change:  236 B
Changelog:
  * Mon Oct 16 2023 Miro Hron??ok  - 39-19
  - Obsolete the last remaining Python 3.11 packages


Package:  initial-setup-0.3.98-2.fc39
Old package:  initial-setup-0.3.97-4.fc39
Summary:  Initial system configuration utility
RPMs: initial-setup initial-setup-gui
Size: 757.87 KiB
Size change:  2.40 KiB
Changelog:
  * Mon Oct 09 2023 Martin Kolman  - 0.3.98-1
  - Fix Anaconda module startup (#2241274) (mkolman)

  * Tue Oct 17 2023 Martin Kolman  - 0.3.98-2
  - Fix tarball (#2241274) (mkolman)



= 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

Re: Libcmis solib bump

[David Tardon]

Hi,

On Thu, 2023-10-12 at 05:38 +, Gwyn Ciesla via devel wrote:
> Libcmis 0.6.0 is coming to rawhide, and libreoffice-TexMaths,
> openoffice.org-diafilter, python-paperwork-backend, and libreoffice
> are being rebuild against it.

FTR, I sincerely doubt either openoffice.org-diafilter or
libreoffice-TexMaths does actually depend on libcmis. I just don't see
why a DIA import filter or a LaTeX equations editor would need to
access document storage services such as Alfresco or Google Drive.

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

Re: Looking for a volunteer to automate the orphaned packages process

[Sérgio Basto]

On Thu, 2023-10-19 at 11:06 +0200, Miro Hrončok wrote:
> Hello folks,
> 
> you might know I run a script that generates
> 
> https://churchyard.fedorapeople.org/orphans.txt
> https://churchyard.fedorapeople.org/orphans.json
> 
> The script is located at
> https://pagure.io/releng/blob/main/f/scripts/find_unblocked_orphans.py
> 
> I try to monitor the output and whenever it is stuck, I restart it.
> 
> Every 2 weeks I try to save a copy of the generated file and send it
> to the 
> devel list, devel announce list and the affected maintainers.
> 
> Every branching, the script needs (trivial) changes.
> 
> When I see packages orphaned for 6+ weeks, I retire them.
> 
> 
> I took this task a coupe years back because I was not satisfied with
> the status 
> quo at that time (packages orphaned for year+ lingering in the
> distro).
> 
> The task is semi-automated but not fully. After almost 5 years, I
> think it's 
> time to pass this to somebody else. Preferably to somebody who would
> enjoy 
> automating it entirely.
> 
> I can provide all the details about the operation if you want to
> become the 
> reaper's apprentice.
> 

yeah, as already mention, I think sometimes is reaped too much, but the
results, at the end of the day, are good, we have a better Fedora. I
know the balance is extremely difficult and needs lots of work.

I have some commits to improve find_unblocked_orphans.py (not yet
completely finished ) , the feature that I'd like implement is query
more than one repo , will be useful to query el + epel for example and
some optimizations IIRC. 


> Please do let me know. I believe this process is essential for the
> health of 
> Fedora but I'd like to be relieved of this task.
> 
> -- 
> 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

-- 
Sérgio M. B.
___
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

[Fedocal] Reminder meeting : ELN SIG

[sgallagh]

Dear all,

You are kindly invited to the meeting:
   ELN SIG on 2023-10-20 from 12:00:00 to 13:00:00 US/Eastern
   At fedora-meet...@irc.libera.chat

The meeting will be about:



Source: https://calendar.fedoraproject.org//meeting/10568/

___
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

Schedule for Thursday's FESCo Meeting (2023-10-19)

[Major Hayden]

Following is the list of topics that will be discussed in the
FESCo meeting Thursday at 17:00UTC in #fedora-meeting-2 on
irc.libera.chat.

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

or run:
  date -d '2023-10-19 17:00 UTC'

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

= Discussed and Voted in the Ticket =

#3083 [FAST TRACK] Special blocker for kdump enabled by mistake
https://pagure.io/fesco/issue/3083
APPROVED (+7, 0, -0)

#3082 [FAST TRACK] Bump maximum size of aarch64 Server network install image to 
1G 
https://pagure.io/fesco/issue/3082
APPROVED (+7, 0, -0)

#3077 Go 1.20 in Fedora 37
https://pagure.io/fesco/issue/3077
APPROVED (+4, 0, -0)

#3073 Change: PHP 8.3
https://pagure.io/fesco/issue/3073
APPROVED (+6, 0, -0)

#3071 Change: Switch pam_userdb from BerkeleyDB to GDBM
https://pagure.io/fesco/issue/3071
APPROVED (+5, 0, -0)

#3070 Change: Drop Delta RPMs
https://pagure.io/fesco/issue/3070
APPROVED (+8, 0, -0)

= Followups =

#3059 F39 incomplete changes: 100% complete deadline
https://pagure.io/fesco/issue/3059

= New business =

#3074 Change: SQLAlchemy 2
https://pagure.io/fesco/issue/3074

= Open Floor = 

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

If you would like to add something to this agenda, you can
reply to this e-mail, file a new issue at
https://pagure.io/fesco, e-mail me directly, or bring it
up at the end of the meeting, during the open floor topic. Note
that added topics may be deferred until the following meeting.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

[Test-Announce] Fedora 39 Branched 20231019.n.0 nightly compose nominated for testing

[rawhide]

Announcing the creation of a new nightly release validation test event
for Fedora 39 Branched 20231019.n.0. Please help run some tests for this
nightly compose if you have time. For more information on nightly
release validation testing, see:
https://fedoraproject.org/wiki/QA:Release_validation_test_plan

Notable package version changes:
anaconda - 20231014.n.0: anaconda-39.32.4-1.fc39.src, 20231019.n.0: 
anaconda-39.32.6-1.fc39.src

Test coverage information for the current release can be seen at:
https://openqa.fedoraproject.org/testcase_stats/39

You can see all results, find testing instructions and image download
locations, and enter results on the Summary page:

https://fedoraproject.org/wiki/Test_Results:Fedora_39_Branched_20231019.n.0_Summary

The individual test result pages are:

https://fedoraproject.org/wiki/Test_Results:Fedora_39_Branched_20231019.n.0_Installation
https://fedoraproject.org/wiki/Test_Results:Fedora_39_Branched_20231019.n.0_Base
https://fedoraproject.org/wiki/Test_Results:Fedora_39_Branched_20231019.n.0_Server
https://fedoraproject.org/wiki/Test_Results:Fedora_39_Branched_20231019.n.0_Cloud
https://fedoraproject.org/wiki/Test_Results:Fedora_39_Branched_20231019.n.0_Desktop
https://fedoraproject.org/wiki/Test_Results:Fedora_39_Branched_20231019.n.0_Security_Lab

Thank you for testing!
-- 
Mail generated by relvalconsumer: https://pagure.io/fedora-qa/relvalconsumer
___
test-announce mailing list -- test-annou...@lists.fedoraproject.org
To unsubscribe send an email to test-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/test-annou...@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

[Fedora Change draft] Minizip transition to minizip-ng

[Lukas Javorsky]

Hi,

We've been working on a set of Fedora changes (zlib and minizip) and now
I'd like to share the minizip Fedora change [1] with you, the community.

This one is smaller than the zlib one, but it needs to be finished before
the zlib (as we will remove the minizip-compat subpackage with the zlib
package).

All details are mentioned in the Change proposal, I just wanted to share it
directly with you via this email.

Please raise any questions/feedback, so we can fine-tune it before asking
for a wrangler from FESCo.

There are currently three packages that don't build with the new minizip-ng
(all reported to their maintainers):
Chromium: https://bugzilla.redhat.com/show_bug.cgi?id=2242271
Libdigidocpp: https://bugzilla.redhat.com/show_bug.cgi?id=2240599
OpenColorIO: https://bugzilla.redhat.com/show_bug.cgi?id=2239262

All other packages have been rebuilt in the testing COPR repository [2].

PS: Don't worry the zlib Fedora Change will be shared with you as well

[1] https://fedoraproject.org/wiki/Changes/MinizipNGTransition
[2] https://copr.fedorainfracloud.org/coprs/ljavorsk/minizip-ng/packages/

-- 
S pozdravom/ Best regards

Lukáš Javorský

Software Engineer, Core service - Databases

Red Hat 

Purkyňova 115 (TPB-C)

612 00 Brno - Královo Pole

ljavo...@redhat.com

___
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: Looking for a volunteer to automate the orphaned packages process

[Maxwell G]

2023-10-19T09:06:53Z Miro Hrončok :


you might know I run a script that generates

https://churchyard.fedorapeople.org/orphans.txt
https://churchyard.fedorapeople.org/orphans.json

The script is located at
https://pagure.io/releng/blob/main/f/scripts/find_unblocked_orphans.py

I try to monitor the output and whenever it is stuck, I restart it.

Every 2 weeks I try to save a copy of the generated file and send it to 
the devel list, devel announce list and the affected maintainers.


Every branching, the script needs (trivial) changes.

When I see packages orphaned for 6+ weeks, I retire them.


I took this task a coupe years back because I was not satisfied with 
the status quo at that time (packages orphaned for year+ lingering in 
the distro).


The task is semi-automated but not fully. After almost 5 years, I think 
it's time to pass this to somebody else. Preferably to somebody who 
would enjoy automating it entirely.


I can provide all the details about the operation if you want to become 
the reaper's apprentice.


Please do let me know. I believe this process is essential for the 
health of Fedora but I'd like to be relieved of this task.

Hi Miro,

Thanks for all of your work on the orphaned package process and related 
processes up until now. I agree that making sure that packages in the 
distro are maintained is crucial.


This task interests me and is similar to previous work I've done in the 
Go ecosystem, but I'm not sure I'm up for additional responsibilities 
right now, at least not before EOY.


Best,
Maxwell
--
Maxwell G (@gotmax23)
Pronouns: He/They
___
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: argyllcms orphaned

[Andreas Schneider]

On Thursday, 19 October 2023 10:20:52 CEST Richard Hughes wrote:
> Hi all,

Hi,
 
> I've orphaned argyllcms -- I'm no longer using the package, and
> haven't worked on color management for some time. If anyone wants to
> take on the package the upstream source is chucked over the wall (no
> source control) every few months, and it sometimes needs patches to
> fix the Linux support. Ohh and it uses jam as the build system
> upstream, which in honesty is going to be easier to rewrite with
> automake or meson before building. I'm happy to give advice to the new
> maintainer. Apologies,

we don't have displaycal in the distribution anymore? :-(

https://github.com/eoyilmaz/displaycal-py3


This required it, it sounds like nobody uses Fedora for color work anymore. 
That would be sad.

Best regards


Andreas

___
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: Looking for a volunteer to automate the orphaned packages process

[Sandro]

On 19-10-2023 11:06, Miro Hrončok wrote:
I can provide all the details about the operation if you want to become 
the reaper's apprentice.


A reaper by the name of Churchyard! ⚰️ 
___
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

Looking for a volunteer to automate the orphaned packages process

[Miro Hrončok]

Hello folks,

you might know I run a script that generates

https://churchyard.fedorapeople.org/orphans.txt
https://churchyard.fedorapeople.org/orphans.json

The script is located at
https://pagure.io/releng/blob/main/f/scripts/find_unblocked_orphans.py

I try to monitor the output and whenever it is stuck, I restart it.

Every 2 weeks I try to save a copy of the generated file and send it to the 
devel list, devel announce list and the affected maintainers.


Every branching, the script needs (trivial) changes.

When I see packages orphaned for 6+ weeks, I retire them.


I took this task a coupe years back because I was not satisfied with the status 
quo at that time (packages orphaned for year+ lingering in the distro).


The task is semi-automated but not fully. After almost 5 years, I think it's 
time to pass this to somebody else. Preferably to somebody who would enjoy 
automating it entirely.


I can provide all the details about the operation if you want to become the 
reaper's apprentice.


Please do let me know. I believe this process is essential for the health of 
Fedora but I'd like to be relieved of this task.


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

argyllcms orphaned

[Richard Hughes]

Hi all,

I've orphaned argyllcms -- I'm no longer using the package, and
haven't worked on color management for some time. If anyone wants to
take on the package the upstream source is chucked over the wall (no
source control) every few months, and it sometimes needs patches to
fix the Linux support. Ohh and it uses jam as the build system
upstream, which in honesty is going to be easier to rewrite with
automake or meson before building. I'm happy to give advice to the new
maintainer. Apologies,

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

[rpms/perl-List-MoreUtils-XS] PR #1: Disable extra test in RHEL builds

[Paul Howarth]

pghmcfc closed without merging a pull-request against the project: 
`perl-List-MoreUtils-XS` that you
are following.

Closed pull-request:

``
Disable extra test in RHEL builds
``

https://src.fedoraproject.org/rpms/perl-List-MoreUtils-XS/pull-request/1
___
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