Re: Staled PRs at https://src.fedoraproject.org/rpms/

[Chris Kelley]

>
> Is there a way to merge PR lists from multiple packages into a single
> backlog?
>
I don't know about Pagure, but you can make bespoke packager dashboards to
show whatever combination of packages/packagers/groups you like :-)
https://packager-dashboard.fedoraproject.org/custom

Cheers,

Chris

On Thu, 25 Jan 2024 at 18:18, Florian Weimer  wrote:

> * Miroslav Suchý:
>
> > I want to point to nice feature of Pagure - it can show you PR where
> > you can act on:
> >
> >
> https://src.fedoraproject.org/user/msuchy/requests?type=actionable=open
> >
> > (your account icon -> My Pull Request -> PR I can act on)
> >
> > Please check it, maybe you will discover some PR that is waiting on
> > your feedback and you are not aware of it.
>
> Is there a way to merge PR lists from multiple packages into a single
> backlog?  We try to keep an eye on the bug list for our components, but
> that only works (to some extent …) because Bugzilla allows us to
> consolidate everything into a single list.  If we had this for PRs, it
> would really help, I think.
>
> Thanks,
> Florian
> --
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> 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: Potential (security) issue for beginners/non-experts when release is End Of Life: Fedora doesn’t consider the behavior of beginners/non-experts sufficiently

[Chris Kelley]

You can lead a horse to water but you can't make it drink:
https://fedoraproject.org/workstation/

Each version is updated for approximately 13 months, and upgrades between
> versions are quick and easy
>

It's right next to the download button :-) Likewise here:
https://docs.fedoraproject.org/en-US/project/#_first

Users are gonna user, if someone wants to not read any of the docs about
what Fedora is, hit that button and put F38 on a machine and run it for 10
years they will. We can only be very clear about what is in support and
what is not, and I think the people responsible for that do a great job.
For what it's worth, I know there are Fedora devs out there running EOL
versions of Fedora, so it is not just new users doing this. Not everyone
has the same "upgrade first; ask questions later" attitude to OS updates I
have it would seem ;-)

I seem to recall a thread from a few months back discussing how a machine
can work out for itself whether it is EOL (or about to be) but I can't seem
to find it. Hopefully someone will be able to elaborate on that part of
your discussion because that reminder would be helpful.

Cheers,

Chris

On Fri, 11 Aug 2023 at 15:25, Christopher Klooz  wrote:

> The below is a duplicate from discourse (I suggest to focus the discussion
> there):
> https://discussion.fedoraproject.org/t/potential-security-issue-for-beginners-non-experts-when-release-is-end-of-life-fedora-doesnt-consider-the-behavior-of-beginners-non-experts-sufficiently/87311/1
>
> I just became aware of another topic from a user who elaborates their
> problem and “by the way” mentions to use Fedora 35. The user provides this
> information in order to give an overview of his system configuration and
> thus does not consider this as part of the problem.
>
> I have seen many of these topics over time, and I guess there are many
> more users out there who use obsoleted Fedora releases (the less
> experienced they are, the more they are likely to end up with obsoleted
> releases, and the less likely they are to end up on ask.fedora so that we
> can make them aware).
>
> We officially want to make Fedora usable for average users (or beginners),
> but many (if not most) average users deploy their systems in a “fire and
> forget” manner: once they made it work, they maybe enable updates and such
> and then they no longer care if everything *seems* to work fine.
>
> I assume that many of these users are not aware that they no longer
> receive updates, which can be dangerous.
>
> First of all, I don’t use my Fedora installations until their *end of
> life*, so I don’t know if we have any means in place that shall make
> users aware once their release reaches *end of life*?
>
> *If not*, does it make sense to add some means?
>
> If we promote Fedora for average users/beginners, we have to also consider
> their behavior.
>
> On one hand, it would be cool to make them a month or two before *end of
> life* aware with a warning message that automatically forwards them to
> the GUI upgrade with a click and also allows them to click “warn me again
> tomorrow” or such.
>
> On the other hand, more easy to implement solutions like that of Tails
> could be sufficient solutions, too: once the Tails ISO image is started
> (live system) and online, it checks if there are new images available. If
> so, it opens a warning window that makes the user aware that this image
> should no longer be used and shows a link and a short elaboration of how to
> get the new one.
>
> Of course there are alternatives, too. Even an apparent bullet point on
> getfedora.org would be a good first step (we could link it to Fedora
> being always up to date with most modern technologies, to link it to
> something positive). In either case, I think a short discussion of this
> makes sense.
>
> This also applies to all Spins.
>
> Best,
> Chris
>
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> 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: dnf conflict in rawhide Docker container in GitHub Action

