[389-devel] 389 DS nightly 2021-05-15 - 95% PASS
https://fedorapeople.org/groups/389ds/ci/nightly/2021/05/15/report-389-ds-base-2.0.4-20210515git2a12316b7.fc34.x86_64.html ___ 389-devel mailing list -- 389-devel@lists.fedoraproject.org To unsubscribe send an email to 389-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/389-devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Bodhi critpath package updates now gated on openQA results
On Fri, 2021-05-14 at 18:20 -0500, Michael Catanzaro wrote: > On Fri, May 14 2021 at 02:17:13 PM -0700, Adam Williamson > wrote: > > I don't know about emails, but the UI isn't indicating a failure, it's > > indicating a missing result. This *is* what it shows if you read it > > carefully. It doesn't say a test failed. > > That's incorrect, see e.g.: > > https://bodhi.fedoraproject.org/updates/FEDORA-2021-72b0305521 > > The gating status changed to failed, then to waiting, then back to > failed, then to passed. And yes, each status change triggers an email. Well, yes, the *gating status* is indeed failed when the tests are not yet run. We've been around this rodeo a few times; nothing else is really possible without something like a test status equivalent to resultsdb, an execdb. But that doesn't exist. I'm not sure why the change to 'waiting' then back to 'failed'. That part looks odd and might be something we could work on. But it's kinda expected at present that the status would go to failed at first and then passed once the test results appear. We could possibly do something kludgey in Bodhi to make it not send out emails for gating status changes right at the time of submission, or something. -- Adam Williamson Fedora QA IRC: adamw | Twitter: adamw_ha https://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 Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
feature request: gnome-shell-extension-panel-date-format.rpm package
the panel-date-format gnome shell extension is very useful and popular. why not make it a standard rpm available in the repository please? ___ 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: Bodhi critpath package updates now gated on openQA results
On Fri, May 14 2021 at 02:17:13 PM -0700, Adam Williamson wrote: I don't know about emails, but the UI isn't indicating a failure, it's indicating a missing result. This *is* what it shows if you read it carefully. It doesn't say a test failed. That's incorrect, see e.g.: https://bodhi.fedoraproject.org/updates/FEDORA-2021-72b0305521 The gating status changed to failed, then to waiting, then back to failed, then to passed. And yes, each status change triggers an email. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
[Test-Announce] Proposal to CANCEL: 2021-05-17 Fedora QA Meeting
Hi folks! I'm proposing we cancel the QA meeting on Monday. I don't have anything urgent on the agenda, so let's take a break. If you're aware of anything important we have to discuss this week, please do reply to this mail and we can go ahead and run the meeting. Thanks! -- Adam Williamson Fedora QA IRC: adamw | Twitter: adamw_ha https://www.happyassassin.net ___ test-announce mailing list -- test-annou...@lists.fedoraproject.org To unsubscribe send an email to test-announce-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/test-annou...@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Bodhi critpath package updates now gated on openQA results
On Fri, 2021-05-14 at 14:40 -0500, Michael Catanzaro wrote: > So this seems like a good idea, but I notice that all tests are marked > as failed until the results arrive. This leads to incorrect failure > emails and incorrect UI indicating lots of test failures where none > exist. Doesn't seem ready for production yet. I don't know about emails, but the UI isn't indicating a failure, it's indicating a missing result. This *is* what it shows if you read it carefully. It doesn't say a test failed. If emails are getting sent out in this situation we should probably fix that, but I don't think you can do much about it in Bodhi UI besides possibly tweak the representation to be a bit clearer about the difference between a failed test and a missing result. The fact that a result is missing is significant information and is the reason the test cannot be gated; it needs to be communicated. This part isn't any different from existing gating on Fedora CI tests, AFAIK (although those may run faster and so the state exists for less time). -- Adam Williamson Fedora QA IRC: adamw | Twitter: adamw_ha https://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 Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: f34 - llvm12 update
On 5/14/21 5:55 AM, Fabio Valentini wrote: > Would it be possible to rebuild and include rust as well? It is > already built against LLVM 12 in rawhide, and building it against LLVM > 12 instead of the LLVM 11 compat package fixes a few code generation > issues and crashes that have been hitting Fedora Rust packages. > jistone might have more details ... I have started the rust rebuild in the side tag: https://koji.fedoraproject.org/koji/taskinfo?taskID=67922508 ___ 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: Bodhi critpath package updates now gated on openQA results
So this seems like a good idea, but I notice that all tests are marked as failed until the results arrive. This leads to incorrect failure emails and incorrect UI indicating lots of test failures where none exist. Doesn't seem ready for production yet. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
[Bug 1960398] Upgrade perl-V to 0.15
https://bugzilla.redhat.com/show_bug.cgi?id=1960398 Fedora Update System changed: What|Removed |Added Status|MODIFIED|ON_QA --- Comment #2 from Fedora Update System --- FEDORA-2021-5dbf99ea4b has been pushed to the Fedora 34 testing repository. Soon you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --advisory=FEDORA-2021-5dbf99ea4b` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2021-5dbf99ea4b See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates. -- You are receiving this mail because: You are on the CC list for the bug. ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: [ELN] Creating a process for ELN-specific changes
On Fri, May 14, 2021 at 06:38:33PM +0200, Miro Hrončok wrote: > I wouldn't say so. I'd say "package both versions as separate > non-modular RPM packages with unique names" is the general answer > when different versions of the package are desired. > > However, the problem here is different. We don't want 2 different > versions packaged in Rawhide AND 2 different versions packaged in > ELN. We want to allow package versions in ELN and Rawhide to be > different. This is exactly a case that modularity is supposed to handle. Two different versions packaged only one time each, built for both targets automatically, with one the default on target A and the other the default on target B, output, but with either version selectable in either target. -- Matthew Miller Fedora Project Leader ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: [ELN] Creating a process for ELN-specific changes
On Fri, May 14, 2021 at 1:01 PM Miro Hrončok wrote: > > On 14. 05. 21 16:29, Stephen Gallagher wrote: > > * Fedora wants to use the latest version of an upstream, but ELN wants > > to stay on LTS releases (e.g. Firefox) > > About this use case: > > Is ELN still consumed as an "add-on repo" for Rawhide, or that is no > longer true? Becasue if it is still the case, this might not work properly. > That's a really good question that I don't have a solid answer to at the moment. I'm not sure it would *ultimately* be a major issue, as it's less likely for ELN to have *newer* packages than Rawhide does (and if they're older, DNF will basically ignore them unless specifically requested). I'd like us to get to a point where ELN is consistently installable, even if that's not an "official" goal. ___ 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: [ELN] Creating a process for ELN-specific changes
On Fri, May 14, 2021 at 12:54 PM Miro Hrončok wrote: ... > > Of course, this time around we were also rushing to get the > > infrastructure in place for CentOS Stream 9, which will already be > > available for EL 10... so maybe the answer here is to just go directly > > from ELN into CentOS Stream 10 at the Fedora 40 Branch point? It means > > a bit more manual syncing from Fedora during that time period, but > > that might not be too painful. > > If the manual sync is easy (no bugzillas flags required), I would say > that is the way to go. It eliminates one extra "why is the workflow > changing every week" moment. It also no longer encourages the RHEL > maintains to push their changes to Fedora branched in the same time > windows when we try to stabilize it. > Yeah, I was becoming more confident in that idea the longer I typed. I think that is probably what we will end up doing. ... > > I think we can make the policy super-simple: every package on ELN gets > > forcibly re-synced to Rawhide on the day we fork to CentOS Stream. > > Each new major release reset, we require them to request to diverge > > the sync again. > > That sounds really harsh towards the maintainers who actually do keep > the eln branch up to date all the time. We would wipe their changes > every 3 years, and they would need to reintroduce them again. Oh, I didn't mean we would clobber the `eln` branch, we'd just flip the switch to re-enable Rawhide builds (with a loud announcement). We'd accept requests at that time to *not* flip the switch for their project, or they could do so at any time afterwards. This would leave the `eln` branch exactly as it was; and if they request not to sync, they can resume from there. I view this as an easy way to do two things at once: 1) See who is still actively maintaining their project for ELN and reset it if they aren't. 2) Make it a no-op for anyone who wants to jump back on the Rawhide train (even if only for some number of months until they freeze it again). > >> 3) Similarly, assume foo has opted in for an eln branch. The Fedora > >> packager maintainer walks away and foo is adapted by another maintainer > >> who wants to maintain %if-spaghetti rather than 2 distinct branches. How > >> do they opt out? Do we "archive" the eln branch until it is requested > >> again? Or do we merge rawhide and eln branches, sot hey have the same > >> HEAD and than turn eln into a symbolic reference? > >> > > > > I think archiving the ELN branch is probably the simplest approach > > here. All we need to do is flip the auto-rebuild configuration back > > over to stop excluding the package and the next Rawhide build will > > trigger an ELN build again. > > However, when looking at the package source, it should be really obvious > that the eln branch is no longer used for ELN. Otherwise it will be very > confusing for people who want to contribute. True... maybe we dead.package the `eln` branch if they don't request to retain it ahead of time. They can always do a git revert to bring it back to life later. ___ 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: [ELN] Creating a process for ELN-specific changes
On 14. 05. 21 16:29, Stephen Gallagher wrote: * Fedora wants to use the latest version of an upstream, but ELN wants to stay on LTS releases (e.g. Firefox) About this use case: Is ELN still consumed as an "add-on repo" for Rawhide, or that is no longer true? Becasue if it is still the case, this might not work properly. -- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: [ELN] Creating a process for ELN-specific changes
On 14. 05. 21 17:20, Stephen Gallagher wrote: On Fri, May 14, 2021 at 11:05 AM Miro Hrončok wrote: ... First of all: Thanks. This is what many of us wanted from the beginning of ELN and this will allow us to crop many of our unwanted dependencies for RHEL 10+, already in ELN. An automation that cherry-picks (rather than merges) Rawhide changes into ELN would be even more helpful. In Python Maint, we have some semi-automatic tools ready; let me know in case you want to explore them. If you've already got tools that can help with this, I'm all ears! We use this to cherry pick commits or entire pull requests from arbitrary components on src.fp.o to other branches/components/dist-gits: https://github.com/fedora-python/ferrypick/blob/master/ferrypick.py This (highly experimental) script can be used to create various backport branches needed to create PRs (it is a wrapper around the script above): https://github.com/fedora-python/branchsync This merge driver can possibly help cherry-pick/merge commits that would otherwise fail due to to %chaneglog problems: https://github.com/encukou/rpm-spec-merge-driver I however do have several concerns to discuss: 1) During the RHEL 9 development cycle, the process was more or less: ELN -> Fedora 34 -> CentOS Stream 9 Do we assume similar concept for RHEL 10? I.e.: ELN -> Fedora 40-ish -> CentOS Stream 10 If so, every change we make in ELN will be de-facto overridden by the sync from Fedora branched and hence making changes in the ELN branch will not help our RHEL-related work much. Or am I missing something? Hmm, that is indeed an interesting question. I don't want to give an off-the-cuff answer (it deserves more thought), but we *will* need to address this. The time period in question (when Rawhide and the Fedora we intend to branch from has diverged) is complicated. This time around, we let ELN stay with Rawhide and used F34 as source for the sync to EL9 until F34 Final Freeze, but indeed if some packages are going to be tracked independently via an ELN branch, that gets... trickier. Of course, this time around we were also rushing to get the infrastructure in place for CentOS Stream 9, which will already be available for EL 10... so maybe the answer here is to just go directly from ELN into CentOS Stream 10 at the Fedora 40 Branch point? It means a bit more manual syncing from Fedora during that time period, but that might not be too painful. If the manual sync is easy (no bugzillas flags required), I would say that is the way to go. It eliminates one extra "why is the workflow changing every week" moment. It also no longer encourages the RHEL maintains to push their changes to Fedora branched in the same time windows when we try to stabilize it. We have a couple years to think this through; thanks for bringing it up. I agree that we don't need to to necessarily solve this right now. 2) Who opts in for the eln branch and who is responsible for keeping it up to date? For cases where the Fedora and RHEL maintainers are the same people, it is obviously them. But what about other cases? E.g.: 1. Fedora maintainer of package foo refuses RHEL-only changes. 2. RHEL maintainer of foo requests an eln branch. 3. Fedora maintainer frequently updates foo in Rawhide. 4. RHEL maintainer does not care about foo in Fedora for 2 years. 5. The package in ELN is much older than the Rawhide one. I think this could be solved by policy. Something like "If the eln branch is neglected (needs to be well defined), the package switches back to the rawhide branch." I think we can make the policy super-simple: every package on ELN gets forcibly re-synced to Rawhide on the day we fork to CentOS Stream. Each new major release reset, we require them to request to diverge the sync again. That sounds really harsh towards the maintainers who actually do keep the eln branch up to date all the time. We would wipe their changes every 3 years, and they would need to reintroduce them again. 3) Similarly, assume foo has opted in for an eln branch. The Fedora packager maintainer walks away and foo is adapted by another maintainer who wants to maintain %if-spaghetti rather than 2 distinct branches. How do they opt out? Do we "archive" the eln branch until it is requested again? Or do we merge rawhide and eln branches, sot hey have the same HEAD and than turn eln into a symbolic reference? I think archiving the ELN branch is probably the simplest approach here. All we need to do is flip the auto-rebuild configuration back over to stop excluding the package and the next Rawhide build will trigger an ELN build again. However, when looking at the package source, it should be really obvious that the eln branch is no longer used for ELN. Otherwise it will be very confusing for people who want to contribute. -- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok ___ devel mailing
Vagrant update in testing on F34.
Hello all, Vagrant is to be updated in F34, to be more compatible with Ruby 3.0. Please give it a go: https://bodhi.fedoraproject.org/updates/FEDORA-2021-17ded5c4ca Thanks! -- Pavel Valena Software Engineer, Red Hat Brno, Czech Republic ___ 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: Non-responsive maintainer: jdulaney
On 14.05.2021 16:14, Jake Hunsaker wrote: I can reach out to her, which package is this for? https://src.fedoraproject.org/rpms/python-networkmanager https://src.fedoraproject.org/rpms/python-networkmanager/pull-request/2 need to be merged and built for F33-Rawhide. It fixes major issues with modern Network Manager versions. -- Sincerely, Vitaly Zaitsev (vit...@easycoding.org) ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: [ELN] Creating a process for ELN-specific changes
On Fri, 14 May 2021 at 12:28, Stephen Gallagher wrote: > On Fri, May 14, 2021 at 12:01 PM Neal Gompa wrote: > > > > On Fri, May 14, 2021 at 11:14 AM Matthew Miller > > wrote: > > > > > > On Fri, May 14, 2021 at 10:29:11AM -0400, Stephen Gallagher wrote: > > > > * Fedora wants to use the latest version of an upstream, but ELN > wants > > > > to stay on LTS releases (e.g. Firefox) > > > > > > Can we provide these things as modules and make them available in both? > > > Firefox LTS seems like an ideal candidate, and I can see someone on > Fedora > > > Linux wanting the option and if the ELN folks are maintaining a package > > > _anyway_ > > > > > > > Firefox ESR can be packaged separately anyway as a "firefox-esr" > package... > > > > Please don't fixate on the use of Firefox as the example. > That is like saying 'dont think about polar bears' to most humans. I will morph his comment can be packaged separately anyway as . or to use Matt's version: could be packaged separately anyway as . The issue with this suggestion is: == Who is going to do that work? == > ___ > 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 > -- Stephen J Smoogen. I've seen things you people wouldn't believe. Flame wars in sci.astro.orion. I have seen SPAM filters overload because of Godwin's Law. All those moments will be lost in time... like posts on BBS... time to reboot. ___ 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: Bodhi critpath package updates now gated on openQA results
On Fri, 2021-05-14 at 16:28 +, Mattia Verga via devel wrote: > I've just realized that this currently doesn't work: Rawhide updates still > aren't marked as critpath. > > See https://github.com/fedora-infra/bodhi/issues/4177#issuecomment-841350366 Oh, that's fine. This is only for stable and Branched anyway. openQA does not test Rawhide updates at present, though that's something I want to work towards this year. -- Adam Williamson Fedora QA IRC: adamw | Twitter: adamw_ha https://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 Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: [ELN] Creating a process for ELN-specific changes
On 14. 05. 21 17:25, Matthew Miller wrote: On Fri, May 14, 2021 at 11:21:26AM -0400, Stephen Gallagher wrote: Can we provide these things as modules and make them available in both? Firefox LTS seems like an ideal candidate, and I can see someone on Fedora Linux wanting the option and if the ELN folks are maintaining a package _anyway_ That's going to be up to the individual maintainers; I don't want to sidetrack the ELN discussion too much. OK, so let me generalize: isn't "make it a module" the general answer when different versions of the package are desired? I wouldn't say so. I'd say "package both versions as separate non-modular RPM packages with unique names" is the general answer when different versions of the package are desired. However, the problem here is different. We don't want 2 different versions packaged in Rawhide AND 2 different versions packaged in ELN. We want to allow package versions in ELN and Rawhide to be different. -- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Bodhi critpath package updates now gated on openQA results
I've just realized that this currently doesn't work: Rawhide updates still aren't marked as critpath. See https://github.com/fedora-infra/bodhi/issues/4177#issuecomment-841350366 ___ 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: Bodhi critpath package updates now gated on openQA results
On Thu, 2021-05-13 at 23:47 -0700, Adam Williamson wrote: > On Fri, 2021-05-14 at 06:06 +0200, Michal Srb wrote: > > > > I thought, under the hood, the button is just telling Bodhi to send the > > "bodhi.update.status.testing.koji-build-group.build.complete" [1] message > > again, so all CI systems listening should trigger? This isn't the case for > > openQA? > > > > Thanks, > > Michal > > > > [1]: > > https://apps.fedoraproject.org/datagrepper/raw?topic=org.fedoraproject.prod.bodhi.update.status.testing.koji-build-group.build.complete=18000 > > Ah, I didn't remember precisely what it does :D > > openQA doesn't currently trigger off that message, for the fairly > simple reason that it didn't exist when I wrote the openQA update > triggering stuff. It triggers off Bodhi "update submitted to testing" > and "update edited" messages. > > I can take a look at whether I can adjust it to use that message as > well/instead, I'll have to make a bit of time for it tomorrow. Well, I looked into it a bit, and... https://github.com/fedora-infra/bodhi/issues/4217 is where I'm at. I kind of don't want to change the openQA tests to always trigger on koji-build-group.build.complete , for a specific reason: it's sent when the update is pushed to updates-testing. This gets done in batches. So if I use that message at the trigger, openQA will sit there idle most of the time, then when an updates-testing push happens, it will try and test a *lot* of updates, all at once. It only has limited worker capacity, so some will wind up sitting in a queue for maybe several hours. The openQA tests do not retrieve the packages from updates-testing - they pull them directly from Koji - so they don't need to wait for them to be in updates-testing. So things work quite nicely now, where we schedule the openQA tests whenever a maintainer pushes the button to submit the update or edit it; this way we don't get sudden batches of multiple updates to test at once, usually, and the work is spread out over time. So ideally I would like to adjust the triggering to only trigger tests on that koji-build-group.build.complete message *when it is marked as being a re-trigger request*. But I can't really do that, because...well...that bug. -- Adam Williamson Fedora QA IRC: adamw | Twitter: adamw_ha https://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 Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: [ELN] Creating a process for ELN-specific changes
On Fri, May 14, 2021 at 12:01 PM Neal Gompa wrote: > > On Fri, May 14, 2021 at 11:14 AM Matthew Miller > wrote: > > > > On Fri, May 14, 2021 at 10:29:11AM -0400, Stephen Gallagher wrote: > > > * Fedora wants to use the latest version of an upstream, but ELN wants > > > to stay on LTS releases (e.g. Firefox) > > > > Can we provide these things as modules and make them available in both? > > Firefox LTS seems like an ideal candidate, and I can see someone on Fedora > > Linux wanting the option and if the ELN folks are maintaining a package > > _anyway_ > > > > Firefox ESR can be packaged separately anyway as a "firefox-esr" package... > Please don't fixate on the use of Firefox as the example. ___ 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
FedoraRespin-34-updates-20210514.0 compose check report
No missing expected images. Failed openQA tests: 3/40 (x86_64) ID: 887428 Test: x86_64 KDE-live-iso desktop_notifications_live URL: https://openqa.fedoraproject.org/tests/887428 ID: 887435 Test: x86_64 KDE-live-iso desktop_login URL: https://openqa.fedoraproject.org/tests/887435 ID: 887444 Test: x86_64 KDE-live-iso apps_startstop URL: https://openqa.fedoraproject.org/tests/887444 Passed openQA tests: 37/40 (x86_64) -- Mail generated by check-compose: https://pagure.io/fedora-qa/check-compose ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: [ELN] Creating a process for ELN-specific changes
On Fri, May 14, 2021 at 11:14 AM Matthew Miller wrote: > > On Fri, May 14, 2021 at 10:29:11AM -0400, Stephen Gallagher wrote: > > * Fedora wants to use the latest version of an upstream, but ELN wants > > to stay on LTS releases (e.g. Firefox) > > Can we provide these things as modules and make them available in both? > Firefox LTS seems like an ideal candidate, and I can see someone on Fedora > Linux wanting the option and if the ELN folks are maintaining a package > _anyway_ > Firefox ESR can be packaged separately anyway as a "firefox-esr" package... -- 真実はいつも一つ！/ Always, there's only one truth! ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: [ELN] Creating a process for ELN-specific changes
On Fri, 14 May 2021 at 11:25, Matthew Miller wrote: > On Fri, May 14, 2021 at 11:21:26AM -0400, Stephen Gallagher wrote: > > > Can we provide these things as modules and make them available in both? > > > Firefox LTS seems like an ideal candidate, and I can see someone on > Fedora > > > Linux wanting the option and if the ELN folks are maintaining a package > > > _anyway_ > > That's going to be up to the individual maintainers; I don't want to > > sidetrack the ELN discussion too much. > > OK, so let me generalize: isn't "make it a module" the general answer when > different versions of the package are desired? > > > I don't know. The maintainer has to want to make it a module and most maintainers are still waiting for time, energy and the equivalent of 'hand over hand' training materials to know how to make them without breaking their existing workflows (or to learn new ones). [The fact that from many conversations, a number of core maintainers do not even use mock to build their packages locally says that we are needing to start training at a much lower level than 'here is how to make a module'.] -- Stephen J Smoogen. I've seen things you people wouldn't believe. Flame wars in sci.astro.orion. I have seen SPAM filters overload because of Godwin's Law. All those moments will be lost in time... like posts on BBS... time to reboot. ___ 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: [ELN] Creating a process for ELN-specific changes
On Fri, May 14, 2021 at 11:25 AM Matthew Miller wrote: > > On Fri, May 14, 2021 at 11:21:26AM -0400, Stephen Gallagher wrote: > > > Can we provide these things as modules and make them available in both? > > > Firefox LTS seems like an ideal candidate, and I can see someone on Fedora > > > Linux wanting the option and if the ELN folks are maintaining a package > > > _anyway_ > > That's going to be up to the individual maintainers; I don't want to > > sidetrack the ELN discussion too much. > > OK, so let me generalize: isn't "make it a module" the general answer when > different versions of the package are desired? ELN's purpose is to be a staging ground for the next major release of enterprise linux. If this is a package that is intended to be in the non-modular set for EL N+1, then it needs to be non-modular in ELN (so we can calculate the dependencies properly). If it is intended to be a module in EL N+1, then ideally it should be a module in ELN (if we can figure out how to get that to work properly; there are technical issues there that make modules built for Fedora not directly importable to CentOS Stream/RHEL). ___ 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: [ELN] Creating a process for ELN-specific changes
On Fri, May 14, 2021 at 11:18 AM Miro Hrončok wrote: > > On 14. 05. 21 16:58, Stephen Gallagher wrote: > > Oh, I absolutely understand that this will lead to dependency > > trimming. However, such things are*also* possible via > > conditionalizing the Rawhide specfile (which remains the recommended > > approach, because it means you don't have to maintain a separate > > branch). > > To be fair, I don't think the reasoning here for why this remains the > recommended approach is sound. Compere your statement with: > > """Conditionalizing the Rawhide specfile can be used for dependency > trimming. However, such things are *also* possible via maintaining a > separate branch (which remains the recommended approach, because it > means you don't have conditionale the Rawhide specfile).""" > > Technically, when presented with two mutually exclusive options A and B, > saying "A is a better option, because it avoids option B" does not feel > like a fair argument. Acknowledged; I was unclear on my statement. I said "you don't have to maintain a separate branch" as shorthand for saying "you don't have to remember to keep another branch up to date, perform separate builds on it, etc.". That's still the recommended approach from my perspective, because it means less risk of bitrot which will fall on the SIG to repair. ___ 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: [ELN] Creating a process for ELN-specific changes
On Fri, May 14, 2021 at 11:21:26AM -0400, Stephen Gallagher wrote: > > Can we provide these things as modules and make them available in both? > > Firefox LTS seems like an ideal candidate, and I can see someone on Fedora > > Linux wanting the option and if the ELN folks are maintaining a package > > _anyway_ > That's going to be up to the individual maintainers; I don't want to > sidetrack the ELN discussion too much. OK, so let me generalize: isn't "make it a module" the general answer when different versions of the package are desired? -- Matthew Miller Fedora Project Leader ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: [ELN] Creating a process for ELN-specific changes
On Fri, May 14, 2021 at 11:16 AM Matthew Miller wrote: > > On Fri, May 14, 2021 at 10:29:11AM -0400, Stephen Gallagher wrote: > > * Fedora wants to use the latest version of an upstream, but ELN wants > > to stay on LTS releases (e.g. Firefox) > > Can we provide these things as modules and make them available in both? > Firefox LTS seems like an ideal candidate, and I can see someone on Fedora > Linux wanting the option and if the ELN folks are maintaining a package > _anyway_ > That's going to be up to the individual maintainers; I don't want to sidetrack the ELN discussion too much. ___ 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: [ELN] Creating a process for ELN-specific changes
On Fri, May 14, 2021 at 11:05 AM Miro Hrončok wrote: ... > First of all: Thanks. This is what many of us wanted from the beginning > of ELN and this will allow us to crop many of our unwanted dependencies > for RHEL 10+, already in ELN. > > An automation that cherry-picks (rather than merges) Rawhide changes > into ELN would be even more helpful. In Python Maint, we have some > semi-automatic tools ready; let me know in case you want to explore them. If you've already got tools that can help with this, I'm all ears! > > I however do have several concerns to discuss: > > > 1) During the RHEL 9 development cycle, the process was more or less: > > ELN -> Fedora 34 -> CentOS Stream 9 > > Do we assume similar concept for RHEL 10? I.e.: > > ELN -> Fedora 40-ish -> CentOS Stream 10 > > If so, every change we make in ELN will be de-facto overridden by the > sync from Fedora branched and hence making changes in the ELN branch > will not help our RHEL-related work much. Or am I missing something? Hmm, that is indeed an interesting question. I don't want to give an off-the-cuff answer (it deserves more thought), but we *will* need to address this. The time period in question (when Rawhide and the Fedora we intend to branch from has diverged) is complicated. This time around, we let ELN stay with Rawhide and used F34 as source for the sync to EL9 until F34 Final Freeze, but indeed if some packages are going to be tracked independently via an ELN branch, that gets... trickier. Of course, this time around we were also rushing to get the infrastructure in place for CentOS Stream 9, which will already be available for EL 10... so maybe the answer here is to just go directly from ELN into CentOS Stream 10 at the Fedora 40 Branch point? It means a bit more manual syncing from Fedora during that time period, but that might not be too painful. We have a couple years to think this through; thanks for bringing it up. > > 2) Who opts in for the eln branch and who is responsible for keeping it > up to date? For cases where the Fedora and RHEL maintainers are the same > people, it is obviously them. But what about other cases? E.g.: > > 1. Fedora maintainer of package foo refuses RHEL-only changes. > 2. RHEL maintainer of foo requests an eln branch. > 3. Fedora maintainer frequently updates foo in Rawhide. > 4. RHEL maintainer does not care about foo in Fedora for 2 years. > 5. The package in ELN is much older than the Rawhide one. > > I think this could be solved by policy. Something like "If the eln > branch is neglected (needs to be well defined), the package switches > back to the rawhide branch." I think we can make the policy super-simple: every package on ELN gets forcibly re-synced to Rawhide on the day we fork to CentOS Stream. Each new major release reset, we require them to request to diverge the sync again. > > 3) Similarly, assume foo has opted in for an eln branch. The Fedora > packager maintainer walks away and foo is adapted by another maintainer > who wants to maintain %if-spaghetti rather than 2 distinct branches. How > do they opt out? Do we "archive" the eln branch until it is requested > again? Or do we merge rawhide and eln branches, sot hey have the same > HEAD and than turn eln into a symbolic reference? > I think archiving the ELN branch is probably the simplest approach here. All we need to do is flip the auto-rebuild configuration back over to stop excluding the package and the next Rawhide build will trigger an ELN build again. ___ 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: [ELN] Creating a process for ELN-specific changes
On 14. 05. 21 16:58, Stephen Gallagher wrote: Oh, I absolutely understand that this will lead to dependency trimming. However, such things are*also* possible via conditionalizing the Rawhide specfile (which remains the recommended approach, because it means you don't have to maintain a separate branch). To be fair, I don't think the reasoning here for why this remains the recommended approach is sound. Compere your statement with: """Conditionalizing the Rawhide specfile can be used for dependency trimming. However, such things are *also* possible via maintaining a separate branch (which remains the recommended approach, because it means you don't have conditionale the Rawhide specfile).""" Technically, when presented with two mutually exclusive options A and B, saying "A is a better option, because it avoids option B" does not feel like a fair argument. Disclaimer: I am not writing this email to discuss once again whether %ifs or branches are better (we disagree on that one and we both know it) nor to discuss which option should be the recommended one (I think we cannot have that discussion before we see eln branches working). I just wanted to point out the problem in the statement. -- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: [ELN] Creating a process for ELN-specific changes
On Fri, May 14, 2021 at 10:29:11AM -0400, Stephen Gallagher wrote: > * Fedora wants to use the latest version of an upstream, but ELN wants > to stay on LTS releases (e.g. Firefox) Can we provide these things as modules and make them available in both? Firefox LTS seems like an ideal candidate, and I can see someone on Fedora Linux wanting the option and if the ELN folks are maintaining a package _anyway_ -- Matthew Miller Fedora Project Leader ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: [ELN] Creating a process for ELN-specific changes
On 14. 05. 21 16:29, Stephen Gallagher wrote:
In nearly all cases, we want the `rawhide` branch in dist-git to
provide the sources used to build packages for ELN. This ensures that
they are kept up to date and minimizes packager effort (since they do
not have to maintain an extra branch).
However, there are some cases where changes desired for ELN (and by
extension, enterprise linux) cannot go into Rawhide. A non-exhaustive
list:
* ELN wants to build without documentation, experimental features or
similar and the maintainer refuses to include `%{rhel}` conditionals
in the spec
* Fedora wants to use the latest version of an upstream, but ELN wants
to stay on LTS releases (e.g. Firefox)
* A package is retired in Rawhide but is needed as a dependency for a
package in ELN (usually as a result of the previous example)
* A package exists solely for use in ELN (e.g. lorax-templates-rhel)
I'm sure there are other good examples, but these are what I could
come up with off the top of my head. If you have other use-cases that
we need to consider, please suggest them.
Maintaining a separate branch for ELN requires us to do the following things:
* Create an `eln` branch for the package
* Exclude the package from the Rawhide auto-rebuild
Maintaining an extra branch is more work for the packager, so it
should be avoided whenever possible. Our goal with ELN is to maximize
the value we provide to enterprise linux while minimizing the
additional load that we put on maintainers.
We may also look into the possibility of extending the auto-rebuilder
to attempt a merge-and-scratch-build from Rawhide to the ELN branch,
to reduce maintainer effort if they opt to maintain their package in
the ELN branch manually.
This is tracked in the ELN SIG as https://github.com/fedora-eln/eln/issues/56
First of all: Thanks. This is what many of us wanted from the beginning
of ELN and this will allow us to crop many of our unwanted dependencies
for RHEL 10+, already in ELN.
An automation that cherry-picks (rather than merges) Rawhide changes
into ELN would be even more helpful. In Python Maint, we have some
semi-automatic tools ready; let me know in case you want to explore them.
I however do have several concerns to discuss:
1) During the RHEL 9 development cycle, the process was more or less:
ELN -> Fedora 34 -> CentOS Stream 9
Do we assume similar concept for RHEL 10? I.e.:
ELN -> Fedora 40-ish -> CentOS Stream 10
If so, every change we make in ELN will be de-facto overridden by the
sync from Fedora branched and hence making changes in the ELN branch
will not help our RHEL-related work much. Or am I missing something?
2) Who opts in for the eln branch and who is responsible for keeping it
up to date? For cases where the Fedora and RHEL maintainers are the same
people, it is obviously them. But what about other cases? E.g.:
1. Fedora maintainer of package foo refuses RHEL-only changes.
2. RHEL maintainer of foo requests an eln branch.
3. Fedora maintainer frequently updates foo in Rawhide.
4. RHEL maintainer does not care about foo in Fedora for 2 years.
5. The package in ELN is much older than the Rawhide one.
I think this could be solved by policy. Something like "If the eln
branch is neglected (needs to be well defined), the package switches
back to the rawhide branch."
3) Similarly, assume foo has opted in for an eln branch. The Fedora
packager maintainer walks away and foo is adapted by another maintainer
who wants to maintain %if-spaghetti rather than 2 distinct branches. How
do they opt out? Do we "archive" the eln branch until it is requested
again? Or do we merge rawhide and eln branches, sot hey have the same
HEAD and than turn eln into a symbolic reference?
--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it:
https://pagure.io/fedora-infrastructure
Re: [ELN] Creating a process for ELN-specific changes
On Fri, May 14, 2021 at 10:53 AM Vít Ondruch wrote: ... > > Maintaining a separate branch for ELN requires us to do the following > > things: > > * Create an `eln` branch for the package > > * Exclude the package from the Rawhide auto-rebuild > > > This is not necessary as long as `git pull --rebase` works. > I'm not sure what you mean here. What I was saying is that we need to make sure that the auto-rebuild doesn't attempt to build the Rawhide content in the ELN buildroot for this package. > > > > > Maintaining an extra branch is more work for the packager, so it > > should be avoided whenever possible. Our goal with ELN is to maximize > > the value we provide to enterprise linux while minimizing the > > additional load that we put on maintainers. > > > Just FTR, you underestimate how much work this is going to save. Really. > I have just merged this PR [1] into ELN. This removes the build > dependency on texlive and while on it, it also removes dependency on > rubygem-stringex. You can check yourselves (and I suggest to take a look > at internal instance of RHEL9 content resolver) how big the dependency > chain is I assume I'll be able to remove 20+ packages and therefore the > Fedora maintainers won't be bothered. It will hopefully remove (at least > in my domain) the build order concerns. > > So far, I have modified 4 packages in RHEL9 and therefore was able to > open requests for removal of ~25 packages. I call it good deal. Oh, I absolutely understand that this will lead to dependency trimming. However, such things are *also* possible via conditionalizing the Rawhide specfile (which remains the recommended approach, because it means you don't have to maintain a separate branch). > > > > We may also look into the possibility of extending the auto-rebuilder > > to attempt a merge-and-scratch-build from Rawhide to the ELN branch, > > to reduce maintainer effort if they opt to maintain their package in > > the ELN branch manually. > > > > > > This is tracked in the ELN SIG as > > https://github.com/fedora-eln/eln/issues/56 > > > I am truly happy for this initiative. > ___ 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: [ELN] Creating a process for ELN-specific changes
Dne 14. 05. 21 v 16:29 Stephen Gallagher napsal(a):
In nearly all cases, we want the `rawhide` branch in dist-git to
provide the sources used to build packages for ELN. This ensures that
they are kept up to date and minimizes packager effort (since they do
not have to maintain an extra branch).
However, there are some cases where changes desired for ELN (and by
extension, enterprise linux) cannot go into Rawhide. A non-exhaustive
list:
* ELN wants to build without documentation, experimental features or
similar and the maintainer refuses to include `%{rhel}` conditionals
in the spec
* Fedora wants to use the latest version of an upstream, but ELN wants
to stay on LTS releases (e.g. Firefox)
* A package is retired in Rawhide but is needed as a dependency for a
package in ELN (usually as a result of the previous example)
* A package exists solely for use in ELN (e.g. lorax-templates-rhel)
I'm sure there are other good examples, but these are what I could
come up with off the top of my head. If you have other use-cases that
we need to consider, please suggest them.
Maintaining a separate branch for ELN requires us to do the following things:
* Create an `eln` branch for the package
* Exclude the package from the Rawhide auto-rebuild
This is not necessary as long as `git pull --rebase` works.
Maintaining an extra branch is more work for the packager, so it
should be avoided whenever possible. Our goal with ELN is to maximize
the value we provide to enterprise linux while minimizing the
additional load that we put on maintainers.
Just FTR, you underestimate how much work this is going to save. Really.
I have just merged this PR [1] into ELN. This removes the build
dependency on texlive and while on it, it also removes dependency on
rubygem-stringex. You can check yourselves (and I suggest to take a look
at internal instance of RHEL9 content resolver) how big the dependency
chain is I assume I'll be able to remove 20+ packages and therefore the
Fedora maintainers won't be bothered. It will hopefully remove (at least
in my domain) the build order concerns.
So far, I have modified 4 packages in RHEL9 and therefore was able to
open requests for removal of ~25 packages. I call it good deal.
We may also look into the possibility of extending the auto-rebuilder
to attempt a merge-and-scratch-build from Rawhide to the ELN branch,
to reduce maintainer effort if they opt to maintain their package in
the ELN branch manually.
This is tracked in the ELN SIG as https://github.com/fedora-eln/eln/issues/56
I am truly happy for this initiative.
Vít
[1]
https://gitlab.com/redhat/centos-stream/rpms/rubygem-kramdown/-/merge_requests/1
___
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
[ELN] Creating a process for ELN-specific changes
In nearly all cases, we want the `rawhide` branch in dist-git to
provide the sources used to build packages for ELN. This ensures that
they are kept up to date and minimizes packager effort (since they do
not have to maintain an extra branch).
However, there are some cases where changes desired for ELN (and by
extension, enterprise linux) cannot go into Rawhide. A non-exhaustive
list:
* ELN wants to build without documentation, experimental features or
similar and the maintainer refuses to include `%{rhel}` conditionals
in the spec
* Fedora wants to use the latest version of an upstream, but ELN wants
to stay on LTS releases (e.g. Firefox)
* A package is retired in Rawhide but is needed as a dependency for a
package in ELN (usually as a result of the previous example)
* A package exists solely for use in ELN (e.g. lorax-templates-rhel)
I'm sure there are other good examples, but these are what I could
come up with off the top of my head. If you have other use-cases that
we need to consider, please suggest them.
Maintaining a separate branch for ELN requires us to do the following things:
* Create an `eln` branch for the package
* Exclude the package from the Rawhide auto-rebuild
Maintaining an extra branch is more work for the packager, so it
should be avoided whenever possible. Our goal with ELN is to maximize
the value we provide to enterprise linux while minimizing the
additional load that we put on maintainers.
We may also look into the possibility of extending the auto-rebuilder
to attempt a merge-and-scratch-build from Rawhide to the ELN branch,
to reduce maintainer effort if they opt to maintain their package in
the ELN branch manually.
This is tracked in the ELN SIG as https://github.com/fedora-eln/eln/issues/56
___
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: Non-responsive maintainer: jdulaney
I can reach out to her, which package is this for? On 5/14/21 5:09 AM, Vitaly Zaitsev via devel wrote: Hello. According to non-responsive maintainer procedure, I'm asking if anyone knows how to contact jdulaney? -- Jake Hunsaker RHCA Cloud Specialist Senior Software Engineer, CEE Engineering 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 Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Fedora-Rawhide-20210514.n.0 compose check report
No missing expected images. Compose FAILS proposed Rawhide gating check! 3 of 43 required tests failed, 4 results missing openQA tests matching unsatisfied gating requirements shown with **GATING** below Failed openQA tests: 15/194 (x86_64), 15/133 (aarch64) New failures (same test not failed in Fedora-Rawhide-20210513.n.0): ID: 887124 Test: x86_64 Workstation-live-iso apps_startstop URL: https://openqa.fedoraproject.org/tests/887124 ID: 887136 Test: x86_64 Workstation-live-iso unwanted_packages URL: https://openqa.fedoraproject.org/tests/887136 ID: 887140 Test: x86_64 KDE-live-iso desktop_notifications_live URL: https://openqa.fedoraproject.org/tests/887140 ID: 887200 Test: aarch64 Server-dvd-iso install_resize_lvm@uefi URL: https://openqa.fedoraproject.org/tests/887200 ID: 887213 Test: aarch64 Server-dvd-iso support_server@uefi URL: https://openqa.fedoraproject.org/tests/887213 ID: 887222 Test: aarch64 Server-dvd-iso install_blivet_resize_lvm@uefi URL: https://openqa.fedoraproject.org/tests/887222 ID: 887229 Test: aarch64 Server-dvd-iso install_repository_nfs_graphical@uefi URL: https://openqa.fedoraproject.org/tests/887229 ID: 887243 Test: aarch64 Workstation-raw_xz-raw.xz desktop_browser@uefi URL: https://openqa.fedoraproject.org/tests/887243 ID: 887248 Test: aarch64 Workstation-raw_xz-raw.xz desktop_update_graphical@uefi URL: https://openqa.fedoraproject.org/tests/887248 ID: 887251 Test: aarch64 Workstation-raw_xz-raw.xz desktop_background@uefi URL: https://openqa.fedoraproject.org/tests/887251 ID: 887253 Test: aarch64 Workstation-raw_xz-raw.xz desktop_printing@uefi URL: https://openqa.fedoraproject.org/tests/887253 ID: 887267 Test: x86_64 universal install_package_set_kde URL: https://openqa.fedoraproject.org/tests/887267 ID: 887275 Test: x86_64 universal upgrade_kde_64bit URL: https://openqa.fedoraproject.org/tests/887275 ID: 887309 Test: x86_64 universal upgrade_2_kde_64bit URL: https://openqa.fedoraproject.org/tests/887309 ID: 887385 Test: x86_64 KDE-live-iso install_default_upload **GATING** URL: https://openqa.fedoraproject.org/tests/887385 ID: 887402 Test: x86_64 KDE-live-iso install_default@uefi **GATING** URL: https://openqa.fedoraproject.org/tests/887402 ID: 887403 Test: x86_64 KDE-live-iso install_no_user **GATING** URL: https://openqa.fedoraproject.org/tests/887403 Old failures (same test failed in Fedora-Rawhide-20210513.n.0): ID: 887130 Test: x86_64 Workstation-live-iso desktop_login URL: https://openqa.fedoraproject.org/tests/887130 ID: 887296 Test: x86_64 universal install_asian_language URL: https://openqa.fedoraproject.org/tests/887296 ID: 887313 Test: x86_64 universal upgrade_2_server_domain_controller URL: https://openqa.fedoraproject.org/tests/887313 ID: 887332 Test: x86_64 universal upgrade_server_domain_controller URL: https://openqa.fedoraproject.org/tests/887332 ID: 887336 Test: x86_64 universal upgrade_realmd_client URL: https://openqa.fedoraproject.org/tests/887336 ID: 887339 Test: x86_64 universal upgrade_2_realmd_client URL: https://openqa.fedoraproject.org/tests/887339 ID: 887346 Test: aarch64 universal install_anaconda_text@uefi URL: https://openqa.fedoraproject.org/tests/887346 ID: 887348 Test: aarch64 universal install_arabic_language@uefi URL: https://openqa.fedoraproject.org/tests/887348 ID: 887366 Test: aarch64 universal upgrade_2_server_domain_controller@uefi URL: https://openqa.fedoraproject.org/tests/887366 ID: 887367 Test: aarch64 universal install_asian_language@uefi URL: https://openqa.fedoraproject.org/tests/887367 ID: 887380 Test: aarch64 universal upgrade_server_domain_controller@uefi URL: https://openqa.fedoraproject.org/tests/887380 ID: 887383 Test: aarch64 universal upgrade_realmd_client@uefi URL: https://openqa.fedoraproject.org/tests/887383 ID: 887384 Test: aarch64 universal upgrade_2_realmd_client@uefi URL: https://openqa.fedoraproject.org/tests/887384 Soft failed openQA tests: 1/194 (x86_64), 3/133 (aarch64) (Tests completed, but using a workaround for a known bug) Old soft failures (same test soft failed in Fedora-Rawhide-20210513.n.0): ID: 887175 Test: x86_64 Cloud_Base-qcow2-qcow2 cloud_autocloud URL: https://openqa.fedoraproject.org/tests/887175 ID: 887176 Test: aarch64 Minimal-raw_xz-raw.xz install_arm_image_deployment_upload@uefi URL: https://openqa.fedoraproject.org/tests/887176 ID: 887232 Test: aarch64 Server-raw_xz-raw.xz install_arm_image_deployment_upload@uefi URL: https://openqa.fedoraproject.org/tests/887232 ID: 887263 Test: aarch64 Cloud_Base-qcow2-qcow2 cloud_autocloud@uefi URL: https://openqa.fedoraproject.org/tests/887263 Passed openQA tests: 162/194 (x86_64), 115/133 (aarch64) New passes (same test not passed in Fedora-Rawhide-20210513.n.0): ID: 887065 Test: x86_64 Server-dvd-iso install_blivet_lvm_ext4 URL:
Re: Storing package metadata in ELF objects
On Fri, 2021-05-14 at 12:41 +0200, Guillem Jover wrote: > On Sat, 2021-04-10 at 13:38:31 +0100, Luca Boccassi wrote: > > On Sat, 2021-04-10 at 13:29 +0100, Luca Boccassi wrote: > > > After an initial discussion [0], recently we have been working on a new > > > specification [0] to encode rich package-level metadata inside ELF > > > objects, so that it can be included automatically in generated coredump > > > files. The prototype to parse this in systemd-coredump and store the > > > information in systemd-journal is ready for testing and merged > > > upstream. We are now seeking further comments/opinions/suggestions, as > > > we have a few months before the next release and thus there's plenty of > > > time to make incompatible changes to the format and implementation, if > > > required. > > I've skimmed over the discussion at [0], and while having this data > seems like it might be "nice", I've to agree with the comments there > voicing that there does not really seem to be an actual need and the > overhead and additional work do not seem worth it, TBH, at least > in the Debian context. Hi Guillem, thanks for having a look, much appreciated! Just to clarify, the need is there - this is not an experimental exercise, but it is borne out of an actual need, and it is undergoing testing right now before deployment in a large scale production infrastructure. Not _everybody_ will need it, and not everywhere - that's absolutely fair, and discussions on whether the ovearhead is worth it for something that is not universally needed, but only in certain use cases, is perfectly reasonable and welcome. I know Zbigniew is going to try and get some raw numbers on the kind of overhead we are talking about, that will hopefully help frame the discussion with more precision. > > > The Fedora Wiki and the systemd.io document have more details, but to > > > make a long story short, a new .notes.package section with a JSON > > > payload will be included in ELF objects, encoding various package- > > > build-time information like distro name, package name, > > > etc. > > > > > > To summarize from the discussion, the main reasons why we believe this > > > is useful are as following: > > > > > > 1) minimal containers: the rpm database is not installed in the > > > containers. The information about build-ids needs to be stored > > > externally, so package name information is not available immediately, > > > but only after offline processing. The new note doesn't depend on the > > > rpm db in any way. > > In the Debian context, the build-ids data is going to be available > in the affected executables, and in debug symbols packages and the > Packages metaindices listing them, so there's no need for access to > any local dpkg database. Given that someone needing to install debug > packages will need access to those indices (either with outgoing network > access or with a repository mirror), these can be queried at that time. > Not to mention that AFAIR the Debian debug symbol servers make it > possible to query for specific build-ids. This is not strictly related to debug packages, though? In fact, on systems where this could be of most use you explicitly do _not_ install debug packages (or anything at all). Or even if you wanted to, you could not - corefiles are not handled inside the container, but outside. Even if you wanted to and were allowed to (which for many environments it's not the case), you can't install a Debian debug package on a CoreOS host or Mariner host or a Flatcar host. > > > 2) handling of a core from a container, where the container and host > > > have different distros > > How each distribution handles debug packages and debug symbols is > going to be different, so it seems there will be a need for explicit > handling of these, at which point the above mentioned querying can be > implemented as well, w/o the need to encode the packaging data inside > the executable. Again, matching to debug symbols is not the main goal here, build-id works for that. The main goal is to have useful metadata immediately available in all occasions, regardless of where the core was generated on the host, without reaching out to external services, so that it is directly included and collated in the system journal when the core file is handled. With a common metadata definition, there's no need to query or explicitly handle anything - this already works if you use systemd- coredump built from the main branch, and handle a core file from different containers running different distros with binaries having this metadata in the ELF file, and it just works. This is tested, not theoretical. > > > 3) self-built and external packages: unless a lot of care is taken to > > > keep access to the debuginfo packages, this information may be lost. > > > The new note is available even if the repository metadata gets lost. > > > Users can easily provide equivalent information in a format that makes > > > sense in their own environment. It
Re: f34 - llvm12 update
On Fri, May 14, 2021 at 2:49 PM Serge Guelton wrote: > > Hi folks, > > we're preparing an update of the LLVM package from 12.0.0rc1 to 12.0.0. > > In addition the package the llvm team maintain, the following packages needs > a rebuild: > > annobin-0:9.65 > bindgen-0:0.57.0 > clazy-0:1.9 > doxygen-1:1.9.1 > gnome-builder-0:3.40.0 > mesa-dri-drivers-0:21.0.2 > mesa-libOSMesa-0:21.0.2 > mesa-vulkan-drivers-0:21.0.2 > postgresql-llvmjit-0:13.2 > qt-creator-0:4.14.1 > qt6-doctools-0:6.0.3 > qt6-linguist-0:6.0.3 > > Once the llvm packaes are all rebuit, we will push these rebuilds in the > side-tag f34-build-side-41029. > > Feel free to contact sguel...@redhat.com and tstel...@redhat.com if you have > any > question/remark. Would it be possible to rebuild and include rust as well? It is already built against LLVM 12 in rawhide, and building it against LLVM 12 instead of the LLVM 11 compat package fixes a few code generation issues and crashes that have been hitting Fedora Rust packages. jistone might have more details ... 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 Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: F35 Change: Drop the the "Allow SSH root login with password" option from the installer GUI (Self-Contained Change proposal)
On Thu, 2021-05-13 at 20:09 +0200, Peter Boy wrote: > > > > Am 12.05.2021 um 22:35 schrieb Ben Cotton : > > > > == Summary == > > Since 2019 the Anaconda installer GUI hosted an option called > > "Allow > > SSH root login with password", that made it possible to enable > > password based root logins over SSH on the installed system. ... > > And > > after two years of transition period it is now time to drop the > > option > > from the GUI. > > > > We discussed that in the Fedora Server Edition Working Group and > opted to leave it as is for the Server installation iso. A lot of > servers are running in a protected environment. And there are > situations when you need urgent access but do not sit at your desktop > and don’t have the key available. So let the server admin decide what > is best in a given installation context. In most cases it is the > current default (disallow password login) Do those server deployments not have any users accounts other than root ? Creating a non-root user account, possibly with admin rights (all possible from within Anaconda) would seem like a safer option for accasional/emergency password based access to such machines over SSH. > ___ > 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 ___ 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
f34 - llvm12 update
Hi folks, we're preparing an update of the LLVM package from 12.0.0rc1 to 12.0.0. In addition the package the llvm team maintain, the following packages needs a rebuild: annobin-0:9.65 bindgen-0:0.57.0 clazy-0:1.9 doxygen-1:1.9.1 gnome-builder-0:3.40.0 mesa-dri-drivers-0:21.0.2 mesa-libOSMesa-0:21.0.2 mesa-vulkan-drivers-0:21.0.2 postgresql-llvmjit-0:13.2 qt-creator-0:4.14.1 qt6-doctools-0:6.0.3 qt6-linguist-0:6.0.3 Once the llvm packaes are all rebuit, we will push these rebuilds in the side-tag f34-build-side-41029. Feel free to contact sguel...@redhat.com and tstel...@redhat.com if you have any question/remark. ___ devel-announce mailing list -- devel-annou...@lists.fedoraproject.org To unsubscribe send an email to devel-announce-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel-annou...@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
f34 - llvm12 update
Hi folks, we're preparing an update of the LLVM package from 12.0.0rc1 to 12.0.0. In addition the package the llvm team maintain, the following packages needs a rebuild: annobin-0:9.65 bindgen-0:0.57.0 clazy-0:1.9 doxygen-1:1.9.1 gnome-builder-0:3.40.0 mesa-dri-drivers-0:21.0.2 mesa-libOSMesa-0:21.0.2 mesa-vulkan-drivers-0:21.0.2 postgresql-llvmjit-0:13.2 qt-creator-0:4.14.1 qt6-doctools-0:6.0.3 qt6-linguist-0:6.0.3 Once the llvm packaes are all rebuit, we will push these rebuilds in the side-tag f34-build-side-41029. Feel free to contact sguel...@redhat.com and tstel...@redhat.com if you have any question/remark. ___ devel-announce mailing list -- devel-announce@lists.fedoraproject.org To unsubscribe send an email to devel-announce-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel-announce@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: F35 Change: Drop the the "Allow SSH root login with password" option from the installer GUI (Self-Contained Change proposal)
On Fri, May 14, 2021 at 07:25:26AM -0400, PGNet Dev wrote: > On 5/14/21 2:05 AM, Juha Tuomala wrote: > >>here, > > > >Sure. But this is devel list. Are developers themselves the target audience? > >:) Hopefully not. Is it defined somewhere? > > by 'here', I meant my company environment, not just this list. > > and, yes, 'developers themselves' -- again, "here" -- *are* a target > audience. their usage of OS installs, whether VM or baremetal, is far higher > than end-users'. There's a special kind of "end users" who exclusively use VMs: Windows and Mac owners who install Fedora in VirtualBox. And there is an infinite amount of Windows users out there ;) I think the premise that there's more bare-metal installs is pretty weak. 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 Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
[Bug 1960607] perl-Encode-3.09 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1960607 Jitka Plesnikova changed: What|Removed |Added Status|NEW |ASSIGNED CC|jples...@redhat.com,| |mspa...@redhat.com, | |ppi...@redhat.com | Doc Type|--- |If docs needed, set a value -- You are receiving this mail because: You are on the CC list for the bug. ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Fedora rawhide compose report: 20210514.n.0 changes
OLD: Fedora-Rawhide-20210513.n.0 NEW: Fedora-Rawhide-20210514.n.0 = SUMMARY = Added images:2 Dropped images: 1 Added packages: 0 Dropped packages:0 Upgraded packages: 89 Downgraded packages: 0 Size of added packages: 0 B Size of dropped packages:0 B Size of upgraded packages: 1.34 GiB Size of downgraded packages: 0 B Size change of upgraded packages: -19.12 MiB Size change of downgraded packages: 0 B = ADDED IMAGES = Image: Xfce raw-xz armhfp Path: Spins/armhfp/images/Fedora-Xfce-Rawhide-20210514.n.0.armhfp.raw.xz Image: Workstation raw-xz armhfp Path: Workstation/armhfp/images/Fedora-Workstation-Rawhide-20210514.n.0.armhfp.raw.xz = DROPPED IMAGES = Image: Cinnamon live x86_64 Path: Spins/x86_64/iso/Fedora-Cinnamon-Live-x86_64-Rawhide-20210513.n.0.iso = ADDED PACKAGES = = DROPPED PACKAGES = = UPGRADED PACKAGES = Package: OpenMolcas-21.02-1.fc35 Old package: OpenMolcas-20.10-2.fc34 Summary: A multiconfigurational quantum chemistry software package RPMs: OpenMolcas Size: 60.03 MiB Size change: -20.16 MiB Changelog: * Thu May 06 2021 Susi Lehtola - 21.02-1 - Disable builds on 32-bit architectures by request of upstream. - Update to release 21.02. Package: ags-3.5.0.32-1.fc35 Old package: ags-3.5.0.31-1.fc35 Summary: Engine for creating and running videogames of adventure (quest) genre RPMs: ags Size: 5.80 MiB Size change: -7.41 KiB Changelog: * Thu May 13 2021 Dominik Mierzejewski - 3.5.0.32-1 - update to 3.5.0.32 Package: annobin-9.72-1.fc35 Old package: annobin-9.71-1.fc35 Summary: Annotate and examine compiled binary files RPMs: annobin-annocheck annobin-docs annobin-plugin-clang annobin-plugin-gcc annobin-plugin-llvm Size: 1.23 MiB Size change: 4.78 KiB Changelog: * Thu May 13 2021 Nick Clifton - 9.72-1 - annocheck: Accept 0 as a valid number for gcc minor versions and release numbers. - gcc-plugin: Add support for ARM and RISCV targets. Package: arm-trusted-firmware-2.5-0.1.rc1.fc35 Old package: arm-trusted-firmware-2.4-1.fc34 Summary: ARM Trusted Firmware RPMs: arm-trusted-firmware-armv8 Size: 147.72 KiB Size change: -8.40 KiB Changelog: * Tue Jan 26 2021 Fedora Release Engineering - 2.4-2 - Rebuilt for https://fedoraproject.org/wiki/Fedora_34_Mass_Rebuild * Mon Feb 01 2021 Peter Robinson - 2.4-3 - Enable newer Amlogic devices * Thu May 13 2021 Peter Robinson - 2.5-0.1.rc1 - New 2.5 RC1 release Package: binutils-2.36.1-10.fc35 Old package: binutils-2.36.1-9.fc35 Summary: A GNU collection of binary utilities RPMs: binutils binutils-devel binutils-gold Size: 90.02 MiB Size change: -25.91 KiB Changelog: * Thu May 13 2021 Nick Clifton - 2.36.1-10 - Enable use of new dtags. Package: bluedevil-5.21.90-1.fc35 Old package: bluedevil-5.21.5-1.fc35 Summary: Bluetooth stack for KDE RPMs: bluedevil Size: 2.03 MiB Size change: -3.01 KiB Changelog: * Thu May 13 2021 Rex Dieter - 5.21.90-1 - 5.21.90 Package: brltty-6.3-5.fc35 Old package: brltty-6.3-4.fc35 Summary: Braille display driver for Linux/Unix RPMs: brlapi brlapi-devel brlapi-java brltty brltty-at-spi2 brltty-docs brltty-dracut brltty-espeak brltty-espeak-ng brltty-speech-dispatcher brltty-xw ocaml-brlapi python3-brlapi tcl-brlapi Size: 13.51 MiB Size change: 2.24 KiB Changelog: * Thu May 13 2021 Jaroslav ??karvada - 6.3-5 - Fixed brlapi multilib Package: btrfs-progs-5.12.1-1.fc35 Old package: btrfs-progs-5.12-1.fc35 Summary: Userspace programs for btrfs RPMs: btrfs-progs btrfs-progs-devel libbtrfs libbtrfsutil python3-btrfsutil Size: 7.17 MiB Size change: 9.40 KiB Changelog: * Thu May 13 2021 Neal Gompa - 5.12.1-1 - Update to 5.12.1 Package: buildah-1.20.2-0.12.dev.git5119393.fc35 Old package: buildah-1.20.2-0.11.dev.git5119393.fc35 Summary: A command line tool used for creating OCI Images RPMs: buildah buildah-tests Size: 75.27 MiB Size change: -489.84 KiB Package: cbmc-5.29.0-1.fc35 Old package: cbmc-5.25.0-2.fc35 Summary: Bounded Model Checker for ANSI-C and C++ programs RPMs: cbmc cbmc-doc cbmc-utils Size: 208.52 MiB Size change: 1.91 MiB Changelog: * Wed May 12 2021 Vincent Mihalkovic - 5.29.0-1 - New upstream release Package: chrony-4.1-1.fc35 Old package: chrony-4.1-0.1.pre1.fc35 Summary: An NTP client/server RPMs: chrony Size: 1.51 MiB Size change: 5.24 KiB Changelog: * Thu May 13 2021 Miroslav Lichvar 4.1-1 - update to 4.1 - enable seccomp filter by default (incompatible with mailonchange directive) Package: copr-backend-1.148-1.fc35 Old package: copr-backend-1.147-1.fc35 Summary: Backend for Copr RPMs: copr-backend copr-backend-doc Size
Re: F35 Change: Drop the the "Allow SSH root login with password" option from the installer GUI (Self-Contained Change proposal)
On 5/14/21 2:05 AM, Juha Tuomala wrote: here, Sure. But this is devel list. Are developers themselves the target audience? :) Hopefully not. Is it defined somewhere? by 'here', I meant my company environment, not just this list. and, yes, 'developers themselves' -- again, "here" -- *are* a target audience. their usage of OS installs, whether VM or baremetal, is far higher than end-users'. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
[Bug 1960607] New: perl-Encode-3.09 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1960607 Bug ID: 1960607 Summary: perl-Encode-3.09 is available Product: Fedora Version: rawhide Status: NEW Component: perl-Encode Keywords: FutureFeature, Triaged Assignee: jples...@redhat.com Reporter: upstream-release-monitor...@fedoraproject.org QA Contact: extras...@fedoraproject.org CC: jples...@redhat.com, mspa...@redhat.com, perl-devel@lists.fedoraproject.org, ppi...@redhat.com Target Milestone: --- Classification: Fedora Latest upstream release: 3.09 Current version/release in rawhide: 3.08-459.fc34 URL: http://search.cpan.org/dist/Encode/ Please consult the package updates policy before you issue an update to a stable branch: https://docs.fedoraproject.org/en-US/fesco/Updates_Policy/ More information about the service that created this bug can be found at: https://fedoraproject.org/wiki/Upstream_release_monitoring Please keep in mind that with any upstream change, there may also be packaging changes that need to be made. Specifically, please remember that it is your responsibility to review the new version to ensure that the licensing is still correct and that no non-free or legally problematic items have been added upstream. Based on the information from anitya: https://release-monitoring.org/project/2849/ -- You are receiving this mail because: You are on the CC list for the bug. ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Fedora for WSL
On Fri, May 14, 2021 at 1:40 AM Dan Čermák wrote: > > Hi Neal, > > Neal Gompa writes: > > > On Thu, May 13, 2021 at 12:44 PM Matthew Miller > > wrote: > >> > >> On Sun, May 09, 2021 at 12:32:00AM -0500, Greg Hellings wrote: > >> > I may be hair-brained to do this, but I've put together an installer for > >> > Fedora on WSL. > >> > >> Hi Greg! Not hair-brained at all -- this is awesome! > >> > > > > A couple of years back, I was working on porting WSL-DistroLauncher to > > be cross compiled with Fedora's MinGW stack. I stopped because of > > *reasons*, but it'd be nice to have the WSL stuff in Fedora and I > > could probably pick that back up and make it a package in Fedora for > > people to trivially generate their own WSL bundles. > > Have you looked at openSUSE's patches: > https://github.com/openSUSE/WSL-DistroLauncher ? It works with their > MinGW stack, at the expense of adding autotools into the mix… > I had not. It seems that their approach was to autotoolize the tree. I was working on making it build with CMake, mostly because I was intending to eliminate the Visual Studio solution files entirely in favor of CMake and submit those upstream. -- 真実はいつも一つ！/ Always, there's only one truth! ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Fedora-Cloud-34-20210514.0 compose check report
No missing expected images. Failed openQA tests: 1/8 (x86_64) Old failures (same test failed in Fedora-Cloud-34-20210513.0): ID: 887049 Test: x86_64 Cloud_Base-qcow2-qcow2 cloud_autocloud URL: https://openqa.fedoraproject.org/tests/887049 Soft failed openQA tests: 1/8 (aarch64) (Tests completed, but using a workaround for a known bug) Old soft failures (same test soft failed in Fedora-Cloud-34-20210513.0): ID: 887057 Test: aarch64 Cloud_Base-qcow2-qcow2 cloud_autocloud@uefi URL: https://openqa.fedoraproject.org/tests/887057 Passed openQA tests: 7/8 (x86_64), 7/8 (aarch64) -- Mail generated by check-compose: https://pagure.io/fedora-qa/check-compose ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Fedora-Cloud-32-20210514.0 compose check report
No missing expected images. Soft failed openQA tests: 1/8 (x86_64), 1/8 (aarch64) (Tests completed, but using a workaround for a known bug) Old soft failures (same test soft failed in Fedora-Cloud-32-20210513.0): ID: 887033 Test: x86_64 Cloud_Base-qcow2-qcow2 cloud_autocloud URL: https://openqa.fedoraproject.org/tests/887033 ID: 887041 Test: aarch64 Cloud_Base-qcow2-qcow2 cloud_autocloud@uefi URL: https://openqa.fedoraproject.org/tests/887041 Passed openQA tests: 7/8 (x86_64), 7/8 (aarch64) -- Mail generated by check-compose: https://pagure.io/fedora-qa/check-compose ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Non-responsive maintainer: jdulaney
Hello. According to non-responsive maintainer procedure, I'm asking if anyone knows how to contact jdulaney? -- Sincerely, Vitaly Zaitsev (vit...@easycoding.org) ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Fedora-Cloud-33-20210514.0 compose check report
No missing expected images. Soft failed openQA tests: 1/8 (x86_64), 1/8 (aarch64) (Tests completed, but using a workaround for a known bug) Old soft failures (same test soft failed in Fedora-Cloud-33-20210513.0): ID: 886960 Test: x86_64 Cloud_Base-qcow2-qcow2 cloud_autocloud URL: https://openqa.fedoraproject.org/tests/886960 ID: 886968 Test: aarch64 Cloud_Base-qcow2-qcow2 cloud_autocloud@uefi URL: https://openqa.fedoraproject.org/tests/886968 Passed openQA tests: 7/8 (x86_64), 7/8 (aarch64) -- Mail generated by check-compose: https://pagure.io/fedora-qa/check-compose ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Bodhi critpath package updates now gated on openQA results
On Fri, 2021-05-14 at 06:06 +0200, Michal Srb wrote: > > I thought, under the hood, the button is just telling Bodhi to send the > "bodhi.update.status.testing.koji-build-group.build.complete" [1] message > again, so all CI systems listening should trigger? This isn't the case for > openQA? > > Thanks, > Michal > > [1]: > https://apps.fedoraproject.org/datagrepper/raw?topic=org.fedoraproject.prod.bodhi.update.status.testing.koji-build-group.build.complete=18000 Ah, I didn't remember precisely what it does :D openQA doesn't currently trigger off that message, for the fairly simple reason that it didn't exist when I wrote the openQA update triggering stuff. It triggers off Bodhi "update submitted to testing" and "update edited" messages. I can take a look at whether I can adjust it to use that message as well/instead, I'll have to make a bit of time for it tomorrow. -- Adam Williamson Fedora QA IRC: adamw | Twitter: adamw_ha https://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 Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: F35 Change: Drop the the "Allow SSH root login with password" option from the installer GUI (Self-Contained Change proposal)
On Thursday, 13 May 2021 18:50:33 EEST PGNet Dev wrote: > On 5/13/21 10:48 AM, Juha Tuomala wrote: > > Virtual machine installation is hopefully a special use case and majority > > of installations are bare metal end users. > > hardly. > > here, Sure. But this is devel list. Are developers themselves the target audience? :) Hopefully not. Is it defined somewhere? I would certainly enjoy the polished user interface that normal users require. > for that, a simple password option is more than sufficient. > again, why not simply 'leave it be'. To make it clear, I agree. Unix/Linux has always been about options and flexibility. And hence having option to pull the root's existing public key somewhere easier is just good progress. Tuju -- t...@iki.fi | http://tuju.fi | sip:t...@iki.fi | +358931575699 | +358401514000 Better to have one, and not need it, than to need one and not have it. ___ 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
