Review request for oclock package (orphaned since F35)

[Globe Trotter]

Hello,

Anyone willing to review this request for a recently (>8 weeks) orphaned package?

https://bugzilla.redhat.com/show_bug.cgi?id=2025138

Happy to review in return.

[Globe Trotter]

Thank you to Dan Čermák for reviewing this package. However, I had two questions from his comments. The first was that the spec file should use gpgverify. 
So, I went to the suggested webpage: https://docs.fedoraproject.org/en-US/packaging-guidelines/#_source_file_veri...
and did the following to get my signature

Source0:    https://www.x.org/pub/individual/app/%%7Bname%7D-%%7Bversion%7D.tar.gz
Source1:    %{source0}.sig

but can not tell how to get the gpg keyring from the site.

Second, it is also suggested that I start using rpmautospec, as that will make package maintenance simpler in the long run. I like that of course, but I am trying to understand where this is used?

Thanks for any advice!

On Monday, November 22, 2021, 04:21:59 PM CST, Globe Trotter via devel  wrote:

Hello,

Anyone willing to review this request for a recently (>8 weeks) orphaned package?

https://bugzilla.redhat.com/show_bug.cgi?id=2025138

Happy to review in return.
_______________________________________________
devel mailing list -- [e-mail]
To unsubscribe send an email to [e-mail]
Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: https://lists.fedoraproject.org/archives/list/[e-mail]
Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure

[Ben Beasley]

Please compare with https://src.fedoraproject.org/rpms/xfontsel/blob/rawhide/f/xfontsel.spec, paying close attention to the comments in the spec file. SKS keyservers have gone offline since that package obtained its keyring, so try using hkps://keys.openpgp.org instead.

That package also uses rpmautospec.

On Mon, Nov 22, 2021, at 7:02 PM, Globe Trotter via devel wrote:
> Thank you to Dan Čermák for reviewing this package. However, I had two 
> questions from his comments. The first was that the spec file should 
> use gpgverify. 
> So, I went to the suggested webpage: 
> https://docs.fedoraproject.org/en-US/packaging-guidelines/#_source_file_veri...
> and did the following to get my signature
>
> Source0:    https://www.x.org/pub/individual/app/%%7Bname%7D-%%7Bversion%7D.tar.gz
> Source1:    %{source0}.sig
>
> but can not tell how to get the gpg keyring from the site.
>
> Second, it is also suggested that I start using rpmautospec, as that 
> will make package maintenance simpler in the long run. I like that of 
> course, but I am trying to understand where this is used?
>
> Thanks for any advice!
>
> On Monday, November 22, 2021, 04:21:59 PM CST, Globe Trotter via devel 
>  wrote:
>
> Hello,
>
> Anyone willing to review this request for a recently (>8 weeks) 
> orphaned package?
>
> https://bugzilla.redhat.com/show_bug.cgi?id=2025138
>
> Happy to review in return.
> _______________________________________________
> devel mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]
> Fedora Code of Conduct: 
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: 
> https://lists.fedoraproject.org/archives/list/[e-mail]
> Do not reply to spam on the list, report it: 
> https://pagure.io/fedora-infrastructure
> _______________________________________________
> devel mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]
> Fedora Code of Conduct: 
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: 
> https://lists.fedoraproject.org/archives/list/[e-mail]
> Do not reply to spam on the list, report it: 
> https://pagure.io/fedora-infrastructure

[Globe Trotter]

Wonderful, thank you! This is the sort of pointer I was looking for. I will now try it.

On Monday, November 22, 2021, 07:05:13 PM CST, Ben Beasley  wrote:

Please compare with https://src.fedoraproject.org/rpms/xfontsel/blob/rawhide/f/xfontsel.spec, paying close attention to the comments in the spec file. SKS keyservers have gone offline since that package obtained its keyring, so try using hkps://keys.openpgp.org instead.

That package also uses rpmautospec.