[Chris Kelley]

I see, thanks for the advice! I made that change and job's a good 'un.

Cheers,

Chris

On Thu, 10 Aug 2023 at 20:38, Adam Williamson 
wrote:

> On Thu, 2023-08-10 at 19:07 +0000, Chris Kelley wrote:
> > Hello all,
> >
> > I have a GitHub Action (
> https://github.com/dogtagpki/jss/actions/runs/5810230552/job/15794978022)
> that fails due to a conflict between dnf and dnf5 when using the rawhide
> docker image. I have been trying to keep up with the dnf/dnf5 revert story,
> but I may have missed something about the current state of
> affairs/expectations around it working without issue. I am not sure to whom
> I should raise this issue, any suggestions welcome - thanks!
>
> Not sure what the specific issue is here, but in general, we recommend
> against pulling from the Docker registry, as it is not updated very
> often. It's much better to pull from registry.fedoraproject.org or
> quay.io , as those are updated with every Rawhide compose.
> --
> Adam Williamson (he/him/his)
> Fedora QA
> Fedora Chat: @adamwill:fedora.im | Mastodon: @ad...@fosstodon.org
> https://www.happyassassin.net
>
>
>
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
> Do not reply to spam, report it:
> https://pagure.io/fedora-infrastructure/new_issue
>
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

dnf conflict in rawhide Docker container in GitHub Action

[Chris Kelley]

Hello all,

I have a GitHub Action 
(https://github.com/dogtagpki/jss/actions/runs/5810230552/job/15794978022) that 
fails due to a conflict between dnf and dnf5 when using the rawhide docker 
image. I have been trying to keep up with the dnf/dnf5 revert story, but I may 
have missed something about the current state of affairs/expectations around it 
working without issue. I am not sure to whom I should raise this issue, any 
suggestions welcome - thanks!

Cheers,

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

[Chris Kelley]

Mine just failed with this, which doesn't look great:

  File "", line 225, in makedirs
OSError: [Errno 28] No space left on device:
'/var/tmp/koji/tasks/996/102220996/local/work'


On Fri, 16 Jun 2023 at 15:31, Ralf Corsépius  wrote:

> Hi,
>
> I am facing (seemingly non-deterministic) FTBSes in builds, which
> flawlessly build local mocks.
>
> On top of that, a couple of minutes ago, koji reported:
>
>   File "/usr/lib/python3.11/site-packages/koji/daemon.py", line 1492, in
> runTask
>  response = (handler.run(),)
>  ^
>File "/usr/lib/python3.11/site-packages/koji/tasks.py", line 335, in run
>  return koji.util.call_with_argcheck(self.handler, self.params,
> self.opts)
> ^^ ...
>
> WTH is going on?
>
> Ralf
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> 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: Review requests: gtksourceviewmm3, mingw-qt6-qtlocation

[Chris Kelley]

Hi Sandro,

I see someone took gtksourceviewmm3, can you swap for apache-logging-parent
please? https://bugzilla.redhat.com/show_bug.cgi?id=2214834
Also unretirement; bump to latest upstream version. It is a parent POM for
metadata so it is a simple one.

Cheers,

Chris

On Thu, 15 Jun 2023 at 08:10, Sandro Mani  wrote:

> Hi
>
> I'd appreciate a review of the following packages:
>
> https://bugzilla.redhat.com/show_bug.cgi?id=2215251 - gtksourceviewmm3 -
> Review to revive retired package, which I need as a dependency for
> gimagereader
>
> https://bugzilla.redhat.com/show_bug.cgi?id=2211959 -
> mingw-qt6-qtlocation - Review to revive retired package, this qt module
> was dropped upstream in the qt-6.3.x series, but re-introduced in qt-6.5.1
>
> Happy to review in exchange.
>
> Thanks
> Sandro
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
> Do not reply to spam, report it:
> https://pagure.io/fedora-infrastructure/new_issue
>
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
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: Changing the License tag of python-rpm-generators from GPLv2+ to a monstrosity

[Chris Kelley]

How fun! Thanks for the links and explanation.

On Fri, 5 May 2023 at 16:09, Miro Hrončok  wrote:

> On 05. 05. 23 16:28, Mamoru TASAKA wrote:
> > Chris Kelley wrote on 2023/05/05 22:55:
> >> As a purely logical expression, this simplifies to "GPL-2.0-or-later AND
> >> LGPL-2.1-or-later". Is that sort of simplification not allowed?
> >>
> >
> > This is no longer allowed:
> >
> https://docs.fedoraproject.org/en-US/legal/license-field/#_no_effective_license_analysis
>
> Also
>
> https://docs.fedoraproject.org/en-US/legal/license-field/#_combined_disjunctive_and_conjunctive_license_expressions
> which says:
>
> """
> The license expression must reflect the disjunctive license choice even if
> one
> or both of the license identifiers in the OR expression also appear
> separately
> in the composite license expression.
>
> ...
>
> License: (GPL-3.0-or-later OR MPL-1.1) AND GPL-3.0-or-later AND MIT
>
> Here we repeat GPL-3.0-or-later because for one binary component it
> appears as
> part of an OR subexpression. That is, OR expressions must be treated as
> though
> they were a single distinct license.
> """
>
> --
> Miro Hrončok
> --
> Phone: +420777974800
> IRC: mhroncok
>
>
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Changing the License tag of python-rpm-generators from GPLv2+ to a monstrosity

[Chris Kelley]

As a purely logical expression, this simplifies to "GPL-2.0-or-later AND
LGPL-2.1-or-later". Is that sort of simplification not allowed?



On Fri, 5 May 2023, 13:20 Miro Hrončok,  wrote:

> python-rpm-generators License tag changes from GPLv2+ to:
>
> GPL-2.0-or-later AND LGPL-2.1-or-later AND
> (LicenseRef-Fedora-Public-Domain OR
> LGPL-2.1-or-later OR GPL-2.0-or-later)
>
> https://src.fedoraproject.org/rpms/python-rpm-generators/pull-request/67
>
> Funny thing is that the "(LicenseRef-Fedora-Public-Domain OR
> LGPL-2.1-or-later
> OR GPL-2.0-or-later)" thing was originally chosen to keep the License tag
> of
> the package simple while allowing others to grab the code from it without
> obligations :/
>
> --
> Miro Hrončok
> --
> Phone: +420777974800
> IRC: mhroncok
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
> Do not reply to spam, report it:
> https://pagure.io/fedora-infrastructure/new_issue
>
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Orphaning despite having maintainers?

[Chris Kelley]

>
> Right now dogtag-pki is off the hook, nothing shows that it is
> 'orphan-impacted'. However, for ecj I still get that and it shows
> explicit dependency on java-1.8.0-openjdk as well while ecj has
> following list of dependencies:
>
dogtag-pki spec explicitly depends on
java-17-openjdk-devel/java-17-openjdk-headless and is no longer showing as
orphan-impacted (it was yesterday though?).
The rest of our java packages do not explicitly depend on any JDK, yet show
as orphan-impacted directly depending on java-1.8.0-openjdk, which
according to the spec is not the case.

On Thu, 27 Apr 2023 at 11:34, Alexander Bokovoy  wrote:

> On to, 27 huhti 2023, Miro Hrončok wrote:
> >On 27. 04. 23 12:19, Alexander Bokovoy wrote:
> >>The graph in the packager dashboard is showing that resteasy directly
> >>depends on java-1.8.0-openjdk which is not true.
> >
> >resteasy (maintained by: cfu, cipherboy, ckelley, edewata, jmagne,
> >mfargett, mharmsen, vakwetu)
> >pki-resteasy-client-3.0.26-23.fc38.noarch requires java-1.8.0-headless
> >= 1:1.8.0.362.b09-2.fc38
> >pki-resteasy-core-3.0.26-23.fc38.noarch requires java-1.8.0-headless =
> >1:1.8.0.362.b09-2.fc38
> >pki-resteasy-jackson2-provider-3.0.26-23.fc38.noarch requires
> >java-1.8.0-headless = 1:1.8.0.362.b09-2.fc38
>
> That is not what is in the binary package (spec file does not even have
> that dependency expression directly).
>
> Binary package https://koji.fedoraproject.org/koji/rpminfo?rpmID=33490808
> has the following Requires statement:
>
> (java-headless or java-17-headless or java-11-headless or
> java-1.8.0-headless)
>
> This library is usable with any supported JDK build.
>
> --
> / Alexander Bokovoy
> Sr. Principal Software Engineer
> Security / Identity Management Engineering
> Red Hat Limited, Finland
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> 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: Orphaning despite having maintainers?

[Chris Kelley]

Apologies, I forgot to say I was getting this info from the Packager
Dashboard:
https://packager-dashboard.fedoraproject.org/dashboard?users=ckelley

On Wed, 26 Apr 2023 at 22:17, Kevin Fenzi  wrote:

> On Wed, Apr 26, 2023 at 07:23:10PM +0100, Chris Kelley wrote:
> > One thing I still don't understand is why all of our java packages are
> > orphan-affected by the orphaning of java-1.8.0-openjdk. None of them
> > BuildRequires a JDK, and the source/target/release values for the
> packages
> > range from 6 to 17. Can anyone shed some light on this please?
>
> What do you mean by 'orphan-affected'?
>
> I only see java-1.8.0-openjdk orphaned... what are the other packages
> you see and how are they affected?
>
> kevin
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> 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: Orphaning despite having maintainers?

[Chris Kelley]

One thing I still don't understand is why all of our java packages are
orphan-affected by the orphaning of java-1.8.0-openjdk. None of them
BuildRequires a JDK, and the source/target/release values for the packages
range from 6 to 17. Can anyone shed some light on this please?

Cheers,

Chris

On Wed, 26 Apr 2023 at 14:56, Gary Buhrmaster 
wrote:

> On Wed, Apr 26, 2023 at 9:04 AM Alexander Bokovoy 
> wrote:
> >
> > Hi,
> >
> > This morning I woke up to find that packages I maintain were orphaned
> > out of blue. Nobody contacted the maintainers, nobody raised any tickets
> > to releng, as far as I can see. Yet, releng ran the orphaning from what
> > I saw in a few bugs.
> >
> > What is happening? Who and how made those decisions?
>
> Removing inactive packagers (who have not
> made any package updates, nor responded to
> direct emails, for an extended period are removed
> from the packagers group as part of good
> security hygiene per:
>
> https://docs.fedoraproject.org/en-US/fesco/Policy_for_inactive_packagers/
>
> It is an artifact of that fact that in Fedora, packages
> have only one main admin, and when that packager
> is removed from the packagers group, their packages
> get orphaned (there is no automated promotion,
> and nor should there be, to select one of the other
> maintainers, as that would also imply other
> responsibilities that one might not want).  You (or
> other interested packager) can go to:
>   https://src.fedoraproject.org
> and "Take" that packager to become the new
> main admin/owner.
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> 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: Dogtag-pki is not installable on F38/Rawhide because it fails the GPG check even if you attempt to skip the check

[Chris Kelley]

Thanks all for the input.

Maybe there was some issue in COPR and/or rawhide at the
> time those packages were signed which caused them to fail
> verification now?  It may be worth trying to rebuild them to
> see if they can be properly signed?
>
I resubmitted the affected packages and now everything works - thanks for
the suggestion!

On Thu, 9 Mar 2023 at 20:42, Todd Zullinger  wrote:

> Hi,
>
> Chris Kelley wrote:
> > TL;DR dogtag-pki is not installable on F38/Rawhide because
> > it fails the GPG check (F37 and prior are fine), even if
> > --nogpgcheck is specified, and I don't understand why.
> >
> > 1) Why does the key not work?
> > 2) Why does --nogpgcheck not work?
>
> It seems like it must be related to the issues reported
> recently with respect to changes in the rpm signature
> backend & stricter crypto-policies, but I don't see _why_
> they are failing.  They don't appear to be using SHA1 or DSA
> algorithms. :/
>
> I think it is suspicious that the three packages which fail
> to verify are the three which have not been built within the
> past week or so.  Attempting an install in a rawhide
> container from today, then checking the package cache after
> it fails simply reports the rpm signature as BAD.
>
> [root@8f5fc423842b /]# rpm -Kvv
> dogtag-jss-5.4.0-0.1.alpha1.20230227143934UTC.0c4012e6.fc39.x86_64.rpm
> D: loading keyring from rpmdb
> D: PRAGMA secure_delete = OFF: 0
> D: PRAGMA case_sensitive_like = ON: 0
> D:  read h# 150
> Header SHA256 digest: OK
> Header SHA1 digest: OK
> D: added key gpg-pubkey-18b8e74c-62f2920f to keyring
> D:  read h# 160
> Header SHA256 digest: OK
> Header SHA1 digest: OK
> D: added key gpg-pubkey-20de059c-5c7ffdbe to keyring
> /var/cache/dnf/copr:copr.fedorainfracloud.org:
> group_pki:master-7092f479845efeda/packages/dogtag-jss-5.4.0-0.1.alpha1.20230227143934UTC.0c4012e6.fc39.x86_64.rpm:
> Header V4 RSA/SHA256 Signature, key ID 20de059c: BAD
> Header SHA256 digest: OK
> Header SHA1 digest: OK
> Payload SHA256 digest: OK
> V4 RSA/SHA256 Signature, key ID 20de059c: BAD
> MD5 digest: OK
>
> Maybe there was some issue in COPR and/or rawhide at the
> time those packages were signed which caused them to fail
> verification now?  It may be worth trying to rebuild them to
> see if they can be properly signed?
>
> --
> Todd
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> 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: Degradated modules support

