Orphaned packages looking for new maintainers

[Maxwell G]

Report started at 2024-05-21 23:14:51 UTC

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

Note: If you received this mail directly you (co)maintain one of the affected
packages or a package that depends on one. Please adopt the affected package or
retire your depending package to avoid broken dependencies, otherwise your
package will be retired when the affected package gets retired.

Request package ownership via the *Take* button in the left column on
https://src.fedoraproject.org/rpms/

Full report available at:
https://a.gtmx.me/orphans/orphans.txt
grep it for your FAS username and follow the dependency chain.

For human readable dependency chains,
see https://packager-dashboard.fedoraproject.org/
For all orphaned packages,
see https://packager-dashboard.fedoraproject.org/orphan

Package  (co)maintainers   Status Change

3Depict   orphan   0 weeks ago  
BitchXorphan, rdieter  0 weeks ago  
ansible-collection-community- @infra-sig, gotmax23, orphan 0 weeks ago  
rabbitmq
balsa orphan   0 weeks ago  
bti   orphan   4 weeks ago  
buildstream   atim, orphan 0 weeks ago  
container-exception-logger@abrt-sig, mmarusak, orphan  0 weeks ago  
cutecworphan   0 weeks ago  
dnssec-nodes  orphan   0 weeks ago  
dnssec-system-trayorphan   0 weeks ago  
dnssec-tools  orphan   0 weeks ago  
erlang-p1_acme@erlang-maint-sig, orphan1 weeks ago  
fleet-commander-admin orphan   0 weeks ago  
fleet-commander-clientorphan   0 weeks ago  
gofer orphan   0 weeks ago  
golang-github-client9-gospell @go-sig, orphan  0 weeks ago  
golang-github-elves-elvish@go-sig, orphan  4 weeks ago  
golang-github-xiaq-persistent @go-sig, orphan  4 weeks ago  
golang-k8s-cli-runtime@go-sig, orphan  1 weeks ago  
golang-k8s-kubectl@go-sig, orphan  1 weeks ago  
gtypist   orphan   0 weeks ago  
jgit  orphan   0 weeks ago  
jolokia-jvm-agent orphan   6 weeks ago  
kanotf-fonts  orphan   0 weeks ago  
laf-pluginorphan   0 weeks ago  
levien-museum-fonts   orphan   0 weeks ago  
libitlmoceap, orphan   0 weeks ago  
logserial orphan   0 weeks ago  
lookuporphan   0 weeks ago  
mingw-cppunit orphan   3 weeks ago  
mingw-freeimage   orphan   6 weeks ago  
mingw-sword   orphan   1 weeks ago  
neofetch  orphan   2 weeks ago  
nuntius   kalev, orphan0 weeks ago  
oc-inject orphan   0 weeks ago  
perl-Crypt-OpenSSL-PKCS10 orphan   0 weeks ago  
perl-Flickr-API   orphan   0 weeks ago  
perl-Flickr-Uploadorphan   0 weeks ago  
perl-Getopt-GUI-Long  orphan   0 weeks ago  
perl-QWizard  orphan   0 weeks ago  
pidgin-guifications   nosnilmot, orphan0 weeks ago  
prometheus-jmx-exporter   orphan   6 weeks ago  
prometheus-simpleclient-java  orphan   6 weeks ago  
python-git-changelog  @neuro-sig, orphan,  0 weeks ago  
  vanessakris   
python-glue   orphan   0

Re: Intention to take over orphaned packages: php-aws-sdk3, php-ralouphie-getallheaders, php-guzzlehttp-guzzle6

[Dominik Wombacher]

> On 05/13/2024 12:29 PM CEST Remi Collet  wrote:
> 
> As I said, because of bundled libraries
>

OK, I work on packaging the AWS C libs right now that would otherwise bundled.
So that problem should be solved / solvable in a couple of weeks.

I would then like to give php-awscrt a try based on your existing work if 
that's fine for you.

> 
> And also lack or PHP reviewers
> I already have tons of packages waiting for review for months
> 

Make sense, maybe we can help each other here? 
Happy to do some reviews and you might able to work on mine that coming up? :)

Dom

-- 
The Wombelix Post
https://dominik.wombacher.cc
--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/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: rich deps result in packages being uninstalled from buildroot

[Zbigniew Jędrzejewski-Szmek]

On Mon, May 20, 2024 at 10:55:58AM +0200, Petr Pisar wrote:
> V Sat, May 18, 2024 at 08:20:53PM +0200, Sandro napsal(a):
> > On 16-05-2024 13:14, Petr Pisar wrote:
> > > A workaround could be rpm-build or mock to register rpm-build package in
> > > /etc/dnf/protected.d configuration files. Packages listed there are 
> > > prevented
> > > from removal no matter of --allow-erasing.
> > 
> > A bit late to the party, but I was wondering if making `add-determinism` and
> > `add-determinism-nopython` require `rpm-build` would also achieve
> > `rpm-build` being protected from removal as a workaround.
> > 
> > If either package requires it there should only be one way forward, if my
> > understanding of the issue is correct.
> > 
> That's also a possible way. Many times defining the reverse dependendency can
> be justified as (add-determinism) being a plugin (of rpm-build). It also helps
> cleaning useless plugins (add-determinism) when the framework (rpm-build) is
> uinstalled.
> 
> A drawback is creating dependency loop.

Thank you for the suggestion. I think that with the current state
things are good, so I don't plan to change things, unless we discover
some breakage.

FWIW, add-determinism is fully functional without rpm-build… I expect
that most people who use it would have rpm-build installed, but
I think it's better to not create dependency loops to keep things
flexible.

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

Re: rich deps result in packages being uninstalled from buildroot

[Petr Pisar]

V Sat, May 18, 2024 at 08:20:53PM +0200, Sandro napsal(a):
> On 16-05-2024 13:14, Petr Pisar wrote:
> > A workaround could be rpm-build or mock to register rpm-build package in
> > /etc/dnf/protected.d configuration files. Packages listed there are 
> > prevented
> > from removal no matter of --allow-erasing.
> 
> A bit late to the party, but I was wondering if making `add-determinism` and
> `add-determinism-nopython` require `rpm-build` would also achieve
> `rpm-build` being protected from removal as a workaround.
> 
> If either package requires it there should only be one way forward, if my
> understanding of the issue is correct.
> 
That's also a possible way. Many times defining the reverse dependendency can
be justified as (add-determinism) being a plugin (of rpm-build). It also helps
cleaning useless plugins (add-determinism) when the framework (rpm-build) is
uinstalled.

A drawback is creating dependency loop.

-- Petr


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

Re: rich deps result in packages being uninstalled from buildroot

[Sandro]

On 16-05-2024 13:14, Petr Pisar wrote:

A workaround could be rpm-build or mock to register rpm-build package in
/etc/dnf/protected.d configuration files. Packages listed there are prevented
from removal no matter of --allow-erasing.


A bit late to the party, but I was wondering if making `add-determinism` 
and `add-determinism-nopython` require `rpm-build` would also achieve 
`rpm-build` being protected from removal as a workaround.


If either package requires it there should only be one way forward, if 
my understanding of the issue is correct.


-- 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: rich deps result in packages being uninstalled from buildroot

[Paul Howarth]

On Fri, 17 May 2024 13:32:24 +
Zbigniew Jędrzejewski-Szmek  wrote:
> > Oh, this is embarrasing. I added two patches but they didn't get
> > applied because %setup not %autosetup. :(
> > I'll push a fixed build in a moment. Sorry for breaking the builds.
> >  
> 
> perl-Finance-Quote-1.6200-1.fc41:
> https://koji.fedoraproject.org/koji/taskinfo?taskID=117804013

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

Re: rich deps result in packages being uninstalled from buildroot

[Zbigniew Jędrzejewski-Szmek]

On Fri, May 17, 2024 at 12:19:34PM +, Zbigniew Jędrzejewski-Szmek wrote:
> On Fri, May 17, 2024 at 09:43:22AM +0100, Paul Howarth wrote:
> > On Thu, 16 May 2024 10:52:29 +
> > Zbigniew Jędrzejewski-Szmek  wrote:
> > 
> > > On Thu, May 16, 2024 at 11:09:01AM +0200, Fabio Valentini wrote:
> > > > This looks like you're putting the resolver between a rock and a
> > > > hard place. :thinking:
> > > > I don't think I've ever seen packages being *removed* when
> > > > installing BuildRequires on top of the minimal buildroot ...
> > > > 
> > > > Would it be possible to adapt the packages so that add-determinism
> > > > and add-determinism-nopython are parallel-installable, and have the
> > > > macro fall back to the add-determinism-nopython executable if the
> > > > add-determinism executable is not available?
> > > > That way BuildRequires are additive and wouldn't force package
> > > > removal from the buildroot, and the rich dependency could be
> > > > simpler - i.e. `Requires: (add-determinism if python3-libs)`,
> > > > without Suggests or else branch.  
> > > 
> > > Yeah, I think this is the most reasonable approach.
> > > I'll push a build that does this shortly.
> > > 
> > > (I tried to test this locally with mock, with the additional packages
> > > in a local repo. When I install everything in one go, things work as
> > > expected. Why I try to check the original issue, and install packages
> > > piecemeal, mock downgrades packages to fall back to the koji version
> > > without dependencies, instead of installing the additional deps. In
> > > koji, it'll only have one version of the package available, so
> > > hopefully it'll pick addition instead of removals.)
> > 
> > Not sure how this is supposed to work: add-determinism-nopython seems
> > to install %{_bindir}/add-determinism.nopython but the macro only seems 
> > to look for %{_bindir}/add-determinism, resulting in this when only
> > add-determinism-nopython is installed:
> > 
> > (https://koji.fedoraproject.org/koji/taskinfo?taskID=117791675)
> 
> Oh, this is embarrasing. I added two patches but they didn't get
> applied because %setup not %autosetup. :(
> I'll push a fixed build in a moment. Sorry for breaking the builds.

perl-Finance-Quote-1.6200-1.fc41:
https://koji.fedoraproject.org/koji/taskinfo?taskID=117804013

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

Re: rich deps result in packages being uninstalled from buildroot

[Zbigniew Jędrzejewski-Szmek]

On Fri, May 17, 2024 at 09:43:22AM +0100, Paul Howarth wrote:
> On Thu, 16 May 2024 10:52:29 +
> Zbigniew Jędrzejewski-Szmek  wrote:
> 
> > On Thu, May 16, 2024 at 11:09:01AM +0200, Fabio Valentini wrote:
> > > This looks like you're putting the resolver between a rock and a
> > > hard place. :thinking:
> > > I don't think I've ever seen packages being *removed* when
> > > installing BuildRequires on top of the minimal buildroot ...
> > > 
> > > Would it be possible to adapt the packages so that add-determinism
> > > and add-determinism-nopython are parallel-installable, and have the
> > > macro fall back to the add-determinism-nopython executable if the
> > > add-determinism executable is not available?
> > > That way BuildRequires are additive and wouldn't force package
> > > removal from the buildroot, and the rich dependency could be
> > > simpler - i.e. `Requires: (add-determinism if python3-libs)`,
> > > without Suggests or else branch.  
> > 
> > Yeah, I think this is the most reasonable approach.
> > I'll push a build that does this shortly.
> > 
> > (I tried to test this locally with mock, with the additional packages
> > in a local repo. When I install everything in one go, things work as
> > expected. Why I try to check the original issue, and install packages
> > piecemeal, mock downgrades packages to fall back to the koji version
> > without dependencies, instead of installing the additional deps. In
> > koji, it'll only have one version of the package available, so
> > hopefully it'll pick addition instead of removals.)
> 
> Not sure how this is supposed to work: add-determinism-nopython seems
> to install %{_bindir}/add-determinism.nopython but the macro only seems 
> to look for %{_bindir}/add-determinism, resulting in this when only
> add-determinism-nopython is installed:
> 
> (https://koji.fedoraproject.org/koji/taskinfo?taskID=117791675)

Oh, this is embarrasing. I added two patches but they didn't get
applied because %setup not %autosetup. :(
I'll push a fixed build in a moment. Sorry for breaking the builds.

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

Re: rich deps result in packages being uninstalled from buildroot

[Vít Ondruch]

Dne 17. 05. 24 v 7:16 Panu Matilainen napsal(a):

On 5/16/24 16:10, Vít Ondruch wrote:


Dne 16. 05. 24 v 14:28 Zbigniew Jędrzejewski-Szmek napsal(a):

On Thu, May 16, 2024 at 01:14:16PM +0200, Petr Pisar wrote:
Proper solution is actually minimazing content of the minimal build 
root

Most of the packages in the buildroot are libraries, pulled in via
dependencies.

@buildsys-build group is:
Mandatory packages   : bash  # basic shell env
  : bzip2 # source extraction
  : coreutils # basic shell env
  : cpio  # source extraction
  : diffutils # source extraction
  : fedora-release-common   # rpm environment
  : findutils # basic shell env
  : gawk  # basic shell env
  : glibc-minimal-langpack  # we want this to 
avoid other langpacks

  : grep  # basic shell env
  : gzip  # source extraction
  : info
  : patch # source extraction
  : redhat-rpm-config  # rpm environment
  : rpm-build  # rpm environment
  : sed   # basic shell env
  : shadow-utils
  : tar   # source extraction
  : unzip # source extraction
  : util-linux    # basic shell env
  : which # basic shell env. (command -v 
is more portable, but meh.)

  : xz    # source extraction



And there is this proposal to reduce the amount of compression 
libraries:


https://github.com/rpm-software-management/rpm/issues/1396

Actually, since RPM now uses `rpmuncompress` to extract the archives, 
it could also make sense to e.g. extract this utility into separate 
sub-package and move the extraction utilities out from the 
@buildsys-build. That would not reduce the the buildroot size at 
first, but get the dependencies to the right place for the start.




Doesn't work.

rpmuncompress doesn't know how to uncompress ANYTHING AT ALL by 
itself. It only knows which command(s) to call to do that.



The point is that the group is not the right place to list the 
extraction utilities. The definition should be closer to RPM IMHO. Of 
course one might argue that distribution might want to have a word and 
avoid some compression algorithm, but it can't add anything what RPM 
somehow does not support.


And I didn't want to imply that rpmuncompress can extract some archive 
on its own. Although it can likely be read that way ...



Vít




- Panu -
--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/

List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue


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

Re: rich deps result in packages being uninstalled from buildroot

[Paul Howarth]

On Thu, 16 May 2024 10:52:29 +
Zbigniew Jędrzejewski-Szmek  wrote:

> On Thu, May 16, 2024 at 11:09:01AM +0200, Fabio Valentini wrote:
> > This looks like you're putting the resolver between a rock and a
> > hard place. :thinking:
> > I don't think I've ever seen packages being *removed* when
> > installing BuildRequires on top of the minimal buildroot ...
> > 
> > Would it be possible to adapt the packages so that add-determinism
> > and add-determinism-nopython are parallel-installable, and have the
> > macro fall back to the add-determinism-nopython executable if the
> > add-determinism executable is not available?
> > That way BuildRequires are additive and wouldn't force package
> > removal from the buildroot, and the rich dependency could be
> > simpler - i.e. `Requires: (add-determinism if python3-libs)`,
> > without Suggests or else branch.  
> 
> Yeah, I think this is the most reasonable approach.
> I'll push a build that does this shortly.
> 
> (I tried to test this locally with mock, with the additional packages
> in a local repo. When I install everything in one go, things work as
> expected. Why I try to check the original issue, and install packages
> piecemeal, mock downgrades packages to fall back to the koji version
> without dependencies, instead of installing the additional deps. In
> koji, it'll only have one version of the package available, so
> hopefully it'll pick addition instead of removals.)

Not sure how this is supposed to work: add-determinism-nopython seems
to install %{_bindir}/add-determinism.nopython but the macro only seems 
to look for %{_bindir}/add-determinism, resulting in this when only
add-determinism-nopython is installed:

(https://koji.fedoraproject.org/koji/taskinfo?taskID=117791675)

+ /usr/bin/add-determinism --brp -j48 
/builddir/build/BUILDROOT/perl-Finance-Quote-1.6200-1.fc41.noarch
/var/tmp/rpm-tmp.hdLEuR: line 89: /usr/bin/add-determinism: No such file or 
directory
error: Bad exit status from /var/tmp/rpm-tmp.hdLEuR (%install)

The intent seems to be that the minimal version checks for existence of
the full version and re-execs it if found. So it seems to me that the
minimal version should be installed as %{_bindir}/add-determinism and
the full version should be called %{_bindir}/add-determinism.withpython
or something. Or maybe just tweak the rpm macro to define
%__brp_add_determinism as %{_bindir}/add-determinism.nopython.

Regards, Paul.
--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/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: rich deps result in packages being uninstalled from buildroot

[Panu Matilainen]

On 5/16/24 16:10, Vít Ondruch wrote:


Dne 16. 05. 24 v 14:28 Zbigniew Jędrzejewski-Szmek napsal(a):

On Thu, May 16, 2024 at 01:14:16PM +0200, Petr Pisar wrote:

Proper solution is actually minimazing content of the minimal build root

Most of the packages in the buildroot are libraries, pulled in via
dependencies.

@buildsys-build group is:
Mandatory packages   : bash  # basic shell env
  : bzip2 # source extraction
  : coreutils # basic shell env
  : cpio  # source extraction
  : diffutils # source extraction
  : fedora-release-common   # rpm environment
  : findutils # basic shell env
  : gawk  # basic shell env
  : glibc-minimal-langpack  # we want this to 
avoid other langpacks

  : grep  # basic shell env
  : gzip  # source extraction
  : info
  : patch # source extraction
  : redhat-rpm-config  # rpm environment
  : rpm-build  # rpm environment
  : sed   # basic shell env
  : shadow-utils
  : tar   # source extraction
  : unzip # source extraction
  : util-linux    # basic shell env
  : which # basic shell env. (command -v 
is more portable, but meh.)

  : xz    # source extraction



And there is this proposal to reduce the amount of compression libraries:

https://github.com/rpm-software-management/rpm/issues/1396

Actually, since RPM now uses `rpmuncompress` to extract the archives, it 
could also make sense to e.g. extract this utility into separate 
sub-package and move the extraction utilities out from the 
@buildsys-build. That would not reduce the the buildroot size at first, 
but get the dependencies to the right place for the start.




Doesn't work.

rpmuncompress doesn't know how to uncompress ANYTHING AT ALL by itself. 
It only knows which command(s) to call to do that.


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

Re: rich deps result in packages being uninstalled from buildroot

[Kevin Kofler via devel]

Neal Gompa wrote:
> I have the question of why is dnf5 running as if "--allow-erasing" is
> always passed to it? Older versions of DNF explicitly didn't do that
> because we get weird behaviors like this.

Without --allow-erasing (which was actually passed explicitly, as Petr Pisar 
pointed out), the intended resolution:
> a) install cargo-rpm-macros, python3, python3-libs, add-determinism, and
> remove add-determinism-nopython 
could also not possibly work because:
> remove add-determinism-nopython 

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

Re: rich deps result in packages being uninstalled from buildroot

[Vít Ondruch]

Dne 16. 05. 24 v 14:28 Zbigniew Jędrzejewski-Szmek napsal(a):

On Thu, May 16, 2024 at 01:14:16PM +0200, Petr Pisar wrote:

Proper solution is actually minimazing content of the minimal build root

Most of the packages in the buildroot are libraries, pulled in via
dependencies.

@buildsys-build group is:
Mandatory packages   : bash  # basic shell env
  : bzip2 # source extraction
  : coreutils # basic shell env
  : cpio  # source extraction
  : diffutils # source extraction
  : fedora-release-common   # rpm environment
  : findutils # basic shell env
  : gawk  # basic shell env
  : glibc-minimal-langpack  # we want this to avoid other 
langpacks
  : grep  # basic shell env
  : gzip  # source extraction
  : info
  : patch # source extraction
  : redhat-rpm-config  # rpm environment
  : rpm-build  # rpm environment
  : sed   # basic shell env
  : shadow-utils
  : tar   # source extraction
  : unzip # source extraction
  : util-linux# basic shell env
  : which # basic shell env. (command -v is more 
portable, but meh.)
  : xz# source extraction



And there is this proposal to reduce the amount of compression libraries:

https://github.com/rpm-software-management/rpm/issues/1396

Actually, since RPM now uses `rpmuncompress` to extract the archives, it 
could also make sense to e.g. extract this utility into separate 
sub-package and move the extraction utilities out from the 
@buildsys-build. That would not reduce the the buildroot size at first, 
but get the dependencies to the right place for the start.



Vít



Out of this list, I see only three candidates for removal:

1. info. This is presumably present for /usr/sbin/install-info.
It's a small package (360kB) and probably not worth the hassle to
remove. On my system, 472 rpms provide info files, and if we remove
it from the default set, we'd need to patch a huge amount of
packages to add it back to make the builds work.

2. util-linux. This could be replaced by util-linux-core. This
has a bunch of deps too, so it'd save some. util-linux has 95
binaries, and while _most_ of them have little use in a constrained
build environment, probably a few are used somewhere. So this
would need some investigation.

3. shadow-utils. It was added in:

commit 79e1728c1b9e9e98d2e38b1286d90d596f233a56
Author: Jesse Keating 
Date:   Tue Jan 15 15:31:27 2008 +

 Make sure shadow-utils makes it into a buildroot, or else mock will fail

It's been a while, and I doubt we actually need it. Maybe we could
drop that?

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


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

Re: rich deps result in packages being uninstalled from buildroot

[Zbigniew Jędrzejewski-Szmek]

On Thu, May 16, 2024 at 01:14:16PM +0200, Petr Pisar wrote:
> Proper solution is actually minimazing content of the minimal build root

Most of the packages in the buildroot are libraries, pulled in via
dependencies.

@buildsys-build group is:
Mandatory packages   : bash  # basic shell env
 : bzip2 # source extraction
 : coreutils # basic shell env
 : cpio  # source extraction
 : diffutils # source extraction
 : fedora-release-common   # rpm environment
 : findutils # basic shell env
 : gawk  # basic shell env
 : glibc-minimal-langpack  # we want this to avoid other 
langpacks
 : grep  # basic shell env
 : gzip  # source extraction
 : info
 : patch # source extraction
 : redhat-rpm-config  # rpm environment
 : rpm-build  # rpm environment
 : sed   # basic shell env
 : shadow-utils
 : tar   # source extraction
 : unzip # source extraction
 : util-linux# basic shell env
 : which # basic shell env. (command -v is more 
portable, but meh.)
 : xz# source extraction

Out of this list, I see only three candidates for removal:

1. info. This is presumably present for /usr/sbin/install-info.
   It's a small package (360kB) and probably not worth the hassle to
   remove. On my system, 472 rpms provide info files, and if we remove
   it from the default set, we'd need to patch a huge amount of
   packages to add it back to make the builds work.

2. util-linux. This could be replaced by util-linux-core. This
   has a bunch of deps too, so it'd save some. util-linux has 95
   binaries, and while _most_ of them have little use in a constrained
   build environment, probably a few are used somewhere. So this
   would need some investigation.

3. shadow-utils. It was added in:

   commit 79e1728c1b9e9e98d2e38b1286d90d596f233a56
   Author: Jesse Keating 
   Date:   Tue Jan 15 15:31:27 2008 +

Make sure shadow-utils makes it into a buildroot, or else mock will fail

   It's been a while, and I doubt we actually need it. Maybe we could
   drop that?

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

Re: rich deps result in packages being uninstalled from buildroot

[Petr Pisar]

V Thu, May 16, 2024 at 04:29:21AM -0600, Neal Gompa napsal(a):
> On Thu, May 16, 2024 at 3:10 AM Fabio Valentini  wrote:
> >
> > On Thu, May 16, 2024 at 9:25 AM Zbigniew Jędrzejewski-Szmek
> >  wrote:
> > >
> > > Hi,
> > >
> > > I've been trying to get 'add-determinism' deployed in buildroots. This
> > > has been unsuccessful because of the following issue.
> > >
> > > The dependency chain is:
> > > redhat-rpm-config has
> > >   Requires build-reproducibility-srpm-macros
> > > and build-reproducibility-srpm-macros has
> > >   Requires:(add-determinism if python3-libs else 
> > > add-determinism-nopython)
> > >   Suggests:add-determinism-nopython
> > >
> > > (The idea is that we install 'add-determinism-nopython' which is 
> > > self-contained,
> > > but if python3 is installed into the buildroot, we pull in the heavier 
> > > version
> > > which has a dependency on python3-libs.)
> > >
> > > This works well enough when installing packages using dnf on a test 
> > > system.
> > > But, in koji and mock builds, this results in rpm-build being unistalled 
> > > (!).
> > >
> > > For example, see 
> > > https://koji.fedoraproject.org/koji/taskinfo?taskID=117684626
> > > and root.log there: first rpm-build is installed along with a bunch of 
> > > other
> > > packages expected in the buildroot, but then cargo-rpm-macros is requested
> > > (presumably via %generate_buildrequires), which depends on python3 and
> > > python3-libs.
> > >
> > > Dnf5 realizes that to satisfy all bounds, it can either:
> > > a) install cargo-rpm-macros, python3, python3-libs, add-determinism, and 
> > > remove add-determinism-nopython
> > > b) install cargo-rpm-macros, python3, python3-libs, and remove 
> > > build-reproducibility-srpm-macros,
> > >rpm-build, fonts-srpm-macros, redhat-rpm-config, and a few other 
> > > packages.
> > > and picks option b).
> >
> > This looks like you're putting the resolver between a rock and a hard
> > place. :thinking:
> > I don't think I've ever seen packages being *removed* when installing
> > BuildRequires on top of the minimal buildroot ...
> >
> > Would it be possible to adapt the packages so that add-determinism and
> > add-determinism-nopython are parallel-installable, and have the macro
> > fall back to the add-determinism-nopython executable if the
> > add-determinism executable is not available?
> > That way BuildRequires are additive and wouldn't force package removal
> > from the buildroot, and the rich dependency could be simpler - i.e.
> > `Requires: (add-determinism if python3-libs)`, without Suggests or
> > else branch.
> 
> I have the question of why is dnf5 running as if "--allow-erasing" is
> always passed to it? Older versions of DNF explicitly didn't do that
> because we get weird behaviors like this.
> 
It's running as if --allow-erasing is passed because --allow-erasing was
passed:

DEBUG util.py:558:  Executing command: ['/usr/bin/systemd-nspawn', '-q', '-M', 
'de96c7c84e6d430584a7795d75824e1d', '-D', 
'/var/lib/mock/f41-build-50967284-6084889-bootstrap/root', '-a', 
'--capability=cap_ipc_lock', 
'--bind=/tmp/mock-resolv.1old43uf:/etc/resolv.conf', '--console=pipe', 
'--setenv=TERM=vt100', '--setenv=SHELL=/bin/bash', 
'--setenv=HOME=/var/lib/mock/f41-build-50967284-6084889/root/installation-homedir',
 '--setenv=HOSTNAME=mock', '--setenv=PATH=/usr/bin:/bin:/usr/sbin:/sbin', 
'--setenv=PROMPT_COMMAND=printf "\\033]0;\\007"', 
'--setenv=PS1= \\s-\\v\\$ ', '--setenv=LANG=C.UTF-8', 
'--setenv=LC_MESSAGES=C.UTF-8', '--resolv-conf=off', '/usr/bin/dnf5', 
'builddep', '--installroot', '/var/lib/mock/f41-build-50967284-6084889/root/', 
'/var/lib/mock/f41-build-50967284-6084889/root//builddir/build/SRPMS/rust-proc-macro2-diagnostics-0.10.1-1.fc41.src.rpm',
 '--setopt=deltarpm=False', '--setopt=allow_vendor_change=yes', 
'--allowerasing', '--setopt=tsflags=nocontexts'] with env {'TERM': 'vt100', 
'SHELL': '/bin/bash', 'HOME': 
'/var/lib/mock/f41-build-50967284-6084889/root/installation-homedir', 
'HOSTNAME': 'mock', 'PATH': '/usr/bin:/bin:/usr/sbin:/sbin', 'PROMPT_COMMAND': 
'printf "\\033]0;\\007"', 'PS1': ' \\s-\\v\\$ ', 
'LANG': 'C.UTF-8', 'LC_MESSAGES': 'C.UTF-8', 'SYSTEMD_NSPAWN_TMPFS_TMP': '0', 
'SYSTEMD_SECCOMP': '0'} and shell False
DEBUG util.py:463:  Updating and loading repositories:
DEBUG util.py:463:   build  100% | 118.4 KiB/s 
|   3.8 KiB |  00m00s
DEBUG util.py:463:  Repositories loaded.
DEBUG util.py:463:  Package   

Re: rich deps result in packages being uninstalled from buildroot

[Zbigniew Jędrzejewski-Szmek]

On Thu, May 16, 2024 at 11:09:01AM +0200, Fabio Valentini wrote:
> This looks like you're putting the resolver between a rock and a hard
> place. :thinking:
> I don't think I've ever seen packages being *removed* when installing
> BuildRequires on top of the minimal buildroot ...
> 
> Would it be possible to adapt the packages so that add-determinism and
> add-determinism-nopython are parallel-installable, and have the macro
> fall back to the add-determinism-nopython executable if the
> add-determinism executable is not available?
> That way BuildRequires are additive and wouldn't force package removal
> from the buildroot, and the rich dependency could be simpler - i.e.
> `Requires: (add-determinism if python3-libs)`, without Suggests or
> else branch.

Yeah, I think this is the most reasonable approach.
I'll push a build that does this shortly.

(I tried to test this locally with mock, with the additional packages
in a local repo. When I install everything in one go, things work as
expected. Why I try to check the original issue, and install packages
piecemeal, mock downgrades packages to fall back to the koji version
without dependencies, instead of installing the additional deps. In
koji, it'll only have one version of the package available, so
hopefully it'll pick addition instead of removals.)

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

Re: rich deps result in packages being uninstalled from buildroot

[Neal Gompa]

On Thu, May 16, 2024 at 3:10 AM Fabio Valentini  wrote:
>
> On Thu, May 16, 2024 at 9:25 AM Zbigniew Jędrzejewski-Szmek
>  wrote:
> >
> > Hi,
> >
> > I've been trying to get 'add-determinism' deployed in buildroots. This
> > has been unsuccessful because of the following issue.
> >
> > The dependency chain is:
> > redhat-rpm-config has
> >   Requires build-reproducibility-srpm-macros
> > and build-reproducibility-srpm-macros has
> >   Requires:(add-determinism if python3-libs else 
> > add-determinism-nopython)
> >   Suggests:add-determinism-nopython
> >
> > (The idea is that we install 'add-determinism-nopython' which is 
> > self-contained,
> > but if python3 is installed into the buildroot, we pull in the heavier 
> > version
> > which has a dependency on python3-libs.)
> >
> > This works well enough when installing packages using dnf on a test system.
> > But, in koji and mock builds, this results in rpm-build being unistalled 
> > (!).
> >
> > For example, see 
> > https://koji.fedoraproject.org/koji/taskinfo?taskID=117684626
> > and root.log there: first rpm-build is installed along with a bunch of other
> > packages expected in the buildroot, but then cargo-rpm-macros is requested
> > (presumably via %generate_buildrequires), which depends on python3 and
> > python3-libs.
> >
> > Dnf5 realizes that to satisfy all bounds, it can either:
> > a) install cargo-rpm-macros, python3, python3-libs, add-determinism, and 
> > remove add-determinism-nopython
> > b) install cargo-rpm-macros, python3, python3-libs, and remove 
> > build-reproducibility-srpm-macros,
> >    rpm-build, fonts-srpm-macros, redhat-rpm-config, and a few other 
> > packages.
> > and picks option b).
>
> This looks like you're putting the resolver between a rock and a hard
> place. :thinking:
> I don't think I've ever seen packages being *removed* when installing
> BuildRequires on top of the minimal buildroot ...
>
> Would it be possible to adapt the packages so that add-determinism and
> add-determinism-nopython are parallel-installable, and have the macro
> fall back to the add-determinism-nopython executable if the
> add-determinism executable is not available?
> That way BuildRequires are additive and wouldn't force package removal
> from the buildroot, and the rich dependency could be simpler - i.e.
> `Requires: (add-determinism if python3-libs)`, without Suggests or
> else branch.