On Mon, Nov 22, 2021, at 7:02 PM, Globe Trotter via devel wrote:
> Thank you to Dan Čermák for reviewing this package. However, I had two 
> questions from his comments. The first was that the spec file should 
> use gpgverify. 
> So, I went to the suggested webpage: 
> https://docs.fedoraproject.org/en-US/packaging-guidelines/#_source_file_veri...
> and did the following to get my signature
>
> Source0:    https://www.x.org/pub/individual/app/%%7Bname%7D-%%7Bversion%7D.tar.gz
> Source1:    %{source0}.sig
>
> but can not tell how to get the gpg keyring from the site.
>
> Second, it is also suggested that I start using rpmautospec, as that 
> will make package maintenance simpler in the long run. I like that of 
> course, but I am trying to understand where this is used?
>
> Thanks for any advice!
>
> On Monday, November 22, 2021, 04:21:59 PM CST, Globe Trotter via devel 
>  wrote:
>
> Hello,
>
> Anyone willing to review this request for a recently (>8 weeks) 
> orphaned package?
>
> https://bugzilla.redhat.com/show_bug.cgi?id=2025138
>
> Happy to review in return.
> _______________________________________________
> devel mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]
> Fedora Code of Conduct: 
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: 
> https://lists.fedoraproject.org/archives/list/[e-mail]
> Do not reply to spam on the list, report it: 
> https://pagure.io/fedora-infrastructure
> devel mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]
> Fedora Code of Conduct: 
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: 
> https://lists.fedoraproject.org/archives/list/[e-mail]
> Do not reply to spam on the list, report it: 
> https://pagure.io/fedora-infrastructure

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

[Björn Persson]

Ben Beasley wrote:
> Please compare with https://src.fedoraproject.org/rpms/xfontsel/blob/rawhide/f/xfontsel.spec, paying close attention to the comments in the spec file. SKS keyservers have gone offline since that package obtained its keyring, so try using hkps://keys.openpgp.org instead.

To elaborate on this, the procedure described in xfontsel.spec finds the
key that was used to make the signature, so whoever made the signature
becomes the trusted upstream.

If you do that *once*, it's a form of trust on first use. It lets you
discover future attacks as long as you continue using the same key,
assuming that you got the right key to begin with.

If you would repeat the key lookup every time you upgrade the package,
then you would render the verification meaningless. You'd just be
verifying that the tarball was signed by whoever signed the tarball. So
don't do that.

Björn Persson

[Globe Trotter]

Can someone please review the oclock package? This was orphaned after F35, and I packaged it for myself, and then would like to put it up. It was tentatively approved, but never finally done so. Thanks!

On Tuesday, November 23, 2021 at 02:43:00 PM CST, Björn Persson  wrote:

Ben Beasley wrote:
> Please compare with https://src.fedoraproject.org/rpms/xfontsel/blob/rawhide/f/xfontsel.spec, paying close attention to the comments in the spec file. SKS keyservers have gone offline since that package obtained its keyring, so try using hkps://keys.openpgp.org instead.

To elaborate on this, the procedure described in xfontsel.spec finds the
key that was used to make the signature, so whoever made the signature
becomes the trusted upstream.

If you do that *once*, it's a form of trust on first use. It lets you
discover future attacks as long as you continue using the same key,
assuming that you got the right key to begin with.

If you would repeat the key lookup every time you upgrade the package,
then you would render the verification meaningless. You'd just be
verifying that the tarball was signed by whoever signed the tarball. So
don't do that.

Björn Persson

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

[Globe Trotter]

Sorry, forgot the BZ: https://bugzilla.redhat.com/show_bug.cgi?id=2025138

On Saturday, May 6, 2023 at 12:36:20 PM CDT, Globe Trotter  wrote:

Can someone please review the oclock package? This was orphaned after F35, and I packaged it for myself, and then would like to put it up. It was tentatively approved, but never finally done so. Thanks!

On Tuesday, November 23, 2021 at 02:43:00 PM CST, Björn Persson  wrote:

Ben Beasley wrote:
> Please compare with https://src.fedoraproject.org/rpms/xfontsel/blob/rawhide/f/xfontsel.spec, paying close attention to the comments in the spec file. SKS keyservers have gone offline since that package obtained its keyring, so try using hkps://keys.openpgp.org instead.