[Chris Kelley]

>
> The above is done by about 2.5 people (counting multiple volunteers as 1
> person). This goes up at times and goes down but for the last year has been
> about that.

An aside - how/where does one volunteer to help releng?

On Thu, 9 Mar 2023 at 21:22, Stephen Smoogen  wrote:

>
>
> On Wed, 8 Mar 2023 at 10:12, Petr Pisar  wrote:
>
>> For module maintainers, module users, and flatpak maintainers:
>>
>> Fedora infrustructure has long-standing problems with supporting modules.
>>
>> Namely, MBS is unable to build modules with deep dependencies
>>  and Bodhi is unable to
>> accept
>> multicontext modules .
>>
>> This results into inability to support affected modules. E.g. it's
>> impossible
>> to build perl-CGI:5.54 for Fedora 39, and it's impossible to update
>> perl-Date-Manip:6.86 in stable Fedoras.
>>
>> Because nobody has tried to tackle these infrastructure deficiencies,
>> module
>> maintainers have hard times to support the modules, and as a result users
>> can
>
> expect dropping of numerous modules from Fedora. If there remain no
>> modules,
>> Fedora project might consider removing Modularity from Fedora
>> infrastructure.
>>
>>
> Most of the work needed to get these worked on successfully requires:
> 1. Nothing being higher priority for Fedora Infra, Fedora Releng, Red Hat
> MBS team, and other parts of the build system that this ties into.
> 2. Schedules being aligned between the 3-4 teams that this is a priority
> to work on for a 4 to 6 week period.
>
> Most of the Fedora Infrastructure and Releng work is tied up in:
> 1. getting a daily compose out the door (Monday through Sunday).
> 2. getting a release out in some form (beta/final) every 12 weeks.
> 3. keeping 40+ services over a couple hundred systems working to meet
> 1&&2.
>
> The above is done by about 2.5 people (counting multiple volunteers as 1
> person). This goes up at times and goes down but for the last year has been
> about that.
>
> I don't think this is unique to Fedora Infra/Releng. The teams which have
> supported MBS, Koji, PDC, ODCS, etc have their own goals they need to
> accomplish and it is hard to get their time to sync up with the usual short
> periods that Fedora Infra can 'slow-down' (usually after a release).
>
> I don't have any easy solutions on how to fix this. Even 'turn off
> modularity' isn't probably easy. Too many services are tied into the Fedora
> build system framework in a way that expects something from other parts
> even if they don't seem connected. You turn off one service, and you find
> out that 3 other things don't work weeks later because they expected some
> sort of 'heart-beat' or some other message.
>
>
>
>> That could also affect seemingly unrelated parts of Fedora like Flatpaks
>> whose build process is based on modularity.
>>
>> -- Petr
>> ___
>> devel mailing list -- devel@lists.fedoraproject.org
>> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
>> Fedora Code of Conduct:
>> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
>> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
>> List Archives:
>> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
>> Do not reply to spam, report it:
>> https://pagure.io/fedora-infrastructure/new_issue
>>
>
>
> --
> Stephen Smoogen, Red Hat Automotive
> Let us be kind to one another, for most of us are fighting a hard battle.
> -- Ian MacClaren
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
> Do not reply to spam, report it:
> https://pagure.io/fedora-infrastructure/new_issue
>
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Dogtag-pki is not installable on F38/Rawhide because it fails the GPG check even if you attempt to skip the check

