Package Maintainer Docs: Pull Request Guide

[Otto Liljalaakso]

Hello,

Pull requests are an important aspect of how Fedora packaging works, 
and, crucially, the easiest way for new contributors to get started. 
Unfortunately, there has been almost no documentation available about 
that topic. To remedy that situation, I submitted a pull request to 
Package Maintainer Docs [1]. Please take a look and give feedback, 
either in the pull request or here on devel.


[1]: https://pagure.io/fedora-docs/package-maintainer-docs/pull-request/156--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
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: Maintaining erlang-xmpp

[Otto Liljalaakso]

Greetings,

If I read the history correctly, your pull request went without reply, then 
automation or mass operation retired erlang-xmpp because it failed to install. 
So obviously the maintainer had left the package without care.

Retiring the package was of course not efficient, I would have been much better 
to hand the package over to you and let you fix it.

Hopefully, we can recover and give the package to you. The right thing to do 
now is to submit a package review request to unretire erlang-xmpp. These links 
explain how to do it:







I am not a packager sponsor myself, so I cannot sponsor you. However, I suggest 
you do push the fixes for all the packages you need to fix eventually. The more 
links you have to demonstrate you understand Fedora packaging, the easier it 
will be to find a sponsor. I understand it is not very motivating to have your 
first pull request ignored. Please be patient, that was not because of you or 
the pull request content. Most probably the single person who had been taking 
care of the package, including processing pull requests, had left.

Asking for sponsors on the list is a valid way to do that. So are tagging 
FE-NEEDSPONSOR in a review request and filing a sponsorship ticket at:



12. toukokuuta 2024 13.43.56 GMT+03:00 rh hn  
kirjoitti:
>Greetings,
>
>packages related to ejabberd have started falling out from Fedora around 
>version 36. That didn't stop me from using ejabberd, so every Fedora release 
>I'm repackaging them. I think it's silly not to share the result of that work 
>with the rest of Fedora.
>
>I'm not a Fedora packager, so I'm following the guides and putting forward my 
>offer to maintain those packages, starting with erlang-xmpp:
>
>https://src.fedoraproject.org/rpms/erlang-xmpp/pull-request/2
>
>(this depends on erlang-stringprep, the fix to which I have not bothered to 
>push anywhere, based on the interest to the above).
>
>I guess I need the packager status to do anything, so can I have the packager 
>status plz? I'm not sure whether the guide says that here is where I can find 
>a sponsor, or whether I should looke elsewhere... but anyway thanks for 
>reading my offer.
>--
>___
>devel mailing list -- devel@lists.fedoraproject.org
>To unsubscribe send an email to devel-le...@lists.fedoraproject.org
>Fedora Code of Conduct: 
>https://docs.fedoraproject.org/en-US/project/code-of-conduct/
>List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
>List Archives: 
>https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
>Do not reply to spam, report it: 
>https://pagure.io/fedora-infrastructure/new_issue
--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Simpler first tutorial package for Package Maintainer Docs

[Otto Liljalaakso]

Kenneth Goldman kirjoitti 3.5.2024 klo 23.07:

A review from a complete newbie ...

1. The link points to a pull request.  Where is the actual tutorial?


At the time you and I originally wrote, nowhere. The docs development 
workflow is to update the documentation source Git using the usual 
workflow with pull requests and so, then automation periodically (once a 
day I think?) generating the actual docs.fedoraproject.org site.


It would be great to have automation that generates a temporary site for 
each pull request, and it would be even more great if it would also 
highlight changed/added/removed parts in the resulting site. But at the 
moment, we do not have anything like that. So if reading Pagure's texual 
diff does not work (which, for large changes, it often does not), then 
you need to fetch the pull request's branch and generate the site 
locally. Repo's README tells you how to that.


But in this case, by coincidence, I just merged the pull request, so now 
you can read the actual tutorial live [2]. Feedback is still welcome, if 
you have any!


[2]: 
https://docs.fedoraproject.org/en-US/package-maintainers/Packaging_Tutorial_1_banner/ 




2. The page refers to Pagure, Antora, ... I wonder if they're necessary for
packaging.


I am not sure what you are referring to with "the page". The pull 
request page?


Antora is the site generator used for Fedora Docs, and Package 
Maintainer Docs sources are hosted on pagure.io, so both of those are 
very much necessary for docs writing. If Pagure or Antora arenecessary 
for packaging? The answers are "yes" and "no". But the tutorial itself 
does not even mention either.



As a newbie, I would like an example that looks like:

1. Push the main branch to github.
2. Do these steps.
n. Push the result to Fedora.


I agree. For now, the tutorial only covers specfile writing and test 
builds, but does not have anything about interaction with upstream, 
pushing to dist-git or official Fedora builds. Extending the tutorial to 
also cover those topics (in part 3 and beyond) would not be very 
difficult. The main issue is that we would need a dummy upstream project 
solely for this purpose, and some people to play the part of upstream 
developers, to merge pull requests from people following the tutorial. 
There was a thread about this kind of tutorial in devel some years ago 
also, but unfortunately I cannot seem to find it now.
--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Simpler first tutorial package for Package Maintainer Docs

[Otto Liljalaakso]

Hello everybody,

I wrote a pull request for Package Maintainer Docs about adding a 
simpler tutorial package than GNU Hello [1]. Since it is a larger change 
and I have not received any reviews yet, I would like to announce this 
work here, in hope of getting some feedback, before just merging the 
change. Since I have already described the work in the pull request 
description, I will just copy it here below. Feel free to respond on the 
list or in pull request comments.


[1]: https://pagure.io/fedora-docs/package-maintainer-docs/pull-request/153

> Add simpler Banner package to packaging tutorial
>
> Packaging tutorial's approach of packaging GNU Hello has suffered from
> certain complexities in GNU Hello package. The package is quite old and
> uses some tooling from the GNU project that are not very widely used
> any more, such as Texinfo. Also, the package is old and thus suffers
> from e.g. having a file that is not UTF-8 encoded. To avoid immediately
> exposing tutorial readers to these quirks, make GNU Hello part 2 of the
> tutorial and add a simpler package, Banner, as part 1. This way the
> reader can reach a complete specfile, compliant with Fedora guidelines,
> quicker, and still get a feeling for resolving packaging quirks in the
> second part.
>
> In the future, basing the first tutorial on real packages should
> probably be switched to hosting dedicated "test project", which avoid
> any quirks and can be packaged to Fedora requirements using only
> Fedora's set of RPM macros. Such package should also avoid GNU
> Autotools and be based on CMake or Meson, which are simpler to
> understand and more widespread today.
--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Obsoleted packages in F40

[Otto Liljalaakso]

Kevin Kofler via devel kirjoitti 31.3.2024 klo 14.14:

Otto Liljalaakso wrote:

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

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

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

Re: Obsoleted packages in F40

[Otto Liljalaakso]

Otto Liljalaakso kirjoitti 30.3.2024 klo 13.41:

Kevin Kofler via devel kirjoitti 25.3.2024 klo 20.34:

Miroslav Suchý wrote:

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


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


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


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


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

Re: Obsoleted packages in F40

[Otto Liljalaakso]

Kevin Kofler via devel kirjoitti 25.3.2024 klo 20.34:

Miroslav Suchý wrote:

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

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


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


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



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


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


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

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

Re: [SPDX] Mass license change: Intro and change of "Bitstream Vera" to "Bitstream-Vera"

[Otto Liljalaakso]

27. maaliskuuta 2024 12.59.11 GMT+02:00 Petr Pisar  
kirjoitti:
>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

I also think the conversion should only be done if the full License string can 
be converted. Partial conversion is confusing, and there is not much value, 
since trivial conversion is, well, trivial, and whoever will eventually need to 
take a look at the nontrivial parts can easily handle it then.
--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Retiring Celestia from Fedora due to licensing issues

[Otto Liljalaakso]

I do not have the answers to your questions, but when figure out how to 
properly do this, please submit an update for the docs. That section has always 
looked very suspect to me.

20. maaliskuuta 2024 18.36.02 GMT+02:00 Mattia Verga via devel 
 kirjoitti:
>After I requested [1] Celestia project upstream to better define 
>licensing of all the textures and 3d models included in upstream data, 
>it turned out that at least some content is licensed CC-BY-NC-SA-3.0 [2] 
>which is not permitted in Fedora.
>
>Upstream is still working on specify exactly the licenses of each file 
>and, maybe, in future will replace the problematic content with FOSS 
>textures. However, since there's no ETA for those tasks and the main 
>program cannot work by simply stripping out the problematic content, I 
>am forced to retire Celestia from Fedora.
>
>I will be following the procedure for completely removing a package [3], 
>however there are a couple of things that I'd like to ask:
>
>- should I wait for the flatpak maintainer to retire the flatpaks 
>(celestia-gtk and celestia-qt) before retiring the RPMs (celestia and 
>celestia-content)?
>- do I need to ask releng to purge celestia sources from the lookaside 
>cache as well?
>-do the flatpaks need to be added to fedora-obsolete-packages (or 
>something similar for flatpaks)?
>
>Thanks
>Mattia
>
>[1] https://github.com/CelestiaProject/CelestiaContent/issues/138
>[2] https://github.com/CelestiaProject/CelestiaContent/issues/147
>[3] 
>https://docs.fedoraproject.org/en-US/package-maintainers/Package_Retirement_Process/#complete_removal
>
>--
>___
>devel mailing list -- devel@lists.fedoraproject.org
>To unsubscribe send an email to devel-le...@lists.fedoraproject.org
>Fedora Code of Conduct: 
>https://docs.fedoraproject.org/en-US/project/code-of-conduct/
>List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
>List Archives: 
>https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
>Do not reply to spam, report it: 
>https://pagure.io/fedora-infrastructure/new_issue
--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: koji news and 1.34.0 upgrade

[Otto Liljalaakso]

Kevin Fenzi kirjoitti 22.2.2024 klo 1.43:

Greetings. After the outage that just completed, koji has been upgraded
to 1.34.0 plus a few patches from upstream. Some highlights:

* A patch has been added allowing us to set 'noarch_arches' on build
tags. This allows us to specify what arch builders will do noarch
builds. Without any setting it's any arch, but this presents problems
for noarch packages that have some dependencies that have dropped i686.
For f41 / rawhide, this has been set to "aarch64 x86_64 ppc64le s390x"
(ie, excluding i686). If this works well we can extend it to other build
tags.
What does this mean in practice for packagers? Can I now stop adding 
`ExcludeArch: %{ix86}` to noarch packages in Rawhide, or should I still 
keep doing that until we know "if this works well"?

--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
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: Donate 1 minute of your time to test upgrades from F39 to F40

[Otto Liljalaakso]

Miroslav Suchý kirjoitti 21.2.2024 klo 9.11:

dnf --releasever=40 --setopt=module_platform_id=platform:f40 \

--enablerepo=updates-testing \
$(rpm -q fedora-repos-modular >/dev/null && echo 
--enablerepo=updates-testing-modular) \

--assumeno distro-sync

In addition to some problems that already have Bugzilla entries or such, 
and were already reported in this thread too, I got some problems with 
retired Rubygems:


|$ LANG=C.UTF-8 sudo dnf --releasever=40 --enablerepo=updates-testing 
--assumeno distro-sync Problem 3: package 
rubygem-byebug-11.1.3-5.fc39.x86_64 from @System requires 
libruby.so.3.2()(64bit), but none of the providers can be installed - 
ruby-libs-3.2.2-181.fc39.x86_64 from @System does not belong to a 
distupgrade repository - problem with installed package 
rubygem-byebug-11.1.3-5.fc39.x86_64 Problem 4: package 
rubygem-shoulda-3.6.0-14.fc39.noarch from @System requires 
(rubygem(shoulda-context) >= 1.0 with rubygem(shoulda-context) < 2 with 
rubygem(shoulda-context) >= 1.0.1), but none of the providers can be 
installed - rubygem-shoulda-context-1.2.2-16.fc39.noarch from @System 
does not belong to a distupgrade repository - problem with installed 
package rubygem-shoulda-3.6.0-14.fc39.noarch Problem 6: cannot install 
both ruby-libs-3.3.0-4.fc40.x86_64 from fedora and 
ruby-libs-3.2.2-181.fc39.x86_64 from @System - package 
ruby-3.3.0-4.fc40.x86_64 from fedora requires ruby-libs(x86-64) = 
3.3.0-4.fc40, but none of the providers can be installed - package 
ruby-3.3.0-4.fc40.x86_64 from fedora requires libruby.so.3.3()(64bit), 
but none of the providers can be installed - package 
rubygem-byebug-11.1.3-5.fc39.x86_64 from @System requires 
libruby.so.3.2()(64bit), but none of the providers can be installed - 
problem with installed package ruby-3.2.2-181.fc39.x86_64 - package 
rubygem-pry-byebug-3.6.0-13.fc39.noarch from @System requires 
(rubygem(byebug) >= 11.0 with rubygem(byebug) < 12), but none of the 
providers can be installed - ruby-3.2.2-181.fc39.x86_64 from @System 
does not belong to a distupgrade repository - problem with installed 
package rubygem-pry-byebug-3.6.0-13.fc39.noarch |


||

I filed a PR for fedora-obsolete-packages for these [1].

[1]: 
https://src.fedoraproject.org/rpms/fedora-obsolete-packages/pull-request/86


|
|
--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
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: Donate 1 minute of your time to test upgrades from F39 to F40

[Otto Liljalaakso]

Dominique Martinet kirjoitti 21.2.2024 klo 15.13:

Miroslav Suchý wrote on Wed, Feb 21, 2024 at 08:11:49AM +0100:

dnf --releasever=40 --setopt=module_platform_id=platform:f40 \
--enablerepo=updates-testing \
$(rpm -q fedora-repos-modular >/dev/null && echo 
--enablerepo=updates-testing-modular) \
--assumeno distro-sync

Error:
  Problem 6: package network-scripts-teamd-1.32-4.fc40.x86_64 from fedora 
requires network-scripts, but none of the providers can be installed
   - problem with installed package network-scripts-teamd-1.32-1.fc39.x86_64
   - package network-scripts-10.20-1.fc39.x86_64 from @System requires 
initscripts(x86-64) = 10.20-1.fc39, but none of the providers can be installed
   - network-scripts-teamd-1.32-1.fc39.x86_64 from @System  does not belong to 
a distupgrade repository
   - initscripts-10.20-1.fc39.x86_64 from @System  does not belong to a 
distupgrade repository


I got this one as well. This happens because network-scripts sub-package 
was just recently dropped from initscripts [1,2]. It looks like it was 
improperly dropped, because the existing dependents were not handled.


I am not sure if I should comment in already closed bug about dropping 
network-scripts, or open a new one (against which component?). I'll cc 
initscripts maintainers here. Could you check network-scripts-teamd and 
possible other remaining dependents of network-scripts and handle them, 
by arranging them to be retired and obsoleted or whatever is appropriate 
in each case?


[1]: https://bugzilla.redhat.com/show_bug.cgi?id=2262795
[2]: 
https://src.fedoraproject.org/rpms/initscripts/c/414789841de9247310ebfd37cd043b75963f7cac?branch=rawhide

--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
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: https://pagure.io/fesco/issue/3082 - proposal to increase aarch64 netinst image size limit to 1G

[Otto Liljalaakso]

Adam Williamson kirjoitti 14.10.2023 klo 21.28:

Hey folks! I mentioned this in the blocker status summary email I just
sent, but figured it also deserved its own thread just to make sure
folks are aware of it. I've sent a ticket to FESCo:

https://pagure.io/fesco/issue/3082

proposing we bump the max size of the aarch64 Server netinst image
(which is release-blocking) from 700M to 1G. A detailed justification
is in the ticket. If you have passionate opinions on this, please read
the ticket and comment. Thanks :)


The discussion seems to happen in the FESCo ticket, but I will comment 
here anyway as I have heard that is the correct way.


I am not really involved with Fedora Server, but anyhow, if Adam and 
others are spending a lot of time to shrink installation images and the 
effect is measured in megabytes or less, I think that time is not well 
spent. Better increase the image size limit and let people concentrate 
on more important items.

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
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: Error when patching test-requirements inside pymemcache source

[Otto Liljalaakso]

15. lokakuuta 2023 1.47.49 GMT+03:00 Priscila Gutierres  
kirjoitti:
>Hello,
>
>I'm trying to patch pymemcache/test-requirements.txt to unpin all the build
>requirements.
>
>I created this patch using git format-patch:
>https://paste.centos.org/view/46800819
>But when trying to create a mockbuild, it fails to apply:
>https://paste.centos.org/view/b1f404c8
>
>Checking patch pymemcache/test-requirements.txt...
>error: pymemcache/test-requirements.txt: does not exist in index
>
>But it exists: https://paste.centos.org/view/a239ec34
>
>What am I missing?
>
>Priscila.

Do you have the new patch listed as Patch: in the specfile? It will not be 
picked up otherwise.

It will help troubleshooting if you can upload your work-in-progress somewhere.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
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 running centpkg

[Otto Liljalaakso]

Stephen Smoogen kirjoitti 7.10.2023 klo 18.30:


On Sat, 7 Oct 2023 at 10:50, stan via devel 
 wrote:


On Fri, 06 Oct 2023 16:05:25 -
"Michael Dawson"  wrote:

> I'm trying to build
> https://gitlab.com/redhat/centos-stream/rpms/nodejs using
centpkg but
> am running into errors.
>
> I'm using Fedora 37 and get this error when I run centpkg mockbuild
> --with=bundled in the directory where I've cloned the
> https://gitlab.com/redhat/centos-stream/rpms/nodejs respository and
> switched to the stream-nodejs-18-rhel-8.10.0 branch.
>
> I'm getting this error:
>
> Total
>                                                    3.7 MB/s |  50 MB
>    00:13 Running transaction check Transaction check succeeded.
> Running transaction test
> Error: Transaction test error:
>   file /usr/sbin/alternatives from install of
> chkconfig-1.19.2-1.el8.x86_64 conflicts with file from package
> alternatives-1.24-1.fc38.x86_64
                      


Good catch. You should not mix and match el and fedora packages or 
repositories like that.


Michael if you are using Fedora 37 as you say lower down, you have 3 
different releases trying to put packages on the system:
EL8, Fedora 37 and Fedora 38. You can possibly match Fedora 37 and 
Fedora 38, but EL8 is like bringing in EL29 packages into the mix.. 
years of changing file locations and such.


Actually, Michael says he is using `centpkg mockbuild` here, so my 
expectation is that Mock bootstraps an appropriate chroot and performs 
the build there. The base system's Fedora version (37 here) should not 
matter, apart from providing a working version of `centpkg` and Mock. 
Because the bootstrapping fails, to me this sounds like a bug in either 
Mock or `centpkg` configuration. Unfortunately, I do not package for 
CentOS Stream, so I do not have a guess what it could be exactly. I 
agree that seeing Fedora 38 mixed in there seems strange.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

[EPEL-devel] Retiring Zim

[Otto Liljalaakso]

I am retiring Zim from EPEL. As specified by the retirement policy [0], 
I sent notification to epel-devel already two months ago [1]. To 
continue using Zim, probably the best way is to use the flatpak from 
Flathub [2].


[0]: 
https://docs.fedoraproject.org/en-US/epel/epel-policy-retirement/#process_no_time_or_desire
[1]: 
https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject.org/message/UB7FZZEEO5HX6HU7SNQH5TX3HDCIW5ID/

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

Re: Orphaned Zim

[Otto Liljalaakso]

Sandro kirjoitti 20.7.2023 klo 12.42:

On 19-07-2023 23:11, Otto Liljalaakso wrote:

Robin Lee kirjoitti 14.7.2023 klo 17.53:
I've orphaned the Zim package. It fails to build with Python 3.12 in 
Rawhide.


Users can move to the flatpak on Flathub, which is also packaged by me.

Thank you for maintaining the Zim package until now. I took it. The 
build failure was easy to fix by BuildRequiring setuptools. I also 
updated to the latest version, and am in the process of looking at 
open bugs and switching to SPDX license identifiers.


I think I may have used Zim in the past and I may have some use for it 
again. I'd be happy to co-maintain. 


Great! I have added you with commit privileges. In case you (or anybody 
else) know Python buildsystems, you could check the upstream issue about 
distutils deprecation [1]. Upstream has just indicated they are 
interested in migrating to something else, but would appreciate some 
suggestions and help.


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

[EPEL-devel] Retiring Zim from EPEL

[Otto Liljalaakso]

Recently, I adopted the orphaned Zim package for Fedora. The previous 
maintainer had added the package to EPEL, while I am not involved with 
EPEL at all. Consequently, I will not maintain the EPEL branches anymore.


From going through the EPEC documentation, it looks like the Retirement 
Process: No Time or Desire [1] is the procedure I should follow. So, 
unless somebody steps up to maintain the EPEL branches for Zim, I will 
retire the package from EPEL.


To my knowledge, there are no issues with Zim and EPEL. I am simply not 
involved with EPEL. The fact that there is no epel9 branch, only epel8 
and epel7, seems strange, but then, I do not know much about EPEL 
package maintenance.


In case I am following the wrong process, please let me know and point 
me to the correct one.


[1]: 
https://docs.fedoraproject.org/en-US/epel/epel-policy-retirement/#process_no_time_or_desire

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

Re: Orphaned Zim

[Otto Liljalaakso]

Robin Lee kirjoitti 14.7.2023 klo 17.53:

I've orphaned the Zim package. It fails to build with Python 3.12 in Rawhide.

Users can move to the flatpak on Flathub, which is also packaged by me.

Thank you for maintaining the Zim package until now. I took it. The 
build failure was easy to fix by BuildRequiring setuptools. I also 
updated to the latest version, and am in the process of looking at open 
bugs and switching to SPDX license identifiers.

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
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: Increase vm.max_map_count value (System-Wide Change proposal)

[Otto Liljalaakso]

Peter Boy kirjoitti 25.4.2023 klo 1.29:

The increase step looks very massive. And I wonder why we should make such a 
change to make games of all things work out of the box. Are games the main use 
case of Fedora?


I do not think there is *the* main use case for Fedora. But certainly, 
games are *a* use case that many users do care about, including me. 
Making them work better is important.



Wouldn't it make more sense to create a game spin instead? After all, we 
already have a Lab. Or make a corresponding change in this context.


Games should work well on Fedora Workstation. Playing games is even a 
use case listed in the Fedora Workstation PRD [1].


[1]: https://docs.fedoraproject.org/en-US/workstation-working-group/prd/

Otherwise, I have no expertise to comment on the proposed change. 
Luckily, we already have some knowledgeable replies from those others.

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
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: The new version of Fedora Messaging Notifications will arrive this week

[Otto Liljalaakso]

Aurelien Bompard kirjoitti 24.4.2023 klo 16.04:

Hi folks!

The "FMN replacement" team has finished writing the new version of our
notification system, and we are ready to deploy!



You will thus still be able to access the current FMN, and it will
keep running until F39. Due to the difference in features, we can't
import existing rules into the new system, so we encourage you to
create new rules that suit you as soon as the new system is up and
running.



We hope you will enjoy the simpler UI and faster processing speed that
the new FMN brings.


Thank you for working on this. I am not exactly sure how this will 
affect things, but my hopes are high that I can be better notifications now.


My current situation is not ideal. I *think* I currently get the following:

1. Bugzilla's own notifications (probably configurable there, but the 
defaults are ok and I have trouble with the Bugzilla UI, so I have not 
bothered to check)

2. Pagure.io's own notifications (nicely configurable there)
3. src.fedoraproject.org's own notifications (nicely configurable there)
4. Bodhi's notifications (not sure if they are sent by Bodhi or some 
middleman, I wouldn't know how to adjust these even if I wanted to)

5. Fedora Discussion's own notifications (nicely configurable there)
6. Random junk that either duplicates the above or I cannot make any 
sense of (I presume this comes from the old thing that is now being 
replaced, but other than that, I have no idea how I could configure this)
7. Sometimes there is a notification that looks similar to the junk from 
6 but actually has interesting information, like that I received a 
Fedora Badge (the fear of losing these diminishes my willingness to try 
out random things to avoid 6)


First, I would like to keep 1 — 5 and get rid of 6. Retaining 7 would be 
nice but not critical. But I am so confused regarding the notifications 
that I am not sure how to achieve that. Is there some kind of guide 
available on how to set up Fedora notifications in general, so I could 
try to clean up things for myself?

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

Re: Auto-assign packager sponsors to tickets?

[Otto Liljalaakso]

Jakub Kadlcik kirjoitti 17.4.2023 klo 18.53:

I want to thank you all for the feedback.

Everything was already mentioned in the discussion so I am not going
to dig into details again. Just a quick summary for anyone who wants
TL;DR for this thread:

- I am not going to implement the original proposal or any variation of it
- Instead, I am going to automatically open an issue in the
package-sponsors tracker for new contributors after they receive
fedora-review+ on their first ticket. A link to this issue along with
some explanation will be automatically commented to their package
review Bugzilla ticket.
- You can follow the progress here
https://github.com/FrostyX/fedora-review-service/issues/18


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

Re: Auto-assign packager sponsors to tickets?

[Otto Liljalaakso]

Benson Muite kirjoitti 4.4.2023 klo 10.43:

Response times to pull requests can vary.  Most people who want to be
packagers are submitting something new.  The above would work well for
SIGS which package related software.  In particular, if a package can be
adopted by a SIG, then the person submitting it need not be sponsored to
have the package in Fedora, as the SIG can adopt the package, and the
person submitting it make pull requests to make changes.


I am wondering that this notion that most of the time, new packagers 
want to submit a new package. Is that just a feeling or do we have some 
way to get actual data?


And how do we control for the fact that even currently, and even more in 
the past, the documentation for the process is assuming that to be the 
typical case. I assume that creates a bias by attracting potential 
contributors who have a new package, and repelling others who have 
something else in mind.

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

Re: Auto-assign packager sponsors to tickets?

[Otto Liljalaakso]

Kalev Lember kirjoitti 4.4.2023 klo 10.36:

On Tue, Apr 4, 2023 at 9:22 AM Vitaly Zaitsev via devel <
devel@lists.fedoraproject.org> wrote:


On 04/04/2023 07:52, Otto Liljalaakso wrote:

Perhaps new package requests could more often be handled in a way where
an existing packager assumes the maintainer position with the agreement
that the submitter keeps the packager updated and in good condition,
through pull requests.


We have a serious problem here: non-packages can't upload sources to
Fedora SCM.

These pull requests require maintainers to do it manually in a separate
commit that breaks %autorelease+%autochangelog.



That's not exactly true. Yes, non-packagers can't upload files to the
lookaside cache, but they can update the 'sources' and '.gitignore' files
in git.

The easiest way to do that is with 'fedpkg new-sources --offline' which
then only does the local modifications that can be committed to git (and
submitted as a PR), but doesn't upload the files to the lookaside cache
servers.


Yes, we have both problems that make working with pull requests clumsy, 
and slow progress like 'fedpkg sources --offline' that is making things 
easier.


In any case, I did not mean that we could just go all-in with pull 
requests now. I mean that we should try to improve things so that using 
them becomes more and more convenient and effective.

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

Re: Auto-assign packager sponsors to tickets?

[Otto Liljalaakso]

Benson Muite kirjoitti 4.4.2023 klo 7.02:

May
also want to automatically track unofficial reviews by prospective
packagers, perhaps even requiring a certain number of unofficial reviews
for the sponsorship process to start.


Yes, I think that the sponsorship process should be made more rigid, 
with at least somewhat formally defined requirements. Maybe something 
along the lines "do N unofficial package reviews AND submit M pull 
requests to packages and get them merged AND convince a sponsor". The 
current approach where "convince a sponsor" is the only actual 
requirement creates unfortunate bias:


1. The easiest way to get in is to know somebody who is already in. This 
is basically the opposite of how I understand "open community".


2. Applicants who find it easy to engage with unknown people in higher 
community standing and have high confidence in their abilities navigate 
the (ill-defined, unclear) process much easier than more cautious types. 
Such character traits are of course very useful when participating in 
open source communities, but discriminating other kinds of personality 
leads to fewer contributors and lost talent. And it is, well, 
discriminatory, thus not very ethical in my opinion.


Another thing that can be improved here is to make it much less 
necessary to even get packager status. Working with pull requests should 
be the norm. Perhaps new package requests could more often be handled in 
a way where an existing packager assumes the maintainer position with 
the agreement that the submitter keeps the packager updated and in good 
condition, through pull requests. The packager status should be just an 
optional thing you can apply at some point in your Fedora contributor 
career, *if* a situation demanding that occurs - much like packager 
sponsor, provenpackager or even FESCo member status is, or how in 
upstream projects there often are prominent contributors that take part 
in the conversation and submit pull requests, without any commit access.

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

Re: Auto-assign packager sponsors to tickets?

[Otto Liljalaakso]

Benson Muite kirjoitti 4.4.2023 klo 7.02:

Thanks for this initiative Jakub. Automated builds on copr of packages
proposed for review has been very helpful.


I completely agree. Great work!

Benson Muite kirjoitti 4.4.2023 klo 7.02:

On 4/4/23 03:59, Jakub Kadlcik wrote:



 From this thread I get
the opposite impression, that Pagure tickets are processed quickly and
FE-NEEDSPONSOR blockers are not looked at. If so, I propose the policy
is updated to ask for a Pagure ticket in every case.


I get the same impression and I would agree with Otto's proposal to
get rid of the FE-NEEDSPONSOR entirely. Apart from it not being
processed as effectively as the package-sponsor repo tickets, the
FE-NEEDSPONSOR is confusing anyway (it is set to a review ticket but
the ticket doesn't need to be sponsored, the contributor does. That
becomes weird when the contributor has more tickets at the same time
and so on). But if I understand correctly, FESCo needs to be involved
and therefore this would be a long-term goal.


Actually, updating a FESCo policy is not difficult at all. Once the 
conversation settles down and there is a consensus on how the policy 
should be updated, just make a pull request for fesco-docs for it and 
file a FESCo issue asking FESCo to consider it. I would be very 
surprised if FESCo rejects it when it has been discussed in devel and 
the sponsors themselves back it.


Actually, in my experience, updating FESCo policies is often *easier* 
updating a random Fedora Docs page. FESCo has a documented process for 
handling tickets, and FESCo members actually do respond to them. For 
other docs, proposals for improvement sometimes get not reply at all, or 
get some comments but are neither merged nor rejected.

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

Re: Auto-assign packager sponsors to tickets?

[Otto Liljalaakso]

Jason Tibbitts kirjoitti 3.4.2023 klo 20.09:

Miroslav Suchý  writes:


In any case, what I wrote was the procedure I documented it when I set
it up.  If all of that documentation was lost, then I don't know what to
say but that's not what was intended.

I drove the change that made this happen.  I made sure the documentation
(in the wiki at the time) referenced the procedure.  If that was lost
after the time when I was able to be very active in Fedora, then that's
a sad state of affairs and I don't know why that would happen, but it
would be really good if it could un-happen.  Did FESCo revert the policy
change or something?


Somewhat recently, the Packager sponsor policy [1] has been rewritten. 
The history is that moved content over from the wiki to the Package 
Maintainer Docs, then edited it to make things more clear. Later, I 
realized that what I edited was actually intended to be a FESCo-approved 
policy, just not clearly marked as such in the wiki and editable by 
anyone. So I went to FESCo to get the material officially approved - see 
the pull request [2].


The result of this is that it is currently a FESCo policy that for new 
packages, the sponsorship is requested by blocking the FE-NEEDSPONSOR 
Bugzilla, and for all other paths by filing a Pagure ticket. The reason 
why I wrote the pull request like that is that at that time, there was 
discussion about this on devel where I proposed using Pagure tickets for 
new packages also, but got negative feedback [3].


The gist of that negative feedback was "very few sponsors are looking at 
the Pagure tickets, we cannot process that many". From this thread I get 
the opposite impression, that Pagure tickets are processed quickly and 
FE-NEEDSPONSOR blockers are not looked at. If so, I propose the policy 
is updated to ask for a Pagure ticket in every case.


[1]: https://docs.fedoraproject.org/en-US/fesco/Packager_sponsor_policy/
[2]: https://pagure.io/fesco/fesco-docs/pull-request/59
[3]: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/X54HX23AFVNPHROX5ULPAEW5YGKWOLPI/

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
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: Release rpkg-1.66 and fedpkg-1.44

[Otto Liljalaakso]

Miro Hrončok kirjoitti 9.3.2023 klo 13.17:

On 09. 03. 23 10:05, Otto Liljalaakso wrote:

Miro Hrončok kirjoitti 8.3.2023 klo 17.29:


However, maybe it does not work as I expected?

[python-setuptools (bundles %)]$ fedpkg prep
Not downloading already downloaded setuptools-65.5.1.tar.gz
Could not execute prep: Could not find the release/dist from branch 
name bundles

Please specify with --release


Right, it looks like you interpreted "outside of an established 
dist-git repository" to cover the case where you do have a Git 
repository, but are in a local branch with a custom name. 
Unfortunately, currently only the case where there is no Git 
repository at all is covered.


Mea culpa. I assumed that's the case because I don't use fedpkg outside 
of git much.


I presume that in your example you intend to eventually create a pull 
request. Fedpkg should have a great support for that as well, but a 
bit (just a bit) more work is needed to cover that case. I suppose 
that it would be enough to, instead of printing the error you saw, 
fall back to using the same default mechanism that is used for the 
no-Git case. I will take a look at some point — unless somebody beats 
me to it, of course.


I took a look at this, and making '--release rawhide' for unknown 
branches is very easy [1]. I did not create a pull request yet, because 
I am a bit unsure if this is a good idea. My assumption is still that 
the vast majority of unknown branches are created for Rawhide pull 
requests. But for the ones that are for some other purpose, the default 
behavior changes from asking to be explicit with --release, to doing the 
wrong thing.


There would be log output notifying about defaulting to 'rawhide', and 
the --release parameter could still be used to select the correct 
release. So maybe convenience for the majority case weighs more than 
some risk for the minority case?


[1]: 
https://pagure.io/fork/oturpe/fedpkg/c/712dc656c4b06dafb693e5048baef45a0d82e973

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
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 Tutorial bug - another suggestion, section vs. macro

[Otto Liljalaakso]

Kenneth Goldman kirjoitti 10.3.2023 klo 15.51:

Here's another "surprise for the new user" that I suggest being added.

What does the % character mean?

Sometimes it's the beginning of a section.  Sometimes it's a macro.

I see now that the web page color codes the two differently,
but that's not obvious.

It would be helpful to explain that early


Good idea.
I pushed an update to the pull request I have open from your earlier 
suggestions [1].

Please take a look.

[1]: https://pagure.io/fedora-docs/package-maintainer-docs/pull-request/115


and provide links
or other instructions on how to find the list of each.

Someone posted /usr/lib/rpm/macros for the list
of macros and suggested rpm -E macro to
view the expansion.


For spec file sections, the link is already there:
"You can find more information in the RPM Reference Manual’s section 
[Spec file format]."


Regarding listing available macros, the situation is unfortunately complex.
You can indeed look into /usr/lib/rpm/macros and find many macros in there.
Unfortunately, they are the macros that are available in your local system.
There are many more available in packages you have not installed,
and also the environment where the package is built has a different set 
of packages installed:

Just a minimal base plus anything that is added with BuildRequires.

Similarly for evaluating macros with "rpm -E '%macro'",
it works and is useful, but there are many caveats:
fedpkg inserts some rpm configuration when it runs,
the result depends on the specfile content,
the set of installed packages also affects the result,
and so on.

So while explaining these things somewhere would be useful,
I hesitate to try to do that in the tutorial.
My fear is that attempting to explain these topics correctly would 
distract the reader too much.
I think it is better to just leave the reader to take the listed macros 
as given for now.


For example, if I try the `rpm -E` method with the very first macro in 
the tutorial, I get this:


$ rpm -E '%autosetup`
error: lua script failed: attempt to index a nil value

So if the tutorial explains 'rpm -E' at all,
it should also explain why that happens locally, but the build works.
Also, this is a slippery slope, because presumably then the reader 
should also be given a method to check how the macro evaluates during 
the build.

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
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 Tutorial bug - missing BuildRequires gcc

[Otto Liljalaakso]

Kenneth Goldman kirjoitti 8.3.2023 klo 0.58:

-Original Message-
From: Jason Tibbitts 
Sent: Wednesday, March 1, 2023 6:51 PM
To: Kenneth Goldman 
Cc: Development discussions related to Fedora 
Subject: [EXTERNAL] Re: Package Tutorial bug - missing BuildRequires gcc


Kenneth Goldman  writes:



but … if the tutorial has a sample .spec file, I think it would help
the new user if it was 100% complete.


I believe that the section "A Complete hello.spec File" at
https://urldefense.proofpoint.com/v2/url?u=https-
3A__docs.fedoraproject.org_en-2DUS_package-2Dmaintainers_Packaging-
5FTutorial-5FGNU-5FHello_-23-5Fa-5Fcomplete-5Fhello-5Fspec-
5Ffile=DwIFaQ=jf_iaSHvJObTbx-
siA1ZOg=DZCVG43VcL8GTneMZb8k8lEwb-O1GZktFfre1-
mlmiA=eBYtndmk1vCkvHX6y2J15Jeb4NPWWyIr8LJxlHhQRhTpEaQ_m0uKlbT
oGi5opX06=AcpJmiCpdwml9x3JU0z6dyLZo19mnWH66P6qtnJMlAs=
is, as indicated, complete.  It does contain the necessary build dependency on
gcc, as well as the others.  If I'm missing something, please feel free to 
enlighten
me.


I see.  This 'hello world' is structured to intentionally have errors.  This 
teaches
the reader how to debug.

I have no issue this approach except that it's unusual.  I suggest some text
at the top of the web page explaining this.

This will help the new student, who might be trained to 'stop reading
on the first error'.


Correct interpretation.
There are two things that the tutorial teaches, actually:
First, what tools need to invoked, which which parameters, in which 
order, to do a package modification in Fedora.

And second, how to write spec files to express your intent.
Perhaps it would be a good idea to split the tutorial into two parts.

The first part would be a new tutorial that gives a working, reasonably 
minimal specfile at the start,

and just teaches what commands need to be invoked.

The second part would just the existing tutorial.
It could be used almost as-is as the specfile writing tutorial.
Probably a lot of prose could be removed and moved to the first part.

As a quick improvement, I will add some explanatory text to the top,
so that the reader starts out with the correct expectation.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
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: Release rpkg-1.66 and fedpkg-1.44

[Otto Liljalaakso]

Miro Hrončok kirjoitti 8.3.2023 klo 17.29:

On 08. 03. 23 9:29, Zbigniew Jędrzejewski-Szmek wrote:

On Wed, Mar 08, 2023 at 08:13:57AM +0100, Ondrej Nosek wrote:


Changelog (web documentation):
https://docs.pagure.org/rpkg/releases/1.66.html
https://docs.pagure.org/fedpkg/releases/1.44.html


   In Fedora, the principle is to perform all modifications in
   ‘Rawhide’ first. Thus, it makes sense to assume that any work that
   happens outside of an established dist-git repository is targeting
   Rawhide. Previously, the user had to manually specify --release
   rawhide on every invocation.

That sounds wonderful!


However, maybe it does not work as I expected?

[python-setuptools (bundles %)]$ fedpkg prep
Not downloading already downloaded setuptools-65.5.1.tar.gz
Could not execute prep: Could not find the release/dist from branch name 
bundles

Please specify with --release

[python-setuptools (bundles %)]$ rpm -q fedpkg
fedpkg-1.44-2.fc37.noarch

[python-setuptools (bundles %)]$ rpm -q rpkg-common
rpkg-common-1.66-3.fc37.noarch


Right, it looks like you interpreted "outside of an established dist-git 
repository" to cover the case where you do have a Git repository, but 
are in a local branch with a custom name. Unfortunately, currently only 
the case where there is no Git repository at all is covered.


I presume that in your example you intend to eventually create a pull 
request. Fedpkg should have a great support for that as well, but a bit 
(just a bit) more work is needed to cover that case. I suppose that it 
would be enough to, instead of printing the error you saw, fall back to 
using the same default mechanism that is used for the no-Git case. I 
will take a look at some point — unless somebody beats me to it, of course.

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
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: Release rpkg-1.66 and fedpkg-1.44

[Otto Liljalaakso]

