Re: intent to orphan notice: python-nss
This has been orphaned. - A ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
dracut broken in 054 -- bz#1965585
Hello all, I wanted to raise awareness of https://bugzilla.redhat.com/show_bug.cgi?id=1965585: this has regressed in dracut 054 and the pending dracut 055 update (https://bodhi.fedoraproject.org/updates/FEDORA-2021-a3ab421a63) does not fix it. Seeing as this is a regression affecting several users (adding 90s to boot time and preventing Wayland from starting, requiring fallback to Xorg); what are the next steps? Is it possible to untag 054 from updates? Could we get 055 masked so it does not get pushed either? See also conversation on #fedora between myself and TJ- attempting to debug this. Attempting to file needinfo? assignee reports: > You can't ask dracut-maint-l...@redhat.com because that account is disabled. - Alex ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
intent to orphan notice: python-nss
Seeing as I've moved on from Fedora packaging... :-) And dogtag-pki no longer depends on python-nss... :-) I'd like to orphan python-nss. But in case anyone wants it, I'm making this offer before I officially orphan the package. There's some context here that Red Hat formerly was the sponsor (and main developer) upstream in Mozilla; the official project page links back to Fedora's bugzilla to report issues. However, the former developer has moved on and so have I. So keep in mind, if you accept this package in Fedora, you might be considered the official upstream maintainer as well. :D If I don't get a response in a couple of days, I'll click the orphan button in Pagure. Happy hackin', - A ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Policy proposal (draft): Don't push knowingly broken or work-in-progress work to dist git
On Tue, Jan 26, 2021 at 4:45 AM Miro Hrončok wrote: > > On 26. 01. 21 3:12, Kevin Kofler via devel wrote: > > Miro Hrončok wrote: > >> 1. Untested changes > >> > >> Packager pushes a "simple update" to dist git without checking if it even > >> builds. It doesn't. Packager has no time to fix this, so they move on for > >> now. Or they submit a build but never check if it actually built. > >> Provenpackagers who need to rebuild the package need to figure this out > >> and fix the problem if it is trivial, or revert the recent commit, when > >> the failure blocks them. > >> > >> IMHO Provenpackagers should not need to worry about this. Changes should > >> be at least smoke tested by a mock/scratch build and installation check > >> before shipping them. > > > > Requiring to do a scratch build or local build before any change in Rawhide > > really does not scale. It takes too long to get anything done in that > > setting. It means 1 extra build in all cases (if it takes n build attempts > > to get a successful build, your proposed workflow requires n+1 builds > > instead of n), which can take hours. > > That's why it is a SHOULD. > > > The suggested alternative workflow of using self pull requests (together > > with CI on pull requests) also does not scale, it adds a lot of steps to the > > process. > > Agreed. > > > IMHO, the real issue is the one Robbie Harwood pointed out: It should NOT be > > a common occurrence for a provenpackager to have to rebuild a package, and > > in particular, provenpackagers should NOT do scripted mass changes. A > > provenpackager should always check what the latest package in Rawhide > > actually is before blindly rebuilding dist-git HEAD. (As a provenpackager, I > > always do that before I do anything to a package owned by someone else.) > > Well, I understand your sentiment against mass spec changes, but there are > cases, where it currently cannot be avoided (e.-g. when a targeted mass > rebuild > is needed for a soname bump). W.g. when we update Python from 3.9 to 3.10 we > will need to rebuild (close to) 4000 packages. How are we supposed to check > what > the latest package in rawhide is and how do I act accordingly if it is not > dist-git HEAD? (Also, mass rebuild.) Just responding to this one point (and in light of the parent's post as well) ...is there a way that the Python bump can be done alongside the usual (and pre-scheduled) mass-rebuild of Fedora packages? I realize Python release bumps are becoming a regular occurrence but I'd rather we piggy-back off an existing deadline (mass-rebuild) than impose other artificial restrictions. I bring this up because, for a week, dogtag-pki was FTBFS in Rawhide (and, your scripts caught it) but I couldn't understand _why_: my local builds were succeeding just fine, it was only remote scratch/non-scratch builds that were failing. It turns out to be a change in my local pki-core (which was installed), but which wasn't yet updated in the dependency in Fedora. This is, admittedly, a case for simplifying PKI's deliverables (and perhaps, make it a single source package), but still: even well-intentioned packagers occasionally get stumped and unknowingly push bad updates. If we instead schedule time around mass-rebuild, I think this would reduce stress for all parties. My 2c. - A > > > The root cause of the issue is that we have recently had way too many > > incompatible changes in the distribution that required mass changing > > thousands of packages in Fedora. Changes such as the BuildRequires: make > > requirement, the changes to the Python and CMake specfile macros, etc. come > > to my mind. Not only do such changes introduce a need for a mass change that > > would otherwise not be there, but they also break many third-party specfiles > > that the mass-changing scripts cannot possibly catch because they are not in > > Fedora dist-git. Compatibility with existing specfiles should be a given. > > The root case of this issue is that packagers push broken stuff to dist-git > (knowingly or not) and provenpackagers cannot do what they need to do. It has > nothing to do with adding "make" to BRs (which was absolutely non-invasive and > no builds were attempted). I see your point, but I don't see how "don't make > mass changes" helps with the issue. > > -- > 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 ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of C
Re: Copr in 2020 and outlook for 2021
Congrats! I can say I've used several of these features and they work well, thanks for your team's work! One query inline... :) On Mon, Jan 4, 2021 at 11:53 AM Miroslav Suchý wrote: > > Let me sum up what we - the Copr team - did in 2020: > > * We enabled CDN for repos. https://fedora-copr.github.io/posts/copr-cdn > > * We enabled runtime dependecies on repositories > https://fedora-copr.github.io/posts/runtime-dependencies > > * We migrated all our servers from PHX datacenter to AWS. With zero downtime > for your repos. > > * Pavel Raiskup became the new Mock project leader, and he released seven > new versions of Mock during 2020. > https://github.com/rpm-software-management/mock/wiki > > * Our small team has been renamed to Community Packaging Team (CPT) because > beside Copr, we maintain other tools as > well: Mock, dist-git, Tito... > > * We drove changes in createrepo_c, which allowed us better throughput. Now, > Copr can build thousands of builds per day. > > * We worked on Fedora packages website, which was outdated and do not work > on recent Fedora. Unfortunately, it will not > be likely used, and static pages will be used as it will require less > maintenance. > > * We introduced Project scoring for projects in Copr (up/down vote) > http://frostyx.cz/posts/upvoting-projects-in-copr > > * We allowed you to delete multiple builds at once. > https://fedora-copr.github.io/posts/deleting-list-of-builds > > * You can use Github Actions now > https://pavel.raiskup.cz/blog/github-push-actions-and-copr.html > > * We created modulemd-tools for low-level handling of repositories and > modules. And tool for generating > module-build-macros. https://github.com/rpm-software-management/modulemd-tools > > * We worked hard on better EOL handling of Copr repositories. > > * We parallelized copr-dist-git imports. > > * We wrote code for Ansible DNF Copr module. This still needs to land in a > proper place like Ansible Galaxy. > https://pagure.io/copr/copr/blob/master/f/ansible > > * We provided --isolation=* and --bootstrap=* knob in Copr > > * We started an experimental "external dependencies" feature in Mock. > https://github.com/rpm-software-management/mock/wiki/Feature-external-deps > > * We created a new python module "templated-dictionary" as a spin-off from > Mock's code. > https://github.com/xsuchy/templated-dictionary > > * We wrote four articles "4 cool new projects to try in COPR" > https://fedoramagazine.org/tag/copr/ > > * Users now have the ability to change the build timeout up to a maximum of > 48 hours > > * Users can group builds in batches now. > https://pavel.raiskup.cz/blog/build-ordering-by-batches-in-copr.html > > > We already have plans to do: > > * Verify GPG checks in DNF using DNSSEC. > https://pagure.io/copr/copr/issue/406 > > * Improve hooks (in cooperation with Packit team) > > * We are going to EOL APIv1 and APIv2 > https://fedora-copr.github.io/posts/EOL-APIv1-APIv2 > > > What will we do in 2021? We have some ideas. Some of them are yours, some of > them are ours. At the end of this email is > a link to Google Form where you can vote what you would like to get. We will > consider your vote. (listed in no specific > order) > > * When you create a project, you may specify that it will be for Package > Review. We do some settings for you, and > `rpminspect` will be run automatically at the end of the build. We can guide > users on how to file Package Review BZ. Or > do that automatically on their behalf. > > * Contribute to fedpkg/Koji that tagged commits will be automatically built > in Koji and may be automatically sent to Bodhi. > > * Help with automatic changelog entries. > > * Native support for Fedora in Travis. Travis has made a lot of changes to how OSS projects can use it, and (IMO) burnt a lot of good will in the community. All of our upstream projects ended up moving off it and onto GitHub Actions. Is there any chance we could vote for GitHub Actions enablement instead of Travis? Currently we run a Fedora Docker image on top of the Ubuntu host, which is less than ideal in some cases (e.g., filesystem package upgrades...). Thanks, Alex > > * Continue on external dependencies. > https://github.com/rpm-software-management/mock/wiki/Feature-external-deps > > * Finish rpm-spec-wizard https://github.com/xsuchy/rpm-spec-wizard > > * Better integration with Koshei. > > * Automatic rebuilds in Copr when dependency change (likely with the help of > Koshei) > > * Enhance release-monitoring and rebase-helper to automatically open PR in > Pagure when new version is available. > > * Enhance `Mock --chain` to try to set %bootstrap when standard loop fails. > When the set succeeds, rebuild the > bootstrapped package again without %bootstrap macro. > https://docs.fedoraproject.org/en-US/packaging-guidelines/#bootstrapping > > * Improve the process of finding a sponsor for the first package. > > * Contribute to fedpkg/koj
Re: The future of Fedora Server (was Re: Fedora 34 Change: Make Fedora CoreOS a Fedora Edition (System-Wide Change))
On Wed, Dec 2, 2020 at 12:52 PM Ben Cotton wrote: > > On Wed, 2020-12-02 at 11:14 -0500, Neal Gompa wrote: > > > There were a number of people interested in helping with reviving the > > Server WG, myself included. But we don't know how to have that move > > forward. We've never really had a situation like this before... > > > I'd start with staging a takeover of https://fedoraproject.org/wiki/Server > > It looks like there are no meeting logs in the last two years, so I > don't think you'll get much pushback. > > I talked to sgallagh before posing this question, so I don't expect > you'll get any pushback. If anything, you'll probably make people > happy. :-) > > On Wed, Dec 2, 2020 at 12:30 PM Adam Williamson > wrote: > > > > I'm not sure it's really warranted, to be honest. A counterpoint is > > that you can consider Server to be sort of dormant *because it works*. > > Is "it still works" sufficient to keep a deliverable at the forefront? > Obviously we want what we ship to work, whether it's an Edition or > bex's Llama Herder Lab. But what is Server doing to move the state of > the art forward? Server is a slightly different case in that generally > you don't want servers to be too adventurous, but if it's in statis, > should it be a flagship? > > Like I said above, the Server WG appears to be in zombie state for at > least the last two years. Is Fedora Server doing what it should be > doing now, or is it doing what it should have done two years ago? IMO, yes. I am a silent consumer of it. It provides a non-graphical default Fedora installation that just works as a target for various automated deployments (e.g., qemu + ansible). For both work and non-work deployments of Fedora on VMs, Fedora Server is my default mechanism to do so (whether on local libvirt or remote cloud deployments). I'm not sure it really needs much care and feeding -- a boring packaging of Fedora with some bare necessities and without any graphical tooling doesn't need much management or steering. Changing what is shipped in the base Server distribution frequently is an anti-feature. That I haven't had any Server-specific bugs or issues is a good thing. > > Of course, we can keep publishing Server images and providing those > > capabilities without calling it an Edition, but...I'm not sure it just > > being sort of quiet and undramatic necessarily merits that, especially > > if we don't have clear replacements for its capabilities yet. > > I'm certainly not advocating we drop Server entirely. But we should > evaluate its place in Fedora, particularly if there's no one providing > active care and feeding. I'd much rather see the Server WG come back > to life and keep it as an Edition. The care and feeding of a Fedora Server edition, IMO, shouldn't come from changes in content curation, but all the packagers involved in maintenance of packages shipped by the edition. My 2c. Alex > > -- > Ben Cotton > He / Him / His > Senior Program Manager, Fedora & CentOS Stream > Red Hat > TZ=America/Indiana/Indianapolis > ___ > 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: Summary/Minutes from today's FESCo Meeting (2020-11-11)
On Tue, Nov 17, 2020 at 1:21 PM Robbie Harwood wrote: > > Matthew Miller writes: > > > On Fri, Nov 13, 2020 at 10:52:57PM +0100, Kevin Kofler via devel wrote: > >> > I completely agree. This is one of the reasons I switched away from > >> > ubuntu years ago (with its 4 (?) tiers of support + repos for its > >> > packages ...). > >> I agree, Fedora did the Core-Extras Merge back in the day for a reason. > > > > That reason was _mainly_ to erase the inside Red Hat, > > community-around-the-edges distinction. That was a huge success and Fedora > > wouldn't be interesting without that. But I think the _technical_ choice was > > in retrospect a mistake. There's a reason RHEL 8 switched the _other_ way. > > Respectfully, I don't agree with that. From a technical perspective, > the splitting of RHEL into many repos is awful to work with, and there > was no reason to suppose it would be otherwise. > > Suppose I depend on a package. That package could now come from any of > the following repositories (assuming I haven't forgotten any): > > - AppStream > - BaseOS > - CRB > - BuildRoot > - EPEL > > And that's just for me building things in BaseOS + AppStream, not even > any layered products. For me internally, these repos are all nearby, > but what if I weren't? Some come from Red Hat, some from CentOS, EPEL > (and ELN) from Fedora, ... > > This is painful to work with; I just need my package to build. From a > technical perspective, we need to consider the time lost due to trying > to configure machines and testing environments with the right repos, > the impossibility of figuring out what repo a package actually is > shipped in [1] (if it even is), etc.. > > And that doesn't even get into modularity - where there's another layer > of package non-discoverability. > > Also RHEL/EPEL policy currently means that "hidden" packages in RHEL > can't be exposed in EPEL - because that would be repackaging them. > > In summary, from a technical perspective, this is an unwieldy mess. > Nothing is gained from the packager's point of view or the end user's > point of view. The gains [2] are in the lifecycle and support realms - > firmly in business, not technical. > > So: no new repo splits please. The only distinction we should care > about is "Fedora" and "not Fedora", in my view - keep it simple and > approachable. I second what Robbie has said as well. I am against the thought of this change. As my team has found out within Red Hat, this repo split has been a large PITA. Because RHEL also won't self-host and many sub-packages are missing from released bits that are otherwise available in e.g., BUILDROOT, building our bits in COPR for QE to test has been an impossible battle. After close to a year, this use case still hasn't been enabled internally. Consider also what other groups such as COPR have to do to support repo splits. Yeah, it might be quick to split it in Koji and repo files, but the impact on other teams and contributors is a huge negative. If people have to go searching for special repos and dependencies to build their packages, the developer experience of Fedora will suffer more. That will push more people to Ubuntu. My 2c., Alex > > Thanks, > --Robbie > > 1: This is an issue with RHEL tools, in my view. > 2: I contend that hiding packages doesn't actually reduce support >burden, just hides it, but that's orthogonal to the conversation. > ___ > 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: INVALID USER jden...@redhat.com / FAS jdennis
Also, JFTR, I believe I only took over internal maintenance of python-nss; I am not a maintainer of Fedora python-nss. There is only one maintainer: https://src.fedoraproject.org/rpms/python-nss - Alex On Wed, Nov 18, 2020 at 2:09 PM Alexander Scheel wrote: > > Note that I have no access to upstream python-nss. The entire upstream > community was John Dennis. The last upstream commit was in 2018 and > the commit prior was in 2017. With his departure, there's no viable > path forward for maintaining python-nss upstream; perhaps someone from > Mozilla will take it over, I do not know. > > Dogtag is looking to remove our dependency on python-nss and will > likely orphan it if we can do so in the f34 release cycle. > > I'll let the list know what we decide. > > > - A > > On Wed, Nov 18, 2020 at 2:00 PM Rob Crittenden wrote: > > > > Miro Hrončok wrote: > > > Hello. > > > > > > Does anybody has an alternate contact info for jden...@redhat.com / FAS > > > jdennis? > > > > > > Bugzilla says the account is invalid: > > > > > > https://bugzilla.redhat.com/show_bug.cgi?id=1892248 > > > > Alex Scheel replaced John as the maintainer. > > > > rob > > ___ 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: INVALID USER jden...@redhat.com / FAS jdennis
Note that I have no access to upstream python-nss. The entire upstream community was John Dennis. The last upstream commit was in 2018 and the commit prior was in 2017. With his departure, there's no viable path forward for maintaining python-nss upstream; perhaps someone from Mozilla will take it over, I do not know. Dogtag is looking to remove our dependency on python-nss and will likely orphan it if we can do so in the f34 release cycle. I'll let the list know what we decide. - A On Wed, Nov 18, 2020 at 2:00 PM Rob Crittenden wrote: > > Miro Hrončok wrote: > > Hello. > > > > Does anybody has an alternate contact info for jden...@redhat.com / FAS > > jdennis? > > > > Bugzilla says the account is invalid: > > > > https://bugzilla.redhat.com/show_bug.cgi?id=1892248 > > Alex Scheel replaced John as the maintainer. > > rob > ___ 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: Donate 1 minute of your time to test upgrades from F32 to F33
I've got a weird one: Error: Problem 1: package openssh-ldap-debuginfo-8.3p1-3.fc32.x86_64 requires openssh-debuginfo(x86-64) = 8.3p1-3.fc32, but none of the providers can be installed - openssh-debuginfo-8.3p1-3.fc32.x86_64 does not belong to a distupgrade repository - problem with installed package openssh-ldap-debuginfo-8.3p1-3.fc32.x86_64 But I'm not partial to my debuginfo and I can nuke it before upgrading. Is this worth reporting? On Fri, Oct 2, 2020 at 3:51 AM Miroslav Suchý wrote: > > Do you want to make Fedora 33 better? Please spend 1 minute of your time and > try to run: > > # Run this only if you use default Fedora modules > # next time you run any DNF command default modules will be enabled again > sudo dnf module reset '*' > > sudo dnf --releasever=33 --setopt=module_platform_id=platform:f33 \ > --enablerepo=updates-testing --enablerepo=updates-testing-modular \ > distro-sync > > This command does not replace `dnf system-upgrade`, but it will reveal > potential problems. You may also run `dnf > upgrade` before running this command. > > > If you get this prompt: > > ... > Total download size: XXX M > Is this ok [y/N]: > > you can answer N and nothing happens, no need to test the actual upgrade. > > But very likely you get some dependency problem now. In that case, please > report it against the appropriate package. Or > against fedora-obsolete-packages if that package should be removed in Fedora > 33. Please check existing reports against > fedora-obsolete-packages first: > https://red.ht/2kuBDPu > and also there is already bunch of "Fails to install" reports: > > https://bugzilla.redhat.com/buglist.cgi?bug_id=1803235&bug_id_type=anddependson&format=tvp&list_id=11399170 > > Thank you > > -- > Miroslav Suchy, RHCA > Red Hat, Associate Manager ABRT/Copr, #brno, #fedora-buildsys > ___ > 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: The Future of the Java Stack (also regarding ELN and RHEL)
What Fabio just mentioned was that the current use case for a build-time only package is invalid. A lot of packages Mikolaj is trying to get build-time only (via modules) are still maintained by the Java Maintenance SIG because they're required by other packages. Allowing them to be build-time only results in the entire ecosystem crumbling. If they're retired, the ecosystem crumbles too. Same result either way. That's why the Java Maintenance SIG was built: so that it can be more than one person working on these packages. - Alex On Fri, Sep 11, 2020 at 12:44 PM Zbigniew Jędrzejewski-Szmek wrote: > > On Fri, Sep 11, 2020 at 06:01:11PM +0200, Fabio Valentini wrote: > > On Fri, Sep 11, 2020 at 5:52 PM Zbigniew Jędrzejewski-Szmek > > wrote: > > > > > > On Fri, Sep 11, 2020 at 11:03:39AM +0200, Hans de Goede wrote: > > > > An other more generic approach which has been brought up once or > > > > twice, but which not really has been discussed in much detail yet > > > > I believe is creating a fedora-builddep repository. > > > > > > > > ATM a normal user has 3 ursine Fedora repos installed: > > > > > > > > fedora > > > > fedora-updates > > > > fedora-updates-testing (disabled by default) > > > > > > > > What if we add a 4th repo called fedora-builddep: > > > > > > > > fedora > > > > fedora-updates > > > > fedora-updates-testing (disabled by default) > > > > fedora-builddep (rolling (within a release), disabled by default) > > > > > > > > So the idea is that all the maven deps which you need, but > > > > do not want to offer any end-user support on would go to > > > > fedora-builddep. > > > > > > If we absolutely must have build-only packages, we can do it more simply: > > > insert > > > Requires: fedora-unmaintained-package > > > or > > > Requires: fedora-buildonly-package > > > (name TBD), and beef up dnf a bit to explain that "this package cannot > > > be installed because it's only maintained at the level appropriate for > > > building packages...". I think there are two advantages: first, no need > > > for a separate repo, so there'll be less infra change and churn. Second, > > > this tag can easily set on each subrpm, without any central list to > > > manage. > > > > I'm not sure making things available only at build-time is going to > > help things. It's just "Modularity under a different name" ... > > Most Java packages are either directly or indirectly depended on by > > non-build-tool packages as well. > > You'd be surprised. Most of the distro directly or indirectly depends > > on the Java stack already - including the libvirt stack, libreoffice, > > some GNOME components, KDE components, etc. So most of those Java > > packages can't be built-time-only packages because they're actually > > required at runtime. > > The number of packages that are *really only ever needed to build > > other RPM packages and for no other reasons* is rather small. > > You are probably right. Still, this would be useful to actually have this > surfaced. If a package marked build-time-only would be needed by anything > else, we would need to either unmark it (and have somebody on the hook > for maintaince) or drop the dependency somehow. And this would be vastly > better than build-time-only packages in modules. > > I'm not enthusiastic about build-time-only packages, but if the choice > is between that and retiring the packages (or hiding them in modules > which has the same effect), I'll take it. > > 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: The Future of the Java Stack (also regarding ELN and RHEL)
Ben, Can Fedora first-party flatpaks be built from unsigned, untrusted content outside of the Fedora Repos? Or can they only be built from content otherwise already present in Fedora? Just curious what benefits a first-party flatpak has versus an upstream one. AFAIK, the last Fedora Container docs said that all Container content must be pulled from Fedora Repos, and therefore was left holding a bunch of RPMs anyways. - A On Thu, Sep 10, 2020 at 11:38 AM Ben Cotton wrote: > > On Thu, Sep 10, 2020 at 10:54 AM Vitaly Zaitsev via devel > wrote: > > > > On 10.09.2020 16:10, Aleksandar Kurtakov wrote: > > > Flatpak is way better suited for our use case and in addition gives us > > > access to a way bigger install base. > > > > Flathub is a third-party repository and not related to Fedora at all. > > > Flat*hub* is third party, but we have first-party flatpaks at > registry.fedoraproject.org. The flatpak package adds it as a remote > via /usr/lib/systemd/system/flatpak-add-fedora-repos.service > > -- > Ben Cotton > He / Him / His > Senior Program Manager, Fedora & CentOS Stream > Red Hat > TZ=America/Indiana/Indianapolis > ___ > 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: The Future of the Java Stack (also regarding ELN and RHEL)
On Thu, Sep 10, 2020 at 10:11 AM Aleksandar Kurtakov wrote: > > > > On Thu, Sep 10, 2020 at 4:46 PM Alexander Scheel wrote: >> >> Hi Joe, >> >> On Thu, Sep 10, 2020 at 8:52 AM Joe Orton wrote: >> > >> > Hi all, >> > >> > I'm writing as the Red Hat engineering manager responsible for Maven and >> > Ant in RHEL, and on behalf of Mikolaj Izdebski and Marian Koncek from my >> > team. I want to give a broad response to some of the points here: >> > >> > 1. The team has two missions in Fedora: >> > >> > a) We deliver, maintain and support Ant and Maven in Fedora. Our aim is >> > to provide developers with the most popular Java build systems which are >> > reviewed, tested, and updated through the release lifecycle. >> > >> > b) We design, develop and document tooling that enables anyone to >> > package Java software with a simple, efficient and scalable process. We >> > are also active members of Java SIG, collaborating on complex changes >> > and guiding new contributors. >> > >> > 2. We are committed to maintaining the Ant and Maven modules in >> > Fedora. We have always expected to make them available as default >> > streams and in the buildroot so they can be available and consumed by >> > non-modular packages, but we completely respect the decisions of FESCo >> > to disallow default streams and of other contributors to adopt and >> > maintain the non-modular packages. We are not going to promise to >> > commit time and resources to maintain the non-modular packages. >> >> As a reminder (as in my RHEL devel-list reply): there are no default >> module streams in Fedora. There is also no Ursa Major/Prime, so were >> they to exist, there would still be no way for non-modular packages to >> use them. >> >> This makes the artifacts produced here useful only to other modules. >> Non-modular packages maintained by other Red Hatters, like Eclipse and >> Dogtag PKI cannot use these artifacts. Both of these stacks have tried >> to modularize in Fedora but ultimately remained non-modular. > > > FWIW, I'm eagerly looking to stop packaging Eclipse as RPM entirely. Flatpak > is way better suited for our use case and in addition gives us access to a > way bigger install base. And the involvement on Java packaging in Fedora is > so low that we literally have to maintain whole other stacks including jetty, > lucene and etc. - not feasible work in any way. Mat Booth (also from the Eclipse team!) still actively helps out with this packaging as RPMs and we thank him for his efforts while they last. :-) But Flatpak isn't suitable for everyone--it isn't great for servers like Dogtag and IdM for instance. So we still need RPM packaging around for that. Also, does that mean Eclipse won't be in RHEL-9? So far it looks like it is not rebuilt for ELN so it seems likely it won't be. https://koji.fedoraproject.org/koji/packageinfo?packageID=183 - Alex > >> >> >> > 3. Our efforts are currently directed mainly at minimization of the >> > dependency tree which leads to maven and ant, automating the process of >> > bootstrapping maven and updating related components, so that new >> > versions can be imported and built reproducibly and with consistent >> > quality. >> > >> > 4. The benefit we want to preserve from modules is to maintain packages >> > with varying expectation of quality, specifically separating the >> > build-time-only vs runtime dependencies. e.g. in that case that a web >> > server like Eclipse Jetty is required as a dep for testing another >> > component during the build, we want to be able to use and build that >> > component, without being indefinitely on the hook for security errata. >> > (The build dependency tree is particularly complex for Maven and >> > involves many examples of packages with frequent and high severity >> > vulnerabilies) >> > >> > Regards, Joe >> > ___ >> > 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 mail
Re: The Future of the Java Stack (also regarding ELN and RHEL)
Hi Joe, On Thu, Sep 10, 2020 at 8:52 AM Joe Orton wrote: > > Hi all, > > I'm writing as the Red Hat engineering manager responsible for Maven and > Ant in RHEL, and on behalf of Mikolaj Izdebski and Marian Koncek from my > team. I want to give a broad response to some of the points here: > > 1. The team has two missions in Fedora: > > a) We deliver, maintain and support Ant and Maven in Fedora. Our aim is > to provide developers with the most popular Java build systems which are > reviewed, tested, and updated through the release lifecycle. > > b) We design, develop and document tooling that enables anyone to > package Java software with a simple, efficient and scalable process. We > are also active members of Java SIG, collaborating on complex changes > and guiding new contributors. > > 2. We are committed to maintaining the Ant and Maven modules in > Fedora. We have always expected to make them available as default > streams and in the buildroot so they can be available and consumed by > non-modular packages, but we completely respect the decisions of FESCo > to disallow default streams and of other contributors to adopt and > maintain the non-modular packages. We are not going to promise to > commit time and resources to maintain the non-modular packages. As a reminder (as in my RHEL devel-list reply): there are no default module streams in Fedora. There is also no Ursa Major/Prime, so were they to exist, there would still be no way for non-modular packages to use them. This makes the artifacts produced here useful only to other modules. Non-modular packages maintained by other Red Hatters, like Eclipse and Dogtag PKI cannot use these artifacts. Both of these stacks have tried to modularize in Fedora but ultimately remained non-modular. > 3. Our efforts are currently directed mainly at minimization of the > dependency tree which leads to maven and ant, automating the process of > bootstrapping maven and updating related components, so that new > versions can be imported and built reproducibly and with consistent > quality. > > 4. The benefit we want to preserve from modules is to maintain packages > with varying expectation of quality, specifically separating the > build-time-only vs runtime dependencies. e.g. in that case that a web > server like Eclipse Jetty is required as a dep for testing another > component during the build, we want to be able to use and build that > component, without being indefinitely on the hook for security errata. > (The build dependency tree is particularly complex for Maven and > involves many examples of packages with frequent and high severity > vulnerabilies) > > Regards, Joe > ___ > 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: The Future of the Java Stack (also regarding ELN and RHEL)
On Wed, Sep 9, 2020 at 6:27 PM Jerry James wrote: > > On Tue, Sep 8, 2020 at 4:19 PM Fabio Valentini wrote: > > However! This has mostly been a one-man-show, with regular > > contributions by Mat Booth (whos thankless task is maintaining the > > Eclipse stack) and the Dogtag PKI team (thanks guys!), who have lately > > been busy doing other things (fixing blocker bugs for F33 and RHEL > > 8.3). > > For those who are willing to help out, is > https://pagure.io/java-maint-sig/issues the place to go to figure out > what needs to be done? Is there any kind of TODO list or wishlist > elsewhere? That has a good list for current issues. Many friendly folks also hang out in #fedora-java, where you can feel free to ask questions or lend a hand if you are looking for something more immediate. The old Stewardship SIG pages also had some interesting data: https://fedora-stewardship.github.io/overview/ I'm not sure if Fabio has migrated the backlog anywhere. > You've mentioned having some kind of script that rebuilds the Java > world to check for issues relating to package updates. Is that > available to the public? How long does it take to run (and on what > hardware do you run it)? This isn't a real integration test of any sort. We rebuild PRs (manually-triggered) and most all dependent packages in COPR and see if the world builds fine. You can find the script in the old Stewardship SIG repo: https://github.com/fedora-stewardship/fedora-stewardship.github.io/blob/master/scripts/review_pr.py There is also: HTH, Alex > Speaking of helping out, if anybody wants mockito 3.x in Fedora, here > is a pull request to do just that: > https://src.fedoraproject.org/rpms/mockito/pull-request/2 > -- > 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 System-Wide Change proposal: Modules in Non-Modular Buildroot
- Original Message - > From: "Randy Barlow" > To: "Development discussions related to Fedora" > > Sent: Thursday, October 17, 2019 1:18:08 PM > Subject: Re: Fedora 32 System-Wide Change proposal: Modules in Non-Modular > Buildroot > > On Thu, 2019-10-17 at 12:56 -0400, Randy Barlow wrote: > > I > > had to write a yaml file that listed hashes of every dependency of > > rpick, and every dependency of those dependencies, and their > > dependencies, and so on. > > By the way, I didn't actually end up doing this, Igor did it for me. I > didn't mean to take credit, I mean more that "I, the packager, had to > do this", not "I, Randy, had to do this". Igor rocks. Just for the obvious reply... :) `ref` behaves just like `git checkout` would. So yeah, you can pass a very explicit hash and then you won't get any updates until you bump the hash in the spec again. However, you could pass tags (like you mention in the comment next to each hash) or branches instead. The latter is what some other modules do, like the eclipse one: https://src.fedoraproject.org/modules/eclipse/blob/2019-06/f/eclipse.yaml#_1069 See also: https://github.com/fedora-modularity/libmodulemd/blob/master/spec.v2.yaml#L268-L273 In the latter case (in RHEL at least), you have to commit a (potentially empty) commit to the module and then a rebuild of the module will pull in the latest contents from the branches you specify for each component RPM. Perhaps we need to collect a "tips and tricks" section for modularity? HTH, Alex > > ___ > 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
- Original Message - > From: "Neal Gompa" > To: "Development discussions related to Fedora" > > Sent: Friday, October 11, 2019 2:36:58 PM > Subject: Re: Modularity and the system-upgrade path > > On Fri, Oct 11, 2019 at 8:50 AM Stephen Gallagher > wrote: > > > > > > > > On Thu, Oct 10, 2019 at 10:41 AM Lukas Ruzicka wrote: > >> > >> Seeing the reaction of the Modularity WG ... I do not understand how it is > >> possible that such important decisions are taken by 4 people without any > >> Fedora wide discussions like this. And yet, it seems a little bit that > >> even opinions on this list will not fall on fertile grounds. > > > > > > > > To be clear, I am reading every single reply to this thread very carefully. > > We *will* be taking all of this feedback into consideration, but please > > understand that we're also trying to balance things. As Neal noted > > upthread, we do have a responsibility to our downstream to make sure that > > we do not break the ability to manage default streams. This becomes much > > more difficult if we cannot have them in Fedora, because the testing of > > them is lost. Additionally, no one on the WG disagrees with you that the > > current state of things is undesirable. I take a moderate amount of > > offense to the repeated insinuations that the solutions we are building > > are "hacks". Yes, there's a proposal to work around the upgrade issue to > > F31 that is absolutely a one-off hack to buy time. But our plans for how > > upgrades should work long-term as well as how defaults need to behave in > > the distro are being considered very carefully. We are trying to avoid > > breakage and to make the process simpler, but we are also shoring up the > > bridge while crossing it. > > > > Two years into this, I am currently not confident that modularity will > be adapted to support community distributions well, especially > fast-paced ones like Fedora. My fears about it encouraging Fedora to > slow down has also seemingly borne fruit, too. Java is proof positive > of this. > > Since the implosion of Fedora Java in the regular distribution and its > move to modules, the traditional effort to move to newer Java versions > has basically disappeared. Java 11 LTS was released last year, and to > this day our default Java is still Java 8 (which is EOL!). Clearly, > we're developing a new antipattern that we need to nip in the bud > sooner rather than later. Not going to argue that we're well behind here, but to my knowledge, the Stewardship SIG maintains just about everything you'd find in a useless modular repo (e.g., packages that are outside of the default module stream's limited API) as an ursine package. We try not to duplicate too much of what's provided in the default module streams. So the claim that Java has imploded in the regular distribution are a little bit of a stretch. Then again, I don't use eclipse and most of my projects use CMake, not maven so I don't miss either of those major projects. I'm mostly talking about the vast swatches of Java libraries... :) > > My disappointment in this became even greater when openSUSE beat us to > switching to Java 11. Their packaging is derived from ours! They've > demodularized Java for openSUSE and then did the work to move > everything forward. Meanwhile, we've now failed at our "first" and > "features" pillars because the incentive is now *gone*. The Stewardship SIG does its best to update packages, but doesn't have the resources to fully switch to JDK 11 ourselves. That's really up to the Java SIG. Also, there's really nothing to do to demodularize a package. Just choose a branch and build it as an ursine package... ___ 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?
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. - Original Message - > From: "Zbigniew Jędrzejewski-Szmek" > To: "Development discussions related to Fedora" > > Sent: Friday, October 11, 2019 1:45:00 PM > Subject: how to list all module repos in Fedora? > > Hi, > > https://src.fedoraproject.org/modules/ returns 404, and > https://src.fedoraproject.org/browse/projects/ seems to list rpms/ > (though there's 622 pages of output, so I'm not sure). > > Is there a way to browse through module repos? > > 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
- Original Message - > From: "Matthew Miller" > To: "Development discussions related to Fedora" > > Sent: Tuesday, October 8, 2019 9:18:29 AM > Subject: Re: Modularity and the system-upgrade path > > On Mon, Oct 07, 2019 at 08:08:56PM -0400, Alexander Scheel wrote: > > > Without modularity, RPM doesn't offer a good way to choose between > > > different > > > versions of the same thing. One can squash version numbers into the name, > > > which covers some use cases, but also becomes unwieldy and loses the > > > _idea_ > > > that these things are different branches of the same basic software. > > > > This is not true at all. > > > > For starters, if you have parallel packages available [0], `rpm -i` will > > let you install them all just fine and track each individually [1]. When > > you go to uninstall it (`rpm -e rpm-test`), it'll complain that you didn't > > specify which one [2], so you'll of course have to specify a version [3]. > > > > If you then go stick it in a repo, DNF will show you the highest version, > > which is expected since DNF generally concerns itself with the updated-ness > > of your system [4]. But you can always pass --showduplicates to show the > > older versions. And nothing prevents you from selecting a different version > > of the package if they exist in the repo [5]. The one place this fails > > is that DNF will perform an upgrade, removing the older version, even if > > you > > choose install [6]. > > What if you want to apply a bugfix (or security update) to both of those > packages? How would that work? I'm not saying it is completely solved, just that what we have left to do is a lot less work than trying to fix modularity. [0] :) Since you asked... :) That's where you apply the dnf intent mechanism (iirc) this thread brought up, except it is a lot simpler because it operates on packages, which are single, relatively atomic units instead of modules, which are globs of special packages. There's four cases here (assuming a two-part version): - dnf install rpm-test # just a package name ---> no versionlock under the hood - dnf install rpm-test-1 # partial version -- major version 1 dnf versionlock rpm-test>=1 dnf versionlock rpm-test<2 ^ user has said, I want any major version 1 of this package, and I'll take any minor releases or patch updates. - dnf install rpm-test-1.0 # full version -- major version 1, minor version 0 dnf versionlock rpm-test>=1.0 dnf versionlock rpm-test<1.1 ^ under a two-part version scheme, this locks the user into only receiving patch updates. This is strict user intent, but we might want to confirm that they agree to receive only patch updates and might miss important bug fixes and some security fixes. - dnf install rpm-test-1.0-1 # full name, version, and release dnf versionlock rpm-test-1.0-1 ^ this is even stricter and prevents any new patch versions. I'd probably add a message to DNF update showing what packages won't be upgraded by a specific policy. And, since it all lives in the versionlock DNF plugin, there's a very well-known, easy way to modify these locks, which you'd also have to provide for modularity intents. I'd probably make it a message with confirmation about all new version locks introduced in a transaction and have the user manually confirm the batch separately from confirming the install. If the user wants to lock dependencies, once they're installed, they can of course use versionlock here as well. Entirely up to them. --- Bugfixes and security updates are the easiest to do. You'd have a version-based dist-git branch for each of your packages: - rpm-test:v1.0 - rpm-test:v1.1 - rpm-test:v2.0 Some policy dictates which releases ship where. So, a bugfix comes in as a patch. The maintainer decides which branches to check it into (depends on the bug, severity, and how well the patch applies to older versions). Since its a patch release, everyone will get it. Now let's say we get a bigger security flaw. It results in a partial rewrite upstream, and isn't conducive to patching. Upstream releases v1.2 and v2.1. I'd: - Annotate it as a security fix in Bodhi, - When dnf update runs: - non-version locked systems get an update to v2.1, - version-locked to any v2 get an update to v2.1, - version-locked to any v1 get an update to v1.2, - Any other version-locked message gets a warning on DNF upgrade saying that they locked themselves out of receiving a security update. Then, the community member can either loosen their versionlock and get the update, or continue opt-out of receiving the update at their own risk.
Re: Modularity and the system-upgrade path
- Original Message - > From: "Matthew Miller" > To: "Development discussions related to Fedora" > > Sent: Monday, October 7, 2019 4:31:18 PM > Subject: Re: Modularity and the system-upgrade path > > On Mon, Oct 07, 2019 at 03:20:21PM -0400, Alexander Scheel wrote: > > > And where is the software for those containers coming from? Some > > > container registry like Docker Hub? One of the main points of > > > Modularity is to provide a trusted source of software to install into > > > containers. > > I never really understood this argument. Could you help me understand > > it? > > In what way do ursine RPMs not already do this? And more importantly, > > what benefits does Modularity bring, based on an earlier thread with > > Modularity use cases? > > I'm going to avoid the word "ursine" because I think it's more confusing > then helpful. It's all the same RPMs, after all. Ok... But we need some word to describe "RPMs without weird context that behave like they're supposed to and somebody maintains them" instead of "RPMs in a module somewhere". Otherwise the discussion gets confusing fast. So if you don't mind, I'll stick with "ursine RPMs" vs "modular RPMs" for now. :) > Without modularity, RPM doesn't offer a good way to choose between different > versions of the same thing. One can squash version numbers into the name, > which covers some use cases, but also becomes unwieldy and loses the _idea_ > that these things are different branches of the same basic software. This is not true at all. For starters, if you have parallel packages available [0], `rpm -i` will let you install them all just fine and track each individually [1]. When you go to uninstall it (`rpm -e rpm-test`), it'll complain that you didn't specify which one [2], so you'll of course have to specify a version [3]. If you then go stick it in a repo, DNF will show you the highest version, which is expected since DNF generally concerns itself with the updated-ness of your system [4]. But you can always pass --showduplicates to show the older versions. And nothing prevents you from selecting a different version of the package if they exist in the repo [5]. The one place this fails is that DNF will perform an upgrade, removing the older version, even if you choose install [6]. So really, the only thing missing here is an option to make `dnf install` mean "install" and not "install or upgrade, whatever DNF feels is best". And then you can do all your user intent on the side: I installed "rpm-test-1.0", so I should always keep it installed... but if I also install "rpm-test", I should take whatever version that was and upgrade it... etc. To be fair, the packages in [0] are parallel installable too. But for the case where you only want parallel availability, you already have that, and can use dnf version locking [7] to prevent unintended upgrades if you manually specified a version. So I really think this is a non-issue in ursine RPMs. Modularity only gives you a way to group packages together, like software collections would've. It seems like the problem isn't in RPM or DNF, but is instead in Fedora's package tooling not letting you ship multiple versions of ursine RPMs without modularity. :) But while it might work better, it wouldn't be as cool and sexy as modules... > > > - Modularity doesn't bring parallel-installability. You'd have to support > >it at the RPM level, which means ursine RPMs would support it to. [0] > > Well, the idea is: if you need parallel install, don't mess with it at the > RPM level. Separate at the container level. See above; RPM actually supports parallel install just fine. We just need packaging guidelines we all agree on to ensure packages at different versions don't conflict and what that means. And lots of upstream work to make that happen for the packages we care about. And a little bit of alternatives magic to choose a default version for us and let us switch conveniently. > > > > - Any size reduction in modular RPMs can be made to urisine RPMs. > > Maybe. But what if it reduces functionality? Modularity allows there to be a > reduced version or a full version which can be swapped in. > > > -- > Matthew Miller > > Fedora Project Leader > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: >
Re: Modularity and the system-upgrade path
- Original Message -
> From: "Stephen Gallagher"
> To: "Development discussions related to Fedora"
>
> Sent: Monday, October 7, 2019 2:59:37 PM
> Subject: Re: Modularity and the system-upgrade path
>
> On Mon, Oct 7, 2019 at 2:56 PM Simo Sorce wrote:
> >
> > I have to ask,
> > given containers are so popular and can deal with any dependency
> > without conflicting with system installed binaries, should we really
> > continue with this very complicated modular design ?
> >
> > Shouldn't we go back to have default packages and then defer to
> > "containers" for applications (and their dependencies) that need to
> > deviate from system defaults for any reason ?
> >
>
> And where is the software for those containers coming from? Some
> container registry like Docker Hub? One of the main points of
> Modularity is to provide a trusted source of software to install into
> containers.
I never really understood this argument. Could you help me understand
it?
In what way do ursine RPMs not already do this? And more importantly,
what benefits does Modularity bring, based on an earlier thread with
Modularity use cases?
As far as I can see:
- Modularity doesn't bring parallel-installability. You'd have to support
it at the RPM level, which means ursine RPMs would support it to. [0]
- Any size reduction in modular RPMs can be made to urisine RPMs.
- Modules rely on RPMs as their source of trust and don't provide any new
trust models.
- To have container-only content (container-preferred content?) you'd need
the maintainer of the package to build separate "desktop/server" and
"container" streams. And, I'm not sure what benefit anyone will see,
that better structuring of sub-packages wouldn't give. Especially since
most modular content (build systems, eclipse, ...) aren't exactly suited
for production server containers. Application and development containers,
sure. [1]
I think, from the user and maintainer point of view, you could handle most
of the use cases of modules by:
- Spending a little time ensuring packages are divided up in a way that
better behaves with modules (to reduce the installation footprint...
say, {pkg}-man only gets installed when man is present, saving the space
on containers). I'd imagine this is a goal of the minimization team
that I've seen mentions of. But perhaps not. :)
- Focusing on guidelines for parallel installability for library
and applications versions.
But perhaps I just never understood Modularity after fighting with it
for so long in Fedora and ending up duplicating what it has undone in
the ursine world... Is there something obvious I'm missing of why
Modularity is more suited for containers than ursine RPMs?
- Alex
[0]: AFAICS, Modularity only gives you parallel availability, that is
multiple versions are available to be selected from, if the
maintainer wishes. But you can't go install the same packages at
two different versions.
[1]: My implicit assumption here is that there's very little we'd do
for container support besides divide down RPMs to make things
better for a layer's disk footprint... Most upstream projects will
either support running in containers, or they won't. I'd think
having lots of container-specific content would be a very minimal
edge case that I'm not sure is worth handling at this point in time.
To be clear, the above deals with *packages* installed inside other
container *images*, not an upstream deciding to say ship, an RPM and
a full *container image* of their own.
> ___
> 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
Drop "pki" Module?
Hi all, I filed a releng ticket about a week ago [0] but haven't heard back. Is there any action I can take myself to move this along? Thanks, Alex [0]: https://pagure.io/releng/issue/8637 ___ 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: "javaewah" (was Re: Over 500 orphaned packages seeking new maintainers)
- Original Message - > From: "Dave Dykstra" > To: "Alexander Scheel" > Cc: "Jan Pazdziora" , "Development discussions related > to Fedora" > > Sent: Tuesday, July 30, 2019 4:45:06 PM > Subject: Re: "javaewah" (was Re: Over 500 orphaned packages seeking new > maintainers) > > Alex, > > Thanks for the quick response. I see that one of my packages > (singularity) has BuildRequires git. However, installing git on fc31 > does not install jgit. Maybe jgit is a BuildRequires of git, but it's > not clear to me that it makes sense to follow those through, since in > order to build my package I don't need to build git, I just need to > install it. Looking here [0], you can see that it is/was a BuildRequires. This was dropped 5 days ago. Once this gets into Miro's output, you'll probably be dropped from affected. - Alex [0]: https://src.fedoraproject.org/rpms/git/blob/master/f/git.spec#_217 [1]: https://src.fedoraproject.org/rpms/git/blob/master/f/git.spec#_1021 > Dave > > > On Tue, Jul 30, 2019 at 04:02:12PM -0400, Alexander Scheel wrote: > > > > > > - Original Message - > > > From: "Dave Dykstra" > > > To: "Development discussions related to Fedora" > > > > > > Cc: "Jan Pazdziora" > > > Sent: Tuesday, July 30, 2019 3:53:37 PM > > > Subject: "javaewah" (was Re: Over 500 orphaned packages seeking new > > > maintainers) > > > > > > I don't see an answer to Jan's question about "javaewah" and think it > > > might have gotten buried in the thread, so I'd like to say -- I have > > > this question too. It seems something went wrong with the script that > > > generated the list. > > > > > > Dave > > > > > > I think you need to view the full report: > > https://churchyard.fedorapeople.org/orphans-2019-07-28.txt ). > > > > > > I see: > > > > > > (orphaned): > > javaewah eclipse-sig, galileo, orphan 0 weeks > > ago > > > > > > ~snip~ > > Depending on: javaewah (378), status change: 2019-07-23 (0 weeks ago) > > ~snip~ > > jgit (maintained by: mbooth) > > jgit-5.4.0-5.fc31.noarch requires > > mvn(com.googlecode.javaewah:JavaEWAH) = 1.1.6 > > jgit-5.4.0-5.fc31.src requires git = 2.22.0-1.fc31, > > mvn(com.googlecode.javaewah:JavaEWAH) = 1.1.6 > > ~sip~ > > git (maintained by: amahdal, besser82, chrisw, pcahyna, pstodulk, > > skisela, tmz) > > git-2.22.0-1.fc31.src requires jgit = 5.4.0-5.fc31 > > > > > > Does that answer the question? Perhaps this is an old dependency that has > > been > > removed. > > > > > > - Alex > > > > > > > > On Mon, Jul 29, 2019 at 01:02:28PM +0200, Jan Pazdziora wrote: > > > > On Mon, Jul 29, 2019 at 12:37:33PM +0200, Miro Hron??ok wrote: > > > > > The following packages are orphaned and will be retired when they > > > > > are orphaned for six weeks, unless someone adopts them. If you know > > > > > for > > > > > sure > > > > > that the package should be retired, please do so now with a proper > > > > > reason: > > > > > https://fedoraproject.org/wiki/How_to_remove_a_package_at_end_of_life > > > > > > > > > > Note: If you received this mail directly you (co)maintain one of the > > > > > affected > > > > > packages or a package that depends on one. Please adopt the affected > > > > > package or > > > > > retire your depending package to avoid broken dependencies, otherwise > > > > > your > > > > > package will be retired when the affected package gets retired. > > > > > > > > > > See the full report: > > > > > https://churchyard.fedorapeople.org/orphans-2019-07-28.txt > > > > > Grep it for your FAS username and follow the dependencies. > > > > > > > > > > Request package ownership via https://pagure.io/releng/issues > > > > > > > > > > Package (co)maintainers > > > > > Status > > > > > Change > > > > > > > > > > javaewah eclipse
Re: "javaewah" (was Re: Over 500 orphaned packages seeking new maintainers)
- Original Message - > From: "Dave Dykstra" > To: "Development discussions related to Fedora" > > Cc: "Jan Pazdziora" > Sent: Tuesday, July 30, 2019 3:53:37 PM > Subject: "javaewah" (was Re: Over 500 orphaned packages seeking new > maintainers) > > I don't see an answer to Jan's question about "javaewah" and think it > might have gotten buried in the thread, so I'd like to say -- I have > this question too. It seems something went wrong with the script that > generated the list. > > Dave I think you need to view the full report: https://churchyard.fedorapeople.org/orphans-2019-07-28.txt). I see: (orphaned): javaewah eclipse-sig, galileo, orphan 0 weeks ago ~snip~ Depending on: javaewah (378), status change: 2019-07-23 (0 weeks ago) ~snip~ jgit (maintained by: mbooth) jgit-5.4.0-5.fc31.noarch requires mvn(com.googlecode.javaewah:JavaEWAH) = 1.1.6 jgit-5.4.0-5.fc31.src requires git = 2.22.0-1.fc31, mvn(com.googlecode.javaewah:JavaEWAH) = 1.1.6 ~sip~ git (maintained by: amahdal, besser82, chrisw, pcahyna, pstodulk, skisela, tmz) git-2.22.0-1.fc31.src requires jgit = 5.4.0-5.fc31 Does that answer the question? Perhaps this is an old dependency that has been removed. - Alex > > On Mon, Jul 29, 2019 at 01:02:28PM +0200, Jan Pazdziora wrote: > > On Mon, Jul 29, 2019 at 12:37:33PM +0200, Miro Hron??ok wrote: > > > The following packages are orphaned and will be retired when they > > > are orphaned for six weeks, unless someone adopts them. If you know for > > > sure > > > that the package should be retired, please do so now with a proper > > > reason: > > > https://fedoraproject.org/wiki/How_to_remove_a_package_at_end_of_life > > > > > > Note: If you received this mail directly you (co)maintain one of the > > > affected > > > packages or a package that depends on one. Please adopt the affected > > > package or > > > retire your depending package to avoid broken dependencies, otherwise > > > your > > > package will be retired when the affected package gets retired. > > > > > > See the full report: > > > https://churchyard.fedorapeople.org/orphans-2019-07-28.txt > > > Grep it for your FAS username and follow the dependencies. > > > > > > Request package ownership via https://pagure.io/releng/issues > > > > > > Package (co)maintainers Status > > > Change > > > > > > javaewah eclipse-sig, galileo, orphan 0 > > > weeks ago > > > > [...] > > > > Hello, > > > > I'm a little bit confused. The javaewah is listed above with the four > > comaintainers, but then below it is listed next to many people's > > usernames, including mine: > > > > > The following packages require above mentioned packages: > > > Report too long for e-mail, see: > > > https://churchyard.fedorapeople.org/orphans-2019-07-28.txt > > > Grep it for your FAS username and follow the dependencies. > > > > > > Affected (co)maintainers > > > abbra: javaewah > > > abo: minlog, extra166y, jdo2-api, groovy18, parboiled, http-builder, > > > gmetrics, codenarc, reflectasm, jcsp, jhighlight, aws-sdk-java, json-lib, > > > mysql-connector-java, jatl, pegdown, jcifs, kryo, > > > google-oauth-java-client, > > > native-platform, google-http-java-client > > > abompard: javaewah > > > abrt-team: javaewah > > > acaringi: log4j12, mvel, concurrentlinkedhashmap-lru, minlog, aalto-xml, > > > extra166y, jdo2-api, groovy18, hppc, jmock, metrics, jctools, logback, > > > simple-xml, jmh, parboiled, javaparser, snowball-java, airline, jsonp, > > > reflections, http-builder, compress-lzf, gmavenplus-plugin, lzma-java, > > > glassfish-management-api, glassfish-jax-rs-api, high-scale-lib, > > > glassfish-gmbal, gmetric4j, gmetrics, rxjava, codenarc, disruptor, > > > fastutil, > > > grizzly-npn, jersey1, simple, jersey, jackson-databind, cli-parser, jcsp, > > > reflectasm, replacer, jamm, grizzly, java_cup, mimepull, treelayout, > > > aws-sdk-java, jhighlight, json-lib, mysql-connector-java, jatl, > > > randomizedtesting, pegdown, jcifs, kryo, janino, mustache-java, > > > remotetea, > > > jackson-modules-base, jdbi, rabbitmq-java-client, > > > google-oauth-java-client, > > > native-platform, glassfish-pfl, google-http-java-client, > > > httpcomponents-asyncclient > > > adamwill: javaewah > > > adelton: javaewah > > > > Checking the full report at > > > > https://churchyard.fedorapeople.org/orphans-2019-07-28.txt > > > > it lists > > > > perl-Git-Repository (maintained by: adelton, iarnell) > > perl-Git-Repository-1.323-3.fc31.noarch requires git = > > 2.22.0-1.fc31 > > perl-Git-Repository-1.323-3.fc31.src requires git = > > 2.22.0-1.fc31 > > > > but I don't see git as being orphaned. > > > > Am I reading the report wrong? > > > > -- > > Jan Pazdziora > > Senior Principal Software
Re: Over 500 orphaned packages seeking new maintainers
> Where this fails is where there's duplication of efforts. Take slf4j as an > example. mizdebsk maintains it in one of his various modules (it looks like > the javapackages module). We maintain it in the SIG as an ursine package so > things like Dogtag and a lot of other things don't break. When you go to > install Dogtag though, you never get the SIG version though: you always > get slf4j from the module (which we can't use in the BUILDROOT because its > not exposed through the API). This is a "feature" in DNF: default module > stream branches beat any ursine package, even with a higher NVR. To me, > and probably to mizdebsk as well, that's unfair. Per request for clarification, in this email, "the SIG" should generally refer to the Stewardship SIG which I am a part (hence, "we"). mizdebsk is already a part of the Java SIG, which is a separate SIG with different (and sometimes overlapping) goals. I, and many of the Stewardship SIG members, are not a part of the Java SIG. Roughly (as I see the unofficial divide), the Stewardship SIG tends to pick up packages for a lot of Java libraries and only keeps ursine versions around. Other people (outside of the Stewardship SIG) generally maintain the modular varieties. The Java SIG cares more about modules and big-ticket items like the JDK, Eclipse, and others (build systems, etc), and enabling that stack in modules. You can read more about the packages the Stewardship SIG maintains here: - https://decathorpe.fedorapeople.org/stewardship-sig.html - https://pagure.io/stewardship-sig - https://fedoraproject.org/wiki/SIGs/Stewardship The Java SIG is here: - https://fedoraproject.org/wiki/SIGs/Java - Alex ___ 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: Over 500 orphaned packages seeking new maintainers
- Original Message - > From: "Stephen John Smoogen" > To: "Development discussions related to Fedora" > > Cc: "Dinesh Prasanth Moluguwan Krishnamoorthy" > Sent: Tuesday, July 30, 2019 12:05:59 PM > Subject: Re: Over 500 orphaned packages seeking new maintainers > > On Tue, 30 Jul 2019 at 10:55, Aleksandar Kurtakov > wrote: > > > > > > > On Tue, Jul 30, 2019 at 5:48 PM Alexander Scheel > > wrote: > > > >> > >> > >> - Original Message - > >> > From: "Christopher" > >> > To: "Development discussions related to Fedora" < > >> devel@lists.fedoraproject.org> > >> > Cc: "Fabio Valentini" > >> > Sent: Monday, July 29, 2019 6:14:57 PM > >> > Subject: Re: Over 500 orphaned packages seeking new maintainers > >> > > >> > On Mon, Jul 29, 2019 at 5:36 PM Alexander Scheel > >> wrote: > >> > > > >> > > > Question (not for Fabio specifically, but for the list) modules can > >> have > >> > > > (Build)Requires on other modules > >> > > > right? > >> > > > >> > > Yes, if the module maintainer is willing to expose their module in the > >> > > BUILDROOT. That was PKI's problem: mizdebsk orphaned the ursine > >> packages, > >> > > exposed them in a module available only at runtime, and refused to > >> open > >> > > it up for build-time use. He wanted us to maintain our own versions of > >> > > all of the packages we use that he modularized. > >> > > >> > I don't think "refused" is a fair characterization. My understanding > >> > of the problem is that creating a module is new (and change is hard), > >> > and unnecessary for most basic packages, so long as their BRs are > >> > available. Maintaining many of the java BRs across multiple releases > >> > was becoming burdensome, so mizdebsk decided to take advantage of > >> > modules to reduce their work load. The ideal at that point was to > >> > expose modules to the ursine BUILDROOT, in order for ursine packagers > >> > to have BRs on them without having to themselves be shipped in a > >> > module. Without that, lots of ursine packages were going to suffer, > >> > and that's what happened. Fedora is now extremely hostile to Java > >> > packagers, unless 1) the java packager is willing to take on dozens or > >> > hundreds of packages, or 2) the java packager is willing to learn how > >> > to do all this module stuff. > >> > > >> > I don't think it's fair to say that mizdebsk "refused" to open them up > >> > to build-time use... but perhaps fair to say that they refused to open > >> > them up to build-time use, when that didn't solve the underlying > >> > problem (because they would still only be available to modular > >> > packages, and not to ursine ones, which is what was needed). > >> > >> This actually has nothing to do with modules vs. ursine packages. mizdebsk > >> maintains a very small API on his modules. This limits what other modules > >> can do with it, including in the BUILDROOT. So when our first attempt to > >> save Dogtag was to modularize it (into the now-deprecated pki module), > >> we realized that wouldn't work *because* of that small API. It simply > >> didn't contain what we needed. > >> > >> We reached out to mizdebsk and his stance was that we should bundle all > >> our dependencies (that he modularized) into *our* module, maintaining > >> *separate* streams from his. This is completely unworkable at scale. He > >> didn't want to expand the API. We put our time elsewhere and stayed > >> ursine. > >> > >> I think "refused" is thus a fair categorization. > >> > > > > And you offered him to take ownership, right? I just couldn't stand > > looking how the single guy keeping Java ecosystem working in Fedora for a > > number of years is being *blamed* for not doing exactly what others need > > and I haven't heard of *anyone* actually proposing to take some of his > > load. > > > > > > The issue is that no one has time to take ownership of these packages. The > whole premise around Fedora's package model for the last 15 years is that > the number of packagers and the number
Re: Over 500 orphaned packages seeking new maintainers
- Original Message - > From: "Christopher" > To: "Development discussions related to Fedora" > > Cc: "Fabio Valentini" > Sent: Monday, July 29, 2019 6:14:57 PM > Subject: Re: Over 500 orphaned packages seeking new maintainers > > On Mon, Jul 29, 2019 at 5:36 PM Alexander Scheel wrote: > > > > > Question (not for Fabio specifically, but for the list) modules can have > > > (Build)Requires on other modules > > > right? > > > > Yes, if the module maintainer is willing to expose their module in the > > BUILDROOT. That was PKI's problem: mizdebsk orphaned the ursine packages, > > exposed them in a module available only at runtime, and refused to open > > it up for build-time use. He wanted us to maintain our own versions of > > all of the packages we use that he modularized. > > I don't think "refused" is a fair characterization. My understanding > of the problem is that creating a module is new (and change is hard), > and unnecessary for most basic packages, so long as their BRs are > available. Maintaining many of the java BRs across multiple releases > was becoming burdensome, so mizdebsk decided to take advantage of > modules to reduce their work load. The ideal at that point was to > expose modules to the ursine BUILDROOT, in order for ursine packagers > to have BRs on them without having to themselves be shipped in a > module. Without that, lots of ursine packages were going to suffer, > and that's what happened. Fedora is now extremely hostile to Java > packagers, unless 1) the java packager is willing to take on dozens or > hundreds of packages, or 2) the java packager is willing to learn how > to do all this module stuff. > > I don't think it's fair to say that mizdebsk "refused" to open them up > to build-time use... but perhaps fair to say that they refused to open > them up to build-time use, when that didn't solve the underlying > problem (because they would still only be available to modular > packages, and not to ursine ones, which is what was needed). This actually has nothing to do with modules vs. ursine packages. mizdebsk maintains a very small API on his modules. This limits what other modules can do with it, including in the BUILDROOT. So when our first attempt to save Dogtag was to modularize it (into the now-deprecated pki module), we realized that wouldn't work *because* of that small API. It simply didn't contain what we needed. We reached out to mizdebsk and his stance was that we should bundle all our dependencies (that he modularized) into *our* module, maintaining *separate* streams from his. This is completely unworkable at scale. He didn't want to expand the API. We put our time elsewhere and stayed ursine. I think "refused" is thus a fair categorization. > At least, that's my understanding of the situation. > > FWIW, I'm probably going to orphan the last of my Java packages, too, > because I don't have time to figure out how to create a bunch of > modules just so I can get the BRs I need. My time would be better > spent building ursine packages in COPR, outside of Fedora's modularity > efforts. I've been watching keenly, to see if the situation will > change, and Fedora will become Java-friendly again, but I don't see > that happening, sadly. Right, and perhaps you'll get lucky and your modules will work because your BRs are exposed in the API of modules. But until then, the SIG is picking up hundreds of packages just to keep the entire ecosystem alive and to help out those maintainers who don't have time or don't want to modularize. > ___ > 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: Over 500 orphaned packages seeking new maintainers
> The reason I'm confused is because AFAIK last time jpackage-utils / > javapackages-tools also was part of the set of > packages causingproblems and javapackages-tools was picked up by the > Stewardship SIG (or so I believe) so I'm > surprised to see it go away again now. One of the SIG's 3 reviewers here... I appreciate all the work Fabio and Miro do (and am looking at making more time to help out on the opening-PR front as well). rpms/javapackages-tools (the RPM) was never maintained by us. mizdebsk only just recently orphaned it. I think what you're thinking of is modules/javapackages-tools (the module form, which contained other packages). We picked up a lot of packages shipped in said module (which wasn't made available in either the ursine or modular buildroots) and maintained them in their ursine form. One very prominent example is a portion of the apache-commons-* packages. See [0] and [1] for a complete list of the overlap. [0]: https://decathorpe.fedorapeople.org/stewardship-sig.html [1]: https://src.fedoraproject.org/modules/javapackages-tools/blob/201901/f/javapackages-tools.yaml > Anyways I maintain 2 games and a few of their deps in Fedora which rely on > java, I guess it might be time to > create a java-games module and move things there. Please don't randomly modularize things unless you have a great reason for doing so. Please check with any dependencies you have may have to see if they're invested in modularizing their packages as well. Consider the community beyond just your packages. > Question (not for Fabio specifically, but for the list) modules can have > (Build)Requires on other modules > right? Yes, if the module maintainer is willing to expose their module in the BUILDROOT. That was PKI's problem: mizdebsk orphaned the ursine packages, exposed them in a module available only at runtime, and refused to open it up for build-time use. He wanted us to maintain our own versions of all of the packages we use that he modularized. We chose to contribute what additional maintenance time we have to the SIG, where more than just us can benefit from them. We did not modularize PKI (in Fedora). > > Regards, > > Hans > ___ > 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