I have the question of why is dnf5 running as if "--allow-erasing" is
always passed to it? Older versions of DNF explicitly didn't do that
because we get weird behaviors like this.




--
真実はいつも一つ！/ 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: rich deps result in packages being uninstalled from buildroot

[Fabio Valentini]

On Thu, May 16, 2024 at 9:25 AM Zbigniew Jędrzejewski-Szmek
 wrote:
>
> Hi,
>
> I've been trying to get 'add-determinism' deployed in buildroots. This
> has been unsuccessful because of the following issue.
>
> The dependency chain is:
> redhat-rpm-config has
>   Requires build-reproducibility-srpm-macros
> and build-reproducibility-srpm-macros has
>   Requires:(add-determinism if python3-libs else add-determinism-nopython)
>   Suggests:add-determinism-nopython
>
> (The idea is that we install 'add-determinism-nopython' which is 
> self-contained,
> but if python3 is installed into the buildroot, we pull in the heavier version
> which has a dependency on python3-libs.)
>
> This works well enough when installing packages using dnf on a test system.
> But, in koji and mock builds, this results in rpm-build being unistalled (!).
>
> For example, see https://koji.fedoraproject.org/koji/taskinfo?taskID=117684626
> and root.log there: first rpm-build is installed along with a bunch of other
> packages expected in the buildroot, but then cargo-rpm-macros is requested
> (presumably via %generate_buildrequires), which depends on python3 and
> python3-libs.
>
> Dnf5 realizes that to satisfy all bounds, it can either:
> a) install cargo-rpm-macros, python3, python3-libs, add-determinism, and 
> remove add-determinism-nopython
> b) install cargo-rpm-macros, python3, python3-libs, and remove 
> build-reproducibility-srpm-macros,
>rpm-build, fonts-srpm-macros, redhat-rpm-config, and a few other packages.
> and picks option b).

This looks like you're putting the resolver between a rock and a hard
place. :thinking:
I don't think I've ever seen packages being *removed* when installing
BuildRequires on top of the minimal buildroot ...

Would it be possible to adapt the packages so that add-determinism and
add-determinism-nopython are parallel-installable, and have the macro
fall back to the add-determinism-nopython executable if the
add-determinism executable is not available?
That way BuildRequires are additive and wouldn't force package removal
from the buildroot, and the rich dependency could be simpler - i.e.
`Requires: (add-determinism if python3-libs)`, without Suggests or
else branch.

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

rich deps result in packages being uninstalled from buildroot

[Zbigniew Jędrzejewski-Szmek]

Hi,

I've been trying to get 'add-determinism' deployed in buildroots. This
has been unsuccessful because of the following issue.

The dependency chain is:
redhat-rpm-config has
  Requires build-reproducibility-srpm-macros
and build-reproducibility-srpm-macros has
  Requires:(add-determinism if python3-libs else add-determinism-nopython)
  Suggests:add-determinism-nopython

(The idea is that we install 'add-determinism-nopython' which is self-contained,
but if python3 is installed into the buildroot, we pull in the heavier version
which has a dependency on python3-libs.)

This works well enough when installing packages using dnf on a test system.
But, in koji and mock builds, this results in rpm-build being unistalled (!).

For example, see https://koji.fedoraproject.org/koji/taskinfo?taskID=117684626
and root.log there: first rpm-build is installed along with a bunch of other
packages expected in the buildroot, but then cargo-rpm-macros is requested
(presumably via %generate_buildrequires), which depends on python3 and
python3-libs.

Dnf5 realizes that to satisfy all bounds, it can either:
a) install cargo-rpm-macros, python3, python3-libs, add-determinism, and remove 
add-determinism-nopython
b) install cargo-rpm-macros, python3, python3-libs, and remove 
build-reproducibility-srpm-macros,
   rpm-build, fonts-srpm-macros, redhat-rpm-config, and a few other packages.
and picks option b).

Without rpm-build installed, the build immediately faceplants.