[Chris Kelley]

Hi all!

TL;DR dogtag-pki is not installable on F38/Rawhide because it fails the GPG 
check (F37 and prior are fine), even if --nogpgcheck is specified, and I don't 
understand why.
1) Why does the key not work?
2) Why does --nogpgcheck not work?

The error I get is:

[root@fedora ~]# dnf copr enable @pki/master; dnf install dogtag-pki

Importing GPG key 0x20DE059C:
 Userid : "@pki_master (None) <@pki#mas...@copr.fedorahosted.org>"
 Fingerprint: B023 2014 243E 33DA CFBA 5269 94CF 0B2D 20DE 059C
 From   : 
https://download.copr.fedorainfracloud.org/results/@pki/master/pubkey.gpg
Is this ok [y/N]: y
Key imported successfully
Import of key(s) didn't help, wrong key(s)?
Problem opening package 
dogtag-jss-5.4.0-0.1.alpha1.20230227143934UTC.0c4012e6.fc39.x86_64.rpm. Failing 
package is: dogtag-jss-5.4.0-0.1.alpha1.20230227143934UTC.0c4012e6.fc39.x86_64
 GPG Keys are configured as: 
https://download.copr.fedorainfracloud.org/results/@pki/master/pubkey.gpg
Problem opening package 
dogtag-ldapjdk-5.4.0-0.1.alpha1.20230127155101UTC.ea85ad3a.fc38.noarch.rpm
Problem opening package 
dogtag-tomcatjss-8.4.0-0.1.alpha1.20230120164140UTC.a5ca31ab.fc38.noarch.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


