Re: protect the builds from deletion
Hi Muneendra, Muneendra Kumar M via devel writes: > Hi All, > I got the below mail . > Can anyone help me the steps to be done to protect the builds. That build is not in any repository and thus koji tries to delete it to free up some space. You can protect it by submitting it to a repository (which you probably did with a later build, I often get these messages too, when koji cleans up old intermediate builds that never made it into the stable repository). Cheers, Dan > > Iam not able to find the same from the below links on how to protect the > builds. > > > Regards, > Muneendra. > > -Original Message- > From: Koji Build System [mailto:build...@fedoraproject.org] > Sent: Friday, November 13, 2020 10:15 AM > To: muneen...@fedoraproject.org > Subject: 1 build marked for deletion > > The following build(s) are unreferenced and have been marked for deletion. > They will be held in the trashcan tag for a grace period. > At the end of that period they will be deleted permanently. This garbage > collection is a normal part of build system operation. > Please see the following url for more information: > > https://fedoraproject.org/wiki/Koji/GarbageCollection > > Build: fctxpd-0.2-1.20200827gitccbaf3a.epel8.playground > https://koji.fedoraproject.org/koji/buildinfo?buildID=1602106 > > If you would like to protect any of these builds from deletion, please > refer to the document linked above for instructions. > ___ > 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 signature.asc Description: PGP signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
protect the builds from deletion
Hi All, I got the below mail . Can anyone help me the steps to be done to protect the builds. Iam not able to find the same from the below links on how to protect the builds. Regards, Muneendra. -Original Message- From: Koji Build System [mailto:build...@fedoraproject.org] Sent: Friday, November 13, 2020 10:15 AM To: muneen...@fedoraproject.org Subject: 1 build marked for deletion The following build(s) are unreferenced and have been marked for deletion. They will be held in the trashcan tag for a grace period. At the end of that period they will be deleted permanently. This garbage collection is a normal part of build system operation. Please see the following url for more information: https://fedoraproject.org/wiki/Koji/GarbageCollection Build: fctxpd-0.2-1.20200827gitccbaf3a.epel8.playground https://koji.fedoraproject.org/koji/buildinfo?buildID=1602106 If you would like to protect any of these builds from deletion, please refer to the document linked above for instructions. smime.p7s Description: S/MIME Cryptographic Signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: wlroots 0.12 update with soname change
On 11/10/20 9:57 PM, Aleksei Bavshin wrote: Greetings, I'm planning to push wlroots 0.12.0 update into rawhide next week. As usual, the update is ABI breaking and will change soname (6 -> 7). This time no source changes required for any of the packages; simple rebuild with release bump would be sufficient. I will send an additional message once I figure out how to set up a side-tag and get new wlroots build published into it. The side-tag is ready. You can build your packages with new wlroots using following command: fedpkg build --target=f34-build-side-33997 Use 'koji wait-repo f34-build-side-33997' to wait for the build repo to be updated if you are building multiple dependent packages (which is likely relevant only for wayfire). I'll request the side-tag merge in a week from the initial announcement or when all rebuilds are completed. Affected packages (maintainer aliases in Bcc): - cage - gamescope - phoc - sway - wayfire -- With best regards, Aleksei Bavshin OpenPGP_signature Description: OpenPGP digital signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Conflicting build-ids in nekovm and haxe
Hi list, Re. https://bugzilla.redhat.com/show_bug.cgi?id=1896901 Since haxe-4.1.3-4 and nekovm-2.3.0-4, both nekovm and haxe packages contains "/usr/lib/.build-id/b0/aed4ddf2d45372bcc79d5e95d2834f5045c09c". The nekovm one is a symlink to "/usr/bin/neko". The haxe one to "/usr/bin/haxelib". Both the neko and haxelib binaries are built with libneko, with a nearly identical main.c with the only difference of the present of neko bytecode embedded as a byte array (neko: the byte array is null; haxelib: the byte array is the haxelib neko bytecode). I'm not sure how to resolve it. Please advice. Best regards, Andy ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Fedora-Rawhide-20201112.n.0 compose check report
Missing expected images: Xfce raw-xz armhfp Compose PASSES proposed Rawhide gating check! All required tests passed Failed openQA tests: 7/177 (x86_64), 14/115 (aarch64) New failures (same test not failed in Fedora-Rawhide-2020.n.0): ID: 721492 Test: x86_64 Workstation-live-iso apps_startstop URL: https://openqa.fedoraproject.org/tests/721492 ID: 721546 Test: aarch64 Server-dvd-iso support_server@uefi URL: https://openqa.fedoraproject.org/tests/721546 ID: 721557 Test: aarch64 Server-dvd-iso modularity_tests@uefi URL: https://openqa.fedoraproject.org/tests/721557 ID: 721569 Test: aarch64 Server-dvd-iso install_repository_nfsiso_variation@uefi URL: https://openqa.fedoraproject.org/tests/721569 ID: 721716 Test: aarch64 universal install_with_swap@uefi URL: https://openqa.fedoraproject.org/tests/721716 Old failures (same test failed in Fedora-Rawhide-2020.n.0): ID: 721586 Test: aarch64 Server-raw_xz-raw.xz base_services_start@uefi URL: https://openqa.fedoraproject.org/tests/721586 ID: 721632 Test: x86_64 universal install_cyrillic_language URL: https://openqa.fedoraproject.org/tests/721632 ID: 721687 Test: aarch64 universal upgrade_2_server_domain_controller@uefi URL: https://openqa.fedoraproject.org/tests/721687 ID: 721699 Test: aarch64 universal install_cyrillic_language@uefi URL: https://openqa.fedoraproject.org/tests/721699 ID: 721712 Test: aarch64 universal upgrade_2_realmd_client@uefi URL: https://openqa.fedoraproject.org/tests/721712 ID: 721736 Test: x86_64 KDE-live-iso desktop_printing URL: https://openqa.fedoraproject.org/tests/721736 ID: 721737 Test: x86_64 KDE-live-iso apps_startstop URL: https://openqa.fedoraproject.org/tests/721737 ID: 721739 Test: x86_64 KDE-live-iso desktop_notifications_postinstall URL: https://openqa.fedoraproject.org/tests/721739 ID: 721744 Test: x86_64 universal support_server URL: https://openqa.fedoraproject.org/tests/721744 ID: 721747 Test: x86_64 universal install_pxeboot@uefi URL: https://openqa.fedoraproject.org/tests/721747 ID: 721750 Test: aarch64 universal support_server@uefi URL: https://openqa.fedoraproject.org/tests/721750 ID: 721752 Test: aarch64 universal install_pxeboot@uefi URL: https://openqa.fedoraproject.org/tests/721752 ID: 721754 Test: aarch64 Server-dvd-iso install_vnc_server@uefi URL: https://openqa.fedoraproject.org/tests/721754 ID: 721755 Test: aarch64 Server-dvd-iso install_vnc_client@uefi URL: https://openqa.fedoraproject.org/tests/721755 ID: 721756 Test: aarch64 Server-dvd-iso install_vncconnect_client@uefi URL: https://openqa.fedoraproject.org/tests/721756 ID: 721757 Test: aarch64 Server-dvd-iso install_vncconnect_server@uefi URL: https://openqa.fedoraproject.org/tests/721757 Soft failed openQA tests: 6/177 (x86_64), 1/115 (aarch64) (Tests completed, but using a workaround for a known bug) Old soft failures (same test soft failed in Fedora-Rawhide-2020.n.0): ID: 721438 Test: x86_64 Server-dvd-iso install_vncconnect_client URL: https://openqa.fedoraproject.org/tests/721438 ID: 721470 Test: x86_64 Server-dvd-iso install_vnc_client URL: https://openqa.fedoraproject.org/tests/721470 ID: 721483 Test: x86_64 Workstation-live-iso desktop_printing URL: https://openqa.fedoraproject.org/tests/721483 ID: 721484 Test: x86_64 Workstation-live-iso desktop_update_graphical URL: https://openqa.fedoraproject.org/tests/721484 ID: 721534 Test: x86_64 Cloud_Base-qcow2-qcow2 cloud_autocloud URL: https://openqa.fedoraproject.org/tests/721534 ID: 721602 Test: aarch64 Cloud_Base-qcow2-qcow2 cloud_autocloud@uefi URL: https://openqa.fedoraproject.org/tests/721602 ID: 721611 Test: x86_64 universal upgrade_2_server_domain_controller URL: https://openqa.fedoraproject.org/tests/721611 Passed openQA tests: 164/177 (x86_64), 100/115 (aarch64) New passes (same test not passed in Fedora-Rawhide-2020.n.0): ID: 721624 Test: x86_64 universal upgrade_2_kde_64bit URL: https://openqa.fedoraproject.org/tests/721624 ID: 721751 Test: aarch64 universal install_iscsi@uefi URL: https://openqa.fedoraproject.org/tests/721751 Installed system changes in test x86_64 Workstation-live-iso install_default@uefi: 1 services(s) added since previous compose: flatpak-system-helper.service System load changed from 1.08 to 0.50 Previous test data: https://openqa.fedoraproject.org/tests/720479#downloads Current test data: https://openqa.fedoraproject.org/tests/721480#downloads Installed system changes in test x86_64 Workstation-live-iso install_default_upload: 1 services(s) added since previous compose: fwupd.service Previous test data: https://openqa.fedoraproject.org/tests/720480#downloads Current test data: https://openqa.fedoraproject.org/tests/721481#downloads Installed system changes in test x86_64 KDE-live-iso install_default@uefi: System load changed from 0.88 to 0.74 Previous test data: https://op
Re: Proposed updates to the FESCo updates policy document
Kevin Fenzi wrote: > We have been over this. If anyone could untag anything they felt like it > would make it much more difficult for everyone to integrate their > changes with the rest of the collection. That issue is simply not something we have observed at any time back when this untagging was still allowed. (And it was even possible as self-service without involving rel-eng at all, because the Rawhide tag used to be open before gating was introduced.) In the worst case, if some build(s) depends on the untagged build(s), the dependent build(s) can simply be untagged as well. It is definitely possible to revert to a consistent state, because one such consistent state trivially exists: the one where *all* builds built after the untagged build get untagged as well. But the minimal set of builds to untag is typically much smaller, if it is even larger than a singleton (a set consisting only of the one build you want to untag to begin with). If the untagged package is a leaf package, the set is even guaranteed to be a singleton (but that is not even a necessary condition, only a sufficient condition). Kevin Kofler ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Summary/Minutes from today's FESCo Meeting (2020-11-11)
Matthew Miller wrote: > Well, except, it clearly *does* work that way. We have many > lightly-maintained packages in practice. Do we really? Which are those packages? The one that keeps getting brought up is Tomcat, but I can tell you from my personal experience that the Fedora Tomcat package has always been working just fine (not only as a build dependency, but for its intended use as a web application server: I use it to locally test Java web applications). > I think it's better to label them as such and find positive ways to > encourage the collaboration I think we all agree is best, rather than the > current state where we basically just pretend that everything is > maintained with high attention. I think that if a maintainer is not able to offer a package the attention they think it needs, they should ask for help, not mark the package as unsupported or hidden. That is how the collaborative approach is supposed to work. Now, if no help shows up, that can only mean one of two things: * either the package is actually working so well that no help is really needed, * or nobody actually cares enough about the package to give it more attention. In both cases, the package is working well enough for what is actually needed and there is no need to give it any special marking. But the situation into which we want to get is that the help is not only requested by the maintainer, but that comaintainers actually sign up for it. But that requires upholding a cooperative environment. Privatizing build dependencies by marking them as "lightly maintained" achieves the exact opposite. Kevin Kofler ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Proposed updates to the FESCo updates policy document
On Fri, Nov 13, 2020 at 12:23:05AM +0100, Kevin Kofler via devel wrote:
> Kevin Fenzi wrote:
> > The one actual proposed change is to allow releng to untag builds that
> > have already gone out in rawhide composes. This was forbidden by the
> > existing policy.
>
> Worded like in the above quote: Finally!
>
> But when I see the actual wording in the proposed changes, I see that we go
> from an undocumented policy to never untag packages in Rawhide (at least,
> not documented anywhere in the current Update Policy – I think it was
> decided in some FESCo meeting and never actually codified in the
> documentation) to a documented policy to almost never untag packages in
> Rawhide ("it will normally not be untagged"), only "in exceptional cases",
> which is very open to interpretation.
Yep. IMHO it should still be a very rare thing.
Perhaps we should come up with a list of the cases under which it would
happen, but I figured leaving it to releng would be ok.
> Hence, I disagree with the wording in the new policy and still ask for the
> "Rawhide must never go backwards in EVR" policy to be completely overturned,
> not just softened with exceptions. There is simply no rationale for it, with
> distro-sync being a thing, and considering that updates-testing, which is
> supposed to be *more* stable than Rawhide, *can* actually go backwards in
> EVR (and that's a good thing).
We have been over this. If anyone could untag anything they felt like it
would make it much more difficult for everyone to integrate their
changes with the rest of the collection.
kevin
signature.asc
Description: PGP signature
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Lenovo portals for South America
On Thursday, November 12, 2020 11:24:47 PM WET Michael Catanzaro wrote: > This list is public, and archived by all sorts of different websites. > So too late Michael, everyone knows that the best way to keep a secret is to hide it in plain sight. :-) -- José Abílio___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Lenovo portals for South America
On Thu, Nov 12, 2020 at 05:24:47PM -0600, Michael Catanzaro wrote: > >Please let me know if you have any problems with these. Interestingly > >these don't seem to be limited to fedoraproject.org accounts in > >the same > >way as the US/Canada site does so *please* don't post these details on > >public forums as if it gets abused it will get pulled down. (Maybe it > >checks on checkout?) > This list is public, and archived by all sorts of different > websites. So too late Mark has clarified that he means to please not share it beyond here. It is a public list, but let's be honest, it's still pretty obscure. :) -- 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
Re: Lenovo portals for South America
On Thu, Nov 12, 2020 at 3:18 pm, Mark Pearson wrote: Please let me know if you have any problems with these. Interestingly these don't seem to be limited to fedoraproject.org accounts in the same way as the US/Canada site does so *please* don't post these details on public forums as if it gets abused it will get pulled down. (Maybe it checks on checkout?) This list is public, and archived by all sorts of different websites. So too late ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Proposed updates to the FESCo updates policy document
Kevin Fenzi wrote:
> The one actual proposed change is to allow releng to untag builds that
> have already gone out in rawhide composes. This was forbidden by the
> existing policy.
Worded like in the above quote: Finally!
But when I see the actual wording in the proposed changes, I see that we go
from an undocumented policy to never untag packages in Rawhide (at least,
not documented anywhere in the current Update Policy – I think it was
decided in some FESCo meeting and never actually codified in the
documentation) to a documented policy to almost never untag packages in
Rawhide ("it will normally not be untagged"), only "in exceptional cases",
which is very open to interpretation.
Hence, I disagree with the wording in the new policy and still ask for the
"Rawhide must never go backwards in EVR" policy to be completely overturned,
not just softened with exceptions. There is simply no rationale for it, with
distro-sync being a thing, and considering that updates-testing, which is
supposed to be *more* stable than Rawhide, *can* actually go backwards in
EVR (and that's a good thing).
Kevin Kofler
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Summary/Minutes from today's FESCo Meeting (2020-11-11)
On Fri, Nov 13, 2020 at 12:07:29AM +0100, Kevin Kofler via devel wrote: > I still believe that this concept is inherently incompatible with the idea > of a cooperative community distribution, and that bringing it up again and > again with minimally changed wording is not a constructive thing to do. > > I can see why RHEL has a business case for having such "second-class > citizen" packages, but this is not how Fedora works or should work. Well, except, it clearly *does* work that way. We have many lightly-maintained packages in practice. I think it's better to label them as such and find positive ways to encourage the collaboration I think we all agree is best, rather than the current state where we basically just pretend that everything is maintained with high attention. -- 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
Re: Summary/Minutes from today's FESCo Meeting (2020-11-11)
David Cantrell wrote: > * #2475 proposal: let's develop the idea of a new repo for > lightly-maintained packages (dcantrell, 15:16:41) This suggestion keeps coming up again and again, but the repetition does not make it any more practical. A small handful individual maintainers wants to use some library/infrastructure package(s) for their package builds, but at the same time excuse themselves from actually maintaining those library/infrastructure package(s). This may be more convenient to the minority that gets to "lightly maintain" those packages, but at the cost of offloading technical debt to the entire remainder of the community, both the majority of maintainers (who would benefit from having the library/infrastructure package(s) fully maintained as a potential build and/or runtime dependency of their own package(s)) and the end users (who would benefit from having the library/infrastructure package(s) fully maintained to build local software, and in some cases, such as Tomcat, also to use them directly). I still believe that this concept is inherently incompatible with the idea of a cooperative community distribution, and that bringing it up again and again with minimally changed wording is not a constructive thing to do. I can see why RHEL has a business case for having such "second-class citizen" packages, but this is not how Fedora works or should work. Kevin Kofler ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
[Test-Announce] Fedora 34 Rawhide 20201112.n.0 nightly compose nominated for testing
Announcing the creation of a new nightly release validation test event for Fedora 34 Rawhide 20201112.n.0. Please help run some tests for this nightly compose if you have time. For more information on nightly release validation testing, see: https://fedoraproject.org/wiki/QA:Release_validation_test_plan Notable package version changes: python-blivet - 20201107.n.1: python-blivet-3.3.1-1.fc34.src, 20201112.n.0: python-blivet-3.3.1-2.fc34.src Test coverage information for the current release can be seen at: https://www.happyassassin.net/testcase_stats/34 You can see all results, find testing instructions and image download locations, and enter results on the Summary page: https://fedoraproject.org/wiki/Test_Results:Fedora_34_Rawhide_20201112.n.0_Summary The individual test result pages are: https://fedoraproject.org/wiki/Test_Results:Fedora_34_Rawhide_20201112.n.0_Installation https://fedoraproject.org/wiki/Test_Results:Fedora_34_Rawhide_20201112.n.0_Base https://fedoraproject.org/wiki/Test_Results:Fedora_34_Rawhide_20201112.n.0_Server https://fedoraproject.org/wiki/Test_Results:Fedora_34_Rawhide_20201112.n.0_Cloud https://fedoraproject.org/wiki/Test_Results:Fedora_34_Rawhide_20201112.n.0_Desktop https://fedoraproject.org/wiki/Test_Results:Fedora_34_Rawhide_20201112.n.0_Security_Lab Thank you for testing! -- Mail generated by relvalconsumer: https://pagure.io/fedora-qa/relvalconsumer ___ 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 ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Proposed updates to the FESCo updates policy document
On Thu, Nov 12, 2020 at 05:40:08PM +, Mattia Verga via devel wrote: > Il 12/11/20 09:54, Zbigniew Jędrzejewski-Szmek ha scritto: > > On Wed, Nov 11, 2020 at 06:36:54PM +, Mattia Verga via devel wrote: > >> Il 11/11/20 16:56, Kevin Fenzi ha scritto: > >>> Greetings. > >>> > >>> FESCo is looking to update the updates policy document that is here: > >>> > >>> https://docs.fedoraproject.org/en-US/fesco/Updates_Policy/ > >>> > >>> For the most part the updates are not changing any policy, but simply > >>> removing old/no longer accurate information (taskotron no longer exists, > >>> bodhi is always enabled, etc) and trying to clarify things. > >>> > >>> The one actual proposed change is to allow releng to untag builds that > >>> have already gone out in rawhide composes. This was forbidden by the > >>> existing policy. > >>> > >>> You can see the PR with the changes: > >>> > >>> https://pagure.io/fesco/fesco-docs/pull-request/40 > >>> > >>> and if you want to view the changed document: > >>> > >>> https://pagure.io/fork/kevin/fesco/fesco-docs/raw/updates-update/f/fesco/modules/ROOT/pages/Updates_Policy.adoc > >>> (you may want to install a adoc viewing extension in your browser to > >>> view it) > >>> > >>> Feedback welcome here or in the PR. > >>> > >>> FESCo is likely to look at this next week for approval. > >>> > >>> Thanks! > >>> > >>> kevin > >> Hi kevin, > >> > >> I've tried to summarize some of the aspects of the (updated) policy in > >> an image [1], is that right? I don't fully understand the difference > >> between the Beta during final freeze and Pre release... > > I think you are splitting one "phase" into two: "beta" and "pre-release". > > That should be just one phase called "pre-release". The "final freeze" > > block is part of that one phase, similarly to how "beta freeze" block > > is part of "pre-beta". > > > > I read the PR again, and it seems to me that the text matches my > > description above, i.e. it only has one phase. > > Maybe it's because my limited English comprehension, but that doesn't > seem much clear to me. > > In the PR I read: > " > > Beta to Pre Release > This is the time between the Beta release and the Final freeze. > > [...] > > Pre release > This is the time after the Final freeze. > > " > > I have uploaded the .svg to > https://mattia.fedorapeople.org/updates_policy.svg feel free to correct it! Yeah, it's kind of complex there. "Pre release" is after 'go' at a 'go/no-go meeting'. At that point updates _are_ pushed to stable, but they populate the updates repo, they no longer are part of the base release packages. The document doesn't make that part very clear tho... it folds in the above with the time before go... perhaps it could be clarified. I can try... kevin signature.asc Description: PGP signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: [ELN] gcc is going to be updated to gcc11 in the ELN buildroot ahead of Rawhide
Hi, all, On Thu, Oct 22, 2020 at 2:27 PM Aleksandra Fedorova wrote: > > Hi, all, > > this is the informational message, no action required. > > Upon agreement between gcc maintainers and ELN SIG we would like to > switch ELN buildroot to use GCC11 ahead of Fedora Rawhide. > > Though ELN is defined as the buildroot where Fedora Rawhide code is > rebuilt into EL-like environment, in the ELN proposal we also > mentioned that ELN can be used to test certain buildroot-related > features on the side so it doesn't block Fedora Rawhide development. > > We think that GCC11 is one such feature, where we can benefit from > testing it first on a small subset of the Fedora content in a separate > environment. > > We would like to invite everyone to join this effort. > > The work is currently tracked on Github: > https://github.com/fedora-eln/eln/issues/8 > > Once GCC11 is merged to the eln tag in koji, one would be able to use > it via, for example, mock or container environment: > quay.io/fedoraci/fedora:eln-x86_64 > > For more info on ELN please refer to ELN Docs (as soon as I update > them, which hopefully happens later today): > > https://docs.fedoraproject.org/en-US/eln/ > > -- > Aleksandra Fedorova > bookwar at #fedora-devel and #fedora-ci Small update on the topic: GCC11 has not landed in the ELN buildroot yet. After we tried the first mass rebuild of ELN packages in a sidetag, several issues were found by gcc maintainers. Jeff has more info on that, but afaiu one issue is related to glib2 and waits for the upstream fix. Once the issue is fixed we may try new ELN mass-rebuild in the sidetag, before doing any real updates in the buildroot itself. Exact timing is yet to be defined. We will be running this mass rebuild with the lowest priority, so that it won't get in the way of regular Fedora builds. (We had a misconfiguration in the rebuild script, which caused the queue on the build system before. This issue is now fixed) -- Aleksandra Fedorova bookwar ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Lenovo portals for South America
While this mail list is public itself. I hope lenovo will check on checkout or they may see abuse someday. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: patch applied without package maintainers' approve
On Thu, 2020-11-12 at 20:47 +0800, Honggang LI wrote: > > > > In terms of "upstream" I'm not sure what you mean there, because > > https://github.com/linux-rdma/rdma-core/blob/master/redhat/rdma-core.spec > > It is the "upstream" spec file. This kind of "oh, the *real* spec file is in another castle" approach is just impractical for distributions. It's always a problem, but it's *especially* a problem if the distribution spec file does not indicate the existence of the "upstream" spec in any way. As is the case here. You cannot expect another Fedora packager to look at https://src.fedoraproject.org/rpms/rdma-core/blob/master/f/rdma-core.spec and know that there is an "upstream" of that file, because *nothing in it tells them that there is*. If you're going to have this kind of "upstream" spec file...well, I wish you wouldn't. But if you do, *AT MINIMUM*, the "downstream" spec files need to have a clear explanation that there is an "upstream" spec file, with a justification as to why, and a link to it. At the very top. Otherwise there is no chance any other Fedora packager is going to find it. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Lenovo portals for South America
Hi Fedora-ites, I finally made some progress with getting some more portals setup for: Argentina: www.lenovo.com/ar/linux Chile: www.lenovo.com/cl/linux Colombia: www.lenovo.com/co/linux Mexico: www.lenovo.com/mx/linux Peru: www.lenovo.com/pe/linux Password: comunidad-linux Please let me know if you have any problems with these. Interestingly these don't seem to be limited to fedoraproject.org accounts in the same way as the US/Canada site does so *please* don't post these details on public forums as if it gets abused it will get pulled down. (Maybe it checks on checkout?) As a note - no Linux systems are available yet worldwide - still working on that one. I'll update when I get success there - it will happen eventually. I am working on getting more portals setup, I'll update as that goes. Let me know any questions Thanks Mark ___ 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
libcap-ng update coming to rawhide
Hello, A new version of libcap-ng is going to be released next week. Normally this isn't newsworthy, nor is this a soname version bump. But it is important to let the broader community know something about it. The behaviour of capng_apply is changing slightly. In the past, capng_apply would silently eat errors when the bounding set could not be changed. In order to change the bounding set, you have to have CAP_SETPCAP. A developer reported an issue in github where their project needed to know that capng_apply was completely successful changing the bounding set. Meaning that they need an error returned. I didn't think too much of it and made the change. Then one day I noticed that I could not update a package against Fedora's git or push a change. Looking into this, I found gnome-keyring was not working. [1] I dug into the source code and found that it was trying to change the bounding set when it had partial capabilities. The fix is to simply verify that you have CAP_SETPCAP before attempting this. I don't know of any other software that is affected. But I wanted to give everyone a heads up before I push it out. I always dogfood libraries I work on, so maybe this is the only issue. Eventually libcap-ng needs to get pushed over to F33 because there is a problem with ambient capailities that the new release fixes. And speaking of ambient capabilities, the new version of libcap-ng contains a new library libdrop_ambient.so. You can use it with LD_PRELOAD to force an app to drop ambient capabilities leaving the other capabilities intact. All the work is done in the constructor, so no function calls are needed. Best Regards, -Steve 1 - https://bugzilla.redhat.com/show_bug.cgi?id=1888978 ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Proposed updates to the FESCo updates policy document
Il 12/11/20 09:54, Zbigniew Jędrzejewski-Szmek ha scritto: > On Wed, Nov 11, 2020 at 06:36:54PM +, Mattia Verga via devel wrote: >> Il 11/11/20 16:56, Kevin Fenzi ha scritto: >>> Greetings. >>> >>> FESCo is looking to update the updates policy document that is here: >>> >>> https://docs.fedoraproject.org/en-US/fesco/Updates_Policy/ >>> >>> For the most part the updates are not changing any policy, but simply >>> removing old/no longer accurate information (taskotron no longer exists, >>> bodhi is always enabled, etc) and trying to clarify things. >>> >>> The one actual proposed change is to allow releng to untag builds that >>> have already gone out in rawhide composes. This was forbidden by the >>> existing policy. >>> >>> You can see the PR with the changes: >>> >>> https://pagure.io/fesco/fesco-docs/pull-request/40 >>> >>> and if you want to view the changed document: >>> >>> https://pagure.io/fork/kevin/fesco/fesco-docs/raw/updates-update/f/fesco/modules/ROOT/pages/Updates_Policy.adoc >>> (you may want to install a adoc viewing extension in your browser to >>> view it) >>> >>> Feedback welcome here or in the PR. >>> >>> FESCo is likely to look at this next week for approval. >>> >>> Thanks! >>> >>> kevin >> Hi kevin, >> >> I've tried to summarize some of the aspects of the (updated) policy in >> an image [1], is that right? I don't fully understand the difference >> between the Beta during final freeze and Pre release... > I think you are splitting one "phase" into two: "beta" and "pre-release". > That should be just one phase called "pre-release". The "final freeze" > block is part of that one phase, similarly to how "beta freeze" block > is part of "pre-beta". > > I read the PR again, and it seems to me that the text matches my > description above, i.e. it only has one phase. Maybe it's because my limited English comprehension, but that doesn't seem much clear to me. In the PR I read: " Beta to Pre Release This is the time between the Beta release and the Final freeze. [...] Pre release This is the time after the Final freeze. " I have uploaded the .svg to https://mattia.fedorapeople.org/updates_policy.svg feel free to correct it! Mattia ___ 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
Sundials-5.5.0+PETSc-3.14.1 updates on Rawhide
Hi all. Sundials-5.5.0 will be updated in seven days, at least, creating a side-tag. Since Sundials and PETSc have package in common (python3-bout++), i will update PETSc to the release 3.14.1 with the Sundials side-tag. Regards. -- --- Antonio Trande Fedora Project mailto: sagit...@fedoraproject.org GPG key: 0x29FBC85D7A51CC2F GPG key server: https://keys.gnupg.net/ OpenPGP_0x29FBC85D7A51CC2F.asc Description: application/pgp-keys OpenPGP_signature Description: OpenPGP digital signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Review request: mingw-zstd, mingw-minizip, mingw-python-psycopg2
On 12.11.20 15:38, Richard Shaw wrote: Hopefully someone can get to them before me, I'm swamped with $DAYJOB, but if not, I'll see if I can find sometime within the next week or so. Thanks Richard Perhaps as a small encouragement: they packages are pretty trivial ;) Sandro ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Review request: mingw-zstd, mingw-minizip, mingw-python-psycopg2
Hopefully someone can get to them before me, I'm swamped with $DAYJOB, but if not, I'll see if I can find sometime within the next week or so. Thanks, Richard ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
systemd v247-rc2 (app.slice, oomd, udev rule changes, light deps)
Hi, we're getting ready to push systemd 247-rc2 to rawhide. This is currently blocked by selinux (see below), but I wanted to give a heads-up. There's a number of changes which are interesting for Fedora: - user units (under user@nnn.service) are segregated into app.slice, session.slice, background.slice. By itself this doesn't do much, but it'll allow e.g. kernel memory protections to be applied to session.slice, ensuring that gnome-shell remains responsive even with high memory contention. This change requires further changes from desktop environments to put appropriate units in the respective slices, so the changes in systemd are just the beginning of the process. - systemd-oomd and oomctl are available, but should be considered "technical preview" (backwards-incompatible changes may still happen). oomd doesn't do anything without configuration, so for anyone interested in this, now is a good moment to experiment with policy settings and suggest some defaults to upstream. - udev rules might need to be adjusted to handle new "bind" and "unbind" events emitted by the kernel. Despite multiple attempts, we couldn't find a way to handle this change in udev in a way that would preserve compatibility with existing rules. See the NEWS file [1] for details. - some non-essential libraries are now loaded using dlopen(). Dependencies in packages have been downgraded from "Requires" to "Recommends" (libpwquality, libqrencode, libxkbcommon, libidn2, libcryptsetup). This will result in smaller installation footprint, but users may need to explicitly install some dependencies. (This only matters where install_weak_deps=False, i.e. not on normal user installations.) - nss-resolve now talks to systemd-resolved using a direct varlink connection, instead of a dbus connection through the system broker. This means that name resolution using resolved is available immediately after resolved is up, while previously it required dbus-broker.service to up, which happens relatively late. There's a bunch of other changes too, see NEWS [1]. The new version is not built in rawhide yet because we're waiting for the selinux policy update [2]. (The biggest problem is selinux policy blocking the check if selinux is enabled ;)). Builds are available in side tag f34-build-side-33917 [3]. [1] https://github.com/systemd/systemd/blob/v247-rc2/NEWS [2] https://github.com/fedora-selinux/selinux-policy/pull/464 [3] https://koji.fedoraproject.org/koji/taskinfo?taskID=55456626 Zbyszek ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: patch applied without package maintainers' approve
On Wed, Nov 11, 2020 at 03:17:47PM +, Peter Robinson wrote: > > I'm one of package maintainers of rdma-core. There is a patch > > applied without any maintainers' review/approve. I had sent two emails > > to patch committer to ask him/her to push the change to upstream. > > But never get response. > > So someone pinged me on IRC about this, I never saw the emails because > you replied to the git commit and I auto archive/mute all those emails > because I get a LOT of them. You never tried other communication > mechanisms that I'm aware of such are IRC. > > Also note there is no packaging requirements to get approval from > package maintainers. > > > The patch maybe useful or fix something. But the divergence between > > upstream and Fedora rawhide is what I don't want to see, because > > such divergence is source of regression issues. > > The addition of libpcap linking against libibverbs pulled in a whole > of extra dependencies that aren't used by Workstation/Cloud or > anything that doesn't have infinband. So this just splits it out to a > smaller package, for a IB user they will see nothing different. Split the package make sense. But you create a new sub-package with name "libibverbs-core". I don't agree with the new name. The original libibverbs package only includes the VERBs API library. https://www.openfabrics.org/downloads/libibverbs/ In 2016, user-space drivers/providers, such as libmlx4, had been merged libibverbs. We may should keep libibverbs only includes the VERBs API library. And create a new sub-package as "libibverbs-providers". I will discuss this with upstream. > I don't see how a spec file change is a "regression", there's nothing RHEL rdma-core builds are based on Fedora builds. Each time, when update upstream rdma-core for RHEL, I will pull changes from Fedora repo if such changes should be applied for RHEL too. The divergence between Fedora and upstream makes my work complicated. I just checked RHEL-9 nightly build, the libibverbs-core package already in RHEL-9. I will have to handle this for RHEL-9. > that will regress here, the rdma-core depends on the package and if > anyone installs that they also get the new sub package, but if the > general user doesn't have IB hardware, which is the vast majority of > users even in the enterprise, they don't have to unnecessarily have > extra stuff clogging up their system. > > In terms of "upstream" I'm not sure what you mean there, because https://github.com/linux-rdma/rdma-core/blob/master/redhat/rdma-core.spec It is the "upstream" spec file. > upstream of Fedora is generally tar files but do feel free to push the > change upstream if you prefer that for managing stuff. I will work with upstream to split the libibverbs package. > > Peter > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Timeshift for Fedora with BTRFS
On Thu, Nov 12, 2020 at 3:37 AM Willi Mutschler wrote: > > Hi, > > I just recently joined the Fedora train and am very excited about it. As I am > a developer of timeshift-autosnap and timeshift-autosnap-apt, I wanted to > have the same functionality in Fedora 33. The idea is that when one runs a > dnf update or upgrade command, timeshift should automatically create a btrfs > snapshot. So basyically the same functionality of zsys in Ubuntu with ZFS, > but with Timeshift. > The idea is, whether one likes it or not, Timeshift is quite popular in the > Linux user space (and gets mentions on the Linux podcasts all the time). > Having it work on Fedora with BTRFS would be quite an asset in my opinion, > and make btrfs more user-friendly (as users can see in a GUI that snapshots > happen instantenously). Anyways, Is there interest in the Fedora devel > community here or is the development actually going another direction? > > I am working on a fork of Timeshift (https://github.com/wmutschl/timeshift), > where currently I hardcoded the BTRFS subvolume layout of Fedora 33 into > Timeshift and it works as it should without renaming the subvolumes to @ and > @home (which is also possible). > Now the next steps (in my opinion or maybe someone has better ideas) would be > to: > 1. Make an interface inside Timeshift to set the names of the BTRFS > subvolumes and try to get it merged upstream. > 2. Adapt timeshift-autosnap (or timeshift-autosnap-apt) for dnf (e.g. create > a dnf plugin similar to the snapper plugin) that makes automatic snapshots > before any DNF operation. > 3. Add the autosnap functionality (of pacman, apt, and hopefully dnf) also > into Timeshift and get it merged upstream. > > Is that a feasible plan? Any feedback is very much appreciated! This sounds very good! I don't particularly like the Ubuntu subvolume layout (which is a subset of the openSUSE subvolume layout), so having Timeshift adapted to support our layout (or even custom layouts in general) would make this much better. :) I expect that what you're trying to do should be feasible, especially since it's been done before with Snapper (which unfortunately lacks a GUI). -- 真実はいつも一つ！/ 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
Fedora-Cloud-31-20201112.0 compose check report
No missing expected images. Passed openQA tests: 7/7 (x86_64), 7/7 (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
Review request: mingw-zstd, mingw-minizip, mingw-python-psycopg2
Hi I've posted some more review requests for mingw packages: - mingw-zstd: https://bugzilla.redhat.com/show_bug.cgi?id=1897115 - mingw-minizip: https://bugzilla.redhat.com/show_bug.cgi?id=1897116 - mingw-python-psycopg2: https://bugzilla.redhat.com/show_bug.cgi?id=1896179 I'd need mingw-zstd and mingw-minizip in particular, as mingw-minizip is a new dependency for mingw-libspatialite, which i need to update for the mingw-proj update I'm working on. Happy to review in exchange. Thanks Sandro ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Lightly-maintained packages (was: Summary/Minutes from today's FESCo Meeting (2020-11-11))
* Miroslav Suchý [11/11/2020 18:05] : > > We already have "lightly-maintained packages" - it is called Copr projects. > Do we need something in between? The issue here is discoverabilty. If $PACKAGE is in a separate repository, be it a 'lightly-maintained' repo or a copr, how do we go about communicating to users wanting to install it that they need to activate that repository and that the software they download from it may or may not work? Emmanuel ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Fedora-Cloud-32-20201112.0 compose check report
No missing expected images. Soft failed openQA tests: 1/7 (x86_64), 1/7 (aarch64) (Tests completed, but using a workaround for a known bug) Old soft failures (same test soft failed in Fedora-Cloud-32-2020.0): ID: 721144 Test: x86_64 Cloud_Base-qcow2-qcow2 cloud_autocloud URL: https://openqa.fedoraproject.org/tests/721144 ID: 721151 Test: aarch64 Cloud_Base-qcow2-qcow2 cloud_autocloud@uefi URL: https://openqa.fedoraproject.org/tests/721151 Passed openQA tests: 6/7 (x86_64), 6/7 (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
Re: Proposed updates to the FESCo updates policy document
On Wed, Nov 11, 2020 at 06:36:54PM +, Mattia Verga via devel wrote: > Il 11/11/20 16:56, Kevin Fenzi ha scritto: > > Greetings. > > > > FESCo is looking to update the updates policy document that is here: > > > > https://docs.fedoraproject.org/en-US/fesco/Updates_Policy/ > > > > For the most part the updates are not changing any policy, but simply > > removing old/no longer accurate information (taskotron no longer exists, > > bodhi is always enabled, etc) and trying to clarify things. > > > > The one actual proposed change is to allow releng to untag builds that > > have already gone out in rawhide composes. This was forbidden by the > > existing policy. > > > > You can see the PR with the changes: > > > > https://pagure.io/fesco/fesco-docs/pull-request/40 > > > > and if you want to view the changed document: > > > > https://pagure.io/fork/kevin/fesco/fesco-docs/raw/updates-update/f/fesco/modules/ROOT/pages/Updates_Policy.adoc > > (you may want to install a adoc viewing extension in your browser to > > view it) > > > > Feedback welcome here or in the PR. > > > > FESCo is likely to look at this next week for approval. > > > > Thanks! > > > > kevin > > Hi kevin, > > I've tried to summarize some of the aspects of the (updated) policy in > an image [1], is that right? I don't fully understand the difference > between the Beta during final freeze and Pre release... I think you are splitting one "phase" into two: "beta" and "pre-release". That should be just one phase called "pre-release". The "final freeze" block is part of that one phase, similarly to how "beta freeze" block is part of "pre-beta". I read the PR again, and it seems to me that the text matches my description above, i.e. it only has one phase. > As a side note, it would be nice to have a link in > docs.fedoraproject.org main page to the fesco section, I currently can't > found and didn't know he existence of it before you posted the link ;-) +1 > [1] https://pasteboard.co/JzTXVfv.png That picture is great. It would be nice include it in the docs, except that we'd need the "source" version (svg?). 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
Timeshift for Fedora with BTRFS
Hi, I just recently joined the Fedora train and am very excited about it. As I am a developer of timeshift-autosnap and timeshift-autosnap-apt, I wanted to have the same functionality in Fedora 33. The idea is that when one runs a dnf update or upgrade command, timeshift should automatically create a btrfs snapshot. So basyically the same functionality of zsys in Ubuntu with ZFS, but with Timeshift. The idea is, whether one likes it or not, Timeshift is quite popular in the Linux user space (and gets mentions on the Linux podcasts all the time). Having it work on Fedora with BTRFS would be quite an asset in my opinion, and make btrfs more user-friendly (as users can see in a GUI that snapshots happen instantenously). Anyways, Is there interest in the Fedora devel community here or is the development actually going another direction? I am working on a fork of Timeshift (https://github.com/wmutschl/timeshift), where currently I hardcoded the BTRFS subvolume layout of Fedora 33 into Timeshift and it works as it should without renaming the subvolumes to @ and @home (which is also possible). Now the next steps (in my opinion or maybe someone has better ideas) would be to: 1. Make an interface inside Timeshift to set the names of the BTRFS subvolumes and try to get it merged upstream. 2. Adapt timeshift-autosnap (or timeshift-autosnap-apt) for dnf (e.g. create a dnf plugin similar to the snapper plugin) that makes automatic snapshots before any DNF operation. 3. Add the autosnap functionality (of pacman, apt, and hopefully dnf) also into Timeshift and get it merged upstream. Is that a feasible plan? Any feedback is very much appreciated! Cheers, Willi --- https://mutschler.eu/linux ___ 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
