[Bug 2020382] perl-CBOR-XS-1.86 is available
https://bugzilla.redhat.com/show_bug.cgi?id=2020382 --- Comment #5 from Fedora Update System --- FEDORA-2021-441f29618c has been pushed to the Fedora 34 testing repository. Soon you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --advisory=FEDORA-2021-441f29618c` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2021-441f29618c See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates. -- You are receiving this mail because: You are on the CC list for the bug. https://bugzilla.redhat.com/show_bug.cgi?id=2020382 ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
[EPEL-devel] Fedora EPEL 7 updates-testing report
The following Fedora EPEL 7 Security updates need testing: Age URL 49 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2021-f005e1b879 debmirror-2.35-1.el7 5 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2021-c1992565eb rpki-client-7.4-1.el7 3 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2021-f69cb3c1f1 rust-1.56.1-1.el7 3 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2021-8f1a739899 cacti-1.2.19-1.el7 cacti-spine-1.2.19-1.el7 The following builds have been pushed to Fedora EPEL 7 updates-testing python-auth-credential-1.1-1.el7 python-dirq-1.8-1.el7 python-messaging-1.2-1.el7 python-simplevisor-1.3-1.el7 Details about builds: python-auth-credential-1.1-1.el7 (FEDORA-EPEL-2021-72e54715a5) Python abstraction of a credential Update Information: Updated to new upstream version. ChangeLog: * Thu Nov 4 2021 Lionel Cons - 1.1-1 - Updated to 1.1 (rhbz #2020219) References: [ 1 ] Bug #2020219 - python-auth-credential-1.1 is available https://bugzilla.redhat.com/show_bug.cgi?id=2020219 python-dirq-1.8-1.el7 (FEDORA-EPEL-2021-cf45baf94d) Directory based queue Update Information: Updated to new upstream version. ChangeLog: * Thu Nov 4 2021 Lionel Cons - 1.8-1 - Updated to 1.8 (rhbz #2020220) References: [ 1 ] Bug #2020220 - python-dirq-1.8 is available https://bugzilla.redhat.com/show_bug.cgi?id=2020220 python-messaging-1.2-1.el7 (FEDORA-EPEL-2021-362a4a8324) Python abstraction of a "message" Update Information: Updated to new upstream version. ChangeLog: * Thu Nov 4 2021 Lionel Cons - 1.2-1 - Updated to 1.2 (rhbz #2020218) References: [ 1 ] Bug #2020218 - python-messaging-1.2 is available https://bugzilla.redhat.com/show_bug.cgi?id=2020218 python-simplevisor-1.3-1.el7 (FEDORA-EPEL-2021-2f17d3b42f) Python simple daemons supervisor Update Information: Updated to new upstream version. ChangeLog: * Thu Nov 4 2021 Lionel Cons - 1.3-1 - Updated to 1.3 (rhbz #2020222) References: [ 1 ] Bug #2020222 - python-simplevisor-1.3 is available https://bugzilla.redhat.com/show_bug.cgi?id=2020222 ___ epel-devel mailing list -- epel-devel@lists.fedoraproject.org To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
[Bug 2020382] perl-CBOR-XS-1.86 is available
https://bugzilla.redhat.com/show_bug.cgi?id=2020382 Fedora Update System changed: What|Removed |Added Status|MODIFIED|ON_QA --- Comment #4 from Fedora Update System --- FEDORA-2021-0c4f7b2691 has been pushed to the Fedora 35 testing repository. Soon you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --advisory=FEDORA-2021-0c4f7b2691` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2021-0c4f7b2691 See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates. -- You are receiving this mail because: You are on the CC list for the bug. https://bugzilla.redhat.com/show_bug.cgi?id=2020382 ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
[Test-Announce] Proposal to CANCEL: 2021-11-08 Fedora QA Meeting
Hi folks! I'm proposing we cancel the QA meeting on Monday. I don't have anything urgent for this week, and it'd probably be more useful to have one next week after some of the things currently in discussion move forward a bit. If you're aware of anything it would be useful to discuss this week, please do reply to this mail and we can go ahead and run the meeting. Thanks! -- Adam Williamson Fedora QA IRC: adamw | Twitter: adamw_ha https://www.happyassassin.net ___ test-announce mailing list -- test-annou...@lists.fedoraproject.org To unsubscribe send an email to test-announce-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/test-annou...@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
[Test-Announce] Fedora 35 QA Retrospective page is up
So, the last of these emails I sent was eight years ago, time flies,
huh? :)
Sudhir suggested bringing these back, and it seemed like a fine idea,
so I did! I've created a Fedora 35 Retrospective page:
https://fedoraproject.org/wiki/Fedora_35_QA_Retrospective
In the past we would've created this page *during* Fedora 35
validation, so we could note things as we went along. I'll try and
remember to create one for Fedora 36 in a month or two.
Just in case anyone wasn't around in 2013 :P, here's how it works!
We use the retrospective page to track things that went well and things
that didn't go so well during the Fedora 35 validation process, and for
tracking ideas we have but don't have time to act on during the rush of
doing validation (that's the wishlist).
Please, add any feedback you have of this type to the retrospective
page! There are instructions on the page for adding feedback.
All feedback is useful, and after the page has been up for a while, we'll
take a look at all the items on the page and come up with specific
recommendations for addressing them which we'll file as issues and
work on in the time before Fedora 36 validation starts up.
You can look at the previous pages for inspiration:
https://fedoraproject.org/wiki/Category:QA_Retrospective
And once again I'll copy/paste James Laska's old list of leading questions
to prompt feedback, because it's still pretty good:
1. Were you able to participate in any Fedora 35 Beta or
Final test runs?
2. What worked well, what prevented you from participating, were
instructions clear?
3. What worked (or didn't work) well about Fedora Test Days this
release?
4. Are you a maintainer, why do you think your critpath updates
haven't been tested? What could you do to encourage more
testing of your proposed updates?
5. Did you escalate any bugs for consideration as
{Beta,Final} release Blockers? Why not? Was the process
well documented and did it make sense?
6. Did you attend or contribute to any Fedora blocker meetings?
Why not? What did you like, dislike? What prevented you from
participating?
7. Did you find any of the release criteria changes or validation
test extensions particularly useful or problematic?
8. Can you think of any obviously important areas we are not
currently covering in the validation tests and criteria?
9. How are you finding the tools that we use for the process, like
the blocker bugs tool and the test day results tool?
10. Unlimited time and resource ... what do you think the the QA
team should focus on for Fedora 36 and beyond
--
Adam Williamson
Fedora QA
IRC: adamw | Twitter: adamw_ha
https://www.happyassassin.net
___
test-announce mailing list -- test-annou...@lists.fedoraproject.org
To unsubscribe send an email to test-announce-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/test-annou...@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
Re: openbabel-3.1* in Rawhide
On Fri, Nov 5, 2021 at 9:23 PM Antonio T. sagitter wrote: > > On 10/24/21 15:11, Alexander Ploumistos wrote: > > Hello Antonio, > > > > On Sun, Oct 24, 2021 at 3:05 PM Antonio T. sagitter > > wrote: > >> > >> We are ready to push openbabel3 in Rawhide > > > > Will it be just Rawhide? Will you please let us know when the build is > > done in order to rebuild dependent packages? > > Within 24 hours i will create a side-tag in Rawhide. Thanks Antonio, I'll probably be able to do the rebuild on Sunday night. ___ 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
Re: openbabel-3.1* in Rawhide
On 10/24/21 15:11, Alexander Ploumistos wrote: Hello Antonio, On Sun, Oct 24, 2021 at 3:05 PM Antonio T. sagitter wrote: We are ready to push openbabel3 in Rawhide Will it be just Rawhide? Will you please let us know when the build is done in order to rebuild dependent packages? Within 24 hours i will create a side-tag in Rawhide. Are we saying goodbye to Avogadro 1.x? Thank you for all the work you've put into this, A. ___ 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 -- --- Antonio Trande Fedora Project mailto: sagit...@fedoraproject.org GPG key: 0xCC1CFEF30920C8AE GPG key server: https://keyserver1.pgp.com/ OpenPGP_0xCC1CFEF30920C8AE.asc Description: OpenPGP public key OpenPGP_signature Description: OpenPGP digital signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Unexpected /patches VERIFY result from rpminspect
On Thu, Nov 04, 2021 at 06:51:23PM +0100, Florian Weimer wrote: * Aleksei Bavshin: On 11/4/21 09:17, Florian Weimer wrote: Why is this VERIFY? The patch was generated as if by “git show”, and I do not see anything wrong with it. rpminspect thinks that the patch is suspiciously large and asks you to confirm that it is intentional. There's a test description in the beginning of the log: Inspects all patches defined in the spec file and reports changes between builds. At the INFO level, rpminspect reports diffstat(1) and patch size changes. If thresholds are reached regarding a change in the patch size or the number of files the patch touches, rpminspect reports the change at the VERIFY level unless the comparison is for a rebase. The configuration file can also list patch names that rpminspect should ignore during the inspection. Is this a new check? It was flagged as a regression in Jenkins. It´s not new, the patches inspection has been present for a while. Thanks, -- David Cantrell Red Hat, Inc. | Boston, MA | EST5EDT ___ 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
Re: Possibly off topic: Slack will discontinue packaging for Fedora
On Fri, 5 Nov 2021 at 17:41, Matthew Miller wrote:
>
> On Fri, Nov 05, 2021 at 10:24:22AM -0700, Gordon Messmer wrote:
> > What I'm asking is whether Fedora, as an organization, is interested
> > in working with prominent vendors to determine whether there are
> > barriers to publishing software for Fedora, or whether they perceive
> > insufficient value in doing so. And, beyond those questions, is
> > there anything we can do as an organization to help change that
> > situation?
>
> I've got thoughts! :)
>
> 1. I think we have some historical wariness of this, because a while ago, we
> put in a big effort around this and it failed. See
> https://fedoraproject.org/wiki/ISV_Special_Interest_Group, which currently
> says "This page was last edited on 12 June 2010, at 22:15." (It won't in a
> second, as I'm adding the {{old}} macro right now...). Former FPL Greg
> DeKoenigsberg
> has some thoughts on why this failed, written about two years after that.
> https://gregdekspeaks.wordpress.com/2012/01/06/why-the-fedora-isv-sig-never-caught-fire/
>
After being a flatpak app maintainer for a few years, Greg's article
was well worth the reread. Flatpak has really nailed some of these
points (e.g. targeting all distros with a single build/release
process, binary dependency predictability, etc)... From an ISV
perspective Flatpak is a *much* better value for money prospect than
in-distro packaging.
--
Mat Booth
http://fedoraproject.org/get-fedora
___
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
Re: Possibly off topic: Slack will discontinue packaging for Fedora
On Fri, 5 Nov 2021 at 13:25, Gordon Messmer wrote: > > On 11/4/21 17:23, Gordon Messmer wrote: > > I don't know if that's of interest to Fedora, as an organization, but > > on the off-chance that it is: Is anyone in a position to ask someone > > at Slack about that decision? And whether there's anything that > > Fedora can do to make publishing that package more feasible? > > > To put a finer point on this: I'm not asking how I can run Slack, or how > other people run or use Slack. Those are questions I would ask on the > user list. > > What I'm asking is whether Fedora, as an organization, is interested in > working with prominent vendors to determine whether there are barriers > to publishing software for Fedora, or whether they perceive insufficient > value in doing so. And, beyond those questions, is there anything we > can do as an organization to help change that situation? > I believe those need to be tied into a couple of other questions 1. How does any organization work with these various prominent vendors? 2. What are the interests of said vendors and what are they focusing on for customer growth? Once those questions have been answered, then we can ask 3. Why did these prominent vendors decide to focus on OS A and B versus A and B and C and ... 4. What barriers are there for making it work for OS C/D/E/F Slack is now owned by Salesforce which will have specific monetary goals for what they want the sub company to focus on. In the past there was a large focus on getting everyone possible to use the product and there is now going to be more focus on paying customers. If we want a port focused for our OS, there need to be significant paying customers who are using Fedora. -- Stephen J Smoogen. I've seen things you people wouldn't believe. Flame wars in sci.astro.orion. I have seen SPAM filters overload because of Godwin's Law. All those moments will be lost in time... like posts on a BBS... time to shutdown -h now. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Possibly off topic: Slack will discontinue packaging for Fedora
On Fri, Nov 05, 2021 at 10:24:22AM -0700, Gordon Messmer wrote:
> What I'm asking is whether Fedora, as an organization, is interested
> in working with prominent vendors to determine whether there are
> barriers to publishing software for Fedora, or whether they perceive
> insufficient value in doing so. And, beyond those questions, is
> there anything we can do as an organization to help change that
> situation?
I've got thoughts! :)
1. I think we have some historical wariness of this, because a while ago, we
put in a big effort around this and it failed. See
https://fedoraproject.org/wiki/ISV_Special_Interest_Group, which currently
says "This page was last edited on 12 June 2010, at 22:15." (It won't in a
second, as I'm adding the {{old}} macro right now...). Former FPL Greg
DeKoenigsberg
has some thoughts on why this failed, written about two years after that.
https://gregdekspeaks.wordpress.com/2012/01/06/why-the-fedora-isv-sig-never-caught-fire/
2. Market share is hard and vendors have to make hard choices with their
limited resources. We're growing, but Ubuntu is still the dominent desktop
Linux flavor. The best thing to convince vendors is customers — paying
customers — demanding it. So, if you're using Slack in a professional
context, and can help make your voice known, that does a lot more than me
reaching out to them. (Which, by the way, I did.)
3. Probably Council Discussion
https://discussion.fedoraproject.org/c/project/council-discuss/60 is a
better venue than devel-list for non-development Fedora Project
organizational-goal topics. I mean, not that this is bad, just that's
_definitely_ good.
--
Matthew Miller
Fedora Project Leader
___
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
Re: Possibly off topic: Slack will discontinue packaging for Fedora
On 11/4/21 17:23, Gordon Messmer wrote: I don't know if that's of interest to Fedora, as an organization, but on the off-chance that it is: Is anyone in a position to ask someone at Slack about that decision? And whether there's anything that Fedora can do to make publishing that package more feasible? To put a finer point on this: I'm not asking how I can run Slack, or how other people run or use Slack. Those are questions I would ask on the user list. What I'm asking is whether Fedora, as an organization, is interested in working with prominent vendors to determine whether there are barriers to publishing software for Fedora, or whether they perceive insufficient value in doing so. And, beyond those questions, is there anything we can do as an organization to help change that situation? ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: [Fedocal] Reminder meeting : ELN SIG
=== #fedora-meeting: ELN SIG 2021-11-05 === Meeting started by StephenGallagher at 16:00:19 UTC. The full logs are available at https://meetbot.fedoraproject.org/fedora-meeting/2021-11-05/eln.2021-11-05-16.00.log.html . Meeting summary --- * Init Process (StephenGallagher, 16:00:20) * ELN Documentation Refresh (StephenGallagher, 16:04:23) * ACTION: dcavalca will document how to access ELN mirrors (StephenGallagher, 16:17:42) * ACTION: tdawson will document the ways in which ELN differs from Rawhide. (StephenGallagher, 16:18:02) * ACTION: sgallagh will open a ticket on how to get started running ELN and self-assign it. (StephenGallagher, 16:18:34) * Open Floor (StephenGallagher, 16:21:07) * Composes haven't broken in over a week! (StephenGallagher, 16:25:31) * Next week's Infrastructure Outage should pave the way for s390x container images in ELN (StephenGallagher, 16:25:51) * LINK: https://tiny.distro.builders/view--view-eln-extras.html (tdawson, 16:29:25) * LINK: https://github.com/fedora-eln/eln/issues/69 (dcavalca, 16:29:41) * LINK: https://xkcd.com/2347/ (StephenGallagher, 16:35:25) Meeting ended at 16:40:03 UTC. Action Items * dcavalca will document how to access ELN mirrors * tdawson will document the ways in which ELN differs from Rawhide. * sgallagh will open a ticket on how to get started running ELN and self-assign it. Action Items, by person --- * dcavalca * dcavalca will document how to access ELN mirrors * tdawson * tdawson will document the ways in which ELN differs from Rawhide. * **UNASSIGNED** * sgallagh will open a ticket on how to get started running ELN and self-assign it. People Present (lines said) --- * StephenGallagher (56) * tdawson (20) * zodbot (16) * dcavalca (13) * michel (8) * davdunc (6) * davdunc[m] (4) * cyberpear (1) * jforbes (1) * Michel (0) * Alexandre (0) * Salim (0) Generated by `MeetBot`_ 0.3 .. _`MeetBot`: https://fedoraproject.org/wiki/Zodbot#Meeting_Functions ___ 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
Re: Expansion of rpmautospec macros when building new packages
Dne 05. 11. 21 v 15:43 Miro Hrončok napsal(a):
On 05. 11. 21 15:35, Vít Ondruch wrote:
Dne 05. 11. 21 v 15:12 Ankur Sinha napsal(a):
On Fri, Nov 05, 2021 14:51:44 +0100, Miro Hrončok wrote:
On 05. 11. 21 14:13, Ankur Sinha wrote:
Hi folks,
I've been working with a few Outreachy candidates to help them learn
packaging. We're using `fedpkg` as much as we can, since it's
what we
use to work with all packages after they're imported into Fedora.
So, we first create git repo to work in, and after we write the spec,
we iteratively use `fedpkg mockbuild` to run mock and test builds
before
running rpmlint and so on and submitting the package for review.
Here, I
noticed we get an srpm which contains the spec where the
`%autorelease`
and `%autochangelog` bits are already expanded.
This is causing a couple of issues with reviews and imports:
- this spec in the srpm now differs from the spec, and fedora-review
will flag this difference---which is confusing for newcomers
(and had
me confused for a bit too)
- after the review, when `fedpkg import` is used to initialise the
SCM
using the approved srpm, again this spec with `%autorelease` and
`%autochangelog` already expanded is pulled in. Here's an
example of a
package we only imported recently where we didn't realise this:
https://src.fedoraproject.org/rpms/python-glymur/blob/rawhide/f/python-glymur.spec
This isn't necessarily a problem from a technical perspective, but
it's
a little annoying that one now has to remember to manually revert the
spec back to use the macros before committing to SCM. If one has to
manually tinker with the changelog etc., it defeats the purpose of
the
macros.
Since we didn't realise this, the package is now not using
`%autochangelog` and the first build has a release value that
isn't 1:
https://koji.fedoraproject.org/koji/packageinfo?packageID=34682
So we'll need to fix it (more work):
https://docs.pagure.org/fedora-infra.rpmautospec/opting-in.html#for-existing-packages
So, can anything be done to make this workflow better? Should
we/can we
disable these when using mockbuild, or add an option to do so that
can
be used for new packages to keep the value at 1? Or do we note that
these macros should only be used right before import (but that means
again editing the spec after running `fedpkg import` and more
confusion
for newcomers)?
The %autorelease/%autochangelog macros assume we are in a git
repository.
Hence if the package is created in a git repository before it is
imported
into Fedora, we should probably teach the packagers to push those
commits to
Fedora when he package is approved, instead of using `fedpkg
import` which
will also throw away their git history.
Hrm, but how would we do this? The new SCM repo that is created has a
completely different commit tree. I guess we can add the new remote and
And then rebase. This is script I use:
~~~
#!/bin/sh
git checkout main
git remote set-url origin
ssh://vondr...@pkgs.fedoraproject.org/rpms/"$@"
git fetch origin
git branch main -t origin/main
git rebase origin/main
~~~
I suppose we could teach `fedpkg import` to be able to import git
history + tarball(s) rather than a SRPM.
I like the idea. However, I am not sure this would work, at least if the
`import` action should be somehow modified to include this functionality.
Maybe there could be something like `fedpkg init-package`. I have
actually another script I use for new packages:
~~~
#!/bin/sh
# A smarter way of importing a new package in Fedora
#
http://blog.fedora-fr.org/bochecha/post/2011/02/A-smarter-way-of-importing-a-new-package-in-Fedora
cd ~/fedora-packages
git init --bare "$@".git
scp -r "$@".git vondr...@fedorapeople.org:~/public_git/
ssh vondr...@fedorapeople.org "touch
~/public_git/${@}.git/git-daemon-export-ok"
rm -rf "$@".git
git clone vondr...@fedorapeople.org:public_git/"$@".git
cd "$@"
touch sources .gitignore
git add sources .gitignore
git commit -m "Initial setup of the local repo"
~~~
This creates the git repo and push it to fedorapeople.org to have it
ready for review. It could also create .spec file via `rpmdev-newspec`
or similar.
If this was followed by `fedpkg initial-import` doing something like the
original script I posted + probably real `fedpkg import`, that would be
super helpful.
Vít
OpenPGP_signature
Description: OpenPGP digital signature
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it:
https://pagure.io/fedora-infrastructure
Re: Expansion of rpmautospec macros when building new packages
On 05. 11. 21 15:35, Vít Ondruch wrote: Dne 05. 11. 21 v 15:12 Ankur Sinha napsal(a): On Fri, Nov 05, 2021 14:51:44 +0100, Miro Hrončok wrote: On 05. 11. 21 14:13, Ankur Sinha wrote: Hi folks, I've been working with a few Outreachy candidates to help them learn packaging. We're using `fedpkg` as much as we can, since it's what we use to work with all packages after they're imported into Fedora. So, we first create git repo to work in, and after we write the spec, we iteratively use `fedpkg mockbuild` to run mock and test builds before running rpmlint and so on and submitting the package for review. Here, I noticed we get an srpm which contains the spec where the `%autorelease` and `%autochangelog` bits are already expanded. This is causing a couple of issues with reviews and imports: - this spec in the srpm now differs from the spec, and fedora-review will flag this difference---which is confusing for newcomers (and had me confused for a bit too) - after the review, when `fedpkg import` is used to initialise the SCM using the approved srpm, again this spec with `%autorelease` and `%autochangelog` already expanded is pulled in. Here's an example of a package we only imported recently where we didn't realise this: https://src.fedoraproject.org/rpms/python-glymur/blob/rawhide/f/python-glymur.spec This isn't necessarily a problem from a technical perspective, but it's a little annoying that one now has to remember to manually revert the spec back to use the macros before committing to SCM. If one has to manually tinker with the changelog etc., it defeats the purpose of the macros. Since we didn't realise this, the package is now not using `%autochangelog` and the first build has a release value that isn't 1: https://koji.fedoraproject.org/koji/packageinfo?packageID=34682 So we'll need to fix it (more work): https://docs.pagure.org/fedora-infra.rpmautospec/opting-in.html#for-existing-packages So, can anything be done to make this workflow better? Should we/can we disable these when using mockbuild, or add an option to do so that can be used for new packages to keep the value at 1? Or do we note that these macros should only be used right before import (but that means again editing the spec after running `fedpkg import` and more confusion for newcomers)? The %autorelease/%autochangelog macros assume we are in a git repository. Hence if the package is created in a git repository before it is imported into Fedora, we should probably teach the packagers to push those commits to Fedora when he package is approved, instead of using `fedpkg import` which will also throw away their git history. Hrm, but how would we do this? The new SCM repo that is created has a completely different commit tree. I guess we can add the new remote and And then rebase. This is script I use: ~~~ #!/bin/sh git checkout main git remote set-url origin ssh://vondr...@pkgs.fedoraproject.org/rpms/"$@" git fetch origin git branch main -t origin/main git rebase origin/main ~~~ I suppose we could teach `fedpkg import` to be able to import git history + tarball(s) rather than a SRPM. -- 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 on the list, report it: https://pagure.io/fedora-infrastructure
Re: Expansion of rpmautospec macros when building new packages
Dne 05. 11. 21 v 15:12 Ankur Sinha napsal(a): On Fri, Nov 05, 2021 14:51:44 +0100, Miro Hrončok wrote: On 05. 11. 21 14:13, Ankur Sinha wrote: Hi folks, I've been working with a few Outreachy candidates to help them learn packaging. We're using `fedpkg` as much as we can, since it's what we use to work with all packages after they're imported into Fedora. So, we first create git repo to work in, and after we write the spec, we iteratively use `fedpkg mockbuild` to run mock and test builds before running rpmlint and so on and submitting the package for review. Here, I noticed we get an srpm which contains the spec where the `%autorelease` and `%autochangelog` bits are already expanded. This is causing a couple of issues with reviews and imports: - this spec in the srpm now differs from the spec, and fedora-review will flag this difference---which is confusing for newcomers (and had me confused for a bit too) - after the review, when `fedpkg import` is used to initialise the SCM using the approved srpm, again this spec with `%autorelease` and `%autochangelog` already expanded is pulled in. Here's an example of a package we only imported recently where we didn't realise this: https://src.fedoraproject.org/rpms/python-glymur/blob/rawhide/f/python-glymur.spec This isn't necessarily a problem from a technical perspective, but it's a little annoying that one now has to remember to manually revert the spec back to use the macros before committing to SCM. If one has to manually tinker with the changelog etc., it defeats the purpose of the macros. Since we didn't realise this, the package is now not using `%autochangelog` and the first build has a release value that isn't 1: https://koji.fedoraproject.org/koji/packageinfo?packageID=34682 So we'll need to fix it (more work): https://docs.pagure.org/fedora-infra.rpmautospec/opting-in.html#for-existing-packages So, can anything be done to make this workflow better? Should we/can we disable these when using mockbuild, or add an option to do so that can be used for new packages to keep the value at 1? Or do we note that these macros should only be used right before import (but that means again editing the spec after running `fedpkg import` and more confusion for newcomers)? The %autorelease/%autochangelog macros assume we are in a git repository. Hence if the package is created in a git repository before it is imported into Fedora, we should probably teach the packagers to push those commits to Fedora when he package is approved, instead of using `fedpkg import` which will also throw away their git history. Hrm, but how would we do this? The new SCM repo that is created has a completely different commit tree. I guess we can add the new remote and And then rebase. This is script I use: ~~~ #!/bin/sh git checkout main git remote set-url origin ssh://vondr...@pkgs.fedoraproject.org/rpms/"$@" git fetch origin git branch main -t origin/main git rebase origin/main ~~~ Vít OpenPGP_signature Description: OpenPGP digital signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Expansion of rpmautospec macros when building new packages
On 05. 11. 21 15:12, Ankur Sinha wrote: On Fri, Nov 05, 2021 14:51:44 +0100, Miro Hrončok wrote: On 05. 11. 21 14:13, Ankur Sinha wrote: Hi folks, I've been working with a few Outreachy candidates to help them learn packaging. We're using `fedpkg` as much as we can, since it's what we use to work with all packages after they're imported into Fedora. So, we first create git repo to work in, and after we write the spec, we iteratively use `fedpkg mockbuild` to run mock and test builds before running rpmlint and so on and submitting the package for review. Here, I noticed we get an srpm which contains the spec where the `%autorelease` and `%autochangelog` bits are already expanded. This is causing a couple of issues with reviews and imports: - this spec in the srpm now differs from the spec, and fedora-review will flag this difference---which is confusing for newcomers (and had me confused for a bit too) - after the review, when `fedpkg import` is used to initialise the SCM using the approved srpm, again this spec with `%autorelease` and `%autochangelog` already expanded is pulled in. Here's an example of a package we only imported recently where we didn't realise this: https://src.fedoraproject.org/rpms/python-glymur/blob/rawhide/f/python-glymur.spec This isn't necessarily a problem from a technical perspective, but it's a little annoying that one now has to remember to manually revert the spec back to use the macros before committing to SCM. If one has to manually tinker with the changelog etc., it defeats the purpose of the macros. Since we didn't realise this, the package is now not using `%autochangelog` and the first build has a release value that isn't 1: https://koji.fedoraproject.org/koji/packageinfo?packageID=34682 So we'll need to fix it (more work): https://docs.pagure.org/fedora-infra.rpmautospec/opting-in.html#for-existing-packages So, can anything be done to make this workflow better? Should we/can we disable these when using mockbuild, or add an option to do so that can be used for new packages to keep the value at 1? Or do we note that these macros should only be used right before import (but that means again editing the spec after running `fedpkg import` and more confusion for newcomers)? The %autorelease/%autochangelog macros assume we are in a git repository. Hence if the package is created in a git repository before it is imported into Fedora, we should probably teach the packagers to push those commits to Fedora when he package is approved, instead of using `fedpkg import` which will also throw away their git history. Hrm, but how would we do this? The new SCM repo that is created has a completely different commit tree. I guess we can add the new remote and then do a force push for the first time, but that then will remove releng's initial commit. A rebase perhaps (not tested, and maybe not the best thing to do for newcomers at the start of a repo)? I use `fedpkg request-repo --no-initial-commit` for this. Unfortunately, it is currently broken on releng's side :/ (this will also mean that we need to drop the `fedpkg import` way of doing things or add additional notes there to the docs.) Sure. -- 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 on the list, report it: https://pagure.io/fedora-infrastructure
Fedora-Rawhide-20211105.n.0 compose check report
No missing expected images. Compose FAILS proposed Rawhide gating check! 24 of 43 required tests failed, 17 results missing openQA tests matching unsatisfied gating requirements shown with **GATING** below Failed openQA tests: 68/141 (aarch64), 108/206 (x86_64) New failures (same test not failed in Fedora-Rawhide-20211104.n.0): ID: 1053378 Test: aarch64 Server-raw_xz-raw.xz base_service_manipulation@uefi URL: https://openqa.fedoraproject.org/tests/1053378 ID: 1053400 Test: aarch64 Cloud_Base-qcow2-qcow2 base_service_manipulation@uefi URL: https://openqa.fedoraproject.org/tests/1053400 ID: 1053550 Test: aarch64 Server-dvd-iso install_vnc_server@uefi URL: https://openqa.fedoraproject.org/tests/1053550 ID: 1053551 Test: aarch64 Server-dvd-iso install_vnc_client@uefi URL: https://openqa.fedoraproject.org/tests/1053551 ID: 1053585 Test: aarch64 universal install_anaconda_text@uefi URL: https://openqa.fedoraproject.org/tests/1053585 ID: 1053714 Test: aarch64 universal install_serial_console@uefi URL: https://openqa.fedoraproject.org/tests/1053714 ID: 1053796 Test: x86_64 Server-dvd-iso install_vnc_server URL: https://openqa.fedoraproject.org/tests/1053796 ID: 1053799 Test: x86_64 Server-dvd-iso install_vncconnect_server URL: https://openqa.fedoraproject.org/tests/1053799 ID: 1053800 Test: aarch64 Server-dvd-iso install_vncconnect_client@uefi URL: https://openqa.fedoraproject.org/tests/1053800 ID: 1053801 Test: aarch64 Server-dvd-iso install_vncconnect_server@uefi URL: https://openqa.fedoraproject.org/tests/1053801 Old failures (same test failed in Fedora-Rawhide-20211104.n.0): ID: 1053201 Test: x86_64 Server-dvd-iso anaconda_help URL: https://openqa.fedoraproject.org/tests/1053201 ID: 1053204 Test: x86_64 Server-dvd-iso install_repository_hd_variation URL: https://openqa.fedoraproject.org/tests/1053204 ID: 1053244 Test: x86_64 Everything-boot-iso memory_check URL: https://openqa.fedoraproject.org/tests/1053244 ID: 1053246 Test: x86_64 Everything-boot-iso memory_check@uefi URL: https://openqa.fedoraproject.org/tests/1053246 ID: 1053247 Test: x86_64 Workstation-live-iso anaconda_help URL: https://openqa.fedoraproject.org/tests/1053247 ID: 1053255 Test: x86_64 Workstation-live-iso desktop_notifications_live URL: https://openqa.fedoraproject.org/tests/1053255 ID: 1053271 Test: x86_64 KDE-live-iso anaconda_help URL: https://openqa.fedoraproject.org/tests/1053271 ID: 1053273 Test: x86_64 KDE-live-iso desktop_notifications_live URL: https://openqa.fedoraproject.org/tests/1053273 ID: 1053293 Test: x86_64 Silverblue-dvd_ostree-iso anaconda_help URL: https://openqa.fedoraproject.org/tests/1053293 ID: 1053331 Test: aarch64 Server-dvd-iso anaconda_help@uefi URL: https://openqa.fedoraproject.org/tests/1053331 ID: 1053412 Test: x86_64 universal upgrade_2_desktop_64bit URL: https://openqa.fedoraproject.org/tests/1053412 ID: 1053413 Test: x86_64 universal upgrade_2_desktop_encrypted_64bit URL: https://openqa.fedoraproject.org/tests/1053413 ID: 1053416 Test: x86_64 universal upgrade_2_server_domain_controller URL: https://openqa.fedoraproject.org/tests/1053416 ID: 1053430 Test: x86_64 universal upgrade_2_kde_64bit URL: https://openqa.fedoraproject.org/tests/1053430 ID: 1053456 Test: x86_64 universal upgrade_desktop_64bit URL: https://openqa.fedoraproject.org/tests/1053456 ID: 1053457 Test: x86_64 universal upgrade_desktop_encrypted_64bit URL: https://openqa.fedoraproject.org/tests/1053457 ID: 1053465 Test: x86_64 universal upgrade_kde_64bit URL: https://openqa.fedoraproject.org/tests/1053465 ID: 1053468 Test: x86_64 universal upgrade_server_domain_controller URL: https://openqa.fedoraproject.org/tests/1053468 ID: 1053480 Test: x86_64 universal upgrade_2_realmd_client URL: https://openqa.fedoraproject.org/tests/1053480 ID: 1053483 Test: x86_64 universal upgrade_realmd_client URL: https://openqa.fedoraproject.org/tests/1053483 ID: 1053485 Test: aarch64 universal upgrade_2_desktop_64bit@uefi URL: https://openqa.fedoraproject.org/tests/1053485 ID: 1053487 Test: aarch64 universal upgrade_2_server_domain_controller@uefi URL: https://openqa.fedoraproject.org/tests/1053487 ID: 1053507 Test: aarch64 universal upgrade_server_domain_controller@uefi URL: https://openqa.fedoraproject.org/tests/1053507 ID: 1053512 Test: aarch64 universal upgrade_realmd_client@uefi URL: https://openqa.fedoraproject.org/tests/1053512 ID: 1053520 Test: aarch64 universal upgrade_desktop_64bit@uefi URL: https://openqa.fedoraproject.org/tests/1053520 ID: 1053522 Test: aarch64 universal upgrade_2_desktop_encrypted_64bit@uefi URL: https://openqa.fedoraproject.org/tests/1053522 ID: 1053532 Test: aarch64 universal upgrade_desktop_encrypted_64bit@uefi URL: https://openqa.fedoraproject.org/tests/1053532 ID: 1053533 Test: aarch64 universal upgrade_2_realmd_client@uefi URL:
Re: Expansion of rpmautospec macros when building new packages
On Fri, Nov 05, 2021 14:51:44 +0100, Miro Hrončok wrote: > On 05. 11. 21 14:13, Ankur Sinha wrote: > > Hi folks, > > > > I've been working with a few Outreachy candidates to help them learn > > packaging. We're using `fedpkg` as much as we can, since it's what we > > use to work with all packages after they're imported into Fedora. > > > > So, we first create git repo to work in, and after we write the spec, > > we iteratively use `fedpkg mockbuild` to run mock and test builds before > > running rpmlint and so on and submitting the package for review. Here, I > > noticed we get an srpm which contains the spec where the `%autorelease` > > and `%autochangelog` bits are already expanded. > > > > This is causing a couple of issues with reviews and imports: > > > > - this spec in the srpm now differs from the spec, and fedora-review > >will flag this difference---which is confusing for newcomers (and had > >me confused for a bit too) > > > > - after the review, when `fedpkg import` is used to initialise the SCM > >using the approved srpm, again this spec with `%autorelease` and > >`%autochangelog` already expanded is pulled in. Here's an example of a > >package we only imported recently where we didn't realise this: > > > > https://src.fedoraproject.org/rpms/python-glymur/blob/rawhide/f/python-glymur.spec > > > > This isn't necessarily a problem from a technical perspective, but it's > > a little annoying that one now has to remember to manually revert the > > spec back to use the macros before committing to SCM. If one has to > > manually tinker with the changelog etc., it defeats the purpose of the > > macros. > > > > Since we didn't realise this, the package is now not using > > `%autochangelog` and the first build has a release value that isn't 1: > > https://koji.fedoraproject.org/koji/packageinfo?packageID=34682 > > > > So we'll need to fix it (more work): > > https://docs.pagure.org/fedora-infra.rpmautospec/opting-in.html#for-existing-packages > > > > So, can anything be done to make this workflow better? Should we/can we > > disable these when using mockbuild, or add an option to do so that can > > be used for new packages to keep the value at 1? Or do we note that > > these macros should only be used right before import (but that means > > again editing the spec after running `fedpkg import` and more confusion > > for newcomers)? > > The %autorelease/%autochangelog macros assume we are in a git repository. > > Hence if the package is created in a git repository before it is imported > into Fedora, we should probably teach the packagers to push those commits to > Fedora when he package is approved, instead of using `fedpkg import` which > will also throw away their git history. Hrm, but how would we do this? The new SCM repo that is created has a completely different commit tree. I guess we can add the new remote and then do a force push for the first time, but that then will remove releng's initial commit. A rebase perhaps (not tested, and maybe not the best thing to do for newcomers at the start of a repo)? (this will also mean that we need to drop the `fedpkg import` way of doing things or add additional notes there to the docs.) -- Thanks, Regards, Ankur Sinha "FranciscoD" (He / Him / His) | https://fedoraproject.org/wiki/User:Ankursinha Time zone: Europe/London signature.asc Description: PGP signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Expansion of rpmautospec macros when building new packages
On 05. 11. 21 14:13, Ankur Sinha wrote: Hi folks, I've been working with a few Outreachy candidates to help them learn packaging. We're using `fedpkg` as much as we can, since it's what we use to work with all packages after they're imported into Fedora. So, we first create git repo to work in, and after we write the spec, we iteratively use `fedpkg mockbuild` to run mock and test builds before running rpmlint and so on and submitting the package for review. Here, I noticed we get an srpm which contains the spec where the `%autorelease` and `%autochangelog` bits are already expanded. This is causing a couple of issues with reviews and imports: - this spec in the srpm now differs from the spec, and fedora-review will flag this difference---which is confusing for newcomers (and had me confused for a bit too) - after the review, when `fedpkg import` is used to initialise the SCM using the approved srpm, again this spec with `%autorelease` and `%autochangelog` already expanded is pulled in. Here's an example of a package we only imported recently where we didn't realise this: https://src.fedoraproject.org/rpms/python-glymur/blob/rawhide/f/python-glymur.spec This isn't necessarily a problem from a technical perspective, but it's a little annoying that one now has to remember to manually revert the spec back to use the macros before committing to SCM. If one has to manually tinker with the changelog etc., it defeats the purpose of the macros. Since we didn't realise this, the package is now not using `%autochangelog` and the first build has a release value that isn't 1: https://koji.fedoraproject.org/koji/packageinfo?packageID=34682 So we'll need to fix it (more work): https://docs.pagure.org/fedora-infra.rpmautospec/opting-in.html#for-existing-packages So, can anything be done to make this workflow better? Should we/can we disable these when using mockbuild, or add an option to do so that can be used for new packages to keep the value at 1? Or do we note that these macros should only be used right before import (but that means again editing the spec after running `fedpkg import` and more confusion for newcomers)? The %autorelease/%autochangelog macros assume we are in a git repository. Hence if the package is created in a git repository before it is imported into Fedora, we should probably teach the packagers to push those commits to Fedora when he package is approved, instead of using `fedpkg import` which will also throw away their git history. -- 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 on the list, report it: https://pagure.io/fedora-infrastructure
[Bug 2020636] New: perl-HTTP-Tiny-0.080 is available
https://bugzilla.redhat.com/show_bug.cgi?id=2020636 Bug ID: 2020636 Summary: perl-HTTP-Tiny-0.080 is available Product: Fedora Version: rawhide Status: NEW Component: perl-HTTP-Tiny Keywords: FutureFeature, Triaged Assignee: jples...@redhat.com Reporter: upstream-release-monitor...@fedoraproject.org QA Contact: extras...@fedoraproject.org CC: jples...@redhat.com, mspa...@redhat.com, perl-devel@lists.fedoraproject.org, ppi...@redhat.com Target Milestone: --- Classification: Fedora Latest upstream release: 0.080 Current version/release in rawhide: 0.078-1.fc35 URL: http://search.cpan.org/dist/HTTP-Tiny/ Please consult the package updates policy before you issue an update to a stable branch: https://docs.fedoraproject.org/en-US/fesco/Updates_Policy/ More information about the service that created this bug can be found at: https://fedoraproject.org/wiki/Upstream_release_monitoring Please keep in mind that with any upstream change, there may also be packaging changes that need to be made. Specifically, please remember that it is your responsibility to review the new version to ensure that the licensing is still correct and that no non-free or legally problematic items have been added upstream. Based on the information from anitya: https://release-monitoring.org/project/2982/ -- You are receiving this mail because: You are on the CC list for the bug. https://bugzilla.redhat.com/show_bug.cgi?id=2020636 ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Planned Outage - build systems ( koji, osbs, mbs, src, pdc, kojipkgs, odcs, registriy) - 2021-11-09 17:00 UTC
Planned Outage - build systems ( koji, osbs, mbs, src, pdc, kojipkgs, odcs, registriy) - 2021-11-09 17:00 UTC There will be an outage starting at 2021-11-09 17:00 UTC, which will last approximately 4 hours. To convert UTC to your local time, take a look at http://fedoraproject.org/wiki/Infrastructure/UTCHowto or run: date -d '2021-11-09 17:00UTC' Reason for outage: We will be doing several maint tasks during this outage: All the s390x builders will be moving from the current z13 maintframe to a z15 mainframe. koji hub and builders will be updated from 1.25.1 to 1.26.1 Updates will be applied to all build servers and reboots done to the latest kernel. Maintainers are advised to avoid starting builds before the outage that won't complete before the outage is over. Some builds may restart or need to be resubmitted if they are running during the maint window. Affected Services: koji (both hub and builders) mbs - module build service odcs - on demand compose service osbs - openshift build service pdc - product def center src - dist-git/pagure kojipkgs - pkgs stored on koji registry - container registries Ticket Link: https://pagure.io/fedora-infrastructure/issue/10302 Please join #fedora-admin or #fedora-noc on irc.libera.chat or add comments to the ticket for this outage above. signature.asc Description: PGP signature ___ devel-announce mailing list -- devel-annou...@lists.fedoraproject.org To unsubscribe send an email to devel-announce-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-annou...@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
Planned Outage - bodhi.fedoraproject.org - 2021-11-08 10:00 UTC
Planned Outage - bodhi.fedoraproject.org - 2021-11-08 10:00 UTC There will be an outage starting on monday at 2021-11-08 10:00 UTC, which will last approximately 2 hours. To convert UTC to your local time, take a look at http://fedoraproject.org/wiki/Infrastructure/UTCHowto or run: date -d '2021-11-08 10:00UTC' Reason for outage: Bodhi will be upgraded to 5.7.1. Affected Services: bodhi / updates.fedoraproject.org may be down or unresponsive during the upgrade window Ticket Link: https://pagure.io/fedora-infrastructure/issue/10310 Please join #fedora-admin or #fedora-noc on chat.libera.net or add comments to the ticket for this outage above. signature.asc Description: PGP signature ___ devel-announce mailing list -- devel-annou...@lists.fedoraproject.org To unsubscribe send an email to devel-announce-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-annou...@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
Planned Outage - build systems ( koji, osbs, mbs, src, pdc, kojipkgs, odcs, registriy) - 2021-11-09 17:00 UTC
Planned Outage - build systems ( koji, osbs, mbs, src, pdc, kojipkgs, odcs, registriy) - 2021-11-09 17:00 UTC There will be an outage starting at 2021-11-09 17:00 UTC, which will last approximately 4 hours. To convert UTC to your local time, take a look at http://fedoraproject.org/wiki/Infrastructure/UTCHowto or run: date -d '2021-11-09 17:00UTC' Reason for outage: We will be doing several maint tasks during this outage: All the s390x builders will be moving from the current z13 maintframe to a z15 mainframe. koji hub and builders will be updated from 1.25.1 to 1.26.1 Updates will be applied to all build servers and reboots done to the latest kernel. Maintainers are advised to avoid starting builds before the outage that won't complete before the outage is over. Some builds may restart or need to be resubmitted if they are running during the maint window. Affected Services: koji (both hub and builders) mbs - module build service odcs - on demand compose service osbs - openshift build service pdc - product def center src - dist-git/pagure kojipkgs - pkgs stored on koji registry - container registries Ticket Link: https://pagure.io/fedora-infrastructure/issue/10302 Please join #fedora-admin or #fedora-noc on irc.libera.chat or add comments to the ticket for this outage above. signature.asc Description: PGP signature ___ devel-announce mailing list -- devel-announce@lists.fedoraproject.org To unsubscribe send an email to devel-announce-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-announce@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Planned Outage - bodhi.fedoraproject.org - 2021-11-08 10:00 UTC
Planned Outage - bodhi.fedoraproject.org - 2021-11-08 10:00 UTC There will be an outage starting on monday at 2021-11-08 10:00 UTC, which will last approximately 2 hours. To convert UTC to your local time, take a look at http://fedoraproject.org/wiki/Infrastructure/UTCHowto or run: date -d '2021-11-08 10:00UTC' Reason for outage: Bodhi will be upgraded to 5.7.1. Affected Services: bodhi / updates.fedoraproject.org may be down or unresponsive during the upgrade window Ticket Link: https://pagure.io/fedora-infrastructure/issue/10310 Please join #fedora-admin or #fedora-noc on chat.libera.net or add comments to the ticket for this outage above. signature.asc Description: PGP signature ___ devel-announce mailing list -- devel-announce@lists.fedoraproject.org To unsubscribe send an email to devel-announce-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-announce@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Expansion of rpmautospec macros when building new packages
Hi folks, I've been working with a few Outreachy candidates to help them learn packaging. We're using `fedpkg` as much as we can, since it's what we use to work with all packages after they're imported into Fedora. So, we first create git repo to work in, and after we write the spec, we iteratively use `fedpkg mockbuild` to run mock and test builds before running rpmlint and so on and submitting the package for review. Here, I noticed we get an srpm which contains the spec where the `%autorelease` and `%autochangelog` bits are already expanded. This is causing a couple of issues with reviews and imports: - this spec in the srpm now differs from the spec, and fedora-review will flag this difference---which is confusing for newcomers (and had me confused for a bit too) - after the review, when `fedpkg import` is used to initialise the SCM using the approved srpm, again this spec with `%autorelease` and `%autochangelog` already expanded is pulled in. Here's an example of a package we only imported recently where we didn't realise this: https://src.fedoraproject.org/rpms/python-glymur/blob/rawhide/f/python-glymur.spec This isn't necessarily a problem from a technical perspective, but it's a little annoying that one now has to remember to manually revert the spec back to use the macros before committing to SCM. If one has to manually tinker with the changelog etc., it defeats the purpose of the macros. Since we didn't realise this, the package is now not using `%autochangelog` and the first build has a release value that isn't 1: https://koji.fedoraproject.org/koji/packageinfo?packageID=34682 So we'll need to fix it (more work): https://docs.pagure.org/fedora-infra.rpmautospec/opting-in.html#for-existing-packages So, can anything be done to make this workflow better? Should we/can we disable these when using mockbuild, or add an option to do so that can be used for new packages to keep the value at 1? Or do we note that these macros should only be used right before import (but that means again editing the spec after running `fedpkg import` and more confusion for newcomers)? -- Thanks, Regards, Ankur Sinha "FranciscoD" (He / Him / His) | https://fedoraproject.org/wiki/User:Ankursinha Time zone: Europe/London signature.asc Description: PGP signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Fedora rawhide compose report: 20211105.n.0 changes
OLD: Fedora-Rawhide-20211104.n.0 NEW: Fedora-Rawhide-20211105.n.0 = SUMMARY = Added images:0 Dropped images: 0 Added packages: 4 Dropped packages:0 Upgraded packages: 116 Downgraded packages: 0 Size of added packages: 2.74 MiB Size of dropped packages:0 B Size of upgraded packages: 5.09 GiB Size of downgraded packages: 0 B Size change of upgraded packages: -52.44 MiB Size change of downgraded packages: 0 B = ADDED IMAGES = = DROPPED IMAGES = = ADDED PACKAGES = Package: python-glymur-0.9.4-9.fc36 Summary: Interface to the OpenJPEG library for working with JPEG 2000 files RPMs:python3-glymur Size:2.65 MiB Package: python-pybv-0.6.0-1.fc36 Summary: A lightweight I/O utility for the BrainVision data format RPMs:python3-pybv Size:33.67 KiB Package: python-requests-exoscale-auth-1.1.2-1.fc36 Summary: Exoscale APIs support for Python-Requests RPMs:python3-requests-exoscale-auth Size:13.04 KiB Package: rust-libblkid-rs-0.1.1-1.fc36 Summary: High level bindings for libblkid RPMs:rust-libblkid-rs+default-devel rust-libblkid-rs+deprecated-devel rust-libblkid-rs-devel Size:42.47 KiB = DROPPED PACKAGES = = UPGRADED PACKAGES = Package: InsightToolkit-4.13.3-8.fc36 Old package: InsightToolkit-4.13.3-7.fc36 Summary: Insight Toolkit library for medical image processing RPMs: InsightToolkit InsightToolkit-devel InsightToolkit-doc InsightToolkit-examples InsightToolkit-vtk InsightToolkit-vtk-devel Size: 76.57 MiB Size change: 11.79 KiB Changelog: * Thu Nov 04 2021 Benjamin A. Beasley - 4.13.3-8 - Remove python2-devel BR (fix RHBZ#1807494), as it is no longer required Package: ansible-collection-community-general-4.0.0-1.fc36 Old package: ansible-collection-community-general-3.8.0-1.fc36 Summary: Modules and plugins supported by Ansible community RPMs: ansible-collection-community-general Size: 1.34 MiB Size change: -145.71 KiB Changelog: * Wed Nov 03 2021 Sagi Shnaidman (@sshnaidm) - 4.0.0-1 - Update to 4.0.0 Package: apache-commons-cli-1.5.0-1.fc36 Old package: apache-commons-cli-1.4-14.fc35 Summary: Command Line Interface Library for Java RPMs: apache-commons-cli apache-commons-cli-javadoc Size: 238.54 KiB Size change: -141.18 KiB Changelog: * Thu Nov 04 2021 Christian Schuermann 1.5.0-1 - Update to upstream version 1.5.0 Package: awscli-1.21.11-1.fc36 Old package: awscli-1.21.10-1.fc36 Summary: Universal Command Line Environment for AWS RPMs: awscli Size: 2.11 MiB Size change: 191 B Changelog: * Thu Nov 04 2021 Gwyn Ciesla - 1.21.11-1 - 1.21.11 Package: cinnamon-5.0.7-1.fc36 Old package: cinnamon-5.0.6-1.fc36 Summary: Window management and application launching for GNOME RPMs: cinnamon cinnamon-devel-doc Size: 8.64 MiB Size change: 3.84 KiB Changelog: * Thu Nov 04 2021 Leigh Scott - 5.0.7-1 - Update to 5.0.7 release Package: cinnamon-screensaver-5.0.7-1.fc36 Old package: cinnamon-screensaver-5.0.6-3.fc36 Summary: Cinnamon Screensaver RPMs: cinnamon-screensaver Size: 1.03 MiB Size change: 858 B Changelog: * Thu Nov 04 2021 Leigh Scott - 5.0.7-1 - Update to 5.0.7 release Package: cldr-emoji-annotation-1:40.0-3.fc36 Old package: cldr-emoji-annotation-1:40-2.fc36 Summary: Emoji annotation files in CLDR RPMs: cldr-emoji-annotation cldr-emoji-annotation-devel cldr-emoji-annotation-dtd Size: 6.23 MiB Size change: -75.74 KiB Changelog: * Fri Oct 29 2021 Takao Fujiwara - 1:40-2 - Bump to release-40 * Fri Oct 08 2021 Takao Fujiwara - 1:40~beta2-1 - Bump to release-40-beta2 * Thu Sep 02 2021 Takao Fujiwara - 1:40~alpha2-1 - Bump to release-40-alpha2 * Mon Aug 23 2021 Takao Fujiwara - 1:40~alpha1-1 - Bump to release-40-alpha1 * Wed Jul 21 2021 Fedora Release Engineering - 1:39-2 - Rebuilt for https://fedoraproject.org/wiki/Fedora_35_Mass_Rebuild * Fri Apr 09 2021 Takao Fujiwara - 1:39 - Bump to release-39 * Tue Apr 06 2021 Takao Fujiwara - 1:39~beta2-1 - Bump to release-39-beta2 * Thu Mar 25 2021 Takao Fujiwara - 1:39~beta-1 - Bump to release-39-beta * Wed Mar 03 2021 Takao Fujiwara - 1:39~alpha4-1 - Bump to release-39-alpha4 * Wed Feb 17 2021 Takao Fujiwara - 1:39~alpha1-1 - Bump to release-39-alpha1 * Mon Feb 08 2021 Takao Fujiwara - 1:39~alpha0-1 - Bump release-39-alpha0 * Tue Jan 26 2021 Fedora Release Engineering - 1:38-2.1 - Rebuilt for https://fedoraproject.org/wiki/Fedora_34_Mass_Rebuild * Fri Dec 18 2020 Takao Fujiwara - 1:38-1.1 - Bump to release-38-1 * Sun Nov 01 2020 Takao Fujiwara - 1:38-1 - Bump release-38 * Thu Oct 22 2020 Takao Fujiwara - 1:38~beta3-1 - Bump release-38-beta3 * Wed Oct 14 2020 Takao Fujiwara - 1:38~beta2-1 - Bump release-38-beta2 * Mon Sep
Re: F36 Change: Remove .la files from buildroot (Self-Contained Change proposal)
On Fri, Nov 5, 2021 at 5:47 AM Timm Bäder wrote: > > > If this change is implemented, manual removal in packages becomes > unnecessary. > > Will you do a 'mass change' sweep to drop those removals? > > I've already looked at all the packages I listed, so looking at them again > shouldn't be > a problem. > But that's just the list of packages that currently ship .la files and not > the list of packages > that *don't* ship them because they successfully remove them. I don't have > a list for > that and I'm not sure how I would generate one. > You'd have to grep through all the spec files. Most of the time 'find' is used so you want to return all lines with 'find' and then grep through those results for 'la'. Thanks, Richard ___ 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
[Bug 2020382] perl-CBOR-XS-1.86 is available
https://bugzilla.redhat.com/show_bug.cgi?id=2020382 --- Comment #3 from Fedora Update System --- FEDORA-2021-441f29618c has been submitted as an update to Fedora 34. https://bodhi.fedoraproject.org/updates/FEDORA-2021-441f29618c -- You are receiving this mail because: You are on the CC list for the bug. https://bugzilla.redhat.com/show_bug.cgi?id=2020382 ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
[Bug 2020382] perl-CBOR-XS-1.86 is available
https://bugzilla.redhat.com/show_bug.cgi?id=2020382 --- Comment #2 from Fedora Update System --- FEDORA-2021-0c4f7b2691 has been submitted as an update to Fedora 35. https://bodhi.fedoraproject.org/updates/FEDORA-2021-0c4f7b2691 -- You are receiving this mail because: You are on the CC list for the bug. https://bugzilla.redhat.com/show_bug.cgi?id=2020382 ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
[Bug 2020382] perl-CBOR-XS-1.86 is available
https://bugzilla.redhat.com/show_bug.cgi?id=2020382 Petr Pisar changed: What|Removed |Added Status|ASSIGNED|MODIFIED Fixed In Version||perl-CBOR-XS-1.86-1.fc36 --- Comment #1 from Petr Pisar --- A bug-fix release suitable for Fedora ≥ 34. -- You are receiving this mail because: You are on the CC list for the bug. https://bugzilla.redhat.com/show_bug.cgi?id=2020382 ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Possibly off topic: Slack will discontinue packaging for Fedora
On 05/11/2021 07:04, Joe Doss wrote: Thanks for the suggestion but I prefer the official client for work. You can also use the official Web version in any modern web browser (Firefox or Chromium). -- Sincerely, Vitaly Zaitsev (vit...@easycoding.org) ___ 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
Re: Possibly off topic: Slack will discontinue packaging for Fedora
On 05/11/2021 01:23, Gordon Messmer wrote: I don't know if that's of interest to Fedora, as an organization, but on the off-chance that it is: Is anyone in a position to ask someone at Slack about that decision? And whether there's anything that Fedora can do to make publishing that package more feasible? Always use Flatpaks with maximum isolation for such proprietary software. -- Sincerely, Vitaly Zaitsev (vit...@easycoding.org) ___ 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
Re: F36 Change: Remove .la files from buildroot (Self-Contained Change proposal)
> If this change is implemented, manual removal in packages becomes unnecessary. > Will you do a 'mass change' sweep to drop those removals? I've already looked at all the packages I listed, so looking at them again shouldn't be a problem. But that's just the list of packages that currently ship .la files and not the list of packages that *don't* ship them because they successfully remove them. I don't have a list for that and I'm not sure how I would generate one. ___ 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
Re: F36 Change: Remove .la files from buildroot (Self-Contained Change proposal)
> This looks like it risks deleting more files than intended. If some > package uses country codes or domain names in filenames, then this > change could silently delete files specific to Laos. None of the packages I inspected looked like they would do this, but I opened https://github.com/rpm-software-management/rpm/pull/1819 upstream to try to minimize the risk. ___ 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
[Bug 2020382] perl-CBOR-XS-1.86 is available
https://bugzilla.redhat.com/show_bug.cgi?id=2020382 Petr Pisar changed: What|Removed |Added CC|de...@fateyev.com, | |ppi...@redhat.com | Status|NEW |ASSIGNED Doc Type|--- |If docs needed, set a value -- You are receiving this mail because: You are on the CC list for the bug. https://bugzilla.redhat.com/show_bug.cgi?id=2020382 ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Fedora-Cloud-34-20211105.0 compose check report
No missing expected images. Soft failed openQA tests: 1/8 (x86_64), 1/8 (aarch64) (Tests completed, but using a workaround for a known bug) Old soft failures (same test soft failed in Fedora-Cloud-34-20211104.0): ID: 1053178 Test: x86_64 Cloud_Base-qcow2-qcow2 cloud_autocloud URL: https://openqa.fedoraproject.org/tests/1053178 ID: 1053179 Test: aarch64 Cloud_Base-qcow2-qcow2 cloud_autocloud@uefi URL: https://openqa.fedoraproject.org/tests/1053179 Passed openQA tests: 7/8 (x86_64), 7/8 (aarch64) -- Mail generated by check-compose: https://pagure.io/fedora-qa/check-compose ___ 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
Fedora-Cloud-35-20211105.0 compose check report
No missing expected images. Soft failed openQA tests: 1/8 (x86_64), 1/8 (aarch64) (Tests completed, but using a workaround for a known bug) Old soft failures (same test soft failed in Fedora-Cloud-35-20211104.0): ID: 1053162 Test: x86_64 Cloud_Base-qcow2-qcow2 cloud_autocloud URL: https://openqa.fedoraproject.org/tests/1053162 ID: 1053163 Test: aarch64 Cloud_Base-qcow2-qcow2 cloud_autocloud@uefi URL: https://openqa.fedoraproject.org/tests/1053163 Passed openQA tests: 7/8 (x86_64), 7/8 (aarch64) -- Mail generated by check-compose: https://pagure.io/fedora-qa/check-compose ___ 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
CPE Weekly Update - Week of November 1st - 5th
Hi everyone, This is a weekly report from the CPE (Community Platform Engineering) Team. If you have any questions or feedback, please respond to this report or contact us on #redhat-cpe channel on libera.chat (https://libera.chat/). If you wish to read this in rendered markdown, check the post on Fedora community blog (waiting for approval, will work later): https://communityblog.fedoraproject.org/cpe-weekly-update---week-of-november-1st---5th/ # Highlights of the week ## Infrastructure & Release Engineering Goal of this Initiative --- Purpose of this team is to take care of day to day business regarding CentOS and Fedora Infrastructure and Fedora release engineering work. It’s responsible for services running in Fedora and CentOS infrastructure and preparing things for the new Fedora release (mirrors, mass branching, new namespaces etc.). The ARC (Advance Reconaissance Crew), which is a subset of the team, investigates possible initiatives that CPE might take on. Update -- * Mini-initiative for docs ( https://pagure.io/fedora-infrastructure/issue/9892) migration going well * ARC is now focused on Bodhi improvements! ### Fedora Infra * F35 is out smoothly! * openqa power9 box is back up and working along with it’s mgmt interface * 67 issues, should go down a bit next week * 17 open ansible PR’s, should be 0 next week ### CentOS Infra including CentOS CI * Business as usual ### Release Engineering * Issue cleanup in the releng tracker * Business as usual ## CentOS Stream Goal of this Initiative --- This initiative is working on CentOS Stream/Emerging RHEL to make this new distribution a reality. The goal of this initiative is to prepare the ecosystem for the new CentOS Stream. Updates --- * Stream 9 mirror links on the website ( https://www.centos.org/centos-stream/#tab-3)! * Stream 9 CI for SIGs has aarch64 boxes * Brainstorming around c8s and c9s processes getting closer together * Working on cleaning up old qcow2 images and old RPMs * Finishing up DistroBuildSync for ELN * Finishing up Content Resolver buildroot integration * Business as usual ## Datanommer/Datagrepper V.2 Goal of this Initiative --- The datanommer and datagrepper stacks are currently relying on fedmsg which we want to deprecate. These two applications need to be ported off fedmsg to fedora-messaging. As these applications are 'old-timers' in the fedora infrastructure, we would also like to look at optimizing the database or potentially redesigning it to better suit the current infrastructure needs. For a phase two, we would like to focus on a DB overhaul. Updates --- * Import still running! (20%) ## CentOS Duffy CI Goal of this Initiative --- Duffy is a system within CentOS CI Infra which allows tenants to provision and access bare metal resources of multiple architectures for the purposes of CI testing. We need to add the ability to checkout VMs in CentOS CI in Duffy. We have OpenNebula hypervisor available, and have started developing playbooks which can be used to create VMs using the OpenNebula API, but due to the current state of how Duffy is deployed, we are blocked with new dev work to add the VM checkout functionality. Updates --- * CI: Dependabot, enable workflow dispatch to re-run tests * Work in progress: - Database models: a diagram and code - Logging (expletive deleted) - Configuration framework ## FCOS OpenShift migration Goal of this Initiative --- Move current Fedora CoreOS pipeline from the centos-ci OCP4 cluster to the newly deployed fedora infra OCP4 cluster. Updates --- * Pull request (https://pagure.io/fedora-infra/ansible/pull-request/839#), which creates project, group, rolebindings to permit the FCOS team access to the OCP4 staging cluster in order to deploy the pipeline, merged ## EPEL Goal of this initiative --- Extra Packages for Enterprise Linux (or EPEL) is a Fedora Special Interest Group that creates, maintains, and manages a high quality set of additional packages for Enterprise Linux, including, but not limited to, Red Hat Enterprise Linux (RHEL), CentOS and Scientific Linux (SL), Oracle Linux (OL). EPEL packages are usually based on their Fedora counterparts and will never conflict with or replace packages in the base Enterprise Linux distributions. EPEL uses much of the same infrastructure as Fedora, including buildsystem, bugzilla instance, updates manager, mirror manager and more. Updates --- * epel9-next configured in koji * Multiple tools configured/updated to support epel9/epel9-next (fedpkg, fedscm-admin, robosignatory, distribution-gpg-keys, mock-core-configs, etc.) * Blocked waiting for migration of Fedora s390x builders to z15 (scheduled for 2021-11-09) * Meetings with multiple stakeholders and potential contributors to plan future work * EPEL docs migrated from Fedora wiki to docs.fp.o (
Fedora-Cloud-33-20211105.0 compose check report
No missing expected images. Soft failed openQA tests: 1/8 (x86_64), 1/8 (aarch64) (Tests completed, but using a workaround for a known bug) Old soft failures (same test soft failed in Fedora-Cloud-33-20211104.0): ID: 1053143 Test: x86_64 Cloud_Base-qcow2-qcow2 cloud_autocloud URL: https://openqa.fedoraproject.org/tests/1053143 ID: 1053144 Test: aarch64 Cloud_Base-qcow2-qcow2 cloud_autocloud@uefi URL: https://openqa.fedoraproject.org/tests/1053144 Passed openQA tests: 7/8 (x86_64), 7/8 (aarch64) -- Mail generated by check-compose: https://pagure.io/fedora-qa/check-compose ___ 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
[Bug 1011333] PerlIO::via leaks a foreign memory
https://bugzilla.redhat.com/show_bug.cgi?id=1011333 Jitka Plesnikova changed: What|Removed |Added Version|33 |rawhide -- You are receiving this mail because: You are on the CC list for the bug. https://bugzilla.redhat.com/show_bug.cgi?id=1011333 ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
[Bug 1007199] perl segfaults when pushing a glob to a thread-shared array
https://bugzilla.redhat.com/show_bug.cgi?id=1007199 Jitka Plesnikova changed: What|Removed |Added Version|33 |rawhide -- You are receiving this mail because: You are on the CC list for the bug. https://bugzilla.redhat.com/show_bug.cgi?id=1007199 ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
[Bug 1807479] Upgrade perl-MooX-late to 0.100
https://bugzilla.redhat.com/show_bug.cgi?id=1807479 Jitka Plesnikova changed: What|Removed |Added Version|33 |rawhide -- You are receiving this mail because: You are on the CC list for the bug. https://bugzilla.redhat.com/show_bug.cgi?id=1807479 ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
[Bug 2018102] stompclt-1.7 is available
https://bugzilla.redhat.com/show_bug.cgi?id=2018102 Fedora Update System changed: What|Removed |Added Fixed In Version|stompclt-1.7-1.el8 |stompclt-1.7-1.el8 |stompclt-1.7-1.fc35 |stompclt-1.7-1.fc35 |stompclt-1.7-1.fc34 |stompclt-1.7-1.fc34 |stompclt-1.7-1.el7 |stompclt-1.7-1.el7 ||stompclt-1.7-1.fc33 --- Comment #14 from Fedora Update System --- FEDORA-2021-01fdca has been pushed to the Fedora 33 stable repository. If problem still persists, please make note of it in this bug report. -- You are receiving this mail because: You are on the CC list for the bug. https://bugzilla.redhat.com/show_bug.cgi?id=2018102 ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Possibly off topic: Slack will discontinue packaging for Fedora
On 11/5/21 12:41 AM, Benson Muite wrote: The Mattermost client is open source and will connect to Slack. There are a number of packages in copr: https://copr.fedorainfracloud.org/coprs/fulltext/?fulltext=mattermost Thanks for the suggestion but I prefer the official client for work. Joe -- Joe Doss j...@solidadmin.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 on the list, report it: https://pagure.io/fedora-infrastructure