I see that the key is new, generated yesterday: 
https://download.copr.fedorainfracloud.org/results/%40pki/master/
What causes this key to be (re)generated? I looked for docs around this but 
couldn't find anything to help me.

To move things along, I tried to work around this with --nogpgcheck ,which led 
to a different error:

Running transaction check
Transaction check succeeded.
Running transaction test
The downloaded packages were saved in cache until the next successful 
transaction.
You can remove cached packages by executing 'dnf clean packages'.
Error: Transaction test error:
  package dogtag-jss-5.4.0-0.1.alpha1.20230227143934UTC.0c4012e6.fc39.x86_64 
does not verify: Header V4 RSA/SHA256 Signature, key ID 20de059c: BAD
  package 
dogtag-ldapjdk-5.4.0-0.1.alpha1.20230127155101UTC.ea85ad3a.fc38.noarch does not 
verify: Header V4 RSA/SHA256 Signature, key ID 20de059c: BAD
  package 
dogtag-tomcatjss-8.4.0-0.1.alpha1.20230120164140UTC.a5ca31ab.fc38.noarch does 
not verify: Header V4 RSA/SHA256 Signature, key ID 20de059c: BAD

...which looks like it is still attempting to do some kind of verification of 
the key.

I have tried setting both gpgcheck=0 and repo_gpgcheck=0 in the repo file, but 
this does not change the result. Am I misunderstanding the purpose/scope of 
this option?

