Re: Stepping away from packaging (and request for owners)
On 19/10/2019 20:38, Jamie Nguyen wrote: === [a]: Need owner === ledger I can take this. This is such a useful utility that it'd be a shame to have it be orphaned. Best of regards, Jani ___ 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: Stepping away from packaging (and request for owners)
Hi Jamie, Jamie Nguyen writes: > == > [b]: Remove my admin/commit access > == > > adobe-source-code-pro-fonts > libmpdclient > libuv > mpc > ncmpc > newsbeuter > notmuch I'd be willing to help out with notmuch, as I am using it quite extensively. Cheers, Dan ___ 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: No More LMMS Updates to Fedora?
Thanks Adam for the information. By the way I meant version 1.2, as v2.0 does not even exist. I'll try contacting the current maintainer as you suggested. Best regards On Sun, Oct 20, 2019, 7:47 AM Adam Williamson wrote: > On Sat, 2019-10-19 at 14:35 -0400, Code Zombie wrote: > > It seems that Fedora repo has been providing lmms version 1.1.3 roughly > > released three years ago. I'm curious if that is there is no one to > > maintain the package or there are legal problems with the new versions of > > LMMS (currently 2.0) disallowing update of the package to new versions. I > > would appreciate any enlightments. > > There appears to be active maintenance of the package going on, it is > not just getting automated rebuilds (I've obfuscated the email address > here): > > * Wed May 01 2019 Thomas Moschny - > 1.1.3-13 > - Use bundled swh ladspa plugins (#1703804). > > * Fri Feb 15 2019 Thomas Moschny - > 1.1.3-12 > - Remove obsolete patch, fix FTBFS (#1675328). > > so I'm gonna guess either 2.0 does indeed have legal issues, or there's > another specific reason not to update to it. (Or 1.2.0 for that > matter). You could try mailing him directly and asking... > -- > Adam Williamson > Fedora QA Community Monkey > IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net > http://www.happyassassin.net > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org > ___ 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: Modularity and the system-upgrade path
On Wed, Oct 16, 2019 at 02:48:13PM -0400, Matthew Miller wrote: > On Wed, Oct 16, 2019 at 08:31:10AM -0400, Stephen Gallagher wrote: > > This is not true. It should be *possible* to have a fully modularized > > distribution, but that isn't a specific goal for Fedora or RHEL. > > Because this keeps coming up, we talked about this at the Fedora Council > meeting today. Our goals for modularity are: > 2. Those alternate streams should be able to have different lifecycles. Hmm, it sounds like the Council hasn't taken into account the constraints on lifecycle of modules that we have slowly discovered during the last two years, constraints that are now part of FESCo-approved policy. Essentially, modules in Fedora are only allowed to EOL at EOL of Fedora release. And to preserve stability for users, a.k.a. following the Update Policy, modules should only change to new major version at Fedora releases. This is exactly the same as for "normal" rpms. The lifecycle of modules in Fedora must be the same as lifecycle of Fedora releases, so no "different lifecycle" is possible. > 1. Users should have alternate streams of software available. > 3. Packaging an individual stream for multiple outputs should be easier > than before. Those *are* useful goals, but they should not be tied to specific technology, we should only care about the end-result. Thus, please replace "Our goals for modularity are" with "What we hope to achieve with modularity" or even "Our goal is for users to be able to". 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
Re: [Mindshare] Re: [Ambassadors] FOSDEM
On Fri, Oct 18, 2019 at 3:37 PM Aleksandra Fedorova wrote: > On Fri, Oct 18, 2019 at 2:37 PM Aniket Pradhan > wrote: > > > > Hello Ankur, Matthew and Brian! > > > > > > > Is there anyone interested in owning this? If so, can you put > together a > > > > > proposal for Mindshare? > > > > > They have a research track this year, so it'll be great to get some > > > NeuroFedora presence there. > > > > I would love to represent Fedora and Neuro-Fedora at FOSDEM this year. > > Although I have no prior experience of "owning" up a booth, so am > > unsure what my responsibilities would be. > > +1 here > > I will be at FOSDEM and I am willing to spend most of my time at the > booth as usual. > But it is going to be hard for me to deal with swag for example, as I > don't see myself carrying the box of t-shirts to Brussels by train. Don’t worry about physically transporting the swag to Brussels. I’ll take care of that. We will most likely do a shard swag object again and sipplemt it with small stuff. Booth ownership involves messaging (important!) and logistics like staffing and hotel rooms (usually coordinated with my help). Regards, bex > > > If you could elaborate a bit > > more about it, I would be happy to submit a proposal for the same on > > Mindshare. If anyone else would be leading, I would be happy to help > > as well. :D > > -- > Aleksandra Fedorova > bookwar > ___ > 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 > -- Brian "bex" Exelbierd (he/him/his) Fedora Community Action & Impact Coordinator @bexelbie | http://www.winglemeyer.org bexel...@redhat.com | b...@pobox.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
Re: Self-Introduction: Christopher Engelhard
On Tue, Oct 01, 2019 at 02:43:03PM +0200, Christopher Engelhard wrote: > Hi all, > since I recently submitted my package for sshguard [1] for review [2], > this is probably a good time to introduce myself (some of you might > remember me from the packaging list). I'm also looking for a sponsor, > assuming the package is positively reviewed. Hi Christopher, welcome to Fedora. sshguard review is more than enough for a first package, quite a complicated beast. I'll sponsor you into the packager group. Zbyszek > I"m Christopher, 35yr old, from Germany originally but living in the > Netherlands. I"m a scientist and write mostly octave & some python code > for data analysis, so I'd consider myself more of a script-wrangler than > a developer, but I follow - and occasionally submit patches to - a > number of other open source projects, including sshguard. > > About the package: > sshguard is a log-monitoring service that blocks brute-force attempts on > common services, similar to fail2ban. It"s not as freely configurable as > the latter, but supports most common services out of the box and > requires little to no configuration. Additionally, it supports pretty > much any blocking backend one might think of. > > Best, > Christopher > > [1] https://www.sshguard.net/ > [2] https://bugzilla.redhat.com/show_bug.cgi?id=1756582 ___ 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: Modularity and the system-upgrade path
On Sun, Oct 20, 2019 at 11:09 AM Zbigniew Jędrzejewski-Szmek wrote: > > On Wed, Oct 16, 2019 at 02:48:13PM -0400, Matthew Miller wrote: > > On Wed, Oct 16, 2019 at 08:31:10AM -0400, Stephen Gallagher wrote: > > > This is not true. It should be *possible* to have a fully modularized > > > distribution, but that isn't a specific goal for Fedora or RHEL. > > > > Because this keeps coming up, we talked about this at the Fedora Council > > meeting today. Our goals for modularity are: > > 2. Those alternate streams should be able to have different lifecycles. > > Hmm, it sounds like the Council hasn't taken into account the constraints > on lifecycle of modules that we have slowly discovered during the last > two years, constraints that are now part of FESCo-approved policy. > > Essentially, modules in Fedora are only allowed to EOL at EOL of Fedora > release. > And to preserve stability for users, a.k.a. following the Update Policy, > modules should only change to new major version at Fedora releases. > This is exactly the same as for "normal" rpms. > > The lifecycle of modules in Fedora must be the same as lifecycle of > Fedora releases, so no "different lifecycle" is possible. Ok, just to be sure that I understand this correctly: - module EOL dates must align with fedora release EOL dates, - Update Policy is the same for modules as for normal packages, - major package updates can only occur at "release upgrade" time If I'm not suffering from too low blood levels of caffeine right now, then from these 3 constraints follows: - default streams are basically useless (since they cannot target multiple fedora releases in most cases, due to the Update Policy), - flexible lifecycle advantages of modules do not apply to fedora, since module EOL dates must align with fedora release EOL dates. Then, what *is* the benefit of using modules for "default" versions of fedora packages, if "default" streams have to usually be maintained separately for different fedora branches, just like normal packages, but with the *additional* overhead of Modularity - and additional work for maintainers of dependent packages? Fabio > > 1. Users should have alternate streams of software available. > > 3. Packaging an individual stream for multiple outputs should be easier > > than before. > > Those *are* useful goals, but they should not be tied to specific technology, > we should only care about the end-result. > > Thus, please replace "Our goals for modularity are" with "What we hope > to achieve with modularity" or even "Our goal is for users to be able to". > > 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 ___ 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: Modularity and the system-upgrade path
On pe, 18 loka 2019, Martin Kolman wrote: On Fri, 2019-10-18 at 11:39 +0300, Alexander Bokovoy wrote: On to, 17 loka 2019, Orion Poplawski wrote: > > > You could install the ipa-client package and enroll a system into IPA from a > > > kickstart in RHEL 7 too.. Without modules. That's what I've deployed for the > > > environments I support, for example. Using a module is not required there. > > > > That wasn't the point, though - the point was the answer the question > > "why do we need *default* module streams?" > > > > The logic is this: FreeIPA maintainers wanted FreeIPA to be a module in > > RHEL, to take advantage of the added flexibility around lifecycles and > > version bumps (basically so each RHEL release isn't tied to one version > > of FreeIPA forever). But if it's modularized and there's no concept of > > 'default stream modules', this is a thing that breaks: you can't > > install it from a kickstart. So, *given that* we wanted to modularize > > FreeIPA in RHEL *and* we also want to still make it deployable via > > kickstart, that creates a requirement for default stream modules or > > something a lot like it. > > This doesn't seem quite true. You couldn't install it with the same kickstart > you used for EL7, but you could use the new module command or syntax in kickstart: > > module --name=NAME [--stream=STREAM] Actually, you could install client packages with the same kickstart file as for RHEL 7, that was one of uses for default profiles. Server package installation from kickstart file is less of a worry because we are running a different deployment process since switching to domain level 1 and that implies you have to do client installation first. And at the time when all this was designed, kickstart had no support for modularized installation. It has it now, of course. Well, module installation vias kickstart has been supported since before 8.0 GA. But I guess the design decisions have taken place before that. Yes, well before that. In any case, one of bigger requirements we had was to keep support for existing kickstart files that install RHEL IdM. Changing them for using modular content for most common use case (installation of IdM client) was seen as a compatibility break. So yes, RHEL 8.x has support for enabling modules in the kickstart files but it was not possible to preserve existing kickstart files that used ipa-client package without enabling default module stream after RHEL IdM was moved to module. -- / Alexander Bokovoy Sr. Principal Software Engineer Security / Identity Management Engineering Red Hat Limited, Finland ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: how to list all module repos in Fedora?
On Fri, Oct 11, 2019 at 01:48:13PM -0400, Alexander Scheel wrote: > If you go to any modular repo: > https://src.fedoraproject.org/modules/eclipse > > And click on "modules" in the path at the top, it takes you to: > > https://src.fedoraproject.org/projects/modules/%2A > > Which lists them all. Great, thanks! 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
Orphaned some leaf Java packages
Hello packagers, I have identified that the Stewardship SIG owned some packages that have now become leaf packages in fedora, since their last dependent packages were recently removed or updated to no longer require them. Because there's no point in maintaining leaf packages that aren't useful on their own, we have orphaned these packages: - extra166y - felix-osgi-foundation - jcsp - multiverse - plexus-cli I did some repoqueries and see no reason why they shouldn't get safely retired after 6 weeks. Fabio ___ 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: Modularity and the system-upgrade path
On Sun, Oct 20, 2019 at 11:35:37AM +0200, Fabio Valentini wrote: > On Sun, Oct 20, 2019 at 11:09 AM Zbigniew Jędrzejewski-Szmek > wrote: > > > > On Wed, Oct 16, 2019 at 02:48:13PM -0400, Matthew Miller wrote: > > > On Wed, Oct 16, 2019 at 08:31:10AM -0400, Stephen Gallagher wrote: > > > > This is not true. It should be *possible* to have a fully modularized > > > > distribution, but that isn't a specific goal for Fedora or RHEL. > > > > > > Because this keeps coming up, we talked about this at the Fedora Council > > > meeting today. Our goals for modularity are: > > > 2. Those alternate streams should be able to have different lifecycles. > > > > Hmm, it sounds like the Council hasn't taken into account the constraints > > on lifecycle of modules that we have slowly discovered during the last > > two years, constraints that are now part of FESCo-approved policy. > > > > Essentially, modules in Fedora are only allowed to EOL at EOL of Fedora > > release. > > And to preserve stability for users, a.k.a. following the Update Policy, > > modules should only change to new major version at Fedora releases. > > This is exactly the same as for "normal" rpms. > > > > The lifecycle of modules in Fedora must be the same as lifecycle of > > Fedora releases, so no "different lifecycle" is possible. > > Ok, just to be sure that I understand this correctly: > > - module EOL dates must align with fedora release EOL dates, Yes, this was voted in https://pagure.io/modularity/issue/112#comment-553234 > Allow maintainers to specify that a module stream will live until > the EOL date of a particular Fedora release or EPEL minor release, > with special cases for "just keep building until I say otherwise"? and approved in https://pagure.io/modularity/issue/112#comment-562677. (I'm providing exact links because it's hard to find.) > - Update Policy is the same for modules as for normal packages, > - major package updates can only occur at "release upgrade" time I'm not sure if that is specified in plain text anywhere. The last image in https://pagure.io/modularity/working-documents/blob/master/f/lifecycles-upgrades-ownership/lifecycles-general.md shows that at least. But the gist of https://docs.fedoraproject.org/en-US/fesco/Updates_Policy/#philosophy applies to modules too: if there's a module that has been released for some Fedora version, a major user-visible change would be just a disruptive for users as a major user-visible change in any packages. This certainly applies to streams like "/stable" and "/version-nnn". Maybe somebody from the Modularity team can provide clarification here and links to policy. > If I'm not suffering from too low blood levels of caffeine right now, > then from these 3 constraints follows: > > - default streams are basically useless (since they cannot target > multiple fedora releases in most cases, due to the Update Policy), In general, yes. If the package versions have incompatibilities and/or user-visible changes, a different stream is needed for each Fedora release. There was a subthread about this recently, starting at https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/C5EX4WI7Z4HZZLVTUIHSMMPPUGTFENYE/. > - flexible lifecycle advantages of modules do not apply to fedora, > since module EOL dates must align with fedora release EOL dates. > > Then, what *is* the benefit of using modules for "default" versions of > fedora packages, if "default" streams have to usually be maintained > separately for different fedora branches, just like normal packages, > but with the *additional* overhead of Modularity - and additional work > for maintainers of dependent packages? That is one of questions we are trying to answer in this thread ;) 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
Re: Modularity and the system-upgrade path
On Sun, Oct 20, 2019 at 10:47:15AM +, Zbigniew Jędrzejewski-Szmek wrote: > On Sun, Oct 20, 2019 at 11:35:37AM +0200, Fabio Valentini wrote: > > On Sun, Oct 20, 2019 at 11:09 AM Zbigniew Jędrzejewski-Szmek > > wrote: > > > > > > On Wed, Oct 16, 2019 at 02:48:13PM -0400, Matthew Miller wrote: > > > > On Wed, Oct 16, 2019 at 08:31:10AM -0400, Stephen Gallagher wrote: > > > > > This is not true. It should be *possible* to have a fully modularized > > > > > distribution, but that isn't a specific goal for Fedora or RHEL. > > > > > > > > Because this keeps coming up, we talked about this at the Fedora Council > > > > meeting today. Our goals for modularity are: > > > > 2. Those alternate streams should be able to have different > > > > lifecycles. > > > > > > Hmm, it sounds like the Council hasn't taken into account the constraints > > > on lifecycle of modules that we have slowly discovered during the last > > > two years, constraints that are now part of FESCo-approved policy. > > > > > > Essentially, modules in Fedora are only allowed to EOL at EOL of Fedora > > > release. > > > And to preserve stability for users, a.k.a. following the Update Policy, > > > modules should only change to new major version at Fedora releases. > > > This is exactly the same as for "normal" rpms. > > > > > > The lifecycle of modules in Fedora must be the same as lifecycle of > > > Fedora releases, so no "different lifecycle" is possible. > > > > Ok, just to be sure that I understand this correctly: > > > > - module EOL dates must align with fedora release EOL dates, > > Yes, this was voted in https://pagure.io/modularity/issue/112#comment-553234 > > Allow maintainers to specify that a module stream will live until > > the EOL date of a particular Fedora release or EPEL minor release, > > with special cases for "just keep building until I say otherwise"? > and approved in https://pagure.io/modularity/issue/112#comment-562677. > (I'm providing exact links because it's hard to find.) > > > - Update Policy is the same for modules as for normal packages, > > - major package updates can only occur at "release upgrade" time > > I'm not sure if that is specified in plain text anywhere. > The last image in > https://pagure.io/modularity/working-documents/blob/master/f/lifecycles-upgrades-ownership/lifecycles-general.md > shows that at least. > > But the gist of > https://docs.fedoraproject.org/en-US/fesco/Updates_Policy/#philosophy > applies to modules too: if there's a module that has been released for > some Fedora version, a major user-visible change would be just a disruptive > for users as a major user-visible change in any packages. This certainly > applies to streams like "/stable" and "/version-nnn". > > Maybe somebody from the Modularity team can provide clarification here > and links to policy. > > > If I'm not suffering from too low blood levels of caffeine right now, > > then from these 3 constraints follows: > > > > - default streams are basically useless (since they cannot target > > multiple fedora releases in most cases, due to the Update Policy), > > In general, yes. If the package versions have incompatibilities and/or > user-visible changes, a different stream is needed for each Fedora > release. There was a subthread about this recently, starting at > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/C5EX4WI7Z4HZZLVTUIHSMMPPUGTFENYE/. Wait, did I just reply to you quoting your earlier mail? Oops, I did. Smooge is right, this thread has started looping. Zbyszek > > - flexible lifecycle advantages of modules do not apply to fedora, > > since module EOL dates must align with fedora release EOL dates. > > > > Then, what *is* the benefit of using modules for "default" versions of > > fedora packages, if "default" streams have to usually be maintained > > separately for different fedora branches, just like normal packages, > > but with the *additional* overhead of Modularity - and additional work > > for maintainers of dependent packages? > > That is one of questions we are trying to answer in this thread ;) ___ 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: Stepping away from packaging (and request for owners)
Am 19.10.19 um 19:38 schrieb Jamie Nguyen: jasmine: 1 I'll check if I can take jasmine (this is quite a bit behind so I want to know if the latest version needs new dependencies or so). Felix ___ 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
vcglib Review too old
Hi, When i try $ fedpkg request-repo vcglib 1677989 Could not execute request_repo: The Bugzilla bug's review was approved over 60 days ago What to do ? so long MUFTI ___ 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: vcglib Review too old
Am 20.10.19 um 14:21 schrieb J. Scheurich: $ fedpkg request-repo vcglib 1677989 Could not execute request_repo: The Bugzilla bug's review was approved over 60 days ago What to do ? A need a "new" review. This can be pretty simple if the original reviewer just resets the "fedora-review" flag and sets it again (assuming there is no new policy which requires changes to the spec file). Felix ___ 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: vcglib Review too old
$ fedpkg request-repo vcglib 1677989 Could not execute request_repo: The Bugzilla bug's review was approved over 60 days ago What to do ? A need a "new" review. This can be pretty simple if the original reviewer just resets the "fedora-review" flag and sets it again (assuming there is no new policy which requires changes to the spec file). There are no changes in the spec file. so long MUFTI ___ 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
Rust review swaps
Hello, I'd like some help to review a handful of Rust packages: 1763459[1] _Review Request: rust-multipart - Backend-agnostic extension for HTTP libraries_ 1763457[2] _Review Request: rust-nickel - Express _ 1763448[3] _Review Request: rust-mustache - Rust implementation of Mustache _ 1763447[4] _Review Request: rust-groupable - Easily aggregate groups of values from key-value Iterators _ 1763436[5] _Review Request: rust-tiny_http - Low level HTTP server library _ 1763433[6] _Review Request: rust-chunked_transfer - Encoder and decoder for HTTP chunked transfer coding (RFC 7230 § 4 _ 1763431[7] _Review Request: rust-iron - Extensible, Concurrency Focused Web Development in Rust _ 1763430[8] _Review Request: rust-buf_redux - Drop-in replacements for buffered I/O in `std::io` with extra features _ 1763428[9] _Review Request: rust-slice-deque - Double-ended queue that Deref's into a slice _ 1763419[10] _Review Request: rust-strip-ansi-escapes - Strip ANSI escape sequences from byte streams _ 1763332[11] _Review Request: rust-actix-testing - Actix testing utils _ They are standard Rust packages and have all been built in COPR https://copr.fedorainfracloud.org/coprs/eclipseo/rusttests/builds/ I suggest grabbing the RPM/SRPM directly from COPR and use "fedora-review -p" to avoid rebuilding them (tricky dependencies ahead). Or add the COPR to your mock.cfg. I'm available for any reviews in exchange. Best regard, Robert-André [1] https://bugzilla.redhat.com/show_bug.cgi?id=1763459 [2] https://bugzilla.redhat.com/show_bug.cgi?id=1763457 [3] https://bugzilla.redhat.com/show_bug.cgi?id=1763448 [4] https://bugzilla.redhat.com/show_bug.cgi?id=1763447 [5] https://bugzilla.redhat.com/show_bug.cgi?id=1763436 [6] https://bugzilla.redhat.com/show_bug.cgi?id=1763433 [7] https://bugzilla.redhat.com/show_bug.cgi?id=1763431 [8] https://bugzilla.redhat.com/show_bug.cgi?id=1763430 [9] https://bugzilla.redhat.com/show_bug.cgi?id=1763428 [10] https://bugzilla.redhat.com/show_bug.cgi?id=1763419 [11] https://bugzilla.redhat.com/show_bug.cgi?id=1763332 ___ 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
Updates to the FTBFS policy
Hello, after the recent discussions, the Fedora's "Fails to Build From Source" policy [0] has been updated [1][2]. The changes include: ## The policy no longer requires e-mails to devel to orphan a package This requirement made automation hard and resulted in most of the packages never being orphaned because almost nobody did this. The public e-mail about a certain package failing to build may have been seen as public shaming by some. ## Packages with NEW bugs will be orphaned after 8 weeks Orphaning packages where the maintainers don't respond at all makes sure that all the dependent package maintainers are properly notified about the problem long before the package is retired. ## Not orphaned packages are only retired after they FTBFS for 13+ months A week before Fedora N branching, packages that haven't built successfully at least on Fedora N-2 will be retired regardless of their FTBFS bug status. This allows the maintainers to postpone the package retirement, but not indefinitely. It also enforces that even if the bugs are closed by mistake, we don't miss any packages. The policy only allows the retirements to happen when there are several announcements about this on the devel list, with the list of packages. This makes sure nothing happens unexpectedly. I hope the changes will help assure Fedora packages stay in an generally healthy state without (especially occasional) Fedora contributors feeling intimidated by the rules. In any case, if you feel you need help when your package fails to build, please don't hesitate to use the devel mailing list to reach out, as does the document describing Fedora packager responsibilities [3] suggests. Thanks to everybody who was involved in this effort. [0] https://docs.fedoraproject.org/en-US/fesco/Fails_to_build_from_source_Fails_to_install/ [1] https://pagure.io/fesco/issue/2244 [2] https://pagure.io/fesco/fesco-docs/pull-request/18 [3] https://docs.fedoraproject.org/en-US/fesco/Package_maintainer_responsibilities/ -- 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: [Mindshare] Re: [Ambassadors] FOSDEM
I'll happy to help with that. Where do I start? On Sun, Oct 20, 2019, 11:32 Brian (bex) Exelbierd wrote: > > > On Fri, Oct 18, 2019 at 3:37 PM Aleksandra Fedorova > wrote: > >> On Fri, Oct 18, 2019 at 2:37 PM Aniket Pradhan >> wrote: >> > >> > Hello Ankur, Matthew and Brian! >> > >> > > > > Is there anyone interested in owning this? If so, can you put >> together a >> > > > > proposal for Mindshare? >> > >> > > They have a research track this year, so it'll be great to get some >> > > NeuroFedora presence there. >> > >> > I would love to represent Fedora and Neuro-Fedora at FOSDEM this year. >> > Although I have no prior experience of "owning" up a booth, so am >> > unsure what my responsibilities would be. >> >> +1 here >> >> I will be at FOSDEM and I am willing to spend most of my time at the >> booth as usual. >> But it is going to be hard for me to deal with swag for example, as I >> don't see myself carrying the box of t-shirts to Brussels by train. > > > Don’t worry about physically transporting the swag to Brussels. I’ll take > care of that. We will most likely do a shard swag object again and sipplemt > it with small stuff. > > Booth ownership involves messaging (important!) and logistics like > staffing and hotel rooms (usually coordinated with my help). > > Regards, > > bex > > > >> >> > If you could elaborate a bit >> > more about it, I would be happy to submit a proposal for the same on >> > Mindshare. If anyone else would be leading, I would be happy to help >> > as well. :D >> >> -- >> Aleksandra Fedorova >> bookwar >> ___ >> 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 >> > -- > Brian "bex" Exelbierd (he/him/his) > Fedora Community Action & Impact Coordinator > @bexelbie | http://www.winglemeyer.org > bexel...@redhat.com | b...@pobox.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
Unresponsive maintainer: smooge Fwd: [Bug 1451148] libmaxminddb-1.3.2 is available
So I am declaring myself an unresponsive maintainer on the libmaxminddb and would like someone else to take this package. libmaxminddb is part of the replacement of the GeopIP packages to work with their new database. I took the package because it was orphaned and at the time I figured I could pick this up. I have not been able to and I am not sure I could make updates to 1.32 in anything other than rawhide now. If anyone knows this package and would like to take it over.. please contact me and I will add you to the list. If not I plan to orphan the package after F31 is released. -- Forwarded message - From: Date: Sat, 25 May 2019 at 02:01 Subject: [Bug 1451148] libmaxminddb-1.3.2 is available To: https://bugzilla.redhat.com/show_bug.cgi?id=1451148 Peter Borsa changed: What|Removed |Added CC||peter.bo...@gmail.com --- Comment #4 from Peter Borsa --- Any update? -- You are receiving this mail because: You are the assignee for the bug. -- 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: [Mindshare] Re: [Ambassadors] FOSDEM
> I'll happy to help with that. Where do I start? +1 I would be a newbie at this, so maybe I could help as a co-booth-owner or something (don't know the actual designation :P). -- Thanks Regards Aniket Pradhan http://home.iiitd.edu.in/~aniket17133/ Aliases: MeWjOr/major () ascii ribbon campaign - against html e-mail /\ www.asciiribbon.org - against proprietary attachments ___ 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: Unresponsive maintainer: smooge Fwd: [Bug 1451148] libmaxminddb-1.3.2 is available
Feel free to assign it to me and I'll try to make an update to it as soon as possible. On Sun, Oct 20, 2019, 16:47 Stephen John Smoogen wrote: > So I am declaring myself an unresponsive maintainer on the > libmaxminddb and would like someone else to take this package. > > libmaxminddb is part of the replacement of the GeopIP packages to work > with their new database. I took the package because it was orphaned > and at the time I figured I could pick this up. > > I have not been able to and I am not sure I could make updates to 1.32 > in anything other than rawhide now. If anyone knows this package and > would like to take it over.. please contact me and I will add you to > the list. If not I plan to orphan the package after F31 is released. > > -- Forwarded message - > From: > Date: Sat, 25 May 2019 at 02:01 > Subject: [Bug 1451148] libmaxminddb-1.3.2 is available > To: > > > https://bugzilla.redhat.com/show_bug.cgi?id=1451148 > > Peter Borsa changed: > >What|Removed |Added > > > CC||peter.bo...@gmail.com > > > > --- Comment #4 from Peter Borsa --- > Any update? > > -- > You are receiving this mail because: > You are the assignee for the bug. > > > -- > 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 > ___ 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: Stepping away from packaging (and request for owners)
Hi! I'll take python-sleekxmpp. FAS: limb. Thank you! -- Gwyn Ciesla she/her/hers in your fear, seek only peace in your fear, seek only love -d. bowie Sent with ProtonMail Secure Email. ‐‐‐ Original Message ‐‐‐ On Saturday, October 19, 2019 12:38 PM, Jamie Nguyen wrote: > Hi all, > > It's been incredible to part of this project and community! :-) > > Once upon a time I was an (over?)enthusiastic packager and it's left me > with ownership of 300+ packages. O_o > > In the last couple years I haven't been able to dedicate enough time to > Fedora, and I've just about kept my most important packages ticking along. > > I keep thinking I'll eventually get around to everything, but I should > probably stop kidding myself! So it's time to step down and let other > people do a better job than I'm doing :-) > > (Of course, I still plan to use Fedora for my servers and laptops > indefinitely!) > > Unfortunately, I have an insane number of NodeJS packages (sorry!), but > here's me trying to step down in a helpful manner: > > 1. nginx, tor and torsocks have active co-maintainers who've been doing > a great job. Massive thanks to Felix (heffer) and Marcel (maha) in > particular! I've emailed them to see if they want ownership. > > 2. I have 5 packages that need owners. Volunteers welcome. [a] > 3. I've removed my admin & commit access from 10 packages. These are > owned by someone else, but some may be in need of co-maintainers. [b] > > 4. I've removed my admin & commit access from 30 NodeJS packages. Most > are already owned by tomh so are in brilliant hands. [c] > > 5. I have 148 NodeJS packages that are listed as runtime dependencies by > other packages (in rawhide). These need owners and love. [d] > > 6. I have 7 NodeJS packages that are listed as BuildRequires by other > packages (in rawhide) but aren't runtime dependencies. These need > owners. [e] > > 7. I have 75 NodeJS packages that are not listed as dependencies (in > rawhide) by any other package. These may need owners. [f] > > 8. I've sent emails to co-maintainers for 51 packages asking if they > want ownership. [g] > > 9. There are 39 other packages that I need to ask someone to remove my > commit access from (where I'm not admin so can't remove myself). > Hopefully that's scriptable by a Proven Packager? > > After a few weeks, if there are any packages I own where nobody has > volunteered to take ownership, I'll orphan them. > > === > [a]: Need owner > === > > bashmount > CutyCapt > dateformat > ledger > utf8cpp > > == > [b]: Remove my admin/commit access > == > > adobe-source-code-pro-fonts > libmpdclient > libuv > mpc > ncmpc > newsbeuter > notmuch > python-sleekxmpp > rubygem-highline > weechat > > === > [c]: Removed my admin/commit access > === > > js-jquery > js-jquery1 > js-sizzle > nodejs > nodejs-assertion-error > nodejs-chai > nodejs-chai-connect-middleware > nodejs-chai-passport-strategy > nodejs-closure-compiler > nodejs-deep-eql > nodejs-difflet > nodejs-inherits > nodejs-mapnik > nodejs-mapnik-vector-tile > nodejs-less > nodejs-packaging > nodejs-passport-oauth1 > nodejs-passport-oauth2 > nodejs-passport-strategy > nodejs-proxyquire > nodejs-set-immediate > nodejs-simple-assert > nodejs-speedometer > nodejs-tap > nodejs-tilelive-mapnik > nodejs-tiletype > nodejs-type-detect > nodejs-uid2 > nodejs-utils-merge > nodejs-xmlbuilder > > === > [d]: Need owner, listed as Requires > === > > jasmine: 1 > js-zlib: 1 > marked: 1 > mocha: 4 > nodejs-abbrev: 1 > nodejs-ansi: 3 > nodejs-ansi-styles: 1 > nodejs-asap: 2 > nodejs-asn1: 1 > nodejs-assert-plus: 1 > nodejs-async: 11 > nodejs-batch: 1 > nodejs-better-assert: 3 > nodejs-bindings: 8 > nodejs-block-stream: 1 > nodejs-boom: 2 > nodejs-buffer-crc32: 1 > nodejs-buffer-equal: 1 > nodejs-bunker: 1 > nodejs-burrito: 1 > nodejs-bytes: 2 > nodejs-callsite: 3 > nodejs-chalk: 14 > nodejs-character-parser: 1 > nodejs-charm: 1 > nodejs-cmd-shim: 1 > nodejs-collections: 1 > nodejs-combined-stream: 2 > nodejs-commander: 7 > nodejs-component-emitter: 7 > nodejs-constantinople: 1 > nodejs-cookie: 2 > nodejs-cookiejar: 1 > nodejs-cookie-signature: 3 > nodejs-cryptiles: 1 > nodejs-css: 1 > nodejs-css-pars
Re: Stepping away from packaging (and request for owners)
Ignore, I see that it's retired. -- Gwyn Ciesla she/her/hers in your fear, seek only peace in your fear, seek only love -d. bowie Sent with ProtonMail Secure Email. ‐‐‐ Original Message ‐‐‐ On Sunday, October 20, 2019 10:03 AM, Gwyn Ciesla wrote: > Hi! I'll take python-sleekxmpp. FAS: limb. Thank you! > > -- > Gwyn Ciesla > she/her/hers > > in your fear, seek only peace > in your fear, seek only love > -d. bowie > > Sent with ProtonMail Secure Email. > > ‐‐‐ Original Message ‐‐‐ > On Saturday, October 19, 2019 12:38 PM, Jamie Nguyen j...@jamielinux.com > wrote: > > > Hi all, > > It's been incredible to part of this project and community! :-) > > Once upon a time I was an (over?)enthusiastic packager and it's left me > > with ownership of 300+ packages. O_o > > In the last couple years I haven't been able to dedicate enough time to > > Fedora, and I've just about kept my most important packages ticking along. > > I keep thinking I'll eventually get around to everything, but I should > > probably stop kidding myself! So it's time to step down and let other > > people do a better job than I'm doing :-) > > (Of course, I still plan to use Fedora for my servers and laptops > > indefinitely!) > > Unfortunately, I have an insane number of NodeJS packages (sorry!), but > > here's me trying to step down in a helpful manner: > > > > 1. nginx, tor and torsocks have active co-maintainers who've been doing > > a great job. Massive thanks to Felix (heffer) and Marcel (maha) in > > particular! I've emailed them to see if they want ownership. > > > > 2. I have 5 packages that need owners. Volunteers welcome. [a] > > > > 3. I've removed my admin & commit access from 10 packages. These are > > owned by someone else, but some may be in need of co-maintainers. [b] > > > > 4. I've removed my admin & commit access from 30 NodeJS packages. Most > > are already owned by tomh so are in brilliant hands. [c] > > > > 5. I have 148 NodeJS packages that are listed as runtime dependencies by > > other packages (in rawhide). These need owners and love. [d] > > > > 6. I have 7 NodeJS packages that are listed as BuildRequires by other > > packages (in rawhide) but aren't runtime dependencies. These need > > owners. [e] > > > > 7. I have 75 NodeJS packages that are not listed as dependencies (in > > rawhide) by any other package. These may need owners. [f] > > > > 8. I've sent emails to co-maintainers for 51 packages asking if they > > want ownership. [g] > > > > 9. There are 39 other packages that I need to ask someone to remove my > > commit access from (where I'm not admin so can't remove myself). > > Hopefully that's scriptable by a Proven Packager? > > After a few weeks, if there are any packages I own where nobody has > > volunteered to take ownership, I'll orphan them. > > > > === > > [a]: Need owner > > > > > > > > bashmount > > CutyCapt > > dateformat > > ledger > > utf8cpp > > > > == > > [b]: Remove my admin/commit access > > > > == > > > > adobe-source-code-pro-fonts > > libmpdclient > > libuv > > mpc > > ncmpc > > newsbeuter > > notmuch > > python-sleekxmpp > > rubygem-highline > > weechat > > > > === > > [c]: Removed my admin/commit access > > > > > > > > js-jquery > > js-jquery1 > > js-sizzle > > nodejs > > nodejs-assertion-error > > nodejs-chai > > nodejs-chai-connect-middleware > > nodejs-chai-passport-strategy > > nodejs-closure-compiler > > nodejs-deep-eql > > nodejs-difflet > > nodejs-inherits > > nodejs-mapnik > > nodejs-mapnik-vector-tile > > nodejs-less > > nodejs-packaging > > nodejs-passport-oauth1 > > nodejs-passport-oauth2 > > nodejs-passport-strategy > > nodejs-proxyquire > > nodejs-set-immediate > > nodejs-simple-assert > > nodejs-speedometer > > nodejs-tap > > nodejs-tilelive-mapnik > > nodejs-tiletype > > nodejs-type-detect > > nodejs-uid2 > > nodejs-utils-merge > > nodejs-xmlbuilder > > > > === > > [d]: Need owner, listed as Requires > > > > > > > > jasmine: 1 > > js-zlib: 1 > > marked: 1 > > mocha: 4 > > nodejs-abbrev: 1 > > nodejs-ansi: 3 > > nodejs-ansi-styles: 1 > > nodejs-asap: 2 > > no
Re: Modularity and the system-upgrade path
On 15. 10. 19 19:25, Miro Hrončok wrote: On 15. 10. 19 19:13, Kevin Fenzi wrote: So, I see the following modules (in rawhide anyhow) that don't seem to have non modular versions: avocado cri-o django dwm eclipse gimp jmc lizardfs mysql ninja perl-bootstrap stratis Do all of those have default streams? I don't know all but I think that at least gimp, django, mysql have nonmodular "dafault" versions. In case of gimp, it has both nonmodular version and a default modular stream. perl-bootstrap is probably needed only to bootstrap Perl. Eclipse has a nonmodular version that fails to install because other stuff has default streams. Yes, some of the modules would need to be "converted back". Better to do it when we can still count them on our fingers. +1 -- Petr Stodulka Core Services (In-place upgrades and migrations) Red Hat ___ 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: Unresponsive maintainer: smooge Fwd: [Bug 1451148] libmaxminddb-1.3.2 is available
I am interested in this package as well, I can help maintain it (fas: jtaylor) Thanks! JT On Sun, Oct 20, 2019, 10:57 Igor Gnatenko wrote: > Feel free to assign it to me and I'll try to make an update to it as > soon as possible. > > On Sun, Oct 20, 2019, 16:47 Stephen John Smoogen wrote: > >> So I am declaring myself an unresponsive maintainer on the >> libmaxminddb and would like someone else to take this package. >> >> libmaxminddb is part of the replacement of the GeopIP packages to work >> with their new database. I took the package because it was orphaned >> and at the time I figured I could pick this up. >> >> I have not been able to and I am not sure I could make updates to 1.32 >> in anything other than rawhide now. If anyone knows this package and >> would like to take it over.. please contact me and I will add you to >> the list. If not I plan to orphan the package after F31 is released. >> >> -- Forwarded message - >> From: >> Date: Sat, 25 May 2019 at 02:01 >> Subject: [Bug 1451148] libmaxminddb-1.3.2 is available >> To: >> >> >> https://bugzilla.redhat.com/show_bug.cgi?id=1451148 >> >> Peter Borsa changed: >> >>What|Removed |Added >> >> >> CC||peter.bo...@gmail.com >> >> >> >> --- Comment #4 from Peter Borsa --- >> Any update? >> >> -- >> You are receiving this mail because: >> You are the assignee for the bug. >> >> >> -- >> 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 >> > ___ > 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: vcglib Review too old
On Sun, Oct 20, 2019 at 03:37:57PM +0200, J. Scheurich wrote: > > >>$ fedpkg request-repo vcglib 1677989 > >>Could not execute request_repo: The Bugzilla bug's review was approved > >>over 60 days ago > >> > >>What to do ? > > > >A need a "new" review. This can be pretty simple if the original > >reviewer just resets the "fedora-review" flag and sets it again > >(assuming there is no new policy which requires changes to the spec > >file). > > > There are no changes in the spec file. You have to unset the fedora-review+ flag, and ask for a re-review. 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
Re: Fedora 32 System-Wide Change proposal: Modules in Non-Modular Buildroot
On Fri, Oct 18, 2019 at 02:00:11PM -0700, Adam Williamson wrote: > On Fri, 2019-10-18 at 16:25 -0400, Robbie Harwood wrote: > > Christopher Engelhard writes: > > > > > On 18.10.19 17:21, Robbie Harwood wrote: > > > > > > > While you're right that the solutions from source distros (i.e., NixOS > > > > and Gentoo) would be very hard to adapt, binary distros have also solved > > > > this problem in different ways. I'm most familiar with Debian's > > > > solution (virtual packages[2], provides:, and alternatives [1]) which > > > > to my mind maps much more clearly onto Fedora's setup. Obviously we > > > > can't use their code wholesale without migrating to APT, but as you say, > > > > the goal is to derive inspiration. > > > > > > > > 1: https://wiki.debian.org/DebianAlternatives > > > > 2: > > > > https://www.debian.org/doc/debian-policy/ch-relationships.html#s-virtual > > > > > > I'm not a Fedora packager (yet[1]), so correct me if I'm > > > misunderstanding things completely, but is there any reason not to > > > adapt the existing RPM provides: functionality for this? > > > > I'm not aware of technical reasons not to do this - as Neal elaborated > > on, this is already possible. > > I don't think there is one. But it's not a perfect solution either. > Modularity is intended to do that - to provide a framework and some > technical backing for treating alternate groups of packages that > provide different implementations of the same thing *as* groups, > essentially. > > I mean, it's not like the Modularity team wasn't aware of these other > approaches, I'm pretty sure they were discussed. It might be reasonable > to go back and check the various docs and blog posts and things the > modularity team put out before just suggesting 'hey what about this > other thing', especially where 'this other thing' is something you > could reasonably imagine at least one of them would probably have heard > or thought of... Well, you might think that, but it's not clear that this was the case. Let's not assume one way or the other. > I mean, we're talking about *stacks* here, remember. FreeIPA isn't one > package - you can't just have 'freeipa4' and 'freeipa5' both providing > 'freeipa' and call it a day. There's a whole ton of stuff that goes in > there. 'freeipa5' might need different version of ten different other > components compared to 'freeipa4'. > > So, you're no longer looking at one pair of packages with the same > 'provides', you're looking at a dozen, and someone needs to be keeping > track of which ones go together and what they're all for in the first > place. But with this approach you're not building any infrastructure > for *doing* that. I would really like this explained. Taking this particular example, to let dnf install all dependencies properly, freeipa5 must already list *all* dependencies through rpm Requires/Conflicts/Recommends/Suggests, including versions. Likewise, freeipa4 must also do that. It doesn't matter if the rpms are built normally or in a module, listing all deps is needed in both cases. If the rpm doesn't work with all versions of dependencies, it might be fine during initial installation, where you get everything latest by default, but will break if the user does a partial upgrade. This means that in one case the user says 'dnf install freeipa5' and they get the full stack, and in the other case they say 'dnf install freeipa4' and they get a different (partially overlapping) set of recursive deps. > These things are clearly a conceptual lump, but > you're not really providing a way to express or work with that. Why not? What is wrong with having rpm Requires? 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
Fedora 31 compose report: 20191020.n.0 changes
OLD: Fedora-31-20191019.n.0 NEW: Fedora-31-20191020.n.0 = SUMMARY = Added images:1 Dropped images: 1 Added packages: 0 Dropped packages:0 Upgraded packages: 0 Downgraded packages: 0 Size of added packages: 0 B Size of dropped packages:0 B Size of upgraded packages: 0 B Size of downgraded packages: 0 B Size change of upgraded packages: 0 B Size change of downgraded packages: 0 B = ADDED IMAGES = Image: Workstation raw-xz armhfp Path: Workstation/armhfp/images/Fedora-Workstation-armhfp-31-20191020.n.0-sda.raw.xz = DROPPED IMAGES = Image: Python_Classroom raw-xz armhfp Path: Labs/armhfp/images/Fedora-Python-Classroom-armhfp-31-20191019.n.0-sda.raw.xz = ADDED PACKAGES = = DROPPED PACKAGES = = UPGRADED PACKAGES = = DOWNGRADED PACKAGES = ___ 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-31-20191020.n.0 compose check report
No missing expected images. Failed openQA tests: 5/153 (x86_64), 1/2 (arm) New failures (same test not failed in Fedora-31-20191019.n.0): ID: 472947 Test: x86_64 KDE-live-iso install_no_user URL: https://openqa.fedoraproject.org/tests/472947 ID: 472956 Test: x86_64 KDE-live-iso apps_startstop URL: https://openqa.fedoraproject.org/tests/472956 ID: 473026 Test: x86_64 universal support_server URL: https://openqa.fedoraproject.org/tests/473026 ID: 473032 Test: x86_64 universal install_iscsi URL: https://openqa.fedoraproject.org/tests/473032 Old failures (same test failed in Fedora-31-20191019.n.0): ID: 472898 Test: x86_64 Server-dvd-iso modularity_tests URL: https://openqa.fedoraproject.org/tests/472898 ID: 472960 Test: arm Minimal-raw_xz-raw.xz install_arm_image_deployment_upload URL: https://openqa.fedoraproject.org/tests/472960 Soft failed openQA tests: 2/153 (x86_64) (Tests completed, but using a workaround for a known bug) Old soft failures (same test soft failed in Fedora-31-20191019.n.0): ID: 472937 Test: x86_64 Workstation-live-iso desktop_update_graphical URL: https://openqa.fedoraproject.org/tests/472937 ID: 473016 Test: x86_64 universal install_asian_language URL: https://openqa.fedoraproject.org/tests/473016 Passed openQA tests: 146/153 (x86_64) New passes (same test not passed in Fedora-31-20191019.n.0): ID: 472939 Test: x86_64 Workstation-live-iso desktop_browser URL: https://openqa.fedoraproject.org/tests/472939 ID: 472952 Test: x86_64 KDE-live-iso desktop_update_graphical URL: https://openqa.fedoraproject.org/tests/472952 ID: 472970 Test: x86_64 Silverblue-dvd_ostree-iso desktop_browser URL: https://openqa.fedoraproject.org/tests/472970 Skipped non-gating openQA tests: 1 of 155 Installed system changes in test x86_64 Workstation-live-iso install_default_upload: System load changed from 0.42 to 0.60 Previous test data: https://openqa.fedoraproject.org/tests/472447#downloads Current test data: https://openqa.fedoraproject.org/tests/472929#downloads Installed system changes in test x86_64 Workstation-live-iso install_default@uefi: Used mem changed from 984 MiB to 867 MiB Previous test data: https://openqa.fedoraproject.org/tests/472449#downloads Current test data: https://openqa.fedoraproject.org/tests/472931#downloads Installed system changes in test x86_64 KDE-live-iso install_default_upload: Used mem changed from 736 MiB to 855 MiB System load changed from 2.62 to 1.69 Average CPU usage changed from 1.50476190 to 27.1 Previous test data: https://openqa.fedoraproject.org/tests/472462#downloads Current test data: https://openqa.fedoraproject.org/tests/472944#downloads Installed system changes in test x86_64 KDE-live-iso install_default@uefi: 1 services(s) added since previous compose: pcscd.service System load changed from 2.54 to 1.84 Previous test data: https://openqa.fedoraproject.org/tests/472464#downloads Current test data: https://openqa.fedoraproject.org/tests/472946#downloads Installed system changes in test x86_64 Silverblue-dvd_ostree-iso install_default_upload: Used mem changed from 733 MiB to 834 MiB Used Swap grew from 0 to 6 MiB System load changed from 0.26 to 0.48 Previous test data: https://openqa.fedoraproject.org/tests/472480#downloads Current test data: https://openqa.fedoraproject.org/tests/472962#downloads Installed system changes in test x86_64 Silverblue-dvd_ostree-iso install_default@uefi: Used swap changed from 4 MiB to 5 MiB System load changed from 0.38 to 0.20 Previous test data: https://openqa.fedoraproject.org/tests/472482#downloads Current test data: https://openqa.fedoraproject.org/tests/472964#downloads Installed system changes in test x86_64 universal install_package_set_kde: Used mem changed from 886 MiB to 790 MiB System load changed from 0.67 to 1.09 Average CPU usage changed from 23.30476190 to 73.75714286 Previous test data: https://openqa.fedoraproject.org/tests/472555#downloads Current test data: https://openqa.fedoraproject.org/tests/473037#downloads -- 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
Summary/Minutes from FESCo Meeting (2019-10-14)
We didn't have quorum, so we didn't vote anything. Meeting summary init process (zbyszek, 15:00:12) Meeting is cancelled because of lack of quorum. (zbyszek, 15:05:40) Next week's chair (zbyszek, 15:05:42) ACTION: zbyszek will chair next meeting (zbyszek, 15:05:52) Reminder: please vote in open tickets. (zbyszek, 15:06:00) Open Floor (zbyszek, 15:06:27) https://pagure.io/fesco/issue/2230 (mhroncok, 15:10:55) https://pagure.io/fesco/issue/2230#comment-599678 (mhroncok, 15:11:01) https://meetbot.fedoraproject.org/fedora-meeting-1/2019-09-23/fesco.2019-09-23-15.00.log.html (mhroncok, 15:11:59) Action items zbyszek will chair next meeting Minutes: https://meetbot.fedoraproject.org/teams/fesco/fesco.2019-10-14-15.00.html Log: https://meetbot.fedoraproject.org/teams/fesco/fesco.2019-10-14-15.00.log.html Text: https://meetbot.fedoraproject.org/teams/fesco/fesco.2019-10-14-15.00.log.txt ___ 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
Schedule for Mondays's FESCo Meeting (2019-10-21)
Following is the list of topics that will be discussed in the FESCo meeting Monday at 15:00UTC in #fedora-meeting-1 on irc.freenode.net. To convert UTC to your local time, take a look at http://fedoraproject.org/wiki/UTCHowto or run: date -d '2019-10-21 15:00 UTC' Links to all issues to be discussed can be found at: https://pagure.io/fesco/report/meeting_agenda = Discussed and Voted in the Ticket = #2243 Python 2 exception for mercurial (runtime and buildtime) https://pagure.io/fesco/issue/2243 APPROVED (+5,0,-0) #2244 Update the FTBFS policy APPROVED (+5,0,-0) https://pagure.io/fesco/issue/2244 (This was also announced in https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/CA6QBPEI26JK6UGAZL7DUPZC2ESAJHZC/.) #2245 F32 System-Wide Change: Binutils 2.33 https://pagure.io/fesco/issue/2245 APPROVED (+5,0,-0) = Followups = #2241 F32 Self-Contained Change: Better Thermal Management for the Workstation https://pagure.io/fesco/issue/2241 #2246 Create a rule to get newly Fedora branched composes sooner https://pagure.io/fesco/issue/2246 #2230 FESCo blocker bug: Broken upgrades via libgit2 https://pagure.io/fesco/issue/2230 = New business = None so far. = Open Floor = For more complete details, please visit each individual issue. The report of the agenda items can be found at https://pagure.io/fesco/report/meeting_agenda If you would like to add something to this agenda, you can reply to this e-mail, file a new issue at https://pagure.io/fesco, e-mail me directly, or bring it up at the end of the meeting, during the open floor topic. Note that added topics may be deferred until the following meeting. ___ 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: Modularity and the system-upgrade path
On Tue, Oct 15, 2019 at 09:26:31PM -0400, Stephen Gallagher wrote: > Alternate Proposal: > > Most things from the original proposal in the first message of this > thread remains the same except: > > Module stream metadata would gain two new optional attributes, > "upgrades:" and "obsoletes:". I'm sorry, but I'm against this proposal, both in its first form, and as amended here. The long discussion in this thread has pushed me over into conviction that modules should not be "on by default" in any way in Fedora. The first form of the proposal was already staggeringly complex — "default", "dep_enabled", "default_enabled", "default", …. Recording user intent when the users interacts directly with the thing might be OK, but mapping that intent onto dependencies that are pulled in automatically is not something that can be well defined. My expectation is that we'd forever be fighting broken expectations and unexpected cases. But the amended proposal actually makes things *worse*, even more complex. We would have two parallel sets of dependency specifications: on the rpms level and on the module level. The interactions between them would be hard to understand for users. I also don't think we need this at all: everything that could be expressed using deps between modules can also be expressed using deps between rpms. We have a rich and well defined dependency language for rpms, so let's just use it. One of the operational problems with Modularity is that it places huge expectations on dnf. Modularity was never very well defined, and dnf had to adapt on the fly to changing rules and requirements. This never went well. Even more complexity, with three parallel sets of semi-interacting-semi-independent sets of constraint rules (rpm deps, module intent, module obsoletes+provides), expressed in different form, is imho a recipe for bad ux. At the same time, this thread has shown that this additional complexity would need to be added to have upgrade paths for modules. Essentially, to me this thread has shown that Modularity needs to go back to drawing board, to reassess goals and assumptions and implementation choices. A lot of what people *thought* Modularity would give them, is simply not possible, and at the same time, the costs and impact on the rest of the distribution is higher than expected. As has been extensively discussed, modules are opaque and a) by design make some rpms not visible and not as available to other packagers as before, b) make it harder for people outside of Fedora to reuse our packaging and build on top of Fedora. Modules also raise the complexity of packaging. I understand that for some expert packagers they provide new functionality, but they complicate life for the majority of packagers. I think this additional complexity is of the reasons for the decline in participation of non-expert packagers in Fedora that was show in FPL's graphs. The work that went into Modularity is certainly not all wasted: I think we all understand the problem and what solutions don't work much better then before. I think we should take a step back and try for a solution which has lower end-user complexity and better backwards compatibility. I'm not asking for an improved proposal here: for me, Modularity in its current form is simply not a net benefit for Fedora's packagers or users. Thus, I'm against both default modules, and adding modules in the buildroot, and against rebasing any part of Fedora to build on top of modules. This is "contingency mode", i.e. thinking how to bring things back to working state. I think it is OK to allow modules to be available, but they must be opt-in, and normal rpms may not allow on the modularized rpms in any way. I wrote this in reply to this thread, even though some things might fit more in the sister thread "Fedora 32 System-Wide Change proposal: Modules in Non-Modular Buildroot". I don't want to send two mails with a lot of text, and the two things are inextricably linked: we cannot enable modules by default, or make more things depend on them by including in the build root, without having working upgrade paths. 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
Re: Orphaned packages looking for new maintainers
Hi Miro, jpype, as the one package only with obvious b0rken depenency, is already fixed in rawhide to use unittest instead of unittest2. No idea why this notification about orphaned packges still reaches out to me. https://src.fedoraproject.org/rpms/jpype/c/49fa1a4dd78b8ef2b09c2ce55084717d33e66236?branch=master https://koji.fedoraproject.org/koji/buildinfo?buildID=1396036 Regards Raphael Am 14.10.19 um 18:06 schrieb Miro Hrončok: … raphgro: python-unittest2 … ___ 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: Orphaned packages looking for new maintainers
On 20. 10. 19 21:53, Raphael Groner wrote: Hi Miro, jpype, as the one package only with obvious b0rken depenency, is already fixed in rawhide to use unittest instead of unittest2. No idea why this notification about orphaned packges still reaches out to me. https://src.fedoraproject.org/rpms/jpype/c/49fa1a4dd78b8ef2b09c2ce55084717d33e66236?branch=master https://koji.fedoraproject.org/koji/buildinfo?buildID=1396036 It sometimes takes a while to get the recent data. It uses the rawhide repository. Currently, it is no longer there, see the most up to date report at: https://churchyard.fedorapeople.org/orphans.txt -- 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: Modularity and the system-upgrade path
On Sun, Oct 20, 2019 at 15:20 Zbigniew Jędrzejewski-Szmek wrote: > On Tue, Oct 15, 2019 at 09:26:31PM -0400, Stephen Gallagher wrote: > > Alternate Proposal: > > > > Most things from the original proposal in the first message of this > > thread remains the same except: > > > > Module stream metadata would gain two new optional attributes, > > "upgrades:" and "obsoletes:". > > I'm sorry, but I'm against this proposal, both in its first form, and > as amended here. The long discussion in this thread has pushed me over > into conviction that modules should not be "on by default" in any way > in Fedora. > > The first form of the proposal was already staggeringly complex — > "default", "dep_enabled", "default_enabled", "default", …. Recording > user intent when the users interacts directly with the thing > might be OK, but mapping that intent onto dependencies that are pulled > in automatically is not something that can be well defined. My expectation > is that we'd forever be fighting broken expectations and unexpected cases. > > But the amended proposal actually makes things *worse*, even more complex. > We would have two parallel sets of dependency specifications: on the > rpms level and on the module level. The interactions between them would > be hard to understand for users. > > I also don't think we need this at all: everything that could be > expressed using deps between modules can also be expressed using deps > between rpms. We have a rich and well defined dependency language for > rpms, so let's just use it. > > One of the operational problems with Modularity is that it places huge > expectations on dnf. Modularity was never very well defined, and dnf > had to adapt on the fly to changing rules and requirements. This never > went well. Even more complexity, with three parallel sets of > semi-interacting-semi-independent sets of constraint rules (rpm deps, > module intent, module obsoletes+provides), expressed in different form, > is imho a recipe for bad ux. > > At the same time, this thread has shown that this additional > complexity would need to be added to have upgrade paths for modules. > Essentially, to me this thread has shown that Modularity needs to go > back to drawing board, to reassess goals and assumptions and > implementation choices. A lot of what people *thought* Modularity > would give them, is simply not possible, and at the same time, the > costs and impact on the rest of the distribution is higher than > expected. > > As has been extensively discussed, modules are opaque and a) by design > make some rpms not visible and not as available to other packagers as > before, b) make it harder for people outside of Fedora to reuse our > packaging and build on top of Fedora. > > Modules also raise the complexity of packaging. I understand that for > some expert packagers they provide new functionality, but they complicate > life for the majority of packagers. I think this additional complexity > is of the reasons for the decline in participation of non-expert > packagers in Fedora that was show in FPL's graphs. > > The work that went into Modularity is certainly not all wasted: I think > we all understand the problem and what solutions don't work much better > then before. I think we should take a step back and try for a solution > which has lower end-user complexity and better backwards compatibility. > > I'm not asking for an improved proposal here: for me, Modularity in its > current form is simply not a net benefit for Fedora's packagers or users. > Thus, I'm against both default modules, and adding modules in the > buildroot, and against rebasing any part of Fedora to build on top of > modules. This is "contingency mode", i.e. thinking how to bring things > back to working state. I think it is OK to allow modules to be available, > but they must be opt-in, and normal rpms may not allow on the > modularized rpms in any way. > > I wrote this in reply to this thread, even though some things might > fit more in the sister thread "Fedora 32 System-Wide Change proposal: > Modules in Non-Modular Buildroot". I don't want to send two mails with > a lot of text, and the two things are inextricably linked: we cannot > enable modules by default, or make more things depend on them by > including in the build root, without having working upgrade paths. > If I were to start from scratch on this, I would look at the simplest solution I would want from Boltron. I want to make it so a package team can make a set of packages in a repository and work out how I can interact with other repositories. I also want to easily build that package set in ways to work on different versions of an operating system. Let us ignore the early goal of modularity of ‘I don’t want a ton of repositories’ which led to ‘virtual repositories’ which led to ‘modules’. For our ‘persona’ story.. let us go back to the days of Dag and Athimm .. and we want to be able to give them the tools to build 2 repositories which worked on
Re: Modularity and the system-upgrade path
On Sun, Oct 20, 2019 at 09:30:52PM -0400, Stephen John Smoogen wrote: > If I were to start from scratch on this, I would look at the simplest > solution I would want from Boltron. I want to make it so a package team can > make a set of packages in a repository and work out how I can interact with > other repositories. I also want to easily build that package set in ways to > work on different versions of an operating system. The question is whether this team wants to do the "heavy lifting" (which might or might not actually be very heavy), of integrating with the rest of the distro. If they don't, then Copr is the answer: it provides all the answers, including automatic rebuilds. If they do, and they invest in following the packaging guidelines and and the release cycles and whatever we say makes the package suitable for users and other packagers to build on, they get to put the package in the distro. > 1. They have a lot of packages they need to tie together > 2. They need to build those packages for multiple deliverable operating > environments > 3. They need to interact with other groups of packages in a way which that > their group can 'know' if there is a chance of coworking. > 4. Many are tied to systems which have fast, hard update cycles which do > not work with even a 'fast' OS like Fedora. > > Users are wanting > 1. A system which can tie these different speed things together. > 2. That system to be updated or is clear on why it can't and what needs to > be done. This is all already satisfied by rpms (even from Copr). In particular, for point 3., there can be no magic: we can *express* relationships between packages with Provides and Requires, but to *know* what should be expressed, we need packager input _and_ ideally lots of QA and testing. No new repo format and metadata language fundamentally changes this. 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
