Re: Orphaning tinymce
On 15/02/2020 21:12, Kevin Fenzi wrote: > Greetings. > > I was (probibly poorly) maintaining tinymce for a while because we used > it for askbot. We no longer do need it so I am going to orphan it and > hope someone out there has more time and energy to give it the love it > needs. > > There's currently some CVE's filed against it. > > It's on versuon 4.5.1 and 5.0 is current. > Thank you for keeping it alive for so long. I don't have any use for tinymce (anymore), and from my perspective, it can get removed. Matthias signature.asc 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
[389-devel] Please review 50900 fix cargo offline
https://pagure.io/389-ds-base/pull-request/50900 — Sincerely, William Brown Senior Software Engineer, 389 Directory Server SUSE Labs ___ 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
[389-devel] 389 DS nightly 2020-02-17 - 96% PASS
https://fedorapeople.org/groups/389ds/ci/nightly/2020/02/17/report-389-ds-base-1.4.3.3-20200217git2f8fbe2.fc31.x86_64.html ___ 389-devel mailing list -- 389-devel@lists.fedoraproject.org To unsubscribe send an email to 389-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/389-devel@lists.fedoraproject.org
Orphaned package: cuneiform
Subj is an OCR system which needs to much love to be alive that I haven't. It's not required from any other package, it never had upstream from he very beginning and it is a `tesseract` OCR to switch to. So it's time to say good bye for me. It would be nice if anybody could adopt it (but I do not believe this could ever happen). See also: https://bugzilla.redhat.com/show_bug.cgi?id=1799265 and I believe there are no opened bugs. Package page: https://src.fedoraproject.org/rpms/cuneiform Regards, Dmitrij ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
[EPEL-devel] Fedora EPEL 8 updates-testing report
The following Fedora EPEL 8 Security updates need testing: Age URL 6 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2020-0e6e3f93b6 mbedtls-2.16.4-1.el8 6 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2020-e016baf8b3 cacti-1.2.9-1.el8 cacti-spine-1.2.9-1.el8 0 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2020-eac9cef8cf hiredis-0.13.3-13.el8 The following builds have been pushed to Fedora EPEL 8 updates-testing byobu-5.132-1.el8 converseen-0.9.8.1-1.el8 snapd-2.43.3-1.el8 snapd-glib-1.55-1.el8 verilator-4.028-1.el8 worker-4.3.0-1.el8 xapian-core-1.4.14-1.el8 Details about builds: byobu-5.132-1.el8 (FEDORA-EPEL-2020-6fb038faad) Light-weight, configurable window manager built upon GNU screen Update Information: - Update to 5.132 fixes rhbz#1803380 ChangeLog: * Sun Feb 16 2020 Filipe Rosset - 5.132-1 - Update to 5.132 fixes rhbz#1803380 * Tue Feb 11 2020 Filipe Rosset - 5.131-1 - Update to 5.131 fixes rhbz#1800974 * Tue Jan 28 2020 Fedora Release Engineering - 5.130-2 - Rebuilt for https://fedoraproject.org/wiki/Fedora_32_Mass_Rebuild References: [ 1 ] Bug #1800974 - byobu-5.131 is available https://bugzilla.redhat.com/show_bug.cgi?id=1800974 [ 2 ] Bug #1803380 - byobu-5.132 is available https://bugzilla.redhat.com/show_bug.cgi?id=1803380 converseen-0.9.8.1-1.el8 (FEDORA-EPEL-2020-c84831dfb4) A batch image conversion tool written in C++ with Qt5 and Magick++ Update Information: - Update to 0.9.8.1 fixes rhbz#1797385 ChangeLog: * Sun Feb 16 2020 Filipe Rosset - 0.9.8.1-1 - Update to 0.9.8.1 fixes rhbz#1797385 * Tue Jan 28 2020 Fedora Release Engineering - 0.9.8.0-2 - Rebuilt for https://fedoraproject.org/wiki/Fedora_32_Mass_Rebuild References: [ 1 ] Bug #1797385 - converseen-0.9.8.1 is available https://bugzilla.redhat.com/show_bug.cgi?id=1797385 snapd-2.43.3-1.el8 (FEDORA-EPEL-2020-f049520d10) A transactional software package manager Update Information: Update to snapd 2.43 and snapd-glib 1.55 ## snapd-2.43 highlights * `snapctl is-connected plug|slot` * Remodel: gadget support * Plug/slot declaration rules: greedy plugs * `system-backup` interface * Speedup seccomp backend setup ## snapd-glib-1.55 highlights * Add new APIs for download and logout actions * Add support for snap store logout * Fix `QSnapdAuthData ()` constructor not copying discharge strings correctly * Remove obsolete screenshot parsing code * Make all snapd 404 errors return `SNAPD_ERROR_NOT_FOUND` ChangeLog: * Thu Feb 13 2020 Maciek Borzecki - 2.43.3-1 - Release 2.43.3 to Fedora (RHBZ#1777328) * Wed Feb 12 2020 Michael Vogt - New upstream release 2.43.3 - interfaces/opengl: allow datagrams to nvidia-driver - httputil: add NoNetwork(err) helper, spread test and use in serial acquire - interfaces: add uio interface - interfaces/greengrass-support: 'aws-iot-greengrass' snap fails to start due to apparmor deny on mounting of "/proc/latency_stats". - data, packaging: Add sudoers snippet to allow snaps to be run with sudo * Thu Jan 30 2020 Fedora Release Engineering - 2.42.2-2 - Rebuilt for https://fedoraproject.org/wiki/Fedora_32_Mass_Rebuild * Tue Jan 28 2020 Michael Vogt - New upstream release 2.43.2 - cmd/snap-confine: Revert #7421 (unmount /writable from snap view) - overlord/snapstate: fix for re-refresh bug - tests, run-checks, many: fix nakedret issues - data/selinux: workaround incorrect fonts cache labeling on RHEL7 - tests: use test-snapd-upower instead of upower - overlord: increase overall settle timeout for slow arm boards * Tue Jan 14 2020 Michael Vogt - New upstream release 2.43.1 - devicestate: use httputil.ShouldRetryError() in prepareSerialRequest - overlord/standby: fix possible deadlock in standby test - cmd/snap-discard-ns: fix pattern for .info files - overlord,o/snapstate: make sure we never leave config behind - data/selinux:
[Bug 1797154] perl-Modern-Perl-1.20200201 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1797154 Fedora Update System changed: What|Removed |Added Fixed In Version|perl-Modern-Perl-1.20200201 |perl-Modern-Perl-1.20200201 |-1.fc32 |-1.fc32 |perl-Modern-Perl-1.20200201 |perl-Modern-Perl-1.20200201 |-1.fc31 |-1.fc31 |perl-Modern-Perl-1.20200201 |perl-Modern-Perl-1.20200201 |-1.fc30 |-1.fc30 |perl-Modern-Perl-1.20200201 |perl-Modern-Perl-1.20200201 |-1.el8 |-1.el8 ||perl-Modern-Perl-1.20200201 ||-1.el7 --- Comment #13 from Fedora Update System --- perl-Modern-Perl-1.20200201-1.el7 has been pushed to the Fedora EPEL 7 stable repository. If problems still persist, please make note of it in this bug report. -- You are receiving this mail because: You are on the CC list for the bug. ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org
[Bug 1797154] perl-Modern-Perl-1.20200201 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1797154 Fedora Update System changed: What|Removed |Added Fixed In Version|perl-Modern-Perl-1.20200201 |perl-Modern-Perl-1.20200201 |-1.fc32 |-1.fc32 |perl-Modern-Perl-1.20200201 |perl-Modern-Perl-1.20200201 |-1.fc31 |-1.fc31 |perl-Modern-Perl-1.20200201 |perl-Modern-Perl-1.20200201 |-1.fc30 |-1.fc30 ||perl-Modern-Perl-1.20200201 ||-1.el8 --- Comment #12 from Fedora Update System --- perl-Modern-Perl-1.20200201-1.el8 has been pushed to the Fedora EPEL 8 stable repository. If problems still persist, please make note of it in this bug report. -- You are receiving this mail because: You are on the CC list for the bug. ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org
[Bug 1801905] perl-Mojolicious-8.33 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1801905 Emmanuel Seyman changed: What|Removed |Added Status|NEW |CLOSED Fixed In Version||perl-Mojolicious-8.33-1.fc3 ||3 Resolution|--- |RAWHIDE Doc Type|--- |If docs needed, set a value Last Closed||2020-02-16 23:49:03 --- Comment #1 from Emmanuel Seyman --- Built for rawhide: https://koji.fedoraproject.org/koji/buildinfo?buildID=1462620 -- 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
Disabling Fedora 29 chroots in Copr
Hello, we have just disabled Fedora 29 chroots in Copr. According to the Fedora wiki [1], Fedora 29 reached the end of its life on 2019-11-30 and therefore we are disabling it in Copr. That effectively means that from this moment, it is no longer possible to submit builds for the following chroots: - fedora-29-x86_64 - fedora-29-i386 - fedora-29-ppc64le - fedora-29-aarch64 Additionally, according to Outdated chroots removal policy [2], Copr is going to preserve existing build results in those chroots for another 180 days and then automatically remove them unless you take an action and prolong the chroots life span in your projects. Read more about this feature in the Copr - Removing outdated chroots blog post [3]. [1] https://fedoraproject.org/wiki/End_of_life [2] https://docs.pagure.org/copr.copr/copr_outdated_chroots_removal_policy.html [3] http://frostyx.cz/posts/copr-removing-outdated-chroots Jakub ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
[Bug 1803552] perl-Devel-Hide-0.0013 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1803552 --- Comment #2 from Upstream Release Monitoring --- the-new-hotness/release-monitoring.org's scratch build of perl-Devel-Hide-0.0013-1.fc30.src.rpm for rawhide completed http://koji.fedoraproject.org/koji/taskinfo?taskID=41527656 -- You are receiving this mail because: You are on the CC list for the bug. ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org
[Bug 1803552] perl-Devel-Hide-0.0013 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1803552 --- Comment #1 from Upstream Release Monitoring --- Created attachment 1663376 --> https://bugzilla.redhat.com/attachment.cgi?id=1663376=edit [patch] Update to 0.0013 (#1803552) -- You are receiving this mail because: You are on the CC list for the bug. ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org
[Bug 1803552] New: perl-Devel-Hide-0.0013 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1803552 Bug ID: 1803552 Summary: perl-Devel-Hide-0.0013 is available Product: Fedora Version: rawhide Status: NEW Component: perl-Devel-Hide Keywords: FutureFeature, Triaged Assignee: p...@city-fan.org Reporter: upstream-release-monitor...@fedoraproject.org QA Contact: extras...@fedoraproject.org CC: iarn...@gmail.com, p...@city-fan.org, perl-devel@lists.fedoraproject.org Target Milestone: --- Classification: Fedora Latest upstream release: 0.0013 Current version/release in rawhide: 0.0012-1.fc33 URL: http://search.cpan.org/dist/Devel-Hide/ Please consult the package updates policy before you issue an update to a stable branch: https://fedoraproject.org/wiki/Updates_Policy More information about the service that created this bug can be found at: https://fedoraproject.org/wiki/Upstream_release_monitoring Please keep in mind that with any upstream change, there may also be packaging changes that need to be made. Specifically, please remember that it is your responsibility to review the new version to ensure that the licensing is still correct and that no non-free or legally problematic items have been added upstream. Based on the information from anitya: https://release-monitoring.org/project/11938/ -- You are receiving this mail because: You are on the CC list for the bug. ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org
Re: Change proposal discussion - Optimize SquashFS Size
On Sun, 16 Feb 2020 10:57:26 -0700 "John M. Harris Jr" wrote: > On Monday, February 10, 2020 10:53:45 AM MST Jared K. Smith wrote: > > On Mon, Feb 10, 2020 at 3:30 AM John M. Harris Jr > > > > > > wrote: > > > As for the software available, that's called choice. I know > > > it's a relative unknown in the GNOME world, as one option is > > > shoved down everyones' throat, but it's a key part of the KDE > > > ideology, as well as GNU/ > > > Linux itself. > > > > John, it's obvious from your posts in this list that you're not a > > fan of GNOME. I'd kindly ask you to please refrain from attacking > > GNOME, especially when the discussion at hand isn't about GNOME > > itself. It's not in keeping with the "be excellent to each other" > > spirit that Fedora likes to keep in its mailing lists. > > > > -- > > Jared Smith > > An observation is not an attack. What I said about GNOME is simply > true, and is commonly considered a good thing by GNOME developers on > this list. I just don't agree with that, and thus far there is no > rule against disagreeing with the GNOME mindset. No dog in this fight, so I'll probably get my just desserts for butting in, but even if what you said about gnome is true, the way you stated your viewpoint would be considered hostile and attacking by an unbiased bystander. Me, for instance. There was no need to throw in the put down of gnome. You could have just said, "... called choice, one of the basic principles of GNU / 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
Re: URGENT: users prompted to upgrade to F32
On Saturday, February 15, 2020, Kevin Fenzi wrote: > On Fri, Feb 14, 2020 at 05:14:57PM -0800, Adam Williamson wrote: > > On Fri, 2020-02-14 at 18:37 -0600, Michael Catanzaro wrote: > > > Hi, > > > > > > Users are being prompted to upgrade to F32. Anyone who knows how to > fix > > > this, please help with > > > https://pagure.io/fedora-infrastructure/issue/8652 ASAP. > > > > We fixed it several hours ago, but people are likely hitting copies of > > the bad data cached somewhere along the line :/ > > > > https://pagure.io/fedora-infrastructure/issue/8652#comment-626587 > > Yeah, it was live for about 45min this morning, but we fixed it as soon > as it was noted. ;( > > Not sure that there is too much more we can do at this point... > > What can we do to ensure it does not happen 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
Re: RFC: Security policy adjustments to make it easier to implement and more friendly to maintainers
On Sun, Feb 16, 2020 at 8:29 PM Chris Murphy wrote: > > On Sun, Feb 16, 2020 at 11:59 AM Fabio Valentini wrote: > > > > On Sun, Feb 16, 2020 at 7:45 PM Neal Gompa wrote: > > > > > > On Thu, Feb 13, 2020 at 3:37 PM Chris Murphy > > > wrote: > > > > > > > > On Thu, Feb 13, 2020 at 12:53 PM David Cantrell > > > > wrote: > > > > > > > > > > Similarly, a package with a medium CVE NEW bugzilla would be > > > > > > orphaned after 4 > > > > > > reminders (after 9-12 weeks), retired at a point if still not > > > > > > CLOSED after 4 months. > > > > > > > > > > > > With low severity, that is 6 reminders (after 15-18 weeks), retired > > > > > > at a point > > > > > > if still not CLOSED after 6 months (similarly to the current > > > > > > policy). > > > > > > > > > > Where do get bug severity information? > > > > > > > > Fedora Workstation WG has an issue "Reconsider updates policy" that > > > > relates to this question. > > > > https://pagure.io/fedora-workstation/issue/107 > > > > > > > > If there are any security updates, GNOME Software pops up a > > > > notification to install them. This thwarts attempts to avoid nagging > > > > the user, because so many updates contain some sort of security > > > > mitigation. One proposal is to not treat security updates as special, > > > > and still wait until a week has passed for the update. > > > > > > > > But the contra argument is, well what if there is an urgent security > > > > fix? > > > > > > > > The repo metadata, I guess, needs some way of distinguishing urgent vs > > > > non-urgent security updates, so that GNOME Software knows whether to > > > > notify the user accordingly. But is there a reliable way of > > > > distinguishing between urgent and non-urgent security updates? I'd > > > > informally suggest "urgent" is something that should be applied today > > > > or tomorrow. Anything else can wait a week or two. > > > > > > > > (snip) > > > > > The repo metadata has the property, so packagers just have to set it > > > in Bodhi when submitting updates. It defaults to unspecified. > > > > It *does* default to unspecified, yes. However, when submitting an > > update of type "security", bodhi won't let you even submit the update > > unless you set the severity to something other than "unspecified". > (snip) > Is there a distribution wide definition for these four severities? > Ideally, urgent should be a high bar, and I wonder if it's possible > many updates tagged as urgent are actually high severity? > https://github.com/fedora-infra/bodhi/blob/develop/bodhi/client/bindings.py#L262 I don't know what the policy is for this, but when I get a CVE bugzilla filed against one of my packages, and I fix it with an update, I set the severity of the update to be the same as the severity of the CVE bug, and I think that's the obvious choice (also, the names of those severities are identical, so I think that's the intention). Fabio > > > > -- > Chris Murphy > ___ > 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: RFC: Security policy adjustments to make it easier to implement and more friendly to maintainers
On Sunday, February 16, 2020 12:28:32 PM MST Chris Murphy wrote: > On Sun, Feb 16, 2020 at 11:59 AM Fabio Valentini > wrote: > > > > > > On Sun, Feb 16, 2020 at 7:45 PM Neal Gompa wrote: > > > > > > > > > > > On Thu, Feb 13, 2020 at 3:37 PM Chris Murphy > > > wrote: > > > > > > > > > > > > > > On Thu, Feb 13, 2020 at 12:53 PM David Cantrell > > > > wrote: > > > > > > > > > > > > > > > > > > Similarly, a package with a medium CVE NEW bugzilla would be > > > > > > orphaned after 4 reminders (after 9-12 weeks), retired at a > > > > > > point if still not CLOSED after 4 months.> > > > > > > > > > > > > > > > > > > > > > > With low severity, that is 6 reminders (after 15-18 weeks), > > > > > > retired at a point if still not CLOSED after 6 months (similarly > > > > > > to the current policy).> > > > > > > > > > > > > > > > > > > Where do get bug severity information? > > > > > > > > > > > > > > > > Fedora Workstation WG has an issue "Reconsider updates policy" that > > > > relates to this question. > > > > https://pagure.io/fedora-workstation/issue/107 > > > > > > > > > > > > > > > > If there are any security updates, GNOME Software pops up a > > > > notification to install them. This thwarts attempts to avoid nagging > > > > the user, because so many updates contain some sort of security > > > > mitigation. One proposal is to not treat security updates as special, > > > > and still wait until a week has passed for the update. > > > > > > > > > > > > > > > > But the contra argument is, well what if there is an urgent security > > > > fix? > > > > > > > > > > > > > > > > The repo metadata, I guess, needs some way of distinguishing urgent > > > > vs > > > > non-urgent security updates, so that GNOME Software knows whether to > > > > notify the user accordingly. But is there a reliable way of > > > > distinguishing between urgent and non-urgent security updates? I'd > > > > informally suggest "urgent" is something that should be applied today > > > > or tomorrow. Anything else can wait a week or two. > > > > > > > > > > > > > > > > (snip) > > > > > > > > > The repo metadata has the property, so packagers just have to set it > > > in Bodhi when submitting updates. It defaults to unspecified. > > > > > > > > It *does* default to unspecified, yes. However, when submitting an > > update of type "security", bodhi won't let you even submit the update > > unless you set the severity to something other than "unspecified". > > > > Is there a distribution wide definition for these four severities? > Ideally, urgent should be a high bar, and I wonder if it's possible > many updates tagged as urgent are actually high severity? > https://github.com/fedora-infra/bodhi/blob/develop/bodhi/client/bindings.py# > L262 Really, a security update is a security update. It should be applied ASAP, regardless. -- John M. Harris, Jr. Splentity ___ 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: RFC: Security policy adjustments to make it easier to implement and more friendly to maintainers
On Sun, Feb 16, 2020 at 11:59 AM Fabio Valentini wrote: > > On Sun, Feb 16, 2020 at 7:45 PM Neal Gompa wrote: > > > > On Thu, Feb 13, 2020 at 3:37 PM Chris Murphy > > wrote: > > > > > > On Thu, Feb 13, 2020 at 12:53 PM David Cantrell > > > wrote: > > > > > > > > Similarly, a package with a medium CVE NEW bugzilla would be orphaned > > > > > after 4 > > > > > reminders (after 9-12 weeks), retired at a point if still not CLOSED > > > > > after 4 months. > > > > > > > > > > With low severity, that is 6 reminders (after 15-18 weeks), retired > > > > > at a point > > > > > if still not CLOSED after 6 months (similarly to the current policy). > > > > > > > > Where do get bug severity information? > > > > > > Fedora Workstation WG has an issue "Reconsider updates policy" that > > > relates to this question. > > > https://pagure.io/fedora-workstation/issue/107 > > > > > > If there are any security updates, GNOME Software pops up a > > > notification to install them. This thwarts attempts to avoid nagging > > > the user, because so many updates contain some sort of security > > > mitigation. One proposal is to not treat security updates as special, > > > and still wait until a week has passed for the update. > > > > > > But the contra argument is, well what if there is an urgent security fix? > > > > > > The repo metadata, I guess, needs some way of distinguishing urgent vs > > > non-urgent security updates, so that GNOME Software knows whether to > > > notify the user accordingly. But is there a reliable way of > > > distinguishing between urgent and non-urgent security updates? I'd > > > informally suggest "urgent" is something that should be applied today > > > or tomorrow. Anything else can wait a week or two. > > > > > (snip) > > > The repo metadata has the property, so packagers just have to set it > > in Bodhi when submitting updates. It defaults to unspecified. > > It *does* default to unspecified, yes. However, when submitting an > update of type "security", bodhi won't let you even submit the update > unless you set the severity to something other than "unspecified". Is there a distribution wide definition for these four severities? Ideally, urgent should be a high bar, and I wonder if it's possible many updates tagged as urgent are actually high severity? https://github.com/fedora-infra/bodhi/blob/develop/bodhi/client/bindings.py#L262 -- Chris Murphy ___ 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: RFC: Security policy adjustments to make it easier to implement and more friendly to maintainers
On Sunday, February 16, 2020 12:25:01 PM MST Neal Gompa wrote: > On Sun, Feb 16, 2020 at 2:23 PM John M. Harris Jr > wrote: > > > > > > On Sunday, February 16, 2020 12:19:41 PM MST Chris Murphy wrote: > > > > > On Sun, Feb 16, 2020 at 11:08 AM John M. Harris Jr > > > > > > wrote: > > > > > > > > > > > > > > > > > > > On Thursday, February 13, 2020 1:34:32 PM MST Chris Murphy wrote: > > > > > > > > > > > > > > > > > But the contra argument is, well what if there is an urgent > > > > > security > > > > > fix? > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > The repo metadata, I guess, needs some way of distinguishing urgent > > > > > vs > > > > > non-urgent security updates, so that GNOME Software knows whether > > > > > to > > > > > notify the user accordingly. But is there a reliable way of > > > > > distinguishing between urgent and non-urgent security updates? I'd > > > > > informally suggest "urgent" is something that should be applied > > > > > today > > > > > or tomorrow. Anything else can wait a week or two. > > > > > > > > > > > > > > > > > > > > > > > > That's an entirely subjective thing. I'd recommend prompting to > > > > install > > > > ALL security updates immediately, but why not just give the user an > > > > option for security updates? This is what Mac and Windows do, and it > > > > makes sense because it's really the user's opinion of security > > > > updates > > > > that matter on their system. > > > > > > > > > > > > > > > Windows has a weekly security and virus definitions update, not every > > > day. Windows Home has no user visible opt out. macOS separates minor > > > version updates and security updates, security updates aren't more > > > often than every few weeks. There's a very rare category of critical > > > security updates that Apple can forcibly push onto user's machine > > > without consent. > > > > > > > > > > > > The complaint on Fedora Workstation relates to frequent, sometimes > > > daily, update notifications because a package has a security related > > > update. The question is how to reduce this to once a week. > > > > > > > > If that's the question, that's what you should have asked. Really, that's > > not something that should be done. Security updates are called security > > updates for a reason. > > > > > > > Yes they are, but it's also about sensible risk management. Most home > users can put off *most* updates (security or otherwise) for a month > without too much worrying. Business users may have a different risk > profile, depending on network topology and other factors. That's for the user to decide. In my opinion, if they're taking that device off of their home network, their risk profile changes dramatically. -- John M. Harris, Jr. Splentity ___ 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: RFC: Security policy adjustments to make it easier to implement and more friendly to maintainers
On Sun, Feb 16, 2020 at 2:23 PM John M. Harris Jr wrote: > > On Sunday, February 16, 2020 12:19:41 PM MST Chris Murphy wrote: > > On Sun, Feb 16, 2020 at 11:08 AM John M. Harris Jr > > wrote: > > > > > > > > > On Thursday, February 13, 2020 1:34:32 PM MST Chris Murphy wrote: > > > > > > > But the contra argument is, well what if there is an urgent security > > > > fix? > > > > > > > > > > > > > > > > The repo metadata, I guess, needs some way of distinguishing urgent vs > > > > non-urgent security updates, so that GNOME Software knows whether to > > > > notify the user accordingly. But is there a reliable way of > > > > distinguishing between urgent and non-urgent security updates? I'd > > > > informally suggest "urgent" is something that should be applied today > > > > or tomorrow. Anything else can wait a week or two. > > > > > > > > > > > > That's an entirely subjective thing. I'd recommend prompting to install > > > ALL security updates immediately, but why not just give the user an > > > option for security updates? This is what Mac and Windows do, and it > > > makes sense because it's really the user's opinion of security updates > > > that matter on their system. > > > > > > Windows has a weekly security and virus definitions update, not every > > day. Windows Home has no user visible opt out. macOS separates minor > > version updates and security updates, security updates aren't more > > often than every few weeks. There's a very rare category of critical > > security updates that Apple can forcibly push onto user's machine > > without consent. > > > > The complaint on Fedora Workstation relates to frequent, sometimes > > daily, update notifications because a package has a security related > > update. The question is how to reduce this to once a week. > > If that's the question, that's what you should have asked. Really, that's not > something that should be done. Security updates are called security updates > for a reason. > Yes they are, but it's also about sensible risk management. Most home users can put off *most* updates (security or otherwise) for a month without too much worrying. Business users may have a different risk profile, depending on network topology and other factors. -- 真実はいつも一つ！/ Always, there's only one truth! ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: RFC: Security policy adjustments to make it easier to implement and more friendly to maintainers
On Sunday, February 16, 2020 12:19:41 PM MST Chris Murphy wrote: > On Sun, Feb 16, 2020 at 11:08 AM John M. Harris Jr > wrote: > > > > > > On Thursday, February 13, 2020 1:34:32 PM MST Chris Murphy wrote: > > > > > But the contra argument is, well what if there is an urgent security > > > fix? > > > > > > > > > > > > The repo metadata, I guess, needs some way of distinguishing urgent vs > > > non-urgent security updates, so that GNOME Software knows whether to > > > notify the user accordingly. But is there a reliable way of > > > distinguishing between urgent and non-urgent security updates? I'd > > > informally suggest "urgent" is something that should be applied today > > > or tomorrow. Anything else can wait a week or two. > > > > > > > > That's an entirely subjective thing. I'd recommend prompting to install > > ALL security updates immediately, but why not just give the user an > > option for security updates? This is what Mac and Windows do, and it > > makes sense because it's really the user's opinion of security updates > > that matter on their system. > > > Windows has a weekly security and virus definitions update, not every > day. Windows Home has no user visible opt out. macOS separates minor > version updates and security updates, security updates aren't more > often than every few weeks. There's a very rare category of critical > security updates that Apple can forcibly push onto user's machine > without consent. > > The complaint on Fedora Workstation relates to frequent, sometimes > daily, update notifications because a package has a security related > update. The question is how to reduce this to once a week. If that's the question, that's what you should have asked. Really, that's not something that should be done. Security updates are called security updates for a reason. -- John M. Harris, Jr. Splentity ___ 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: RFC: Security policy adjustments to make it easier to implement and more friendly to maintainers
On Sun, Feb 16, 2020 at 11:08 AM John M. Harris Jr wrote: > > On Thursday, February 13, 2020 1:34:32 PM MST Chris Murphy wrote: > > But the contra argument is, well what if there is an urgent security fix? > > > > The repo metadata, I guess, needs some way of distinguishing urgent vs > > non-urgent security updates, so that GNOME Software knows whether to > > notify the user accordingly. But is there a reliable way of > > distinguishing between urgent and non-urgent security updates? I'd > > informally suggest "urgent" is something that should be applied today > > or tomorrow. Anything else can wait a week or two. > > That's an entirely subjective thing. I'd recommend prompting to install ALL > security updates immediately, but why not just give the user an option for > security updates? This is what Mac and Windows do, and it makes sense because > it's really the user's opinion of security updates that matter on their > system. Windows has a weekly security and virus definitions update, not every day. Windows Home has no user visible opt out. macOS separates minor version updates and security updates, security updates aren't more often than every few weeks. There's a very rare category of critical security updates that Apple can forcibly push onto user's machine without consent. The complaint on Fedora Workstation relates to frequent, sometimes daily, update notifications because a package has a security related update. The question is how to reduce this to once a week. -- Chris Murphy ___ 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: RFC: Security policy adjustments to make it easier to implement and more friendly to maintainers
On Sun, Feb 16, 2020 at 7:45 PM Neal Gompa wrote: > > On Thu, Feb 13, 2020 at 3:37 PM Chris Murphy wrote: > > > > On Thu, Feb 13, 2020 at 12:53 PM David Cantrell > > wrote: > > > > > > Similarly, a package with a medium CVE NEW bugzilla would be orphaned > > > > after 4 > > > > reminders (after 9-12 weeks), retired at a point if still not CLOSED > > > > after 4 months. > > > > > > > > With low severity, that is 6 reminders (after 15-18 weeks), retired at > > > > a point > > > > if still not CLOSED after 6 months (similarly to the current policy). > > > > > > Where do get bug severity information? > > > > Fedora Workstation WG has an issue "Reconsider updates policy" that > > relates to this question. > > https://pagure.io/fedora-workstation/issue/107 > > > > If there are any security updates, GNOME Software pops up a > > notification to install them. This thwarts attempts to avoid nagging > > the user, because so many updates contain some sort of security > > mitigation. One proposal is to not treat security updates as special, > > and still wait until a week has passed for the update. > > > > But the contra argument is, well what if there is an urgent security fix? > > > > The repo metadata, I guess, needs some way of distinguishing urgent vs > > non-urgent security updates, so that GNOME Software knows whether to > > notify the user accordingly. But is there a reliable way of > > distinguishing between urgent and non-urgent security updates? I'd > > informally suggest "urgent" is something that should be applied today > > or tomorrow. Anything else can wait a week or two. > > (snip) > The repo metadata has the property, so packagers just have to set it > in Bodhi when submitting updates. It defaults to unspecified. It *does* default to unspecified, yes. However, when submitting an update of type "security", bodhi won't let you even submit the update unless you set the severity to something other than "unspecified". Fabio > > -- > 真実はいつも一つ！/ Always, there's only one truth! > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: RFC: Security policy adjustments to make it easier to implement and more friendly to maintainers
On Thu, Feb 13, 2020 at 3:37 PM Chris Murphy wrote: > > On Thu, Feb 13, 2020 at 12:53 PM David Cantrell > wrote: > > > > Similarly, a package with a medium CVE NEW bugzilla would be orphaned > > > after 4 > > > reminders (after 9-12 weeks), retired at a point if still not CLOSED > > > after 4 months. > > > > > > With low severity, that is 6 reminders (after 15-18 weeks), retired at a > > > point > > > if still not CLOSED after 6 months (similarly to the current policy). > > > > Where do get bug severity information? > > Fedora Workstation WG has an issue "Reconsider updates policy" that > relates to this question. > https://pagure.io/fedora-workstation/issue/107 > > If there are any security updates, GNOME Software pops up a > notification to install them. This thwarts attempts to avoid nagging > the user, because so many updates contain some sort of security > mitigation. One proposal is to not treat security updates as special, > and still wait until a week has passed for the update. > > But the contra argument is, well what if there is an urgent security fix? > > The repo metadata, I guess, needs some way of distinguishing urgent vs > non-urgent security updates, so that GNOME Software knows whether to > notify the user accordingly. But is there a reliable way of > distinguishing between urgent and non-urgent security updates? I'd > informally suggest "urgent" is something that should be applied today > or tomorrow. Anything else can wait a week or two. > The repo metadata has the property, so packagers just have to set it in Bodhi when submitting updates. It defaults to unspecified. -- 真実はいつも一つ！/ Always, there's only one truth! ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: URGENT: users prompted to upgrade to F32
On Friday, February 14, 2020 5:37:53 PM MST Michael Catanzaro wrote: > Hi, > > Users are being prompted to upgrade to F32. Anyone who knows how to fix > this, please help with > https://pagure.io/fedora-infrastructure/issue/8652 ASAP. A quick note: This only affected GNOME users, or those using GNOME Software. KDE users did not get that notification. -- John M. Harris, Jr. Splentity ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: swap-on-ZRAM by default
On Tuesday, February 11, 2020 3:44:17 AM MST Daniel P. Berrangé wrote: > On Mon, Feb 10, 2020 at 09:05:27PM -0700, John M. Harris Jr wrote: > > > On Monday, February 10, 2020 12:03:25 PM MST Robbie Harwood wrote: > > > > > "John M. Harris Jr" writes: > > > > > > > On Saturday, January 25, 2020 2:52:05 PM MST Chris Murphy wrote: > > > > > > > >> Question and (pre)proposal: > > > >> > > > >> Can Fedora converge on a single swap-on-ZRAM implementation, and if > > > >> so, which one? Fedora Workstation WG wants to move to swap-on-ZRAM > > > >> by > > > >> default in Fedora 33, and the working group needs to pick something > > > >> soon. > > > > > > > > > > > > Using swap on zram disables the ability to hibernate, making it a > > > > non-starter for many users. If this is going to be thrown into > > > > anything, the user needs to be asked whether they want it or not in > > > > the installer, otherwise you're just taking away features. > > > > > > > > > I thought you told me that the workstation group considers hibernation > > > unsupported? (id:2368390.zu9c8gp...@marvin.jharris.pw) > > > > > > Thanks, > > > --Robbie > > > > > > They do, but that doesn't negate the fact that it is actually supported > > (you can hibernate your system), and using swap on zram outright breaks > > hibernation (for obvious reasons). > > > This discussion is mixing up two different interpretations of meaning > of "supported". > > - Supported, as in, "this use case is in scope & is a release criteria" > > vs > > - Supported, as in, "the functionality works from a technical POV" > > Thus since hibernation is declared an unsupported use case, the fact that > it might happen to work from a technical POV is merely good fortune and is > not required to stay that way, even if some people might be using that now. > > IOW, if swap-on-ZRAM benefits core supported use cases, then it can be > acceptable to break unsupported use cases even if the latter currently > work at a technical POV. Enabling this kind of trade off to be made is > precisely why it is beneficial to define the scope of a product for > what is supported vs unsupported. In this case, I mean supported as in: Users in at least KDE can open their respective menu and choose Leave -> Hibernate Users can run `hibernate` ..and it just works. I'd imagine this is also the case in GNOME, though I don't use it actively to verify on real hardware, and that it works in qemu doesn't mean it works on metal. If it doesn't work on real hardware, that's a GNOME-specific issue. -- John M. Harris, Jr. Splentity ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: swap-on-ZRAM by default
On Tuesday, February 11, 2020 3:28:36 AM MST Roberto Ragusa wrote: > On 2020-02-11 05:05, John M. Harris Jr wrote: > > > > They do, but that doesn't negate the fact that it is actually supported > > (you can hibernate your system), and using swap on zram outright breaks > > hibernation (for obvious reasons). > > > You would need to > > swapon /dev/arealdisk > swapoff /dev/zram0 > hibernate > > certainly a slow process. The problem comes from the fact that this method isn't supported from GUI, which is how most users use hibernation. -- John M. Harris, Jr. Splentity ___ 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: RFC: Security policy adjustments to make it easier to implement and more friendly to maintainers
On Thursday, February 13, 2020 1:34:32 PM MST Chris Murphy wrote: > On Thu, Feb 13, 2020 at 12:53 PM David Cantrell > wrote: > > > > > Similarly, a package with a medium CVE NEW bugzilla would be orphaned > > > after 4 reminders (after 9-12 weeks), retired at a point if still not > > > CLOSED after 4 months.> > > > > > > > > > > With low severity, that is 6 reminders (after 15-18 weeks), retired at a > > > point if still not CLOSED after 6 months (similarly to the current > > > policy).> > > > > > > Where do get bug severity information? > > > Fedora Workstation WG has an issue "Reconsider updates policy" that > relates to this question. > https://pagure.io/fedora-workstation/issue/107 > > If there are any security updates, GNOME Software pops up a > notification to install them. This thwarts attempts to avoid nagging > the user, because so many updates contain some sort of security > mitigation. One proposal is to not treat security updates as special, > and still wait until a week has passed for the update. > > But the contra argument is, well what if there is an urgent security fix? > > The repo metadata, I guess, needs some way of distinguishing urgent vs > non-urgent security updates, so that GNOME Software knows whether to > notify the user accordingly. But is there a reliable way of > distinguishing between urgent and non-urgent security updates? I'd > informally suggest "urgent" is something that should be applied today > or tomorrow. Anything else can wait a week or two. That's an entirely subjective thing. I'd recommend prompting to install ALL security updates immediately, but why not just give the user an option for security updates? This is what Mac and Windows do, and it makes sense because it's really the user's opinion of security updates that matter on their system. -- John M. Harris, Jr. Splentity ___ 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: Change proposal discussion - Optimize SquashFS Size
On Monday, February 10, 2020 10:53:45 AM MST Jared K. Smith wrote: > On Mon, Feb 10, 2020 at 3:30 AM John M. Harris Jr > > wrote: > > As for the software available, that's called choice. I know > > it's a relative unknown in the GNOME world, as one option is shoved down > > everyones' throat, but it's a key part of the KDE ideology, as well as > > GNU/ > > Linux itself. > > John, it's obvious from your posts in this list that you're not a fan of > GNOME. I'd kindly ask you to please refrain from attacking GNOME, > especially when the discussion at hand isn't about GNOME itself. It's not > in keeping with the "be excellent to each other" spirit that Fedora likes > to keep in its mailing lists. > > -- > Jared Smith An observation is not an attack. What I said about GNOME is simply true, and is commonly considered a good thing by GNOME developers on this list. I just don't agree with that, and thus far there is no rule against disagreeing with the GNOME mindset. -- John M. Harris, Jr. Splentity ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
[Bug 1803512] perl-Text-CSV_XS-1.41 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1803512 Paul Howarth changed: What|Removed |Added Status|NEW |CLOSED Fixed In Version||perl-Text-CSV_XS-1.41-1.fc3 ||3 ||perl-Text-CSV_XS-1.41-1.fc3 ||2 Resolution|--- |RAWHIDE Doc Type|--- |If docs needed, set a value Last Closed||2020-02-16 17:16:04 --- Comment #1 from Paul Howarth --- F33 Build: https://koji.fedoraproject.org/koji/taskinfo?taskID=41524506 F32 Build: https://koji.fedoraproject.org/koji/taskinfo?taskID=41524559 -- You are receiving this mail because: You are on the CC list for the bug. ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org
[Bug 1803531] perl-Test-mysqld-1.0013 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1803531 --- Comment #2 from Upstream Release Monitoring --- the-new-hotness/release-monitoring.org's scratch build of perl-Test-mysqld-1.0013-1.fc30.src.rpm for rawhide failed http://koji.fedoraproject.org/koji/taskinfo?taskID=41525401 -- You are receiving this mail because: You are on the CC list for the bug. ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org
[Bug 1803531] perl-Test-mysqld-1.0013 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1803531 --- Comment #1 from Upstream Release Monitoring --- Created attachment 1663361 --> https://bugzilla.redhat.com/attachment.cgi?id=1663361=edit [patch] Update to 1.0013 (#1803531) -- You are receiving this mail because: You are on the CC list for the bug. ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org
[Bug 1803531] New: perl-Test-mysqld-1.0013 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1803531 Bug ID: 1803531 Summary: perl-Test-mysqld-1.0013 is available Product: Fedora Version: rawhide Status: NEW Component: perl-Test-mysqld Keywords: FutureFeature, Triaged Assignee: de...@fateyev.com Reporter: upstream-release-monitor...@fedoraproject.org QA Contact: extras...@fedoraproject.org CC: de...@fateyev.com, perl-devel@lists.fedoraproject.org Target Milestone: --- Classification: Fedora Latest upstream release: 1.0013 Current version/release in rawhide: 1.0012-4.fc31 URL: http://search.cpan.org/dist/Test-mysqld/ Please consult the package updates policy before you issue an update to a stable branch: https://fedoraproject.org/wiki/Updates_Policy More information about the service that created this bug can be found at: https://fedoraproject.org/wiki/Upstream_release_monitoring Please keep in mind that with any upstream change, there may also be packaging changes that need to be made. Specifically, please remember that it is your responsibility to review the new version to ensure that the licensing is still correct and that no non-free or legally problematic items have been added upstream. Based on the information from anitya: https://release-monitoring.org/project/8094/ -- 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
Another take on RStudio (review swaps?)
Hi all, There were some efforts to package RStudio in the past [1], but they're all dead. So following recent work by Dan Čermák for openSUSE [2], I adapted it for Fedora and submitted it for review: https://bugzilla.redhat.com/show_bug.cgi?id=1803528 If anyone is interested in pushing this forward, I can review something in exchange. Note that the koji scratch build fails on s390x due to a Java stack overflow. Does anyone know what's the default in that arch and how to increase it? Thanks, Iñaki [1] https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/thread/AJ44JDERYQMY6MIMFCKQEZL75JEHISQL/ [2] https://build.opensuse.org/package/show/devel:languages:R:released/rstudio ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: How to write License field for packages bundling mutliple others
On Sun, Feb 16, 2020 at 9:25 AM Igor Gnatenko wrote: > > In Rust world we package all crates as source code in -devel packages. > Then we use them to build the real applications. > > Some time ago, someone noticed that we don't put licenses of those > -devel packages into a resulting RPM with app which is fair. > > However, I'm not entirely sure how to properly write the License tag. > What should be there if -devel packages have: > > * ASL 2.0 > * ASL 2.0 or Boost > * ASL 2.0 or MIT > * ISC > * MIT > * (MIT or ASL 2.0) and BSD > * Unlicense or MIT > > Is it correct to put License: ISC and MIT and ASL 2.0 and BSD? My understanding is that "effective license" statements generally only apply for binary artifacts or things where there's a clear way to resolve to a simpler situation. Since Rust stuff only has that apply if binary artifacts are produced (when producing executables or binary libraries), in most cases you can't do that. Since Rust packages are normally a pile of source code that people can freely depend on any part of (unless you're compiling a binary), you need to list it all out. So then it gets to be this fun string: > License: ASL 2.0 and (ASL 2.0 or Boost) and (ASL 2.0 or MIT) and ISC and MIT > and ((MIT or ASL 2.0) and BSD) and (Unlicense or MIT) Isn't it wonderful? :/ -- 真実はいつも一つ！/ 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
[Bug 1803512] New: perl-Text-CSV_XS-1.41 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1803512 Bug ID: 1803512 Summary: perl-Text-CSV_XS-1.41 is available Product: Fedora Version: rawhide Status: NEW Component: perl-Text-CSV_XS Keywords: FutureFeature, Triaged Assignee: p...@city-fan.org Reporter: upstream-release-monitor...@fedoraproject.org QA Contact: extras...@fedoraproject.org CC: anon.am...@gmail.com, jose.p.oliveira@gmail.com, ka...@ucw.cz, p...@city-fan.org, perl-devel@lists.fedoraproject.org, xav...@bachelot.org Target Milestone: --- Classification: Fedora Latest upstream release: 1.41 Current version/release in rawhide: 1.40-2.fc32 URL: http://search.cpan.org/dist/Text-CSV_XS/ Please consult the package updates policy before you issue an update to a stable branch: https://fedoraproject.org/wiki/Updates_Policy More information about the service that created this bug can be found at: https://fedoraproject.org/wiki/Upstream_release_monitoring Please keep in mind that with any upstream change, there may also be packaging changes that need to be made. Specifically, please remember that it is your responsibility to review the new version to ensure that the licensing is still correct and that no non-free or legally problematic items have been added upstream. Based on the information from anitya: https://release-monitoring.org/project/3434/ -- 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
How to write License field for packages bundling mutliple others
In Rust world we package all crates as source code in -devel packages. Then we use them to build the real applications. Some time ago, someone noticed that we don't put licenses of those -devel packages into a resulting RPM with app which is fair. However, I'm not entirely sure how to properly write the License tag. What should be there if -devel packages have: * ASL 2.0 * ASL 2.0 or Boost * ASL 2.0 or MIT * ISC * MIT * (MIT or ASL 2.0) and BSD * Unlicense or MIT Is it correct to put License: ISC and MIT and ASL 2.0 and BSD? ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: How to deal with large number of bugs related to the, "multiple definition of..." issue
For now I'm settling for packages which I know I don't want to be retired to add: # https://gcc.gnu.org/gcc-10/porting_to.html#common %define _legacy_common_support 1 To the top of the spec with a link to an upstream issue if filed... 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
How to deal with large number of bugs related to the, "multiple definition of..." issue
So I have several FTBFS bugs most likely from the new gcc being more pedantic. I understand the bug at a high level but I think it would be nice if someone who really understood it could perhaps document strategies for figuring out how to find the right file that needs to be updated and how. Perhaps a Fedora wiki page for gcc? For now I don't have a lot of time to deal with it so I'm going to either have to change the bugs to assigned or let the packages get retired due to this issue. 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
Re: Why does "fedpkg build" failed for wdune ?
On Sun, Feb 16, 2020 11:21:34 +, Paul Howarth wrote: > On Sun, 16 Feb 2020 06:24:09 +0100 > "J. Scheurich" wrote: > > > https://koji.fedoraproject.org/koji/taskinfo?taskID=41519708 > > > > | Result > > > > | GenericError: Build already in progress (task 41519706) > > > > I already started "fedpkg build", but it said > > > > ... > > Watching tasks (this may be safely interrupted)... > > > > so i interrupted it and restarted "fedpkg build" > You interrupted the watching of the task, not the task itself. Additionally, you can watch running tasks using `koji watch-task ..`. `koji --help` will tell you more. -- Thanks, Regards, Ankur Sinha "FranciscoD" (He / Him / His) | https://fedoraproject.org/wiki/User:Ankursinha Time zone: Europe/London 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: Why does "fedpkg build" failed for wdune ?
On Sun, 16 Feb 2020 06:24:09 +0100 "J. Scheurich" wrote: > https://koji.fedoraproject.org/koji/taskinfo?taskID=41519708 > > | Result > > | GenericError: Build already in progress (task 41519706) > > I already started "fedpkg build", but it said > > ... > Watching tasks (this may be safely interrupted)... > > so i interrupted it and restarted "fedpkg build" You interrupted the watching of the task, not the task itself. The task completed, failing on armv7hl https://koji.fedoraproject.org/koji/taskinfo?taskID=41519706 > What to do ? Have a look to see why the task failed, then either fix it (if it's a package problem) or resubmit the build (if it's an infrastructure problem). Paul. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
[Bug 1803381] perl-Devel-Hide-0.0012 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1803381 Paul Howarth changed: What|Removed |Added Status|NEW |CLOSED Fixed In Version||perl-Devel-Hide-0.0012-1.fc ||32 ||perl-Devel-Hide-0.0012-1.fc ||33 Resolution|--- |RAWHIDE Doc Type|--- |If docs needed, set a value Last Closed||2020-02-16 11:15:23 --- Comment #2 from Paul Howarth --- F32 Build: https://koji.fedoraproject.org/koji/taskinfo?taskID=41520914 F33 Build: https://koji.fedoraproject.org/koji/taskinfo?taskID=41520935 -- 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
COPR builds from SCM still not working
Hello all. COPR builds from SCM are still failing with no visible errors. Does anyone know how to fix this? Full build log: https://copr.fedorainfracloud.org/coprs/phracek/PyCharm/build/1241112/ P.S. I cannot even upload SRPM due to its size. COPR throw HTTP 500 error when trying to upload SRPM file >500M. -- 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
Orphaned rome
I've just orphaned rome (Java rss library). Couple of its dependencies have been removed and I don't have neither the time nor the need to maintain it anymore. -- Alexander Kurtakov Red Hat Eclipse Team ___ 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-20200216.0 compose check report
No missing expected images. Passed openQA tests: 1/1 (x86_64) -- Mail generated by check-compose: https://pagure.io/fedora-qa/check-compose ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Fedora-Cloud-30-20200216.0 compose check report
No missing expected images. Passed openQA tests: 1/1 (x86_64) -- Mail generated by check-compose: https://pagure.io/fedora-qa/check-compose ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