Does anyone have any idea why this key does not work, or have some doc I can 
look at to try figure it out myself?
Likewise for the workaround, anyone have any insight there?

Thanks for your patient reading if you go this far :-) I'm hoping this is a 
lack of familiarity on my part with GPG.

Cheers,

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

[Chris Kelley]

For me it is:

99% "I want to check if local changes build" - fedpkg scratch-build --srpm
1% "Something changed in Rawhide and I want to see if X still builds" -
fedpkg scratch-build

I didn't know "fedpkg build" has a scratch option, TIL.

Cheers,

Chris

On Mon, 16 Jan 2023 at 10:52, Daniel P. Berrangé 
wrote:

> On Mon, Jan 16, 2023 at 09:56:31AM +0200, Otto Liljalaakso wrote:
> > 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.
>
> Yep, testing non-pushed content is the primary reason for doing a
> scratch-build. So 95% of the time I'll use  "fedpkg scratch-build --srpm"
> on non-pushed content. Very occassionally I'll do a scratch build
> with pushed content, if testing compat with the latest build root
> contents.
>
> Probably 70% of the time I would often also add  "--arch x86_64" to
> avoid burning CPU time across all the Fedora arch builders for a plain
> smoketest. Sometimes might pick a different arch if chasing a particular
> arch problem.
>
> With regards,
> Daniel
> --
> |: https://berrange.com  -o-
> https://www.flickr.com/photos/dberrange :|
> |: https://libvirt.org -o-
> https://fstop138.berrange.com :|
> |: https://entangle-photo.org-o-
> https://www.instagram.com/dberrange :|
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> 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: [Fedora-legal-list] Re: SPDX Office hours