(This can be reproduced by calling 'mock -i redhat-rpm-config' and
later 'mock -i cargo-rpm-macros'. It reproduces with both dnf5 and
dnf, so it's not a dnf5-related regresion.)

How to make this not happen, i.e. how to prevent rpm-build and other
packages that were explicitly pulled in via the @buildsys-build group
from being uninstalled? I think this is a general problem, not just
limited to the case described above. We now have hundreds of rich
Requires deps declared in packages, and each one creates the
possibility that dnf might opt to uninstall the package involved in
the rich dep, rather than installing the deps, if there is no
mechanism to prevent previously-explicitly-requested packges from
being removed.

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

Re: Smaller buildroot for Perl packages

[Frank Ch. Eigler]

Hi -

> > OK, build-time dependency changes may not need the side tag but do
> > need a spec update to prevent a FTBFS at next build.
> 
> Only those packages that actually need dtrace would require changes. Such
> changes could land gradually as needed.

They'd have to land at the next respin of each of those packages.

- FChE
--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/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: Smaller buildroot for Perl packages

[Miro Hrončok]

On 13. 05. 24 17:11, Frank Ch. Eigler wrote:

Hi -


I also did a test rebuild of all packages directly build-requiring
systemtap-sdt-devel and identified these packages that really need the
dtrace script: [...]

(The logistic challenge there will be side-tag rebuilding all those
after a systemtap subrpm split.)


I don't understand why that would be necessary. Could you please explain why
do you believe it would?


OK, build-time dependency changes may not need the side tag but do
need a spec update to prevent a FTBFS at next build.


Only those packages that actually need dtrace would require changes. Such 
changes could land gradually as needed.


--
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: Smaller buildroot for Perl packages

[Petr Pisar]

V Mon, May 13, 2024 at 11:11:05AM -0400, Frank Ch. Eigler napsal(a):
> > > > > I also did a test rebuild of all packages directly build-requiring
> > > > > systemtap-sdt-devel and identified these packages that really need the
> > > > > dtrace script: [...]
> > > (The logistic challenge there will be side-tag rebuilding all those
> > > after a systemtap subrpm split.)
> > 
> > I don't understand why that would be necessary. Could you please explain why
> > do you believe it would?
> 
> OK, build-time dependency changes may not need the side tag but do
> need a spec update to prevent a FTBFS at next build.
> 
I was more worried about these races: If you first add BuildRequies and then
the new package, there will be a window when the packages won't resolve build
dependencies. If you first add the new package and then the BuildRequiers,
then there will a window when the packages will fail to build.

This race can be solved by two separate changes in systemtap: First add the
new package and run-require it from systemtap-sdt-devel. Then add
the BuildRequires. And finally remove the run-time dependency from
systemtap-sdt-devel.

-- Petr


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

Re: Smaller buildroot for Perl packages

[Petr Pisar]

V Mon, May 13, 2024 at 04:14:53PM +0200, Vít Ondruch napsal(a):
> Dne 10. 05. 24 v 14:16 Petr Pisar napsal(a):
> > V Fri, May 10, 2024 at 01:13:53PM +0200, Lumír Balhar napsal(a):
> > > I also did a test rebuild of all packages directly build-requiring
> > > systemtap-sdt-devel and identified these packages that really need the
> > > dtrace script: glib2, sssd, qemu, python2.7, postgresql15, postgresql16,
> > > perl, php, mariadb10.11, and libvirt. Those would newly depend on a new
> > > package where we move the script to.
> > > 
[...]
> > Unanswered question is run-time dependencies. There might be packages which
> > run-require systemtap-sdt-devel because of dtrace executable:
> > 
> > # dnf -q -C repoquery --whatrequires systemtap-sdt-devel
> > lttng-ust-devel-0:2.13.8-1.fc41.x86_64
> > perl-devel-4:5.38.2-507.fc41.x86_64
> > systemtap-testsuite-0:5.1~pre17062192g5fd8daba-1.fc40.x86_64
> 
> 
> What about BuildRequires? Shouldn't they be included in your query?
> 
The original poster already checked the BuildRequires with a rebuild.

-- Petr


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

Re: Smaller buildroot for Perl packages

[Frank Ch. Eigler]

Hi -

> > > > I also did a test rebuild of all packages directly build-requiring
> > > > systemtap-sdt-devel and identified these packages that really need the
> > > > dtrace script: [...]
> > (The logistic challenge there will be side-tag rebuilding all those
> > after a systemtap subrpm split.)
> 
> I don't understand why that would be necessary. Could you please explain why
> do you believe it would?

OK, build-time dependency changes may not need the side tag but do
need a spec update to prevent a FTBFS at next build.

- FChE
--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/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: Smaller buildroot for Perl packages

[Vít Ondruch]

Dne 10. 05. 24 v 14:16 Petr Pisar napsal(a):

V Fri, May 10, 2024 at 01:13:53PM +0200, Lumír Balhar napsal(a):

I might have an idea how to make building Perl packages faster and their
buildroot a little bit smaller.

perl-devel depends on systemtap-sdt-devel and that package contains a single
script written in Python and using pycparser. The single script bring
python3-pycparser and therefore the whole Python with its standard library
to the buildroot of all perl packages although (according to my testing)
none of the packages needs it.

I've selected all packages build-requiring perl-devel but don't
build-requiring python-devel directly - 520 in total. And from that number:

  7  faild to build for unrelated reasons
  3  packages have python3-devel in buildroot (different reasons than
systempat-sdt-devel)
81  packages have python3-libs but not python3-devel (different reasons than
systempat-sdt-devel)

and finally, the rest - 436 packages - builds fine without the python script
in systemtap-sdt-devel and therefore without Python at all.

My idea is to split systemtap-sdt-devel into two packages: one with all the
content but without the python script (/usr/bin/dtrace) and a new one
containing only the mentioned script.

That would make buildroots for many packages smaller and their builds
faster.

I also did a test rebuild of all packages directly build-requiring
systemtap-sdt-devel and identified these packages that really need the
dtrace script: glib2, sssd, qemu, python2.7, postgresql15, postgresql16,
perl, php, mariadb10.11, and libvirt. Those would newly depend on a new
package where we move the script to.

What do you think about this idea? Is it worth writing a Fedora change for
it?


That looks like a great optimization from Perl point of view. It also seems
that only 10 components will need adjustments, so a self-contained Fedora
change should be enough.

Unanswered question is run-time dependencies. There might be packages which
run-require systemtap-sdt-devel because of dtrace executable:

# dnf -q -C repoquery --whatrequires systemtap-sdt-devel
lttng-ust-devel-0:2.13.8-1.fc41.x86_64
perl-devel-4:5.38.2-507.fc41.x86_64
systemtap-testsuite-0:5.1~pre17062192g5fd8daba-1.fc40.x86_64



What about BuildRequires? Shouldn't they be included in your query?

Vít


But probably the most important part is systemtap maintainer (CCed). Is he
fine with this change? Isn't this incompatible change too obstrusive for dtrace
users? I believe it isn't, otherwise dtrace would not be packaged in a -devel
package.

-- Petr

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


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

Re: Intention to take over orphaned packages: php-aws-sdk3, php-ralouphie-getallheaders, php-guzzlehttp-guzzle6

[Remi Collet]

Le 29/04/2024 à 11:32, domi...@wombacher.cc a écrit :

On 04/24/2024 4:21 PM CEST Remi Collet  wrote:



I suspect you may need awscrt extension which is quite
a nightmare as it bundles tons of libaws-*


You suspect right, "aws/aws-crt-php": "^1.2.3".


https://git.remirepo.net/cgit/rpms/php/pecl/php-pecl-awscrt.git/tree/


Wow cool, thanks for sharing. Is there a reasons you didn't use your package to 
create one for Fedora? It looks like you did all the heavy lifting already.

What I can already tell: I opened a can of worms with my wish to keep 
php-aws-sdk3 alive. It will be a challenge but a good learning opportunity too.


As I said, because of bundled libraries

And also lack or PHP reviewers
I already have tons of packages waiting for review for months

Remi
--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/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: Smaller buildroot for Perl packages

[Miro Hrončok]

On 10. 05. 24 17:16, Frank Ch. Eigler wrote:

[...]
I also did a test rebuild of all packages directly build-requiring
systemtap-sdt-devel and identified these packages that really need the
dtrace script: glib2, sssd, qemu, python2.7, postgresql15, postgresql16,
perl, php, mariadb10.11, and libvirt. Those would newly depend on a new
package where we move the script to.

(The logistic challenge there will be side-tag rebuilding all those
after a systemtap subrpm split.)


I don't understand why that would be necessary. Could you please explain why do 
you believe it would?


--
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: Smaller buildroot for Perl packages

[Zbigniew Jędrzejewski-Szmek]

On Fri, May 10, 2024 at 01:13:53PM +0200, Lumír Balhar wrote:
> My idea is to split systemtap-sdt-devel into two packages: one with all the
> content but without the python script (/usr/bin/dtrace) and a new one
> containing only the mentioned script.
+1

I think it's weird that a user program (/usr/bin/dtrace) is installed
in a package called *-devel. So I think it'd good to split it out to
a separate package even for that.

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

Re: Smaller buildroot for Perl packages

[Frank Ch. Eigler]

Hi -


> [...]
> > My idea is to split systemtap-sdt-devel into two packages: one with all the
> > content but without the python script (/usr/bin/dtrace) and a new one
> > containing only the mentioned script.

No objection here.


> > [...]
> > I also did a test rebuild of all packages directly build-requiring
> > systemtap-sdt-devel and identified these packages that really need the
> > dtrace script: glib2, sssd, qemu, python2.7, postgresql15, postgresql16,
> > perl, php, mariadb10.11, and libvirt. Those would newly depend on a new
> > package where we move the script to.

(The logistic challenge there will be side-tag rebuilding all those
after a systemtap subrpm split.)

How much time did excluding the python bits from the perl buildroot
actually save during your tests? 


> Unanswered question is run-time dependencies. There might be packages which
> run-require systemtap-sdt-devel because of dtrace executable:
> 
> # dnf -q -C repoquery --whatrequires systemtap-sdt-devel
> lttng-ust-devel-0:2.13.8-1.fc41.x86_64
> perl-devel-4:5.38.2-507.fc41.x86_64
> systemtap-testsuite-0:5.1~pre17062192g5fd8daba-1.fc40.x86_64

By default, these packages could inherit dependencies on both of the
split subrpms, until their respective packagers decide to analyze and
narrow it further down.

- FChE
--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/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: Smaller buildroot for Perl packages

[Petr Pisar]

V Fri, May 10, 2024 at 01:13:53PM +0200, Lumír Balhar napsal(a):
> I might have an idea how to make building Perl packages faster and their
> buildroot a little bit smaller.
> 
> perl-devel depends on systemtap-sdt-devel and that package contains a single
> script written in Python and using pycparser. The single script bring
> python3-pycparser and therefore the whole Python with its standard library
> to the buildroot of all perl packages although (according to my testing)
> none of the packages needs it.
> 
> I've selected all packages build-requiring perl-devel but don't
> build-requiring python-devel directly - 520 in total. And from that number:
> 
>  7  faild to build for unrelated reasons
>  3  packages have python3-devel in buildroot (different reasons than
> systempat-sdt-devel)
> 81  packages have python3-libs but not python3-devel (different reasons than
> systempat-sdt-devel)
> 
> and finally, the rest - 436 packages - builds fine without the python script
> in systemtap-sdt-devel and therefore without Python at all.
> 
> My idea is to split systemtap-sdt-devel into two packages: one with all the
> content but without the python script (/usr/bin/dtrace) and a new one
> containing only the mentioned script.
> 
> That would make buildroots for many packages smaller and their builds
> faster.
> 
> I also did a test rebuild of all packages directly build-requiring
> systemtap-sdt-devel and identified these packages that really need the
> dtrace script: glib2, sssd, qemu, python2.7, postgresql15, postgresql16,
> perl, php, mariadb10.11, and libvirt. Those would newly depend on a new
> package where we move the script to.
> 
> What do you think about this idea? Is it worth writing a Fedora change for
> it?
> 
That looks like a great optimization from Perl point of view. It also seems
that only 10 components will need adjustments, so a self-contained Fedora
change should be enough.

Unanswered question is run-time dependencies. There might be packages which
run-require systemtap-sdt-devel because of dtrace executable:

# dnf -q -C repoquery --whatrequires systemtap-sdt-devel
lttng-ust-devel-0:2.13.8-1.fc41.x86_64
perl-devel-4:5.38.2-507.fc41.x86_64
systemtap-testsuite-0:5.1~pre17062192g5fd8daba-1.fc40.x86_64

But probably the most important part is systemtap maintainer (CCed). Is he
fine with this change? Isn't this incompatible change too obstrusive for dtrace
users? I believe it isn't, otherwise dtrace would not be packaged in a -devel
package.

-- Petr


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

Smaller buildroot for Perl packages

[Lumír Balhar]

Hi.

I might have an idea how to make building Perl packages faster and their 
buildroot a little bit smaller.


perl-devel depends on systemtap-sdt-devel and that package contains a 
single script written in Python and using pycparser. The single script 
bring python3-pycparser and therefore the whole Python with its standard 
library to the buildroot of all perl packages although (according to my 
testing) none of the packages needs it.


I've selected all packages build-requiring perl-devel but don't 
build-requiring python-devel directly - 520 in total. And from that number:


 7  faild to build for unrelated reasons
 3  packages have python3-devel in buildroot (different reasons than 
systempat-sdt-devel)
81  packages have python3-libs but not python3-devel (different reasons 
than systempat-sdt-devel)


and finally, the rest - 436 packages - builds fine without the python 
script in systemtap-sdt-devel and therefore without Python at all.


My idea is to split systemtap-sdt-devel into two packages: one with all 
the content but without the python script (/usr/bin/dtrace) and a new 
one containing only the mentioned script.


That would make buildroots for many packages smaller and their builds 
faster.


I also did a test rebuild of all packages directly build-requiring 
systemtap-sdt-devel and identified these packages that really need the 
dtrace script: glib2, sssd, qemu, python2.7, postgresql15, postgresql16, 
perl, php, mariadb10.11, and libvirt. Those would newly depend on a new 
package where we move the script to.


What do you think about this idea? Is it worth writing a Fedora change 
for it?


Have a nice day.
Lumír
--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/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

F41 Change Proposal: Multiple Versioned CRI-O and CRI-Tools Packages (self-contained)

[Aoife Moloney]

This is a proposed Change for Fedora Linux.
This document represents a proposed Change. As part of the Changes
process, proposals are publicly announced in order to receive
community feedback. This proposal will only be implemented if approved
by the Fedora Engineering Steering Committee.

Wiki - https://fedoraproject.org/wiki/Changes/VersionedCRI-OandCRI-ToolsPackages
Discussion Thread -
https://discussion.fedoraproject.org/t/f41-change-proposal-multiple-versioned-cri-o-and-cri-tools-packages-self-contained/116526

== Summary ==
The installed versions of CRI-O and CRI-Tools are supposed to match
the version of Kubernetes that they are deployed with. FESCo recently
approved multiple, versioned packages for Kubernetes
(https://fedoraproject.org/wiki/Changes/VersionedKubernetesPackages).
This Change Request, if approved, will allow Fedora to also provide
matching versions of CRI-O and CRI-Tools for Kubernetes administrators
that use Fedora as the base machine OS.

== Owner ==
* Name: [[User:Buckaroogeek| Brad Smith]]
* Email: bradley.g.sm...@gmail.com

* Name: [[User:haircommander| Peter Hunt]]
* Email: peh...@redhat.com


== Detailed Description ==
Both CRI-O (https://src.fedoraproject.org/rpms/cri-o, upstream:
https://github.com/cri-o/cri-o) and CRI-Tools
(https://src.fedoraproject.org/rpms/cri-tools, upstream:
https://github.com/kubernetes-sigs/cri-tools) are designed to version
match the version of Kubernetes they are deployed with. Version
matching is a guarantee to Kubernetes administrators that these
components use the same API version of the target Kubernetes
installation.

Starting in Fedora 41, users will be able to install any supported
version of Kubernetes (typically 3 concurrent, supported versions)
using, for example, "dnf install kubernetes1.30". This Change, if
approved would allow the user to also install CRI-O and/or CRI-Tools
with the same version, i.e. "dnf install cri-o1.30 kubernetes1.30" or
"dnf install cri-tools1.30" to work with any version 1.30 CRI
(Container Runtime Interface) implementation.

CRI-O is a well-regarded CRI implementation. Each Kubernetes cluster
requires a CRI implementation such as cri-o to function. Alternatives
include containerd or Docker Engine among others.

CRI-Tools contains the crictl command line interface tool that
provides a CLI for CRI-compatible container runtimes. This allows the
CRI runtime developers to debug their runtime without needing to set
up Kubernetes components.

== Feedback ==
TBD

== Benefit to Fedora ==

Enthusiasts and kubernetes administrators and developers will have
access to the full stack of properly versioned components to install
and manage a Kubernetes cluster directly from Fedora repositories. All
supported versions of Kubernetes and related components such as CRI-O
and CRI-Tools will be available in each of the supported releases of
Fedora, starting with Fedora 41.

The past practice of tying a specific version of Kubernetes to a
release of Fedora created an unnecessary tight coupling between Fedora
and Kubernetes for cluster administrators and developers. In order to
change the version of either Kubernetes or Fedora, the version of the
other component also needed to change. This proposal provides changes
that finalize the uncoupling of Fedora releases and Kubernetes cluster
versions.

== Scope ==
* Proposal owners: Request appropriate src.fedoraproject.org
repositories from Fedora engineering and maintain those repositories.

* Policies and guidelines: N/A (not needed for this Change)

* Trademark approval: N/A (not needed for this Change)

* Alignment with the Fedora Strategy: This proposal enhances Fedora's
strengths in Technology and Innovation as it enhances the use of
Fedora to function as the machine OS for any supported version of
Kubernetes and as the administrator's workstation for all supported
Kubernetes clusters regardless of where the cluster is deployed.

== Upgrade/compatibility impact ==
The shift from the existing model to the versioned model could create
friction for current users of CRI-O or CRI-Tools on Fedora. Proper use
of Provides and Obsoletes in the spec files as well as a supporting
communication plan will help to reduce those complications.


== Early Testing (Optional) ==

Do you require 'QA Blueprint' support? N

== How To Test ==
# 1. Install a versioned CRI-O or CRI-Tools package on a fresh
instance of Fedora. Install should be error free.
# 2. On an existing Fedora machine, replace a non-versioned CRI-O or
CRI-Tools package with a versioned package. There should not be any
errors.



== User Experience ==
The user experience should remain unchanged except for the need to
select a specific version of CRI-O or CRI-Tools.




== Dependencies ==
No direct dependencies. If Kubernetes is installed and used then CRI-O
and Kubernetes should have the same major:minor version. As a command
line tool,  the version of CRI-Tools will be selected by the user
based on their s

F41 Change Proposal: Multiple Versioned CRI-O and CRI-Tools Packages (self-contained)

[Aoife Moloney]

This is a proposed Change for Fedora Linux.
This document represents a proposed Change. As part of the Changes
process, proposals are publicly announced in order to receive
community feedback. This proposal will only be implemented if approved
by the Fedora Engineering Steering Committee.

Wiki - https://fedoraproject.org/wiki/Changes/VersionedCRI-OandCRI-ToolsPackages
Discussion Thread -
https://discussion.fedoraproject.org/t/f41-change-proposal-multiple-versioned-cri-o-and-cri-tools-packages-self-contained/116526

== Summary ==
The installed versions of CRI-O and CRI-Tools are supposed to match
the version of Kubernetes that they are deployed with. FESCo recently
approved multiple, versioned packages for Kubernetes
(https://fedoraproject.org/wiki/Changes/VersionedKubernetesPackages).
This Change Request, if approved, will allow Fedora to also provide
matching versions of CRI-O and CRI-Tools for Kubernetes administrators
that use Fedora as the base machine OS.

== Owner ==
* Name: [[User:Buckaroogeek| Brad Smith]]
* Email: bradley.g.sm...@gmail.com

* Name: [[User:haircommander| Peter Hunt]]
* Email: peh...@redhat.com


== Detailed Description ==
Both CRI-O (https://src.fedoraproject.org/rpms/cri-o, upstream:
https://github.com/cri-o/cri-o) and CRI-Tools
(https://src.fedoraproject.org/rpms/cri-tools, upstream:
https://github.com/kubernetes-sigs/cri-tools) are designed to version
match the version of Kubernetes they are deployed with. Version
matching is a guarantee to Kubernetes administrators that these
components use the same API version of the target Kubernetes
installation.

Starting in Fedora 41, users will be able to install any supported
version of Kubernetes (typically 3 concurrent, supported versions)
using, for example, "dnf install kubernetes1.30". This Change, if
approved would allow the user to also install CRI-O and/or CRI-Tools
with the same version, i.e. "dnf install cri-o1.30 kubernetes1.30" or
"dnf install cri-tools1.30" to work with any version 1.30 CRI
(Container Runtime Interface) implementation.

CRI-O is a well-regarded CRI implementation. Each Kubernetes cluster
requires a CRI implementation such as cri-o to function. Alternatives
include containerd or Docker Engine among others.

CRI-Tools contains the crictl command line interface tool that
provides a CLI for CRI-compatible container runtimes. This allows the
CRI runtime developers to debug their runtime without needing to set
up Kubernetes components.

== Feedback ==
TBD

== Benefit to Fedora ==

Enthusiasts and kubernetes administrators and developers will have
access to the full stack of properly versioned components to install
and manage a Kubernetes cluster directly from Fedora repositories. All
supported versions of Kubernetes and related components such as CRI-O
and CRI-Tools will be available in each of the supported releases of
Fedora, starting with Fedora 41.

The past practice of tying a specific version of Kubernetes to a
release of Fedora created an unnecessary tight coupling between Fedora
and Kubernetes for cluster administrators and developers. In order to
change the version of either Kubernetes or Fedora, the version of the
other component also needed to change. This proposal provides changes
that finalize the uncoupling of Fedora releases and Kubernetes cluster
versions.

== Scope ==
* Proposal owners: Request appropriate src.fedoraproject.org
repositories from Fedora engineering and maintain those repositories.

* Policies and guidelines: N/A (not needed for this Change)

* Trademark approval: N/A (not needed for this Change)

* Alignment with the Fedora Strategy: This proposal enhances Fedora's
strengths in Technology and Innovation as it enhances the use of
Fedora to function as the machine OS for any supported version of
Kubernetes and as the administrator's workstation for all supported
Kubernetes clusters regardless of where the cluster is deployed.

== Upgrade/compatibility impact ==
The shift from the existing model to the versioned model could create
friction for current users of CRI-O or CRI-Tools on Fedora. Proper use
of Provides and Obsoletes in the spec files as well as a supporting
communication plan will help to reduce those complications.


== Early Testing (Optional) ==

Do you require 'QA Blueprint' support? N

== How To Test ==
# 1. Install a versioned CRI-O or CRI-Tools package on a fresh
instance of Fedora. Install should be error free.
# 2. On an existing Fedora machine, replace a non-versioned CRI-O or
CRI-Tools package with a versioned package. There should not be any
errors.



== User Experience ==
The user experience should remain unchanged except for the need to
select a specific version of CRI-O or CRI-Tools.




== Dependencies ==
No direct dependencies. If Kubernetes is installed and used then CRI-O
and Kubernetes should have the same major:minor version. As a command
line tool,  the version of CRI-Tools will be selected by the user
based on their s

Orphaned packages looking for new maintainers

[Maxwell G]

Report started at 2024-05-06 17:14:29 UTC

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

Note: If you received this mail directly you (co)maintain one of the affected
packages or a package that depends on one. Please adopt the affected package or
retire your depending package to avoid broken dependencies, otherwise your
package will be retired when the affected package gets retired.

Request package ownership via the *Take* button in the left column on
https://src.fedoraproject.org/rpms/

Full report available at:
https://a.gtmx.me/orphans/orphans.txt
grep it for your FAS username and follow the dependency chain.

For human readable dependency chains,
see https://packager-dashboard.fedoraproject.org/
For all orphaned packages,
see https://packager-dashboard.fedoraproject.org/orphan

Package  (co)maintainers   Status Change

bti   orphan   2 weeks ago  
container-workflow-tool   orphan   5 weeks ago  
emacs-htmlize orphan   6 weeks ago  
golang-github-elves-elvish@go-sig, orphan  2 weeks ago  
golang-github-xiaq-persistent @go-sig, orphan  2 weeks ago  
jolokia-jvm-agent orphan   4 weeks ago  
mingw-cppunit orphan   0 weeks ago  
mingw-freeimage   orphan   4 weeks ago  
mozilla-fira-fontsmaxamillion, orphan  0 weeks ago  
neofetch  orphan   0 weeks ago  
php-bantu-ini-get-wrapper adamwill, orphan 6 weeks ago  
php-christophwurst-id3parser  orphan   6 weeks ago  
php-deepdiver-zipstreamer orphan   6 weeks ago  
php-doctrine-dbal orphan, remi 6 weeks ago  
php-fgrosse-phpasn1   orphan   6 weeks ago  
php-giggsey-localeorphan   6 weeks ago  
php-league-uri-interfaces orphan   6 weeks ago  
php-opencloud-openstack   orphan   6 weeks ago  
php-opis-closure  orphan, remi 6 weeks ago  
php-pimpleorphan   6 weeks ago  
php-punic orphan   6 weeks ago  
php-scssphp   orphan   6 weeks ago  
php-stecman-symfony-console-  orphan   6 weeks ago  
completion  
prometheus-jmx-exporter   orphan   4 weeks ago  
prometheus-simpleclient-java  orphan   4 weeks ago  
python-jose   orphan   5 weeks ago  
rust-clap_lex @rust-sig, orphan0 weeks ago  
rust-digest_auth  @rust-sig, orphan0 weeks ago  
rust-lev_distance @rust-sig, orphan0 weeks ago  
rust-stratisd_proc_macros @rust-sig, bgurney, mulhern, 1 weeks ago  
  orphan
snakeyaml mizdebsk, orphan, sbluhm 4 weeks ago  
vim-editorconfig  orphan   4 weeks ago  
wdune orphan   1 weeks ago  

The following packages require above mentioned packages:
Depending on: golang-github-xiaq-persistent (1), status change: 2024-04-19 (2 
weeks ago)
golang-github-elves-elvish (maintained by: @go-sig, orphan)
golang-github-elves-elvish-0.15.0-11.fc40.src requires 
golang(github.com/xiaq/persistent/hash) = 0-0.12.20210113git3175cfb.fc40, 
golang(github.com/xiaq/persistent/hashmap) = 0-0.12.20210113git3175cfb.fc40, 
golang(github.com/xiaq/persistent/vector) = 0-0.12.20210113git3175cfb.fc40
golang-github-elves-elvish-devel-0.15.0-11.fc40.noarch requires 
golang(github.com/xiaq/persistent/hash) = 0-0.12.20210113git3175cfb.fc40, 
golang(github.com/xiaq/persistent/hashmap) = 0-0.12.20210113git3175cfb.fc40, 
golang(github.com/xiaq/persistent/vector) = 0-0.12.20210113git3175cfb.fc40

Depending on: mozilla-fira-fonts (1), status change: 2024-05-03 (0 weeks ago)
apostrophe (maintained by: atim

Orphaned packages looking for new maintainers

[Maxwell G]

Report started at 2024-04-27 20:06:57 UTC

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

Note: If you received this mail directly you (co)maintain one of the affected
packages or a package that depends on one. Please adopt the affected package or
retire your depending package to avoid broken dependencies, otherwise your
package will be retired when the affected package gets retired.

Request package ownership via the *Take* button in the left column on
https://src.fedoraproject.org/rpms/

Full report available at:
https://a.gtmx.me/orphans/orphans.txt
grep it for your FAS username and follow the dependency chain.

For human readable dependency chains,
see https://packager-dashboard.fedoraproject.org/
For all orphaned packages,
see https://packager-dashboard.fedoraproject.org/orphan

Package  (co)maintainers   Status Change

bamf  orphan   0 weeks ago  
bti   orphan   0 weeks ago  
container-workflow-tool   orphan   4 weeks ago  
emacs-htmlize orphan   5 weeks ago  
golang-github-elves-elvish@go-sig, orphan  1 weeks ago  
golang-github-xiaq-persistent @go-sig, orphan  1 weeks ago  
jolokia-jvm-agent orphan   2 weeks ago  
mingw-freeimage   orphan   2 weeks ago  
php-aws-sdk3  orphan   4 weeks ago  
php-bantu-ini-get-wrapper adamwill, orphan 4 weeks ago  
php-christophwurst-id3parser  orphan   4 weeks ago  
php-deepdiver-zipstreamer orphan   4 weeks ago  
php-doctrine-dbal orphan, remi 4 weeks ago  
php-fgrosse-phpasn1   orphan   4 weeks ago  
php-giggsey-localeorphan   4 weeks ago  
php-guzzlehttp-guzzle6orphan   4 weeks ago  
php-league-uri-interfaces orphan   4 weeks ago  
php-opencloud-openstack   orphan   4 weeks ago  
php-opis-closure  orphan, remi 4 weeks ago  
php-pimpleorphan   4 weeks ago  
php-punic orphan   4 weeks ago  
php-ralouphie-getallheaders   orphan   4 weeks ago  
php-scssphp   orphan   4 weeks ago  
php-stecman-symfony-console-  orphan   4 weeks ago  
completion  
prometheus-jmx-exporter   orphan   2 weeks ago  
prometheus-simpleclient-java  orphan   2 weeks ago  
python-jose   orphan   3 weeks ago  
rust-stratisd_proc_macros @rust-sig, bgurney, mulhern, 0 weeks ago  
  orphan
snakeyaml mizdebsk, orphan, sbluhm 2 weeks ago  
vim-editorconfig  orphan   3 weeks ago  
wdune orphan   0 weeks ago  

The following packages require above mentioned packages:
Depending on: bamf (16), status change: 2024-04-22 (0 weeks ago)
deepin-daemon (maintained by: @deepinde-sig, @go-sig, cheeselee, zsun)
deepin-daemon-5.14.44-8.fc40.x86_64 requires bamf-daemon = 
0.5.6-1.fc41, deepin-session-ui = 5.6.2-3.fc40

plank (maintained by: filiperosset)
plank-0.11.89-15.20210202.git013d051.fc40.src requires 
pkgconfig(libbamf3) = 0.5.6
plank-0.11.89-15.20210202.git013d051.fc40.x86_64 requires 
bamf-daemon = 0.5.6-1.fc41
plank-devel-0.11.89-15.20210202.git013d051.fc40.i686 requires 
pkgconfig(libbamf3) = 0.5.6
plank-devel-0.11.89-15.20210202.git013d051.fc40.x86_64 requires 
pkgconfig(libbamf3) = 0.5.6
plank-libs-0.11.89-15.20210202.git013d051.fc40.i686 requires 
libbamf3.so.2
plank-libs-0.11.89-15.20210202.git013d051.fc40.x86_64 requires 
libbamf3.so.2()(64bit)

deepin-calendar (maintained by: @deepinde-sig, cheeselee, felixonmars, 
zsun)
deepin-calendar-5.10.0-3.fc40.x86_64

Re: Ownership request for retired packages libtsm and kmscon

[Kevin Fenzi]

On Tue, May 07, 2024 at 08:59:26AM GMT, José Relvas via devel wrote:
> Hey folks,
> 
> `libtsm` was retired because it was orphaned. `kmscon` was retired because it 
> relied on this package.
> 
> I'm currently not in the "packagers" group, but I'm interested in taking 
> ownership of these packages and re-adding them to Fedora if I get sponsored.
> 
> Upstream has ceased development for both `libtsm` and `kmscon`, however, 
> they've been forked and continue to be well maintained:
> 
> -  `libtsm`: https://github.com/Aetf/libtsm
> -  `kmscon`: https://github.com/Aetf/kmscon
> 
> Among other improvements, the build system has been modernized (meson instead 
> of GNU autotools!) and dependencies have been cleaned up. Packaging these 
> forks should be significantly easier compared to the abandoned upstream.
> 
> I've done some testing locally and ran into no major issues, so I believe I'm 
> capable of handling packaging. I've experimented with sending a few PRs to 
> Fedora packages and I feel comfortable with RPM packaging now.
> 
> Please let me know if this is possible :)

I'd suggest submitting them for review. Since they are using a different
upstream and the buildsystem and other things have changed anyhow, a
review is probibly a good idea. Then, as part of that you can find a
sponsor...

https://docs.fedoraproject.org/en-US/package-maintainers/Joining_the_Package_Maintainers/

kevin


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

Re: RFC: Flaws detected by static analyzers in Fedora 41 Core Critical Path Packages

[Siteshwar Vashisht]

On Wed, Apr 24, 2024 at 6:26 PM Siteshwar Vashisht 
wrote:

> Hello,
>
> This is a follow up on my previous email[1] about OpenScanHub Prototype
> for Fedora.
> Thank you to those who have provided early feedback. Your help is truly
> appreciated!
>
> I am writing this message to get feedback from the community on possibly
> new defects identified by static analyzers in Core Critical Path packages
> that have changed in Fedora 41.
>
> TLDR: This report[2] contains 14188 identified defects. Please review the
> report and provide feedback.
>
> A mass scan was performed this week on the packages that have changed in
> Fedora 41. This report[2] contains all the new defects that have been
> identified in the core packages listed in Critical Path Packages. Please
> review the report and fix or report any defects to upstream that may be
> real bugs. Not all defects reported by OpenScanHub may be actual bugs, so
> please verify reported defects before investing time into fixing or
> reporting them. We hope this is helpful for the packages you maintain and
> for the upstream projects. Questions can be asked on the OpenScanHub
> mailing list[3]. If you want to see the full logs of the scans, they are
> available on the tasks[4] page. User documentation for performing a scan is
> available on the Fedora wiki[5].
>
> If the feedback on this report is positive, there may be a possibility of
> increasing the scope of scans to cover a wider range of packages.
>

I plan to perform another mass scan this month. Please provide any
feedback, if you missed this message earlier.


>
> Please remember this is currently an early production stage for
> OpenScanHub scanning. Constructive feedback is appreciated. Thank you!
>
> [1]
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/OMKLJFW4VC242QSA7R4KMGI6IGBT3YLM/
>
> [2] https://svashisht.fedorapeople.org/f41-22-Apr-2024/
>
> [3]
> https://lists.fedoraproject.org/archives/list/openscan...@lists.fedoraproject.org/
>
> [4] https://openscanhub.fedoraproject.org/task/
>
> [5] https://fedoraproject.org/wiki/OpenScanHub
>
--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/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

Ownership request for retired packages libtsm and kmscon

[José Relvas via devel]

Hey folks,

`libtsm` was retired because it was orphaned. `kmscon` was retired because it 
relied on this package.

I'm currently not in the "packagers" group, but I'm interested in taking 
ownership of these packages and re-adding them to Fedora if I get sponsored.

Upstream has ceased development for both `libtsm` and `kmscon`, however, 
they've been forked and continue to be well maintained:

-  `libtsm`: https://github.com/Aetf/libtsm
-  `kmscon`: https://github.com/Aetf/kmscon

Among other improvements, the build system has been modernized (meson instead 
of GNU autotools!) and dependencies have been cleaned up. Packaging these forks 
should be significantly easier compared to the abandoned upstream.

I've done some testing locally and ran into no major issues, so I believe I'm 
capable of handling packaging. I've experimented with sending a few PRs to 
Fedora packages and I feel comfortable with RPM packaging now.

Please let me know if this is possible :)

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

Orphaned packages looking for new maintainers

[Maxwell G]

Report started at 2024-05-06 17:14:29 UTC

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

Note: If you received this mail directly you (co)maintain one of the affected
packages or a package that depends on one. Please adopt the affected package or
retire your depending package to avoid broken dependencies, otherwise your
package will be retired when the affected package gets retired.

Request package ownership via the *Take* button in the left column on
https://src.fedoraproject.org/rpms/

Full report available at:
https://a.gtmx.me/orphans/orphans.txt
grep it for your FAS username and follow the dependency chain.

For human readable dependency chains,
see https://packager-dashboard.fedoraproject.org/
For all orphaned packages,
see https://packager-dashboard.fedoraproject.org/orphan

Package  (co)maintainers   Status Change

bti   orphan   2 weeks ago  
container-workflow-tool   orphan   5 weeks ago  
emacs-htmlize orphan   6 weeks ago  
golang-github-elves-elvish@go-sig, orphan  2 weeks ago  
golang-github-xiaq-persistent @go-sig, orphan  2 weeks ago  
jolokia-jvm-agent orphan   4 weeks ago  
mingw-cppunit orphan   0 weeks ago  
mingw-freeimage   orphan   4 weeks ago  
mozilla-fira-fontsmaxamillion, orphan  0 weeks ago  
neofetch  orphan   0 weeks ago  
php-bantu-ini-get-wrapper adamwill, orphan 6 weeks ago  
php-christophwurst-id3parser  orphan   6 weeks ago  
php-deepdiver-zipstreamer orphan   6 weeks ago  
php-doctrine-dbal orphan, remi 6 weeks ago  
php-fgrosse-phpasn1   orphan   6 weeks ago  
php-giggsey-localeorphan   6 weeks ago  
php-league-uri-interfaces orphan   6 weeks ago  
php-opencloud-openstack   orphan   6 weeks ago  
php-opis-closure  orphan, remi 6 weeks ago  
php-pimpleorphan   6 weeks ago  
php-punic orphan   6 weeks ago  
php-scssphp   orphan   6 weeks ago  
php-stecman-symfony-console-  orphan   6 weeks ago  
completion  
prometheus-jmx-exporter   orphan   4 weeks ago  
prometheus-simpleclient-java  orphan   4 weeks ago  
python-jose   orphan   5 weeks ago  
rust-clap_lex @rust-sig, orphan0 weeks ago  
rust-digest_auth  @rust-sig, orphan0 weeks ago  
rust-lev_distance @rust-sig, orphan0 weeks ago  
rust-stratisd_proc_macros @rust-sig, bgurney, mulhern, 1 weeks ago  
  orphan
snakeyaml mizdebsk, orphan, sbluhm 4 weeks ago  
vim-editorconfig  orphan   4 weeks ago  
wdune orphan   1 weeks ago  

The following packages require above mentioned packages:
Depending on: golang-github-xiaq-persistent (1), status change: 2024-04-19 (2 
weeks ago)
golang-github-elves-elvish (maintained by: @go-sig, orphan)
golang-github-elves-elvish-0.15.0-11.fc40.src requires 
golang(github.com/xiaq/persistent/hash) = 0-0.12.20210113git3175cfb.fc40, 
golang(github.com/xiaq/persistent/hashmap) = 0-0.12.20210113git3175cfb.fc40, 
golang(github.com/xiaq/persistent/vector) = 0-0.12.20210113git3175cfb.fc40
golang-github-elves-elvish-devel-0.15.0-11.fc40.noarch requires 
golang(github.com/xiaq/persistent/hash) = 0-0.12.20210113git3175cfb.fc40, 
golang(github.com/xiaq/persistent/hashmap) = 0-0.12.20210113git3175cfb.fc40, 
golang(github.com/xiaq/persistent/vector) = 0-0.12.20210113git3175cfb.fc40

Depending on: mozilla-fira-fonts (1), status change: 2024-05-03 (0 weeks ago)
apostrophe (maintained by: atim

Re: Orphaned packages looking for new maintainers

[Maxwell G]

On Fri May 3, 2024, Maxwell G wrote:
> Report started at 2024-04-27 20:06:57 UTC

Apologizes, I accidentally sent an outdated report. I will resend later
today.
--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/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

Orphaned packages looking for new maintainers

[Maxwell G]

Report started at 2024-04-27 20:06:57 UTC

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

Note: If you received this mail directly you (co)maintain one of the affected
packages or a package that depends on one. Please adopt the affected package or
retire your depending package to avoid broken dependencies, otherwise your
package will be retired when the affected package gets retired.

Request package ownership via the *Take* button in the left column on
https://src.fedoraproject.org/rpms/

Full report available at:
https://a.gtmx.me/orphans/orphans.txt
grep it for your FAS username and follow the dependency chain.

For human readable dependency chains,
see https://packager-dashboard.fedoraproject.org/
For all orphaned packages,
see https://packager-dashboard.fedoraproject.org/orphan

Package  (co)maintainers   Status Change

bamf  orphan   0 weeks ago  
bti   orphan   0 weeks ago  
container-workflow-tool   orphan   4 weeks ago  
emacs-htmlize orphan   5 weeks ago  
golang-github-elves-elvish@go-sig, orphan  1 weeks ago  
golang-github-xiaq-persistent @go-sig, orphan  1 weeks ago  
jolokia-jvm-agent orphan   2 weeks ago  
mingw-freeimage   orphan   2 weeks ago  
php-aws-sdk3  orphan   4 weeks ago  
php-bantu-ini-get-wrapper adamwill, orphan 4 weeks ago  
php-christophwurst-id3parser  orphan   4 weeks ago  
php-deepdiver-zipstreamer orphan   4 weeks ago  
php-doctrine-dbal orphan, remi 4 weeks ago  
php-fgrosse-phpasn1   orphan   4 weeks ago  
php-giggsey-localeorphan   4 weeks ago  
php-guzzlehttp-guzzle6orphan   4 weeks ago  
php-league-uri-interfaces orphan   4 weeks ago  
php-opencloud-openstack   orphan   4 weeks ago  
php-opis-closure  orphan, remi 4 weeks ago  
php-pimpleorphan   4 weeks ago  
php-punic orphan   4 weeks ago  
php-ralouphie-getallheaders   orphan   4 weeks ago  
php-scssphp   orphan   4 weeks ago  
php-stecman-symfony-console-  orphan   4 weeks ago  
completion  
prometheus-jmx-exporter   orphan   2 weeks ago  
prometheus-simpleclient-java  orphan   2 weeks ago  
python-jose   orphan   3 weeks ago  
rust-stratisd_proc_macros @rust-sig, bgurney, mulhern, 0 weeks ago  
  orphan
snakeyaml mizdebsk, orphan, sbluhm 2 weeks ago  
vim-editorconfig  orphan   3 weeks ago  
wdune orphan   0 weeks ago  

The following packages require above mentioned packages:
Depending on: bamf (16), status change: 2024-04-22 (0 weeks ago)
deepin-daemon (maintained by: @deepinde-sig, @go-sig, cheeselee, zsun)
deepin-daemon-5.14.44-8.fc40.x86_64 requires bamf-daemon = 
0.5.6-1.fc41, deepin-session-ui = 5.6.2-3.fc40

plank (maintained by: filiperosset)
plank-0.11.89-15.20210202.git013d051.fc40.src requires 
pkgconfig(libbamf3) = 0.5.6
plank-0.11.89-15.20210202.git013d051.fc40.x86_64 requires 
bamf-daemon = 0.5.6-1.fc41
plank-devel-0.11.89-15.20210202.git013d051.fc40.i686 requires 
pkgconfig(libbamf3) = 0.5.6
plank-devel-0.11.89-15.20210202.git013d051.fc40.x86_64 requires 
pkgconfig(libbamf3) = 0.5.6
plank-libs-0.11.89-15.20210202.git013d051.fc40.i686 requires 
libbamf3.so.2
plank-libs-0.11.89-15.20210202.git013d051.fc40.x86_64 requires 
libbamf3.so.2()(64bit)

deepin-calendar (maintained by: @deepinde-sig, cheeselee, felixonmars, 
zsun)
deepin-calendar-5.10.0-3.fc40.x86_64

[EPEL-devel] RFC: incompatible upgrade of catch for EPEL; packages that do not rebuild to be retargeted to catch2

[Michel Lind]

Dear all,

I plan to upgrade catch in epel8 and epel9 to the latest 3.5.4 from Fedora, and 
introduce catch2 for packages that are currently using EPEL's catch (v2) and 
won't rebuild against catch v3


❯ fedrq pkgs -P catch-devel -b epel8
catch-devel-2.13.8-1.el8.x86_64

❯ fedrq pkgs -P catch-devel -b epel9
catch-devel-2.13.8-2.el9.x86_64

Plan of action:
- this announcement
- start COPR repos
- rebuild Fedora's latest catch for epel9 and epel8 in the COPR repos
- rebuild Fedora's latest catch2 in the COPR repos
- rebuild dependent packages
- if any of them fail, switch to catch2 and try again

(until this point, nothing will be committed to dist-git or built - per the 
incompatible upgrade policy, I'm waiting for a week of discussion first)


- build new catch and catch2 in side tag
- submit PRs to packages that need change, with instructions on how to build 
against the side tag

- merge and build the unbuilt packages with provenpackager after another week

The list of potentially affected packages:

❯ fedrq whatrequires --src -P catch-devel -b epel8
cppzmq-4.4.1-1.el8.src
et-6.2.1-2.el8.src
flamethrower-0.11.0-7.el8.src
gulrak-filesystem-1.5.14-1.el8.src
rttr-0.9.6-3.el8.src

❯ fedrq whatrequires --src -P catch-devel -b epel9
Pencil2D-0.6.6-24.el9.src
cli11-2.2.0-1.el9.src
cppzmq-4.8.1-2.el9.src
et-6.2.1-2.el9.src
gulrak-filesystem-1.5.14-1.el9.src
libopenshot-0.3.2-1.el9.src
rttr-0.9.7-0.1git7edbd58.el9.src
spdlog-1.10.0-1.el9.src
tomlplusplus-3.4.0-1.el9.src

Best regards,

--
 _o) Michel Lind
_( ) identities: https://keyoxide.org/5dce2e7e9c3b1cffd335c1d78b229d2f7ccc04f2


OpenPGP_0x8B229D2F7CCC04F2.asc
Description: OpenPGP public key


OpenPGP_signature.asc
Description: OpenPGP digital signature
--
___
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: Intention to take over orphaned packages: php-aws-sdk3, php-ralouphie-getallheaders, php-guzzlehttp-guzzle6

[dominik]

> On 04/24/2024 4:21 PM CEST Remi Collet  wrote:
> 
> I can probably help for PHP reviews

Thank you, appreciated!

> Notice:
> 
> - php-ralouphie-getallheaders: this is a compat layer  providing a 
> missing function in PHP < 7.3 for php-fpm users
> 
> Please check you really still need it ;)

Good point, that dependency comes from php-guzzlehttp-psr7 which still depends 
on php-ralouphie-getallheaders even in newer versions :-/ 

> - php-guzzlehttp-guzzle6: this was version 6
> 
> A new package is probably needed for version 7
> 
> See https://bugzilla.redhat.com/show_bug.cgi?id=1982627
> (this stalled review was for 7.3.0, current is 7.8.1)

Right and aws-sdk-php seem to be fine with guzzlehttp/guzzle ^7.4.5 but as you 
stated, not packaged in Fedora yet.

> - php-aws-sdk3: is really outdated (3.191.10 => 3.305.1)
> 
> New version probably have different dependencies

Yeah going through them right now to get an understanding what current 
dependencies are missing in Fedora.

> I suspect you may need awscrt extension which is quite
> a nightmare as it bundles tons of libaws-*

You suspect right, "aws/aws-crt-php": "^1.2.3".

> https://git.remirepo.net/cgit/rpms/php/pecl/php-pecl-awscrt.git/tree/

Wow cool, thanks for sharing. Is there a reasons you didn't use your package to 
create one for Fedora? It looks like you did all the heavy lifting already.

What I can already tell: I opened a can of worms with my wish to keep 
php-aws-sdk3 alive. It will be a challenge but a good learning opportunity too.


Dom


--
The Wombelix Post
https://dominik.wombacher.cc
--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/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: RFC: Flaws detected by static analyzers in Fedora 41 Core Critical Path Packages

[Siteshwar Vashisht]

On Thu, Apr 25, 2024 at 2:18 AM Carlos Rodriguez-Fernandez <
carlosrodrifernan...@gmail.com> wrote:

> Actually, I see what the problem is.
>
> The task is for 2.69-8 [1], but the subtask runs for 2.69-3 first to
> then have a reference for the diff. So I guess it will work next time a
> new version of libcap goes out.
>

`koji latest-build f40 libcap` gives me: libcap-2.69-3.fc40

I used the mock profile from Fedora 41 to do the build, so probably that
caused the build failure.


>
> [1] https://openscanhub.fedoraproject.org/task/83/
>
> On 4/24/24 17:11, Carlos Rodriguez-Fernandez wrote:
> > Hi Siteshwar,
> >
> > Thank you for the report. The libcap subtask failed [1] for a known
> > issue, which is present in libcap 2.69-3 in Fedora rawhide, but was
> > already fixed two weeks ago. Fedora rawhide has 2.69-8, and I can
> > confirm it is the case when I run the fedora:41 images. 2.69-8 should
> > have been in the mirrors for more than one week. I'm surprised it wasn't
> > picked up when this report was run. Will the report be rerun eventually
> > with an updated version of Fedora 41?
> >
> > Thank you,
> > Carlos R.F.
> >
> > [1] https://openscanhub.fedoraproject.org/task/135/log/stdout.log
> >
> >
> > On 4/24/24 09:26, Siteshwar Vashisht wrote:
> >> Hello,
> >>
> >> This is a follow up on my previous email[1] about OpenScanHub
> >> Prototype for Fedora.
> >> Thank you to those who have provided early feedback. Your help is
> >> truly appreciated!
> >>
> >> I am writing this message to get feedback from the community on
> >> possibly new defects identified by static analyzers in Core Critical
> >> Path packages that have changed in Fedora 41.
> >>
> >> TLDR: This report[2] contains 14188 identified defects. Please review
> >> the report and provide feedback.
> >>
> >> A mass scan was performed this week on the packages that have changed
> >> in Fedora 41. This report[2] contains all the new defects that have
> >> been identified in the core packages listed in Critical Path Packages.
> >> Please review the report and fix or report any defects to upstream
> >> that may be real bugs. Not all defects reported by OpenScanHub may be
> >> actual bugs, so please verify reported defects before investing time
> >> into fixing or reporting them. We hope this is helpful for the
> >> packages you maintain and for the upstream projects. Questions can be
> >> asked on the OpenScanHub mailing list[3]. If you want to see the full
> >> logs of the scans, they are available on the tasks[4] page. User
> >> documentation for performing a scan is available on the Fedora wiki[5].
> >>
> >> If the feedback on this report is positive, there may be a possibility
> >> of increasing the scope of scans to cover a wider range of packages.
> >>
> >> Please remember this is currently an early production stage for
> >> OpenScanHub scanning. Constructive feedback is appreciated. Thank you!
> >>
> >> [1]
> >>
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/OMKLJFW4VC242QSA7R4KMGI6IGBT3YLM/
> <
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/OMKLJFW4VC242QSA7R4KMGI6IGBT3YLM/
> >
> >>
> >> [2] https://svashisht.fedorapeople.org/f41-22-Apr-2024/
> >> <https://svashisht.fedorapeople.org/f41-22-Apr-2024/>
> >>
> >> [3]
> >>
> https://lists.fedoraproject.org/archives/list/openscan...@lists.fedoraproject.org/
> <
> https://lists.fedoraproject.org/archives/list/openscan...@lists.fedoraproject.org/
> >
> >>
> >> [4] https://openscanhub.fedoraproject.org/task/
> >> <https://openscanhub.fedoraproject.org/task/>
> >>
> >> [5] https://fedoraproject.org/wiki/OpenScanHub
> >> <https://fedoraproject.org/wiki/OpenScanHub>
> >>
> >> --
> >> ___
> >> devel mailing list -- devel@lists.fedoraproject.org
> >> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> >> Fedora Code of Conduct:
> >> https://docs.fedoraproject.org/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/ne

Re: RFC: Flaws detected by static analyzers in Fedora 41 Core Critical Path Packages

[Siteshwar Vashisht]

On Thu, Apr 25, 2024 at 2:12 AM Carlos Rodriguez-Fernandez <
carlosrodrifernan...@gmail.com> wrote:

> Hi Siteshwar,
>
> Thank you for the report. The libcap subtask failed [1] for a known
> issue, which is present in libcap 2.69-3 in Fedora rawhide, but was
> already fixed two weeks ago. Fedora rawhide has 2.69-8, and I can
> confirm it is the case when I run the fedora:41 images. 2.69-8 should
> have been in the mirrors for more than one week. I'm surprised it wasn't
> picked up when this report was run. Will the report be rerun eventually
> with an updated version of Fedora 41?
>

I plan to run the mass scans again based on the feedback from the
community. Although, I do not have a timeline for that. I would appreciate
any suggestions on when it fits in the Fedora release schedule to run a
mass scan.


>
> Thank you,
> Carlos R.F.
>
> [1] https://openscanhub.fedoraproject.org/task/135/log/stdout.log
>
>
> On 4/24/24 09:26, Siteshwar Vashisht wrote:
> > Hello,
> >
> > This is a follow up on my previous email[1] about OpenScanHub Prototype
> > for Fedora.
> > Thank you to those who have provided early feedback. Your help is truly
> > appreciated!
> >
> > I am writing this message to get feedback from the community on possibly
> > new defects identified by static analyzers in Core Critical Path
> > packages that have changed in Fedora 41.
> >
> > TLDR: This report[2] contains 14188 identified defects. Please review
> > the report and provide feedback.
> >
> > A mass scan was performed this week on the packages that have changed in
> > Fedora 41. This report[2] contains all the new defects that have been
> > identified in the core packages listed in Critical Path Packages. Please
> > review the report and fix or report any defects to upstream that may be
> > real bugs. Not all defects reported by OpenScanHub may be actual bugs,
> > so please verify reported defects before investing time into fixing or
> > reporting them. We hope this is helpful for the packages you maintain
> > and for the upstream projects. Questions can be asked on the OpenScanHub
> > mailing list[3]. If you want to see the full logs of the scans, they are
> > available on the tasks[4] page. User documentation for performing a scan
> > is available on the Fedora wiki[5].
> >
> > If the feedback on this report is positive, there may be a possibility
> > of increasing the scope of scans to cover a wider range of packages.
> >
> > Please remember this is currently an early production stage for
> > OpenScanHub scanning. Constructive feedback is appreciated. Thank you!
> >
> > [1]
> >
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/OMKLJFW4VC242QSA7R4KMGI6IGBT3YLM/
> <
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/OMKLJFW4VC242QSA7R4KMGI6IGBT3YLM/
> >
> >
> > [2] https://svashisht.fedorapeople.org/f41-22-Apr-2024/
> > <https://svashisht.fedorapeople.org/f41-22-Apr-2024/>
> >
> > [3]
> >
> https://lists.fedoraproject.org/archives/list/openscan...@lists.fedoraproject.org/
> <
> https://lists.fedoraproject.org/archives/list/openscan...@lists.fedoraproject.org/
> >
> >
> > [4] https://openscanhub.fedoraproject.org/task/
> > <https://openscanhub.fedoraproject.org/task/>
> >
> > [5] https://fedoraproject.org/wiki/OpenScanHub
> > <https://fedoraproject.org/wiki/OpenScanHub>
> >
> > --
> > ___
> > devel mailing list -- devel@lists.fedoraproject.org
> > To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> > Fedora Code of Conduct:
> https://docs.fedoraproject.org/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: RFC: Flaws detected by static analyzers in Fedora 41 Core Critical Path Packages

[Carlos Rodriguez-Fernandez]

Actually, I see what the problem is.

The task is for 2.69-8 [1], but the subtask runs for 2.69-3 first to 
then have a reference for the diff. So I guess it will work next time a 
new version of libcap goes out.


[1] https://openscanhub.fedoraproject.org/task/83/

On 4/24/24 17:11, Carlos Rodriguez-Fernandez wrote:

Hi Siteshwar,

Thank you for the report. The libcap subtask failed [1] for a known 
issue, which is present in libcap 2.69-3 in Fedora rawhide, but was 
already fixed two weeks ago. Fedora rawhide has 2.69-8, and I can 
confirm it is the case when I run the fedora:41 images. 2.69-8 should 
have been in the mirrors for more than one week. I'm surprised it wasn't 
picked up when this report was run. Will the report be rerun eventually 
with an updated version of Fedora 41?


Thank you,
Carlos R.F.

[1] https://openscanhub.fedoraproject.org/task/135/log/stdout.log


On 4/24/24 09:26, Siteshwar Vashisht wrote:

Hello,

This is a follow up on my previous email[1] about OpenScanHub 
Prototype for Fedora.
Thank you to those who have provided early feedback. Your help is 
truly appreciated!


I am writing this message to get feedback from the community on 
possibly new defects identified by static analyzers in Core Critical 
Path packages that have changed in Fedora 41.


TLDR: This report[2] contains 14188 identified defects. Please review 
the report and provide feedback.


A mass scan was performed this week on the packages that have changed 
in Fedora 41. This report[2] contains all the new defects that have 
been identified in the core packages listed in Critical Path Packages. 
Please review the report and fix or report any defects to upstream 
that may be real bugs. Not all defects reported by OpenScanHub may be 
actual bugs, so please verify reported defects before investing time 
into fixing or reporting them. We hope this is helpful for the 
packages you maintain and for the upstream projects. Questions can be 
asked on the OpenScanHub mailing list[3]. If you want to see the full 
logs of the scans, they are available on the tasks[4] page. User 
documentation for performing a scan is available on the Fedora wiki[5].


If the feedback on this report is positive, there may be a possibility 
of increasing the scope of scans to cover a wider range of packages.


Please remember this is currently an early production stage for 
OpenScanHub scanning. Constructive feedback is appreciated. Thank you!


[1] 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/OMKLJFW4VC242QSA7R4KMGI6IGBT3YLM/ <https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/OMKLJFW4VC242QSA7R4KMGI6IGBT3YLM/>


[2] https://svashisht.fedorapeople.org/f41-22-Apr-2024/ 
<https://svashisht.fedorapeople.org/f41-22-Apr-2024/>


[3] 
https://lists.fedoraproject.org/archives/list/openscan...@lists.fedoraproject.org/ <https://lists.fedoraproject.org/archives/list/openscan...@lists.fedoraproject.org/>


[4] https://openscanhub.fedoraproject.org/task/ 
<https://openscanhub.fedoraproject.org/task/>


[5] https://fedoraproject.org/wiki/OpenScanHub 
<https://fedoraproject.org/wiki/OpenScanHub>


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


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

Re: RFC: Flaws detected by static analyzers in Fedora 41 Core Critical Path Packages

[Carlos Rodriguez-Fernandez]

Hi Siteshwar,

Thank you for the report. The libcap subtask failed [1] for a known 
issue, which is present in libcap 2.69-3 in Fedora rawhide, but was 
already fixed two weeks ago. Fedora rawhide has 2.69-8, and I can 
confirm it is the case when I run the fedora:41 images. 2.69-8 should 
have been in the mirrors for more than one week. I'm surprised it wasn't 
picked up when this report was run. Will the report be rerun eventually 
with an updated version of Fedora 41?


Thank you,
Carlos R.F.

[1] https://openscanhub.fedoraproject.org/task/135/log/stdout.log


On 4/24/24 09:26, Siteshwar Vashisht wrote:

Hello,

This is a follow up on my previous email[1] about OpenScanHub Prototype 
for Fedora.
Thank you to those who have provided early feedback. Your help is truly 
appreciated!


I am writing this message to get feedback from the community on possibly 
new defects identified by static analyzers in Core Critical Path 
packages that have changed in Fedora 41.


TLDR: This report[2] contains 14188 identified defects. Please review 
the report and provide feedback.


A mass scan was performed this week on the packages that have changed in 
Fedora 41. This report[2] contains all the new defects that have been 
identified in the core packages listed in Critical Path Packages. Please 
review the report and fix or report any defects to upstream that may be 
real bugs. Not all defects reported by OpenScanHub may be actual bugs, 
so please verify reported defects before investing time into fixing or 
reporting them. We hope this is helpful for the packages you maintain 
and for the upstream projects. Questions can be asked on the OpenScanHub 
mailing list[3]. If you want to see the full logs of the scans, they are 
available on the tasks[4] page. User documentation for performing a scan 
is available on the Fedora wiki[5].


If the feedback on this report is positive, there may be a possibility 
of increasing the scope of scans to cover a wider range of packages.


Please remember this is currently an early production stage for 
OpenScanHub scanning. Constructive feedback is appreciated. Thank you!


[1] 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/OMKLJFW4VC242QSA7R4KMGI6IGBT3YLM/ <https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/OMKLJFW4VC242QSA7R4KMGI6IGBT3YLM/>


[2] https://svashisht.fedorapeople.org/f41-22-Apr-2024/ 
<https://svashisht.fedorapeople.org/f41-22-Apr-2024/>


[3] 
https://lists.fedoraproject.org/archives/list/openscan...@lists.fedoraproject.org/ <https://lists.fedoraproject.org/archives/list/openscan...@lists.fedoraproject.org/>


[4] https://openscanhub.fedoraproject.org/task/ 
<https://openscanhub.fedoraproject.org/task/>


[5] https://fedoraproject.org/wiki/OpenScanHub 
<https://fedoraproject.org/wiki/OpenScanHub>


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


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

RFC: Flaws detected by static analyzers in Fedora 41 Core Critical Path Packages

[Siteshwar Vashisht]

Hello,

This is a follow up on my previous email[1] about OpenScanHub Prototype for
Fedora.
Thank you to those who have provided early feedback. Your help is truly
appreciated!

I am writing this message to get feedback from the community on possibly
new defects identified by static analyzers in Core Critical Path packages
that have changed in Fedora 41.

TLDR: This report[2] contains 14188 identified defects. Please review the
report and provide feedback.

A mass scan was performed this week on the packages that have changed in
Fedora 41. This report[2] contains all the new defects that have been
identified in the core packages listed in Critical Path Packages. Please
review the report and fix or report any defects to upstream that may be
real bugs. Not all defects reported by OpenScanHub may be actual bugs, so
please verify reported defects before investing time into fixing or
reporting them. We hope this is helpful for the packages you maintain and
for the upstream projects. Questions can be asked on the OpenScanHub
mailing list[3]. If you want to see the full logs of the scans, they are
available on the tasks[4] page. User documentation for performing a scan is
available on the Fedora wiki[5].

If the feedback on this report is positive, there may be a possibility of
increasing the scope of scans to cover a wider range of packages.

Please remember this is currently an early production stage for OpenScanHub
scanning. Constructive feedback is appreciated. Thank you!

[1]
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/OMKLJFW4VC242QSA7R4KMGI6IGBT3YLM/

[2] https://svashisht.fedorapeople.org/f41-22-Apr-2024/

[3]
https://lists.fedoraproject.org/archives/list/openscan...@lists.fedoraproject.org/

[4] https://openscanhub.fedoraproject.org/task/

[5] https://fedoraproject.org/wiki/OpenScanHub
--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/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: Intention to take over orphaned packages: php-aws-sdk3, php-ralouphie-getallheaders, php-guzzlehttp-guzzle6

[Remi Collet]

Le 24/04/2024 à 11:41, domi...@wombacher.cc a écrit :


I'm not in the packager group yet and looking for a Sponsor to completed the 
onboarding process.
Afterwards I want to become the maintainer of the orphaned packages 
php-aws-sdk3 [1], php-ralouphie-getallheaders [2] and php-guzzlehttp-guzzle6 
[3].
My main motivation is to keep the php-aws-sdk3 package alive.
The other two are orphaned dependencies that I'm willing to adopt too.


I can probably help for PHP reviews

Notice:

- php-ralouphie-getallheaders: this is a compat layer  providing a 
missing function in PHP < 7.3 for php-fpm users


Please check you really still need it ;)

- php-guzzlehttp-guzzle6: this was version 6

A new package is probably needed for version 7

See https://bugzilla.redhat.com/show_bug.cgi?id=1982627
(this stalled review was for 7.3.0, current is 7.8.1)

- php-aws-sdk3: is really outdated (3.191.10 => 3.305.1)

New version probably have different dependencies

I suspect you may need awscrt extension which is quite
a nightmare as it bundles tons of libaws-*

https://git.remirepo.net/cgit/rpms/php/pecl/php-pecl-awscrt.git/tree/



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

Intention to take over orphaned packages: php-aws-sdk3, php-ralouphie-getallheaders, php-guzzlehttp-guzzle6

[dominik]

Hi everyone,

I'm not in the packager group yet and looking for a Sponsor to completed the 
onboarding process. 
Afterwards I want to become the maintainer of the orphaned packages 
php-aws-sdk3 [1], php-ralouphie-getallheaders [2] and php-guzzlehttp-guzzle6 
[3]. 
My main motivation is to keep the php-aws-sdk3 package alive. 
The other two are orphaned dependencies that I'm willing to adopt too.

The review for my first Fedora package is ongoing [4]. 
If you want to learn more about me, I did send a self introduction recently [5].

I'm also interested to co-maintain ec2-hibinit-agent [6] and talked with 
maintainer davdunc [7] about it. 
He's happy to get a co-maintainer but all boils down that I'm not in the 
packager group yet.

I'm looking for guidance what's the best way forward. 
Should I raising an issue at packager-sponsors [8]?
Or reach out to active sponsors [9] directly?

Dom


[1] https://src.fedoraproject.org/rpms/php-aws-sdk3
[2] https://src.fedoraproject.org/rpms/php-ralouphie-getallheaders
[3] https://src.fedoraproject.org/rpms/php-guzzlehttp-guzzle6
[4] https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=2274150
[5] 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/ER3GG2A7Z4ZLSHDB4NHDLIAZCY4P6WDD/
[6] https://src.fedoraproject.org/rpms/ec2-hibinit-agent
[7] https://src.fedoraproject.org/user/davdunc
[8] https://pagure.io/packager-sponsors/issues
[9] https://docs.pagure.org/fedora-sponsors/active


--
The Wombelix Post
https://dominik.wombacher.cc
--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/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: Orphaning my packages: elvish, git-delta & dependencies

[Felix Wang]

Thanks, I opened a re-review request of elvish to follow package renaming 
process [1].
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=2276356

[1] 
https://docs.fedoraproject.org/en-US/package-maintainers/Package_Renaming_Process/
--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/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: Orphaning my packages: elvish, git-delta & dependencies

[Mikel Olasagasti]

Hau idatzi du Felix Wang (topa...@outlook.com) erabiltzaileak (2024
api. 22(a), al. (03:57)):
>
> I'd like to take elvish package,

Current package golang-github-elves-elvish should be replaced by a new
one[1], set correct Obsoletes tag and retired. The name and goipath
are not correct anymore.a

> and I filed a review request of golang-pkg-nimblebun-lsp, which it is a 
> dependency of elvish.
> I would be grateful If you can take the review, or I can do the review swap 
> if am familiar the knowledge with it.
> https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=2276326

Approved.

[1] 
https://download.copr.fedorainfracloud.org/results/mikelo2/elvish/fedora-rawhide-x86_64/07333485-elvish/elvish.spec
plus the Obsoletes should be OK for the review.
--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/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: Orphaning my packages: elvish, git-delta & dependencies

[Felix Wang]

I'd like to take elvish package, and I filed a review request of 
golang-pkg-nimblebun-lsp, which it is a dependency of elvish.
I would be grateful If you can take the review, or I can do the review swap if 
am familiar the knowledge with it.
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=2276326
--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/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: Orphaning my packages: elvish, git-delta & dependencies

[Mikel Olasagasti]

Hau idatzi du Janet Black (uhh...@gmail.com) erabiltzaileak (2024 api.
19(a), or. (21:06)):
>
> Hi, I do not have the time to contribute packages to Fedora these days.

Thanks for your work Janet.

> I am orphaning the following packages under my maintainership:
> - golang-github-elves-elvish

I can't take it and not an user of elvish, but if someone wants to
jump in I've created a copr with updated spec (and required extra dep)
to help anyone interested.

https://copr.fedorainfracloud.org/coprs/mikelo2/elvish/

> - golang-github-xiaq-persistent

Not needed by newer elvish versions.

---
Mikel
--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/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: Orphaning my packages: elvish, git-delta & dependencies

[Fabio Valentini]

On Fri, Apr 19, 2024 at 9:06 PM Janet Black  wrote:
>
> Hi, I do not have the time to contribute packages to Fedora these days.
>
> I am orphaning the following packages under my maintainership:
> - golang-github-elves-elvish
> - golang-github-xiaq-persistent
> - rust-box_drawing
> - rust-git-delta

I'll take the two Rust packages for now. Thank you for the notification!

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

Orphaning my packages: elvish, git-delta & dependencies

[Janet Black]

Hi, I do not have the time to contribute packages to Fedora these days.

I am orphaning the following packages under my maintainership:
- golang-github-elves-elvish
- golang-github-xiaq-persistent
- rust-box_drawing
- rust-git-delta
--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/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: F41 Change Proposal: Versioned Kubernetes Packages (Self-Cont

[Brad Smith]

One of the characteristics of Kubernetes is that skipping minor
versions during an upgrade is not supported. This reduces the
potential complexity in correctly setting Obsoletes/Provides in the
package for the replacing version. The unsupported version can also be
marked deprecated. These steps can help inform a user during dnf
updates.

In addition, there is a Kubernetes page in Quick Docs which contains,
in part, life cycle information for each Kubernetes release. While I
am a maintainer this page will be kept reasonably current, although I
cannot speak for subsequent maintainers. This page can be supplemented
by email to this list and posts on the Fedora community blog and
Discussions.

I will be glad to update the proposal to make this more explicit.

best regards

Brad Smith



On Sun, Apr 14, 2024 at 8:56 AM Zbigniew Jędrzejewski-Szmek
 wrote:
>

> Something that is not discussed explicitly in the proposal:
> what happens during an upgrade, when the user has a version installed
> that is not supported anymore. Do they get some notification that
> they should switch to the next one?
>
> Zbyszek
--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: F41 Change Proposal: Versioned Kubernetes Packages (Self-Cont

[Zbigniew Jędrzejewski-Szmek]

On Mon, Mar 25, 2024 at 04:15:44PM +, Aoife Moloney wrote:
> Wiki - https://fedoraproject.org/wiki/Changes/VersionedKubernetesPackages
> == Owner ==
> * Name: [[User:Buckaroogeek| Brad Smith]]
> * Email: bradley.g.sm...@gmail.com
> 
> 
> == Detailed Description ==
> The Kubernetes project maintains 3 concurrent versions with a new
> release every 4 months. Each version has a defined life-cycle of
> approximately 1 year (https://https://kubernetes.io/releases/ for
> details and current versions). In this proposal a release is a
> major:minor version combination such as 1.28 or 1.27 and ignores any
> patch updates (e.g. 1.28.1 or 1.28.2 as these are part of the same
> 1.28 minor release).

Something that is not discussed explicitly in the proposal:
what happens during an upgrade, when the user has a version installed
that is not supported anymore. Do they get some notification that
they should switch to the next one?

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

Re: Orphaned packages looking for new maintainers

[Michael J Gruber]

Michel Lind venit, vidit, dixit 2024-04-12 21:59:42:
> On Fri, Apr 12, 2024 at 07:59:46AM -0700, Carlos Rodriguez-Fernandez wrote:
> > Regarding libteam, the author of the package is the maintainer, email in
> > bugzilla is different than the one on the project. I wonder if Jiro just
> > missed the notification that his package is failing to build in F40.
> > 
> Indeed. cc-ing Jiri to see if he wants to be added back. Jiri, if you do
> so, maybe change your email in
> https://accounts.fedoraproject.org/user/salimma/settings/email/ ?
> 
> Meanwhile I'm doing a build that removes the network-scripts-teamd
> subpackage - my initial glance at the changelog was wrong, most Fedora
> releases are already on 1.32 so we don't need to bump the package yet.
> 

Don't we need to obsolete the subpackage, though, so that it gets
removed on upgrade? Or can we rely on the fact that it had been pulled
in as a dependency only (rather than installed directly)?

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

Orphaned packages looking for new maintainers

[Maxwell G]

Report started at 2024-04-12 13:04:40 UTC

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

Note: If you received this mail directly you (co)maintain one of the affected
packages or a package that depends on one. Please adopt the affected package or
retire your depending package to avoid broken dependencies, otherwise your
package will be retired when the affected package gets retired.

Request package ownership via the *Take* button in the left column on
https://src.fedoraproject.org/rpms/

Full report available at:
https://a.gtmx.me/orphans/orphans.txt
grep it for your FAS username and follow the dependency chain.

For human readable dependency chains,
see https://packager-dashboard.fedoraproject.org/
For all orphaned packages,
see https://packager-dashboard.fedoraproject.org/orphan

   Package  (co)maintainersStatus Change

container-workflow-tool orphan 2 weeks ago  
emacs-htmlize   orphan 3 weeks ago  
jolokia-jvm-agent   orphan 0 weeks ago  
kio-upnp-ms jgrulich, orphan   5 weeks ago  
libteam orphan 0 weeks ago  
loudgainorphan 4 weeks ago  
mingw-freeimage orphan 0 weeks ago  
mrxvt   orphan 4 weeks ago  
nextcloud   ichavero, orphan   2 weeks ago  
perl-WWW-Google-Contactsorphan 5 weeks ago  
php-aws-sdk3orphan 2 weeks ago  
php-bantu-ini-get-wrapper   adamwill, orphan   2 weeks ago  
php-christophwurst-id3parserorphan 2 weeks ago  
php-deepdiver-zipstreamer   orphan 2 weeks ago  
php-doctrine-dbal   orphan, remi   2 weeks ago  
php-fgrosse-phpasn1 orphan 2 weeks ago  
php-giggsey-locale  orphan 2 weeks ago  
php-guzzlehttp-guzzle6  orphan 2 weeks ago  
php-league-uri-interfaces   orphan 2 weeks ago  
php-opencloud-openstack orphan 2 weeks ago  
php-opis-closureorphan, remi   2 weeks ago  
php-pimple  orphan 2 weeks ago  
php-punic   orphan 2 weeks ago  
php-ralouphie-getallheaders orphan 2 weeks ago  
php-scssphp orphan 2 weeks ago  
php-stecman-symfony-console-orphan 2 weeks ago  
completion  
prometheus-jmx-exporter orphan 0 weeks ago  
prometheus-simpleclient-javaorphan 0 weeks ago  
python-aiomqtt  orphan 5 weeks ago  
python-autoprop orphan 5 weeks ago  
python-colorcet orphan 5 weeks ago  
python-jose orphan 1 weeks ago  
python-limits   orphan 4 weeks ago  
python-paramorphan 5 weeks ago  
python-pyct orphan 5 weeks ago  
python-signature-dispatch   orphan 5 weeks ago  
python-vecrec   orphan 5 weeks ago  
snakeyaml   mizdebsk, orphan, sbluhm   0 weeks ago  
vim-editorconfigorphan 1 weeks ago  

The following packages require above mentioned packages:
Depending on: libteam (56), status change: 2024-04-07 (0 weeks ago)
NetworkManager (maintained by: @gnome-sig, alexl, bengal, caolanm, 
danw, dcbw, ffmancera, ihuguet, liangwen12year, lkundrak, rhughes, rstrode, 
thaller)
NetworkManager-1:1.46.0-2.fc41.src requires teamd-devel = 
1.32-4.fc40
NetworkManager-team-1:1.46.0-2.fc41.x86_64 requires 
libteamdctl.so.0()(64bit)

anaconda (maintained by: anaconda-maint, jkonecny, kkoukiou, m4rtink, 
rvykydal

Re: Orphaned packages looking for new maintainers

[Michel Lind]

On Fri, Apr 12, 2024 at 07:59:46AM -0700, Carlos Rodriguez-Fernandez wrote:
> Regarding libteam, the author of the package is the maintainer, email in
> bugzilla is different than the one on the project. I wonder if Jiro just
> missed the notification that his package is failing to build in F40.
> 
Indeed. cc-ing Jiri to see if he wants to be added back. Jiri, if you do
so, maybe change your email in
https://accounts.fedoraproject.org/user/salimma/settings/email/ ?

Meanwhile I'm doing a build that removes the network-scripts-teamd
subpackage - my initial glance at the changelog was wrong, most Fedora
releases are already on 1.32 so we don't need to bump the package yet.

Best regards,

-- 
 _o) Michel Lind (né Salim)
_( ) identities: https://keyoxide.org/5dce2e7e9c3b1cffd335c1d78b229d2f7ccc04f2


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: Orphaned packages looking for new maintainers

[Michel Lind]

On Fri, Apr 12, 2024 at 09:09:31AM -0500, Maxwell G wrote:
> Report started at 2024-04-12 13:04:40 UTC
> libteam orphan 0 weeks 
> ago  
> 
> The following packages require above mentioned packages:
> Depending on: libteam (56), status change: 2024-04-07 (0 weeks ago)
>   NetworkManager (maintained by: @gnome-sig, alexl, bengal, caolanm, 
> danw, dcbw, ffmancera, ihuguet, liangwen12year, lkundrak, rhughes, rstrode, 
> thaller)
>   NetworkManager-1:1.46.0-2.fc41.src requires teamd-devel = 
> 1.32-4.fc40
>   NetworkManager-team-1:1.46.0-2.fc41.x86_64 requires 
> libteamdctl.so.0()(64bit)
> 
>   anaconda (maintained by: anaconda-maint, jkonecny, kkoukiou, m4rtink, 
> rvykydal, vladimirslavik, vponcova)
>   anaconda-core-41.9-1.fc41.x86_64 requires NetworkManager = 
> 1:1.46.0-2.fc41, NetworkManager-libnm = 1:1.46.0-2.fc41, NetworkManager-team 
> = 1:1.46.0-2.fc41, teamd = 1.32-4.fc40
>   anaconda-gui-41.9-1.fc41.x86_64 requires NetworkManager-wifi = 
> 1:1.46.0-2.fc41
> 
>   ladvd (maintained by: @epel-packagers-sig, ixs, ttorcz)
>   ladvd-1.1.2-20.fc40.src requires libteam-devel = 1.32-4.fc40
>   ladvd-1.1.2-20.fc40.x86_64 requires libteam.so.5()(64bit)
> 
...

That's a lot of dependent packages! I've taken up libteam, the open bugs
seem reasonable to fix and there is a new release as well (I'll
prioritize fixing the bug first then build the new release in Rawhide
first).

If there's anyone who is interested in comaintaining libteam, let me
know.

Best regards,

-- 
 _o) Michel Lind (né Salim)
_( ) identities: https://keyoxide.org/5dce2e7e9c3b1cffd335c1d78b229d2f7ccc04f2


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: Orphaned packages looking for new maintainers

[Carlos Rodriguez-Fernandez]

Regarding libteam, the author of the package is the maintainer, email in 
bugzilla is different than the one on the project. I wonder if Jiro just 
missed the notification that his package is failing to build in F40.



On 4/12/24 07:09, Maxwell G wrote:

Report started at 2024-04-12 13:04:40 UTC

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

Note: If you received this mail directly you (co)maintain one of the affected
packages or a package that depends on one. Please adopt the affected package or
retire your depending package to avoid broken dependencies, otherwise your
package will be retired when the affected package gets retired.

Request package ownership via the *Take* button in the left column on
https://src.fedoraproject.org/rpms/

Full report available at:
https://a.gtmx.me/orphans/orphans.txt
grep it for your FAS username and follow the dependency chain.

For human readable dependency chains,
see https://packager-dashboard.fedoraproject.org/
For all orphaned packages,
see https://packager-dashboard.fedoraproject.org/orphan

Package  (co)maintainersStatus 
Change

container-workflow-tool orphan 2 weeks ago
emacs-htmlize   orphan 3 weeks ago
jolokia-jvm-agent   orphan 0 weeks ago
kio-upnp-ms jgrulich, orphan   5 weeks ago
libteam orphan 0 weeks ago
loudgainorphan 4 weeks ago
mingw-freeimage orphan 0 weeks ago
mrxvt   orphan 4 weeks ago
nextcloud   ichavero, orphan   2 weeks ago
perl-WWW-Google-Contactsorphan 5 weeks ago
php-aws-sdk3orphan 2 weeks ago
php-bantu-ini-get-wrapper   adamwill, orphan   2 weeks ago
php-christophwurst-id3parserorphan 2 weeks ago
php-deepdiver-zipstreamer   orphan 2 weeks ago
php-doctrine-dbal   orphan, remi   2 weeks ago
php-fgrosse-phpasn1 orphan 2 weeks ago
php-giggsey-locale  orphan 2 weeks ago
php-guzzlehttp-guzzle6  orphan 2 weeks ago
php-league-uri-interfaces   orphan 2 weeks ago
php-opencloud-openstack orphan 2 weeks ago
php-opis-closureorphan, remi   2 weeks ago
php-pimple  orphan 2 weeks ago
php-punic   orphan 2 weeks ago
php-ralouphie-getallheaders orphan 2 weeks ago
php-scssphp orphan 2 weeks ago
php-stecman-symfony-console-orphan 2 weeks ago
completion
prometheus-jmx-exporter orphan 0 weeks ago
prometheus-simpleclient-javaorphan 0 weeks ago
python-aiomqtt  orphan 5 weeks ago
python-autoprop orphan 5 weeks ago
python-colorcet orphan 5 weeks ago
python-jose orphan 1 weeks ago
python-limits   orphan 4 weeks ago
python-paramorphan 5 weeks ago
python-pyct orphan 5 weeks ago
python-signature-dispatch   orphan 5 weeks ago
python-vecrec   orphan 5 weeks ago
snakeyaml   mizdebsk, orphan, sbluhm   0 weeks ago
vim-editorconfigorphan 1 weeks ago

The following packages require above mentioned packages:
Depending on: libteam (56), status change: 2024-04-07 (0 weeks ago)
NetworkManager (maintained by: @gnome-sig, alexl, bengal, caolanm, 
danw, dcbw, ffmancera, ihuguet, liangwen12year, lkundrak, rhughes, rstrode, 
thaller)
NetworkManager-1:1.46.0-2.fc41.src requires teamd-devel = 
1.32-4.fc40
NetworkManager-team-1:1.46.0-2.fc41.x86_64 requires

Orphaned packages looking for new maintainers

[Maxwell G]

Report started at 2024-04-12 13:04:40 UTC

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

Note: If you received this mail directly you (co)maintain one of the affected
packages or a package that depends on one. Please adopt the affected package or
retire your depending package to avoid broken dependencies, otherwise your
package will be retired when the affected package gets retired.

Request package ownership via the *Take* button in the left column on
https://src.fedoraproject.org/rpms/

Full report available at:
https://a.gtmx.me/orphans/orphans.txt
grep it for your FAS username and follow the dependency chain.

For human readable dependency chains,
see https://packager-dashboard.fedoraproject.org/
For all orphaned packages,
see https://packager-dashboard.fedoraproject.org/orphan

   Package  (co)maintainersStatus Change

container-workflow-tool orphan 2 weeks ago  
emacs-htmlize   orphan 3 weeks ago  
jolokia-jvm-agent   orphan 0 weeks ago  
kio-upnp-ms jgrulich, orphan   5 weeks ago  
libteam orphan 0 weeks ago  
loudgainorphan 4 weeks ago  
mingw-freeimage orphan 0 weeks ago  
mrxvt   orphan 4 weeks ago  
nextcloud   ichavero, orphan   2 weeks ago  
perl-WWW-Google-Contactsorphan 5 weeks ago  
php-aws-sdk3orphan 2 weeks ago  
php-bantu-ini-get-wrapper   adamwill, orphan   2 weeks ago  
php-christophwurst-id3parserorphan 2 weeks ago  
php-deepdiver-zipstreamer   orphan 2 weeks ago  
php-doctrine-dbal   orphan, remi   2 weeks ago  
php-fgrosse-phpasn1 orphan 2 weeks ago  
php-giggsey-locale  orphan 2 weeks ago  
php-guzzlehttp-guzzle6  orphan 2 weeks ago  
php-league-uri-interfaces   orphan 2 weeks ago  
php-opencloud-openstack orphan 2 weeks ago  
php-opis-closureorphan, remi   2 weeks ago  
php-pimple  orphan 2 weeks ago  
php-punic   orphan 2 weeks ago  
php-ralouphie-getallheaders orphan 2 weeks ago  
php-scssphp orphan 2 weeks ago  
php-stecman-symfony-console-orphan 2 weeks ago  
completion  
prometheus-jmx-exporter orphan 0 weeks ago  
prometheus-simpleclient-javaorphan 0 weeks ago  
python-aiomqtt  orphan 5 weeks ago  
python-autoprop orphan 5 weeks ago  
python-colorcet orphan 5 weeks ago  
python-jose orphan 1 weeks ago  
python-limits   orphan 4 weeks ago  
python-paramorphan 5 weeks ago  
python-pyct orphan 5 weeks ago  
python-signature-dispatch   orphan 5 weeks ago  
python-vecrec   orphan 5 weeks ago  
snakeyaml   mizdebsk, orphan, sbluhm   0 weeks ago  
vim-editorconfigorphan 1 weeks ago  

The following packages require above mentioned packages:
Depending on: libteam (56), status change: 2024-04-07 (0 weeks ago)
NetworkManager (maintained by: @gnome-sig, alexl, bengal, caolanm, 
danw, dcbw, ffmancera, ihuguet, liangwen12year, lkundrak, rhughes, rstrode, 
thaller)
NetworkManager-1:1.46.0-2.fc41.src requires teamd-devel = 
1.32-4.fc40
NetworkManager-team-1:1.46.0-2.fc41.x86_64 requires 
libteamdctl.so.0()(64bit)

anaconda (maintained by: anaconda-maint, jkonecny, kkoukiou, m4rtink, 
rvykydal

Re: "fedpkg local" builds fail for rust packages

[Vít Ondruch]

Dne 09. 04. 24 v 14:15 Fabio Valentini napsal(a):

On Tue, Apr 9, 2024 at 1:19 PM Vít Ondruch  wrote:

Dne 08. 04. 24 v 12:32 Neal Gompa napsal(a):

Packaged Rust crates work *fine* for local development as long as you
are willing to cut yourself off from crates.io. Unlike *every other
language package manager*, Cargo does not support multiple concurrent
indexes. This is ultimately the bottleneck, and there's been very
little interest in resolving this upstream.

Upstream issue: https://github.com/rust-lang/cargo/issues/4883


OTOH, there does not seem to be linked any PR implementing this RFE.

All people involved with Rust packaging in Fedora seem to be very
disillusioned wrt/ getting stuff upstreamed into cargo.
As far as I know, all of us have had very frustrating experiences when
trying to work with cargo upstream.



Trust me, I know the feeling.

But after all, I almost always had bigger success providing PR then just 
suggesting some changes. And of course a lot of patience is needed as well.



Vít




Spending a lot of time working on feature development only to be told
"we're not interested" is not a good way to spend our (limited) time.

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


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

Re: "fedpkg local" builds fail for rust packages

[Fabio Valentini]

On Tue, Apr 9, 2024 at 1:19 PM Vít Ondruch  wrote:
>
> Dne 08. 04. 24 v 12:32 Neal Gompa napsal(a):
> > Packaged Rust crates work *fine* for local development as long as you
> > are willing to cut yourself off from crates.io. Unlike *every other
> > language package manager*, Cargo does not support multiple concurrent
> > indexes. This is ultimately the bottleneck, and there's been very
> > little interest in resolving this upstream.
> >
> > Upstream issue: https://github.com/rust-lang/cargo/issues/4883
>
>
> OTOH, there does not seem to be linked any PR implementing this RFE.

All people involved with Rust packaging in Fedora seem to be very
disillusioned wrt/ getting stuff upstreamed into cargo.
As far as I know, all of us have had very frustrating experiences when
trying to work with cargo upstream.
Spending a lot of time working on feature development only to be told
"we're not interested" is not a good way to spend our (limited) time.

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

Re: "fedpkg local" builds fail for rust packages

[Vít Ondruch]

Dne 08. 04. 24 v 12:32 Neal Gompa napsal(a):

On Mon, Apr 8, 2024 at 6:17 AM Richard W.M. Jones  wrote:

On Fri, Apr 05, 2024 at 03:33:35PM +0200, Fabio Valentini wrote:

On Fri, Apr 5, 2024 at 9:51 AM Michael J Gruber  wrote:

So you're saying that those packages are in the repos for everyone but
not meant to be installed by anyone (besides mock chroots), and that is
how and why they are packaged.

Yes. That is the best we can do given how cargo + Rust work.


`This package contains library source intended for building other packages which
use the "xyz" crate.`

So the description matches what I said?


Unless you `fedpkg local` build it. Or maybe only if you `fedpkg
mockbuild` it. Does a rebuild from `fedpkg srpm` even work?

Wow!

Sorry to burst your bubble, but "fedpkg local" is an ugly hack
(independent of Rust peculiarities).

fedpkg local works fine for almost all cases.


And I am not interested in adding workarounds to the Rust packaging
toolchain to support it.

"fedpkg mockbuild" and "fedpkg srpm" all work as expected ...


Is there any other set of packages which we package like that?

Probably golang ... maybe Haskell, OCaml?

OCaml is definitely _not_ packaged like this.  ocaml-* and
ocaml-*-devel packages are normal packages that can be installed by
end users if they want, although usually only if they're developing
OCaml software.


Packaged Rust crates work *fine* for local development as long as you
are willing to cut yourself off from crates.io. Unlike *every other
language package manager*, Cargo does not support multiple concurrent
indexes. This is ultimately the bottleneck, and there's been very
little interest in resolving this upstream.

Upstream issue: https://github.com/rust-lang/cargo/issues/4883



OTOH, there does not seem to be linked any PR implementing this RFE.


Vít




Without this feature, it becomes difficult to do development using
packaged crates.




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

Orphaning some Java packages

[Severin Gehwolf]

Hi,

I'm orphaning a couple of packages of mine which I no longer use or
were used as a dependency of a package I've maintained before and am no
longer using:

Packages without co-maintainers:

jolokia-jvm-agent
prometheus-simpleclient-java
prometheus-jmx-exporter

Packages with co-maintainers:

cglib
snakeyaml

Feel free to take on any of those packages if you're interested.

Thanks,
Severin
--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/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: "fedpkg local" builds fail for rust packages

[Neal Gompa]

On Mon, Apr 8, 2024 at 6:17 AM Richard W.M. Jones  wrote:
>
> On Fri, Apr 05, 2024 at 03:33:35PM +0200, Fabio Valentini wrote:
> > On Fri, Apr 5, 2024 at 9:51 AM Michael J Gruber  
> > wrote:
> > >
> > > So you're saying that those packages are in the repos for everyone but
> > > not meant to be installed by anyone (besides mock chroots), and that is
> > > how and why they are packaged.
> >
> > Yes. That is the best we can do given how cargo + Rust work.
> >
> > > `This package contains library source intended for building other 
> > > packages which
> > > use the "xyz" crate.`
> >
> > So the description matches what I said?
> >
> > > Unless you `fedpkg local` build it. Or maybe only if you `fedpkg
> > > mockbuild` it. Does a rebuild from `fedpkg srpm` even work?
> > >
> > > Wow!
> >
> > Sorry to burst your bubble, but "fedpkg local" is an ugly hack
> > (independent of Rust peculiarities).
>
> fedpkg local works fine for almost all cases.
>
> > And I am not interested in adding workarounds to the Rust packaging
> > toolchain to support it.
> >
> > "fedpkg mockbuild" and "fedpkg srpm" all work as expected ...
> >
> > > Is there any other set of packages which we package like that?
> >
> > Probably golang ... maybe Haskell, OCaml?
>
> OCaml is definitely _not_ packaged like this.  ocaml-* and
> ocaml-*-devel packages are normal packages that can be installed by
> end users if they want, although usually only if they're developing
> OCaml software.
>

Packaged Rust crates work *fine* for local development as long as you
are willing to cut yourself off from crates.io. Unlike *every other
language package manager*, Cargo does not support multiple concurrent
indexes. This is ultimately the bottleneck, and there's been very
little interest in resolving this upstream.

Upstream issue: https://github.com/rust-lang/cargo/issues/4883

Without this feature, it becomes difficult to do development using
packaged crates.


-- 
真実はいつも一つ！/ 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: "fedpkg local" builds fail for rust packages

[Richard W.M. Jones]

On Fri, Apr 05, 2024 at 03:33:35PM +0200, Fabio Valentini wrote:
> On Fri, Apr 5, 2024 at 9:51 AM Michael J Gruber  
> wrote:
> >
> > So you're saying that those packages are in the repos for everyone but
> > not meant to be installed by anyone (besides mock chroots), and that is
> > how and why they are packaged.
> 
> Yes. That is the best we can do given how cargo + Rust work.
> 
> > `This package contains library source intended for building other packages 
> > which
> > use the "xyz" crate.`
> 
> So the description matches what I said?
> 
> > Unless you `fedpkg local` build it. Or maybe only if you `fedpkg
> > mockbuild` it. Does a rebuild from `fedpkg srpm` even work?
> >
> > Wow!
> 
> Sorry to burst your bubble, but "fedpkg local" is an ugly hack
> (independent of Rust peculiarities).

fedpkg local works fine for almost all cases.

> And I am not interested in adding workarounds to the Rust packaging
> toolchain to support it.
> 
> "fedpkg mockbuild" and "fedpkg srpm" all work as expected ...
> 
> > Is there any other set of packages which we package like that?
> 
> Probably golang ... maybe Haskell, OCaml?

OCaml is definitely _not_ packaged like this.  ocaml-* and
ocaml-*-devel packages are normal packages that can be installed by
end users if they want, although usually only if they're developing
OCaml software.

Rich.

> > If that is how you do things for the rust eco-system, those "devel"
> > packages should be clearly distinguished from real development packages,
> > come with a huge boiler plate "do not install" - or, really, be in a
> > separate repo if installing them is both worthless and misleading for
> > any "real" user. CRB for Fedora material.
> 
> You just pasted the package description above. What more do you want?
> It clearly states that the purpose of the packages is to build other packages.
> 
> Also, Fedora won't do split repos (been there, done that), and stuff
> like it doesn't even work that well in RHEL (and causes all sorts of
> issues).
> 
> While I agree that the situation is not ideal, I still think this is
> the best that we can do:
> 
> 1. We don't want Rust applications to vendor their dependencies
> 2. Rust can only do static linking (for now)
> -> Dependencies can only be shipped as source code, not as compiled artifacts.
> 
> And while you *can* use packaged Rust crates for local development if
> you really want, it's not really a supported use case.
> 
> 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

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

Re: "fedpkg local" builds fail for rust packages

[Fabio Valentini]

On Sat, Apr 6, 2024 at 12:42 PM Björn Persson  wrote:
>
> Fabio Valentini wrote:
> > - Installing rust-*-devel packages on your local system (i.e. outside
> > of ephemeral build environments) is not supported.
> > - The "rust-*-devel" packages are build system implementation details,
> > if you want to say it like that.
> > - They are not shipped to users and are not useful for Rust developers.
> > - They are *only* intended to be installed in temporary chroots (like
> > those set up by mock).
>
> I don't know enough about Rust to understand how the perfectly normal
> usecase of installing libraries as RPM packages has been made so
> problematic. I'll just state my strong opinion that packages that
> aren't meant for software development should not have "-devel" in their
> names.

Bascially, this is because of limitations of cargo.
It has no support for looking up dependencies in multiple places, only
*one* source of dependencies is configurable.
By default, dependencies are downloaded from crates.io. We override
the "crates.io" source with the directory where Rust crates are
packaged for Fedora.
Using vendored dependencies works similarly - there, the "crates.io"
source is overridden with the directory that contains vendored
sources.

But there is *no way* to specify *look here, and if it's not there,
look elsewhere". If dependencies are not present in the one configured
source, cargo just fails.
So using packaged Rust crates for development is difficult - since you
can't configure cargo to "use dependencies from
"/usr/share/cargo/registry" and fall back to downloading from
crates.io for things that aren't available".

(Side note: The train for using a different suffix than "-devel" has
left the station a decade ago. Changing this now is impractical, so
the naming bikeshedding is not helping.)

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: "fedpkg local" builds fail for rust packages

[Fabio Valentini]

On Sat, Apr 6, 2024 at 4:45 AM Scott Schmit  wrote:
>
> This perhaps explains why my efforts to use these packages did nothing
> but waste my time for days. 
>
> It sounds like you've wasted others' time as well.  That's not very
> Friendly, and playing nitpicky language lawyer games doesn't change
> that, and is also unFriendly.  This is about more than just you.  Other
> people are trying to do things, and you're sitting here saying "too bad,
> I don't care, it doesn't work and that's not my problem."  If that's not
> your intent, that's how it's coming across.
>
> That's an unacceptable attitude, and I think you need to rethink how
> you're approaching this conversation and re-read
> https://docs.fedoraproject.org/en-US/project/ from top to bottom.

I'm sorry about that. I don't want anybody to feel like they're
wasting their time.
I really am trying to do my best here, but there are some constraints
that I need to work within - both from the upstream cargo side and the
RPM packaging reality.

I inherited the way we do Rust packaging from my "predecessor" when he
stopped contributing to Fedora, I didn't invent things this way.
Since I took over maintenance of most Rust packages in Fedora (and the
tooling we use to create and maintain them), I tried to push many
improvements that make things better for package maintainers.

However, we're working with an upstream project that is either
indifferent or entirely hostile towards distribution packaging (rust /
cargo). Almost all improvements and / or bug fixes that we have asked
for in the past years have been either ignored or dismissed as "not
our problem". As frustrating as this is, I need to work with what I
have, and sometimes that leads to less than ideal outcomes - but
please don't blame me for that.

> It does not clearly state *anything* you've just now dropped on us.
> Also, all RPMs are packages, not all packages are RPMs.  For all I know,
> "package" could be another way of saying "crate."  And just because it's
> "intended" to do something doesn't mean "it won't work for anything
> else" or "it's not supported if you try to use it for anything else."

You are right, this could be stated more clearly.

> And I question whether making packages like that is acceptable for
> Fedora.

The way Rust packages work (and Go packages work very similarly) was
signed-off on by FESCo and / or the Packaging Committee, multiple
times. If you have a problem with how things work, take things up with
those decision bodies.
Again, I'm trying to make something that works well here, but I'm
trying to do my best given the constraints that we're working within.

> The naming convention for packages for the last 25 years as far as I've
> ever known has established that "foo-devel" packages provide programming
> support files that will allow *me* to build *my own* software using
> conventional build tools.
>
> The way you've described it, they shouldn't be "foo-devel" packages at
> all, because they're useless for routine development.  Admittedly, the
> packaging guidelines don't address this, but I assume this is because
> this principle is so obvious that nobody thought it needed to be said.
> I mean, it's in the mission statement!

The distinction between "-libs" and "-devel" subpackages doesn't
really make sense for languages like Rust or Go. There *are* no
separately distributed header / development files.
The source code *is* the thing that is redistributed for development.
I'm not sure if there's a better name for them than "-devel" packages.

> It seems to me that these not-"devel" packages should be named
> "foo-mock-build-support-for-internal-use-only-and-you-are-on-your-own-if-you-try-to-use-it-for-anything-else".
> That would be a whole lot clearer.  We can even consider the
> ridiculously-long name a feature.

Sorry, but this isn't helpful.

> You've already said there's no support for using them, so it sounds to
> me like they're ineligible for inclusion in RHEL (which involves paid
> support), so who cares if it works well in RHEL?  You've already said
> they don't work well in Fedora either.

We support these packages *for building other packages*.
The Rust stack is one of the most well-maintained large language
stacks in Fedora, with consistently very low numbers of packages that
have issues like broken builds or broken dependencies.

But RHEL does not include packages for Rust crates *at all* and uses
vendored dependencies unconditionally.
Which is not an acceptable solution for Fedora for multiple reasons.

> > 1. We don't want Rust applications to vendor their dependencies
>
> I'm trying to write my own software, so what business do you have
> telling me what I can do wi

Re: "fedpkg local" builds fail for rust packages

[Björn Persson]

Fabio Valentini wrote:
> - Installing rust-*-devel packages on your local system (i.e. outside
> of ephemeral build environments) is not supported.
> - The "rust-*-devel" packages are build system implementation details,
> if you want to say it like that.
> - They are not shipped to users and are not useful for Rust developers.
> - They are *only* intended to be installed in temporary chroots (like
> those set up by mock).

I don't know enough about Rust to understand how the perfectly normal
usecase of installing libraries as RPM packages has been made so
problematic. I'll just state my strong opinion that packages that
aren't meant for software development should not have "-devel" in their
names.

Björn Persson


pgp42QTPCqdJp.pgp
Description: OpenPGP digital signatur
--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/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: "fedpkg local" builds fail for rust packages

[Scott Schmit]

On Thu, Apr 04, 2024 at 10:41:19PM +0200, Fabio Valentini wrote:
> If you really don't mind jumping through multiple hoops just because
> you want to use "fedpkg local" instead of "fedpkg mockbuild", then I
> guess I can't stop you.
> 
> All I *can* do is tell you that you're not going to like the experience:
> 
> - Using "fedpkg local" is not supported for Rust packages, and I won't
> be adding workarounds to the Rust macros for it.
> - Installing rust-*-devel packages on your local system (i.e. outside
> of ephemeral build environments) is not supported.
> - The "rust-*-devel" packages are build system implementation details,
> if you want to say it like that.
> - They are not shipped to users and are not useful for Rust developers.
> - They are *only* intended to be installed in temporary chroots (like
> those set up by mock).
> - They don't get "Obsoletes" or "Provides" in case there are dropped
> subpackages and / or incompatible updates. This is not an issue
> because they are only ever *installed*, but never supposed to be
> *upgraded* in-place. Any issues you get by installing them on your
> host system are your own.

(putting this back in for larger context)

On Fri, Apr 05, 2024 at 03:33:35PM +0200, Fabio Valentini wrote:
> On Fri, Apr 5, 2024 at 9:51 AM Michael J Gruber wrote:
> > `This package contains library source intended for building other
> > packages which use the "xyz" crate.`
> 
> So the description matches what I said?

No, it does not.  You've thrown out a whole bunch of restrictive terms
of service that are not explicitly stated in the description.

You've said it only works from mock.  "from mock" is not in that
description.

I've used Fedora (and Red Hat Linux before that) for a combined total of
25 years.  Never have I heard of a package that's only for internal
distribution use and I think it's a complete violation of Fedora's
mission statement.

Distribution packages are packaged for *users* to allow *users* to use
them for things *besides* building the distribution.  (Whether that's
software development or otherwise.)

Maybe I should quote Fedora's mission statement:
> Fedora creates an innovative platform for hardware, clouds, and
> containers that enables software developers and community members to
> build tailored solutions for their users.
>
> At the operating system level, we don’t just integrate. We do new
> things — we build a platform, not just a distribution. The *Features*
   
> and *First* foundations drive us to innovate. We do all of this as a
> transparent, collaborative community of *Friends*, and entirely as
> open source and free software — *Freedom.*

This perhaps explains why my efforts to use these packages did nothing
but waste my time for days. 

It sounds like you've wasted others' time as well.  That's not very
Friendly, and playing nitpicky language lawyer games doesn't change
that, and is also unFriendly.  This is about more than just you.  Other
people are trying to do things, and you're sitting here saying "too bad,
I don't care, it doesn't work and that's not my problem."  If that's not
your intent, that's how it's coming across.

That's an unacceptable attitude, and I think you need to rethink how
you're approaching this conversation and re-read
https://docs.fedoraproject.org/en-US/project/ from top to bottom.

> > If that is how you do things for the rust eco-system, those "devel"
> > packages should be clearly distinguished from real development packages,
> > come with a huge boiler plate "do not install" - or, really, be in a
> > separate repo if installing them is both worthless and misleading for
> > any "real" user. CRB for Fedora material.
> 
> You just pasted the package description above. What more do you want?
> It clearly states that the purpose of the packages is to build other packages.

It does not clearly state *anything* you've just now dropped on us.
Also, all RPMs are packages, not all packages are RPMs.  For all I know,
"package" could be another way of saying "crate."  And just because it's
"intended" to do something doesn't mean "it won't work for anything
else" or "it's not supported if you try to use it for anything else."

And I question whether making packages like that is acceptable for
Fedora.

The naming convention for packages for the last 25 years as far as I've
ever known has established that "foo-devel" packages provide programming
support files that will allow *me* to build *my own* software using
conventional build tools.

The way you've described it, they shouldn't be "foo-devel" packages at
all, because they're useless fo

Re: "fedpkg local" builds fail for rust packages

[Jerry James]

On Fri, Apr 5, 2024 at 7:35 AM Fabio Valentini  wrote:
> On Fri, Apr 5, 2024 at 9:51 AM Michael J Gruber  
> wrote:
> > Is there any other set of packages which we package like that?
>
> Probably golang ... maybe Haskell, OCaml?

Not OCaml, no.  The OCaml packages can be installed and used for
software development.
-- 
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: "fedpkg local" builds fail for rust packages

[Fabio Valentini]

On Fri, Apr 5, 2024 at 3:16 PM Emanuel Lima  wrote:
>
> I'm not sure this helps, but I maintain a Rust and Go package that builds 
> fine with fedpkg local. If you want to take a look at the spec:
>
> https://src.fedoraproject.org/rpms/kata-containers/blob/rawhide/f/kata-containers.spec

This is a particularly bad example for a Rust package for two reasons:

"fedpkg local" only works because you build with vendored sources
(without following the bundling guidelines, i.e. declaring bundled
dependencies).
The package also builds in a way that does not respect default Fedora
compiler flags (see
https://bugzilla.redhat.com/show_bug.cgi?id=2167235).

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: "fedpkg local" builds fail for rust packages

[Fabio Valentini]

On Fri, Apr 5, 2024 at 9:51 AM Michael J Gruber  wrote:
>
> So you're saying that those packages are in the repos for everyone but
> not meant to be installed by anyone (besides mock chroots), and that is
> how and why they are packaged.

Yes. That is the best we can do given how cargo + Rust work.

> `This package contains library source intended for building other packages 
> which
> use the "xyz" crate.`

So the description matches what I said?

> Unless you `fedpkg local` build it. Or maybe only if you `fedpkg
> mockbuild` it. Does a rebuild from `fedpkg srpm` even work?
>
> Wow!

Sorry to burst your bubble, but "fedpkg local" is an ugly hack
(independent of Rust peculiarities).
And I am not interested in adding workarounds to the Rust packaging
toolchain to support it.

"fedpkg mockbuild" and "fedpkg srpm" all work as expected ...

> Is there any other set of packages which we package like that?

Probably golang ... maybe Haskell, OCaml?

> If that is how you do things for the rust eco-system, those "devel"
> packages should be clearly distinguished from real development packages,
> come with a huge boiler plate "do not install" - or, really, be in a
> separate repo if installing them is both worthless and misleading for
> any "real" user. CRB for Fedora material.

You just pasted the package description above. What more do you want?
It clearly states that the purpose of the packages is to build other packages.

Also, Fedora won't do split repos (been there, done that), and stuff
like it doesn't even work that well in RHEL (and causes all sorts of
issues).

While I agree that the situation is not ideal, I still think this is
the best that we can do:

1. We don't want Rust applications to vendor their dependencies
2. Rust can only do static linking (for now)
-> Dependencies can only be shipped as source code, not as compiled artifacts.

And while you *can* use packaged Rust crates for local development if
you really want, it's not really a supported use case.

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: "fedpkg local" builds fail for rust packages

[Emanuel Lima]

I'm not sure this helps, but I maintain a Rust and Go package that builds fine 
with fedpkg local. If you want to take a look at the spec:

https://src.fedoraproject.org/rpms/kata-containers/blob/rawhide/f/kata-containers.spec
--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/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: "fedpkg local" builds fail for rust packages

[Michael J Gruber]

Fabio Valentini venit, vidit, dixit 2024-04-04 22:41:19:
> On Thu, Apr 4, 2024 at 9:42 PM pfed--- via devel
>  wrote:
> >
> > On Thu, Apr 04, 2024 at 09:51:31AM +0200, Fabio Valentini wrote:
> > > > > The short answer is: No, "fedpkg local" is not expected to work for
> > > > > Rust packages, and probably won't ever work as expected for Rust
> > > > > packages.
> > > > >
> > > > > I am not really interested in adding the "--allow-dirty" flag (not
> > > > > sure if it would even work in this case), since building Rust packages
> > > > > with "fedpkg local" is not working for other reasons. Primarily,
> > > > > "fedpkg local" does not support dynamically generated BuildRequires -
> > > > > this is only supported when building in mock.
> > >
> > > > I don't know what you mean? For me after patching the macro locally
> > > > local builds work as expected. Maybe I'm overlooking something?
> > >
> > > You might be lucky and just tried to package a Rust crate with no
> > > dependencies?
> > > Dependencies on other Rust crates are only resolved dynamically at build
> > > time, which "fedpkg local" does not support. So it works "by accident" for
> > > Rust crates with no crate dependencies, but in general, it can't work.
> >
> > That would have been extremely lucky, but no, I'm building crates with
> > dependencies. And the build generates the requires list just fine.
> >
> > What is not possible is installing build dependencies directly from a
> > spec file from a fresh clone, if that is what you mean? But in this case
> > running a local build generates a `.buildreqs.nosrc.rpm` file with the
> > correct dependencies, which can be passed to `dnf builddep`.
> >
> > And since a local build does not manage build dependencies themselves,
> > rather relies on them just being there, I don't really see an issue in
> > that?
> 
> If you really don't mind jumping through multiple hoops just because
> you want to use "fedpkg local" instead of "fedpkg mockbuild", then I
> guess I can't stop you.
> 
> All I *can* do is tell you that you're not going to like the experience:
> 
> - Using "fedpkg local" is not supported for Rust packages, and I won't
> be adding workarounds to the Rust macros for it.
> - Installing rust-*-devel packages on your local system (i.e. outside
> of ephemeral build environments) is not supported.
> - The "rust-*-devel" packages are build system implementation details,
> if you want to say it like that.
> - They are not shipped to users and are not useful for Rust developers.
> - They are *only* intended to be installed in temporary chroots (like
> those set up by mock).
> - They don't get "Obsoletes" or "Provides" in case there are dropped
> subpackages and / or incompatible updates. This is not an issue
> because they are only ever *installed*, but never supposed to be
> *upgraded* in-place. Any issues you get by installing them on your
> host system are your own.

So you're saying that those packages are in the repos for everyone but
not meant to be installed by anyone (besides mock chroots), and that is
how and why they are packaged.

`This package contains library source intended for building other packages which
use the "xyz" crate.`

Unless you `fedpkg local` build it. Or maybe only if you `fedpkg
mockbuild` it. Does a rebuild from `fedpkg srpm` even work?

Wow!

Is there any other set of packages which we package like that?

If that is how you do things for the rust eco-system, those "devel"
packages should be clearly distinguished from real development packages,
come with a huge boiler plate "do not install" - or, really, be in a
separate repo if installing them is both worthless and misleading for
any "real" user. CRB for Fedora material.

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: "fedpkg local" builds fail for rust packages

[Fabio Valentini]

On Thu, Apr 4, 2024 at 9:42 PM pfed--- via devel
 wrote:
>
> On Thu, Apr 04, 2024 at 09:51:31AM +0200, Fabio Valentini wrote:
> > > > The short answer is: No, "fedpkg local" is not expected to work for
> > > > Rust packages, and probably won't ever work as expected for Rust
> > > > packages.
> > > >
> > > > I am not really interested in adding the "--allow-dirty" flag (not
> > > > sure if it would even work in this case), since building Rust packages
> > > > with "fedpkg local" is not working for other reasons. Primarily,
> > > > "fedpkg local" does not support dynamically generated BuildRequires -
> > > > this is only supported when building in mock.
> >
> > > I don't know what you mean? For me after patching the macro locally
> > > local builds work as expected. Maybe I'm overlooking something?
> >
> > You might be lucky and just tried to package a Rust crate with no
> > dependencies?
> > Dependencies on other Rust crates are only resolved dynamically at build
> > time, which "fedpkg local" does not support. So it works "by accident" for
> > Rust crates with no crate dependencies, but in general, it can't work.
>
> That would have been extremely lucky, but no, I'm building crates with
> dependencies. And the build generates the requires list just fine.
>
> What is not possible is installing build dependencies directly from a
> spec file from a fresh clone, if that is what you mean? But in this case
> running a local build generates a `.buildreqs.nosrc.rpm` file with the
> correct dependencies, which can be passed to `dnf builddep`.
>
> And since a local build does not manage build dependencies themselves,
> rather relies on them just being there, I don't really see an issue in
> that?

If you really don't mind jumping through multiple hoops just because
you want to use "fedpkg local" instead of "fedpkg mockbuild", then I
guess I can't stop you.

All I *can* do is tell you that you're not going to like the experience:

- Using "fedpkg local" is not supported for Rust packages, and I won't
be adding workarounds to the Rust macros for it.
- Installing rust-*-devel packages on your local system (i.e. outside
of ephemeral build environments) is not supported.
- The "rust-*-devel" packages are build system implementation details,
if you want to say it like that.
- They are not shipped to users and are not useful for Rust developers.
- They are *only* intended to be installed in temporary chroots (like
those set up by mock).
- They don't get "Obsoletes" or "Provides" in case there are dropped
subpackages and / or incompatible updates. This is not an issue
because they are only ever *installed*, but never supposed to be
*upgraded* in-place. Any issues you get by installing them on your
host system are your own.

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: "fedpkg local" builds fail for rust packages

[pfed--- via devel]

On Thu, Apr 04, 2024 at 09:51:31AM +0200, Fabio Valentini wrote:
> > > The short answer is: No, "fedpkg local" is not expected to work for
> > > Rust packages, and probably won't ever work as expected for Rust
> > > packages.
> > >
> > > I am not really interested in adding the "--allow-dirty" flag (not
> > > sure if it would even work in this case), since building Rust packages
> > > with "fedpkg local" is not working for other reasons. Primarily,
> > > "fedpkg local" does not support dynamically generated BuildRequires -
> > > this is only supported when building in mock.
> 
> > I don't know what you mean? For me after patching the macro locally
> > local builds work as expected. Maybe I'm overlooking something?
> 
> You might be lucky and just tried to package a Rust crate with no
> dependencies?
> Dependencies on other Rust crates are only resolved dynamically at build
> time, which "fedpkg local" does not support. So it works "by accident" for
> Rust crates with no crate dependencies, but in general, it can't work.

That would have been extremely lucky, but no, I'm building crates with
dependencies. And the build generates the requires list just fine.

What is not possible is installing build dependencies directly from a
spec file from a fresh clone, if that is what you mean? But in this case
running a local build generates a `.buildreqs.nosrc.rpm` file with the
correct dependencies, which can be passed to `dnf builddep`.

And since a local build does not manage build dependencies themselves,
rather relies on them just being there, I don't really see an issue in
that?

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

[Thomas Moschny]

Hi,

sorry for the late response, have been a bit busy recently...

Yes, we should remove botan (1) from Fedora - that has also been a request
by upstream. The point is, I want to keep monotone, and it needs a bit of
work to switch it over to botan2. There exists a branch that should have
the necessary changes, but no released version.

Anyway, the monotone switch will not make it in time for F40 I guess, but
I'll look into it.

Regarding botan3, I guess no one has volunteered yet to maintain it.

Regards,
Thomas


Am Do., 4. Apr. 2024 um 20:28 Uhr schrieb Jens-Ulrik Petersen <
peter...@redhat.com>:

> https://botan.randombit.net/handbook/support.html#branch-support-status
> can be referenced in the retirement commit:
>
> Branch
>
> First Release
>
> End of Active Development
>
> End of Life
>
> Botan 1.8
>
> 2008-12-08
>
> 2010-08-31
>
> 2016-02-13
>
> Botan 1.10
>
> 2011-06-20
>
> 2012-07-10
>
> 2018-12-31
> (Though 1.11.x also exists, or was that a devel series for botan2?)
> --
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct:
> https://docs.fedoraproject.org/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
>


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

[Jens-Ulrik Petersen]

https://botan.randombit.net/handbook/support.html#branch-support-status
can be referenced in the retirement commit:

Branch

First Release

End of Active Development

End of Life

Botan 1.8

2008-12-08

2010-08-31

2016-02-13

Botan 1.10

2011-06-20

2012-07-10

2018-12-31
(Though 1.11.x also exists, or was that a devel series for botan2?)
--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/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

[Jens-Ulrik Petersen]

On Thu, Apr 4, 2024 at 12:51 AM Sandro  wrote:

> On 03-04-2024 18:35, Jens-Ulrik Petersen wrote:
> > I took botan [...]
>

I guess that was a bad idea - so I have re-orphaned it after some detailed
discussions with @penguinpee in #devel.
He also helped to decouple monotone from ikiwiki in rawhide, so the impact
should be less now.

The last botan-1.1 release was in 2018 and I think Debian/Ubuntu dropped
botan1 at the same time?
So it seems high time to remove this unmaintained version from Fedora too.
(We have botan2 in Fedora of course and I hope to see botan3 as well?)

It seems too late to do more on this for F40 now? or we would need an Final
Exception

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

Re: "fedpkg local" builds fail for rust packages

[Gwyn Ciesla via devel]

Is there any chance fedpkg local can be adapted to support dynamic 
BuildRequires?

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

On Thursday, April 4th, 2024 at 2:51 AM, Fabio Valentini  
wrote:

> On Thu, Apr 4, 2024, 00:54 Philip Matura via devel 
>  wrote:
> 

> > On Thu, Apr 04, 2024 at 12:03:56AM +0200, Fabio Valentini wrote:
> > > On Wed, Apr 3, 2024 at 11:47 PM pfed--- via devel
> > >  wrote:
> > > >
> > > > Maybe we could add the `--allow-dirty` to the `%cargo_install` macro -
> > > > from the top of my head this should not break anything, but I'm not
> > > > sure. There does not seem to be a general "ignore-git" option for cargo.
> > > >
> > > > Or are there other ways to get this to work?
> > >
> > > The short answer is: No, "fedpkg local" is not expected to work for
> > > Rust packages, and probably won't ever work as expected for Rust
> > > packages.
> > >
> > > I am not really interested in adding the "--allow-dirty" flag (not
> > > sure if it would even work in this case), since building Rust packages
> > > with "fedpkg local" is not working for other reasons. Primarily,
> > > "fedpkg local" does not support dynamically generated BuildRequires -
> > > this is only supported when building in mock.
> > 

> > I don't know what you mean? For me after patching the macro locally
> > local builds work as expected. Maybe I'm overlooking something?
> 

> 

> You might be lucky and just tried to package a Rust crate with no 
> dependencies?
> 

> Dependencies on other Rust crates are only resolved dynamically at build 
> time, which "fedpkg local" does not support. So it works "by accident" for 
> Rust crates with no crate dependencies, but in general, it can't work.
> 

> Fabio
> 

> 

> > 

> > Philip Matura
> > --
> > ___
> > devel mailing list -- devel@lists.fedoraproject.org
> > To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> > Fedora Code of Conduct: 
> > https://docs.fedoraproject.org/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: "fedpkg local" builds fail for rust packages

[Fabio Valentini]

On Thu, Apr 4, 2024, 00:54 Philip Matura via devel <
devel@lists.fedoraproject.org> wrote:

> On Thu, Apr 04, 2024 at 12:03:56AM +0200, Fabio Valentini wrote:
> > On Wed, Apr 3, 2024 at 11:47 PM pfed--- via devel
> >  wrote:
> > >
> > > Maybe we could add the `--allow-dirty` to the `%cargo_install` macro -
> > > from the top of my head this should not break anything, but I'm not
> > > sure. There does not seem to be a general "ignore-git" option for
> cargo.
> > >
> > > Or are there other ways to get this to work?
> >
> > The short answer is: No, "fedpkg local" is not expected to work for
> > Rust packages, and probably won't ever work as expected for Rust
> > packages.
> >
> > I am not really interested in adding the "--allow-dirty" flag (not
> > sure if it would even work in this case), since building Rust packages
> > with "fedpkg local" is not working for other reasons. Primarily,
> > "fedpkg local" does not support dynamically generated BuildRequires -
> > this is only supported when building in mock.
>
> I don't know what you mean? For me after patching the macro locally
> local builds work as expected. Maybe I'm overlooking something?
>

You might be lucky and just tried to package a Rust crate with no
dependencies?

Dependencies on other Rust crates are only resolved dynamically at build
time, which "fedpkg local" does not support. So it works "by accident" for
Rust crates with no crate dependencies, but in general, it can't work.

Fabio


> Philip Matura
> --
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct:
> https://docs.fedoraproject.org/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: "fedpkg local" builds fail for rust packages

[Philip Matura via devel]

On Thu, Apr 04, 2024 at 12:03:56AM +0200, Fabio Valentini wrote:
> On Wed, Apr 3, 2024 at 11:47 PM pfed--- via devel
>  wrote:
> >
> > Maybe we could add the `--allow-dirty` to the `%cargo_install` macro -
> > from the top of my head this should not break anything, but I'm not
> > sure. There does not seem to be a general "ignore-git" option for cargo.
> >
> > Or are there other ways to get this to work?
> 
> The short answer is: No, "fedpkg local" is not expected to work for
> Rust packages, and probably won't ever work as expected for Rust
> packages.
> 
> I am not really interested in adding the "--allow-dirty" flag (not
> sure if it would even work in this case), since building Rust packages
> with "fedpkg local" is not working for other reasons. Primarily,
> "fedpkg local" does not support dynamically generated BuildRequires -
> this is only supported when building in mock.

I don't know what you mean? For me after patching the macro locally
local builds work as expected. Maybe I'm overlooking something?

Philip Matura
--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/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: "fedpkg local" builds fail for rust packages

[Fabio Valentini]

On Wed, Apr 3, 2024 at 11:47 PM pfed--- via devel
 wrote:
>
> Maybe we could add the `--allow-dirty` to the `%cargo_install` macro -
> from the top of my head this should not break anything, but I'm not
> sure. There does not seem to be a general "ignore-git" option for cargo.
>
> Or are there other ways to get this to work?

The short answer is: No, "fedpkg local" is not expected to work for
Rust packages, and probably won't ever work as expected for Rust
packages.

I am not really interested in adding the "--allow-dirty" flag (not
sure if it would even work in this case), since building Rust packages
with "fedpkg local" is not working for other reasons. Primarily,
"fedpkg local" does not support dynamically generated BuildRequires -
this is only supported when building in mock.

I wonder if "fedpkg local" shouldn't just error out when attempting to
build spec files that use %generate_buildrequires ...

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

"fedpkg local" builds fail for rust packages

[pfed--- via devel]

Hi all,

I like using `fedpkg local` builds to speed up testing of packaging, but
now encountered a problem trying to package a rust program for the first
time. It turns out a local build fails in the install step for all rust
packages (that I tried out) with an error like

error: 152 files in the working directory contain changes that were not yet 
committed into git:
[ ... file list ... ]
to proceed despite this and include the uncommitted changes, pass the 
`--allow-dirty` flag

The problem is the line

/usr/bin/env CARGO_HOME=.cargo RUSTC_BOOTSTRAP=1 RUSTFLAGS='-Copt-level=3 
-Cdebuginfo=2 -Ccodegen-units=1 -Cstrip=none -Cforce-frame-pointers=yes 
-Clink-arg=-specs=/usr/lib/rpm/redhat/redhat-package-notes --cap-lints=warn' 
/usr/bin/cargo package -l | grep -w -E -v 'Cargo.(lock|toml.orig)' | xargs -d 
'\n' /usr/bin/cp --parents -a -t $REG_DIR

coming from the `%cargo_install` macro, where `cargo package -l` is used
to generate the file list. Now, since `fedpkg local` builds inside a
subdirectory of the package repo, `cargo package` sees that it's
operating inside a git repo and issues the above warning, exiting
non-zero.

I know to work around this by using rpmbuild manually or testing with
mock builds all the time, but I think it would be great if local builds
would work, too.

Maybe we could add the `--allow-dirty` to the `%cargo_install` macro -
from the top of my head this should not break anything, but I'm not
sure. There does not seem to be a general "ignore-git" option for cargo.

Or are there other ways to get this to work?

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

[Sandro]

On 03-04-2024 18:35, Jens-Ulrik Petersen wrote:

I took botan as a penance for my sins in the previous thread  haha 


הַלְּלוּ־יָהּ 

Thanks!

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

Re: Orphaned packages looking for new maintainers

[Jens-Ulrik Petersen]

I took botan as a penance for my sins in the previous thread ;-) haha 
--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/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

Orphaned packages looking for new maintainers

[Maxwell G]

Report started at 2024-04-02 16:05:20 UTC

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

Note: If you received this mail directly you (co)maintain one of the affected
packages or a package that depends on one. Please adopt the affected package or
retire your depending package to avoid broken dependencies, otherwise your
package will be retired when the affected package gets retired.

Request package ownership via the *Take* button in the left column on
https://src.fedoraproject.org/rpms/

Full report available at:
https://a.gtmx.me/orphans/orphans.txt
grep it for your FAS username and follow the dependency chain.

For human readable dependency chains,
see https://packager-dashboard.fedoraproject.org/
For all orphaned packages,
see https://packager-dashboard.fedoraproject.org/orphan

Package  (co)maintainers   Status Change

botan orphan   1 weeks ago  
container-workflow-tool   orphan   1 weeks ago  
emacs-htmlize orphan   1 weeks ago  
kio-upnp-ms   jgrulich, orphan 3 weeks ago  
ktp-contact-runner@kde-sig, orphan, rdieter3 weeks ago  
liquidshell   orphan   5 weeks ago  
loudgain  orphan   3 weeks ago  
mrxvt orphan   3 weeks ago  
nextcloud ichavero, orphan 1 weeks ago  
perl-Git-PurePerl iarnell, orphan  6 weeks ago  
perl-Net-GitHub   jplesnik, lkundrak, orphan,  6 weeks ago  
  ppisar
perl-Spreadsheet-ParseExcel-  jplesnik, orphan, ppisar 6 weeks ago  
Simple  
perl-Spreadsheet-WriteExcel-  jplesnik, orphan, ppisar 6 weeks ago  
Simple  
perl-String-Diff  iarnell, orphan  6 weeks ago  
perl-WWW-Google-Contacts  orphan   3 weeks ago  
php-aws-sdk3  orphan   1 weeks ago  
php-bantu-ini-get-wrapper adamwill, orphan 1 weeks ago  
php-christophwurst-id3parser  orphan   1 weeks ago  
php-deepdiver-zipstreamer orphan   1 weeks ago  
php-doctrine-dbal orphan, remi 1 weeks ago  
php-fgrosse-phpasn1   orphan   1 weeks ago  
php-giggsey-localeorphan   1 weeks ago  
php-guzzlehttp-guzzle6orphan   1 weeks ago  
php-league-uri-interfaces orphan   1 weeks ago  
php-opencloud-openstack   orphan   1 weeks ago  
php-opis-closure  orphan, remi 1 weeks ago  
php-phpSmug   orphan   5 weeks ago  
php-pimpleorphan   1 weeks ago  
php-punic orphan   1 weeks ago  
php-ralouphie-getallheaders   orphan   1 weeks ago  
php-scssphp   orphan   1 weeks ago  
php-stecman-symfony-console-  orphan   1 weeks ago  
completion  
python-aiomqttorphan   4 weeks ago  
python-autoprop   orphan   4 weeks ago  
python-colorcet   orphan   4 weeks ago  
python-extractcode@python-packagers-sig, orphan3 weeks ago  
python-jose   orphan   0 weeks ago  
python-limits orphan   3 weeks ago  
python-param  orphan   4 weeks ago  
python-pyct   orphan   4 weeks ago  
python-signature-dispatch orphan   4 weeks ago  
python-vecrec orphan   4 weeks ago  
telepathy-logger-qt   @kde-sig, jgrulich, orphan   3

Orphaned packages looking for new maintainers

[Maxwell G]

Report started at 2024-04-02 16:05:20 UTC

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

Note: If you received this mail directly you (co)maintain one of the affected
packages or a package that depends on one. Please adopt the affected package or
retire your depending package to avoid broken dependencies, otherwise your
package will be retired when the affected package gets retired.

Request package ownership via the *Take* button in the left column on
https://src.fedoraproject.org/rpms/

Full report available at:
https://a.gtmx.me/orphans/orphans.txt
grep it for your FAS username and follow the dependency chain.

For human readable dependency chains,
see https://packager-dashboard.fedoraproject.org/
For all orphaned packages,
see https://packager-dashboard.fedoraproject.org/orphan

Package  (co)maintainers   Status Change

botan orphan   1 weeks ago  
container-workflow-tool   orphan   1 weeks ago  
emacs-htmlize orphan   1 weeks ago  
kio-upnp-ms   jgrulich, orphan 3 weeks ago  
ktp-contact-runner@kde-sig, orphan, rdieter3 weeks ago  
liquidshell   orphan   5 weeks ago  
loudgain  orphan   3 weeks ago  
mrxvt orphan   3 weeks ago  
nextcloud ichavero, orphan 1 weeks ago  
perl-Git-PurePerl iarnell, orphan  6 weeks ago  
perl-Net-GitHub   jplesnik, lkundrak, orphan,  6 weeks ago  
  ppisar
perl-Spreadsheet-ParseExcel-  jplesnik, orphan, ppisar 6 weeks ago  
Simple  
perl-Spreadsheet-WriteExcel-  jplesnik, orphan, ppisar 6 weeks ago  
Simple  
perl-String-Diff  iarnell, orphan  6 weeks ago  
perl-WWW-Google-Contacts  orphan   3 weeks ago  
php-aws-sdk3  orphan   1 weeks ago  
php-bantu-ini-get-wrapper adamwill, orphan 1 weeks ago  
php-christophwurst-id3parser  orphan   1 weeks ago  
php-deepdiver-zipstreamer orphan   1 weeks ago  
php-doctrine-dbal orphan, remi 1 weeks ago  
php-fgrosse-phpasn1   orphan   1 weeks ago  
php-giggsey-localeorphan   1 weeks ago  
php-guzzlehttp-guzzle6orphan   1 weeks ago  
php-league-uri-interfaces orphan   1 weeks ago  
php-opencloud-openstack   orphan   1 weeks ago  
php-opis-closure  orphan, remi 1 weeks ago  
php-phpSmug   orphan   5 weeks ago  
php-pimpleorphan   1 weeks ago  
php-punic orphan   1 weeks ago  
php-ralouphie-getallheaders   orphan   1 weeks ago  
php-scssphp   orphan   1 weeks ago  
php-stecman-symfony-console-  orphan   1 weeks ago  
completion  
python-aiomqttorphan   4 weeks ago  
python-autoprop   orphan   4 weeks ago  
python-colorcet   orphan   4 weeks ago  
python-extractcode@python-packagers-sig, orphan3 weeks ago  
python-jose   orphan   0 weeks ago  
python-limits orphan   3 weeks ago  
python-param  orphan   4 weeks ago  
python-pyct   orphan   4 weeks ago  
python-signature-dispatch orphan   4 weeks ago  
python-vecrec orphan   4 weeks ago  
telepathy-logger-qt   @kde-sig, jgrulich, orphan   3

Re: Obsoleted packages in F40

[Otto Liljalaakso]

Kevin Kofler via devel kirjoitti 31.3.2024 klo 14.14:

Otto Liljalaakso wrote:

So, I would actually much prefer if package retirement automatically
added the package to fedora-obsolete-packages. Perhaps there are special
cases where that would not be a good idea - if there are some, `fedpkg
retire` could have a flag to prevent that from happening.

We have had this discussion several times on this list. The compromise that
was agreed upon is that packages should be added to fedora-obsolete-packages
ONLY if having those packages installed BREAKS something, e.g., prevents
upgrading some other package due to broken dependencies, or causes a file
conflict with some other package. Being retired is by itself NOT a reason to
forcefully remove a package that users may depend on from their systems. So
that is what should be documented, not your personal wishes.
Even if I happen to spend my time documenting what rules the Fedora 
community agrees, I still reserve the right to voice my opinion on what 
the rule should be. I have not submitted any pull request to change any 
documentation to follow what I suggest above, just to clarify what the 
actual, existing rule is.

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

[Kevin Kofler via devel]

Otto Liljalaakso wrote:
> So, I would actually much prefer if package retirement automatically
> added the package to fedora-obsolete-packages. Perhaps there are special
> cases where that would not be a good idea - if there are some, `fedpkg
> retire` could have a flag to prevent that from happening.

We have had this discussion several times on this list. The compromise that 
was agreed upon is that packages should be added to fedora-obsolete-packages 
ONLY if having those packages installed BREAKS something, e.g., prevents 
upgrading some other package due to broken dependencies, or causes a file 
conflict with some other package. Being retired is by itself NOT a reason to 
forcefully remove a package that users may depend on from their systems. So 
that is what should be documented, not your personal wishes.

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

Re: Obsoleted packages in F40

[Otto Liljalaakso]

Otto Liljalaakso kirjoitti 30.3.2024 klo 13.41:

Kevin Kofler via devel kirjoitti 25.3.2024 klo 20.34:

Miroslav Suchý wrote:

I want to highlight that we have policy for removing policy
https://docs.fedoraproject.org/en-US/package-maintainers/Package_Retirement_Process/#complete_removal
which at the end mention adding the package to
https://src.fedoraproject.org/rpms/fedora-obsolete-packages


I do not think the "Completely Removing a Package" section is meant 
for the cases you mention. The only example given in that section is 
licensing issues, i.e. a situation where Fedora was actually not even 
allowed to distribute the package, either because of the license 
conditions, or because of Fedora's own bylaws.


On the other hand, you do not have to refer to that section if you 
want to remind packages about fedora-obsolete-packages. Right before 
there is "Obsoleting Packages", which asks to consider obsoleting for 
every retirement. 


In attempt to make it more clear that obsoleting should be considered 
every time a package is retired, I submitted a pull request for Package 
Maintainer Docs [1].


[1]: https://pagure.io/fedora-docs/package-maintainer-docs/pull-request/152
--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/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: Obsoleted packages in F40

[Otto Liljalaakso]

Kevin Kofler via devel kirjoitti 25.3.2024 klo 20.34:

Miroslav Suchý wrote:

I just upgraded my workstation to F40 and it surprised how many packages
were reported by `remove-retired-packages`. There was lots of orphaned
packages - there is nothing to do about them. But there was lot of
packages that were removed intentionally. See the list at the end of my
email.

I want to highlight that we have policy for removing policy
 
https://docs.fedoraproject.org/en-US/package-maintainers/Package_Retirement_Process/#complete_removal
which at the end mention adding the package to
 https://src.fedoraproject.org/rpms/fedora-obsolete-packages


I do not think the "Completely Removing a Package" section is meant for 
the cases you mention. The only example given in that section is 
licensing issues, i.e. a situation where Fedora was actually not even 
allowed to distribute the package, either because of the license 
conditions, or because of Fedora's own bylaws.


On the other hand, you do not have to refer to that section if you want 
to remind packages about fedora-obsolete-packages. Right before there is 
"Obsoleting Packages", which asks to consider obsoleting for every 
retirement.



The point of fedora-obsolete-packages is to remove packages that actually
BREAK things when they remain installed. Otherwise, the best thing to do is
to NOT obsolete those packages. Users might still rely on them. E.g., they
might have locally built software that depends on the dropped compatibility
libraries. Forcefully obsoleting those will break the locally installed
software.


I have wondered at this approach even since I discovered that Fedora 
actually handles retired packages on distro upgrade like this. In 
today's always-connected IT environment full of malicious actors and 
threats, I consider it a basic principle to only have software that is 
kept up-to-date by *somebody*. For stuff I built and/or installed by 
myself, I take that responsibility myself, and suffer the consequences 
when I fail to deliver. But if distribution stops providing upgrades to 
a package, I would expect it be removed automatically.


So, I would actually much prefer if package retirement automatically 
added the package to fedora-obsolete-packages. Perhaps there are special 
cases where that would not be a good idea - if there are some, `fedpkg 
retire` could have a flag to prevent that from happening.

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

[EPEL-devel] EPEL Packages SIG page rewrite

[Troy Dawson]

I have done a first draft to rewrite the EPEL Packagers SIG page.[1]
The most dramatic thing was that I took out all of the "What is EPEL" stuff.
That is all found elsewhere in the EPEL docs and was (in my opinion) the
confusing stuff, making people think you needed to join the SIG, and that
by joining the SIG you had more permissions than you really did.
I really only did a minor change to the requirements, simply adding the
part I thought was significant to members of the sig.
Let me know what ya'll think.
I've added 'meeting' to the issue, so it will be on the agenda for next
weeks meeting.

Troy

[1] - https://pagure.io/epel/pull-request/270
--
___
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: Orphaned packages looking for new maintainers

[Miro Hrončok]

On 27. 03. 24 16:03, Jens-Ulrik Petersen wrote:
On Wed, Mar 27, 2024 at 9:46 PM Miro Hrončok > wrote:


On 25. 03. 24 7:48, Jens-Ulrik Petersen wrote:
 > Also botan got orphaned despite the FTI going away
 > > [1] ;-(
 > Could it be un-orphaned back?

 > [1] Seems FTI failed to close the bug fixed on 2024-03-07

It was closed after it was fixed. The update was stuck at beta freeze and
nobody associated the FTI bugzilla with it.


No, it was reported  
installable (comment 5) on 7th March by fti-bugs but was not closed as it 
should have been then.


On Fedora 41 only.

Then it was orphaned  
(comment 6) on 21st March.


Yes, because it was still NEW and not acted upon by the maintainer.

Then again reported  
installable (comment 7) on 25th which actually closed the bug.


On Fedora 40.


Which is why I am asking if the orphaned can be reverted, please.


Yes, if the previous maintainer is still interested in maintaining it, they can 
take the package back by clicking on the *Take* button.


It makes no sense to me to assign it back to them if they are not interested.

--
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: Orphaned packages looking for new maintainers

[Jens-Ulrik Petersen]

On Wed, Mar 27, 2024 at 9:46 PM Miro Hrončok  wrote:

> On 25. 03. 24 7:48, Jens-Ulrik Petersen wrote:
> > Also botan got orphaned despite the FTI going away
> >  [1] ;-(
> > Could it be un-orphaned back?
>
> > [1] Seems FTI failed to close the bug fixed on 2024-03-07
>
> It was closed after it was fixed. The update was stuck at beta freeze and
> nobody associated the FTI bugzilla with it.
>

No, it was reported 
installable (comment 5) on 7th March by fti-bugs but was not closed as it
should have been then.
Then it was orphaned
 (comment 6) on
21st March.
Then again reported 
installable (comment 7) on 25th which actually closed the bug.
Which is why I am asking if the orphaned can be reverted, please.

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