[389-devel] 389 DS nightly 2020-01-29 - 96% PASS
https://fedorapeople.org/groups/389ds/ci/nightly/2020/01/29/report-389-ds-base-1.4.3.2-20200129git8a3cea6.fc31.x86_64.html ___ 389-devel mailing list -- 389-devel@lists.fedoraproject.org To unsubscribe send an email to 389-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/389-devel@lists.fedoraproject.org
Re: Review swaps (antlr4 reboot)
Hi Fabio, On Tue, Jan 28, 2020 at 2:42 AM Fabio Valentini wrote: > I'll take a look at your review requests. I've been steeping in Java > packaging for so long that I might as well do it ;) Thank you! I'm glad to have your expert eye take a look. > I'll have some simple packages for you to review in return. I'm on it! Regards, -- Jerry James http://www.jamezone.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
Review swaps - practrand - Software package for the Randon number generation & testing
Hi, I have a simple package for review. It's called practrand - a Software package for the Randon number generation & testing https://bugzilla.redhat.com/show_bug.cgi?id=1795461 I offer to review some simple package in return. Thanks! Jirka ___ 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
Re: What would it take to drop release and changelog from our spec files? (and do we want to?)
On Tue, Jan 28, 2020 at 6:12 PM Stasiek Michalski wrote:
>
>
> On Tue, Jan 28, 2020 at 23:57, Dan Čermák
> wrote:
> > Neal Gompa writes:
> >
> >> On Tue, Jan 28, 2020 at 7:27 AM Pierre-Yves Chibon
> >> wrote:
> >>>
> >>> On Fri, Jan 10, 2020 at 09:54:59PM -0500, Neal Gompa wrote:
> >>> > On Fri, Jan 10, 2020 at 11:37 AM Pierre-Yves Chibon
> >>> wrote:
> >>> > >
> >>> > >
> >>> > > The release field would need to be set by koji ignoring
> >>> whatever is in the spec
> >>> > > file. How do we want to do this?
> >>> > > - Based on dates?
> >>> > > - Using an always increasing integer?
> >>> > > - Using the number of successful builds since the last time
> >>> the version field changed?
> >>> > > - Another idea?
> >>> > >
> >>> > > The third option looks like to be the one closest to our
> >>> current behavior.
> >>> > >
> >>> >
> >>> > I always envisioned that we'd use a variant of the third option.
> >>> >
> >>> > The options I've thought of:
> >>> >
> >>> > * %{dist}.
> >>> > * .%{?dist}
> >>> > * %{dist}..
> >>>
> >>> I've been thinking a bit about this and been wondering any reason
> >>> why not to do
> >>> simply?
> >>> %{dist}
> >>>
> >>> This would basically mimic what we are currently doing by hand, it
> >>> would be the
> >>> less changes to our current way of working (making opting-in
> >>> smoother).
> >>>
> >>
> >> If we're not doing automatic builds, sure. I've been going on two
> >> big
> >> assumptions:
> >>
> >> 1. We're going to do automatic building
> >> 2. We need *some* kind of stable leading portion of release for
> >> packagers to use for specified dependencies, especially
> >> Obsoletes+Provides combos.
> >
> > How is openSUSE taking care of 2 then? OBS bumps the release on each
> > rebuild and that can result in crazily high release numbers. I assume
> > they got a mechanism for Obsoletes+Provides and we could use that too?
>
> You got me curious there, so I looked it up with dnf, the highest
> release
> number in Factory is 1475.12 and it belongs to elib, which had its
> source/
> patches last updated 13 years ago, and its spec/changes 5 years ago.
>
The original commit of that package[1] had an absurdly high Release
number, so OBS stuck to it. At the fourth commit[2], the version was
synced and updated to 1451. The original autobuild system had a
Release value sync mechanism which I assume was dropped as part of the
migration from autobuild to OBS. That system likely synced the state
of that value as it was rebuilt without source changes. After that
point, we finally arrive at when the in-spec value was set to zero by
Stephen Kulow[3]. But regardless, OBS kept that value and kept
incrementing it on further commits, leading to the 1475 we have now.
There hasn't been a new version of elib to trigger OBS to reset the
Release value back to zero, so that's why the value is ridiculously
high. There have been 12 builds of the latest commit of elib (hence
the 12).
So if elib were theoretically replaced with something else, you'd do
the following:
Obsoletes: elib < 1.0-1476
Provides: elib = 1.0-1476
[1]:
https://build.opensuse.org/package/view_file/openSUSE:Factory/elib/elib.spec?expand=1=98133cb490cebaf272c34d2316c6fb81
[2]:
https://build.opensuse.org/package/rdiff/openSUSE:Factory/elib?linkrev=base=4
[3]:
https://build.opensuse.org/package/rdiff/openSUSE:Factory/elib?linkrev=base=13
--
真実はいつも一つ！/ Always, there's only one truth!
___
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
Re: Ideas for better development processes when maintaining hundreds of packages
On Tuesday, 28 January 2020 10:03:09 CET Richard W.M. Jones wrote: > * committing to git should build the package > > Is there a reason why this wouldn't be the case? Please no. Sometimes you just fix a typo or add a comment and there's no need to rebuild until a next release. ___ 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
Re: Git Forge Requirements: Please see the Community Blog
On Tue, Jan 28, 2020, 22:06 Iñaki Ucar wrote: > On Tue, 28 Jan 2020 at 20:58, Leigh Griffin wrote: > > > > This thread is serving as a source of requirements (although it has > meandered dramatically away from that) > > When I first read the post, my thought was: wow, what a convoluted and > abstruse way of saying "we want to abandon Pagure". Probably this > wasn't your intent, but that's what I got. And given the reactions, > other people too. > The linked blog to the ODF is very explicit that Pagure is one of the 3 forge options we are considering. I can't stress enough that it's a viable choice and ultimately what we opt for will come down to an analysis driven by the requirements gathered. I'm unsure how the blog has been interpreted any other way but hopefully this clears it up. If you (and others) elaborate on how you use Pagure (and other forges) and what you value from your day to day usage, we will take that on board and use it to drive our decision making. > > Iñaki > ___ > 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 > ___ 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
Re: What would it take to drop release and changelog from our spec files? (and do we want to?)
Neal Gompa writes:
> On Tue, Jan 28, 2020 at 7:27 AM Pierre-Yves Chibon
> wrote:
>>
>> On Fri, Jan 10, 2020 at 09:54:59PM -0500, Neal Gompa wrote:
>> > On Fri, Jan 10, 2020 at 11:37 AM Pierre-Yves Chibon
>> > wrote:
>> > >
>> > >
>> > > The release field would need to be set by koji ignoring whatever is in
>> > > the spec
>> > > file. How do we want to do this?
>> > > - Based on dates?
>> > > - Using an always increasing integer?
>> > > - Using the number of successful builds since the last time the
>> > > version field changed?
>> > > - Another idea?
>> > >
>> > > The third option looks like to be the one closest to our current
>> > > behavior.
>> > >
>> >
>> > I always envisioned that we'd use a variant of the third option.
>> >
>> > The options I've thought of:
>> >
>> > * %{dist}.
>> > * .%{?dist}
>> > * %{dist}..
>>
>> I've been thinking a bit about this and been wondering any reason why not to
>> do
>> simply?
>>%{dist}
>>
>> This would basically mimic what we are currently doing by hand, it would be
>> the
>> less changes to our current way of working (making opting-in smoother).
>>
>
> If we're not doing automatic builds, sure. I've been going on two big
> assumptions:
>
> 1. We're going to do automatic building
> 2. We need *some* kind of stable leading portion of release for
> packagers to use for specified dependencies, especially
> Obsoletes+Provides combos.
How is openSUSE taking care of 2 then? OBS bumps the release on each
rebuild and that can result in crazily high release numbers. I assume
they got a mechanism for Obsoletes+Provides and we could use that too?
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
Re: Ideas for better development processes when maintaining hundreds of packages
"Richard W.M. Jones" writes: > I always think that Fedora works fine if you maintain 1-5 packages. > It's possible to maintain 20 with a lot of work. And if you want to > maintain 100+ (things like the ocaml-* set that I help to maintain) > then you have to write your own automation. Could we do things > better? No one asked for them, but here are my ideas ... > > --- > > * kill the %changelog > > Please, let's kill it, and generate it from the git changelog. > I'm glad to see there's a proposal to do this. > > A general principle I'm following here is a packager should never > be asked to enter the same information twice. > > * committing to git should build the package > > Is there a reason why this wouldn't be the case? Not really no. I've been involved quite a bit in building packages on openSUSE's Buildservice and every commit there results in a rebuild. So it is doable, *but* OBS has the advantage that it discards all builds except for the most recent successful one, or it would have run out of storage ages ago. Although someone (Randy Barlow maybe?) had the idea to generate the changelog and to trigger builds from git tags instead of commits, which has a certain charm to it as well. If there was a choice whether to trigger builds from commits or tags and how to generate the %changelog, then I think that most use cases should be covered? > > * commit groups of packages together > > One reason why automatic commit -> build might not be desirable is if > you're trying to build a group of packages in a side tag. In my > opinion this means we should allow groups of packages to be committed > together. (Unfortunately because we chose to put every package in its > own git repo, the obvious way to do this can't work, but we could > still have a "ChangeId:" header in the commit message that ties > packages together). > > The packages should be built in build dependency order into a side > tag, and the side tag turned into an update, with no further > involvement from the packager unless something fails to build. > > This change on its own would solve the main problem that > affects people maintaining large sets of packages. How about something like `fedpkg add-to-side-tag` (yes the name needs work) that would work like this: $ fedpkg request-side-tag $ fedpkg add-to-side-tag $tag_name $pkgA $pkgB $pkgC $pkgGlob Now all git commits/tags pushed to $pkgA $pkgB $pkgC $pkgGlob result in them being built in the side tag $tag_name by default. Once the side tag is merged, you go back to building the "ordinary way". > > * “Fixes:” etc headers in git > > RHEL already does this. It should be possible to add special headers > to the commit message to automatically close bugs, ie: > > $ git commit -m "ocaml: Update to version 4.10.0 > Fixes: RHBZ#12345" > > Note the build, update and bug closing would happen completely > automatically, assuming there was no build or test failure. +1 on this one. > > * CVE bugs should autoclose when a package is rebased I don't think this is a good idea as you should actually check that this update fixes the CVE. Cheers, Dan 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
Re: Git Forge Requirements: Please see the Community Blog
On Tue, 28 Jan 2020 at 20:58, Leigh Griffin wrote: > > This thread is serving as a source of requirements (although it has meandered > dramatically away from that) When I first read the post, my thought was: wow, what a convoluted and abstruse way of saying "we want to abandon Pagure". Probably this wasn't your intent, but that's what I got. And given the reactions, other people too. Iñaki ___ 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
Re: [security] only latest Qt 5.14.1 has all fixes
Kevin Kofler wrote: > Rex Dieter wrote: >> Latest CVE there has a backported fix applied to fedora's packaging, and >> is currently in bodhi updates-testing, >> https://bodhi.fedoraproject.org/updates/FEDORA-2020-9139ba5469 >> https://bodhi.fedoraproject.org/updates/FEDORA-2020-e9b85978d4 > > But that's only QtBase. QtWebEngine has dozens of security fixes again in > 5.14.0 and 5.14.1 and our package is stuck on 5.13.2. (5.14.0 adds the > fixes from Chrom* 78, 5.14.1 the ones from Chrom* 79. 5.13.2 only has > security fixes up to Chrom* 77.) QtBase was the primary CVE mentioned in the original link. QtWebengine packaging is less restricted as far as updates and pretty sure that wasn't the point of the original post. -- Rex ___ 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
Re: [security] only latest Qt 5.14.1 has all fixes
Rex Dieter wrote: > Latest CVE there has a backported fix applied to fedora's packaging, and > is currently in bodhi updates-testing, > https://bodhi.fedoraproject.org/updates/FEDORA-2020-9139ba5469 > https://bodhi.fedoraproject.org/updates/FEDORA-2020-e9b85978d4 But that's only QtBase. QtWebEngine has dozens of security fixes again in 5.14.0 and 5.14.1 and our package is stuck on 5.13.2. (5.14.0 adds the fixes from Chrom* 78, 5.14.1 the ones from Chrom* 79. 5.13.2 only has security fixes up to Chrom* 77.) Kevin Kofler ___ 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
Re: Ideas for better development processes when maintaining hundreds of packages
Stephen John Smoogen writes: > On Tue, 28 Jan 2020 at 13:01, Robbie Harwood wrote: >> >> "Richard W.M. Jones" writes: >> >> > I always think that Fedora works fine if you maintain 1-5 packages. >> > It's possible to maintain 20 with a lot of work. And if you want to >> > maintain 100+ (things like the ocaml-* set that I help to maintain) >> > then you have to write your own automation. Could we do things >> > better? No one asked for them, but here are my ideas ... >> > >> > --- >> > >> > * CVE bugs should autoclose when a package is rebased >> > >> > Fabiano built the mingw-openssl package recently, but there are still >> > a load of open CVE bugs against this package referring to the older >> > version. These should be closed automatically. I think this will >> > require collecting the version of the package that fixes a CVE and >> > recording that in Bugzilla (or in the package itself in some standard >> > way). >> >> This is an interesting idea, and I appreciate you're considering ways to >> resolve this problem. However, I'm concerned that this will lead to >> maintainers not actually checking whether a version fixes an issue - >> since we don't have automatic verification (or even usually manual >> verification) of security fixes, that wouldn't get caught. >> > > You are assuming that maintainers actually check to see if a version > fixes an issue already. If a packager has 100's or 1000's of > packages.. there is no way they will have done so except on a 1 in a > million case set. I think if are going to aim that a packager can > 'maintain' hundreds or thousands of packages that we also assume that > this security is not going to be checked by the maintainer. If it > needs to be checked it will need to be 'outsourced' to some group who > can do so. Per Package Maintainer Responsibilities [1], maintainers are expected to "deal with reported bugs in a timely manner" and reach out if they cannot handle the load. I think it's reasonable to expect maintainers to be close to compliance with the policy they agreed to when becoming maintainers :) Personally, I think if you have enough packages that you cannot actually triage your own bugtracker, you have too many packages. I don't think it's at all reasonable for one person to be responsible for "100's or 1000s of packages", and I think not knowing whether security issues are or are not fixed in a given version of them is a perfect illustration of why that doesn't work. What I would like us to do is move away from needing to do that. Whether that involves more SIG-like maintainer groups, or a different format, I don't know; but one thing we do need is more monitoring of the security issues than we have right now. Thanks, --Robbie 1: https://docs.fedoraproject.org/en-US/fesco/Package_maintainer_responsibilities/ 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
Re: [security] only latest Qt 5.14.1 has all fixes
Latest CVE there has a backported fix applied to fedora's packaging, and is currently in bodhi updates-testing, https://bodhi.fedoraproject.org/updates/FEDORA-2020-9139ba5469 https://bodhi.fedoraproject.org/updates/FEDORA-2020-e9b85978d4 ___ 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
Re: Git Forge Requirements: Please see the Community Blog
On Tue, Jan 28, 2020, 15:58 Adam Saleh wrote: > Way we were discussing this, I think there were several points I didn't > really see here. > > a) we are gathering requirements for Git Forge, but we need a good Dist > Git as well. > > There might be difference in requirements and tooling for Dist Git > compared to generic fully featured Git Forge. > It might still be useful to abandon Pagure as a full-featured git-forge > and instead focus on making it really useful as a dist-git solution. > > b) Whatever we decide, there will be significant investment required. > Either by re-investing in our existing solution, or in the migration > effort. > > I think we really want to avoid the `Polarion` situation, where we wouldn't > be clear about all of the costs involved in migration, and end up with a > solution that only saved effort/money on paper, > and in reality it could cost many a man-day of > migration/maintenance/workaround efforts. > > I am not yet sure how to make this less vague, and more "Gathering > requirements", > @Leigh Griffin will there be some sort of a poll in > the end, or how do we actually get a list of requirements? > This thread is serving as a source of requirements (although it has meandered dramatically away from that) but I will default to the Fedora Council for how a combined set from the input in this thread and others is collated and presented. When all requirements are gathered from all stakeholders I will share the distilled version out. > > I assume we are in the "Research" phase of ODF [1], but this is first time > I am interacting with the framework :-) > We are in that phase of getting requirements and analyzing them. Sorry on my phone here so I can't be 100% sure of the formal phases off hand. > > Adam > > [1] > https://github.com/red-hat-people-team/open-decision-framework/blob/master/ODF-community.md > > > > On Fri, Jan 24, 2020 at 4:56 PM Michael Catanzaro > wrote: > >> On Wed, Jan 22, 2020 at 11:37 am, Michael Catanzaro >> wrote: >> > It doesn't have as many features as github.com, >> >> Sorry, this was a typo. I meant: it doesn't have as many features as >> gitlab.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 >> > ___ > 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 > ___ 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
[Bug 1795761] New: perl-Devel-PatchPerl-1.84 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1795761 Bug ID: 1795761 Summary: perl-Devel-PatchPerl-1.84 is available Product: Fedora Version: rawhide Status: NEW Component: perl-Devel-PatchPerl Keywords: FutureFeature, Triaged Assignee: jples...@redhat.com Reporter: upstream-release-monitor...@fedoraproject.org QA Contact: extras...@fedoraproject.org CC: iarn...@gmail.com, jples...@redhat.com, perl-devel@lists.fedoraproject.org Target Milestone: --- Classification: Fedora Latest upstream release: 1.84 Current version/release in rawhide: 1.80-1.fc32 URL: http://search.cpan.org/dist/Devel-PatchPerl/ Please consult the package updates policy before you issue an update to a stable branch: https://fedoraproject.org/wiki/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/6561/ -- You are receiving this mail because: You are on the CC list for the bug. ___ 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
Re: Ideas for better development processes when maintaining hundreds of packages
On Tue, Jan 28, 2020 at 2:39 PM Randy Barlow wrote: > > On Tue, 2020-01-28 at 09:03 +, Richard W.M. Jones wrote: > > If you want to go even further with this idea, then it could even be > > possible we allow packages into Fedora without any review. They > > would > > start in the outermost stream in a "there be dragons" repository that > > only the foolhardy would enable, but as their quality improved they > > would *automatically* migrate into the mainstream. > > We would need to at least have license review. Though automation can > help with licensing, there are weird things sometimes that only a human > could detect, like this[0]: > > https://github.com/szymach/c-pchart/issues/35 > > I do think we could automate a lot of the other elements of review > though, and I agree that it would be helpful. > > Having a bot at least check for the obvious licence problems would > still be helpful, but a bot that approves a package license still needs > to be double checked by a human, in my opinion. The bot would be > helpful in catching negatives (no license, or unacceptable license, > etc.) > This is something that I'm working on trying to bring over from the openSUSE community to Fedora. They've written a web app[1] that actually does this and they wired it into the contribution processes built into their build system so that they can get these done reasonably well and have a good understanding of the license makeup of their distribution of packages. There's a few things left and I'm hoping to try to spin up a test instance running on Fedora to see how it works. [1]: https://github.com/openSUSE/cavil -- 真実はいつも一つ！/ Always, there's only one truth! ___ 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
Re: Ideas for better development processes when maintaining hundreds of packages
On Tue, 2020-01-28 at 09:03 +, Richard W.M. Jones wrote: > If you want to go even further with this idea, then it could even be > possible we allow packages into Fedora without any review. They > would > start in the outermost stream in a "there be dragons" repository that > only the foolhardy would enable, but as their quality improved they > would *automatically* migrate into the mainstream. We would need to at least have license review. Though automation can help with licensing, there are weird things sometimes that only a human could detect, like this[0]: https://github.com/szymach/c-pchart/issues/35 I do think we could automate a lot of the other elements of review though, and I agree that it would be helpful. Having a bot at least check for the obvious licence problems would still be helpful, but a bot that approves a package license still needs to be double checked by a human, in my opinion. The bot would be helpful in catching negatives (no license, or unacceptable license, etc.) [0] Thanks to Remi for catching it in https://bugzilla.redhat.com/show_bug.cgi?id=1425275 - I hadn't even noticed it myself! signature.asc Description: This is a digitally signed message part ___ 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
Re: Ideas for better development processes when maintaining hundreds of packages
On Tue, 28 Jan 2020 at 14:01, Emmanuel Seyman wrote: > > * Stephen John Smoogen [28/01/2020 13:08] : > > > > You are assuming that maintainers actually check to see if a version > > fixes an issue already. If a packager has 100's or 1000's of > > packages.. there is no way they will have done so except on a 1 in a > > million case set. I think if are going to aim that a packager can > > 'maintain' hundreds or thousands of packages that we also assume that > > this security is not going to be checked by the maintainer. > > I really don't think I'm *that* special a case so I'ld prefer you check > that this is actually true rather than assume something wrong. > I realized after I sent it that someone would assume I was personally talking about their work. It is not what I meant and I apologize for my imprecise language. The issue I was aiming at that we currently have a high probability that we are missing CVE's just from the mass of packages and the mass of CVE's out there. My assumption that most packagers don't have the time to set up test cases for each CVE to confirm it is fixed comes from listening to 15 years of #fedora-devel, bugzilla and mailing lists where the fix is 'moved to latest upstream to fix CVE-123456' and then followups of 'updated to newer version to get right fix.. etc etc'. The nature of the work is that this is happening and will continue to happen whether or not we automate parts to help handle more packages per developer. Even if the packager is checking, mistakes will happen.. you may not replicate the CVE environment correctly.. it may be found that a cornercase still occurs... etc etc. The time to commit and build is short also for a lot of people and so the probability of it actually happening all the time is remote. That said, giving it an actual number (1 in a million) was wrong. -- Stephen J Smoogen. ___ 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
[Bug 1795754] perl-Clipboard-0.22 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1795754 --- Comment #2 from Upstream Release Monitoring --- the-new-hotness/release-monitoring.org's scratch build of perl-Clipboard-0.22-1.fc30.src.rpm for rawhide completed http://koji.fedoraproject.org/koji/taskinfo?taskID=41150757 -- You are receiving this mail because: You are on the CC list for the bug. ___ 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
[Bug 1795755] New: perl-CPANPLUS-Dist-Fedora-0.2.2 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1795755 Bug ID: 1795755 Summary: perl-CPANPLUS-Dist-Fedora-0.2.2 is available Product: Fedora Version: rawhide Status: NEW Component: perl-CPANPLUS-Dist-Fedora Keywords: FutureFeature, Triaged Assignee: jples...@redhat.com Reporter: upstream-release-monitor...@fedoraproject.org QA Contact: extras...@fedoraproject.org CC: i...@cicku.me, jples...@redhat.com, perl-devel@lists.fedoraproject.org Target Milestone: --- Classification: Fedora Latest upstream release: 0.2.2 Current version/release in rawhide: 0.2.1-1.fc32 URL: http://search.cpan.org/dist/CPANPLUS-Dist-Fedora/ Please consult the package updates policy before you issue an update to a stable branch: https://fedoraproject.org/wiki/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/5882/ -- You are receiving this mail because: You are on the CC list for the bug. ___ 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
[Bug 1795754] perl-Clipboard-0.22 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1795754 --- Comment #1 from Upstream Release Monitoring --- Created attachment 1656082 --> https://bugzilla.redhat.com/attachment.cgi?id=1656082=edit [patch] Update to 0.22 (#1795754) -- You are receiving this mail because: You are on the CC list for the bug. ___ 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
[Bug 1795754] New: perl-Clipboard-0.22 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1795754 Bug ID: 1795754 Summary: perl-Clipboard-0.22 is available Product: Fedora Version: rawhide Status: NEW Component: perl-Clipboard Keywords: FutureFeature, Triaged Assignee: mkre...@gmail.com Reporter: upstream-release-monitor...@fedoraproject.org QA Contact: extras...@fedoraproject.org CC: iarn...@gmail.com, mkre...@gmail.com, perl-devel@lists.fedoraproject.org, xav...@bachelot.org Target Milestone: --- Classification: Fedora Latest upstream release: 0.22 Current version/release in rawhide: 0.21-1.fc32 URL: http://search.cpan.org/dist/Clipboard/ Please consult the package updates policy before you issue an update to a stable branch: https://fedoraproject.org/wiki/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/14091/ -- You are receiving this mail because: You are on the CC list for the bug. ___ 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
[Bug 1795727] perl-Error-0.17029 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1795727 Paul Howarth changed: What|Removed |Added Status|NEW |CLOSED Fixed In Version||perl-Error-0.17029-1.fc32 Resolution|--- |RAWHIDE Doc Type|--- |If docs needed, set a value Last Closed||2020-01-28 19:16:04 --- Comment #3 from Paul Howarth --- Build done: https://koji.fedoraproject.org/koji/taskinfo?taskID=41150123 -- You are receiving this mail because: You are on the CC list for the bug. ___ 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
Re: Ideas for better development processes when maintaining hundreds of packages
On Tue, 28 Jan 2020 at 13:49, Richard W.M. Jones wrote: > > On Tue, Jan 28, 2020 at 01:08:11PM -0500, Stephen John Smoogen wrote: > > On Tue, 28 Jan 2020 at 13:01, Robbie Harwood wrote: > > > > > > "Richard W.M. Jones" writes: > > > > > > > I always think that Fedora works fine if you maintain 1-5 packages. > > > > It's possible to maintain 20 with a lot of work. And if you want to > > > > maintain 100+ (things like the ocaml-* set that I help to maintain) > > > > then you have to write your own automation. Could we do things > > > > better? No one asked for them, but here are my ideas ... > > > > > > > > --- > > > > > > > > * CVE bugs should autoclose when a package is rebased > > > > > > > > Fabiano built the mingw-openssl package recently, but there are still > > > > a load of open CVE bugs against this package referring to the older > > > > version. These should be closed automatically. I think this will > > > > require collecting the version of the package that fixes a CVE and > > > > recording that in Bugzilla (or in the package itself in some standard > > > > way). > > > > > > This is an interesting idea, and I appreciate you're considering ways to > > > resolve this problem. However, I'm concerned that this will lead to > > > maintainers not actually checking whether a version fixes an issue - > > > since we don't have automatic verification (or even usually manual > > > verification) of security fixes, that wouldn't get caught. > > > > > > > You are assuming that maintainers actually check to see if a version > > fixes an issue already. If a packager has 100's or 1000's of > > packages.. there is no way they will have done so except on a 1 in a > > million case set. I think if are going to aim that a packager can > > 'maintain' hundreds or thousands of packages that we also assume that > > this security is not going to be checked by the maintainer. If it > > needs to be checked it will need to be 'outsourced' to some group who > > can do so. > > Also the bit where I said > "(or in the package itself in some standard way)." > > Of course that standard way doesn't exist (or does it?) but we could > surely encourage upstreams to provide data that we need in a standard > format, especially if we coorperate with Debian, SUSE, Arch and others. > > For example, for my upstream projects I write release notes (!= the > changelog) but they're text files and not really in any standard > location or format. Also we have security bug pages but again not in > a standard way. > > If it was standardized we could suck that data straight into Fedora > and no packager, whether maintaining 1 or 100 packages, would have to > be troubled by this. > My main concern is that we have been coming up with 'standard' proposals for 20 years and we can't seem to get more than any 4 maintainers to agree to what that means... even if they do the same work in Debian/SuSE/Arch etc. Too many idiosyncratic techniques which they use to keep themselves sane or working in whatever environments they have. At this point, I will take whatever we can standardize on even if it is clay tablets mailed to Babylon (ok maybe something a little less archaic) -- Stephen J Smoogen. ___ 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
[Bug 1795690] perl-File-Find-Object-Rule-0.0312 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1795690 Paul Howarth changed: What|Removed |Added Status|NEW |CLOSED Fixed In Version||perl-File-Find-Object-Rule- ||0.0312-1.fc32 Resolution|--- |RAWHIDE Doc Type|--- |If docs needed, set a value Last Closed||2020-01-28 19:04:27 --- Comment #2 from Paul Howarth --- Build done: https://koji.fedoraproject.org/koji/taskinfo?taskID=41149531 -- You are receiving this mail because: You are on the CC list for the bug. ___ 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
Re: Ideas for better development processes when maintaining hundreds of packages
* Stephen John Smoogen [28/01/2020 13:08] : > > You are assuming that maintainers actually check to see if a version > fixes an issue already. If a packager has 100's or 1000's of > packages.. there is no way they will have done so except on a 1 in a > million case set. I think if are going to aim that a packager can > 'maintain' hundreds or thousands of packages that we also assume that > this security is not going to be checked by the maintainer. I really don't think I'm *that* special a case so I'ld prefer you check that this is actually true rather than assume something wrong. Emmanuel ___ 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
[Bug 1795691] perl-File-Find-Object-0.3.5 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1795691 Paul Howarth changed: What|Removed |Added Status|NEW |CLOSED Fixed In Version||perl-File-Find-Object-0.3.5 ||-1.fc32 Resolution|--- |RAWHIDE Doc Type|--- |If docs needed, set a value Last Closed||2020-01-28 18:51:25 --- Comment #2 from Paul Howarth --- Build done: https://koji.fedoraproject.org/koji/taskinfo?taskID=41149055 -- You are receiving this mail because: You are on the CC list for the bug. ___ 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
Re: Ideas for better development processes when maintaining hundreds of packages
On Tue, Jan 28, 2020 at 01:08:11PM -0500, Stephen John Smoogen wrote: > On Tue, 28 Jan 2020 at 13:01, Robbie Harwood wrote: > > > > "Richard W.M. Jones" writes: > > > > > I always think that Fedora works fine if you maintain 1-5 packages. > > > It's possible to maintain 20 with a lot of work. And if you want to > > > maintain 100+ (things like the ocaml-* set that I help to maintain) > > > then you have to write your own automation. Could we do things > > > better? No one asked for them, but here are my ideas ... > > > > > > --- > > > > > > * CVE bugs should autoclose when a package is rebased > > > > > > Fabiano built the mingw-openssl package recently, but there are still > > > a load of open CVE bugs against this package referring to the older > > > version. These should be closed automatically. I think this will > > > require collecting the version of the package that fixes a CVE and > > > recording that in Bugzilla (or in the package itself in some standard > > > way). > > > > This is an interesting idea, and I appreciate you're considering ways to > > resolve this problem. However, I'm concerned that this will lead to > > maintainers not actually checking whether a version fixes an issue - > > since we don't have automatic verification (or even usually manual > > verification) of security fixes, that wouldn't get caught. > > > > You are assuming that maintainers actually check to see if a version > fixes an issue already. If a packager has 100's or 1000's of > packages.. there is no way they will have done so except on a 1 in a > million case set. I think if are going to aim that a packager can > 'maintain' hundreds or thousands of packages that we also assume that > this security is not going to be checked by the maintainer. If it > needs to be checked it will need to be 'outsourced' to some group who > can do so. Also the bit where I said "(or in the package itself in some standard way)." Of course that standard way doesn't exist (or does it?) but we could surely encourage upstreams to provide data that we need in a standard format, especially if we coorperate with Debian, SUSE, Arch and others. For example, for my upstream projects I write release notes (!= the changelog) but they're text files and not really in any standard location or format. Also we have security bug pages but again not in a standard way. If it was standardized we could suck that data straight into Fedora and no packager, whether maintaining 1 or 100 packages, would have to be troubled by this. Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones Read my programming and virtualization blog: http://rwmj.wordpress.com Fedora Windows cross-compiler. Compile Windows programs, test, and build Windows installers. Over 100 libraries supported. http://fedoraproject.org/wiki/MinGW ___ 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
Issues currently blocking building Python packages on Fedora Rawhide
Hi, There are currently 4 issues which prevent to build the Python package on Fedora Rawhide: Python 3.8.1 and Python 3.9.0a3 packages are impacted, at least. My Python 3.9.0a3 PR: https://src.fedoraproject.org/rpms/python39/pull-request/16 Example of Python 3.8.1 PR with failing tests: https://src.fedoraproject.org/rpms/python3/pull-request/164 I'm investigating these 4 issues. The 4 issues: (*) test_import: test_unwritable_module() => FIXED! It's a bug in Python 3.9.0a3, it has already been fixed upstream. It only fails when Python was installed. https://bugs.python.org/issue39459 (*) test_zipfile: test_add_file_after_2107() failure => failed to reproduce :-( https://bugs.python.org/issue39460 So far, I failed to reproduce it. It seems to only occur on Fedora Rawhide. It should be a recent change in Rawhide. (*) test_io hangs randomly => need to reproduce the bug with --timeout https://src.fedoraproject.org/rpms/python39/pull-request/16 I modified my Python 3.9.0a3 PR to run tests with --timeout=1800, so if the test hangs again, we should get a traceback where Python hangs. (*) GCC 10 and -fcommon: "redefined symbol cannot be used on reloc" when linking libpython3.9.so => reported to GCC upstream https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93384 It may be a missing "extern" in PyAPI_FUNC() when Python is built. I should try to build Python using -fno-common to see if it's enough to reproduce the issue. Victor ___ python-devel mailing list -- python-devel@lists.fedoraproject.org To unsubscribe send an email to python-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/python-devel@lists.fedoraproject.org
Re: [security] only latest Qt 5.14.1 has all fixes
This is more a request to ship secure versions of software in fedora and rhel that don't have open CVE's when fixed versions are available On Tue, 28 Jan 2020, 19:21 Artem Tim, wrote: > Request 768036 (accepted) > Qt 5.14.1 - untested, as usual > https://build.opensuse.org/request/show/768036 > > That is all we need to know about how packages updating in openSUSE or > something else? > ___ > 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 > ___ 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
Re: Ideas for better development processes when maintaining hundreds of packages
On Tue, 28 Jan 2020 at 13:01, Robbie Harwood wrote: > > "Richard W.M. Jones" writes: > > > I always think that Fedora works fine if you maintain 1-5 packages. > > It's possible to maintain 20 with a lot of work. And if you want to > > maintain 100+ (things like the ocaml-* set that I help to maintain) > > then you have to write your own automation. Could we do things > > better? No one asked for them, but here are my ideas ... > > > > --- > > > > * CVE bugs should autoclose when a package is rebased > > > > Fabiano built the mingw-openssl package recently, but there are still > > a load of open CVE bugs against this package referring to the older > > version. These should be closed automatically. I think this will > > require collecting the version of the package that fixes a CVE and > > recording that in Bugzilla (or in the package itself in some standard > > way). > > This is an interesting idea, and I appreciate you're considering ways to > resolve this problem. However, I'm concerned that this will lead to > maintainers not actually checking whether a version fixes an issue - > since we don't have automatic verification (or even usually manual > verification) of security fixes, that wouldn't get caught. > You are assuming that maintainers actually check to see if a version fixes an issue already. If a packager has 100's or 1000's of packages.. there is no way they will have done so except on a 1 in a million case set. I think if are going to aim that a packager can 'maintain' hundreds or thousands of packages that we also assume that this security is not going to be checked by the maintainer. If it needs to be checked it will need to be 'outsourced' to some group who can do so. > I feel like bodhi updates help with this for non-rawhide versions (at > least, in the web interface) by proposing possible "fixed in this > version" bugs, but I'm not sure how to get that for rawhide without > requiring bodhi there (which I don't want to do). > > Thanks, > --Robbie > ___ > 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 -- Stephen J Smoogen. ___ 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
Re: Git Forge Requirements: Please see the Community Blog
On Tue, 28 Jan 2020 at 12:17, Martin Kolman wrote: > > On Wed, 2020-01-22 at 13:28 -0500, Neal Gompa wrote: > > On Wed, Jan 22, 2020 at 12:58 PM Milan Crha wrote: > > > On Wed, 2020-01-22 at 11:37 -0600, Michael Catanzaro wrote: > > > > they all picked GitLab CE. > > > > > > Hi, > > > I do not want to pollute this thread with unrelated information, > > > but for what it worth, I only recently realized that GitLab CE, the one > > > hosted on GNOME, does not have searching working properly. I filled a > > > bug upstream [1]. Being able to reliably search in issues is rather > > > essential function, from my point of view. I'm wondering how they can > > > search for anything when they've filled 10k+ issues. > > > > > > Anyway, if you think this doesn't belong to this thread then I > > > apologize. > > > > Fulltext search in GitLab is an Enterprise Edition feature and > > requires a separate deployment of ElasticSearch. > Ouch - really ? :-( > > Well, I guess that demonstrates quite nicely the dangers of open core > projects right here and there... Well even if it wasn't opencore .. the search tools would still require a lot of infrastructure to work. An allure of pagure has been that it runs on 1 system front and back. To get the feature set that people seem to want from gitlab would require about 6 to 18 systems (the 'this is how it should be done if you want the minimum of dealing with corner cases') with each sub-service adding on more systems for its own cluster. You also find that you need to upgrade your hardware to have 10 gigabit switches, fast storage, and other clustering tools which were not budgeted for. Yes you can do it with less but you will keep running into corner cases as you have more and more use-cases from different developer groups. So you end up standing up a large set of hardware and find yourself still focusing on running something other than building software. And that is the real allure of going to an outsourced software stack. They deal with running things and fixing all the corner cases your developers will find. [Whether those fixes actually ever occur is for some future crisis.] You can then focus on the main job that you started off on, regularly making an OS. -- Stephen J Smoogen. ___ 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
[EPEL-devel] [Fedocal] Reminder meeting : EPEL Steering Co
Dear all, You are kindly invited to the meeting: EPEL Steering Co on 2020-01-29 from 18:00:00 to 19:00:00 GMT At freenode@fedora-meeting The meeting will be about: This is the weekly EPEL Steering Committee Meeting. A general agenda is the following: #meetingname EPEL #topic Intros #topic Old Business #topic EPEL-6 #topic EPEL-7 #topic EPEL-8 #topic Openfloor #endmeeting Source: https://apps.fedoraproject.org/calendar/meeting/9672/ ___ 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
Re: Ideas for better development processes when maintaining hundreds of packages
"Richard W.M. Jones" writes: > I always think that Fedora works fine if you maintain 1-5 packages. > It's possible to maintain 20 with a lot of work. And if you want to > maintain 100+ (things like the ocaml-* set that I help to maintain) > then you have to write your own automation. Could we do things > better? No one asked for them, but here are my ideas ... > > --- > > * CVE bugs should autoclose when a package is rebased > > Fabiano built the mingw-openssl package recently, but there are still > a load of open CVE bugs against this package referring to the older > version. These should be closed automatically. I think this will > require collecting the version of the package that fixes a CVE and > recording that in Bugzilla (or in the package itself in some standard > way). This is an interesting idea, and I appreciate you're considering ways to resolve this problem. However, I'm concerned that this will lead to maintainers not actually checking whether a version fixes an issue - since we don't have automatic verification (or even usually manual verification) of security fixes, that wouldn't get caught. I feel like bodhi updates help with this for non-rawhide versions (at least, in the web interface) by proposing possible "fixed in this version" bugs, but I'm not sure how to get that for rawhide without requiring bodhi there (which I don't want to do). Thanks, --Robbie 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
[Bug 1795727] perl-Error-0.17029 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1795727 --- Comment #2 from Upstream Release Monitoring --- the-new-hotness/release-monitoring.org's scratch build of perl-Error-0.17029-1.fc30.src.rpm for rawhide completed http://koji.fedoraproject.org/koji/taskinfo?taskID=41145679 -- You are receiving this mail because: You are on the CC list for the bug. ___ 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
[Bug 1795727] perl-Error-0.17029 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1795727 --- Comment #1 from Upstream Release Monitoring --- Created attachment 1656057 --> https://bugzilla.redhat.com/attachment.cgi?id=1656057=edit [patch] Update to 0.17029 (#1795727) -- You are receiving this mail because: You are on the CC list for the bug. ___ 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
[Bug 1795727] New: perl-Error-0.17029 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1795727 Bug ID: 1795727 Summary: perl-Error-0.17029 is available Product: Fedora Version: rawhide Status: NEW Component: perl-Error Keywords: FutureFeature, Triaged Assignee: p...@city-fan.org Reporter: upstream-release-monitor...@fedoraproject.org QA Contact: extras...@fedoraproject.org CC: jose.p.oliveira@gmail.com, p...@city-fan.org, perl-devel@lists.fedoraproject.org, st...@silug.org, tcall...@redhat.com Target Milestone: --- Classification: Fedora Latest upstream release: 0.17029 Current version/release in rawhide: 0.17028-1.fc32 URL: http://search.cpan.org/dist/Error/ Please consult the package updates policy before you issue an update to a stable branch: https://fedoraproject.org/wiki/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/7092/ -- You are receiving this mail because: You are on the CC list for the bug. ___ 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
Re: [security] only latest Qt 5.14.1 has all fixes
Request 768036 (accepted) Qt 5.14.1 - untested, as usual https://build.opensuse.org/request/show/768036 That is all we need to know about how packages updating in openSUSE or something else? ___ 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
Re: Git Forge Requirements: Please see the Community Blog
On Wed, 2020-01-22 at 13:28 -0500, Neal Gompa wrote: > On Wed, Jan 22, 2020 at 12:58 PM Milan Crha wrote: > > On Wed, 2020-01-22 at 11:37 -0600, Michael Catanzaro wrote: > > > they all picked GitLab CE. > > > > Hi, > > I do not want to pollute this thread with unrelated information, > > but for what it worth, I only recently realized that GitLab CE, the one > > hosted on GNOME, does not have searching working properly. I filled a > > bug upstream [1]. Being able to reliably search in issues is rather > > essential function, from my point of view. I'm wondering how they can > > search for anything when they've filled 10k+ issues. > > > > Anyway, if you think this doesn't belong to this thread then I > > apologize. > > Fulltext search in GitLab is an Enterprise Edition feature and > requires a separate deployment of ElasticSearch. Ouch - really ? :-( Well, I guess that demonstrates quite nicely the dangers of open core projects right here and there... > > > > -- > 真実はいつも一つ！/ Always, there's only one truth! > ___ > 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 ___ 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
[security] only latest Qt 5.14.1 has all fixes
As mentioned in: https://www.qt.io/blog/qt-5.14.1-released https://www.qt.io/blog/qt-offering-changes-2020 Qt 5.14.1 seems to be the only available Qt version that contains various security fixes for CVE's, after Qt's recent switch of patch handling (for open source only the latest version receives fixes but distributions can backport), just mentioning the most popular one: CVE-2020-0570 and there are a bunch of others. With latest version in Rawhide being 5.13 I ask how is Fedora affected by these CVE's? When will the Fedora Qt maintainers provide a packages without known security issues if thus affected? Distributions like arch and gentoo have already made the switch to latest. openSUSE build service which allows you to edit spec files even from your phone has it for several months now https://build.opensuse.org/project/show/KDE:Qt:5.14 ___ 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
Re: Ideas for better development processes when maintaining hundreds of packages
It would be nice if you could look into existing code instead of writing new one: https://github.com/ignatenkobrain/git-rpm-changelog On Tue, Jan 28, 2020, 12:43 Pierre-Yves Chibon wrote: > On Tue, Jan 28, 2020 at 09:03:09AM +, Richard W.M. Jones wrote: > > I always think that Fedora works fine if you maintain 1-5 packages. > > It's possible to maintain 20 with a lot of work. And if you want to > > maintain 100+ (things like the ocaml-* set that I help to maintain) > > then you have to write your own automation. Could we do things > > better? No one asked for them, but here are my ideas ... > > > > --- > > > > * kill the %changelog > > > > Please, let's kill it, and generate it from the git changelog. > > I'm glad to see there's a proposal to do this. > > > > A general principle I'm following here is a packager should never > > be asked to enter the same information twice. > > There are a few tricky things about this, but overall I think it's doable > and > some of the tricky things may just be things we just have to accept as > being > different from the current situation. > > We are playing a bit of a proof of concept of what a RPM changelog > generated > from git logs could look like. The outcome of this is at: > https://pagure.io/Fedora-Infra/generate_changelog/tree/master > > Feel free to poke at it and see how it behaves. > > The script only considers: > - the last two years of commits > - commits touching either the spec file or patches (ending with .patch) > > We want a way to say: [Ignore XXX] (or simply [Ignore] if it's the current > commit that should be ignored), as well as a way to say: [Replace XXX] to > be > able to replace an existing commit message, but that's not there yet. > > One of the thing that may change is that we may end up with changelog > entry that > do not have a corresponding nvr at the end. > The python script above shows that, it'll only add the v-r in the > changelog when > either one of them changed, if they are the same, it doesn't specify them. > > Another aspect that is getting trickier is: > - update to 1.1-1 > > - fix missing BR > > - spec clean up > > 3 commits, can all be either on 3 different days but could also be on the > same > day. Could be from 3 different people, but could also be from the same > person. > So we could have 3 commits, on 1 day from 1 person, two of which would make > sense to group together (update to 1.1-1 and fix missing BR) and one that > shouldn't since the build succeeded before that and thus the -1 that goes > out to > the mirror will not have this clean up entry. > The current approach we took is: we have 3 entries in the changelog (and > only > one has the v-r specified). It's not ideal, but we don't quite see how to > solve > this question yet. > If the "spec clean up" contains "[ignore]", that question is solved, but > if we > replace "spec clean up" with "Drop sub-package foo" then we do not have a > good > idea on how to consolidate the commit messages into a single changelog > entry. > Suggestions welcome :) > > > > * committing to git should build the package > > > > Is there a reason why this wouldn't be the case? > > That was part of the proposal we debated last fall and there seemed to be > much > more people against this than I thought there would be. > Maybe we could start with having an opt-in approach. > > > * commit groups of packages together > > > > One reason why automatic commit -> build might not be desirable is if > > you're trying to build a group of packages in a side tag. In my > > opinion this means we should allow groups of packages to be committed > > together. (Unfortunately because we chose to put every package in its > > own git repo, the obvious way to do this can't work, but we could > > still have a "ChangeId:" header in the commit message that ties > > packages together). > > > > The packages should be built in build dependency order into a side > > tag, and the side tag turned into an update, with no further > > involvement from the packager unless something fails to build. > > > > This change on its own would solve the main problem that > > affects people maintaining large sets of packages. > > If we use a magic word to support opt-into automating commit -> build, we > could > get partly there. > BuildIn: Fedora, EPEL > BuildIn: > BuildIn: rawhide > ... > > > * “Fixes:” etc headers in git > > > > RHEL already does this. It should be possible to add special headers > > to the commit message to automatically close bugs, ie: > > > > $ git commit -m "ocaml: Update to version 4.10.0 > > Fixes: RHBZ#12345" > > > > Note the build, update and bug closing would happen completely > > automatically, assuming there was no build or test failure. > > We clearly don't have a good mapping from commit messages to bugzilla. > dist-git has the info, either in the rpm changelog or in the git commit > messages > koji has only the info of the git commit it was triggered from > bodhi works at the
[Bug 1790410] perl-XML-LibXML-2.0202 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1790410 Petr Pisar changed: What|Removed |Added CC||ppi...@redhat.com --- Comment #2 from Petr Pisar --- XML-LibXML-2.0202 brought a regression in SAX interface that, I hope, fixed in perl-XML-LibXML-2.0202-2.fc32. We retracted the updates from Fedora 31 because it triggered additional failures in tests of other packages. These should have already been corrected in the affected packages. -- You are receiving this mail because: You are on the CC list for the bug. ___ 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
[Bug 1795690] perl-File-Find-Object-Rule-0.0312 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1795690 --- Comment #1 from Upstream Release Monitoring --- An unexpected error occurred while creating the scratch build and has been automatically reported. Sorry! -- You are receiving this mail because: You are on the CC list for the bug. ___ 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
[Bug 1795691] New: perl-File-Find-Object-0.3.5 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1795691 Bug ID: 1795691 Summary: perl-File-Find-Object-0.3.5 is available Product: Fedora Version: rawhide Status: NEW Component: perl-File-Find-Object Keywords: FutureFeature, Triaged Assignee: p...@city-fan.org Reporter: upstream-release-monitor...@fedoraproject.org QA Contact: extras...@fedoraproject.org CC: i...@cicku.me, p...@city-fan.org, perl-devel@lists.fedoraproject.org Target Milestone: --- Classification: Fedora Latest upstream release: 0.3.5 Current version/release in rawhide: 0.3.4-1.fc32 URL: http://search.cpan.org/dist/File-Find-Object/ Please consult the package updates policy before you issue an update to a stable branch: https://fedoraproject.org/wiki/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/2886/ -- You are receiving this mail because: You are on the CC list for the bug. ___ 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
[Bug 1795690] New: perl-File-Find-Object-Rule-0.0312 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1795690 Bug ID: 1795690 Summary: perl-File-Find-Object-Rule-0.0312 is available Product: Fedora Version: rawhide Status: NEW Component: perl-File-Find-Object-Rule Keywords: FutureFeature, Triaged Assignee: p...@city-fan.org Reporter: upstream-release-monitor...@fedoraproject.org QA Contact: extras...@fedoraproject.org CC: i...@cicku.me, p...@city-fan.org, perl-devel@lists.fedoraproject.org Target Milestone: --- Classification: Fedora Latest upstream release: 0.0312 Current version/release in rawhide: 0.0311-1.fc32 URL: http://search.cpan.org/dist/File-Find-Object-Rule/ Please consult the package updates policy before you issue an update to a stable branch: https://fedoraproject.org/wiki/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/2887/ -- You are receiving this mail because: You are on the CC list for the bug. ___ 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
[Bug 1795691] perl-File-Find-Object-0.3.5 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1795691 --- Comment #1 from Upstream Release Monitoring --- An unexpected error occurred while creating the scratch build and has been automatically reported. Sorry! -- You are receiving this mail because: You are on the CC list for the bug. ___ 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
Re: Git Forge Requirements: Please see the Community Blog
Way we were discussing this, I think there were several points I didn't really see here. a) we are gathering requirements for Git Forge, but we need a good Dist Git as well. There might be difference in requirements and tooling for Dist Git compared to generic fully featured Git Forge. It might still be useful to abandon Pagure as a full-featured git-forge and instead focus on making it really useful as a dist-git solution. b) Whatever we decide, there will be significant investment required. Either by re-investing in our existing solution, or in the migration effort. I think we really want to avoid the `Polarion` situation, where we wouldn't be clear about all of the costs involved in migration, and end up with a solution that only saved effort/money on paper, and in reality it could cost many a man-day of migration/maintenance/workaround efforts. I am not yet sure how to make this less vague, and more "Gathering requirements", @Leigh Griffin will there be some sort of a poll in the end, or how do we actually get a list of requirements? I assume we are in the "Research" phase of ODF [1], but this is first time I am interacting with the framework :-) Adam [1] https://github.com/red-hat-people-team/open-decision-framework/blob/master/ODF-community.md On Fri, Jan 24, 2020 at 4:56 PM Michael Catanzaro wrote: > On Wed, Jan 22, 2020 at 11:37 am, Michael Catanzaro > wrote: > > It doesn't have as many features as github.com, > > Sorry, this was a typo. I meant: it doesn't have as many features as > gitlab.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 > ___ 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
Re: Ideas for better development processes when maintaining hundreds of packages
On Tue, Jan 28, 2020 at 8:59 AM Pierre-Yves Chibon wrote: > > On Tue, Jan 28, 2020 at 02:51:28PM +0100, Florian Weimer wrote: > > * Pierre-Yves Chibon: > > > > >> Sorry for being unclear. The spec file in dist-git would still show > > >> some (older) version of the %changelog entries under this model. > > >> > > >> The corrections would update the %changelog with all the historic > > >> entries. Since auto-generation stops at this commit, the new generated > > >> %changelog will include the fixed entries. > > >> > > >> This would also avoid the need for a new knob to adjust how far back the > > >> %changelog generation goes. > > > > > > Let me rephrase to see if I understand correctly. > > > The changelog would be something like: > > > `` > > > %changelog > > > %generate_changelog > > > > > > > > > `` > > > > > > This way we don't need to generate the old entries, we can just focus on > > > the > > > commits once the packager has opted in and not look at the old commits in > > > the > > > git history. > > > > > > Is that what you were thinking? > > > > Yes, but the generation would not stop when %generate_changelog was > > added, but when the last edit below %changelog was made. > > > > Does this make sense? Sorry if I'm not explaining this properly. > > I think I understand, by going up until the time the changelog was last > touched > (be that the macro or something else), we give an easy way to edit it. > > We would also need to have fepdkg generate-changelog to help with this. > This is pretty similar to how it works in Mageia, actually. In the Mageia workflow, changelog entries are managed manually until it is imported into our Dist-SVN. The changelog section is stripped and split into a separate file in a separate folder in the SVN tree (which is the equivalent of an orphan branch) and appended after the VCS-based changelog on package builds. This can be viewed locally as well, like so (example from python-distro in Mageia): $ mgarepo rpmlog -o python-distro * Thu Sep 20 2018 Sysadmin Bot 1.0.2-7.mga7 + Revision: 1288676 - Mageia 7 Mass Rebuild * Sat Aug 05 2017 Pascal Terjan 1.0.2-6.mga7 + Revision: 1135369 - Rebuild for python 3.6 * Thu Mar 16 2017 Neal Gompa 1.0.2-5.mga6 + Revision: 1093149 - Port to Mageia - imported package python-distro * Sat Feb 11 2017 Fedora Release Engineering - 1.0.2-4 - Rebuilt for https://fedoraproject.org/wiki/Fedora_26_Mass_Rebuild * Tue Jan 24 2017 Miroslav Suchý 1.0.2-3 - typo in license macro * Tue Jan 24 2017 Miroslav Suchý 1.0.2-2 - add license macro for el6 You can see from the above example where the generated / manual changelog split occurs. mgarepo is packaged in Fedora and you can play with this to see how it works. :) -- 真実はいつも一つ！/ Always, there's only one truth! ___ 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
Re: Fedora 32 Mass Rebuild
On Tue, Jan 28, 2020 at 11:24:44AM +0100, Hans de Goede wrote:
> Hi,
>
> On 28-01-2020 10:37, Vascom wrote:
> > Are s390x builders ready for Mass Rebuild?
> > I see many fail builds only on s390x without logs.
>
> I was about to ask the same thing, there are logs though, but only
> from koji or mock, not from an actual build, e.g. :
>
> https://koji.fedoraproject.org/koji/taskinfo?taskID=41124919
>
> "
> Result
>
> Traceback (most recent call last):
> File "/usr/lib/python3.7/site-packages/koji/daemon.py", line 1294, in
> runTask
> response = (handler.run(),)
> File "/usr/lib/python3.7/site-packages/koji/tasks.py", line 313, in run
> return koji.util.call_with_argcheck(self.handler, self.params, self.opts)
> File "/usr/lib/python3.7/site-packages/koji/util.py", line 263, in
> call_with_argcheck
> return func(*args, **kwargs)
> File "/usr/sbin/kojid", line 1343, in handler
> h = koji.get_rpm_header(fn)
> File "/usr/lib/python3.7/site-packages/koji/__init__.py", line 914, in
> get_rpm_header
> hdr = ts.hdrFromFdno(fo.fileno())
> File "/usr/lib64/python3.7/site-packages/rpm/transaction.py", line 185, in
> hdrFromFdno
> raise rpm.error("error reading package header")
> _rpm.error: error reading package header
>
> "
>
> I hope that these failed builds can be automatically retried (once the
> problem is solved)
> and that as a package maintainer I do not end up having to resubmit all of
> these
> manually?
Yeah, we disabled those builders... we can resubmit the failed jobs.
kevin
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
Re: How to handle circular build dependencies?
Markku Korkeala wrote: > Hi, > > sorry if this a newbie question, I tried to search this > but did not find good documentation on this problem. > > I'm in the process of upgrading the clojure package to > next version, which has new dependencies. These dependencies > require certain clojure version themselves, so it makes a > chicken-and-egg kind of problem. Are there good ways to handle > these kind of circular dependencies? See if this helps, https://docs.fedoraproject.org/en-US/packaging-guidelines/#bootstrapping -- Rex ___ 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
Re: Ideas for better development processes when maintaining hundreds of packages
On Tue, Jan 28, 2020 at 02:51:28PM +0100, Florian Weimer wrote: > * Pierre-Yves Chibon: > > >> Sorry for being unclear. The spec file in dist-git would still show > >> some (older) version of the %changelog entries under this model. > >> > >> The corrections would update the %changelog with all the historic > >> entries. Since auto-generation stops at this commit, the new generated > >> %changelog will include the fixed entries. > >> > >> This would also avoid the need for a new knob to adjust how far back the > >> %changelog generation goes. > > > > Let me rephrase to see if I understand correctly. > > The changelog would be something like: > > `` > > %changelog > > %generate_changelog > > > > > > `` > > > > This way we don't need to generate the old entries, we can just focus on the > > commits once the packager has opted in and not look at the old commits in > > the > > git history. > > > > Is that what you were thinking? > > Yes, but the generation would not stop when %generate_changelog was > added, but when the last edit below %changelog was made. > > Does this make sense? Sorry if I'm not explaining this properly. I think I understand, by going up until the time the changelog was last touched (be that the macro or something else), we give an easy way to edit it. We would also need to have fepdkg generate-changelog to help with this. Pierre ___ 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
Re: Ideas for better development processes when maintaining hundreds of packages
* Pierre-Yves Chibon: >> Sorry for being unclear. The spec file in dist-git would still show >> some (older) version of the %changelog entries under this model. >> >> The corrections would update the %changelog with all the historic >> entries. Since auto-generation stops at this commit, the new generated >> %changelog will include the fixed entries. >> >> This would also avoid the need for a new knob to adjust how far back the >> %changelog generation goes. > > Let me rephrase to see if I understand correctly. > The changelog would be something like: > `` > %changelog > %generate_changelog > > > `` > > This way we don't need to generate the old entries, we can just focus on the > commits once the packager has opted in and not look at the old commits in the > git history. > > Is that what you were thinking? Yes, but the generation would not stop when %generate_changelog was added, but when the last edit below %changelog was made. Does this make sense? Sorry if I'm not explaining this properly. Thanks, Florian ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Ideas for better development processes when maintaining hundreds of packages
On Tue, Jan 28, 2020 at 02:25:33PM +0100, Florian Weimer wrote: > * Pierre-Yves Chibon: > > > On Tue, Jan 28, 2020 at 01:53:32PM +0100, Florian Weimer wrote: > >> * Pierre-Yves Chibon: > >> > >> > Feel free to poke at it and see how it behaves. > >> > > >> > The script only considers: > >> > - the last two years of commits > >> > - commits touching either the spec file or patches (ending with .patch) > >> > > >> > We want a way to say: [Ignore XXX] (or simply [Ignore] if it's the > >> > current > >> > commit that should be ignored), as well as a way to say: [Replace XXX] > >> > to be > >> > able to replace an existing commit message, but that's not there yet. > >> > >> Have you considered only auto-generating %changelog entries since the > >> last commit that changed the %changelog section? > > > > We thought about that, pull the last changelog from the last build, get the > > commit hash of that last build and only generate the new changelog from > > HEAD... > > The issue was: how to fix existing entries (typo, wrong content...) and our > > thought on this was that it would be easier to re-generate the entire > > changelog > > for this reason. > > > >> To fix entries, you would run a tool to materialize the current > >> auto-generated %changelog (and Release:), and then make the necessary > >> corrections and additions. > > > > Where would this corrections/additions live though? > > We were thinking to include the corrections in other/new commits but if we > > don't > > reach the old commits, we can't correct them. > > > > What did you have in mind? > > Sorry for being unclear. The spec file in dist-git would still show > some (older) version of the %changelog entries under this model. > > The corrections would update the %changelog with all the historic > entries. Since auto-generation stops at this commit, the new generated > %changelog will include the fixed entries. > > This would also avoid the need for a new knob to adjust how far back the > %changelog generation goes. Let me rephrase to see if I understand correctly. The changelog would be something like: `` %changelog %generate_changelog `` This way we don't need to generate the old entries, we can just focus on the commits once the packager has opted in and not look at the old commits in the git history. Is that what you were thinking? If so I think I like it, if not I still like this but then I didn't catch what you meant :) Thanks, Pierre ___ 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
Re: Ideas for better development processes when maintaining hundreds of packages
* Pierre-Yves Chibon: > On Tue, Jan 28, 2020 at 01:53:32PM +0100, Florian Weimer wrote: >> * Pierre-Yves Chibon: >> >> > Feel free to poke at it and see how it behaves. >> > >> > The script only considers: >> > - the last two years of commits >> > - commits touching either the spec file or patches (ending with .patch) >> > >> > We want a way to say: [Ignore XXX] (or simply [Ignore] if it's the current >> > commit that should be ignored), as well as a way to say: [Replace XXX] to >> > be >> > able to replace an existing commit message, but that's not there yet. >> >> Have you considered only auto-generating %changelog entries since the >> last commit that changed the %changelog section? > > We thought about that, pull the last changelog from the last build, get the > commit hash of that last build and only generate the new changelog from > HEAD... > The issue was: how to fix existing entries (typo, wrong content...) and our > thought on this was that it would be easier to re-generate the entire > changelog > for this reason. > >> To fix entries, you would run a tool to materialize the current >> auto-generated %changelog (and Release:), and then make the necessary >> corrections and additions. > > Where would this corrections/additions live though? > We were thinking to include the corrections in other/new commits but if we > don't > reach the old commits, we can't correct them. > > What did you have in mind? Sorry for being unclear. The spec file in dist-git would still show some (older) version of the %changelog entries under this model. The corrections would update the %changelog with all the historic entries. Since auto-generation stops at this commit, the new generated %changelog will include the fixed entries. This would also avoid the need for a new knob to adjust how far back the %changelog generation goes. Thanks, Florian ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Ideas for better development processes when maintaining hundreds of packages
On Tue, Jan 28, 2020 at 01:53:32PM +0100, Florian Weimer wrote: > * Pierre-Yves Chibon: > > > Feel free to poke at it and see how it behaves. > > > > The script only considers: > > - the last two years of commits > > - commits touching either the spec file or patches (ending with .patch) > > > > We want a way to say: [Ignore XXX] (or simply [Ignore] if it's the current > > commit that should be ignored), as well as a way to say: [Replace XXX] to be > > able to replace an existing commit message, but that's not there yet. > > Have you considered only auto-generating %changelog entries since the > last commit that changed the %changelog section? We thought about that, pull the last changelog from the last build, get the commit hash of that last build and only generate the new changelog from HEAD... The issue was: how to fix existing entries (typo, wrong content...) and our thought on this was that it would be easier to re-generate the entire changelog for this reason. > To fix entries, you would run a tool to materialize the current > auto-generated %changelog (and Release:), and then make the necessary > corrections and additions. Where would this corrections/additions live though? We were thinking to include the corrections in other/new commits but if we don't reach the old commits, we can't correct them. What did you have in mind? Thanks, Pierre ___ 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
Re: Ideas for better development processes when maintaining hundreds of packages
* Pierre-Yves Chibon: > Feel free to poke at it and see how it behaves. > > The script only considers: > - the last two years of commits > - commits touching either the spec file or patches (ending with .patch) > > We want a way to say: [Ignore XXX] (or simply [Ignore] if it's the current > commit that should be ignored), as well as a way to say: [Replace XXX] to be > able to replace an existing commit message, but that's not there yet. Have you considered only auto-generating %changelog entries since the last commit that changed the %changelog section? To fix entries, you would run a tool to materialize the current auto-generated %changelog (and Release:), and then make the necessary corrections and additions. Thanks, Florian ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Fedora Packager Dashboard mockups
On 24. 12. 19 9:50, Dan Čermák wrote: Hi Miro, I like your packaging dashboard a lot, I think this a good idea and an improvement for the packaging experience! Dan, thanks for your feedback and an offer to help. Sorry for the very late reply. Unfortunately, my idea to work on this during the winter holiday turned out to be non realistic. Hence the mockup is all I have so far and there is really nothing to help with, as nothing is going on. I wish I had more time to devote to this, but frankly, I just don't :( -- 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
Re: Ideas for better development processes when maintaining hundreds of packages
On Tue, 28 Jan 2020 at 05:41, Daniel P. Berrangé wrote: > > On Tue, Jan 28, 2020 at 11:32:46AM +0100, Guido Aulisi wrote: > > Il giorno mar 28 gen 2020 alle ore 10:04 Richard W.M. Jones > > ha scritto: > > > > > > I always think that Fedora works fine if you maintain 1-5 packages. > > > It's possible to maintain 20 with a lot of work. And if you want to > > > maintain 100+ (things like the ocaml-* set that I help to maintain) > > > then you have to write your own automation. Could we do things > > > better? No one asked for them, but here are my ideas ... > > > > > > --- > > > > > > * kill the %changelog > > > > > > Please, let's kill it, and generate it from the git changelog. > > > I'm glad to see there's a proposal to do this. > > > > > > A general principle I'm following here is a packager should never > > > be asked to enter the same information twice. > > > > > > * committing to git should build the package > > > > > > Is there a reason why this wouldn't be the case? > > > > Sometimes you only add comments to the spec file and a rebuild is not > > needed. > > What % of commits to dist-git are this scenario ? I've done this myself > but a few times but for myself it is a 2-3% of my commits don't involve > a build. There is no real harm in doing a build in these cases IMHO. It > would have negligible extra burden on Fedora build infrastructure, while > potentially simplifying the common case for maintainers. > I want to start off by saying I think that Richard's ideas on the whole would be good.. however I do not think any of them would be a negligible extra burden. The problem is we only have so much disk space, so many builders, and we have way too many ways for builds and composes to fail which takes up time that would be used to fix other problems. And finally we have a limited budget of people who work on the build system nearly full-time. That means we usually have to graft on some new set of tools onto the existing build system which ends up adding even more ways to cause failures. -- Stephen J Smoogen. ___ 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
Re: What would it take to drop release and changelog from our spec files? (and do we want to?)
On Tue, Jan 28, 2020 at 7:27 AM Pierre-Yves Chibon wrote:
>
> On Fri, Jan 10, 2020 at 09:54:59PM -0500, Neal Gompa wrote:
> > On Fri, Jan 10, 2020 at 11:37 AM Pierre-Yves Chibon
> > wrote:
> > >
> > >
> > > The release field would need to be set by koji ignoring whatever is in
> > > the spec
> > > file. How do we want to do this?
> > > - Based on dates?
> > > - Using an always increasing integer?
> > > - Using the number of successful builds since the last time the version
> > > field changed?
> > > - Another idea?
> > >
> > > The third option looks like to be the one closest to our current behavior.
> > >
> >
> > I always envisioned that we'd use a variant of the third option.
> >
> > The options I've thought of:
> >
> > * %{dist}.
> > * .%{?dist}
> > * %{dist}..
>
> I've been thinking a bit about this and been wondering any reason why not to
> do
> simply?
>%{dist}
>
> This would basically mimic what we are currently doing by hand, it would be
> the
> less changes to our current way of working (making opting-in smoother).
>
If we're not doing automatic builds, sure. I've been going on two big
assumptions:
1. We're going to do automatic building
2. We need *some* kind of stable leading portion of release for
packagers to use for specified dependencies, especially
Obsoletes+Provides combos.
--
真実はいつも一つ！/ Always, there's only one truth!
___
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
Re: What would it take to drop release and changelog from our spec files? (and do we want to?)
On Fri, Jan 10, 2020 at 09:54:59PM -0500, Neal Gompa wrote:
> On Fri, Jan 10, 2020 at 11:37 AM Pierre-Yves Chibon
> wrote:
> >
> >
> > The release field would need to be set by koji ignoring whatever is in the
> > spec
> > file. How do we want to do this?
> > - Based on dates?
> > - Using an always increasing integer?
> > - Using the number of successful builds since the last time the version
> > field changed?
> > - Another idea?
> >
> > The third option looks like to be the one closest to our current behavior.
> >
>
> I always envisioned that we'd use a variant of the third option.
>
> The options I've thought of:
>
> * %{dist}.
> * .%{?dist}
> * %{dist}..
I've been thinking a bit about this and been wondering any reason why not to do
simply?
%{dist}
This would basically mimic what we are currently doing by hand, it would be the
less changes to our current way of working (making opting-in smoother).
Thanks,
Pierre
___
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
Re: Java Dev Group and Fedora Quality
On Tue, Jan 28, 2020 at 12:18 AM Neal Gompa wrote: > Honestly, the correct thing is to make it so the maven to RPM > interface is as transparent as possible. We've done a reasonably good > job with this in Rust, Ruby, and Python, and the situation is (slowly) > improving in Go. But nobody has sat down and looked at what we have in > RPM today and taken a fresh look at how Java packaging *could* work. I [...] > Riffing off what Florian had for his DevConf.cz talk title, > JPackage/RPM Java is basically packaging like it's 1999. The rest of > the ecosystems are moving forward. Java has not. And I think that's > where a lot of the pain exists. That is not true. Java packaging in Fedora has been improved a lot over the past years. In the last few years we have automated or improved many things, such as: - removal of post/postun scriptlets for Maven metadata generation, - auto-requires/provides for Maven and OSGi artifacts, - versioned auto-requires on JRE/JDK, - macros for POM editing, - integration with various build systems, incl. Maven, Tycho, Gradle, Ivy, - automatic documentation (javadoc) generation, - javadoc subpackage generation, - buildrequires generation during build, - auto buildrequires (with mock plugin), and many more > But without interest or investment from the Java stack packagers at > Red Hat, there's basically no way to get a redesign of Java packaging > done, much less even on the table. I don't see any need for total redesign of Java packaging, but if anyone wants to do it, you can count on me to participate in that effort. Likewise, I'm interested in making smaller improvements to the current design. If anyone has any requests or suggestions for improvements to Java packaging, you can write to java-devel list or open issue at https://github.com/fedora-java/javapackages/issues -- Mikolaj Izdebski ___ 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
Re: Ideas for better development processes when maintaining hundreds of packages
On Tue, Jan 28, 2020 at 11:32:46AM +0100, Guido Aulisi wrote: > Il giorno mar 28 gen 2020 alle ore 10:04 Richard W.M. Jones > ha scritto: > > > > I always think that Fedora works fine if you maintain 1-5 packages. > > It's possible to maintain 20 with a lot of work. And if you want to > > maintain 100+ (things like the ocaml-* set that I help to maintain) > > then you have to write your own automation. Could we do things > > better? No one asked for them, but here are my ideas ... > > > > --- > > > > * kill the %changelog > > > > Please, let's kill it, and generate it from the git changelog. > > I'm glad to see there's a proposal to do this. > > > > A general principle I'm following here is a packager should never > > be asked to enter the same information twice. > > > > * committing to git should build the package > > > > Is there a reason why this wouldn't be the case? > > Sometimes you only add comments to the spec file and a rebuild is not needed. In the current situation, the build would fail in koji because you did not touch either version nor release. So koji will very quickly fail and move on. In the future, if you opt-in for auto-generated changelog and release fields, this may result in an actual build, which will make koji busy for a little while long and then it'll stay there, on its own, until it's garbage collected. The only release for which this would end up going to the user would be rawhide. Pierre ___ 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
Re: Ideas for better development processes when maintaining hundreds of packages
On Tue, Jan 28, 2020 at 09:03:09AM +, Richard W.M. Jones wrote: > I always think that Fedora works fine if you maintain 1-5 packages. > It's possible to maintain 20 with a lot of work. And if you want to > maintain 100+ (things like the ocaml-* set that I help to maintain) > then you have to write your own automation. Could we do things > better? No one asked for them, but here are my ideas ... > > --- > > * kill the %changelog > > Please, let's kill it, and generate it from the git changelog. > I'm glad to see there's a proposal to do this. > > A general principle I'm following here is a packager should never > be asked to enter the same information twice. There are a few tricky things about this, but overall I think it's doable and some of the tricky things may just be things we just have to accept as being different from the current situation. We are playing a bit of a proof of concept of what a RPM changelog generated from git logs could look like. The outcome of this is at: https://pagure.io/Fedora-Infra/generate_changelog/tree/master Feel free to poke at it and see how it behaves. The script only considers: - the last two years of commits - commits touching either the spec file or patches (ending with .patch) We want a way to say: [Ignore XXX] (or simply [Ignore] if it's the current commit that should be ignored), as well as a way to say: [Replace XXX] to be able to replace an existing commit message, but that's not there yet. One of the thing that may change is that we may end up with changelog entry that do not have a corresponding nvr at the end. The python script above shows that, it'll only add the v-r in the changelog when either one of them changed, if they are the same, it doesn't specify them. Another aspect that is getting trickier is: - update to 1.1-1 - fix missing BR - spec clean up 3 commits, can all be either on 3 different days but could also be on the same day. Could be from 3 different people, but could also be from the same person. So we could have 3 commits, on 1 day from 1 person, two of which would make sense to group together (update to 1.1-1 and fix missing BR) and one that shouldn't since the build succeeded before that and thus the -1 that goes out to the mirror will not have this clean up entry. The current approach we took is: we have 3 entries in the changelog (and only one has the v-r specified). It's not ideal, but we don't quite see how to solve this question yet. If the "spec clean up" contains "[ignore]", that question is solved, but if we replace "spec clean up" with "Drop sub-package foo" then we do not have a good idea on how to consolidate the commit messages into a single changelog entry. Suggestions welcome :) > * committing to git should build the package > > Is there a reason why this wouldn't be the case? That was part of the proposal we debated last fall and there seemed to be much more people against this than I thought there would be. Maybe we could start with having an opt-in approach. > * commit groups of packages together > > One reason why automatic commit -> build might not be desirable is if > you're trying to build a group of packages in a side tag. In my > opinion this means we should allow groups of packages to be committed > together. (Unfortunately because we chose to put every package in its > own git repo, the obvious way to do this can't work, but we could > still have a "ChangeId:" header in the commit message that ties > packages together). > > The packages should be built in build dependency order into a side > tag, and the side tag turned into an update, with no further > involvement from the packager unless something fails to build. > > This change on its own would solve the main problem that > affects people maintaining large sets of packages. If we use a magic word to support opt-into automating commit -> build, we could get partly there. BuildIn: Fedora, EPEL BuildIn: BuildIn: rawhide ... > * “Fixes:” etc headers in git > > RHEL already does this. It should be possible to add special headers > to the commit message to automatically close bugs, ie: > > $ git commit -m "ocaml: Update to version 4.10.0 > Fixes: RHBZ#12345" > > Note the build, update and bug closing would happen completely > automatically, assuming there was no build or test failure. We clearly don't have a good mapping from commit messages to bugzilla. dist-git has the info, either in the rpm changelog or in the git commit messages koji has only the info of the git commit it was triggered from bodhi works at the nevr level. A lot of food for thoughts here :) Pierre ___ 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:
[Bug 1795427] perl-YAML-1.30 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1795427 Paul Howarth changed: What|Removed |Added Status|NEW |CLOSED Fixed In Version||perl-YAML-1.30-1.fc32 Resolution|--- |RAWHIDE Doc Type|--- |If docs needed, set a value Last Closed||2020-01-28 10:59:42 --- Comment #2 from Paul Howarth --- Build done: https://koji.fedoraproject.org/koji/taskinfo?taskID=41127779 -- You are receiving this mail because: You are on the CC list for the bug. ___ 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
Fedora-Cloud-31-20200128.0 compose check report
No missing expected images. Passed openQA tests: 1/1 (x86_64) -- 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
Re: Ideas for better development processes when maintaining hundreds of packages
On Tue, Jan 28, 2020 at 11:32:46AM +0100, Guido Aulisi wrote: > Il giorno mar 28 gen 2020 alle ore 10:04 Richard W.M. Jones > ha scritto: > > > > I always think that Fedora works fine if you maintain 1-5 packages. > > It's possible to maintain 20 with a lot of work. And if you want to > > maintain 100+ (things like the ocaml-* set that I help to maintain) > > then you have to write your own automation. Could we do things > > better? No one asked for them, but here are my ideas ... > > > > --- > > > > * kill the %changelog > > > > Please, let's kill it, and generate it from the git changelog. > > I'm glad to see there's a proposal to do this. > > > > A general principle I'm following here is a packager should never > > be asked to enter the same information twice. > > > > * committing to git should build the package > > > > Is there a reason why this wouldn't be the case? > > Sometimes you only add comments to the spec file and a rebuild is not needed. What % of commits to dist-git are this scenario ? I've done this myself but a few times but for myself it is a 2-3% of my commits don't involve a build. There is no real harm in doing a build in these cases IMHO. It would have negligible extra burden on Fedora build infrastructure, while potentially simplifying the common case for maintainers. Regards, Daniel -- |: https://berrange.com -o-https://www.flickr.com/photos/dberrange :| |: https://libvirt.org -o-https://fstop138.berrange.com :| |: https://entangle-photo.org-o-https://www.instagram.com/dberrange :| ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Ideas for better development processes when maintaining hundreds of packages
On Tue, 28 Jan 2020 at 10:53, Richard W.M. Jones wrote: > > On Tue, Jan 28, 2020 at 10:21:41AM +0100, Milan Crha wrote: > > On Tue, 2020-01-28 at 10:03 +0100, Richard W.M. Jones wrote: > > > * committing to git should build the package > > > > > > Is there a reason why this wouldn't be the case? > > > > Hi, > > the answer for the above is just your following point: > > > > > * commit groups of packages together > > > > aka the dependencies. Sometimes you want a special side tag, sometimes > > it's not needed. The way I do it right now (it's only about 4 packages > > depending on each other, not hundreds), is that I commit to master, > > then to stable, then the second package to master, to stable, then > > third and finally to the fourth and then I ran a chain-build as this: > > "a : b : c " in package 'd', (which builds 'c' and 'd' in parallel, > > once 'a' and 'b' are built in serial). Then I just refresh the koji > > build page from time to time and verify that the build still runs > > and/.or it finished successfully. I can run chain-build in stable too, > > it only needs a bit more intervention, to define overrides for 'a' and > > 'b' in bodhi, to be able to build them. > > > > I'm afraid fully automating such things might be a challenge. In other > > words, properly solving dependencies is problematic. Having yet another > > syntax to describe it, or the groups you suggest, scares me a bit. And > > we are not talking about inter-package dependencies, with packages you > > are not maintaining. > > This is not a problem - it has been solved several times > independently. I most recently proposed this, but it's certainly > isn't the first time it has been done: > > https://rwmj.wordpress.com/2020/01/14/goals-an-experimental-new-tool-which-generalizes-make/ > http://git.annexia.org/?p=fedora-ocaml-rebuild.git;a=summary > > What we need is Fedora to recognize that maintaining 100s of packages > mostly automatically should be a goal. If you look at the ecosystems > around language packaging (cpan, nodejs, crates, opam, etc) this ought > to be self-evident. When there's a unified well-organized language-specific ecosystem (and rpm-friendly; see the Java case...) it's definitely easier to do this, and yet... See [1] for example (and follow the "Homepage" button to see the tooling and setup) for an attempt to maintain thousands of packages for a particular ecosystem that is quite strict and homogeneous. And yet, as I said, many aspects of those specs wouldn't pass a package review. That said, I completely agree that "maintaining 100s of packages mostly automatically" should be a goal. Iñaki [1] https://copr.fedorainfracloud.org/coprs/iucar/cran/ ___ 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
Re: Ideas for better development processes when maintaining hundreds of packages
Il giorno mar 28 gen 2020 alle ore 10:04 Richard W.M. Jones ha scritto: > > I always think that Fedora works fine if you maintain 1-5 packages. > It's possible to maintain 20 with a lot of work. And if you want to > maintain 100+ (things like the ocaml-* set that I help to maintain) > then you have to write your own automation. Could we do things > better? No one asked for them, but here are my ideas ... > > --- > > * kill the %changelog > > Please, let's kill it, and generate it from the git changelog. > I'm glad to see there's a proposal to do this. > > A general principle I'm following here is a packager should never > be asked to enter the same information twice. > > * committing to git should build the package > > Is there a reason why this wouldn't be the case? Sometimes you only add comments to the spec file and a rebuild is not needed. Ciao Guido ___ 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
Re: Fedora 32 Mass Rebuild
Hi,
On 28-01-2020 10:37, Vascom wrote:
Are s390x builders ready for Mass Rebuild?
I see many fail builds only on s390x without logs.
I was about to ask the same thing, there are logs though, but only
from koji or mock, not from an actual build, e.g. :
https://koji.fedoraproject.org/koji/taskinfo?taskID=41124919
"
Result
Traceback (most recent call last):
File "/usr/lib/python3.7/site-packages/koji/daemon.py", line 1294, in runTask
response = (handler.run(),)
File "/usr/lib/python3.7/site-packages/koji/tasks.py", line 313, in run
return koji.util.call_with_argcheck(self.handler, self.params, self.opts)
File "/usr/lib/python3.7/site-packages/koji/util.py", line 263, in
call_with_argcheck
return func(*args, **kwargs)
File "/usr/sbin/kojid", line 1343, in handler
h = koji.get_rpm_header(fn)
File "/usr/lib/python3.7/site-packages/koji/__init__.py", line 914, in
get_rpm_header
hdr = ts.hdrFromFdno(fo.fileno())
File "/usr/lib64/python3.7/site-packages/rpm/transaction.py", line 185, in
hdrFromFdno
raise rpm.error("error reading package header")
_rpm.error: error reading package header
"
I hope that these failed builds can be automatically retried (once the problem
is solved)
and that as a package maintainer I do not end up having to resubmit all of these
manually?
Regards,
Hans
вт, 28 янв. 2020 г. в 11:39, Mohan Boddu :
We are starting the mass rebuild now.
Thanks.
On Mon, Jan 27, 2020 at 5:38 PM Jeff Law wrote:
On Mon, 2020-01-27 at 21:23 +0100, Fabio Valentini wrote:
On Mon, Jan 27, 2020 at 4:46 PM Jeff Law wrote:
On Mon, 2020-01-27 at 16:34 +0100, Jakub Jelinek wrote:
On Mon, Jan 27, 2020 at 10:25:50AM -0500, Mohan Boddu wrote:
Hi all,
Per the Fedora 32 schedule[1] we will be starting a mass rebuild for
Fedora 32 today. We are doing a mass rebuild for Fedora 32 for all the
changes:
https://fedoraproject.org/wiki/Changes/GLIBC231
https://fedoraproject.org/wiki/Releases/32/ChangeSet#Binutils_2.33
https://fedoraproject.org/wiki/Changes/FontLangProvidesToLangpacks
https://fedoraproject.org/wiki/Changes/golang1.14
https://fedoraproject.org/wiki/Changes/GCC10
https://fedoraproject.org/wiki/Changes/Free_Pascal_Compiler_3.2.0
we will start the mass rebuild on 2020-01-27
I thought the mass rebuild should be also for
https://fedoraproject.org/wiki/LTOByDefault
but the required changes AFAIK haven't landed into redhat-rpm-config yet.
CCing Jeff on the current state.
(snip)
After finally starting looking at the LTO vs GDB issues last week, I
think we should defer LTO until F33. There's just too many GDB
failures when used with LTO that aren't understood yet.
Since the mass rebuild starts today (or has already started), you're
cutting it pretty close there ...
So you'll either need to postpone to F33 or request a second mass
rebuild - soon.
Can you comment on the FESCo ticket with the current status? Just to
keep us in the loop
Umm, Ben and I were already discussing the situation this morning. I
believe the page and fesco ticket both have current state (deferring to
F33).
jeff
___
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
___
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
___
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
___
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
[Bug 987118] perl-5.18: File handles modified with binmode ':unix' leak
https://bugzilla.redhat.com/show_bug.cgi?id=987118 --- Comment #14 from Petr Pisar --- A potential fix was committed to the upstream as d55a14617a40beb0dfda90ca2decc55918c0810c. -- You are receiving this mail because: You are on the CC list for the bug. ___ 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
Re: Bubblemail: looking for package maintainer
Hi, Robert-André was faster than myself :) Regards, Javier ___ 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
Re: Ideas for better development processes when maintaining hundreds of packages
On Tue, Jan 28, 2020 at 10:21:41AM +0100, Milan Crha wrote: > On Tue, 2020-01-28 at 10:03 +0100, Richard W.M. Jones wrote: > > * committing to git should build the package > > > > Is there a reason why this wouldn't be the case? > > Hi, > the answer for the above is just your following point: > > > * commit groups of packages together > > aka the dependencies. Sometimes you want a special side tag, sometimes > it's not needed. The way I do it right now (it's only about 4 packages > depending on each other, not hundreds), is that I commit to master, > then to stable, then the second package to master, to stable, then > third and finally to the fourth and then I ran a chain-build as this: > "a : b : c " in package 'd', (which builds 'c' and 'd' in parallel, > once 'a' and 'b' are built in serial). Then I just refresh the koji > build page from time to time and verify that the build still runs > and/.or it finished successfully. I can run chain-build in stable too, > it only needs a bit more intervention, to define overrides for 'a' and > 'b' in bodhi, to be able to build them. > > I'm afraid fully automating such things might be a challenge. In other > words, properly solving dependencies is problematic. Having yet another > syntax to describe it, or the groups you suggest, scares me a bit. And > we are not talking about inter-package dependencies, with packages you > are not maintaining. This is not a problem - it has been solved several times independently. I most recently proposed this, but it's certainly isn't the first time it has been done: https://rwmj.wordpress.com/2020/01/14/goals-an-experimental-new-tool-which-generalizes-make/ http://git.annexia.org/?p=fedora-ocaml-rebuild.git;a=summary What we need is Fedora to recognize that maintaining 100s of packages mostly automatically should be a goal. If you look at the ecosystems around language packaging (cpan, nodejs, crates, opam, etc) this ought to be self-evident. Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones Read my programming and virtualization blog: http://rwmj.wordpress.com Fedora Windows cross-compiler. Compile Windows programs, test, and build Windows installers. Over 100 libraries supported. http://fedoraproject.org/wiki/MinGW ___ 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
Re: Review swaps (antlr4 reboot)
On Tue, Jan 28, 2020, 05:44 Jerry James wrote: > Greetings, > > The antlr4 package needs a reboot so that it can ship the various > language runtime libraries, and so that it can be updated to the > latest version. I have been in contact with the maintainers of the > current antlr4 package and have received approval to proceed with > this. > > I would like to swap reviews for the following: > > treelayout: https://bugzilla.redhat.com/show_bug.cgi?id=1795467 > This package was previously in Fedora, but was retired after being > orphaned. It has been retired long enough that a re-review is > necessary. > > mojo-executor: https://bugzilla.redhat.com/show_bug.cgi?id=1795468 > > string-template-maven-plugin: > https://bugzilla.redhat.com/show_bug.cgi?id=1795469 > Depends on mojo-executor. > > antlr4-cpp-runtime: https://bugzilla.redhat.com/show_bug.cgi?id=1795470 > Depends on treelayout and string-template-maven-plugin. The funny > name is because, so far as I am aware, it is still not possible to > have a noarch main package with arch-specific subpackages. I selected > one of the arch-specific language runtimes to be the main package, and > antlr4 itself (which is noarch) is a subpackage. Once this package is > in Rawhide, the existing antlr4 package will be retired and the > antlr4-python3-runtime subpackage will be removed from the coq > package. > Hi Jerry, I'll take a look at your review requests. I've been steeping in Java packaging for so long that I might as well do it ;) I'll have some simple packages for you to review in return. Fabio > Thanks in advance. Regards, > -- > Jerry James > http://www.jamezone.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 > ___ 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
Re: Fedora 32 Mass Rebuild
Are s390x builders ready for Mass Rebuild? I see many fail builds only on s390x without logs. вт, 28 янв. 2020 г. в 11:39, Mohan Boddu : > > We are starting the mass rebuild now. > > Thanks. > > On Mon, Jan 27, 2020 at 5:38 PM Jeff Law wrote: > > > > On Mon, 2020-01-27 at 21:23 +0100, Fabio Valentini wrote: > > > On Mon, Jan 27, 2020 at 4:46 PM Jeff Law wrote: > > > > On Mon, 2020-01-27 at 16:34 +0100, Jakub Jelinek wrote: > > > > > On Mon, Jan 27, 2020 at 10:25:50AM -0500, Mohan Boddu wrote: > > > > > > Hi all, > > > > > > > > > > > > Per the Fedora 32 schedule[1] we will be starting a mass rebuild for > > > > > > Fedora 32 today. We are doing a mass rebuild for Fedora 32 for all > > > > > > the > > > > > > changes: > > > > > > > > > > > > https://fedoraproject.org/wiki/Changes/GLIBC231 > > > > > > https://fedoraproject.org/wiki/Releases/32/ChangeSet#Binutils_2.33 > > > > > > https://fedoraproject.org/wiki/Changes/FontLangProvidesToLangpacks > > > > > > https://fedoraproject.org/wiki/Changes/golang1.14 > > > > > > https://fedoraproject.org/wiki/Changes/GCC10 > > > > > > https://fedoraproject.org/wiki/Changes/Free_Pascal_Compiler_3.2.0 > > > > > > > > > > > > we will start the mass rebuild on 2020-01-27 > > > > > > > > > > I thought the mass rebuild should be also for > > > > > https://fedoraproject.org/wiki/LTOByDefault > > > > > but the required changes AFAIK haven't landed into redhat-rpm-config > > > > > yet. > > > > > > > > > > CCing Jeff on the current state. > > > > > > (snip) > > > > > > > After finally starting looking at the LTO vs GDB issues last week, I > > > > think we should defer LTO until F33. There's just too many GDB > > > > failures when used with LTO that aren't understood yet. > > > > > > Since the mass rebuild starts today (or has already started), you're > > > cutting it pretty close there ... > > > > > > So you'll either need to postpone to F33 or request a second mass > > > rebuild - soon. > > > > > > Can you comment on the FESCo ticket with the current status? Just to > > > keep us in the loop > > Umm, Ben and I were already discussing the situation this morning. I > > believe the page and fesco ticket both have current state (deferring to > > F33). > > > > jeff > > > > > ___ > > 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 > ___ > 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 ___ 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
Re: Java Checkstyle Blocked Even Though Build was Successful
Dne 28. 01. 20 v 5:07 Scott Talbert napsal(a): > On Tue, 28 Jan 2020, Bill Chatfield via devel wrote: > >> Are any of you on the java-devel list so that I could move my newb >> questions >> there? I can guarantee that it's a low-traffic list so there's no >> risk in >> joining it. :-) >> >> google-http-java-client looks easy to fix. It won't build because it >> needs >> one dependency, maven-checkstyle-plugin, which won't build because it >> needs >> one dependency, checkstyle. But, checkstyle is blocked even though built >> successfully the last time. >> >> So, all three packages look unnecessarily blocked. > > checkstyle was retired because it was orphaned for 6+ weeks. I don't > know why it was orphaned, but since it was retired 6 months ago, it > will have to be re-reviewed to come back. In that case this should be the process: https://fedoraproject.org/wiki/Orphaned_package_that_need_new_maintainers#Claiming_Ownership_of_a_Retired_Package Vít > > Scott > > ___ > 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 ___ 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
Re: Java Checkstyle Blocked Even Though Build was Successful
On Tue, Jan 28, 2020, 05:08 Scott Talbert wrote: > On Tue, 28 Jan 2020, Bill Chatfield via devel wrote: > > > Are any of you on the java-devel list so that I could move my newb > questions > > there? I can guarantee that it's a low-traffic list so there's no risk in > > joining it. :-) > > > > google-http-java-client looks easy to fix. It won't build because it > needs > > one dependency, maven-checkstyle-plugin, which won't build because it > needs > > one dependency, checkstyle. But, checkstyle is blocked even though built > > successfully the last time. > > > > So, all three packages look unnecessarily blocked. > > checkstyle was retired because it was orphaned for 6+ weeks. I don't know > why it was orphaned, but since it was retired 6 months ago, it will have > to be re-reviewed to come back. > IIRC, it was orphaned in the 11/2018 extinction event. The Stewardship SIG temporarily picked it up, but we opted for dropping it because the packaged version was pretty outdated and had open CVEs associated with it. In almost all cases, checkstyle should not be essential for package builds, and you should be able to just disable the maven plugin without consequences: %prep (setup and patches be here) %pom_disable_plugin :maven-checkstyle-plugin Fabio > Scott___ > 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 > ___ 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
Re: Unannounced soname bump with samba 4.12~rc1
On Sun, 2020-01-26 at 00:12 +0100, Fabio Valentini wrote: > - evolution-mapi > - openchange(-client) Hi, the above two are rebuilt too. Bye, Milan ___ 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
Re: Ideas for better development processes when maintaining hundreds of packages
On Tue, 2020-01-28 at 10:03 +0100, Richard W.M. Jones wrote: > * committing to git should build the package > > Is there a reason why this wouldn't be the case? Hi, the answer for the above is just your following point: > * commit groups of packages together aka the dependencies. Sometimes you want a special side tag, sometimes it's not needed. The way I do it right now (it's only about 4 packages depending on each other, not hundreds), is that I commit to master, then to stable, then the second package to master, to stable, then third and finally to the fourth and then I ran a chain-build as this: "a : b : c " in package 'd', (which builds 'c' and 'd' in parallel, once 'a' and 'b' are built in serial). Then I just refresh the koji build page from time to time and verify that the build still runs and/.or it finished successfully. I can run chain-build in stable too, it only needs a bit more intervention, to define overrides for 'a' and 'b' in bodhi, to be able to build them. I'm afraid fully automating such things might be a challenge. In other words, properly solving dependencies is problematic. Having yet another syntax to describe it, or the groups you suggest, scares me a bit. And we are not talking about inter-package dependencies, with packages you are not maintaining. Bye, Milan ___ 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
Ideas for better development processes when maintaining hundreds of packages
I always think that Fedora works fine if you maintain 1-5 packages. It's possible to maintain 20 with a lot of work. And if you want to maintain 100+ (things like the ocaml-* set that I help to maintain) then you have to write your own automation. Could we do things better? No one asked for them, but here are my ideas ... --- * kill the %changelog Please, let's kill it, and generate it from the git changelog. I'm glad to see there's a proposal to do this. A general principle I'm following here is a packager should never be asked to enter the same information twice. * committing to git should build the package Is there a reason why this wouldn't be the case? * commit groups of packages together One reason why automatic commit -> build might not be desirable is if you're trying to build a group of packages in a side tag. In my opinion this means we should allow groups of packages to be committed together. (Unfortunately because we chose to put every package in its own git repo, the obvious way to do this can't work, but we could still have a "ChangeId:" header in the commit message that ties packages together). The packages should be built in build dependency order into a side tag, and the side tag turned into an update, with no further involvement from the packager unless something fails to build. This change on its own would solve the main problem that affects people maintaining large sets of packages. * “Fixes:” etc headers in git RHEL already does this. It should be possible to add special headers to the commit message to automatically close bugs, ie: $ git commit -m "ocaml: Update to version 4.10.0 Fixes: RHBZ#12345" Note the build, update and bug closing would happen completely automatically, assuming there was no build or test failure. * CVE bugs should autoclose when a package is rebased Fabiano built the mingw-openssl package recently, but there are still a load of open CVE bugs against this package referring to the older version. These should be closed automatically. I think this will require collecting the version of the package that fixes a CVE and recording that in Bugzilla (or in the package itself in some standard way). * create streams of packages automatically depending on quality scores We know a lot about packages such as: - How many bugs are opened against them? - What's the average time between a bug being filed and fixed? - Do they get regularly updated? - Do they pass or fail CI tests? - How many rpmlint / fedora-packager problems do they have? Why don't we use that data to build streams of high quality and lesser quality packages? Allow the end users to choose whether they want the best curated packages only, or they're prepared to accept the risk of taking a package with lots of bugs or CVEs (this is assuming the previous point is fixed, so these are real CVEs, not irrelevant bugs). If you want to go even further with this idea, then it could even be possible we allow packages into Fedora without any review. They would start in the outermost stream in a "there be dragons" repository that only the foolhardy would enable, but as their quality improved they would *automatically* migrate into the mainstream. --- Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones Read my programming and virtualization blog: http://rwmj.wordpress.com Fedora Windows cross-compiler. Compile Windows programs, test, and build Windows installers. Over 100 libraries supported. http://fedoraproject.org/wiki/MinGW ___ 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
Re: Fedora 32 Mass Rebuild
We are starting the mass rebuild now. Thanks. On Mon, Jan 27, 2020 at 5:38 PM Jeff Law wrote: > > On Mon, 2020-01-27 at 21:23 +0100, Fabio Valentini wrote: > > On Mon, Jan 27, 2020 at 4:46 PM Jeff Law wrote: > > > On Mon, 2020-01-27 at 16:34 +0100, Jakub Jelinek wrote: > > > > On Mon, Jan 27, 2020 at 10:25:50AM -0500, Mohan Boddu wrote: > > > > > Hi all, > > > > > > > > > > Per the Fedora 32 schedule[1] we will be starting a mass rebuild for > > > > > Fedora 32 today. We are doing a mass rebuild for Fedora 32 for all the > > > > > changes: > > > > > > > > > > https://fedoraproject.org/wiki/Changes/GLIBC231 > > > > > https://fedoraproject.org/wiki/Releases/32/ChangeSet#Binutils_2.33 > > > > > https://fedoraproject.org/wiki/Changes/FontLangProvidesToLangpacks > > > > > https://fedoraproject.org/wiki/Changes/golang1.14 > > > > > https://fedoraproject.org/wiki/Changes/GCC10 > > > > > https://fedoraproject.org/wiki/Changes/Free_Pascal_Compiler_3.2.0 > > > > > > > > > > we will start the mass rebuild on 2020-01-27 > > > > > > > > I thought the mass rebuild should be also for > > > > https://fedoraproject.org/wiki/LTOByDefault > > > > but the required changes AFAIK haven't landed into redhat-rpm-config > > > > yet. > > > > > > > > CCing Jeff on the current state. > > > > (snip) > > > > > After finally starting looking at the LTO vs GDB issues last week, I > > > think we should defer LTO until F33. There's just too many GDB > > > failures when used with LTO that aren't understood yet. > > > > Since the mass rebuild starts today (or has already started), you're > > cutting it pretty close there ... > > > > So you'll either need to postpone to F33 or request a second mass > > rebuild - soon. > > > > Can you comment on the FESCo ticket with the current status? Just to > > keep us in the loop > Umm, Ben and I were already discussing the situation this morning. I > believe the page and fesco ticket both have current state (deferring to > F33). > > jeff > > > ___ > 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 ___ 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
Fedora-Cloud-30-20200128.0 compose check report
No missing expected images. Passed openQA tests: 1/1 (x86_64) -- 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
Re: swap-on-ZRAM by default
On Mon, Jan 27, 2020 at 03:02:38PM -0500, Rahul Sundaram wrote: > Hi > > On Mon, Jan 27, 2020 at 8:56 AM Zbigniew Jędrzejewski-Szmek wrote: > > > It is "upstream" in the sense that it is under the same umbrella. > > There are no plans to move the code to the main repo, because it's in > > rust and currently combining meson which is used for systemd proper > > with rust and cargo is not very convenient. > > > > A bit of a tangent but there was a proposal for systemd itself to start > using C++ at some point. Was that or Rust still in consideration? C++ is not being considered — if we switch the language, we'd like to make a bigger leap, i.e. rather to Rust than to C++. This generator is exactly "Rust [being] in consideration". Zbyszek ___ 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