[Chris Kelley]

Fortnight is not Old English, it is modern British English and in daily use
for probably 100,000,000+ people.
I use "every two weeks" when speaking to people who are not British though,
and it is likely a better choice here as an international list.
Still, it is not an arcane word and it solves this problem entirely :-)

On Thu, 12 Jan 2023 at 22:31, Gary Buhrmaster 
wrote:

> On Thu, Jan 12, 2023 at 10:19 PM David Woodhouse 
> wrote:
>
> > The English word for that is 'fortnightly', FWIW.
>
> While that is Old English, and still commonly used
> in parts of the world and in some formal language
> usage, most people just use the words "every two
> weeks" rather than asking people to pull out their
> OED.
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> 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: [Fedora-legal-list] Re: SPDX Office hours

[Chris Kelley]

Fortnightly isn't ambiguous :-)

On Thu, 12 Jan 2023, 22:09 Jilayne Lovejoy,  wrote:

> every two weeks was my understanding too, although I don't think Miro set
> up a recurring invite b/c we were also going to try to alternate the time
> of day to accommodate various time zones.
>
> Bi-weekly is ambiguous in English, I've had this challenge before!
>
> Jilayne
>
> On 1/12/23 10:14 AM, Richard Fontana wrote:
>
> On Thu, Jan 12, 2023 at 11:33 AM Miro Hrončok  wrote:
>
>> On 11. 01. 23 20:10, Miroslav Suchý wrote:
>> > This is intended to be bi-weekly.
>>
>> Every two weeks or twice a week?
>>
>
> Since I was at a meeting yesterday where this was discussed I am pretty
> sure the intention was every two weeks. Yes, "bi-weekly" is ambiguous in
> English. :-)
>
> Richard
>
> ___
> legal mailing list -- le...@lists.fedoraproject.org
> To unsubscribe send an email to legal-le...@lists.fedoraproject.org
> Fedora Code of Conduct: 
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: 
> https://lists.fedoraproject.org/archives/list/le...@lists.fedoraproject.org
> Do not reply to spam, report it: 
> https://pagure.io/fedora-infrastructure/new_issue
>
>
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
> Do not reply to spam, report it:
> https://pagure.io/fedora-infrastructure/new_issue
>
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Strange maven build problem in jackson packages

[Chris Kelley]

Thanks very much for the help - I have now built successfully! \o/

Although the spec BRs mvn(org.apache.felix:maven-bundle-plugin),
> pom.xml doesn't mention it.  Add this to %prep:
>
> %pom_add_plugin "org.apache.felix:maven-bundle-plugin:5.1.1" .
> "true"
>
I had actually tried adding the plugin in like this but tried to add the
extensions tag in using a separate xpath statement - obviously incorrectly.
This was the missing ingredient, doing both together!

After doing that, the build still fails:
>
Yeah I had a patch to fix the java version but I removed it temporarily in
my desperation.

  Also, patch 0001-Add-extensions-true-to-build-helper-maven-plugin.patch

accomplishes nothing
Even more desperation -_-

Merry winter holiday of your choice!
>
May you also find happiness in your own choice!

I think your theory is correct - and the dependency that was updated
> is fasterxml-oss-parent:
>
Long time no see Rich, small world, I hope you're keeping well! So this was
side-tag noobing after all, I should have considered that it was something
I had changed. Lesson learned.

Cheers again,

Chris

On Thu, 15 Dec 2022 at 19:35, Richard Fearn  wrote:

> > My theory is that there is a dependency that was updated in Rawhide,
> which is problematic for my build, and that dep was recently updated in c9s
> and is now causing the same problem for me there. Has anyone seen anything
> like this before? How did you begin to investigate it? Or am I just being a
> side-tag noob?
>
> I think your theory is correct - and the dependency that was updated
> is fasterxml-oss-parent:
>
>
> https://src.fedoraproject.org/rpms/fasterxml-oss-parent/c/ce8d84d5ac23d0218facd26a161641c9acba27d7?branch=rawhide
>
> * The parent of jackson-annotations is com.fasterxml.jackson:jackson-parent
> * The parent of jackson-parent is com.fasterxml:oss-parent
> * oss-parent no longer includes maven-bundle-plugin in its POM
>
> So I guess you could (a) add maven-bundle-plugin back into oss-parent,
> or (b) (as Jerry suggests) add it to jackson-annotations with
> %pom_add_plugin. (Not sure which is best...)
>
> As Jerry mentioned the patch is redundant because it's patching the
> build-helper-maven-plugin config, only for that plugin to later be
> removed from the POM with %pom_remove_plugin.
>
> It's maven-bundle-plugin that enables the "bundle" packaging type to
> be used, not build-helper-maven-plugin.
>
> Regards,
>
> Richard
>
> --
> Richard Fearn
> richardfe...@gmail.com
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
> Do not reply to spam, report it:
> https://pagure.io/fedora-infrastructure/new_issue
>
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Strange maven build problem in jackson packages

[Chris Kelley]

Hello all!

I recently took over maintaining the Jackson serialisation packages in Fedora 
and I am rebasing them to the latest upstream version in a side-tag: 
https://koji.fedoraproject.org/koji/builds?userID=ckelley=60533. I am 
experiencing curious difficulties I am hoping someone may be able to shed light 
on!

Before attempting this update in Rawhide, I performed the update in copr: 
https://copr.fedorainfracloud.org/coprs/ckelley/pki/packages/
This, after a bit of trial-and-error, was successful - and these packages are 
now being used successfully in the upstream CI for various packages. All good.

Then, I attempted the same in Rawhide. The first 3 packages in the side-tag 
(FYI first time side-tagging) build fine, but jackson-annotations does not: 
https://koji.fedoraproject.org/koji/taskinfo?taskID=95305556
The failure is strange as the dep that provides the code to understand bundle 
packaging is present (and it works in copr).

After a bit of frustration I stopped to focus on performing the same update in 
CentOS 9 Stream, from the same sources. This update too was successful 
(eventually, first side-tag there too). The spec files are essentially 
identical between c9s and Rawhide, so I don't see an explanation there.

Curiously, I submitted a later update to jackson-annotations in c9s and it now 
fails with the exact same packaging problem as occurs in Rawhide. That update 
contained only a RH internal test file, the sources and spec were untouched.

My theory is that there is a dependency that was updated in Rawhide, which is 
problematic for my build, and that dep was recently updated in c9s and is now 
causing the same problem for me there. Has anyone seen anything like this 
before? How did you begin to investigate it? Or am I just being a side-tag noob?

Any help at all appreciated, thanks!

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

[Chris Kelley]

Hi Steve,

You don't specify which version of Fedora each box is using, but if you
have one running F32 or earlier and one running F33+ then Petr is probably
correct. This is likely a result of SHA-1 being disabled in the DEFAULT
SWCP:

https://fedoraproject.org/wiki/Changes/StrongCryptoSettings2
https://pagure.io/fedora-docs/release-notes/issue/470

You can use 'update-crypto-policies --show' to see what your active policy
is, presumably it is DEFAULT on both machines.

Cheers,

Chris

On Wed, 27 Oct 2021 at 12:11, Petr Pisar  wrote:

> V Tue, Oct 26, 2021 at 01:31:31PM -0400, Steve Dickson napsal(a):
> > A very strange problem... on one of my fedora
> > build machine I'm getting the following error
> > when I do a git pull
> >
> > $ git pull
> > sign_and_send_pubkey: signing failed for RSA "/home/steved/.ssh/id_rsa"
> from
> > agent: agent refused operation
>
> Disabled SHA-1 in system-wide cryptopolicy?
>
> -- Petr
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
> Do not reply to spam on the list, report it:
> https://pagure.io/fedora-infrastructure
>
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure