[Bug 1703269] serious typo in Summary
https://bugzilla.redhat.com/show_bug.cgi?id=1703269 Fedora Update System changed: What|Removed |Added Fixed In Version|perl-Sereal-Encoder-4.007-2 |perl-Sereal-Encoder-4.007-2 |.fc28 |.fc28 ||perl-Sereal-Encoder-4.007-2 ||.fc30 --- Comment #9 from Fedora Update System --- perl-Sereal-Encoder-4.007-2.fc30 has been pushed to the Fedora 30 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://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org
[Bug 1703269] serious typo in Summary
https://bugzilla.redhat.com/show_bug.cgi?id=1703269 Fedora Update System changed: What|Removed |Added Status|ON_QA |CLOSED Fixed In Version||perl-Sereal-Encoder-4.007-2 ||.fc28 Resolution|--- |ERRATA Last Closed||2019-05-07 04:49:50 --- Comment #8 from Fedora Update System --- perl-Sereal-Encoder-4.007-2.fc28 has been pushed to the Fedora 28 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://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org
[Bug 1698172] perl-Sereal-4.007 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1698172 Fedora Update System changed: What|Removed |Added Status|ON_QA |CLOSED Fixed In Version|perl-Sereal-4.007-1.fc31|perl-Sereal-4.007-1.fc31 ||perl-Sereal-4.007-1.fc28 Resolution|--- |ERRATA Last Closed||2019-05-07 04:49:49 --- Comment #9 from Fedora Update System --- perl-Sereal-4.007-1.fc28 has been pushed to the Fedora 28 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://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org
[389-devel] Please review: filter optimisation
https://pagure.io/389-ds-base/pull-request/50252 -- Sincerely, William ___ 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://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/389-devel@lists.fedoraproject.org
[389-devel] Re: Groups are not accessible by filter
Ok, I will check.
Thanks
On Tue, May 7, 2019 at 8:21 AM William Brown wrote:
>
> > On 7 May 2019, at 11:31, Anuj Borah wrote:
> >
> > @William Brown
> >
> > Actually my concern was as bellow:
> >
> > topo.standalone.search_s(DEFAULT_SUFFIX, ldap.SCOPE_SUBTREE, F4, ['cn',
> 'cn', 'cn'])
> > >>[dn: uid=bhall,ou=People,dc=example,dc=com
> > cn: Benjamin Hall
> >
> > ]
> >
> > Question: Can we use these filter directly in filter module. --->>
> like Accounts().filter(F4, ['cn', 'cn', 'cn'])
> >
> > As this works :
> > (Pdb) Accounts(topo.standalone, DEFAULT_SUFFIX).filter(F4)
> > []
> >
> > But this does not work:
> > (Pdb) Accounts(topo.standalone, DEFAULT_SUFFIX).filter((&(F4)(['cn',
> 'cn', 'cn'])))
> > *** SyntaxError: invalid syntax
>
> ^ it says invalid syntax because your F4, (...) is not vaild. You should
> rethink this part of the statement ...
>
> >
> >
> > And these filter as bellow.
> >
> > topo.standalone.search_s(DEFAULT_SUFFIX, ldap.SCOPE_SUBTREE, F10,
> ['mailquota', 'nsRoleDN'])
> > >> [dn: uid=mtyler,ou=People,dc=example,dc=com
> > mailquota: 600
> > nsRoleDN: cn=new managed role,ou=People,dc=example,dc=com
> >
> > ]
> >
> > Question these filter also: Accounts(...).filter(F10,
> ['mailquota', 'nsRoleDN'])
>
> As above.
>
> Try doing:
>
> next_filter = F4, (...)
> Account(...).filter(next_filter).
>
> Is that valid? Why? Why not? What do you need to do to make it valid?
>
> >
> > Regards
> > Anuj Borah
> >
> > On Tue, May 7, 2019 at 5:22 AM William Brown wrote:
> > You are missing a key part of the question again: "Is there any chance
> we can use these filters TO GET lib389 objects of the type X".
> >
> > So for example:
> >
> > > On 3 May 2019, at 17:12, Anuj Borah wrote:
> > >
> > > @William Brown
> > >
> > > Are there any chance we can use these filter with filter module
> directly .
> > >
> > > F1 = "(sn=Hall)"
> >
> > If you do:
> >
> > Groups(...).filter("sn=hall")
> >
> > No because it doesn't make sense for a group to match this.
> >
> > If you did:
> >
> > Person(...).filter("sn=hall")
> >
> > Yes! it would work.
> >
> > > F2 = "(nsRoleDN=cn=new managed role)"
> >
> > Groups(...).filter(nsRoleDn=...)
> >
> > Again, doesn't make sense. But:
> >
> > Accounts(...).filter(nsRoleDn=...)
> >
> > Would make sense, to show all Accounts that are part of the role.
> >
> > > F3 = "(l=sunnyvale)"
> >
> > Here, l= would make sense on things like:
> >
> > OrganisationUnits().filter("l=...")
> > Person("l=...")
> >
> > > F4 = "(& (| {} {}) {})".format(F2, F1, F3)
> > > F10 = "(& {} {})".format(F6, F9)
> >
> > Provdide the type you WANT would satisfy these conditions, yes.
> >
> > But you would be better to do:
> >
> > F4 = (&(cond)(cond)(cond))
> >
> > Rather than str sub. Alternately, use gen_filter.
> >
> >
> >
> > So again - you are missing a key element of the question, which is "is
> this filter suitable to get objects of the type I need to work with".
> Lib389 doesn't think like "just search and get generic things" it thinks as
> "search and get strongly typed objects".
> >
> > >
> > > topo.standalone.search_s(DEFAULT_SUFFIX, ldap.SCOPE_SUBTREE, F4,
> ['cn', 'cn', 'cn'])
> > > >>[dn: uid=bhall,ou=People,dc=example,dc=com
> > > cn: Benjamin Hall
> > >
> > > ]
> > >
> > > topo.standalone.search_s(DEFAULT_SUFFIX, ldap.SCOPE_SUBTREE, F10,
> ['mailquota', 'nsRoleDN'])
> > > >> [dn: uid=mtyler,ou=People,dc=example,dc=com
> > > mailquota: 600
> > > nsRoleDN: cn=new managed role,ou=People,dc=example,dc=com
> > >
> > > ]
> > >
> > > Regards
> > > Anuj Borah
> > >
> > > On Mon, Apr 29, 2019 at 12:29 PM Anuj Borah wrote:
> > > Yes, it is.
> > >
> > > On Mon, Apr 29, 2019 at 11:17 AM William Brown wrote:
> > >
> > >
> > > > On 29 Apr 2019, at 15:00, Anuj Borah wrote:
> > > >
> > > > @William Brown
> > > >
> > > > Sorry my bad , syntax was wrong .
> > > >
> > > > (Pdb) len(Accounts(topo.standalone,
> DEFAULT_SUFFIX).filter("(testUserAccountControl:1.2.840.113556.1.4.803:=8388608,
> ['attrlist=cn:sn:uid:testUserAccountControl'])"))
> > > > 6
> > > >
> > > > Thanks .
> > > >
> > > >
> > > > On Mon, Apr 29, 2019 at 10:26 AM Anuj Borah
> wrote:
> > > > @William Brown
> > > >
> > > > This is the filter :
> "testUserAccountControl:1.2.840.113556.1.4.803:=8388608",
> ['attrlist=cn:sn:uid:testUserAccountControl']
> > > >
> > > > len(topo.standalone.search_s(DEFAULT_SUFFIX,
> ldap.SCOPE_SUBTREE,"testUserAccountControl:1.2.840.113556.1.4.803:=8388608",
> ['attrlist=cn:sn:uid:testUserAccountControl'])) --- Thid one works .
> > > > > 6
> > > >
> > > > But the full filter does not fit with filter module .
> > > >
> > > > > (Pdb) len(Accounts(topo.standalone,
> DEFAULT_SUFFIX).filter("(testUserAccountControl:1.2.840.113556.1.4.803:=8388608)",
> ['attrlist=cn:sn:uid:testUserAccountControl']))
> > > > > *** TypeError: filter() takes 2 positional arguments but 3 were
> given
> > > > > (Pdb) len(Accounts(topo.standalone,
>
Fedora Rawhide-20190506.n.1 compose check report
Missing expected images: Atomichost qcow2 x86_64 Atomichost raw-xz x86_64 Compose FAILS proposed Rawhide gating check! 3 of 47 required tests failed openQA tests matching unsatisfied gating requirements shown with **GATING** below Failed openQA tests: 7/146 (x86_64), 1/2 (arm) ID: 397012 Test: x86_64 Server-dvd-iso modularity_tests URL: https://openqa.fedoraproject.org/tests/397012 ID: 397042 Test: x86_64 KDE-live-iso install_no_user **GATING** URL: https://openqa.fedoraproject.org/tests/397042 ID: 397055 Test: arm Minimal-raw_xz-raw.xz install_arm_image_deployment_upload URL: https://openqa.fedoraproject.org/tests/397055 ID: 397065 Test: x86_64 Silverblue-dvd_ostree-iso desktop_browser URL: https://openqa.fedoraproject.org/tests/397065 ID: 397067 Test: x86_64 universal install_anaconda_text **GATING** URL: https://openqa.fedoraproject.org/tests/397067 ID: 397070 Test: x86_64 universal install_repository_http_graphical **GATING** URL: https://openqa.fedoraproject.org/tests/397070 ID: 397115 Test: x86_64 universal install_arabic_language URL: https://openqa.fedoraproject.org/tests/397115 ID: 397124 Test: x86_64 universal upgrade_2_desktop_64bit URL: https://openqa.fedoraproject.org/tests/397124 Soft failed openQA tests: 3/24 (i386), 5/146 (x86_64) (Tests completed, but using a workaround for a known bug) ID: 397015 Test: i386 Server-boot-iso install_default URL: https://openqa.fedoraproject.org/tests/397015 ID: 397016 Test: i386 Server-dvd-iso install_default URL: https://openqa.fedoraproject.org/tests/397016 ID: 397027 Test: x86_64 Workstation-live-iso desktop_update_graphical URL: https://openqa.fedoraproject.org/tests/397027 ID: 397034 Test: x86_64 Workstation-boot-iso memory_check@uefi URL: https://openqa.fedoraproject.org/tests/397034 ID: 397035 Test: x86_64 Workstation-boot-iso memory_check URL: https://openqa.fedoraproject.org/tests/397035 ID: 397039 Test: i386 Workstation-boot-iso memory_check URL: https://openqa.fedoraproject.org/tests/397039 ID: 397123 Test: x86_64 universal upgrade_2_minimal_64bit URL: https://openqa.fedoraproject.org/tests/397123 ID: 397125 Test: x86_64 universal upgrade_2_server_64bit URL: https://openqa.fedoraproject.org/tests/397125 Passed openQA tests: 134/146 (x86_64), 21/24 (i386) Skipped non-gating openQA tests: 1 of 172 -- 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://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
[Bug 1707203] New: perl-Test-Time-0.08 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1707203 Bug ID: 1707203 Summary: perl-Test-Time-0.08 is available Product: Fedora Version: rawhide Status: NEW Component: perl-Test-Time Keywords: FutureFeature, Triaged Assignee: emman...@seyman.fr Reporter: upstream-release-monitor...@fedoraproject.org QA Contact: extras...@fedoraproject.org CC: emman...@seyman.fr, perl-devel@lists.fedoraproject.org Target Milestone: --- Classification: Fedora Latest upstream release: 0.08 Current version/release in rawhide: 0.07-2.fc30 URL: http://search.cpan.org/dist/Test-Time/ 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/14370/ -- 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://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org
[Fedocal] Reminder meeting : Modularity Team (weekly)
Dear all, You are kindly invited to the meeting: Modularity Team (weekly) on 2019-05-07 from 15:00:00 to 16:00:00 UTC At fedora-meetin...@irc.freenode.net The meeting will be about: Meeting of the Modularity Team. More information available at: [Modularity Team Docs](https://docs.pagure.org/modularity/) The agenda for the meeting is available as flagged tickets [in the Modularity repository](https://pagure.io/modularity/issues?status=Open=Meeting). Source: https://apps.fedoraproject.org/calendar/meeting/9480/ ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
[389-devel] Re: Groups are not accessible by filter
> On 7 May 2019, at 11:31, Anuj Borah wrote:
>
> @William Brown
>
> Actually my concern was as bellow:
>
> topo.standalone.search_s(DEFAULT_SUFFIX, ldap.SCOPE_SUBTREE, F4, ['cn', 'cn',
> 'cn'])
> >>[dn: uid=bhall,ou=People,dc=example,dc=com
> cn: Benjamin Hall
>
> ]
>
> Question: Can we use these filter directly in filter module. --->> like
> Accounts().filter(F4, ['cn', 'cn', 'cn'])
>
> As this works :
> (Pdb) Accounts(topo.standalone, DEFAULT_SUFFIX).filter(F4)
> []
>
> But this does not work:
> (Pdb) Accounts(topo.standalone, DEFAULT_SUFFIX).filter((&(F4)(['cn', 'cn',
> 'cn'])))
> *** SyntaxError: invalid syntax
^ it says invalid syntax because your F4, (...) is not vaild. You should
rethink this part of the statement ...
>
>
> And these filter as bellow.
>
> topo.standalone.search_s(DEFAULT_SUFFIX, ldap.SCOPE_SUBTREE, F10,
> ['mailquota', 'nsRoleDN'])
> >> [dn: uid=mtyler,ou=People,dc=example,dc=com
> mailquota: 600
> nsRoleDN: cn=new managed role,ou=People,dc=example,dc=com
>
> ]
>
> Question these filter also: Accounts(...).filter(F10, ['mailquota',
> 'nsRoleDN'])
As above.
Try doing:
next_filter = F4, (...)
Account(...).filter(next_filter).
Is that valid? Why? Why not? What do you need to do to make it valid?
>
> Regards
> Anuj Borah
>
> On Tue, May 7, 2019 at 5:22 AM William Brown wrote:
> You are missing a key part of the question again: "Is there any chance we can
> use these filters TO GET lib389 objects of the type X".
>
> So for example:
>
> > On 3 May 2019, at 17:12, Anuj Borah wrote:
> >
> > @William Brown
> >
> > Are there any chance we can use these filter with filter module directly .
> >
> > F1 = "(sn=Hall)"
>
> If you do:
>
> Groups(...).filter("sn=hall")
>
> No because it doesn't make sense for a group to match this.
>
> If you did:
>
> Person(...).filter("sn=hall")
>
> Yes! it would work.
>
> > F2 = "(nsRoleDN=cn=new managed role)"
>
> Groups(...).filter(nsRoleDn=...)
>
> Again, doesn't make sense. But:
>
> Accounts(...).filter(nsRoleDn=...)
>
> Would make sense, to show all Accounts that are part of the role.
>
> > F3 = "(l=sunnyvale)"
>
> Here, l= would make sense on things like:
>
> OrganisationUnits().filter("l=...")
> Person("l=...")
>
> > F4 = "(& (| {} {}) {})".format(F2, F1, F3)
> > F10 = "(& {} {})".format(F6, F9)
>
> Provdide the type you WANT would satisfy these conditions, yes.
>
> But you would be better to do:
>
> F4 = (&(cond)(cond)(cond))
>
> Rather than str sub. Alternately, use gen_filter.
>
>
>
> So again - you are missing a key element of the question, which is "is this
> filter suitable to get objects of the type I need to work with". Lib389
> doesn't think like "just search and get generic things" it thinks as "search
> and get strongly typed objects".
>
> >
> > topo.standalone.search_s(DEFAULT_SUFFIX, ldap.SCOPE_SUBTREE, F4, ['cn',
> > 'cn', 'cn'])
> > >>[dn: uid=bhall,ou=People,dc=example,dc=com
> > cn: Benjamin Hall
> >
> > ]
> >
> > topo.standalone.search_s(DEFAULT_SUFFIX, ldap.SCOPE_SUBTREE, F10,
> > ['mailquota', 'nsRoleDN'])
> > >> [dn: uid=mtyler,ou=People,dc=example,dc=com
> > mailquota: 600
> > nsRoleDN: cn=new managed role,ou=People,dc=example,dc=com
> >
> > ]
> >
> > Regards
> > Anuj Borah
> >
> > On Mon, Apr 29, 2019 at 12:29 PM Anuj Borah wrote:
> > Yes, it is.
> >
> > On Mon, Apr 29, 2019 at 11:17 AM William Brown wrote:
> >
> >
> > > On 29 Apr 2019, at 15:00, Anuj Borah wrote:
> > >
> > > @William Brown
> > >
> > > Sorry my bad , syntax was wrong .
> > >
> > > (Pdb) len(Accounts(topo.standalone,
> > > DEFAULT_SUFFIX).filter("(testUserAccountControl:1.2.840.113556.1.4.803:=8388608,
> > > ['attrlist=cn:sn:uid:testUserAccountControl'])"))
> > > 6
> > >
> > > Thanks .
> > >
> > >
> > > On Mon, Apr 29, 2019 at 10:26 AM Anuj Borah wrote:
> > > @William Brown
> > >
> > > This is the filter :
> > > "testUserAccountControl:1.2.840.113556.1.4.803:=8388608",
> > > ['attrlist=cn:sn:uid:testUserAccountControl']
> > >
> > > len(topo.standalone.search_s(DEFAULT_SUFFIX,
> > > ldap.SCOPE_SUBTREE,"testUserAccountControl:1.2.840.113556.1.4.803:=8388608",
> > > ['attrlist=cn:sn:uid:testUserAccountControl'])) --- Thid one works .
> > > > 6
> > >
> > > But the full filter does not fit with filter module .
> > >
> > > > (Pdb) len(Accounts(topo.standalone,
> > > > DEFAULT_SUFFIX).filter("(testUserAccountControl:1.2.840.113556.1.4.803:=8388608)",
> > > > ['attrlist=cn:sn:uid:testUserAccountControl']))
> > > > *** TypeError: filter() takes 2 positional arguments but 3 were given
> > > > (Pdb) len(Accounts(topo.standalone,
> > > > DEFAULT_SUFFIX).filter("(testUserAccountControl:1.2.840.113556.1.4.803:=8388608),
> > > > ['attrlist=cn:sn:uid:testUserAccountControl']"))
> > > > *** ldap.FILTER_ERROR: {'desc': 'Bad search filter', 'errno': 2,
> > > > 'info': 'No such file or directory'}
> > >
> > >
> > > Regards
> > > Anuj Borah
> > >
> >
> > That
Fedora rawhide compose report: 20190506.n.1 changes
OLD: Fedora-Rawhide-20190505.n.0 NEW: Fedora-Rawhide-20190506.n.1 = SUMMARY = Added images:9 Dropped images: 1 Added packages: 37 Dropped packages:0 Upgraded packages: 109 Downgraded packages: 0 Size of added packages: 21.07 MiB Size of dropped packages:0 B Size of upgraded packages: 2.43 GiB Size of downgraded packages: 0 B Size change of upgraded packages: -79.13 MiB Size change of downgraded packages: 0 B = ADDED IMAGES = Image: Cloud_Base qcow2 s390x Path: Cloud/s390x/images/Fedora-Cloud-Base-Rawhide-20190506.n.1.s390x.qcow2 Image: KDE raw-xz armhfp Path: Spins/armhfp/images/Fedora-KDE-armhfp-Rawhide-20190506.n.1-sda.raw.xz Image: Security live i386 Path: Labs/i386/iso/Fedora-Security-Live-i386-Rawhide-20190506.n.1.iso Image: Cloud_Base raw-xz s390x Path: Cloud/s390x/images/Fedora-Cloud-Base-Rawhide-20190506.n.1.s390x.raw.xz Image: Design_suite live i386 Path: Labs/i386/iso/Fedora-Design_suite-Live-i386-Rawhide-20190506.n.1.iso Image: Cloud_Base vmdk s390x Path: Cloud/s390x/images/Fedora-Cloud-Base-Rawhide-20190506.n.1.s390x.vmdk Image: Mate live x86_64 Path: Spins/x86_64/iso/Fedora-MATE_Compiz-Live-x86_64-Rawhide-20190506.n.1.iso Image: Workstation raw-xz aarch64 Path: Workstation/aarch64/images/Fedora-Workstation-Rawhide-20190506.n.1.aarch64.raw.xz Image: Python_Classroom raw-xz armhfp Path: Labs/armhfp/images/Fedora-Python-Classroom-armhfp-Rawhide-20190506.n.1-sda.raw.xz = DROPPED IMAGES = Image: Minimal raw-xz aarch64 Path: Spins/aarch64/images/Fedora-Minimal-Rawhide-20190505.n.0.aarch64.raw.xz = ADDED PACKAGES = Package: golang-github-blakesmith-ar-0-0.2.20190505git809d437.fc31 Summary: Golang ar archive file library RPMs:golang-github-blakesmith-ar-devel Size:12.81 KiB Package: obs-service-rust2rpm-1-1.fc31 Summary: OBS source service: Generate rpm packaging for Rust crates RPMs:obs-service-rust2rpm Size:11.62 KiB Package: perl-XML-Atom-OWL-0.104-1.fc31 Summary: Parse an Atom file into RDF RPMs:perl-XML-Atom-OWL Size:31.90 KiB Package: redhat-fonts-2.2.0-1.fc31 Summary: Red Hat fonts RPMs:redhat-display-fonts redhat-text-fonts Size:323.80 KiB Package: rust-aes-0.3.2-1.fc31 Summary: Facade for AES (Rijndael) block ciphers implementations RPMs:rust-aes+default-devel rust-aes-devel Size:86.98 KiB Package: rust-array-init-0.0.4-1.fc31 Summary: Safe wrapper for initializing fixed-size arrays RPMs:rust-array-init+default-devel rust-array-init+nightly-devel rust-array-init-devel Size:30.34 KiB Package: rust-comrak-0.6.1-1.fc31 Summary: 100% CommonMark-compatible GitHub Flavored Markdown parser and formatter RPMs:comrak rust-comrak+benchmarks-devel rust-comrak+clap-devel rust-comrak+default-devel rust-comrak-devel Size:4.04 MiB Package: rust-dbus0.2-0.2.3-1.fc31 Summary: Bindings to D-Bus, which is a bus commonly used on Linux for inter-process communication. RPMs:rust-dbus0.2+default-devel rust-dbus0.2-devel Size:50.42 KiB Package: rust-gspell-0.2.0-1.fc31 Summary: Rust bindings for gspell RPMs:rust-gspell+default-devel rust-gspell-devel Size:23.34 KiB Package: rust-gspell-sys-0.2.0-1.fc31 Summary: Raw C-FFI bindings for the gspell library RPMs:rust-gspell-sys+default-devel rust-gspell-sys+dox-devel rust-gspell-sys-devel Size:40.81 KiB Package: rust-gstreamer-0.13.0-1.fc31 Summary: Rust bindings for GStreamer RPMs:rust-gstreamer+default-devel rust-gstreamer+dox-devel rust-gstreamer+embed-lgpl-docs-devel rust-gstreamer+futures-core-preview-devel rust-gstreamer+futures-devel rust-gstreamer+purge-lgpl-docs-devel rust-gstreamer+rustdoc-stripper-devel rust-gstreamer+ser_de-devel rust-gstreamer+serde-devel rust-gstreamer+serde_bytes-devel rust-gstreamer+serde_derive-devel rust-gstreamer+subclassing-devel rust-gstreamer+v1_10-devel rust-gstreamer+v1_12-devel rust-gstreamer+v1_14-devel rust-gstreamer-devel Size:267.32 KiB Package: rust-gstreamer-audio-0.13.0-1.fc31 Summary: Rust bindings for GStreamer Audio library RPMs:rust-gstreamer-audio+default-devel rust-gstreamer-audio+dox-devel rust-gstreamer-audio+embed-lgpl-docs-devel rust-gstreamer-audio+purge-lgpl-docs-devel rust-gstreamer-audio+rustdoc-stripper-devel rust-gstreamer-audio+v1_10-devel rust-gstreamer-audio+v1_12-devel rust-gstreamer-audio+v1_14-devel rust-gstreamer-audio-devel Size:95.28 KiB Package: rust-gstreamer-audio-sys-0.7.0-1.fc31 Summary: FFI bindings to libgstaudio-1.0 RPMs:rust-gstreamer-audio-sys+default-devel rust-gstreamer-audio-sys+dox-devel rust-gstreamer-audio-sys+v1_10-devel rust-gstreamer-audio-sys+v1_12-devel rust-gstreamer-audio-sys+v1_14-devel rust-gstreamer-audio-sys+v1_2-devel rust-gstreamer-audio-sys+v1_4-devel rust-gstreamer-audio-sys+v1_6-devel rust-gstreamer-audio-sys+v1_8-devel rust-gstreamer-audio-sys-devel Size:95.68 KiB Package: rust-gstreamer-base-0.13.0-1.fc31 Summary: Rust bindings for GStreamer Base
[389-devel] 389 DS nightly 2019-05-07 - 88% PASS
https://fedorapeople.org/groups/389ds/ci/nightly/2019/05/07/report-389-ds-base-1.4.1.2-20190506git8046842.fc29.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://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/389-devel@lists.fedoraproject.org
Re: Kernel upgrades
On Mon, May 6, 2019 at 2:47 PM Chris Murphy wrote: > > I suggest keeping things as is, with saved_entry set in the grubenv. > And that's because GRUB and the grub-boot-success.service are able to > do an automatic fallback to the previous working kernel if boot fails > following a kernel upgrade. Sorry for the confusion, I don't think this is correct. If boot is not successful, the GRUB menu will not be hidden at the next boot giving the user the option of picking another kernel. -- 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://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
[Bug 1707167] New: perl-Log-ger-0.028 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1707167 Bug ID: 1707167 Summary: perl-Log-ger-0.028 is available Product: Fedora Version: rawhide Status: NEW Component: perl-Log-ger Keywords: FutureFeature, Triaged Assignee: jples...@redhat.com Reporter: upstream-release-monitor...@fedoraproject.org QA Contact: extras...@fedoraproject.org CC: jples...@redhat.com, perl-devel@lists.fedoraproject.org Target Milestone: --- Classification: Fedora Latest upstream release: 0.028 Current version/release in rawhide: 0.027-1.fc31 URL: http://search.cpan.org/dist/Log-ger/ 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/15741/ -- 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://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org
[Bug 1707154] New: perl-libwww-perl-6.39 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1707154 Bug ID: 1707154 Summary: perl-libwww-perl-6.39 is available Product: Fedora Version: rawhide Status: NEW Component: perl-libwww-perl Keywords: FutureFeature, Triaged Assignee: ppi...@redhat.com Reporter: upstream-release-monitor...@fedoraproject.org QA Contact: extras...@fedoraproject.org CC: caillon+fedoraproj...@gmail.com, john.j5l...@gmail.com, ka...@ucw.cz, perl-devel@lists.fedoraproject.org, ppi...@redhat.com, rhug...@redhat.com, rstr...@redhat.com, sandm...@redhat.com Target Milestone: --- Classification: Fedora Latest upstream release: 6.39 Current version/release in rawhide: 6.38-1.fc31 URL: http://search.cpan.org/dist/libwww-perl/ 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/3024/ -- 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://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org
Re: Is possible to use caching for livemedia-creator
Danishka Navin wrote: > Is it possible to enable caching for livemedia-creator? > Similar to the --cache option in livecd-creator. Why not just use livecd-creator? It is still maintained by the community (mainly Neal Gompa, see https://github.com/livecd-tools/livecd-tools ) and it supports this IMHO essential feature. And livecd-creator typically accepts kickstarts written for livemedia-creator with few to no changes, unlike the other way round. 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://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Firefox certificate
Tom Hughes wrote: > Right now that is the only fix I think - there isn't a code fix yet > so any talk about a Fedora update is premature. See now why it was an absolutely horrible idea to allow the Fedora Firefox package to reject extensions not signed by upstream? I still strongly believe that such a restriction is inherently incompatible with the concept of Free Software and absolutely unacceptable in a Free Software distribution such as Fedora. 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://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Kernel upgrades
On Mon, May 6, 2019 at 3:51 PM Chris Murphy wrote: > > GRUB pre-boot environment can read grubenv from anything GRUB supports > reading, which is practically anything including mdadm RAID. Your > grubenv can be read, it just can be changed by GRUB in the pre-boot ^can't !! -- 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://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Self Introduction: Guillaume Fayard
Hi, I just submitted my first review request on Bugzilla : https://bugzilla.redhat.com/show_bug.cgi?id=1706548. The packaged software is called "simple-dnf" and it is meant to be a lightweight (and fast) GUI for DNF. I did not create it but I found it very quite cool and effective; as I was interested by the packaging world I decided to create a COPR repository for testing purpose: https://copr.fedorainfracloud.org/coprs/arkelis/simple-dnf/, now I'm submitting for official repo! To introduce myself, I'm Guillaume Fayard, a French student at a general engineering school; I'm interested in Python, Web development, Server administration... I did not yet contribute to many open source project, I usually help to translate things (for example Python docs). I have small website (in French) hosting various documents I'm writing / I wrote: pycolore.fr Regards Guillaume Fayard ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Kernel upgrades
On Mon, May 6, 2019 at 3:15 PM Steven A. Falco wrote: > > As I was reading through the documentation, I came across a statement that > grubenv is unavailable on RAID - please see the second to last sentence here: > > https://www.gnu.org/software/grub/manual/grub/html_node/Environment-block.html > > My machine is set up with /boot on SW RAID-1 (and everything else on SW > RAID-5 / LVM). That said, grubenv appears to update properly. I don't know > if the manual is not quite current, or if there is some other explanation - > perhaps any updates always occur under Linux, while the RAID-1 is assembled. > > Regardless, everything is good now, so I'll stop obsessing about it. :-) Yep. https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/PBCAGLM46RSG54QW3DM43U4H5YQSHZNB/ GRUB pre-boot environment can read grubenv from anything GRUB supports reading, which is practically anything including mdadm RAID. Your grubenv can be read, it just can be changed by GRUB in the pre-boot environment. That means it can't change boot_success to 0. It'll always be a 1, meaning GRUB will think your boots are always successful. When a new kernel is installed, the package scripts cause grubenv saved_entry to get updated. This is happening through kernel file system and md code, so it's a completely supported change, and that's how GRUB in the pre-boot environment can see the updated saved_entry and know which kernel version to boot by default. But it's worth keeping an eye on anomalies. There is the potential for goofy things happening. Unrelated to this particular feature, rather it was grub.cfg being updated, in cases where that update happened very quickly followed by an immediate reboot, GRUB only saw the previous grub.cfg. On journaled file systems, the new file gets written out, and indicated only in the journal, and a particular set of circumstances preventing the root fs from being cleanly unmounted resulted in a hidden new grub.cfg that only became revealed after journal replay by the kernel code. The GRUB code can't read file system journals, so it was seeing the stale file as a result of reading stale file system metadata without the benefit of reading the journal. :P -- 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://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Enable dmarc mitigations
On Sun, May 05, 2019 at 12:43:02PM -0700, stan via devel wrote: > To each their own, of course, but there was a long discussion of > discourse here a while ago. I tried it out, but it was like a bad > version of a mailing list. It sent me a mail informing me that there > were messages to read. Then I had to go there and read the messages on > the web, using their interface. That's definitely the primary intended mode of interaction, but there is also a "mailing list mode" which does more of what you want. (One email per post, and you can reply directly.) -- 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://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Kernel upgrades
On 5/6/19 4:47 PM, Chris Murphy wrote: > On Mon, May 6, 2019 at 1:04 PM Steven A. Falco wrote: >> >>> # grub2-editenv list >> >> Here is the command output: >> >> saved_entry=2aa6409d5c354eea9cc2e4630c4efda0-5.0.11-300.fc30.x86_64 >> boot_success=1 >> boot_indeterminate=1 >> kernelopts=root=/dev/mapper/fedora-root ro resume=/dev/mapper/fedora-swap >> rd.lvm.lv=fedora/root rd.md.uuid=77ae1678:58a79067:c0ad29e6:bd1862f8 >> rd.md.uuid=bac1fa34:2d7a26e5:969d63ac:33ff4572 rd.lvm.lv=fedora/swap > > Looks normal. > > Also, about the /boot/grub2/grubenv symlink to > /boot/efi/EFI/fedora/grubenv - I'm only seeing this on clean installs > from Fedora-Workstation-Live-x86_64-30-1.2.iso so it might be related > to how the lives are assembled and rsync'd over. It doesn't happen > with a minimal or server installation on a BIOS VM. The install originated as a "server edition", so that is consistent. > At the moment, I think whatever problem there was has been cleared and > it's now behaving normally. Agreed. >> I'm reading through the various scripts trying to understand the impact of >> GRUB_DEFAULT. It seems like having GRUB_DEFAULT=saved is not currently >> hurting me. The last upgrade, to 5.0.11-300, properly made that kernel the >> new default. >> >> If GRUB_DEFAULT is commented out, then I think grub will always choose the >> first item in its menu, which would be fine, because the newest kernel >> always appears first in the grub menu. Is that why you recommended >> commenting it out? > > Nope, sorry, you're confused. I referred to GRUB_SAVEDEFAULT - > thinking maybe you had a customized /etc/default/grub. GRUB_DEFAULT > and GRUB_SAVEDEFAULT are two different things, but the latter depends > on the former. It wouldn't be the first time I was confused. :-) > I suggest keeping things as is, with saved_entry set in the grubenv. > And that's because GRUB and the grub-boot-success.service are able to > do an automatic fallback to the previous working kernel if boot fails > following a kernel upgrade. I will leave it alone, as you recommend. As I was reading through the documentation, I came across a statement that grubenv is unavailable on RAID - please see the second to last sentence here: https://www.gnu.org/software/grub/manual/grub/html_node/Environment-block.html My machine is set up with /boot on SW RAID-1 (and everything else on SW RAID-5 / LVM). That said, grubenv appears to update properly. I don't know if the manual is not quite current, or if there is some other explanation - perhaps any updates always occur under Linux, while the RAID-1 is assembled. Regardless, everything is good now, so I'll stop obsessing about it. :-) And thanks for all your help! Steve ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
[Bug 1520948] Upgrade perl-Test-WWW-Mechanize-PSGI to 0.38
https://bugzilla.redhat.com/show_bug.cgi?id=1520948 Fedora Update System changed: What|Removed |Added Status|MODIFIED|ON_QA --- Comment #9 from Fedora Update System --- perl-Test-WWW-Mechanize-PSGI-0.39-1.fc30 has been pushed to the Fedora 30 testing repository. If problems still persist, please make note of it in this bug report. See https://fedoraproject.org/wiki/QA:Updates_Testing for instructions on how to install test updates. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2019-93da6851fb -- 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://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org
[Bug 1706481] perl-Verilog-Perl-3.466 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1706481 Fedora Update System changed: What|Removed |Added Status|MODIFIED|ON_QA --- Comment #2 from Fedora Update System --- perl-Verilog-Perl-3.466-1.fc30 has been pushed to the Fedora 30 testing repository. If problems still persist, please make note of it in this bug report. See https://fedoraproject.org/wiki/QA:Updates_Testing for instructions on how to install test updates. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2019-4e177d2751 -- 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://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org
Re: Upgrade to F30 gone wrong
On Mon, May 6, 2019 at 12:27 PM Martin Kolman wrote: > > On Mon, 2019-05-06 at 12:09 -0600, Chris Murphy wrote: > > It is completely impractical for QA to, every cycle, do a clean > > install of each version of Fedora, and upgrade them in sequence to the > > current pre-release version, and if any of those get stuck somewhere, > > suggest it would be release blocking. It's totally untenable. > As a manual test - indeed. But as a fully automated test running in a VM it > could work IMHO. To what end? Someone would have to build this test in openqa, and then when it fails, check it and try and figure out why it failed, which itself could take hours. The release criterion is clear, such a bug wouldn't block release. That a thing can be done does not mean that thing should be done. > This would presumably run for many hours, but if multiple runs could be done > for different starting > versions N in parallel, it should still be short enough to gate stuf like > GO/NOGO decissions. And the outcome in this particular instance would differ, how? Someone would need to create these tests in openqa, then someone needs to check the failing tests, and work out the cause of the problem. That's exactly what happened in this case. And quite a lot of such testing, including this one and the one you're proposing, when they aren't release blocking someone may not do that. There's quite a lot on QA's plate with just blockers and important freeze exception bugs. Everything else depends on available bandwidth. -- 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://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
[Bug 1705095] perl-Verilog-Perl-3.464 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1705095 Fedora Update System changed: What|Removed |Added Status|MODIFIED|ON_QA --- Comment #4 from Fedora Update System --- perl-Verilog-Perl-3.466-1.fc30 has been pushed to the Fedora 30 testing repository. If problems still persist, please make note of it in this bug report. See https://fedoraproject.org/wiki/QA:Updates_Testing for instructions on how to install test updates. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2019-4e177d2751 -- 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://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org
Re: Kernel upgrades
On Mon, May 6, 2019 at 1:04 PM Steven A. Falco wrote: > > > # grub2-editenv list > > Here is the command output: > > saved_entry=2aa6409d5c354eea9cc2e4630c4efda0-5.0.11-300.fc30.x86_64 > boot_success=1 > boot_indeterminate=1 > kernelopts=root=/dev/mapper/fedora-root ro resume=/dev/mapper/fedora-swap > rd.lvm.lv=fedora/root rd.md.uuid=77ae1678:58a79067:c0ad29e6:bd1862f8 > rd.md.uuid=bac1fa34:2d7a26e5:969d63ac:33ff4572 rd.lvm.lv=fedora/swap Looks normal. Also, about the /boot/grub2/grubenv symlink to /boot/efi/EFI/fedora/grubenv - I'm only seeing this on clean installs from Fedora-Workstation-Live-x86_64-30-1.2.iso so it might be related to how the lives are assembled and rsync'd over. It doesn't happen with a minimal or server installation on a BIOS VM. At the moment, I think whatever problem there was has been cleared and it's now behaving normally. > > I'm reading through the various scripts trying to understand the impact of > GRUB_DEFAULT. It seems like having GRUB_DEFAULT=saved is not currently > hurting me. The last upgrade, to 5.0.11-300, properly made that kernel the > new default. > > If GRUB_DEFAULT is commented out, then I think grub will always choose the > first item in its menu, which would be fine, because the newest kernel always > appears first in the grub menu. Is that why you recommended commenting it > out? Nope, sorry, you're confused. I referred to GRUB_SAVEDEFAULT - thinking maybe you had a customized /etc/default/grub. GRUB_DEFAULT and GRUB_SAVEDEFAULT are two different things, but the latter depends on the former. I suggest keeping things as is, with saved_entry set in the grubenv. And that's because GRUB and the grub-boot-success.service are able to do an automatic fallback to the previous working kernel if boot fails following a kernel upgrade. -- 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://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Upgrade to F30 gone wrong
On Mon, May 06, 2019 at 12:13:16PM -0600, Chris Murphy wrote: > On Mon, May 6, 2019 at 8:47 AM Tomasz Torcz wrote: > > > > % dnf --releasever=31 system-upgrade download > > Before you continue ensure that your system is fully upgraded by running > > "dnf --refresh upgrade". Do you want to continue [y/N]: > > > > So this message should read “Ensure your system is different that > > we test for”? > > No. > > Different than release testing that occurred during the last final > freeze, yes. But still tested, as QA, and many other Fedora users and > testers, test the packages in updates-testing before those packages > move to the updates repo. Ah, ok. “through-the-upgrades” meant “dnf system-upgrade”, no plain “dnf upgrade”. Even criteria talks about fully upgraded system. I've misunderstood completely :( -- Tomasz TorczOnce you've read the dictionary, xmpp: zdzich...@chrome.pl every other book is just a remix. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Kernel upgrades
On 5/6/19 2:53 PM, Chris Murphy wrote: > On Mon, May 6, 2019 at 7:39 AM Steven A. Falco wrote: >> >> Thanks for the explanation. Here are the contents of /etc/default/grub. As >> you suspected, there is a GRUB_DEFAULT=saved line in there. >> >> GRUB_TIMEOUT=5 >> GRUB_DISTRIBUTOR="$(sed 's, release .*$,,g' /etc/system-release)" >> GRUB_DEFAULT=saved >> GRUB_DISABLE_SUBMENU=true >> GRUB_TERMINAL_OUTPUT="console" >> GRUB_CMDLINE_LINUX="resume=/dev/mapper/fedora-swap rd.lvm.lv=fedora/root >> rd.md.uuid=77ae1678:58a79067:c0ad29e6:bd1862f8 >> rd.md.uuid=bac1fa34:2d7a26e5:969d63ac:33ff4572 rd.lvm.lv=fedora/swap" >> GRUB_DISABLE_RECOVERY="true" >> GRUB_ENABLE_BLSCFG=true > > This is a stock /etc/default/grub - there's nothing custom about it. > >> I looked for grubenv, and the only one I found is at /boot/grub2/grubenv. >> There is nothing in /boot/efi/EFI/fedora. This machine was set up on >> 2018-11-24, so it started life as a Fedora 29 machine. > > Ahh not sure. Might be new in Fedora 30 and doesn't get changed on upgrades? > >> Is there a command I should run to move grubenv to /boot/efi/EFI/fedora? I >> think I would also have to create a symlink from >> /boot/efi/EFI/fedora/grubenv to /etc/default/grub. I could of course do it >> manually, but if there is a better procedure, like re-installing some >> package(s), that would be preferable. > > The purpose of the symlink is so that grubenv commands and usage just > work without respect to firmware type. You don't have to fix this. But > I'm still curious about the contents of that grubenv, so what do you > get fro > > # grub2-editenv list Here is the command output: saved_entry=2aa6409d5c354eea9cc2e4630c4efda0-5.0.11-300.fc30.x86_64 boot_success=1 boot_indeterminate=1 kernelopts=root=/dev/mapper/fedora-root ro resume=/dev/mapper/fedora-swap rd.lvm.lv=fedora/root rd.md.uuid=77ae1678:58a79067:c0ad29e6:bd1862f8 rd.md.uuid=bac1fa34:2d7a26e5:969d63ac:33ff4572 rd.lvm.lv=fedora/swap I'm reading through the various scripts trying to understand the impact of GRUB_DEFAULT. It seems like having GRUB_DEFAULT=saved is not currently hurting me. The last upgrade, to 5.0.11-300, properly made that kernel the new default. If GRUB_DEFAULT is commented out, then I think grub will always choose the first item in its menu, which would be fine, because the newest kernel always appears first in the grub menu. Is that why you recommended commenting it out? Steve ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Where are armv7hl, i686 and ppc64le Container tar.xz files?
> > And why below s390x does not have Fedora-Container-Base-*.tar.xz? > > Those are things that failed in the final RC2 compose of Fedora30. > > Since they were not release blocking, they... didn't block the release. > > ...snip... > > > > I change my question. > > Do you know who is creating this kind of multi arch container images? > > https://dl.fedoraproject.org/pub/fedora/linux/releases/30/Container/aarch64/images/ > > Those were all made by the Fedora 30 rc2 compose. > > pungi is the tool, and this: > https://pagure.io/pungi-fedora/blob/f30/f/fedora-final.conf > was the config used. > > Does that answer the question? Yes, Kevin. Thank you for the info. What I do not understand is below DockerHub has Feodra 30 ppc64le, Fedora 29 armhfp that Fedora Project did not release. https://hub.docker.com/r/ppc64le/fedora/ Fedora 29, 30 https://hub.docker.com/r/arm32v7/fedora/ Fedora 29 (not 30) Anyway, as what I wanted is layer.tar in the image archive, maybe I will take it from DockerHub's image like this. $ docker pull arm32v7/fedora:29 $ docker save arm32v7/fedora:29 -o 29-armhfp.tar $ tar -xf 29-armhfp.tar $ ls -l */layer.tar -rw-r--r-- 1 jaruga jaruga 256970240 Feb 20 14:00 88edf58c1d5b3ee606b724b19ac4b4866b20ba93d15d5b330fc6cc29055b480b/layer.tar Thanks. Solved. -- Jun Aruga / He - His - Him jar...@redhat.com / IRC: jaruga ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Kernel upgrades
On Mon, May 6, 2019 at 7:39 AM Steven A. Falco wrote: > > Thanks for the explanation. Here are the contents of /etc/default/grub. As > you suspected, there is a GRUB_DEFAULT=saved line in there. > > GRUB_TIMEOUT=5 > GRUB_DISTRIBUTOR="$(sed 's, release .*$,,g' /etc/system-release)" > GRUB_DEFAULT=saved > GRUB_DISABLE_SUBMENU=true > GRUB_TERMINAL_OUTPUT="console" > GRUB_CMDLINE_LINUX="resume=/dev/mapper/fedora-swap rd.lvm.lv=fedora/root > rd.md.uuid=77ae1678:58a79067:c0ad29e6:bd1862f8 > rd.md.uuid=bac1fa34:2d7a26e5:969d63ac:33ff4572 rd.lvm.lv=fedora/swap" > GRUB_DISABLE_RECOVERY="true" > GRUB_ENABLE_BLSCFG=true This is a stock /etc/default/grub - there's nothing custom about it. > I looked for grubenv, and the only one I found is at /boot/grub2/grubenv. > There is nothing in /boot/efi/EFI/fedora. This machine was set up on > 2018-11-24, so it started life as a Fedora 29 machine. Ahh not sure. Might be new in Fedora 30 and doesn't get changed on upgrades? > Is there a command I should run to move grubenv to /boot/efi/EFI/fedora? I > think I would also have to create a symlink from /boot/efi/EFI/fedora/grubenv > to /etc/default/grub. I could of course do it manually, but if there is a > better procedure, like re-installing some package(s), that would be > preferable. The purpose of the symlink is so that grubenv commands and usage just work without respect to firmware type. You don't have to fix this. But I'm still curious about the contents of that grubenv, so what do you get fro # grub2-editenv list -- 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://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Upgrade to F30 gone wrong
On Mon, 2019-05-06 at 12:09 -0600, Chris Murphy wrote: > On Mon, May 6, 2019 at 7:25 AM Roberto Ragusa wrote: > > On 5/6/19 1:40 PM, Julen Landa Alustiza wrote: > > > > > We found this bug before releasing, but it is not a release blocking bug > > > (the upgrade criteria just cover clean n > > > and n-1 upgrading to n+1 and this bug just happens whith continously > > > upgraded systems since fc21 or lower) > > > > Wait a moment, is n and n-1 defined to "installed from scratch n and n-1?". > > Correct. > > "For each one of the release-blocking package sets, it must be > possible to successfully complete a direct upgrade from a fully > updated, clean default installation of each of the last two stable > Fedora releases with that package set installed." > > https://fedoraproject.org/wiki/Fedora_30_Beta_Release_Criteria#Upgrade_requirements > > > Is this a precedent that n-installed is different than n-through-upgrades? > > It is completely impractical for QA to, every cycle, do a clean > install of each version of Fedora, and upgrade them in sequence to the > current pre-release version, and if any of those get stuck somewhere, > suggest it would be release blocking. It's totally untenable. As a manual test - indeed. But as a fully automated test running in a VM it could work IMHO. Grossly simplified description of such an automated test: - create a VM - install old fedora version N via kickstart - setup SSH keys for remote access in the kickstart - apply any other customizations needed - SSH to machine, run commands to upgrade to N+1, repeat until desired current version is reached Test considered successfull if it is possible to login to the upgraded system after final reboot. Test considered failed if a timeout is reached, with timeouts assigned to the individual parts (installation, prepare for upgrade, upgrade). More granular checks could be used, at the cost of more complicated test harness. This would presumably run for many hours, but if multiple runs could be done for different starting versions N in parallel, it should still be short enough to gate stuf like GO/NOGO decissions. > > And not least of which is the BIOS bootloader staleness issue, but > file systems are inherently non-deterministic data blobs. The older > they get, the more non-deterministic they become, and the more likely > problems are edge cases that require special handling. The older it > is, the less stable it is, and the more likely you'll run into > problems no one else has. It's just the way they are. > > > -- > 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://getfedora.org/code-of-conduct.html > 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://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Upgrade to F30 gone wrong
On Mon, May 6, 2019 at 8:47 AM Tomasz Torcz wrote: > > % dnf --releasever=31 system-upgrade download > Before you continue ensure that your system is fully upgraded by running > "dnf --refresh upgrade". Do you want to continue [y/N]: > > So this message should read “Ensure your system is different that > we test for”? No. Different than release testing that occurred during the last final freeze, yes. But still tested, as QA, and many other Fedora users and testers, test the packages in updates-testing before those packages move to the updates repo. -- 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://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Where are armv7hl, i686 and ppc64le Container tar.xz files?
On 5/6/19 4:58 AM, Jun Aruga wrote: > I am looking for arch container archive files like > "Fedora-Container-Base-30-1.2.aarch64.tar.xz > " for Fedora 30 > I found the x86_64, aarch64 and s390x's archive files in below directory. > But where is the archive file of armv7hl, i686 and ppc64le? > I assume the multi archs except x86_64, aarch64 and s390x existed in > the age of Fedora 24, 25 in below releases directory. > > And why below s390x does not have Fedora-Container-Base-*.tar.xz? Those are things that failed in the final RC2 compose of Fedora30. Since they were not release blocking, they... didn't block the release. ...snip... > > I change my question. > Do you know who is creating this kind of multi arch container images? > https://dl.fedoraproject.org/pub/fedora/linux/releases/30/Container/aarch64/images/ Those were all made by the Fedora 30 rc2 compose. pungi is the tool, and this: https://pagure.io/pungi-fedora/blob/f30/f/fedora-final.conf was the config used. Does that answer the question? kevin 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://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Where are armv7hl, i686 and ppc64le Container tar.xz files?
I found Fedora 30 armhfp container image here. https://dl.fedoraproject.org/pub/fedora/linux/development/30/Container/ I am still looking for Fedora 30 armv7hl, i686 and ppc64le container images. -- Jun Aruga / He - His - Him jar...@redhat.com / IRC: jaruga ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Upgrade to F30 gone wrong
On Mon, May 6, 2019 at 7:25 AM Roberto Ragusa wrote: > > On 5/6/19 1:40 PM, Julen Landa Alustiza wrote: > > > We found this bug before releasing, but it is not a release blocking bug > > (the upgrade criteria just cover clean n and n-1 upgrading to n+1 and this > > bug just happens whith continously upgraded systems since fc21 or lower) > > Wait a moment, is n and n-1 defined to "installed from scratch n and n-1?". Correct. "For each one of the release-blocking package sets, it must be possible to successfully complete a direct upgrade from a fully updated, clean default installation of each of the last two stable Fedora releases with that package set installed." https://fedoraproject.org/wiki/Fedora_30_Beta_Release_Criteria#Upgrade_requirements > Is this a precedent that n-installed is different than n-through-upgrades? It is completely impractical for QA to, every cycle, do a clean install of each version of Fedora, and upgrade them in sequence to the current pre-release version, and if any of those get stuck somewhere, suggest it would be release blocking. It's totally untenable. And not least of which is the BIOS bootloader staleness issue, but file systems are inherently non-deterministic data blobs. The older they get, the more non-deterministic they become, and the more likely problems are edge cases that require special handling. The older it is, the less stable it is, and the more likely you'll run into problems no one else has. It's just the way they are. -- 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://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Where are armv7hl, i686 and ppc64le Container tar.xz files?
I change my question. Do you know who is creating this kind of multi arch container images? https://dl.fedoraproject.org/pub/fedora/linux/releases/30/Container/aarch64/images/ Jun ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Upgrade to F30 gone wrong
Am 04.05.19 um 22:50 schrieb Sam Varshavchik: > Chris Murphy writes: > >> This bug itself was expected to be an edge case, that not many users >> would be affected, in that not many would have a stale Fedora 20 or >> older bootloader. Surely 'grub2-install' would have been manually run, >> or the user has done a recent clean install since Fedora 20, right?! > > One of my bricks that will soon get Fedora 30 was originally installed > with Fedora Core 4. > Started with F18, used dnf distro-sync since and had no major fault in between. > Obviously a minority; but you'll be surprised to learn how many > systems there are which have been running Fedora for a very long time. > Fedora 20 is what, about five years old? There are many, many systems > which are at least five years old. People don't really swap hardware > every 2-3 years, any more. > You can switch hw without the need of a reinstallation, as next to noone compiles kernels for a specific system anymore. They boot simply anything now. Best regards, Marius ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Orphaned packages seeking maintainers
The following packages are orphaned and will be retired when they are orphaned for six weeks, unless someone adopts them. If you know for sure that the package should be retired, please do so now with a proper reason: https://fedoraproject.org/wiki/How_to_remove_a_package_at_end_of_life Note: If you received this mail directly you (co)maintain one of the affected packages or a package that depends on one. Please adopt the affected package or retire your depending package to avoid broken dependencies, otherwise your package will be retired when the affected package gets retired. Grep this for you FAS name and follow the dependencies: See https://churchyard.fedorapeople.org/orphans-2019-05-06.txt Request unorphaning or unretirement via: https://pagure.io/releng/issues Package (co)maintainers Status Change Ray orphan 5 weeks ago aeskulap orphan 3 weeks ago ahkab orphan 4 weeks ago ceph-deploy branto, fsimonce, ktdreyer, 0 weeks ago orphan, trhoden clpbardcantrel, orphan 0 weeks ago cwiid orphan 5 weeks ago dvdbackup cicku, orphan3 weeks ago emacs-pymacs orphan 3 weeks ago gnome-dvb-daemon orphan 3 weeks ago gnome-shell-extension-orphan 3 weeks ago openweather gnome-shell-extension-panel-osd orphan 3 weeks ago gnue-common orphan 5 weeks ago gpart dcantrel, orphan 0 weeks ago h2akurtakov, dchen, lef, orphan0 weeks ago jam-control orphan 5 weeks ago ltspfsenslaver, orphan 2 weeks ago ninja-ide echevemaster, orphan 2 weeks ago nodejs-after nodejs-sig, orphan 7 weeks ago nodejs-alter nodejs-sig, orphan 7 weeks ago nodejs-ansi-font nodejs-sig, orphan 7 weeks ago nodejs-ansidiff nodejs-sig, orphan 7 weeks ago nodejs-archiver nodejs-sig, orphan 7 weeks ago nodejs-archiver-utils nodejs-sig, orphan 7 weeks ago nodejs-ast-traverse nodejs-sig, orphan 7 weeks ago nodejs-ast-types nodejs-sig, orphan 7 weeks ago nodejs-astral nodejs-sig, orphan 7 weeks ago nodejs-astral-angular-annotatenodejs-sig, orphan 7 weeks ago nodejs-astral-passnodejs-sig, orphan 7 weeks ago nodejs-async-cachenodejs-sig, orphan 7 weeks ago nodejs-async-each nodejs-sig, orphan 7 weeks ago nodejs-aws-sign2 nodejs-sig, orphan 7 weeks ago nodejs-base64-js nodejs-sig, orphan 7 weeks ago nodejs-basic-auth-parser nodejs-sig, orphan 7 weeks ago nodejs-bl nodejs-sig, orphan 7 weeks ago nodejs-breakable nodejs-sig, orphan 7 weeks ago nodejs-camel-case nodejs-sig, orphan 7 weeks ago nodejs-caniuse-db nodejs-sig, orphan 7 weeks ago nodejs-change-casenodejs-sig, orphan 7 weeks ago nodejs-clone nodejs-sig, orphan 7 weeks ago nodejs-clsnodejs-sig, orphan 7 weeks ago nodejs-co nodejs-sig, orphan 7 weeks ago nodejs-commoner nodejs-sig, orphan 7 weeks ago nodejs-compress-commons nodejs-sig, orphan 7 weeks ago nodejs-console-browserify nodejs-sig, orphan 7 weeks ago nodejs-constant-case nodejs-sig, orphan 7 weeks ago nodejs-crc32-stream nodejs-sig, orphan 7 weeks ago nodejs-dashdash nodejs-sig, orphan 7 weeks ago nodejs-date-now nodejs-sig, orphan 7 weeks ago nodejs-deferred nodejs-sig, orphan 7 weeks ago nodejs-defs nodejs-sig, orphan 7 weeks ago nodejs-degenerator
Re: How to install a mountpoint directory from an rpm?
> On Fri, May 3, 2019 at 9:13 PM jaltman > Then I think you want the fhs-discuss mailing list, to help this get > through, at https://lists.linux-foundation.org/mailman/listinfo/fhs-discuss. > It's a pretty quiet list, so there may be a more active relevant chat > channel. Does anyone else know of a more active list or channel to > update the FHS ? I have submitted a Bugzilla request to the FHS at https://bugs.linuxfoundation.org/show_bug.cgi?id=1438 ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Upgrade to F30 gone wrong
On Mon, May 6, 2019 at 1:52 AM Nicolas Mailhot wrote: > > Le dimanche 05 mai 2019 à 16:14 -0600, Chris Murphy a écrit : > > > > Right and that's the same with beta testing, which is how bugs like > > this can sometimes not even get found until after release. A lot of > > tests are done on pristine systems that are throw away. It's entirely > > understandable few people want to test Fedora pre-release on their > > rock solid 5+ year old Fedora system, but we actually stumbled on > > this > > in some sense by luck of alternate arch acting like a canary. > > That's not true, many boot problems are found quite early in the > process by rawhide users, but rawhide users feedback is not taken into > account by installer folks because they don't look at boot problems > before quite late in the cycle, when rawhide users have already moved > on manually, and the default solution is always to reinstall from > scratch. > > So problems are found, just not fixed This is out of scope because the context of the conversation is upgrades. You're talking about the installer which means clean installs. -- 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://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
[Bug 1520948] Upgrade perl-Test-WWW-Mechanize-PSGI to 0.38
https://bugzilla.redhat.com/show_bug.cgi?id=1520948 --- Comment #8 from Fedora Update System --- perl-Test-WWW-Mechanize-PSGI-0.39-1.fc29 has been submitted as an update to Fedora 29. https://bodhi.fedoraproject.org/updates/FEDORA-2019-7ca5842031 -- 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://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org
[Bug 1520948] Upgrade perl-Test-WWW-Mechanize-PSGI to 0.38
https://bugzilla.redhat.com/show_bug.cgi?id=1520948 Fedora Update System changed: What|Removed |Added Status|ASSIGNED|MODIFIED --- Comment #7 from Fedora Update System --- perl-Test-WWW-Mechanize-PSGI-0.39-1.fc30 has been submitted as an update to Fedora 30. https://bodhi.fedoraproject.org/updates/FEDORA-2019-93da6851fb -- 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://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org
orphan compat-openssl10-pkcs11-helper
Once upon a time, qca needed this, but hasn't for quite awhile, so I'm no longer interested in maintaining compat-opensl10-pkcs11-helper According to repoquery, one item (still) depends on it: gnupg-pkcs11-scd -- Rex ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Orphaned packages seeking maintainers
The following packages are orphaned and will be retired when they are orphaned for six weeks, unless someone adopts them. If you know for sure that the package should be retired, please do so now with a proper reason: https://fedoraproject.org/wiki/How_to_remove_a_package_at_end_of_life Note: If you received this mail directly you (co)maintain one of the affected packages or a package that depends on one. Please adopt the affected package or retire your depending package to avoid broken dependencies, otherwise your package will be retired when the affected package gets retired. Grep this for you FAS name and follow the dependencies: See https://churchyard.fedorapeople.org/orphans-2019-05-06.txt Request unorphaning or unretirement via: https://pagure.io/releng/issues Package (co)maintainers Status Change Ray orphan 5 weeks ago aeskulap orphan 3 weeks ago ahkab orphan 4 weeks ago ceph-deploy branto, fsimonce, ktdreyer, 0 weeks ago orphan, trhoden clpbardcantrel, orphan 0 weeks ago cwiid orphan 5 weeks ago dvdbackup cicku, orphan3 weeks ago emacs-pymacs orphan 3 weeks ago gnome-dvb-daemon orphan 3 weeks ago gnome-shell-extension-orphan 3 weeks ago openweather gnome-shell-extension-panel-osd orphan 3 weeks ago gnue-common orphan 5 weeks ago gpart dcantrel, orphan 0 weeks ago h2akurtakov, dchen, lef, orphan0 weeks ago jam-control orphan 5 weeks ago ltspfsenslaver, orphan 2 weeks ago ninja-ide echevemaster, orphan 2 weeks ago nodejs-after nodejs-sig, orphan 7 weeks ago nodejs-alter nodejs-sig, orphan 7 weeks ago nodejs-ansi-font nodejs-sig, orphan 7 weeks ago nodejs-ansidiff nodejs-sig, orphan 7 weeks ago nodejs-archiver nodejs-sig, orphan 7 weeks ago nodejs-archiver-utils nodejs-sig, orphan 7 weeks ago nodejs-ast-traverse nodejs-sig, orphan 7 weeks ago nodejs-ast-types nodejs-sig, orphan 7 weeks ago nodejs-astral nodejs-sig, orphan 7 weeks ago nodejs-astral-angular-annotatenodejs-sig, orphan 7 weeks ago nodejs-astral-passnodejs-sig, orphan 7 weeks ago nodejs-async-cachenodejs-sig, orphan 7 weeks ago nodejs-async-each nodejs-sig, orphan 7 weeks ago nodejs-aws-sign2 nodejs-sig, orphan 7 weeks ago nodejs-base64-js nodejs-sig, orphan 7 weeks ago nodejs-basic-auth-parser nodejs-sig, orphan 7 weeks ago nodejs-bl nodejs-sig, orphan 7 weeks ago nodejs-breakable nodejs-sig, orphan 7 weeks ago nodejs-camel-case nodejs-sig, orphan 7 weeks ago nodejs-caniuse-db nodejs-sig, orphan 7 weeks ago nodejs-change-casenodejs-sig, orphan 7 weeks ago nodejs-clone nodejs-sig, orphan 7 weeks ago nodejs-clsnodejs-sig, orphan 7 weeks ago nodejs-co nodejs-sig, orphan 7 weeks ago nodejs-commoner nodejs-sig, orphan 7 weeks ago nodejs-compress-commons nodejs-sig, orphan 7 weeks ago nodejs-console-browserify nodejs-sig, orphan 7 weeks ago nodejs-constant-case nodejs-sig, orphan 7 weeks ago nodejs-crc32-stream nodejs-sig, orphan 7 weeks ago nodejs-dashdash nodejs-sig, orphan 7 weeks ago nodejs-date-now nodejs-sig, orphan 7 weeks ago nodejs-deferred nodejs-sig, orphan 7 weeks ago nodejs-defs nodejs-sig, orphan 7 weeks ago nodejs-degenerator
[Bug 1520948] Upgrade perl-Test-WWW-Mechanize-PSGI to 0.38
https://bugzilla.redhat.com/show_bug.cgi?id=1520948 Ralf Corsepius changed: What|Removed |Added Status|NEW |ASSIGNED --- Comment #6 from Ralf Corsepius --- Thanks, Emmanuel. Provided upstream's response, I am taking the plunge and will upgrade the package to 1.39 -- 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://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org
[Bug 1701654] perl-SNMP-Info-3.68 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1701654 Jitka Plesnikova changed: What|Removed |Added Status|NEW |CLOSED CC||jples...@redhat.com Fixed In Version||perl-SNMP-Info-3.68-1.fc31 Resolution|--- |RAWHIDE Assignee|w...@gouldfamily.org|jples...@redhat.com Last Closed||2019-05-06 14:50:55 -- 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://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org
Re: Upgrade to F30 gone wrong
On Mon, May 06, 2019 at 09:54:33AM -0400, Stephen John Smoogen wrote: > On Mon, 6 May 2019 at 09:26, Roberto Ragusa wrote: > > > On 5/6/19 1:40 PM, Julen Landa Alustiza wrote: > > > > > We found this bug before releasing, but it is not a release blocking bug > > (the upgrade criteria just cover clean n and n-1 upgrading to n+1 and this > > bug just happens whith continously upgraded systems since fc21 or lower) > > > > Wait a moment, is n and n-1 defined to "installed from scratch n and n-1?". > > Is this a precedent that n-installed is different than n-through-upgrades? > > > > > As far as I know this has been the case from Red Hat Linux 6.1 and all > Fedora's. It is nice if it works (which it generally does) but there are > too many little things which make it impossible to catch even a fraction of > the outliers. % dnf --releasever=31 system-upgrade download Before you continue ensure that your system is fully upgraded by running "dnf --refresh upgrade". Do you want to continue [y/N]: So this message should read “Ensure your system is different that we test for”? -- Tomasz Torcz RIP is irrevelant. Spoofing is futile. xmpp: zdzich...@chrome.pl Your routes will be aggreggated. -- Alex Yuriev ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
[Bug 1704645] Upgrade perl-Devel-Cover to 1.33
https://bugzilla.redhat.com/show_bug.cgi?id=1704645 Jitka Plesnikova changed: What|Removed |Added Summary|Upgrade perl-Devel-Cover to |Upgrade perl-Devel-Cover to |1.32|1.33 -- 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://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org
[Bug 1706973] New: Upgrade perl-Config-Model to 2.134
https://bugzilla.redhat.com/show_bug.cgi?id=1706973 Bug ID: 1706973 Summary: Upgrade perl-Config-Model to 2.134 Product: Fedora Version: rawhide Status: NEW Component: perl-Config-Model Assignee: david.hanneq...@gmail.com Reporter: jples...@redhat.com QA Contact: extras...@fedoraproject.org CC: david.hanneq...@gmail.com, perl-devel@lists.fedoraproject.org Target Milestone: --- Classification: Fedora Latest Fedora delivers 2.133 version. Upstream released 2.134. When you have free time, please upgrade it. -- 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://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org
Re: Docker and user namespaces on F30
Podman 1.2 and Docker CE 18.09.5 on My Fedora 30 work for your use case. $ rpm -q kernel kernel-5.0.5-200.fc29.x86_64 kernel-5.0.10-200.fc29.x86_64 kernel-5.0.10-300.fc30.x86_64 $ podman --version podman version 1.2.0 $ podman run -it --rm docker.io/php:7-fpm-alpine sh /var/www/html # uname -a Linux f8b9dafd7816 5.0.10-300.fc30.x86_64 #1 SMP Tue Apr 30 16:22:12 UTC 2019 x86_64 Linux $ docker --version Docker version 18.09.5, build e8ff056 $ docker run -it --rm docker.io/php:7-fpm-alpine sh /var/www/html # uname -a Linux 936e897b0a9b 5.0.10-300.fc30.x86_64 #1 SMP Tue Apr 30 16:22:12 UTC 2019 x86_64 Linux On Sat, May 4, 2019 at 5:05 PM Julien Enselme wrote: > > Hi, > > I just updated to F30 and my docker setup with user namespaces doesn't > work anymore. When I try to run: > docker run -it --rm docker.io/php:7-fpm-alpine sh > I get this error: > docker: Error response from daemon: OCI runtime create failed: > container_linux.go:348: starting container process caused > "process_linux.go:402: container init caused \"rootfs_linux.go:58: > mounting \\\"mqueue\\\" to rootfs > \\\"/var/lib/docker/1000.1001/btrfs/subvolumes/38ce5c87e31bbbcec010db85 > 383d1af57e8652ff4e4c411cebe0c2102a36a020\\\" at \\\"/dev/mqueue\\\" > caused \\\"operation not permitted\\\"\"": unknown. > > I tried to disable SELinux with setenforce 0 but got the same result. > > However, dk run --userns=host -it --rm docker.io/php:7-fpm-alpine sh > works fine. So it seems to be limited to user namespaces. > > My kernel: 5.0.9-301.fc30.x86_64 > > Any ideas on where this may come from? This worked fine on F29 (and > probably on older versions too, I have this setup for a while now). > > Regards, > -- > Julien Enselme > http://www.jujens.eu/ > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org -- Jun Aruga / He - His - Him jar...@redhat.com / IRC: jaruga ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: bootctl: no entry could be determined as default (Was: Upgrade to F30 gone wrong)
On Mo, 06.05.19 09:20, Dridi Boukelmoune (dridi.boukelmo...@gmail.com) wrote: > On Sun, May 5, 2019 at 1:45 PM Zbigniew Jędrzejewski-Szmek > wrote: > > > This makes the assumption, which was also made earlier in the thread, > > that it's somehow impossible to check what bootloader is installed. > > Why? My bootloader is happy to tell me its version: > > $ bootctl > > ... > > Current Boot Loader: > > Product: systemd-boot 241-565-g43d51bb > > Features: ✓ Boot counting > >✓ Menu timeout control > >✓ One-shot menu timeout control > >✓ Default entry control > >✓ One-shot entry control > > File: /EFI/systemd/systemd-bootx64.efi > > ... > > Nowadays it's gives the exact git commit it's built from, in the past > > it was just the release version, but either is enough. Therefore > > 'bootctl update' can fairly reliably *update*, i.e. do the installation > > if the thing we have is newer than the version already installed. > > That's news to me, and unfortunately it doesn't look as nifty on my system: > > ... > Current Boot Loader: > Product: n/a > Features: ✗ Boot counting >✗ Menu timeout control >✗ One-shot menu timeout control >✗ Default entry control >✗ One-shot entry control > ESP: n/a > File: └─n/a That only works properly on distros that implement the boot loader spec and the boot loader interface properly: https://systemd.io/BOOT_LOADER_SPECIFICATION https://systemd.io/BOOT_LOADER_INTERFACE Unfortunately, Fedora/grub do not support either. (Which is a pity of course, since it also means there's no working "systemctl --boot-loader-entry=" support in Fedora, nor "sytemctl kexec" support). Lennart -- Lennart Poettering, Berlin ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
[Bug 1702577] Upgrade perl-Net-Appliance-Session to 4.300005
https://bugzilla.redhat.com/show_bug.cgi?id=1702577 Jitka Plesnikova changed: What|Removed |Added Status|NEW |CLOSED Fixed In Version||perl-Net-Appliance-Session- ||4.35-1.fc31 Resolution|--- |RAWHIDE Assignee|negativ...@gmail.com|jples...@redhat.com Last Closed||2019-05-06 14:05:11 -- 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://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org
Re: Upgrade to F30 gone wrong
On Mon, 6 May 2019 at 09:26, Roberto Ragusa wrote: > On 5/6/19 1:40 PM, Julen Landa Alustiza wrote: > > > We found this bug before releasing, but it is not a release blocking bug > (the upgrade criteria just cover clean n and n-1 upgrading to n+1 and this > bug just happens whith continously upgraded systems since fc21 or lower) > > Wait a moment, is n and n-1 defined to "installed from scratch n and n-1?". > Is this a precedent that n-installed is different than n-through-upgrades? > > As far as I know this has been the case from Red Hat Linux 6.1 and all Fedora's. It is nice if it works (which it generally does) but there are too many little things which make it impossible to catch even a fraction of the outliers. > Regards. > > -- > Roberto Ragusamail at robertoragusa.it > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org > -- Stephen J Smoogen. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Upgrade to F30 gone wrong
Roberto Ragusa igorleak hau idatzi zuen (2019 mai. 6, al. 15:34): > On 5/6/19 1:40 PM, Julen Landa Alustiza wrote: > > > We found this bug before releasing, but it is not a release blocking bug > (the upgrade criteria just cover clean n and n-1 upgrading to n+1 and this > bug just happens whith continously upgraded systems since fc21 or lower) > > Wait a moment, is n and n-1 defined to "installed from scratch n and n-1?". > Is this a precedent that n-installed is different than n-through-upgrades? > > Regards. > > -- > Roberto Ragusamail at robertoragusa.it Technically speaking and for our releasing criteria yep, we block on fresh fc28/fc29 default installation of blocker package sets upgrades to fc30, previously upgraded fc28/fc29 are out of scope. We do our best to support upgrading from previously upgraded systems, but they're not considered blocker bugs if clean default installations of n or n-1 are not affected https://fedoraproject.org/wiki/Fedora_30_Beta_Release_Criteria#Upgrade_requirements > ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Kernel upgrades
On 5/5/19 6:29 PM, Chris Murphy wrote: > On Sun, May 5, 2019 at 8:22 AM Steven A. Falco wrote: >> >> I just upgraded my machine from F29 to F30. Now, whenever I install a new >> kernel, the new kernel does not automatically become the default. In other >> words, when I reboot, the previous kernel is still chosen by grub2. >> >> I can manually choose the new kernel in the grub2 menu, at which point it >> _does_ become the new default. I don't wind up at the "grub>" prompt, so I >> think grub2 itself is fine. It is just that the grubenv is not updated when >> the new kernel is installed. >> >> The machine has UEFI, but the system boots using the legacy BIOS >> compatibility layer. I know that the boot mechanism changed a bit for F30, >> but I'm not sure where to look to identify the cause of this problem. It >> doesn't seem to be the same issue as described in BZ 1652806. > > Post your /etc/default/grub file > > I'm willing to bet there's a line > > GRUB_SAVEDEFAULT=true > > If so, delete that line or comment it out and then run the usual > grub2-mkconfig and directing the output to the proper grub.cfg path > for your firmware type. > > The default that should be honored is found in the grubenv file, which > (curiously) is found at the same path no matter your firmware type: > /boot/efi/EFI/fedora/grubenv > > You can list its contents > > # grub2-editenv list > > And you can change it with > > #grub2-set-default > > The title of the kernel is found in the /boot/loader/entries/*conf > files - there is one file for each kernel. Thanks for the explanation. Here are the contents of /etc/default/grub. As you suspected, there is a GRUB_DEFAULT=saved line in there. GRUB_TIMEOUT=5 GRUB_DISTRIBUTOR="$(sed 's, release .*$,,g' /etc/system-release)" GRUB_DEFAULT=saved GRUB_DISABLE_SUBMENU=true GRUB_TERMINAL_OUTPUT="console" GRUB_CMDLINE_LINUX="resume=/dev/mapper/fedora-swap rd.lvm.lv=fedora/root rd.md.uuid=77ae1678:58a79067:c0ad29e6:bd1862f8 rd.md.uuid=bac1fa34:2d7a26e5:969d63ac:33ff4572 rd.lvm.lv=fedora/swap" GRUB_DISABLE_RECOVERY="true" GRUB_ENABLE_BLSCFG=true I looked for grubenv, and the only one I found is at /boot/grub2/grubenv. There is nothing in /boot/efi/EFI/fedora. This machine was set up on 2018-11-24, so it started life as a Fedora 29 machine. Is there a command I should run to move grubenv to /boot/efi/EFI/fedora? I think I would also have to create a symlink from /boot/efi/EFI/fedora/grubenv to /etc/default/grub. I could of course do it manually, but if there is a better procedure, like re-installing some package(s), that would be preferable. Steve ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
[Bug 1702578] Upgrade perl-Net-CLI-Interact to 2.300003
https://bugzilla.redhat.com/show_bug.cgi?id=1702578 Jitka Plesnikova changed: What|Removed |Added Status|NEW |CLOSED Fixed In Version||perl-Net-CLI-Interact-2.300 ||003-1.fc31 Resolution|--- |RAWHIDE Assignee|negativ...@gmail.com|jples...@redhat.com Last Closed||2019-05-06 13:37:13 -- 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://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org
Re: Upgrade to F30 gone wrong
On 5/6/19 1:40 PM, Julen Landa Alustiza wrote: We found this bug before releasing, but it is not a release blocking bug (the upgrade criteria just cover clean n and n-1 upgrading to n+1 and this bug just happens whith continously upgraded systems since fc21 or lower) Wait a moment, is n and n-1 defined to "installed from scratch n and n-1?". Is this a precedent that n-installed is different than n-through-upgrades? Regards. -- Roberto Ragusamail at robertoragusa.it ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Bad locale environment in mock install
For some reason, a "mock install" ends up running %post scripts with LC_ALL=en_US.UTF8, for which I need glibc-all-langpacks. This does not happen with a manual install from a mock shell. The tiny spec file below reproduces the problem. If I use "mock -n install" (I have a few other things in the chroot that I need), the log file shows that the locale is en_US.UTF8. If I run a mock shell, and manully "rpm -i" inside the shell, the locale is the expected C.UTF-8 Anyone knows why I'm getting a bad locale, with mock install? === Summary: Locale in mock Name: mocklocale Version: 1 Release: 1 License: 1 Group: System Environment/Base %description test %prep %build %install rm -rf $RPM_BUILD_ROOT mkdir -p $RPM_BUILD_ROOT %clean rm -rf $RPM_BUILD_ROOT %files %defattr(-,root,root,-) %post locale >/var/tmp/locale.log %changelog * Mon May 6 2019 Sam Varshavchik - - Initial build. pgpVIeyaVoyHE.pgp 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://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Where are armv7hl, i686 and ppc64le Container tar.xz files?
I am looking for arch container archive files like "Fedora-Container-Base-30-1.2.aarch64.tar.xz " for Fedora 30. I found the x86_64, aarch64 and s390x's archive files in below directory. But where is the archive file of armv7hl, i686 and ppc64le? I assume the multi archs except x86_64, aarch64 and s390x existed in the age of Fedora 24, 25 in below releases directory. And why below s390x does not have Fedora-Container-Base-*.tar.xz? https://dl.fedoraproject.org/pub/fedora/linux/releases/30/Container/ x86_64/ images/ Fedora-Container-Base-30-1.2.x86_64.tar.xz Fedora-Container-Minimal-Base-30-1.2.x86_64.tar.xz aarch64/ images/ Fedora-Container-Base-30-1.2.aarch64.tar.xz Fedora-Container-Minimal-Base-30-1.2.aarch64.tar.xz https://dl.fedoraproject.org/pub/fedora-secondary/releases/30/Container/ s390x/ images/ Fedora-Container-Minimal-Base-30-1.2.s390x.tar.xz => No Fedora-Container-Base-*.tar.xz Thanks. -- Jun Aruga / He - His - Him jar...@redhat.com / IRC: jaruga ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
[cancelled] Re: dropping autogenerated dependency on pkg-config
Due to lack of popular support for the idea (to put it mildly), I won't be doing this. Thank you all for participating in the discussion and good arguments (both pro and con). Zbyszek On Sun, Apr 28, 2019 at 08:55:56PM +, Zbigniew Jędrzejewski-Szmek wrote: > Hi everyone, > > currently, we autogenerate a dependency on pkg-config for all rpms > that ship a .pc file. "dnf repoquery --whatrequires /usr/bin/pkg-config" > returns 4632 entries on my laptop. > > This has always felt backward to me: those packages *provide* something > that is used by pkg-config, they don't *require* pkg-config for anything. > As an analogy, packages with headers are read by a C compiler, but > we don't make them require gcc, and if a package ships an .so file, we > don't add a dependency on the linker to it. Instead, anything which wants > to consume .pc files should simply depend on the tools that consume those > files (pkg-config, pkgconf, or a custom re-implementation). > > Proposal: let's drop the autogenerated dependency on /usr/bin/pkg-config > (this would require a trivial change in /usr/lib/rpm/pkgconfigdeps.sh). > > Note: autogenerated Provides/Requires like pkgconfig(foo) are not > part of this proposal. > > Advantages: > - less entries in the dependency graph > - removal of illogical dependency > - less packages installed (pkgconf, pkgconf-m4, pkgconf-pkg-config, > libpkgconf) > (Those packages are small, maybe 200k together so this isn't a strong >reason.) > > Disadvantages: > - stuff that uses pkg-config or pkgconf will need to grow a dependency > (e.g. meson which invokes /usr/bin/pkg-config internally). > so there will be some churn. > > Zbyszek ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Upgrade to F30 gone wrong
Nicolas Mailhot via devel igorleak hau idatzi zuen (2019 mai. 6, al. 09:59): Le dimanche 05 mai 2019 à 16:14 -0600, Chris Murphy a écrit : > > Right and that's the same with beta testing, which is how bugs like > this can sometimes not even get found until after release. A lot of > tests are done on pristine systems that are throw away. It's entirely > understandable few people want to test Fedora pre-release on their > rock solid 5+ year old Fedora system, but we actually stumbled on > this > in some sense by luck of alternate arch acting like a canary. That's not true, many boot problems are found quite early in the process by rawhide users, but rawhide users feedback is not taken into account by installer folks because they don't look at boot problems before quite late in the cycle, when rawhide users have already moved on manually, and the default solution is always to reinstall from scratch. So problems are found, just not fixed About this specific bug... We found this bug before releasing, but it is not a release blocking bug (the upgrade criteria just cover clean n and n-1 upgrading to n+1 and this bug just happens whith continously upgraded systems since fc21 or lower) so QA folks talked with bootloader ones, it was a difficult bug to fix without breaking things/overwriting other bootloaders and there was no time to announce, discuss and decide about policy changes so we went ahead documenting it on common bugs. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Orphaning rubygem-paranoia
Thanks for the action, Vit. I take care for next time. -- Jun Aruga / He - His - Him ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Upgrade to F30 gone wrong
On Mon, 2019-05-06 at 09:52 +0200, Nicolas Mailhot via devel wrote: > Le dimanche 05 mai 2019 à 16:14 -0600, Chris Murphy a écrit : > > Right and that's the same with beta testing, which is how bugs like > > this can sometimes not even get found until after release. A lot of > > tests are done on pristine systems that are throw away. It's entirely > > understandable few people want to test Fedora pre-release on their > > rock solid 5+ year old Fedora system, but we actually stumbled on > > this > > in some sense by luck of alternate arch acting like a canary. > > That's not true, many boot problems are found quite early in the > process by rawhide users, but rawhide users feedback is not taken into > account by installer folks because they don't look at boot problems > before quite late in the cycle, when rawhide users have already moved > on manually, and the default solution is always to reinstall from > scratch. Actually we monitor all the bugs all the time, but's it's basically a firehose - if we get multiple bugreports with a similar problems or a bug with many "happened to me as well" comments it's much more likely it will get fixed than a serious looking but (from bugzilla queue PoV) one-off bug. That can indeed get lost in the overall noise caused by all the imaginable setups and installation methods people use, combined with stuff like hardware failures and driver issues. > > So problems are found, just not fixed > > -- > Nicolas Mailhot > > > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html > 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://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
[Test-Announce] Proposal to CANCEL: 2019-05-06 Fedora QA Meeting
Hey everyone, I'm proposing we cancel the QA meeting tomorrow, Monday, May 6. Adam is on vacation and we don't have many action items from last week that we need to discuss, at least not right away. If you have something urgent, please send a message to the test list or respond to this email. Otherwise, enjoy the week off and we can plan to meet the Monday after tomorrow! Geoff Marr IRC: coremodule ___ 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://getfedora.org/code-of-conduct.html 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://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Upgrade to F30 gone wrong
On 5/6/19 10:46 AM, Nicolas Mailhot via devel wrote: Le dimanche 05 mai 2019 à 12:33 -0400, Steve Grubb a écrit : On Sunday, May 5, 2019 11:39:50 AM EDT Nicolas Mailhot via devel wrote: It would be nice to have a robust upgradeable bootloader setup. I'm pretty sure that ranks before having a pretty flicker-free boot to Fedora users. Pretty boot has been a workstation priority for how many releases now? Baring that, just having a reinstall bootloader option in rescue mode would go a long way to make this all less a PITA. Fedora has been doing incompatible bootloader changes every few years for as long as I remember Rescue mode? I couldn't find it. All references I could find to a rescue mode date back to 2013 or later. You have a rescue mode on the generic (or network) install iso. That's the swiss knife for rescuing Fedora systems that do not boot. You need to work from the iso because if your bootloader is DOA… you can't do anything from the installed system. Which is all good, if it works. The Fedora 30 netinstall iso tracebacked and failed to find a single Linux filesystem out of ~10 on my system which had this issue. Fortunately F29 rescue image worked. Should've filed a bug, but when your system is in a fast reboot loop prior to even getting to grub prompt, bug reports are not necessarily the first priority. That system started life as Fedora 15 or so, quite possible bootloader never updated since because ... well, there hasn't been any reason to do so, AFAIR. This was by far the worst outcome of a distro-upgrade that I can remember, and I've done quite a few. Somebody said something about being victims of our own success, and there's a point in there: distro-upgrades have been so uneventful for such a long time that I admit, it never even occurred to me to look at the common bugs page before s*** hit the fan. Unfortunately, while the rescue mode will usually find the installed system, it does not know how to install a bootloader with current Fedora defaults. You always need to dig up the current Fedora magic from the internet. Which is a pity since the main reason people rescue from the iso are boot problems Yup. And when you add the confusion of UEFI and BIOS bootloader differences (for one, do 'dnf reinstall ..', for the other, do 'grub2-install', wtf? and documentated in a dark kernel-related corner somewhere) and the less technical people are out the door already, and even the more technical are halfway there. Multiboot is always going to be a problem, but especially for simpler setups, /root/anaconda-ks.cfg provides more than just an educated guess as to where the bootloader might be lurking. The rescue mode could offer something based on that. - Panu - ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Orphaning rubygem-paranoia
I wish you have removed @ruby-packagers-sig from the list of maintainers prior orphaning the package. Anyway, I have opened releng ticket to get this fixed: https://pagure.io/releng/issue/8328 Vít Dne 06. 05. 19 v 12:03 Jun Aruga napsal(a): > We have orphaned rubygem-paranoia discussing co-maintainer, as It is > not a required package to install Rails. > https://bugzilla.redhat.com/show_bug.cgi?id=1675942#c7 > ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Orphaning rubygem-paranoia
We have orphaned rubygem-paranoia discussing co-maintainer, as It is not a required package to install Rails. https://bugzilla.redhat.com/show_bug.cgi?id=1675942#c7 -- Jun Aruga / He - His - Him jar...@redhat.com / IRC: jaruga ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Upgrade to F30 gone wrong
Le dimanche 05 mai 2019 à 16:14 -0600, Chris Murphy a écrit : > > Right and that's the same with beta testing, which is how bugs like > this can sometimes not even get found until after release. A lot of > tests are done on pristine systems that are throw away. It's entirely > understandable few people want to test Fedora pre-release on their > rock solid 5+ year old Fedora system, but we actually stumbled on > this > in some sense by luck of alternate arch acting like a canary. That's not true, many boot problems are found quite early in the process by rawhide users, but rawhide users feedback is not taken into account by installer folks because they don't look at boot problems before quite late in the cycle, when rawhide users have already moved on manually, and the default solution is always to reinstall from scratch. So problems are found, just not fixed -- Nicolas Mailhot ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Upgrade to F30 gone wrong
Le dimanche 05 mai 2019 à 12:33 -0400, Steve Grubb a écrit : > On Sunday, May 5, 2019 11:39:50 AM EDT Nicolas Mailhot via devel > wrote: > > It would be nice to have a robust upgradeable bootloader setup. I'm > > pretty > > sure that ranks before having a pretty flicker-free boot to Fedora > > users. > > Pretty boot has been a workstation priority for how many releases > > now? > > > Baring that, just having a reinstall bootloader option in rescue > > mode would > > go a long way to make this all less a PITA. Fedora has been doing > > incompatible bootloader changes every few years for as long as I > > remember > > Rescue mode? I couldn't find it. All references I could find to a > rescue mode date back to 2013 or later. You have a rescue mode on the generic (or network) install iso. That's the swiss knife for rescuing Fedora systems that do not boot. You need to work from the iso because if your bootloader is DOA… you can't do anything from the installed system. Unfortunately, while the rescue mode will usually find the installed system, it does not know how to install a bootloader with current Fedora defaults. You always need to dig up the current Fedora magic from the internet. Which is a pity since the main reason people rescue from the iso are boot problems Regards, -- Nicolas Mailhot ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Upgrade to F30 gone wrong
On 5/5/19 7:59 PM, Nico Kadel-Garcia wrote: On Sun, May 5, 2019 at 7:49 AM Roberto Ragusa wrote: [root@localhost ~]# grep fedora-release /root/install.log Installing fedora-release-3-8.i386. [root@localhost ~]# uname -a Linux localhost 5.0.4-200.fc29.x86_64 #1 SMP Mon Mar 25 02:27:33 UTC 2019 x86_64 x86_64 x86_64 GNU/Linux You're kind of begging for pain, at this point. Thee have been enough subtle, fundamental, and functionally incompatible updates to filesysems such as ext4 and xfs that a surprise at upgrade should not shock you too much. You are supposing the the filesystem has remained the same. Instead, the content has been copied over a couple of times, so it is now a fresh ext4 (on lvm, on dmcrypt, with SSD discard enabled,...). This system was upgraded from Fedora 3 up to 29. Also note it started as i386, but at Fedora 16 got transformed into x86_64, a kind of (manual) upgrade never officially considered possible. *Ouch*. OK, now you're just hurting yourself. Definitely time to back up your old system and do a fresh install. Turning an i386 to x86_64 was easier than expected. First you switch to 64 bit kernel (64 bit kernel with 32 bit userspace is a good but not widely known idea); then you add the x86_64 libs (that can often live in parallel to i686 ones); then you switch the real applications to x86_64 and finally you can remove i686 libs you don't want anymore (possibly every one of them). All done with yum and rpm on a live system. This has been my daily work system for about 15 years, no reason to scratch it. it probably contains no traces of the initial setup (apart from /root/install.log), it evolved without any discontinuity. Last time I ran anaconda for upgrading was in F14 (according to /root/upgrade.log); after that it has always been yum/dnf. Regards. -- Roberto Ragusamail at robertoragusa.it ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
[Bug 1705095] perl-Verilog-Perl-3.464 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1705095 Fedora Update System changed: What|Removed |Added Status|ON_QA |MODIFIED --- Comment #3 from Fedora Update System --- perl-Verilog-Perl-3.466-1.fc30 has been submitted as an update to Fedora 30. https://bodhi.fedoraproject.org/updates/FEDORA-2019-4e177d2751 -- 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://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org
[Bug 1706481] perl-Verilog-Perl-3.466 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1706481 --- Comment #1 from Fedora Update System --- perl-Verilog-Perl-3.466-1.fc30 has been submitted as an update to Fedora 30. https://bodhi.fedoraproject.org/updates/FEDORA-2019-4e177d2751 -- 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://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org
bootctl: no entry could be determined as default (Was: Upgrade to F30 gone wrong)
On Sun, May 5, 2019 at 1:45 PM Zbigniew Jędrzejewski-Szmek wrote: > This makes the assumption, which was also made earlier in the thread, > that it's somehow impossible to check what bootloader is installed. > Why? My bootloader is happy to tell me its version: > $ bootctl > ... > Current Boot Loader: > Product: systemd-boot 241-565-g43d51bb > Features: ✓ Boot counting >✓ Menu timeout control >✓ One-shot menu timeout control >✓ Default entry control >✓ One-shot entry control > File: /EFI/systemd/systemd-bootx64.efi > ... > Nowadays it's gives the exact git commit it's built from, in the past > it was just the release version, but either is enough. Therefore > 'bootctl update' can fairly reliably *update*, i.e. do the installation > if the thing we have is newer than the version already installed. That's news to me, and unfortunately it doesn't look as nifty on my system: ... Current Boot Loader: Product: n/a Features: ✗ Boot counting ✗ Menu timeout control ✗ One-shot menu timeout control ✗ Default entry control ✗ One-shot entry control ESP: n/a File: └─n/a Available Boot Loaders on ESP: ESP: /boot/efi (/dev/disk/by-partuuid/$UUID) File: └─/EFI/BOOT/BOOTIA32.EFI File: └─/EFI/BOOT/BOOTX64.EFI Boot Loaders Listed in EFI Variables: Title: Fedora ID: 0x0001 Status: active, boot-order Partition: /dev/disk/by-partuuid/$UUID File: └─/EFI/fedora/shimx64.efi Title: Linux Firmware Updater ID: 0x Status: active, boot-order Partition: /dev/disk/by-partuuid/$UUID File: └─/EFI/fedora/shimx64.efi ... Where $UUID is the same for all three occurrences. Dridi ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Upgrade to F30 gone wrong
On Sat, May 4, 2019 at 9:36 PM Chris Murphy wrote:
>
> While handling this bug with a Common Bugs report is suboptimal, it
> has long been expected that users should read Common Bugs before
> installing or upgrading their systems. Making that advice more
> prominent might be reasonable.
I never heard of that, is it mentioned by the release announcement or
the blog entry on how to upgrade from fX to f{X+1}?
I think I would have remembered (and definitely checked the Common
Bugs) if that were the case. I will probably have plenty of time to
forget about it until f31 is out, so I'm all for advertising the
Common Bugs more!
Dridi
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
[Bug 1706481] perl-Verilog-Perl-3.466 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1706481 Jitka Plesnikova changed: What|Removed |Added Status|NEW |MODIFIED Fixed In Version||perl-Verilog-Perl-3.466-1.f ||c31 -- You are receiving this mail because: You are on the CC list for the bug. ___ perl-devel mailing list -- perl-de...@lists.fedoraproject.org To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/perl-de...@lists.fedoraproject.org
Re: Enable dmarc mitigations
On May 5, 2019 9:43:02 PM GMT+02:00, stan via devel wrote: >On Sun, 5 May 2019 14:19:59 +0200 >Vitaly Zaitsev via devel wrote: > >> Hello, qrsBRWN. >> >> Sun, 05 May 2019 10:57:06 +0200 you wrote: >> >> > Exactly what platform did you have in mind? >> >> Discourse[1] for example. GTK developers already testing it[2] as >> mailing lists replacement. >> >> 1: https://github.com/discourse/discourse >> 2: https://blog.gtk.org/2019/03/05/testing-discourse-for-gtk/ > >To each their own, of course, but there was a long discussion of >discourse here a while ago. I tried it out, but it was like a bad >version of a mailing list. It sent me a mail informing me that there >were messages to read. Then I had to go there and read the messages on >the web, using their interface. I have used Discourse and yes it does behave pretty much like a webforum from 90s. > >So much better than just getting the message directly into my chosen >mail client! (/sarcasm) It probably works well for those who are >addicted to the web, and check their phone every few minutes; it >fits with their work style, plus they get affirmation. But I don't >fit that template, so I wasn't enamored. > >If forced to, I could probably use it, but I prefer the push model >to the pull model. That is, it isn't an improvement for me, it doesn't >buy me anything I want. Exactly this. While swanky it really does nothing new but takes away accessibility since there will be a gazillion email notifications which in and of themselves are useless. With a mailing list I can just reply directly instead of having to switch to a different interface. This just adds a step and forces me to use a particular client. I realized now that this mail sounds really negative. To add nuance: great suggestion and I'm all for changing things if the new things solves the problem better than the old things. Discourse however, doesn't seem to do that. > > >___ >devel mailing list -- devel@lists.fedoraproject.org >To unsubscribe send an email to devel-le...@lists.fedoraproject.org >Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html >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://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