To elaborate on this, the procedure described in xfontsel.spec finds the
key that was used to make the signature, so whoever made the signature
becomes the trusted upstream.

If you do that *once*, it's a form of trust on first use. It lets you
discover future attacks as long as you continue using the same key,
assuming that you got the right key to begin with.

If you would repeat the key lookup every time you upgrade the package,
then you would render the verification meaningless. You'd just be
verifying that the tarball was signed by whoever signed the tarball. So
don't do that.

Björn Persson

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

[Sandro]

On 06-05-2023 19:36, Globe Trotter via devel wrote:
> Can someone please review the oclock package? This was orphaned after
> F35, and I packaged it for myself, and then would like to put it up.
> It was tentatively approved, but never finally done so. Thanks!

Looks like the package is approved. The fedora-review flag is set to 
'+', meaning approved. You should be able to proceed with requesting a 
dist-git repo.

-- Sandro

[Sandro]

On 06-05-2023 23:43, Sandro wrote:
> On 06-05-2023 19:36, Globe Trotter via devel wrote:
> > Can someone please review the oclock package? This was orphaned after
> > F35, and I packaged it for myself, and then would like to put it up.
> > It was tentatively approved, but never finally done so. Thanks!
>
> Looks like the package is approved. The fedora-review flag is set to
> '+', meaning approved. You should be able to proceed with requesting a
> dist-git repo.

Or rather file a releng ticket requesting unretirement at 
https://pagure.io/releng/new_issue?template=package_unretirement&title=U... 
now the package is approved.

Sorry for the confusion.

-- Sandro

[Globe Trotter]

Thank you for this. I got:

fedpkg import ~/rpmbuild/SRPMS/oclock-1.0.4-4.fc37.src.rpm
Removing no longer used file: dead.package
Could not execute import_srpm: This package or module is retired. The action has stopped.

so I guess I have request unretirement. I thought I did it sometime ago, but maybe not.

Thanks again!

On Saturday, May 6, 2023 at 04:52:55 PM CDT, Sandro  wrote:

On 06-05-2023 23:43, Sandro wrote:
> On 06-05-2023 19:36, Globe Trotter via devel wrote:
> > Can someone please review the oclock package? This was orphaned after
> > F35, and I packaged it for myself, and then would like to put it up.
> > It was tentatively approved, but never finally done so. Thanks!
>
> Looks like the package is approved. The fedora-review flag is set to
> '+', meaning approved. You should be able to proceed with requesting a
> dist-git repo.

Or rather file a releng ticket requesting unretirement at 
https://pagure.io/releng/new_issue?template=package_unretirement&title=U... 
now the package is approved.

Sorry for the confusion.

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

[Globe Trotter]

How long does it take to unretire a package? I was thinking that it was automatic, but I have not received any notification yet. Did this request last evening.

On Saturday, May 6, 2023 at 07:25:30 PM CDT, Globe Trotter via devel  wrote:

Thank you for this. I got:

fedpkg import ~/rpmbuild/SRPMS/oclock-1.0.4-4.fc37.src.rpm
Removing no longer used file: dead.package
Could not execute import_srpm: This package or module is retired. The action has stopped.

so I guess I have request unretirement. I thought I did it sometime ago, but maybe not.

Thanks again!

On Saturday, May 6, 2023 at 04:52:55 PM CDT, Sandro  wrote:

On 06-05-2023 23:43, Sandro wrote:
> On 06-05-2023 19:36, Globe Trotter via devel wrote:
> > Can someone please review the oclock package? This was orphaned after
> > F35, and I packaged it for myself, and then would like to put it up.
> > It was tentatively approved, but never finally done so. Thanks!
>
> Looks like the package is approved. The fedora-review flag is set to
> '+', meaning approved. You should be able to proceed with requesting a
> dist-git repo.

Or rather file a releng ticket requesting unretirement at 
https://pagure.io/releng/new_issue?template=package_unretirement&title=U... 
now the package is approved.

Sorry for the confusion.

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

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