Zbigniew Jędrzejewski-Szmek kirjoitti 8.3.2023 klo 10.29:

On Wed, Mar 08, 2023 at 08:13:57AM +0100, Ondrej Nosek wrote:

Hi all,
a new version rpkg-1.66 together with fedpkg-1.44 are released containing
both features and bugfixes.
Currently, only Fedora 37 (and Rawhide) packages are present in stable
repositories.
Other supported packages are waiting in testing repositories and should be
available in stable in the next two days.

Changelog (web documentation):
https://docs.pagure.org/rpkg/releases/1.66.html
https://docs.pagure.org/fedpkg/releases/1.44.html


   In Fedora, the principle is to perform all modifications in
   ‘Rawhide’ first. Thus, it makes sense to assume that any work that
   happens outside of an established dist-git repository is targeting
   Rawhide. Previously, the user had to manually specify --release
   rawhide on every invocation.

That sounds wonderful!


Thank you for the encouraging feedback.
I think Fedora needs one tool that provides a consistent and simple 
experience, usable for all normal packaging tasks.

Working with specfiles outside of Git repositories falls into that category,
be it for preparing a new package, reviewing them or just playing around 
with a specfile you just downloaded from somewhere.


The pull request to move the harmless but scary-looking "Failed Git 
this-and-that" printouts was just merged.
With that fix in, I think when rpkg 1.67 is released, the no-Git use 
case for fedpkg will finally be in good shape.


Apart from that, there is still the serious problem that 'fedpkg import' 
and rpmautospec do not play well together.

But, I think that is fixable too, and I intend to look at that next.

If anybody knows of another case where things do not work nicely,
I would be interested in hearing about it and making it work.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: fedpkg: Failed to get repository name from Git url or pushurl

[Otto Liljalaakso]

Petr Pisar kirjoitti 7.3.2023 klo 16.48:

V Tue, Mar 07, 2023 at 02:19:11PM -, Betty Liu napsal(a):

I'm using CentOS stream 8 and I've downloaded the source code of yellow. In the 
same directory, I've made the spec file, but after I run
fedpkg --release f28 mockbuild


I worry that f28 is tool old and unknown to mock nowdays. Try a number between
f36 and f39. Those are currently supported Fedora releases.


It shows error

Failed to get repository name from Git url or pushurl
Failed to get ns from Git url or pushurl
warning: line 3: Possible unexpanded macro in: Release:%autorelease
error: %changelog entries must start with *
error: query of specfile /home/lucia/cs/fedora-packaging/hello/hello.spec 
failed, can't parse

Could not execute mockbuild: ('Could not download sources: %s', 
rpkgError('Could not get n-v-r-e from 
/home/lucia/cs/fedora-packaging/hello/hello.spec',))


I think that spec files which use %autorelease macro need to be processed from
a git repository.


Not true. If rpmautospec (that is where %autorelease and %autochangelog 
come from) is available, %autorelease and %autochangelog will evaluate 
to usable defaults even without a Git repository.


The Git related, scary looking output is just fedpkg being overly chatty 
about its internal workings. I have already submitted a pull request to 
move them to debug log level [1].


[1]: https://pagure.io/rpkg/pull-request/660


or as a quick workaround, modify the spec file like this >> Release:
%autorelease



Release:1%{?dist}


%changelog
%autochangelog


%changelog
* Tue Mar 07 2023 Betty Liu  - 2.10-1

That changes will resort to manually maintained release number and changelog
entries.


This workaround will work, and that is how the tutorial was before it 
was just recently converted to rpmautospec as part of Rpmautospec by 
Default [2].


[2]: https://fedoraproject.org/wiki/Changes/Rpmautospec_by_Default

I think the Package Maintainer Docs should be explicit about expecting a 
supported Fedora release. I will take a look at adding such note.

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
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 Tutorial bug - missing BuildRequires gcc

[Otto Liljalaakso]

Kenneth Goldman kirjoitti 1.3.2023 klo 22.35:

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

The tutorial says:

Lines which are not needed (e.g. BuildRequires and Requires) can be
commented out with the hash # for now.

However, I believe that this line is needed.  I'm new so perhaps I'm missing
something.

BuildRequires: gcc


Hello Kenneth,

Thank you reporting the problems you have with the tutorial here on 
devel. This kind of feedback is really useful for improving the 
tutorial. I can see how it can be confusing in its current form. The 
root of the problem here seems to be that the tutorial first instructs 
to create a new specfile with rpmdev-newspec, then to replace it with a 
different initial specfile, and then later goes back to discussing 
something that was in the rpmdev-newspec's variant. The Requires: and 
BuildRequires: in the line you quote refer to that.


I wrote a pull request to improve this [1]. Please take a look.

[1]: https://pagure.io/fedora-docs/package-maintainer-docs/pull-request/115
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
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 Statistics - University of Constantinople edition

[Otto Liljalaakso]

Omair Majid kirjoitti 1.3.2023 klo 5.13:

Hi,

Miroslav Suchý  writes:


The list of packages needed to be converted is again here:

 
https://pagure.io/copr/license-validate/blob/main/f/packages-without-spdx-final.txt

List by package maintainers is here


https://pagure.io/copr/license-validate/blob/main/f/packages-without-spdx-final-maintainers.txt


One package that I care about (`dotnet7.0`) was added to Fedora after
the Let's-move-Fedora-to-SPDX decision was finalized. So the package has
been using SPDX identifiers since the original package review.

How do I make sure such a package is recognized as converted-to-SPDX?


I have the same issue with iir1, also it has been SPDX from the birth, 
but now flagged as needing conversion.


I think Miroslav and company are doing an amazing job with the follow up 
and trying to ensure that everything gets converted eventually. However, 
please try to avoid creating busy work for packagers. We also have 
actual packaging tasks to handle.


The solution for new packages should be such that packagers do not need 
to do anything special. Could you just check package age and exclude 
anything added after SPDX went live? Any problems in such packages are 
just regular guidelines violations. They are important to fix of course, 
but strictly speaking not related to the migration effort.

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
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: Feedback wanted for a proposed improvement to RPM's ELF dependency generator

[Otto Liljalaakso]

Gordon Messmer kirjoitti 23.2.2023 klo 7.34:


In case it helps: I started with the filelist in the "fedora" repo, and 
a list of all of the deps printed by dnf repoquery that ended with 
'()(64bit)', which should be a list of all of the ELF dependencies that 
don't have versioned symbols.  I compared the two to build a list of 
dependencies that match the prefix of a file in the file list, but not 
the entire file name (so the dependency "libssl.so.1.1()(64bit)" matches 
"libssl.so.1.1.1q").


In the "fedora" repo, I can only currently find about 11 dependencies 
that look like they'd be a symlink to a full name, where the full name 
suffix isn't a numeric version:


https://paste.centos.org/view/7e996c65 ("odd" full names)

https://paste.centos.org/view/0b26cb00 (the full list)

CentOS paste links don't last very long, so let me know if those expire 
too quickly.


I only got to this message now. The links did expire too quickly for me.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: fedpkg: Failed to get repository name from Git url or pushurl

[Otto Liljalaakso]

Otto Liljalaakso kirjoitti 21.2.2023 klo 11.45:

Kenneth Goldman kirjoitti 14.2.2023 klo 21.19:

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

Working through the basic tutorial there:

fedpkg --release f37 mockbuild

fails with

Failed to get repository name from Git url or pushurl
Failed to get ns from Git url or pushurl
[repeats forever]

How does fedpkg know what to build?  Does it default to whatever .spec 
file

exists?
Is there another argument to fedpkg. Are there some other steps between
Rpmdev-newspec and fedpkg?

What am I missing?


Sorry for not responding earlier, I currently maintain that tutorial and 
have extensively rewritten it from an earlier tutorial.


The tutorial should be self contained, you should be able to complete it 
by just doing everything listed there.

No other arguments to fedpkg are needed.
I am not certain what is the deduction logic it uses, however.

If the problem you encountered is still reproducible, please open a new 
issue at [1].

If you add some more details regarding the steps you took
(like the sequence of cli commands you issued from a fresh start),
we can take a look what is happening and how to fix it.

[1]: https://pagure.io/fedora-docs/package-maintainer-docs/issues


Ok, I found the other parts of the thread now.
Something strange is going on here - it seems that when Arthur replies,
threading breaks and I see separate subthreads in Thunderbird.
Also lists.fedoraproject.org seems to be similarly confused.

Anyhow, while UTF-8 is valid in specfile %description and creating a 
specfile that is not UTF-8 is an error,

the tutorial is not intended to touch on such topics.
So I replaced the Unicode quotes with 7-bit ASCII ones [1].

To fix the endless loop of warnings you ran into,
I submitted a patch for rpkg (the library that powers fedpkg) [2].

The warnings themselves are quite pointless.
They are shown every time fedpkg is ran outside of Git repository,
even if everything works just fine.
I have meant to do something about them for some time already,
this case finally motivated me to submit a patch [3].

[1]: 
https://pagure.io/fedora-docs/package-maintainer-docs/c/7fa522266bc90f15ee124376f409b897ddfca142?branch=main

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

Re: fedpkg: Failed to get repository name from Git url or pushurl

[Otto Liljalaakso]

Vít Ondruch kirjoitti 15.2.2023 klo 12.21:


Dne 14. 02. 23 v 20:19 Kenneth Goldman napsal(a):

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



I wish this was update to suggest to create git repository right from 
start.


BTW I think that fedpkg could help with this task and therefore opened 
this RFE:


https://pagure.io/fedpkg/issue/500


I have attempted to modify the tutorial to use a Git repository, see [1].
As you see from the comments, there is some resistance to this idea.
I actually I have to agree: Building packages should be possible without 
necessarily mixing in Git.
So I think the better path is to improve the tutorial and tools so that 
everything works nicely without Git.
A lot has already done, as you will see from the changelog for upcoming 
rpkg 1.66 and fedpkg [2,3].


[1]: https://pagure.io/fedora-docs/package-maintainer-docs/pull-request/88
[2]: https://pagure.io/rpkg/pull-request/656
[3]: https://pagure.io/fedpkg/pull-request/501
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: fedpkg: Failed to get repository name from Git url or pushurl

[Otto Liljalaakso]

Kenneth Goldman kirjoitti 14.2.2023 klo 21.19:

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

Working through the basic tutorial there:

fedpkg --release f37 mockbuild

fails with

Failed to get repository name from Git url or pushurl
Failed to get ns from Git url or pushurl
[repeats forever]

How does fedpkg know what to build?  Does it default to whatever .spec file
exists?
Is there another argument to fedpkg. Are there some other steps between
Rpmdev-newspec and fedpkg?

What am I missing?


Sorry for not responding earlier, I currently maintain that tutorial and 
have extensively rewritten it from an earlier tutorial.


The tutorial should be self contained, you should be able to complete it 
by just doing everything listed there.

No other arguments to fedpkg are needed.
I am not certain what is the deduction logic it uses, however.

If the problem you encountered is still reproducible, please open a new 
issue at [1].

If you add some more details regarding the steps you took
(like the sequence of cli commands you issued from a fresh start),
we can take a look what is happening and how to fix it.

[1]: https://pagure.io/fedora-docs/package-maintainer-docs/issues
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
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: shorter shutdown timers are now enabled in rawhide

[Otto Liljalaakso]

Kevin Fenzi kirjoitti 3.2.2023 klo 19.57:

On Fri, Feb 03, 2023 at 06:32:20PM +0100, Fabio Valentini wrote:


It's a 1:1 copy of the update "notes" from bodhi (except re-flowed to
fit into however many columns plain-text emails support).
So it's "markdown", not "awful", but sometimes it's hard to see the
difference ;)
Not sure if it would be possible for bodhi to convert markdown update
notes to "plain text" (i.e. drop all markup) before including it in
the emails it sends out ...


Yeah. Please file RFE at https://github.com/fedora-infra/bodhi ?


https://github.com/fedora-infra/bodhi/issues/5049
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
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: Use cases for 'fedpkg scratch-build'

[Otto Liljalaakso]

Otto Liljalaakso kirjoitti 16.1.2023 klo 23.31:

Miro Hrončok kirjoitti 16.1.2023 klo 16.05:

On 16. 01. 23 14:57, Richard Shaw wrote:


Since `fedpkg scratch-build` bombs out with an error if you've made 
local changes I propose a slight modification:


If no changes are made then it does a normal scratch build for the 
"does this still build / not build" 1% use case


If there are local changes it automatically uploads an SRPM for the 
99% use case.


I love this.

$ fedpkg scratchbuild  / $ fedpkg build --scratch
Uncommitted changes found, uploading SRPM...


I like this modified proposal, too. It achieves what I wanted to do, and 
(unlike my original idea) does not break the "1% case" for 'fedpkg 
scratch-build'. I will try to create a pull request for this. More than 
a single line needs to change, but it should not be too difficult.


Pull request that implements what is discussed above:
https://pagure.io/rpkg/pull-request/653
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
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: Use cases for 'fedpkg scratch-build'

[Otto Liljalaakso]

Vít Ondruch kirjoitti 17.1.2023 klo 13.34:


Dne 16. 01. 23 v 21:59 Otto Liljalaakso napsal(a):

Vít Ondruch kirjoitti 16.1.2023 klo 16.50:

I don't oppose to change of the defaults.

However, I am also using `fedpkg scratch-build --srpm some.rpm`. So 
how would the proposed change influence this command?


I do not intend to change that behavior in any way.



But you proposed to basically drop the `--srpm` option. So maybe this 
should work: `fedpkg scratch-build some.rpm` instead. Not sure. I have 
not thought about this into details especially in relation to plain 
`fedpkg build`.


