11:54 a.m.
Like many of you, I have been quite inconvenienced because of
dnf5-related breakage of fedora-review. I've been monkeying with it
today and finally got a successful run of fedora-review after making
the following changes [*].
1. Edit /etc/mock/templates/fedora-rawhide.tpl. Change:
config_opts['package_manager'] = 'dnf'
to:
config_opts['package_manager'] = 'dnf5'
2. Run 'mock -r fedora-rawhide-x86_64 --scrub=bootstrap'
3. Edit /usr/lib/python3.11/site-packages/FedoraReview/deps.py. Change line
83 from:
"dnf repoquery -q -C --requires --resolve " + "
".join(list(set(pkgs))),
to:
"dnf repoquery -q -C --requires " + "
".join(list(set(pkgs))),
Change line 97 from:
name = line.rsplit(".", 2)[0]
to:
name = resolve_one(line)[0].rsplit(".", 2)[0]
Change line 286 from:
"dnf repoquery -C -l " + " ".join(list(set(pkgs))),
to:
"dnf repoquery --files " + " ".join(list(set(pkgs))),
Other changes may be needed.
[*] Altering rpm-controlled files is generally a bad idea, and I do not
recommend it. I am only doing so in this case because fedora-review does
not work at all without these changes. I understand that my changes will
be overwritten the next time a mock-core-configs or fedora-review update
is installed.
--
Jerry James
http://www.jamezone.org/
1:39 p.m.
On Mon, Jul 17, 2023 at 10:54 AM Jerry James <loganjerry(a)gmail.com> wrote:
Like many of you, I have been quite inconvenienced because of
dnf5-related breakage of fedora-review. I've been monkeying with it
today and finally got a successful run of fedora-review after making
the following changes [*].
1. Edit /etc/mock/templates/fedora-rawhide.tpl. Change:
config_opts['package_manager'] = 'dnf'
to:
config_opts['package_manager'] = 'dnf5'
2. Run 'mock -r fedora-rawhide-x86_64 --scrub=bootstrap'
3. Edit /usr/lib/python3.11/site-packages/FedoraReview/deps.py. Change line
83 from:
"dnf repoquery -q -C --requires --resolve " + "
".join(list(set(pkgs))),
to:
"dnf repoquery -q -C --requires " + "
".join(list(set(pkgs))),
Change line 97 from:
name = line.rsplit(".", 2)[0]
to:
name = resolve_one(line)[0].rsplit(".", 2)[0]
Change line 286 from:
"dnf repoquery -C -l " + " ".join(list(set(pkgs))),
to:
"dnf repoquery --files " + " ".join(list(set(pkgs))),
Other changes may be needed.
[*] Altering rpm-controlled files is generally a bad idea, and I do not
recommend it. I am only doing so in this case because fedora-review does
not work at all without these changes. I understand that my changes will
be overwritten the next time a mock-core-configs or fedora-review update
is installed.
Skip steps 1 and 2. They are unnecessary. Step 3 is all you need.
--
Jerry James
http://www.jamezone.org/
5:38 p.m.
On 17-07-2023 20:39, Jerry James wrote:
On Mon, Jul 17, 2023 at 10:54 AM Jerry James
<loganjerry(a)gmail.com> wrote:
> Like many of you, I have been quite inconvenienced because of
> dnf5-related breakage of fedora-review. I've been monkeying with it
> today and finally got a successful run of fedora-review after making
> the following changes [*].
>
> 1. Edit /etc/mock/templates/fedora-rawhide.tpl. Change:
>
> config_opts['package_manager'] = 'dnf'
>
> to:
>
> config_opts['package_manager'] = 'dnf5'
>
> 2. Run 'mock -r fedora-rawhide-x86_64 --scrub=bootstrap'
>
> 3. Edit /usr/lib/python3.11/site-packages/FedoraReview/deps.py. Change line
> 83 from:
>
> "dnf repoquery -q -C --requires --resolve " + "
".join(list(set(pkgs))),
>
> to:
>
> "dnf repoquery -q -C --requires " + "
".join(list(set(pkgs))),
>
> Change line 97 from:
>
> name = line.rsplit(".", 2)[0]
>
> to:
>
> name = resolve_one(line)[0].rsplit(".", 2)[0]
>
> Change line 286 from:
>
> "dnf repoquery -C -l " + " ".join(list(set(pkgs))),
>
> to:
>
> "dnf repoquery --files " + " ".join(list(set(pkgs))),
>
> Other changes may be needed.
>
> [*] Altering rpm-controlled files is generally a bad idea, and I do not
> recommend it. I am only doing so in this case because fedora-review does
> not work at all without these changes. I understand that my changes will
> be overwritten the next time a mock-core-configs or fedora-review update
> is installed.
Skip steps 1 and 2. They are unnecessary. Step 3 is all you need.
Would that be a temporary solution for Copr as well? I mean for all
rawhide builds? I quite miss not having fedora-review available there.
-- Sandro
5:38 a.m.
Hello Jerry,
I proposed a workaround a few days ago
https://pagure.io/FedoraReview/pull-request/485
but your patch looks like a proper fix. I'll try it and merge to the
fedora-review codebase.
Does anybody know what was the purpose of --resolve and if it will be
no problem when we remove it?
Jakub
On Tue, Jul 18, 2023 at 12:39 AM Sandro <lists(a)penguinpee.nl> wrote:
On 17-07-2023 20:39, Jerry James wrote:
> On Mon, Jul 17, 2023 at 10:54 AM Jerry James <loganjerry(a)gmail.com> wrote:
>> Like many of you, I have been quite inconvenienced because of
>> dnf5-related breakage of fedora-review. I've been monkeying with it
>> today and finally got a successful run of fedora-review after making
>> the following changes [*].
>>
>> 1. Edit /etc/mock/templates/fedora-rawhide.tpl. Change:
>>
>> config_opts['package_manager'] = 'dnf'
>>
>> to:
>>
>> config_opts['package_manager'] = 'dnf5'
>>
>> 2. Run 'mock -r fedora-rawhide-x86_64 --scrub=bootstrap'
>>
>> 3. Edit /usr/lib/python3.11/site-packages/FedoraReview/deps.py. Change line
>> 83 from:
>>
>> "dnf repoquery -q -C --requires --resolve " + "
".join(list(set(pkgs))),
>>
>> to:
>>
>> "dnf repoquery -q -C --requires " + "
".join(list(set(pkgs))),
>>
>> Change line 97 from:
>>
>> name = line.rsplit(".", 2)[0]
>>
>> to:
>>
>> name = resolve_one(line)[0].rsplit(".", 2)[0]
>>
>> Change line 286 from:
>>
>> "dnf repoquery -C -l " + "
".join(list(set(pkgs))),
>>
>> to:
>>
>> "dnf repoquery --files " + "
".join(list(set(pkgs))),
>>
>> Other changes may be needed.
>>
>> [*] Altering rpm-controlled files is generally a bad idea, and I do not
>> recommend it. I am only doing so in this case because fedora-review does
>> not work at all without these changes. I understand that my changes will
>> be overwritten the next time a mock-core-configs or fedora-review update
>> is installed.
>
> Skip steps 1 and 2. They are unnecessary. Step 3 is all you need.
Would that be a temporary solution for Copr as well? I mean for all
rawhide builds? I quite miss not having fedora-review available there.
-- Sandro
_______________________________________________
devel mailing list -- devel(a)lists.fedoraproject.org
To unsubscribe send an email to devel-leave(a)lists.fedoraproject.org
Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
8:22 a.m.
On Tue Jul 18, 2023 at 12:38 +0200, Jakub Kadlcik wrote:
Hello Jerry,
I proposed a workaround a few days ago
https://pagure.io/FedoraReview/pull-request/485
but your patch looks like a proper fix. I'll try it and merge to the
fedora-review codebase.
Does anybody know what was the purpose of --resolve and if it will be
no problem when we remove it?
--requires --resolve resolves the entire dependency tree of a package.
--requires just prints the direct dependencies that are specified in the
RPM metadata.
I don't know what this code is used for,
but I don't think simply removing --resolve is the right solution.
--
Maxwell G (@gotmax23)
Pronouns: He/They
8:27 a.m.
On Tue, Jul 18, 2023, 15:22 Maxwell G <maxwell(a)gtmx.me> wrote:
On Tue Jul 18, 2023 at 12:38 +0200, Jakub Kadlcik wrote:
> Hello Jerry,
> I proposed a workaround a few days ago
> https://pagure.io/FedoraReview/pull-request/485
>
> but your patch looks like a proper fix. I'll try it and merge to the
> fedora-review codebase.
>
> Does anybody know what was the purpose of --resolve and if it will be
> no problem when we remove it?
--requires --resolve resolves the entire dependency tree of a package.
--requires just prints the direct dependencies that are specified in the
RPM metadata.
I don't know what this code is used for,
but I don't think simply removing --resolve is the right solution.
Is it though? I assume you're thinking of "--recursive". As far as I know,
"--requires --resolve" force resolution of virtual provides instead. I
don't think removing "--resolve" is the correct solution for this case.
For example, the check if a package depends on something that's deprecated
(i.e. "Provides: deprecated ()") would need to resolve and check the actual
package dependencies, not only virtual provides.
Fabio
--
Maxwell G (@gotmax23)
Pronouns: He/They
_______________________________________________
devel mailing list -- devel(a)lists.fedoraproject.org
To unsubscribe send an email to devel-leave(a)lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it:
https://pagure.io/fedora-infrastructure/new_issue
9:26 a.m.
On Tue Jul 18, 2023 at 15:27 +0200, Fabio Valentini wrote:
On Tue, Jul 18, 2023, 15:22 Maxwell G <maxwell(a)gtmx.me> wrote:
> On Tue Jul 18, 2023 at 12:38 +0200, Jakub Kadlcik wrote:
> > Hello Jerry,
> > I proposed a workaround a few days ago
> > https://pagure.io/FedoraReview/pull-request/485
> >
> > but your patch looks like a proper fix. I'll try it and merge to the
> > fedora-review codebase.
> >
> > Does anybody know what was the purpose of --resolve and if it will be
> > no problem when we remove it?
>
> --requires --resolve resolves the entire dependency tree of a package.
> --requires just prints the direct dependencies that are specified in the
> RPM metadata.
> I don't know what this code is used for,
> but I don't think simply removing --resolve is the right solution.
>
Is it though? I assume you're thinking of "--recursive". As far as I know,
"--requires --resolve" force resolution of virtual provides instead. I
don't think removing "--resolve" is the correct solution for this case.
For example, the check if a package depends on something that's deprecated
(i.e. "Provides: deprecated ()") would need to resolve and check the actual
package dependencies, not only virtual provides.
Fabio
Indeed. You're right!
--
Maxwell G (@gotmax23)
Pronouns: He/They
12:16 p.m.
On Tue, Jul 18, 2023 at 7:28 AM Fabio Valentini <decathorpe(a)gmail.com> wrote:
On Tue, Jul 18, 2023, 15:22 Maxwell G <maxwell(a)gtmx.me> wrote:
> --requires --resolve resolves the entire dependency tree of a package.
> --requires just prints the direct dependencies that are specified in the
> RPM metadata.
> I don't know what this code is used for,
> but I don't think simply removing --resolve is the right solution.
Is it though? I assume you're thinking of "--recursive". As far as I know,
"--requires --resolve" force resolution of virtual provides instead. I don't
think removing "--resolve" is the correct solution for this case.
For example, the check if a package depends on something that's deprecated (i.e.
"Provides: deprecated ()") would need to resolve and check the actual package
dependencies, not only virtual provides.
That's the reason for the second change I proposed, namely changing
line 97 from:
name = line.rsplit(".", 2)[0]
to:
name = resolve_one(line)[0].rsplit(".", 2)[0]
The `resolve_one` function resolves the dependencies one at a time, to
compensate for unavailability of the --resolve option. On second
thought, though, perhaps that code should be:
for arg in resolve_one(line):
name = arg.rsplit(".", 2)[0]
deps.append(name.rsplit("-", 2)[0])
--
Jerry James
http://www.jamezone.org/
12:17 p.m.
On Tue, 18 Jul 2023 15:27:01 +0200
Fabio Valentini <decathorpe(a)gmail.com> wrote:
On Tue, Jul 18, 2023, 15:22 Maxwell G <maxwell(a)gtmx.me> wrote:
> On Tue Jul 18, 2023 at 12:38 +0200, Jakub Kadlcik wrote:
> > Hello Jerry,
> > I proposed a workaround a few days ago
> > https://pagure.io/FedoraReview/pull-request/485
> >
> > but your patch looks like a proper fix. I'll try it and merge to
> > the fedora-review codebase.
> >
> > Does anybody know what was the purpose of --resolve and if it
> > will be no problem when we remove it?
>
> --requires --resolve resolves the entire dependency tree of a
> package. --requires just prints the direct dependencies that are
> specified in the RPM metadata.
> I don't know what this code is used for,
> but I don't think simply removing --resolve is the right solution.
>
Is it though? I assume you're thinking of "--recursive". As far as I
know, "--requires --resolve" force resolution of virtual provides
instead. I don't think removing "--resolve" is the correct solution
for this case.
For example, the check if a package depends on something that's
deprecated (i.e. "Provides: deprecated ()") would need to resolve and
check the actual package dependencies, not only virtual provides.
I have a script that uses --requires, --resolve and --recursive all at
the same time:
...
dnf repoquery \
--quiet \
--releasever=$RELEASE_VER \
$EXTRA_REPO_SPEC \
--disablerepo=\* \
--enablerepo=$LOCAL_SOURCE_REPO \
--enablerepo=$LOCAL_BINARY_REPO \
--enablerepo=$BASE_BINARY_REPO \
--arch=${BINARY_ARCHLIST},noarch,src \
--forcearch=$FORCE_ARCH \
--qf ' %{name}' \
--requires --resolve --recursive $BUILD_GROUP $LOCAL_PACKAGE_LIST
...
I use it to work out all of the dependencies (build and run time) for
all of the packages in a local repo so that I can mirror them locally.
Regards, Paul.
1:59 a.m.
On pondělí 17. července 2023 20:39:11 CEST Jerry James wrote:
On Mon, Jul 17, 2023 at 10:54 AM Jerry James
<loganjerry(a)gmail.com> wrote:
> Like many of you, I have been quite inconvenienced because of
> dnf5-related breakage of fedora-review. I've been monkeying with it
> today and finally got a successful run of fedora-review after making
> the following changes [*].
>
> 1. Edit /etc/mock/templates/fedora-rawhide.tpl. Change:
>
> config_opts['package_manager'] = 'dnf'
>
> to:
>
> config_opts['package_manager'] = 'dnf5'
>
> 2. Run 'mock -r fedora-rawhide-x86_64 --scrub=bootstrap'
>
> 3. Edit /usr/lib/python3.11/site-packages/FedoraReview/deps.py. Change line
> 83 from:
>
> "dnf repoquery -q -C --requires --resolve " + "
".join(list(set(pkgs))),
>
> to:
>
> "dnf repoquery -q -C --requires " + "
".join(list(set(pkgs))),
>
> Change line 97 from:
>
> name = line.rsplit(".", 2)[0]
>
> to:
>
> name = resolve_one(line)[0].rsplit(".", 2)[0]
>
> Change line 286 from:
>
> "dnf repoquery -C -l " + " ".join(list(set(pkgs))),
>
> to:
>
> "dnf repoquery --files " + " ".join(list(set(pkgs))),
>
> Other changes may be needed.
>
> [*] Altering rpm-controlled files is generally a bad idea, and I do not
> recommend it. I am only doing so in this case because fedora-review does
> not work at all without these changes. I understand that my changes will
> be overwritten the next time a mock-core-configs or fedora-review update
> is installed.
Skip steps 1 and 2. They are unnecessary. Step 3 is all you need.
Note that the step 1 is going to happen soon for everyone:
https://github.com/rpm-software-management/mock/issues/1147
Don't forget to run 2 with Mock v5+ (once released).
Pavel
--
Jerry James
http://www .jamezone.org/
_______________________________________________
devel mailing list -- devel(a)lists.fedoraproject.org
To unsubscribe send an email to devel-leave(a)lists.fedoraproject.org
Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
9:47 p.m.
Hi all,
On Mon, Jul 17, 2023 at 10:54:43AM -0600, Jerry James wrote:
Like many of you, I have been quite inconvenienced because of
dnf5-related breakage of fedora-review. I've been monkeying with it
today and finally got a successful run of fedora-review after making
the following changes [*].
I'm happy (and relieved) to say that a fixed fedora-review is ready for
testing:
https://bodhi.fedoraproject.org/updates/?search=&packages=fedora-revi...
This uses Jakub Kadlcik's initial PR to use dnf-3 instead of dnf, so we
don't necessarily commit ourselves to using DNF 5 until the we know for
sure if Fedora 39 will ship with DNF 5 or not.
Thanks also to Benjamin A. Beasley, Miro Hrončok, Benson Muite, Jitka
Plesnikova, Pavel Raiskup, and Sérgio M. Basto for contributing changes
shipped in this release.
0.10.0 was supposed to have gone out 3 months ago, but blocked by
changes in setuptools/distutils causing our release script to generate
an incomplete tarball. I've done a more thorough fix that will hopefully
hold until we rewrite our build process be PEP 517 compliant for the
next release.
Once this lands in F38, Fedora Review Service should be fixed, unless
I'm missing something.
Best regards,
--
Michel Alexandre Salim
identities: https://keyoxide.org/5dce2e7e9c3b1cffd335c1d78b229d2f7ccc04f2
4:40 p.m.
Thank you very much Michel for going through the release.
It couldn't be easy.
There is a reported bug in Bodhi, so it will need some minor fixups
but we are close. Really looking forward to it.
Jakub
On Tue, Jul 25, 2023 at 4:48 AM Michel Alexandre Salim
<salimma(a)fedoraproject.org> wrote:
Hi all,
On Mon, Jul 17, 2023 at 10:54:43AM -0600, Jerry James wrote:
> Like many of you, I have been quite inconvenienced because of
> dnf5-related breakage of fedora-review. I've been monkeying with it
> today and finally got a successful run of fedora-review after making
> the following changes [*].
>
I'm happy (and relieved) to say that a fixed fedora-review is ready for
testing:
https://bodhi.fedoraproject.org/updates/?search=&packages=fedora-revi...
This uses Jakub Kadlcik's initial PR to use dnf-3 instead of dnf, so we
don't necessarily commit ourselves to using DNF 5 until the we know for
sure if Fedora 39 will ship with DNF 5 or not.
Thanks also to Benjamin A. Beasley, Miro Hrončok, Benson Muite, Jitka
Plesnikova, Pavel Raiskup, and Sérgio M. Basto for contributing changes
shipped in this release.
0.10.0 was supposed to have gone out 3 months ago, but blocked by
changes in setuptools/distutils causing our release script to generate
an incomplete tarball. I've done a more thorough fix that will hopefully
hold until we rewrite our build process be PEP 517 compliant for the
next release.
Once this lands in F38, Fedora Review Service should be fixed, unless
I'm missing something.
Best regards,
--
Michel Alexandre Salim
identities: https://keyoxide.org/5dce2e7e9c3b1cffd335c1d78b229d2f7ccc04f2
_______________________________________________
devel mailing list -- devel(a)lists.fedoraproject.org
To unsubscribe send an email to devel-leave(a)lists.fedoraproject.org
Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
6:34 p.m.
On 25-07-2023 04:47, Michel Alexandre Salim wrote:
Once this lands in F38, Fedora Review Service should be fixed,
unless
I'm missing something.
First of all, thanks for bringing fedora-review back. I rely on it quite
a bit reviewing my own packages as well as for official reviews.
I noticed that in f39 builds in Copr the directory containing the
results is now named after the package. Comparing that to the
"traditional" fedora-review directory in f38 builds, I miss the
`licensecheck.txt` file.
The contents of the fedora-review directory ($PACKAGE_NAME) in f39 look
more alike to a local fedora-review, which is fine. But
`licensecheck.txt` is invaluable for checking licenses of generated
files. Just now I finished a review using the f38 build, which detected
two additional licenses in generated files, that went unnoticed by the
submitter.
Can `licensecheck.txt` be added back to f39 fedora-review runs, please?
-- Sandro
10:36 a.m.
Hello Sandro,
I noticed that in f39 builds in Copr the directory containing the
results is now named after the package. Comparing that to the
"traditional" fedora-review directory in f38 builds, I miss the
`licensecheck.txt` file.
It suddenly started happening and I don't know what is to blame yet.
You can follow
https://github.com/FrostyX/fedora-review-service/issues/28
https://pagure.io/FedoraReview/issue/486
I plan to work on it as soon as I can.
Jakub
On Wed, Jul 26, 2023 at 1:34 AM Sandro <lists(a)penguinpee.nl> wrote:
>
> On 25-07-2023 04:47, Michel Alexandre Salim wrote:
> > Once this lands in F38, Fedora Review Service should be fixed, unless
> > I'm missing something.
>
> First of all, thanks for bringing fedora-review back. I rely on it quite
> a bit reviewing my own packages as well as for official reviews.
>
I noticed that in f39 builds in Copr the directory containing the
results is now named after the package. Comparing that to the
"traditional" fedora-review directory in f38 builds, I miss the
`licensecheck.txt` file.
>
> The contents of the fedora-review directory ($PACKAGE_NAME) in f39 look
> more alike to a local fedora-review, which is fine. But
> `licensecheck.txt` is invaluable for checking licenses of generated
> files. Just now I finished a review using the f38 build, which detected
> two additional licenses in generated files, that went unnoticed by the
> submitter.
>
> Can `licensecheck.txt` be added back to f39 fedora-review runs, please?
>
> -- Sandro
> _______________________________________________
> devel mailing list -- devel(a)lists.fedoraproject.org
> To unsubscribe send an email to devel-leave(a)lists.fedoraproject.org
> Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
> Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
12:50 p.m.
On Wed, Jul 26, 2023 at 05:36:04PM +0200, Jakub Kadlcik wrote:
Hello Sandro,
> I noticed that in f39 builds in Copr the directory containing the
> results is now named after the package. Comparing that to the
> "traditional" fedora-review directory in f38 builds, I miss the
> `licensecheck.txt` file.
It suddenly started happening and I don't know what is to blame yet.
You can follow
https://github.com/FrostyX/fedora-review-service/issues/28
https://pagure.io/FedoraReview/issue/486
I plan to work on it as soon as I can.
Jakub
Thanks for your work on this Jakub! I'll cut another release once this
is done.
Will try to work on modernizing the build system more, but I'll probably
not get to it for a couple of weeks - need to deal with my Rawhide
FTBFSes first.
Cheers,
--
Michel Alexandre Salim
identities: https://keyoxide.org/5dce2e7e9c3b1cffd335c1d78b229d2f7ccc04f2
4:18 p.m.
On 26-07-2023 17:36, Jakub Kadlcik wrote:
Hello Sandro,
> I noticed that in f39 builds in Copr the directory containing the
> results is now named after the package. Comparing that to the
> "traditional" fedora-review directory in f38 builds, I miss the
> `licensecheck.txt` file.
It suddenly started happening and I don't know what is to blame yet.
You can follow
https://github.com/FrostyX/fedora-review-service/issues/28
https://pagure.io/FedoraReview/issue/486
I plan to work on it as soon as I can.
Thank you Jakub. I'll be following along. It's not all that urgent by
any means as long as the file is still there in the stable branches.
-- Sandro
12:48 p.m.
On Mon, Jul 24, 2023 at 09:47:32PM -0500, Michel Alexandre Salim wrote:
Hi all,
On Mon, Jul 17, 2023 at 10:54:43AM -0600, Jerry James wrote:
> Like many of you, I have been quite inconvenienced because of
> dnf5-related breakage of fedora-review. I've been monkeying with it
> today and finally got a successful run of fedora-review after making
> the following changes [*].
>
I'm happy (and relieved) to say that a fixed fedora-review is ready for
testing:
https://bodhi.fedoraproject.org/updates/?search=&packages=fedora-revi...
fedora-review-0.10.0-1.fc3{7,8} had shebang issues, for those who are
testing please retest fedora-review-0.10.0-2.fc3{7,8} that I just posted
to fix this, thanks!
Turns out we never touched the shebangs and they still had Python
2-isms, and %{py3_shebang_fix} just adds a duplicate -sP which is not
needed -- it's the -tt that was the issue.
--
Michel Alexandre Salim
identities: https://keyoxide.org/5dce2e7e9c3b1cffd335c1d78b229d2f7ccc04f2
300
days inactive
309
days old
16 comments
8 participants
participants (8)
-
Fabio Valentini -
Jakub Kadlcik -
Jerry James -
Maxwell G -
Michel Alexandre Salim -
Paul Howarth -
Pavel Raiskup -
Sandro