[Sandro]

On 07-05-2023 17:34, Globe Trotter via devel wrote:
> How long does it take to unretire a package? I was thinking that it
> was automatic, but I have not received any notification yet. Did this
> request last evening.

I don't think it's fully automated. It's a member of the releng team 
that has to process it. They will be back on duty on Monday.

See for example te previous unretirement request for oclock:

https://pagure.io/releng/issue/10396

-- Sandro

[Globe Trotter]

I see, thanks! I had indeed forgotten that the previous request had been closed.

On Sunday, May 7, 2023 at 10:50:42 AM CDT, Sandro  wrote:

On 07-05-2023 17:34, Globe Trotter via devel wrote:
> How long does it take to unretire a package? I was thinking that it
> was automatic, but I have not received any notification yet. Did this
> request last evening.

I don't think it's fully automated. It's a member of the releng team 
that has to process it. They will be back on duty on Monday.

See for example te previous unretirement request for oclock:

https://pagure.io/releng/issue/10396

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

[Globe Trotter]

Still no movement on my unretire requests for both slim and oclock, not even a request for additional information.

On Sunday, May 7, 2023 at 10:50:42 AM CDT, Sandro  wrote:

On 07-05-2023 17:34, Globe Trotter via devel wrote:
> How long does it take to unretire a package? I was thinking that it
> was automatic, but I have not received any notification yet. Did this
> request last evening.

I don't think it's fully automated. It's a member of the releng team 
that has to process it. They will be back on duty on Monday.

See for example te previous unretirement request for oclock:

https://pagure.io/releng/issue/10396

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

[Sandro]

On 11-05-2023 17:57, Globe Trotter via devel wrote:
> Still no movement on my unretire requests for both slim and oclock, not even a request for additional information.

Tags have been added to the ticket. So, it has come up in one of the 
meetings. Supposedly, no-one has found the time yet to work on it.

Feel free to ping in the ticket or bring it up in one of the meetings.

-- Sandro

[Globe Trotter]

Thanks, Sandro! How does one ping in the ticket on paguire?

On Friday, May 12, 2023 at 07:41:47 PM CDT, Sandro  wrote:

On 11-05-2023 17:57, Globe Trotter via devel wrote:
> Still no movement on my unretire requests for both slim and oclock, not even a request for additional information.

Tags have been added to the ticket. So, it has come up in one of the 
meetings. Supposedly, no-one has found the time yet to work on it.

Feel free to ping in the ticket or bring it up in one of the meetings.

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

[Sandro]

On 14-05-2023 00:45, Globe Trotter via devel wrote:
> Thanks, Sandro! How does one ping in the ticket on paguire?

The easiest way is to just leave a comment in the ticket. If you need 
info from a specific person you would tag that person (@fas_user). That 
ensures people watching the ticket queue get another notification, 
bringing the ticket to their attention again.

But since Kevin already explained the delay, there's no need for that 
now. Either Kevin or the person returning from PTO next week will surely 
pick it up.

-- Sandro

[Kevin Fenzi]

On Sat, May 13, 2023 at 02:41:10AM +0200, Sandro wrote:
> On 11-05-2023 17:57, Globe Trotter via devel wrote:
> > Still no movement on my unretire requests for both slim and oclock, not even a request for additional information.
>
> Tags have been added to the ticket. So, it has come up in one of the
> meetings. Supposedly, no-one has found the time yet to work on it.
>
> Feel free to ping in the ticket or bring it up in one of the meetings.

FYI, the main release engineer who usually processes these was on pto
last week, and I (who do release engineering work in my 'spare' time)
didn't have any time to get to any.

If there's urgency on any request, please do note that in the ticket...

We are working on automating unretire requests... hopefully that will
land before too long.

Otherwise we will get to them as soon as we can.

I might be able to do some this weekend, but I am trying to catch up on
around the house/yard tasks, so no promises. :)

kevin

[Globe Trotter]

Thanks, Kevin! No  problem, no rush, I did not quite know what to expect, hence the questions. Thanks again!