My original idea was to make --srpm the default, i.e. 'fedpkg 
scratch-build' would be the same as 'fedpkg scratch-build --srpm'. No 
change to 'fedpkg scratch-build --srpm ', or to 'fedpkg 
scratch-build --srpm-mock' (with or without path). The lost feature 
would have been what 'fedpkg scratch-build' currently does: build the 
srpm in Koji, then do a scratch build from it.


Anyhow, Richard has a better proposal in another subthread, which I 
intend to follow: All existing behaviour is kept, but if there are local 
changes, 'fedpkg scratch-build' does what 'fedpkg scratch-build --srpm' 
does — currently an error is printed in this situation.

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
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: Use cases for 'fedpkg scratch-build'

[Otto Liljalaakso]

Miro Hrončok kirjoitti 16.1.2023 klo 16.05:

On 16. 01. 23 14:57, Richard Shaw wrote:


Since `fedpkg scratch-build` bombs out with an error if you've made 
local changes I propose a slight modification:


If no changes are made then it does a normal scratch build for the 
"does this still build / not build" 1% use case


If there are local changes it automatically uploads an SRPM for the 
99% use case.


I love this.

$ fedpkg scratchbuild  / $ fedpkg build --scratch
Uncommitted changes found, uploading SRPM...


I like this modified proposal, too. It achieves what I wanted to do, and 
(unlike my original idea) does not break the "1% case" for 'fedpkg 
scratch-build'. I will try to create a pull request for this. More than 
a single line needs to change, but it should not be too difficult.

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
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: Use cases for 'fedpkg scratch-build'

[Otto Liljalaakso]

Michael J Gruber kirjoitti 16.1.2023 klo 14.46:


`--srpm` is named misleadingly, by the way, because it names the "transport of the 
source" when indeed it implies a potentially different source version. That's 
another reasons why removing it (the name) and making it the mode of operation for 
`scratch-build` makes sense:
- `scratch-build` is about doing things from (your) scratch. That involves an 
srpm for technical reasons.
- `build` is about building something pushed, and `--scratch` only changes 
where it is build.


Actually, --srpm is named like that because you can also do 'fedpkg 
scratch-build --srpm path/to/my/src.rpm', which does what you would 
expect. Generating the srpm from the local working directory is just the 
default when no path is given.



Now I'm wondering: Does `fedpkg build --srpm` imply `--scratch`? I would hope so, and I'm 
really wondering whether any srpm-mode should belong to that command at all. It's much 
clearer if `build` deals with sources "in the buildsystem" only, and 
{copr,scratch,local,mock}-build with the local sources. (Yes, `local` and `mockbuild` 
could have helpful aliases, too.)


I tried it. 'fedpkg build --srpm' is not a scratch build. However, Koji 
does not accept such build requests: "ActionNotAllowed: policy violation 
(build_from_srpm)".

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
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: Use cases for 'fedpkg scratch-build'

[Otto Liljalaakso]

Vít Ondruch kirjoitti 16.1.2023 klo 16.50:

I don't oppose to change of the defaults.

However, I am also using `fedpkg scratch-build --srpm some.rpm`. So how 
would the proposed change influence this command?


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

Use cases for 'fedpkg scratch-build'

[Otto Liljalaakso]

Hello everybody,

I would like to gather different use cases for the 'fedpkg 
scratch-build' command.


Currently, this is exactly the same as 'fedpkg build --scratch', meaning 
that is performs a scratch build of the pushed head of the current 
branch. At least in my workflow, I only do scratch builds before 
pushing, to ensure that what I am about to push builds correctly in 
Koji. Because if this, I never use the default form. Instead, I always 
specify 'fedpkg scratch-build --srpm', so that the srpm to build from is 
locally generated from the local working directory.


What I would like to do is to submit a pull request to either fedpkg or 
rpkg, making that the default. It is a single line code change, not 
counting changes to documentation and code comments.


Doing a scratch build from the pushed contents would still be possible 
by either a) using 'fedpkg build --scratch' or b) checking out the 
remote head and then issuing 'fedpkg scratch-build'.


Above change seems like a clear improvement to me, making the most used 
option the default. But I have noticed that workflows differ wildly 
between packagers, so before submitting any code for review, I would 
like to hear if somebody regularly uses the default form 'fedpkg 
scratch-build' and thinks it currently does the right thing.


This issue came up when we were updating Package Maintainer Docs about 
Koji [1].


[1]: 
https://pagure.io/fedora-docs/package-maintainer-docs/pull-request/101#comment-181487

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
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: Automation of Fedora SCM requests

[Otto Liljalaakso]

Richard Shaw kirjoitti 10.1.2023 klo 15.08:

On Tue, Jan 10, 2023 at 5:26 AM Michal Konecny  wrote:


Hi everyone,

this automation is now in place and new SCM requests will be processed
automatically. If you find any issue with the automation, please report it
to toddlers issue tracker [0].

On behalf of CPE Team,
Michal

[0] - https://pagure.io/fedora-infra/toddlers/issues



While I'm hopeful I can find this email if needed but it would be better if
this was documented here (and wherever else appropriate):

https://docs.fedoraproject.org/en-US/package-maintainers/New_Package_Process_for_New_Contributors/#add_package_to_source_code_management_scm_system_and_set_owner


Pull request:
https://pagure.io/fedora-docs/package-maintainer-docs/pull-request/107

I am grateful if authors of the new automation can review this.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
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: F38 proposal: Rpmautospec by Default (System-Wide Change proposal)

[Otto Liljalaakso]

Neal Gompa kirjoitti 4.1.2023 klo 18.02:

On Wed, Jan 4, 2023 at 10:51 AM Rahul Sundaram  wrote:


On Wed, Jan 4, 2023 at 10:38 AM Neal Gompa  wrote:


On Wed, Jan 4, 2023 at 10:25 AM Chuck Anderson  wrote:


Perhaps this can be modified to create a layout that matches dist-git?


Probably not, because Dist-Git is a Fedora-specific thing, so I
wouldn't accept such a change in rpmdevtools upstream.



You can add it with a --distro flag



Well, more specifically, it's a Fedora build system specific thing.
Building Fedora packages in other systems doesn't necessarily work
that way.

If you want something like this, it probably makes sense to be in
fedpkg(1) itself.


That is exactly what fedpkg does. It calls rpmbuild with a config that 
is compatible with the dist-git layout.


Regarding documenting the configuration that rpmbuild needs, I have 
proposed earlier [1] that people who want to promote rpmbuild usage 
write a tutorial for that. It could create the same package that current 
GNU Hello tutorial creates, just using an alternative toolset.


A lighter way would be to just add a new section to "Installing Package 
Tools" [2], explaining what needs to be configured so that rpmbuild can 
be invoked directly.


Personally, I would prefer that contributions to Package Maintainer Docs 
would either fix parts that are wrong, outdated or unclear, or add 
material that is completely missing, instead of adding alternatives for 
topics that are already well covered. But these docs are under shared 
ownership of all Fedora packagers, so if somebody thinks it is important 
and is willing to work on it, pull requests are welcome!


[1]: 
https://pagure.io/fedora-docs/package-maintainer-docs/pull-request/88#comment-177864
[2]: 
https://docs.fedoraproject.org/en-US/package-maintainers/Installing_Packager_Tools/

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
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: F38 proposal: Rpmautospec by Default (System-Wide Change proposal)

[Otto Liljalaakso]

Dan Horák kirjoitti 3.1.2023 klo 15.23:

On Tue, 3 Jan 2023 08:14:04 -0500
Stephen Smoogen  wrote:


Could you please elucidate why the command that people have used for nearly
30 years and is the most documented on how to build rpms is broken? And how
people should use instead when they may be dealing with an environment
which doesn't allow fedpkg to work? [AKA I am working on a package which I
want to submit for review so I need to build a @$@$% src RPM somehow and I
am being told I can't use the built in command to do so]


I wonder whether we should start recommending "rpkg" instead of plain
"rpmbuild" for the initial/non-dist-git work on rpms ... I am finding it
quite useful/powerful.


Perhaps we have other places that still recommend rpmbuild for this, but 
at least our "GNU Hello" packaging tutorial [1] currently uses fedpkg 
for this.


The instructions given in the tutorial do work. Unlike Stephen implies, 
fedpkg can be used outside of Git repository for this and other tasks.


This Change will make that tutorial use also rpmautospec. I have a pull 
request ready for that [2].


[1]: 
https://docs.fedoraproject.org/en-US/package-maintainers/Packaging_Tutorial_GNU_Hello/

[2]: https://pagure.io/fedora-docs/package-maintainer-docs/pull-request/102
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
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: F38 proposal: Rpmautospec by Default (System-Wide Change proposal)

[Otto Liljalaakso]

Kalev Lember kirjoitti 3.1.2023 klo 11.19:

On Tue, Jan 3, 2023 at 10:13 AM Zbigniew Jędrzejewski-Szmek <
zbys...@in.waw.pl> wrote:


On Tue, Jan 03, 2023 at 09:32:58AM +0100, Vitaly Zaitsev via devel wrote:

On 02/01/2023 21:44, Zbigniew Jędrzejewski-Szmek wrote:

- fedpkg mockbuild


But it doesn't work correctly (will always use Release: 1) if you run
"rpmbuild -bs foo-bar.spec" which is a very common scenario.


"Doctor, it hurts when I do that."

'rpmbuild -bs' is broken. Don't use it.



Yes, I would say that as well. It's just a low level tool and can never
have all the integration with git that fedpkg has.

We might need to update package maintainer documents to be clear about this
though, so that people know that they should use 'fedpkg srpm' and not
'rpmbuild -bs'.


In Package Maintainer Docs, we have just a single instance of rpmbuild 
usage, at Using the Koji Build System — Scratch Builds [1]. Everything 
else is fedpkg based already. I made a pull request to get rid of that 
single outlier [2].


Did you have some other source of documentation in mind that would need 
more work?


[1]: 
https://docs.fedoraproject.org/en-US/package-maintainers/Using_the_Koji_Build_System/#scratch_builds

[2]: https://pagure.io/fedora-docs/package-maintainer-docs/pull-request/101
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
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: F38 proposal: Rpmautospec by Default (System-Wide Change proposal)

[Otto Liljalaakso]

Zbigniew Jędrzejewski-Szmek kirjoitti 2.1.2023 klo 22.44:

On Sun, Jan 01, 2023 at 03:10:22PM +0100, Florian Weimer wrote:

* Vitaly Zaitsev via devel:


On 30/12/2022 20:01, Ben Cotton wrote:

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


-1 until these known issues[1] are fixed, especially with changelogs
  and using rpmautospec in COPR or mock.

[1]:
https://docs.pagure.org/fedora-infra.rpmautospec/peculiarities.html#known-constraints


The page doesnt discuss COPR/mock?

COPR seems to work in some cases, specifically with the dist-git build
(but not just building from dist-git).

A quick check suggests that rpmautospec does the right thing and
produces a portable source RPM that doesn't depend on rpmautospec
anymore.  As a result, the compatibility impact won't be too severe, I
hope.


Also mock builds seem fine. I tested this now on F37 with a few different 
scenarios:
- fedpkg mockbuild
- git commit --allow-empty -m Rebuild && fedpkg mockbuild
- fedpkg srpm && mock *.src.rpm
seem to generate the expected versions numbers and changelogs.


All these examples work because 'fedpkg srpm' does the rpmautospec 
conversion, and all the used fedpkg commands imply 'fedpkg srpm'.


If you generate an srpm which still contains %autorelease and 
%autochangelog with 'rpmbuild -bs', mock will not convert them by 
itself. Also, 'mock --buildsrpm' will not convert them. Perhaps Vitaly 
meant mock should support such usage?


But I wonder, if that is really necessary? In many cases like local test 
builds, the default values for uncoverted %autorelease and 
%autochangelog are just fine, and if the real values are needed, 'fedpkg 
srpm' can be called before invoking mock.

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
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 build failing in Koji for rawhide i686

[Otto Liljalaakso]

Sandro kirjoitti 12.11.2022 klo 20.16:
I recently updated brewtarget to 3.0.3. In koji the build fails[1] only 
for rawhide i686 arch with the following error:


/usr/bin/ld: /lib/libsndfile.so.1: undefined reference to 
`mpg123_open_handle_64'
/usr/bin/ld: /lib/libsndfile.so.1: undefined reference to 
`mpg123_replace_reader_handle_64'

/usr/bin/ld: /lib/libsndfile.so.1: undefined reference to `mpg123_seek_64'
/usr/bin/ld: /lib/libsndfile.so.1: undefined reference to 
`mpg123_length_64'

collect2: error: ld returned 1 exit status
gmake[2]: *** [CMakeFiles/brewtarget.dir/build.make:518: brewtarget] 
Error 1
gmake[2]: Leaving directory 
'/builddir/build/BUILD/brewtarget-3.0.3/redhat-linux-build'
gmake[1]: *** [CMakeFiles/Makefile2:152: CMakeFiles/brewtarget.dir/all] 
Error 2
gmake[1]: Leaving directory 
'/builddir/build/BUILD/brewtarget-3.0.3/redhat-linux-build'

gmake: *** [Makefile:169: all] Error 2
error: Bad exit status from /var/tmp/rpm-tmp.i0qxEh (%build)

I ran 'readelf -s /lib/libsndfile.so.1 | grep mpg123' inside the mock 
chroot and it shows the symbols to be present in the library.


All other branches build fine for all archs. The previous release, only 
a couple of weeks ago, built fine for all branches and I don't see any 
changes in the code that would explain this error.


[1] https://koji.fedoraproject.org/koji/taskinfo?taskID=94094782

I appreciate any pointers,


Why do you need to build for i686?
Could you just add 'ExcludeArch: %{ix86}' and thus avoid the problem?
That is the recommended approach since
"Encourage Dropping Unused / Leaf Packages on i686" [1].

[1]: https://fedoraproject.org/wiki/Changes/EncourageI686LeafRemoval
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
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: Karma for OpenSSL needed

[Otto Liljalaakso]

Kevin Fenzi kirjoitti 2.11.2022 klo 20.33:

On Wed, Nov 02, 2022 at 08:15:00PM +0200, Otto Liljalaakso wrote:


Would it be possible to update Koji's web UI so that it offers the signed
one for download? Is there anything going for the current behavior of
offering the unsigned one instead?


Which signed one?
Some packages have multiple signed copies at the same time.

koji also only knows them by their short hash of the key, not
'fedora-37' or something.

Signed packages are cleaned up after some amount of time if they are not
in a tag requiring keeping them.


Thank you for this information, I was not aware of these details.


So, I suppose the web interface could offer signed copies if they exist,
but might be confusing if you don't know what the various keys short
hash is. Feel free to file a RFE for koji folks: https://pagure.io/koji


I personally will not, because I have been happily downloading the 
unsigned builds from Koji for testing, thus I cannot really present the 
case.
But perhaps somebody who would prefer, or insists on, using only signed 
builds wants to?

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
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: Karma for OpenSSL needed

[Otto Liljalaakso]

Vít Ondruch kirjoitti 2.11.2022 klo 16.18:


Dne 01. 11. 22 v 18:59 Fabio Valentini napsal(a):
On Tue, Nov 1, 2022 at 6:53 PM Demi Marie Obenour 
 wrote:


Please push them out to testing immediately.  Some, such as myself, 
simply

refuse to install unsigned packages.

The packages are already signed, no need to wait for them to be pushed
to testing.



Just FTR, this is the URL which can be obtained from Koji:

https://kojipkgs.fedoraproject.org//packages/openssl/3.0.5/3.fc37/x86_64/openssl-libs-3.0.5-3.fc37.x86_64.rpm

and this is the signed version:

https://kojipkgs.fedoraproject.org//packages/openssl/3.0.5/3.fc37/data/signed/5323552a/x86_64/openssl-libs-3.0.5-3.fc37.x86_64.rpm


Not sure if there is any better way to obtain the signed version early.


Would it be possible to update Koji's web UI so that it offers the 
signed one for download? Is there anything going for the current 
behavior of offering the unsigned one instead?

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
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: [side tags] Undesired automatic side-tag removal happened - how to deal with it in the future?

[Otto Liljalaakso]

Zdenek Dohnal kirjoitti 10.10.2022 klo 11.17:

However the side tag:

f38-build-side-58658

got automatically deleted, even when it had builds connected to it 
already. Documentation [1] does not mention any automatic side-tags 
cleanup and its deadlines.


[1] https://docs.fedoraproject.org/en-US/rawhide-gating/multi-builds/


Unfortunately, it depends on which documentation page you look at.
The Package Maintenance Guide [2] does explain it:
"Side tags are cleaned up 30 days after creation,
or 14 days if they have not been used at all."

These two pages basically have the same information,
with different gaps.
Things would be simpler if they were merged together.
Personally, I would expand Package Maintenance Guide,
because it is part of the Package Maintainer Docs,
and that more of the docs that package maintainers need
would be in one place.

As for getting a pre-warning about expiring side tags,
with instructions on how to extend the lifespan,
and well as instructions for re-creating the side tag afterwards:
both sound great from packager maintainer's perspective.

[2]: 
https://docs.fedoraproject.org/en-US/package-maintainers/Package_Update_Guide/#multiple_packages

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

Re: When is a file dependency appropriate?

[Otto Liljalaakso]

Miro Hrončok kirjoitti 6.10.2022 klo 2.33:

On 06. 10. 22 1:21, Otto Liljalaakso wrote:
Recently, I have run into some cases where file dependencies like 
Requires: /usr/bin/foo are used.


In a recent thread on this mailing list [1],
it is mentioned that such Requires should be avoided,
because resolving file dependencies requires a large amount of memory.


I don't believe that resolving file-Requires from directories listed at 
[2] from your email is more memory hungry. Where exactly was that said?
[1]: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/CRREDQUPPJYWVRMA4DOKYU2KZZLKC4D5/
[2]: 
https://docs.fedoraproject.org/en-US/packaging-guidelines/#_file_and_directory_dependencies 


Maybe I should have re-read the thread closely before posting,
because the most relevant message is this [3]:

"
The discussion in the bug indicates that this memory growth is related to
loading of the full filepath dataset. We have been discussing splitting
out the non-primary-filepath-data (i.e. paths that are not /etc, /usr/bin,
/usr/sbin), out into a separate lazilly-loaded file. If we manage to do
that, we'll kill two birds with one stone:

- initial download of repo metadata on every freakin' dnf operation can
  go down from 80 to 20 MB
- the peak memory use will go down
"

Which exactly confirms what you say.

I am still wondering a bit if there is something else bad about file 
dependencies?

I was asked not to use those in a recent package review [4].
Maybe that was just a reviewer preference then,
and not based on any benefit for the distribution?

[3]: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/QOQQNVN4JPJOAVUBJJM4XLSINPTOG3VE/

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

When is a file dependency appropriate?

[Otto Liljalaakso]

Recently, I have run into some cases where file dependencies like 
Requires: /usr/bin/foo are used.


In a recent thread on this mailing list [1],
it is mentioned that such Requires should be avoided,
because resolving file dependencies requires a large amount of memory.

On the other hand, if the dependency really is to the named executable,
then such Require seems to be the most correct way to declare it.

Is there any recommendation which of these should be given more weight?
The packaging guidelines do not state any position currently [2].
Should they actually recommend using Requires: foo (the package name),
to help dnf memory usage?
Of course unless there is some specific reason to use the file 
dependency, like /usr/bin/ffmpeg that can come from Fedora or RPM 
Fusion, depending on which variant the user has chosen to install.


[1]: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/CRREDQUPPJYWVRMA4DOKYU2KZZLKC4D5/
[2]: 
https://docs.fedoraproject.org/en-US/packaging-guidelines/#_file_and_directory_dependencies

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
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: Review swaps for 3 nagios plugins

[Otto Liljalaakso]

2. lokakuuta 2022 22.30.02 GMT+03:00 Till Hofmann  
kirjoitti:
>I'm looking for reviews or review swaps for 3 nagios plugins:
>
>python-nagios-plugins-check_systemd
>https://bugzilla.redhat.com/show_bug.cgi?id=2082886
>
>nagios-plugins-check_ssl_cert
>https://bugzilla.redhat.com/show_bug.cgi?id=2131602
>
>nagios-plugins-check_newest_file_age
>https://bugzilla.redhat.com/show_bug.cgi?id=2131603
>
>All those packages are trivial to review. I'd be happy to review 
>packages in exchange!

I can review these later today. I have the following simple CMake C++ library 
to swap:

iir1 - DSP IIR Realtime C++ filter library
https://bugzilla.redhat.com/show_bug.cgi?id=2129191

And another CMake C++ library, Loguru, coming up soon. I will ask you about 
when I get the review request up.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Self Introduction: Sébastien Le Roux

[Otto Liljalaakso]

Alexander Ploumistos kirjoitti 28.9.2022 klo 22.13:

On Wed, Sep 28, 2022 at 8:35 PM Sébastien Le Roux
 wrote:


However I wasn't able to understand how to provide a 'koji' build,
I can build the package using 'fedpkg' (local) but not sure how both
relate ...


It's in the "Scratch Builds" section of this document (they're quickly
piling up, I know…):
https://docs.fedoraproject.org/en-US/package-maintainers/Using_the_Koji_Build_System/
Essentially, you do a scratch build of your package in Rawhide and if
it is successful, you post the link to your review request.


Hello Sébastien, and welcome to Fedora!
If you can point to some particular problems in the join documentation,
please let me know.
I would like to fix any issues there,
so that people coming after you would have easier time.
Even a general perception of the current docs is welcome,
it can be difficult to understand what newcomers really would need.

I already create a pull request that adds Koji scratch builds to the GNU 
Hello tutorial [1].


[1]: https://pagure.io/fedora-docs/package-maintainer-docs/pull-request/94
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
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: Sourcegraph documentation

[Otto Liljalaakso]

Vít Ondruch kirjoitti 27.9.2022 klo 10.41:


Dne 27. 09. 22 v 9:21 Vít Ondruch napsal(a):


Dne 26. 09. 22 v 22:20 Otto Liljalaakso napsal(a):


On a different level, Sourcegraph is an effective way to query the 
package sources. For instance, just querying for string 'rexml' 
reveals that the package exists and that is comes from the 'ruby' 
source package:


https://sourcegraph.com/search?q=context:global+repo:%5Esrc%5C.fedoraproject%5C.org/rpms/.*%24+rexml=standard




Ah, this searches just the dist-git, not the expanded sources (not 
surprisingly, how would it work). In that case, this is might be better 
source:


Correct. If you are wondering about my use of the term "package 
sources", that what src.fedoraproject.org calls itself, right there at 
the top. Admittedly, it could also mean the expanded source archives.


Actually, is the sourcegraph.com documented somewhere in some 
discoverable way? I know that we have this service, but my memory 
failed me in details last time  I tried to remember what was its name.


But not sure if I'll be able to come up with the "search" next time. 
But is there any other place where this is documented except of the:


https://fedoramagazine.org/using-sourcegraph-to-search-34000-fedora-repositories/


Not that I know of. We can add it to "Useful links for Package 
Maintainers" [1]. I am not sure if that satisfies your condition of 
discoverability, though.


[1]: https://pagure.io/fedora-docs/package-maintainer-docs/pull-request/90
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
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: Unretire rubygem-logging

[Otto Liljalaakso]

Robby Callicotte via devel kirjoitti 26.9.2022 klo 21.52:


I will also close https://bugzilla.redhat.com/show_bug.cgi?id=2129584 since
this is already in ruby.  I simply did a search in src.fedoraproject.org and
did not see this package.  Sorry bout that.


Querying the repositories can be a complex task sometimes. Source and 
binary package names do not necessarily match, there can be multiple 
binary packages for one source package, and packages can also provide 
other things than their name.


In this case, a better query would have been e.g. 'dnf search rexml' or 
'dnf repoquery --whatprovides 'rubygem(rexml)'.


On a different level, Sourcegraph is an effective way to query the 
package sources. For instance, just querying for string 'rexml' reveals 
that the package exists and that is comes from the 'ruby' source package:


https://sourcegraph.com/search?q=context:global+repo:%5Esrc%5C.fedoraproject%5C.org/rpms/.*%24+rexml=standard
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Updates to nextcloud

[Otto Liljalaakso]

Avi Alkalay kirjoitti 25.9.2022 klo 12.20:

Wow, that’s too much of a process to grasp.


Sorry if I was unclear, I did not mean that you should start the 
Non-responsive package maintainer process right now. The purpose of the 
process is to release the package in case its current maintainers are 
really gone and not taking care of it, so that somebody else can step 
in. Your pull request is now two days old, we do give more time than 
that for maintainers to respond. Starting the process is only 
appropriate if you do not get any response in a long time, like some 
weeks. People may be on vacation, or just happen to be really busy with 
other things.



The original bug that is being fixed is
https://bugzilla.redhat.com/show_bug.cgi?id=1933529

But my PR also improves and fixes other packaging problems that I’ve found
along the way of using the software. Also brings an upstream update.

I wrote it all in the PR.

I had to learn how to use Copr and at the end I have the package built for
many future Fedora and CentOS versions too. It’s all there in the link
provided in my first email.


Thank you for your effort. I do not know much about NextCloud, but 
superficially, it looks like a valuable contribution.



I’ll check your links but I’m not sure it is clear for me what else should
I do beyond the PR, bug report and Copr builds. After your message, it is
still unclear for me if maintainers will take over and accept my PR.


You have done all the correct things, you should not need to do anything 
more at this point. The NextCloud maintainers should review you pull 
request and merge it, unless they have some concerns, which you would 
then resolve together.


I suggest you wait for some time to see if the maintainers are still 
around. I am a bit surprised if they are not, because a new maintainer 
was added just recently.


Unfortunately, if your pull request really is and remains ignored, the 
Non-responsive package maintainer process is the only way to move the 
package to somebody who is willing to handle it and other work items for 
the package.


(Well, actually there is yet another way. People with provenpackager 
access can access any package, so one of them *could* merge your pull 
request and start the builds. But this system is not really intended as 
a back-up for normal package maintenance, but rather for critical issues 
like security fixes, and for performing large changes that affect many 
packages.)

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

Re: Updates to nextcloud

[Otto Liljalaakso]

Avi Alkalay kirjoitti 24.9.2022 klo 14.31:

NextCloud is an amazing project that lets you run your own DropBox with
steroids.

Current F36 package is not performing well because it was not well
integrated with PHP-FPM.

I fixed it in my branch (
https://src.fedoraproject.org/fork/aviram/rpms/nextcloud/commits/rawhide)
along with upstream update to 24.0.5 and other required fixes. PR is here:
https://src.fedoraproject.org/rpms/nextcloud/pull-request/7

I'm looking for someone to approve it and make it into official Fedora.


The correct way to do this is by filing issues in Bugzilla and creating 
PRs (which you have already done). In case they are ignored, you should 
invoke the Non-responsive maintainer policy [1].


Note that the Non-responsive maintainer process was recently started for 
NextCloud [2]. In that case, the current maintainer eventually responded 
and thus is still the main admin. A new co-maintainer was also added. It 
seems that there are multiple people interested in this package and 
ready to contribute, I hope that an arrangement can be found so that 
updates and other fixes can be handled efficiently.


As an aside, if the intent is to only package NextCloud official 
releases, and not betas and release candidates, it would make sense to 
configure release-monitoring.org so that it would stop suggesting those [3].


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

[2]: https://pagure.io/fesco/issue/2838
[3]: https://bugzilla.redhat.com/show_bug.cgi?id=2115524
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
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: Donate 1 minute of your time to test upgrades from F36 to F37

[Otto Liljalaakso]

oli oli via devel kirjoitti 22.9.2022 klo 18.36:

Last metadata expiration check: 0:10:04 ago on Thu Sep 22 17:22:15 2022.
Error:
  Problem 1: package mopidy-spotify-4.1.1-1.fc36.noarch requires 
python3.10dist(mopidy) >= 3, but none of the providers can be installed
   - mopidy-3.3.0-1.fc36.noarch does not belong to a distupgrade repository
   - problem with installed package mopidy-spotify-4.1.1-1.fc36.noarch
  Problem 2: package python3-pyspotify-2.1.3-2.fc36.x86_64 requires python(abi) 
= 3.10, but none of the providers can be installed
   - python3-3.10.6-1.fc36.x86_64 does not belong to a distupgrade repository
   - problem with installed package python3-pyspotify-2.1.3-2.fc36.x86_64


mopidy-spotify is a RPM Fusion package, which has been retired [1]. 
According to the retirement notice, it does not work any more, so I 
suppose you should just remove it. I am not sure if RPM Fusion has 
something like fedora-obsolete-packages, where it could be added so that 
it would be automatically removed for others having the same problem.


[1]: 
https://pkgs.rpmfusion.org/cgit/nonfree/mopidy-spotify.git/commit/?id=a390757c3c03c58191a38161bf043da3ee9a0a06

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
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 wants to replace regular rpms with modules

[Otto Liljalaakso]

Ben Cotton kirjoitti 6.9.2022 klo 21.28:

https://fedoraproject.org/wiki/Changes/ReplaceDnfWithDnf5

== Summary ==
Make DNF5 the new default packaging tool. The change will replace DNF,
LIBDNF, and DNF-AUTOMATIC with the new DNF5 and new Libdnf5 library.
It is a second step after
https://fedoraproject.org/wiki/Changes/MajorUpgradeOfMicrodnf.



== How To Test ==

Install `dnf5` package from
https://copr.fedorainfracloud.org/coprs/rpmsoftwaremanagement/dnf5-unstable/


I did this, and tried using dnf5 instead of dnf. It look like dnf5 wants 
to switch a lot of packages I have to modules. It is my understanding 
that in Fedora, nothing should be installed from modules unless 
explictly requested. What is going on here?


Using postgresql as an example, I have it installed as regular rpm, not 
module:


$ LANG=C.UTF-8 dnf -C info --installed postgresql
Installed Packages
Name : postgresql
Version  : 14.3
Release  : 8.fc37
Architecture : x86_64
Size : 6.0 M
Source   : postgresql-14.3-8.fc37.src.rpm
Repository   : @System
From repo: fedora

But dnf5 wants to use a module instead:

$ LANG=C.UTF-8 sudo dnf5 upgrade --assumeno postgresql
Updating and loading repositories:
Repositories loaded.
Package  Arch   Version  Repository
Upgrading:
 postgresql  x86_64 15beta2-1.module_f37 fedora-mod
  replacing postgresql   x86_64 14.3-8.fc37  
 postgresql-private-libs x86_64 15beta2-1.module_f37 fedora-mod
  replacing postgresql-private-libs
 x86_64 14.3-8.fc37  
 postgresql-server   x86_64 15beta2-1.module_f37 fedora-mod
   replacing postgresql-server
 x86_64 14.3-8.fc37  
Installing dependencies:
 libicu69x86_64 69.1-1.fc37  fedora

Transaction Summary:
 Installing:1 packages
 Upgrading: 3 packages
 Replacing: 3 packages

Operation aborted by the user.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
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: Non-responsive maintainer check for golang-github-prometheus-common-devel

[Otto Liljalaakso]

18. syyskuuta 2022 13.31.24 GMT+03:00 zebo...@gmail.com kirjoitti:
>
>I haven't seen fpokorny active even when I started working on Go
>packages. Is there a way to reallocate all is Go packages to either the
>go-sig group or myself?

According to policy, they cannot be allocated to the SIG: "SIGs cannot be 
primary maintainers, but they can be co-maintainers." [1] 

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

Re: update libXft to 2.3.6

[Otto Liljalaakso]

18. syyskuuta 2022 1.53.45 GMT+03:00 Thomas Dickey  kirjoitti:
>The release monitoring project for libXft
>(https://release-monitoring.org/project/1777/)
>doesn't appear to have noticed the release of 2.3.6 a week ago.
>Any clues on how to fix this?

When I open that link, it shows 2.3.6 as the latest release. Maybe there just 
was some lag? It says "retrieved on 2022-09-10", though, strange that you still 
did not see it a week later.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
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: F38 proposal: Strong crypto settings: phase 3, forewarning 2/2 (System-Wide Change proposal)

[Otto Liljalaakso]

Tommy Nguyen kirjoitti 17.9.2022 klo 10.44:

On Sat, 2022-09-17 at 10:40 +0300, Otto Liljalaakso wrote:

Leigh Scott kirjoitti 17.9.2022 klo 10.27:

On Thu, 2022-09-15 at 22:42 +0300, Otto Liljalaakso wrote:

I found this:
https://bugzilla.rpmfusion.org/show_bug.cgi?id=6410#c1

Again, not a very friendly response. The short is that they are
currently in freeze so no action can be taken ATM.


I did not write that, Tommy did. Please be careful with attribution,
especially with clips that can be interpreted as negative.

Other than that, great to see somebody from RPM Fusion involved in
this


It was almost certainly a typo when editing the replies. I doubt they
intended to misquote.


No malice assumed, and no harm done! I just wanted to point out the 
accident.

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
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: F38 proposal: Strong crypto settings: phase 3, forewarning 2/2 (System-Wide Change proposal)

[Otto Liljalaakso]

Leigh Scott kirjoitti 17.9.2022 klo 10.27:

On Thu, 2022-09-15 at 22:42 +0300, Otto Liljalaakso wrote:

I found this: https://bugzilla.rpmfusion.org/show_bug.cgi?id=6410#c1

Again, not a very friendly response. The short is that they are
currently in freeze so no action can be taken ATM.


I did not write that, Tommy did. Please be careful with attribution, 
especially with clips that can be interpreted as negative.


Other than that, great to see somebody from RPM Fusion involved in this 
thread!

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
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: Replace DNF with DNF5 (System-Wide Change proposal)

[Otto Liljalaakso]

Ben Cotton kirjoitti 6.9.2022 klo 21.28:

== Summary ==
Make DNF5 the new default packaging tool. The change will replace DNF,
LIBDNF, and DNF-AUTOMATIC with the new DNF5 and new Libdnf5 library.



== Upgrade/compatibility impact ==
The new DNF5 will obsolete `dnf`, `yum`, `dnf-automatic`, `yum-utils`,
and DNF plugins (core and extras).d by `fedora-obsolete-packages`.


These two are the only mentions of dnf-automatic in this change. What 
does "replace" mean here? How does DNF5 cover dnf-automatic's use case?

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
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: F38 proposal: Strong crypto settings: phase 3, forewarning 2/2 (System-Wide Change proposal)

[Otto Liljalaakso]

Tommy Nguyen kirjoitti 16.9.2022 klo 6.51:

On Thu, 2022-09-15 at 22:42 +0300, Otto Liljalaakso wrote:

RPM Fusion Fedora 37 repository seems to be all SHA256 already.


Thanks for doing the research. I plan on upgrading to the F37 beta
soon. Have you done so already and what are your results?


I have the same plan, but currently I cannot fully upgrade my Fedora 36 
[1], so Fedora 37 Beta has to wait until that is resolved.


However, this issue is easily reproducible in a Toolbox container. 
There, I see the reported problems for Fedora 36, but not for Rawhide.
I have not tried Fedora 37, and do not plan to do so, because based on 
the information that has been gathered, I am convinced that the problem 
will be gone soon enough.


[1]: https://bugzilla.redhat.com/show_bug.cgi?id=2124059
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
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: F38 proposal: Strong crypto settings: phase 3, forewarning 2/2 (System-Wide Change proposal)

[Otto Liljalaakso]

Tommy Nguyen kirjoitti 15.9.2022 klo 17.40:



On Sep 15, 2022, at 10:26 AM, Otto Liljalaakso  wrote:

So maybe it is just that, for Fedora 36 at least, RPM Fusion it not compatible 
with the new crypto settings.

I also see the following key ids in the errors I reported in the original 
message. How can I check what those are, more RPM Fusion keys?

6dc1be18
d651ff2e
94843c65


A while back I reported the issue and someone said that it has to do with their 
sub key. Not much that can be done except report it to rpmfusion (unless it’s 
already been done).


I tried searching bugzilla.rpmfusion.org, but could not find anything 
that looks relevant. I also wanted to search the mailing lists, but 
apparently, at the moment, RPM Fusion is not publicly archiving its 
mailing lists [1].


[1]: https://bugzilla.rpmfusion.org/show_bug.cgi?id=4759#c5

Anyhow, I did some more research. It looks like RPM Fusion has switched 
signing packages with SHA256, but in their repository for Fedora 36, 
there are older builds around that still use SHA1. At least the SHA1 
ones that I found are older than the SHA256 ones.


RPM Fusion Fedora 37 repository seems to be all SHA256 already.

So, it looks like there is nothing to fix here, except maybe adding some 
note to testing instructions.



In order to identify the rest of the keys, try:

rpm -qa gpg-pubkey\*
rpm -qi gpg-pubkey-keyid-goeshere


Thanks, they are all from RPM Fusion.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
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: F38 proposal: Strong crypto settings: phase 3, forewarning 2/2 (System-Wide Change proposal)

[Otto Liljalaakso]

Tommy Nguyen kirjoitti 15.9.2022 klo 16.28:


On Thu, 2022-09-15 at 16:18 +0300, Otto Liljalaakso wrote:

To test this, I did enable TEST-FEDORA39 on my system, first
installed
as Fedora 24, now running 36. For some rpm and dnf operations, I get
the
following kind of errors:

error: rpmdbNextIterator: skipping h# 740
Header V3 RSA/SHA1 Signature, key ID d651ff2e: BAD
Header SHA256 digest: OK
Header SHA1 digest: OK

I first noticed this with 'dnf upgrade', simplified to 'dnf reinstall
glibc', perhaps the best reproduces is 'rpm -qa > /dev/null'.

Regardless of these errors, all the commands work as expected. Still
I
wonder, is it expected that old installations will see, and keep
seeing,
these errors after distrusting SHA-1?


That is the RPM Fusion signing key.


Yes, I have RPM Fusion enabled. I also see that there are more problems 
with RPM Fusion:


$ sudo dnf install vlc
...
Problem opening package faad2-libs-2.10.0-3.fc36.x86_64.rpm
Problem opening package libdca-0.0.7-5.fc36.x86_64.rpm
Problem opening package live555-2022.02.07-1.fc36.x86_64.rpm
The downloaded packages were saved in cache until the next successful 
transaction.

You can remove cached packages by executing 'dnf clean packages'.
Error: GPG check FAILED

If I install vlc when the DEFAULT policy is in force, then put 
TEST-FEDORA39 back, I cannot remove vlc any more:


$ sudo dnf remove vlc
...
Remove  96 Packages
Freed space: 377 M
Is this ok [y/N]: y
Running transaction check
error: rpmdbNextIterator: skipping h# 526
Header V3 RSA/SHA1 Signature, key ID d651ff2e: BAD
Header SHA256 digest: OK
Header SHA1 digest: OK
Error: An rpm exception occurred: package not installed

So maybe it is just that, for Fedora 36 at least, RPM Fusion it not 
compatible with the new crypto settings.


I also see the following key ids in the errors I reported in the 
original message. How can I check what those are, more RPM Fusion keys?


6dc1be18
d651ff2e
94843c65
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
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: F38 proposal: Strong crypto settings: phase 3, forewarning 2/2 (System-Wide Change proposal)

[Otto Liljalaakso]

Ben Cotton kirjoitti 29.8.2022 klo 21.30:

https://fedoraproject.org/wiki/Changes/StrongCryptoSettings3Forewarning2

== Summary ==

Cryptographic policies will be tightened in Fedora ''38''-39,
SHA-1 signatures will no longer be trusted by default.
Fedora ''38'' will do a "jump scare", introducing the change but then
reverting it in time for Beta.
Test your setup with TEST-FEDORA39 today and file bugs in advance so
you won't get bit by Fedora ''38''-39.


To test this, I did enable TEST-FEDORA39 on my system, first installed 
as Fedora 24, now running 36. For some rpm and dnf operations, I get the 
following kind of errors:


error: rpmdbNextIterator: skipping h# 740
Header V3 RSA/SHA1 Signature, key ID d651ff2e: BAD
Header SHA256 digest: OK
Header SHA1 digest: OK

I first noticed this with 'dnf upgrade', simplified to 'dnf reinstall 
glibc', perhaps the best reproduces is 'rpm -qa > /dev/null'.


Regardless of these errors, all the commands work as expected. Still I 
wonder, is it expected that old installations will see, and keep seeing, 
these errors after distrusting SHA-1?

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
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: Troubleshooting EPEL 8 build

[Otto Liljalaakso]

9. syyskuuta 2022 15.58.26 GMT+03:00 Ron Olson  
kirjoitti:
>
>Also, on a related note, what is the protocol for having one platform
>fail to build, while the others do? Is it okay to submit the
>Fedora/EPEL-9 builds to production, or is it more of a all-or-nothing
>kind of thing? I’ve been taking the latter approach, but I’ve been
>wondering if it’s not okay to let everyone else have the
>latest-n-greatest, as I’ve been having a lot of trouble finding the
>time to troubleshoot this EPEL-8 issue.

Yes, you can submit builds for various Fedora and EPEL releases even if you 
have problems with others. Even if you submit all the Bodhi updates in one go, 
you cannot ensure that they hit users at the same time. Getting karma in Bodhi, 
mirror sync delays and users' update schedules make the end result 
unpredictable.

Perhaps it is a good idea to start from Rawhide and work in order of decreasing 
release numbers, to avoid situation where a newer release has an older version, 
for extended periods of time. But I do not think there is a hard ban such 
situation, either.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Check out the Fedora Packager Dashboard!

[Otto Liljalaakso]

Miro Hrončok kirjoitti 25.8.2022 klo 11.32:

Hello folks,

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


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


I agree with others, this is a great and very useful service. In attempt 
to make it better known, I just proposed it to be linked from the 
Package Maintainer Docs:


https://pagure.io/fedora-docs/package-maintainer-docs/pull-request/85

If anybody knows more useful services that are not visible those docs, 
please let me know so we can add those, too.

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
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: Confused about what to do about a ticket

[Otto Liljalaakso]

Jarek Prokop kirjoitti 26.8.2022 klo 17.50:

Hi,

Usually for Rawhide updates CLOSED RAWHIDE + add NVR into `fixed in 
version`
if only Rawhide fixes that bug (e.g., a new software version), that 
should be enough.


But it seems auto updates can take care of the tickets if you specify 
the bugs via the `Resolves: rhbz#1234` references as noted by Vít.


A webpage… Depends what you plan on doing, I use this if I am unsure in 
the bug status workflow: 
https://docs.fedoraproject.org/en-US/package-maintainers/bug_status/


Regarding how updates work in different branches, see Package Update 
Guide [1]. Rawhide is covered in section "Rawhide and early Branched".


[1]: 
https://docs.fedoraproject.org/en-US/package-maintainers/Package_Update_Guide/

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
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: percona-xtrabackup bundling the kitchen sink in static libs

[Otto Liljalaakso]

Sven Lankes kirjoitti 26.8.2022 klo 0.03:



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


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

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


Thank you for correcting me, and for updating bug statuses. I apologize 
for not checking on those bugs more closely before writing here.


I had to go back and check how I ended up pasting a link that contains 
EPEL bugs as well. The reason: If you click on package's "Bugs" link at 
Fedora Packages site, you get bugs for Fedora only. If you click "Bug 
Reports" at Fedora Package Sources, you get bug for Fedora *and* EPEL. I 
must have used the latter this time.

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

Re: Retiring: python-sendgrid

[Otto Liljalaakso]

Fabio Valentini kirjoitti 25.8.2022 klo 16.01:

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


Once upon a time, Ali Erdinc Koroglu  said:

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


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


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


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

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

Re: Adoption of flare package

[Otto Liljalaakso]

Sandro kirjoitti 25.8.2022 klo 1.05:


On 8/24/22 23:43, Otto Liljalaakso wrote:


It looks like a commit was queuing in a pull request for a long time,
then merged after other things had happened in rawhide. Probably a more
correct Git date to use in %changelog would be the commit date instead
of author date:

$  git log --pretty=fuller -n 1 fffbc90b
commit fffbc90bcf7a79f918d6ee7f34dfdc43042967c6
Author: Justin Jacobs 
AuthorDate: Tue Oct 12 18:31:17 2021 -0400
Commit: Erik Schilling 
CommitDate: Tue Feb 1 19:42:45 2022 +0100

  Update to 1.12 and fix font symlinks

The date when the release happened is good, too.


Well, the release never happened. In flare's spec file it is not 
present. According to koji[1] it went from 1.07 straight to 1.13. Same 
for flare.


So, I decided to just remove the changelog entry entirely.


Thank you, that is a good solution.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
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: Adoption of flare package

[Otto Liljalaakso]

Sandro kirjoitti 24.8.2022 klo 23.50:


Yes, after I talked to him he became aware of the dependency between the 
two packages and adopted flare as well.


AFAIK, both packages have been updated to the latest upstream release 
now and built successfully. They should find their way into the 
different repos, soon.


Great!


However, one part of the cause of that problem is the trailing dot in
the end of '%cmake' [2]. It would be good to remove that. Since you are
interested in starting with package maintenance, that could be a good
first pull request for you.


I'll do that. I'm still in the process of getting acquainted. I tried to 
fork flare and flare-engine earlier, but wasn't able to. Seems like it 
was a temporary issue. Just tried again and it worked.


Anonymous forking in src.fedoraproject.org is a bit tricky to setup and 
use, great to hear that you got it working.



Building flare-engine also prints out another (non-fatal) error, you
could also correct that in a pull request, just for practice:

error: %changelog not in descending chronological order


I saw that when linting. Wasn't sure how to handle that. The offending 
changelog entry has the right date according to git blame. The releases 
are in the right order. Probably just adjust the date to when that 
release actually happened and silence rpmlint...


It looks like a commit was queuing in a pull request for a long time, 
then merged after other things had happened in rawhide. Probably a more 
correct Git date to use in %changelog would be the commit date instead 
of author date:


$  git log --pretty=fuller -n 1 fffbc90b
commit fffbc90bcf7a79f918d6ee7f34dfdc43042967c6
Author: Justin Jacobs 
AuthorDate: Tue Oct 12 18:31:17 2021 -0400
Commit: Erik Schilling 
CommitDate: Tue Feb 1 19:42:45 2022 +0100

Update to 1.12 and fix font symlinks

The date when the release happened is good, too.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
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: Adoption of flare package

[Otto Liljalaakso]

Sandro kirjoitti 24.8.2022 klo 14.33:

On 23-08-2022 16:00, Sandro wrote:

I am interested in adopting the orphaned flare package[1]. It doesn't
appear to have any complicated requirements. My local build on a recent
git clone succeeded without effort.


Hello Sandro,

Thank you for taking interest in this.

I became aware of the package being orphaned by the announcement sent a 
couple of days ago. While flare is being orphaned, flare-engine is not.


So, I guess my next step would be to contact the current maintainer, 
Sandipan Roy aka bytehackr, and discuss with him? Both packages rely on 
the same source. I guess he would appreciate a heads up. Maybe he took 
flare-engine recently and forgot about flare.


I see that Sandipan has adopted both flare-engine and flare now. It 
might still be a good idea to contact them. Both packages still have 
missing builds for some releases, and it is always good to have more 
than one person taking care of a package.



As I'm not in the packagers group, yet, I will have to complete the
sponsoring process first. For that I am looking for a sponsor, too.


Regarding the FTBFS bug [3], it looks like the rebuild failed for the 
s390x target. Not sure, this is a desired target. Could probably just be 
disabled.


You are misinterpreting the situation. It is true that the only failed 
architecture is s390x, but the rest have been cancelled, presumably 
because that one failed.


If you check build.log attached to Bugzilla, you will the following error:

> Error: /builddir/build/BUILD/flare-engine-v1.13/redhat-linux-build is 
not a directory


Which looks like a certain horrible problem Fedora has been having with 
CMake [1]. It has since then been fixed, or at least worked around, so 
just issuing a rebuild should get past that.


However, one part of the cause of that problem is the trailing dot in 
the end of '%cmake' [2]. It would be good to remove that. Since you are 
interested in starting with package maintenance, that could be a good 
first pull request for you.


Building flare-engine also prints out another (non-fatal) error, you 
could also correct that in a pull request, just for practice:


error: %changelog not in descending chronological order

Finally, regarding your proposal to disable building on s390x. It is 
understandable that it feels useless, because people do not usually play 
games on mainframes. However, generally Fedora tries to build everything 
on all architectures. So, always first investigate what is the issue, 
only resort to ExcludeArch if the problem is really unsolvable for 
certain architecture.


Hope this helps, and please ask if anything is unclear.

[1]: https://bugzilla.redhat.com/show_bug.cgi?id=2059201
[2]: 
https://src.fedoraproject.org/rpms/flare-engine/blob/rawhide/f/flare-engine.spec#_46

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
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: percona-xtrabackup bundling the kitchen sink in static libs

[Otto Liljalaakso]

Paul Wouters kirjoitti 23.8.2022 klo 3.07:


Hi,

I looked at fixing percona-xtrabackup and noticed it is staticly linking
to a bunch of libraries. These .a files are then removed in %install so
they are not shipped. It bundles a bunch of this stuff from its extra/ dir:

duktape  googletest  icu  libcbor  libedit  libevent  libfido2  libkmip  
lz4  protobuf  rapidjson  robin-hood-hashing  zlib  zstd


On top of that, it pins boost to a specific (older!) version and bundles 
boost

seperate via dist-git / sources :(


The relevant policy is Bundled software policy [1]. Unlike in the past, 
a package does not need a FESCo exception to bundle dependencies. 
However, the requirements of that policy are not being met here: The 
reason for bundling should be recorded in the specfile, and Provides: 
bundled(x) = 1.2.3 should be included.


[1]: https://docs.fedoraproject.org/en-US/fesco/Bundled_Software_policy/


I've just fixed it up in the same bad way, making it link to the old
openssl just to get it past F35FailsToInstall for rhbz#1989019. It is
going through rawhide and the branches now. But I think perhaps this
package should be removed from rawhide.

This package clearly breaks a lot of packaging rules, so I was
wondering if there was ever any exception of some kind given to this
package? I will definitely look at $dayjob migrating away from this,
eg see if myhoard or mariabackup can be used instead.

Any feedback would be appreciated, as it seems the maintainer is MIA.


If the maintainer is not responding, you should invoke the 
Non-responsive maintainer policy [2]. This package has CVE bugs open 
[3], so most probably it should eith be retired, or somebody should 
start caring for it.


[2]: 
https://docs.fedoraproject.org/en-US/fesco/Policy_for_nonresponsive_package_maintainers/
[3]: 
https://bugzilla.redhat.com/buglist.cgi?bug_status=NEW_status=ASSIGNED=Fedora=percona-xtrabackup=Fedora=Fedora%20EPEL

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
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: rpmautospec by default

[Otto Liljalaakso]

Zbigniew Jędrzejewski-Szmek kirjoitti 6.8.2022 klo 20.19:

On Sat, Aug 06, 2022 at 06:29:25PM +0200, Miro Hrončok wrote:

On 06. 08. 22 16:10, Zbigniew Jędrzejewski-Szmek wrote:

Let's make %autorelease + %autochangelog the default approach in Fedora 
packaging


I still haven't got around to start using it, because I recall that
initially there were problems I've reported or followed and nobody was
looking into them. This got a bit better, but is still quite bad :(


My experience was similar. Initially, I was excited about not having to 
tinker with the specfile changelog any more, so converted some packages 
to rpmautospec. Then I ran into issues, so I converted everything back 
to manual changelog. Also I got the feeling that issues were fixed 
slowly. The two issue ssI was tracking at the time [1,2] have since been 
marked fixed, though.


[1]: https://pagure.io/fedora-infra/rpmautospec/issue/104
[2]: https://pagure.io/fedora-infra/rpmautospec/issue/189

I believe removing menial work from packaging workflow is really 
valuable, probably even necessary to keep things running in the future. 
But if some automation is recommended for all packagers, please make 
sure that people who follow that recommendation do have to regret.



The following issues all bother me and nobody seem to have the resources to
fix them or even look at them:

https://pagure.io/fedora-infra/rpmautospec/issue/238 -- 9 months ago


I mention this one in my wall'o'text above. It's something for
fedora-review to fix. I don't think it's a blocking issue though:
fedora-review is always slow with following new things and reviewers
must always be prepared to ignore most of its output.


The complaint about missing dist tag has been already fixed [1]. Is 
there something else that does not work in fedora-review yet?


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

Re: Self Introduction: Jiri Hnidek

[Otto Liljalaakso]

Welcome Jiri!

Jiri Hnidek kirjoitti 5.8.2022 klo 17.02:

I'm Red Hatter and I'm a member of the Candlepin team [1]. I develop mostly
client-tools in this project. It means that I contribute mostly to
subscription-manager [2] , virt-who [3] and other repositories related to
Red Hat Subscription Management (RHSM).


(snip)


I would like to fix following two Bugzilla issues:
* https://bugzilla.redhat.com/show_bug.cgi?id=2089022
* https://bugzilla.redhat.com/show_bug.cgi?id=2110853

but I need to become a Fedora packager. I IMHO need permission to pushing
commits to following repositories:

* https://src.fedoraproject.org/rpms/subscription-manager
* https://src.fedoraproject.org/rpms/subscription-manager-cockpit
* https://src.fedoraproject.org/rpms/subscription-manager-rhsm-certificates


Not necessarily. You could also submit the required fixes as pull 
requests to those repositories and let the current maintainer perform 
the actual build.


On the other hand, in your case the "Becoming a co-maintainer" route for 
sponsorship [1] could make sense. You need to be a co-maintainer to 
build those packages yourself in any case. Probably it is the best to 
ask the current maintainers how they prefer to proceed with your 
contribution.


[1]: 
https://docs.fedoraproject.org/en-US/fesco/Packager_sponsor_policy/#comaintainer

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