Re: F41 Change Proposal: Make OpenSSL distrust SHA-1 signatures by default (system-wide)

[Petr Pisar]

V Tue, Jun 11, 2024 at 04:09:54PM +0200, Dmitry Belyavskiy napsal(a):
> I understand that not all old systems are upgradeable (though many of them
> can be turned to smth using better algorithms - e.g. EC SSH keys are
> available on RHEL 7).
> So for these use cases we would like to propose either use runcp utility

Is the runcp utility packaged for Feodora?

-- 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: RPM_* env variables vs macros

[Petr Pisar]

V Thu, Jun 06, 2024 at 08:36:25AM +, Zbigniew Jędrzejewski-Szmek napsal(a):
> On Thu, Jun 06, 2024 at 09:53:48AM +0300, Panu Matilainen wrote:
> > On 6/5/24 18:22, Zbigniew Jędrzejewski-Szmek wrote:
> > > On Tue, Jun 04, 2024 at 09:31:47AM +0200, Vít Ondruch wrote:
> > > > 
> > > > Dne 04. 06. 24 v 9:27 Vít Ondruch napsal(a):
> > > > > 
> > > > > Dne 04. 06. 24 v 8:11 Panu Matilainen napsal(a):
> > > > > > On 6/3/24 17:18, Eike Rathke wrote:
> > > > > > > Hi Panu,
> > > > > > > 
> > > > > > > On Monday, 2024-06-03 15:55:09 +0300, Panu Matilainen wrote:
> > > > > > > 
> > > > > > > > or better yet, ${RPM_BUILD_ROOT}.
> > > > > > > 
> > > > > > > Why better?
> > > > > > 
> > > > > > In general, the RPM_* environment variables available to build
> > > > > > scriptlets are what should be used instead of macros. Because,
> > > > > > macros are processed while parsing the spec, which is different from
> > > > > > actually *building* it. For one, using the environment improves srpm
> > > > > > reproducibility because the local gunk like number of CPUs, the
> > > > > > concrete path of %buildroot etc are only visible the scriptlets
> > > > > > where actually used.
> > > > > > 
> > > > > > It's a subtle thing, took me 10+ years with rpm to grok the
> > > > > > recommendation I'd seen long, long, long ago.
> > > > > > 
> > > > > 
> > > > > I wish this nugget was captured somewhere on more prominent place.
> > > > > Because what you say does not really correspond with what we have in
> > > > > guidelines:
> > > > > 
> > > > > https://docs.fedoraproject.org/en-US/packaging-guidelines/#_using_buildroot_and_optflags_vs_rpm_build_root_and_rpm_opt_flags
> > > > > 
> > > > > 
> > > > > And I have not checked the RPM documentation
> > > > 
> > > > 
> > > > There is this section:
> > > > 
> > > > https://rpm-software-management.github.io/rpm/manual/spec.html#build-scriptlets
> > > > 
> > > > also recommending RPM_ macros for scriptlets:
> > > 
> > > I acknowledge what Panu wrote, but I think there are also countervailing 
> > > reasons
> > > to prefer the macro:
> > > - it is shorter and generally more consistent with the rest of the spec 
> > > file,
> > >which will have many many macros and only occasionally a shell 
> > > variable,
> > >so the macro is more aesthetic.
> > > - but the big thing is that the macro is safe wrt. typos, while the 
> > > variable
> > >not so much. It's just too easy to make a stupid typo in the variable 
> > > name
> > >and do bad things™ in a local build.
> > > 
> > >${RPM_BUILD_ROOT:?} would be a better way to spell the variable 
> > > reference,
> > >but that's too long expect people to use it.
> > 
> > Yeah the thing is those macros can and will never go away because everybody
> > instinctively prefers them for consistency within the spec, shorter to type
> > and all.
> > 
> > > 
> > > So maybe we should have a macro that would expand to the env var:
> > >%global BUILDROOT ${RPM_BUILD_ROOT:?}
> > > and recommend that people use that instead?
> > 
> > That'd be a third variant of the same thing, probably causing even more
> > confusion, and specs using that would be incompatible with everything else.
> > Let's not.
> > 
> > Making the macros expand to the corresponding environment variables is a is
> > a sound strategy though, and what we're doing with %_smp_mflags already:
> > 
> > %_smp_mflags -j${RPM_BUILD_NCPUS}
> > 
> > It can cause some breakage though so care needs to be taken. And just now,
> > we've already rocked the boat more than is entirely healthy for a single
> > release, so further experiments in this area will have to wait for some
> > other time.
> 
> I don't think we could ever change %buildroot to be ${RPM_BUILD_ROOT:?},
> because the variable may be used in context where shell variable expansion
> is not supported… (E.g. a trivial "find '%{buildroot}' -name '*.a' -delete")
> 
Moreover, the scripts can be interpreted with a different shell than bash.
A shell where ${RPM_BUILD_ROOT:?} is invalid or has a different meaning.

That's actually a reason why to prefer manually typing shell variables in the
scripts: Shells know how to safely expand variables. rpm-build cannot know how
to escape the expanded value.

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

[rpms/perl-Crypt-OpenSSL-Random] PR #5: fedora-ci.koji-build.rpmdeplint.functional is not supported on non-Rawhide

[Petr Pisar]

ppisar closed without merging a pull-request against the project: 
`perl-Crypt-OpenSSL-Random` that you
are following.

Closed pull-request:

``
fedora-ci.koji-build.rpmdeplint.functional is not supported on non-Rawhide
``

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

[rpms/perl-Crypt-OpenSSL-Random] PR #5: fedora-ci.koji-build.rpmdeplint.functional is not supported on non-Rawhide

[Petr Pisar]

ppisar commented on the pull-request: 
`fedora-ci.koji-build.rpmdeplint.functional is not supported on non-Rawhide` 
that you are following:
``
Scratch build does not  exhibit gating.yaml :(
``

To reply, visit the link below
https://src.fedoraproject.org/rpms/perl-Crypt-OpenSSL-Random/pull-request/5
--
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

[rpms/perl-Crypt-OpenSSL-Random] PR #4: fedora-ci.koji-build.rpmdeplint.functional is not supported on non-Rawhide

[Petr Pisar]

ppisar closed without merging a pull-request against the project: 
`perl-Crypt-OpenSSL-Random` that you
are following.

Closed pull-request:

``
fedora-ci.koji-build.rpmdeplint.functional is not supported on non-Rawhide
``

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

[rpms/perl-Crypt-OpenSSL-Random] PR #5: fedora-ci.koji-build.rpmdeplint.functional is not supported on non-Rawhide

[Petr Pisar]

ppisar opened a new pull-request against the project: 
`perl-Crypt-OpenSSL-Random` that you are following:
``
fedora-ci.koji-build.rpmdeplint.functional is not supported on non-Rawhide
``

To reply, visit the link below
https://src.fedoraproject.org/rpms/perl-Crypt-OpenSSL-Random/pull-request/5
--
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

[rpms/perl-Crypt-OpenSSL-Random] PR #4: fedora-ci.koji-build.rpmdeplint.functional is not supported on non-Rawhide

[Petr Pisar]

ppisar opened a new pull-request against the project: 
`perl-Crypt-OpenSSL-Random` that you are following:
``
fedora-ci.koji-build.rpmdeplint.functional is not supported on non-Rawhide
``

To reply, visit the link below
https://src.fedoraproject.org/rpms/perl-Crypt-OpenSSL-Random/pull-request/4
--
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: rpm-ostree, dnf and bootc in a bootable containers world

[Petr Pisar]

V Mon, May 20, 2024 at 02:15:49PM -0400, Joseph Marrero napsal(a):
> * dnf4 & dnf5 should provide a more helpful error when a user types
> `dnf install` on a booted image-based system (pointing them to unlock
> the system or use rpm-ostree).
[...]
> * dnf should be used during container builds of image-based Fedora for
> most applications and examples.
> 
How is it that DNF is not good enough for users, but at the same time it's
good enough for building the images?

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

[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

[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:  PackageArch   Version   
  Repository  Size
DEBUG util.py:463:  Removing dependent packages:
  
DEBUG util.py:463:   build-reproducibility-srpm-macros noarch 0.2.0-6.fc41  
  build  684.0   B
DEBUG util.py:463:   fonts-srpm-macros noarch 1:2.0.5-14.fc40   
  build   55.3 KiB
DEBUG util.py:463:   forge-srpm-macros noarch 0.3.1-1.fc41  
  build   39.0 KiB
DEBUG 

Re: Comp groups

[Petr Pisar]

V Wed, May 15, 2024 at 12:13:16AM +0200, Emmanuel Seyman napsal(a):
> Both of these require a pretty significant overhaul, IMHO. Unless
> someone has any objections, I will file a PR on the fedora-comps repo
> replacing the contents of the perl group with the following:
> 
>  Mandatory Packages:
>perl
>  Default Packages:
>git-cpan-patch
>perl-CPAN-Uploader
>perl-Data-Printer
>perl-Devel-Confess
>perl-Devel-NYTProf
>perl-Dist-Zilla
>perl-Module-Build-Tiny
>perl-Perl-Critic
>perl-Pod-Readme
>perl-Software-License
>perltidy
>  Optional Packages:
>cpanspec
>perl-Code-TidyAll
>perl-Modern-Perl
>vim-perl-support
>  
> Another commit will make perl-web the following group:
> 
>  Mandatory Packages:
>   perl
>  Default Packages:
>   perl-CGI-Formbuilder
>   perl-HTML-FormHandler
>   perl-HTTP-BrowserDetect
>   perl-MIME-Types
>   perl-Plack
>   perl-XML-Atom
>   perl-XML-RSS
>  Optional Packages:
>   perl-Attean
>   perl-Dancer2
>   perl-Mojolicious
>   perl-Task-Catalyst
>   perl-Template
> 
> Thoughts? Suggestions?
> 
That looks good.

-- Petr


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

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

[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

Re: Issues updating fedora 39 to rawhide

[Petr Pisar]

V Tue, Apr 23, 2024 at 11:35:55AM -0300, Guinevere Larsen napsal(a):
> Hi all,
> 
> I just installed fedora 39 on a virtual machine with the plan to make it a
> rawhide box. I followed the docs guide (namely using `dnf upgrade --refresh`
> then `dnf system-upgrade download --releasever=rawhide`) and by chance
> noticed that the keys that were being installed were for fedora 40, and I
> wonder why that was. At the end there are a lot of errors in the form:
>     public key for  is not installed, failing package is 
>         GPG keys are configured as
> file:///etc/pki/rpm-gpg/RPM-GPG-KEY-fedora-rawhide-x86-64
> 
> A few of the packages throwing errors have NVR ending in fc40., others
> ending in fc41.
> 
If you were able to tell us at one package like that, we could look what's
wrong.

Did the "dnf system-upgrade download --releasever=rawhide" command ask you
to confirm importing a new key?

> Is it an issue on my end, or a problem with the GPG keys provided? (or some
> secret third thing, maybe)
> 
Maybe a similar issue to
.

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

[rpms/perl-Task-Catalyst] PR #1: Stop building for 32-bit x86

[Petr Pisar]

ppisar commented on the pull-request: `Stop building for 32-bit x86` that you 
are following:
``
I see. Could you please mention flamegraph in the commit message? E.g. "Stop 
building for 32-bit x86 because of flamegraph".
``

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

Re: [SPDX] Mass license change Artistic 2.0 to Artistic-2.0

[Petr Pisar]

V Thu, Apr 11, 2024 at 01:04:22PM +0200, Miroslav Suchý napsal(a):
> perl-Unix-Groups-FFI
> perl-Unix-Groups-FFI

You can remove perl-Unix-Groups-FFI from your list. I converted both of them.

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

[rpms/perl-Task-Catalyst] PR #1: Stop building for 32-bit x86

[Petr Pisar]

ppisar commented on the pull-request: `Stop building for 32-bit x86` that you 
are following:
``
Indeed. perl-Devel-NYTProf is fullarch. @jjames, what's the problem with 
flamegraph?
``

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

[rpms/perl-Task-Catalyst] PR #1: Stop building for 32-bit x86

[Petr Pisar]

ppisar commented on the pull-request: `Stop building for 32-bit x86` that you 
are following:
``
perl-Task-Catalyst is noarch. What's the point of ExcludeArch? Preventing from 
building it on i686 builders because perl-Devel-NYTProf requires flamegraph 
which wont be there? Could you please write this reason to a commit message?

Also if you convert License tag, also convert the comment above.
``

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

Re: convert everything to rpmautospec?

[Petr Pisar]

V Mon, Apr 08, 2024 at 01:12:38PM -0500, Michel Lind napsal(a):
> - should we update the packaging docs? Does this need to be a new Change
>   Proposal or does this just need to go through the Fedora packaging
>   committee? (Those involved in the Change like zbyszek can probably
>   advise here)
> 
FPC with an anouncement on devel list should be enough.

> - should we extend this further and say, if we no longer assume NEVRAs
>   are monotonically increasing in a new release, we should allow
>   packagers to use this opportunity to drop epochs in Rawhide? (likely
>   with proper announcement beforehand in devel@)
> 
Who will check reverse dependncies? E.g. perl will drop "Epoch: 4". Who will
check that no other package "Requires: perl > 4:..."? I remind that
fedora-ci.koji-build.rpmdeplint.functional gating test is still not enforced
globally.

-- 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: convert everything to rpmautospec?

[Petr Pisar]

V Mon, Apr 08, 2024 at 11:37:48AM +, Zbigniew Jędrzejewski-Szmek napsal(a):
> OK, so you mean that the approach with '.' at the end of Release
> doesn't work. Yes, that case is not supported very well.
> 
> There is no great solution here, but there are a few options. Which
> one makes the most sense depends a lot on the package. But in particular:
> - just switch to non-autorelease numbering when introducing the
>   minorbump, e.g. just do Release: 15%{?dist}.1 and then .2, etc.
> 
> Looking at the docs again, the docs are not great, and we should
> support this case better. This certainly needs looking into.
> 
Now I recalled yet another downstream issue: Importing without a git history
will reset release numbers. That hashes RPM-dependencies which refer to
a specific release (like "Conflicts: foo < 1-20" after a package split). One
should of course carefully check them on import, but forking whole
distribution like that into a new downstream distribution warrants there will
remain gems like this.

I don't say it's Fedora's problem. I only try to show why some people are not
keen to adopt rpmautospec.

-- 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: convert everything to rpmautospec?

[Petr Pisar]

V Mon, Apr 08, 2024 at 11:37:48AM +, Zbigniew Jędrzejewski-Szmek napsal(a):
> On Mon, Apr 08, 2024 at 01:11:22PM +0200, Petr Pisar wrote:
> > RHEL do updates into older minor distribution versions. E.g. you might want 
> > to
> > build for RHEL 9.2 and RHEL 9.3. Users staying on 9.2 should update to that
> > build for 9.2, users staying on 9.3 to the build for 9.3 and users uprgading
> > from 9.2 to 9.3 should update to the build for 9.3 regardeless they updated 
> > to
> > the 9.2 build before or not.
> 
> OK, so you mean that the approach with '.' at the end of Release
> doesn't work. Yes, that case is not supported very well.
> 
> There is no great solution here, but there are a few options. Which
> one makes the most sense depends a lot on the package. But in particular:
> - just switch to non-autorelease numbering when introducing the
>   minorbump, e.g. just do Release: 15%{?dist}.1 and then .2, etc.
>
That's what people probably do, but it's not ideal because people need not to
forget to do it and it means a larger churn in dist-git than would be otherwise
necessary.

> > > > - I sometimes need a different commit message from an RPM changelog 
> > > > entry.
> > > 
> > > That's not a problem, the %changelog entry is customziable, see
> > > https://docs.pagure.org/fedora-infra.rpmautospec/autochangelog.html.
> > >
> > If I understand it correctly
> 
> You understand incorrectly ;) Please see the docs linked above.
> 
I see. A multi-line commit message without ellipsis reproduces only the first
line into the RPM changlog. That would do. Thanks for insisting on the
documentation.

> > With preserving the release numbers. Last time it subsituted the release
> > number with a dummy value. Part of the development is comparing old and new
> > builds and testing an upgrade path. A dummy release number is not 
> > sufficient.
> 
> No. I don't know what "last time" means, but it hasn't been like that
> since it was officially introduced in Fedora.

Indeed. I probably mistaken it with building from a source package in mock.

-- 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: convert everything to rpmautospec?

[Petr Pisar]

V Mon, Apr 08, 2024 at 10:49:42AM +, Zbigniew Jędrzejewski-Szmek napsal(a):
> On Mon, Apr 08, 2024 at 12:28:34PM +0200, Petr Pisar wrote:
> > - It breaks upgrade path in downstream distributions (e.g. fixes in RHEL 
> > minor
> >   releases).
> 
> Hmm, can you provide describe the workflow that is broken in more
> detail?
> 
RHEL do updates into older minor distribution versions. E.g. you might want to
build for RHEL 9.2 and RHEL 9.3. Users staying on 9.2 should update to that
build for 9.2, users staying on 9.3 to the build for 9.3 and users uprgading
from 9.2 to 9.3 should update to the build for 9.3 regardeless they updated to
the 9.2 build before or not.

It's bascially the same problem as Fedora has when users upgrade from Fredora
40 to 41. Fedora "fixed" the rpmautospec problem by stating that upgrade path
between Fedoras is not maintained anymore and users need to do "dnf
distro-sync" to ignore the RPM versioning.

All that stems from tha fact that a number of commits between parallelly
supported braches is not monotonic.

> > - I sometimes need a different commit message from an RPM changelog entry.
> 
> That's not a problem, the %changelog entry is customziable, see
> https://docs.pagure.org/fedora-infra.rpmautospec/autochangelog.html.
>
If I understand it correctly the customization is actually dumping a changelog
into a static file. So instead of a few-line commit one would need to review
the complete changelog. No, thanks.

> > - I prefer "fedpkg local" over mock (faster, smaller, easier to debug).
> 
> That also just works.
> 
With preserving the release numbers. Last time it subsituted the release
number with a dummy value. Part of the development is comparing old and new
builds and testing an upgrade path. A dummy release number is not sufficient.

-- 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: convert everything to rpmautospec?

[Petr Pisar]

V Sun, Apr 07, 2024 at 03:15:16PM +, Zbigniew Jędrzejewski-Szmek napsal(a):
> I think it's time to switch to rpmautospec completely.
> Thus, the proposal:
> - new packages MUST use rpmautospec
> - packagers SHOULD convert their packages
> - provenpackagers MAY convert existing packages
>   (e.g. when they want to push some fix or separately from other
>work)
> - people submitting pull requests against src.fp.o MAY also
>   include a conversion in the pull request and packagers SHOULD
>   merge it.
> 
I don't like it because:

- It breaks upgrade path in downstream distributions (e.g. fixes in RHEL minor
  releases).

- I sometimes need a different commit message from an RPM changelog entry.

- I prefer "fedpkg local" over mock (faster, smaller, easier to debug).

-- 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: bad error on console / shell ... any idea ! ?

[Petr Pisar]

V Sat, Mar 30, 2024 at 09:40:46AM -, Cătălin George Feștilă napsal(a):
> I tried this command on the default Fedora installation... the TAB Key gave 
> me this error:
> [root@fedora mythcat]# dnf5 search scV: __reassemble_comp_words_by_ref: 
> command not found
> terminate called after throwing an instance of 'std::invalid_argument'
>   what():  stoi

This is a known issue
 triggered by
upgrading bash-completion to 2.12 version.

-- 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: [SPDX] Mass license change: Intro and change of "Bitstream Vera" to "Bitstream-Vera"

[Petr Pisar]

V Tue, Mar 26, 2024 at 02:52:50PM +0100, Miroslav Suchý napsal(a):
> I have no strong opinion how to process with the case of  "MIT and BSD and
> Bitstream Vera and OFL". I think that converting it to " MIT and BSD and
> Bitstream-Vera and OFL" is probably best option. I.e. the License tag will
> become mixture of Callaway and SPDX. It will not make it valid SPDX formula
> so it will still pop up as package to be fixed, but at least some work will
> be done.

In other words, it will be a regression. Invalid by either system:

$ license-validate 'MIT AND BSD AND Bitstream-Vera and OFL'
Not a valid license string
Run with -v option to see more information.
$ license-validate --old 'MIT AND BSD AND Bitstream-Vera and OFL'
Not a valid license string
Run with -v option to see more information.

I wouldn't do it.

If you want to hint the packager, then open a pull request with the partial
conversion.

-- 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: F41 Change Proposal: Disable openSSL Engine Support (system-wide)

[Petr Pisar]

V Wed, Mar 20, 2024 at 02:05:52PM +, Daniel P. Berrangé napsal(a):
> Consider you've built your own app on Fedora 39 that uses these
> symbols, and now upgrade to F40. RPM will consider the dependency
> still satisfied, as the SONAME hasn't changed on libcrypto. The
> app throws linker errors at some point due to the missing symbols.
> 
> Another alternative is to continue providing fully functional engine
> symbols, but remove the header files so in practice you can't compile
> something new that uses it. This is still forking the API, but at least
> has not forked the ELF ABI, so the upgrade doesn't explode.
> 
Another option is remove the symbols, change soname, and rebuild reverse
dependencies.

-- 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: perl segfault in F40

[Petr Pisar]

V Mon, Mar 11, 2024 at 08:33:47AM -0600, Jerry James napsal(a):
> Argh, dang time change.  I meant to remark on that and obviously
> forgot.  Yes, libpkgconf 2.1.0 is not ABI compatible with libpgkconf
> 1.9.5, but the soname was not bumped.  Besides pkgconf itself and
> perl-PkgConfig-LibPkgConf, the build2 and perl-Alien-pkgconf packages
> may also need rebuilds.

I discovered this issue a week ago. I reported it to the upstream (somebody
already posted the link), rebuilt perl-PkgConfig-LibPkgConf
 and notified
build2 maintainers .
perl-Alien-pkgconf does not need rebuilding because it does not use the shared
library.

-- 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: reprodubible builds (re)introduction

[Petr Pisar]

V Fri, Mar 08, 2024 at 05:04:01PM +, Zbigniew Jędrzejewski-Szmek napsal(a):
> And perl-Module-Build has:
> ├── ./usr/libexec/perl-Module-Build/_build/magicnum
> │ @@ -1 +1 @@
> │ -1016
> │ +697476
> 
> It's generated via
>   $self->_write_data('magicnum', $self->magic_number(int rand 1_000_000));
> It seems strange to fix the seed for tests like this…
> 
That file was a byproduct of perl-Module-Build's build script. I removed it
the from a binary package and perl-Module-Build-0.42.34-6.fc41 should be
reproducible now.

-- 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: reprodubible builds (re)introduction

[Petr Pisar]

V Fri, Mar 08, 2024 at 04:54:04PM +, Zbigniew Jędrzejewski-Szmek napsal(a):
> On Fri, Mar 08, 2024 at 09:07:30AM +0100, Petr Pisar wrote:
> > (2) Both perl-Alien-pkgconf NEVRAs reports a differing
> > /usr/lib64/perl5/vendor_perl/auto/share/dist/Alien-pkgconf/status.json
> > content. That content looks likes this:
> > 
> > 
> > {"libs":"-lpkgconf","version":"2.1.0","install_type":"system","cflags":"-I/usr/include/pkgconf","dll":"/lib64/libpkgconf.so.4.0.0"}
> > 
> > That means you had to perform rebuilds of the same NEVRA with different
> > libpkgconf-devel packages in the build roots. That looks like a bug in your
> > mini rebuild scheduler.
> 
> Diffoscope says:
> 
> ├── ./usr/lib64/perl5/vendor_perl/auto/share/dist/Alien-pkgconf/status.json
> │ ├── Pretty-printed
> │ │┄ Ordering differences only
> │ │ @@ -1,7 +1,7 @@
> │ │  {
> │ │  "libs": "-lpkgconf",
> │ │ +"dll": "/lib64/libpkgconf.so.4.0.0",
> │ │  "version": "2.1.0",
> │ │ -"install_type": "system",
> │ │  "cflags": "-I/usr/include/pkgconf",
> │ │ -"dll": "/lib64/libpkgconf.so.4.0.0"
> │ │ +"install_type": "system"
> │ │  }
> 
> It would be great to sort the dictionary to avoid this randomness.
> 
You are right. I completely forgot the ordering. I fixed it in
perl-Alien-pkgconf-0.19-10.fc41.

> > (3) Some packages listed in builds-2024-02-fc41-filtered.txt are missing 
> > from
> > builds-2024-02-fc41-filtered.results.txt. E.g.
> > perl-CPAN-Plugin-Sysdeps-0.73-1.fc41 is listed as COMPLETE, yet results are
> > missing.
> 
> Yes. Some packages failed to build, and then I finished the build
> early because there were already enough interesting results.
> 
> (The few failures I looked at were caused by differences in BR between
> architectures. This is currently a corner case that I'm not sure how
> to deal with. Most of the time, using a srpm from a different
> architecture works fine, but in some cases the set of installed
> packages would differ, and then I can't figure out which version of
> the rpm for the local architecture would have been used and buildroot
> creation fails. I would be happy to describe the problem in more
> detail. It's also possible that other packages FTBFS, I didn't look
> into this and I didn't save the logs.)
>  
> > (4) dnf5-5.1.13-1.fc41.src reports changes in Requires (e.g. "removed
> > REQUIRES createrepo_c"). That again looks like you built the same NEVRA in
> > different build roots (for some reason "%bcond_without tests" flipped).
> 
> Yes, the build root is different. I install the package set that was
> used for the main package build and just call mock with that and it
> does both srpm and the binary rpms there. But koji does the srpm build
> in a separate buildroot that is smaller.
> 
Using SRPMs from a different archicture won't work as you find out. You need
to unpack the SRPM and do "dnf builddep THE_UNPACKED_SPEC_FILE". But then you
will have a different build root content comparing to the Koji build.

So I guess an architecture of the builder needs to be handled as a piece of
the reproducibility environment (i.e. reproducing a noarch package built on
s390x on s390x, not on x86_64), or you can assume that noarch builds should
not differ among builder archictures and then ignore the build root content
and only focus on the resulting binary 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

Re: reprodubible builds (re)introduction

[Petr Pisar]

V Thu, Mar 07, 2024 at 12:39:37PM +, Zbigniew Jędrzejewski-Szmek napsal(a):
> The effort to make package builds in Fedora reproducible has picked up steam 
> again.
> We now have a new website: 
> https://docs.fedoraproject.org/en-US/reproducible-builds
> and an issue tracker: https://pagure.io/fedora-reproducible-builds/project
> and a matrix room: https://matrix.to/#/#reproducible-builds:fedora.im
> 
> We've done a mini rebuild using [1] for the package list [2] and results are 
> at [3].
> (The result is a json dump of rpmdiff output by package. Generally, "" means
> the rebuild was identical except for variable metadata, and non-empty
> output else means that the rebuild was different.)
> 
> [1] https://github.com/keszybz/fedora-repro-build
> [2] https://fedorapeople.org/~zbyszek/builds-2024-02-fc41-filtered.txt
> [3] https://fedorapeople.org/~zbyszek/builds-2024-02-fc41-filtered.results.txt
> 
Is this mini rebuild a one-shot thing, or are are you going to rebuild the
packages repeatedly or use the results for something significant? I ask
because I spotted some discrepancies in those text files:

(1) Some packages are listed twice, with different NEVRAs. E.g.
perl-Alien-pkgconf or perl-RDF-RDFa-Generator.

(2) Both perl-Alien-pkgconf NEVRAs reports a differing
/usr/lib64/perl5/vendor_perl/auto/share/dist/Alien-pkgconf/status.json
content. That content looks likes this:


{"libs":"-lpkgconf","version":"2.1.0","install_type":"system","cflags":"-I/usr/include/pkgconf","dll":"/lib64/libpkgconf.so.4.0.0"}

That means you had to perform rebuilds of the same NEVRA with different
libpkgconf-devel packages in the build roots. That looks like a bug in your
mini rebuild scheduler.

(3) Some packages listed in builds-2024-02-fc41-filtered.txt are missing from
builds-2024-02-fc41-filtered.results.txt. E.g.
perl-CPAN-Plugin-Sysdeps-0.73-1.fc41 is listed as COMPLETE, yet results are
missing.

(4) dnf5-5.1.13-1.fc41.src reports changes in Requires (e.g. "removed
REQUIRES createrepo_c"). That again looks like you built the same NEVRA in
different build roots (for some reason "%bcond_without tests" flipped).

All that means you might hunting ghosts instead of real bugs.

-- 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: help needed with failing eccodes build for f40

[Petr Pisar]

V Thu, Feb 29, 2024 at 10:02:32AM +0100, Jos de Kloe napsal(a):
> Dear all,
> 
> while doing koji builds for the latest eccodes version 2.34.1 I ran in to an
> issue that is puzzling to me, and I have no idea to solve this.
> 
> The build runs just fine for f38, f39 and f41/rawhide, but for f40 I get a
> number of g++ errors like this:
> 
>  error: ‘opj_destroy_decompress’ was not declared in this scope; did you
> mean ‘opj_end_decompress’?
>   209 | opj_destroy_decompress(dinfo);
>   | ^~
>   | opj_end_decompress
> 
> see: https://koji.fedoraproject.org/koji/buildinfo?buildID=2412368
> 
> Does anyone have an idea what is happening here and how this can be solved?
> 
The function is supposed to be declared in openjpeg.h header file which is
supposed to be packaged in openjpeg2-devel.

Checking root.log files of eccodes builds, F40 used
openjpeg2-devel-2.5.1-1.fc40, while F41 used openjpeg2-devel-2.5.2-1.fc41.

It's quite possible that opj_destroy_decompress was added in 2.5.2 and does
not exist in 2.5.1. If it is so, you should specify the minimal version among
BuildRequires: openjpeg2-devel >= 2.5.2.

Why is openjpeg2-devel-2.5.2-1.fc40 not available in F40 build root? It is
because that build has not been submitted to Bodhi and has not passed into
updates repository.

I recommend creating a side tag for F40, tag openjpeg2-devel-2.5.2-1.fc40
there, build eccodes there, and both builds push into a single Bodhi update.

-- 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: DNF5 ~ how to "remove --oldinstallonly" ?

[Petr Pisar]

V Thu, Feb 22, 2024 at 02:28:18PM +1100, Ian Laurie napsal(a):
> I have my dnf configured with installonly_limit=6 and now and then find
> it useful to get rid of old kernels (for example after a move from
> Fedora n to n+1).
> 
> I know in the early days of DNF5 you couldn't do this, but can you do it
> now?
> 
It seems this feature has not yet been implemented. A request for it
 is still opened
and "dnf5 remove --help" does not mention that feature.

-- 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: [Fedora-packaging] Guiding co-dependent RPM packages to swap nicely

[Petr Pisar]

V Wed, Feb 21, 2024 at 10:54:16AM +0100, Miro Hrončok napsal(a):
> Assume I have two "stacks" of RPM packages available:
> 
> postgresql16
>   provides postgresql-any version 16
>   conflicts with other postgresql-any
> postgresql16-plugin
>   provides postgresql-any-plugin
>   requires postgresql16
>   conflicts with other postgresql-any-plugin
> 
> postgresql20
>   provides postgresql-any version 20
>   conflicts with other postgresql-any
> postgresql20-plugin
>   provides postgresql-any-plugin
>   requires postgresql20
>   conflicts with other postgresql-any-plugin
> 
> On my system, I have postgresql16 and postgresql16-plugin installed and I
> want to "upgrade" to postgresql20*.
> 
> Using my distribution package manager, I would want to run something like:
>   dnf swap postgresql16 postgresql20
> 
> However that will fail, as the package manager does not know I want to also
> swap postgresql16-plugin with postgresql20-plugin.
> 
> Is there something I can do as a package maintainer to "guide" the
> co-dependent swap case?
> 
I don't think there is anything like "dnf module switch-to".

What works now is manually listing the new packages:

dnf install --allowerasing postgresql20 postgresql20-plugin

For the guided multi-swap, DNF would have to uderstand that
postgresql20-plugin and postgresql16-plugin are different streams of the same
software. If it doesn't understand it, --allowerasing will resolve to
uinstalling the old packages without installing the new ones. (Because a
dependency solver prefers smaller transactions (uninstalling N packages) over
larger ones (uninstall N + install N).)

There is the postgresql-any-plugin Provide, but DNF does not know that it
actually identifies what the user wants to retain. Hypothetically pinpointing
it:

dnf upgrade --allowerasing postgresql-any postgresql-any-plugin

could do it. But I worry that DNF prefers interpreting the arguments as
package names instead of as provides. (Especially in the real life where
Fedora 41 now contains postgresql15 package providing postgresql next to
postgresql package.)

Nonetheless, your guided swap with referring to a single provide/package:

dnf upgrade --allowerasing postgresql-any

would not work for the very same reason: DNF does not know that
postgresql-any-plugin provide should be preserved, while any other provides of
postgresql16-plugin package (e.g. postgresql16-plugin provide itself) do not
matter.

To do that there would have to be two kinds of provides (i.e. a new RPM tag or
a namespace in Provides) and DNF would have to handle the special
postgresql-any and postgresql-any-plugin provides as "explicitly installed".
Of course that would break current behavior. So this feature would have to be
activated with a new option, e.g.  --allow-swap, which would break the
prohibition of uninstalling packages and enforced preserving the special
provides:

dnf upgrade --allow-swap postgresql-any

So yeah, DNF does not have enough metadata. We need RPM-formalized
alternatives.

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

perl-Image-PNG-Libpng-tests license corrected

[Petr Pisar]

I corrected a perl-Image-PNG-Libpng-tests license tag from

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

to

(GPL-1.0-or-later OR Artistic-1.0-Perl) AND 
LicenseRef-Fedora-UltraPermissive

-- 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: Doubts on /etc/mock/fedora-40-*.cfg

[Petr Pisar]

V Fri, Feb 16, 2024 at 01:11:38PM +0100, Petr Pisar napsal(a):
> If locally run mock is expected to mimich Koji as much as possible, it should
> change fedora-40*.cfg to use dnf5.
> 
https://bugzilla.redhat.com/show_bug.cgi?id=2264535

-- 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: Doubts on /etc/mock/fedora-40-*.cfg

[Petr Pisar]

V Fri, Feb 16, 2024 at 12:09:27PM +0100, Ralf Corsépius napsal(a):
> Am 16.02.24 um 12:00 schrieb Ralf Corsépius:
> > Hi,
> > 
> > today, mock-core-configs-40.1-1.fc39.noarch landed, bringing along
> > 
> > /etc/mock/fedora-40-x86_64.cfg
> > and
> > /etc/mock/fedora-40-i386.cfg
> > 
> > Now, I'm wondering about config_opts['package_manager']
> > 
> > fedora-40-*.cfg includes templates/fedora-branched.tpl
> > which sets
> > config_opts['package_manager']=dnf
> > 
> > This is unlike fedora-rawhide-*.cfg which sets
> > config_opts['package_manager']=dnf5
> > 
> > I.e. all fc40 packages having been built before fedora-40*.cfgs were
> > introduced, were using "dnf", while packages being built from now on
> > will be using "dnf"
> 
> Typo: This was meant to be
> "... were using "dnf5", ... will be using "dnf".
> 
> > Shouldn't fedora-40*.cfgs set config_opts['package_manager']=dnf5 ?
> > 
Good catch. F40 packages are suppossed to be built with dnf5
.

I believe Koji uses mock configs from Koji build tag configuration instead
those provided by mock-core-configs.

If locally run mock is expected to mimich Koji as much as possible, it should
change fedora-40*.cfg to use dnf5.

-- 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: Provides: libmupdf.so.23.10()(64bit) missing on *EL

[Petr Pisar]

V Thu, Feb 15, 2024 at 05:10:34PM +0100, Michael J Gruber napsal(a):
> Am Do., 15. Feb. 2024 um 17:06 Uhr schrieb Petr Pisar :
> >
> > V Thu, Feb 15, 2024 at 04:57:10PM +0100, Michael J Gruber napsal(a):
> > > Hi there
> > >
> > > I recently switched mupdf to shared libraries. During test builds on
> > > COPR for EPEL I noticed a strange difference to fedora builds which I
> > > can reproduce with koji scratch builds as well (epel9 vs fc39). The
> > > difference is in the automatic provides for the -libs sub package:
> > >
> > > Provides: mupdf-libs = 1.23.10-2.el9 mupdf-libs(x86-64) = 1.23.10-2.el9
> > >
> > > Provides: libmupdf.so.23.10()(64bit) mupdf-libs = 1.23.10-2.fc39
> > > mupdf-libs(x86-64) = 1.23.10-2.fc39
> > >
> > > And, of course, packages built against mupdf-devel automatically
> > > require ibmupdf.so.23.10()(64bit) and fail to install on *EL.
> > >
> > > I even tested with `%ldconfig_scriptlets libs`, which makes no difference.
> > >
> > > Both packages have the same file contents including the lib, the
> > > SONAME is `libmupdf.so.23.10`.
> > >
> > Where is the file with libmupdf.so.23.10 SONAME? I remember a discussion 
> > about
> > rpmbuild not to generate provides and requires for a SONAME if the libary is
> > not installed into a standard library path.
> 
> It's in /usr/lib64/ in both cases (x86_64, checked with
> rpmdev-extract). spec part is:
>
Does running a dependency generator for ELF files on that file report the
expected provides? Look at /usr/lib/rpm/fileattrs/elf.attr content. There
should be a ".../elfdeps --provides" command for generating provides. Take
that command and pass the library file as a possitional argument. An example:

/usr/lib/rpm/elfdeps --provides /usr/lib64/libacl.so.1.1.2301
libacl.so.1(ACL_1.0)(64bit)
libacl.so.1(ACL_1.1)(64bit)
libacl.so.1(ACL_1.1)(64bit)
libacl.so.1(ACL_1.2)(64bit)
libacl.so.1(ACL_1.2)(64bit)
libacl.so.1()(64bit)

-- 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: Provides: libmupdf.so.23.10()(64bit) missing on *EL

[Petr Pisar]

V Thu, Feb 15, 2024 at 04:57:10PM +0100, Michael J Gruber napsal(a):
> Hi there
> 
> I recently switched mupdf to shared libraries. During test builds on
> COPR for EPEL I noticed a strange difference to fedora builds which I
> can reproduce with koji scratch builds as well (epel9 vs fc39). The
> difference is in the automatic provides for the -libs sub package:
> 
> Provides: mupdf-libs = 1.23.10-2.el9 mupdf-libs(x86-64) = 1.23.10-2.el9
> 
> Provides: libmupdf.so.23.10()(64bit) mupdf-libs = 1.23.10-2.fc39
> mupdf-libs(x86-64) = 1.23.10-2.fc39
> 
> And, of course, packages built against mupdf-devel automatically
> require ibmupdf.so.23.10()(64bit) and fail to install on *EL.
> 
> I even tested with `%ldconfig_scriptlets libs`, which makes no difference.
> 
> Both packages have the same file contents including the lib, the
> SONAME is `libmupdf.so.23.10`.
> 
Where is the file with libmupdf.so.23.10 SONAME? I remember a discussion about
rpmbuild not to generate provides and requires for a SONAME if the libary is
not installed into a standard library path.

-- 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: Package review ticket status change after approval

[Petr Pisar]

V Tue, Feb 06, 2024 at 01:34:54PM +, Zbigniew Jędrzejewski-Szmek napsal(a):
> On Mon, Jan 29, 2024 at 06:47:21PM +, Mattia Verga via devel wrote:
> > That said, I'd like to make a request and maybe make all reviewers aware 
> > of a feature which was implemented some time ago. I've noticed many 
> > reviewers change the ticket status from ASSIGNED to POST when they flag 
> > the package as approved: I'd like to request to not do that.
> 
> The reason for POST is that this allows the reviews that are "done"
> from the reviewer's side to be easily distinguished in a bugzilla
> listing.

flags == fedora-review+

I don't say its easy to query, but it's the normative way stating that the
reviewer is done.

-- 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: Bodhi 8.0.2 deployed to prod

[Petr Pisar]

V Mon, Feb 05, 2024 at 07:00:28PM +, Mattia Verga via devel napsal(a):
> - There should be no more Updates ejected from the composes that remain 
> stuck in pending state due to wrong tags applied to their builds (or, 
> better, they should be automatically pushed again after 48 hours)
> - The webUI now allows unpushing Rawhide updates which fail gating tests
> - Builds associated to unpushed updates can now be moved to other 
> existing updates

Thanks.

-- 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: Figure out what killed an app (rhbz#2253099)

[Petr Pisar]

V Wed, Jan 31, 2024 at 01:07:42PM +0100, Milan Crha napsal(a):
>   evolution-3211 [003] d..1.   355.904404: signal_generate: sig=9 errno=0 
> code=128 comm=evolution pid=3211 grp=1 res=0
>   evolution-3211 [003] d..2.   355.904450: signal_generate: sig=9 errno=0 
> code=0 comm=bwrap pid=3257 grp=1 res=0
> 
Key information is code=128. That code is probably si_code member described in
sigaction(2). The manual lists a lot of values as constants. 128 value is
SI_KERNEL according to /usr/include/asm-generic/siginfo.h. It is documented
as "sent by the kernel from somewhere". It means the first signal does not
come a user space. It's genuinly generated by kernel. E.g. when the process is
killed for out-of-memory reason. However, in this case, I would expect kernel
to log this event into dmesg. E.g. out-of-memory killer is very verbose in
dmesg.

Strange thing is the second line. It reads that process 3211 (code=0 meads
SI_USER, "sent by kill, sigsend, raise") sent SIGKILL to 3257. It's
questionable how a process 3211 killed with the first signal can still emit
signals. A possible explanation is that the signals are procecessed
asychnously and evolution manages to dispatch the signal to bwrap before kernel
termites evolution because of the first signal. Or I misinterpret the
log.

-- 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: Figure out what killed an app (rhbz#2253099)

[Petr Pisar]

V Wed, Jan 31, 2024 at 11:08:16AM +0100, Milan Crha napsal(a):
>   Hi,
> I tried to investigate a rawhide bug:
> https://bugzilla.redhat.com/show_bug.cgi?id=2253099
> which is about Evolution being killed "by something". That's the thing,
> I do not know what killed it, thus even why it had been killed. It's
> even not killed after certain steps, it's killed "randomly", on various
> occasions.
> 
> I did search the internet, but they usually expect the killer is the
> OOM service, which logs about the action either in the dmesg or in the
> journal, but in this case there is no sign about whom killed it in
> either of these logs.
>

This procedure works for me
. The
tracefs file system has a nice log. An example of /usr/bin/sleep receiving
SIGKILL from bash:

root@fedora-40:/sys/kernel/debug/tracing # cat trace
# tracer: nop
#
# entries-in-buffer/entries-written: 1/1   #P:4
#
#_-=> irqs-off/BH-disabled
#   / _=> need-resched
#  | / _---=> hardirq/softirq
#  || / _--=> preempt-depth
#  ||| / _-=> migrate-disable
#   / delay
#   TASK-PID CPU#  |  TIMESTAMP  FUNCTION
#  | | |   | | |
bash-4867[002] d..1. 10571.864270: signal_generate: sig=9 
errno=0 code=0 comm=sleep pid=4866 grp=1 res=0

-- 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: Lost KDC for FEDORAPROJECT.ORG realm

[Petr Pisar]

V Tue, Jan 23, 2024 at 10:21:26AM -0500, Steve Dickson napsal(a):
> On 1/23/24 10:08 AM, Steve Dickson wrote:
> > I had to change my /etc/krb5.conf do to
> > some realm changes... and now when I
> > to a kinit to FEDORAPROJECT.ORG  it
> > hangs for a while then errors with
> > 
> > kinit: Cannot contact any KDC for realm 'FEDORAPROJECT.ORG' while
> > getting initial credentials
> > 
> > My question is, what has to be in the /etc/krb5.conf
> > for the FEDORAPROJECT.ORG realm to be found?
> > 
> > In the past I didn't think there was anything in
> > the file and assume the realm was found by the
> > 
> > includedir /etc/krb5.conf.d/
> > includedir /var/lib/sss/pubconf/krb5.include.d/
> > 
> On further review... it appears fedoraproject_org
> in /etc/krb5.conf.d/ defines the KDC for  FEDORAPROJECT.ORG
> 
> [realms]
>  FEDORAPROJECT.ORG = {
> kdc = https://id.fedoraproject.org/KdcProxy
> pkinit_anchors = FILE:/etc/pki/ipa/fedoraproject_ipa_ca.crt
>  }
>
> Has something change where I need to do some type of update?
>
This is roughly the correct settings.

Currently the KDC HTTP transport does not work because of a configuration
mistake on the server. 7 hours ago I managed to obtain a ticket by using a raw
Kerberos protocol with "kdc = ip02.id.fedoraproject.org:1088".

-- 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: Module needs a non-packaged module, how to?

[Petr Pisar]

V Tue, Dec 26, 2023 at 02:03:50PM -, Johan Vromans napsal(a):
> For the next release of my ChordPro application (fedora package `chordpro`,
> CPAN module `App::Music::ChordPro`) it needs a CPAN module that is not
> packaged: `JavaScript::QuickJS`.
> 
> How to proceed? I have no intentions to become package maintainer for this
> module. 

From engineering point of view, packaging JavaScript::QuickJS would be the
best option.

> Can I add the module source as `Source1` and build it together with the rest
> of ChordPro?

You can. But you need to follow
.

Also don't miss that if you install bundled JavaScript::QuickJS into standard
Perl paths (e.g. /usr/share/perl5/vendor_perl) it will become available to
other Perl code and users and you will get into same troubles as if you
packaged it separately.

> Should I use a `cpan` command to add it?

Do you mean when building chordpro in Fedora Koji? No, because Koji has no
access to the Internet.

Do you mean after installing chordpro on a user's systems when a user execute
the application? Not that it would be impossible, but it's against Fedora's
spirit (and maybe some rules) that packages that Fedora delivers are usable
per se without third-party artifacts.

> Or is there a better way?

lib/ChordPro/Delegate/ABC.pm shows that there more options than
JavaScript::QuickJS. But the other options are also not packaged in Fedora.

Maybe removing ChordPro::Delegate::ABC module from chordpro RPM package could
be an option. The module is only used from a single place and the use is
guarded with an eval block. If chordpro is usable without ABC support, then it
could be the way.

-- Petr


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

[rpms/perl-Font-AFM] PR #4: Do not depend on files from /usr/share

[Petr Pisar]

ppisar opened a new pull-request against the project: `perl-Font-AFM` that you 
are following:
``
Do not depend on files from /usr/share
``

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

[rpms/perl-Convert-Color] PR #1: Do not depend on files from /usr/share

[Petr Pisar]

ppisar opened a new pull-request against the project: `perl-Convert-Color` that 
you are following:
``
Do not depend on files from /usr/share
``

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

perl-URI-NamespaceMap license tag corrected

[Petr Pisar]

I corrected a mistake in perl-URI-NamespaceMap License tag from:

(GPL+ or Artistic) or Public Domain

to:

(GPL-1.0-or-later OR Artistic-1.0-Perl) AND LicenseRef-Fedora-Public-Domain

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

License of perl metapackage should be LicenseRef-Not-Copyrightable

[Petr Pisar]

V Fri, Dec 08, 2023 at 07:11:09AM +0100, Miroslav Suchý napsal(a):
> We added new license LicenseRef-Not-Copyrightable that should be used for
> packages like foo-filesystem that e.g., create just directories and does not
> have copyrightable code nor content.
> 
I believe all metapackages, i.e. packages without files which only require
another packages, fall into this category.

Therefore I believe that a binary "perl" package should:

-License:GPL-1.0-or-later OR Artistic-1.0-Perl
+License:LicenseRef-Not-Copyrightable

First, I wanted to write to legal list, to ask them whether
LicenseRef-Not-Copyrightable also applies to metapackages with a proper
upstream. But when I tried to formulate what binary "perl" means, I realized
that because of dual-lived modules, it is not all libraries, tools,
documentation and features you get by compiling perl sources. We transitively
install software built from different sources.  Also we cannot predict
dual-lived packages to comes with a new license. And we even do not want to
track the changes in perl package. Those are the reasons why we do not list
licenses of all 190 dependent packages in "perl".

Therefore I believe that "GPL-1.0-or-later OR Artistic-1.0-Perl" at "perl" is
an overly simplified statement that it's a lie.

By the way, if you want to list all the licenses used in the perl sources, RPM
has a new "SourceLicense" tag for that.

-- Petr



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

Re: F40 Change Proposal: F40 Change Proposal: Unify /usr/bin and /usr/sbin (System-Wide)

[Petr Pisar]

V Mon, Jan 08, 2024 at 09:42:41PM +, Zbigniew Jędrzejewski-Szmek napsal(a):
> On Mon, Jan 08, 2024 at 03:26:45PM +, Gary Buhrmaster wrote:
> > On Mon, Jan 8, 2024 at 1:37 PM Zbigniew Jędrzejewski-Szmek
> >  wrote:
> > > $ dnf5 repoquery -l $(dnf5 repoquery --whatprovides '/usr/sbin/*' --qf 
> > > '%{name}\n') | rg '/usr/s?bin/' | sed -r 's|(.*)/([^/]*)$|\2|' | sort | 
> > > uniq -c | rg -w 2
> > >
> > > says that /usr/sbin/{makemap,rpcinfo,rpcbind,sestatus,udevadm}
> > > "shadow" files in /usr/bin. But those are all symlinks, i.e. they will
> > > need just to be dropped to prevent a FTBFS. I added this list with
> > > four packages to the Scope section.
> > 
> > Thanks, but I think the query does not produce
> > all possible results, as I know for a fact that there is
> > a package (exabgp) that has both a /usr/sbin/exabgp-healthcheck
> > and a (different) /usr/bin/exabgp-healthcheck file
> > (which is why I prompted my query, as I expect
> > there might be others (I plan to fix exabgp)).
> 
> Indeed. With both dnf-5 and dnf5, the inner repoquery doesn't list exabgp.
> Either a bug or I'm doing something wrong.
> 
Thanks for testing DNF5. I notified DNF5 maintainers
.

-- 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: F40 Change Proposal: F40 Change Proposal: Unify /usr/bin and /usr/sbin (System-Wide)

[Petr Pisar]

V Thu, Dec 21, 2023 at 10:20:11AM +0100, Vít Ondruch napsal(a):
> 
> Dne 20. 12. 23 v 20:53 Aoife Moloney napsal(a):
> > ** Adjust `%_sbindir` in `/usr/lib/rpm/macros` (part of `rpm`
> > package). Packages will be updated automatically during the mass
> > rebuild.
> 
> 
> Isn't the ultimate goal to drop the `%_sbindir` all together? Shouldn't at
> minimum the packaging guidelines be updated? We could probably drop the
> `%_sbindir` automatically in near future.
> 
That or another, I'd like this Change to explicitly state whether packagers are
supposed to keep using %_sbindir, or to replace it with %_bindir in their spec
files.

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

A license correction in rwhoisd

[Petr Pisar]

I corrected a license tag in rwhoisd package from:

Public Domain and zlib and GPLv2+

to:

Public Domain and HSRL and GPLv2+

The License tag will be converted to SPDX format once Legal approves new
license identifiers.

-- 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: libxml2 2.12.0 (and 2.12.1) in rawhide, with some API breaks

[Petr Pisar]

V Wed, Nov 29, 2023 at 04:45:10AM -0500, Andrea Bolognani napsal(a):
> Since the libxml2 developers are apparently okay with changing their
> structs in ABI-incompatible ways on account of the fact that users
> are not supposed to be accessing them directly anyway, perhaps they
> could fully commit to this idea by moving struct definitions to the
> .c files and leaving just the typedefs in the .h files? That's how
> other libraries handle the situation.
>
I asked the upstream .

-- 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: libxml2 2.12.0 (and 2.12.1) in rawhide, with some API breaks

[Petr Pisar]

V Tue, Nov 28, 2023 at 12:24:45PM +0100, Dodji Seketeli napsal(a):
> Daniel P. Berrangé  a écrit:
> 
> > On Mon, Nov 27, 2023 at 04:20:16PM +0100, Fabio Valentini wrote:
> >> On Fri, Nov 24, 2023 at 12:08 PM David King  
> >> wrote:
> >> >
> >> > The latest released versions of libxml2 have a couple of important
> >> > changes in header files that have unintentionally caused some packages
> >> > to fail to build without modification, including:
> >> >
> >> > * several functions now accept or return a const xmlError struct
> >> > * cyclic dependencies in header files were fixed (by dropping some
> >> >includes)
> >> 
> >> Sorry if the answer to this question is obvious - but shouldn't
> >> breaking changes like these cause an soname bump?
> >> I realize the whole "unintentional" part - but if these changes also
> >> affect ABI (the first sounds like it might do that), dependent
> >> packages would need to be rebuilt either way, wouldn't they?
> >
> > IIUC, the changes in libxml2 are API breaks, but not ABI breaks.
> >
> > ie the 'xmlError' parameter should have been const all along,
> > and apps would have been using it as if it were const. The
> > API was changed to correct this mistake and should be backcompat
> > with an pre-existing compiled app, but cause warnings on new
> > builds. Annoying, but an acceptable change without soname bump.
> 
> For what it's worth, the ABI compatibility verifier caught this change
> between libxml2.so.2.11.5 and libxml2.so.2.12.0 and categorized it as
> being "ABI compatible" (i.e, not incompatible/breaking) at:
> https://artifacts.dev.testing-farm.io/b7d369b0-f288-4564-a331-48492c20bf8c/:
> 
>   [C] 'function int xmlCopyError(xmlErrorPtr, xmlErrorPtr)' at error.c:985:1 
> has some indirect sub-type changes:
> parameter 1 of type 'typedef xmlErrorPtr' changed:
>   entity changed from 'typedef xmlErrorPtr' to compatible type 'const 
> xmlError*'
> in pointed to type 'struct _xmlError':
>   entity changed from 'struct _xmlError' to 'const _xmlError'
>   type size hasn't changed
> 
> I guess the important bit here is "entity changed from 'struct _xmlError' to 
> 'const _xmlError'".
> 
> So, yes, this is not an ABI incompatible change.
>
Well abidiff for createrepo_c

complains:

  underlying type 'xmlParserCtxt*' changed:
in pointed to type 'typedef xmlParserCtxt' at tree.h:40:1:
  underlying type 'struct _xmlParserCtxt' at parser.h:181:1 changed:
type size changed from 3840 to 3968 (in bits)
4 data member insertions:
  'unsigned int maxAmpl', at offset 3840 (in bits) at 
parser.h:323:1
  'xmlParserNsData* nsdb', at offset 3872 (in bits) at 
parser.h:325:1
  'unsigned int attrHashMax', at offset 3904 (in bits) at 
parser.h:326:1
  'xmlAttrHashBucket* attrHash', at offset 3936 (in bits) at 
parser.h:327:1
1 data member changes (5 filtered):
  type of 'int* attallocs' changed:
in pointed to type 'int':
  type name changed from 'int' to 'unsigned int'
  type size hasn't changed

While most (all?) libxml2 functions pass a pointer to xmlParserCtxt, a
definition of the xmlParserCtxt structure is open to anybody in
. That means an application built against old libxml2 can
construct a different structure than libxml2 expects. That is called
an ABI breakage.

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

[rpms/perl-local-lib] PR #2: Ensure csh syntax is used for C shell even if SHELL env var is unset.

[Petr Pisar]

ppisar commented on the pull-request: `Ensure csh syntax is used for C shell 
even if SHELL env var is unset.` that you are following:
``
The AVC failure is tracked at . 
It won't block perl-local-lib because it does not enforce 
fedora-ci.koji-build.installability.functional test 
.

This change will get info Fedora when a maintainer of this package builds it. A 
Fedora version after another. If this package is distributed in EPEL, then 
likewise. If it is distributed in RHEL, you need to go to Red Hat support and 
ask them to include this change.
``

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

Re: How can I delete a rawhide Bodhi update?

[Petr Pisar]

V Thu, Nov 23, 2023 at 04:40:39PM +0100, Florian Weimer napsal(a):
> I've got an update that I don't see pushed to stable.  How do I make
> sure that doesn't happen?
> 
> As it's for rawhide, I didn't create the Bodhi update, and I don't see
> an option to delete it.
> 
That's the glory automation which creates updates after finishing a build on
behalf of the user wihout ownership by the user.

Once there is such update created, you only can file a ticket against relengs
(or infra) to delete the update. Without admins intervening, your only option
is to bump a release and do new build. The old, stuck update will get
superseded by the new update.

To prevent from creating the updates, the only way, known to me, is building
into a side tag and creating the update from the sidetag. Then you will be an
owner of the update.

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

[rpms/perl-local-lib] PR #2: Ensure csh syntax is used for C shell even if SHELL env var is unset.

[Petr Pisar]

ppisar commented on the pull-request: `Ensure csh syntax is used for C shell 
even if SHELL env var is unset.` that you are following:
``
Just a nit pick: If SHELL is not set, Perl local::lib is not fooled into sh 
syntax. It's a documented feature:

   *   Rather basic shell detection. Right now anything with csh in its
name is assumed to be a C shell or something compatible, and
everything else is assumed to be Bourne, except on Win32 systems. If
the "SHELL" environment variable is not set, a Bourne-compatible
shell is assumed.

But I agree that your fix is appropriate.
``

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

Re: DNF5: Checking signatures of packages installed out of a repository?

[Petr Pisar]

V Tue, Nov 14, 2023 at 01:25:08PM -0500, Christopher napsal(a):
> On Tue, Nov 14, 2023 at 9:24 AM Petr Pisar  wrote:
> >
> > V Tue, Nov 14, 2023 at 08:16:39AM -0500, Christopher napsal(a):
> > > On Tue, Nov 14, 2023 at 8:03 AM Jaroslav Mracek  
> > > wrote:
> > > >
> > > > I believe that one of the strong complains was related to not signed 
> > > > packages. The use case is that when I build RPMs locally and then I 
> > > > install them (see bellow).
> > > >
> > > > dnf install *.rpm --setopt=localpkg_gpgcheck=true
> > > > ...
> > > > Package dnf-4.17.1-1.git.9598.552e61e.fc38.noarch.rpm is not signed
> > > > Package dnf-automatic-4.17.1-1.git.9598.552e61e.fc38.noarch.rpm is not 
> > > > signed
> > > > Package dnf-data-4.17.1-1.git.9598.552e61e.fc38.noarch.rpm is not signed
> > > > Package python3-dnf-4.17.1-1.git.9598.552e61e.fc38.noarch.rpm is not 
> > > > signed
> > > > Package yum-4.17.1-1.git.9598.552e61e.fc38.noarch.rpm is not signed
> > > > Error: GPG check FAILED
> > > >
> > > > Jaroslav
> > >
> > > I think for the sake of security, it'd be better if this were on by
> > > default, and you just had to specify the --nogpgcheck
> >
> > Technical note: --nogpgcheck does not imply localpkg_gpgcheck=false. Both of
> > them operate independently. That's another painful property of the current
> > code and documentation.
> >
> > -- Petr
> 
> Why wouldn't this apply? Both the documentation for 'dnf' and
> 'dnf.conf' use similar terminology "gpgcheck", and the man page says
> "Skip checking GPG signatures on packages (if RPM policy allows)."

dnf.conf(5) reads (shortened):

gpgcheck
Whether to perform GPG signature check on packages found in this
repository.

localpkg_gpgcheck
Whether to perform a GPG signature check on local packages (packages in
a file, not in a repository).

> it doesn't apply, it seems like it definitely *should*, for
> intuitiveness-sake.

I agree it's not intuitive. That's why SuSE wants the meaning of "gpgcheck"
option to be configurable
<https://github.com/rpm-software-management/dnf5/issues/727>.

-- 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: DNF5: Checking signatures of packages installed out of a repository?

[Petr Pisar]

V Tue, Nov 14, 2023 at 08:16:39AM -0500, Christopher napsal(a):
> On Tue, Nov 14, 2023 at 8:03 AM Jaroslav Mracek  wrote:
> >
> > I believe that one of the strong complains was related to not signed 
> > packages. The use case is that when I build RPMs locally and then I install 
> > them (see bellow).
> >
> > dnf install *.rpm --setopt=localpkg_gpgcheck=true
> > ...
> > Package dnf-4.17.1-1.git.9598.552e61e.fc38.noarch.rpm is not signed
> > Package dnf-automatic-4.17.1-1.git.9598.552e61e.fc38.noarch.rpm is not 
> > signed
> > Package dnf-data-4.17.1-1.git.9598.552e61e.fc38.noarch.rpm is not signed
> > Package python3-dnf-4.17.1-1.git.9598.552e61e.fc38.noarch.rpm is not signed
> > Package yum-4.17.1-1.git.9598.552e61e.fc38.noarch.rpm is not signed
> > Error: GPG check FAILED
> >
> > Jaroslav
> 
> I think for the sake of security, it'd be better if this were on by
> default, and you just had to specify the --nogpgcheck

Technical note: --nogpgcheck does not imply localpkg_gpgcheck=false. Both of
them operate independently. That's another painful property of the current
code and documentation.

-- 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: Groff: Revert the mapping of special characters for UTF-8 devices introduced in 1.23.0 version

[Petr Pisar]

V Thu, Nov 09, 2023 at 12:11:55PM +0100, Lukas Javorsky napsal(a):
> >
> > Did we try to persuade upstream to revert the problem?  But if they're
> > not receptive then a downstream fix aligned with Debian looks right.
> >
> 
> I didn't yet. However, if they decided to stop mapping these characters, I
> don't think they would be willing to revert it back. They mentioned the
> option to map it locally as I did in the PR. I assume they want to stop
> mapping it on their end and let distros decide if they want to do it
> themselves.
> 
I think an upstream only wants to adhere to the language specification
(groff_char(7)). These small differences became prominent with the advent of
UTF-8 capable terminals. They have always been visible in a PostScript output.

Imagine you are the upstream and a user sends you a bug report that groff does
not behave according to the specification. While another user complains that
his nonconforming input behaves weirdly. There is no solution which would
satisfy both.

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

perl-Time-Out-0.21 license change

[Petr Pisar]

perl-Time-Out-0.21 changed a license back from

Artistic-2.0 AND (GPL-1.0-or-later OR Artistic-1.0-Perl)

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

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

perl-Time-Out license change

[Petr Pisar]

perl-Time-Out-0.20 changed a license from
GPL-1.0-or-later OR Artistic-1.0-Perl
to
Artistic-2.0 AND (GPL-1.0-or-later OR Artistic-1.0-Perl)

-- 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: DNF5: Checking signatures of packages installed out of a repository?

[Petr Pisar]

V Tue, Oct 31, 2023 at 04:49:30PM -0700, Kevin Fenzi napsal(a):
> FWIW, from what I can recall, yum used to check all packages, but this
> resulted in tons of people complaining because they did not want it to
> check their local packages. So, a localpkg_gpgcheck option was added and
> set to false. dnf4 still has this option.
> 
Thanks for bringing this option I did not know about. DNF5 supports it and it
also defaults to false.

-- 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: DNF5: Checking signatures of packages installed out of a repository?

[Petr Pisar]

V Tue, Oct 31, 2023 at 04:32:09PM +0100, Fabio Valentini napsal(a):
> On Tue, Oct 31, 2023 at 4:24 PM Petr Pisar  wrote:
> >
> > Hello,
> >
> > DNF5 got a complaint
> > <https://github.com/rpm-software-management/dnf5/issues/991> that "dnf 
> > update
> > https://...; skips verifying package signatures:
> >
> > $ sudo dnf update 
> > https://kojipkgs.fedoraproject.org//packages/gnome-control-center/45.1/2.fc40/data/signed/a15b79cc/x86_64/gnome-control-center-45.1-2.fc40.x86_64.rpm
> >  
> > https://kojipkgs.fedoraproject.org//packages/gnome-control-center/45.1/2.fc40/data/signed/a15b79cc/noarch/gnome-control-center-filesystem-45.1-2.fc40.noarch.rpm
> > [...]
> > Warning: skipped PGP checks for 2 package(s).
> >
> > A DNF5 developer confirmed that old DNF4 does not verify signatures too.
> > The verification happens only for packages comming from a repository. Why 
> > DNF5
> > looks bad is because it actually prints the warning and thus keeps the user
> > better informed.
> >
> > The nonchecking behavior probably exists to make installing local packages
> > easy. If DNF5 would insist on checking the signatures, Fedora users would 
> > have
> > to pass --no-gpgchecks option to their "dnf5" commands to override the new
> > default, or start signing their packages. As always security is not easy.
> >
> > Because this an old behavior and some users probably depend on it, enabling
> > the verification for all cases looks like an abrupt change.
> >
> > I would would like to hear your opinion: Should DNF5 start verifying all
> > packages? Should DNF5 keep ignoring signatures for out-of-repository 
> > packages?
> > Or should rather narrow the verification skip to packages from a local file
> > system? Any other options?
> 
> I wonder - how would DNF (4 or 5 doesn't matter) know how to check that at 
> all?
> I mean, if the package isn't associated with a repository (like
> installing an RPM directly), which GPG key should it even be checked
> against?
> 
Against any key already existing in an RPM database (rpm -qa | grep gpg-pubkey).

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

DNF5: Checking signatures of packages installed out of a repository?

[Petr Pisar]

Hello,

DNF5 got a complaint
 that "dnf update
https://...; skips verifying package signatures:

$ sudo dnf update 
https://kojipkgs.fedoraproject.org//packages/gnome-control-center/45.1/2.fc40/data/signed/a15b79cc/x86_64/gnome-control-center-45.1-2.fc40.x86_64.rpm
 
https://kojipkgs.fedoraproject.org//packages/gnome-control-center/45.1/2.fc40/data/signed/a15b79cc/noarch/gnome-control-center-filesystem-45.1-2.fc40.noarch.rpm
[...]
Warning: skipped PGP checks for 2 package(s).

A DNF5 developer confirmed that old DNF4 does not verify signatures too.
The verification happens only for packages comming from a repository. Why DNF5
looks bad is because it actually prints the warning and thus keeps the user
better informed.

The nonchecking behavior probably exists to make installing local packages
easy. If DNF5 would insist on checking the signatures, Fedora users would have
to pass --no-gpgchecks option to their "dnf5" commands to override the new
default, or start signing their packages. As always security is not easy.

Because this an old behavior and some users probably depend on it, enabling
the verification for all cases looks like an abrupt change.

I would would like to hear your opinion: Should DNF5 start verifying all
packages? Should DNF5 keep ignoring signatures for out-of-repository packages?
Or should rather narrow the verification skip to packages from a local file
system? Any other options?

-- 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: status openssl1.1

[Petr Pisar]

V Mon, Oct 16, 2023 at 08:55:12AM +0200, josef radinger via devel napsal(a):
> Hi
> 
> openssl1.1 reached EOS on recently (11th September 2023 I assume)
> https://www.openssl.org/blog/blog/2023/03/28/1.1.1-EOL/
> 
> according to
> https://www.openssl.org/source/:
> ...
> The previous LTS version (the 1.1.1 series) is also available but has
> recently gone out of support.
> ...
> 
> paid extended support for 1.1.1 would be available, but is maybe not the way
> to go for fedora.
> 
> we have
> https://fedoraproject.org/wiki/Changes/DeprecateOpensslCompat#Upgrade/compatibility_impact
> with no changes since 2022
> and a closed tracker bug at
> https://bugzilla.redhat.com/show_bug.cgi?id=2108694
> 
> maybe we should start deprecating that package?
> 
The package is already deprecated:

# dnf5 repoquery --provides openssl1.1 | grep deprecated
deprecated()

Maybe you wanted to say start removing? I rough estimation of an impact of the
removal are these 3 components:

gloo-0.5.0^git20230824.01a0c81-6.fc40.src.rpm
opensmtpd-6.8.0p2-12.fc39.src.rpm
python3.6-3.6.15-20.fc39.src.rpm

-- 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: Execute RPM dependency generators on the .spec file which ships them

[Petr Pisar]

V Fri, Oct 06, 2023 at 06:06:14PM +0200, Vít Ondruch napsal(a):
> I am still playing with idea of executing RPM dependency generators on the
> .spec file which ships them. I have created RPM RFE ticket quite a while ago
> here:
> 
> https://github.com/rpm-software-management/rpm/issues/782
> 
> So for no luck with having this implemented.
> 
> However, I think there is reasonable way. It would be enough to have some
> generic attr file around. I have create small test package exploring this
> idea and you can find it in my Copr repo:
> 
> https://copr.fedorainfracloud.org/coprs/vondruch/rpm-local-generator/
> 
> https://copr-dist-git.fedorainfracloud.org/cgit/vondruch/rpm-local-generator/rpm-local-generator-support.git/tree/rpm-local-generator-support.spec
> 
> On the same place, you can also find package leveraging this concept:
> 
> https://copr-dist-git.fedorainfracloud.org/cgit/vondruch/rpm-local-generator/rpm-local-generator-test.git/tree/rpm-local-generator-test.spec
> 
> Would somebody else benefit from this idea/package or can somebody spot some
> issue with it? Thx for feedback.
> 
That's hilarious because it's completely out of specification for the genarators
:

A generator is just an executable that reads file name(s) from stdin

While your rpm-local-generator-test.spec redefines it to a function reading
an argument:

%global __local_generator_provides() 
local-generator-provide(%%{basename:%{1}})

I'd like to see comments from RPM maintainers.

Does it work for multiple files packaged in rpm-local-generator-test.spec?

-- 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: Intention to tighten RPM crypto-policy back

[Petr Pisar]

V Fri, Oct 06, 2023 at 12:53:23PM +0200, Kamil Paral napsal(a):
> On Tue, Sep 26, 2023 at 7:23 PM Alexander Sosedkin 
> wrote:
> 
> > On Tue, Sep 19, 2023 at 7:47 PM Kevin Fenzi  wrote:
> > > It might be good to go through all the ones that were hit by this (it
> > > wasn't just chrome) and indicate if they are now fixed.
> > > You can see a partial list in the common bug:
> > >
> > >
> > https://discussion.fedoraproject.org/t/popular-third-party-rpms-fail-to-install-update-remove-due-to-security-policies-verification/70498
> > >
> > > and in the discussion off it.
> >
> > Whoa, that's too many, I suspect misreporting.
> >
> 
> It was definitely accurate at the time when I wrote it :)

These Fedora Project keys distribute in 
are also affected:

$ gpg --list-keys 6A2FAEA2352C64E5
pub   rsa4096 2013-12-16 [SCE]
  91E97D7C4A5E96F17F3E888F6A2FAEA2352C64E5
uid   [  neznámá   ] Fedora EPEL (7) 

$ gpg --list-keys 21EA45AB2F86D6A1
pub   rsa4096 2019-06-05 [SCE]
  94E279EB8D8F25B21810ADF121EA45AB2F86D6A1
uid   [  neznámá   ] Fedora EPEL (8) 

$ gpg --list-keys 7BB90722DBBDCF7C
pub   rsa4096 2018-11-13 [SCE] [platnost skončí: 2028-12-31]
  C2A3FA9DC67F68B98BB543F47BB90722DBBDCF7C
uid   [  neznámá   ] Fedora (iot 2019) 

-- 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: An update on RHEL moving to issues.redhat.com

[Petr Pisar]

V Mon, Sep 18, 2023 at 10:12:17AM +0100, Daniel P. Berrangé napsal(a):
> On Mon, Sep 18, 2023 at 09:57:28AM +0200, Petr Pisar wrote:
> > V Fri, Sep 15, 2023 at 01:27:23PM -0400, Colin Walters napsal(a):
> > > To state the blindingly obvious thing, RHEL made a decision to centralize 
> > > on
> > > Gitlab.  Having Fedora be on pagure creates IMO unnecessary friction for 
> > > me.
> > > I would be quite curious to get some sort of survey of other engineers for
> > > how they feel.
> > 
> > My selfishly preferable option is not to use Gitlab.com for Fedora exactly
> > because RHEL uses Gitlab.com. The reason is very practical: You need 
> > separate
> > accounts for the two projects and GitLab.com is not good at using multiple
> > accounts simulatenously. Having different systems makes to problem go away 
> > and
> > my life easier.
> 
> You don't require separate accounts. It is a choice developers can
> make to keep their upstream vs RHEL work in gitlab.com separated,
> or under the same account. There are pros & cons, so it is really
> a matter of personal preference.
>
It's is a matter of security. With a single account you give Fedora admins
an access to RHEL and vice versa.

-- 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: An update on RHEL moving to issues.redhat.com

[Petr Pisar]

V Fri, Sep 15, 2023 at 01:27:23PM -0400, Colin Walters napsal(a):
> To state the blindingly obvious thing, RHEL made a decision to centralize on
> Gitlab.  Having Fedora be on pagure creates IMO unnecessary friction for me.
> I would be quite curious to get some sort of survey of other engineers for
> how they feel.

My selfishly preferable option is not to use Gitlab.com for Fedora exactly
because RHEL uses Gitlab.com. The reason is very practical: You need separate
accounts for the two projects and GitLab.com is not good at using multiple
accounts simulatenously. Having different systems makes to problem go away and
my life easier.

-- 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: Automate your Fedora package maintenance using Packit

[Petr Pisar]

V Fri, Sep 15, 2023 at 03:13:22PM +0100, Daniel P. Berrangé napsal(a):
> I think it isn't too hard to make it acceptable, just stick a
> flag in the middle of your process that human has to acknowledge
> eg:
> 
>   1. Release monitoring files the new BZ ticket (it already includes
>  wording warning the maintainer to review the new release for
>  licensing changes).
> 
>  This BZ would have a flag set  'license-review=?' initially
> 
>   2. Maintainer reviews the new tarball to check the license
>  situation is all still golden.
> 
>  If OK, maintainer toggles flag to license-review=+,
>  else toggles to license-review=-
> 
>   3. Packit sees the flag approval and its magic happens to
>  upload tarball and file pull request, etc
> 
> 
I like this.

-- 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: Automate your Fedora package maintenance using Packit

[Petr Pisar]

V Fri, Sep 15, 2023 at 12:53:21PM +0200, Laura Barcziova napsal(a):
> Yes, Fedora dist-git lookaside cache. The upstream archive is uploaded
> automatically

Did you know that a license review must precede uploading to Fedora dist-git
lookaside cache? The reason is once the archive is uploaded, Fedora
distributes it.

-- 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: Automate your Fedora package maintenance using Packit

[Petr Pisar]

V Fri, Sep 15, 2023 at 09:22:46AM +0200, Laura Barcziova napsal(a):
> Once set up, here's how it works:
> 
>-
> 
>Upstream Release Monitoring creates a Bugzilla bug when new upstream
>versions are detected.
>-
> 
>As a reaction to that, Packit:
>-
> 
>   automatically uploads the upstream archive to the lookaside cache,
>   -
What lookaside cache? Fedora dist-git? Who does review licenses in the new
upstream archive BEFORE uploading it?

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

perl-CBOR-XS license corrected

[Petr Pisar]

I corrected perl-CBOR-XS license from:

GPLv3+ and (BSD or GPLv2+)

to:

GPL-1.0-or-later AND (BSD-2-Clause OR GPL-2.0-or-later)

-- 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: KDE and GNOME Join Hands To Add Payments To Turn Flathub Into a Store for the Linux Desktop

[Petr Pisar]

V Fri, Sep 01, 2023 at 02:25:37PM +0100, Daniel P. Berrangé napsal(a):
> On Wed, Aug 30, 2023 at 10:18:50PM -, Ryan Bach via devel wrote:
> > It would be nice for Redhat to monetize the Desktop. What do you guys think?
> 
> IMHO talking about Red Hat needing to monetize the desktop is missing
> the point of this. There are 1000's of OSS projects that will never be
> interesting to big the Linux vendors like Red Hat, SUSE, etc, and yet
> the people working on those projects still have bills to pay.
> 
> The proposals wrt donations / payments in Flathub would support the
> long tail of OSS projects, by providing another place to potentially
> collect some funds directly from users, without having a commercial
> Linux vendor in the middle picking & choosing who to give funding to
> while skimming off the top of the funds.
> 
That's quite naive idea. In real world any middle man who collects and
distributes money in order to "sell software" will have to obey to financial,
tax, and security regulations. Thus no middle man will do this task without
skimming the funds. Commercial entities are better suited for this role than
non-profit organisations.

It would be another story if the transaction system did not involve money.
E.g. delivering payment information from software authors to software users
and delivering software in the same direction. However, these nonmonetery
systems suffer from various fraud attempts and loss of trust.

Commercial middle entities fights against the frauds by requesting personal
data and cash deposits. That's another level of regulations which nobody will
undergo for "free".

Then what left is mediating donations. But that does not need any formal or
unified system. Software authors can siply keep a notice in README/About with
a payment details.

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

teckit license corrected

[Petr Pisar]

After clarifying an MPL version with an upstream, I corrected a license tag
from:

(LGPL-2.1-or-later OR CPL-1.0) AND (LGPL-2.1-or-later OR GPL-2.0-or-later OR 
MPL-2.0 OR MPL-1.1)

to:

(LGPL-2.1-or-later OR CPL-1.0) AND (LGPL-2.1-or-later OR GPL-2.0-or-later OR 
MPL-2.0)

-- 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: Adding Passim as a Fedora 40 feature?

[Petr Pisar]

V Fri, Aug 25, 2023 at 07:34:35PM +0100, Richard Hughes napsal(a):
> you need to reboot into the new firmware before the published firmware gets
> shared;

Won't this suppress an effeciency of the local sharing? If a typical period
between a download and the reboot is significantly longer than a period in
which machines check for and download the firmaware, it will happen that all
machines will sepearately download the firmware from a central server instead
of downloading it from local peers. Because all the machines will be waiting
on the reboot.

> on the logic that you don't want to advertise to the world that you're
> currently running insecure firmware.
> 
For how long is the firmware adveritised? As long as it is advertised, people
know what version you are currently running. This information becomes
interesting when a new firmware is released. Then you have exactly the same
problem you want to address.

-- 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: Adding Passim as a Fedora 40 feature?

[Petr Pisar]

V Fri, Aug 25, 2023 at 12:42:34PM +0100, Richard Hughes napsal(a):
> The tl;dr: is I want to add a mDNS server that reshares the public
> firmware update metadata from the LVFS on your LAN.

I see you wrote "metadata". It's not the firmware itself .Sill my concert is
the same: what's a license of the metada? Can I redistribute them?

-- 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: Replacing DNF with DNF5: changes reverted and helping steps

[Petr Pisar]

V Tue, Aug 15, 2023 at 11:52:55AM +0100, Peter Robinson napsal(a):
> On Tue, Aug 15, 2023 at 11:41 AM Petr Pisar  wrote:
> >
> > V Tue, Aug 15, 2023 at 12:09:34PM +0200, Vít Ondruch napsal(a):
> > > Dne 14. 08. 23 v 19:30 Adam Williamson napsal(a):
> > > > On Mon, 2023-08-14 at 16:59 +0200, Vít Ondruch wrote:
> > > > > $ sudo dnf update -x dnf
> > > > > Updating and loading repositories:
> > > > > Repositories loaded.
> > > > > Failed to resolve the transaction:
> > > > > Problem 1: package mass-prebuild-1.1.0-1.fc39.noarch requires dnf, but
> > > > > none of the providers can be installed
> > [...]
> > > > I think only the mass-prebuild maintainer can help you there. dnf5
> > > > cannot be set to provide dnf, because it...doesn't.
> > >
> > > I know and yet again, I have not find any issues using mass-prebuild with
> > > DNF5 and until now, it worked just fine. I probably won't ever understand
> > > this game with names.
> > >
> > Since DNF5 is planned as a replacement for Fedora 40 and because Fedora 39 
> > has
> > already branched, I'd like to see making dnf5 replacing dnf package in 
> > Fedora
> > 40 as soon as possible. To have a testing, integration, and stablization 
> > period
> > as long as possible.
> 
> Quoting Samantha [1]:
> 
> "We've gone ahead and decided not to replace DNF with DNF05 in Fedora
> 39 and, perhaps notably, Fedora 40 as well. Fedora 41 is the safest
> option at the moment."
> 
> So I thought it wasn't coming until Fedora 41?
> 
You are right. I was mistaken and thought that DNF5 only slipped a Fedora
release. Then ignore my suggestion.

-- 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: Replacing DNF with DNF5: changes reverted and helping steps

[Petr Pisar]

V Tue, Aug 15, 2023 at 12:09:34PM +0200, Vít Ondruch napsal(a):
> Dne 14. 08. 23 v 19:30 Adam Williamson napsal(a):
> > On Mon, 2023-08-14 at 16:59 +0200, Vít Ondruch wrote:
> > > $ sudo dnf update -x dnf
> > > Updating and loading repositories:
> > > Repositories loaded.
> > > Failed to resolve the transaction:
> > > Problem 1: package mass-prebuild-1.1.0-1.fc39.noarch requires dnf, but
> > > none of the providers can be installed
[...]
> > I think only the mass-prebuild maintainer can help you there. dnf5
> > cannot be set to provide dnf, because it...doesn't.
> 
> I know and yet again, I have not find any issues using mass-prebuild with
> DNF5 and until now, it worked just fine. I probably won't ever understand
> this game with names.
> 
Since DNF5 is planned as a replacement for Fedora 40 and because Fedora 39 has
already branched, I'd like to see making dnf5 replacing dnf package in Fedora
40 as soon as possible. To have a testing, integration, and stablization period
as long as possible.

That would also resolve Vít's issue with mass-prebuild.

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

[rpms/perl-HTTP-Tiny] PR #3: Add perl-HTTP-Tiny-https package for delivering of HTTPs support

[Petr Pisar]

ppisar commented on the pull-request: `Add perl-HTTP-Tiny-https package for 
delivering of HTTPs support` that you are following:
``
This patch makes https tests optional in perl-HTTP-Tiny-tests. That goes 
against current practice we (at least I) have in tests subpackages: We tend to 
enforce all test features in tests subpackages. My approach has two advantages: 
The tests are deterministic and the https feature can be controlled with 
perl_bootstrap macro.

When you add a hard dependency on perl-HTTP-Tiny-https into many packages, it 
could happen that you make the packages uninstallable while bootstrapping and 
that would lead to build cycles as Jitka pointed. I'd rather wrap the hard 
Requires on IO::Socket::SSL in perl-HTTP-Tiny-https with perl_boostrap 
condition. On one hand, that would make the perl-HTTP-Tiny-https dummy while 
bootstrapping. On the other hand, it would centralize the boostrapping to 
perl-HTTP-Tiny.spec. With your current approach you will have to go after every 
of the hard Requires and condition them with perl_bootstrap on case-by-case 
basis.

I don't say that your approach is utterly wrong, it has it's own potential. I 
only say that I would use a different approach.
``

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

Re: Removal of Modular repos broke upgrades to Fedora 39: What now?

[Petr Pisar]

V Fri, Aug 04, 2023 at 12:16:14PM +0200, Miro Hrončok napsal(a):
> With the retirement of modularity, the modular dnf repositories for Fedora
> 39 no longer exist. However, this will introduce a problem during upgrades.
> When users try to upgrade from previous Fedora releases with
> fedora-repos-modular installed, they will hit fatal errors that will
> probably look like this:
> 
> Errors during downloading metadata for repository 'fedora-modular':
>   - Status code: 404 for
> https://mirrors.fedoraproject.org/metalink?repo=fedora-modular-39=x86_64
> (IP: ...)
>   - Status code: 404 for
> https://mirrors.fedoraproject.org/metalink?repo=fedora-modular-39=x86_64
> (IP: ...)
>   - Status code: 404 for
> https://mirrors.fedoraproject.org/metalink?repo=fedora-modular-39=x86_64
> (IP: ...)
> Error: Failed to download metadata for repo 'fedora-modular': Cannot prepare
> internal mirrorlist: Status code: 404 for
> https://mirrors.fedoraproject.org/metalink?repo=fedora-modular-39=x86_64
> (IP: ...)
> 
> Or:
> 
> Error: Failed to download metadata for repository 'fedora-modular': Cannot
> download repomd.xml: Cannot download repodata/repomd.xml: All mirrors were
> tried
> 
> (The actual error might differ depending on the exact state of the removal
> of the modular repos and their mirrorlist etc.)
> 
> 
> This is caused by the combination of the following facts:
> 
>  - the modular repo configuration in Fedora 37/38 has 
> skip_if_unavailable=False
>  - when the releasever is set to 39, the URLs of the repos give error 404
> 
This is a general problem of removing a repository from the distribution.
Unrelated to Modularity.

I propose this procedure: Keep Fedora <= 38 as it is. For Fedora 39 and 40
keep an empty repository on mirrors and uninstall the repository configuration
by obsoleting fedora-repos-modular. Then in Fedora 41 remove the repository
from mirrors.

That way users of currently relased Fedoras <= 38 will have access to their
modules, and users upgrading to Fedora 39 or 40 won't get the 404 HTTP error.
After this upgrade to 39 or 40 the repository definition became nonexistant
thanks to the obsolete. Fedora >= 41 can stop mirroring the repository because
upgrade guidelines only support jump to N+1 and N+2 distribution release.

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

lpsolve license change

[Petr Pisar]

lpsolve-5.5.2.11-3.fc39 changed a license from:

LGPL-2.1-or-later AND GPL-2.0-or-later WITH Bison-exception-2.2

to:

LGPL-2.1-or-later AND GPL-2.0-or-later WITH Bison-exception-2.2 AND BSD-3-clause

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

cvs license corrected

[Petr Pisar]

I corrected a license tag for cvs package from:

BSD and GPL+ and GPLv2+ and LGPLv2+ and zlib and Public Domain

to:

GPL-2.0-or-later AND GPL-1.0-or-later AND Latex2e-translated-notice AND 
LicenseRef-Fedora-Public-Domain

-- 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: Summary/Minutes from today's FESCo Meeting (2023-07-27)

[Petr Pisar]

V Thu, Jul 27, 2023 at 11:03:46AM -0700, Tom Stellard napsal(a):
> * #3039 RFC: Roadmap for DNF5 in Fedora 39 / invoking the Contingency
>   Mechanism  (tstellar, 17:04:33)
>   * AGREED: APPROVED(+7,0,-0) The switch to DNF5 will be postponed
> (likely to Fedora 41, to be determined by the Change Owners) and
> reverted in Rawhide for the time being (i.e. dnf 4 will provide
> /usr/bin/dnf again).  (tstellar, 17:27:21)
>
It also means reverting dependency adjustments in all reverse dependencies
(i.e. packages which call "dnf" program):

-Requires:   dnf
+Requires:   dnf5

that were summoned by DNF team
.

-- 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: F39 proposal: Perl 5.38 (System-Wide Change proposal)

[Petr Pisar]

V Thu, Jul 20, 2023 at 12:34:30PM -, Xiaojie Chen napsal(a):
> I am interesting in the upgrading of perl.

As a Fedora user, simply upgrade your system to Fedora Rawhide, or to Fedora 39 
when it
it is released.

> Where can I find the detailed process of upgrading and building Perl,
> including the entire build steps,

.


> the list of built RPM packages,

.

> and the building order of Perl module packages?

That's complicated. We use tools from perl-Fedora-Rebuild RPM package. They
compute the order as the packages are being built. Logs and configuration from
the rebuild has jplesnik who performed the rebuild. Try asking her for them.

-- 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: How to correctly use Upstream release monitoring functionality?

[Petr Pisar]

V Tue, Jun 27, 2023 at 08:34:50AM +0200, Petr Pisar napsal(a):
> You can also check an archive of the notification
> <https://apps.fedoraproject.org/datagrepper/raw?category=hotness=2592000>.
> 
There is
<https://apps.fedoraproject.org/datagrepper/raw?category=hotness=cpr=2592000>:

org.fedoraproject.prod.hotness.update.drop the-new-hotness saw an update
for 'cpr', but release-monitoring.org doesn't know what that project is
called in Fedora land JSON

It looks like a mapping from an upstream project to a Fedora package was not
defined at the time when Anitya detected a new version in the upstream.

Though, I don't fully understand the message. I thought that Anitya notifies
distributions only having set the mapping. Either the message is wrongly
worded, or my idea how it works is wrong.

-- 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: How to correctly use Upstream release monitoring functionality?

[Petr Pisar]

V Tue, Jun 27, 2023 at 02:03:36AM -, Felix Wang napsal(a):
> I see the Fedora documentation about Upstream release monitoring. First, add 
> the project to Anitya and map it to the corresponding Fedora package, and 
> secondly, enable the monitoring in its fedora-src repository. I have set 
> these for cpr package, but I didn't receive the related message about its 
> updating status. Could anyone can help me to explain and use this?
> 
> Ref:
> https://docs.fedoraproject.org/en-US/package-maintainers/Upstream_Release_Monitoring/
> https://release-monitoring.org/project/66765/
> https://src.fedoraproject.org/rpms/cpr
> https://bugzilla.redhat.com/buglist.cgi?bug_status=NEW_status=ASSIGNED=Fedora=Fedora=Fedora%20EPEL=cpr

Did you enable the notifications first in Fedora
 and then in Anitya
? I guess if you do it in the
other way, a notification from Anitya is discarded by Fedora because
creating bug reports in Fedora's Bugzilla is disabled at the time of arrival
of the notification.

Otherwise, it's some kind of bug in the notification chain. You can file
i ticket to  or to
 to start an
investigation. You can also check an archive of the notification
.

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

[rpms/perl-WWW-Mechanize] PR #1: Updated Source0 to the URL that works

[Petr Pisar]

ppisar closed without merging a pull-request against the project: 
`perl-WWW-Mechanize` that you
are following.

Closed pull-request:

``
Updated Source0 to the URL that works
``

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

[rpms/perl-WWW-Mechanize] PR #1: Updated Source0 to the URL that works

[Petr Pisar]

ppisar commented on the pull-request: `Updated Source0 to the URL that works` 
that you are following:
``
Thanks for the patch. I've merged it. I will modernize the spec file and built 
it soon.
``

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

[rpms/perl-Devel-CheckLib] PR #3: Requires: redhat-rpm-config for tests

[Petr Pisar]

ppisar commented on the pull-request: `Requires: redhat-rpm-config for tests` 
that you are following:
``
I think the dependency should go to perl-Devel-CheckLib package. 
Devel::Checklib::_findcc() defaults compiler flags to $Config(cflags).
``

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

Re: Modules without MBS

[Petr Pisar]

V Wed, Jun 21, 2023 at 11:52:36AM +0200, Remi Collet napsal(a):
> Le 13/06/2023 à 18:32, Petr Pisar a écrit :
> > Hello,
> > 
> > as it seems that module build infrastructure isn't getting any better, as
> > modular YUM repositories are going to be deconfigured
> > <https://fedoraproject.org/wiki/Changes/No_default_fedora-repos-modular>,
> > there is a time to look at different ways how to package alternative 
> > content.
> 
> Another way/proposal
> 
> Keep "modularity", but drop MBS
> 
> 1/ create a stream package which defines few needed stuff
> 
> mostly
> - %dist => .module+name+stream.distro
> - %modularitylabel
> 
That stream package would have to be registered as an optional member of
@build-srpm group and because the package is specific to a stream, the package
would have to be kept away from nonmodular build tag. Packagers would probaly
tag the stream package into their side tags dedicated for their streams.

> and possibly the .yaml template
> 
To enforce reprodusibility and auditability, Koji to has a rule that all input
is first commited into dist-git and then a Koji task loads it from there and
a packager has no way to influence it. A module-build task in Koji would have
to be changed to implement a logic for handling the YAML templates. With MBS
it was MBS service which implemented the logic and then imported the output as
a module build into Koji.

The same goes for the stream package. I have no idea how MBS builds
module-build-macros in Koji. A task info reads "Src: cli-build/src.rpm".
Probably a privileged operation which does not involve dist-git.

> 2/ modify createrepo
> 
> so all the packages with modularitylabel=name:stream:*
> are be part of name:stream module
> 
Or modify createrepo_c to export the modularitylabel into primary.xml. The
YAML files, if ever needed, would be synthesized by DNF.

My largest problem with this approach is a manual management of the tags on
the modular builds. Koji does not have a way how to be asked for all builds
belonging to a stream. MBS worked around it by using ephemeral tags for
building each stream and then maintaining a registry of these tags and their
builds for a later use (e.g. for updating the stream).

> Done.
> 
> And we have something which works and have been heavily tested
> 
> Yes this is a 1 level only modularity.
>
I worry that even this user-side-only modularity is unwelcome
<https://fedoraproject.org/wiki/Changes/No_default_fedora-repos-modular>.

-- 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: Modules without modularity

[Petr Pisar]

V Tue, Jun 20, 2023 at 03:31:27PM +, Zbigniew Jędrzejewski-Szmek napsal(a):
> On Tue, Jun 13, 2023 at 06:32:45PM +0200, Petr Pisar wrote:
> > I spent some time thinking how to approximate the nice features with current
> > state of RPM, Koji, and DNF and come up with this approach
> > <https://ppisar.fedorapeople.org/postmodular/>.
> 
> Thank you for the detailed proposal that tries to explore all the
> corner cases.  This looks like it should work. It'd be nice to update
> "postgresql demodularization pr" [1] to this scheme to test it on a real
> live package.
> 
> [1] https://src.fedoraproject.org/rpms/postgresql/pull-request/59
> 
I can do it, but:

Current policy requires building Rawhide builds from rawhide branch. (Hence
I assumed that alternative streams will have separarate dist-git
reposirories. Somebody already correctly pointed that dedicated repositories
with obligate reviews would be too bureaucratic.)

My proposal requires metapackages which should have a dedicated component. The
reason is that the metapackage of a default stream needs to be installed in
@build group, i.e. before building the first content package and for building
the content package. (I could cram the metapackage into the same spec file
with postgresql by bootstrapping, but I guess from process point of view
it's uggly.) Also the metapackage needs to be required from fedora-release.

Currently you cannot build my proposal in Koji, because current Koji
configures mock not to pass --allowerasing option to "dnf builddep"
command. And current Mock actually disabled the option for DNF5
<https://github.com/rpm-software-management/mock/pull/1027> because DNF5 did
not support it until very recently.

And finally, I found a misfeature in DNF where "dnf install" intentionally
ignores RPM Provides
<https://github.com/rpm-software-management/dnf5/issues/620>. If DNF
maintainers do not change their mind, my proposal will be buildable after
fixing <https://github.com/rpm-software-management/dnf5/issues/626>, but an
installation with a base, no-stream name won't work. Someone invoking "dnf
install" would always have to use the real package name with a stream
suffix/prefix. (That bug does not affect transitive dependencies.)

And from practical point of view, postgresql is not a good toy package. Most
of the time it fails to build.

-- 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: Modules without modularity

[Petr Pisar]

V Tue, Jun 20, 2023 at 03:47:13PM +, Mattia Verga via devel napsal(a):
> Il 20/06/23 17:31, Zbigniew Jędrzejewski-Szmek ha scritto:
> >
> > [1] https://src.fedoraproject.org/rpms/postgresql/pull-request/59
> >
> > Zbyszek
> 
> Isn't the package name required to match the name of specfile?
> 
It is.

But you can work around it by keeping the main package nonexisten (i.e.
moving all files from "%files" section to "%files -n MY_FUNNY_NAME" section and
removing "%files" section).  Source package would retain main package name,
but there wouldn't be any binary package of that name.

But I'm not sure whether relengs won't protest that they have multiple
source packages with the same name in a sources repository.

-- 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: Test the side-tag: (was: Obsolete of DNF by DNF5 in RAWHIDE)

[Petr Pisar]

V Thu, Jun 15, 2023 at 12:03:39PM +0200, Nicola Sella napsal(a):
> *TL;DR please, test scratch builds in f39-build-side-68994 side-tag.*
> 
> The changes for dnf5 are now ready to be tested before landing in rawhide.
> We made a side-tag with the newest dnf and dnf5, and we would like to get
> some feedback on that. We would like to push the changes to rawhide for the
> next week.
> 
I upgraded dnf5 on my dnf5-only system to the side tag packages without any
problems.
I was able to use your side tag as a boostrap and build repository in mock.
I was able to install python3-dnf alognside dnf5.
Scratchbuilding libmodulemd in Koji with your side tag also passed.

I did not test uprading f39 to your side tag repository.

-- 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: Modules without modularity

[Petr Pisar]

V Thu, Jun 15, 2023 at 01:33:38AM +0200, Kevin Kofler via devel napsal(a):
> Petr Pisar wrote:
> > I spent some time thinking how to approximate the nice features with
> > current state of RPM, Koji, and DNF and come up with this approach
> > <https://ppisar.fedorapeople.org/postmodular/>. The linked approach
> > achieves it at the expense of dedicated build targets and an inability to
> > introduce completely new modules (as opposite to new streams of existing
> > modules) after releasing an installation media.
> 
> So the linked approach emulates Modularity with its main issues (in 
> particular, the risk of dependency version conflicts ("RPM hell") between 
> packages, due to the mutual exclusiveness of the different versions of a 
> "stack") by massive abuse of the Conflicts RPM tag (which is frowned upon 
> for exactly the aforementioned reason) and without an opt-out (because you 
> want to drop these packages into the main repository rather than the 
> optional modular one that is now going to be disabled by default for a good 
> reason). I fail to see the improvement from that proposal.
> 
You got it right. It is to emulate Modularity features without Modularity.

> If you want to build packages with this (selectable mutually exclusive 
> versions) approach, please keep using the normal Modularity

I prefer using the normal Modularity. However, there is a strong pressure to
remove it from Fedora. See
<https://fedoraproject.org/wiki/Changes/No_default_fedora-repos-modular> and
<https://fedoraproject.org/wiki/Changes/RetireModularity>.

> and accept that 
> users now have to explicitly opt in to those modules.

That's exactly what killed the current modularity. Nobody felt a presure to
fix the tooling because Modularity was off by default.

> And in particular, please accept that non-modular packages are not allowed
> to require one of those modules (or in particular, a specific version
> thereof). Attempting to work around those requirements (designed to protect
> users from version conflicts they cannot resolve) is a very bad idea.
> 
I understand the horror that you can have two packages which cannot be
installed at the same time. The same as you cannot start httpd and nginx
services at the same time. But now the conflict is visible on RPM level.

I think it's a matter of the policy. Not of the underlying technology.
Technically you could build and push into repositories a nonmodular package
which depended on modular packeges even in the old Modularity. It were only
people who did not do it and policies which were set against it.

> If you really need a package to depend on a specific version of a library, 
> that library version should be packaged as a parallel-installable 
> compatibility library as per the packaging guidelines.
> 
Of course. My proposal does not forbids it. If users of the
parallel-installable packages are fine with rewriting all their RPM dependcies
and file locations in their applications, then parallel-installable packages
are a perfect solution. It's simply a different problem with a different
solution.

-- 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: Modules without modularity

[Petr Pisar]

V Wed, Jun 14, 2023 at 10:29:31AM +0200, Dan Čermák napsal(a):
> Petr Pisar  writes:
> > The only drawback is one have to decide before GA which software will
> > have an alternative content and create meta-packages for the default
> > streams. Otherwise, users installing from GA media and upgrading later
> > could get installed a nondefault stream.
> 
> Why is that?
> 
My wording was not completely correct. I'm sorry. The problem is what people
mean with "upgrade".

"dnf upgrade" is fine.

"dnf upgrade application" is not fine. "dnf install application" is also not
fine. I will start with explaining simpler "dnf install application":

- A user has installed fedora-release which never heard about stack.
- There is an application in a repository which requires stack.
- The user installs the application and stack is pulled in as a dependency.

Now the same procedure when the first step is before adding stack2 into
the repository, but the installation happens after that:

- A user has installed fedora-release which never heard about stack.
- The distributor adds stack2, an alternative to stack (Provides: stack = 2),
  and updates fedora-release to suggest stream-stack-default.
- The user installs the application. As a result stack2 is pulled in.
  The reason is that stack2 provides "stack = 2" which is higher than
  "stack = 1" provided by stack package.

Now the user end up with the same application but stack2 instead of stack.

A situation with "dnf upgrade application" would be fine if application
depended on stack from the very beginning. But what if the dependency on stack
was added to application in between:

- A user has installed fedora-release which never heard about stack.
- User has installed application. No stack was pulled in because there was no
  need for it.
- The distributor adds stack2, an alternative to stack (Provides: stack = 2),
  and updats fedora-release to suggest stream-stack-default. The distributor
  also updates application to depend on stack.
- The user updates the application. As a result stack2 instead of stack is
  installed. The reason is the same very same as in "dnf install application"
  case -- DNF could choose beetween stack and stack2, so it choose the one
  with a higher version.

Frankly, I would consider automatic selection of the highest alternative to be
a welcome feature, not a bug. At the end, the user only requested application,
so he does not care about a version of stack. If the stack version mattered,
the user should have specified it explicitly. E.g. "dnf install application
stack".

But things then get complicated when users split transactions into multiple
steps. E.g.:

# dnf install stack
# dnf install application

would end with application and stack, but:

# dnf install application
# dnf install stack

would end with application, stack2 and then an error "stack conflicts with
stack2".

DNF operations are not commutative. And people expect to have their
installation procedures reproducible.

You might also ask why would somebody invoke "dnf upgrade application" instead
of "dnf upgrade". Well, some people read security alerts, evaluate a risk, and
then explicitly update selected packages. That's how they end up with
"dnf upgrade application".

-- 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: Modules without modularity

[Petr Pisar]

V Wed, Jun 14, 2023 at 10:19:27AM +0200, Remi Collet napsal(a):
> Your approach will move complexity back to packagers.
> 
Yes. That's because the problem has a complexity and the complexity needs to
live somewhere. With modularity it was in MBS and in modular filtering part of
DNF. If you remove modularity, the complexity has to emerge again somewhere.
With my approach the somwehere is new metapackages, new dependencies, and new
build targets.

> I'm also very concerned by the "vendor" approach
> 
> It seems possible using some stream---
> (or  being  vendor-number, as with module)
> 
I don't understand it. Do you mean that anybody can add his own stream, or
sqaut a namespace? Yes, he can. It was possible even in modularity. Here it is
worse because those identifiers are free-style package names. There are no
separate fields or entities designated for  and  anymore.

> It seems also need to manage dependency with a stack or with a specific
> stream.
> 
> Ex:
> An application will require the default stack (build and run)

If the application ignores nondefault stacks, no action is required. That's
why the proposal is so obsesed with default streams. I think this will be
the most prevaling case. E.g. automake is written in Perl and an automake
maintainer does not care whether it works with alternative Perls or not. He
does not have to. The same attitude was used in modularity.

> An extension of the stack will require the specific stream (build and run)
> 
The extension can add build- and run-time dependenices on packages from that
stream. However, that will effectively make the extension part of the stream.
In that case a maintainer of the extension should including it into the
stream. That, by a the proposed recommendations, would change an RPM name of
the extension. I guess that Fedora would insist on this name change as
Fedora's packaging guidelines now insist on nonmodular packages to only depend
on nonmodular content.

On the other hand, I can imagine that packages (especially top-level
applications) which are not a logical part of any specific stream but depends
on that nondefault stream, will retain its original name and simply users will
have to switch the stream with "--allowerasing". It's the fragmentation of
well-integrated Fedora Christopher (?) wrote in this thread. In his eyes there
is no need for applications like that.


> What about CI ?
> 
CI would have to adapt to switch the streams. As in case of modularity. As far
as I know Fedora does not supports modules in CI. But the switching can happen
as an implicit part of CI environment installation. If CI populated the
enviromemnt with "dnf --root=... install 
, then DNF would pick the fitting streams automatically.
Or if there were no solution, DNF would report a dependency resolution error.

> An application will be build will one stream (default)
> but we probably need to test it with all available streams.
>
That would be difficult to automate. Packagers could configure CI to repeat
tests for listed streams. Modularity was better for automation because streams
were a formal entity which could be queried and set. In the my approach there
is no such capability because simply there is no modular entity. That's
definitely a regression.

Howver, in reality the automation even in RHEL was not so hot. As far as
I know a list of stream combinations to test was always defined statically.

> And perhaps have to use (because not compatible with 3)
> Requires: (stream-stack-default or stream-stack-2)
> 
Rich dependencices are one option. Another option is to leverage ordering.
Because the packages from streams provide the same base name with different
versions:

php74
  Provides: php = 7.4
php80
  Provides: php = 8.0
php82
  Provides: php = 8.2

then you can write "Requires: php >= 8.0" to exclude php-7.4.

Now I'm not sure whether versioning stream-stack from your question wouldn't
break default streams. I forgot whether DNF prefers a package with highest
provider or a package with highest version and whether the versioning is
stronger than weak dependencies or not.

> What about reviews ?
> 
> If I want to create  stream-stack-3, with 100 packages ?
> 
> For now, there is a review exception for compatibility packages
> for "older" version, but not for newer version.
>
Good catch. Fedora would have to change rules to recognize that stack3 is an
upgrade of stack2. Or those could live in stream branches of dist-git where
they hide in repository under the base name.

Frankly I haven't yet thought on these policies Fedora asserts. So far
I thinking on feasibily from DNF and Koji point of view.

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

Re: Modules without modularity

[Petr Pisar]

V Tue, Jun 13, 2023 at 03:20:06PM -0400, Christopher napsal(a):
> (First the negative... don't worry, it's not all negative)
> I wonder why we need this at all. I believe that modularity has failed
> to gain a foothold in Fedora, just like scl before it, because Fedora
> just doesn't need this. One of the best things about Fedora is the
> dependency-convergence and curated nature of all the packaged
> versions, so that everything works out of the box. The use cases for
> alternative versions are edge cases that the vast majority of users do
> not need or care about. And the ones that most users do care about
> (making sure their application works) are usually satisfied with
> compat packaging, when needed.
> 
> So much (over-?)engineering has gone into such niche use cases, and
> Fedora is arguably no better off for all that effort. Nowadays, it's
> so easy to spin up a VM or container using older versions of things,
> if you need them, or you can use snaps or flatpaks, or
> language-specific version management tools like mvn or rvm, for the
> developer use cases. What is the real benefit to Fedora to continue to
> push down the path of alternative, mutually-exclusive streams that
> affect the entire system? My experience struggling with modularity as
> a casual packager, and as a user, has left a bad taste in my mouth for
> any similar attempts, and I'm highly skeptical of the need of such a
> thing (and bracing for the impact when it all comes crashing down on
> my favorite OS due to unintended consequences).
> 
I agree that for Fedora it's a niche problem and any attempt to introduce
alternative versions never flew long there.

My explanation for it is that what Fedora offers and what Fedora users want is
a self-inforced relation. If Fedora choose a short release cycle with
single-version, well-integrated code base, then naturally any attempt to bring
alternative versions which partion the code is frown. There are different
distributions with a different life cycle, e.g. rolling release, that
incorporates incompatible versions as an inevitable phenomenon. Those
distributions of course have a different vision and different user as well as
packager base. This is not a critique of Fedora. It only illustrates that
different distributions have different priorities.

You can take my proposal as a mental exercise to explore what is possible and
what isn't with the current state of packaging in Fedora. I'm not going to
hide that the proposal more targets to long-lifecycle derivates of Fedora and
I wanted to get a broader audience, especially from Fedora as an upstream.

> (Now the positive)
> That said, I like the simplicity of your approach, using metapackages
> and native RPM tooling to handle the situation. However niche the use
> case is, having such a simple approach means that it's merely a matter
> of documenting some guidelines for packagers to follow if they have
> need of that situation. I still think that the need for that will be
> rare, and wonder how many of these kinds of metapackages would
> actually get created in Fedora. I suspect that it would be very few.
> But the important bit is that if they do get created, they are
> unlikely to affect me unless I want to use them. This is very
> different from modularity, which seemed to have a downstream impact on
> everybody, especially when you were forced to use modularity if your
> dependencies were... which I think was enough to oust a lot of casual
> packagers, because they had to understand a whole new dimension of
> packaging guidelines and tooling. Your approach requires none of that.
> 
> The one downside to your approach, that I think was an early selling
> point of modularity, is that yours kind of requires that the
> alternative streams are built for every Fedora version. I think
> modularity marketed itself as being able to have a module whose
> version lifetimes were longer than OS release cycles (which could
> reduce packager workload for streams that were slow-moving and didn't
> change across Fedora releases). I don't know how much that actually
> happened in practice, though, so I don't know if anybody will care
> about that difference in your approach.

Thanks for the review.

Modularity indeed helped to maintain a single source across all Fedora
releases. However, behind the scene it spawned separate builds and updates for
each Fedora release. (That's something that current JDK proposal tackles
.) Very
contrary, one had to rebuild a module for each new release. Otherwise, the
module disapeared from Rawhide.

My proposal does not bring this feature. I think packagers can leverage
packages.cfg file in dist-git repositories to configure multiple builds with
a single "fedpkg build" command (as it was used in EPEL8 for EPEL8-next
builds).

-- Petr


signature.asc
Description: PGP signature
___
devel mailing list -- 

Re: Modules without modularity

[Petr Pisar]

V Tue, Jun 13, 2023 at 01:06:33PM -0700, Brad Smith napsal(a):
> Is this thread on alternatives to alternatives also relevant:
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/thread/4AUQVBKLQBU6LIWZGVXN2CM3XTYQAKXZ/#4AUQVBKLQBU6LIWZGVXN2CM3XTYQAKXZ
> ?
>
It's relevant in the meaning that it enables to choose an implementation from
multiple alternatives after building the packages, the choice is made on an
end system.

However, all the aproaches discussed in the thread only deal with execve(2), or
even only with execvpe(3). Anything what happens before is out of their scope.

My proposal, as well as modularity, has a larger goal. And that is make the
altarnatives look-alike also on RPM level.

> Modules provide a mechanism for system level switches between
> alternative versions as does Petr's  proposal (i.e. sudo required). As
> others have remarked, there is also a need for a similar capability at
> the user level (without sudo; e.g. environment modules) or even at the
> shell level.
> 
Yes. Different people require different distance of control. That's the reason
why all of them exist and have their users.

> It would be nice if there were a compendium of all similar options for Fedora.
>
If the compendium means a documentation, then I doubt a Fedora specific,
comprehensive documenation would be meaningful. It's like documenting various
web browsers a user could use. Moreover, I feel the Packaging Guidelines
 do
not want a comprehensive list of options there. They rather document the best
approach.

If the compendium means that all the frameworks should be packaged in Fedora,
I would let it on organic growth. If somebody needs one, he can package and
maintain it.

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