On Saturday, May 13, 2023 at 06:12:33 PM CDT, Kevin Fenzi  wrote:

On Sat, May 13, 2023 at 02:41:10AM +0200, Sandro wrote:
> On 11-05-2023 17:57, Globe Trotter via devel wrote:
> > Still no movement on my unretire requests for both slim and oclock, not even a request for additional information.
>
> Tags have been added to the ticket. So, it has come up in one of the
> meetings. Supposedly, no-one has found the time yet to work on it.
>
> Feel free to ping in the ticket or bring it up in one of the meetings.

FYI, the main release engineer who usually processes these was on pto
last week, and I (who do release engineering work in my 'spare' time)
didn't have any time to get to any.

If there's urgency on any request, please do note that in the ticket...

We are working on automating unretire requests... hopefully that will
land before too long.

Otherwise we will get to them as soon as we can.

I might be able to do some this weekend, but I am trying to catch up on
around the house/yard tasks, so no promises. :)

kevin

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

[Benson Muite]

Hi Ranjan,

Thanks for contributing to Fedora and maintaining packages.

On 5/14/23 03:27, Globe Trotter via devel wrote:
> Thanks, Kevin! No  problem, no rush, I did not quite know what to expect, hence the questions. Thanks again!

It seems it is just the review that is needed:
https://docs.fedoraproject.org/en-US/fesco/Policy_for_orphan_and_retired_pac...

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

Generally reviews go faster if the person asking for the review does a
review of another package - many people ask for review swaps on this
list. For a package with a reviewer you can add NEEDINFO in bugzilla so
that if an person has assigned themselves as reviewer does not respond
after a while, a new reviewer can take it up.
> On Saturday, May 13, 2023 at 06:12:33 PM CDT, Kevin Fenzi  wrote:
>
> On Sat, May 13, 2023 at 02:41:10AM +0200, Sandro wrote:
> > On 11-05-2023 17:57, Globe Trotter via devel wrote:
> > > Still no movement on my unretire requests for both slim and oclock, not even a request for additional information.
> >
> > Tags have been added to the ticket. So, it has come up in one of the
> > meetings. Supposedly, no-one has found the time yet to work on it.
> >
> > Feel free to ping in the ticket or bring it up in one of the meetings.

[Globe Trotter]

Benson,

Thanks! The package was cleared  on BZ some time ago. Is there some additional review that is needed?

Best wishes,
Ranjan

On Sunday, May 14, 2023 at 05:41:35 AM CDT, Benson Muite  wrote:

Hi Ranjan,

Thanks for contributing to Fedora and maintaining packages.

On 5/14/23 03:27, Globe Trotter via devel wrote:
> Thanks, Kevin! No  problem, no rush, I did not quite know what to expect, hence the questions. Thanks again!

It seems it is just the review that is needed:
https://docs.fedoraproject.org/en-US/fesco/Policy_for_orphan_and_retired_pac...

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

Generally reviews go faster if the person asking for the review does a
review of another package - many people ask for review swaps on this
list. For a package with a reviewer you can add NEEDINFO in bugzilla so
that if an person has assigned themselves as reviewer does not respond
after a while, a new reviewer can take it up.
> On Saturday, May 13, 2023 at 06:12:33 PM CDT, Kevin Fenzi  wrote:
>
> On Sat, May 13, 2023 at 02:41:10AM +0200, Sandro wrote:
> > On 11-05-2023 17:57, Globe Trotter via devel wrote:
> > > Still no movement on my unretire requests for both slim and oclock, not even a request for additional information.
> >
> > Tags have been added to the ticket. So, it has come up in one of the
> > meetings. Supposedly, no-one has found the time yet to work on it.
> >
> > Feel free to ping in the ticket or bring it up in one of the meetings.

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

[Benson Muite]

Ranjan,

On 5/14/23 13:46, Globe Trotter via devel wrote:
> Thanks! The package was cleared  on BZ some time ago. Is there some additional review that is needed?

Sorry, that is correct. Usually state is set to post. It seems to have
been unretired:
https://pagure.io/releng/issue/11417

Though project ownership has not been updated:
https://src.fedoraproject.org/rpms/oclock

It seems Slim has been unretired:
https://pagure.io/releng/issue/11310
and project ownership updated:
https://src.fedoraproject.org/rpms/slim
Maybe just need to add the new files?
> Best wishes,
> Ranjan

[Kevin Fenzi]

On Sun, May 14, 2023 at 02:04:57PM +0300, Benson Muite wrote:
> Ranjan,
>
> On 5/14/23 13:46, Globe Trotter via devel wrote:
> > Thanks! The package was cleared  on BZ some time ago. Is there some additional review that is needed?
>
> Sorry, that is correct. Usually state is set to post. It seems to have
> been unretired:
> https://pagure.io/releng/issue/11417

Yep.
> Though project ownership has not been updated:
> https://src.fedoraproject.org/rpms/oclock

It looks updated to me? Did I miss something there? 
Do let me know in the ticket if so.
> It seems Slim has been unretired:
> https://pagure.io/releng/issue/11310
> and project ownership updated:
> https://src.fedoraproject.org/rpms/slim
> Maybe just need to add the new files?

Yes, it should be unretired and all ready to push commits
to/build/update.

kevin

[Globe Trotter]

Kevin, oclock was not updated, and Beson's email made me realize that I could go an do it myself. I did that by the time you check. slim's was updated and both packages are now in testing.

Best,
Ranjan

On Sunday, May 14, 2023 at 10:49:44 AM CDT, Kevin Fenzi  wrote:

On Sun, May 14, 2023 at 02:04:57PM +0300, Benson Muite wrote:
> Ranjan,
>
> On 5/14/23 13:46, Globe Trotter via devel wrote:
> > Thanks! The package was cleared  on BZ some time ago. Is there some additional review that is needed?
>
> Sorry, that is correct. Usually state is set to post. It seems to have
> been unretired:
> https://pagure.io/releng/issue/11417

Yep.
> Though project ownership has not been updated:
> https://src.fedoraproject.org/rpms/oclock

It looks updated to me? Did I miss something there? 
Do let me know in the ticket if so.
> It seems Slim has been unretired:
> https://pagure.io/releng/issue/11310
> and project ownership updated:
> https://src.fedoraproject.org/rpms/slim
> Maybe just need to add the new files?

Yes, it should be unretired and all ready to push commits
to/build/update.

kevin

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

[Sandro]

On 14-05-2023 12:40, Benson Muite wrote:
> It seems it is just the review that is needed:

The re-review is done:

https://bugzilla.redhat.com/show_bug.cgi?id=2025138

Releng unretiring the package is the next step, really.

-- Sandro

[Dan Čermák]

Hi,

Globe Trotter via devel  writes:
> Thank you to Dan Čermák for reviewing this package. However, I had two questions from his comments. The first was that the spec file should use gpgverify. 
> So, I went to the suggested webpage: https://docs.fedoraproject.org/en-US/packaging-guidelines/#_source_file_veri...
> and did the following to get my signature
>
> Source0:    https://www.x.org/pub/individual/app/%%7Bname%7D-%%7Bversion%7D.tar.gz
> Source1:    %{source0}.sig
>
> but can not tell how to get the gpg keyring from the site.
>
> Second, it is also suggested that I start using rpmautospec, as that will make package maintenance simpler in the long run. I like that of course, but I am trying to understand where this is used?

rpmautospec reduces the necessary churn when updating packages, in the
simplest case it boils down to this:
- use `Release: %autorelease` instead of bumping it yourself
- don't write the %changelog yourself, just put:
--8<---------------cut here---------------start------------->8---
%changelog
%autochangelog
--8<---------------cut here---------------end--------------->8---
at the bottom of the spec

The rpmautospec automation will then bump the release via %autorelease
on each git commit and put every commit message into the changelog.
This has the huge advantage, that it makes updating across all branches
rather easy as you do not have to resolve merge conflicts due to
diverging changelogs or different release numbers any more.

Hope this explains it a bit, feel free to reach out directly if you've
got further questions,

Dan